Mobile software agents at the basic level contain code, state information and data. Mobile software agents are similar to any other software program, with the exception that they can move from one system to another and execute locally on a remote system. A mobile software agent may be executed on many systems during its life cycle. In some instances, mobile software agents may work under the control of a central entity that provides inputs to the agents. In other instances, the agents may be autonomous and independently make decisions.
Conventional software agents have some long-standing problems. When an agent is moved to a remote system, there is currently no mechanism for the agent to decide if the remote system is trustworthy. There are some solutions that make use of digital certificates to verify the identity of the remote system. However, there is no mechanism for verifying the trustworthiness of the remote system.
When a computer accepts a mobile software agent, it has to make sure that the code of the mobile software agent is not malicious in nature. A conventional approach involves a signed code that the remote entity can use to verify that the code is authentic. However, no mechanism exists for verifying whether the state of the agent and the data transmitted along with the agent are trustworthy.
When a computer downloads a mobile software agent, it has to make sure that the system that it needs to interact with to import a code is not malicious in nature. Conventional solutions used to ensure that the agent and the platform are trustworthy use digital certificates and limit the resources available to the agent on the remote system, (e.g., sandboxing). Use of digital certificates will help identify the code and the platform, but does not provide any indication of how trustworthy the platform is at the given point in time. Restricting access to resources will help make the receiving entity more secure, but it limits the functionality that the agent can support. In addition, this does not prevent a malicious code from being imported or operating on the remote system, but it merely reduces the extent of the potential damage a code may do after it is imported. Moreover, this method reduces but does not quite eliminate the possibility that the imported code damages a receiving system.
Trusted Computing Group (TCG) is an organization established with an aim of enhancing security of the computing environment in disparate computer platforms. TCG has adopted specifications developed by the trusted computing platform alliance. At the root of the TCG specifications is a tamper resistant security hardware device embedded in the platform, which is called the trusted platform module (TPM). The TPM acts as a “root of trust” for the platform, and has integrated cryptographic functionality providing integrity, creation and use of digital signatures and privacy protecting mechanisms. A platform configuration register (PCR) is a 20-byte storage area, internal to the TPM, which contains a cumulative digest of a number of measured values, typically consisting of embedded data. The TCG specification mandates that there be at least sixteen PCRs within a TPM.
Integrity reporting may be used to determine a platform's current configuration. FIG. 1 shows a conventional attestation procedure 150 for a system 100 having a TPM 106. A challenger 102 requests one or more PCR values from a platform agent 104 (step 152). The platform agent collects stored measurement log (SML) entries, which are integrity measurement values (step 154). The platform agent 104 requests PCR values from the TPM 106 (step 156). The PCR values are measurement digests of the integrity measurement values, (i.e., signed hash of the integrity measurement values). The TPM 106 signs the PCR values using an attestation identity key (AIK) (step 158), and sends it to the platform agent 104 (step 160). The platform agent 104 also collects credentials that vouch for the TPM 106 from the repository 108 (steps 162, 164). The platform agent 104 sends the signed PCR values, the SML entries and the credentials to the challenger (step 166). The challenger 102 then verifies the platform configuration (step 168). For the verification, the challenger 102 computes a measurement digest from the received SML entries and compares the computed measurement digest with the PCR values. The challenger 102 also evaluates the platform credentials and checks signatures.
Recently, methods to virtualize the functions of a physical TPM have been proposed. Using these methods, a single physical TPM can be used on systems where multiple operating systems are running concurrently or multiple software and hardware sub-entities on the system can take on functions of ‘virtualized’, ‘instantiated’ TPM using the single physical TPM on board. TPMs typically provide singular instances of features, such as endorsement and storage root key pairs, TPM owner, one set of PCRs and other singletons, with existing TPM-based security architectures having been built around these features.
From its inception, the current TPM was not designed to be accessed by multiple systems at the same time. Therefore, a virtual TPM that can work with multiple operating systems on the same machine would need extended command sets that are new to the current TPM v1.2 commands.
In one proposed virtual TPM model, each created instance of a TPM holds an association with a virtual machine (VM) throughout its lifetime on the platform. As modern hypervisors also allow for the migration of operating system VMs from one physical machine to another, a virtual TPM implementation must support migration of the TPM state. Prior art methods allow, (using extended virtual TPM command sets), TPM state migration such that the complete state of the TPM is secured throughout the transition, based on migratable storage keys that are shared between the involved systems.
USPTO Backgrounds
USPTO Backgrounds