TSF Code Integrity

The TSF Boot Manager is an Authenticode signed image file, based on the Portable Executable (PE) image file format. A SHA hash based signature and a public key certificate chain are embedded in the

boot manager Authenticode signed image file under the “Certificate” IMAGE_DATA_DIRECTORY of the IMAGE_OPTIONAL_HEADER of the file. This public key certificate chain ends in a root public key. The boot manager uses the embedded SHA hash based signature and public key certificate chain to validate its own integrity. A SHA hash of the boot manager image file is calculated for the whole file, with the exception of the following three elements which are excluded from the hash calculation: the CheckSum field in the IMAGE_OPTIONAL_HEADER, the IMAGE_DIRECTORY_ENTRY_SECURITY

IMAGE_DATA_DIRECTORY, and the public key certificate table, which always resides at the end of the image file.

If the boot manager is validated, then the root public key of the embedded public key certificate chain must match one of the Microsoft root public keys which indicate that Microsoft is the publisher of the boot manager. These root public keys are necessarily hardcoded in the boot manager. If the boot manager cannot validate its own integrity, then the boot manager does not continue to load other modules and displays an error message.

After the boot manager determines its integrity, it attempts to load one application from the following list of boot applications:

 Winload.exe or Winload.efi, the boot application used to load the Windows 7/WS08R2 kernel

 ntoskrnl.exe, the Windows kernel

 winresume.exe or winresume.efi, the boot application used for resuming from the hibernation file “hiberfil.sys”

 memtest.exe, a memory testing application.

These boot applications are also Authenticode signed image files. For each of the Windows 7/WS08R2 boot applications, the boot manager uses the embedded trusted SHA hash based signature and public key certificate chain within the boot application’s IMAGE_OPTIONAL_HEADER to validate the integrity of the boot application before attempting to load it. Except for the following three elements which are excluded from the hash calculation, a SHA hash of a boot application image file is calculated for the whole file: the CheckSum field in the IMAGE_OPTIONAL_HEADER, the

IMAGE_DIRECTORY_ENTRY_SECURITY IMAGE_DATA_DIRECTORY, and the public key certificate table, which always resides at the end of the image file.

If the boot application is validated, then the root public key of the embedded public key certificate chain must match one of the hardcoded Microsoft’s root public keys. If the boot manager cannot validate the integrity of the boot application, then the boot manager does not continue to load Windows 7/WS08R2 modules, instead displaying an error message below along with the full name of the boot application that failed the integrity check.

After the boot application’s integrity has been determined, the boot manager attempts to load the boot application. When configured, the full volume encryption (FVE) facility within the Windows 7/WS08R2 boot manager also conducts its own independent SHA-256 hash based validation of the boot

applications as identified above. If the boot application is successfully loaded, the boot manager then transfers execution to the loaded application.

After the Windows 7/WS08R2 Winload boot application is loaded, it receives the transfer of execution from the boot manager. During its execution, Winload attempts to load the Windows 7/WS08R2 kernel (ntoskrnl.exe) together with a number of critical drivers. Among the modules that Winload must validate in the Portable Executable (PE) image file format, are the cryptography related modules listed below.

These modules are listed in a hardcoded list.

 The Windows 7/ WS08R2 kernel;

 The Windows 7/ WS08R2 kernel security device driver;

 The Windows 7/ WS08R2 code integrity library module; and

 The BitLocker™ drive encryption filter driver.

The four image files above have their trusted SHA hashes stored in catalog files that reside in the local machine catalog directory.

Because they are PKCS #7 SignedData messages, catalog files are signed. The root public key of the certificate chain used to verify the signature of a Microsoft’s catalog file must match one of the

Microsoft’s root public keys indicating that Microsoft is the publisher of the Windows 7/WS08R2 image files. These Microsoft’s root public keys are hardcoded in the Winload boot application.

If the image files are validated, their SHA hashes, as calculated by the Winload boot application, must match their trusted SHA hashes in a Microsoft’s catalog file, which has been verified by the Winload boot application. A SHA hash of an image file is calculated for the whole file, with the exception of the following three elements which are excluded from the hash calculation: the CheckSum field in the IMAGE_OPTIONAL_HEADER, the IMAGE_DIRECTORY_ENTRY_SECURITY IMAGE_DATA_DIRECTORY, and the public key certificate table, which always resides at the end of the image file.

