Comment by drdaeman | Hacker News Reader

Comment by drdaeman | Hacker News Reader

Parent Full thread

Can you (or someone) please tell what’s the point, for a regular GNU/Linux user, of having this thing you folks are working on?

I can understand corporate use case - the person with access to the machine is not its owner, and corporation may want to ensure their property works the way they expect it to be. Not something I care about, personally.

But when it’s a person using their own property, I don’t quite get the practical value of attestation. It’s not a security mechanism anymore (protecting a person from themselves is an odd goal), and it has significant abuse potential. That happened to mobile, and the outcome was that users were “protected” from themselves, that is - in less politically correct words - denied effective control over their personal property, as larger entities exercised their power and gated access to what became de-facto commonplace commodities by forcing to surrender any rights. Paired with awareness gap the effects were disastrous, and not just for personal compute.

So, what’s the point and what’s the value?

The value is being able to easily and robustly verify that my device hasn't been compromised. Binding disk encryption keys to the TPM such that I don't need to enter a password but an adversary still can't get at the contents without a zero day.

Of course you can already do the above with secure boot coupled with a CPU that implements an fTPM. So I can't speak to the value of this project specifically, only build and boot integrity in general. For example I have no idea what they mean by the bullet "runtime integrity".

I don’t think attestation can provide such guarantees. To best of my understanding, it won’t protect from any RCE, and it won’t protect from malicious updates to configuration files. It won’t let me run arbitrary binaries (putting a nail to any local development), or if it will - it would be a temporary security theater (as attackers would reuse the same processes to sign their malware). IDSes are sufficient for this purpose, without negative side effects.

And that’s why I said “not a security mechanism”. Attestation is for protecting against actors with local hardware access. I have FDE and door locks for that already.

I think all of that comes down to being a matter of what precisely you're attesting? So I'm not actually clear what we're talking about here.

Given secure boot and a TPM you can remotely attest, using your own keys, that the system booted up to a known good state. What exactly that means though depends entirely on what you configured the image to contain.

> it won’t protect from malicious updates to configuration files

It will if you include the verified correct state of the relevant config file in a merkel tree.

> It won’t let me run arbitrary binaries (putting a nail to any local development), or if it will - it would be a temporary security theater (as attackers would reuse the same processes to sign their malware).

Shouldn't it permit running arbitrary binaries that you have signed? That places the root of trust with the build environment.

Now if you attempt to compile binaries and then sign them on the production system yeah that would open you up to attack (if we assume a process has been compromised at runtime). But wasn't that already the case? Ideally the production system should never be used to sign anything. (Some combination of SGX, TPM, and SEV might be an exception to that but I don't know enough to say.)

> Attestation is for protecting against actors with local hardware access. I have FDE and door locks for that already.

If you remotely boot a box sitting in a rack on the other side of the world how can you be sure it hasn't been compromised? However you go about confirming it, isn't that what attestation is?

Well, maybe we're talking about different things, because I've asked from a regular GNU/Linux user perspective. That is, I have my computers and I'm concerned I would lose my freedoms to use them as I wish, because this attestation would be adopted and become de-facto mandatory if I ever want to do something online. Just like what happened to mobile, and what's currently slowly happening to other desktop OSes.

Production servers are a whole different story - it's usually not my hardware to begin with. But given how things are mostly immutable those days (shipped as images rather than installed the old-fashioned sysadmin way), I'm not really sure what to think of it...

You originally asked what the value proposition for a regular (non-corporate) user was. Then you raised some objections to my answer (or at least so I thought).

Granted these technologies can also be abused. But that involves running third party binaries that require SGX or other DRM measures before they will unlock or decrypt content or etc. Or querying a security element to learn who signed the image that was originally booted. Devices that support those things are already widespread. I don't think that's what this project is supposed to be. (Although I could always be wrong. There's almost no detail provided.)

> For example I have no idea what they mean by the bullet "runtime integrity".

This is for example dm-verity (e.g. `/usr/` is an erofs partiton with matching dm-verity). Lennart always talks about either having files be RW (backed by encryption) or RX (backed by kernel signature verification).

> The value is being able to easily and robustly verify that my device hasn't been compromised.

That is impossible.

"secure" devices get silently tampered with everyday.

You can never guarantee that.

https://attestation.app/about For mobiles, it helps make tampering obvious.

https://doc.qubes-os.org/en/latest/user/security-in-qubes/an... For laptops, it helps make tampering obvious. (a different attestation scheme with smaller scope however)

This might not be useful to you personally, however.

Laptops can already have TPM based on FLOSS (with coreboot with Heads). It works well with Qubes btw, and is recommended by the developers: https://forum.qubes-os.org/t/qubes-certified-novacustom-v54-...

Reply on news.ycombinator.com