The objective of this work package is the analysis of the interaction between the operating system and a Trusted Platform Module as well as its role during the boot process. Logging and configuration capabilities are being derived.The exact release of the Windows 10 system in focus is build 1607, 64-bit, long-term servicing branch (LTSB), German language.

• Tools & Scripts: Trusted Platform Module and Unified Extensible Firmware Interface “Secure Boot”
• Trusted Platform Module Provisioning (Version 1.0)
• Work Package 5: Trusted Platform Module and Unified Extensible Firmware Interface “Secure Boot” (Version 1.1)
• Work Package 5: Trusted Platform Module and Unified Extensible Firmware Interface “Secure Boot” (Version 1.0)

Due to the long duration of this project, a differential analysis between the original version Windows 10, Build 1607 and Windows 10 Enterprise LTSC 2019 (Build 1809) was carried out for this work package. This version will be supported by Microsoft until 2029.

There are no significant changes in functional and/or implementation aspects of the interaction between Windows 10 and the Trusted Platform Module (TPM). This also applies to the TPM provisioning process, the role that the TPM plays in activities of the operating system, and the configuration and logging capabilities of the TPM.

• Download differential analysis of TPM

Table of contents analysis document

1 Introduction
1.1 Executive Summary (german)
1.2 Executive Summary (english)
1.3 Concept and Terms
2 Technical Analysis of Functionalities
2.1 TPM Communication Interfaces
2.1.1 TPM Communication: Userland
2.1.2 TPM Communication: Kernelland
2.1.3 TPM Usage Profiles
2.2 Windows Boot
2.2.1 Boot Manager
2.2.2 Windows Loader
2.2.3 Windows Kernel
2.3 The Windows Defender ELAM Driver
2.4 Integrity Measurement
2.5 TPM Provisioning
2.5.1 Manual Provisioning
2.5.2 Auto-provisioning
2.6 Security Aspects
3 Configuration and Logging Capabilities
3.1 Configuration Capabilities
3.1.1 Programmatic Configuration Capabilities
3.1.2 Non-programmatic Configuration Capabilities
3.1.3 Recommended Configuration Settings
3.2 Logging Capabilities
Appendix
Reference Documentation
Keywords and Abbreviations

Summary:

The objective of this work package is the analysis of the: (i) interactions between the Windows 10 operating system that is subject of analysis and the Trusted Platform Module (TPM); (ii) the role that the TPM plays in activities of the operating system, with a focus on the boot process (which we refer to as Windows boot); and (iii) the configuration and logging capabilities of the TPM. The TPM standard in focus is that of version 2.0. The exact release of the Windows 10 system in focus is build 1607, 64-bit, long-term servicing branch (LTSB), German language.

The TPM is a passive device executing commands submitted to it and returning relevant data, such as status codes. The parts of the Windows 10 system deployed in user-land can communicate with the TPM in two ways: direct or abstracted. The direct TPM communication involves executing functions declared as part of the TBS library file named tbs.dll whereas the abstracted way is communicating via the Windows 10 CNG library (CNG: Crypto Next Generation). This library abstracts functionalities of the TBS library by providing a cryptography provider called Platform Cryptographic Provider.

The parts of the Windows 10 system deployed in kernel-land can communicate with the TPM by invoking functions implemented in the TPM export driver. Basically, export drivers are kernel-mode library files exporting routines to the kernel or other drivers.

The core activities of the Windows boot process are performed by three entities booting the Windows system to its full extent, making it ready for use: the boot manager, the Windows loader, and the Windows kernel. In summary:

• the boot manager reads the Boot Configuration Database (BCD, a database of configuration parameters for starting Windows), potentially presents a boot menu, and loads the Windows loader;
• the Windows loader loads boot drivers and the Windows kernel; boot drivers are drivers that are required for starting the Windows kernel and the Windows operating system in general, such as file-system drivers;
• the Windows kernel loads system drivers, initializes the Windows subsystem, and runs the session manager smss.exe; system drivers are drivers required for regular system operation.

Each part checks the integrity of the following one by verifying the components digital signature. The certificates of image signers are verified using a public key stored as part of a root certificate issued by Microsoft. This certificate is hardcoded in the boot manager executable, the windows loader and the Windows kernel in a data structure informally referred to as the root table.

In the context of the Windows loader, the TPM is used for integrity measurement and BitLocker operations.

The TPM stores the hashes calculated in the pre-OS environment and related data into a context known as the WBCL or "Windows Boot Configuration Log". A new WBCL is generated at every system startup since this is when new integrity measurements are made.

Proof-of-Concept for TPM Provisioning outside of Windows 10

The objective of this work package is the development of a proof-of-concept (PoC) for provisioning the TPM outside of the Windows operating system. The TPM provisioning process involves multiple activities, such as setting an owner authorization value and storing a storage root key (SRK) in the TPM device. The focus of this work is on setting an owner authorization value. This process involves changing an already set owner authorization value, or specifying a new owner authorization value, and storing this value in the TPM. In this work, we use the tpm2-tools Linux toolset of version 3.1.3-2 for setting an owner authorization value in Linux.

Trusted Platform Module Provisioning (Version 1.0)

Table of contents analysis document

1 Introduction
1.1 Concepts and Terms
2 Technical Analysis
2.1 User Manual
Appendix
References
Keywords and Abbreviations

Summary:

If a given TPM device is provisioned in Linux, the owner authorization value set in Linux cannot be used in the context of Windows 10. It could be observed that in such a scenario, Windows 10 does not re-provision the TPM. In addition, the non-programmatic TPM configuration capabilities of Windows 10 do not enable users to manually input the owner authorization value in order to execute protected TPM commands and functionalities (e.g., changing the set owner authorization value). This is because a Windows 10 instance does not consider a TPM device trustworthy when the ownership of it has been taken in another operating system instance.