Trusted computing platform

CROSS-REFERENCE TO RELATED APPLICATIONS

0001This patent application is a continuation application of U.S. Ser. No. 09/913,452, filed on Dec. 5, 2001 now U.S. Pat. No. 6,988,250, which is the U.S. national stage of PCT application No. PCT/GB00/00528, filed on Feb 15, 2000.

TECHNICAL FIELD

0002The present invention generally relates to trusted devices, trusted computing platforms, trusted transactions and methods of operating the same.

BACKGROUND ART

0003For commercial applications, a client computing platform typically operates in an environment where its behaviour is vulnerable to modification by local or remote entities. This potential insecurity of the platform is a limitation on its use by local parties who might otherwise be willing to use the platform, or remote parties who might otherwise communicate with the platform; for example, for the purposes of E-commerce. For the present purposes, both local parties and remote parties will be referred to as “users” unless otherwise stated.

0004Existing security applications, for example virus detection software, execute on computing platforms under the assumption that the platform will operate as intended and that the platform will not subvert processes and applications. This is a valid assumption provided that the intended software state has not become unstable or has not been damaged by other software such as viruses. Users, therefore, typically restrict the use of such platforms to non-critical applications, and weigh the convenience of using the platforms against the risk to sensitive or business critical data.

0005Increasing the level of trust in platforms therefore enables greater user confidence in existing security applications (such as the ‘Secure Sockets Layer’ or ‘IPSec’) or remote management applications. This enables greater reliance on those applications and hence reduced ‘cost of ownership’. Greater trust also enables new electronic methods of business, since there is greater confidence in the correct operation of both local and remote computing platforms.

0006In this document, the word ‘trust’ is used in the sense that something can be ‘trusted’ if it always behaves in the expected manner for the intended purpose.

DISCLOSURE OF THE INVENTION

0007The present inventors have appreciated that it is desirable to use a physical device in a computing platform to verify and possibly enforce trust in that platform. Typically, the device provides trusted measurement and reporting of attributes of the associated platform, which indicate the integrity of the platform. Also, most preferably, the device is tamper-resistant.

0008In accordance with a first aspect, the present invention provides computing apparatus comprising, mounted on an assembly, main processing means and main memory means, each being connected for communication with one or more other components on the assembly, together with a trusted device mounted on the assembly and being connected for communications with one or more other components on the assembly, the trusted device being arranged to acquire a true value of an integrity metric of the computing apparatus.

0009As used herein for reasons of simplicity of description, the term “device” also encompasses plural devices having equivalent function, or equivalent functionality integrated into one or more existing platform devices or assemblies. Additionally, the term ‘true’ as used herein implies that the value is that which correctly reflects the state of the computing apparatus. This may be ensured if the measurement method is substantially un-modifiable other than by the trusted device.

0010In accordance with a second aspect, the present invention provides a method of operating a system comprising trusted computing apparatus and a user, the trusted computing apparatus incorporating a trusted device being arranged to acquire the true value of an integrity metric of the computing apparatus, the method comprising the steps of:

0011the trusted device acquiring the true value of the integrity metric of the trusted computing apparatus;

0012the user generating a challenge for the trusted computing apparatus to prove its integrity and submitting the challenge to the trusted computing apparatus;

0013the trusted computing apparatus receiving the challenge, and the trusted device generating a response including the integrity metric and returning the response to the user; and

0014the user receiving the response, extracting the integrity metric from the response and comparing the integrity metric with an authenticated metric for the trusted computing apparatus that had been generated by a trusted party.

0015In accordance with a third aspect, the present invention provides a method of establishing a communications channel in a system between trusted computing apparatus and remote computing apparatus, the method including the step of the remote computing apparatus verifying the integrity of the trusted computing apparatus using the above method, and maintaining the communications channel for further transactions in the event the integrity of the trusted computing apparatus is successfully verified by the remote computing apparatus.

0016In accordance with a fourth embodiment, the present invention provides a method of verifying that trusted computing apparatus is trustworthy for use by a user for processing a particular application, the method including the step of the user verifying the integrity of the trusted computing apparatus using the above method, and the user using the trusted computing apparatus to process the particular application in the event the integrity of the trusted computing apparatus is successfully verified by the remote computing apparatus.

0017Other aspects and embodiments of the present invention will become apparent from the following description and claims.

BRIEF DESCRIPTION OF THE DRAWINGS

0018A preferred embodiment of the present invention will now be described by way of example only with reference to the accompanying drawings in which:

0019<figref idref="DRAWINGS">FIG. 1</figref> is a diagram that illustrates a system capable of implementing embodiments of the present invention;

0020<figref idref="DRAWINGS">FIG. 2</figref> is a diagram which illustrates a motherboard including a trusted device arranged to communicate with a smart card via a smart card reader and with a group of modules;

0021<figref idref="DRAWINGS">FIG. 3</figref> is a diagram that illustrates the trusted device in more detail;

0022<figref idref="DRAWINGS">FIG. 4</figref> is a flow diagram which illustrates the steps involved in acquiring an integrity metric of the computing apparatus;

0023<figref idref="DRAWINGS">FIG. 5</figref> is a flow diagram which illustrates the steps involved in establishing communications between a trusted computing platform and a remote platform including the trusted platform verifying its integrity; and

0024<figref idref="DRAWINGS">FIG. 6</figref> is a flow diagram which illustrates the steps involved in verification of a trusted computing platform by a potential user of that platform by means of a smart card.

BEST MODE FOR CARRYING OUT THE INVENTION, & INDUSTRIAL APPLICABILITY

0025The present exemplary embodiment generally provides the incorporation into a computing platform of a physical trusted device whose function is to bind the identity of the platform to reliably measured data that provides an integrity metric of the platform. The identity and the integrity metric are compared with expected values provided by a trusted party (TP) that is prepared to vouch for the trustworthiness of the platform. If there is a match, the implication is that at least part of the platform is operating correctly, depending on the scope of the integrity metric.

0026A user verifies the correct operation of the platform before exchanging other data with the platform. A user does this by requesting the trusted device to provide its identity and an integrity metric. (Optionally the trusted device will refuse to provide evidence of identity if it itself was unable to verify correct operation of the platform.) The user receives the proof of identity and the identity metric, and compares them against values which it believes to be true. Those proper values are provided by the TP or another entity that is trusted by the user. If data reported by the trusted device is the same as that provided by the TP, the user trusts the platform. This is because the user trusts the entity. The entity trusts the platform because it has previously validated the identity and determined the proper integrity metric of the platform.

0027Once a user has established trusted operation of the platform, he exchanges other data with the platform. For a local user, the exchange might be by interacting with some software application running on the platform. For a remote user, the exchange might involve a secure transaction. In either case, the data exchanged is ‘signed’ by the trusted device. The user can then have greater confidence that data is being exchanged with a platform whose behaviour can be trusted.

0028The trusted device uses cryptographic processes but does not necessarily provide an external interface to those cryptographic processes. Also, a most desirable implementation would be to make the trusted device tamperproof, to protect secrets by making them inaccessible to other platform functions and provide an environment that is substantially immune to unauthorised modification. Since tamper-proofing is impossible, the best approximation is a trusted device that is tamper-resistant, or tamper-detecting. The trusted device, therefore, preferably consists of one physical component that is tamper-resistant.

0029Techniques relevant to tamper-resistance are well known to those skilled in the art of security. These techniques include methods for resisting tampering (such as appropriate encapsulation of the trusted device), methods for detecting tampering (such as detection of out of specification voltages, X-rays, or loss of physical integrity in the trusted device casing), and methods for eliminating data when tampering is detected. Further discussion of appropriate techniques can be found at http://www.cl.cam.ac.uk/˜mgk25/tamper.html. It will be appreciated that, although tamper-proofing is a most desirable feature of the present invention, it does not enter into the normal operation of the invention and, as such, is beyond the scope of the present invention and will not be described in any detail herein.

0030The trusted device is preferably a physical one because it must be difficult to forge. It is most preferably tamper-resistant because it must be hard to counterfeit. It typically has an engine capable of using cryptographic processes because it is required to prove identity, both locally and at a distance, and it contains at least one method of measuring some integrity metric of the platform with which it is associated.

0031A trusted platform <b>10</b> is illustrated in the diagram in <figref idref="DRAWINGS">FIG. 1</figref>. The platform <b>10</b> includes the standard features of a keyboard <b>14</b>, mouse <b>16</b> and visual display unit (VDU) <b>18</b>, which provide the physical ‘user interface’ of the platform. This embodiment of a trusted platform also contains a smart card reader <b>12</b>—a smart card reader is not an essential element of all trusted platforms, but is employed in various preferred embodiments described below. Along side the smart card reader <b>12</b>, there is illustrated a smart card <b>19</b> to allow trusted user interaction with the trusted platform as shall be described further below. In the platform <b>10</b>, there are a plurality of modules <b>15</b>: these are other functional elements of the trusted platform of essentially any kind appropriate to that platform (the functional significance of such elements is not relevant to the present invention and will not be discussed further herein).

0032As illustrated in <figref idref="DRAWINGS">FIG. 2</figref>, the motherboard <b>20</b> of the trusted computing platform <b>10</b> includes (among other standard components) a main processor <b>21</b>, main memory <b>22</b>, a trusted device <b>24</b>, a data bus <b>26</b> and respective control lines <b>27</b> and lines <b>28</b>, BIOS memory <b>29</b> containing the BIOS program for the platform <b>10</b> and an Input/Output (IO) device <b>23</b>, which controls interaction between the components of the motherboard and the smart card reader <b>12</b>, the keyboard <b>14</b>, the mouse <b>16</b> and the VDU <b>18</b>. The main memory <b>22</b> is typically random access memory (RAM). In operation, the platform <b>10</b> loads the operating system, for example Windows NT™, into RAM from hard disk (not shown). Additionally, in operation, the platform <b>10</b> loads the processes or applications that may be executed by the platform <b>10</b> into RAM from hard disk (not shown).

0033Typically, in a personal computer the BIOS program is located in a special reserved memory area, the upper 64K of the first megabyte do the system memory (addresses FØØØh to FFFFh), and the main processor is arranged to look at this memory location first, in accordance with an industry wide standard.

0034The significant difference between the platform and a conventional platform is that, after reset, the main processor is initially controlled by the trusted device, which then hands control over to the platform-specific BIOS program, which in turn initialises all input/output devices as normal. After the BIOS program has executed, control is handed over as normal by the BIOS program to an operating system program, such as Windows NT (™), which is typically loaded into main memory <b>22</b> from a hard disk drive (not shown).

0035Clearly, this change from the normal procedure requires a modification to the implementation of the industry standard, whereby the main processor <b>21</b> is directed to address the trusted device <b>24</b> to receive its first instructions. This change may be made simply by hard-coding a different address into the main processor <b>21</b>. Alternatively, the trusted device <b>24</b> may be assigned the standard BIOS program address, in which case there is no need to modify the main processor configuration.

0036It is highly desirable for the BIOS boot block to be contained within the trusted device <b>24</b>. This prevents subversion of the obtaining of the integrity metric (which could otherwise occur if rogue software processes are present) and prevents rogue software processes creating a situation in which the BIOS (even if correct) fails to build the proper environment for the operating system.

0037Although, in the preferred embodiment to be described, the trusted device <b>24</b> is a single, discrete component, it is envisaged that the functions of the trusted device <b>24</b> may alternatively be split into multiple devices on the motherboard, or even integrated into one or more of the existing standard devices of the platform. For example, it is feasible to integrate one or more of the functions of the trusted device into the main processor itself, provided that the functions and their communications cannot be subverted. This, however, would probably require separate leads on the processor for sole use by the trusted functions. Additionally or alternatively, although in the present embodiment the trusted device is a hardware device that is adapted for integration into the motherboard <b>20</b>, it is anticipated that a trusted device may be implemented as a ‘removable’ device, such as a dongle, which could be attached to a platform when required. Whether the trusted device is integrated or removable is a matter of design choice. However, where the trusted device is separable, a mechanism for providing a logical binding between the trusted device and the platform should be present.

0038The trusted device <b>24</b> comprises a number of blocks, as illustrated in <figref idref="DRAWINGS">FIG. 3</figref>. After system reset, the trusted device <b>24</b> performs a secure boot process to ensure that the operating system of the platform <b>10</b> (including the system clock and the display on the monitor) is running properly and in a secure manner. During the secure boot process, the trusted device <b>24</b> acquires an integrity metric of the computing platform <b>10</b>. The trusted device <b>24</b> can also perform secure data transfer and, for example, authentication between it and a smart card via encryption/decryption and signature/verification. The trusted device <b>24</b> can also securely enforce various security control policies, such as locking of the user interface.

0039Specifically, the trusted device comprises: a controller <b>30</b> programmed to control the overall operation of the trusted device <b>24</b>, and interact with the other functions on the trusted device <b>24</b> and with the other devices on the motherboard <b>20</b>; a measurement function <b>31</b> for acquiring the integrity metric from the platform <b>10</b>; a cryptographic function <b>32</b> for signing, encrypting or decrypting specified data; an authentication function <b>33</b> for authenticating a smart card; and interface circuitry <b>34</b> having appropriate ports (<b>36</b>, <b>37</b> &amp; <b>38</b>) for connecting the trusted device <b>24</b> respectively to the data bus <b>26</b>, control lines <b>27</b> and address lines <b>28</b> of the motherboard <b>20</b>. Each of the blocks in the trusted device <b>24</b> has access (typically via the controller <b>30</b>) to appropriate volatile memory areas <b>4</b> and/or non-volatile memory areas <b>3</b> of the trusted device <b>24</b>. Additionally, the trusted device <b>24</b> is designed, in a known manner, to be tamper resistant.

0040For reasons of performance, the trusted device <b>24</b> may be implemented as an application specific integrated circuit (ASIC). However, for flexibility, the trusted device <b>24</b> is preferably an appropriately programmed micro-controller. Both ASICs and micro-controllers are well known in the art of microelectronics and will not be considered herein in any further detail.

0041One item of data stored in the non-volatile memory <b>3</b> of the trusted device <b>24</b> is a certificate <b>350</b>. The certificate <b>350</b> contains at least a public key <b>351</b> of the trusted device <b>24</b> and an authenticated value <b>352</b> of the platform integrity metric measured by a trusted party (TP). The certificate <b>350</b> is signed by the TP using the TP's private key prior to it being stored in the trusted device <b>24</b>. In later communications sessions, a user of the platform <b>10</b> can verify the integrity of the platform <b>10</b> by comparing the acquired integrity metric with the authentic integrity metric <b>352</b>. If there is a match, the user can be confident that the platform <b>10</b> has not been subverted. Knowledge of the TP's generally-available public key enables simple verification of the certificate <b>350</b>. The non-volatile memory <b>35</b> also contains an identity (ID) label <b>353</b>. The ID label <b>353</b> is a conventional ID label, for example a serial number, that is unique within some context. The ID label <b>353</b> is generally used for indexing and labelling of data relevant to the trusted device <b>24</b>, but is insufficient in itself to prove the identity of the platform <b>10</b> under trusted conditions.

0042The trusted device <b>24</b> is equipped with at least one method of reliably measuring or acquiring the integrity metric of the computing platform <b>10</b> with which it is associated. In the present embodiment, the integrity metric is acquired by the measurement function <b>31</b> by generating a digest of the BIOS instructions in the BIOS memory. Such an acquired integrity metric, if verified as described above, gives a potential user of the platform <b>10</b> a high level of confidence that the platform <b>10</b> has not been subverted at a hardware, or BIOS program, level. Other known processes, for example virus checkers, will typically be in place to check that the operating system and application program code has not been subverted.

0043The measurement function <b>31</b> has access to: non-volatile memory <b>3</b> for storing a hash program <b>354</b> and a private key <b>355</b> of the trusted device <b>24</b>, and volatile memory <b>4</b> for storing acquired integrity metric in the form of a digest <b>361</b>. In appropriate embodiments, the volatile memory <b>4</b> may also be used to store the public keys and associated ID labels <b>360</b><i>a</i>-<b>360</b><i>n </i>of one or more authentic smart cards <b>19</b><i>s </i>that can be used to gain access to the platform <b>10</b>.

0044In one preferred implementation, as well as the digest, the integrity metric includes a Boolean value, which is stored in volatile memory <b>4</b> by the measurement function <b>31</b>, for reasons that will become apparent.

0045A preferred process for acquiring an integrity metric will now be described with reference to <figref idref="DRAWINGS">FIG. 4</figref>.

0046In step <b>500</b>, at switch-on, the measurement function <b>31</b> monitors the activity of the main processor <b>21</b> on the data, control and address lines (<b>26</b>, <b>27</b> &amp; <b>28</b>) to determine whether the trusted device <b>24</b> is the first memory accessed. Under conventional operation, a main processor would first be directed to the BIOS memory first in order to execute the BIOS program. However, in accordance with the present embodiment, the main processor <b>21</b> is directed to the trusted device <b>24</b>, which acts as a memory. In step <b>505</b>, if the trusted device <b>24</b> is the first memory accessed, in step <b>510</b>, the measurement function <b>31</b> writes to volatile memory <b>3</b> a Boolean value which indicates that the trusted device <b>24</b> was the first memory accessed. Otherwise, in step <b>515</b>, the measurement function writes a Boolean value which indicates that the trusted device <b>24</b> was not the first memory accessed.

0047In the event the trusted device <b>24</b> is not the first accessed, there is of course a chance that the trusted device <b>24</b> will not be accessed at all. This would be the case, for example, if the main processor <b>21</b> were manipulated to run the BIOS program first. Under these circumstances, the platform would operate, but would be unable to verify its integrity on demand, since the integrity metric would not be available. Further, if the trusted device <b>24</b> were accessed after the BIOS program had been accessed, the Boolean value would clearly indicate lack of integrity of the platform.

0048In step <b>520</b>, when (or if) accessed as a memory by the main processor <b>21</b>, the main processor <b>21</b> reads the stored native hash instructions <b>354</b> from the measurement function <b>31</b> in step <b>525</b>. The hash instructions <b>354</b> are passed for processing by the main processor <b>21</b> over the data bus <b>26</b>. In step <b>530</b>, main processor <b>21</b> executes the hash instructions <b>354</b> and uses them, in step <b>535</b>, to compute a digest of the BIOS memory <b>29</b>, by reading the contents of the BIOS memory <b>29</b> and processing those contents according to the hash program. In step <b>540</b>, the main processor <b>21</b> writes the computed digest <b>361</b> to the appropriate non-volatile memory location <b>4</b> in the trusted device <b>24</b>. The measurement function <b>31</b>, in step <b>545</b>, then calls the BIOS program in the BIOS memory <b>29</b>, and execution continues in a conventional manner.

0049Clearly, there are a number of different ways in which the integrity metric may be calculated, depending upon the scope of the trust required. The measurement of the BIOS program's integrity provides a fundamental check on the integrity of a platform's underlying processing environment. The integrity metric should be of such a form that it will enable reasoning about the validity of the boot process—the value of the integrity metric can be used to verify whether the platform booted using the correct BIOS. Optionally, individual functional blocks within the BIOS could have their own digest values, with an ensemble BIOS digest being a digest of these individual digests. This enables a policy to state which parts of BIOS operation are critical for an intended purpose, and which are irrelevant (in which case the individual digests must be stored in such a manner that validity of operation under the policy can be established).

