Hacker News new | ask | show | jobs
by repiret 241 days ago
I agree with all of the articles points except for the first one: TPM and Secure Boot do not reduce user choice or promote state or corporate surveillance. If you want to be able to prevent root kits you need secure boot, and if you want to store secrets that don't need a user password to unlock and can't be stolen by taking apart the computer, you need a TPM; or you need substantially similar alternatives.

I would say that specifically with Secure Boot, Microsoft actually promoted user choice: A Windows Logo compliant PC needs to have Microsoft's root of trust installed by default. Microsoft could have stopped there, but they didn't. A Windows Logo compliant PC _also_ needs a way for users to install their own root of trust. Microsoft didn't need to add that requirement. Sure, there are large corporate and government buyers that would insist on that, but they could convince (without loss of generality) Dell to offer it to them. Instead, Microsoft said all PCs need it, and as a result, anybody who wants to take advantage of secure boot can do so if they go through the bother of installing their own root of trust and signing their boot image.

17 comments

> I would say that specifically with Secure Boot, Microsoft actually promoted user choice: A Windows Logo compliant PC needs to have Microsoft's root of trust installed by default. Microsoft could have stopped there, but they didn't.

This was not the case with the initial rollout of Secure Boot, it was combined with locked BIOS to lock PCs so that they could only boot Windows 8 on some devices. This was the case on Windows RT ARM machines from that era.

All that has to be done today for machines to be locked down again is to flip a bit or blow an e-fuse. It's already the case on phones and tablets.

There is also a real potential for abusing TPMs or cryptographic co-processors to enforce remote attestation.

I say this as someone who agrees with your first paragraph and uses Secure Boot + TPMs on all of my machines.

> There is also a real potential for abusing TPMs or cryptographic co-processors to enforce remote attestation.

People here REALLY need to start understanding this issue. Remote Attestation is the kind of tech that if abused will end free computing over night.

And it's already happening in the form of Google play integrity API. Many apps already require it. It's just a matter of time before they push similar tech to the desktop. And on mobile it hurts more because many banks now require a mobile app for 2FA.

Personally I think any form of attestation is evil.

I agree. Now: "Papers, please."
There's a reason Microsoft is aggressively deprecating "older" CPU's that work perfectly fine. Heck, I have one laptop with Windows 11 that worked great, but won't update from 22h2 to 24h2 because CPU support was dropped between versions, leaving me with only the glib suggestion from the Windows Update UI to "Buy a new device".

Ironically, installing Windows 10 and activating ESU would lead to longer hardware life.

Of course, I didn't. Instead, I installed Linux on that laptop too. My partner had no issues switching.

TPM wasn't the only reason older CPUs were dropped. The biggest reasons where the line in the sand Microsoft chose would not be supported in Windows 11 was Spectre/Meltdown [0] mitigation. Windows 10 added a bunch of intentional slowdowns to mitigate that disaster and people incorrectly blamed Windows 10 for being slow and not the CPUs and their CVEs. Windows 11 seems to have wanted a clean slate without needing to have any of those slowdown mitigations in the codebase and eliminate some classes of "Windows 11 is slow on my machine" complaints.

I'm not sure Microsoft took the best approach. I might have opted into a "Windows 11 Slow CPU" SKU if it was marketed right. That might have been a little kinder than "all these CPUs with this awful series of bugs are trash, even though we have had a successful workaround".

[0] https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit...

Yes, Microsoft is blocking CPUs which lack the ability for Virtualization Based Security. Given OS security is important to Microsoft (surprise, I know), enforcing VBS is a priority.
Security for Microsoft...
My understanding is that Spectre etc. only is a problem if the user choses to run hostile code on their computer.
I think "chooses to" is doing a lot of work there in your understanding. Spectre exploits were found in the wild even in JS code submitted to ad networks. I suppose a user could choose to uBlock all ad JS and never visit webpages they don't trust. Those are choices, sort of.

But also that's a bit victim blaming isn't it? Do you want to explain to your grandfather or partner or child "Oh sorry, you had a password stolen because you chose to visit Google.com on a day where Google let an ad buyer attach Spectre exploit malware"? (Google could also chose to not let ads attach JS at all, but that's a very different problem.)

Computers have millions of places they get code from to run. Is "your CPU has a data leaking bug in it" the user's problem or the OS's problem? When there's a mitigation the OS can manage? When security-in-depth is an option?

I installed Bazzite on my own old Desktop not supported by Windows 11. One of the first things the Linux kernel spits out on boot if I have the boot console up is about running with Spectre mitigations. The Linux kernel also thinks it is important to mitigate (as Windows 10 did, but Windows 11 doesn't include and so doesn't support this old Desktop).

Windows 11 has full spectre/meltdown mitigations by default. That Wikipedia article doesn't mention Windows 11 at all.
> People here REALLY need to start understanding this issue.

The idea that understanding is the problem feels like a fallacy. People need to upgrade hardware, and when all chips contain such functionality, consumers won't have a choice of alternatives. What you want is legislation (or a dominant competitor lacking such features, which doesn't exist).

Legislation doesn't help unless its the right legislation.

After all, legislation is what is forbidding you from producing a competing x86 processor with the changes you want.

Remote attestation is already here with Play Protect/Integrity on Android, and Microsoft's Pluton co-processor enables the same thing
See also:

- Private Access Token [0]

- Web Environment Integrity [1]

among other proposals.

0: https://news.ycombinator.com/item?id=31751203

1: https://news.ycombinator.com/item?id=36785516

Microsoft had a lot of practice with this with the recent Xbox hardware & software.
> over night.

No, I think they bend over backwards not to do it overnight because of the outcry but try to make all required changes and enforcements gradually over the years so in the end you will have no choice but there will not be any sudden change that would spark protests.

s/if/when/
> This was not the case with the initial rollout of Secure Boot, it was combined with locked BIOS to lock PCs so that they could only boot Windows 8 on some devices. This was the case on Windows RT ARM machines from that era.

Okay, but, that was like 15 years ago, on some shitty first-run computers that no one bought. A failed first attempt. I've never met a single person that owned, or has ever used, a Windows RT device.

The world has moved on. But oddly continues to buy bootloader-locked iPhones and Androids by the bucketful.

Dwelling on the past isn't going to move us forward. Anyone pushing the "Secure Boot and TPM are evil" trope in 2025 is objectively a fool and should be ignored. Most don't even realize what a TPM does, they think it's some secret chip inserted by glowies into their computers to prevent them from running free software. No.

Normally I would agree that security measures are needed in many, but not all cases, but only if they are in complete control of the user and cannot by altered by any one organization. For-profit companies cannot be in control of these mechanisms. We have seen how they can be abused with the latest decision by Google to limit side-loading to people who identify themselves. So your take is really a misdirection from how these tools are being used against our property.
> For-profit companies cannot be in control of these mechanisms.

But they are not in control of Secure Boot.

Microsoft runs a root CA that is pre-installed on most PCs. It could have been Verisign or someone else, but MS made sense at the time, likely because they had additional code signing expertise.

You are free to delete these keys and/or install your own. If there wasn't preexisting infrastructure, Secure Boot would be DOA for most people.

Microsoft can force manufacturers to can change the way that works at any time, its vendor specific and they are totally in control, via pressure on manufactures to toe that line if they want to continue sell computers with Windows.
> But they are not in control of Secure Boot.

> Microsoft runs a root CA that is pre-installed on most PCs.

How can you write those two statements on two adjacent rows? In practice that makes MS a gatekeeper.

Don’t confuse the real point with the caricature. There’s a very real risk of only giant corporations being able to control software, because the general public does not even draw a distinction between “having control over what software is running on your computer,” and “being able to run a curated collection of software blessed by the manufacturer and subject to their exclusive discretion.” The full acceptance of the Apple iOS platform proves this. Apple must bless all binaries, and except for cases that are getting less and less common where jailbreaks are possible, the user has no authority and you could argue they do not own the device.

Some combination of the advertising industry and those with a vested interest in anti-fraud such as banks will eventually try to sneak remote attestation in there, which has the potential to put a complete end to ownership of devices as we have always understood it.

> Dwelling on the past isn't going to move us forward.

Forgetting the past will make PC's as closed as phones.

I wouldn't mind that if in fact the parent poster didn't try to make it look like an argument that Microsoft is kind and playing nice. They did a bad thing there, there was an outrage, they fixed it, the end. If possible, they will do another bad thing again, should it benefit them.
> Okay, but, that was like 15 years ago, on some shitty first-run computers that no one bought.

I wouldn't call the first Microsoft Surface, Surface 2, Dell XPS 10, and Lenovo IdeaPad Yoga 11 products that no one bought.

> I've never met a single person that owned, or has ever used, a Windows RT device.

I have and I also regrettably bought one myself.

> Dwelling on the past isn't going to move us forward.

The past dictates the future, and history repeats itself. Microsoft made their intentions known, it would be foolish to pretend they haven't. They continue to make their intentions known today with the Pluton cryptographic co-processor, that paired with a TPM, can enforce remote attestation by design. That is literally the intent of the Pluton chip: ensuring platform integrity and securely attesting to 3rd parties that your system is Blessed/trusted.

> Anyone pushing the "Secure Boot and TPM are evil" trope in 2025 is objectively a fool and should be ignored

Anyone tearing down this strawman is tilting at windmills for some reason.

> Most don't even realize what a TPM does, they think it's some secret chip inserted by glowies into their computers to prevent them from running free software.

I wouldn't project ignorance on those you don't actually know. You can understand what a TPM does, understand how it can be abused today and acknowledge how it was abused in the past.

> There is also a real potential for abusing TPMs or cryptographic co-processors to enforce remote attestation.

Remote attestation can be misused, yes. But why writing it as TPM is the problem? In cases where remote attestation is used for good, TPM improves the setup, if anything.

I dont see the rationale for what you wrote, and am genuinely curious what it is.

You can't do remote attestation without something like a TPM.

Let's compare these scenarios:

A) TPMs are optional and 30% of users have them. A bank is thinking about requiring remote attestation to use their services. Since they'd lock out 70% of users they decide to not do it.

B) TPMs are mandatory and 90% of users have them. A bank is thinking about requiring remote attestation to use their services. Since they'd only lock out 10% of users they decide to do it.

And banking is the nice example here. Refusing to serve a site if the user is using an ablocker is very much in the interest of powerful players in the space, see WEI. Every platform that has wide spread TPM adoption, namely Android and iOS have shown that they will abuse them for anti-consumer purposes sooner or later. We are talking about Microsoft here, the current and past poster child for anti-consumer decisions.

I hope that explains why making TPMs blanket available introduces new risks to sovereign computing.

I see your point. Its the very unbalanced power balance between consumers and providers, and the dishonest tactics of the latter. It ought to be addressed politically (its idealistic, I know). Until then use free software and multiple devices, or something like that. The TPM chips in themselves are a powerful concept, that can, and should, be used to the consumers advantage.
Because that's what has been going on in the Android world for years and for the iPhone was the case from the start.

Root your phone, even if it is just for the ability to make full backups (because that is, to this day, not a thing on Android)? Say goodbye to banking, most games, even the proposed new EU "digital identity" government wallet was supposed to enforce attestation.

And everyone with a phone on the "bad vendor" list that either doesn't get Google certification from the start or gets it revoked due to sanctions? Same.

Then you really should be angry at Apple and Google, not the hardware.

The preparations for eIDAS 2.0 (the EU thing) has been heavily inspired by SSI. If they keep up the good work, and implement it properly, security and privacy will be top notch. And that is only possible by using TPM (or really SE when we talk about mobile phones).

Yes, I know that eIDAS might end up not meeting the early promises. We will have to see. But in that case it will be despite the possibilities that the hardware provides, not because of them.

TPMs form the root of trust needed for remote attestation. If not TPMs, cryptographic co-processors can do similar things, or work in tandem with TPMs to accomplish the same thing.
On the face of it they're just security features, and I don't deny they are, but the industry as a whole are using those features to implement device verification systems that are being used to lock down their platforms and centralize control over their software ecosystems.

Being able to install another OS isn't much good if critical applications and websites refuse to run on it.

>Being able to install another OS isn't much good if critical applications and websites refuse to run on it.

The battle has already been lost on this. Just look at all the companies that are app-only and don't offer a web version.

That the battle is lost doesn't mean we should stop fighting. Even the war being lost isn't a reason to. The equivalent in the real world is resistance.
I wouldn't say it's lost, but the trendlines aren't good.
I honestly have only come across one company that is app only. That was because I was with them when they changed over, otherwise I would never have signed up.

This was my local gym which sacked their front desk staff and moved to app access only, and with an app infested with trackers at that. Needless to say I don't go to that gym anymore.

It's popular with fintechs, especially new ones. Robinhood for instance was app-only for a few years before they got their web version. Revolut theoretically has a web version but it has far less features than the mobile app. Restaurant "apps" (for ordering and offers) are often app-only as well.
Honest question: What does TPM have to do with this? I mean, Revolut developers don't need to check for TPM or similar to serve other functionalities just because you're on browser or mobile app. Am I getting something wrong?
There might not be "TPMs" exactly on smartphones, but both Android and iOS have device attestation APIs that does the same thing that TPMs do, ie. cryptographically prove to a remote party that you're running some particular version of software.

https://developer.android.com/google/play/integrity

https://developer.apple.com/documentation/devicecheck

>I mean, Revolut developers don't need to check for TPM or similar to serve other functionalities just because you're on browser or mobile app.

Some features are simply not available in the web version. You can try running the app in an emulator to get past that limitation, but an emulator won't be able to spoof device attestations, so if they bother checking for it you're screwed.

Want another exemple as fresh as yesterday?

I'm on a move, had to pay some transport company to move some stuff for me, pick-up date tomorrow. Paid online, website asked for a confirmation from my bank's app (N26), fair enough. Opened the app, just to be greated with "Please Update. The latest app version includes new features, enhancements and stability improvements" with the only choice: "Update now".

Being confronted with an app designed to refuse to work was irritating enough (for context, I'm from a generation were we used to own our devices), but I clicked on "Update" anyway, just to be told by apple store that there was no update for my iPhone 7.

Ok, the writting was on the wall. You know, I own one iphone and 2 android phones already, all of them several years old but in pristine condition. That's how I am, I care for things. I'm not going to buy yet another one, if only because I hate waste and fear mismanagement of natural resources. That's how I am, I care for things.

Now you are mandating me to add more e-waste? There is no way I'm going to do that, so I decided to connect to N26's wensite, but guess what? You need the app to login. Well, if you insist you can also login with a short message, which I did, just to check that there was no way to confirm a paiement on the website.

But you can contact "support", so I tried that. To their credit, the robot bouncer was quick to admit incompetence and to connect me with a friendly fellow human, who was unfortunately only allowed to lecture me about why those "new features and enhancements" were essential to my account's security, while being unable to tell me exaclty what they were or what was the problem with the current version, and suggested I login from someone else's phone instead.

Security? Whose security?

To anyone working in tech, let me remind you what an actual threat model is.

My actual threat model in the actual world is that your company might stole my money, or prevent me from access it which amount to the same thing. Data points: Despite all the stories on the news about mischievous hackerz from russia and china, I've been stolen money only twice in my life, not a lot of but at the time I needed it, and twice by banks.

My threat model is that the electronic gadget that I bought and carry with me all the time stops obeying me and starts obeying some adversarial company. And that, in perfect novlang mastery, you want me to call this a "trusted device".

My threat model is that our civilization might drown in e-waste.

Want another exemple of app only service? Wait for a days or two, as I'm confident I will face the same issue soon.

Yes, your bank is shit, but this is also Apple's fault to a large degree.

There is absolutely no reason to release a new major version of your OS every year, and there is no reason to arbitrarily drop support for older devices (except extremely contrived ones, that I'm sure will be posted below). I made the mistake of acquiring an Ipad once. Its only job was playing YouTube videos in bed (yes I know), until Apple and Google in unison decided that it should be thrown into a landfill, because its OS was unsupported and the YouTube app, for no reason at all, would no longer work. Was the device suddenly unable to decode H.264 video or playing audio? Nope. But please just throw it in the trash and buy a new one - what are you, poor?!

> this is also Apple's fault to a large degree

I don't know, I haven't checked extensively but I believe supporting iphone7 is still one checkbox away in xcode (xcode 26 release notes state that it "supports on-device debugging in iOS 15 and later", which is what is installed on my iphone).

I could imagine how some team at N26 though that "supporting" more devices was too much on their plate, which I would sympathise with, but the most likely scenario to me is that some technically inept "decision maker" decided to ban older phones in a security gesture to give the impression that he is adding value.

Note: I also own a venerable ipad air2 (2009) that I bought second hand long ago to serve as a midi controller. Still a very nice, well build machine. It's not allowed to connect to wifi or it would figure out what year it is. I call it "hibernatus" (reference to https://en.wikipedia.org/wiki/Hibernatus) :)

Beautifully said!

I must just have a sixth sense to avoid those kinds of services. And I also have a zero tolerance policy. For example, if a restaurant says I have to order on my phone, I stand up and go to leave. I am old enough now they probably just assume I am technologically illiterate.

Counter example, from the future :)

Year 2034, you have a nice vintage, lightly used electric car. Battery still charges and whole box drives. Do you need to buy new car or gov need to prohibit you using it or enforce to scrap it ? Most likely yes - battery is about to explode, possibly on crowded crossroad...

Real problems sometimes demands 0 or 1 action.

Just "phone app from everyone" etc is monopolies inflicted harm on society.

Your story is appalling, and I agree that this is a major problem.

However, drowning in e-waste from smartphones is many orders of magnitude from being an issue, as trivial calculations easily show. Mentioning it makes your argument rhetorically much weaker. The iPhone 16 is 147.6mm × 71.6mm × 7.8mm (8.2 × 10⁻⁵ m³) and weighs 170g, according to https://www.dimensions.com/element/apple-iphone-16-18th-gen. The population of France is 68.6 million people. One iPhone per person each year for the next century would be 6.86 billion iPhones in France, assuming the population remained constant. This would weigh 1.2 million tonnes and fit in a sphere 51 meters in diameter. If stacked 6 meters deep it would cover 9.4 hectares, a circle 340 meters in diameter. France contains 63 million hectares. The hypothetical pile of iPhones would cover about a third of the area of the Gravelines Nuclear Power Station near Calais.

Far from drowning in e-waste from smartphones, if you dump it in a landfill, it will be extremely hard even to find the e-waste without a map.

Even if you didn't have a countryside to bury e-waste in, this should be obvious even on the household scale. Suppose you and your four children each get a new iPhone every year, and instead of throwing them away, you put them in a box in the attic. How big is the box? It's a 35 cm cube after 100 years. It would weigh 85 kg, though, so you'd want to use several smaller boxes. But there is no risk of drowning.

"Drowning in e-waste" was a metaphor for "slowly destroying the conditions for civilisation with the violent obsession for more fossil fuel and more minerals to extract".
its even worse when you discover the app itself is just a webview
TPM and Secure Boot would be good things if there were no way to prove to third parties that you're using them, or have them configured a certain way (i.e., remote attestation). It's the fact that that is possible that makes them reduce user choice and promote state and corporate surveillance.
Maybe. This assumes I trust Microsoft to have part of my computer where I have no ability to interrogate it to see what they’re doing in there.

If it’s on my computer, I should be allowed to read and write to it. End of story. I don’t care if that makes it vulnerable. So far as I’m concerned, letting Microsoft keep secrets from me on my own computer is similarly catastrophic to losing my HD to a crypto-locker virus.

> TPM and Secure Boot would be good things if there were no way to prove to third parties that you're using them, or have them configured a certain way (i.e., remote attestation).

This is exactly what a TPM was made for, so your statement is a little bit paradoxical.

The ideal is the owner being able to use TPM/SecureBoot/etc to ensure that the device is in the configuration they want. That means resisting tampering, and making any successful tampering become obvious.

The problem is third parties using TPM/SecureBoot/etc as a weapon against the owner via remote attestation, by preventing them from configuring their own device, with the threat of being cut off from critical services.

Having the upside without the downside would be nice, but how could it work? Is a technical solution feasible, or would it need a law/regulation?

Not a crypto expert, but given how both, bad players seeking control and people seeking to verify their cloud machines are both remote it seems that the technology will rollout without problem and will end up being force fed into all consumer devices with bullshit excuses.
Thing is, because the whole design is closed as well as firmware, the security of it is near zero, even for sealing firmware device images (e.g. option ROM), much less bootloaders. Multiple security holes have been found.

There's no issue booting a boot rootkit with the standard Windows bootloader unless you manually seal the image with command line or group policy, and even then it's possible to bypass by installing a fresh bootloader because the images are identical and will boot after a wipe.

>Thing is, because the whole design is closed as well as firmware, the security of it is near zero, even for sealing firmware device images (e.g. option ROM), much less bootloaders. Multiple security holes have been found.

This. It is secure only for MS, AMD or Intel.

> if you want to store secrets that don't need a user password to unlock and can't be stolen by taking apart the computer, you need a TPM

I had a Win 7 system and just entered a password on boot, this decrypted the disk. It was supported without mods or TPM (maybe some registry tweaks though). On Ubuntu I do the same, no need for TPM. Am I missing something? My disk is encrypted. If they take it apart, they need my password to crack the encryption.

The important part in the parent is "that don't need a user password". You just said you had to supply a (user) password.

With a TPM you can set it up that your disk is unlocked automatically, but only if no-one changed anything in the signed boot chain. This is the default with Bitlocker on Windows and is also possible on Linux, though somewhat more finicky.

but why bother? I can fit enough entropy in my head to make my hard drive uncrackable, and I can back up my data even if some chip breaks.

It's just added complexity and corporate control so people can use worse passwords

But most people don't want to enter a password, and if you make people enter a password too much, they'll choose terrible passwords and put them on a sticky note. Windows Hello can only be done securely with a TPM. A server that I want to turn back on all by itself after a power outage can only be done securely with a TPM.

I want a TPM in my computer so I can have the security and convenience. Yes, it's another point of failure. But I need backups in case the hard drive fails anyway. And besides, the OS can be designed so I can enter a password if I need to use the drive without the TPM.

>Windows Hello can only be done securely with a TPM

I think in general biometrics are in the same ballpark as low-entropy passwords. IDK, I personally have no faith in trusted computing hardware because it can be broken with the right equipment. You're right that it can be used alongside ordinary security measures, but I just think it encourages putting your eggs into a cryptographicially-weak hardware-strong basket (which represents a downgrade because crypto is stronger than hw).

>A server that I want to turn back on all by itself after a power outage can only be done securely with a TPM.

Can you describe how this prevents a MITM attack? I assume you mean a remote server? I've heard of colocation setups like this, but I think they rely on a couple of unstated assumptions.

> >A server that I want to turn back on all by itself after a power outage can only be done securely with a TPM.

> Can you describe how this prevents a MITM attack? I assume you mean a remote server? I've heard of colocation setups like this, but I think they rely on a couple of unstated assumptions.

I'm not sure what you mean by prevent a MitM attack, unless you're worried about someone with probes MitM-ing your TPM-CPU connection in the DC.

You can bind a TPM to measurements on the host (let's say for argument's sake you want Secure Boot state, Option ROM state, and UEFI state), then configure the OS to ask the TPM for the (or rather, a) decryption key during boot.

The TPM will check that the state(s) you bound to is (are) the same as when you bound them, and if so it will give the OS the key. Your disk is encrypted, but the boot process is automatic/unattended, as well as completely contained within the server chassis.

There are ways to attack this hypothetical setup, buuuuut there are ways to attack remotely entering your disk password as well, and bear in mind that denial of service is a security vulnerability. Tradeoffs.

I agree that biometrics are in the same ballpark as low-entropy passwords, which means their security relies on avoiding offline attacks. My ATM card is protected by a 4-digit pin. That's perfectly secure, because the ATM network won't let you enter a wrong pin more than a single-digit number of times before locking the account.

Windows Hello allows you to log in with a 6-digit pin. That's perfectly secure, because the TPM lets them design a system where you can't do an offline attack on the pin. Too many wrong entries and you'll need to use your password.

I doubt there's more than two dozen bits of entropy provided by finger print readers or facial recognition authentication, but you can make an acceptably secure login experience with it because, again, the TPM lets you prevent offline attacks.

But without password, anybody can physically access the device and exfiltrate data. That is even easier than regular password protection, where the storage medium would have to be removed or a live OS would have to be booted.

The risk is data leakage. With a TPM and no password, there is no data leakage protection.

Passwordless boot with a TPM means the software can control what secrets it gives out. Yeah, if you boot to a desktop operating system and auto-login as an admin user, that doesn't leave things very secure, but that's not the only scenario.

Consider a server. It can have an encrypted hard drive, boot with the TPM without a password, and run its services. In order to steal data from it, you need to either convince software running on the server to give you that data, or you need to do some sort of advanced hardware attack, like trying to read the contents of DRAM while the computer is running.

There are other use cases too, like kiosks, booting to a guest login, corporate owned laptops issued to employees, allowing low-entropy (but rate limited) authentication after booting, to name a few.

> Am I missing something? My disk is encrypted. If they take it apart, they need my password to crack the encryption.

You’re not protected from an evil maid attack. An attacker with physical access could make your device boot their own payload to capture your encryption key and install a rootkit.

I—like most people—don't have a maid. Is Tom Cruise going to break into my house to add a keylogger to my computer without me noticing? If anyone is breaking in, my threat model is worrying about me or my family getting killed, not someone installing an evil bootloader.

Most market segmentation is just to screw customers (e.g. ECC support), but measured boot is one that really only needs to be on enterprise server or workstation-class hardware, and actually causes issues by existing in mass market hardware.

If your threat model includes evil maid attacks a TMP will not save you. They can just install a physical keylogger and then do whatever they want. The only threat model that a TPM helps with is where the owner of the computer is considered the threat by someone else.
So what happens when they use their physical access to turn off secure boot or just replace the component/device with one that looks the same, prompts for your password and sends it to them?
You get a prompt to enter Bitlocker recovery key if you turn off Secure boot in BIOS.
That's Windows doing that, which they've just compromised and then configured to display only the normal login prompt but send your credentials to the attacker.

They can also decrypt your hard drive by doing the same thing without modifying the original machine by just stealing it and leaving you a compromised one of the same model to also steal your password.

If evil maid attack, and you see this prompt, you a) re-enable secure boot, if did not work b) throw away the device.

