Which of the following functions are performed by the trusted platform module (tpm)?

Trusted Platform Module

A trusted platform module (TPM) chip is a processor that can provide additional security capabilities at the hardware level. Not all computer manufacturers employ TPM chips, but the adoption has steadily increased. If included, a TPM chip is typically found on a system’s motherboard.

The TPM chip allows for hardware-based cryptographic operations. Security functions can leverage the TPM for random number generation; the use of symmetric, asymmetric, and hashing algorithms; and secure storage of cryptographic keys and message digests. The most commonly referenced use case for the TPM chip is ensuring boot integrity. By operating at the hardware level, the TPM chip can help ensure that kernel-mode rootkits are less likely to be able to undermine operating system security. In addition to boot integrity, TPM is also commonly associated with some implementations of full disk encryption.

Trusted Platform Module

Some systems have TPM but it may be disabled in the BIOS. To enable TPM, an administrator will need to be at the physical system and enable it prior to boot in the BIOS. While here it is a great idea to create a BIOS password to only allow administrators in the BIOS. Remember as easy as it is to enable TPM, it is also easy to disable it. TPM may be managed with two different tools in Windows 7: TPM Management by typing tpm.msc in the Start menu Search or TPM Security Hardware by typing tpminit in the Start menu Search.

Once TPM is enabled and either of the management tools accessed, the administrator will need to create a TPM owner password:

Type tpminit in the Start menu Search.

The computer may need to reboot to enable TPM or reset TPM firmware through the BIOS.

Select Automatically create the password or Manually create a password. If creating your own network, ensure it is a long passphrase. The longer it is, the more difficult it will be to crack. Include all types of characters.

Save the password, print it, or save it to a USB for when the computer needs to be decommissioned or managing TPM in the future.

Click Initialize.

Tip

TPM and full disk encryption should be setup by an administrator especially if the system is a corporate asset. If an end user performs this setup and then is let go or decides to leave, it will be very difficult to recover the TPM password or full disk encryption password. Key management is a very important aspect of encryption.

To manage TPM once it has been initiated for the first time, type tpm.msc in the Start menu Search to start the TPM Management MMC as shown in Figure 8.35. TPM may be turned off from the Action panel by clicking Turn TPM Off. This will turn off TPM but not clear the owner password. The password should be kept until the TPM is cleared. To clear the TPM, click Clear TPM on the Actions panel. This will clear the TPM to factory defaults and all TPM keys and data protected by the keys lost! The TPM owner password may also be changed from the Actions panel and requires the password or user to be logged in by clicking Change Owner Password.

BitLocker with TPM may be used for full disk encryption with the following modes:

TPM-Only – Only the TPM is used to validate the boot files, operating system, and encrypted volumes. This is transparent to the user and will allow other users onto the hard drive. Therefore, this mode is not recommended as it will not provide the key benefits of full disk encryption. If TPM is missing, BitLocker will enter Recovery mode and will require the recovery key or password.

TPM and PIN – This uses TPM and a user inputted PIN. If either is missing, BitLocker will enter Recovery mode and will require the recovery key or password.

TPM and Startup Key – This uses TPM and a startup key located in a USB device. The user must have the USB device to boot the system. If either is missing, BitLocker will enter Recovery mode and will require the recovery key or password.

TPM and Smart Card Certificate – This uses TPM and a smart card provided by the user. If either is missing, BitLocker will enter Recovery mode and will require the recovery key or password.

Computers that do not have TPM may use Startup Key Only or Smart Card Certificate Only mode to decrypt the hard drive and have access to the files. These options are viewed in the next section.

Digital Rights Management

The TPM is a part of what Microsoft is calling its Next-Generation Secure Computing Base (NGSCB), or System Integrity, which was originally codenamed Palladium. Many saw the initiative as a way for Microsoft to implement, and to allow others to implement, very strong Digital Rights Management (DRM) protections. This has not changed much in the years since it was first announced, and at this time, there is a great deal of skepticism and an outcry against the NGSCB.

You’ll notice that we have not mentioned DRM in this chapter until now, and we’ve done that for a reason. The TPM, Windows Vista’s TPM Services, and the NGSCB overall, provide a great deal of functionality. You can use some of that functionality to implement DRM techniques that are stronger than anything media pirates have come up against thus far. That is sure. However, as you have seen throughout this chapter, the TPM is not about DRM. It is a device centered on cryptography, providing key storage locations, cryptographic functions, and hashing functions. Yes, you can use those cryptography features to implement DRM applications, but you can also use them to implement a great number of security features and applications.

