TPM-Fail Attacks Against Cryptographic Coprocessors

Really interesting research: TPM-FAIL: TPM meets Timing and Lattice Attacks, by Daniel Moghimi, Berk Sunar, Thomas Eisenbarth, and Nadia Heninger.

Abstract: Trusted Platform Module (TPM) serves as a hardware-based root of trust that protects cryptographic keys from privileged system and physical adversaries. In this work, we per-form a black-box timing analysis of TPM 2.0 devices deployed on commodity computers. Our analysis reveals that some of these devices feature secret-dependent execution times during signature generation based on elliptic curves. In particular, we discovered timing leakage on an Intel firmware-based TPM as well as a hardware TPM. We show how this information allows an attacker to apply lattice techniques to recover 256-bit private keys for ECDSA and ECSchnorr signatures. On Intel fTPM, our key recovery succeeds after about1,300 observations and in less than two minutes. Similarly, we extract the private ECDSA key from a hardware TPM manufactured by STMicroelectronics, which is certified at CommonCriteria (CC) EAL 4+, after fewer than 40,000 observations. We further highlight the impact of these vulnerabilities by demonstrating a remote attack against a StrongSwan IPsecVPN that uses a TPM to generate the digital signatures for authentication. In this attack, the remote client recovers the server's private authentication key by timing only 45,000 authentication handshakes via a network connection.

The vulnerabilities we have uncovered emphasize the difficulty of correctly implementing known constant-time techniques, and show the importance of evolutionary testing and transparent evaluation of cryptographic implementations.Even certified devices that claim resistance against attacks require additional scrutiny by the community and industry, as we learn more about these attacks.

These are real attacks, and take between 4-20 minutes to extract the key. Intel has a firmware update.

Attack website. News articles. Boing Boing post. Slashdot thread.

Posted on November 15, 2019 at 9:36 AM • 13 Comments

Comments

Ross SniderNovember 15, 2019 12:08 PM

I'd really like to see implementation security considered a critical security feature for the selection criteria of contest ciphers.

Implementation security would measured assuming non-expert implementers will develop the most naive versions of the cryptographic codes (e.g. using look up tables for S-boxes, and failing to validate special cases like points in subgroups).

A good example are ed25519's Edwards' Curves, whose default naive implementation is timing oracle free.

While the conventional wisdom is that only security experts should implement cryptography, the reality is that this is both unenforceable and unverifiable. Further, security experts implementing these systems under the review and assurance structures of multi-billion dollar organizations, checked and certified by industry bodies _still_ make these kinds of mistakes.

There was some interesting research at NYU on leakage resistant cryptography I saw around 2011 (security model assumes a certain rate of private bit leakage through unspecified means), but I haven't kept up with that. These kinds of lines of research to me seem promising.

Clive RobinsonNovember 15, 2019 4:19 PM

@ ALL,

From the article,

    Our analysis reveals that some of these devices feature secret-dependent execution times during signature generation based on elliptic curves. In particular, we discovered timing leakage on an Intel firmware-based TPM as well as a hardware TPM.

In other words "A know implementation fault opening up time based side channels that leak keyMat".

Such time based side channels havr been known about publically since the 1980's when they became glaringly obvious in that French idea that became the "Smart Card" which later became the foundations of your mobile phone SIM and bank cards.

The AES contest was in effect rigged to make the code produced as side channel ridden as possible, and such side channels were in public crypto libraries that were still in use till faorly recently.

There realy is no excuse for Intel to be pushing out such obviously insecure dross. Thus the question arises as to,

    Who put these faults in? And why did nobody find them diring test etc.

Put simply many will think this should not have happened without quite deliberate intent or collusion with the likes of the NSA.

Steven ClarkNovember 15, 2019 5:06 PM

That's a lot of signatures to get out of a TPM key. An attacker who can make this happen necessarily is already running commands or code on the host (unless a network daemon is providing a "free signatures" service). So it's not an in so much as a way to make a bad situation worse, like a supply chain attack.

SpaceLifeFormNovember 15, 2019 5:35 PM

@Steven Clark

It leaks, you do not need local access.

A network server, (think web server), can leak the bits. Slowly, and surely, it will reveal the private key.

It's just a matter of traffic and time.


Assembly LanguageNovember 15, 2019 7:11 PM

https://www.felixcloutier.com/x86/cmovcc
https://mudongliang.github.io/x86/html/file_module_x86_id_34.html
https://stackoverflow.com/questions/30150274/purpose-of-cmove-instruction-in-x86-assembly

The "CMOVcc" instructions of the x86 architecture, e.g., appear to be intended (or at least ought to be able) to provide constant-time execution for algorithms designed free of key-dependent conditional branches.

The problem then becomes that of key-dependent fetches of S-box information and the like which may or may not be cached at any particular level by the microprocessor.

ThothNovember 15, 2019 10:59 PM

TPMs and smartcards are typically not immune to timing attacks. If you observe the Protection Profile for TPMs and Smartcards, it only mentions attacks on power lines (SPA and DPA) and fault injection attacks (SFA) for cards with higher level of certification. Timing attacks are omitted.

Its down to the security policies and their requirements because all manufacturers will only put in enough resources and R&D to achieve whatever the Protection Profile requires them to do.

Gunter KönigsmannNovember 16, 2019 3:32 AM

@Steven Clark: The problem is that your web browser and all of its plugins execute local code. And that the cloud services you might be using do the same, potentially for many clients on the same computer.

