[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

> 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

Reply to: