in 2019; given a swathe of Rowhammer and Spectre attacks, fundamental issues with the security of CPUs have been raised repeatedly. Now at the close of the year, we have an issue specific to the hardware security modules known as "TPM".
Devices compliant to the Trusted Platform Module standard (see the most recent revision from 2016) have been around for some time. Microsoft's Bitlocker software can use one to store the secret keys for full disk encryption. And this integrates into the UEFI "Secure boot" system to ensure the FDE keys are ONLY released if the firmware and bootstrap software images have the correct hash values (that is, the ones they had when the key was written into the TPM). The TPM can also be used in the same manner as other HSM tokens (such as the yubikey) to store the secret key for a PKI keypair and compute digital signatures and decrypt data with that key without the actual key ever leaving the hardware.
Given the availability of these modules "onboard" many computers, it is perhaps inevitable that some Digital Rights Management systems use them to "lock" certain content to a single, physical device. It may be equally inevitable that some of the owners of such devices would very much like to extract the private key themselves. (They would be in the dubious company of criminal attackers of course, and even government agencies like the FBI, but the device owners are a significant group too).
For cases where the TPM is a separate, discrete chip on the board, this can be a danger to the Secure Boot process. Back in March of last year, a researcher for Pulse Security announced he had been able to "listen" to the data being sent between the CPU and the TPM chip, and thus "hear" the Bitlocker key being released to the boot loader. This led to warnings to avoid using TPM to secure Bitlocker. Perhaps obviously, a similar attack could be used to find the per-file encryption key for DRM-protected media, but crucially, not the private key itself (as that is never sent, just the results).
However, there IS a way to calculate a private key purely from the results of legitimate signing and decryption requests—and that is by observing (with a high-precision timer) while the device performs the math needed to decrypt or sign. How many forms of math (especially exponentiation) work in computers is that one of two numbers in the computation is repeatedly multiplied, either by 2 (for straight multiplication) or by itself (exponentiation). If a bit in the OTHER number is set, then this intermediate result is added (or multiplied) with the working value. If it is not, then this bit can be skipped and the calculation move on immediately to the next multiple of the intermediate.
In its purest form, this is a "timing attack." You can make this easier if you can choose (rather than just passively observing) which numbers are sent to the device for signing or encryption, and also if you can observe the actual power usage of the chip as it operates rather than just timing how long the total operation takes (this is called a "power analysis attack"). Combining those two is a "differential power analysis" (DPA) and is a type of chosen-cyphertext attack on the device. (All these attacks are considered "side-channel" attacks, as a class).
This, again, is not new. Back in 2017, an HSM from the company "Infineon" was found to be vulnerable to such an attack, leaking its RSA keys. In response, the company released updated firmware for its devices, which fixed the issue by ensuring the response always took a constant time, not replying as soon as the calculation was complete. (NOTE: This constant time "fix" is common in the industry, and in fact is one of the things to be tested in order to obtain FIPS or EAL4 certification—somewhat an embarrassment for Infineon, and more so for the lab that issued their certified rating for this chip).
So yeah, that happened, way back in 2017. Which got a group of researchers to thinking, “We know at least one TPM chip didn't properly implement constant time for RSA... what about for other key types?” Increasingly, asymmetric encryption is done using either Diffie-Hellman or Elliptic Curve keys, not RSA. (NOTE: interestingly, the latest generation of SSL, the TLS 1.3 standard, has NO suites where RSA is used for encryption. It is relegated to digitally signing a hash of the DHE or ECDHE exchange, in order to avoid man-in-the-middle attacks).
So, one quick purchase of a box-load of TPMs later, and almost all of them passed the test... but two didn't (and hey, it only takes one.) The first is an STMicroelectronics TPM chip called a "ST33TPHF2ESPI" (catchy name, but...). And the second is a device by Intel. Leaving aside the STM chip for now, we should look at the Intel version of this problem, because it isn't in fact ONE chip that is affected, but a large number of them.
Looking back at the "sniffing" and DPA attacks, we can see that allowing an attacker to access the wires attached to a TPM is a danger, in and of itself. Intel addressed this issue by moving the TPM onto the same die as the CPU itself. By integrating this "firmware TPM" into their design, at one stroke they removed two analysis threats, and both simplified and cheapened the final solution.
Indeed, the TPM no longer needed to be manufactured separately, and board manufacturers no longer needed to find a place to site one, then run wires to it in their board layouts. But as a consequence, across an entire range of Intel's products, there is a vulnerable TPM lurking inside the same package as the CPU. Luckily, Intel learned its lesson from the infamous "Pentium" math bug. Intel CPUs can be fixed with a firmware patch, and in fact such a patch has already been issued for affected CPUs. STMicroelectronics similarly has an updated firmware image for their chips to resolve this issue.
In practical terms, this is more of a concern for server operators than users. The White Paper written by researchers details a working, fully remote attack against an installation of StrongSwan (IPSec VPN server software) configured to use the TPM for its ECDSA signatures. This attack took a very large number of key operations (around 40,000) but took place entirely over the network connection, using only normal communications with the server (so is a risk for any real-world systems so configured). So, if you ARE operating a server using the TPM to "improve security" you probably should patch this now.