Should the Winload boot application be unable to validate the integrity of one of the Windows 7/WS08R2 image files, the Winload boot application does not continue to load other Windows 7/WS08R2 image files. Rather it displays an error message, along with the full name of the Windows 7/WS08R2 image file which does not have the validated integrity.

In addition, Windows File Protection maintains a set of protected files that are stored in a cache along with cryptographic hashes of each of those files. Once the system is initialized, Windows File Protection is loaded and will scan the protected files to ensure they have valid cryptographic hashes. Windows File Protection also registers itself to be notified should any of the protected files be modified so that it can recheck the cryptographic checksum at any point while the system is operational. Should the any of the cryptographic hash checks fail, the applicable file will be restored from the cache.

SFR Mapping:

The TSF Protection function satisfies the following SFRs:

 FPT_ITT.1, FPT_ITT.3: The TSF provides internet-based standard protocols for IP security and Key management. IPSec with AH and ESP implementations protect transferred TSF data from disclosure and modification. AH provides data signature functionality to protect against

modification; ESP provides encryption to protect against disclosure as well as modification. The TSF implements IP AH. AH provides integrity, authentication and anti-replay. AH uses a hashing algorithm, such as SHA, to compute a keyed message hash for each IP packet. Additionally, IPSec policies and filters may be configured to reject the packet or audit the event if the results of a service applied to a packet challenges the integrity of the packet (modification, insertion of data, replay of data). Any packets rejected as a result of an integrity error are rejected and the event is audited.

 FPT_RCV.1: The TSF enters a halted state upon failure and allows the user to restart the operating system in a limited operational mode where recovery can be attempted.

 FPT_WPF_EX.1: The TSF implements memory protection on 64-bit architectures by not

executing code on pages marked for data only. The owing process has the ability to set the flags associated with its memory pages.

 FPT_WPF_EX.2: When configured, the TSF is capable of performing full disk volume encryption in order to protect the disk contents (TSF, TSF data, and user data) from potential modification and disclosure. Only when appropriate credentials are provided can the TSF be made to start or the contents of the disk be otherwise accessed.

 FPT_WPF_EX.3: The TSF is capable of encrypting the content of removable USB storage devices using BitLocker. Furthermore, the TSF provides the ability to require the use of this feature in order to write content to removable USB storage devices.

 FPT_WPF_EX.4: The TSF includes a Network Policy Service role that allows administrators to define network access requirements and also serves to compare reported health profiles against the requirements in order to decide which, if any, network services will be provided to an applicable client. The TSF also includes agents that serve as the counterpart for the health profiles based on TSF settings and installed applications. The agents report their health profiles to the server when network access is needed so that the server can provide applicable network access credentials (or not) based on comparing that data to its configured health requirements.

 FPT_WPF_EX.5: When a supporting TPM chip is present, the TSF can use it to store FVE

encryption keys. When starting the TOE, the TPM chip will release the FVE encryption keys only when the integrity of selected operating system components can be confirmed.

 FPT_STM.1, FMT_MTD.1a (partial): The real-time clock in each Windows 7 and Windows Server 2008 R2 platform, in conjunction with periodic domain synchronization and restricting the ability to change the clock to authorized administrators, provides a reliable source of time stamps for the TSF.

 FPT_TRC_EXT.1: The TSF provides consistency of replicated GPOs and DS data by implementing a well-defined TSF replication algorithm that results in replication as soon as possible.

 FPT_TST_EXT.1: The TSF includes cryptographic self-tests in accordance with FIPS 140-2 per the FIPS certification (certificates #1319, #1321, #1326, #1327, #1328, #1329, #1330, #1331, #1332,

#1333, #1334, #1335, #1336, #1337, #1338, and #1339). Beyond this, the TSF includes a number of checks performed during the boot sequence designed to ensure cryptographically that TSF images have not been modified. Windows File Protection also serves to help prevent

modification or other corruption of TSF files. Finally, as described above, BitLocker enables Full

Volume Encryption for the operating system and all of its data. While BitLocker prevents disclosure of data, it also ensures the integrity of that data. If any changes are made, it will not decrypt properly resulting in a failure of the operating system to boot and run should any changes be made to the TOE or its data stores.