Hacker News Reader

Comment by andrewmcwatters | Hacker News Reader

Can I ask, is this a real, actual concern? Why do I need to sign and verify my software is my software? Why is a hash not sufficient integrity verification?

I have never heard of a good argument for this besides the Apple-esque control of remotely disabling the ability for software to run based on certificate authority, which is not a feature I'm interested in.

Further, I'd like to not see this as possible, since year after year more and more software companies seem to think they're entitled to more and more.

View on HN

Fifteen years ago the principle security worry in running a web application was that some "script kiddy" would break in and deface your homepage.

Today the threats are much more real. Ransomware, cryptocurrency miners, even state actors.

An enormous point of weakness in modern software is the supply chain - many projects now have thousands of nested dependencies.

Most of those dependencies represents at least one human being who can be threatened with a crowbar and forced to ship an exploit, which can then infect vast numbers of production applications.

So yes, for me this is a very real concern!

Why can't they be "threatened with a crowbar" to sign the exploit?

Ultimately the system will need to support signatures which represent not just "I made this" but "I reviewed this", and people will need to set policies for whose reviews they trust, and how many reviews they require for each component.

If reviewers can build up a reputation anonymously, that will make it harder to find the human who needs to be crowbarred, but I'm not sure how you prove you are a good reviewer in a way which isn't gameable.

Alternatively, the reviewers could be well known teams in multiple jurisdictions, such that an attacker would need to buy multiple crowbars and multiple plane tickets.

Those are interesting points / possible approaches, however is there any indication that this particular project enables any of that?

This seems focused on signing binaries / build artifacts.

IMHO it seems like if you have the threat model of "crowbared maintainer forced to insert backdoor" you probably don't trust sources let alone binaries and need to vet your dependency sources and then compile your own binaries from them.

Many open source dependencies will not have a jurisdictionally diverse review team, or any review team at all (single maintainer).

With reproducible builds, the difference between signing a binary and signing the source code from which it is built should be meaningless.

I agree that the threat model should include the threat of untrustworthy source code, because we want the countermeasures to work equally well against backdoors, "bugdoors", and genuine bugs.

Good points.

I suspect for a lot of projects reproducible builds are themselves a bit of a hurdle and not being verified in the rarer case that they already exist, but the point of reproducible + signed builds as indirect source-signing stands.

The reviewing aspect sounds a lot like cargo-crev. [1]

[1] https://github.com/crev-dev/cargo-crev

Harder to manage scaling that

Great point.

You have to be in person for that attack, which is a much higher cost than taking over someone's account remotely from a different country. It's also a much higher risk of getting caught and going to jail.

Ok but the premise of physical harm in person comes from the parent comment, not mine:

"Most of those dependencies represents at least one human being who can be threatened with a crowbar and forced to ship an exploit, which can then infect vast numbers of production applications."

And when the certificate is compromised ? Crxpto AG ? There are a lot of companies/states which supply certificates which are then used for MITM.

This is where the transparency log comes in, certificate signing is openly auditable. It's the same as certificate transparency, malicious or mistakenly administered certificates are openly auditable (instead of being a transaction that occurs behind the doors of a commercial CA).

Also, in future implementations it would be possible for security conscious publishers to attach cryptographic attestations produced by trusted third party hardware manufacturers to their signature demonstrating the private key was generated on the hardware device and therefore could not be under the control of the service operators. Security conscious clients could start to require this for dependencies they pull in.

> Can I ask, is this a real, actual concern? Why do I need to sign and verify my software is my software? Why is a hash not sufficient integrity verification?

Security is layered so there is no one thing to just secure it. With that in mind, how do you control which revision of something is deployed? Do you use the hash? What if someone pushed a different version to your container repo? Could that be somehow run somewhere? It may require someone gaining privileges but that is not an uncommon situation. This is why multi-layered security is useful.

If something is signed and verified you can know WHO it came from. Someone with access to sign it. In the situation where a bad actor pushed something to a container repo the verification step would fail and you would catch it.

This is just one example. There are many others.

> Why is a hash not sufficient integrity verification?

