GB2412465A - Resetting a register on receipt of a locality confirming message - Google Patents

Abstract

A method and apparatus for resetting and modifying special registers in a security token is described. In one embodiment, a register may be reset when a reset flag is true when a special transmission on a bus demonstrates the mutual locality of the associated processor and chipset. A modify flag may also be used to indicate whether the register contents may be modified. Modifications may also be dependent upon demonstration of mutual locality. A locality confirming message may be sent by security bus logic in response to receiving a special bus message from a processor.

Description

24 1 2465

SYSTEM AND METHOD FOR RESETTING

4 PLATFO1<n: ,ONGURATION REGISTER

FIELD

1] The present disclosure relates generally to microprocessor systems, and more specifically to microprocessor systems that may operate in a trusted or secured environment.

BACKGROUND

2] The increasing number of financial and personal transactions being performed on local or remote microcomputers has given impetus for the establishment of "trusted" or "secured" microprocessor environments.

The problem these environments try to solve is that of loss of privacy, or data being corrupted or abused. Users do not want their private data made public. They also do not want their data altered or used in inappropriate transactions. Examples of these include unintentional release of medical records or electronic theft of funds from an on-line bank or other depository. Similarly, content providers seek to protect digital content (for example, music, other audio, video, or other types of data in generalJ from being copied without authorization.

3] One component of such a trusted microprocessor system may be trusted platform module (TPM3, as disclosed in the Trusted (computing Platform Alliance (TCPAJ Main Specification, version l.la, 1 December 2001, issued by the Trusted Computing Platform Alliance (available at www. trustedpc.com at the time of filing of the present application). The TPM may include several special registers, called platform conk gumption registers (PCR) The PCRs may be used to store encrypted digests of files, including software programs, which may later be retrieved to further the process of authentication. As the contents of these PCRs are therefore significant to the secure or 'rusted nature of the system, the PCRs should 3;) ,cl, be reset 'by gneral-purpose cpeaticus of the system. Current: design limits the PC,Ps to be rese'; only upon a goner system reset: E.g. power- on reset).

SUMMARY OF THE INVENTION

According to a first aspect of this invention there is provided an apparatus as claimed in claim I or 12 herein.

According to a second aspect of this invention there is provided a chipset as claimed in claim g herein.

According to a third aspect of this invention there is provided a method as claimed in claim 15 herein.

Preferred features of the invention are defined by the dependent claims. 2< in, lo.

BRIEF DESCRIYIION OF TlIE 1)RAWINGS [Q0041 'Ihe present hovel ion is illustrated try way of example, avid not by way of limitation, no the figures of the clccor,lpanying drawings and in which like reference numerals refer to similar elements and in which: L ] Figure 1 is a diagram of an exemplary trusted or secured software environment, according to one embodiment of the present invention.

6] Figure is a diagram of certain exemplary trusted or secured software modules and exemplary system environment, according to one embodiment of the present invention.

7] Figure 3 is a detailed diagram of the security token of the system of Figure 2A, according to one embodiment of the present invention.

8] Figure 4 is a schematic diagram of an exemplary microprocessor system adapted to support the secured software environment of Figure 1, according to one embodiment of the present invention.

9] Figure 5 is a flowchart showing resetting of platform configuration registers, according to one embodiment of the present invention.

[00101 Figure 6 is a flowchart showing resetting of platform configuration registers, according to another embodiment of the present invention.

DETAILED:DESC:RIPPION [00111 The following description describes techniques for resetting or modifying special registers used in a feasted or secured environment in a microprocessor system. In the followlug description, nullleros specific details such as logic implementations, software module allocation, 3r! ntr;l cch';les bits situating echniclles. and details of operation are set forth in order to provide a more thorough understanding of the present invention. It will be appreciated, however, by one skilled in the art that the invention may be practiced without such specific details. In other instances, control structures, gate level circuits and full software instr-ucrion sccluences have not Con ShO1 it' scat: il in order not to obsc, or e the invention. Those of ordinary skill in the Arts Witil the in c', i ted descriptions, will be able to implement appropriate functionality without undue experimentation. The invention is disclosed in the form of a microprocessor system. However, the invention may be practiced in other forms of processor such as a digital signal processor, a minicomputer, or a mainframe computer.

2] In one embodiment, a new kind of platform configuration register (PCR) is used in conjunction with a trusted platform module (TPM) within a security token. Each new POR may have associated with it a pair of flags that may be used to indicate whether or not the PCR may be either reset or have its contents modified. The security token may have a bus interface that may receive special locality-confrming messages. These iocalty-confrming messages may indicate both that the security token is in direct physical connection with other system resources and also that trusted software desires to reset or modify PCR contents.

3] Referring now to Figure 1, a diagram of an exemplary trusted or secured software environment is shown, according to one embodiment of the present invention. In the Figure 1 embodiment, trusted and untrusted software may be loaded simultaneously and may execute simultaneously on a single computer system. A secure virtual machine monitor (SVMM) 350 selectively permits or prevents direct access to hardware resources 380 from one or more untrusted operating systems 340 and untrusted applications 310 through 330. In this context, "untrusted" does not necessarily mean that the operating system or applications are deliberately misbehaving, but that the size and variety of interacting code makes it impractical to reliably assert that the software is behaving as desired, and that revere are no Rises or other foreign code interfering with its execution. In a typical embodiment, the untrusted code might consist of the normal operating system and applications found on today's personal computers.

4] SVMM 350 also selectively permits or prevents direct access to hardware resou c.s 380 from one orluore trusted or secure kernels 360 and one or more trusted applications 370. Such a trusted or secure kernel 360 and trusted applications 370 may be limited in size and functionality to aid in the ability to perform trust analysis upon it. The trusted application 370 may be any software code, program, routine, or set of routines which is executable in a secure environment. Thus, the trusted application 370 may be a variety of applications, or code sequences, or may be a relatively small application such as a Java apples.

[()015] Instructions or operations normally performed by operating system 340 or kernel 360 that could alter system resource protections or privileges may be trapped by SVMM 350, and selectively permitted, partially permitted, or rejected. As an example, in a typical embodiment, instructions that change the processor's page table that would normally be performed by operating system 340 or kernel 360 would instead be trapped by SVMM 350, which would ensure that the request was not attempting to change page privileges outside the domain of its virtual machine.

6] Referring now to Figure 2, a diagram of certain exemplary trusted or secured software modules and exemplary system environment is shown, according to one embodiment of the present invention. In the Figure 2 embodiment, processor 202, processor 212, processor 222, and optional other processors (not shown) are shown. In other embodiments, the number of processors may differ, as may the boundary 9 f various components and functional units.

7] Processors 202, 212, 222 may contain certain special circuits or logic elements to support secure or trusted operations. For example, processor 202 may- contain secure enter tSENTTER) logic 204 to support the execution of special SEN'I'ER instructions that may initiate fisted -^ e.ratic,ns RENTER Is one example of a privileged,ns rucrion defined FESS ? machine instruction tilat usually can only be executeci when in special mode and usually available to the operating system or systems but not to other Users. Privileged operations may occur upon the execution of privileged instructions. Processor 202 may also contain bus message logic 2()G to support special bus messagr;s pn - ystem bus 230 in support -of special SENTER operations. In alternate enibodirneits, ire.noy control functions of chipset 240 may be allocated to circuits within the processors, and for multiple processors may be included on a single die.

In these embodiments, special bus messages may also be sent on busses internal to the processors. The use of special bus messages may increase the security or trustability of the system for several reasons. Circuit elements such as processors 202, 212, and 222 or chipset 240 may only issue or respond to such messages if they contain the appropriate logic elements of embodiments of the present disclosure, or their equivalents.

Therefore successful exchange of the special bus messages may help ensure proper system configuration. Special bus messages may also permit activities that should normally be prohibited, such as resetting a platform configuration register 286. The ability of potentially hostile untrusted code to spy on certain bus transactions may be curtailed by allowing special bus messages to be issued only in response to special security instructions.

100181 Additionally, processor 202 may contain secure memory to support secure initialization operations. In one embodiment secure memory 208 may be an internal cache of processor 202, perhaps operating in a special mode.

9] A "chipset" may be defined as a group of circuits and logic that support memoir and input/output (I/O) operations for a connected processor or processors. Individual elements of a chipset may be grouped together on a single chip, a pair of chips, or dispersed among multiple chips, including processors. In the Figure 2 embodiment, chipset 240 may include circuitry and logic to support memory and IIO operations to support processors 202, 212, and 222. In one embodiment, chipset 240 may interface with a number of memos pages 250 through 252 -d a device-access, age table 24g containing control information indicating whether non- processor devices may access the memory pages 250 through 262 Chipset 240 ma:, include device-access logic 247 that may

I

permit or deny direct memory access (DMA) from I/O devices to selected poi Libel i of the memory pages -51) through;262. In some embodiment the device access logic 17 Aid}, coi1Lain all relevant information required to permit or deny such accesses. In other embodiments, the device access logic 247 may access such information held in the device access page table 248. The functions of chipset 24() may further be allocated among one or more physical devices in alternate embodiments. Chipset 240 may additionally include its own bus message logic 242 to support special bus messages on system bus 230 in support of special SENTER operations.

[00203 Chipset:240 may support standard I/O operations on I/O busses such as peripheral component interconnect (PCI), accelerated graphics port (AGP), universal serial bus (USB), low pin count (LPC) bus, or any other kind of I/O bus (not shown). An interface 290 may be used to connect chipset 240 with token 276, containing one or more platform configuration registers (PAR) 286, 294. In one embodiment, interface 290 may be the LPC bus (Low Pin Count (LPC) Interface Specification, Intel Corporation, rev. 1.0, 29 December 1997) modified with the addition of certain security enhancements. One example of such a security enhancement would be a locality confirming message, utilizing a previously-reserved message header and address information targeting a platform configuration register (PCR) 286 within token 276. In one embodiment, token 276 may contain special security features, and in one embodiment may include the trusted platform module (TPM) 281 disclosed in the Trusted Computing Platform Allialce (TCPA) Main Specification, version 1. la, 1 December 2001, issued by the TCPA (available at the time of filing of the present application at vr. trustedpc.com). The interface 290 may provide a data path for various two- way communications between chipset 210 and token 276.

The security bus logic 266 of chipset 240 may include circuits to generate 3n and transmit localitr-conTirm.ig messages to taker 76 rOO21l T,rro so+. iwre components identified in sysei end onment 200 are a Secure Virtual Machine Monitor (SVMM) 282 module and a Secure Znitializatun Authenticated Code (SINIT-AC.) 280 module. The SWIM 282 module may be stored on a system disk or other mass storage, and moved or copied to other locations as net e tsar e In one embodir lent, prior to beginning the secure launch process SV, 282 may He moved or copied to one or more memory pages 250 through 262. Following the secure enter process, a virtual machine environment may be created in which the SVM 282 may operate as the most privileged code within the system, and may be used to permit or deny direct access to certain system resources by the operating system or applications within the created virtual machines.

[00221 Some of the actions required by the secure enter process may be beyond the scope of simple hardware implementations, and may instead advantageously use a software module whose execution can be implicitly tr usted. In one embodiment, these actions may be performed by Secure Initialization (SINIT) code. Such action may include checking critical portions of the system configuration to ensure that is supports the correct instantiation of the secure environment, configuring the device access logic 247 and device access page table 248, and calculate and register the SVMM 282 identity prior to transferring system control to it. Here "register" means placing a trust measurement of SVMM 282 into a register, for example into PCR 286 or into POR 294. When this last action is taken, the trustworthiness of the SVMM 282 may be inspected by a potential system user.

3] The SINIT code may be produced by the manufacturer of the processors or of the chipsets. For this reason, the SINIT code may be 2 trusted to aid in the secure launch of chipset 240. In order to distribute the SINIT code, in one embodiment a well-known cryptographic hash is made of the entire SINIT code, producing a value known as a "digest".

One embodiment produces a 1 60-bit value for the digest. The digest may then be encrypted by a private key held in one embodiment by the - 0 1laruicure Or able rocOssvr, -0 ''-vials a ï,ltal signature. IvThen the oINIT code is 4-u-dled with 'e correspond fig digital signature, the combination may be referred to as SINIT authenticated code (SINIT-AC) 280. Copies of the STNIT-AC 280 may be later validated as discussed bO10l, ,, . _ [0024] Any logical processor may initiate the secure launch process, and may then be referred to as the initiating logical processor (ILP). In the present example processor 202 becomes the ILP, although any of the processors on system bus 230 could become the ILP. Neither memoryresident copy of SINIT-AG 280 nor memory-resident copy of SVMM 282 may be considered trustworthy at this time since, among other reasons, the other processors or the DMA devices may overwrite memory pages 250 - 262.

5] The ILP (processor 202) then executes a privileged instruction.

