Application scenarios

The Trusted Platform Module (TPM) can be used on IPCs for various purposes:

  • The hard disk of the IPC can be encrypted in such a way that it can only be decrypted in the device containing the respective individual TPM.
  • It can protect the integrity of the system during early startup phases, so that unauthorized tampering is detected.
  • Customer-developed applications can have secret key material protected by the TPM so that it cannot be copied (stolen) from the device.

Further use cases are conceivable. The above options are described in more detail below.

Encrypting the hard disk with the TPM

On IPCs running Windows 10, Microsoft's BitLocker Drive Encryption is available to protect the confidentiality of data on the hard drive. The entire file system of a partition is encrypted. When Windows processes access files, the corresponding blocks are made available in decrypted form in the RAM. Ideally, the encryption remains unnoticed by users and processes in the live system. If the system partition is to be encrypted, it makes sense to use a TPM together with BitLocker. BitLocker also supports encryption without a TPM, but in this case a PIN entry or the insertion of a USB memory device with an unlock key is required when starting the system. With a TPM, protection can be achieved without such additional steps. Unattended startup without TPM and without PIN entry or plugging in a USB stick means that the hard disk could be started up in external systems. The combination of BitLocker with TPM is therefore ideal for unattended startup in industrial control systems.

The idea behind combining the encryption of the hard disk by BitLocker with the TPM is that the industrial controller can still boot unattended but the hard disk cannot be removed and used in another system. This helps with unattended systems that to which unauthorized persons may have physical access. For example, unauthorized persons should not be able to remove a hard disk from the industrial controller and manipulate or copy it with a laptop. The TPM serves as a security chip that stores the key for decrypting the hard disk in a way that cannot be copied. If the hard disk is removed, the TPM remains in the IPC. The hard disk cannot be decrypted outside the IPC.

Application scenarios 1:
Hard disk encryption.

Hard disk encryption alone is insufficient. For example, as long as an unauthorized person can log on to the running IPC and use the file system at will, disk encryption can be defeated by copying or manipulating data on the running system. This is especially true if hard disk encryption is enabled but the default administrator password has not been changed.

Hard disk encryption including TPM must therefore be combined with further protective measures. As a minimum, this includes limiting access the IPC to authorized users with individual authentication (e.g. password), as also described in the IPC Security Guide. A combination of hard disk encryption with the Windows KIOSK mode is ideal.

If hard disk encryption via BitLocker is enabled with Windows 10 (see: Encrypting your hard disk with BitLocker), integrity protection is automatically activated for the early boot phases. This is intended to prevent the system from being started with a manipulated BIOS or a manipulated kernel driver, for example, which would subsequently allow an attacker to access the data on the hard disk in the live system, even though its contents are encrypted.

Protecting system integrity with TPM

With Windows 10, the startup process can be secured so that as soon as the BIOS is activated, all software components involved in the startup chain are checked for tampering in the Windows kernel and kernel drivers, for example. This is referred to as trusted boot or measured boot. Windows uses a TPM for this purpose. This type of startup procedure must be activated to take effect. It is not active by default. When using BitLocker hard disk encryption (see above), it is automatically enabled.

The idea of the trusted boot concept is that sensitive data only becomes accessible once the system has ensured that trusted software is running. Accordingly, the TPM, in interaction with Windows 10, does not allow decryption of data on the hard disk partition encrypted by BitLocker until the system has determined that all previously started components were OK, i.e. not tampered with. For this purpose, cryptographically strong checksums are stored in the TPM chip. They are compared with the existing software during the start-up process. The decryption key for the hard disk is only released by the TPM if there is a match.

Application scenarios 2:
System integrity with context.

For legitimate updates to the Windows kernel, kernel drivers and other software components, while Windows is running it takes care of updating the required checksum memory in the TPM chip. If such software components or the BIOS are updated outside the running TPM, the checksums in the TPM chip are not automatically updated. Any manipulation is detected at the next start-up, in which case the start-up process is stopped. By providing the recovery key from BitLocker, an administrator can allow Windows to continue the boot process and use it to update the checksums in the TPM chip.

 

 

 

Protecting application data with TPM

APIs exist for applications in Windows, which applications can use to protect their own data in particular by means of the TPM chip. One of the APIs is provided in the form of the TPM software stack by Microsoft Research on GitHub (see: https://github.com/microsoft/TSS.MSR).

Please note: Usually, the application data is then bound to a specific TPM chip and cannot be reused on a different device via backup and restore. It is therefore advisable to bind only very sensitive data directly to the TPM chip, for example private keys. For all other sensitive data, hard disk encryption should be used (see above).

Please note: Programming of the API to use the TPM chip requires appropriate knowledge of security mechanisms and experience in common security practices. Otherwise, it is far too easy for the application itself to contain a loophole that allows an attacker to gain access to sensitive data despite the TPM chip. For example, after decryption by the TPM, the application must not store the data in plain text in the file system.

The idea behind this is to protect particularly sensitive data with the TPM chip in such a way that it cannot be copied at all and/or can only be used if the integrity of the system has been verified (i.e. the system has not been tampered with). In this case a copy of the data would be useless for an attacker, who would have to steal hardware to have any chance of using the data. Such a theft attempt would usually be noticed and can be responded to. When designing the safety function of the application, an important consideration is how to respond to such incidents in a meaningful way.

Application scenarios 3:
Protection of application data.

One option is to use different keys for different applications, which in turn are used to encrypt files. Both the encrypted files and the keys can be stored outside the TPM in the normal file system. While the keys are encrypted with a so-called root key, which remains exclusively in the TPM, the files are encrypted and decrypted with those keys. The keys are only used in the TPM. For this purpose, they are each activated by loading them into a register of the TPM and can then be used for decryption. Decryption takes place in the TPM so that the private key is never used outside the TPM.