Windows Vista BitLocker Client Platform Requirementsdownload.microsoft.com/download/a/f/7/af7777e5-7dcd-… · Web views-crtm 12.15.2 13.15.2 The BIOS must always boot to the OS

Windows Vista BitLocker Client Platform RequirementsMay 16, 2006

AbstractThis document describes the functional requirements that components on a Microsoft® Windows Vista™-capable Host Platform must meet to enable the Microsoft BitLocker™ feature of Windows Vista to run on that platform and provide a good user experience.

To contact the BitLocker Drive Encryption team, send e-mail to [email protected] .

This information applies for the Windows Vista operating system.

The current version of this paper is maintained on the Web at: http://www.microsoft.com/whdc/system/platform/hwsecurity/BitLockerReq.mspx

Contents1. Introduction..........................................................................................................................4

1.1 Conventions Used in this Document.............................................................................41.2 How to Use this Document............................................................................................4

2. BitLocker BIOS Functional Requirements...........................................................................42.1 BitLocker TCG BIOS Interface Requirements...............................................................4

BIOS 85..........................................................................................................................5BIOS 86.12 86a.12 86b.12 86c.12 88.12.1 88a.12.2.....................................................5BIOS 89.12.3..................................................................................................................6BIOS 92.12.5..................................................................................................................6BIOS 96.12.7..................................................................................................................7BIOS 97.12.8..................................................................................................................8BIOS 101.12.12..............................................................................................................9BIOS 131a.13 37.3.2.3.1................................................................................................9

2.2 BitLocker General Requirements for Integrity Measurement and PCR Usage...........10All Pre-Operating System Measurement Agents 27b.3.2.2..........................................10Ensure No Event Log Entries Reference PCR [8 – 15]................................................10All Pre-Operating System Measurement Agents 74.10.3.............................................10All Pre-Operating System Measurement Agents 101...................................................11All Pre-Operating System Measurement Agents 72a.10.1 72b.10.1...........................11All Pre-Operating System Measurement Agents 73.10.2.1..........................................11Pre-Operating System Measurement Agents 75.10.4.2...............................................12All Pre-Operating System Measurement Agents 75a.10.4.3........................................12

2.3 BitLocker PCR [4] and PCR [5] Usage Requirements................................................12BIOS 77.8.1..................................................................................................................12

2.5 BitLocker Host Platform Power State Transition Requirements..................................14BIOS 77j.8.3.1..............................................................................................................14S-CRTM 79.8.3.1.3 27a.3.2.2......................................................................................14S-CRTM 80.8.3.1.4 80.8.3.1.5 27a.3.2.2.....................................................................15S-CRTM 82.8.3.1.6 27a.3.2.2......................................................................................15

2.6 BitLocker PCR [0] and PCR [1] Usage Requirements................................................15S-CRTM 32.3.2.3.1......................................................................................................15All Pre-Operating System Measurement Agents that Use PCR [0] 33.3.2.3.1.............16BIOS POST 34.3.2.3.1.................................................................................................16BIOS 1c........................................................................................................................16

http://www.microsoft.com/whdc/system/platform/hwsecurity/BitLockerReq.mspx

mailto:[email protected]

Windows Vista BitLocker Client Platform Requirements - 2

BIOS 2.9.......................................................................................................................17BIOS POST 35.3.2.3.1.................................................................................................17BIOS POST 35a.3.2.3.1...............................................................................................17BIOS 36c.3.2.3.1..........................................................................................................17All Pre-Operating System Measurement Agents that Use PCR [0] 36b.3.2.3.1...........18BIOS 36a.3.2.3.1..........................................................................................................18BIOS 48.3.2.3.2............................................................................................................18

2.7 BitLocker PCR [2] Usage Requirements.....................................................................18BIOS 53.3.2.3.3 54.3.2.3.3 51.3.2.3.3..........................................................................19Option ROM Code 52.3.2.3.3 55.3.2.3.3......................................................................19Applications that Modify Option ROM Code 50.3.2.3.3................................................19

3. BitLocker TPM Integration Requirements..........................................................................203.1 TPM Requirements.....................................................................................................20

TPM 1a TPM 1b...........................................................................................................213.2 BitLocker One-to-One Binding Requirements.............................................................21

Host Platform Construction 18e...................................................................................213.3 BitLocker Locality Requirements.................................................................................21

Host Platform Construction 20.3.2.1............................................................................22BIOS 102.3.2.1.4..........................................................................................................22

3.4 BitLocker Static CRTM and Embedded Firmware Requirements...............................22S-CRTM 22d.3.2.1.2....................................................................................................22S-CRTM update process 22a.3.2.1.2 132.1.2.2 22c.3.2.1.2 134.3.2.1.2 135.6.2........22BIOS Recovery Mode process 135.6.1........................................................................23

3.5 BitLocker Host Platform Reset Requirements.............................................................23Host Platform Construction 17.1.2.7.2 18a.1.2.7.3 18b.1.2.7.3 BIOS 1d.....................24S-CRTM 23.3.2.1.1......................................................................................................24BIOS 18c.1.2.8.............................................................................................................24

3.7 BitLocker Command Method Physical Presence Indicator Requirements..................25BIOS 9a........................................................................................................................25Host Platform Construction 7.1.2.3..............................................................................25S-CRTM 12.15.2 13.15.2.............................................................................................26

4. BitLocker System Partition Requirements.........................................................................26OEM or VAR 1g............................................................................................................26OEM or VAR 1h............................................................................................................26

5. BitLocker Requirements for System Firmware Support of USB Flash Drive.....................26BIOS 1j.........................................................................................................................26

May 16, 2006© 2006 Microsoft Corporation. All rights reserved.


Disclaimer

This is a preliminary document and may be changed substantially prior to final commercial release of thesoftware described herein.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, email address, logo, person, place or event is intended or should be inferred.

© 2006 Microsoft Corporation. All rights reserved.

Microsoft, BitLocker, Windows, Windows Vista, and the Windows Logo are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.



1. IntroductionThis document lists the requirements that the different components on a Microsoft® Windows Vista™-capable PC Client Host Platform must meet for that Host Platform to work functionally with Microsoft BitLocker™ Drive Encryption.

1.1 Conventions Used in this DocumentIn this document the label “v1.21 TCG Specification” refers to the v1.21 TCG PC Client Specific Implementation Specification for Conventional BIOS, available to TCG member companies at https://www.trustedcomputinggroup.org/apps/org/workgroup/pcclientwg/.

1.2 How to Use this DocumentThis document is a list of the requirements that a Windows Vista-capable PC Client Host Platform must meet for BitLocker compatibility.

