Windows 11: TPMs and Digital Sovereignty(secret.club) |
Windows 11: TPMs and Digital Sovereignty(secret.club) |
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...
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.
TPM came next.
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.
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,
lots of banks’ legacy OFX endpoints are listed here: https://www.ofxhome.com/index.php/home/directory
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?
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.
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.
"(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"
https://www.cnbc.com/2021/10/05/microsofts-panos-panay-expla...
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.
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.
https://gbatemp.net/threads/nintendo-reportedly-issues-dmca-...
„ 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“
DRTM, a technology supported by Windows 11 that is layered on top of the TPM, aims to solve this very problem.
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.
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".
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.
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'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.
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.
See also:
https://courses.cs.washington.edu/courses/csep590/06wi/final...
(TFA linked this, too.)
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.
If statistics bear out, you'd be incorrect (at least with regards to a non-Windows OS being run by 'most').
I keep a bright line between personal equipment and work equipment.
Anyway, my last few jobs have given me Macs for development.
I guess I do have multiple partitions after all, they're just on different machines!
Use what you prefer. I can use any and get my job done. All 3 have their own pros and cons.
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.
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.
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
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.
And native desktop development is, like, 2% of enterprise development. Tops. And all the paying users are over on the mac side.
...which leads me to believe that Cobol does not lend itself well to unit and integration testing in isolation then.
[1] https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf...