|
| ▲ | direwolf20 3 hours ago | parent | next [-] |
| Remote attestation is literally a form of DRM |
| |
| ▲ | microtonal 3 hours ago | parent | next [-] | | There are genuine positive applications for remote attestation. E.g., if you maintain a set of servers, you can verify that it runs the software it should be running (the software is not compromised). Or if you are running something similar to Apple's Private Compute Cloud to run models, users can verify that it is running the privacy-preserving image that it is claiming to be running. There are also bad forms of remote attestation (like Google's variant that helps them let banks block you if you are running an alt-os). Those suck and should be rejected. Edit: bri3d described what I mean better here: https://news.ycombinator.com/item?id=46785123 | | | |
| ▲ | youarentrightjr an hour ago | parent | prev [-] | | > Remote attestation is literally a form of DRM Let's say I accept this statement. What makes you think trusted boot == remote attestation? |
|
|
| ▲ | omnicognate 3 hours ago | parent | prev | next [-] |
| As the immediate responder to this comment, I claim to be the next guy. I love systemd. |
|
| ▲ | josephcsible 3 hours ago | parent | prev | next [-] |
| "cryptographically verifiable integrity" is a euphemism for tivoization/Treacherous Computing. See, e.g., https://www.gnu.org/philosophy/can-you-trust.en.html |
|
| ▲ | elcritch 3 hours ago | parent | prev | next [-] |
| Secure boot and attestation both generally require a form of DRM. It’s a boon for security, but also for control. |
| |
| ▲ | youarentrightjr 32 minutes ago | parent [-] | | > Secure boot and attestation both generally require a form of DRM. They literally don't. For a decade, I worked on secure boot & attestation for a device that was both: - firmware updatable
- had zero concept or hardware that connected it to anything that could remotely be called a network | | |
| ▲ | warkdarrior 4 minutes ago | parent [-] | | Interesting. So what did the attestation say once I (random Internet user) updated the firmware to something I wrote or compiled from another source? |
|
|
|
| ▲ | mikkupikku 3 hours ago | parent | prev | next [-] |
| I don't mind SystemD. |
|
| ▲ | bri3d 3 hours ago | parent | prev [-] |
| Hacker News has recently been dominated by conspiracy theorists who believe that all applications of cryptography are evil attempts by shadowy corporate overlords to dominate their use of computing. |
| |
| ▲ | josephcsible 3 hours ago | parent | next [-] | | No, it's not "all applications of cryptography". It's only remote attestation. | |
| ▲ | mikkupikku 2 hours ago | parent | prev [-] | | Buddy, if I want encryption of my own I've got secure boot, LUKS, GPG, etc. With all of those, why would I need or even want remote attestation? The purpose of that is to assure corporations that their code is running on my computer without me being able to modify it. It's for DRM. | | |
| ▲ | bri3d an hour ago | parent [-] | | I am fairly confident that this company is going to assure corporations that their own code is running on their own computers (ie - to secure datacenter workloads), to allow _you_ (or auditors) to assure that only _your_ asserted code is also running on their rented computers (to secure cloud workloads), or to assure that the code running on _their_ computers is what they say it is, which is actually pretty cool since it lets you use Somebody Else's Computer with some assurance that they aren't spying on you (see: Apple Private Cloud Compute). Maybe they will also try to use this to assert "deep" embedded devices which already lock the user out, although even this seems less likely given that these devices frequently already have such systems in place. IMO it's pretty clear that this is a server play because the only place where Linux has enough of a foothold to make client / end-user attestation financially interesting is Android, where it already exists. And to me the server play actually gives me more capabilities than I had: it lets me run my code on cloud provided machines and/or use cloud services with some level of assurance that the provider hasn't backdoored me and my systems haven't been compromised. | | |
| ▲ | mikkupikku an hour ago | parent [-] | | How can you be "pretty sure" they're going to develop precisely the technology needed to implement DRM but also will never use or allow it to be used by anybody but the lawful owners of the hardware? You can't. It's like designing new kinds of nerve gas, "quite sure" that it will only ever be in the hands of good guys who aren't going to hurt people with it. That's powerful naïveté. Once you make it, you can't control who has it and what they use it for. There's no take-backsies, that's why it should never be created in the first place. | | |
| ▲ | bri3d an hour ago | parent [-] | | The technology needed to implement DRM has been there for 20+ years and has already evolved in the space where it makes sense from an "evil" standpoint (if you're on that particular side of the fence - Android client attestation), so someone implementing the flip side that might actually be useful doesn't particularly bother me. I remember the 1990s "cryptography is the weapon of evil" arguments too - it's funny how the tables have turned, but I still believe that in general these useful technologies can help people overall. | | |
| ▲ | mikkupikku 34 minutes ago | parent [-] | | The technology already exists and also there is unmet industrial market demand for the technology. Incoherent. If it already exists as you say, then Lennart should fuck off and find something else to make. | | |
| ▲ | bri3d 8 minutes ago | parent [-] | | > The technology already exists and also there is unmet industrial market demand for the technology. The "bad" version, client attestation, is already implemented on Android, and could be implemented elsewhere but is only a parallel concept. There is unmet industrial market demand for the (IMO) "not so bad / maybe even good" version, server attestation. |
|
|
|
|
|
|
