System and method for measuring staleness of attestation during booting between a first and second device by generating a first and second time and calculating a difference between the first and second time to measure the staleness

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims priority from U.S. Provisional Application No. 61/303,870 filed Feb. 12, 2010, and U.S. Provisional Application No. 61/381,160 filed Sep. 9, 2010, the entire disclosures of which are incorporated herein by reference.

STATEMENT OF GOVERNMENTAL INTEREST

This invention was made with government support under contract number H98230-04-D-0305 awarded by the National Security Agency (NSA). The government has certain rights in the invention.

BACKGROUND

The present invention relates to the field of computer security, in particular, attesting the state of computer platforms using trusted computing.

A primary goal of trusted computing is ensuring that computers behave in known and predictable ways, which creates a safer computing environment. The Trusted Computing Group (TCG) is a not-for-profit organization formed to develop, define and promote open, vendor-neutral, industry standards for trusted computing building blocks and software interfaces across multiple platforms. The TCG has defined mechanisms for achieving trusted computing using hardware and software components that identify trusted software and enforce behavior so that only known and trusted software can execute. TCG specifications for the hardware based Trusted Platform Module (TPM), a PC Client (PC), and Trusted Network Connect (TNC) specifications define such mechanisms. The TPM is both the name of a published specification detailing a secure cryptoprocessor that can store cryptographic keys that protect information, as well as the general name of implementations of that specification, often called the “TPM chip” or “TPM Security Device.” The TNC is an open architecture for network access control, promulgated by the TCG.

One such mechanism involves generating cryptographic hashes of static executable files prior to their execution in order to uniquely identify the software so that it can be compared against a list of hashes of trusted software files. A cryptographic hash function is a deterministic procedure that takes an arbitrary block of data and returns a fixed-size bit string, the cryptographic hash value, such that an accidental or intentional change to the data will change the hash value. For example, when a computer boots, a cryptographic hash function may be performed on values within predetermined registers of the computer's basic input/output system (BIOS). The resulting hash value is cryptographically signed and stored by the computer. If the computer reboots, a new cryptographic hash function will be computed on the values and the resulting hash value will be cryptographically signed and stored by the computer. In the case when the hash values are stored inside the TPM, these values are not signed.

Unwanted, e.g., viral, software that is executed on the computer may change the data on the computer files, thus creating a new hash value. The difference between the new hash value and the old hash value will be an indicator that the computer has been rebooted or hacked. This would be a red flag that unwanted software has infiltrated the computer. As such, the computer may no longer be trusted.

Unknown and therefore untrusted software can be blocked from execution locally or reported to a remote party that can make an assessment of the computer's state. If the computer is deemed to be running in an untrusted state, it might be restricted from accessing network or other resources. Decisions on what software should be trusted can be evaluated locally or remotely through a process called attestation.

The process of measuring or identifying trusted software on a computer can be rooted in software tied to the lowest layers of the computer's hardware including its BIOS and its TPM. PC defines the trusted software known as root of trust for measurement (RTM) located in the boot block of the BIOS software.

Although RTM measurements are taken and recorded in a well-defined sequence, there are no protocols or mechanisms currently defined to associate an absolute or relative time with these measurements. Therefore, their freshness during an attestation exchange cannot be verified.

Hash values reported through attestation can be used to identify the software or configuration files loaded during the booting of the computer and its operating system. In the case of Integrity Measurement Architecture (IMA), executables, configuration files, and libraries loaded into memory that are identified by a configurable policy are hashed and extended into platform configuration registers (PCRs) prior to loading or execution. PCRs are TPM registers for storing platform configuration measurements. The hashes are also recorded in a manifest file for later reporting to the attester.

The existing attestation protocols defined by TCG include a nonce to prove that the quoting of the measurements is fresh. In security engineering, a nonce is an abbreviation of number used once. It is often a pseudo-random number issued in an authentication protocol to ensure that old communications cannot be reused. To ensure that a nonce is used only once, it should be time-variant (including a suitably fine-grained timestamp in its value), or generated with enough random bits to ensure a probabilistically insignificant chance of repeating a previously generated value. However, the nonce mechanism alone does not provide an indication of when the measurements were actually taken. As a result, there is a possibility of getting a fresh quote of stale measurements. Stale measurements may not accurately reflect the current state of the computer.

Unfortunately, freshness in reporting does not guarantee freshness in measurement. When the elapsed time between the measurement of software and the reporting of the measurement values of resulting PCRs to a remote attester is significant, i.e., possibly days or even months in the case of a server, the measurement may no longer accurately reflect the state of the running processes and may be considered stale. In fact, it is widely believed that a longer time between the time of measurement and time of reporting corresponds to a reduction in our assurance that the measurement accurately identifies the current executing software. The potential for compromise increases once the software executes in system memory.

What is needed is a method for measuring staleness of TPM measurements such that attestation decisions can be made correctly.

BRIEF SUMMARY

The present invention provides a system and method for measuring staleness of TPM measurements such that attestation decisions can be made correctly.