Each requirement contains four pieces of information: The requirement itself; in some cases, this is a set of closely related requirements. The Host Platform entity that must meet this requirement; for example, the BIOS, Option ROM code, the TPM, or, in the most general case, Host Platform construction. A unique ID for the requirement; in some cases, this is a set of unique IDs. This ID serves two purposes: (1) it is the same ID associated with this requirement in previous releases of this document, so tracking of a requirement from release to release is possible and (2) all digits in the ID to the right of the first digit in the ID refer to the TCG Specification section number from which this BitLocker requirement is derived (for example, if an ID = 88.12.1, the unique tracking ID for this BitLocker requirement is 88, and you can refer to Section 12.1 of the TCG Specification to get more detailed information about that requirement). A suggested set of verification metrics; these are offered primarily as a clarification of the requirement itself but may be used as a starting point by Host Platform manufacturers to validate that their Host Platform meets the requirement. More extensive verification than is listed in this document should be performed.

Developers of the different components that must meet BitLocker requirements can use the targeted checklists in this document to determine when they are done with development of their component for BitLocker.

2. BitLocker BIOS Functional RequirementsThis section lists the requirements for the BIOS and other pre-operating system measurement agents.

2.1 BitLocker TCG BIOS Interface RequirementsTo use the TPM in the pre-operating system environment, BitLocker code that runs in the pre-operating system environment calls the TCG INT 1Ah interface that is exported by the BIOS. This section lists the BitLocker TCG BIOS Interface requirements.


https://www.trustedcomputinggroup.org/apps/org/workgroup/pcclientwg/


BIOS 85The BIOS must expose a TCG INT 1Ah, sub-function BBh interface to pre-operating system environment applications.

BitLocker code, running in the pre-operating system environment, uses the INT 1Ah, sub-function BBh interface to access the TPM. See Section 12 of the TCG Specification for a full definition of the INT 1Ah, sub-function BBh interface which, in the rest of this document is simply referred to as the “TCG BIOS interface”

Suggested verification metrics: TCG_StatusCheck function must return expected values. Individual functions must return expected values. Unsupported functions must return TCG_PC_UNSUPPORTED.

BIOS 86.1286a.1286b.1286c.1288.12.188a.12.2On exit from the TCG BIOS Interface:

The A20 gate state must be preserved. The processor’s memory mode must be in Real Mode with 64K segment limits and must not be in virtual 8086 mode. SS, ESP and EBP must be preserved. EAX must contain the return code (described in section 12.3) CF must be 0 (cleared) if function returned successfully, or 1 (set) if function returned an error. An unsupported function must still follow these requirements and return EAX = TCG_PC_UNSUPPORTED with CF = 1.

On entry into the TCG BIOS Interface: The caller may have the A20 gate either enabled or disabled The caller may be assumed to always be in Real Mode with 64K segment limits

Suggested verification metrics: Call presence-check function with A20 disabled. Ensure function returns correct parameters and A20 is still disabled. Ensure SS, ESP and EBP registers are preserved. Ensure Real Mode is preserved. Repeat test with A20 enabled. Ensure function returns correct parameters and A20 is still enabled. Repeat tests 1 and 2 with each supported function. Repeat tests 1 and 2 with each unsupported function, ensuring A20, SS, SP, BP and Real Mode are still preserved. Perform tests that return successful codes and ensure EAX=TCG_PC_OK with CF=0. Perform tests that return error codes and ensure EAX!=TCG_PC_OK with CF=1.



BIOS 89.12.3All TCG BIOS Interface functions must return one or more of the following error codes (into EAX):

TCG_PC_OK: The function returned success. TCG_PC_TPMERROR: The pre-operating system TPM driver returned an error; see Table 24, in Section 13 of the TCG Specification, for a list of the pre-operating system TPM driver error codes. Bits [15:0] contain the value “TCG_PC_TPM_ERROR” and bits [31:16] contain the TPM driver error code. TCG_PC_LOGOVERFLOW: Insufficient memory to create Event Log entry. TCG_PC_UNSUPPORTED: BIOS does not support the called INT 1Ah function. TCG_PC_INVALID_PARAM: Caller passed an invalid parameter to a supported INT 1Ah function.

Suggested verification metrics: Test each supported function with functioning hardware and ensure EAX returns

TCG_PC_OK. Test each unsupported function and ensure EAX returns

TCG_PC_UNSUPPORTED. Test supported functions that interact with a TPM, with TPM non-functioning

and ensure EAX returns TCG_PC_TPMERROR in lower 16 bits with correct error in bits [31:16].

Test supported functions that write to the TCG Log, with a full log, and ensure those functions return TCG_PC_LOGOVERFLOW.

Perform selection of invalid parameter tests and ensure TCG_PC_INVALID_PARAM is returned.

BIOS 92.12.5The TCG BIOS Interface must implement the TCG_StatusCheck function.

The input parameters must be interpreted as follows: AX = BB00h. All other registers are ignored.

The TCG_StatusCheck function has the following return requirements: EAX = 0h or EAX [31:16] = TCG_INTERFACE_SHUTDOWN and EAX [15:0] = TCG_PC_TPM_ERROR if the interface has been shut down. EBX = 41504354h. ECX = version (described below). EDX = feature flags (currently 0). ESI = 32-bit physical address of the TCG Event log. This must not be zero. EDI = 32-bit physical address of the first byte of the last event of the log. CF = 0. CS, DS, ES, SS, ESP and EBP must be preserved.



The version (ECX) must indicate a TPM version of at least 1.2. The fields are as follows:

Bits 7:0(CL)=TCG BIOS Minor Version (02h for v1.2). Bits 15:8(CH)=TCG BIOS Major Version (01h for v1.0). Bits 23:16=Errata Level (00h for v1.2, 01h for v1.21). Bits 31:24=Reserved, must be 0.

A BIOS that wants to explicitly indicate that the TCG BIOS Interface is not supported should ensure that the following return conditions are met:

EAX is non-zero. EBX is not explicitly set to 41504354h. CF is set.

Suggested verification metrics: Call function with EAX = 1234BB00h, EBX = AABBCCDDh, ECX = FFFF0000h and verify on return registers are as expected. Verify ECX [15:0] returns a version >= 0x0102h (according to current TCG Specification version). Verify ECX [23:16] returns correct errata version, 0 or 1 if ECX [15:0] == 0x0102h. Verify ECX [23:16] is not FFh. Verify ECX [31:24] returns 0h. Verify function returns correct EAX value after interface has been shut down.

BIOS 96.12.7The TCG INT 1Ah interface must implement the TCG_PassThroughToTPM function.

The input registers must be interpreted as follows: AX = BB02h. ES:DI = segment:offset of input parameter block. Physical location is 16*ES+DI. DS:SI = segment:offset of output parameter block. Physical location is 16*DS+SI. EBX = 41504354h. ECX = 0h. EDX = 0h.

The Input Parameter Block must be interpreted as follows: +00h (WORD): IPBLength = 8h + Length of input data. +02h (WORD): Reserved = 0h. +04h (WORD): OPBMaxLength = Length of output parameter block buffer, and must be at least 4 bytes. A buffer length up to 0x800 bytes may be provided by BitLocker Drive Encryption and must be supported. +06h (WORD): Reserved = 0h. +08h (BYTE array): TPMOperandIn - Input data.



The TCG_PassThroughToTPM must either pass TPMOperandIn to the TPM (using IPBLength-8h to determine the length of the operand to pass to the TPM), or must return an error to the caller.

If TCG_PassThroughToTPM returns an error to the caller, it must fill the Output Parameter Block as follows:

+00h (WORD): 04h +02h (WORD): 00h

If TCG_PassThroughToTPM obtains a result from the TPM that is bigger then the buffer can hold, it must return as much information as possible to the caller, and return a successful error code. In this case, the Output Parameter Block would be:

+00h (WORD): OPBMaxLength. +02h (WORD): 00h. +04h (BYTE array): Truncated return data OPBMaxLength-04h bytes.

If TCG_PassThroughToTPM obtains a result from the TPM, even an error, the function must return the TPM result in the buffer, and return a successful error code. In this case, the Output Parameter Block would be:

+00h (WORD): OPBLength (Length of data returned by the TPM + 04h bytes). +02h (WORD): 00h. +04h (BYTE array): Data returned by the TPM, which is 04h bytes less then the value specified by OPBLength.

On return, all registers must be preserved except: EAX = Status. CF = 1 on error, 0 on success.

Suggested verification metric: TCG_PassThroughToTPM to seal a 0x400-byte block of data; then call TCG_PassThroughToTPM to unseal that same data.

BIOS 97.12.8The TCG BIOS Interface must implement the TCG_ShutdownPreBootInterface function.

The input registers must be interpreted as follows: AX = BB03h EBX = 41504354h

On return, all registers must be preserved except: EAX = Status CF = 1 on error, 0 on success

After this function has executed, all supported TCG BIOS Interface functions must return

EAX [31:16] = TCG_INTERFACE_SHUTDOWN EAX [15:0] = TCG_PC_TPM_ERROR



Suggested verification metrics: Verify this function succeeds unless interface has already been shut down. Verify all supported functions return required error after this function has been called.

BIOS 101.12.12The TCG BIOS Interface must implement the TCG_CompactHashLogExtendEvent function.

The input registers must be interpreted as follows: AX = BB07h. ES:DI = segment:offset of buffer to be hashed. Physical location of buffer starts at 16*ES+DI. ECX = length of buffer to be hashed. Lengths of 0 through 32K must be supported. EDX = PCR number that that hash must be extended into. ESI = an informative value that must be stored in the event log. EBX = 41504354h. ECX = 0h. EDX = 0h.

The hash of the data must be calculated. The hash must be extended to the specified PCR. An event must be logged of type EV_COMPACT_HASH, containing the informative value specified by ESI and the PCR specified by EDX. A failure to extend the specified PCR with the specified hash in this function WILL affect security and must (if a failure cannot be avoided) result in the TPM being put into error mode before the function returns to the caller.

The hashing function must complete and return quickly; it is allowed and recommended that the hashing function be done in software. The buffer to be hashed that is supplied by BitLocker Drive Encryption may be up to 32K bytes in length and that must be supported.

On return, all registers must be preserved except: EAX = Status. If this value is not TCG_PC_OK then the TPM must be placed into a state where no values can be unsealed. CF = 1 on error, 0 on success.

BIOS 131a.1337.3.2.3.1If the BIOS pre-operating system TPM driver running under the TCG BIOS Interface fails to communicate with the TPM to extend PCRs, then the BIOS must ensure that the TPM hardware cannot be used to unseal any values during the current boot cycle. The BIOS must do one of the following:

Disable the connection to the TPM for the current boot cycle. Take action to prevent the Host Platform from loading any IPL or the operating system. Perform a Host Platform reset.



Force transfer of control of the Host Platform to a Manufacturer Approved Environment (MAE).

If communication with the TPM is possible, but other failure or environmental conditions occur that prevents a hash from being calculated, the BIOS may cap all PCR [0 – 7] with 01h. This ensures that the TPM is never left in a state where PCRs contain a subset of necessary measurements required to unseal a secret.

Suggested verification metrics: Call this function to extend a length of zero bytes. Call this function to extend a length of 32 bytes. Call this function to extend a length of 32K bytes. Call this function to extend a length of 64K bytes if supported. Call this function to extend a length of 2M bytes if supported.

2.2 BitLocker General Requirements for Integrity Measurement and PCR UsageBitLocker requires a small set of integrity measurements and PCR usage requirements that apply to all the pre-operating system environment measurement agents: S-CRTM, BIOS POST, Option ROM code, applications that modify Option ROM code, and IPL code.

All Pre-Operating System Measurement Agents 27b.3.2.2All pre-operating system measurement agents, including the BIOS, must only make measurements into PCR [0 - 7].

PCR [8 – 15] must not be used by pre-operating system measurement agents; PCR [8 – 15] are reserved for the operating system environment.

Suggested verification metric: Ensure each PCR [8 - 15] contain the constant value 0 (20 bytes of 0).

Ensure No Event Log Entries Reference PCR [8 – 15].Before transferring control to another entity within Locality 0, an executing entity must measure the entity to which it will transfer control.

NOTE: TCG says that this is the most general rule for meeting the transitive chain of trust requirements. The “entities within Locality 0” are the all the measurement agents who are using TPM PCRs: S-CRTM, BIOS POST, Option ROM code, applications that modify Option ROM code, and IPL code.

All Pre-Operating System Measurement Agents 74.10.3Prior to transferring control to another entity within Locality 0, an executing entity must measure the entity to which it will transfer control.

When a measurement is performed, the following steps must occur:1. If a hash of a block of code or data is performed, the SHA-1 algorithm must be

used to calculate the hash. This is required for predictability and audit.

2. The 20-byte value calculated in step 1, or, in the event of capping, a constant 20-byte value, must be written to the specified PCR of the TPM. This performs an extend operation, and is required for security and audit.



3. The 20-byte value is inserted into an event log structure. The event log structure is formed as:

pcrIndex field = PCR used in step (2). digest field = the 20-byte value that was written in step (2). eventType field = the type of event, which also defines how the event field is interpreted. event field = data specific to the eventType field. In some cases this may be the data actually measured.

Steps 2 and 3 may occur in any actual order but must logically occur together. Performing step 2, but not step 3, would maintain security, but prevent auditing. Performing step 3, but not step 2, would prevent auditing and reduce the security level.

For a given PCR, the order that values are extended into a PCR must exactly match the order that values are logged; this is to enable auditing.

Suggested verification metrics: Verify - For each PCR:

Begin with CheckValue = 0 (20 bytes). Read each Event Log entry in turn for the given PCR, and calculate CheckValue = SHA-1(CheckValue || Digest). Once end of log has been reached, verify CheckValue == PCR value.

Audit: Maintain a description of all events that may be logged and all events that must be logged. Ensure each event covered in the must list is actually logged. Ensure only events in the must and may lists are logged.

All Pre-Operating System Measurement Agents 101The pre-operating system measurement agents must add entries to the TCG Event Log.

See the requirement 74.10.3, immediately above, and the suggested measurement metrics for that requirement. Measurement agents that use the measurement method specified in requirement 74.10.3 automatically meet this requirement.

All Pre-Operating System Measurement Agents 72a.10.172b.10.1In the TCG Event Log:

All constants and data must be represented as little-endian unless otherwise explicitly stated. All strings must be represented as an array of ASCII bytes with the left-most character placed in the lowest memory location.

Suggested verification metrics: Check endian-ness of all entries logged. Check all bytes in strings have the value 0x20-0x7F only.



All Pre-Operating System Measurement Agents 73.10.2.1In the TCG Event Log:

Each entry must use the TCG_PCClientPCREventStruc structure, as defined in Section 10.2 of the TCG Specification. The eventType field of this structure must contain one of the event type codes defined in Section 10.4.1 of the TCG Specification.

If the BIOS uses the eventType field value EV_SEPARATOR, then this event must delimit actions taken during the pre-operating system and operating system environments. If measurements are supported and enabled the event field must be -1. If measurements are disabled or not supported, the event field must be NULL.

Suggested verification metric: The EV_SEPARATOR event type is measured the same way every time.

Pre-Operating System Measurement Agents 75.10.4.2If the eventType field in the TCG_PCClientPCREventStruc structure is set to EV_EVENT_TAG, then the other fields in the structure must meet the requirements in section 10.4.2 of the TCG Specification. In particular,

The event field of the TCG_PCClientPCREventStruc structure must be filled with a TCG_PCClientTaggedEventStruct structure. The event ID field of the TCG_PCClientTaggedEventStruct structure must be one of the EventID values specified in the requirements starting with section 10.4.2.3, Host Platform Specific Event Tags.

Suggested verification metric: Parse the Event Log.

All Pre-Operating System Measurement Agents 75a.10.4.3If the eventType field in the TCG_PCClientPCREventStruc structure is set to EV_ACTION, then the other fields in the structure must meet the requirements in section 10.4.3 of the TCG Specification. In particular,

The event field of the TCG_PCClientPCREventStruc structure must be filled with a string specified in section 10.4.3 of the TCG Specification.

When the BIOS enters ROM-based Setup in the pre-Boot environment, then the BIOS must set TCG_PCClientPCREventStruc.event = “Entering ROM Based Setup” and set TCG_PCClientPCREventStruc.pcrIndex = 1. If the Host Platform is designed to always perform a Host Platform Reset upon exit from the ROM-based Setup utility, then this measurement does not have to be made.

When the BIOS sets TCG_PCClientPCREventStruc.event equal to “User Password Entered”, “Administrator Password Entered”, “Password Failure”, or “Boot Sequence User Intervention” then the BIOS must set TCG_PCClientPCREventStruc.pcrIndex = 1.

Suggested verification metric: Parse the Event Log.

2.3 BitLocker PCR [4] and PCR [5] Usage RequirementsAfter the BIOS has completed its initialization and testing of the Host Platform hardware, the BIOS looks through a pre-defined sequence of boot devices, looking



for operating system code (called IPL code) to load and jump to. There can be any number of entries in the boot sequence, but until the BIOS finds a bootable device and loads a block of IPL code from it, the BIOS does not hash and extend any code into PCR [4].

This section contains the BitLocker requirements for PCR [4] and PCR [5] usage during the pre-operating system to operating system transition.

BIOS 77.8.1 BIOS must only measure IPL that the BIOS intends to execute. BIOS must be consistent in it’s measurements to PCR [4] and PCR [5] across boot cycles; that is, the BIOS must produce the same measurements in PCR [4] and PCR [5] every boot cycle that the same boot device is selected. If an IPL Device is not recognized by the BIOS, but instead, is handled by Option ROM code, then the Option ROM code is considered to be the IPL. The Option ROM code must still be measured to PCR [4] even if already measured to PCR [2] and/or PCR [0]. If an Option ROM is capable of booting IPL off a hard disk drive, then the Option ROM must always measure the next portion of the IPL into PCR [4]. If an Option ROM is capable of booting an IPL off any boot device, and that Option ROM participates in the static root of trust for measurement, then the Option ROM must always measure the next portion of the IPL into PCR [4]. When booting off a hard disk device, or a hard disk-like device, with a primary boot sector (where the primary boot sector is typically a Master Boot Record (MBR) or has been otherwise identified as having an MBR):

Bytes [0 – 1B7h] must be measured to PCR [4]. Bytes [1B8h - 1FFh] must be measured to PCR [5]. BIOS must not skip measurement of the MBR.

When booting off a floppy disk device, or a floppy disk-like device, with a boot sector (where the boot sector is typically a file system boot sector):

Bytes [0 – 1FFh] must be measured to PCR [4]. For a given boot attempt, the following events must be measured:

The BIOS must measure the invocation of INT 19h into PCR [4]. The BIOS must measure at least one EV_SEPARATOR separator into PCR [0 – 7] prior to entering the IPL / Option ROM. The BIOS must measure the appropriate EV_ACTION “Booting” indicating what device is being booted, if IPL code for that device has been found. The BIOS must measure the first block of IPL before entering it, if IPL code for that device has been found. This may be an Option ROM where applicable. The BIOS must also measure IPL data into PCR [5] if the location of IPL data is known. The BIOS must measure the invocation of INT 18h into PCR [4]. The order of measurements must be consistent across each and every reboot.

The items listed below can be used to verify the required sequence of events; however, more extensive verification is required than is listed here:

When booting off a hard disk drive, with the hard disk drive set to be the primary boot device, ensure the following events are in the Event Log:



At least one EV_SEPARATOR to PCR [0-7]. No INT 18h to PCR[4]. Exactly one INT 19h to PCR[4]. Exactly one “Booting” EV_ACTION to PCR [4] describing the action of booting off a hard disk drive. MBR [0 – 1B7h] is measured to PCR [4] as IPL code event; the MBR measurement must be checked exactly. MBR [1B8h – 1FFh] is measured to PCR [5] as IPL data event; the measurement must be checked exactly.

When booting off a USB flash drive, configured as primary boot device and with an MBR, ensure the events in the event log are exactly the same as in (1). When booting off a hard disk drive, with CDROM drive configured as primary boot device and hard disk drive set to be second boot device, with no CDROM present, ensure the events in the event log are exactly the same as in (1). When booting off a hard disk drive, with CDROM drive configured as primary boot device and hard disk drive set to be second boot device, with a bootable CDROM present and the bootable CDROM calling INT 18h or INT 19h, ensure the events in the event log are as follows:

At least one EV_SEPARATOR to PCR [0-7]. At least one INT 19h to PCR [4], and either two INT 19h entries or one INT 18h entry to PCR [4] depending on CDROM boot code. The second INT 19h entry or first INT 18h entry must occur after the first “Booting” / IPL measurement events, and before the second “Booting” / IPL measurement events. Exactly two “Booting” EV_ACTION to PCR [4] describing the action of booting off (first) a CDROM drive, and (second) a hard disk drive. MBR [0 – 1B7h] is measured to PCR [4] as the second IPL code event. The MBR measurement must be checked exactly.

2.5 BitLocker Host Platform Power State Transition RequirementsThis section contains the BitLocker requirements for Host Platform power state transitions.

BIOS 77j.8.3.1Host Platforms and post-BIOS Operating Systems must support ACPI; however, the ACPI “G” states are outside the scope of the TCG Specification.

S-CRTM 79.8.3.1.327a.3.2.2When the Host Platform enters and exits the S3 state:

Exiting S3, the command to restore the PCRs must be issued by the CRTM; the CRTM should ignore any error resulting from the TPM entering failure mode. If any component is executed prior to the CRTM jumping to the operating system resume vector, it must have been previously measured before entering the S3 state.



NOTE: For the S-CRTM to meet these requirements, other entities on the Host Platform must meet these requirements when the Host Platform enters and exits the S3 state:

The TPM must preserve PCR values and other TPM state. During S3, the TPM must prohibit all TPM functions. Entering S3, the operating system TPM driver must issue the TPM_SaveState command.

Suggested verification metrics: Check PCR states are preserved across S3 sleep/wake if TPM_SaveState command was issued before sleep. No PCRs [0-5] should be modified when returning to operating system environment. Check TPM is disabled if TPM_SaveState command was not issued before sleep, or if additional TPM commands were issued before sleep.

S-CRTM 80.8.3.1.480.8.3.1.527a.3.2.2When the Host Platform enters and exits the S4 state:

The S-CRTM must issue a TPM_Startup (ST_CLEAR) command. After completing resume from S4, the PCR contents may be different if the entry into S4 was initiated by the BIOS instead of the operating system.

NOTE: When the Host Platform enters and exits the S4 state: The power to the TPM may be interrupted.

Suggested verification metrics: Extend PCR [0-15] prior to S4. Ensure PCRs contain expected values on resume from S4. Issue TPM_SaveState prior to S4. Repeat test 1. Ensure PCRs contain expected values on resume from S4.

S-CRTM 82.8.3.1.627a.3.2.2When the Host Platform enters and exits the S5 state:

The S-CRTM must issue a TPM_Startup (ST_CLEAR) command.

NOTE: When the Host Platform enters and exits the S4 state: The power to the TPM may be interrupted.

Suggested verification metrics: Extend PCR [0-15] prior to S5. Ensure PCRs contain expected values on resume from S4. Issue TPM_SaveState prior to S5. Repeat test 1. Ensure PCRs contain expected values on resume from S5. Repeat tests 1&2 comparing an operating system reset against operating system shutdown/reboot.



2.6 BitLocker PCR [0] and PCR [1] Usage RequirementsThis section contains the BitLocker requirements for PCR [0] and PCR [1] usage.

S-CRTM 32.3.2.3.1The S-CRTM must measure the S-CRTM’s version identifier into PCR [0].

Suggested verification metrics: Test by checking event log against auditable list. Audit expected value -> Hash mapping. A list of steps should exist, such as “measure Hash (xxx) or measure Hash (Firmware physical address x, length y)” that can be audited.

All Pre-Operating System Measurement Agents that Use PCR [0] 33.3.2.3.1All Host Platform firmware physically bound to the motherboard must be measured into PCR [0] if it is:

Executed by the Host Platform CPU(s). Is part of the Host Platform Transitive Trust Chain.

This includes, but is not limited to: BIOS POST code. Embedded SMM code and the code that sets it up.

Suggested verification metrics: Test PCR [0] measurements against a must list of measurements (see 74.10.3). Audit expected value -> Hash mapping. A list of steps should exist, such as “measure Hash (xxx) or measure Hash (Firmware physical address x, length y)” that can be audited.

BIOS POST 34.3.2.3.1 The ACPI table, in the form that it is stored in flash memory prior to modification and fix-ups, must be measured into PCR [0]. If the stored form is compressed, the compressed form may be measured instead of the decompressed form. This measurement must be repeatable over every boot for any hardware and NVRAM configuration for a given instance of the firmware.

The intent is a normalized ACPI table, prior to the NVRAM settings being applied. In other words, the measurement into PCR [0] should always be the same for a given BIOS, no matter what the NVRAM / CMOS settings are.

Suggested verification metrics: Identify this measurement in the event log. Change configurations via NVRAM / CMOS settings, reboot and verify measurement is unmodified.

BIOS 1cThe platform class for platforms adhering to this specification must specify “Class = 00h” for PC Client BIOS class, or “Class = 01h” for Server BIOS class. This class is



stored at offset +24 of the ACPI table and indicates how the platform is anticipated to be used. It also indicates the ACPI table format which is slightly different between Client and Server BIOS classes.

Suggested verification metrics: Verify ACPI table specifies one of the supported class types. Verify ACPI table size and parameters correspond to the class type. Audit that the applicable class type is used.

BIOS 2.9The Host Platform ACPI namespace must contain an ACPI device object in an appropriate scope for the TPM:

The ACPI device object representing the TPM must contain either a _HID object with the value of “PNP0C31”, a _CID object with the value of “PNP0C31”, or a _CID object that evaluates to a package where the value “PNP0C31” is one of the IDs within the package. The ACPI device object representing the TPM must claim all hardware resources consumed by the TPM; this includes any legacy I/O ports and other hardware resources. If there are configurable resource options, the ACPI device object representing the TPM must contain _PRS and _SRS control methods as required in the ACPI specification.

A BIOS that meets this set of requirements enables discovery of the TPM 1.2 by the operating system, dynamic re-balancing of the system resources, and loading of the appropriate device driver for this system, all of which BitLocker depends on.

Suggested verification metrics: Query Microsoft Windows® PnP for devices that report a HID or CID of PNP0C31. For devices that report PNP0C31, verify via PnP (CMAPI) that all resources are reported. In particular, there must be a read/write memory-mapped I/O port starting at system memory address 0xFED40000; for more information, see Section 9, ACPI Device Object for TPM, in the v1.21 TCG Spec.

BIOS POST 35.3.2.3.1BIS code, excluding the BIS Certificate, must be measured into PCR [0].

Suggested verification metrics: Identify this measurement in the Event Log. Audit measurement that is stored in the Event Log.

BIOS POST 35a.3.2.3.1Manufacturer-controlled embedded Option ROMs, as a binary image, must be measured into PCR [0].

TCG says a manufacturer-controlled embedded Option ROM is: Attached to the motherboard Has release and update controlled by the Host Platform manufacturer.



Suggested verification metrics: Identify these measurements in the Event Log. Audit measurement that is stored in the Event Log.

BIOS 36c.3.2.3.1 Changes to the user setup configuration must not be measured into PCR [0]. The BIOS Setup configuration changes that reflect change of boot order must be measured into PCR [1].

Suggested verification metric: Perform a setup configuration. Identify PCR changes and event log changes that occur as a result of the configuration change. Verify PCR [0] always remains consistent.

All Pre-Operating System Measurement Agents that Use PCR [0] 36b.3.2.3.1Any other code or information that is relevant to the S-CRTM, POST BIOS, or manufacturer-controlled embedded Option ROMs, if measured, must be measured into PCR [0].

Suggested verification metric: Audit all regions of all firmware and what event each region of firmware is measured into. Any regions of firmware not measured require detailed review.

BIOS 36a.3.2.3.1 The BIOS must attempt to detect and measure the presence of any Non-Host Platform. If the BIOS detects the presence of a Non-Host Platform, then the BIOS must measure relevant information about its presence, such as type, version, and so on, into PCR [0] using EV_NONHOST_INFO. If the BIOS detects the presence of a Non-Host Platform, then BIOS may measure components within the Non-Host Platform (for example, firmware not intended to be executed by the Host Platform CPU) that are not part of the Transitive Trust Chain but may affect the trust of the Host Platform.

A Non-Host Platform contains firmware that is not executed by the Host Platform CPU. An example is Intel’s Advanced Management Technology (AMT) building block down on the motherboard.

Suggested verification metric: Audit existence of a Non-Host Platform. Identify event entry that measurement is logged to.

BIOS 48.3.2.3.2Entities that must not be measured into PCR [1] are:

Values and registers that are automatically updated (for example, clocks).



System unique information such as asset numbers, serial numbers, and so on. Passwords.

Suggested verification metrics: Check PCR [1] across reboots, ensure PCR [1] value remains consistent. Modify Asset Tag / Serial number, ensure PCR [1] value remains consistent.

2.7 BitLocker PCR [2] Usage RequirementsThis section lists the BitLocker requirements for PCR [2] usage.

BIOS 53.3.2.3.354.3.2.3.351.3.2.3.3

Non-manufacturer-controlled embedded Option ROMs must be measured into PCR [2]. NOTE: TCG says that a non-manufacturer-controlled Option ROM is physically contained on the motherboard (as opposed to an add-in card), but the release and control of any update is not controlled by the motherboard manufacturer. BIOS must measure the visible portion of the Option ROM into PCR [2] prior to executing it. In all cases, Option ROM code that is executed must be measured even if the binary representing the code was already measured into PCR [0]. For each discovered Option ROM, the BIOS must perform measurements into PCR [2] as follows:1. Measure the event OptionROMExecute.2. Measure the visible Option ROM code prior to executing it.3. Repeat until all Option ROMs are measured and executed.

Suggested verification metrics: Audit all regions of all firmware and what event each region of firmware is measured with. Any regions of firmware not measured require detailed review. Verify all identified regions occupied by Option ROM are measured into PCR [2] using the OptionROMExecute event.

Option ROM Code 52.3.2.3.355.3.2.3.3

The Option ROM must measure into PCR [2] the portion of the Option ROM code that is not visible to the BIOS. TCG says some Option ROMs may use paging or other techniques to load and execute code that is not visible to the BIOS when measuring the visible portion of the Option ROM; only the visible Option ROM code can measure this hidden Option ROM code. Option ROMs, when executing, must perform measurements into PCR [2] as follows:

When un-hiding Option ROM code, measure the event “Un-hiding Option ROM Code”.



Measure the hidden Option ROM code into PCR [2] prior to executing it.

Suggested verification metrics: Audit option ROMs that use paging. Verify all such identified options ROMs have additional events as described by this requirement.

Applications that Modify Option ROM Code 50.3.2.3.3An application that modifies Option ROM code must run only if the administrator allows it to run.

Any application that modifies Option ROM code must do one of the following: Measure the new code into PCR [2], Cause a Host Platform Reset.

If the application runs in the pre-operating system environment, this application must execute after the BIOS has measured the Option ROM code that the application modifies.

If the application runs in the operating system environment, the application must: Disable BitLocker. Modify the Option ROM code. Schedule a task to run in the operating system environment after the next Host Platform re-boot that re-enables BitLocker. Re-boot the Host Platform.



3. BitLocker TPM Integration RequirementsThis section contains the BitLocker requirements for how the system integrates the BIOS with the TPM, the platform reset signal, and the physical presence indicator. The block diagram below shows the scope of the requirements in this section.

Figure 3-1 Integration of the TPM with Other Components on the Host Platform

3.1 TPM RequirementsThis section lists the BitLocker requirements for the TPM, the component labeled “2” in Figure 3-1.