This privileged instruction may in one embodiment be referred to as a secured enter (SENTER) instruction, and may be supported by SENT:ER logic 204. Execution of the SENTER instruction may cause the ILP (processor 202) to issue special bus messages on system bus 230. In other embodiments, other privileged instructions may be executed.

6] After issuing the special bus message, the ILP (processor 202) may check to see when and if the other processors, which may be referred to as responding logical processors (RLPs) are ready to enter secure operations. When the RLPs are ready, the ILP (processor 202) may move both a copy of SINIT-AC 280 and key 284 into secure memory for the purpose of authenticating and subsequently executing the SINIT code included in SINIT-AC 280. In one embodiment, this secure memory may be an internal cache of the {LP (processor 202), perhaps operating in a special mode. Key 284 represents the public. key corresponding to the private key used to encrypt the digital signature included in the SINIT-AC 280 module, and is used to verify the digital signature and thereby authenticate the SINIT code. In one embodiment, key 284 may already b_ stored in the processor, perhaps as part of the REFUTER logic 204. In 3rJ another emoodin,ent' key QS,f+ may be stored in a read-onIy key register 244 of chipset:240j which is read by the ILP. In yet another embodiment, either the processor or the chipset's key register 244 may actually hold a cryptographic digest of key 284, where key 284 itself is included in the SINIT-AC 280 module. In this last embodiment, the ILP reads the digest from key register 244, caiculate;. &1 equivalent cryptographic hash over the key 284 embedded in SIN IT- 280, and compares the two digests to ensure the supplied key 284 is indeed trusted.

[00271 A copy of SINIT-AC and a copy of a public key may then exist within secure memory. The ILP may now validate the copy of SINIT-AC by decrypting the digital signature included in the copy of the SINIT-AC using the copy of a public key. This decryption produces an original copy of a cryptographic hash's digest. If a newly-calculated digest matches this original digest then the copy of SINIT-AC and its included SINIT code may be considered trustable.

8] The ILP may now register the unique identity of the SINIT-AC module by writing the SINIT-AC module's cryptographic digest value to a platform configuration register 286 in the security token 276, as outlined below. The ILP's execution of its SENTER instruction may now terminate oy transferring execution control to the trusted copy of the SINIT code held within the ILP's secure memory. The trusted SINIT code may then perform its system test and configuration actions and may register the memory-resident copy of SV\IIvI, in accordance with the definition of 'registe, " above.

1002gl Registration of the memoy-resident copy of SVMM may be performed in several manners. In one embodiment, the SENTER instruction running on the ILP writes the calculated digest of SINIT-AC: into PCR 286 within the security token 276. Subsequently, the trusted SINIT code may Or. rite We calculated West of the memory-resident SVMM to the same PCR 286 or another PCR 294 within the security token 276.

If the SVMM digest is written to the same PCR 286, the security token 276 hashes the original contents OSIRIS digest) with the new value (SVMM digest) and writes the result back into 'he POR 286. In embodiments Ad rrhel-e the. s. {init3alizil a, ite to PUP 286 is limited to the SENTER ïstrletior., the Desolating digest may be used as a root OI trust for the system.

[00301 Once the trusted SINIT code has completed its execution, and has registered the identity of the SVMM in a PCR, Iliad MINI' ' code may transfer IL' execution control to the SVMM. In a typical cbodm.en!t, i1-first SVMM instructions executed by the ILP may represent a self initialization routine for the SVMM. The ILP may in one embodiment cause each of the RLPs to join in operations under the supervision of the nowexecuting copy of SVMM. From this point onwards, the overall system is operating in trusted mode as outlined in the discussion of Figure 1 above.

[00311 Referring now to Figure 3, a detailed diagram of the security token 275 of the system of Figure 2 is shown, according to one embodiment of the present invention. Token 276 may include a TPM 278 containing several prior-art PCRs 232, 234, 236, 238. These prior-art PCRs may be reset only at a general system reset event. The present TPM 7.73 may contain 16 or more prior-art general-purpose PCRs.

2] Additionally, in one embodiment token 276 may include PCRs 286, 294 of the present invention. Each PCR 286, 294 may be associated with flags indicating the behavior of the PCR under differing conditions.

For example, PCR 286 has associated with it a reset flag 2g8 and a. modify flag 292, and PCR 294 has associated with it a reset flag 296 and a modify flag 998. When reset flag 288 has the logical value tme, PCR 286 may be reset under the command of a localily-confirming message arriving on the interface 290. When modify flag 292 has the logical value me, PER 286 may hate its contents modified under the command of a locality- confrrning message arriving on the interface 290. In one embodiment, an encrypted digest of SINIT-AC 280 is intended to be written into PCR 286 and an encrypted digest of SVMM 282 is intended to he mitten into PCR 294. These digests may be exhibited upon request as part of an attestation process that may demonstrate to a local or remote 3G user rrlat syste.rl en;iro-.rrlent Fort AS Gperatirlg in a secure or rousted manner.

10033] In another embodiment, digests of SINIT-AC 280 and of SVMM 282 may be written into a single PCR' such as PCR 286. In this I, embodiment, first the digest of SINIT-AC is written into PCR 286. Then the contents of E,C;' 286 are cryptologically combined with a digest of SVMM 282, and the reu!tit g combirir if. ligest written into PC:R 286. In one embodiment, circuitry within token 276, configured to support PCR 286, may take the value of an incoming write request over interface 290, cryptologically combine this value with the current value within PCR 286, and then place the resulting new value within PCR 286. This process may be referred to as an "extend" operation. The value of the incoming write request may be said to be "extended onto" the current value within PCR 286. This extended value within PCR 286, representing a combined digest, may then be exhibited upon request as part of an attestation process that may demonstrate to a local or remote user that system environment 200 is operating in a secure or trusted manner.

4] Reset flags 288, 296 and modify flags 292, 298 may be set to logic true values at the time of manufacture of token 276. This will permit the resetting and content modification of PCR 086, 294 upon receipt of a locality-confirming bus message on interface 290. In other embodiments, reset flags 288, 296 and modify flags 292, 298 may have their values changed between true and false depending upon specific security actions taken under the control of TPM 278.

[00351 In the Figure 3 embodiment, exemplar additional PCRs 201, 203, and 205 of an embodiment are shown. In alternate embodiments fewer or additional PCRs in accordance with an embodiment of the present invention may be utilized. Additional PORs such as PCRs 201, 203 and 205 may be utilized to store security-related information, such as digests of code, in other embodiments. Any additional PCRs, such as exemplary PCRs 201, 203, and 205, may have the associated reset flags 2073 209, and 211, respectively. and the associated modify flags 213, 215, and 2175 respectively.

GIG 0036] T he Pairs 236. 294 may He reset Or ir.dified at t rues other +an general SYSLV5mI resets -Wher1 =1C SYStC:r1 enWVirnrneI1t 900 CaUS-VS localitr confirming messages to be sent from chipset 240 to token 276. In one embodiment, the locality-confirming messages may be generated by security bus logic 266 of chipset 240 in response to the bus message logic 242 ret eiving a SENTER special bus message. over system bus 230. The E;TER special bus message in turn may result from 'he c=>ecut.i. .- self a SENTER instruction in a processor. Such a SENTER instruction may be executed days, weeks, or months subsequent to any general system reset event. Details of the SENTER process, transferring system operation from insecure operations to secure operations, are described below in connection with Figures 3 through 7.

[00371 In the Figure 3 embodiment, token 276 is shown in an exemplary trusted or secure personal computer environment.

Specifically, token 276 is shown connected with chipset 240 via an interface 290. In alternate embodiments, token 276 of an embodiment of the present invention may be used in other system environments.

Examples of such environments may include a data server environment, a cellular or other form of mobile telephone, a mobile data port, an automotive system, a cable or satellite television system, or a personal digital assistant (PDA). These examples should not be construed as limiting, as there are many other so stem environments that may utilize a token of a present embodiment. An interface 290 or alternate equivalent interface may connect the other embodiment token to circuitry within one of the above exemplary system environments, wherein chipset 240 may be a portion of, for example, an integrated cellular telephone controller or a PDA controller. These embodiments are in accordance with the definition of "chipset" included in the discussion of Figure 2 above.

8] Referring now to Figure 4, one embodiment of a microprocessor system 400 adapted to support the secured software environment of Figure 1 is shown. CPU A 410, CPU B 414, C:PU C 418, and CPU D 422 may be similar to the processors of Figure 1, but may be configured with additional microcode or logic circuitry to support the execution of special hi instructioris. In one e. Ab^.dirnent, this addition >1 microcode or logic circuitry moor be We STINTER lo,.c Q4 of Figure 2. These special instructions may support the issuance of special bus messages on system bus 420. In one embodiment, the issuance of special bus messages may s be supported by circuitry such as the bus message logic 206 of Figure 2.

