The Dangers of Microsoft Pluton

* SMM has been part of x86 for decades. The Secured Core requirements around SMM actually reduce its power.

* The claimed requirement to remove the third party UEFI CA certificate from 2022 Secured Core PCs is entirely unrelated to Pluton (it's required regardless of whether Pluton is enabled or not, and even whether the CPU has Pluton or not)

* Most of the description of Pluton is actually a description of a TPM. You don't need DICE for remote attestation. TPMs are already a hardware keystore.

* System firmware is already being updated via Windows Update. The discussion about Pluton and Windows Update is around Pluton getting firmware updates that way (the existing story around firmware updates for TPMs is largely not good)

* Existing TPM-based remote attestation already includes the secure boot state

The short version: everything that the article is worried about being enabled by Pluton is already possible, and has been for years.

But there's a meaningful point here. Remote attestation can certainly be used to restrict access to resources in ways that are incompatible with general purpose computing, or which reduce user choice. Remote attestation can also be used to give end users confidence that their machine is in a good state without constraining what they do with it. As a technology, remote attestation can be used in both good and bad ways. We do need to keep track of whether anyone is threatening to use it in bad ways and react appropriately.

(But tbh remote attestation as an attack on general purpose computing isn't the really scary thing about widespread remote attestation. Remote attestation ties back to the TPM's endorsement key, an immutable cryptographic key certified by the TPM vendor at manufacturing time. The straightforward implementation of allowing arbitrary remote sites to trigger remote attestation would tie all of these accesses back to a single piece of hardware, and would be a privacy nightmare.)

> The claimed requirement to remove the third party UEFI CA certificate from 2022 Secured Core PCs is entirely unrelated to Pluton (it's required regardless of whether Pluton is enabled or not, and even whether the CPU has Pluton or not)

Pluton is de-facto a Secured Core PC implementation, and Secure Core PCs are also making this change. Thus it effects both Pluton and Secured Core, but the new requirement does not effect non-Pluton and non-Secure-Core systems. Because Secured-Core PCs are currently niche and will no longer exist once Pluton is broadly adopted, Pluton will be the first appearance of this change for the vast majority of users.

If I'm selling a 12th Gen Intel system right now, I can keep the 3rd-party UEFI certificate enabled. If I am selling a 12th Gen Secure Core PC, then this year I must disable that certificate, but my non-Secured-Core PCs can again keep it open. When Pluton arrives, that door must be shut.

You can verify this with Microsoft's Secured Core PC documentation:

https://docs.microsoft.com/en-us/windows-hardware/design/dev...

> Most of the description of Pluton is actually a description of a TPM. You don't need DICE for remote attestation. TPMs are already a hardware keystore.

To an extent. The original TPM is very finicky as documented by the comments on this post and elsewhere - even changing a RAM stick could invalidate the TPM's assertion. For this reason, the TPM was very unideal for DRM due to it's all-or-nothing approach, which Microsoft Pluton does not make the mistake of repeating, allowing for much more granular security that makes it much more easily applied. The second reason why Pluton is much more dangerous is that the TPM could be easily virtualized or hacked over the bus rendering DRM use-cases quite broken, whereas Pluton supports neither weakness, making its DRM potential (again) much more potent. Finally, using DICE, unlike a TPM, the Pluton is explicitly designed to give a computer a permanent identity that can never be erased, which (again) TPM does not guarantee.

Useful HN comment explaining: https://news.ycombinator.com/item?id=25193346

That's actually the big reason why the Remote Assertion is an important point here. The TPM version of it was almost unusable outside of very niche business applications and BitLocker, while with DICE, the Pluton is far more potent. (After all, if TPM worked fine on it's own, why does DICE even exist?)

I think the last point to further back this view I will also add is these comments from a Microsoft employee on the subject.

https://lobste.rs/s/fdguww/dangers_microsoft_pluton#c_tdlo1r

> System firmware is already being updated via Windows Update. The discussion about Pluton and Windows Update is around Pluton getting firmware updates that way (the existing story around firmware updates for TPMs is largely not good)

Microsoft themselves states in Pluton's announcement that Pluton will hardware-integrate with Windows Update for various system firmware, through their "chip-to-cloud" security initiative. To quote them:

"One of the other major security problems solved by Pluton is keeping the system firmware up to date across the entire PC ecosystem. Today customers receive updates to their security firmware from a variety of different sources than can be difficult to manage, resulting in widespread patching issues. Pluton provides a flexible, updateable platform for running firmware that implements end-to-end security functionality authored, maintained, and updated by Microsoft. Pluton for Windows computers will be integrated with the Windows Update process in the same way that the Azure Sphere Security Service connects to IoT devices."

This is a little frustratingly vague and thus part of the reason why Pluton requires some speculation. Judging by the reference to "different sources that are difficult to manage", it appears you don't update Pluton, Pluton updates you. Pluton has an active role in your system's security, whereas TPM was only passive.

No, it's not. You can deploy Pluton without having to implement the Secured Core PC spec.

> Microsoft Pluton does not make the mistake of repeating,

No, seriously, the only remote attestation supported by Pluton on x86 at present is literally this TPM-based remote attestation. There's no meaningful fragility here - remote attestation means you can look at the individual log events rather than just looking at the composite PCR values, and that lets you ignore the noise created by things like hardware configuration changes. I have helped build and deploy infrastructure that makes use of remote attestation to validate secure boot state.

> the TPM could be easily virtualized

No, because the EK certificate won't chain back to a trusted CA>

> hacked over the bus

True in some cases, but already mitigated on all systems that are using fTPMs (ie, most Windows 11 systems).

> the Pluton is explicitly designed to give a computer a permanent identity that can never be erased, which (again) TPM does not guarantee.

TPM does, in fact, guarantee that. The endorsement key is static over the lifetime of the TPM.

> why does DICE even exist

DICE provides a set of features that don't require the functionality of a full TPM. This allows you to implement things like device identity attestation in a standardised way that works for both hardware with a full TPM and also IoT devices where a TPM would be too expensive.

> Today customers receive updates to their security firmware from a variety of different sources

Look at the diagram immediately above that quote. They're talking about the firmware that runs on Pluton, not the firmware executed by the main CPU.

Again, you're raising a legitimate issue (remote attestation can be used for bad things), but you're burying it under a bunch of misconceptions and just flat out inaccuracies. I agree that we should be worried about widespread use of remote attestation, both from a "War on general purpose computing" perspective and a privacy perspective. But literally everything you're legitimately worried about happening could happen right now. Framing this as something that's tied to Pluton risks giving people the impression that they can avoid it by just not buying anything with Pluton, and that's simply untrue.

I may update the article to reflect this, I will look into that further. So far the few Pluton systems available all seem to also implement Secured Core, however, as more systems become available perhaps that will change...? I am OK with being wrong here and openly admit that there may be inaccuracies and speculation due to the limited public information and limited number of systems and configurations with Pluton so far.

I'm not quite at the point of agreement yet, mainly because your argument leaves Pluton's addition and functionality almost redundant and inexplicable. From your perspective, almost everything the Pluton is capable of is also possible with a TPM. However, this does not make sense to me, as why implement the Pluton if an fTPM is fully capable of everything the Pluton can do? Why can't an fTPM just be updated with CPU microcode which Windows Update already can handle? What is the point of SHACK then if TPM is fully capable of handling keys already? Why would Microsoft make a grand announcement about how this allows for "chip-to-cloud" security with Project Cerberus and all that, if nothing actually changes almost at all?

Also, can you explain how this checks out with Microsoft RIoT?

PSP and ME firmware isn't part of the CPU microcode. There's no fundamental reason why the updates couldn't be provided via Windows Update, but that would require Intel and AMD to choose to do so. There's frequently fairly tight binding between ME/PSP firmware and the system firmware, so it may well be the case that the vendors simply don't feel comfortable providing updates without board vendors having validated that first. The ME and PSP also offer significantly larger attack surfaces than Pluton does, so there are legitimate concerns over whether they can offer the same level of security assertion.

TPMs normally sequester keys to themselves, but the spec doesn't say anything about how that's handled - the keys could be in a separate hardware block that's isolated from the rest of the TPM, or they could be just living in RAM on the TPM. In the latter case, any vulnerability in the TPM firmware would potentially allow the keys to be exfiltrated. SHACK is intended to provide a higher degree of isolation, such that even if the Pluton firmware is compromised the keys will still be inaccessible to an attacker.

I'm not quite sure what you mean with respect to RIoT. Devices that make use of RIoT aren't intended to be general purpose computing devices.

1. This would require that Intel and AMD find it less intrusive to build an entire additional SoC into their processors, on whatever node necessary, than to package their software for Windows Update. Also, it leaves out the question, why couldn't Microsoft have required that AMD and Intel just implement a TPM outside of the PSP/ME with similar hardware protections? Intel would have vastly preferred that, as then they could have just marketed it as part of their vPro solution.

2. For RIoT, it was reported by IEEE in their report that the Pluton does implement RIoT, and this report was endorsed by the Vice President of OS Security at Microsoft as the best write-up so far just yesterday (see https://twitter.com/dwizzzleMSFT/status/1551594590087438336). So there is more to the story than you believe on this subject. Unless the Vice President of OS Security at Microsoft who actually worked on Pluton is incorrect, Pluton does have RIoT.

I will dare quote a fair-use bit of the paywalled report:

"Pluton also implements the device identifier composition engine (DICE) specification, as defined by the TCG, along with the Robust Internet of Things (RIoT) specification, as defined by Microsoft, to achieve DICE+RIoT. Using this technology, a device cannot masquerade its boot path; more simply, it provides a strong method for attesting to a device’s current state and status (e.g., patch version, firmware version, etc.). It is important that this is implemented in hardware, rather than firmware, because the hardware which performs the initial measurements and checks on power-on cannot be modified by an attacker. Relying on device attestation rooted in firmware or software is dangerous because if the initial stages of the boot process are compromised then the entire boot process can be falsified and a bogus attestation can be produced. While Microsoft intends for this technology to be compatible with their Azure Attestation service, since it is built using open standards it can be leveraged by any attestation service, which supports DICE+RIoT."

Edit: On that note, I have added an update to the blog post noting this conversation and that while I am not fully convinced of your points, it is also worth reading.

Edit 2: On a third note, I doubt that Microsoft intends "Secured Core" to be a thing that just sticks around forever. Even though this is just speculation, I find it hard to believe Microsoft would not one day make Secured Core or parts thereof (say, everything except the Thunderbolt protection) mandatory. That is yet another possibility, that "Secured Core" become more and more similar to mainline Windows over time. They may have already to OEMs, but I will admit there is no way to prove one way or the other.

Pluton can be used in different contexts, and it can certainly be used in more IoT focused scenarios. UEFI doesn't really integrate with the DICE case terribly well (I'm dealing with DICE at the moment professionally, because I've made some poor choices in life), so I don't imagine it'll be relevant in the general purpose computing segment.

Truly, there are days I feel like Oedipus had a good idea. Tired of reading the rampant industry gaslighting around what our current crop of engineering talent is whipping up for the up-and-comings to be subjected to.

everything that the article is worried about being enabled by Pluton is already possible, and has been for years.

There's a HUGE difference between "possible" and "very easy to deploy". https://news.ycombinator.com/item?id=29859106

That means in three years, every supported PC will have TPM 2.0. Within ~1 year, assuming that Intel and AMD fulfill what they've implied in the launch announcement, every new PC will also come with Pluton.

That's a lot easier to deploy to compared to having some PCs with TPM, others without, some out-of-date on TPM 1.1, some with unpatched firmware (like the 2017 Infineon bug), so forth.

Now... some say, what about non-Windows systems, like macOS and Chrome? Think bigger for a second - Cisco (as an example) is in the Trusted Computing Group that designed a lot of this stuff, and Cisco Meraki is deployed in so many businesses for Wi-Fi security its incredible. All Cisco Meraki has to do (for example, maybe its not Cisco) is make a connection app that uses Pluton/TPM on Windows, Secure Enclave/T2 on macOS/iOS with Apple DeviceCheck, and SafetyNet on ChromeOS/Android. And you are all done - you've successfully made sure every new system is almost certainly untampered with. You've locked the door. For any system that can't be verified, no problems sending them to the IT Help Desk to be manually registered with a private key and sign a disclaimer.

It wasn't possible before, but five years from now, it will be much easier. Every Windows PC will be on the same page, and all major systems will have consistent assertion frameworks. Now, is Pluton wholly responsible? No. Windows 11 plays a role. Pluton just makes it broader and stronger, and Pluton also provides a long-term strengthening as eventually the TPM 2.0-only level will be able to be cut off for just Pluton.

This is mainly because, at this point,

A. A TPM's level of access and capabilities to a system is well-known at this point. Pluton, we do not know with certainty what all of its capabilities are.

B. Microsoft has explicitly stated Pluton will have functionality added to it in the future though software updates, most likely that cannot be downgraded, that are not present yet. It's not that Pluton might have stuff added later - Microsoft has said stuff will be added later. What these upgrades entail or are capable of is also unknown.

C. Because of the above, Pluton requires a previously-unknown level of trust for Microsoft, because Pluton almost certainly has anti-downgrade procedures. Microsoft could, potentially, send out an update just blocking Linux and if Pluton received the update, it would be irreversible. Maybe this isn't within Pluton's abilities, but we just don't know. Just that Microsoft (or a hacker of Microsoft - I'm more concerned about a rogue employee than Microsoft at the moment) could have permanent effects on the security of a system is worth paying attention over.

D. Because of the reasons above, Pluton should be regarded with extra skepticism as it is a magical black box, with unknown capabilities, that it is not clear whether it can actually be disabled. (Already on my blog, there's a user talking about how Pluton briefly boots and then disables itself if the UEFI says that it should be disabled, not that it never starts, so theoretically a Pluton update could ignore its own disable switch.) I don't have verification of that, but until we know more... TPM is known, TPM can screw people, Pluton has the potential to extremely screw people over, and while many of my doomsday speculations can actually be recreated with just a TPM if TPMs are widely adopted, perhaps it could be enhanced with more Pluton-specific ones. Perhaps my doomsday predictions actually weren't far enough.

Thus, your point that Pluton doesn't add too much might be completely valid right now. That doesn't mean Pluton isn't also a potential Trojan horse that Microsoft updates as they please with new things that we didn't expect or ask for with no ability to undo them.

Edit: Removed a previous edit, and adding that, to complement the above notes, it does not help instill confidence that Microsoft isn't telling what Pluton can and cannot do at a hardware level. They've said a few things it can do right now, and just said more stuff will be coming in the future, but they won't talk about where its limits are. So... trust the black box without questions please. To be fair, this isn't the first time (Intel ME, AMD PSP?), but it is unsettling to have another one.

They certainly will be, if most people don't have Pluton. If only a minority have it, they wouldn't be able to even come close to requiring it.

https://www.bleepingcomputer.com/forums/t/613941/tpm-20-is-m...