Subscribe Now
Trending News

Blog Post

The Dangers of Microsoft Pluton
News

The Dangers of Microsoft Pluton 

In upcoming Intel, Qualcomm, and AMD processors, there is going to be a new chip, built-in to the CPU/SoC silicon die, co-developed by Microsoft and AMD called the Pluton. Originally developed for the Xbox One as well as the Azure Sphere, the Pluton is a new security (cynical reader: DRM) chip that will soon be included in all new Windows PCs, and is already shipping in mobile Ryzen 6000 chips.

This new chip was announced by Microsoft in 2020, however details of what it was actually capable of, and what it actually means for the Windows ecosystem were kept frustratingly vague. Now with Pluton rolling out in some AMD chips, it is possible to put together a cohesive story of what Pluton can do from several disparate sources.

Because Microsoft’s details are sparse, this article will attempt to summarize all that we now know regarding Pluton. It may contain inaccuracies or speculation, but any potential inaccuracy or speculation will be called out where possible.

What’s inside Pluton?

Pluton encompasses several functions. I’ll be throwing out the acronyms first and some of their meanings and effects later in the article:

  • A full TPM 2.0 implementation, developed by Trusted Computing Group (TCG)
  • SHACK (Secure Hardware Cryptography Key) implementation
  • DICE (Device Identifier Composition Engine) implementation, also designed by TCG
  • Robust Internet of Things (RIoT) specification compliance, a specification developed by Microsoft and announced with almost no fanfare all the way back in 2016

However, besides these functions, Pluton implements the full breadth of security improvements that Microsoft used to only have on the Windows 10 Secured-Core PC systems. A Pluton system is a superset of the Secured-Core PC specification which was previously only on select systems. A Secured-Core PC requires the following additional technology measures that were not previously required for a standard PC:

  • Dynamic Root of Trust for Measurement (DRTM)
  • System Management Mode (SMM)
  • Memory Access Protection (Kernel DMA Protection, protects against Plundervolt Thunderspy)
  • Hypervisor Code Integrity (HVCI)

Also, starting this year, new Secured-Core PCs (and Pluton PCs by extension) will also be required to drop support for the Microsoft 3rd-party UEFI Secure Boot Certificate Authority by default. This means that the shim bootloader used for booting some Linux OSs will no longer be trusted without flipping a switch in the UEFI firmware, which may partly be why Lenovo and Dell have announced they are keeping Pluton disabled by default. However, this might not do much in the long run, as will be explored below.

It is important to note that Pluton is very much like the Secure Enclave or TrustZone systems on macOS/iOS/Android systems, with a full (secure) CPU core, its own small onboard RAM, ROM, RNG, fuse bank, and so forth. For (obvious) security reasons, Pluton only boots officially-signed Microsoft firmware and carries anti-downgrade protections inherited from the Xbox. On non-Windows systems like Linux, Pluton quietly degrades into only a generic TPM 2.0 implementation.

A lot of acronyms, but what is the big picture?

In a nutshell, Microsoft believes they need to exercise more control over PC Security than previously. This came up with Windows 11, which infamously required 8th Gen or newer CPUs, TPM 2.0, and Secure Boot capability. At the time, there was (and still is) much concern regarding the almost arbitrary nature of the requirements.

However, while Microsoft was terrible at defining why certain CPUs made the cut and others didn’t (like why no Zen 1?), Ars Technica noticed a pattern:

Windows 11 (and also Windows 10!) uses virtualization-based security, or VBS, to isolate parts of system memory from the rest of the system. VBS includes an optional feature called “memory integrity.” That’s the more user-friendly name for something called Hypervisor-protected code integrity, or HVCI. HVCI can be enabled on any Windows 10 PC that doesn’t have driver incompatibility issues, but older computers will incur a significant performance penalty because their processors don’t support mode-based execution control, or MBEC.

And that acronym seems to be at the root of Windows 11’s CPU support list. If it supports MBEC, generally, it’s in. If it doesn’t, it’s out. MBEC support is only included in relatively new processors, starting with the Kaby Lake and Skylake-X architectures on Intel’s side, and the Zen 2 architecture on AMD’s side—this matches pretty closely, albeit not exactly, with the Windows 11 processor support lists.

Windows 11, by (almost) requiring MBEC, TPM 2.0, Secure Boot capability, and so forth is in every way trying to get people used to a Pluton-lite experience, as “Pluton-y” as possible without actually having Pluton yet. Windows 11 is the “stepping stone” to Pluton with security requirements to match. With Windows rumored to return to the 3-year version cycle with Windows 12 in ~2024, and with Microsoft clearly being less afraid of cutting off large swaths of old PCs, it would not shock me if Windows 12 makes Pluton a system requirement. Windows 10 for old systems, Windows 11 for systems not quite there, Windows 12 for the endgame.

Anything more I should know about what Pluton aims to do?

I’ve thrown out the acronyms for those interested in further reading, but what are the design goals behind those acronyms?

Microsoft originally developed Pluton for the Xbox, but also for the Azure Sphere. When they developed the Azure Sphere chip for secure IoT Devices, they designed it to be in compliance with their “Seven Properties of Highly Secure Devices“:

Microsoft also in that document shares how Pluton was integrated with this MediaTek IoT Chip, which looks probably pretty similar to how it is being integrated in Intel/AMD/Qualcomm:

It is not perfectly possible to implement Azure Sphere levels of security in a Windows PC. On Azure Sphere, a device becomes permanently locked to one manufacturer’s account permanently and only runs one app, with absolutely no ability to boot alternative apps or operating systems. Microsoft is no doubt going to need to compromise Pluton for general-purpose computing, but by how much…