JonKnowsNothingNovember 16, 2019 10:41 AM

@Clive Robinson @All

@All

a remote attack against a StrongSwan IPsecVPN that uses a TPM to generate the digital signatures for authentication. In this attack, the remote client recovers the server's private authentication key by timing only 45,000 authentication handshakes via a network connection.

@Clive

Put simply many will think this should not have happened without quite deliberate intent or collusion with the likes of the NSA.

iirc

Snowden docs detailed how the NSA can crack a ridiculous amount of VPNs in a depressingly small amount of time.

I would hazard our insecurities both physical and psychological can be laid at the dirty feet of the NSA. The Dirty Hands are the CIAs.

What about the Brits? Well... the NSA ran the show, the 5EY were useful (F)(T)ools. They are so much easier to control now, all you have to do is wave a Bankrupt's Golf Course at them...

Who?November 17, 2019 1:14 PM

It is not clear to me... after applying the firmware upgrades —to these systems lucky enough to get the upgrades from the manufacturer— are the TPM coprocessors immune to timing and lattice attacks or is it just another hardware workaround against an specific implementation of an attack technique?

I do not care if these attacks are consequence of lazy development or the inner work of a intelligence agency (a north american, chinese or russian one, who cares?); discovering, and fixing, these side channels are great news.

Let me play devil's advocate... I do not think this one is a backdoor introduced by the NSA; the U.S. Government has been requesting for years systems that include TPM chips. It is a requirement to win a U.S. Government contract. I think it is just a matter of lazy development techniques.

WaelNovember 17, 2019 1:59 PM

@Who?

are the TPM coprocessors immune to timing and lattice attacks

Not all TPMs are created equal. Some have more measures of protection than others.

I do not care if these attacks are consequence of lazy development

One possibility, out of many. See the last response.

the inner work of a intelligence agency (a north american, chinese or russian one, who cares?);

Highly unlikely.

I do not think this one is a backdoor introduced by the NSA;

Niether do I.

Government has been requesting for years systems that include TPM chips. It is a requirement to win a U.S. Government contract

Right.

I think it is just a matter of lazy development techniques.

Possible, plus some known reasons:

  • HW TPMs are extremely limited in resources, and several optimizations result in some weaknesses
  • HW Manufacturers are under constant pressure to reduce cost and remain competitive, so they need to support additional features with more dwindling resources
  • Some time optimizations in generating RSA key-pairs resulted--without mentioning names--in weaknesses that subsequently made the manufacturer revert the optimizations

Many moons ago, I was aware that some PC manufacturers had to use some optimization techniques (lack of resources and ROM space) that caused some weaknesses. These weaknesses were within the "acceptable risk appetite" for the use-case. They were not backdoors, by any means. And they could not have been used for backdoors.

Three things to keep in mind:

  1. Nothing is perfectly secure
  2. TPMs were not designed to be HW crypto-processors or crypto accelerators
  3. TPMs mainly introduce a HW (in case of HW TPMs, and some fTPM implementations) root of trust (RoT) that's used as a primitive building block to facilitate the means to cryptographically prove to a challenger the state of the platform.

Previous related discussions: here, and there. There were many others... this is sufficent, though.

Who?November 18, 2019 1:57 PM

Hi Wael.

Thanks a lot for the comments and the links to older threads. Very instructive. I like the second link a lot, and found valuable information on it.

Indeed, you are right. First TPMs were used to store hashes of hardware and software configurations (BIOS, CMOS, NVRAM and SMBIOS) only; over the time it has become a sort of full-featured secure cryptographic processor. You have a very good point about the limited resources available for these cryptoprocessors. Lack of resources impact on its ability to do its work on a secure manner.

Optimizing performance on a limited resource cryptoprocessor usually means opening a door to serious timing-related attacks. It is hard to explain to customers, but a cryptographic framework should do all cryptographic operations in the same amount of time. It means making them as expensive as the slowest of these operations. It is usually bad as is, but it becomes worse on a slow device.

Hope the industry will be able to close all these side channels, not just hide them, even if it makes TPMs slower. I do not really care about performance when we are talking about security.

The example concerning VPNs is impressive. It seems that we will need to protect the ends of a VPN in a way connections can only be established from other, trusted, end points. By now I understand some networks whose end points cannot be fixed by a firmware upgrade will need to move to software-only VPN implementations.

At least we know a few more industry-wide vulnerabilities now, how fixing them (ok, iff a firmware upgrade is available) and we have some idea how certain supposedly secure VPNs can be breached. This knowledge itself is a win for the security community. Don't you agree?

WaelNovember 18, 2019 9:07 PM

@Who?

This knowledge itself is a win for the security community. Don't you agree?

More than agree. It's good for the security community, for hackers (crackers,) for spooks, ... perhaps not so good for the manufacturers?

Then again, it may be bad for everyone :)

Steven ClarkNovember 21, 2019 6:42 PM

@JonKnowsNothing et al. That's 45000 signatures, over a presumably low-jitter connection, to an as-I-called-it "free signatures" service. Using an HSM or TPM directly for a key getting used by a network service may turn out to also be a bad idea no matter what is implementing the engine. I still have doubts about timing attacks run over the Internet instead of GbE. Yes this is bad but the TPM implementers aren't the only weak links in this chain, and there are some nice restrictions on the attack to slow this thing in the wild until people get patched.

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Sidebar photo of Bruce Schneier by Joe MacInnis.