GB2444797A - Evidence of manufacturing processes - Google Patents

Abstract

In order to provide evidence concerning at least one stage of a process for manufacturing an item (10), evidence is accumulated during manufacture. After manufacture of the item (10), this evidence is used by a verifying entity (30) to provide check that the item (10) has been manufactured in an acceptable manner. Both a method and an item of manufacture for use in implementing the method, are provided. The method may be used in the manufacture of trusted computing platforms.

Description

EVIDENCE OF MANUFACTURING PROCESSES

Field of the Invention

The present invention relates to a method for providing evidence of manufacturing processes and to an item of manufacture for use in implementing such method. It is particularly relevant to the generation of evidence during manufacturing processes which can later be used by a certifying entity to provide certification that a manufactured product has been manufactured according to agreed criteria. A particular application of the invention is in the creation of trusted computing platforms.

Background

In many commercial circumstances, it is generally desirable for the manufacturer of apparatus to be able to warrant that apparatus has been properly manufactured. In certain commercial circumstances, it may be necessary or desirable to provide a high level of confidence that individual devices have been properly manufactured. Such proof would typically require evidence to be provided of the manufacturing process used to create individual devices. Provision of such proof is difficult to achieve in a way that does not significantly affect the manufacturing process, particularly where production lines are used.

This issue is particularly significant where it is necessary for multiple parties to rely on the proper manufacture of individual devices. An example of this is in trusted computing (such as is taught by the specifications of the Trusted Computing Group (TCG)), where it is necessary for parties to be able to trust that a Trusted Platform Module (TPM) has been properly manufactured, and that a computing environment (typically a computer platform) incorporating that 1PM has been properly formed and is a suitable environment for a TPM.

According to TCG specifications, both an Endorsement Certificate (EC), certifying that a TPM has been properly formed and has a valid Endorsement Key (EK) and a Platform Certificate, certifying that a particular 1PM is present in a suitably formed and appropriate computing environment, are required for appropriate trust to be placed in a computing platform containing a 1PM.

This provides practical issues in achieving economic manufacture both of TPMs themselves and of computer platforms containing TPMs, as performing the actions necessary for these certificates to be generated creates significant additional cost and unpredictability in the manufacturing process.

Summary of the Invention

In accordance with a first aspect of the present invention there is provided a method of providing assurance concerning manufacture of an item, the method comprising: (a) in respect of each of multiple stages of a manufacturing process concerning the item, providing evidence enabling authentication that an approved or particular manufacturing entity has overseen that manufacturing stage in respect of the specific item concerned; (b) after manufacture of the item, using the evidence provided in respect of said multiple stages to determine, in a verifying system, whether the item concerned has been manufactured in an

acceptable manner.

According to a second aspect of the present invention, there is provided an item arranged to provide evidence concerning multiple stages of a process for its manufacture, the item being arranged to store during the manufacturing process evidence relating to each of said multiple stages of said process, and to use the stored evidence to facilitate verification that said multiple stages of said process conforms with predetermined requirements.

According to a third aspect of the present invention, there is provided a method of providing assurance concerning manufacture of an item, the method comprising: (a) during manufacture of the item obtaining evidence in respect of a stage of manufacture to enable authentication that an approved or particular manufacturing entity has overseen that manufacturing stage in respect of the specific item concerned; (b) after manufacture of the item, using the evidence obtained in respect of said stage to determine, in a verifying system, whether the item concerned has been manufactured in an acceptable manner; the evidence being provided to the verifying system in such a way that only a specific verifying system can use the evidence as intended.

According to a fourth aspect of the present invention, there is provided a method of providing assurance concerning manufacture of an item, the method comprising: (a) during manufacture of the item, obtaining evidence in respect of a stage of manufacture to enable authentication that an approved or particular manufacturing entity has overseen that manufacturing stage in respect of the specific item concerned; (b) after manufacture of the item, using the evidence obtained in respect of said stage to determine, in a verifying system, whether the item concerned has been manufactured in an acceptable manner; where (b) is initiated by a request sent to the verifying system item upon user activation of the item, this request including supplementary data provided by the user, a positive determination in (b) by the verifying system being dependent upon verification of said supplementary data by the verifying system.

Brief Description of the Drawings

By way of example, specific embodiments of the present invention are described below with reference to the accompanying drawings, in which: Fig. 1 provides a general overview of complimentary registration and certification process in accordance with embodiments of the invention, the registration process being effected during manufacture of an item; Fig. 2 illustrates a registration process in accordance with a first embodiment of the invention, the registration process providing evidence of manufacture in relation to a trusted platform module; Fig. 3 illustrates a certification process in accordance with the first embodiment of the invention, the certification process using evidence of manufacture in relation to a trusted platform module to produce a trusted computing credential; Fig. 4 is a flow diagram that illustrates the processes of Figures 3 and 4; Fig. 5 illustrates a registration process of a second embodiment of the invention; Fig. 6 illustrates a certification process of the second embodiment of the invention; and Fig. 7 is a flow diagram that illustrates an enhanced version of the second embodiment of the invention.

Specific Description of Embodiments of the Invention Figure 1 provides a general illustration of methods according to embodiments of the invention. A production line 20, illustrated schematically in Figure 1, is provided with one or more checkpoints 25 at which stage data is generated for an item 10 undergoing manufacture; the item 10 is illustrated in dashed form as a part-manufactured object at each such checkpoint 25 on the production line). Each piece of stage data generated by the checkpoints 25 relates to a part of the item manufacturing process (a processing or manufacturing stage) -for example, identifying the manufacturing stage concerned, the entity carrying out (or, more generally, overseeing) the manufacturing stage, and any other relevant details of the manufacturing stage concerned. Each piece of stage data is then manipulated in some way to generate stage evidence for a certifying system 30 to enable it to authenticate that an approved or particular entity has overseen the manufacturing stage in respect of the item 10. In overall terms, this stage evidence comprises: the stage data itself, association evidence for associating the stage data with the item 10 and the manufacturing entity, and verification data.

The association evidence can be considered the core evidential element though all of the above elements are needed to prove the associations it evidences (this is akin to a standard public-key digital signature scheme providing evidence that a particular party has signed a document -although the digital signature produced by the party in respect of the document is the core element associating the party and document, the elements needed to prove the association comprise not only the digital signature, but also the document itself and verification data in the form of the signing party's public key).

In the present case, the stage data and association evidence are provided to the certifying system, and the verification data comprises item-verification data that the item 10 can present to the certifying system subsequent to manufacture to enable the certifying system to verify that the presenting item is the specific item that is the subject of the association evidence and therefore associated with the corresponding stage and manufacturing entity.

The stage data and/or association evidence can be provided to the verifying system by the manufacturing entity directly or they can be provided via the item 10 along with the item-verification data; in Figure 1, the item 10 is depicted as passing (arrow 32) stage evidence from its memory 15 to the certifying system 30.

Regarding how the association evidence associates the stage data with the item 10, as will be described further below, the item 10 contains a processor and a digital memory, enabling it to process the stage data so that the stage evidence provides an authenticatable association between the item and the stage data. Regarding the association between the manufacturing entity with the stage data, this can for example be evidenced by the communication path used to pass the item-processed stage data to the certifying entity or by the manufacturing entity digitally signing the item-processed stage data.

The process by which the pieces of stage evidence are generated for a manufacturing stage is referred to below as the "registration" process. The stage evidence from one or more manufacturing stages is used to persuade the certifying system 30 (preferably a party trusted by those who will need to rely directly or indirectly on the item -in some circumstances the certifying system may be the manufacturing entity, but if not the certifying system and the manufacturing entity will generally have a trust relationship between each other) to certify the item 10 as meeting some predetermined requirements, such as the meeting of the requirements of a technical standard. The process of providing a certificate based on the stage evidence is referred to below as the "certification" process. As already indicated, the certification process involves an item 10 providing the certifying system with itemverification data for establishing that the item is the specific item subject of stage evidence held by to the certifying system. If this is the case and the stage evidence is sufficient to meet the predetermined requirements, the certifying system 30 provides (in step 34) a certificate for the item 10 or its owner to certify that the item 10 meets the predetermined requirements.

Preferably, this is a certificate digitally signed with a private key of the certifying system, so that third parties can place reliance on the certificate as having been generated by the certifying system 30.

Of course, the certifying system may require an item to have undergone multiple approved processing stages before it issues a certificate. Where all manufacturing stages are carried out by the same manufacturing entity, the certifying system will usually comprise a single certifying entity making it easy to ensure that an item has been suitably processed before a certificate is issued. However, where different manufacturing stages are carried out by different manufacturing entities, then the certifying system may comprise multiple certifying entities; in this case, these certifying entities must collaborate (for example, via a head certifying entity) in the making of a determination as to whether a certificate should be issued.

There will now be described in greater detail, with reference to Figures 2 and 7, how the overall approach outlined above is applied in embodiments of the invention relating to trusted computing (particularly as described in the technical specifications provided by the Trusted Computing Group), and in particular to the manufacture of trusted components such as Trusted Platform Modules (TPM5) and of trusted platforms containing TPMs. A TPM is a computing environment designed to be located within a computer platform but to be at least logically protected against unauthorised modification from it -the TPM is adapted to store measurements of the integrity of its host computer platform, and is also provided with cryptographic capabilities. The same references as were used in Figure 1 are retained in Figures 2 to 7 for corresponding elements; in particular, the reference 10 used for the manufactured item in Figure 1 is also used for the TPM I trusted platform in Figures 2 to 7.

The approach shown in Figure 1 may be applied either to the manufacture of a TPM, or to the manufacture of a trusted platform containing a TPM, or to both. In the case of manufacture of a 1PM, the evidence would be used to provide the basis for an Endorsement Certificate (EC), a certification that the Endorsement Key (EK) possessed by the TPM was associated with a genuine and properly manufactured TPM. In the case of the manufacture of a trusted platform containing a TPM, the evidence would be used to provide the basis for a Platform Certificate, a certification that the computer platform contained a specific TPM and that the TPM was located in a properly formed computing environment (for trusted computing as taught by the Trusted Computing Group, this involves the platform comprising a root of trust for measurement (RTM) so that it can be assured that measurements of platform integrity take place without subversion).

In manufacture both of TPMs and trusted platforms, there are advantages to using approaches to providing evidence according to embodiments of the invention. Different issues arise, however, with each form of manufacture, as are discussed briefly below.

A TPM is typically provided as a single semiconductor chip (though other forms of provision are possible). It will thus typically be manufactured in a semiconductor fabrication facility. Such manufacturing environments are typically relatively secure and highly controlled, but function according to precisely controlled processes. In one prior art manufacturing process for TPM5, a TPM generates its own Endorsement Key, and then conducts a reliable exchange with the manufacturer thereafter so that the manufacturer, having been in full control of the manufacturing process, provides an Endorsement Certificate certifying that the Endorsement Key is associated with a validly manufactured TPM. There are two significant difficulties associated with this prior art solution. The first is that generation of an Endorsement Key is a non-deterministic process and can thus vary very considerably in the length of time that it takes. This is extremely difficult to accommodate in a precisely controlled manufacturing process. The second is that the generation of the Endorsement Certificate requires a significant processing capability and a significant data exchange between the TPM and the Endorsement Certificate generator -provision of such a capability on the production line is not convenient as it is not generally required in semiconductor device fabrication.

The problems in manufacture of trusted platforms containing TPMs (whether or not the TPMs have pre-existing EKs and EK Certificates) are slightly different in character. Such production lines may be less rigidly controlled, but they are also typically less secure. Providing certification at the production line creates some risks, as it is necessary to use a private key for the purpose. It is undesirable to have a private certifying key present in any environment where there is a risk that the private key may be obtained by a party that is not authorised to possess it because certification is an all-or-nothing event.

he manufacture of trusted platforms containing TPMs may continue after platforms leave a factory. For example, a value added reseller (VAR) may add certain software to the computing platform in which case there is preferably evidence to show that the computer platform has been sold by a specific VAR.

Indeed, the manufacture of trusted platforms containing TPMs may even continue when the platforms are in the possession of the final customer or end user. his is already common practice for PC platforms; for example.

existing platforms may complete the software environment in a platform when the end user first switches on the platform, and in such cases the related evidence may comprise identification of the customer or may comprise identification information supplied to the customer, for example.

Both the manufacture of TPMs and of trusted platforms (items 10) may therefore benefit from deferral of the generation of certificates to a later stage.

In embodiments of the invention, this is achieved by the generation of preferably multiple pieces of stage evidence (which can be done in a fast and deterministic manner), and storage of item- verification data in the item 10 in the 1PM, during the manufacturing process. This evidence is then later used -for example, on first activation of the computer platform by the end user -to obtain the necessary certificates.

A first method embodying the invention is described below with reference to Figures 2 to 4. In particular, Figure 2 shows the registration process for generating stage evidence at a checkpoint 25 corresponding to a particular stage in the manufacture of a 1PM 10 (the process is essentially similar at a checkpoint in the manufacture of a trusted platform). At each checkpoint, a data logger 50 is provided on the production line; in fact, a single data logger 50 can be provided for all checkpoints overseen by the same manufacturer. If a platform that is being manufactured contains a TPM, the platform itself may act as the data logger with appropriate software being loaded and run on the platform (this software is preferably removed when now longer needed).

The ordata logger 50 is loaded with a public key ("CEpubKey") of the certifying entity to be used in relation to the manufacturing stage or stages (checkpoints) served by the data logger.

For each checkpoint, the corresponding data logger 50 is required to reliably insert stage data ("reference") into 1PM 10 and reliably record item-processed stage data ("registeredSignature") from the 1PM but does not require cryptographic functions or on-line access while communicating with the 1PM. The stage data ("reference") may include identification information, such as a serial number, provided by a manufacturer or process-certifying entity, for example. Such identification information is preferably not retained by the data logger once the registration process is complete, to avoid the potential for misuse of the identification information. None of the data logger's data are secrets, although they may be private. The data logger may, of course, require cryptographic operations and on-line access to communicate with a certifying entity. If the platform containing the 1PM is the data logger, the platform may communicate with the certifying entity using any communication method that is available to the platform, such as via a modem or a LAN or wirelessly, or via a physical token, such as USB memory or a floppy disk or a CD.

Insertion of stage data ("reference") into a TPM can be achieved by use of predefined commands which the 1PM is arranged to recognise and act upon.

These commands support the registration process in relation to the manufacture of TPM5 and TPM-enabled platforms to enable TCG certificates to be created at any time after registration. The commands enable recording of the passage of a TPM (and the platform containing that TPM) through various stages of processing. The more stages that are recorded, the greater the confidence that a particular TPM and TPM- enabled platform deserves an EK and / or platform certificate. The commands used, for example, may be tagged with the prefix "TPM_register".

For the process shown here, the 1PM 10 is sufficiently well formed to be able to operate and use a basic cryptographic functionality -if checkpoints at an early phase of manufacture are required, a different mechanism must be used appropriate to the then state of the 1PM.

Using the plain command TPM_register, the data logger 50 provides two pieces of data to the 1PM 10, namely: a reference ("reference") typically indicating the manufacturer and an identification of the relevant stage of the manufacturing process, and a public key ("CEpubKey") of the process certifying entity to be used (typically the manufacturer itself). The TPM receives this data and generates and returns to the data logger a hash ("registeredSignature") computed using the reference ("reference") and the public key ("CEpubKey"). This hash needs to be demonstrably the product of the 1PM, but also should be obtainable fast and predictably (and hence should be the result of a deterministic process). This can be achieved with an HMAC hashing process: the 1PM can generate an HMAC key ("regKey") using its random number generator, and use this key to generate a hash of the reference, the public key, and a nonce ("regNonce") generated for the purpose by the 1PM. The data logger 50 stores the TPM's response ("registeredSignature") as plain text.

The plain command TPM_register thus enables a trail of a manufacturing process to be recorded in a TPM. . The TPM_register command is rapid and of fixed duration, requiring essentially just the creation of two nonces ("regKey", "regNonce") and performance of one HMAC digest. As a consequence, the TPM_register command can be executed at each of the checkpoints.

Eventually enough items of stage evidence, concerning respective manufacturing stages, are associated via TPM_register with a 1PM 10 (or a trusted platform incorporating a 1PM) to justify the generation of an EK and br platform credential. The end result is that the TPM and the data logger(s) both hold a chain of evidence comprising a series of references and a series of associated hashes ("registeredSignatures")..

As depicted in Figure 2, the evidence held by the or each data logger 50, for example, the received HMAC ("registeredSignatures") together with the relevant reference and public key ("CEpubKey"), is provided to the certifying entity 30 to enable the latter to certify that the manufacturing process was performed according to the relevant predetermined requirements -this evidence should be held securely, and can subsequently be used in a secure computing environment when needed. If a certifying entity 30 is prepared to accept a delayed response and the data logger is the platform hosting the 1PM, the TPM's hash response ("registeredSignatures") may be recorded in the TPM's protected non-volatile storage or in other platform memory, and provided to a certifying entity at a later time (for example by the platform sending the registered signature(s) to the certifying entity via a communications node of the manufacturer such as to provide a verifiable association with the manufacturing entity).

In relation to the terms used above when describing the registration process in relation to Figure 1, at the end of the Figure 2 registration process for each manufacturing stage, the "stage evidence" comprises the "reference" (the "stage data"), the "registeredSignature" (the "association evidence"), and the elements "regKey" and "regNonce" held by the TPM (the "item-verification data"). It may be noted that "registeredSignature" does not of itself associate the manufacturing entity with the TPM and stage data but in this first embodiment, the communication endpoint or path used to pass "registeredSignature" to the certifying entity is utilized to prove to the certifying entity that the evidence is being provided by a particular (or an anonymous but approved) manufacturing entity; this applies even where the data logger is the plafform provided the latter uses a communication node of the manufacturing entity to contact the certifying entity. Where the certifying entity is the manufacturer carrying out a particular processing stage and that stage takes place in a closed environment which also holds the certifying entity, the certifying entity can reliably trust that the evidence provided by the stage data logger originates from the manufacturer.

Other commands in the TPM_register family comprise TPM_registerGetHandle and TPM_registerGetCertificate and these use information associated with TPM_register to generate evidence of processing for process-certifying entities. TPM_registerGetHandle and TPM_registerGetCertificate may be used at any time after a TPM has an EK and the appropriate checkpoint has been recorded in the TPM and data logger.

The TPM_registerGetHandle command causes the 1PM to return a list of public keys belonging to entities that have registered with the TPM for the purpose of creating a processing certificate. The pubkeys are externally indexed via nonces generated by the TPM. This anonymises the trail of processing of a particular TPM / platform.

The TPM_registerGetCertificate command causes the TPM to return data that can be used to request a processing certificate. A proof-of-purchase, verifiable by a certification entity, is optionally shipped to the customer along with the platform, to be used with TPM_registerGetCertificate.

There is no significant substantive difference between the results achieved in TPM manufacture and in trusted platform manufacture -the type of information in the references may differ in practice (for example, a platform reference may indicate not only the manufacturer and the manufacturing stage, but also the type of platform being constructed and additional details concerning the computing environment), but the basic process need not.

Use of registration processes such as described above for generating evidence of manufacture allows the certification of the TPM and the computing platform to be deferred to a later stage. This deferral may be to a later stage of the manufacture and distribution chain (for example, by a value added reseller), or alternatively, evidence relating to such later stages could itself be logged, as it may be relevant to a certifying entity's willingness to certify the TPM or the computing platform. A logical point for effecting the certification process is when the computing platform is activated by the end user. A description will now be given, with reference to Figure 3, of the carrying out of the certification process of the first method embodying the invention, at the time a computing platform is activated by the end user.

Turning now to a consideration, for the first embodiment, of the certification process carried out in respect of each set of stage evidence, it is first noted that a certifying entity 30 preferably has one further asymmetric key additional to that needed to effect a simple signing operation. More particularly, a certifying entity 30 preferably has: one asymmetric signing key (as normal), one asymmetric encryption key (for decrypting data provided by the TPM as will be more fully explained below), a safe environment to store data gathered by the data logger, and a secure environment to decrypt information from a TPM and to sign certificates.

The certification process may simply begin with dialogue with the user initiated by the computing platform when it is activated -this could be in the form of a question to the user as to whether he or she wishes to obtain Endorsement and Platform Certificates (assuming neither has so far been obtained, but that evidence relevant to each is held by the TPM). In the example shown in Figure 3, the user provides the 1PM 10 with supplementary data 60 This supplementary data is, for example, licence data in the form of a license number ("licence") provided in documentation associated with the platform for software held on the platform, and/or proof-of-purchase data.

Such supplementary data will generally not have been available during manufacture (for example, a software license number may well be providedindependently of the manufacturing stage during which the software was added to the platform) but is likely to be relevant, as a matter of policy, at least to whether a platform certificate should be issued). Although supplementary data 60 could be provided in relation to every manufacturing stage to be evidenced, the provision of data 60 may only be required in respect of one particular stage or may only be required to be provided once to the certifying entity in respect of all the stages for which it is to provide an encompassing certificate. The 1PM generates its own Endorsement Key (if it has not already done so) - outside a production environment, it does not matter that this is a non-deterministic process of unpredictable duration -and prepares data for certification.