All put together, what are the effects on me when Pluton arrives?

  1. You will no longer be able to install Linux with Pluton enabled unless the Microsoft 3rd-party UEFI Certificate is enabled in your UEFI Firmware. See Microsoft’s 7 Principles #5.
  2. Pluton will integrate with Windows Update at least for system firmware, potentially allowing for some forms of drivers to be updated as well as potentially having downgrade prevention. This may partly be why Windows 11 has new driver requirements (DCH compliance). See Microsoft’s 7 Principles #3, #6, and possibly #7.
  3. With SHACK, Secret Keys will be able to be stored in hardware and be able to encrypt and decrypt material without the key ever being exposed to firmware or software. This allows for a potentially stronger BitLocker… or just plain old DRM. See Microsoft’s 7 Principles #2.
  4. DICE+RIoT is where the rubber really hits the road. In Microsoft’s documentation of what RIoT can do:

Meanwhile, DICE appears to share a lot of the same goals as RIoT:

DICE and RIoT appear to be different parts of the same solution: Providing a device-specific key and assertion capabilities. What’s more, consider when it is combined with SMM and DRTM:

Why is DICE+RIoT+SMM+DRTM sandwich so potentially extremely dangerous? Imagine if you are a game developer who wants to prevent cheating. According to IEEE’s interpretation, it could be possible to use Pluton to irrefutably verify (aka “assert”) that:

  1. The device is running Windows,
  2. The device is up-to-date or recently updated,
  3. The device has not had Secure Boot disabled or tampered with

Part #3 is most important. When you combine #3, the ability to have the Pluton security processor assert that the device has booted with Secure Boot in accordance with Microsoft’s 7 Principles #5 using the sandwich, and a potential custom kernel module for anti-cheat, you have successfully proven cryptographically:

  1. The device has securely booted,
  2. Your kernel module has loaded,
  3. Your kernel module, and Windows itself, has absolutely not been tampered with in any way
  4. Windows is up-to-date with all or most security features enabled,
  5. By having Hypervisor-powered Code Integrity through HVCI/MBEC, injecting code will be extremely difficult even if the code is flawed or contains exploits

If you were a DRM designer, you would probably be drooling. No more workarounds or hacks – its an on-silicon, Xbox-proven solution, now on Windows. Microsoft, of course, doesn’t want to talk about that use-case and says that it will primarily be used by their Azure Attestation Service and allowing businesses to keep devices up-to-date and secure, but the road to Hell is paved with good intentions. As IEEE has noted citing personal conversations with Microsoft Engineers, any attestation service could use Pluton for their own ends, as DICE+RIoT are both open standards for this kind of thing. In fact, Microsoft’s use of open standards for assertions might make this more dangerous in my opinion.

Doomsday and “Fearmongering” Speculations Below – Objectively verified knowledge ends here

What is to prevent school WiFi from one day requiring a Pluton assertion that your Windows PC hasn’t been tampered with before you can join the network? As far as I can tell from the above specifications, there is no reason, assuming that the school had the ability to provide a connection client app before connecting.

Microsoft’s other use of DICE+RIoT, in their own words, is to enable “Zero Trust Computing.” By giving every device the ability to have secret keys completely out of reach of the main processor (see 7 Security Principles #2 and #5), it is theoretically possible to create documents, messages, and other content that is completely unreadable except by a specific device using a key that cannot be extracted from that device.

Imagine thus, a different scenario from the game developer. Imagine a (maybe corrupt) government agency or business. In the not-too-distant future, the following could be possible with Pluton (with some custom app development to streamline everything together):

  • All devices in the network have Pluton and are enrolled in Azure.
  • Every time a document is created and added to the network, it is added with a Pluton certificate verifying who created the document. Anonymous documents are kept off the network.
  • Every user in the organization is in Azure through Active Directory, and has specific devices attached to their User. Their User is enrolled in specific groups, such as Accounting or Legal.
  • Documents are encrypted through Azure to be only readable on specific client devices using the device-specific public key.
  • Thus, employees can read approved documents, but only on authorized systems.

To put this together, imagine this hypothetical scenario. A user in Legal creates a document. When the user uploads it, Azure verifies it against Pluton to both verify the document as being likely clean, and also to firmly establish who created it. When another user wants to download the document, Azure only provides a version that has been encrypted with the user’s Pluton public key if that user belonged in the right department, and thus only readable by that user.

  • These authorized systems could contain MDM (Mobile Device Management) measures that, thanks to Pluton with Secure Boot and physical attack protection, cannot be disabled. It also cannot easily have code injected or bypasses installed due to the Hypervisor. Pluton will also, in this situation, likely enforce BitLocker with an unknown unlock key.
  • The system is tamper-resistant and constantly updated, meaning that should a strict MDM policy be in place, extracting documents from a system without authorization could be potentially extraordinarily difficult to impossible.

Now, Microsoft might look at the above and laugh this off as fear mongering, as that is much further than what Pluton is being pitched as right now, as a firmware security device to prevent malware. However, how far away is it actually? If you can have Pluton verify a system as Securely booted without tampering, encrypt and decrypt material with an unextractable key, and connect to Azure for firmware updates, how much harder is it to add a secure mode to Microsoft Office that pulls it all together? You can’t hack Microsoft Office’s read-only or other protection modes if your MDM blocks external apps, the hypervisor prevents code injection, you can’t mess with Secure Boot without your keys getting invalidated, and your document is encrypted with a key only your device has that cannot be extracted.

The road to Hell is paved with good intentions. It looks as though Microsoft’s Next-Gen Secure Computing Base / Palladium project never really died.

Read More

Related posts

© Copyright 2022, All Rights Reserved