Re: Proposal: increasing mirror security
Jason wrote:
>
> I would prefer to use the idea of a trusted site (like ftp.debian.org) to
> fetch package file MD5 summs from, that way we do not get involed with the
> sticky issue of cyrpto hooks.
What about:
1. Every package already contains MD5 checksum.
2. Each section contains two new files. The first is a list
of (package name, checksum, signer, signed checksum).
The signer would be the packager, who presumably already has
PGP/GPG. The packager, in turn, would normally be the package
maintainer. But this isn't necessarily always true, to the
system needs to be flexible enough to handle a more general case.
The second file is list of (signers, public keys). With
offical packages, this list is already published in a package --
something which must be considered "dirty" until we find some
other way to verify it. However we *could* sign this list by
a trusted public key which is available from a canonical site,
e.g., ftp.debian.org. This key should rarely change, so people
will rarely need to ping the site.
Authentication is then fairly simple:
1. Verify we have the current top-level public key, or download it.
2. Verify the signature on the list of signers with #1.
3. Verify the MD5 checksum signatures for each package with #2.
4. For each package, verify that the three MD5 checksums match.
(Signed checksum, package checksum, and computed checksum).
This system has several benefits:
1. It eliminates the chokepoint of checking ftp.debian.org for
all signatures and/or checksums. It's entirely self-validating
once you have that particular trusted key.
2. It only requires signatures by two parties. Packagers,
who are presumably entering their pass phrases already,
and the list of signers. That list would only change as
maintainers are added or change their keys.
3. If you allow multiple top-level signers, it can support
packages which use .deb format but aren't offical debian
packages. E.g., I've created "debian" packages at work
to manage internal tools used by my employer. These companies
were small enough that everyone who used these packages knew me
and could easily verify the package, but that's not true in
many packages.
> and it requires that the clients
> know exactly which key to expect so changing keys becomes difficult.
More precisely, they need to know who did the signature. Propogation
of changed keys is a separate problem which must be addressed in any
protocol.
> We are not very vunerable to the sort of attacks we have heard of, someone
> could go onto a mirror and could change a file and change the Packages
> file but they would have to do that every single day!
But how many people will download the packages in the meanwhile?
Bear Giles
bgiles@coyotesong.com
Reply to: