Comment by bri3d
12 days ago
The typical HN rage-posting about DRM aside, there's no reason that remote attestation can't be used in the opposite direction: to assert that a server is running only the exact code stack it claims to be, avoiding backdoors. This can even be used with fully open-source software, creating an opportunity for OSS cloud-hosted services which can guarantee that the OSS and the build running on the server match. This is a really cool opportunity for privacy advocates if leveraged correctly - the idea could be used to build something like Apple's Private Cloud Compute but even more open.
Like evil maid attacks, this is a vanishingly rare scenario brought out to try to justify technology that will overwhelmingly be used to restrict computing freedom.
In addition, the benefit is a bit ridiculous, like that of DRM itself. Even if it worked, literally your "trusted software" is going to be running in an office full of the most advanced crackers money can buy, and with all the incentive to exploit your schema but not publish the fact that they did. The attack surface of the entire thing is so large it boggles the mind that there are people who believe on the "secure computing cloud" scenario.
WHAT is the usage and benefit for private users? This is always neglected.
avoiding backdoors as a private person you always can only solve with having the hardware at your place, because hardware ALWAYS can have backdoors, because hardware vendors do not fix their shit.
From my point of view it ONLY gives control and possibilities to large organizations like governments and companies. which in turn use it to control citizens
You're absolutely right, but considering Windows requirements drive the PC spec, this capability can be used to force Linux distributions in bad ways.
So, some of the people doing "typical HN rage-posting about DRM" are also absolutely right.
The capabilities locking down macOS and iOS and related hardware also can be used for good, but they are not used for that.
> but considering Windows requirements drive the PC spec, this capability can be used to force Linux distributions in bad ways
What do you mean by this?
Is the concern that systemd is suddenly going to require that users enable some kind of attestation functionality? That making attestation possible or easier is going to cause third parties to start requiring it for client machines running Linux? This doesn't even really seem to be a goal; there's not really money to be made there.
As far as I can tell the sales pitch here is literally "we make it so you can assure the machines running in your datacenter are doing what they say they are," which seems pretty nice to me, and the perversions of this to erode user rights are either just as likely as they ever were or incredibly strange edge cases.
Microsoft has a "minimum set of requirements" document about "Designed for Windows" PCs. You can't sell a machine with Windows or tell it's Windows compatible without complying with that checklist.
So, every PC sold to consumers is sanctioned by Microsoft. This list contains Secure Boot and TPM based requirements, too.
If Microsoft decides to eliminate enrollment of user keys and Secure Boot toggle, they can revoke current signing keys for "shims" and force Linux distributions to go full immutable to "sign" their bootloaders so they can boot. As said above, it's not something Amutable can control, but enable by proxy and by accident.
Look, I work in a datacenter, with a sizeable fleet. Being able to verify that fleet is desirable for some kinds of operations, I understand that. On the other hand, like every double edged sword, this can cut in both ways.
I just want to highlight that, that's all.
3 replies →
Have you run an Android device recently?
3 replies →
> there's no reason that remote attestation can't be used in the opposite direction
There is: corporate will fund this project and enforce its usage for their users not for the sake of the users and not for the sake of doing any good.
What it will be used for is to bring you a walled garden into Linux and then slowly incentivize all software vendors to only support that variety of Linux.
LP has a vast, vast experience in locking down users' freedom and locking down Linux.
> There is: corporate will fund this project and enforce its usage for their users not for the sake of the users and not for the sake of doing any good.
I'd really love to see this scenario actually explained. The only place I could really see client-side desktop Linux remote attestation gaining any foothold is to satisfy anti-cheat for gaming, which might actually be a win in many ways.
> What it will be used for is to bring you a walled garden into Linux and then slowly incentivize all software vendors to only support that variety of Linux.
What walled garden? Where is the wall? Who owns the garden? What is the actual concrete scenario here?
> LP has a vast, vast experience in locking down users' freedom and locking down Linux.
What? You can still use all of the Linuxes you used to use? systemd is open source, open-application, and generally useful?
Like, I guess I could twist my brain into a vision where each Ubuntu release becomes an immutable rootfs.img and everyone installs overlays over the top of that, and maybe there's a way to attest that you left the integrity protection on, but I don't really see where this goes past that. There's no incentive to keep you from turning the integrity protection off (and no means to do so on PC hardware), and the issues in Android-land with "typical" vendors wanting attestation to interact with you are going to have to come to MacOS and Windows years before they'll look at Linux.
> client-side desktop Linux remote attestation gaining any foothold is to satisfy anti-cheat for gaming, which might actually be a win in many ways.
It will be, no doubt. As soon as it is successfully tested and deployed for games, it will be used for movies, government services, banks, etc. And before you know you do not have control of your own computer.
> Who owns the garden?
Not you.
> everyone installs overlays over the top of that
Except this breaks cryptography and your computer is denied multiple services. Because you are obviously a hacker, why else would anyone want to compile and run programs.
> turning the integrity protection off (and no means to do so on PC hardware)
It's a flip of a switch, really. Once Microsoft decides you have had enough, the switch is flipped and in a couple of years no new Intel computer will boot your kernel.
4 replies →
intel have had a couple of goes at this
and each time the doors have been blasted wide off by huge security vulnerabilities
the attack surface is simply too large when people can execute their own code nearby
it doesn't stop remote code injection. Protecting boot path is frankly hardly relevant on server compared to actual threats.
You will get 10000 zero days before you get a single direct attack at hardware
The idea is that by protecting boot path you build a platform from which you can attest the content of the application. The goal here is usually that a cloud provider can say “this cryptographic material confirms that we are running the application you sent us and nothing else” or “the cloud application you logged in to matched the one that was audited 1:1 on disk.”