Frank Lin PIAT <fp...@klabs.be> writes: > On Mon, 2010-03-08 at 12:59 -0800, Russ Allbery wrote:
>> 1. Strengthen the integrity check so that it could potentially be useful >> for security purposes as well as for simple integrity checking. > Yes, this is the intended goal. Imagine the following scenario: > 1. You boot a trusted device with Debian Live or D-I > 2. A helper mounts the root, usr and var partitions of the inspected > system > 3. It then fetches the list of installed package and version > 4. It then fetches the list of signatures for the installed system, from > your trusted mirror. > 5. Then it validates the installed files on the inspected system. > 6. You just have to trust one GPG key (per repository). > All that relies on the current infrastructure and chain of trust > (Repository's Releases.gpg->Packages.gpg->checksum). Alternatively, what > I am currently doing is to periodically export my md5sums to a trusted > system. The missing link, in this validation scenario, is how to get a signed copy of the MD5 checksums of the files in the package. If that package is still current, you can get this by downloading and extracting the copy of that package from the Debian archive and examining the MD5 checksums in it, but of course if the package is still current you don't even need MD5 checksums. You can just compare the files directly with the files you have. Hence, adding a stronger checksum doesn't really help, except possibly for some minor convenience. > It would be much easier if a signed list of check-sums for current > packages in our archive were published (basically, when we create > Packages.gpg, we would need to extract the checksums contained in those > packages, then sign it. This list could also included the recently > updated packages, which is useful for point-releases, and unstable). Yes, this plus a repository for older checksums for packages that are no longer current would be required to let this work as an audit. (It's common in practice for not all packages on a system to be at the latest version.) But if you instead put a PGP signature directly in the package, then you can always verify the package regardless of whether it's current or not provided that you still have the original package (in /var/cache/apt, for instance), which is why this is superior to using a hash. Not to mention that the infrastructure you describe for publishing signed hashes doesn't really exist and you have to download the full package. >> If we take option 1, going to a stronger hash is strictly less useful >> in every respect than going to embedded PGP signatures > Can you elaborate? checksums are currently signed, no? No, the MD5 checksums currently included in packages aren't signed. The package as a whole, which includes the checksum, is itself checksumed, and that checksum is included in Packages, which in turn is signed. So we have validation of current packages at time of installation. But as soon as that's no longer the current package (which happens all the time in unstable and testing, and happens in stable with new point releases), we lose that signature because it depends on the current Packages list. > I see some problems with signed packages: > 1. Software developers and vendors will start distributing standalone > binary packages, and pretend they are "safe" because they are signed. > This is not safe: only an APT-like mechanism provides security > updates. Well, it depends on how you define safety. The signed package is now verified to come from the package signer, which is indeed more safe. Having ongoing security support is a separate problem. I see this as a feature. It lets one distribute and install packages with verified origins without needing to set up a full apt archive, which a lot of people find tricky to do properly. > 2. You still need an infrastructure to publish valid packages version. I don't think we do. > 3. What do we do when we want to change a GPG key? we re-sign all > the packages, probably breaking existing packages checksums? Key change is a problem, yes, but note that an expired PGP signature is still stronger in all respects than a SHA256 hash, given that you can always ignore the signature part completely and just verify the hash. (Assuming the signature uses a reasonable hash, of course.) So while this is a problem, it doesn't pose any worse of a problem than just having the SHA256 hash does. > Last but not least: > 4. How long is it going to implement it? Does it seems realistic to > implement your proposal before Squeeze +1 (or event Squeeze +2)? > What do we do in-between? Use MD5. My point is mostly that it's not clear to me SHA256 is any better than what we have now for the problem that hashes are capable of solving. >> If we take option 2, SHA256 offers no benefits over MD5 and just takes >> longer to compute. > Why is that everyone seems to move away from MD5? Because MD5 is not sufficient protection against an attacker. It's possible to create two documents with identical MD5 hashes, which means that you can't rely on signatures and verification based on MD5 when the goal is to protect against an attacker aware that you're using MD5 and intentionally attempting to break MD5. (That being said, I believe MD5 preimage attacks, which is when you have a known file and hash and are attempting to come up with a second file with the same hash, remain an unsolved problem. The MD5 attacks to date are collision attacks, not preimage attacks. Preimage attacks are considerably harder. So the peril of using MD5 is frequently overstated by people who don't analyze whether a collision attack is relevant or a preimage attack is required.) >> There is essentially zero chance that random file corruption or typical >> local modification will result in a successful MD5 preimage attack. > An attacker has plenty of time to pre-compute a valid replacement for, > let say, a library in Debian Stable. The existing system is not a security mechanism and doesn't defend against an attacker. That remains true with SHA256 in many cases as well, however, since we aren't publishing a canonical source of the SHA256 hashes either. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3zea1fu....@windlord.stanford.edu