faulTPM: Exposing AMD fTPMs' Deepest Secrets
arxiv.org
arxiv.org
This might not be surprising to some, despite Windows hiding the GUI passphrase functionality behind some group policy settings, both "Require additional authentication at startup" and "Enhanced PIN", which isn't perhaps the most intuitive and a normal user might not even realize unless they notice the "normal" PIN is numerical-only. In any case, for the average person that might have their devices stolen, this is likely not to be a threat, but I think a passphrase should always be preferable, BitLocker doesn't support any better option.
I figured it would be generally known at this point, especially with the whole perceptual hash debacle (intended to satisfy LEAs despite the plan to finally enable image encryption). I'm not sure what the internal politics looked like after the perceptual hash snitch got axed - my friends who would know quit Apple by then.
Now, you have a multiple products on the market that can crack passcodes by utilizing flaws that allow you to brute force PINs, which are by default 6 digit numbers. (Despite most guidance demanding 8)
UFED, get it? its right in the name :] Video has little demonstration with older phones, one click bypass for all passcodes.
>Later provision was added to allow export of 56-bit encryption if the exporter promised to add "key recovery" backdoors by the end of 1998.
First SSL crippled to 40-bit RC2/RC4
First 802.11 wireless protocol WEP "64" key length shortened to 40 bits
https://en.wikipedia.org/wiki/A5/1 vs https://en.wikipedia.org/wiki/A5/2
>to allow the British secret service to eavesdrop more easily. The British proposed a key length of 48 bits, while the West Germans wanted stronger encryption to protect against East German spying, so the compromise became a key length of 54 bits
>Documents leaked by Edward Snowden in 2013 state that the NSA "can process encrypted A5/1"
Also a couple kilobytes of flash costs basically nothing. And you could hash keys over a certain length, which is much better than having such a short limit on a human-typed string.
Don't/can't? Then you're a fool trusting someone else to do something you yourself cannot inspect. Then again, most people seem to be oddly fine with that. I am not of that number.
source: just trust me bro
but argon2($string_of_any_length) should produce a fixed-length byte string, no?
Timing attack on the character of the pw which failed?
"Our attack utilizes the AMD-SP’s vulnerability to voltage fault injection attacks [14] to extract a chip-unique secret from the targeted CPU."
"The attack requires access to the motherboard of the target system (4.1), particularly its SPI bus and voltage regulators."
In other words, it is required to open the laptop and connect custom (but cheap) hardware to the motherboard to disrupt its normal operation.
What's old is new again!
https://www.intel.com/content/www/us/en/newsroom/news/the-st...
Approaches such as yours do make the attack require a lot more skill to accomplish.
Which would be detected if internal watchdog monitors voltages. But if spikes are short enough they might be pretty hard (or just expensive) to detect.
That said, even a host using a dTPM with proper authentication of the dTPM has a problem if the SP is vulnerable to voltage fault injection attacks, because even though SPI bus sniffing wouldn't yield the unlocked FDE keys, the attacker presumably could get full control of the CPU and recover the unlocked FDE keys there.
In other words, the problem here is the voltage fault injection vulnerabilities in general. The fTPM part of it is not as big a deal as the total compromise of the whole system due to those voltage fault injection vulnerabilities.
This won't help break a PIN that is protected by the dTPM, but it will fully break any protection relying on the host to verify a PIN. (Which is the default BitLocker behavior.)
Every time I think about the millions of computers that will be declared worthless this year, it makes me a little bit more angrier.
What is this a reference to? Every computer I've found will let you boot into the bios and disable secure boot or add new keys to the trust store.
Bsd was made by people who love unix, linux was made by people who hate windows.
As one example, I had to take a proctored exam recently, and the only supported OS was Windows or MacOS. Linux was not an option.
Then there is games, Proton is great but plenty of AAA titles are still not compatible.
Just for starters.
Got on the phone with support and they were dumbfounded. Got the idea to just spoof my user agent as a windows box on edge and it worked perfectly afterwards.
Even if not done on purpose there is a lot of crufty shit online that breaks in unsuspecting ways when I'm on a linux/BSD box. Especially if interfacing with the government websites and webapps. Our state fire code website looks straight out of 2002 and has multiple warnings about making sure to use IE6... in 2023.
Maybe its just my use case (fire industry / local government), but it helps to have a mac or windows machine lying around as backup.
Changed the background to match the same one on her old laptop and added some desktop icons, and boom 99% of her experience was the same. Had to help her a little with the LibreOffice -- that's a little different -- but otherwise functionally similar to Windows 7 / Win10.
I'm using linux as a daily driver and at this point there isn't anything I can't do on Windows. The hold out for a while was games, but Proton w/ Steam works well and I can play big titles like Cyberpunk 2077.
Hell, I installed the Chicago95 XFCE theme on my main system to see how well it emulated the look and feel of Windows 95 and wound up liking it. Why? Because even though it looks dated, the icons were immediately familiar and I felt navigation instantly become easier.
Do not underestimate the power of familiarity. Many of us grew up on DOS/Windows playing games and typing school work up in Word so moving away from those familiar waters is HARD. It's like being an immigrant moving to a new country - you have to put in extra effort to learn to adjust to culture and language. Some can, some cant. YMMV.
They chose an arbitrary cut-off date for hardware support for their new OS. They decided not to support old stuff anymore and they had to pick a date/technology platform. It was always going to be arbitrary. In my opinion they should've picked a clearer distinction (i.e. require a certain level of AVX support so all binaries can be built with AVX optimizations enabled) but I can see why they chose to do this. After all, they're going to have to support the OS for ten years, that four year old CPU is fourteen years old by the time Windows 11 goes out of support.
Most of my machines were on a Linux distro before that decision, and Debian 12 is providing a good enough to me experience on the desktop, even gaming.
I'll probably just stay there indefinitely. Is that an upgrade? Subjective. I'm happier here.
From Microsoft's website:
>Memory integrity works better with Intel Kabylake and higher processors with Mode-Based Execution Control, and AMD Zen 2 and higher processors with Guest Mode Execute Trap capabilities. Older processors rely on an emulation of these features, called Restricted User Mode, and will have a bigger impact on performance.
https://learn.microsoft.com/en-us/windows/security/threat-pr...
There're no fundamental changes to what's actually required, the limitations are arbitrary and set by Microsoft (and they provide a means to get around them).
It'll work fine.
If not, there are other operating systems that do work. Microsoft isn't the exclusive owner of the PC space, that's one of the major points of all of the antitrust fines and lawsuits.
But hey at least the OS has a revolutionary new green technology called... Battery saving mode!
Kool-aid Jammers are my latest laugh. Plastic pouch. Plastic straw wrapper. Paper straw.
Right, the straw was the enemy here?
That does not make these PCs obsolescent in any way. People still use Windows 7, and even Windows XP. Especially in the many contexts where "security" is not important at all.
I don't even think Apple hits 8 for OSX updates. They obsolete the laptops more quickly than that, even if they do hit 6-7 years regularly.
Apple does not support any macOS version for that long, and is unlikely to support a current version of macOS on any given device for that long.
Modern web browsers will stop working on older operating systems - so will other apps.
Not only is it a massive security risk, but it will simply become impractical for most users.
Besides, if you're afraid of the TPM vulnerability described in this article, you ought to be more worried about running an out of date OS!
Apple does not provide security updates for Catalina, which was released 3.5 years ago. People would be crazy to run unpatched OSes for any use case involving the internet or wifi.
You are probably largely using x86_64 which come with the option to do so, but there has been a lot of push around moving to things like ARM for energy efficiency reasons.
There has? Where?
Specifically for Windows PCs, not chromebooks or apples.
https://cdimage.debian.org/debian-cd/current/amd64/iso-dvd/
(Or, for laptops with closed WiFi and no Ethernet, use this installer: https://cdimage.debian.org/cdimage/unofficial/non-free/cd-in... )
TPM = Trusted Platform Module. Trusted is an adjective modifying platform. The business case is that software should not run on untrusted platforms because hardware can always attack software. So, the promise is that TPM will allow software to guarantee* to users that the hardware is not malicious.
* as much as one can guarantee anything in tech
From my perspective TPM is mostly about compliance with security directives. Actual security engineers would realize the TPM's security provided is about as far as you can throw it. You have no idea who designed the thing, who manufactured it, or who swapped it out while it was in shipping to you.
Wait, what? In most cases you 100% know who designed and manufactured it. Regarding "swapping out" a TPM, how do you do that for fTPMs or TPMs that are on the same die as the CPU? Come up with a perfect replica AMD CPU with a bugged TPM? Desolder the original CPU and put the replica in?
It's painfully obvious nowadays that openssl was written by the NSA (or equivalent state level entity) via intermediaries deliberately adding subtle but significant vulnerabilities.
Let me propose this metaphor: you buy a front door to your house. For some reason I (the door vendor) include a complete lockset. I tell you that the lockset is totally secure. I offer you volumes of academic research and attestations that this is true. But there is no practical means by which you can establish the security of that lockset.
Do you believe that no one else can open your front door?
The problem is that your lack of context and perspective on this fairly simple, easily-falsified theory calls all of your opinions into question.
A more nuanced conspiracy theorist would say "if you look at PR's to openssl that contributed later-discovered security issues, 70% were from first-time contributors who never went on to submit any other PR's". And I'd be like "wow, that's suggestive of a coordinated action", and we could dig into it.
But "the NSA wrote openssl" is as factually, demonstrably wrong as saying "the NSA builds every door lock that's for sale at Home Depot". It's too big of a conspiracy, to inefficient for the supposed state goals, and too easy to falsify by just looking at a couple of examples.
You might for example, just outright buy out the cryptography solution providers:
https://en.wikipedia.org/wiki/Crypto_AG
Money is a relatively simply mechanism to achieve an end goal. Much safer than for example, torturing someone or beating them with a wrench.
"Plug this chip that says made in China into your mainboard, for security reasons, to continue." is not really emitting trust or confidence in any way.
I'm sure 30 other chips made in china on same board are entirely fine
All wrong, as others have pointed out. As for the last of the above, if the OEM includes (as they should) platform certificates for the TPM, then the TPM cannot have been swapped out while in transit w/o the OEM helping the attacker. For example, Dell includes platform certificates binding the TPM.
TPMs aren't very secure and as a discrete component their connection to the CPU can be intercepted (unlike fTPM or apple's integrated solutions).. There's a big difference between having a deliberate backdoor and just a vulnerable design that can be exploited.
I haven't seen them accused of being backdoored. Intel's ME (and AMD's equivalent) perhaps but that's not the TPM.
TPMs can also be used to hide DRM keys from the user and I'm also opposed to that, but generally that stuff is hidden in other hardware. Like Google's wildvine stuff in mobile CPUs.
BTW, there is Chinese passport law which states that the algorithm should be independently developed. The law once blocked TPM 1.0 but allows TPM 2.0
- decap it, scan it with an electron scanning microscope, reverse engineer it (or have already done so), and read the seeds and all NVRAM on the chip
- force the manufacturer to record the seeds even though they have processes to never do so, then force the manufacturer to reveal the seeds a dTPM shipped with given an EKpub for it
A few nation states could probably pull off the latter, but probably very few. And I suspect they haven't bothered and won't until TPM usage finally gets in the way. This is pure speculation, and they may well have forced all the manufacturers already for all any one of us knows.
More nation states could pull of the former. But again, they might not bother until TPM usage finally gets in the way.
As long as BMCs and BIOSes continue to use non-encrypted sessions to talk to dTPMs there is no need to do any of this when the attacker has physical access to the motherboard.
Example: https://arstechnica.com/gadgets/2021/08/how-to-go-from-stole...
In this sense an integrated solution is better because there is no simple bus to sniff, but it does have to be properly implemented of course. Which seems to be not the case here.
By the way a dTPM should have a real entropy RNG so technically it shouldn't have any (usable) seed. It's basically a smartcard soldered onto the mainboard. Of course smartcards can also have key generation flaws like the Infineon flaw a while back. https://www.schneier.com/blog/archives/2017/10/security_flaw...
While that is strictly speaking true, the TPM command set allows you to set up an encrypted session to the TPM using an ECDH or RSA key for key exchange that authenticates the TPM.
The problem is that the BMCs and BIOSes out there don't record a public key for a primary key on the TPM and then don't bother using encrypted sessions (not even opportunistically getting that public key from the TPM, which would defeat passive attacks).
That's a software problem, not a TPM problem!
I know that TPM 2.0 is a huge topic, so it's quite forgivable that people don't know these things. I've written a tutorial that might help: https://github.com/tpm2dev/tpm.dev.tutorials/tree/master/Int...
I do think it's time for a TPM 3.0 though. What apple does with their T2 security chip, and later with the M1/M2, is having the secure element not only handle the key material but the actual encryption as well. They have hardware acceleration that can handle encryption at full disk speeds. This is still a much better option than a TPM especially with symmetric encryption where the key would inevitably end up in the main CPU. In Apple's scenario this no longer happens.
- encrypt all command and response parameters instead of up to just one
- add a version of TPM2_Quote() that encrypts and signs so one can have ciphertext that one can demonstrate were made by a TPM encrypting to a restricted, shielded key
- add a small secure enclave facility
- add more EC algorithms, EdDSA, etc.
- add more cipher modes for AES
- increase RAM and NVRAM requirements
All of this can be done incrementally in 2.x, so calling it 3.0 would be just marketing (perhaps pretty good marketing).
The seeds are an essential part of the TPM story as for generation (derivation) of primary keys, and being able to "take ownership" of a TPM by changing those seeds.
The seeds are not an essential part of the TPM story for its RNG. A TPM absolutely can and should have a solid HW RNG. Though, were I designing a TPM, I'd combine the output of a HW RNG w/ a PRNG seeded internally.
But a manufacturer-installed seed that they have control over sounds like a very bad idea.
The problem here is that while it is possible for a BMC / BIOS to know a dTPM's EKpub and use it to establish encrypted (and authenticated) sessions to the dTPM, most BMCs/BIOSes don't. This is a limitation on the host side, not the TPM side. I get that in total the vulnerability exists, but it doesn't have to, and TPM has a perfectly good solution for it. Take it up with the OEMs!
Also, made me remember (once again) decade old presentation on TPM: https://www.youtube.com/watch?v=XgFbqSYdNK4
The problem isn't the TPM. The problem is the CPU (SP) being vulnerable to voltage fault injection attacks. You could be using no TPM and still have all your secrets leak if the host is fully compromised.
Whose computer is this, anyway?
https://www.stat.rice.edu/~dobelman/kstorm.txt
https://news.ycombinator.com/item?id=6337282
https://www.militaryaerospace.com/computers/article/16711478...
https://www.businessinsider.com/leaked-german-government-war...
https://supplychaindigital.com/technology/nsa-trusted-comput...
https://redmondmag.com/articles/2013/08/22/windows-8-securit...
https://blogs.ncl.ac.uk/security/2015/07/29/on-the-trust-of-...
> It is also important to note that any user concerns about TPM 2.0 are addressable. The first concern, generally expressed as "lack of user control," is not correct as OEMs have the ability to turn off the TPM in x86 machines; thus, purchasers can purchase machines with TPMs disabled (of course, they will also be unable to utilize the security features enabled by the technology). The second concern, generally expressed as "lack of user control over choice of operating system," is also incorrect. In fact, Windows has been designed so that users can clear/reset the TPM for ownership by another OS of they wish. Many TPM functions can also be used by multiple OSes (including Linux) concurrently.
This refers to the fact that you can:
- disable the TPM if you don't want to use it
- change the platform/endorsement/owner hierarchies' seeds, delete all the platform and endorsement certificates, and thus render any agreements between the NSA and the TPM manufacturers useless to backdooring the host (unless the agreement involves voluntary vulnerabilities in the TPM's firmware)
The last article you link to is much more interesting because it actually involves thinking about how the NSA (or other such agency) could have a backdoor inserted into the TPM:
> However, such “trust” can be easily misused to break security. In the talk, I used TPM as an example. Suppose TPM is used to implement secure data encryption/decryption. A standard-compliant implementation will be trivially subject to the following attack, which I call the “trap-door attack”. The TPM first compresses the data before encryption, so that it can use the saved space to insert a trap-door block in the ciphertext. The trap-door block contains the decryption key wrapped by the attacker’s key. The existence of such a trap-door is totally undetectable so long as the encryption algorithms are semantically secure (and they should be).
Er, well, this fails because there is no way to compress cryptographic material, and we're talking about random or pseudo-random keys being compressed (which, you can't) then encrypted. So this particular idea fails immediately.
That doesn't mean that there aren't other backdoors. For example, the ciphertext could be larger than necessary rather than use a compression of the plaintext. But this too fails because the sizes of the ciphertexts are easy to determine from the plaintext sizes.
The best way to add a backdoor is to have secret commands that use public keys for authentication (and even encryption) so that you have to know the backdoor in order to be able to use it. I cannot prove that there is no such backdoor, but if you have the means to decap and reverse engineer a dTPM then you can do this.
There are many things to worry about when it comes to firmware backdoors, the TPM ain't one of them.
Excuse me, but wtf. That's BS. Cryptographic material is nothing but data. A Huffman encode will work on a number that happens to be a public key just as happily as it will a anything else.
Cryptographic material doesn't have a magic "immune to compression" characteristic.
Encrypted material should not be compressable because it needs to appear random no matter what the unencrypted contents are, otherwise you have information about those contents. (You can trade off between the security and compressability, but shouldn't.)
In principle, given an n-bit prime p, you can store an expected log₂ n − 0.5 additional bits by using the gap between p and the next prime. Though in practice, I'd be surprised if the 19 or so extra bits could be dangerous.
Thinking about AES-256 will be easier. Say we have 2^40 computers able to randomly generate 2^64 AES-256 keys every day. Well, it will still take a long time to generate all possible AES-256 keys. So say in the best case scenario we get close to 2^120 keys or so. How would we even measure their frequencies so we could assign Huffman codes to them? Well, we can't, and even if we could most keys would have a frequency between 1 and 3. And still the next key to be generated could be outside that set so we really have to assign a code to each key, and there's... 2^256 possible keys... which means that even if we could assign a code to each key we couldn't write that down because there's not enough atoms on Earth to do it with. But let's say we just define a collation of AES-256 keys and assign then Huffman codes in order... But now we'll soon see that most keys will get codes assigned that are longer than 256 bits. Which means that the average input to this compressor would... yield an expansion, not a compression.
And, yes, you can compress specific pseudo-random looking symbols, but only a few. We're talking about arbitrary pseudo-random data, and that will not compress.
_Even if you would be able to control every bit of firmware on your computer and there was no DRM or similar you still would want a TPM!_
through potential a different implementation and not some of the features build on top of it
like something like a TKey integrated into your CPU with some additions for securing the boot chain (including the EFI itself) would probably be a convenient, simple, way to have the necessary security without many of the problems ... or did I just reinvent TPM ?
IMHO more like: There is little to no profit in this, nor much motivations for AMD/Intel to provide this. But it does involve additional work, especially if the fTPM implementation they use currently does (partially) use code they got from other companies which they can't open source.
Through you wouldn't need a FPGA, for a TPM to really be secure you want it to be integrated into the CPU. And most times this means it's not a "special" physical chip but just a "standard co-processor" running some software. E.g. in case of ARM Android smart phones it's likely a more or less normal Cortex M0 processor (and it likely runs more then "just" a TPM, e.g. some DRM pipe protection code).
So theoretically you would just need to publish the "bar metal" code and anyone could analyze it and then build and run it e.g. using qemu (if qemu can handle co-processors idk.). And by also allowing to extract the build code from the CPU combined with reproducible builds you could also verify it runs what it says it runs (kinda, I mean who says there isn't a hardware backdoor rewriting the code, and it being a FPGA doesn't help there because the FPGA hardware could also rewrite the FPGA bin-code.... at least theoretically)
TPM and secure boot combined can create computers that run key-per-cpu encrypted system binaries that can not be modified by the device owner meaning next time microsoft does something fucky there will be no path out, no programs to disable it, its just how you have to live now.
Its not worth it to head down that path.
TKey is based on ideas like TPM and DICE. Think of TKey as a TPM-in-time, and a discrete TPM on an x86 mainboard as a TPM-in-space. Both go through the load-hash-measure-trust/execute steps, but TKey only needs one hardware domain to accomplish this whereas a discrete TPM needs two.
Measurements and their results need to be computed in a context that can't be subverted by the object that is being measured. In the discrete-TPM case the host loads and hashes the object and then sends it to the TPM before letting the object influence the host's control flow.
The only difference in the TKey case is that instead of sending the hash to a TPM the TKey derives key material based on Hash(sk, Hash(object)) and then removes sk from RAM. This is roughly equivalent to TPM sealing.
The TKey equivalent of TPM quoting/attestation would involve a signing step using sk, and leaving the resulting certificate in RAM before letting the object influence control flow. A downside to this approach is that each measurement creates another level in a PKI-like structure. If you do the same thing with a discrete TPM you can do multiple measurements and still only have one signature attesting all of them.
You very much can. It's trivial.
TPMs have four key "hierarchies" each of which has a seed. Of those four, one (the "null" hierarchy) gets a random seed each time the TPM is reset, while the other three (the platform, endorsement, and owner hierarchies) have their seeds stored in EEPROM/NVRAM, and there are functions in the spec for replacing those with new, randomly generated seeds.
All primary keys in a TPM are derived from seeds, and the derived keys are not stored anywhere -- they are always derived as needed from the hierarchy's seed and a given template. Therefore changing a hierarchy's seed loses all access to primary keys previously used in that hierarchy.
All other keys are saved off-chip encrypted to a primary key. Thus rotating a hierarchy's see loses all access to all keys previously used in that hierarchy (not just the primary keys).
The only thing here that is remotely problematic here is that you have to trust the TPM's RNG. If you're paranoid you might believe that the RNG is itself a PRNG with a hidden seed and that the manufacturer knows it. But if you roll the endorsement hierarchy seed and delete the endorsement key certificate from the TPM, then how will the manufacturer identify the TPM in order to look up its putative hidden RNG seed? Even if they could find it, how would they know which RNG output was used as the hierarchy's new seed?
So, yes, you can "replace all the vendor keys". It really is trivial. However, before you do it you may want to use the existing keys and certificates to bootstrap (enroll) the host into your organization's network and then change the seeds and certify various public keys as derived after the seeds are changed so that you can continue using the TPM for attestation.
Only when you can bring your own keys for the entire boot and trust chain can you untether yourself from the vendor once you have purchased the hardware.
I.e., I'm objecting to this focus on TPM in TFA and this discussion because a voltage fault injection vulnerability in the SP is fatal to security regardless of TPM usage/non-usage. I'm also objecting to the idea that TPM adds vulnerabilities when a non-TPM-using system already is full of ways for NSA and/or other such agencies to backdoor it.
It's not just about updates through regular channels but about evil maid attacks with signed malicious firmware. This vector would be avoidable if you could sever the trust relationship.
Another wrinkle is that some of the blobs are encrypted (e.g. ME), so they can't even be audited.
Currently too much of the trust chain relies on untrustworthy components. So you can't trust the system. But the DRM vendor can well enough for their purposes. Which makes them a negative.
> I.e., I'm objecting to this focus on TPM in TFA and this discussion because a voltage fault injection vulnerability in the SP is fatal to security regardless of TPM usage/non-usage.
Yes, agreed.
Yes, evil maid attacks are the primary way for targeted attacks using malicious firmware.
So this is something that maybe the TCG should tackle. It should be possible (maybe it is?) to require that the host meet some policy before the firmware update can run -- this would prevent unauthenticated evil maid attacks.
This will always be true unless you build all the components yourself. And you don't have time to build all the components yourself. Therefore this will always be true.
With root of trust measurement you get to see that you're running code you've arbitrarily decided to trust. Everything else you could do would be mitigations (e.g., look for access patterns that imply compromise) or attempts to suss out vulnerable and/or backdoored components (e.g., reverse engineering and analysis). Not that one should not do those other things, but that root of trust measurement is still both, essential and insufficient.
Remember: perfection is the enemy because it's unattainable. We can tilt at windmills, but that won't get us anywhere.
Reinventing this wheel will probably lose a lot of good things. People who reinvent wheels often fail to understand what came before.
The important keyword is authenticated though. If it's not authenticated you can corrupt it.
Maybe the key itself is "more secure" because it only lives in the lockbox and is only taken out to unlock the front door and then put back right away. Is this the right system for actually securing access to my home, though?
Surely the device should serve the interests of the user that pays for it, and not some random developer.
TFA is fine, but thinking that this is specifically a vulnerability because of TPM is a serious mistake. Not using a TPM won't make you safer.
"Motivated by Windows 11’s push to use the TPM for even more applications, we apply the vulnerability to Microsoft BitLocker and show the first fTPM-based attack against the popular Full Disk Encryption solution. BitLocker’s default TPM-only strategy manages – without any changes to the user experience – to swiftly step up a user’s security in the face of a lost or stolen device. However, as our work complements the established at- tacks against dTPMs with an even more potent attack against AMD fTPMs, a TPM-only configuration lulls a non-technical user with high protection needs into a false sense of security."
"Users who fear a physical attacker with reasonable resources should opt for a TPM and PIN configuration. When BitLocker identifies that the underlying TPM is an fTPM, users should be urged to turn their PIN into a passphrase."
And there's probably some large enterprises that use regular Linux desktops with LUKS/Btrfs/ZFS encryption in TPM only mode, to match their Windows setups. Systemd e.g. added systemd-cryptenroll with ergonomics comparable to Windows' Bitlocker enrollment.
its a very convenient feature
through is not convenient to setup
and a lot of Linux users never trusted it to be secure, i. e. a lot of people expected an attack like this sooner or later
at least the recent ubuntu versions when using the default full disk encryption setup do setup decryption using TPM you still need an additional password as without you would e.g. lose access to your data if you change some hardware, you motherboard brakes or depending on how they set it up you also need the password after kernel upgrades etc.
but the vulnerability allow someone with hardware access to access all your data by booting their code but messing with the TPM in a way where it still measures as if it's was booting your code
When our attack is successfully executed on a target, this means that TPM+PIN is broken on systemd-cryptenroll, and as secure as PIN-only with the same PIN on BitLocker.
When TPMs became popular, dedicated TPMs were mainly used, being a separate chip on the mainboard connected via the SPI or LPC bus. These were prone to (relatively primitive) bus sniffing attacks, where you would hook up a Logic Analyzer to the bus, watch a regular boot procedure grab the disk key, and then use software like Dislocker to extract all data from a USB Live Linux or alike.
Nowadays, most modern CPUs (both on Intel and AMD) ship firmware TPMs that are "included" with CPU die, making them safe against the bus sniffing attacks. However, they can still be prone to more sophisticated attacks like ours.
they are for boot chain security which is an essential featur for any laptop
TPM by itself never prevents anyone from doing anything
but it's used with features like secure boot, but as long as they fully implement the spec they don't prevent you from doing with your laptop what you want as long as you don't install software which does so
secure enclave and similar used for DRM isn't directly a TPM feature but more an extension using TPM and other CPU features
and yes it can be used to security store keys in your hardware. Any keys! A feature any user understanding security would appreciate.
For DRM to work, it has to be running in a trusted environment where the user can’t just load up a debugger as superuser and read the keys from memory.
The way you do that is by using secure boot to ensure that you are running a trusted kernel that enforces appropriate access controls… which requires TPM.
One of the main selling points of TPM is that you have chain of trust to ensure the boot process wasn’t tampered by a rogue boot loader that modified your code. And, yes, that has security benefits as well, but don’t for a second think that DRM wasn’t a major consideration.
and attacks which mess with the boot chain have been a huge problem for a long time for enterprises, TPM likely would have ended up very similar to how it did even if there wouldn't be DRM. Also the DRM lobby has since a long time pushed for moving (parts of) the DRM into the firmware (i.e. in a context where TPM doesn't matter much), which is where vendor-locked secure enclaves and similar come in which are related to TPM2.0 but not the same. For example on some ARM/Android chips part of the DRM system is in a locked secure co-processor.
And just because something can be abused doesn't mean it isn't useful or it's fundamentally bad. Through you seem to be making exactly that argument now with a "but it was designed with bad things in mind" added, which is a IMHO pointless argument. What matters is what it _is now_, not why it ended up there.
And what it is now is an _essential_ security feature for laptops, which also can be abused iff used in combination with some other features and that other features are tweaked to harm the user (e.g. don't allow custom keys for secure boot).
Yes, I am aware of that. But having DRM that is not completely ineffective has a prerequisite that it runs on a kernel that does enforce those access controls. The only way that works is with a trusted boot chain.
You originally responded “no” to a post saying that one purpose of TPM is to facilitate DRM.
The fact that both TEE and fTPM run on the PSP (or AMD-SP) might add a little confusion, but is nevertheless interesting.
I was using the phrase “trusted environment” more generally than that.
I do not mean a separate environment from the main CPU. Rather, that applications (like software DRM, or even the graphics driver) running on the CPU can’t trust the OS to enforce access controls without a secure boot environment.
How do you know that windows won’t let the user spin up a debugger and dump all your memory (or load a modified driver that lets them dump the frame buffer after content has been decrypted) for later use?
You need to trust that you are running in an environment where users haven’t just loaded whatever kernel modules or graphics drivers they want.
TPM is generally how you get a secure boot chain, so it is a prerequisite. Hence, TPM facilitates DRM.
https://www.reddit.com/r/pcgaming/comments/phutif/riot_games...
Part of that is things like:
* Don’t load an unsigned (or wrongly-signed) GPU driver, because it might be modified to allow a user to read from framebuffer memory after content has been decrypted.
I imagine that the MPAA et. al. are planning to attack the splitter thingy one day, so they’ll want to make sure you can’t slurp the frame buffer when that avenue is gone.
The TPM supports encrypted sessions, but they are opt in. See Parameter Encryption in the TPM spec. The issue is that Bitlocker doesn't use them for whatever reason. If Bitlocker turned on encrypted sessions, it would be not possible to sniff the key. It's crazy that Microsoft keep things insecure.
this makes it very very unlikely to be usable in a virus or remote attack
but if you lose your arm laptop and didn't use a encryption password you might want to consider your data leaked
also I would treat Intel cpus the same, Intel having a similar vulnerability is not unlikely
So I take this is more of a data exfiltration type of attack?
Edit: here is the POC https://github.com/PSPReverse/ftpm_attack
QUESTION FOR THE AUTHORS: Is there any way in which a voltage fault injection vulnerability in the SP can affect only the fTPM and not actually be a full host compromise but for the fTPM compromise?
I believe the answer to that has to be no. If you can compromise the SP you can compromise the whole system. Therefore this isn't really about fTPM. But you'll notice that many commenters are running away with this and saying that TPMs make systems less secure, which is not really correct.
Yes, TPMs are not used correctly by most BMC/BIOS implementations, or even by OSes, and there are vulnerabilities that arise from that misuse. But TPM 2.0 does provide what is needed to solve those issues.
The wholesale attacks on TPM 2.0 itself here are not warranted, especially if the SP vulnerabilities are more general rather than being specifically limited to fTPMs.
This is not addressing my question. It's not the TPM that's exploited but the SP. If the SP is compromised then the whole host is compromised.
People don't need "flagship" CPUs for every single purpose. There is no reason why one cannot have a slower more private system for specific purposes, say general purpose computing, and the faster one with the autonomous network-aware CPU and OS be used for games only or something.
I am waiting for a high performance ARM or RISC-V chip that's on par with AMD and Intel performance. One without secure boot. The moment that comes out, my Ryzen system is going in the bin immediately.
Tenstorrent Ascalon, a RISC-V CPU TBA 2024, has performance competitive with projected Zen5 performance, while using less power.
As Zen5 is also TBA 2024, they'll be on par in the same year.
RISC-V is inevitable.
[1]: https://trustedcomputinggroup.org/wp-content/uploads/TCG_Sto...
Looking into it shortly, I've found a paper from 2019 from Meijer et al. ([1]) finding several flaws with OPAL-compliant drives. They further find that BitLocker entirely depends on SSD-based encryption if the hardware advertises it. This finding's nature is very similar to ours in that BitLocker's Disk Encryption is insecure/unreliable in particular hardware configurations.
Do the researchers consider it a known fact that that fTPM is broken by design and thus do think that nobody will get hurt? It would make sense to require an additional passphrase on fTPM devices for bitlocker. Was there a statement from Microsoft or AMD?
That sounds pretty practical.
No. Your wording suggests that once attackers gain physical access, all is lost. It is not true. With a passphrase based full disk encryption, if the passphrase is strong and the machine is powered off, physical access doesn't imply data access.
https://www.bloomberg.com/news/features/2018-10-04/the-big-h...
This is _trivial_ for any mildly sophisticated attacker.
Room bugged = keyboard keylogged
So cracking it in 3 hours by amateurs is pretty bad, because now even not too sophisticated thieves can start looking for crypto wallets or sensitive data to ransom.
anyone did similar tests to the el-cheapo ones that will end up on 99% of computers around the world?
My bet is that messing with voltages on those chips too will expose all sorts of exploits too.
The beauty of a discrete TPM is its anti-hammering protection, making a numerical PIN a very effective security measure (akin to a SIM/SmartCard).
[1] https://www.sciencedirect.com/science/article/pii/S089812211...
There's still other active attacks resulting from the BMC and BIOS and parts of the OS not also doing the encrypted session thing.
wether pluton features contributed to allowing this attack I can't tell from the abstract
As this includes an attack against the secure processor, does this also pose risks to any DRM keys?
No, thanks, bioctl(4) works well under OpenBSD for disk encryption and so will do under HyperbolaBSD.
When did we start creating nightmarish system complexity to guard against attacks that are generally exceedingly rare....oh wait. Forgot where I was.
I'll take "nightmarish complexity" that puts these attacks outside of the scope of a technically savvy teenager over having to carry my machine with me everywhere I go, any day of the week.
trust only open-source software crypto