Live data from Hacker News

The Dangers of Microsoft Pluton

gabrielsieben.tech

471–480 of 554 posts

Re: The Dangers of Microsoft Pluton

#471
post #66

nowadays 98% of things implying "security" are actually unwanted products, protections for "the other side" or trivial distortions of reality where, conveyed by "security" itself, the user himself becomes the product - 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 powe…

> - 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

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?

Re: The Dangers of Microsoft Pluton

#472
post #459

Earlier quoted context omitted.

As a bit of an Anarcho-Libertarian who is often in the middle of these conversations from either side, I would imagine part of the problem is your framing of this issue as if it is only coming from one direction, when there is plenty of evidence that both sides are into things like banning books[0] it's just a question of which books they want banned. [0] When It Comes to Banning Books, Both Right and Left Are Guilty…

The both sides framing is a common tactic used to make this seem even but there’s a pretty notable difference if you look at the details. For example, Newsweek’s right-wing owners love this framing but the left example is a single school district removing a book from the curriculum whereas the right wing examples are far more widespread and include books being removed from libraries. The motives are also different: b…

According to the article that I linked, California has banned "To Kill a Mockingbird" in schools due to racism and you seem to be implying that is because the book "depict[s] racism positively"; however, I read it back in school and I remember discussing extensively how the book showed racism in a most negative light.

It doesn't seem to me like you are willing to believe that both sides could be over stepping here, but I personally am sure of it.

Re: The Dangers of Microsoft Pluton

#473
post #466

Earlier quoted context omitted.

You are incorrect yourself in several ways here. > 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…

> Pluton is de-facto a Secured Core PC implementation 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 indi…

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

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?

Re: The Dangers of Microsoft Pluton

#474
post #407

Earlier quoted context omitted.

No. MSFT has bet the business on Cloud and while the virtualization stack they use is Hyper-V, they have a TON of products running Linux under the hood in the cloud. A big chunk (I don't know the real number, but it's closer to 50% than 10%) of customer vm's on Azure are running Linux. All this to say, MSFT is highly invested in the Linux ecosystem. They would be shooting themselves in the foot to try and kill it off…

I think author meant Linux desktop Andy client facing Linux is, like the SteamOS.

I don't think Microsoft feels threatened by desktop Linux. If it catches on, it will be because manufacturers start shipping it, not because it's easier to install.

Manufacturers sell Linux workstations designed for power users and developers. UEFI/TPM, and now Pluton won't be a stumbling block for that as it hasn't been so far.

Dell is the biggest seller of pre-installed Linux desktop machines, and they are all billed as Workstations for power users or developers. Their home machines only have as an option Windows or ChromeOS. (Count that as Linux if you like, but I wouldn't...)

Why? Being more price competitive by bundling a free or cheap OS is not worth it in scaling up their support for a new OS. That's your stumbling block to better Linux desktop adoption, in my opinion.

Causing issues with remote attestation are probably more a side effect of just not caring about other OS's, rather than some sinister plot to sink Linux on the desktop.

Re: The Dangers of Microsoft Pluton

#475

Earlier quoted context omitted.

All Florida did was add a criteria to their selection process to disallow books that include Critical Theory/Critical Race Theory or their praxis in the teaching of math, etc. Every state selects which text books can be used by their schools so if Florida "burns books" then by definition every single other state does too. Where are the text books in California that teach math using Biblical stories and imagery? Obvio…

Of course, bible stories would be inappropriate because superstition and religion have no place in schools. We're supposed to educate students about reality. But there's nothing wrong with teaching students how they can use math to understand social problems and complex real-world issues. Math is a great tool for thinking about things like income inequality, climate change and economics.

Well since you opened that can of worms, CT/CRT is just another religion, and not a nice one.

Ibram X. Kendi, in his book “How to Be an Antiracist” states, “The only remedy to racist discrimination is antiracist discrimination. The only remedy to past discrimination is present discrimination. The only remedy to present discrimination is future discrimination.”

The whole movement is predicated, explicitly, on instilling hatred and animosity on some out-group, it's a viscous ideology masquerading as compassion.

Re: The Dangers of Microsoft Pluton

#476
post #469

Earlier quoted context omitted.

As someone who enjoys hacking, looking at that list sounds terrible. As a regular user, most of that list doesn't sound too bad. Their future devices will automatically have these features enabled, they're not likely to change those settings to "break" their device (from the perspective of Trusted Computing) so they'll have a smooth experience getting into it. - Can't block ads? A lot of average users already don't/d…

This is all just giving away control to corporations. Freedom is about having the option, not using it. Even if most "regular users" never use it, if they ever change their mind they'll surely appreciate having it. It also affects the ability to develop new hardware, and being locked to hardware/software approved by the remote side (e.g. Facebook or whichever app/site you're using) is a pretty Dystopian reality. > My…

If all clients interfacing with the bank's API are required to prove they're locked down devices running proven official clients it reduces the potential attack surface. Lowering the attack surface increases the security.

If the market really cared about being able to run whatever software you wanted, nobody would be buying iPhones. Fire TV sticks and Rokus wouldn't move any products. Playstations, Xboxes, and Nintendo Switches would be crushed under the massive marketshare of Mister devices and Steam PCs. One quick look at reality shows this isn't the case.

I think you're massively overestimating the market size of people who actually care.

Note that I'm not making any moral argument here, I'm not saying whether these things are good or bad. Personally as someone who likes to tinker and has been bitten several times by DRM and the likes, I'm not too much of a fan. As someone who has to try and ensure compliance on devices, its a godsend. But at the same time I know lots of people who buy Xboxes and Playstations because there's less cheating that happen on that platform. I know lots of people who buy iPhones and iPads because they know the odds of accidentally getting malware on it is very low compared to alternatives. To them, locked down hardware is a selling point.

I don't like having to lock my bike, its a huge pain. But at the same time there's tons of people here arguing locks shouldn't exist. Trusted computing, in the right context, is a good thing. Being able to lock your door is good! Being able to assure your device is what you say it is is good! I definitely agree there are potential dystopian futures with this technology, but that's true of any truly revolutionary technology. Wheels move carts of grain and help tanks roll. Being able to break dinitrogen into more usable sources gives us cheap fertilizer and explosives.

Re: The Dangers of Microsoft Pluton

#477
post #105

Earlier quoted context omitted.

Up to the community to prove their have a market value to be kept around and aren't yet another OpenMoko.

That is precisely the proof I need before I ever buy into either. I'm very optimistic about PinePhone but AIUI it's currently quite far from being a reliable daily driver for the kinds of tasks I need one for.

If everyone behaved as you do, we probably wouldn't have any progress.

Re: The Dangers of Microsoft Pluton

#478
post #466

Earlier quoted context omitted.

> Pluton is de-facto a Secured Core PC implementation 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 indi…

> No, it's not. You can deploy Pluton without having to implement the Secured Core PC spec. 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 th…

Given the apparent requirements around the Third Party UEFI CA, it's impossible for any device with a plug-in GPU to meet the Secured Core PC requirements. Unless Pluton is never going to be present in workstations, Pluton does not imply Secured Core.

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.

Re: The Dangers of Microsoft Pluton

#479

Earlier quoted context omitted.

still waiting on the secure boot lockdown everyone has insisted is coming for the better part of two decades...

The goal is not to prevent you from running Linux, is to make it so that Linux cannot access the content you are interested in. Remote Attestation establishes a root of trust that can be used to verify that all of the software down the line is "approved": - You won't be able to browse sites or use apps with ads unless you run a 'trusted' device, OS and browser that does not block ads. - You won't be able to browse si…

>- You won't be able to browse sites

How would that work?

HTTP is just HTTP

Re: The Dangers of Microsoft Pluton

#480
post #478

Earlier quoted context omitted.

> No, it's not. You can deploy Pluton without having to implement the Secured Core PC spec. 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 th…

Given the apparent requirements around the Third Party UEFI CA, it's impossible for any device with a plug-in GPU to meet the Secured Core PC requirements. Unless Pluton is never going to be present in workstations, Pluton does not imply Secured Core. 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…

I'm not entirely sold for a few reasons.

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.

Post reply on HN