Hacker News Reader

Comment by mikkupikku | Hacker News Reader

Sounds like kernel mode DRM or some similarly unwanted bullshit.

It's probably built on systemd's Secure Boot + immutability support.

As said above, it's about who controls the keys. It's either building your own castle or having to live with the Ultimate TiVo.

We'll see.

We all know who controls the keys. It's the first party who puts their hands on the device.

Doesn't have to be. While I'm not a fan of systemd (my comment history is there), I want to start from a neutral PoV, and see what it does.

I have my reservations, ideas, and what it's supposed to do, but this is not a place to make speculations and to break spirits.

I'll put my criticism out politely when it's time.

And once you remove the friction for requiring cryptographic verification of each component, all it takes is one well-resourced lobby to pass a law either banning user-controlled signing keys outright or relegating them to second-class status. All governments share broadly similar tendencies; the EU and UK govts have always coveted central control over user devices.

Just to make it clear - on Android you don't have the keys. Even with avb_custom_key you can't modify many partitions.

None of the consumer mobile devices give you all the keys. There are many reasons for that, but 99.9% of them are monetary reasons.

But I want to buy that kind of device for money and I can't.. something is wrong with the market, looks like collusion..

> who controls the keys

Not you. This technology is not being built for you.

> Sounds like kernel mode DRM or some similarly unwanted bullshit.

Look, I hate systemd just as much as the next guy - but how are you getting "DRM" out of this?

As the immediate responder to this comment, I claim to be the next guy. I love systemd.

I don't like few pieces and Mr. Lennarts attitude to some bugs/obvious flaws, but by far much better than old sysv or really any alternative we have.

Doing complex flows like "run app to load keys from remote server to unlock encrypted partition" is far easier under systemd and it have dependency system robust enough to trigger that mount automatically if app needing it starts

I don't mind SystemD.

"cryptographically verifiable integrity" is a euphemism for tivoization/Treacherous Computing. See, e.g., https://www.gnu.org/philosophy/can-you-trust.en.html

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.

No, it's not "all applications of cryptography". It's only remote attestation.

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.

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.

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.

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.

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.

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

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

Interesting choice of analogy, to compare something with the singular purpose to destroy biological entities, to a computing technology that enforces what code is run.

Can you not see there might be positive, non-destructive applications of the latter? Are you the type of person that argues cars shouldn't exist due to their negative impacts while ignoring all the positives?

Remote attestation is literally a form of DRM

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

I agree that DRM feels good when you're the one controlling it.

> There are genuine positive applications for remote attestation

No doubt. Fully agree with you on that. However Intel ME will make sure no system is truly secure and server vendors do add their mandatory own backdoors on top of that (iLO for HP, etc).

Having said that, we must face the reality: this is not being built for you to secure your servers.

> Remote attestation is literally a form of DRM

Let's say I accept this statement.

What makes you think trusted boot == remote attestation?

Trusted boot is literally a form of DRM. A different one than remote attestation.

> Trusted boot is literally a form of DRM. A different one than remote attestation.

No, it's not. (And for that matter, neither is remote attestation)

You're conflating the technology with the use.

I believe that you have only thought about these technologies as they pertain to DRM, now I'm here to tell you there are other valid use cases.

Or maybe your definition of "DRM" is so broad that it includes me setting up my own trusted boot chain on my own hardware? I don't really think that's a productive definition.

It's possible to not implement remote attestation even when you implement secure boot.

This company is explicitly all about implementing remote attestation (which is a form of DRM):

https://amutable.com/events

> Remote Attestation of Imutable Operating Systems built on systemd

> Lennart Poettering

> This company is explicitly all about implementing remote attestation (which is a form of DRM):

Is there a HN full moon out?

Again, this is wrong.

DRM is a policy.

Remote attestation is a technology.

You can use remote attestation to implement DRM.

You can also use remote attestation to implement other things.

there are no other things. The entire point of remote attestation is to manage(i.e. take away) rights of user that runs it, unless you own entire chain, which you do not on any customer device

Secure boot and attestation both generally require a form of DRM. It’s a boon for security, but also for control.

> 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

Interesting. So what did the attestation say once I (random Internet user) updated the firmware to something I wrote or compiled from another source?

> Interesting. So what did the attestation say once I (random Internet user) updated the firmware to something I wrote or compiled from another source?

The update is predicated on a valid signature.

So your device had no user freedom. You're not doing much to refute the notion that these technologies are only useful to severely restrict user freedom for money.

> So your device had no user freedom. You're not doing much to refute the notion that these technologies are only useful to severely restrict user freedom for money.

Would love to hear more of your thoughts on how the users of the device I worked on had their freedom restricted!

I guess my company, the user of the device that I worked on, was being harmed by my company, the creator of the device that I worked on. It's too bad that my company chose to restrict the user's freedom in this way.

Who cares if the application of the device was an industrial control scenario where errors are practically guaranteed to result in the loss of human life, and as a result are incredibly high value targets ala Stuxnet.

No, the users rights to run any code trumps everything! Commercial device or not, ever sold outside of the company or not, terrorist firmware update or not - this right shall not be infringed.

I now recognize I have committed a great sin, and hope you will forgive me.

Reply on news.ycombinator.com