Honestly TPM is probably creating more bad than good at this point.
Every time I think about the millions of computers that will be declared worthless this year, it makes me a little bit more angrier.
Every time I think about the millions of computers that will be declared worthless this year, it makes me a little bit more angrier.
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.
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.
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.
Also, made me remember (once again) decade old presentation on TPM: https://www.youtube.com/watch?v=XgFbqSYdNK4
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!