In accordance with an aspect of the present invention, a method is provided for determining with a first device, staleness of attestation measurements at a second device. The method includes booting up the second device at a first time, the second device having a communication portion, a security portion, a basic input/output system and a trusted protection module. Further, the method includes generating an initial counter based on the booting up of the second device at the first time. A current counter is then generated based on a second time after the first time. The method additionally includes providing a request to the second device from the first device, the request requesting booting information and current information, the booting information being based on the initial counter, the current information being based on the current counter. Still further, the method includes providing a response to the first device from the second device, the response including the booting information and the current information. Finally, the method includes determining, via the first device, the generated initial counter and the current counter based on the response.

Additional advantages and novel features of the invention are set forth in part in the description which follows, and in part will become apparent to those skilled in the art upon examination of the following or may be learned by practice of the invention. The advantages of the invention may be realized and attained by means of the instrumentalities and combinations particularly pointed out in the appended claims.

BRIEF SUMMARY OF THE DRAWINGS

The accompanying drawings, which are incorporated in and form a part of the specification, illustrate an exemplary embodiment of the present invention and, together with the description, serve to explain the principles of the invention. In the drawings:

<figref idrefs="DRAWINGS">FIG. 1</figref> illustrates a computer system in accordance with aspects of the present invention;

<figref idrefs="DRAWINGS">FIG. 2</figref> illustrates an example method in accordance with an aspect of the invention;

<figref idrefs="DRAWINGS">FIG. 3</figref> illustrates an example of using provably fresh measurements for remote attestation in accordance with an aspect of the present invention; and

<figref idrefs="DRAWINGS">FIG. 4</figref> illustrates an example of applying the law of superposition to PCR-<b>7</b> with a tickHash.

DETAILED DESCRIPTION

The present invention provides a system and method for reporting the relative age of a measurement without any modifications to the TPM design in a way that can be proven by a third party. The existing time capabilities of TPM are leveraged in order to establish a temporal reference point for when measurements were taken and recorded into TPM's registers.

Provably fresh measurements provide a solution to the stale measurement quandary. The tickCount and tickStamp capabilities of TPM are utilized to establish a temporal reference point that can be cryptographically associated with measurements protected by the TPM in a way that can be verified by a remote attester. By associating a temporal reference point with measurements protected in the TPM, the relative time a measurement that was recorded into the TPM can be proven. The measurements protected by TPM are associated with time by extending a representative hash of the time into the targeted PCR.

In an example embodiment, hashes are loaded into PCRs by using an iterative one-way SHA-1 (Secure Hash Algorithm-1) hash function called an extend operation. Once a hash has been loaded, it cannot be reset to a previous state since the hashes can be read out of the TPM. Additionally, most of PCRs inside TPM can only be reset to their original value by turning off power to TPM hardware. This ensures that PCRs reflect the state of the computer since its initial boot and has not been modified.

A computer system in accordance with an aspect of the present invention, where an attester wants to make an assessment of the state of an attestee, such that only known or trusted software can be executed will now explained below with reference to <figref idrefs="DRAWINGS">FIG. 1</figref>.

<figref idrefs="DRAWINGS">FIG. 1</figref> illustrates a computer system <b>100</b> in accordance with aspects of the present invention.

As illustrated in the figure, computer system <b>100</b> includes an attester <b>102</b>, and an attestee <b>104</b>. In one example, attester <b>102</b> may be a server and attestee <b>104</b> may be a client. Attester <b>102</b> includes a processor <b>106</b>, a memory <b>108</b>, a communication module <b>110</b> and a security module <b>112</b>. Attestee <b>104</b> includes a communication module <b>122</b>, a BIOS <b>124</b>, a TPM <b>126</b>, a security module <b>128</b>, and a processor <b>130</b>.

Each of the elements of attester <b>102</b> are illustrated as individual devices, however, in some embodiments at least two of processor <b>106</b>, memory <b>108</b>, communication module <b>110</b> and security module <b>112</b> may be combined as a unitary device. Further, in some embodiments, at least one of processor <b>106</b>, memory <b>108</b>, communication module <b>110</b> and security module <b>112</b> may be implemented as a tangible computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such tangible computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer. Non-limiting examples of tangible computer-readable media include physical storage and/or memory media such as RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer. For information transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer may properly view the connection as a computer-readable medium. Thus, any such connection may be properly termed a computer-readable medium. Combinations of the above should also be included within the scope of computer-readable media.

Similarly, each of the elements of attestee <b>104</b> are illustrated as individual devices, however, in some embodiments at least two of communication module <b>122</b>, BIOS <b>124</b>, TPM <b>126</b>, security module <b>128</b> and processor <b>130</b> may be combined as a unitary device. Further, in some embodiments, at least one of communication module <b>122</b>, BIOS <b>124</b>, TPM <b>126</b>, security module <b>128</b> and processor <b>130</b> may be implemented as a tangible computer-readable media for carrying or having computer-executable instructions or data structures stored thereon.

Attester <b>102</b> and attestee <b>104</b> communicate through a handshake signal <b>109</b>, for example, for exchanging keys and transfer of data, etc.

