METHOD, SYSTEM, COMPUTER PROGRAM PRODUCT FOR UPDATING SOFTWARE

Abstract

A method for updating code in an execution environment, comprising: Identifying an update device associated with a new chain-of-trust code; Measuring a characteristic feature of the identified updating device and providing the characteristic feature of the updating device to an attestation system having means for storing and comparing measured values with attestation values; Installing the new chain-of-trust code into the execution environment; Measuring a characteristic of the new chain-of-trust code and providing the characteristic of the new chain-of-trust code to the attestation system; Notifying the attestation system that the chain-of-trust code has been updated to a new version, whereby the attestation system shall verify the source of the new chain-of-trust code immediately after the notification; Attesting the identifying feature of the update device associated with the new chain-of-trust code against a previously stored attestation value by the attestation system; and in response to a determination by the attestation system that the identifying characteristic of the update device matches a previously stored attestation value of the update device, validating the integrity of the updated chain-of-trust code in the execution environment, where, if the identifying characteristic of the updating device does not match the previously stored attestation value and the attestation system has verified the source of the corresponding code, then: Updating the attestation value with the identifying characteristic of the new version of the component; and Notify a management level that the identifying characteristic does not match an attestation value and whether the attestation system recognizes the source of the component.

Description

Technical area

[0001] The present invention relates to a method, a system, and a computer program product for updating software. The invention particularly relates to processes for trusted booting and remote attestation. As set forth in this specification, trusted computing, trusted booting, and remote attestation generally refer to technology standards developed by a standards organization called the Trusted Computing Group. BACKGROUND

[0002] Trusted booting is a method for booting and establishing a chain of trust in a trusted computing system. Boot components can be cryptographically measured and stored in a secure device, such as a Trusted Platform Module (TPM). Each boot component measures a characteristic reading of the next boot component and stores this reading in the secure device, determining the reading before control is passed to the measured component. Once the system is running, the readings can be extracted for verification by a remote system using a remote attestation process, such as Direct Anonymous Attestation (DAA). A sequence of readings is called a chain of trust.

[0003] Computer systems are frequently updated with new features and software additions. An update may require changing a boot component that is part of the trust chain, and after such an update, remote attestation will indicate a change in the metric; the trust chain is broken. With many systems and numerous updates, this creates a major, difficult management problem. The change in the metric will only "show up" after at least one re-reading. The re-reading may occur only upon reboot or during runtime (depending on the system's design).

[0004] There is therefore a need in technology to solve the above-mentioned problem.

[0005] The document “Property-Based TPM Virtualization” by Ahmad-Reza Sadeghi, Christian Stüble and Marcel Winandy, published in “Information Security, 11th International Conference, ISC 2008, 2008, pp. 1-16, http: / / www.trust.rub.de / research / publications / SaStWi2008 / [accessed on October 18, 2016] describes a flexible and privacy-preserving design of a virtual Trusted Platform Module.

[0006] The paper “A Practical Property-based Bootstrap Architecture” by René Korthaus et al., published in “Proceedings of the 2009 ACM Workshop on Scalable Trusted Computing, 2009, pp. 29-38, http: / / doi.acm.org / 10.1145 / 1655108.1655114” [accessed on October 18, 2016], describes a property-based bootstrap architecture with an extended bootloader.

[0007] The document US 2008 / 0 256 363 A1 describes an update system for trusted components comprising a check logic configured to validate the integrity of an update of a trusted component of a computing device, and logic arranged in the trusted component configured to validate the integrity of the check logic.

[0008] The document “TCG Mobile Reference Architecture” of the “Trusted Computing Group”, Beaverton, Oregon, June 12, 2007, https: / / www.trustedcomputinggroup.org / wpcontent / uploads / MPWG-tcg-mobile-reference-architecture-1.pdf [accessed October 18, 2016] describes Trusted Platform Modules (TPMs) and their use by a client computer. SUMMARY OF THE INVENTION

[0009] The invention is based on the object of providing an improved method, system, and computer program product for updating software. This object is achieved by the subject matter of the independent patent claims.

[0010] In a first aspect of the invention, a method is provided for updating code in an execution environment, the method comprising: installing new code; measuring a characteristic of the new code and providing the characteristic to an attestation system; notifying the attestation system that the code has been updated to a new version, wherein, if the attestation system determines that the characteristic of the new code does not match a previously stored attestation value, the system knows that a permissible mismatch may have occurred.

[0011] In the preferred embodiment, the code is a component used in the boot process, although the code could also refer to another component in the chain of trust that is not booting. In other embodiments, the code is all or part of firmware, a hypervisor, a virtual machine, an operating system, or an application. New code can be a new version of a component or an entirely new component.

[0012] A previously stored attestation value is a reference value used by the attestation system to check whether a valid identifying characteristic of a system component is present. The previously stored attestation value is stored in the attestation system by a system administrator or requested by an initialization process, whereby a first identifying characteristic of a component is trusted and used by the attestation system as an attestation value.

[0013] The method advantageously comprises detecting the presence of a new version of an operating system component, the update phase being carried out automatically.

[0014] The invention notifies the attestation system of the update, but attestation values can only be updated by the attestation system or a system administrator. Attestation values could only be updated by the hypervisor in a less secure embodiment. In the preferred embodiment, the hypervisor has no access to the attestation system except through notifications; the attestation system must perform attestation immediately upon notification, verifying the source of the new version of the component. Once it has verified the source of the new component, it can accept the boot measurement of the new component upon a future reboot, even if the measurement does not match the stored attestation value.

[0015] A hypervisor notification phase is added to the familiar software update process, so that the chain of trust begins with the hypervisor. In the preferred embodiment, the notification phase consists of the updated system sending a "check me" message to the attestation system, so that the attestation system knows that a new measurement has been determined. The attestation notification prevents the attestation system from panicking when the attested system reboots and detects different measurements.

[0016] The preferred embodiment may allow a trusted component, such as the hypervisor, to participate in the measurement process and measure another component so that the attestation system can trust the measured component.

[0017] Installing the new version (651.N) of the component (616.N) advantageously comprises: identifying an update device (612.N) associated with the new version (651.N); measuring a characteristic feature of the identified update device (612.N); installing the new version (651.N) of the device; and providing the characteristic measurement value (PCR17) of the update device to the attestation system (620), wherein the attestation system (620) can match the characteristic measurement value (PCR17) of the update device (612.N) with a previously stored attestation value (624.N) to validate a permissible update. The reference numerals of Fig. 6 have been included in the previous paragraph for illustrative purposes and as an example only.

[0018] Further advantageously, immediately after notification, the attestation system checks the source of the new version of the component it finds in the hypervisor. In the preferred embodiment, checking the source of a component involves checking the component that installed the update; however, in other embodiments, other checks may be performed, such as where the update came from or how it was installed. Furthermore, if the metric does not match an attestation value and the attestation system has checked the source of the corresponding component, one or more of the following is performed: updating the attestation value with the metric of the new version of the component; and / or notifying a management layer that a metric does not match an attestation value and whether the attestation system recognizes the source of the component.

[0019] In a second aspect of the invention, a method is provided for updating and attesting an operating system component in a hypervisor, the method comprising: detecting a new version of a component of an operating system; installing the new component version; measuring an identifying characteristic of the component and providing the characteristic to an attestation system; notifying the attestation system that a component has been updated to a new version; and wherein, if the attestation system detects that the identifying characteristic of the new component does not match a previously stored attestation value, the system knows that a permissible mismatch may have occurred.

[0020] In a third aspect of the invention, there is provided a method for checking the integrity of a program, the method comprising: Extracting a component measurement stored by the program installation process; checking the component measurement against measurements stored by the checking system and rejecting the measurement if it does not match; further checking the rejected component measurement and rejecting it again if it does not come from another component known to the checking system; and indicating an acceptance if the component measurement passes a test and a rejection if the measurement does not pass any of the tests.

[0021] In view of a further aspect, the present invention provides a computer program product for updating code in an execution environment, the computer program product comprising: a computer-readable storage medium readable by a processing circuit and storing instructions for execution by the processing circuit to perform a method for performing the steps of the invention.

[0022] In a further aspect, the present invention provides a computer program stored on a computer-readable medium and loadable into the internal memory of a digital computer, the computer program comprising software code portions when the program is executed on a computer to perform the steps of the invention.

[0023] This description presents a solution that allows a system to inform the attesting party what to expect during the next trusted boot in a virtualized system using a virtual TMP. Brief description of the drawings

[0024] The present invention will now be described by way of example only with reference to preferred embodiments as illustrated in the following figures: Fig. 1 is a schematic implementation diagram of a trusted data processing system according to the prior art and in which a preferred embodiment of the present invention may be practiced; Fig. 2 is a schematic process diagram of a trusted data processing system according to the prior art and in which a preferred embodiment of the present invention may be practiced; Fig. 3 is a schematic process diagram for attesting the trusted data processing system according to the prior art and in which a preferred embodiment of the present invention may be practiced; Fig. 4 is a schematic process diagram for updating the trusted computing system according to the prior art and in which a preferred embodiment of the present invention may be practiced; Fig. 5 is a comparison diagram showing equivalent steps of an update process of the embodiment and the update process of the prior art, in which a preferred embodiment of the present invention can be carried out; Fig. 6 is a schematic implementation diagram of a system according to a preferred embodiment of the present invention; Fig. 7 is a schematic process diagram of the update process according to a preferred embodiment of the present invention; Fig. 8 is a process diagram of a new component loading process according to a preferred embodiment of the present invention; Fig. 9 is a process diagram of an attestation process according to a preferred embodiment of the present invention; and Fig. 10 is a schematic implementation diagram of a system of a physical embodiment. DESCRIPTION OF THE EMBODIMENTS

[0025] Fig. 1 is a simplified implementation diagram of a prior art trusted system comprising: a platform 10; a Trusted Platform Module 20 (TPM 20) and an attestation system 30. The platform 10 comprises: a boot process 200 (hereinafter referred to as Fig. 2); an update process 12; and the boot components 15.1 to 15N (here and elsewhere in this description, the letter N is used to represent a number, but not a specific number). The boot components 15 include: the boot components 15.1 to 15N. The TPM 20 has the platform configuration registers 22.1 to 22N. The TPM 20 is shown implemented separately from the platform 10, but it could also be part of the platform 10. A platform configuration register PCR is also referred to as a register. The attestation system 30 has an attestation process 300 and the attestation values 34.1 to 34N. The attestation system 30 is shown implemented separately from the platform.

[0026] Fig. 2 is a simplified process diagram of a prior art boot process 200 comprising a sequence of steps 202 through 212 for executing a number of boot components in the following order.

[0027] Step 202 is used to execute the first boot component.

[0028] Step 204 is used to measure a characteristic of the next boot component and store the measured value in a register (for example, 22.1).

[0029] Step 206 is used to execute the next component.

[0030] Step 208 may be used to measure a characteristic of the subsequent boot component and store the measured value in a subsequent register (for example, 22.2).

[0031] Step 210 represents a boot cycle that repeats steps 206 and 208 for possible subsequent boot components.

[0032] Step 212 represents the end of the process when no boot components remain.

[0033] In the preferred embodiment, a hypervisor performs initial steps (corresponding to steps 200, 202, 204 in the prior art) so that the measuring and execution begin in the hypervisor. For example, the hypervisor provides a hypercall "H-Measure" that measures and executes code such as a next boot component. In another example, platform firmware could perform the initial steps and start a subsequent boot component in a hypervisor.

[0034] Fig. Figure 3 is a simplified process diagram of a prior art attestation process 300 comprising a sequence of logic steps 302 through 308 described below. The attestation process is executed after the trusted platform has booted.

[0035] Step 302 is used to extract measured values stored in registers.

[0036] Step 304 is used to compare the measured values with the attestation values 34.1 to 34N stored by the attestation system 30.

[0037] Step 306 is used to indicate 1) an acceptance if the values match the measured values, or 2) a rejection if there is no match between the values and measured values.

