5 ms·

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

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.

schoen 5y ago
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.
- andrewmcwatters 5y ago
  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.
  - schoen 5y ago
    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!).
    - andrewmcwatters 5y ago
      Right, I can understand how this would be important now. Thank you.
- allset_ 5y ago
  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.
detaro 5y ago
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.
- andrewmcwatters 5y ago
  That's not control.
  - detaro 5y ago
    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)
    - andrewmcwatters 5y ago
      I see now.
- mfer 5y ago
  > 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.
wmf 5y ago
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.
- decodebytes 5y ago
  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.
zahllos 5y ago
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.
enragedcacti 5y ago
> 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.
- andrewmcwatters 5y ago
  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.
simonw 5y ago
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!
- BenTheElder 5y ago
  Why can't they be "threatened with a crowbar" to sign the exploit?
  - dane-pgp 5y ago
    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.
    - BenTheElder 5y ago
      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).
mfer 5y ago
> 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.

schoen 5y ago

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.

andrewmcwatters 5y ago
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.
- schoen 5y ago
  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!).
  - andrewmcwatters 5y ago
    Right, I can understand how this would be important now. Thank you.
allset_ 5y ago
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.

detaro 5y ago

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.

andrewmcwatters 5y ago
That's not control.
- detaro 5y ago
  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)
  - andrewmcwatters 5y ago
    I see now.
mfer 5y ago
> 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.

wmf 5y ago

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.

decodebytes 5y ago
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.

zahllos 5y ago

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.

enragedcacti 5y ago

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

andrewmcwatters 5y ago
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.

simonw 5y ago

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!

BenTheElder 5y ago
Why can't they be "threatened with a crowbar" to sign the exploit?
- dane-pgp 5y ago
  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.
  - BenTheElder 5y ago
    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).

mfer 5y ago

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