Check Who Signed Off On Your Software 25
An anonymous reader submits "The Software Sig Page encourages software maintainers to publish verifiable signatures for released software and to build the web of trust among software maintainers and software users. If you're afraid of downloading a trojaned OpenSSH, being 0wned while capturing packets, compiling an MTA as well as a backdoor on your system, not being able to trust tools you use every day, or never having a chance from the moment your OS boots, then you want some level of assurance that the software you use is everything the mainatainers expected you to have and no more. Look and check the MD5 and PGP signatures that come with software you download."
This seems like an issue for OSS (Score:3, Interesting)
If you're downloading god-knows-what from the Internet, you're taking a big chance, and this latest idea is probably pretty good for those people.
Nope.. (Score:3, Insightful)
Who tells you that no one compromised the data before it was put on the CD?
How can you be sure that the software companies compilers aren't compromised? (see Reflections on trusting Trust [wbglinks.net])
Even if the software you bought isn't compromised by any third party - can you trust the software company ?
Re:Nope.. (Score:2)
If they are, then digital signatures will do nothing but provide you with a false sense of security!
Re: (Score:1)
Re:This seems like an issue for OSS (Score:5, Interesting)
That's right. Because no software houses suffer from hacked networks. Because all sub-contractors are trustworthy. Because the source used to generate a CD is inherently more secure than a source used to generate a downloadable file.
Do you know that Microsoft is the only party that ever touches their data before it gets pressed and shipped? If you thought so, you're wrong.
Re:This seems like an issue for OSS (Score:1)
as long as there is no wide ranging crypto tech working in software distribution, talking about security is nonsense.
Re:This seems like an issue for OSS (Score:1, Insightful)
Re:This seems like an issue for OSS (Score:1)
MD5 (Score:1)
Good for a small market (Score:5, Insightful)
BSD ports tree required MD5 check (Score:4, Informative)
Since Gentoo has a ports-style package management system, perhaps it does something similar.
Re:BSD ports tree required MD5 check (Score:3, Informative)
Re:BSD ports tree required MD5 check (Score:3, Informative)
be aware of what you are checking.. (Score:5, Informative)
If there is a PGP signature, but it is from an untrusted key, that is no better than a MD5 sum. Anyone can create a PGP key with any name on it and upload it to the public keyservers. The real authentication comes from the web-of-trust. Of course, there are some mitigating factors.. like having the author sign with the same key for previous releases and then you notice that the key has changed. That can help, but only if you are vigilant.
The web-of-trust is the real important factor here. If you are a software distributor, try to get your keys signed by multiple people in the well-connected group.
If you are a software user, see if you can find a key that you trust enough to sign it.. either by a face-to-face identification verification (with a signature that you can upload to the keyservers), or by using a well-accepted key in the well-connected set and signing it LOCALLY (so that it doesn't get uploaded to the keyservers and pollute the trusted set for other users). Something from the top-50 signed keys [kjsl.com] would be suitable:.
Sites like biglumber.com [biglumber.com] maintain a list of people interested in key signings in different localities. This is a big help in getting some signatures and connecting yourself to the well-connected-set of keys.
Also, if you want to check the path of trust between two keys, check out the PGP Pathfinder [earth.li]. An example is the path from Werner Koch (GPG author) to Phil Zimmerman (PGP author) [earth.li].
This will enable you to build up your web-of-trust, which really indicates that the keys belong to who they say they do. PGP is your friend, use it wisely.
-molo
Slackware packages.. (Score:1)
-K
It's not the trojans that worry me (Score:4, Insightful)
The web of trust (Score:4, Insightful)
Mediocre solutions (Score:5, Informative)
This is a best-case scenario with MD5sums, and even a best case is pretty worthless. Debian up until very recently has relied on MD5sums, which are little more than a false sense of security. Yes, if the person who uploads a trojaned package forgets to update the MD5sum that goes along with it, you will know. The problem is they won't forget, they will update it, and you won't know what hit you. The advantage comes when you download the MD5sum from another site like they recommend here. Not only does the attacker have to break a second site's security (assuming they can't just break it once higher upstream, defeating this weak method of security), they have to know which site to break into to upload the MD5 to or else you will get the right one and know.
The problem is, MD5 never protected from man in the middle attacks. Anyone between you and the internet (or some kid in the next dorm room) can simply hijack your connection (dns spoofing works great, they are close and can give a response to your dns request faster than the real server, and give their own IP address). Then once you are connected to them, they just become a transparent proxy for the site you are supposed to be using. Your software updater asks for a package that the attacker has pre-prepared, sends that instead of what you expected, and when you ask for the md5 (no matter who you ask) they pretend to be the source and give you the hacked MD5. Using MD5 for security like this is like eating leather when you run out of food. It is not acceptable.
So what is? PGP? Yes and no. PGP allows you to trust that a developer believes that their binary and source are good. What if that developer has been trojaned? Well, I guess everybody else who uses that software is too. Look at the recent debian hack. If the exploit the attacker used worked on 64-bit systems, the main machine that signs and distributes compiled binaries would have been hacked. Great, now we have PGP signed trojans. Clearly using PGP does not make you bulletproof.
So what do we do? I know many will be happy with nonsense like "nothing is perfect", hell, people used to argue against encryption on those grounds on the debian mailing lists. The argument went like this. People know that MD5 is insecure, so it keeps them on their toes, but people think PGP is perfect and might get lazy. Uh huh. Lets keep the system broken so that we know there is at all times a gaping hole in our system that would make the goatse man jealous.
Here is what I think we should do. First require developers to sign their source code before release. That is just a first step. Second, have many reviewers. Lots of people read patches before they apply them to be sure that there are no back doors. These people should also sign the patches. Once there are enough signatures on source saying it is good, a distributed compilation takes place. Again signatures are compared, this time of the binaries (or a tarball of them). Yes there will be a few complications, the compiler systems will need to be similar enough to produce exact code, or the insignificant portions of the binary can be ignored in the checksum - whatever, we can handle that problem. As long as everyone uses the same version of GCC, or it is at least specified which one was used (and which switches were used for ./configure) there can now be many signed binary packages that are practically as transparent as the source code.
Who trusts who might seem like a big deal, but really it isn't. Debian can require that the source code is verified by certain people before being compiled, and the binaries signed by certain people before official distribution. The NSA will likely choose completely different people to check source code, and have their own compile farms. Who will I trust? Well put it this way. I would want to know what both Debian and the NSA have to say, especially if they disagree. I will listen
Simple... (Score:2)