[0038] Step 308 represents the end of the process. The state-of-the-art attestation process relies on the attestation values being correct, and the state-of-the-art attestation values are updated by an administrator.

[0039] Fig. 4 is a simplified process diagram of a prior art update process 400 having a sequence of steps 402 through 406.

[0040] Step 402 is used to determine that a component needs to be updated with a newer version of the component.

[0041] Step 404 is used to update the component by removing the old component and loading the new component.

[0042] Step 406 represents the end of the process. In this process, the component is not identified as a boot component and therefore it is not known that the update will affect the attestation value maintained by the attestation system.

[0043] Fig. Figure 5 shows a comparison of results from a prior art trusted system with the results from the preferred embodiment trusted system.

[0044] A complete update and attestation according to the state of the art comprises the following combined processes in sequence: 200, 300, 400, and 300 again. The boot process 200 loads the boot components, and each component is measured in turn; the measured values are stored in the TPM 20. The attestation process 300 retrieves the measured values and checks them against the stored attestation values, indicating acceptance because the values and measured values match. The update process 400 performs an update on one or more components, including one or more boot components, changing the TPM measured value. Further execution of the attestation process 300 indicates rejection because the attestation value was not updated and the attestation values and the TPM measured values do not match.

[0045] The update and attestation process of the preferred embodiment comprises the following combined process steps in sequence: 606, 622, 700, and 622 again. The boot process 606 loads the boot components; each boot component is measured, and the measurements are stored in a TPM. An attestation process 622 of the embodiment retrieves the measurements and checks them against the stored attestation values, indicating acceptance because the values and measurements match. The update process 700 of the embodiment performs an update on one or more boot components and changes the measurements in the TPM. In the preferred embodiment, the attestation system is notified that the update has been performed. The attestation process 622 indicates acceptance because it checks the source of the update component.

[0046] In another embodiment, the attestation values are updated by measured values determined during the update.

[0047] Fig. Figure 6 shows a schematic component diagram of the trusted computing system of the preferred embodiment. The trusted computing system includes a platform 600; an attestation system 620; and an update registry 650.

[0048] The update registry 650 is a storage resource and index for maintaining the current versions of individual operating system and application components for use in operating system or application update instances. In the figure, the update registry includes updates 651.1 through 650N. Querying the component version numbers or dates in the update registry against the component version numbers or dates of an operating system instance determines which components need to be updated.

[0049] During operation, the platform 600 is a hardware platform with a hypervisor 604 for running and managing virtual operating systems. An example of a platform is an IBM Power System. During operation, the hypervisor 604 includes: a boot process 606; an update process 700; update facilities 612.1 through 612N; and a virtual machine hosting environment. The hypervisor of the present example creates a single virtual machine 605 in the single operating system hosting environment 614; however, the preferred embodiment assumes that more than one operating system could be updated on more than one virtual machine. Each virtual machine has a corresponding virtual TPM. The attestation system trusts each virtual machine running on a hypervisor.Trust comes from a real TPM or from current and trusted signed updates and other security measures.

[0050] The virtual Trusted Platform Module 610 has a plurality of registers (PCRs) PCR1, 2, 3 ... 17, 18 ... N. Each PCR can store a measured value or a value.

[0051] The update devices 612.1 to 612N comprise an example set of separate components, each of which is associated with a corresponding boot component (616.1 to 616N), and each of which can update the operating system with a corresponding update (651.1 to 651N). For example, the boot component 616.3 can be updated by the update device 612.3 using the update 651.3, and so on for the boot component 616N, the update device 612N, and the update 651N. Each update device has links to corresponding updates and boot components. Each update device is to be measured and then executed by the hypervisor. The measured value is stored in a first declared register (for example, PCR17).During execution, an updater measures the new component it is installing and updates a second, agreed-upon register (for example, PCR18). Note that the updater can only copy something or create the component during processing. The "Bosboot" updater, for example, creates an image of a new operating system component from many configuration files and system data during processing.

[0052] In a preferred embodiment, the updater is capable of directly notifying the attestation system that the operating system has been updated. This may involve the updater establishing direct contact with the attestation system or obtaining a common process on the hypervisor to establish contact. The virtual operating system 614 (for example, IBM AIX*), when loaded by the hypervisor, includes boot components 616.1 through 616N, which are loaded as part of the boot process to provide a functioning virtual operating system with applications, data, and interfaces. Other operating system components that are not part of the boot process are not shown.

[0053] The boot process 606 has a process like the boot process 200 according to the prior art.

[0054] The attestation system 620 includes an attestation process 622 and the attestation values 624.1 through 624N. The attestation system 620 and the hypervisor 604 have agreed on which registers (PCR1...N) are used to record the updater's measurement value and the modified component's signature (also referred to as the identifying characteristic). In the preferred embodiment, these agreed registers are referred to as the first agreed register and the second agreed register. In the example, the first and second agreed registers are, for example, PCR17 and PCR18.

[0055] The attestation system must attest the registers in the TPM. All register values are propagated using an attestation protocol that uses digital signatures and other security mechanisms to ensure trust. The attestation system can detect whether the agreed-upon registers (for example, the first and second agreed-upon registers PCR17 and 18) are set and are capable of preparing for reboot and subsequent modification of the currently trusted registers (for example, PCR1, 2, and 3).

[0056] The attestation system reads the first agreed-upon register (for example, PCR17) and determines that the updater is a trusted updater. This determination is made by: examining a master list of metrics from known and trusted updaters; and examining a trusted boot event log, updated with metadata whenever the registers were changed. If the attestation system determines that the first agreed-upon register contains a trusted value, it assumes that the second agreed-upon register also contains a trusted value, which is used in the next comparison of the boot register associated with the updater detected in the update.

[0057] With reference to Fig. 7, the hypervisor update process 700 comprises the logical process steps 702 to 710.

[0058] Step 702 is used to determine that a boot component has an available update by checking the update registry 650 for newer components. For example, the boot component 616.3 of the virtual operating system 614 has version 1 of the AIX boot image (AIX Boot Image 1), but the update 651.3 in the update registry 650 was loaded with version 2 of the AIX boot image (AIX Boot Image 2). This is preferred, but in other embodiments, a different mechanism may be used to determine when to update.

[0059] Step 704 serves to load the new boot component by activating the associated update device (for example, the update device 612.3), and the associated update device is capable of updating the boot component; the associated update device accesses the new boot component and installs the new boot component over the old boot component or installs it in place of the old boot component. The above description is the essential operation of the boot loading step, and a more detailed operation of the boot loading step is described below with reference to Fig. 8 described.

[0060] Step 706 is used to measure a new boot component after it has been loaded into the virtual operating system, so that the new measurement uniquely identifies the new boot component in its location in the virtual operating system. The new measurement is added to a specific register in the Trusted Platform Module. In the preferred embodiment, the attestation system 620 looks for the specific register and knows that it holds a new measurement, not an old one.

[0061] Step 708 is used to notify the attestation system 620 that a boot component has been updated.

[0062] Step 710 indicates the end of the update process 700.

[0063] While step 704 for loading a new boot component was described above as a simple embodiment of the invention, the preferred embodiment of the invention uses further processing to improve the level of trustworthiness. The step 704 described below with reference to Fig. The process 704 for loading a new boot component described in Figure 8 is a preferred embodiment of the invention and includes process steps 802 to 812.

[0064] Step 802 identifies an update component associated with the boot component. In the example below, a program named bosboot is invoked to overwrite AIX boot image 1 with AIX boot image 2.

[0065] Step 804 is used to load the identified update device into the operating system.

[0066] Step 806 measures the update device and adds the measured value to the first declared register. In the example below, a program named Hypercall Bosboot measures and increments the first declared register (for example, PCR17) in the TPM.

[0067] Step 808 is used to invoke the update facility to install the update component. In the example below, Bosboot writes the new boot image.

[0068] Step 810 is used to measure the new boot component and add the measured value to the second declared register.

[0069] Step 812 is the end of process 704 for loading a new boot component.

[0070] With reference to Fig. 9, the logical process steps 902 through 910 of the attestation process 622 according to the preferred embodiment are described. The attestation process is executed after the trusted platform boots, but is independent of the trusted platform.

[0071] Step 902 is used to extract measured values stored in registers.

[0072] Step 904 is used to compare the measured values with the attestation values 624.1 to 624N stored by the attestation system 620.

[0073] Step 906 is used to indicate an acceptance when the values match the measured values.

[0074] Step 908 is used to indicate a rejection if mismatched boot readings from step 906 match a known update device.

[0075] Step 910 is used to indicate a rejection if there are inconsistent measured values after steps 908 and 910.

[0076] Step 912 is used to indicate the end of the process. EXAMPLE

[0077] An example of the operation of the preferred embodiment includes an IBM Power* system hosting an IBM Power Hypervisor (PHYP) with a single virtual AIX system. The AIX system uses a virtual TPM device and includes trusted boot functionality. The system is monitored and attested by a separate attestation system. During attestation, the following PCR measurements are returned, where PCR1, PCR2, and PCR3 are registers in the TPM. PCR1=Open firmware PCR2=AIX boot image PCR3=AIX Trusted Execution Database

[0078] The attestation system considers these measurements trustworthy and does not indicate a security issue when they are returned via attestation. The following functions are available to allow the AIX boot image to be modified and the attestation system to be informed of this update.