In any case data stays secure.

Edit: Hmm, you have a point, how do I know secure boot was disabled in the first place? Anyway, still works for servers and unattended reboots.

There is no password. The machine will fail to boot and decrypt you hard drive.
Either you're entering something into the machine to authenticate yourself or they can just copy or modify your files without authenticating to begin with.

If they just want your password they don't need to decrypt your hard drive, they can format it and install a rootkit that steals your password as soon as you try to login.

So don't turn off secure boot. Replace the target machine with an identical decoy machine set up to capture whatever credentials are required to log in to the machine once BitLocker auto-unlocks, then use these to log in to Windows on the original machine and steal any encrypted data accessible by the user who logs in.

This would be more difficult to pull off in the presence of non-password security like a hardware token, as you'd need to forward the actual login UI to the decoy machine, but still not terribly difficult if the login UI will display on an externally-connected monitor and accept input from an externally-connected keyboard and pointing device, and the hardware security device connects via an external interface like USB.

You're now just making up more and more ridiculous nonsense to beat a wrong point.
Many OEM's don't allow changing keys and Microsoft doesn't even enforce their own certification requirements. See:

https://linustechtips.com/topic/1610033-hp-charges-for-warra...

I think it has the potential to create that situation if those features ever change. I should probably update that language, but I still feel from a consumer choice perspective, those solutions seem vendor specific and not governed by an open organization.
You are 100% correct and we can see the situation on phones where you can't boot anything not approved by the vendor.
> Microsoft actually promoted user choice

Let’s not give Microsoft too much credit here…

Between 2011 and 2013, multiple Linux / free software organisations raised the issue with the EC. There was an actual antitrust investigation which at the time was seen as what motivated Microsoft to open the solution to third parties by 2013.

So in a way, thank you EU for making it so we have choices at all.

With that said, I think the technology still does more to promote vendor lock-in and as others have said, it’s one windows update away from a dystopian hellscape where all your bits have been pre-approved by someone else.

I am starting to see the benefits to secure boot and TPM from a gaming perspective. I realize this can still be tampered with but it eliminates so many casual cheaters that the edge case is practically irrelevant.

I don't see how my TPM module will prevent me from using the machine the way I want. The offer of a cryptographic assurance to a 3rd party is something I happily provide in order to gain access to a competitive gaming resource. Cheaters really fucking suck and if this is what it takes to ruin their day, then fantastic. I'm looking forward to TPM3.0 now after seeing how ruinous this has been to their schemes. These tools are effective.

Battlefield 6 is especially problematic for malcontents because its developers also enjoy using statistical methods to detect cheaters. TPM2.0 + statistical methods + $69.99 per try = probably can't afford to play this game unfairly for very long. Even if you can afford it, the in game progression takes an eternity. You're gonna need that 8x scope if you want your "undetectable" frame scanning aimbot to be of any use.

> I don't see how my TPM module will prevent me from using the machine the way I want.

I guess people don't know this particular dystopia is implemented.

First a platform gets third parties (games, banks, etc.) to impose their attestation system on customers. Congrats, you're locked in! This is the gun they point at you but the bullet comes after.

