3 ms·

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 runni

by bri3d 9mo 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.

bayindirh 9mo ago
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.
- bri3d 9mo ago
  > 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.
  - bayindirh 9mo ago
    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.
    - bri3d 9mo ago
      I don't see how this relates in any way to Amutable and it has been a "concern" for 20+ years (which has never come to pass). How do you think this relates at all?
      - bayindirh 9mo ago
        Before this point in time, Linux never supported being an immutable image. Neither filesystems, nor the mechanism to lock it down was there. The best you could do was, TiVoization, but that would be too obvious and won't fly. Now we have immutable distributions (SuSE, Fedora, NixOS). We have the infrastructure for attestation (systemd's UKI, image based boot, and other immutability features), TPMs and controversially uutils (Which is MIT licensed and has the stated goal to replace all GNU userspace). You can build an immutable and adversarial userspace where you don't have to share the source, and require every boot and application call to attest. The theoretical thickness of the wall is both much greater and this theoretical state is much easier to achieve. 20 years ago the only barrier was booting. After that everything was free. Now it's possible to boot into a prison where your every ls and cd command can be attested. Oh, Rust is memory safe. Good luck finding holes.
        bri3d 9mo ago
        > Before this point in time, Linux never supported being an immutable image. What? As just one example, dm-verity was merged into the mainline kernel 13 years ago. I built immutable, verified Linux systems at least ten years ago, and it was considered old hat by the time I got there. > The best you could do was, TiVoization, but that would be too obvious and won't fly. What does this even mean? "TiVoization" is the slang for "you get a device that runs Linux, you get the GPL sources, but you can't flash your own image on the device because you don't own the keys." This is the exact same problem then as it was now and just as "obvious?" I understand the fears that come from client attestation (certainly, the way it has been used on Android has been majorly detrimental to non-Google ROMs), but, to the Android point, the groundwork has always been there. I'd be very annoyed if someone showed up and said "we're making a Linux-based browser attestation system that your bank is going to partner on," but nobody has even gone this direction on Windows yet. > Oh, Rust is memory safe. Good luck finding holes. I break secure boot systems for a living and I'd say _maybe_ half of the bugs I find relate to memory safety in a way Rust would fix. A lot of systems already use tools which provide very similar safety guarantees to Rust for single threaded code. Systems are definitely getting more secure and I do worry about impenetrable fortresses appearing in the near future, but making this argument kind of undermines credibility in this space IMO.
  - LooseMarmoset 9mo ago
    Have you run an Android device recently?
    - bri3d 9mo ago
      Yes, I reference Android client attestation in my comments in this thread frequently. I actually see this company as likely to be the flip side of the “bad” client attestation coin; server attestation actually provides a lot of nice properties to end users and providers who wish to provide secure solutions with very limited user downside.
      - LooseMarmoset 9mo ago
        It won't remain "server" attestation. It will become "client" attestation, with the end result that you won't own your own machine anymore, you'll just be paying for a client device upon which you won't control the hardware or software anymore. See any mobile phone at all, anymore.
        bri3d 9mo ago
        I don’t see anyone investing in this for general purpose desktop Linux in the state desktop Linux exists today; the harbinger of the Desktop Linux Apocalypse would be web-based Windows attestation (just as Android attestation is eroding alt-OSes) which feels like a viable “threat” but thankfully doesn’t seem to be happening just yet. I do think this approach might get used for client attestation in gaming, which I actually don’t mind; renting/non-owning a client that lets me play against non cheaters is a pretty good gaming outcome, and needing a secure configuration to run games seems like a fine trade for me (vs for example needing a secure desktop configuration to access my bank, which would be irksome).
cwillu 9mo ago
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.
- AshamedCaptain 9mo ago
  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.
blibble 9mo ago
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
deknos 9mo ago
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
PunchyHamster 9mo ago
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
- bri3d 9mo ago
  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.”
egorfine 9mo ago
> 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.
- bri3d 9mo ago
  > 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.
  - egorfine 9mo ago
    > 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.

by bri3d 9mo ago

bayindirh 9mo ago

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.

bri3d 9mo ago
> 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.
- bayindirh 9mo ago
  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.
  - bri3d 9mo ago
    I don't see how this relates in any way to Amutable and it has been a "concern" for 20+ years (which has never come to pass). How do you think this relates at all?
    - bayindirh 9mo ago
      Before this point in time, Linux never supported being an immutable image. Neither filesystems, nor the mechanism to lock it down was there. The best you could do was, TiVoization, but that would be too obvious and won't fly. Now we have immutable distributions (SuSE, Fedora, NixOS). We have the infrastructure for attestation (systemd's UKI, image based boot, and other immutability features), TPMs and controversially uutils (Which is MIT licensed and has the stated goal to replace all GNU userspace). You can build an immutable and adversarial userspace where you don't have to share the source, and require every boot and application call to attest. The theoretical thickness of the wall is both much greater and this theoretical state is much easier to achieve. 20 years ago the only barrier was booting. After that everything was free. Now it's possible to boot into a prison where your every ls and cd command can be attested. Oh, Rust is memory safe. Good luck finding holes.
      - bri3d 9mo ago
        > Before this point in time, Linux never supported being an immutable image. What? As just one example, dm-verity was merged into the mainline kernel 13 years ago. I built immutable, verified Linux systems at least ten years ago, and it was considered old hat by the time I got there. > The best you could do was, TiVoization, but that would be too obvious and won't fly. What does this even mean? "TiVoization" is the slang for "you get a device that runs Linux, you get the GPL sources, but you can't flash your own image on the device because you don't own the keys." This is the exact same problem then as it was now and just as "obvious?" I understand the fears that come from client attestation (certainly, the way it has been used on Android has been majorly detrimental to non-Google ROMs), but, to the Android point, the groundwork has always been there. I'd be very annoyed if someone showed up and said "we're making a Linux-based browser attestation system that your bank is going to partner on," but nobody has even gone this direction on Windows yet. > Oh, Rust is memory safe. Good luck finding holes. I break secure boot systems for a living and I'd say _maybe_ half of the bugs I find relate to memory safety in a way Rust would fix. A lot of systems already use tools which provide very similar safety guarantees to Rust for single threaded code. Systems are definitely getting more secure and I do worry about impenetrable fortresses appearing in the near future, but making this argument kind of undermines credibility in this space IMO.
- LooseMarmoset 9mo ago
  Have you run an Android device recently?
  - bri3d 9mo ago
    Yes, I reference Android client attestation in my comments in this thread frequently. I actually see this company as likely to be the flip side of the “bad” client attestation coin; server attestation actually provides a lot of nice properties to end users and providers who wish to provide secure solutions with very limited user downside.
    - LooseMarmoset 9mo ago
      It won't remain "server" attestation. It will become "client" attestation, with the end result that you won't own your own machine anymore, you'll just be paying for a client device upon which you won't control the hardware or software anymore. See any mobile phone at all, anymore.
      - bri3d 9mo ago
        I don’t see anyone investing in this for general purpose desktop Linux in the state desktop Linux exists today; the harbinger of the Desktop Linux Apocalypse would be web-based Windows attestation (just as Android attestation is eroding alt-OSes) which feels like a viable “threat” but thankfully doesn’t seem to be happening just yet. I do think this approach might get used for client attestation in gaming, which I actually don’t mind; renting/non-owning a client that lets me play against non cheaters is a pretty good gaming outcome, and needing a secure configuration to run games seems like a fine trade for me (vs for example needing a secure desktop configuration to access my bank, which would be irksome).

cwillu 9mo ago

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.

AshamedCaptain 9mo ago
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.

blibble 9mo ago

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

deknos 9mo ago

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

PunchyHamster 9mo ago

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

bri3d 9mo ago
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.”

egorfine 9mo ago

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

bri3d 9mo ago
> 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.
- egorfine 9mo ago
  > 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.