Processor <b>106</b> is operable to communicate with memory <b>108</b> via signal <b>114</b> for storage of any data. Processor <b>106</b> is also operable to communicate with security module <b>112</b> via signal <b>120</b>. Security module <b>112</b> is responsible for generating any keys used by attester <b>102</b>, for example, when requesting a measurement of PCRs from attestee <b>104</b>. Processor <b>106</b> is also operable to communicate with communication module <b>110</b> via signal <b>116</b>.

Communication module <b>110</b> is operable to receive a key from security module <b>112</b> via signal <b>118</b> and also a request for PCR quotes from processor <b>106</b>, and to communicate with attestee <b>104</b> via signal <b>109</b>.

Processor <b>130</b> is operable to communicate with communication module <b>122</b>, security module <b>128</b>, BIOS <b>124</b> and TPM <b>126</b> to provide controls to these modules as needed. Processor <b>130</b> may include an internal or external memory.

Communication module <b>122</b> interfaces with BIOS <b>124</b> via signal <b>138</b>. Communication module <b>122</b> also interfaces with security module <b>128</b> via signal <b>144</b>.

TPM <b>126</b> further includes an internal counter called TC (tick counter) <b>134</b>, a key storage module <b>135</b> and memory registers called PCRs <b>136</b>. TC <b>134</b>, key storage <b>135</b> and PCRs <b>136</b> are illustrated as individual devices, however, in some embodiments they may be combined as a unitary device. Further, in some embodiments, at least one of TC <b>134</b>, key storage module <b>135</b> and PCRs <b>136</b> may be implemented as a tangible computer-readable media for carrying or having computer-executable instructions or data structures stored thereon.

BIOS <b>124</b> includes the BIOS software and further includes an RTM <b>132</b>. RTM <b>132</b> is a trusted software as defined by PC and is used for kick starting the measurements of other trusted software components. RTM <b>132</b> begins an inductive chain of software identification where hashes of executable files are loaded into PCRs <b>136</b> via signal <b>140</b>.

Security module <b>128</b> is operable to generate any keys required for attestation process by TPM <b>126</b>. It interfaces with TPM <b>126</b> via signal <b>142</b>.

PCRs <b>136</b> are also used to store information about the boot sequence of attestee <b>104</b>. In particular, PCRs <b>136</b> can record information about the history of the boot sequence, BIOS <b>124</b>, the configuration settings of BIOS <b>124</b>, and the boot configuration for BIOS <b>124</b>. Numbering of PCRs <b>136</b> is standard as specified by PC put out by TCG. In this example, PCRs are grouped as PCRs <b>136</b> but individual PCR will be referred to as PCR-<b>1</b>, PCR-<b>2</b> . . . PCR-<b>19</b> and so on.

TPM <b>126</b> resets TC <b>134</b> on power-up, which increments by a tickCount at a fixed rate to an internal clock inside TPM <b>126</b>. Upon power-up, when TC <b>134</b> is reset to zero, TPM <b>126</b> also generates and stores a 20-byte random value called a tickNonce. For purposes of discussion, a 20-byte word is used for a tickNonce, but any other sized word may be used. TC <b>136</b> is internally associated with the tickNonce. TPM <b>126</b> can prove that a tickCount and tickNonce are associated with TPM <b>126</b> by signing the combination with an internally protected signing key (SK) such as an Attestation Identity Key (AIK), provided by security module <b>128</b>. The signature is also calculated over an external 20-byte anti-replay nonce passed into TPM <b>126</b> along with another 20-byte external “blob” of data.

The process of associating the current tickCount, tickNonce, the external blob, and anti-replay nonce using a digital signature is called tick stamping. The resulting tickStamp can be exported from TPM <b>126</b> along with all the components that were signed and the signature from the signing key as follows: <br />timestamp=Sign_SK(external blob∥anti-replay nonce∥tickCount∥tickNonce).

The integrity of this structure can be verified with a corresponding TPM <b>126</b> generated public key. If two tickStamps from the same TPM are extracted during the same power cycle for comparison (i.e., have the same tickNonce), the difference of their tickCounts equals the number of ticks that have elapsed between the generation of the tickStamps. This difference can be converted to time by determining the ratio of ticks to seconds.

Key storage module <b>135</b> stores and protects keys for TPM <b>126</b>. In a remote attestation protocol such as the one defined in TNC, TPM <b>126</b> serves as a root of trust for reporting (RTR) by cryptographically signing the contents of PCRs <b>136</b> using a 1024-bit or 2048-bit RSA key that is internally generated and protected by TPM <b>126</b>. RSA, which stands for Rivest, Shamir and Adleman, is an algorithm that is used for public key cryptography. Attester <b>102</b> initiates a TPM quote function of selected PCRs <b>136</b>. TPM <b>126</b> returns the value of selected PCRs <b>136</b> along with its signature over the value. The signature and thus the integrity of selected PCRs <b>136</b> can be verified using the corresponding public key generated by TPM <b>126</b>.

An external random number or a nonce may be included as input into the quoting function as a way of ensuring the reporting of selected PCRs <b>136</b> values is fresh and in response to a specific external request. Once the integrity of selected PCRs <b>136</b> has been verified with the quote, attester <b>102</b> can then use selected PCRs <b>136</b> value to verify the integrity of the log or manifest file, which describes the hash values that were extended into selected PCRs <b>136</b>. Once the log has been verified with selected PCRs <b>136</b>, attester <b>102</b> can use the log to help understand the state of the computer as represented by the details described in the log.

There are two basic protocols for performing attestation defined by TCG—one that uses a static root of trust for measurement (SRTM), which is associated with the physical boot of the system, and another using a dynamic root of trust of measurement (DRTM) which is used for measurement of a dynamic launch of a secure loader, which is usually of a hypervisor. They are both part of RTM <b>132</b>. DRTM can be entered multiple times per physical boot, and does not reset the power to TPM <b>126</b>. As a result, both the tickNonce and the tickCount together must be used to distinguish between measurements of the DRTM, were it to go through multiple measurement cycles.

SRTM roots a chain of trust that starts with the boot block of the BIOS, which is considered immutable. The boot block code hashes the rest of the BIOS and extends the results into PCR-<b>0</b>. Additionally, the boot block hashes the configuration settings of the BIOS and extends the results into PCR-<b>1</b>. After this, the rest of the BIOS software is passed control of the system in order to perform its many functions. One function it performs is extending the hash of the any firmware in peripherals that are on the system before they are given any control of the system. The firmware hashes are extended into PCR-<b>2</b> and its configuration settings into PCR-<b>3</b>. Before the BIOS passes control to the next piece of code, the Master Boot Record (MBR), it itself is measured and the results extended with its configuration settings into PCRs-<b>4</b> and PCR-<b>5</b>. This process establishes a chain of trust where each section of code measures the next section of code before it is passed control of the system.

During attestation, if the PCR values recorded in PCR-<b>0</b> through PCR-<b>5</b> match known values of trusted code, then the recipient of those values can be assured that the system has performed its allotted task and can then believe the accuracy of the next value in the trust chain.

The DRTM process roots a chain of trust starting sometime after SRTM and the boot of the system. In this chain, processor <b>130</b> itself forms a root of trust, using a special instruction that puts the system into a known, isolated state. In this state, no other hardware or software is able to affect the mechanisms processor <b>130</b> uses to measure special software called an authenticated code (AC) module. This state also allows processor <b>130</b> to set PCR-<b>17</b>, PRC-<b>18</b> and PCR-<b>19</b> to a value of all zeros. When booted, those PCRs are set to all 1's. This module, after being verified as having been signed by processor <b>130</b> manufacturer, is then given control of processor <b>130</b> and begins to measure the next set of code, which is usually a hypervisor loader, a hypervisor and host OS, into resettable PCR-<b>17</b> and PCR-<b>18</b>. Then control is passed from the AC module to the hypervisor loader. In this way a chain of trust is again created, and a party attesting the measurements will be able to look at the chain of trust and assess how trustworthy he believes the software to be.

Although both SRTM and DRTM measurements are taken and recorded in a well-defined sequence, there are no protocols or mechanisms currently defined to associate an absolute or relative time (e.g., tickCount) with these measurements to indicate when those measurements were taken. Therefore, their freshness during an attestation exchange cannot be verified.

Hash values reported through attestation can be used to identify the software or configuration files loaded during the booting of the computer and its operating system. In the case of Integrity Measurement Architecture (IMA), executables, configuration files, and libraries loaded into memory that are identified by a configurable policy are hashed and extended into PCR-<b>10</b> prior to loading or execution. The hashes are also recorded in a manifest file for later reporting to attester <b>102</b>. In the case of the use of DRTM, additional measurements of a running hypervisor and state of the system are made sometime after the boot sequence into PCRs <b>136</b>, which are resettable under controlled conditions.

The existing attestation protocols defined by TCG include a nonce to prove that the quoting of the measurements is fresh; however, the nonce mechanism alone does not provide an indication of when the measurements were actually taken. As a result, there is a possibility of getting a fresh quote of stale measurements. Stale measurements may not accurately reflect the current state of the computer platform <b>100</b>.

Unfortunately, freshness in reporting does not guarantee freshness in measurement. When the elapsed time between the measurement of software and the reporting of the measurement values of resulting PCRs to a remote attester is significant, i.e., possibly days or even months in the case of a server, the measurement may no longer accurately reflect the state of the running processes and may be considered stale. In fact, it is widely believed that a longer time between the time of measurement and time of reporting corresponds to a reduction in our assurance that the measurement accurately identifies the current executing software. The potential for compromise increases once the software executes in system memory.

An example flow chart of the proposed method, in accordance with an aspect of the present invention is explained below using <figref idrefs="DRAWINGS">FIG. 2</figref>.

<figref idrefs="DRAWINGS">FIG. 2</figref> illustrates an example method <b>200</b> in accordance with an aspect of the invention.

Method <b>200</b> starts (S<b>202</b>) and attestee <b>104</b> boots up (S<b>204</b>). For example, BOIS <b>124</b> initiates boot sequence, which includes loading software and/or configuration files. PCRs <b>136</b> and tickCounter <b>134</b> may be reset to their initial values.

A tickStamp is then generated (S<b>206</b>). For example, security module <b>128</b> generates a nonce every time BIOS <b>124</b> is powered on. TickCounter <b>134</b> provides its initial value from boot up to security module <b>128</b>. Security module <b>128</b> uses the nonce to cryptographically sign the initial tickCount to generate a tickStamp. Accordingly, the tickStamp may be authenticated, by using the nonce as will be described later.

The tickStamp is then stored in a PCR (S<b>208</b>). For example, security module <b>128</b> may store the tickStamp in at least one PCR of PCRs <b>136</b>. In another embodiment, the tickStamp can be integrated in with another PCR of PCRs <b>136</b> used to store system measurements as will be discussed later.

In this example, the tickStamp generation (S<b>206</b>) and the storage of the tickStamp (S<b>208</b>) are executed after boot sequence (S<b>204</b>), however in some embodiments, the tickStamp generation (S<b>206</b>) and the storage of the tickStamp (S<b>208</b>) may be executed with the boot sequence (S<b>204</b>).

It is then determined whether there is a request for the PCR values (S<b>210</b>). For example, attester <b>102</b> may send a request to attestee <b>104</b>. In an example embodiment, when attestor <b>102</b> and attestee <b>104</b> initially communicate, a handshake is performed wherein public keys may be exchanged for purposes of enabling secure, authenticated communication. During the handshake, security module <b>128</b> of attestee provides the nonce to security module <b>112</b> of attester <b>102</b>. Security module <b>112</b> then uses the nonce to generate the request for the PCR values. Communication portion <b>110</b> then transmits the request to communication portion <b>122</b>.

If there is no request for PCR measurements, attestee <b>104</b> waits for a request. While waiting, it is determined whether attestee re-boots (S<b>212</b>). If there is no boot then attestee <b>104</b> keeps waiting to receive a PCR measurement (S<b>210</b>). In case a boot has occured, a new tickStamp is generated (S<b>206</b>). As mentioned above, in the case of intrusive malware, the user of attestee may be unaware of an instillation of malware, which results in a reboot. However, in accordance with an aspect of the present invention, evidence of the reboot will be recorded with a corresponding tickstamp.

Returning to the determination of whether there is a request for the PCR values (S<b>210</b>), if there is a request for PCR measurements, the attestee may send the PCR measurements (S<b>214</b>). TPM <b>126</b> in attestee <b>104</b> cryptographically signs the contents of PCRs <b>136</b> and returns the PCR values along with its signature over the value. TPM <b>126</b> also sends a log file (which includes tickStamp from the last boot, which is the current boot cycle) along with the PCR values. The log file is used to interpret the PCR values.

Once attester <b>102</b> receives the PCR values sent by attestee <b>104</b>, attester <b>102</b> may request for the tickCount to check the freshness of the PCR values. In particular, as mentioned above, the PCR values may not accurately reflect the state of attestee <b>104</b> if they are stale, e.g., very old. Accordingly, attester <b>102</b> should at some point request a current tickCount, which will be used to determine the freshness of the PCR values.

It is then determined whether there is a request for a tickCount (S<b>216</b>). For example, attester <b>102</b> may send a request to attestee <b>104</b>. In an example embodiment, security module <b>112</b> then uses the nonce to generate the request for the tickCount. Communication portion <b>110</b> then transmits the request to communication portion <b>122</b>. In some cases, attester <b>102</b> can request to get a tickCount when the request for the PRC values is sent. In some cases, attester <b>102</b> can request to get a tickCount at some time after attestee boots up. In some cases, attester <b>102</b> can send a request for attestee to send a tickCount at a later predetermined time.

If there is no request for a tickCount, attestee <b>104</b> waits for a request. While waiting, it is determined whether attestee re-boots (S<b>218</b>). If there is no boot then attestee <b>104</b> keeps waiting to receive a tickCount request (S<b>216</b>). In case a boot has occurred, a new tickStamp is generated (S<b>206</b>). As mentioned above, in the case of intrusive malware, the user of attestee may be unaware of an instillation of malware, which results in a reboot. However, in accordance with an aspect of the present invention, evidence of the reboot will be recorded with a corresponding tickstamp.

Returning to the determination of whether there is a request for a tickCount (S<b>216</b>), if there is a request for a tickCount, the attestee may send the tickCount (S<b>220</b>). In an example embodiment, tickCounter <b>134</b> provides a current tickCount to security portion <b>128</b>. Security portion <b>128</b> signs the tickCount using a private key and the nonce to generate a current tickStamp.

Then the response from the attestee is verified (S<b>222</b>). In an example embodiment, attester <b>102</b> verifies response from attestee <b>104</b> using the public key provided during the handshake. In an example embodiment, security module <b>112</b> uses the public key and the nonce decrypt the response and verify the authenticity. Once decrypted and authenticated, processor <b>106</b> uses PCR values to verify the integrity of the log file which includes the hash values extended in to PCRs <b>136</b>.