[0079] PHYP is modified to include a new method (called a hypercall, specifically H_Measure). H_Measure takes parameters that describe something to be measured and executed, such as address and length. The resulting measured value is placed in a specific register of the TPM, such as PCR17. The specific boot register is not important; it can be an absolutely addressed register or an indirectly addressed register. What matters is that the attestation system knows where to look. PHYP returns control to AIX at the passed-by address. The important difference is that the hypercall is first used to measure a component and then to execute that component. What is measured is subsequently executed.

[0080] To function, the hypervisor must also be trustworthy. The trustworthiness of a state-of-the-art hypervisor is ensured by the IBM Power System, which updates the PHYP code in a very restrictive manner, and only updates signed by the IBM Power System can be installed. In the present embodiment, the IBM Power System has a real TPM device, and the PHYP is measured in the real TPM. A technique known as "deep attestation" can be used to retrieve the real TPM measurements via the virtual AIX system.

[0081] A defined set of AIX programs, referred to in the description as updaters, are allowed to modify components of the trusted boot process. In this example, Bosboot is the only updater program allowed to update the AIX boot image. With this technique, Bosboot must be trusted, and therefore, when Bosboot is built, a digital signature of Bosboot is taken and published. For H_Measure to successfully measure Bosboot, Bosboot should be a single static piece of code that can be loaded into a contiguous piece of memory so that the measurement can be performed. It is important that Bosboot be measurable. Bosboot does not need to be static if other security measures are in place to ensure that non-static programs cannot be easily bypassed.

[0082] In this example, an AIX boot image 1 is changed to an AIX boot image 2, thereby informing the attestation system that an unnecessary security breach has been prevented. The operations are as follows: 1. Bosboot (an update facility) is called (step 702) to rewrite the boot image. 2. The AIX kernel loads (step 704) Bosboot into memory and calls H_Messen. 3. PHYP measures (step 706) Bosboot and magnifies PCR17 in the TPM. 4. Execution is passed from the hypervisor to Bosboot, and Bosboot writes the new boot image and inflates PCR18 with a measurement of an AIX boot image. 2 Similar to PCR17, it doesn't matter which register is used, as long as the attestation system knows that PCR18 has a special meaning. 5. The attestation system is informed (step 708) that it should attest again, with no further information needing to be exchanged.

[0083] If the attestation system now attests the system, the following values are returned (step 902). PCR1=Open firmware PCR2=AIX boot image 1 PCR3=AIX Trusted Execution Database1 PCR17=bosboot PCR18=AIX boot image2

[0084] The attestation system will detect that PCR17 has changed since the last attestation, which will trigger an action (step 908) in the attestation system. First, the value of PCR17 is checked. The system determines that a legitimate IBM-published bosboot was invoked, so the system knows that PCR18 will be a new AIX boot image. When the attestation system now completes a new trusted boot, the attestation system can determine that the new value reported via PCR1 came from a trusted bosboot, so no action is required. EMBODIMENTS

[0085] The above describes the preferred embodiment with a hypervisor to manage a virtual machine operating environment, as well as other embodiments in which a single function may differ in one way or another from the preferred embodiment.

[0086] An embodiment that differs substantially from the preferred embodiment relates to an embodiment without virtualization, one as in Fig. 10. This embodiment includes a platform 1000; an attestation system 1020; and an update registry database 1050. The platform 1000 is designed and manufactured using silicon. Similar to the preferred embodiment, the TPM 1010 is not an integral component, and another secure device / storage that maintains metrics and something similar to attestation could be used.

[0087] The update registry 1050 is a storage resource and index for maintaining the current versions of individual operating system and application components for use in operating system or application update instances. In the figure, the update registry includes updates 1051.1 through 1050N. Querying the component version numbers or dates in the update registry against the component version numbers or dates of an operating system instance determines which components need to be updated.

[0088] The attestation system 1020 has an attestation process 1022 and the attestation values 1024.1 to 1024N. Apart from the difference that the operating system is a real operating system running on a physical machine, the attestation process 1022 and the attestation values 1024.1 to 1024N are the same as those in Fig. 6 shown.

[0089] During operation, the platform 1000 is a hardware platform comprising: a boot process 1006; an update process 1700; update devices 1012.1 through 1012N; a TPM 1010; and an operating system 1014. Similar to the preferred embodiment, the TPM 1010 is not an essential component, and another secure device / storage that maintains metrics and something similar to attestation could be used.

[0090] In the non-virtual environment, a TPM 1010 includes special-purpose registers (SR1, SRN) that can be used to hold measurement values. SRs behave exactly like PCRs in that a write to them actually involves writing a new value along with the old value, followed by hashing using a strong hash algorithm. The processor includes instructions that enable updating these special-purpose registers (SRs). The processor is modified to include a measurement instruction. This instruction uses an identifier for an SR, a memory address, and a length. It measures the data at the address (and all bytes up to the length) and then stores the measurement value in the specified SR. The processor transfers execution to the address.

[0091] In the non-virtual environment, the platform 1000 must update code, with update code associated with the code to perform the update. The associated code is loaded into memory, then the measure instruction is used to measure and execute the associated code. The measured value is stored in a first declared register. The executed associated code can now install the code, which may only involve writing data to a disk. Before the write operation, or before each write operation (if an N-byte write limit exists), measured values are taken and written to a second declared register (an SR, where this correlates with the update of the second declared register PCR18).

[0092] In the non-virtual environment, platform 1000 must inform an attestation system 1020 that an update has occurred. As in the preferred embodiment, attestation system 1020 attests, thereby transmitting the values of the SRs using cryptographic techniques to maintain trust. The attestation process 1022 is similar to the preferred embodiment.

[0093] It will be apparent to those skilled in the art that the method of the described embodiments of the present invention may be suitably carried out in whole or in part in one or more logic devices comprising logic elements arranged to perform the method steps, and that these logic elements may comprise hardware components, firmware components, or a combination thereof.

[0094] It will further be apparent to those skilled in the art that a logic arrangement according to the described embodiments of the present invention may be suitably implemented, in whole or in part, in a logic device comprising logic elements for performing the method steps, and that these logic elements may comprise components such as logic gates in, for example, a programmable logic array or an application-specific integrated circuit. Such a logic arrangement may further be implemented in basic elements for temporarily or permanently establishing logic structures in such an array or circuit, for example using a virtual hardware descriptor language that can be stored and transferred using fixed or portable carrier media.

[0095] It will be appreciated that the method and arrangement described above may also be suitably implemented, in whole or in part, in software running on one or more processors (not shown in the figures), and that the software may be provided in the form of one or more computer program elements located on any suitable data carrier (also not shown in the figures), such as a magnetic or optical disk or the like. Channels for transmitting data may, in turn, comprise storage media of all descriptions, as well as signal-carrying media, such as wired or wireless signal-carrying media.

[0096] The present invention may further be suitably embodied as a computer program product for use with a computer system. Such an embodiment may comprise a set of computer-readable instructions that are either permanently stored on a physical medium, such as a computer-readable medium, for example, a floppy disk, CD-ROM, ROM, or hard disk, or that are transferable to a computer system using a modem or other interface device over either a physical medium, including, but not limited to, optical or analog data transmission lines, or intangibly using wireless techniques, including, but not limited to, microwave, infrared, or other transmission techniques. The set of computer-readable instructions implements all or part of the functionality described above.

[0097] Those skilled in the art will appreciate that these computer-readable instructions may be written in a variety of programming languages for use with many computer architectures or operating systems. Such instructions may further be stored using any current or future storage technology, including, but not limited to, semiconductor, magnetic, or optical technology, or transmitted using any current or future data transmission technology, including, but not limited to, optical, infrared, or microwave technology.It is conceivable that such a computer program product may be distributed as a removable medium with accompanying printed or electronic documentation, for example as shrink-wrapped software, pre-installed on a computer system, for example on a system ROM or a hard disk, or from a server or electronic bulletin board over a network, for example the Internet or the World Wide Web.

[0098] Alternatively, the preferred embodiment of the present invention may be implemented in the form of a computer-implemented method for implementing a service, comprising the steps of implementing computer program code that is operative to cause the computer system to perform all of the method steps when the code is implemented and executed in a computer infrastructure.

[0099] Alternatively, the described embodiments of the present invention may be implemented in the form of a data carrier having functional data thereon, the functional data having functional computer data structures to enable the computer system to perform all method steps when the data is loaded into and executed on a computer system. SUMMARY OF THE PREFERRED EMBODIMENT

