Ruslan Rakhmetov, Security Vision
One of the main tasks in ensuring the cybersecurity of endpoints is reliable encryption key management, trusted loading of OS components to protect against VPO (rootkits, bootkits), full-disk drive encryption, credential protection, and isolation of cryptographic computing from the potential malicious effects of compromised OS components. To solve these problems, dedicated cryptographic modules (cryptoprocessors) are used, in which encryption keys are stored and operations with sensitive data are performed - they are called trusted platform modules (abbreviated TPM, Trusted Platform Module). In this article, we will talk about the principles of TPM modules, their functions and main components, as well as give examples of practical applications of TPM for data protection.
The need to use a trusted component that works with critical data and is isolated from potential malicious effects is inherent in the principles of creating secure information systems. For example, in the famous "Orange Book" ("Criteria for determining the security of computer systems", English "Trusted Computer System Evaluation Criteria"), the concept of a "trusted computing base" was introduced. "trusted computing base", abbreviated as TCB) as a set of protective software and hardware mechanisms in a computer system that ensures the implementation of an information security policy in the system, while the processes inside the TCB should not be influenced by untrusted processes. One of the ways of such isolation is the implementation of privileged security processes in a separate physical device. For example, back in the late 90s, trusted boot tools appeared in Russia (also called trusted boot hardware and software modules, abbreviated as APMDZ) to protect the OS boot process, monitor the integrity of the BIOS/UEFI/OS loader/OS kernel, authenticate users and log their actions, as well as generate reliable cryptographic keys using a dedicated hardware random number generator. Abroad, such cryptomodules are called trusted platform modules (TPM, Trusted Platform Module) - in 2003, the non-profit organization Trusted Computing Group (TCG), now a consortium of more than 100 technology companies, developed the first TPM modules version 1.1b, which began to be actively integrated into the motherboards of commercial PCs of various vendors. In the period from 2005 to 2009, a new version of TPM 1.2 was developed, which took into account the comments of vendors - a standard software interface and a standard pinout for integration into motherboards appeared (physical interfaces SPI, LPC, I2C, SMBus can be used). The TPM 1.2 specification used the SHA-1 hashing algorithm, in which a vulnerability was discovered in 2005, leading to reduced resistance to collisions - despite the fact that the first practical exploitation of this vulnerability was demonstrated only in 2017 (the SHAttered attack, two different documents with the same SHA-1 hashes were demonstrated). The TCG developers decided to update the TPM specification. In 2014, the TPM 2.0 specification was published, which added new algorithms for encryption, hashing, and hash-based simulation (HMAC). In 2015, the TPM 2.0 specification became an international standard. The standards ISO/IEC 11889-1:2015, ISO/IEC 11889-2:2015, ISO/IEC 11889-3:2015 and ISO/IEC 11889-4:2015 were developed, describing, respectively, the architecture, structures, commands and supporting procedures for the software library of the TPM module. Currently, the current version 184 of the TPM 2.0 library is available on the TCG website, and the source code for the TPM software implementation is available on the Linux developer community's GitHub page, as well as on the Microsoft implementation page.
The TPM 2.0 module allows you to perform the following operations:
· Asymmetric encryption using RSA 2048, ECC P256, ECC BN256 algorithms;
· Symmetric encryption using AES 128, AES 256 algorithms;
· Hashing using SHA-1, SHA-2 algorithms (256 bits);
· Hash-based simulation (HMAC) using SHA-1, SHA-2 (256 bit) algorithms;
· Dedicated hardware random number generator;
· "Binding" (English binding, wrapping) of encryption keys: generation of keys for symmetric encryption and their encryption/decryption using public/private keys built into the TPM - the created symmetric keys are "tied" to the TPM module;
· "Sealing" of encrypted data: decryption of data using "linked" keys is possible only if the system is in a predefined secure state.;
· Attestation of devices: verifying the authenticity of the installed TPM chip, verifying the integrity and security of the downloaded firmware and OS;
· Protection against attacks by brute force PIN codes installed for TPM;
· Protection of internal non-volatile memory (used for storing cryptographic keys, certificates, and service information).
In order to understand how the "binding" and "sealing" of keys and device certification work, you need to get acquainted with the internal structure of the TPM module version 2.0, its main functional blocks and principles of operation.:
1. Theoretically, the TPM module is a component of a computing system that allows you to understand whether a trusted computing database (TCB) has been compromised. In case of compromise, the TPM will prohibit the system from booting. The TPM module implements the concept of Roots of Trust ("roots of trust") - trusted software and hardware components, on the authenticity and integrity of which the critical security functions they perform depend.
2. The TPM module includes several software components:
2.1. CRTM (Core Root of Trust for Measurement): the component of the motherboard firmware contained in the BIOS/UEFI, which starts in the very first place when the device is restarted. CRTM enjoys the unconditional trust of other system components, and its integrity is checked during a self-test at device startup.
2.2. RTM (Root of Trust for Measurement): after passing a successful CRTM self-check, control is transferred to RTM, which performs hashing of subsequent running components - BIOS/UEFI, OS loader, OS itself. The hashing result (hash sum or digest, i.e. "summary") is called a "measurement" and is passed to the RTS component.
2.3. RTS (Root of Trust for Storage): this component stores "measurements" in special hardware registers in the TPM module, they are called PCR (Platform Configuration Register, platform configuration registers, 24 in total). These registers are write-only available to the TPM chip and their values are reset when the device is restarted. A special feature of PCR registers is that when it is necessary to write a new "dimension" to the PCR, the old value is not replaced with a new one, but the old register value and the new "dimension" are concatenated with hashing the concatenation result:
NEW_PCR value = hash of (old_pcr value | dimension value)
This algorithm resembles the "Merkle Tree" used in blockchain technology. Thus, any current value of the PCR register will be the result of previous measurements, which allows you to verify the authenticity of the current PCR value by reproducing all the performed hashing operations of the loaded components.
2.4. RTR (Root of Trust for Reporting): This component receives data from the RTS (i.e., the values of the PCR registers) and allows you to sign them using the AIK private key (Attestation Identity Key, see below). Signed values can be transferred to a validating system ("attester"), which can verify their authenticity using a publicly available TPM certificate. Thus, for example, the integrity and authenticity of the OS boot chain can be verified.
2.5. EK (Endorsement Key, confirmation key): Manufacturers of TPM chips generate a unique pair of asymmetric encryption EK keys (RSA with a key of 2048/3072/4096 bits or ECC P256/P384/P521/) based on a unique sequence of numbers (Endorsement Seed) for each TPM module. However, the created pair of EK keys cannot be exported to another TPM chip, and the certificate of the public EK key is signed by the manufacturer of the TPM module. The EK key allows you to uniquely identify each TPM, and is also used as the root of trust for all keys generated by this TPM for digital signature and device certification. However, EK keys are never directly used - instead, AK keys are created based on EK (similar to how typical PKI infrastructures do not use RootCA directly, but create subordinate subcas).
2.6. AK (Attestation Key, attestation key, in version TPM 1.2 they were called AIK, Attestation Identity Key): AK keys are created on a TPM chip, they are used to certify the device and keys generated by the TPM module and allow you to confirm that the keys were created by a genuine TPM chip. The Attestation Protocol is executed for AK keys: a new AK key pair is generated based on EK, the device sends a certificate request for AK to the corporate Attestation center (Attestation CA) (the request includes the AK public key and the EK certificate), the attestation center verifies the authenticity of the requested device (sends an encrypted challenge to the devicethe request, which is decrypted with the private key EK and sent back), then the attestation center issues a certificate for the public key AK. As a result, the verifying party (for example, a posturing server for remotely verifying the integrity of a device on the network) receives in response to its request an AK-key-signed value of a certain PCR register (this structure is called "Quote", "link"): Attestation CA will be able to verify the signature, and the Quote itself will contain proof that that the OS boot chain on the device connected to the network has not been compromised. The EK key and the AK keys form an Endorsement Hierarchy, in which the keys are not deleted after the device is rebooted.
2.7. SRK (Storage Root Key): Based on a unique sequence of numbers (Storage Seed), when initializing or resetting the TPM module, an asymmetric encryption SRK key pair is generated, unique for each TPM. At the same time, unlike EK keys, a new pair of SRK keys can be generated by the new owner of the TPM chip. The SRK key pair is used for secure storage of other keys created on the TPM chip (with the exception of the EK and AK keys): symmetric encryption keys created by the TPM chip can only be decrypted inside the TPM chip using the SRK private key alone - this is how the "binding" functionality is implemented encryption keys for the TPM module. Using this approach allows you to store securely encrypted keys on an untrusted medium (for example, on a hard disk or in RAM), since the amount of permanent memory of TPM chips must be at least 100 kilobytes according to the specification (although TPM manufacturers can use larger NVRAM modules). In addition to "binding" keys, you can use the "sealing" functionality. sealing) encrypted data: access to SRK to decrypt symmetric encryption keys is possible only if the PCR registers contain certain information - for example, they contain confirmation that the OS boot chain on the device has not been compromised. SRK keys can also be used for device certification: in the challenge certification protocol, the request will be encrypted first with EK (which does not change when the TPM owner changes), and then with SRK (which may change when the device owner changes). The SRK key forms a Storage Hierarchy, the keys in which are not deleted after the device is rebooted.
2.8. In addition to the hierarchy of confirmation (Endorsement Hierarchy) and the hierarchy of storage (Storage Hierarchy), the TPM has a hierarchy of platforms (Platform Hierarchy) - it stores encryption / signature keys that are not deleted after device reboot and are used by the device manufacturer, for example, to verify the integrity of the firmware. In another, fourth, NULL Hierarchy, keys are deleted when the device is rebooted, so this hierarchy is used for temporary storage of data, such as session keys.
3. TPM modules can be discrete (placed on the motherboard as a separate chip), integrated (into the chipset, motherboards), firmware (Intel Platform Trust Technology and AMD fTPM), virtual (vTPM) and software (in fact, TPM emulators are only for experiments), while the most reliable are considered discrete TPM chips.
Let's consider further examples of practical use of TPM modules using the Windows OS as an example:
1. Windows Hello technology allows you to use a "private/public key" pair, while the private key is stored in the TPM, and access to it is provided only after passing biometric authentication (by face, fingerprint) or after entering a PIN code.
2. BitLocker technology allows you to perform full-disk encryption of the drive, while the BitLocker decryption key is stored in the TPM, protected by a PIN code (or biometrics), and access to it is provided using the "sealing" functionality: if the PCR registers contain information about the correct OS boot chain on the device, then access to SRK for decryption of the symmetric encryption BitLocker key is provided. This prevents access to data on the hard disk when trying to boot a third-party OS from external drives, when changing the hardware configuration of the device, when trying to access the hard disk after installing it in another device. At the same time, in Linux-based systems, the drive encryption technology (Linux Unified Key Setup, LUKS) also supports the use of TPM chips to manage disk encryption keys.
3. Measured Boot technology allows you to control the integrity and immutability of the boot chain (UEFI/BIOS firmware, bootloader, OS kernel, OS kernel modules, and device drivers) by sequentially recording "measurements" (hashes from loaded components) in PCR registers, followed by their reconciliation with data recorded in the Windows Boot Configuration Log.
4. Health Attestation technology allows, based on Measured Boot data, to conduct remote attestation on Microsoft Azure Attestation servers using AK attestation keys.
5. Credential Guard technology allows you to isolate the process LSASS.exe responsible for processing user credentials (NTLM hashes, Kerberos tickets) - it is executed in a secure memory area (Virtual Secure Mode), the key for accessing which is protected by the TPM module using the "sealing" functionality.
 (2).jpg)