0050Other integrity checks could involve establishing that various other devices, components or apparatus attached to the platform are present and in correct working order. In one example, the BIOS programs associated with a SCSI controller could be verified to ensure communications with peripheral equipment could be trusted. In another example, the integrity of other devices, for example memory devices or co-processors, on the platform could be verified by enacting fixed challenge/response interactions to ensure consistent results. Where the trusted device <b>24</b> is a separable component, some such form of interaction is desirable to provide an appropriate logical binding between the trusted device <b>14</b> and the platform. Also, although in the present embodiment the trusted device <b>24</b> utilises the data bus as its main means of communication with other parts of the platform, it would be feasible, although not so convenient, to provide alternative communications paths, such as hard-wired paths or optical paths. Further, although in the present embodiment the trusted device <b>24</b> instructs the main processor <b>21</b> to calculate the integrity metric in other embodiments, the trusted device itself is arranged to measure one or more integrity metrics.

0051Preferably, the BIOS boot process includes mechanisms to verify the integrity of the boot process itself. Such mechanisms are already known from, for example, Intel's draft “Wired for Management baseline specification v 2.0—BOOT Integrity Service”, and involve calculating digests of software or firmware before loading that software or firmware. Such a computed digest is compared with a value stored in a certificate provided by a trusted entity, whose public key is known to the BIOS. The software/firmware is then loaded only if the computed value matches the expected value from the certificate, and the certificate has been proven valid by use of the trusted entity's public key. Otherwise, an appropriate exception handling routine is invoked.

0052Optionally, after receiving the computed BIOS digest, the trusted device <b>24</b> may inspect the proper value of the BIOS digest in the certificate and not pass control to the BIOS if the computed digest does not match the proper value. Additionally, or alternatively, the trusted device <b>24</b> may inspect the Boolean value and not pass control back to the BIOS if the trusted device <b>24</b> was not the first memory accessed. In either of these cases, an appropriate exception handling routine may be invoked.

0053<figref idref="DRAWINGS">FIG. 5</figref> illustrates the flow of actions by a TP, the trusted device <b>24</b> incorporated into a platform, and a user (of a remote platform) who wants to verify the integrity of the trusted platform. It will be appreciated that substantially the same steps as are depicted in <figref idref="DRAWINGS">FIG. 5</figref> are involved when the user is a local user. In either case, the user would typically rely on some form of software application to enact the verification. It would be possible to run the software application on the remote platform or the trusted platform. However, there is a chance that, even on the remote platform, the software application could be subverted in some way. Therefore, it is anticipated that, for a high level of integrity, the software application would reside on a smart card of the user, who would insert the smart card into an appropriate reader for the purposes of verification. <figref idref="DRAWINGS">FIG. 5</figref> illustrates the flow of actions for the general case—a more specific flow of actions for verification by a user smart card will be described with reference to <figref idref="DRAWINGS">FIG. 6</figref> further below.

0054At the first instance, a TP, which vouches for trusted platforms, will inspect the type of the platform to decide whether to vouch for it or not. This will be a matter of policy. If all is well, in step <b>600</b>, the TP measures the value of integrity metric of the platform. Then, the TP generates a certificate, in step <b>605</b>, for the platform. The certificate is generated by the TP by appending the trusted device's public key, and optionally its ID label, to the measured integrity metric, and signing the string with the TP's private key.

0055The trusted device <b>24</b> can subsequently prove its identity by using its private key to process some input data received from the user and produce output data, such that the input/output pair is statistically impossible to produce without knowledge of the private key. Hence, knowledge of the private key forms the basis of identity in this case. Clearly, it would be feasible to use symmetric encryption to form the basis of identity. However, the disadvantage of using symmetric encryption is that the user would need to share his secret with the trusted device. Further, as a result of the need to share the secret with the user, while symmetric encryption would in principle be sufficient to prove identity to the user, it would insufficient to prove identity to a third party, who could not be entirely sure the verification originated from the trusted device or the user.

