Re: Bug#540215: Introduce dh_checksums
Frank Lin PIAT <fpiat@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: