One of the key tenets of having good security is reducing how attackable your system is. This is what we call an attack surface – a system needs as few attack surfaces as possible, and as small as possible, to minimize any potential unwarranted intrusion. Beyond that, any additional security to detect and protect is vital. Both hardware and software can be used for that layer of additional security, and it becomes particularly important when dealing with virtualization, especially when it comes to virtual and physical attacks. In order to create a more unified system, Microsoft’s Pluton Security Processor, which works with Windows, is coming to the three major hardware vendors that implement the OS: AMD, Intel, and Qualcomm. What makes this different is that this is a physical in-hardware implementation that will be built directly into the future processors from each of the three companies.

Pioneered in both Xbox consoles and Microsoft’s Azure Sphere ecosystem, the Pluton Security Processor enables a full-stack chip-to-cloud security akin to a Trusted Platform Module (TPM). The TPM has been a backbone of server security over the last decade or more, providing a physical store for security keys and other metadata that verifies the integrity of a system. In the mobile space, a built-in TPM allows for other security verification, such as Windows Hello or Bitlocker.

Over time, according to Microsoft, a physical TPM module in these systems have become a weak point in modern security design. Specifically, gaining physical access to the system makes the TPM useless allowing for in-transit data hijacks or man-in-the-middle data pruning. Because a TPM is an optional addition to most server environments, that physical module-to-CPU data pathway becomes an important attack surface.

What the Pluton project from Microsoft and the agreement between AMD, Intel, and Qualcomm will do is build a TPM-equivalent directly into the silicon of every Windows-based PC of the future. The Pluton architecture will, initially, build an emulated TPM to work with existing specifications for access to the current suites of security protocols in place. Because Pluton will be in-silicon, it severely reduces the physical attack surface of any Pluton-enabled device.

The Pluton architecture seems to also allow for a superset of TPM features, perhaps to be enabled in the future. Microsoft highlights both the unique Secure HArdware Cryptography Key (SHACK) technology such that security keys are never exposed outside of the hardware environment, as well as community engagement such as what has been done through Project Cerberus, part of the Open Compute Project to enable root-of-trust and firmware authentication. We are told this is particularly important as it pertains to wide-spread patching issues.

All of the silicon vendors involved will have Pluton as the first layer of security – additional layers (such as AMD’s PSP) will go below this. From the three vendors, AMD has worked with Microsoft already on Pluton for consoles, so it should not be a big step to see Pluton in AMD consumer and enterprise silicon sooner rather than later, along with AMD’s other technologies such as Secure Encryption Virtualization. Intel stated that its long-term relationship with Microsoft should lead to a smooth Pluton integration, however the company declined to comment on a potential timeline. Qualcomm is the odd-one-out in a sense, as its cycles are a little different, but the company is quoted as stated that on-die hardware root-of-trust security is an important component of the whole silicon.

A number of parallels are being drawn between Pluton and Apple’s T2 security chip, which was moved inside the recently announced M1 processor. 

Sources

Comments Locked

27 Comments

View All Comments

  • Jorgp2 - Monday, November 23, 2020 - link

    Lol, you have no idea what you're going on about
  • Samus - Tuesday, November 24, 2020 - link

    I agree with practically everything you said, and what is most annoying about this entire trend is they don't offer a way to disable\bypass it. At least with most custom-built PC's you can disable things like secure boot and various security functions like DEP which is all essential for basic software troubleshooting or even testing a sandbox.

    But the industry knows better than security engineers so -_-
  • azfacea - Tuesday, November 24, 2020 - link

    I are agree. This isnt about security its about controlling ppl. its also about putting a million backdoors that no one asked for, and then 3 years later "they stop maintainingg" the garbage that no one asked for, so you have the opportunity to buy a new box, or be exposed to widely known and completely catastrophic vulnerabilities.

    we need regulators and initiatives like fsf to get involved and fix this. but that wont happen until a catastrophic disaster takes place first. Consumers have never accepted this, and will never accept it if given the choice. but its going to take a crisis to get this into apple/google/ms/sony thick head that my PC is mine and not your remote property.
  • edzieba - Wednesday, November 25, 2020 - link

    "M$'s own tablets like Surface are already riddled with enough Secure Boot and other garbage locks that block users from installing OSS like Linux distributions"

    Ah, the persistent myth that Secure Boot is somehow incompatible with Linux. Possibly from the early days of UEFI where Linux bootloaders had not bothered to implement UEFI support yet and just relied on having the user switch to legacy mode, which came a-cropper when devices started dropping legacy mode. But if you don't believe me, maybe you'll believe the Debian devs: https://wiki.debian.org/SecureBoot#What_is_UEFI_Se...

    "UEFI Secure Boot is not an attempt by Microsoft to lock Linux out of the PC market here; SB is a security measure to protect against malware during early system boot. Microsoft act as a Certification Authority (CA) for SB, and they will sign programs on behalf of other trusted organisations so that their programs will also run. There are certain identification requirements that organisations have to meet here, and code has to be audited for safety. But these are not too difficult to achieve.

    SB is also not meant to lock users out of controlling their own systems. Users can enrol extra keys into the system, allowing them to sign programs for their own systems. Many SB-enabled systems also allow users to remove the platform-provided keys altogether, forcing the firmware to only trust user-signed binaries. "
  • lmcd - Saturday, November 28, 2020 - link

    Early secure boot did not support nearly the same amount of keys that modern secure boot does. Early UEFI was sometimes not even on ROM, it was on disk, easy to accidentally write over! There were many practices from early OEM UEFI implementations that were not Linux-friendly. MS might not have been at fault but they didn't enforce good standards.
  • abufrejoval - Monday, November 23, 2020 - link

    While I couldn’t agree more, that a secure and trustable root of trust and management engine is necessary, there are several pre-conditions for its use and Microsoft doesn’t have a particularly good track record when it comes to doing it right.

    1. The owner, not Microsoft nor any of the vendors must be in command. If I was from North Korea, I want to be sure it won’t stop me from nuking my enemy, just because they manufactured it

    2. Just to be clear, the Apple, Google or Xbox approach is completely unacceptable, because they put ultimate control under foreign corporate control and I’d declare Apple hostile, if I had one. Microsoft loves Apple way too much for comfort. No, a corporate bypass isn’t enough: I as a EU citizen don’t want to be compromised by US executive order.

    3. I want SEV on the client side. Because I demand #1 and some vendors will stop performing their services unless they have exclusive supreme control, the only way out is SEV or safe VMs/containers via MKTME or better. Unfortunately, Ryzen 5000 and Tiger Lake client SoCs may have the hardware but not the firmware to support this. Why does that remind me of VM supported purposefully missing from 80386 until Mendel Rosenblum found a work-around with the 486SL?

    4. Open Source hardware, software, process attestation by independent auditors

    5. Kill switch, just in case somebody discovers how it actually makes things less secure. This has just gone far too many times to not expect this to happen
  • AdrianBc - Tuesday, November 24, 2020 - link

    I completely agree. Good points.
  • boeush - Monday, November 23, 2020 - link

    Will the development of this new hardware platform follow Microsoft's time-honored process of moving slowly and breaking things just for kicks and giggles on every Patch Tuesday?
  • Dug - Monday, November 23, 2020 - link

    Someone always finds a window to break in these things, no matter how many door locks you put on.
  • beginner99 - Tuesday, November 24, 2020 - link

    Oh, I bet you they ship with an NSA backdoor.

Log in

Don't have an account? Sign up now