Therefore, we could have spent the entire chapter participating in the flame war that rages on the Internet about the TPM and Microsoft’s NGSCB, or we could have a productive discussion about how the TPM works, what it can be used for, and how Windows Vista takes advantage of it. If we had taken the first route, you’d end up with some gross misconceptions about the TPM and everything related to it, and you wouldn’t be equipped to implement Windows Vista on TPM-equipped devices.

However, it would be just as misleading if we did not mention DRM at all in the chapter. So, keep in mind that there are DRM applications for the TPM as well. One TPM feature that will be especially useful to those who want to implement DRM is the device authentication feature the TPM provides. You may buy a song via download with a usage right that limits playback of the song to that device alone. The TPM can seal a key that will be used to encrypt the song, and the song cannot be decrypted and played back from another system.

Hardware-Based Approach

Verifying the runtime using a software-based file integrity tool such as Tripwire provides us with a good level of trust of our runtime. The software responsible for the runtime verification will be “awakened” once in a while (usually by the OS scheduler), and will detect any modifications if they occur.

Though this gives us a solution to the specific problem of runtime file modification by verifying the runtime file's integrity, no one can assure us of the integrity of the tool itself, which can suffer from the same problems it should defend against. So, it seems like we need to perform this kind of verification at the OS level—but the same problem is also relevant to the OS, which can be influenced by a kernel-level rootkit. How can we be assured that the OS has not been tampered with? Do we need to trust the boot loader, running before it? Who can assure us of the boot loader's integrity?

This is a classic “chicken and egg” problem, in which software potentially vulnerable to offline attacks and other types of manipulation cannot be trusted. We need a way to stop it, by means of an entity that can assure us that the software has not been manipulated. And that entity can only be implemented in hardware, such as when utilizing a Trusted Platform Module (TPM).

A TPM provides hardware-level encryption functionality to a system. It is a hardware chip specified by the Trusted Computing Group (TCG),F formed by IBM, Intel, Microsoft, HP, AMD, and others. Implemented as an additional processor often placed on the motherboard or as part of another chip, it is used as the first element in a “chain of trust” relation (discussed shortly), by providing secure storage for crypto master keys or computed hashes, and secure key generation. The significance of the TPM is that all the sensitive cryptography operations are performed in hardware, separated from the OS memory space, which has a greater attack surface and weak points toward the manipulation threat. The TPM contains a separate processor and a limited amount of internal storage for performing cryptography and does not rely on the OS, which is more exposed to software manipulation.

Built on top of its crypto low-level services, an important usage of a TPM in our context is the verification of software integrity.

Note

TPMs are preinstalled on many computers, yet very few people/organizations utilize them to protect their machines.

A TPM is a good, cost-effective mechanism that requires minimal resources, yet significantly increases the general security level of a system by protecting it against sensitive data modification and disclosure.

The TPM contains a unique permanent RSA key pair called the Endorsement Key (EK), burned into the chip at the time of manufacture. The EK is used to derive other keys from it to perform cryptographic operations and to identify the system using that TPM. For protection, the EK is kept inside the TPM and never leaves it, so it is not accessible to the system software.

When a TPM is used for the first time, defined as the “taking ownership” operation, the TPM creates a Storage Root Key (SRK) key pair, based on the EK and the system administrator's provided password, which resets any previous information stored in the chip.

The TPM also creates an Attestation Identity Key (AIK) used to protect any changes to firmware and software. The AIK is used to hash sensitive sections (such as the BIOS, loader, kernel, etc.) using the SHA-1 function and store the results (“measurements”) inside the TPM storage, called the Platform Configuration Register (PCR). On each system boot, the system measurements will be compared with those stored in the TPM, and if there's a match the system will be considered trusted. Anyfailure in verifying the system integrity will result in locking the machine while stopping the boot process. This way, if the machine has been manipulated, the TPM will be able to detect the manipulation without relying on the machine's own software. Using the same mechanism, the machine can also prove its integrity to remote machines, by sending signed hashes calculated based on the current machine state (e.g., an external machine observing the baseline signatures of some protected files).

A TPM, as a disconnected hardware device out of reach of the software that it is supposed to protect, provides an end to the software verification problem in which software is guarded by another piece of software susceptible to the same problem against which it is supposed to guard. It pushes the problem down by adding a hardware-level counterpart that provides a higher level of security, compared to software.

