Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
  • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities

Definitions

• the present invention relates generally to security in processing systems, and more particularly, to a methodology for installing binding information into an initial or re ⁇ placement trusted device in a secured processing system.
• Present-day computing systems and in particular large-scale server systems, often include support for running multiple virtual machines.
• the system may be a large-scale on-demand server system that executes hundreds of server instances on a single hardware platform to support customers with varying computing requirements.
• multiple partitions which may differ in operating system and application mix, are concurrently present in system memory and processes executing in each partition are run in an environment that supports their execution on a guest operating system.
• the virtual machine provides an environment similar enough to a real hardware platform that the operating system can run with little or no mod ⁇ ification.
• a hypervisor (sometimes referred to as a virtual machine monitor) manages all of the virtual machines or partitions and abstracts system resources so that each partition provides a machine-like environment to each operating system instance.
• each device generally supports one or more of the above-described partitions, although it is possible to share tasking on a partition between multiple devices.
• Groups of devices or an individual device may be associated with a particular customer and it is desirable to secure access to a device or group by only that customer including securing the devices from the manufacturer of the devices and system.
• binding can be physical, i.e., the device is permanently attached to the system, or binding can be accomplished cryptographically, allowing for removable devices and networked systems.
• a platform credential is issued to a system (or particular trusted groups of devices within a system) only when the credential provider is certain that a trusted device has been validly bound to the system. The credential certifies that the platform embodies one or more trusted devices and therefore has the AUS040504
• the certification is performed at the manu ⁇ facturers site and the trusted devices are either permanently physically bound to the system, or are cryptographically bound to the system without possibility of field re ⁇ placement.
• the above-mentioned removable and networked devices provide protection from data tampering or impersonation by refusing to initiate in a system unless the device is crytographically bound to the system.
• the information associated with the binding is generally encrypted and is stored in non-volatile storage within the device by the man ⁇ ufacturer.
• only a trusted system can access data associated with or stored within a particular device, dramatically reducing the impact of misappropriation or misuse of removable devices.
• data associated with a device (such as a stored context or "state" of one of the above-mentioned virtual machines) is secured by an encryption mechanism that requires a key that is stored within the associated device or devices.
• the two-layer mechanism hardware binding and data encryption keyed to a particular device or devices provides a high level of security against data mining by misappropriation or misuse of removable devices.
• the new device When one of the devices fails or at initial installation of a trusted device into a system, the new device must be bound to the system in order for the device to initialize according to the above-described security methodology. If other devices having the desired security binding are present and operational in the system, binding information can be transferred from one of the other devices. However,- if no other device is available with the desired binding, i.e., the last device with that binding has failed or only one such device was present in the system originally, then it is necessary for the binding to be established by other means, typically by returning the system to the man ⁇ ufacturer.
• One method of attacking a system with bound devices is to remove a device during the binding process or otherwise rendering a device "unbound” and attempting to install the device on another system. Also, failure could occur during the binding process that may compromise the integrity of the system by causing a device to appear to be secured to a particular platform when it is not.
• Figure 1 is a block diagram of a computing system in which an embodiment of the invention is practiced.
• Figure 2 is a block diagram of memory images and information flow within a system in accordance with an embodiment of the present invention.
• Figure 3 is a flowchart depicting portions of a method in accordance with an embodiment of the present invention.
• Figure 4 is a flowchart depicting further portions of a method in accordance with an embodiment of the present invention'.'
• Figure 5 is a flowchart depicting still further portions of a method in accordance with an embodiment of the present invention. Best Mode for Carrying Out the Invention
• the system includes a secured local system 5 having four processor modules (processor module 1OA and three other identical processor modules lOB-D).
• Local system 5 may be connected to other system units 5A forming a super-scalar processing system.
• the local systems are connected to a credential provider server 1 via an Internet connection 3 or an alternative network interface.
• Credential provider server includes a processor 12A for executing server program instructions in accordance with an embodiment of the present invention and a server memory 11 for storing the program instructions and data.
• Each processing module 1OA, lOB-D includes a processor 12 for executing program instructions, a local memory 6 that is generally mapped as system memory accessible by other processor modules lOB-D and a cache 14 for storing data and program instructions.
• Processing modules 1OA, lOB-D also each includes a non ⁇ volatile memory 13 that stores values used by the method of the present invention to verify that processor modules 1OA, lOB-D are installed in the system to which they are bound.
• Processor modules 1OA, lOB-D also each may include a service processor 16 which may carry out the security functions of the present invention, or alternatively processor 12 may perform the tasks described in further detail below.
• Processor modules 1OA, lOB-D also include a local fast interface 18 for intercommunication with other modules in local system 5, and a network interface 15 for communication with other system units 5A and Internet connection 3.
• Local system also includes a storage device 7 as well as other devices 9, to which the binding techniques of the present invention may be applied.
• a system non- volatile memory 13A is also included for storing binding verification data and other system values associated with the security techniques of the present invention, such as the system serial number or other identifier.
• a virtual machine monitor program or "hypervisor” provides support for execution of multiple virtual machines (VMs) or “partitions” that each provide an execution environment for an operating system and a number of "guest” programs (applications and services executed by an operating system and , , running in the associated VM).
• VMs virtual machines
• guest programs applications and services executed by an operating system and , , running in the associated VM.
• the present invention provides for binding of devices in local system 5 so that the devices can only be used in local system 5.
• credential provider server 1 provides a credential to local system 5 that certifies to others that the system includes one or more trusted devices and therefore embodies the attributes associated with the trusted device. The certificate can then be used by other systems to verify that they can inter-operate with system 5 using the characteristics associated with a trusted platform device.
• ar ⁇ rangement is an illustration applicable to systems in which processor modules 1OA, lOB-D are removable modules that may be inserted in or removed from local system 5 via a chassis or other interconnect arrangement.
• binding in the sense of the present invention may extend to other arrangements such as the networked in ⁇ terconnect illustrated between local system 5 and other system units 5A.
• the present invention uses encryption and public/private key pairs to secure binding-related com- AUS040504
• munications between devices and therefore security can be maintained in en ⁇ vironments where the devices bound to a system may actually be located in physically disparate locations.
• shared symmetric keys may alternatively be employed.
• processor modules any device for which it is useful to bind uniquely to a system and where verification of a credential is useful.
• storage devices within a computer system could be bound to the system so that they will only operate with the system and a credential could be supplied in response to a query before an application or operating system routine trusts data stored on the device or trusts the device as a sink for data. Therefore, it should be understood that the following description, while referring for illustrative purposes to a binding of processor module 1OA to local system 5 applies to binding of other devices and other systems, as well.
• FIG. 2 a block diagram is shown depicting memory images and information flow within the computer system of Figure 1.
• device non- volatile memory 13 a device specific identifier is stored, along with a unique device-specific key pair installed at the time of device manufacture.
• processor module 1OA generates a random bit sequence
• the device-generated secret which the device then hashes with a system-specific identifier provided by local system 5 to processor module 1OA from system non- k' volatile memory 13A (or can be accessed from system non- volatile memory 13A directly by processor module 10A).
• the hashed result the "platform binding record” (PBR) is stored in processor module 1OA non- volatile memory 13 for future use in verifying that local system 5 is the system bound uniquely to processor module 1OA.
• a private key unique to processor module 1OA is used to sign the PBR and the signed PBR is sent to local system 5 where it is stored in system non-volatile memory 13A.
• processor module can verify that local system 5 is the system to which it was bound upon subsequent return of the signed PBR to processor module 1OA, as the signature on the signed PBR validates the signed PBR as having been generated by processor module 1OA.
• Llcal system 5 Upon receipt of the PBR from processor module 1OA, Llcal system 5 verifies the signed PBR using a system-unique public key provided by the manufacturer of processor module 1OA and stores the signed PBR to return to processor module 1OA for verification at initialization and other intervals as deemed necessary by the hypervisor.
• a binding verification record is sent to credential provider server 1, which verifies that the system/device combination is valid and now properly bound.
• the binding verification record is verified using a device-specific public key retrieved from a database 22, which is indexed via the device identifier and AUS040504
• the binding verification record provides evidence that a particular device was bound to a system by including various information that can exist only in the device. In the illustrative embodiment, this is performed by using the device- specific private key to sign a hash of several pieces of information, including a device- specific public endorsement key, the system identifier provided during the binding process and a unique device identifier (generally the serial number).
• the above information is hashed over a one-time use device secret (distinct from the one-time device generated secret) that was installed at the time of manufacture of the device.
• the one-time use device secret is then "burned" (erased) after the binding ver ⁇ ification record is generated.
• This one-time secret is also stored in the manufacturer's (credential provider's) database, providing a verification that the device has been bound.
• the verification can only be performed once, as once the device has burned the one-time use secret, if the other one-way ratchets described below are overcome, binding of the device still cannot be verified without a binding verification record generated in conformity with the one-time use device secret.
• the device-specific endorsement key is also unique to the initial trusted device and provides further verification that the device being bound is the correct device, as the endorsement key is also retained by the credential provider.
• the endorsement key is associated with the credential and is later used to show that the trusted platform virtual machines are running on a trusted platform device associated with a particular credential (which will contain the endorsement key as well).
• Database 22 maintains public key information for all devices produced so that keys can be found to validate messages from devices, as well as the device one-time use secret. If the binding is validated, a credential 20 is generated and sent to processor module 1OA, which stores it in device non-volatile memory 13 (which can include disk file storage) for use in identifying the platform provided by processor module 1OA as a trusted platform having an identity certified by the credential provider (e.g., the man ⁇ ufacturer or other certification entity).
• the credential provider e.g., the man ⁇ ufacturer or other certification entity
• processor module 1OA Since the unique private key is only stored within processor module 1OA and is not retained by the manufacturer after injection of the private key into processor module 1OA at the factory, nor stored anywhere else, it is extremely difficult for another device to impersonate processor module 1OA during a binding process. It is therefore highly unlikely that a credential would be issued to any combination of devices and systems other than a known system and a known set of devices. Other techniques may be applied in addition to the above in order to further increase the difficulty.
• an integration process is performed by migrating binding in ⁇ formation from another trusted device (step 32).
• the integration securely shares the hashed result (PBR) that was stored in the other device and stores it in the non- volatile memory 13 of the unbound device, which can then return a signed PBR to local system 5 for storage in system non-volatile memory 13A by signing the PBR from the other device with its own private key.
• PBR hashed result
• the newly-bound device can verify the system in the same manner that the existing trusted device can. It should be noted that the unique private key of each device does not need to be exported, only the hashed result that was generated during binding of the existing trusted device.
• the method of the present invention is employed to bind the new device without performing the integration process of step 32.
• a system-specific identifier such as the system serial number is sent to the device (step 33).
• the device generates a random bit stream used as a secret value and hashes this value with the system-specific identifier to produce a hashed result (PBR) (step 34).
• the device stores the PBR and then signs the hashed result with the device's unique private key to provide a signed PBR (step 36) that is then sent to the system for use at each device initialization.
• Proof of binding is also generated and is sent along with the system identifier to the credential provider (step 37).
• the credential provider determines whether or not the binding is valid (decisionv38) by verifying the identity of the system and device as - -ja signatures within the signed proof of binding.
• the credential provider has a public key for each device that is used to validate the signed proof of binding record and verify that it came from that particular device.
• the system identifier is also part of the basis for the signed proof of binding, the identity of the system is also thereby identified, even though the device and system identifiers may also be sent "in the clear”.
• a credential is issued for the device and sent back to the system (step 39) so that the system can prove that it contains a trusted device.
• a credential it is not necessary for a credential to be sent to the system, and may be maintained on the credential provider server or stored at another location, as long as it is accessible to components needing to verify that the system contains a trusted device with certain attributes. But, if the binding is invalid ( decision 38), then the device is notified to abort the binding process (step 40).
• step 50 When a device is installed in the system (step 50), a state value is read from the device non- volatile memory (step 51). Three states are possible: “bound”, “unbound” and “binding”. The three states are employed in a one-way “ratchet” scheme that ensures that once the binding process is AUS040504
• the device can never return to an unbound state, and once binding is completed, the device can never return from the bound condition.
• the device is in the "binding" state when the device is installed (decision 51) it is an indication that a binding process was interrupted in some manner and is an indication that tampering may have occurred by removal of the device during another binding process. So, if the device is in the binding state (decision 51) at installation, the device is locked out by the system (step 52) and must be returned to the man ⁇ ufacturer in order to be re-used. If the device is in the "bound” state (decision 53), then the binding is verified normally (step 54) and the device is initialized. If the device is in the "unbound” state (decision 53), the binding exchanges and verifications are performed (step 55) as exemplified by Figure 3.
• the state of the device is set to the "bound" state (step 57), otherwise the device is left in the "binding" state (step 58), preventing further use of the device.
• the device will be rendered useless until reprogrammed at the factory, preventing attempts to subvert the binding process by removal during installation.
• FIG. 5 still another portion of the method in accordance with the illustrated embodiment of the invention is depicted.
• a service call is received by the manufacturer (step 60). If the system has one functioning trusted device left (decision 61) the integration process mentioned above is performed on a replacement device using the trusted device (step 62). « However, if no trusted devices are left functioning in the system (decision 61), then the system credential is invalidated (step 63) and a replacement device is optionally pre- bound to the system that sent the service call (step 64) and the replacement device is shipped to the customer site (step 65). The binding process described above is then performed as illustrated in Figures 3 and 4 once the replacement device is installed in the system.
• the ver ⁇ ification of binding made by the credential provider server is made in conformity with a database entry that indicates that the replacement device is intended for installation in a particular system and will only issue a credential upon binding of the device to the correct system.
• the database contains information such as the device identifier, system identifier to which the device is assigned and the unique public keys associated with the system and the device.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Hardware Design (AREA)
• General Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Software Systems (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Storage Device Security (AREA)
• Hardware Redundancy (AREA)
• Information Transfer Between Computers (AREA)

Priority Applications (4)

Applications Claiming Priority (2)

Publications (1)

Family

ID=34970960

Family Applications (1)

Country Status (8)

Cited By (3)

Families Citing this family (44)

Citations (6)

• 2004
  • 2004-10-21 US US10/970,461 patent/US7143287B2/en not_active Expired - Lifetime
• 2005
  • 2005-06-23 CN CNB2005800358006A patent/CN100458807C/zh not_active Expired - Lifetime
  • 2005-06-23 WO PCT/EP2005/052937 patent/WO2006045644A1/en not_active Ceased
  • 2005-06-23 EP EP05754217A patent/EP1805571B1/en not_active Expired - Lifetime
  • 2005-06-23 DE DE602005023195T patent/DE602005023195D1/de not_active Expired - Lifetime
  • 2005-06-23 AT AT05754217T patent/ATE479154T1/de not_active IP Right Cessation
  • 2005-06-23 JP JP2007537241A patent/JP4410821B2/ja not_active Expired - Fee Related
  • 2005-10-11 TW TW094135408A patent/TWI365654B/zh not_active IP Right Cessation

Patent Citations (6)

Also Published As

Similar Documents

Legal Events