TPM 1aTPM 1bThe TPM used on the Host Platform must be compliant with the TPM Main Specification; Family 1.2; Level 2; Revision 0.85 or later (see requirement #1 on page 12 of the TCG Specification).

The TPM used on the Host Platform must be compliant with the TCG PC Client Specific TPM Interface Specification; Version 1.2; Revision RC29 (see requirement #2 on page 12 of the TCG Specification).

BitLocker code requires capabilities found only in TPM v1.2 and a TPM on the platform that meets this requirement enables the Microsoft TPM 1.2 driver that ships in Vista to be a “universal driver” (work with all vendor’s TPMs).

Suggested verification metrics: Exercise functionality only available in TPM v 1.2.



Exercise TPM functionality using the universal driver that ships in Vista.

3.2 BitLocker One-to-One Binding RequirementsThis section lists the BitLocker requirements for the one-to-one bindings of components to the Host Platform (see label “3” in Figure 3-1).

The relationship between the Endorsement Key, a TPM, and a Host Platform is described in the TPM Main Specification v1.2, Part 1, Section 11.2:

The EK is transitively bound to the Platform via the TPM as follows: An EK is bound to one and only one TPM (for example, there is a one to one correspondence between an Endorsement Key and a TPM.) A TPM is bound to one and only one Platform. (for example, there is a one to one correspondence between a TPM and a Platform.) Therefore, an EK is bound to a Platform. (for example there is a one to one correspondence between an Endorsement Key and a Platform.

Host Platform Construction 18eThe Endorsement Key (EK) must be generated and inserted in the TPM before the Host Platform leaves the Host Platform manufacturer-controlled environment.

Suggested verification metric: Internal audit – Process review.

3.3 BitLocker Locality RequirementsThis section contains the requirements for the relationship labeled “4” in Figure 3-1. Locality requirements are primarily about the relationship of the TPM to the core logic chipset on the Host Platform; however, the scope of some of the TCG Specification Locality requirements includes other Host Platform components as well as the TPM and the core logic chipset.

To better understand the TCG Specification requirements referred to in this section, download the v1.2 TCG PC Client Specific TPM Interface Specification (TIS) from the TCG public web site, at https://www.trustedcomputinggroup.org/groups/pc_client/ and read the sections about Locality.

Host Platform Construction 20.3.2.1There must be a memory-mapped port defined for Locality 0.

NOTE: This is a requirement for the relationship between the TPM and the core logic chipset. Locality 0 is the Host Platform environment used by the S-CRTM and its chain of trust. Locality 0 must use the system/software memory address FED40000h through FED40FFFh; for more information, see Section 9.1, TPM Locality Levels, in the TCG PC Client Specific TPM Interface Specification (TIS), Version 1.2, July 11, 2005 (downloadable from www.trustedcomputinggroup.org).

The BitLocker team interprets this to be a requirement which is stated as, “The TPM must have a memory-mapped port defined for Locality 0.” BitLocker code sends all commands to the TPM through memory-mapped Locality 0.


http://www.trustedcomputinggroup.org/

https://www.trustedcomputinggroup.org/groups/pc_client/


BIOS 102.3.2.1.4When BIOS uses INT 19h to transition the Host Platform from pre-boot to post-boot environment, the value of localityModifier must equal 0; see Figure 4 in Section 3.2.1.4, Locality for Transition to IPL, of the v1.21 TCG Specification

NOTE: TCG says that the localityModifier is part of a special cycle on the Host Platform LPC bus that connects the chipset to the TPM; for more information, refer to Section 9 of the TCG PC Client Specific TPM Interface Specification, Version 1.2.

3.4 BitLocker Static CRTM and Embedded Firmware RequirementsThis section contains the requirements for the Static CRTM, labeled “5” in Figure 3-1.

S-CRTM 22d.3.2.1.2Upon completion of the manufacturer-specific BIOS Boot Block process, at the next Host Platform Reset event, code execution must begin with an instruction within the S-CRTM controlled and designated by the Host Platform manufacturer.

Suggested verification metric: All manufacturer approved CRTM’s and CRTM update methods should comply with the TCG PC Client Specific Implementation Specification for Conventional BIOS V1.21, Rev 0.24 dated March 09, 2006 as well as any published errata.

S-CRTM update process 22a.3.2.1.2132.1.2.222c.3.2.1.2134.3.2.1.2135.6.2The Core Root of Trust for Measurement (CRTM) must be an immutable portion of the Host Platform’s initialization code that executes upon a Host Platform Reset.

“Immutable” can mean either: The CRTM cannot be updated/modified. The CRTM can only be updated / modified through a manufacturer-approved method. This modification must be accomplished through a method that maintains trust of the host platform.

The following requirements apply to all Host Platforms in which the CRTM is modifiable.

If CRTM Update/Modification and/or Disaster Recovery methods are implemented, they must not allow a non-manufacturer-approved CRTM to be written. The Host Platform must implement CRTM Update Validation. All code which executes prior to the installation of a new CRTM, but within the same boot cycle, must either (1) be present in the existing CRTM, OR (2) be determined to be valid through the CRTM Update Validation process. The Host Platform must implement CRTM Update Access Control. CRTM Update Access Control must ensure that the ability to modify the CRTM is disabled whenever executing code which is not manufacturer-approved.



Suggested verification metric: Internal Audit – Security Review

Microsoft welcomes platform manufacturers to work with the BitLocker team to review your process for a Host Platform manufacturer-approved agent and method for S-CRTM modification; send e-mail to [email protected] .

The manufacturer-approved method should rely on cryptographic signatures to validate the update, as well as any code involved in the update process.

BIOS upgrades may require the cooperation of the operating system to ensure that the change does not trigger BitLocker recovery and prevent the operating system from booting. Microsoft plans to provide a WMI interface for BIOS vendors.

CRTM Update Validation refers to the process by which the CRTM update and the code performing the update is verified to be manufacturer-approved before the update is applied.

CRTM Update Access Control refers collectively to any hardware and/or software measures that prevent modification of the CRTM until all necessary validation has succeeded.

BIOS Recovery Mode process 135.6.1BIOS Recovery Mode:

Must, upon completion, cause a Host Platform Reset. Must not allow impersonation of another valid boot state; this applies to the values in the pre-operating system state’s PCRs.

If the BIOS Recovery code is on another media, such as a floppy disk, then that code must be measured into PCR [4].

Any CRTM/BIOS Disaster Recovery method must not allow a non-manufacturer-approved CRTM/BIOS to be written.

3.5 BitLocker Host Platform Reset RequirementsThis section lists the BitLocker requirements for Host Platform Reset, labeled “6” in Figure 3-1.

One of the requirements in this section, the requirement with the ID = 1d, refers to the TCG Platform Reset Attack Mitigation Specification, Revision 0.92 or later, which can be downloaded by TCG Member companies at www.trustedcomputinggroup.org/apps/org/workgroup/pcclientwg.

Host Platform Construction 17.1.2.7.218a.1.2.7.318b.1.2.7.3BIOS 1d

Upon a Host Platform Reset, the boot strap CPU must be reset and begin execution within the S-CRTM; all remaining CPU(s) must be reset. Upon a Host Platform Reset, the TPM must be reset, using the TPM_Init signal. The TPM must not be reset without a Host Platform Reset. Allowing the TPM to be reset independently of ALL of the CPU’s and the chipset can allow malicious code to measure desirable values into the TPM PCR registers. The BIOS must implement the interface defined in the TCG PC Client Specific Platform Reset Attack Mitigation Specification Version 0.92, or later.


http://www.trustedcomputinggroup.org/apps/org/workgroup/pcclientwg

mailto:[email protected]


BitLocker Drive Encryption relies on the security of all components being reset simultaneously.

If a warm boot is detected (that is, the reset signal was not toggled), the BIOS must immediately perform a full platform reset (also known as a hard reset) so that all the PCR values are reset with the CPU’s and Chipset in a controlled state (see requirement 23.3.2.1.1). For example, one way for BIOS to detect that a full platform reset has not occurred to send a TPM_Startup command to the TPM; if the TPM returns a TPM_INVALID_POSTINIT error code, then BIOS can use that as am indicator that it must force a hard reset.

Suggested verification metrics: Internal audit – Hardware review, ensure that the reset signals are tied together in a manner that resetting one component of CPU/Chipset/TPM will reset the other components. Ensure that toggling the reset line on the TPM will reset the CPU and chipset.

S-CRTM 23.3.2.1.1Upon Host Platform Reset, the S-CRTM must have control of the TBB.

That is, the same reset signal must service the TPM, the CPU, and all chipsets. If one is reset, all must be reset. This is to prevent the TPM PCR registers being accidentally reset without entering into CRTM portion of Firmware in a controlled state to reload the PCRs with new measurements.

Suggested verification metric: Internal audit – Hardware review.

BIOS 18c.1.2.8Upon return from a PCI Option ROM, the BIOS must check the return status from the Option ROM and if requested, the BIOS must perform a Host Platform Reset per Section 5.2.1.24.1 of the PCI Firmware Specification, Revision 3.0.

Section 5.2.1.24 of the PCI Firmware Specification, Rev 3.0, states that “Support for Configuration Utility Code management is optional for the system firmware, so this requirement does not apply to all Host Platforms.

More specifically, Section 5.2.1.24 defines three different ways that an Option ROM controls the way the BIOS executes the Option ROM Configuration Utility Code – labeled Legacy, Hybrid, and Delayed Execution methods. Only the Delayed Execution method returns the Host Platform Request that is the scope of the TCG requirement to the left; this TCG requirement does not apply to the Legacy and Hybrid methods.

Suggested verification metric: Audit – Review handling of return value of Option ROMs.

3.7 BitLocker Command Method Physical Presence Indicator RequirementsThe Physical Presence Interface is used to authenticate TPM functionality required to enable, activate, and clear the TPM when the TPM owner is not available or the TPM owner has lost the owner authorization. As such, the integrity of the platform relies on the implementation of this indication.



BitLocker integrates with platforms that support the software method of physical presence. On platforms shipped with the TPM off, users can only turn on the TPM if they have provided an indication of physical presence. Ways to detect the user's physical presence include: prompting the user to press a specific key on the keyboard, pressing a button on the case, or to inserting physical media such as a USB device.

The general requirements are: The BIOS must implement the interface "TCG Physical Presence Interface – ACPI_1-00_0-25.doc", dated July 13, 2005 or the latest revision, available to TCG Member companies at www.trustedcomputinggroup.org/apps/org/workgroup/pcclientwg. The BIOS must expose a secondary option (such as setup menu options) to enable and activate (turn on), disable, and clear the TPM.

NOTE: This requirement ensures that minimal TPM administration is still available in the event of a corrupted or removed operating system.

The document describing the Physical Presence Interface encapsulates the rest of the TCG requirements in the following table. The BitLocker team recommends reading the Physical Presence Interface document, especially the pseudocode section, as a companion to understanding the main TCG requirements in this area.

BIOS 9aThe BIOS must implement the interface "TCG Physical Presence Interface – ACPI_1-00_0-25.doc", dated July 13, 2005 or the latest revision.

Suggested verification metric: Windows Vista's "tpm.msc" launches the TPM management snap-in that integrates with the Physical Presence Interface.

Host Platform Construction 7.1.2.3The indication of Physical Presence must be contained within the Trusted Building Block (TBB).

TCG says the TBB is the combination of the CRTM, TPM, connection of the CRTM to the motherboard, and connection of the TPM to the motherboard; the connection of the CRTM to the TPM is done through transitive trust of the CRTM connection and the TPM connection.

NOTE: Asserting the physical presence indication within the CRTM satisfies this requirement.

S-CRTM 12.15.213.15.2

The BIOS must always boot to the OS with the PhysicalPresence flag in the TPM set to FALSE and the PhysicalPresenceLock flag in the TPM set to TRUE. The Physical Presence Interface must be designed such that it can only be executed if the user is physically present (for example, presses a button, inserts a floppy disk, or inserts a USB device).


http://www.trustedcomputinggroup.org/apps/org/workgroup/pcclientwg


Suggested verification metrics: The BIOS must confirm that the physically-present user actually requested the execution of the TPM operation. This confirmation is achieved via a pre-OS dialog. If the request is rejected by the physically-present user, the BIOS must clear the request so that the user is not prompted to confirm again on the next reboot.

NOTE: The pseudocode section of the Physical Presence Interface document clarifies this requirement.

4. BitLocker System Partition RequirementsThis section lists the BitLocker requirements for a separate system partition on the Host Platform hard disk drive – a partition separate from the operating system partition.

OEM or VAR 1gSystems that provide BitLocker BIOS enhancements must provide a second hard disk drive (HDD) partition, outside the Windows partition, that enables BitLocker functionality.

OEM or VAR 1hThe second HDD partition must be formatted as NTFS, be the active system partition, with at least 50MB dedicated to BitLocker utilities.

NOTE: This second partition may need to be as large as 1.5GB to accommodate other Windows Vista features such as Windows recovery and upgrade to Windows Vista from Windows XP; regardless of the size of this second partition, at least 50MB must be available exclusively for BitLocker.

5. BitLocker Requirements for System Firmware Support of USB Flash DriveThis section lists the BitLocker requirements for system firmware support for reading and writing files from a USB mass storage class device.

BIOS 1jThe BIOS must successfully perform a read operation on a reference USB mass storage class device.


Documents

Windows Vista BitLocker Client Platform Requirementsdownload.microsoft.com/download/a/f/7/af7777e5-7dcd-… · Web views-crtm 12.15.2 13.15.2 The BIOS must always boot to the OS