In order to decide which certifying entity to use, the user uses the command TPM_registerGetHandle to ascertain what certifying entity or entities can be used; thereafter, the user uses TPM_requestCertificate to cause the TPM to generate data to be sent to a certifying entity. This data is then sent to the chosen certifying entity.

The data prepared for sending to the certifying entity 30 must be sufficient to allow the certifying entity 30 to be able to ensure that the data matches the association evidence provided through the data logger(s) 50; in the present embodiment, this data must at least comprise the stage data ("reference"), and the item-verification data ("regKey" and "regNonce"). To provide this data, but in a form which would vary each time a certificate is requested (preserving privacy by preventing correlation of data transmitted from a particular computing platform), the data should include a further nonce and be encrypted. In the preferred form of the first embodiment, this is achieved by encrypting the data with a nonce symmetric encryption key (generated at the TPM.) that is also included in a hash added to the data to be encrypted. Use of a nonce symmetric encryption key has the added advantage of eliminating constraints on size of data to be sent. The nonce symmetric encryption key is itself encrypted for passing to the certifying entity using the public key "CEpubKey" of the latter.

The certification process carried out by the first embodiment in relation to one manufacturing stage is illustrated in Figure 3. The license information 60, the reference ("reference") , the symmetric encryption key ("nonceSymmetricKey") and the public Endorsement Key ("pubEK") of the 1PM are hashed using the same HMAC process and key ("regKey") as used to generate the TPM response ("registeredSignature") to the data logger.

This hash ("requestSignature"), together with the reference, the license information, the nonce ("regNonce") and the key ("regKey") used in generating the response ("registeredSignature") to the data logger, are all encrypted using the symmetric key ("nonceSymnietricKey"). The nonce symmetric key is itself encrypted using the certifying-entity public key ("CEpubKey") used in the evidence generating process. The data encrypted with the nonce symmetric key and the encrypted nonce symmetric key itself are provided together to the certifying entity 30 as a request for certification.

The certifying entity 30 -typically the manufacturer (or controller of the TPM/platform processing step concerned) itself, but it is possible that the evidence has been forwarded to another certifying party with which the manufacturer has a strong trust relationship -receives the request from the TPM 10 and uses the private key corresponding to the public key ("CEpubKey") used in evidence generation to decrypt the nonce symmetric key, and hence to unpack the evidence from the request. This use of the private key can be made in a secure computing environment, as it need not be physically associated with the manufacturing process. This evidence is then processed to check its compatibility with the evidence received from the data logger 50; in particular, the key ("regKey") used in generating the TPM response ("registeredSignature") to the data logger is now used to recompute that response using the components supplied by the TPM for comparison with the version received by the certifying entity via the data logger. A match assures the verifying entity that the TPM making the request for a certificate is the TPM that generated version supplied via the data logger (this version already being known to be associated with a particular manufacturing entity).

Furthermore, the stage data "reference" is also tied in with the TPM and manufacturing entity.. Confidence can be enhanced by via verification, by recomputation of the "requestSignature" hash, that the same HMAC key was used during registration (for generating ("registeredSignature") and during the request for the certificate. The supplementary data 60 ("licence") is preferably also checked against a database of acceptable values (for example, license numbers or, where the supplementary data is proof-of-purchase data, sales data).

The certifying entity 30 can then establish whether it is prepared to certify that this process stage was performed by the relevant manufacturer on the requesting TPM. If so the certifying entity uses his private signing key to create a processing certificate. A processing trail may need to be certificated to convince some entity to create an EK credential and / or a platform credential.

As already indicated, generation of a certificate may follow directly or indirectly from the verification process carried out by the certifying entity on the basis of the stage evidence. In the simplest case, the certifying entity receives evidence from multiple stages of processing of a particular TPM or platform and is able from its collected evidence to judge whether the whole manufacturing (or other) process has been validly carried out, and if so can itself generate and digitally sign the relevant certificate (containing the public Endorsement Key of the relevant TPM) and act as certifying entity for it.

Alternative models are possible -it may be more commercially appropriate, and consistent with the trust relationships for end users and parties interacting with the trusted platform, for the entity providing the certificate to be a well-known third party independent of the manufacturer itself. Use of such a third party may also be appropriate where evidence generated for processing stages under control of different parties (for example, the TPM manufacturer, the platform manufacturer, and even a value added reseller and/or the end user) is relevant. In this case, the certifying entity or entities associated with the various TPM/platform processing stages may attest to an overall third-party certifying entity as to what evidence they have (and have confirmed against the TPM request) concerning the manufacture of a TPM or trusted platform, and the overall certifying entity may judge whether this evidence is sufficient for it to issue the relevant certificate As already mentioned, the term "certifying system" is used herein to cover both the case where a single certifying entity is involved in determining whether a certificate is to be issued, and the case where multiple certifying entities are involved.

Where the certifying system is supplied with stage evidence in respect of multiple processing stages and makes a judgement based on these multiple sets of stage evidence whether the item concerned has been manufactured in an acceptable manner, this judgement will typically be based on a specified policy that determines what sets of stage evidence are essential and what processing entities are acceptable -if appropriate, a point scoring system can be used and different point counts can be applied to different pieces of evidence (optionally with different weightings applied according to the processing entity involved). More complicated policies can be applied using artificial intelligence reasoning systems.

The level of confidence in information submitted to a certifying entity may be improved if the data supplied to a certifying entity is additionally signed by one of a TPM's Attestation Identity Keys. This requires an alteration to existing TCG specifications, since signing with an AIK is strictly controlled. An AIK signature over certification data, interpreted in the context of an AIK certificate, provides confidence to a certifying entity that that registration data came from a genuine TPM with a particular EK and AIK. If correlation between EK and AIK is unacceptable because of privacy concerns, the data provided to the certifying entity could be modified to exclude the public EK.

On receipt of certification information signed by a verified AIK, the certifying entity should have sufficient confidence to provide a certificate of some sort for the TPM with that EK and/or AIK. The certificate could indicate when the certifying entity received the registration information, and/or the EK of that TPM, and/or the AIK used by that TPM, for example. The certificate might be used as evidence of when manufacturing of a platform containing a TPM with a particular EK and/or particular AIK was finished on customers' premises, for example. Alternatively, the certificate could be a normal EK Certificate.

Alternatively, if the 1PM with that AIK and/or EK is already known to be incorporated into a genuine trusted platform, the certificate could be a normal Platform Certificate.

Figure 4 depicts the steps of the above-described first method with steps 400 to 408 being the registration process and steps 410 to 414 being the certification process. At step 400 the checkpoint data logger 50 uses the TPM_register() command to pass: a reference (for example, a digest assigned by the certifying entity 30 to register this stage of processing), and CEpubKey (a TPM_PUBKEY public encryption key belonging to the certifying entity that wishes to sign processing certificates). In response at step 402 the 1PM creates registrationKey (an HMAC key created by the TPM's RNG); registrationNonce (a nonce from the TPM's RNG); and registeredSignature (the HMAC of reference registrationNonce CEpubKey signed by registrationKey).

The 1PM stores at step 404 the data reference, CEpubKey, registrationNonce and registrationKey in the certificatelndex row of a TPMregistry table of Shielded Locations.

The 1PM returns registeredSignature at step 406 and the data logger stores at step 408 the structure (CEpubKey, reference, registeredSignature) and sends it to the certifying entity 30.

At step 410 the 1PM distinguishes or selects a particular certifying entity and generates data to enable generation of a certificate by that certifying entity.

To distinguish a particular certifying entity, TPM_registercetHandle() returns an array of pairs (certificatelndex, CEpubKey), where "certificatelndex" is a pointer to the row in the TPMregistry table containing CEpubKey. To generate data to enable generation of a certificate by a selected certifying entity, TPM_registerGetCertificate() passes index -a pointer to a particular set of registration information, obtained via TPM_registerGetH andle() and licenceDigest -a plain-text value optionally given to a customer as proof-of-purchase. In response the 1PM creates sessionKey -a nonce symmetric key created by the TPM from the TPM's RNG -and creates requestSignature -the HMAC of [reference II licenceDigest sessionKey pubEK] signed using registrationKey. The TPM returns reference, licenceDigest, registrationNonce, registrationKey, requestSignature, pubEK, all encrypted by sessionKey, plus sessionKey encrypted by CEpubKey.

At step 412 the Owner or Operator sends to the certifying entity the data returned by TPM_registerGetCertificate. At step 414 the certifying entity creates the certificate. In particular the entity uses CEpubKey to identify a corresponding privKey, uses that privKey to decrypt sessionKey, uses sessionKey to decrypt the values returned by TPM_registerGetCertificate, verifies that licenceDigest is valid proof-of-purchase, verifies that requestSignature is the HMAC of [tpmReference licenceDigest sessionKey JJ CEpubEK] using registrationKey, uses reference to locate the registeredSignature, and verifies that registeredSignature is the HMAC of reference II registrationNonce CEpubKey signed by registrationKey The first method described above requires checkpoints to log registeredSignatures and reliably communicate those registeredSignatures to certifying entities 30. A second method embodying the invention that may be used in conjunction with such logging or instead of such logging is to provide capability at the checkpoint 25 to protect and use a cryptographic signing key to cryptographically sign registeredSignatures and store the resultant signature (called registerReceipt) in the platform or (preferably) the TPM using additional storage capability at the TPM. If the platform hosting the TPM is the logger, the platform should of course reliably erase the cryptographic signing key after completing the registration process. Later, the TPM can provide the registerReceipt to the appropriate certifying entity. If the appropriate public verification key is accepted by certifying entities, a certifying entity can verify that a registerReceipt retrieved from a 1PM is a signature created at a bona fide checkpoint of an approved or particular manufacturing entity. A certifying entity might accept a verification key by virtue of the fact that it was manually communicated (via email, for example) by the manufacturing factory, for example. Preferably a checkpoint would not be operated until a certifying entity had confirmed acceptance of the verification key. Verification keys could be recorded when a checkpoint is installed in a production environment, or when new signing keys are created (at the start of every new production batch, for example). Preferably, new public verification keys would be accompanied by evidence that they are valid verification keys. Such evidence could take the form of arbitrary data signed by the corresponding signing key, and I or a certificate describing the verification key, and / or selected examples of registeredSignatures and registerReceipt, for example.

A verification key does not necessarily disclose the identity of a manufacturer as it may be sufficient for the verification key to be reliably associated with an approved' manufacturer for example by a certificate issued by an appropriate certifying authority.

RegisterReceipts must be communicated anonymously to certifying entities, in order to maintain platform privacy. This can be done using the same method as previously, where data is encrypted under a symmetric key that is itself encrypted under the public key of a certifying entity.

In one implementation, the checkpoints are Trusted Platform PC-Clients each with their own 1PM; in this case, each checkpoint's signing key is a non-migratable key (that is, specific to the TPM) protected by the PC's TPM, the checkpoints' validation keys are the public part of those non-migratable keys, and each checkpoint's TPM creates a TCG certifylnfo data structure signed by a TPM identity key to attest to the properties of the non-migratable key.

This certifylnfo structure and the attestation identity key (AIK) certificate of the TPM identity key should be accepted by a certifying entity as evidence that a checkpoint's verification key is a bone fide verification key.

Figure 5 illustrates the registration process of the second method. Stages I and 2 are the same as previously described. In stage 3, the checkpoint signs the registeredSignature and sends the registerReceipt to the 1PM, which records it with the existing data set of [reference, CEpubKey, regNonce, regKey].

Figure 6 illustrates the certification process of the second method. The process is similar to that described previously, except that the data encrypted by the symmetric key includes registerReceipt, and requestSignature is an HMAC over data that includes registerReceipt. Again, supplementary data (for example, license data 60) may be incorporated into the process The second method could be further enhanced by passing a checkpoint's verification key to a 1PM along with the registerReceipt, and the 1PM verifying the registerReceipt before accepting the registerReceipt. This checks that each registerReceipt is a valid signature. Preferably the TPM stores the checkpoint's verification key, to provide redundancy in case a verification key is lost. (If a very large number of platforms with valid licences, for example, used the same lost checkpoint verification key, it is likely that that verification key is genuine.) The second method could be further enhanced by storing in TPMs a verification key belonging to a certifying entity, causing the certifying entity to sign a checkpoint's validation key, and causing the TPM to verify the checkpoint's validation key using the entity's verification key before accepting a registerReceipt. This proves that the checkpoint's validation key has been acknowledged by a certifying entity.

Fig. 7 is a flow diagram illustrating the steps implemented in relation to the second method when incorporating the above enhancements. This diagram is similar to that shown in Figure 4 for the first method and repetition of the detail in common to the first method and the enhanced second method is avoided, for the purposes of clarity, except where additional explanation is required. At step 700 the checkpoint which may be for example a Trusted Platform PC-Client as described above confirms its verification key with a certifying entity prior to operation. At step 702 the checkpoint passes the reference and CEpubKey to the TPM and the TPM returns its registeredSignature at step 706, again as is discussed above with reference to Fig. 4. At step 708 the checkpoint finds the registeredSignature and returns the registerReceipt to the TPM together with the verification key.

At step 710 the TPM verifies the registerReceipt and stores it as well as the verification key as discussed above. At step 712, when a platform certificate is required, TPM distinguishes the certifying entity 30 and the requestSignature as indicated above, except that the requestSignature data structure is an HMAC over data that includes registerReceipt together with its verification key. At step 714 the certifying entity 30 checks to see registerReceipt and verification key in order to provide appropriate certification, the various checks following the approach described in more detail above with reference to Fig. 4.

Although this enhanced second method puts a signing capability in a manufacturing environment, this method is different to putting a certifying entity in a manufacturing environment. Some reasons are that: (1) the control point for issuing EK and platform certificates is not exposed to a manufacturing environment; (2) there is additional redundancy (multiple checkpoints must be missed before it becomes impossible to issue EK and platform certificates, and it is possible to recover from inappropriate issuance of a registerReceipt); (3) there is additional confidence (extra information such as reference data, licence data, and other checkpoints, can be taken into account before issuing an EK or platform certificate).

One advantage of this enhanced second method is that it can eliminate the need for a checkpoint to record registeredSignatures and another is that it can reduce the effect of data loss. If a registerReceipt is lost by a 1PM, only that TPM is affected and the loss is likely to be inconsequential because the loss of registerReceipt from a TPM is likely to mean that that TPM was faulty.

On the other hand, loss of a log of several registeredSignatures from a checkpoint affects many platforms, which are presumably still functional.

Another advantage of this method is that it eliminates the need for the checkpoint to communicate large volumes of data to certifying entities. Only the validation key is essential to be communicated from the checkpoint to the certifying entities.

It should be noted that privacy is preserved effectively through these processes -only the manufacturer (or other process controller) is able to identify the TPM associated with a particular process step, by virtue of the data encryption approach adopted. Third parties intercepting communications are not able even to correlate certificate requests with a particular computing platform, as the certificate request itself will change each time it is made (as the symmetric encryption key will change each time).

Generating processing certificates on a production line requires either cryptographic signing equipment on the production line or a secure communication channel to a secure environment that can do cryptographic signing. Using this process, however, the processing certificate can be created by the manufacturer after delivery of equipment to the customer. The process does not decrease a customer's privacy because data used to request processing certificates cannot be used by a third party to identify a TPM or a platform. The reason is that the data changes every time that certificates are requested, and cannot be interpreted by anyone other than the registered certifying entity. In addition the certifying entity cannot obtain data from a platform without consent of the Owner. The reason is that production of the data via TPM_registerGetCertificate requires use of Owner authorization data.

The provision of supplementary data 60 (such as license data) can be effected whether one or multiple processing stages are to be evidenced to a certifying system. Furthermore, the provision of supplementary data 60 can be omitted if this data is not required by the certifying system.

In certain applications, the issuance of a certificate by the certifying system may not be required, the role of the system simply being to verify that an item has been manufactured in an acceptable manner (for example, before release into a closed operational environment). Thus, in the broader view of the present invention, the foregoing certifying system (and certifying entities) becomes a verifying system (entities) with the generation of certificates being an additional function provided in many applications (such as in the embodiments described above).

Claims (26)

1. Claims 1. A method of providing assurance concerning manufacture of an

   item, the method comprising: (a) in respect of each of multiple stages of a manufacturing process concerning the item, providing evidence enabling authentication that an approved or particular manufacturing entity has overseen that manufacturing stage in respect of the specific item concerned; (b) after manufacture of the item, using the evidence provided in respect of said multiple stages to determine, in a verifying system, whether the item concerned has been manufactured in an acceptable manner.
2. 2. A method as claimed in claim 1 in which (b) further comprises the verifying system issuing a certificate on determining that the item concerned has been manufactured in an acceptable manner.
3. 3. A method as claimed in claim 1 in which the verifying system comprises: a plurality of verifying entities each verifying, for each of one or more corresponding manufacturing stages, that the stage concerned has been carried out on the item by an approved or particular manufacturing entity, and a head verifying entity determining whether the item concerned has been manufactured in an acceptable manner in dependence on the verifications effected by the other verifying entities.
4. 4. A method as claimed in claim 1, in which the evidence provided in (a) is provided in a form whereby the item can be identified from the evidence only by the verifying system.
5. 5. A method as claimed in claim I in which for each manufacturing stage the evidence comprises: stage data indicative of the manufacturing stage concerned; association evidence associating the stage data with the manufacturing entity overseeing that stage and the item; and verification data comprising item-verification data generated and stored by the item.; the stage data and association evidence being provided to the verifying system to enable the latter to verify, as part of (b), the association of the item and manufacturing entity with the stage upon presentation of the item-verification data to the verifying entity by the item.
6. 6. A method as claimed in claim 5 in which the association evidence evidences the association of the item with the stage data by means of a digital signature of the stage data by the item.
7. 7. A method as claimed in claim 6 in which the digital signature by the item is a keyed hash formed using a key generated by the item and passed confidentially to the verification system in the item verification data.
8. 8. A method as claimed in claim 6 in which the association evidence evidences the association of the manufacturing item with the stage data by virtue of the manufacturing entity being used to pass the digital signature of the stage data by the item to the verifying system
9. 9. A method as claimed in claim 6 in which the association evidence evidences the association of the manufacturing item with the stage data by virtue of the manufacturing entity digitally signing the digital signature of the stage data by the item.
10. 10. A method as claimed in claim 1 in which the item comprises a trusted computing component.
11. 11. A method as claimed in claim 10 in which the trusted component comprises one of a trusted platform module or a trusted platform containing a trusted platform module.
12. 12. A method as claimed in claim 1 in which the item comprises a trusted computing platform containing a trusted platform module, (b) being initiated by a request generated by the trusted computing platform upon user activation.
13. 13. A method as claimed in claim 1 in which the item comprises a trusted computing platform containing a trusted platform module, (b) being initiated by a request sent to the verifying system by the trusted computing platform upon user activation, this request including supplementary data provided by the user, a positive determination in (b) by the verifying system being dependent upon verification of said supplementary data by the verifying system.
14. 14. A method as claimed in claim 13 in which said supplementary data is license data.
15. 15. A method as claimed in claim 13 in which said supplementary data is proof of purchase data.
16. 16. An item arranged to provide evidence concerning multiple stages of a process for its manufacture, the item being arranged to store during the manufacturing process evidence relating to each of said multiple stages of said process, and to use the stored evidence to facilitate verification that said multiple stages of said process conforms with predetermined requirements.
17. 17. An item as claimed in claim 16 in which the item comprises one of a trusted platform module and a trusted platform containing a trusted platform module.
18. 18. An item as claimed in claim 17 in which the trusted platform module holds respective stage data for each said stage, a digital signature of stage data for the stage, and a key unique to that stage and used in generating the digital signature of the corresponding stage data.
19. 19. A method of providing assurance concerning manufacture of an item, the method comprising: (a) during manufacture of the item, obtaining evidence in respect of a stage of manufacture to enable authentication that an approved or particular manufacturing entity has overseen that manufacturing stage in respect of the specific item concerned; (b) after manufacture of the item, using the evidence obtained in respect of said stage to determine, in a verifying system, whether the item concerned has been manufactured in an

    acceptable manner;

    the evidence being provided to the verifying system in such a way that only a specific verifying system can use the evidence as intended.
20. 20. A method as claimed in claim I in which in (a) a public key of said specific verifying system is included in the evidence.
21. 21. A method as claimed in claim 20 in which the evidence comprises: stage data indicative of the manufacturing stage; association evidence associating the stage data with the manufacturing entity overseeing that stage and the item; and verification data comprising item-verification data generated and stored by the item.; the stage data and association evidence being provided to the verifying system to enable the latter to verify, as part of (b), the association of the item and manufacturing entity with the stage upon presentation of the item-verification data to the verifying entity by the item.
22. 22. A method as claimed in claim 21 in which the association evidence evidences the association of the item with the stage data by means of a keyed hash formed using a key generated by the item and passed confidentially to the verification system in the item verification data.
23. 23. A method as claimed in claim 21 in which the association evidence evidences the association of the manufacturing item with the stage data by virtue of the manufacturing entity being used to pass the digital signature of the stage data by the item to the verifying system
24. 24. A method as claimed in claim 21 in which the association evidence evidences the association of the manufacturing item with the stage data by virtue of the manufacturing entity digitally signing the digital signature of the stage data by the item.
25. 25. A method as claimed in claim 20 in which (b) is initiated by a request sent to the verifying system by the item upon user activation, this request including supplementary data provided by the user, a positive determination in (b) by the verifying system being dependent upon verification of said supplementary data by the verifying system.
26. 26. A method of providing assurance concerning manufacture of an item, the method comprising: (a) during manufacture of the item, obtaining evidence in respect of a stage of manufacture to enable authentication that an approved or particular manufacturing entity has overseen that manufacturing stage in respect of the specific item concerned; (b) after manufacture of the item, using the evidence obtained in respect of said stage to determine, in a verifying system, whether the item concerned has been manufactured in an

    acceptable manner;

    where (b) is initiated by a request sent to the verifying system item upon user activation of the item, this request including supplementary data provided by the user, a positive determination in (b) by the verifying system being dependent upon verification of said supplementary data by the verifying system.