[0100] In summary, this invention relates to a method and apparatus for updating an operating system executing in a trusted hypervisor computing environment.More particularly, this invention relates to a method, a system, and a computer program product for updating an operating system executing in a hypervisor environment, comprising: detecting a new version of a component of an operating system; installing the new component version; measuring an identifying characteristic of the component and providing it to an attestation system; notifying the attestation system that a component has been updated to a new version, wherein, if the attestation system detects that the identifying characteristic of the new component does not match a previously stored attestation value, the system knows that a permissible mismatch may have occurred.Installing the new version of the component comprises: identifying an update device associated with the new version of the component; measuring an identifying characteristic of the identified update device; loading and installing the new version of the component; and providing both the identifying measurement of the update device and the new version of the component to the attestation system. NOTES

[0101] *IBM, AIX, Express, ibm.com, Power, Power7, and Tivoli are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. A complete list of IBM U.S. trademarks is available at www.ibm.com / legal / copytrade.shtml.

Claims

[1] A method for updating code in an execution environment, comprising: Identifying an update device associated with a new chain-of-trust code; Measuring a characteristic feature of the identified updating device and providing the characteristic feature of the updating device to an attestation system having means for storing and comparing measured values with attestation values; Installing the new chain-of-trust code into the execution environment; Measuring a characteristic of the new chain-of-trust code and providing the characteristic of the new chain-of-trust code to the attestation system; Notifying the attestation system that the chain-of-trust code has been updated to a new version, whereby the attestation system shall verify the source of the new chain-of-trust code immediately after the notification; Attesting the identifying feature of the update device associated with the new chain-of-trust code against a previously stored attestation value by the attestation system; and in response to a determination by the attestation system that the identifying characteristic of the update device matches a previously stored attestation value of the update device, validating the integrity of the updated chain-of-trust code in the execution environment, where, if the identifying characteristic of the updating device does not match the previously stored attestation value and the attestation system has verified the source of the corresponding code, then: Updating the attestation value with the identifying characteristic of the new version of the component; and Notify a management level that the identifying characteristic does not match an attestation value and whether the attestation system recognizes the source of the component. [2] Method according to one of claims 1, wherein the identifying features are stored in a secure memory to which only the storage method and the attestation system have access. [3] A method according to any one of claims 1 or 2, wherein the execution environment is a hypervisor and the code is a virtual operating system for execution in a virtual machine of the hypervisor. [4] Method according to one of claims 1 to 3, wherein registers are located in a trusted platform module. [5] A method according to any one of claims 1 to 4, further comprising determining that new code is available and that an update is required before performing the steps of claim 1. [6] A system for updating code in an execution environment by executing a method according to any one of the preceding claims, comprising: an identification means for identifying an update device associated with a new chain-of-trust code; a measuring means for measuring a characteristic feature of the identified updating device; an installation tool for installing the new chain-of-trust code into the execution environment; a measuring means for measuring a characteristic feature of the new chain-of-trust code and providing the characteristic feature of the new chain-of-trust code to an attestation system; a notification means for notifying the attestation system that the new chain-of-trust code has been updated to a new version, whereby the attestation system checks the source of the new chain-of-trust code immediately after the notification; means for providing the identifying feature of the updating device to the attestation system, wherein the attestation system can match the identifying feature of the updating device with a previously stored attestation value to validate a permissible update, where, if the identifying characteristic of the updating device does not match the attestation value and the attestation system has verified the source of the corresponding code, then: Updating the attestation value with the identifying characteristic of the new version of the component; and Notify a management level that the identifying characteristic does not match an attestation value and whether the attestation system recognizes the source of the component. [7] A system according to any one of claims 6, wherein the identifying features are stored in a secure memory accessible only to the storage method and the attestation system. [8] A system according to any one of claims 6 or 7, wherein the execution environment is a hypervisor and the code is a virtual operating system for execution in a virtual machine of the hypervisor. [9] A system according to any one of claims 6 to 8, wherein registers are located in a trusted platform module. [10] A system according to any one of claims 6 to 9, further comprising determining that new code is available and that an update is required before performing the steps of claim 6. [12] A computer program product for generating a first computer resource in a client computer, the computer program product comprising: a computer-readable storage medium readable by a processing circuit and storing instructions for execution by the processing circuit to perform a method according to any one of claims 1 to 5.

Images