package signing infrastructure
Wichert, Ben and I had some conversations in Atlanta, amongst which
was package singing. I told Wichert I'd write up what we more or less
came up with, and the corresponding design.
The basic idea is that dpkg should include a verifier for a general
purpose policy description language, and we were thinking of using
SPKI/SDSI [1]. There's an free implementation of this by Carl Ellison
[2] [3], and we were thinking of using that.
Doing this will make it possible for us to improve our public key
infrastructure &c without having to distribute updated versions of
dpkg. Instead, there would be some root keys included with dpkg (or
configured locally, for other package sources) which would specify
both the policy and to delegate to the actual keys used to sign
packages.
(Unfortunately the web page where Carl Ellison distributes his
implementation hasn't caught up with the US export control
relaxations, so I wasn't able to obtain the actual source code. So
I'd be grateful if someone in the US would do that and then go through
the necessarily formalities to get a copy of the bare source on
non-us, or mail it to me here, or something.)
It's also clear that we're going to have to have one PKI
intfrastructure and policy description per package origin. So, for
example, you'll still have to sign packages you generate locally, but
you can put the keys you use directly into dpkg's configuration file
containing the list of top-level keys, so that you don't need to copy
Debian's infrastructure.
If you want to download packages from a third-party (the KDE site, to
take an example), and have them install without warnings, you'll have
to install the KDE people's root keys, and those keys get to specify
their own PKI structure.
Likewise, a `downstream' distribution can add their own verification
keys.
The root verification keys used should be determined by the claimed
origin of the package, and if the verification does not succeed then
dpkg will issue a warning, and by default not install the package.
Wichert asked me to write down a proposed initial PKI structure, so
here it is:
PROPOSED INITIAL PACKAGE SIGNING PKI
Objectives:
We want to reduce the risk that end users will install the wrong
packages - either modified or trojanned ones, or the wrong versions.
There are various parts of this task that are very hard -
particularly, ensuring the integrity of the maintainer's system and
their key, and ensuring the integrity of any centrally-maintained
services. We want to try to mitigate these risks, though we can't
eliminate them.
We are only going talk here about binary packages, and only about
integrity from the point they are built to the point they are
installed. The problem of ensuring that the right source code is
used is also interesting, but we won't tackle it yet, and the problem
of ensuring that the source is accurately translated into the binary
is very hard, so we won't address that either.
Proposal - generics:
1. Each origin has one or more root keys. The policy specification
for the origin will be configured into dpkg's (and related programs')
configuration, and will be a k-out-of-n of the origin's root keys.
2. Each origin uses SDSI's usual signature delegation mechanisms to
sign packages or delegate to other keys.
Proposal - Debian origin signature policy:
A package is to be installed on an end-system if:
* It was signed by a maintainer;
* The maintainer's key comes with a cert from new-maintainer
(and the cert was not expired at the Distribution Date[1])
* Either
- A Packages file, signed by dinstall no earlier than the
Distribution Date, mentioned this package by name and checksum;
- There is a certificate from dinstall saying the package was
made part of one or more distribution(s), no earlier than the
Distribution Date)
The Distribution Date is a date which must be presented to the user
for approval; the signing process attempts to prevent an attacker from
forcing the system to install packages which were made obsolete before
that date. Usually it will be the date of the signature on the
relevant Packages file(s). (This is to make it possible to install
from a 3-year-old CD.)
When dinstall installs a package it must still enforce all of the
policies it usually does; in particular, it should still check that a
package is signed and a maintainer's key is valid when a package is
installed.
* There will be three root keys, which will be kept securely by three
different people, preferably on kept-disconnected laptops. We
should start with a lax policy for managing these keys to get
faster deployment, and then improve the security of these keys with
time. The root policy will be 2-out-of-3.
* When we significantly improve the security of root keys (or indeed
any keys) we should generate new keys. In the case of root keys
the old root keys will delegate to the new ones, to allow
newly-signed packages to be installed on old systems.
For Future Discussion - Debian origin policy enhancements:
* There should be a fast-track to revoking a maintainer key, and a
maintainer (or others?) should be able to revoke a package.
* Online revocation ?
* When we have package pools, do we want a separate `secure' system to
enforce the package pool migration / time delay process ?
Implementation:
I haven't mapped this to SPKI yet. When we have a relevant
implementation sort-of-working is the right time to do so.
Ian.
We haven't been able to look at
[1] IETF WG: http://www.ietf.org/html.charters/spki-charter.html,
see also RFC's 2692 and 2693.
[2] http://www.toc.lcs.mit.edu/~cis/sdsi.html
[3] This contains RSA, and we want to use RSA anyway, so we have to
wait until September for deployment (due to the RSA patent). I don't
think this will be a problem :-).
Reply to: