> You’ve probably noticed that the marketing for this requirement is vague and confusing, and that’s intentional. It doesn’t do much for you, the consumer. However, it does set the stage for the future where Microsoft begins shipping their TPM on your processor. Enter Microsoft’s Pluton. The same technology is present in the Xbox. It would be an absolute dream come true for companies and vendors with special interests to completely own and control your PC to the same degree as a phone or the Xbox.
Explains why official sites don't explain what the TPM is beyond "security" [1], nor that this "security" means "security against the owner" - though the computer is nominally yours, it's built to keep secrets from you.
When Microsoft originally published a short page with their justification of the advantages of UEFI and GPT drive layout, everything touted as an advantage was false.
As this was foisted and users became accustomed to the migration away from more well-proven traditional operation, the page was edited into oblivion as it could be seen users would have better recognized the falsehood by then after having some direct experience.
So many "influencers" were already carrying the flag on their own that the page was eventually removed.
The page is long gone now but I definitely saved a copy because it was so blatant. Don't know how easy I can find it. May be on the Wayback Machine.
It had recently become possible to bypass Windows 7 activation using "Windows Loader" (by DAZ), a sophisticated hacker tool which loaded the proper BIOS hardware key[0] not from the mainboard, but optionally from a replaced MBR sector 0 on the HDD which then pointed to a file containing a copy of the original sector 0, from which the non-W7 MB then could boot W7 normally without needing activation.
GPT as "standard" and UEFI with Microsoft SecureBoot were then rushed out in time for the W8 release. Therefore almost all PC's newer than the ones "designed for W7" would require not only a complete HDD refomatting, but a more extensive complete repartitioning (MBR-style) before anyone could even try to install W7 or anything else other than what the PC originally shipped with.
Seemed to me simply to make it more difficult to install W7 on all future PC's, which would turn out to be the main competition for W8 after all. Linux was not as much of a threat, but the collateral damage was not unintentional and set Linux PC and dual-boot approaches back at least two years.
Now there is supposedly a hack that allows W7 to be installed on GPT volumes.
One of the Microsoft claims was that one of the security "deficiencies" of MBR HDD layout not found with GPT was the unused sectors which padded the area from sector 1 up until the first sector of the first partition which is the partition's boot sector (usually up to sector 63 but at least sector 32 and sometimes 1024 or more). This normally unused area between sector 0 and the first partition's boot sector was a good place for GRUB to routinely use for its bootloader but had also been a location for the occasional "rootkit" that could not be removed by reformatting or often even repartioning (you would have to zero that part of the HDD using ordinary non-Windows tools, like a disk editor or dd in Linux). Also an optional location for Windows Loader. "Benefits" of GPT was that no sectors are unspecified, true but in practice sectors 5 through 31 are still never used unless you have created more than 8 GPT partitions on the HDD. You can also leave as much space in between GPT partitons as you would like (this is not the factory default), and Windows built-in tools can do the job.
If you were on top of this and had a plain MBR mainboard with protection from flashing the BIOS, there was no way the mainboard itself could contain any kind of malware. If the HDD was clean, or fully zeroed, you were fine.
With UEFI systems, which contain much more extensive and flexible firmware you were actually more subject to nefarious actions if any could be devised, which could then reside in the mainboard along with the UEFI firmware regardless how thoroughly you zero the HDD.
This seems to have now become possible, maybe with the recent leak alone.
With the slyly undocumented proprietary UEFI firmwares, it is also not too easy to know if "updating the BIOS" actually clears any possible malware that might be still lurking there along with the new factory firmware you put in.
As far as I know there is no routine malware scan to check for compromised UEFI firmware like there has been for decades with HDD's.
UEFI seemed to be very dependent on highly secret firmware keys never being revealed, otherwise I expected a UEFI MB would then be compromised in a way that BIOS MB's could not, and potentially much more difficult to detect & remove.
[0] factory key code for the Windows version that originally shipped within a W7 PC mainboard BIOS so it would not require retail-OS-style activation, could then be used to freely activate W7 on older Vista PC's and expected to function on W8 PC's to come if they had regular traditional BIOS and MBR HDD layout. Almost like they knew in advance that W8 PC buyers would massively prefer to install W7 if they could rather than the original Windows 8.0.
I agree with the sentiment of the piece, but I disagree with the idea that TPMs don't add much value for end users.
TPMs were originally designed in the early days of ecommerce, when it became clear that home computers would need better security if they were going to be used for financial transactions.
Today's TPMs don't have a lot of compute power, but they have a lot of features.
It's just that we don't have that much software taking the best advantage of those features yet, probably because they have only just become ubiquitous in the last couple years.
TPMs lay the groundwork for unphishable credentials, using hardware-bound asymmetric keys.
TPMs add a user-friendly option for full-disk encryption, in a way that's resistant to physical attacks.
TPMs can be used to protect symmetric credentials too, instead of storing them on disk (see systemd-creds TPM2 support).
And, TPMs do have actual privacy mechanisms. End-user TPMs do not offer up their endorsement key to any third party. Attestation workflows shield third parties from the endorsement key.
I'm excited for more widespread use of TPMs in Linux especially. Lately systemd has been making some good progress here.
Seems like a lot of banking and other secure business is moving to mobile first or mobile only, presumably as it's likely the only secure device the user has.
I agree with your assessment: desktop-browser online banking (with US banks in particular) is a depressing experience given how they’re full of ads for credit-card offers and manual (if not broken) OFX/QFX downloads that only contain a fraction of the actual backend txn data that the banks won’t ever share with their (retail-banking) customers…
And yet, while lots of banks now use SMS 2FA, none of the banks I use (Chase, BoA, Citi, and a couple of credit-unions) offer the far more secure TOTP scheme, let alone any way for headless clients to download txn data except via the literally-25+-years-old Quicken/Intuit OFX endpoints - presumably without 2FA, but with zero documentation in their online help and their retail banking customer support people have no idea what I’m talking about when I say OFX - it’s maddening,
LOADS of data - especially for industry-verticals that have heavy integration with credit-card companies (e.g. airlines include ticketing and even seat info in the metadata they submit to banks: this dates back to how air-miles rewards cards originally worked in the late 1980s) and there was tight integration between banks and airlines - even (or so I'm told) to the point of where banks' in-house "main" databases and ssytems have dozens of very, very hardcoded fields because of that early collab work - which then ossified in-place and now everyone's too scared to remove those now unused fields for fear of breaking everything.
...which leads me to believe that Cobol does not lend itself well to unit and integration testing in isolation then.
> And, TPMs do have actual privacy mechanisms. End-user TPMs do not offer up their endorsement key to any third party. Attestation workflows shield third parties from the endorsement key.
Then how do endorsement keys work?
If I understood the OP correctly, the purpose of the endorsement key is so a third party can choose only to accept attestation from TPMs of "trusted" vendors. How does this work if the third party can't query the endorsement key?
Ah, this was a grammar error on my part. Sorry about that, let me clarify.
TPMs do offer up their endorsement key (or an endorsement key certificate) to third parties.
And, TPMs can share attestations in a way that doesn't reveal the endorsement key. They use attestation keys for this. Attestation keys can sign TPM attestations, and these keys do not identify the TPM.
This approach requires a trusted CA. The CA confirms the TPM's identity (using an endorsement certificate issued by the TPM vendor), it confirms that the attestation key and endorsement key reside on the same TPM, and it issues a certificate for an attestation key.
The attestation certificate might contain TPM vendor info, firmware version number, and proof that the attestation private key is hardware-bound. But it need not contain any permanent identifier. The TPM can now use its attestation key and certificate to sign attestations for a third party.
Yes, there are end-user uses for TPMs. But, personally, none of them are compelling enough to overcome my fundamental mistrust of how companies will use them.
The underlying point you should be calling out if you want to present this argument is that "User freedom should prevail over companies' freedom". The only thing attestation enables is companies enacting their own policies along the lines of "I only want users who are willing to let their device attest x level of security". The user is not required to use that service, they're not required to run W11 or to enable the fTPM in their BIOS.
Asking for widespread change and the death of TPM attestation is like saying that companies should be forced to serve all customers even if it degrades the services they provide, if it requires x orders of magnitude more personnel for fraud/risk/etc management, or if it degrades the experience of other users on the service willing to perform attestation. Maybe this is the right approach, maybe we just need some good regulation that won't deepen the moat of existing players, but this is the crux of the argument being made.
> We are here to remind you that the TPM requirement of Windows 11 furthers the agenda to protect the PC against you, its owner.
No. It's to protect third party services that your PC makes network requests to. Your PC in itself doesn't need any protection from you.
Ok, so instead of Microsoft turning my PC into an Xbox, it's banks asking Microsoft to turn my PC into a credit card reader. This is not materially different.
We already know how this works on Android. Attestation requirements and DRM tend to creep beyond their initial scope if implementing them is easy. And those requirements will include not having owner-level control over your machine[0]. If you root Android, you basically forefeit access to all banking apps, most gaming apps, and a whole bunch of things that you wouldn't even think should require secure attestation.
On the web, we all thought that EME DRM was going to lock down web video and cascade into audio and text. This didn't come to pass primarily because DRM vendors charge money that free web video platforms don't have. If EME had made DRM ubiquitous, the best case would have been one distro vendor offering "blessed" kernel builds that can still "go online", and anyone wanting to be online with their own Linux kernel potentially violating DMCA 1201 or being limited to an increasingly shrinking "clearweb".
There's three types of companies here:
- People that absolutely need user-hostile attestation: banks, competitive multiplayer games, and streaming services
- People that would never demand attestation on principle: normal websites, blogs, web forums, the Fediverse, and YouTube[1]
- People who would implement attestation if it were available regardless of the impact on their user base: Facebook/Meta, Twitter, basically any social media network.
That third group is arguably the largest. They will tolerate unattested users, but they wish they didn't have to. Making attestation easier makes it way more likely for them to demand it.
[0] This could be made less onerous with per-partition boot policies, but only Apple Macs do this AFAIK.
[1] YouTube's stance on DRM is very very weird. Google has the capability to DRM all their content, but they don't. And they've used YouTube as a trojan horse to push open standards like VP8/9 and AV1. On the other hand, they do try to obfuscate video download in ways that the RIAA thinks is DRM.
As a truly absurd example of "if you give developers the option, they will abuse it" : I am not allowed to check the train schedules for the Slovenian national rail service on phone with a custom ROM (not even rooted).
Turns out, the company that got the tender to build it encrypted all traffic to the API with a custom encryption scheme and added three layers of obfuscation/anti-tampering (presumably) in order to make it basically impossible for another company to take over the app, guaranteeing all subsequent tenders go to them. The only even remotely sensitive thing - buying a ticket - happens in a WebView anyways, 90% of the app is just timetable data.
I don't really understand why I can't also force my device to _lie_ to any app that demands that. Is it somehow checking the exact combination of my firmware against a database of allowed root certs?
More or less, yes. The exact details vary from system to system: TPMs were built for PCs where firmware and OSes are diverse, so TPM works off boot measurements and hash functions. On phones all the attestation stuff runs on a separate processor with only one kind of firmware and it gets told by the main processor whether or not the user installed a custom ROM (in which case, no attestation for you).
This is because the people in the "need attestation yesterday" camp specifically do not want a system in which device owners can lie about their attestation status, because:
- For streaming video platforms, the whole point of trusting attestation is to prevent owner tampering, because they want to ensure that you aren't retaining any video past your subscription end date
- For banks, they want to protect you from hackers, rather than themselves from you, so an owner override "should" be tolerable. However, banks also work entirely off of risk assessments and probabilities. And the number of owners genuinely overriding their own attestations so they can run custom ROMs is lower than the number of hackers who would attack the override so they can steal credit card numbers. So in practice the attestation is a fraud signal[0], and allowing overrides at all is like allowing hackers to falsify your fraud data.
[0] Specifically a signal that something is NOT fraudulent, since all the correct, unmodified software was run
To lie you need to have control of the TPM or trick it somehow - otherwise the remote service will know you are a liar.
This is still possible on Android for instance but it gets more and more difficult - I have a health tacking app that complains daily about the fact that my device is rooted - I will have to see what setting i have to block from it so it stops doing that.
My understanding is that there is something like a system call that a program can use to query the TPM for the current system state. The TPM will then reply with some sort of hash representing the state and also a signature for that hash using a private key stored inside the TPM.
The program (i.e. the netflix app or a browser) can then pass on that data structure to netflix' servers, which will then decide if they permit 4K content or not.
To circumvent this, you'd have to know two things:
1) what kind of hash for a "non-rooted" system netflix is expecting in the first place.
2) the private key to sign the hash with.
To get the former, you'd have to eavesdrop on a connection on a non-rooted device. To get the letter you'd have to extract the key from a TPM, which is likely specifically built to make this hard.
> The underlying point you should be calling out if you want to present this argument is that "User freedom should prevail over companies' freedom".
I'm still baffled by the DMCA's anti-circumvention clause in that regard. While users are given some rights in the DMCA, companies seem to be perfectly free to trample over those rights using technological restrictions. If users then try to circumvent those restrictions, suddenly they are in violation of the law.
One of the reasons why Microsoft and OEMs are promoting TPM is to encourage planned obsolescence, so that users will replace their PCs as often as they replace their smartphones, right?
"(Lenovo) said people buy new smartphones every other year but became accustomed used to buying new PCs every six or seven years. The industry needs to do better at motivating people to buy new devices"
Tbh I'd expect the trend of upgrading phones to start to slow down as well as they become "good enough" but there are still pretty big gains being made in cameras.
Laptops are just good enough now. If you took the 3 year old M1 internals, and stuck them in the new case and told me it was the 2024 model, I'd not notice anything was off.
Phones are locked down. All you need is a vendor to refuse further software updates after 5 years, after releasing a more resource-draining updates prior to this, and it doesn’t matter how good the old hardware is. People won’t be able to use it
A capitalist economy predicated on infinite growth necessarily needs planned obsolescence to artificially churn consumption to increase growth (with new devices costing more). With public-traded companies bound to make profits for shareholders, this is no surprise.
> Did you know that technologies such as Intel Boot Guard that have existed for the better part of a decade defend well against such attacks that might seek to overwrite flash memory?
It's rather funny to see Boot Guard as a "good" example here. Boot Guard is what's actually taking freedom away. With a vendor-locked Boot Guard configuration, you cannot replace the firmware with anything not signed by the vendor. Bye bye dreams of coreboot (until a private key leaks like it just did ha ha).
Netflix & co denying service to machines that don't pass Microsoft attestation? Literally who cares, just go to The Pirate Bay instead.
„ specifically, Lockpick bypasses the Console TPMs to permit unauthorized access to, extraction of, and decryption of all the cryptographic keys, including product keys, contained in the Nintendo Switch“
Except, in the future, your Linux partition will be unable to access most online services because they'll all rely on remote attestation to check if your device is running an unmodified Windows OS, similar to what many android apps already do.
> to check if your device is running an unmodified windows OS
Remote attestation sounds secure in theory but its Achilles heel is that at the remote end sb will have to perform a judgement of what „an modified OS“ is. And any wrong decision will stress test that sb‘s support division and might be subject to litigation. Likely there will be some industry standard white list which itself might be subject to manipulation (similar to the compromised SSL root certificates we had years ago).
I can’t imagine this will be set in place for all available PC software.
Furthermore, attestation happens during run time of a software stack that might itself be vulnerable to exploits. An attacker might find a way to short-circuit remote attestation w/o the remote party knowing.
I switched to full time macOS in 2019 from a 15 year background professionally on Windows in IT admin/architect type roles.
Granted, at that point Windows was web browser, IDE, and remoting into Linux machines for 95% of my work.
I appreciate having first class support for all my command line tools and utils, which I generally get on macOS. I have linuxified my macOS experience, installing and pathing gnu versions of everything you would normally expect. I rarely use the utils from macOS.
I have a Windows gaming PC that hasn't been powered on this year.
I like my MBP battery life and lack of futzing needed for my work (I do use better touch tool, but that's it).
I have turned down further interviews if I find out I'm going to be saddled with a corporate locked down Windows laptop.
You can run older Word versions (up to 2016 I believe) very well inside wine. It’s even easy to install (PlayOnLinux e.g. guided you through the install). No need for a windows license.
I've found libreoffice to work well enough for any docx simple enough to have come from an older version of Word, but I might just be ignorant of how Word actually differs from the tools I use to view it; it just works for me ¯\_ (ツ) _/¯
I do find the suite rather large, but use functional package management to keep most of it's files abstracted away-- I bet the appimage or flatpak is pretty sweet in the same way
I also imagine I'm not the only one who doesn't use their work laptop for personal stuff (even on a separate partition). At my previous job, I never even took my work laptop home, and in my current remote job, my work laptop gets booted up at the start of each work day and shut down at the end; I have my own devices for non-work use.
Not me. Any work I'm doing for an employer is done solely on equipment they supply and everything else is done solely on my own equipment. Never the twain shall meet. So my personal machines are all 100% Linux, and my work machines are all whatever my employer wants them to be.
I guess I do have multiple partitions after all, they're just on different machines!
If Windows is required for work then you've already lost. Seriously I'm unable to be productive in Windows (or Mac, I tried). I don't know what the stats are on employers requiring Windows but my current one doesn't (mainly because of a sizable chunk of Mac users, not that there's any support for Linux).
Where I work pretty much everyone who's not a developer or system admin uses Windows. Most of them never leave the confines of Edge, Teams, Sharepoint, Outlook, and MS Office with maybe the exception being Zoom. It's an enterprise config of some sort so it more or less stays out of their way. Windows Home sounds absolutely horrific and I can't imagine why anyone uses it, other than they don't know anything else.
So you’re used to Linux. But there are people who can do your job faster than you who use windows or macOS. Just like there are people who will work slower and be limited compared to you.
Use what you prefer. I can use any and get my job done. All 3 have their own pros and cons.
I don't develop or support anything on Windows. Sure that excludes 99.9% (I guess) of career options involving a computer, but I've still found employment that doesn't require Windows. But once either Microsoft finally succeeds at banning Linux from running on desktop PCs (which is basically what this is about), or every single employer requires everyone to run Windows, then I guess I'll switch careers to farming or something.
The same thing will happen that always happens... some TPM vendor that has millions upon millions of devices in the field will have their private signing key leaked. MS won't be able to cripple millions of machines. Bam, before you know it someone has a patch for QEMU to have it emulate a device with random identifiers signed using the leaked key.
Except that it can't actually do that, because x86 DRTM doesn't remove SMM handlers installed by the system firmware, ACPI tables also remain resident and could be changed to contain malicious code, etc.
DRTM does not remove any malicious firmware provided code or data. Traditionally it is merely a measurement mechanism that happens after ExitBootServices which measures platform state in an unforgable manner. Practically the DRTM event can also cause certain chipset registers to get locked or SMM supervisors to get launched depending on the platform. SMM and ACPI tables (on some x86 platforms certain tables are rebuilt) are measured into a PCR by the secure loader or security processor during the DRTM event. The idea is that if malicious code or data was present then the PCR values wouldn't match the previous boot session and TPM secrets wouldn't unseal.
While what you said is technically correct, it is by design and any compromised firmware can do as it pleases before the DRTM event at the cost of getting caught and having the device fail attestation or not be able to access encrypted data (depending on what policy is layered on top of DRTM itself as it is just a security primitive). By having PCRs get reset during the DRTM event secrets are much more reliably able to be sealed to specific PCR values.
The claim that SMM is measured by (Intel) DRTM is interesting. Do you have any details on that? To my knowledge Intel was trying to solve this issue using the concept of an 'SMM Transfer Monitor (STM)' not simply by measuring the SMM environment [1]. But it's been 8 years since [1] was written so if you have links to more current information, it'd be welcome.
Unfortunately, I don't believe there is any up to date and detailed public documentation on the modern DRTM flows that exist on both Intel and AMD platforms. Maybe documentation has been recently updated but I’m not sure if I’m able to share more beyond what I already have.
I was so into locking down systems, making sure I knew where every packet was going, not trusting anything.
Meanwhile I'm also "wardriving", phreaking with a red box, running an underground BBS ... all sorts of stuff. I had one of those fancy t-shirts with the export-restricted RSA encryption source code printed it. Because, why not?
Now I just quickly skim a 2 year old article about Windows 11 and TPM again, on a Windows 11 device, and have just enough left in me to post a comment.
> You see, the PC (emphasis on personal here) is in a way the last bastion of digital freedom you have. The TPM requirement of Windows 11 furthers the agenda to protect the PC against you, its owner. These keys are then cryptographically tied to the vendor who issued them, and as such, not only does a TPM uniquely identify your machine anywhere in the world, but content distributors can pick and choose what TPM vendors they want to trust.
Every time these technologies come out, there are similar "it's all over" scenarios. But so far it hasn't been all over, and I've been around a while. I recall Intel Management Engine (ME) really piquing my interest for a bit. So my computer now has a computer running on it, that still runs when I turn it off, has access to the system hardware, including memory, the contents of the display, keyboard input, and the network? And the keys to the kingdom are secure ... they haven't been shared with anyone else who may be highly interested in having those ... ?
Hello, anyone ... I'm still secure, right? ... right!? Forget it, I'll just disable it. Oh. Nevermind. Wait ... what? Intel ME has a ring −3 rootkit??! Just ... ah, forget it ... what's on TV?
And then AMD shows up with their own. At least that one can be disabled by BIOS. I think? Hope?
> Did we mention that a TPM isn’t going to protect you from UEFI malware that was planted on the device by a rogue agent at manufacture time?
If you are the target of a rogue agent at manufacturing time, that is way past "game over". If they want it they're going to get it and you're not going to stop it by having, or not having, things like TPM on a Windows machine. I can't tell if this is more about losing the ability to watch HD video and DRM, or if nation states are coming after you. Those are slightly different. I'd personally prefer neither but I'd settle for the former. If it's security then it's more Tor/Tails and a USB key than Windows.
Certain groups can even shut down highly specialized air-gapped equipment that is deeply underground. It's like "if there's a will, there's a way".
and that's one of the reasons I see no use in TPM. This is also a layer of complexity which usually is the opposite of more security.
TBH I don't get it why people cheer this TPM and Secure Boot stuff as much.
Explains why official sites don't explain what the TPM is beyond "security" [1], nor that this "security" means "security against the owner" - though the computer is nominally yours, it's built to keep secrets from you.
[1] https://support.microsoft.com/en-us/topic/what-is-tpm-705f24...