News AMD's TPM Hacked: faulTPM Attack Defeats BitLocker and TPM-Based Security

[hotaru.hino]

A typical PIN of 4-8 digits could be cracked in seconds.

TPMs have an anti-hammering mechanism built in. From what I can gather from https://technet440.rssing.com/chan-6827930/article22207.html, TPM 2.0 times out after 32 attempts, and it allows for another attempt after 2 hours.

If my math is right, even with a 4-digit PIN, it should take up to 19,936 hours to run through its course. Multiply this by 10 for every digit you add.

 

[setx]

And your learned solution would be.....what?

Something at least open-source. I know it's harder for hardware, but there is movement in that way as big companies are also disgusted by those "security" black boxes.

 

[Kamen Rider Blade]

I would never trust the TPM presented by Intel or AMD.

Doesn't matter, I don't want them holding the Encryption Keys to my data.

I'll keep them else-where, off-line, thank you.

 

[palladin9479]

TPMs have an anti-hammering mechanism built in. From what I can gather from https://technet440.rssing.com/chan-6827930/article22207.html, TPM 2.0 times out after 32 attempts, and it allows for another attempt after 2 hours.

If my math is right, even with a 4-digit PIN, it should take up to 19,936 hours to run through its course. Multiply this by 10 for every digit you add.

This is only matters if someone is typing into the screen, which we aren't. What they do instead is copy the memory to a file, then just try every PIN from 00000000 to 99999999, which is trivial. Once the correct decryption key is found, we then use that to decrypt the stored encryption key from the file and use that to decrypt the storage medium.
Basically this renders TPM useless as a protection element as encryption schemes are only as strong as their weakest link, and in this case it's the encryption key.

Honestly if someone wants FDE, just use Veracrypt with a long passphrase. The only downside is corporate IT can't recover the data if the user forgets the passphrase.

 

[PaulAlcorn]

"The attack does require physical access to the machine for 'several hours.'"

Seriously?? If somebody has access to your PC that long, that "hack" is the least of your problems.

This pathetic story is typical of the anti-AMD BS articles that get posted here lately. Wouldn't me surprise me in the least if it turns out that Intel funded the whole pathetic "hack"!

Please explain how this is "anti-AMD BS." We report on all nature of vulnerabilities from both AMD and Intel. This is news, which is what we cover. A quick Google will find plenty of examples of Intel vulnerabilities that we have covered as well, sometimes in batches.

 

[mikewinddale]

I would be more concerned with someone having access to my disassembled PC for several hours than the risk of this attack.

If someone steals your PC, then this hack means that they can access your data.

Do you know anyone who has left a laptop at the coffee shop? If yes, then this matters.

 

[mikewinddale]

"The attack does require physical access to the machine for 'several hours.'"

Seriously?? If somebody has access to your PC that long, that "hack" is the least of your problems.

False. If someone steals my computer, then I can file a home insurance claim and get my money back. No big problem.

But if they hack my TPM, then they have access to all the sensitive data on my computer, such as a Chrome browser that saves every password to every bank account and credit card I have. That's much worse.

 

[PaulAlcorn]

This is one of the reasons that I stopped reading Tom's a while ago.
While it's great to know that this is a thing (I'm a Systems Admin, I appreciate it somewhat), this is on older architectures, and this exact thing was likely the target of the 'Walled-Garden' security design on the Ryzen 5000G/U CPU's. Since it's an outgoing architecture, new equipment should resolve this.

Also, using smart cards as a multi-factor authentication with domain to also encrypt the hard drive may be another way to counter this hack. It's pretty extreme, but it might work.

So while I did actually think about this because you can use the walled-garden to store Azure AD security objects so that an authenticated user can access very privileged information, the reality is - only the big fortune 500's, 'Enterprise' companies, and Gov'ts will even consider using a schema this secured.
If a company has a regular policy of updating laptops that are outside of secured company premises, this issue is a non-starter.
Ryzen 5000G's shouldn't be an issue, and these are now... 1.5 years old? This is about the window it typically takes to crack hardware security these days, if not less.

This impacts Zen 3 processors, and AMD has stated multiple times that it will continue to release processors for AM4 platforms, which are Zen 3 and older. In fact, they just released new 5000-series models in June of last year. It isn't yet clear if the hack applies to Zen 4.

 

[mikewinddale]

Physical access to the machine for hours will equal a comprised machine regardless of what security you are using.

Not if encryption works. The whole point of encryption is so that when someone loses a company laptop, the sensitive data are safe.

 

[PaulAlcorn]

Insider threats are always going to be with us. The fact that this hack required direct physical access with specialized hardware shows how robust the current security is. Not losing any sleep over this particular issue.

This hack was done with off-the-shelf components that cost around $200. They have also posted all software needed to execute the hack to Github.

 

[hotaru.hino]

What they do instead is copy the memory to a file

What memory?

 

[palladin9479]

What memory?

Oh..
Ok the way TPM works is that the encryption key is kept encrypted inside a bit of NVRAM inside the TPM device, the user then inserts a PIN which serves to decrypt that key and that key is then used to decrypt the storage device. The TPM firmware protects the key from brute forcing the PIN since four to eight digit PINs are terrible and weak against brute force attacks.

What makes this particularly bad is that encryption schemes like TPM are supposed to protect the device against having the data stolen via physical theft. The assumption is that the attacker has acquire physical access to the device and has all the time in the world to attempt to break the full disk encryption.

 

[blppt]

Crap! Just yesterday some dweeb with glasses and a pocket protector came to my door and asked to see my PC for a bit! Why would I have thought anything bad would come of it!?

Did you flush his head down the toilet, then stuff him in a locker?

 

[drivinfast247]

Did you flush his head down the toilet, then stuff him in a locker?

💪

 

[neojack]

ok, well i im the IT of a small to medum business, we design heavy equipment. our biggest assets are our intellectual property, so when i was hired 4 months ago, i started to enable bitlocker on sensible laptops. I dont really care about the laptop themselves, but the data inside can be invaluable. The main attack vector here would be someone stealing a laptop or any other data repository.

The article does not talk enough about the countermesures.

There is an option on Lenovo's Bios fr a pre boot fingerprint authentication, or supervisor password. Are those vulnerable too ?

Another option is the optional PIN activated on windows : https://www.howtogeek.com/262720/how-to-enable-a-pre-boot-bitlocker-pin-on-windows/

Funny thing, they used a Lenevo Ideapad 5. we have severall of them....
I guess I have more work than I expected.

 

[TJ Hooker]

TPMs have an anti-hammering mechanism built in. From what I can gather from https://technet440.rssing.com/chan-6827930/article22207.html, TPM 2.0 times out after 32 attempts, and it allows for another attempt after 2 hours.

If my math is right, even with a 4-digit PIN, it should take up to 19,936 hours to run through its course. Multiply this by 10 for every digit you add.

Did you ignore everything I wrote other than the sentence you quoted? I already addressed why whatever rate-limiting the fTPM provides is irrelevant if the attacker has pulled off the exploit described in this article.

 

[warforge]

They're going to be really upset when they realize the windows pin was 1234

 

[TerryLaze]

Something at least open-source. I know it's harder for hardware, but there is movement in that way as big companies are also disgusted by those "security" black boxes.

If a security feature is open source then attackers have all the data on attack vectors without any need for the guesswork, they can just read through the source code, plans, and everything.

The best way to secure a lock is to make it hidden so that attackers can't even find it and add a prominent mock lock to keep them occupied.

 

[edzieba]

If the data on your system is very valuable, there is a risk that people will break into your offices and walk off with your hardware. If the data is highly encrypted, this is much less of a threat. The key is to use both full disk hardware encryption and high bit depth encryption at the file level. If you wish to add software based file system encryption, that is also an option.

Remember, corporations are not worried about the loss of the hardware, they are worried about the loss of the data on the hardware.

Bingo. For an attack that takes an encrypted drive and basically decrypts it with no need for password recovery or other credentials and without any network connectivity, a few hours is not a big impediment. A basic bag-snatch gains unlimited time to perform the attack ,but even an 'evil maid' attack can gain a few hours for direct hardware access with good planning.

ok, well i im the IT of a small to medum business, we design heavy equipment. our biggest assets are our intellectual property, so when i was hired 4 months ago, i started to enable bitlocker on sensible laptops. I dont really care about the laptop themselves, but the data inside can be invaluable. The main attack vector here would be someone stealing a laptop or any other data repository.

The article does not talk enough about the countermesures.

There is an option on Lenovo's Bios fr a pre boot fingerprint authentication, or supervisor password. Are those vulnerable too ?

Another option is the optional PIN activated on windows : https://www.howtogeek.com/262720/how-to-enable-a-pre-boot-bitlocker-pin-on-windows/

Funny thing, they used a Lenevo Ideapad 5. we have severall of them....
I guess I have more work than I expected.

Unfortunately, adding fingerprint/PIN/etc on boot would do nothing to stop this attack. Because this attack reveals the actual encryption key within the TPM, tools that merely restrict access to the TPM (such as boot passwords) are 100% ineffective in stopping it, as they are completely bypassed. The only way to block this attack would be to not store the encryption key on the device at all, which is impractical - you would need to type the entire 256-bit Bitlocker key on every single boot. And since no human could reasonably memorise a 265-bit string, that means having a physical copy carried alongside the laptop, just as vulnerable as having it stored in the now-readable fTPM..

Basically, this means practical drive encryption is irrevocably broken on Zen 2 and Zen 3 (at least).

 

[palladin9479]

Bingo. For an attack that takes an encrypted drive and basically decrypts it with no need for password recovery or other credentials and without any network connectivity, a few hours is not a big impediment. A basic bag-snatch gains unlimited time to perform the attack ,but even an 'evil maid' attack can gain a few hours for direct hardware access with good planning.


Unfortunately, adding fingerprint/PIN/etc on boot would do nothing to stop this attack. Because this attack reveals the actual encryption key within the TPM, tools that merely restrict access to the TPM (such as boot passwords) are 100% ineffective in stopping it, as they are completely bypassed. The only way to block this attack would be to not store the encryption key on the device at all, which is impractical - you would need to type the entire 256-bit Bitlocker key on every single boot. And since no human could reasonably memorise a 265-bit string, that means having a physical copy carried alongside the laptop, just as vulnerable as having it stored in the now-readable fTPM..

Basically, this means practical drive encryption is irrevocably broken on Zen 2 and Zen 3 (at least).

It's more complicated then that. There are basically two keys present in these systems, the Media Encryption Key (MEK) and the Key Encryption Key (KEK). The MEK is an extremely long key that is generated whenever you encrypt a drive and is usually stored in an encrypted format at the beginning of the disk. The KEK is a key that is generated from a hash of something else, usually a long passphrase or PIN (really weak), the hashed key is what is used to encrypt or decrypt the MEK. In this way we can "change" our password/pin without needing to decrypt and then re-encrypt the entire volume, instead we just re-encrypt the MEK.

Now what TPM does is move the MEK from the storage volume into it's own internal NVRAM, then "promise" not to let people get to that NVRAM. This is the black box nature of the solution, their entire "we promise not to let anyone near the MEKs, you can trust us". What makes it worse is that the KEK used to access is based on really weak keys, an eight digit pin is stupid low entropy and easily cracked by anything made in the last few decades. The "promise" from TPM was that they would mitigate this weakness by restricting the number of tries. The other "benefit" was that the IT could have "backup" keys that would let them bypass the TPM vault entirely, just in case the user "forgot" the PIN or passphrase to get to their disk.

A real solution to FDE isn't to have a user remember a 256-bit key, but to never use a weak KEK in the first place and instead use a strong key passphrase combined with user education that if they lose it then it's gone forever. Anytime we give ourselves a "get out of jail free" back door, we also give the bad guys the exact same back door and we must always assume the bad guys are smarter then us.

 

[edzieba]

It's more complicated then that. There are basically two keys present in these systems, the Media Encryption Key (MEK) and the Key Encryption Key (KEK). The MEK is an extremely long key that is generated whenever you encrypt a drive and is usually stored in an encrypted format at the beginning of the disk. The KEK is a key that is generated from a hash of something else, usually a long passphrase or PIN (really weak), the hashed key is what is used to encrypt or decrypt the MEK. In this way we can "change" our password/pin without needing to decrypt and then re-encrypt the entire volume, instead we just re-encrypt the MEK.

Now what TPM does is move the MEK from the storage volume into it's own internal NVRAM, then "promise" not to let people get to that NVRAM. This is the black box nature of the solution, their entire "we promise not to let anyone near the MEKs, you can trust us". What makes it worse is that the KEK used to access is based on really weak keys, an eight digit pin is stupid low entropy and easily cracked by anything made in the last few decades. The "promise" from TPM was that they would mitigate this weakness by restricting the number of tries. The other "benefit" was that the IT could have "backup" keys that would let them bypass the TPM vault entirely, just in case the user "forgot" the PIN or passphrase to get to their disk.

A real solution to FDE isn't to have a user remember a 256-bit key, but to never use a weak KEK in the first place and instead use a strong key passphrase combined with user education that if they lose it then it's gone forever. Anytime we give ourselves a "get out of jail free" back door, we also give the bad guys the exact same back door and we must always assume the bad guys are smarter then us.

Close: MEK remains resident on the drive, it's the KEK that goes to the TPM, and the pin/biometric/etc access control mediated by the TPM is to the KEK. It's how you can (with some many hoops jumped) move an encrypted drive between a TPM-enabled and a non-TPM-enabled box without decrypting in-between.

 

[jaquith]

Seriously?? If somebody has access to your PC that long, that "hack" is the least of your problems.

This pathetic story is typical of the anti-AMD BS articles that get posted here lately.

Seriously did you think this through? Basically every effected governmental, corporate or any notebook with critical / private information needs to be replaced and shredded.

 

[setx]

If a security feature is open source then attackers have all the data on attack vectors without any need for the guesswork, they can just read through the source code, plans, and everything.

The best way to secure a lock is to make it hidden so that attackers can't even find it and add a prominent mock lock to keep them occupied.

Sir, you came straight from the stone age, right?
Security-through-obscurity is exactly what modern cryptography teaches to never rely upon. En/decryption implementation shall be open and only data (key) shall be secret.

 

[Kamen Rider Blade]

Honestly if someone wants FDE, just use Veracrypt with a long passphrase. The only downside is corporate IT can't recover the data if the user forgets the passphrase.

That's a Feature, not a Bug!

 

[TJ Hooker]

One advantage a TPM based solution has over 'regular' FDE is protection from evil maid attacks. Although this of course assumes the evil maid in question can't compromise the TPM itself.