Now you can't leave the platform or you lose all your games, have to get a new bank, etc. The more stuff they can get to require that, the more stuck you are. This also prevents any new competitors from building a network effect. But competition -- the ability to switch to a competitor -- is the only thing stopping them from being the worst people in the world. Ads in the start menu. Censoring whatever they don't like. If you want to buy something -- anything -- they want a 30% cut. They'll hide it from you but take it anyway. All your local files get uploaded to their cloud and the terms let them use it for AI training, or whatever else they want. And soon you have to pay a monthly fee if you don't want them to be deleted. Why would not paying also delete them from your local machine? Because screw you, you don't have a choice anymore.

> I don't see how my TPM module will prevent me from using the machine the way I want.

"Your version of TPM is unsupported. Please update your hardware to enjoy playing Battlefield 7". Your 69.99 per try just went up to 769.99 _for legitimate users_ because you need a new CPU with updated TPM for every new version. I'm being hyperbolic, but only slightly.

If you want a real example of this, Windows 11 requires TPM 2.0 to run. Hardware predating wide TPM2 adoption can be powerful enough to run Windows 11, except the company decided you need a new computer to do that.

> I am starting to see the benefits to secure boot and TPM from a gaming perspective. I realize this can still be tampered with but it eliminates so many casual cheaters that the edge case is practically irrelevant.

This is overkill for a feature that is only relevant to one specific usage of PCs. Imagine if your PC got crippled because farmer IT admin benefits from it

I don't think it helps for cheaters, you have cheaters on console and it's even more locked down than that.
Not to mention hardware based cheating that just implements a fully compliant USB mouse, keyboard, and HDMI setup, and DMA like https://www.dma-cheats.com/
I'm sure some jackass is going to suggest cryptographically verifying that you are using peripherals from trusted manufacturers soon.
That's physically not possible though, you could always have a device which pushes through the buttons on a genuine controller.
Of course, but the analog hole never stopped DRM aficionados from trying either. Who cares if the "solution" mainly ends up hurting legitimate users.
Entertainment is the last thing you should give up your freedoms for.
> If you want to be able to prevent root kits you need secure boot

I think this is very misleading. Secure boot was a response to the poor security of commodity operating systems which allowed programs easy access to make low-level system modifications. In other words, the poor security models of commodity operating systems was the actual cause that allowed rootkits to spread and become a major threat that required mitigation.

In an alternate world in which operating systems enforced least privilege on all programs, the likelihood of a rootkit spreading would be orders of magnitude smaller, almost not even worth mentioning. The motivation for secure boot in this world is really only to prevent supply chain attacks, which can also be solved by just buying hardware from reputable companies. Secure boot arguably would not have been created in this world, thus avoiding the new dangers inherent to it.

Yes, but when an individual hacker needs a secure computer and is deciding which computer to buy, it does him no good to tell him that if the whole industry had evolved in a more convenient way over the last 4 decades, he would have been able to avoid secure boot: in the actual world, the only user-facing computers on the market with decent security use secure boot to help deliver that decent security where "user-facing" means "used to browse the web and maybe other things".

Also remote attestation has pro-social uses. Without it, photographs will soon become useless as evidence because soon there will be no way to distinguish a photo of a real scene from the output of generative AI.

My point is that secure boot isn't the only way forward, and depending on your circumstances, a foundation built on something like seL4 could suffice for particular applications. And it doesn't even require a whole new OS or foundation like seL4, even Windows has the right core primitives if they're used in the right way [1]. And that work was from 2005, not 40 years ago, but still long before any of this really became an issue.

[1] https://cacm.acm.org/research/polaris-2/

Coreboot with Heads exists and works fine for me with Qubes OS. So it's not a hypothetical.
Coreboot with Heads and Qubes prevents malware that has inserted itself into the firmware of your ethernet driver, keyboard or block-storage device from modifying your software?
Yes? Qubes provides compartmentalization for the hardware you listed.
> TPM and Secure Boot do not reduce user choice or promote state or corporate surveillance

Now with remote attestation they do.

> installing their own root of trust and signing their boot image

Won't matter. They can tell we did this. They won't trust our keys. Only their own.

> Microsoft didn't need to add that requirement.

Yes, they did. It was written by the specter of the US Department Of Justice.

> If you want to be able to prevent root kits you need secure boot

Secure boot is a rootkit.

a lot of what he says is straight lies or stupidity. I love linux but disagree with everything he says.
These are old counterproductive FSF memes that should be retired, but stick around anyway.