Next, attester measures the staleness of the PCR values (S<b>224</b>). Once attester <b>102</b> verifies the measurements and the log file, attester <b>102</b> can calculate the time for the new tickCount and the old tickCount and determine the time difference between the two by dividing it by a parameter. From the time difference, freshness of the measurements can be determined.

At this point, method <b>200</b> stops (S<b>226</b>).

The proposed method as described in <figref idrefs="DRAWINGS">FIG. 2</figref>, can be used for determining freshness of measurements for remote attestation of attestee <b>104</b> by attester <b>102</b> of <figref idrefs="DRAWINGS">FIG. 1</figref>.

An aspect of the present invention makes use of the relative time of the tickcount within tick counter <b>134</b> as the time source for establishing a temporal reference point for measurements recorded in PCRs <b>136</b>. There are several forms of this counter that can be utilized. However, before any of them can be used by extension into TPM <b>126</b>, they may be converted into a 160-bit value. SHA-1 hashing algorithm is proposed and the resulting hash of a time source of TPM <b>126</b> is called a tickHash. The one-way nature of a PCR extension function of PCRs <b>136</b>, makes the extension of a tickHash into a PCR of PCRs <b>136</b> become a temporal reference point for measurements, recorded before and after the tickHash. It is always the case that measurements extended into a PCR of PCRs <b>136</b> after the tickHash are no staler than the tickHash itself; similarly, measurements recorded before the tickHash must be older than the tickhash.

Potential time formats of TPM <b>126</b> for conversion into a tickHash might include the following: 1) a hash of only the current tickCount, 2) a hash of the complete tickStamp structure which includes the signature of TPM <b>126</b> and the current tickCount, or 3) a hash of the signature of TPM <b>126</b> extracted from the tickStamp (which covers the tickCount in the tickStamp structure). To generate the 160-bit tickHash, the internal SHA-1 cryptographic function of TPM <b>126</b> could be used, or could be generated external to TPM <b>126</b> using a software (or hardware) cryptographic implementation (e.g., openssl). Generating the tickHash using a time structure that includes the signature of TPM <b>126</b> (i.e., either option 2 or 3) allows a remote attestor, e.g., attestor <b>102</b>, to verify that the count was derived by a TPM in a trusted state (as proved by the PCRs). The time values in TPM <b>126</b> used to generate the tickHash must be recorded in a log or manifest so that the final hash can be re-generated by a remote attester, e.g. attestor <b>102</b>, for verification of the integrity of the PCR log and to compute the relative freshness in its measurements (see below).

In one example embodiment, the relative freshness of a tickHash, T_freshis computed by computing the difference between the tickCount from a recorded tickHash, tickCount_A, and the current tickCount, tickCount_cur: <br /><i>T</i>_fresh=tickCount_cur−tickCount_A

More generically, the freshness between any two measurements is the difference between their tickCounts (with the same tickNonce), where tickCount is relatively newer than tickCount_y: <br /><i>T</i>_fresh=tickCount_x−tickCount_x

Extending the tickHash into a PCR establishes a reference point that can establish the relative freshness of other PCR recorded measurements to boot time. When establishing freshness of a tickHash extended into a PCR, the attester may first verify integrity of the PCR and then the integrity of the PCR log or manifest. In order to verify the integrity of information contained within a PCR log, an attester may hash the values extended into the PCR in order they were extended, from the first value to the last. The final hash may be equal to the corresponding PCR value returned in a TPM signed quote that was verified using the TPM's public signing key (e.g., AIK public key or certificate). To verify the time associated with PCR measurements, the tickHash that was extended into a PCR may have also been included in the log file in the temporal order it was extended into the TPM. Therefore, the data structures, or some representation of them, that comprised the tickCount or tickStamp may be recorded in the log in order to regenerate the tickHash and verify the PCR. Once the PCR has been verified, the relative freshness of its measurements can be deduced from their temporal location in the log file in relationship to the extended tickHash.

<figref idrefs="DRAWINGS">FIG. 3</figref> illustrates an example <b>300</b> of using provably fresh measurements for remote attestation in accordance with an aspect of the present invention.

As illustrated in the figure, example <b>300</b> includes an attesting client <b>302</b> and an attestation requestor <b>304</b>.

At boot, attesting client <b>302</b> loads configuration files and PCRs. A boot loader, for example, Grub, extends PCRs as part of boot sequence. Also, in an example embodiment, SRTM and DRTM protocol is followed. Note that in step <b>3</b>, tickHash₁is extended in to PCR-<b>8</b>, and later on in step <b>6</b>, tickHash₂is extended in to PCR-<b>19</b>, which implies that the PCR log maintains the order in which PCRs were extended. Once the boot sequence is complete, attesting client <b>302</b> waits for an attestation request.

Attestation requestor <b>304</b> then sends an attestation measurement request with a random nonce to attesting client <b>302</b> in step <b>8</b>.

Attesting client <b>302</b> returns the quote of PCRs including nonce, tickHash₃of nonce, and log values for PCR-<b>8</b> and PCR-<b>19</b> in step <b>9</b>. Note that the log file includes tickCount and tickStamp corresponding to each tickHash.

Attestation requestor <b>304</b> verifies TPM's public signing key, which was the same key used for both PCR quote and tickHash in step <b>10</b>.

Attestation requestor <b>304</b> computes and verifies PCRs and PCR logs in step <b>11</b>.

Attestation requestor <b>304</b> can now subtract tickCount_PCRfrom recorded tickHash₂in the PCR log from tickCount_TSprotected by the returned tickStamp from tickHash₃, which should be returned in relative real-time. By converting the counts to time (in seconds), attestation requestor <b>304</b> can determine how long it has been since the measurement was taken, T_fresh. <br /><i>T</i>_fresh=tickCount_TS−tickCount_PCR

As discussed above using <figref idrefs="DRAWINGS">FIG. 3</figref>, relative freshness of measurements for remote attestaion can be verified by extending tickHash into a PCR in the temporal order.

Note that the technique behind provably fresh measurements also solves a “reboot in the middle” problem associated with remote attestation. This problem is defined by a computer being attacked after it has attested to be in a trustworthy state. After the attacker completes their nefarious task, they reboot the machine back into the trustworthy state unbeknownst to the remote attester. The technique behind provably fresh measurements solves this problem by recording the tickNonce associated with a tickCount. Because a reboot in the middle would have different tickNonce's associated with the tickStamp's taken before and after the reboot, the reboot would be noticeable to the remote attester. A remote attester can distinguish between boot sequences by comparing the tickNonce from PCRs reported before and after the reboot. The attester is able to detect the reboot even if the tickStamp recording of the middle (bad) boot sequence is faked—because in the “reboot in the middle” attack, it is the two good boot sequences that need to be distinguished.

The basic approach of generating a tickHash in order to associate time, i.e., the tickCount, with a measurement, can be applied in two basic scenarios. In one method called Establishing Relative Boot Time, any modifications to current trusted code in the BIOS or any modifications to the TPM to establish freshness of measurements are not required. A second approach, called Law of Superposition, integrates the provably fresh measurement technique of extending tickHashes together with other measurement software to establish a relative time of measurements recorded in PCRs. First method of Establishing Relative Boot Time is discussed below.

It might be considered ideal to extend a tickHash into each PCR before it is otherwise extended by other measurements to establish temporal references for each measurement. Although this would provide proof that subsequent measurements were extended after the tickHash was created, there are a number of problems encountered with this approach in current deployed systems.

First, changing a RTM in order to extend the tickHash would require a change to the PC Client specification, as well as requiring updates to the BIOS. It would also affect programs like Tboot that already are using a DRTM to load PCR-<b>17</b> and PCR-<b>18</b> with measurements of a dynamic boot sequence.

Secondly, adding a dynamic element, e.g., the tickCount, into a PCR measurement makes the resulting PCR measurement more dynamic by including an incrementing counter. Because the PCR values would always be different, this may increase the amount of effort needed to verify a PCR measurement by a remote attester, e.g., a Trusted Network Connect Radius Proxy, to determine if an attesting client is in a known good state. The current setup of PCR measurements has “nearly static” measurements being extended into even PCRs and configuration settings which may be more dynamic measured into odd PCRs. Thus the BIOS firmware is measured into PCR <b>0</b> and the configuration settings of the BIOS are measured into PCR <b>1</b>.

In general, it is assumed that measurements can be considered good if they are “relatively” fresh. That is, if the concern is that the system could have been subverted within seconds of its having booted, then the freshness of the measurements are irrelevant. Therefore, it is assumed that measurements of critical components need only to have been taken a few seconds from the system having fully booted. In this case, it can be assumed that the system has booted into a trusted state, which is proved by examining the current PCR measurements. As such, in order to avoid having to change either the BIOS or the ACM modules used in Tboot to guarantee integrity of the DRTM, time measurement are allowed to be done by the operating system's kernel. Tboot (Trusted Boot) is a conventional open source, pre-kernel/VMM (virtual memory manager) module that performs a measured and verified launch of an operating system kernel/VMM.

While it would be best to have the RTM actually place a tickHash value early into a PCR that is already defined (such as PCR-<b>1</b>, PCR-<b>3</b> or PCR-<b>6</b>), for most cases, it is sufficient for the measured OS kernel to place the tichHash measurement into a PCR that is not already in use. It is proposed that for static measurements, the tickHash be extended into PCR-<b>11</b> (to reflect the freshness of subsequent load-time IMA measurements). In support of DRTM, it is suggested to extend the tickHash into PCR-<b>19</b> immediately after a DRTM hypervisor is loaded by the hypervisor kernel. The stability of the tickHash reference point is assured because PCR-<b>11</b> can only be reset by a full reboot sequence of the system and PCR-<b>19</b> can only be reset by going through a reboot of the VT-x (in the case of Intel) or Pacifica (in the case of AMD) cycle. In both the latter cases, PCR-<b>19</b> will then reflect a value as to when the late booting of a hypervisor took place.