Similarly ehlpset.430 may be similar to chipset: 130 but relay support talc above mentioned sF ecial cycle. . n system bus 420. Additionally chipset 430 may possess additional page protection circuitry for protecting page tables within physical memory 434. In one embodiment, the page protection circuitry may be the device access logic 247 of Figure 2.

9] In one embodiment, chipset 430 interfaces an additional data bus called a modified low pin count (LPC) bus 450 through a LPC bus logic (LPC-BL) 452. Modified LPC bus 450 may be used to connect chipset 430 with a security token 454. Token 454 may in one embodiment include the trusted platform module (TPM) 460 envisioned by the TCPA. In one embodiment, token 454 mar include SINIT PCR 470 and SVMM PCR 480. Each PC:R 470, 48Q may be associated with flags indicating the behavior of the PCR under differing conditions. For example, SINIT PCR 470 has associated with It a reset flag in and a modify flag 474, and SWIM PCR 480 has associated with it a reset flag 482 and a modify flag 484. When reset flag 472 has the logical value true, SINIT PCR 470 may be reset under the command of a locality con5rming message arriving on the modified LPC bus 450. When modify flag 474 has the logical value true, SINIT PCR 470 may have its contents modified under the command of a locality-confirming message arriving on the modified LPC bus 450. In one embodiment, an encrypted digest of SINIT-AC is intended to be written into SINIT PCR 470 and an encrypted digest of SVMM is intended to be written into SVMM PCR 480. These digests may be exhibited upon request as part of an attestation process that may demonstrate to a local or remote user that microprocessor system 400 is operating in a secure or trusted manner.

F004C}] In an alternate embodiment, digests of SINIT-AC and of SVMM may be written into a single PCR, such as SINIT PCR 470. In this JO errlbodile.lt' fast the digest of SINJ''=-r is written into STNTT PCR 470.

Then the contents of SINIT PCR +70 a, e cr,,tologically combined -with adigest of SVMM, and the resulting combined digest written into SINIT PCR 470. In one embodiment, circuit within token 454, configured to support SINIT PCR 470, may take the value of an incoming write request viler modified PC bus 450, cryptoiog.cally combine this value wills the current value within SINIT PCR 470, and then replace the be Faulting new value within SINIT PCR 470. This combined digest may then be exnibted upon request as part of an attestation process that may demonstrate to a local or remote user that microprocessor system 400 is operating in a secure or trusted manner.

1] Reset flags 472, 482 and modify Hags 474, 484 may be set to logic true values at the time of manufacture of token 454. This will lO permit the resetting and content modification of SINIT PCR 470 and SVMM PCR 4&0 upon receipt of a locality-confirming bus message on modified LPC bus 450. In other embodiments, reset flags 472, 482 and modify flags 474, 484 may have their values changed between true and false depending upon specific security actions taken within microprocessor system 400, such as a SL;N1K or other privileged instruction execution.

2] In order to use a SVMM 350 in a microprocessor system such as microprocessor system 400, several actions may need to be taken. One action may be that the system configuration should be tested for trustworthiness, both in terms of hardware configuration, the SVMM 350 itself, and any software that loads and starts the SVMM 350. Another action may be to register the SVMM 350 identity and transfer system control to it. When this last action is talren the trustworthiness of the SVMM 35Q may be inspected by a potential system user.

3] In one embodiment, a copy of SINIT-AC may be stored in the fixed media 444 for use when the microprocessor system 400 needs to enter secure operations. When logical processor, for example physical processor CPU 414' desires to initialize system wide secure operations using the SVMM 35O, it may load a copy of SINIT-AC into memory 434 to 3, foray a an_ loper esident copy of SINIT-AC. Arty- logical p, ocessor starting -up secure operations in this.-ner may be referred to as an initiating logical processor (ILP). In the present example CPU B 414 becomes the ILP. OPU 414 as ILP may then load a copy of SVMM into memory to form a memoryresident copy of SVMM. This copy of SVMM may be on nun-cortiguous pages of Emory, but the chipset 430 will main a page table f or it. Neiicr SINIT-AC nor SVMM may be considered trustworthy at this time since, among other reasons, the other processors or the DMA devices may overwrite memory 434.

10044] The ILP then may execute a special or privileged instruction implemented in microcode or other processor logic, such as SENTER.

Execution of the SENTER instruction may cause the ILP to issue special bus messages on system bus 420, and then wait considerable time intervals for subsequent system actions. In other embodiments, other privileged instructions may be executed.

[004li] After issuing the special bus message, the ILP (CPU B 414) checks to see when and if all the RLPs have properly responded. When the RLPs are ready to enter secure operations, the ILP may move both the memoryresident copy of SINIT-AC and a cryptographic public key of chipset 430 into secure memory. In one embodiment, this secure memory may be the internal cache of the ILP, CPU B 414 Copy of SINIT-AC and copy of public key may then exist within internal cache. The ILP may now validate the cache-resident copy of SINIT-AC by decrypting the digital signature of this copy of the SINIT-AC using the cache-resident copy of public key. This decryption produces an original copy of a cryptographic hash's redigests. If a newly-calculated "digest" matches this original "digest" Men the cache-resident copy of SINIT-AC may be considered

trustable.

? roods] At this point during the execution of the SENTER instruction, a pair of locality-confrming messages may be generated by LPC-BL 452.

This allows the resetting of SINIT PCR 470 and the writing of the SINIT digest illtO SrNIT PCR 470.

[00471 The ILP may- now issue avower special bus message, via system 7.' Bus h20 signaling We Plaiting Pulp s icon h 4i u MU C 41, CrU D 42) and chipset 430 that secured operations are going iQ b_ i,,+.iaed. The trusted cache-resident copy of SINIT-AC may then test and validate the copy of SVMM residing in physical memory 434. In one embodiment, SINIT-AC may read the page table entries for the copy of SVMM located in memory 434. SINIT-AC nits- Hun command chipsui: 430 to prevent OMA access from I/O devices to those pace table entries. -Validation and subsequent registration of the memo-resident copy of SEMI may be performed in several manners. Again during this portion of the execution of the SENTER instruction, another pair of locality-confirming messages may be generated by LPC-BL 452. This allows the resetting of SVMM PCR 480 and the writing of the SVMM digest into S-\rvilvI PCR 480.

8] At this point the memory-resident copy of SVMM may begin execution, at the ending of execution of the SENTER instruction. The ILP may in one embodiment cause each of the RLPs to join in operations under the supervision of the now-executing memory-resident copy of SVMM. From this point onwards the overall system is operating in trusted mode as outlined in the discussion of Figure 1 above.

10049] Referring now to Figure 5, a flowchart showing reseLung of platform configuration registers is shown, according to one embodiment of the present invention. The method shown in Figure 5 may be used for the secure or trusted computer environments of Figure 1 and Figure 3. The method may also be used in other environments, such as a cellular or other form of mobile telephone, automobile or other security systems, or in a digital or satellite television or other media exchange system. In these latter embodiments, circuits within the named equipment may serve as the equivalent of the chipset 240 or chipset 430 for the purpose of sending locality-confirming messages to a security token.