Essentially, the TPM creates a chain of trust in which it serves as the root in the chain of integrity verification of multiple parts of the computing environment required for the creation of a trusted boot path. It serves as the first verification performed in the system, in which the basic characteristics of the system are verified. Moreover, the TPM verifies that the BIOS can be trusted, in which case it passes control to it. The BIOS, after being verified, will check the next link following it, which is the Master Boot Record (MBR), which in turn checks the OS loader, which will check the OS itself (and especially the kernel), and following that the application runtime libraries.

Combining this approach with a software integrity solution (as discussed earlier) to protect an application VM runtime library with a chain of trust can prevent the manipulation of the software baseline itself. Software such as Tripwire would be responsible for verifying the runtime integrity based on its baseline, while the chain of trust would be responsible for verifying the system integrity while covering the software baseline.

Figure 9.4 illustrates the chain of trust.

In this model, every layer is responsible for verification of the next layer after it so that the machine as a whole is considered trusted only if the whole chain is verified. Only one broken link will result in the chain of trust being unverified.

Note

The trust must come from somewhere. The TPM is the only link in the chain that is “self-trusted,” and its security is implemented in hardware. This doesn't make it unbreakable; it just makes it more difficult to break because breaking it requires more resources and specialized tools.

To use the TPM (after making sure the system is equipped with one), you need to turn it on in the BIOS.

Then, you need to enable the TPM and initialize it by taking ownership of it, while running with administrator privileges. For example, performing the preceding steps in the Windows OS (starting with Windows Vista) is done using the Trusted Platform Module Management console accessed from the MMC console or directly by launching tpm.msc from the command line.

Running it for the first time, before initializing the TPM, results in the screen shown in Figure 9.5, which contains the only option for initializing it.

After clicking on Initialize TPM to turn it on and initialize its content, we will be asked to shut down the system (see Figure 9.6), and later to assign a password for its protection. The password protects the TPM against unauthorized access to the TPM content and management operations.

After the TPM is ready to be used, you'll need software that will utilize it to check system integrity. An example of such a tool is BitLocker, which is integrated into newer versions of the Windows OS, such as Windows 7 and Windows Server 2008 R2. BitLocker provides validation of the OS boot process while encrypting the machine's hard drive by utilizing the TPM to protect the encryption keys. Besides protecting the system's confidentiality, it serves as a system integrity tool. At boot time, it allows only authorized users to start the system (see Figure 9.7) while verifying that the boot data has not been tampered with.

BitLocker is an example of software that drives the TPM, which is the main component leveraging the security level of a system. Now that the system is protected with a hardware-level TPM module and software-level file integrity monitoring, an attacker will need to invest a lot more effort to tamper with the runtime binaries to deploy an MCR. Granted, this is not a bulletproof solution (there's no such thing, aswe mentioned previously), but it does give us an added advantage in terms of detecting malicious activities.

4.3.7 Trusted platform module

The Trusted Platform Module offers facilities for the secure generation of cryptographic keys, and limitation of their use, in addition to a random number generator. It also includes capabilities such as remote attestation and sealed storage.

Remote attestation creates a nearly unforgeable hash-key summary of the hardware and software configuration. The program encrypting the data determines the extent of the summary of the software. This allows a third party to verify that the software has not been changed.

Binding encrypts data using the TPM endorsement key, a unique RSA key burned into the chip during its production, or another trusted key descended from it.

Sealing encrypts data in similar manner to binding, but in addition specifies a state in which the TPM must be in order for the data to be decrypted (unsealed).

Software can use a Trusted Platform Module to authenticate hardware devices. Since each TPM chip has a unique and secret RSA key burned in as it is produced, it is capable of performing platform authentication and as such is a key part of secure boot.

Generally, pushing the security down to the hardware level in conjunction with software provides more protection than a software-only solution. However even where a TPM is used, a key would still be vulnerable while a software application that has obtained it from the TPM is using it to perform encryption/decryption operations, as has been illustrated in the case of a cold boot attack. This problem is eliminated if key(s) used in the TPM are not accessible on a bus or to external programs and all encryption/decryption is done in the TPM.

Bitlocker and Hyper-V

BitLocker works with the Trusted Platform Module (TPM) chip in supported systems to encrypt the data partitions of your hard drives. A Virtual Hard Disk (VHD) or virtual machine configuration can be placed on a BitLocker encrypted partition to allow the data contained on the VHD to benefit from this security as well—regardless of the guest operating system. This allows you to extend the protection of BitLocker to incompatible and legacy Windows operating systems. Once BitLocker is enabled on your host system, and the drives prepared and encrypted, the only step required is creation of the virtual devices on the encrypted drive.

Trusted Platform Module

Developed and updated by the Trusted Computing Group, a Trusted Platform Module (TPM) chip is a processor that can provide additional security capabilities at the hardware level. Not all computer manufacturers employ TPM chips, but the adoption has steadily increased. If included, a TPM chip is typically found on a system’s motherboard.

The TPM chip allows for hardware-based cryptographic operations. Security functions can leverage the TPM for random number generation, the use of symmetric, asymmetric, and hashing algorithms, and secure storage of cryptographic keys and message digests. The most commonly referenced use case for the TPM chip is ensuring boot integrity. By operating at the hardware level, the TPM chip can help ensure that kernel mode rootkits are less likely to be able to undermine operating system security. In addition to boot integrity, TPM is also commonly associated with some implementations of full disk encryption. With encryption, the TPM can be used to securely store the keys that can be used to decrypt the hard drive.

Given the storage of highly sensitive and valuable information, the TPM chip itself could be targeted by adversaries. With TPM being hardware-based, tampering with the TPM remotely from the operating system is made much less likely. The TPM chip also has aspects of tamper proofing to try to ensure that a physically compromised TPM chip does not allow for trivial bypass of the security functions offered.

Turning on BitLocker on Systems without a TPM

Turning on BitLocker on systems without a TPM is similar to the normal activation process. Make sure you have a USB flash drive available to store the startup key.

Log on as an administrator.

Click Start, click Control Panel, and then click BitLocker Drive Encryption.

On the BitLocker Drive Encryption page, click Turn On BitLocker on the operating system volume.

On the BitLocker Drive Encryption Platform Check dialog box click Continue with BitLocker Drive Encryption.

On the Set BitLocker startup preferences page select Require Startup USB key at every startup (see Figure 5.12).

On the Save your Startup Key page select your USB drive from the list and click Next.

On the Save the recovery password page, click Save the password on a USB drive.

On the Save a Recovery Password to a USB Drive Box, select your USB drive and click Save.

On the Encrypt the selected disk volume page, confirm that the Run BitLocker System Check checkbox is selected, and then click Continue.

Confirm that you want to reboot.

BitLocker

BitLocker, which hit the scene with the advent of Windows Vista, is (at the time of this writing) available in Vista Enterprise and Ultimate, as well as Server 2k8 (and is listed as a planned feature in Windows 7). According to Microsoft, its stated purpose is to protect “against data theft or exposure on computers that are lost or stolen, and offers more secure data deletion when computers are decommissioned” (Microsoft, 2008b). It does this by providing users with a built-in “whole-disk” encryption solution.

BitLocker is designed to function together with a hardware chip called a Trusted Platform Module (TPM) (usually built into the system/motherboard), which stores the encryption/decryption keys (called a Full Volume Encryption Key, or FVEK) and releases them only after verifying the integrity of early boot components and boot configuration data. In short, the practical effect is that the TPM will allow a BitLocker-encrypted drive to be booted (and decrypted) only if the drive is located in its original computer. BitLocker and its TPM can also work in conjunction with a PIN and/or a USB device containing the required keys.13 To properly function, BitLocker requires at least two partitions, with one being reserved as a system partition of at least 1.5GB on which boot files and the Windows Pre-execution environment are stored, and the identification of such a partitioning scheme could indicate BitLocker's use.

Regardless of the specific implementation, failing to recognize the use of BitLocker in advance of acquiring a traditional forensic image can leave the examiner unable to access the data in the image. A quick look at each volume's primary volume boot sector (sector offset 3) can reveal whether the volume is BitLocker-encrypted. In place of the normal OEM vendor name (usually NTFS in Vista), the examiner will see -FVE-FS- (\x2d\x46\x56\x45\x2d\x46\x53\x2d), indicating that the volume is covered by Full Volume Encryption (BitLocker). Alternately, when digital investigators are dealing with a live system, on a computer running a BitLocker-capable version of Vista (or Server 2k8), executing the manage-bde.wsf script will display the BitLocker status of volumes for which it has been implemented. If the script is run and no results are returned, it is usually safe to assume that BitLocker is not being used on the system.

Practitioner's Tip: Bring Your Own Tools

As with most commands/binaries used in incident response, examiners should roll with their own tools, and (if at all possible) not rely on those already present on the system to be examined. Examiners should also note that they may be required to run this script in conjunction with the Windows script host, cscript.exe. Both manage-bde.exe and cscript.exe are located in c:\windows\system32 and can be added to a response toolkit.

Ideally, forensic examiners want to have the keys to decrypt an encrypted drive. BitLocker keys (64-bytes in length) are held in memory while the system is up and running, and researchers are making an effort to develop practical methods for locating and then utilizing such information (Kornblum, 2009). However, these techniques are in their early development and may not be feasible in certain investigations. The simplest approach is to recover the key when the system is still running and digital investigators can use the manage-bde.wsf script to obtain the BitLocker recovery password (Mueller, 2008). Running the following command in the console will provide an examiner with the recovery key and numerical recovery password for the specific BitLocker-encrypted volume (D:\, in this example):

cscript manage-bde.wsf –protectors –get d:

Once the examiner has the recovery password, a copy of the BitLocker-encrypted drive can be connected to a forensic system running Vista (or a BitLocker-aware forensic suite, such as EnCase Forensic with its Decryption Suite module) and the data can be recovered by simply supplying the recovery password when prompted.

Once running, it is possible to temporarily disable BitLocker (e.g., cscript manage-bde.wsf –protectors –disable d:). It is also possible to permanently decrypt the data via the BitLocker Drive Encryption interface, if permitted to do so by the data/drive owner; however, permanently decrypting the data would mean a tremendous impact on the in situ state of data on the drive, which is a situation normally eschewed in forensic and legal circles. With that said, the best way to image a computer running BitLocker may be to image it live (e.g., obtain a logical image of the BitLocker-encrypted volume). Although this is not the preferred method of forensic imaging according to traditional forensic dogma, obtaining a logical image from a running system does currently represent an examiner's best chance to obtain valid, usable data for the furtherance of their investigation, while (if done with proper forensic tools and methodology) having a far more minimal impact on the affected system.

So, what are an examiner's options? The investigator can always hold out hope that the owner of the system they wish to examine will consent to the examination and the booting of their computer, and willingly provide any items needed to boot the system (e.g., PIN, FVKE on USB, etc.).14 Within corporate or government environments running BitLocker-encrypted systems, a network administrator will often have a master key to unlock the computers. However, once a protected computer is booted in such a manner, the data is still technically encrypted, meaning if the system were to lose power the data would again become unreadable.

It should also be noted that Windows 7 contains another BitLocker feature that will be of interest to investigators: the ability to BitLocker-encrypt removable media (such as a thumb drive) via a user-friendly right-click option. Once encrypted, a BitLockered-thumb drive, for example, will be protected from unauthorized access when not plugged into the Windows 7 machine that encrypted it. Such a drive will be transparently accessible to the user when plugged into its home machine, and accessible via password when plugged into any other computer running a Windows OS.

3.7 Securing point to point (P2P) communications

Table 4 contains a list of features which are used to establish secure P2P communication between DWs.

Table 4. Features used to establish secure P2P communication.

The mobile devices within the DW ecosystem must contain tamper proof mechanisms such as trusted platform modules (TPM) and secure elements (SE) as for storing DE. The DE is associated to the DW who generated it, and a DID is the identity mechanism for binding the identifier to the user.

The DID can provide the identity owner with privacy by using pairwise unique DIDs for each relationship, for example, between DW and DW or between DW and DC, but this can only be done by establishing an encrypted private channel between their endpoints or mobile devices. These DIDs act as pseudonyms which rely on private software agents that are installed on the mobile devices, but to ensure that the owner is always addressable, an agent can be run on a trusted intermediary or agency which will host the pseudonymous network address.

In the event of a lost, faulty, or breached mobile device, the DWs have the ability to recover their keys which are stored on their mobile devices. This is done through the mobile application via quorum of appointed trustees that the Stewards on the ledger must verify.

Fig. 12 demonstrates the secure private channel between DW user C and DW custodian F; the chain-like image represents the immutable identifier record in the ledger.

Fig. 13 demonstrates the collaboration between the DWs, BC, and the trusted institutions. The DC in the example shows how one user may have multiple identifiers, that is, ‘did:net:123456789:abcdefg’ and ‘did:leg:0123456789:abcdefzz’, and in this case the DC is a regular user in one ledger but holds elevated permissions on another.