Despite the difficulties described earlier for integrating a tickHash solution with other measurement components, the benefits of this approach should be noted. To describe the basic principles behind this approach, an analogy to the scientific laws employed in geology is presented. In order to determine the age of fossils buried in the earth, geologist use the Law of Superposition. The law, which applies to stratified deposits of rock and minerals, states that older layers of deposits are found at the bottom of a stratum while newer layers are found closer to the top. The age of a fossil can be determined by establishing the location of a fossil with the stratum. This same principle is the basis for the novel idea of provable fresh measurements, which helps to identify the relative age or freshness of measurements quoted from a TPM.

Values extended into TPM's PCRs behave in a similar fashion to the Law of Superposition because of the one-way SHA-1 function used by TPM to extend a PCR. The one-way nature of the hash function guarantees the chronological ordering of the measurements in the PCR. Older measurements occur earlier in the sequence and new measurements occur later in the sequence. In terms of the Law of Superposition, extending a tickHash into a PCR is similar to injecting the tickHash in the PCR's “stratum”. Because the age of the tickHash relative to boot is known, the age of other measurements extended before or after the tickHash can be established.

In order to establish a relative time of a measurement, it needs to be recorded in a PCR between two time events. Those could be 1) initial boot and a tickHash, 2) between a tickHash and current time, or 3) between two tickHashes. In order to more precisely determine the freshness of measurements, the first tickHash should be extended as soon as possible (after SRTM, DRTM) to establish an initial temporal reference for earlier measurements and all later measurements. Extending other tickHashes interspersed with other measurements helps to accurately determine the relative age of those measurements between the tickHashes—similar to the Law of Superposition. As an example, <figref idrefs="DRAWINGS">FIG. 4</figref> illustrates this principle as applied to PCR-<b>7</b>.

<figref idrefs="DRAWINGS">FIG. 4</figref> illustrates an example <b>400</b> of applying the Law of Superposition to PCR-<b>7</b> with a tickHash.

As illustrated in the figure, <b>402</b> represents a set of PCRs, where PCR-<b>7</b> is represented by <b>408</b>. An x-axis <b>406</b> represents a timeline for PCR-<b>7</b><b>408</b>. A TPM <b>404</b> extends tickHash into PCR-<b>7</b><b>108</b> at times <b>410</b>, <b>412</b> and <b>414</b>. Measurements from the operating system (OS) are extended in to PCR-<b>7</b><b>408</b> are shown as <b>416</b> and <b>418</b>.

An initial tickHash is extended in to PCR-<b>7</b><b>408</b> at time <b>410</b>, when tickCount is equal to <b>050</b>. Between time <b>410</b> and time <b>412</b>, several other software measurements are recorded, which are extended into PCR-<b>7</b><b>408</b>, as shown by <b>416</b>. At time <b>412</b>, tickCount is equal to <b>100</b>. Between time <b>412</b> and time <b>414</b>, some other software measurements are recorded, which are extended into PCR-<b>7</b><b>408</b>, as shown by <b>418</b>. At time <b>414</b>, tickCount is equal to <b>300</b>.

As seen from <figref idrefs="DRAWINGS">FIG. 4</figref>, extending tickHashes interspersed with other software measurements help to establish the relative age of the measurements between them. Similar to the Law of Superposition, knowing the age of tickHashes at times <b>410</b>, <b>412</b> and <b>414</b>, the age of measurements <b>416</b> and <b>418</b> can be determined accurately.

As discussed above and in accordance with aspects of the present invention, provably fresh measurements are used to solve the stale measurement problem in remote attestation. The tickCount and tickStamp capabilities of TPM are utilized to establish a temporal reference point that can be cryptographically associated with measurements protected by TPM in a way that can be verified by a remote attester. By associating a temporal reference point with measurements protected in TPM, the relative time a measurement was recorded into TPM can be proven. A time stamp is associated with the measurements protected by the TPM by extending a representative hash of the time into the targeted PCR. Since the code that measures the tickStamp into an unused PCR would have itself been measured, the attestee can verify that the measurement into the unused PCR was done at roughly the same time as the boot for the computer.

The technique behind provably fresh measurements also solves “reboot in the middle” problem associated with remote attestation. The basic approach of generating a tickHash in order to associate time (i.e., the tickCount) with a measurement, is applied in two basic scenarios. In the method of Establishing Relative Boot Time, any modifications to current trusted code in the BIOS or any modifications to the TPM to establish freshness of measurements is not required. Another method based on Law of Superposition, integrates the provably fresh measurement technique of extending tickHashes together with other measurement software to establish a relative time of measurements recorded in PCRs. In another embodiment the tickStamping may be integrated with the RTM measurements taken at the boot time.

The foregoing description of various preferred embodiments of the invention have been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed, and obviously many modifications and variations are possible in light of the above teaching. The example embodiments, as described above, were chosen and described in order to best explain the principles of the invention and its practical application to thereby enable others skilled in the art to best utilize the invention in various embodiments and with various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the claims appended hereto.