[00501 The Figure 5 embodiment starts in block 520, where a first locality-confimning message is sent over an interface, addressed to a first PCR. Data within the first locaity-confirrning message indicates a reset is to be performed. and in block 50 the reset flag of the first PCR is checked to see if resets may be allowed. If so, then the first PCR is reset.

u Then -rat block 5ii= & second loci-con Prolog lllessags Its sent, addressed to the F; st PCR Apia wrhiT the second locality-confir,lling message indicates a digest (or other data) write is to be performed, and in block 550 the modify flag of the first PCR is checked to see if _.

modifications to the value contained within the first PCR may be allowed.

if so' then the first PCR is written with tile digest con-. within the second}Mali confirming message.

[00513 In block 56Q, a third locality-confirming message may men De sent that is addressed to a second PCR. Data within the third localityconfirming message indicates a reset is to be performed, and in block 570 the reset flag of the second PCR is checked to see if resets may be allowed If so, then the second PCR is reset. Then in block 580 a fourth iocaiity- confirming message is sent, addressed to the second PCR. Data within the fourth locality-confirming message indicates a digest (or other data) write is to be performed, and in block 590 the modify flag of the second PCR is checked to see if modifications to the value contained within the second PCR may be allowed. If so, then the second PCR is written with the digest contained within the fourth locality-confirming message.

2] Referring now to Figure 6, a flowchart showing resetting or platform configuration registers is shown, according to another embodiment of the present invention. The method of Figure 6 may be used in various environments as listed above in connection with the method of Figure 5. The Figure 6 embodiment starts in block 620, where a first locality-confirming message is sent over an interface, addressed to a first PCR. Data within the first locality-confirming message indicates a reset is to be performed, and in block 630 the reset flag of the first PCR is checked to see if resets may be allowed. If so, then the first PCR is reset.

Then in block 640 second localit;y-confirrning message is sent, addressed to the first PCR. Data within the second locality-confirming message indicates a digest (or other data) write is to be performed, and in block 650 the modify flag of the first PCR is checked to see if m-modifications to the value contained within the first PC:R may be allowed.

if SOj then the first PCR is written with the digest contained within the second 1GCa16' Ly -CC^.li-mir 0 m essa get iOo53i Then is. Foci 66C a -,. ird lo^alify-cor,frI.irg message is sent.

addressed again to the first POR. Data within the third locality confirrning message indicates a digest (or other data) write is to be performed, and in block 670 the modify Bag of the first PCR is checked to see if modicaf ions tC Ace value confined wit; the first PC R may sill be allowed. If so, then block 680 Me token cryptographically hashes the digest contained within the Gird Iocality-confiming message onto the existing contents of the first PCR. Then in block 690 Me resulting combined digest rrmy be written into like first POR This process may be the extend process as described above m connection wife Figure 2.

[00543 the foregoing specification, the invention has been described with reference to specific e:EempIar embodiments Hereof. It will, however, be evident Mat various modcabo:as and Ranges may be made thereto without departing from the broader scope of tile nvendon as set form in the appended claims. The Cation and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Claims (16)

- CLAIMS

1. An apparatus comprising: a semiconductor chip having a first register to store a first digest; and a first flag coupled to said first register to indicate whether to permit said first register to reset responsive to a locality confirming message originating on another semiconductor chip.

2. The apparatus of claim 1, wherein said first flag may be set at manufacture.

3. The apparatus of claim 1 or 2, further comprising a second flag coupled to said first register to indicate whether to permit contents of said first register to change responsive to said locality confirming message.

4. The apparatus of any preceding claim, further comprising a second register to store a second digest.

2) S. The apparatus of claim 4, further comprising a third flag coupled to said second register to indicate whether to permit said second register to reset responsive to said locality confirming message.

6. The apparatus of claim 5, further comprising a fourth flag coupled to said second register to indicate whether to permit contents of said second register to change responsive to said locality confirming message.

7. The apparatus of any preceding claim' further comprising a circuitry supporting said first register responsive to a Nitrite instruction to extend said first digest 3() with a seconds digest.

8. A chipset, compria rig bus message logy to receive a special bus message from a processor; and security bus logic to send a locality confirming message responsive to said special bus message.

9. T he chipset of claim 8, when said special bus message is issued during the period of execution of a secured enter instruction.

10. The chipset of claim 8 or 9, wherein said locality confirming message includes instructions to reset a register.

11. The chipset of claim 8, 9 or 10, wherein locality confirming message includes instructions to modify the contents of a register.

12. An apparatus, comprising: a first register to store a first digest; and a first flag coupled to said first register to indicate whether to permit contents of said first register to be modified responsive to a locality confirming message.

13. The apparatus of claim 12, wherein said first flag may be set at manufacture.

14. The apparatus of claim 12 or 13, further comprising a second flag coupled to said first register to indicate whether to permit said first register to reset responsive to said locality confirming message.

15. A method, comprising: transmitting a first locality con.r,.rm..inD message on a 7'rSt'^,'JS; and 0 deterrninirg whether to nnodiy contents of a first register responsively to said first locality confirming message. . .

16. The method of claim 15, further comprising determining whether to modify contents of said first register responsive to a first flag.

A A flu f in