The Dangers of Microsoft Pluton

- no, I don't need protections for the side channel, I never asked for them

- no, I don't need a unique identifier, who is the demented person who asked you for it

- no, I am not going to glitch the power supply, and even if I did it means I am interested in doing it and wish it worked instead I was prevented from doing it

- no, I don't care at all about having a hw store for certificates, which are ephemeral and dropped from above anyway so what am I supposed to trust?

- and so on

"not secure by design" nowadays comes close to being a coveted feature

Are you talking about brown-out detection circuits, or is there something else?

Gee I wonder why. /s Such statements are tedious to say the least, preventions have been implemented, obviously it curtails such abuse, obviously that reduces frequency.

> the whole TPM module isn't really needed in my opinion

It's nice that you have no key material that would need to be kept strictly on the device, but a lot of users actually do. We don't want people's Webauthn tokens carried away, we don't want Bitlocker keys stolen, most certainly we do not want biometric authentication data stolen. Maybe you have reduced that risk to near zero, but that's not the case for the vast majority of users.

The frequency dropped even before TPM was deployed on most machines and I guess most systems still haven't it enabled today. Reason for that is that there are simply more direct and profitable ways to get system access, see most applications of ransomware for example.

> It's nice that you have no key material

You can use many different types of authenticators. If you use Windows Hello you need TPM and they try to hinder you adding alternative means without TPM being activated. But that is a different story and solely on Microsoft. No need to falsely or passive aggressively suggest that a system would be insecure without these specific means.

I interpreted your sentence as two disjoint statements and thought you find UEFI/SB and TPMs all useless. But yes, it indeed started dropping before. TPMs don't deal with that topic unless we're speaking of Trusted Boot, which is a whole separate concept.

> [...] hinder you adding alternative means without TPM being activated. But that is a different story and solely on Microsoft.

No it's not solely on Microsoft. If there isn't a safe place to store keys, it makes sense to dissuade storing them. Fairly obvious, isn't it?

> You can use many different types of authenticators.

It's not a very realistic suggestion for most users and use-cases. Having a built-in module that does the job has a lot of upsides.

> No need to falsely or passive aggressively suggest that a system would be insecure without these specific means.

I didn't say such a system would be insecure, however it can't safely store key material, it would be less secure in a bunch of contexts.

And downsides, especially for corporate usage you don't want your data protected by device keys if they aren't set by yourself or replicated elsewhere. But it is a security risk to deploy such keys on local machines in the first place in many circumstances.

> If there isn't a safe place to store keys, it makes sense to dissuade storing them. Fairly obvious, isn't it?

The behavior is that you can only add keys if you already activated TPM. This is an implementation detail of Windows Hello. Perhaps they changed it but I can think of some reasons why they forgot to add the option.

> it would be less secure in a bunch of contexts

No, I disagree. Severely less secure depends on the security model. Applications cannot usually randomly access any memory, but yes, the system would need to ensure that and there can be attacks. If you assume your system is compromised on that level your device encryption will be bypassed via the same channel. TPM comes with its own suite of security flaws in regards of device identification (bug or feature?). That is a relevant threat model compared to many memory attacks regardless of the countless other fingerprinting problems we currently are subjected to. Plus the DRM issues around remote attestation and sealed storage.

It's a solved problem in corporate environments.

> But it is a security risk to deploy such keys on local machines in the first place in many circumstances.

That's a massive stretch and no normal corporation agrees with that statement.

> No, I disagree.

Other people's threat models are not something you can disagree with.

> If you assume your system is compromised on that level your device encryption will be bypassed via the same channel.

Well not really, it's not a bypass. Continuous abuse of a compromised machine is significantly noisier than exfiltrating the keys needed and then abusing those. Plus you can't touch anything that would change TPM measurements, or you'll lock yourself out. It's much more cumbersome.

People fought against that and actually won, 23 years ago: https://news.ycombinator.com/item?id=10106870

Unfortunately, that may have been the only victory, as they slowly started introducing a lot of other stuff silently under the guise of "security".

"not secure by design" nowadays comes close to being a coveted feature

Absolutely. As the saying goes, "insecurity is freedom".

I absolutely don’t want my internet connected pet cam to be accessed remotely (outside the set of companies i’ve decided to trust, namely the manufacturer.)

Protection against hardware tempering is less good and probably mostly anti-consumer. The most legitimate cases I’ve heard:

- Protection from (some) supply chain attacks

- Leasing models. Where you acquire the item for less than it’s hardware cost and pay over time.

But honestly I’m not convinced of either.

Disclosure: I worked on Azure Sphere, the first place Pluton was developed outside Xbox.

Edit: I’ve read the whole article now. These scenarios are really bad and really realistic. Pluton is bad.

Before you say, "well, they're the government, why don't they just compromise the secure boot CA"; the problem is that cryptographic signatures create evidence. If someone finds your boot sector malware you don't want it to be attributable - but signatures from an already-trusted entity create exactly the kind of paper trail you'd rather avoid. If Microsoft signs a boot sector virus, then it's obviously a US government cyberweapon, and any companies that find it in their systems will start suing. In this particular context, secure boot is a policy of "no execution without attribution".

[0] Which nowadays can even be done in a browser. Modern browsers actually have to have throttling and CPU usage limits because of this.

> "not secure by design" nowadays comes close to being a coveted feature

That's a huge market opportunity. I would buy "insecure" products over secure ones every time.

At that same time, Microsoft started using your HDD serial as an identifier. Nowadays there are unique identifiers in most of your hardware, including the north bridge of your motherboard and the TPM that windows now requires.

Also, mobile devices got all kinds of unique identifiers from day 0.

This one makes no sense. Wouldn't 99.9% of power supply glitches be some sort of accident, and something that the end user probably doesn't want?