0056In step <b>610</b>, the trusted device <b>24</b> is initialised by writing the certificate <b>350</b> into the appropriate non-volatile memory locations <b>3</b> of the trusted device <b>24</b>. This is done, preferably, by secure communication with the trusted device <b>24</b> after it is installed in the motherboard <b>20</b>. The method of writing the certificate to the trusted device <b>24</b> is analogous to the method used to initialise smart cards by writing private keys thereto. The secure communications is supported by a ‘master key’, known only to the TP, that is written to the trusted device (or smart card) during manufacture, and used to enable the writing of data to the trusted device <b>24</b>; writing of data to the trusted device <b>24</b> without knowledge of the master key is not possible.

0057At some later point during operation of the platform, for example when it is switched on or reset, in step <b>615</b>, the trusted device <b>24</b> acquires and stores the integrity metric <b>361</b> of the platform.

0058When a user wishes to communicate with the platform, in step <b>620</b>, he creates a nonce, such as a random number, and, in step <b>625</b>, challenges the trusted device <b>24</b> (the operating system of the platform, or an appropriate software application, is arranged to recognise the challenge and pass it to the trusted device <b>24</b>, typically via a BIOS-type call, in an appropriate fashion). The nonce is used to protect the user from deception caused by replay of old but genuine signatures (called a ‘replay attack’) by untrustworthy platforms. The process of providing a nonce and verifying the response is an example of the well-known ‘challenge/response’ process.

0059In step <b>630</b>, the trusted device <b>24</b> receives the challenge and creates an appropriate response. This may be a digest of the measured integrity metric and the nonce, and optionally its ID label. Then, in step <b>635</b>, the trusted device <b>24</b> signs the digest, using its private key, and returns the signed digest, accompanied by the certificate <b>350</b>, to the user.

0060In step <b>640</b>, the user receives the challenge response and verifies the certificate using the well known public key of the TP. The user then, in step <b>650</b>, extracts the trusted device's <b>24</b> public key from the certificate and uses it to decrypt the signed digest from the challenge response. Then, in step <b>660</b>, the user verifies the nonce inside the challenge response. Next, in step <b>670</b>, the user compares the computed integrity metric, which it extracts from the challenge response, with the proper platform integrity metric, which it extracts from the certificate. If any of the foregoing verification steps fails, in steps <b>645</b>, <b>655</b>, <b>665</b> or <b>675</b>, the whole process ends in step <b>680</b> with no further communications taking place.

0061Assuming all is well, in steps <b>685</b> and <b>690</b>, the user and the trusted platform use other protocols to set up secure communications for other data, where the data from the platform is preferably signed by the trusted device <b>24</b>.

0062Further refinements of this verification process are possible. It is desirable that the challenger becomes aware, through the challenge, both of the value of the platform integrity metric and also of the method by which it was obtained. Both these pieces of information are desirable to allow the challenger to make a proper decision about the integrity of the platform. The challenger also has many different options available—it may accept that the integrity metric is recognised as valid in the trusted device <b>24</b>, or may alternatively only accept that the platform has the relevant level of integrity if the value of the integrity metric is equal to a value held by the challenger (or may hold there to be different levels of trust in these two cases).

0063The techniques of signing, using certificates, and challenge/response, and using them to prove identity, are well known to those skilled in the art of security and therefore need not be described in any more detail herein.

0064As indicated above, <figref idref="DRAWINGS">FIG. 6</figref> shows the flow of actions in an example of verification of platform integrity by a user interacting with the trusted platform with a smart card <b>19</b>. As will be described, the process conveniently implements a challenge/response routine. There exist many available challenge/response mechanisms. The implementation of an authentication protocol used in the present embodiment is mutual (or 3-step) authentication, as described in ISO/IEC 9798-3, “Information technology—Security techniques—Entity authentication mechanisms; Part 3; Entity authentication using a public key algorithm”, International Organization for Standardization, November 1993. Of course, there is no reason why other authentication procedures cannot be used, for example 2-step or 4-step, as also described in this reference.

0065Initially, the user inserts their smart card <b>19</b> into the smart card reader <b>12</b> of the platform in step <b>700</b>.

0066Beforehand, a platform configured for use by users of in this way will typically be operating under the control of its standard operating system and executing the authentication process, which waits for a user to insert their smart card <b>19</b>. Apart from the smart card reader <b>12</b> being active in this way, such a platform is typically rendered inaccessible to users by ‘locking’ the user interface (i.e. the screen, keyboard and mouse). This will however not be the case in all embodiments of the invention.

0067When the smart card <b>19</b> is inserted into the smart card reader <b>12</b>, the trusted device <b>24</b> is triggered to attempt mutual authentication in step by generating and transmitting a nonce A to the smart card <b>19</b> in step <b>705</b>. A nonce, such as a random number, is used to protect the originator from deception caused by replay of old but genuine responses (called a ‘replay attack’) by untrustworthy third parties.

0068In response, in step <b>710</b>, the smart card <b>19</b> generates and returns a response comprising the concatenation of: the plain text of the nonce A, a new nonce B generated by the smart card <b>19</b>, an ID of the trusted device <b>24</b> and some redundancy; the signature of the plain text, generated by signing the plain text with the private key of the smart card <b>19</b>; and a certificate containing the ID and the public key of the smart card <b>19</b>.

0069The trusted device <b>24</b> authenticates the response by using the public key in the certificate to verify the signature of the plain text in step <b>715</b>. If the response is not authentic, the process ends in step <b>720</b>. If the response is authentic, in step <b>725</b> the trusted device <b>24</b> generates and sends a further response including the concatenation of: the plain text of the nonce A, the nonce B, an ID of the smart card <b>19</b> and the acquired integrity metric; the signature of the plain text, generated by signing the plain text using the private key of the trusted device <b>24</b>; and the certificate comprising the public key of the trusted device <b>24</b> and the authentic integrity metric, both signed by the private key of the TP.

0070The smart card <b>19</b> authenticates this response by using the public key of the TP and comparing the acquired integrity metric with the authentic integrity metric, where a match indicates successful verification, in step <b>730</b>. If the further response is not authentic, the process ends in step <b>735</b>.

0071If the procedure is successful, both the trusted device <b>24</b> has authenticated the logon card <b>19</b> and the smart card <b>19</b> has verified the integrity of the trusted platform and, in step <b>740</b>, the authentication process executes the secure process for the user.

0072In certain types of interaction, the authentication process can end at this point. However, if a session is to be continued between the user and the trusted platform, it is desirable to ensure that the user remains authenticated to the platform.

0073Where continued authentication is required, the authentication process sets an interval timer in step <b>745</b>. Thereafter, using appropriate operating system interrupt routines, the authentication process services the interval timer periodically to detect when the timer meets or exceeds a pre-determined timeout period in step <b>750</b>.

0074Clearly, the authentication process and the interval timer run in parallel with the secure process. When the timeout period is met or exceeded, the authentication process triggers the trusted device <b>24</b> to re-authenticate the smart card <b>19</b>, by transmitting a challenge for the smart card <b>19</b> to identify itself in step <b>760</b>. The smart card <b>19</b> returns a certificate including its ID and its public key in step <b>765</b>. In step <b>770</b>, if there is no response (for example, as a result of the smart card <b>19</b> having been removed) or the certificate is no longer valid for some reason (for example, the smart card has been replaced with a different smart card), the session is terminated by the trusted device <b>24</b> in step <b>775</b>. Otherwise, in step <b>770</b>, the process from step <b>745</b> repeats by resetting the interval timer.

0075Additionally, or alternatively, in some embodiments it may be required that the user profile is encrypted and signed to protect privacy and integrity. If so, a secure data transfer protocol may be needed between the trusted device <b>24</b> and the smart card <b>19</b>. There exist many available mechanisms for transferring secure credentials between two entities. A possible implementation, which may be used in the present embodiment, is secure key transport mechanisms from ISO/IEC DIS 11770-3, “Information technology—Security techniques—Key management—Part 3: Mechanisms using asymmetric techniques”, International Organization for Standardization, March 1997.

0076Modifications of this verification process using other well-known challenge and response techniques can easily be achieved by the skilled person. Similarly, alternative verification processes can be used by parties interacting with the platform in a different manner (that is, other than as a user equipped with a smart card).