How do I get rid of TPM error?

To clear the TPM Open the Windows Defender Security Center app. Select Device security. Select Security processor details. Select Security processor troubleshooting. Select Clear TPM. You'll be prompted to restart the computer. Jul 31, 2023

Is it OK to clear TPM?

As discussed above, clearing TPM will lead to all TPM-protected keys and data loss such as BitLocker encrypted drive. So, it's crucial to back up the data beforehand. How to make a backup quickly? MiniTool Partition Wizard is a trustworthy tool.

Why Windows 11 is forcing everyone to use TPM chips?

Its purpose is to protect encryption keys, user credentials, and other sensitive data behind a hardware barrier so that malware and attackers can't access or tamper with that data. TPMs work by offering hardware-level protection instead of software only.

Is enabling TPM a good thing?

It's an added layer of protection so potential malware cannot access any credentials, encryption keys, and other very sensitive user data stored in your system. Think of the TPM as the fingerprint or facial recognition system on your smartphone. Without the correct biometrics, you can't access any information.

What causes TPM failure?

Most TPMS failures are caused by tire pressure sensors that have reached the end of the road . The batteries inside the tire pressure sensors have a service life that typically ranges from 5 to 7 years.

What causes TPM malfunction?

A message stating "TPM Chip Malfunction" may pop up in Microsoft Teams or in Office 365 applications. This message appears when the computer stops recognizing the built-in Trusted Platform Module security chip. Another symptom of this issue is constantly being prompted for a BitLocker recovery key.

TPM Usage (2024)

For Developers > Design Documents >

Introduction

This document describes the usage of a Trusted Platform Module (TPM) in Chromedevices (Chromebook or other form factors), including firmware, operatingsystem, and applications. It assumes some knowledge of Chrome OS concepts aswell as TPM functions. It may be of interest to Chromium OS developers who wantto use the TPM and to users who wish to understand the usage of the TPM inChrome OS.

Chrome OS uses the TPM for these tasks:

Preventing software and firmware version rollback
Maintaining information to detect transitions between normal anddeveloper modes
Protecting user data encryption keys
Protecting certain user RSA keys (‘hardware-backed’ certificates)
Providing tamper evidence for installation attributes
Protecting stateful partition encryption keys
Attesting TPM-protected keys
Attesting device mode

The TPM is not directly available outside of Chrome OS for any purpose; that is,no remote computer has access to the TPM.

Chrome OS does not use the TPM for the following:

Trusted boot - the TPM is not used as part of the Chrome OS verifiedboot solution.
Hardware-strength platform configuration reporting. See AttestingDeviceModefor more details.
Whole-disk encryption or similar. In particular, the TPM is not usedto unwrap an encryption key during the boot process.

The rest of this document first discusses the four different modes of operationof Chrome devices; then it describes how Chrome OS controls TPM ownership; andfinally it presents each area of TPM usage in detail.

Modes of Operation

A Chrome device can be booted in four different modes, corresponding to thesettings of two switches (physical or virtual) at power on. They are thedeveloper switch and the recovery switch. They may be physically present on thedevice, or they may be virtual, in which case they are triggered by certain keypresses at power on. When both switches are off, the boot is called normal modeboot. When the developer switch is on, it is called developer mode boot. Whenthe recovery switch is on, it is called recovery mode boot (and normal-recoveryor developer-recovery when there is a need to distinguish them).

TPM Ownership and Restrictions

Most of the TPM functionality becomes available after a TPM owner isestablished. In normal mode, Chrome OS attempts to establish a TPM owner with arandom password, which is generated only after the owner of the Chrome devicestarts using it. When the owner password is created, there is a period of timein which the user can find out what it is and write it down. After this period,the password is destroyed. However, knowledge of the owner password is notnecessary at any point in Chrome OS.

Under certain conditions, the TPM owner will be cleared, rendering keyscurrently protected by the TPM useless (and therefore the data protected bythose keys unrecoverable). These conditions are as follows:

On the first power-on after switching to developer mode, the TPM iscleared by the firmware before the OS kernel begins booting.
On the first power-on after switching to normal mode, the TPM isalso cleared by the firmware before the OS kernel begins booting.
During a recovery mode boot in normal mode, a Chrome OS recoveryimage will clear the TPM before the device is rebooted.
Some Chrome devices allow the system (or, if in developer mode, theuser) to explicitly request that the TPM owner be cleared on thenext reboot.

When a non-Chrome OS image is booted in developer mode, it is up to thatuser-installed OS to decide whether or not to take ownership, or do anything atall with the TPM. The user-installed system, for example, may create additionalTPM NVRAM spaces other than those that Chrome OS creates (e.g., see RollbackPreventionbelow).

Note the following developer mode restrictions on the TPM:

The TPM physical presence command is disabled by the read-writefirmware on every boot. This means that physical presence cannot beasserted even by a custom OS.
The NVRAM firmware space (see RollbackPreventionbelow) cannot be removed.
The NVRAM kernel space (see RollbackPreventionbelow) can be removed, but doing so will result in the firmwareforcing recovery mode at the next boot.

In the event that the NVRAM kernel space is removed, the device will only boot aGoogle-provided recovery image, which will try to reconstruct that space. ChromeOS recovery will aggressively destroy other spaces as needed to make room.

Rollback Prevention

The normal boot process of a Chrome device follows a chain of trust, in thefollowing order:

Read-only section of firmware (set during factory installation andunchangeable in software)
Upgradable section of firmware (called read-write firmware)
Kernel
Programs and services that comprise the operating system

Each link in the chain is responsible for verifying that the next link has notbeen tampered with before yielding control to it.

Read-write firmware and kernel can be updated, either manually (through a“recovery” process) or automatically. For security, the automatic update processdoes not allow updating to versions of the software that are older than thecurrent one. This prevents “remote rollback attacks,” in which a remote attackerreplaces newer software, through a hard to exploit vulnerability, with oldersoftware, with a well-known and easy to exploit vulnerability.

To prevent remote rollback attacks, Chrome devices reserve two small NVRAMspaces in the TPM to store version numbers and other information. These NVRAMspaces are called “firmware space” and “kernel space.” They are created duringfactory initialization and are never removed. (The kernel space can be removedin developer mode, but the firmware space cannot. Also note that a Chrome OSrecovery image will try to recreate the kernel space, possibly removing otherspaces to make room.)

The firmware space contains the read-write firmware version number (among otherthings). It is created with permission TPM_NV_PER_GLOBALLOCK |TPM_NV_PER_PPWRITE, and is locked by setting the TPM bGlobalLock bit. On anormal boot, this space is locked by the read-only firmware, possibly afterupdating it to reflect the version of the verified read-write firmwareinstalled. As mentioned, this update may only replace the current version numberwith a larger one.

The kernel space contains the kernel version number. It is created withpermission TPM_NV_PER_PPWRITE. On a normal boot it is locked by turning off andlocking physical presence in the read-write firmware. As in the case of thefirmware space, the read-write firmware will update this number to the versionnumber of the current kernel.

On a recovery boot (either in normal or developer mode), neither the firmwarenor the kernel space is locked. Therefore the recovery image can bypass theanti-rollback mechanism. Bypassing the anti-rollback mechanism is allowedbecause there are legitimate cases in which it is desirable to install olderversions of the system, as long as this rollback does not happen without theknowledge of the user.

Protecting User Data Encryption Keys

User data in Chrome OS is encrypted when stored on the disk using the eCryptfsstacked filesystem. When a user logs in for the first time, two random 128-bitAES keys are generated. One key is used by eCryptfs to encrypt file names, andthe other is used to encrypt file content. These keys are managed locally; theyare not escrowed outside of the Chrome device. This allows users to log in andaccess their data while offline and also means that the keys never need to leavethe device. However, this feature also necessitates a strong method ofprotecting these keys from disclosure as they are stored in a persistent file ondisk.

Chrome OS uses the TPM to make parallelized attacks and password brute-forcingdifficult. One feature and one characteristic of the TPM are exploited here.First, the TPM provides secure key storage for RSA keys. This means that theprivate key only exists in plain text while it resides on the TPM itself--it canonly be stored outside of the TPM in encrypted form. This feature makesparallelizing difficult: decrypt operations involving that key must happen onthe TPM itself (unless a vulnerability exists whereby the attacker can obtainthe plain-text private key of a TPM-wrapped RSA key). Second, the TPM is arelatively slow device. Private key operations can take over half a second tocomplete; this provides a level of brute-force protection by effectivelythrottling the rate at which guesses can be made.

To protect the user keys, Chrome OS creates a system-wide RSA key wrapped by theTPM’s Storage Root Key (SRK) on first boot. When storing a particular user’s AESkeyset, Chrome OS encrypts the keyset using a random symmetric key. Thatsymmetric key is encrypted using the system-wide RSA key. To tie the decryptionto a user secret, 128 bits of this encrypted blob are encrypted a second timeusing a key derived from the user’s login password. Since this step is donewithout padding, any decryption must blindly decrypt those 128 bits and thendecrypt the entire blob on the TPM before knowing if the decryption process (andtherefore the password) was correct. Using this method (over per-user TPM keysrequiring authentication) has the benefit of avoiding the TPM’s dictionaryattack defense, which is overly aggressive for use during user login.

There are two important implications to the use of the TPM to protect user data:

If the TPM is cleared, user data protected by it cannot berecovered. In this case, Chrome OS removes user data.
If the TPM is somehow disabled or faults, user data cannot beaccessed. Chrome OS will fail logins for existing users until theTPM is enabled.

Protecting Certain User RSA Keys

Chrome OS implements TPM-backed cryptographic services via the Chaps PKCS #11component. (More information about Chaps can be found in the Chaps TechnicalDesign.) RSA private keysgenerated or imported into a Chaps PKCS #11 token with a modulus size supportedby the TPM (typically up to 2048 bits) will be wrapped by the TPM Storage RootKey (SRK). Each user account on the device has a distinct token. A user canimport a certificate and private key into his TPM-backed token by using the‘Import and Bind’ operation available in Chrome’s certificate manager. Also, anykeys generated using the Webkit ‘keygen’ tag will use the TPM-backed token bydefault.

RSA private keys that are not supported by the TPM and all other PKCS #11 data(certificates, public keys, data objects, TPM-encrypted key blobs, etc.) areencrypted with a symmetric key and stored in /home/chronos/user/.chaps. Thissymmetric key is itself encrypted using a TPM-backed key which requires a valuepartially derived from the user password for authorization. Thus, a user’s Chapstoken can only be decrypted if both the TPM and the user password are available.

Tamper-Evident Installation Attributes

The first time a device is used, a set of installation attributes is stored onthe device and remains tamper-evident for the remainder of the install (i.e.,until the device mode changes). If a device has been enterprise enrolled, asevidenced by a ribbon with text like “This device is owned by yourcompany.com,”then the installation attributes correspond to this enrollment. If not, the setof attributes is empty. Either way, the tamper-evidence for the set ofattributes is implemented by computing a salted hash of the attributes andstoring the random salt and the hash in TPM NVRAM with TPM_NV_PER_WRITE_DEFINEpermissions (i.e. read-only until destroyed by the TPM owner). The hash can thenbe verified at any time to ensure the attributes have not been modified. Thistamper-evident container is referred to as the “lockbox.”

Stateful Partition Encryption

Some parts (e.g., /var, /home/chronos) of the stateful partition are encryptedusing dm-crypt. The encryption key is randomly chosen via the TPM’s RNG on firstboot and is encrypted by a TPM-held “system key” (read from TPM NVRAM duringstartup). This system key is actually the random salt used for hashinginstallation attributes.

Attesting TPM-Protected Keys

If an RSA private key has been generated in the TPM and has always beennon-migratable, then the key may be certified by a key that has been verified asan Attestation Identity Key (AIK). No key, including any AIK, is certifiedunless the user or device-owner has consented to remote attestation of his orher device. A certified key credential gives very strong assurance that the keyis protected by a Chrome Device TPM.

Attesting Device Mode

At boot time, the read-only firmware extends TPM PCR0 with the status of thedeveloper and recovery mode switches. The value of PCR0 can later be quotedusing a key that has been verified as an Attestation Identity Key (AIK). Thequote, in combination with the AIK credential, gives assurance that the reportedPCR0 value is accurate. While assurance of the PCR0 value is very strong,assurance that this correctly reflects the device mode is weaker because of thereliance on read-only firmware to extend PCR0. It is nonetheless useful forreporting policy compliance. This PCR0 quote is not available outside of ChromeOS unless the user or device-owner has consented to remote attestation of thedevice.

Chrome OS-Specific TPM Configuration

Under Chrome OS, there are a few configuration settings for the TPM that maydiffer from other operating systems:

TPM ownership, as discussed above, is automatic and random. Whilethe user may choose to write the random owner password down, it isnever used. Rather, TPM ownership is established merely to enablethe cryptographic features (such as using keys wrapped directly orindirectly by the SRK) that Chrome OS uses in the TPM.
The Storage Root Key (SRK) is unrestricted so that it can be usedwithout the owner password. Since the TPM is used as a genericcryptographic device, and Chrome OS manages clearing the TPM infirmware as necessary, unrestricted use of the SRK is allowable.
In Chrome OS, the TPM is only used locally on the Chrome device.Chrome OS uses TrouSerS for communication with the TPM, which hasbeen patched to use a UNIX domain socket instead of a TCP socket.
Under Chrome OS, physical presence is disabled on every boot by theread-write firmware.