not necessarily endorsing the need for this, but one reason is that if the hash and file are hosted by the same site an attacker who compromised the web server can trivially change the hash to match their payload. With this system, they would have to compromise both the web server and the signing server.

You can also leverage this to trust a binary even from an unknown source because the signature will match and confirm authenticity regardless of how trustworthy the source of the binary is.

That's just an incorrect usage of an integrity hash. If you obtain a resource from another party other than the original vendor, you need to verify integrity.

If the vendor itself is compromised, then I can understand such a system.

How do you know which hash is the correct one? you can

a) check a signature on the hash (current method)

b) check with a central authority if the hash is ok (now that's central control)

c) somehow discover the hash from some other source - possible, but not something users will generally manually verify, and the question of how to trust that hash again quickly comes down to signatures or authority.

That's not control.

At least as much as a signature check, and if you send a hash to somewhere to look it up it reveals more about your system than the signature verification does. If you fetch a list of trusted hashes, the source can customize it more precisely to what to tell you is ok than if you verify a signature.

How is telling you "don't trust this hash" any less "Apple-esque control of remotely disabling the ability for softwareto run" than something saying "don't trust this certificate after $date"? (E.g. the recent-ish Apple outrage was that they switched to uploading hashes over just verifying signatures)

I see now.

> How do you know which hash is the correct one?

Figuring out the correct hash is different from knowing that the software you got is from who you expected it to be from. If you sign 100 versions of something and you verify what you got... you'll know they came from who you expected (rather than a bad actor) but you might not know which version to run from that.

This isn't about users' entitlement to run software, but about publishers and users' ability to confirm that everyone has the same version of the software -- to mitigate supply-chain attacks. This is a real, actual concern because governments and probably organized crime are interested in attacking supply chains in order to attack end users, for example by hacking software developers or publishers in order to substitute a slightly modified version of code.

It could be useful for software distributors to have their version history memorialized somewhere outside of their own control, for example to reduce the attractiveness of governments trying to compel them to secretly tamper with some users' versions of a program, or to make it meaningful and more straightforward to check later on whether they published what they thought they published.

So once again, what is the difference between this and an authorized list of integrity hash values?

Edit: I misread the latter portion of your post. I see now. Thanks.

As some other replies pointed out, if that list is distributed in the same place as the software itself, an attacker can modify both of them at the same time.

Maybe the list is digitally signed by the publisher, but then often the signing key is also distributed in the same place as the software itself (and also often used on the same infrastructure that the software was compiled on).

Also, if the list of hash values is distributed only by a software publisher, the software publisher will get the ability to secretly backdoor some users, but not others, by creating two or more different versions of that list. Then it can deny the existence of the backdoored version to the public (or to itself, if the backdooring was done by an unauthorized insider!).

Right, I can understand how this would be important now. Thank you.

It's also a significant step in a direction to where every dependency that these software publishers is also signed, increasing the overall confidence that there's no malicious code in the software they publish.

Is there a trustable, out-of-band way for users to get the hash? How?

There's a real vulnerability where users get a compromised package and a matching hash from the same compromised repository.

This is where the transparency log comes in. The hash / signature and public key (by way of a signed x509 certificate) are hashed into an tamper resistant immutable merkle tree. This makes it hard to tamper with the hash. However a bad hash could still be put into the tree, but this is sort of a feature not a bug aspect of a transparency log, anyone can audit the log and see those bad entries. You as an individual are not susceptible to a targeted attack, you see what everyone else sees.

This is an idiom borrowed from certificate transparency. You kind of want the badly signed certs to be recorded, as they can be monitored and audited for. Everything is out in the open in the plain light of day.

Yes it is a real concern. If you're running a Linux distribution, chances are you are downloading your packages from a mirror and not the primary mirror for your distribution. This is done to everyone's benefit bandwidth-wise.

However it opens up the possibility that the artefacts can be tampered with on the server. Signing confirms their authenticity. In a (cryptographically secure) hash, there is no 'key' and so anyone can create a valid one for their modified bundle.

Ditto for containers, Android Apps, and just about anything else we use.

Reply on news.ycombinator.com