Proposal: Implementing signing process for official tarballs (try #1)

[Joanna Rutkowska]

For background discussion see this thread on kde-devel:
http://lists.kde.org/?t=127479320200006&r=1&w=2

I. The Incentive
=================

Digital Signatures can prove that a given file is authentic, i.e. that
is has been indeed created by a person that signed it (e.g. KDE release
manager), and that its contents has not been tampered since then.

Digital Signatures do *not* prove any other property, e.g. that the file
is not malicious. In fact there is nothing that could stop people from
signing a malicious program, and it even happens from time to time in
reality.

The point is, of course, that people need to choose to trust some
vendors, e.g. Linus Torvalds, Red Hat, Ubuntu, KDE, etc, and assume that
if a file(s) was indeed signed by those individuals, then indeed it
should not be malicious and buggy in some horrible way. But the decision
of whether to trust certain people (e.g. those behind the KDE Project)
is beyond the scope of digital signatures. It's more of a sociological
and political decision.

However, once we make a decision to trust somebody (e.g. The KDE project
and the files released by them), then digital signatures are useful,
because they make it possible to limit our trust only to those few
people we chose, and not to worry about all the Bad Things That Can
Happen In The Middle between us and the them (i.e. the vendor), such as:
server compromises, dishonest IT stuff at the hosting company,
compromised routers, attacks on insecure DNS protocols, "last mile" WiFi
attacks, etc.

If we verify all the files we download from the vendor, we don't need to
worry about all the above bad things, because we would easily be able to
detect when the files have been tampered (and not execute/install/open
them).

II. The Proposed Scheme
====================

I will use the term "release manager" to describe a person that creates
and uploads the official, stable tarball with the KDE core software,
such as the tarballs available here:

ftp://ftp.kde.org/pub/kde/stable/4.4.3/src/

Each release manager should generate their own GPG signing key (with a
validity of, say, 1 year) and use it for creating detached GPG
signatures for each released tarball package. The signatures should be
published on the same ftp server, where the tarballs are published.

There should also be one ore more "master signing key" that would be
used only to sign keys of the approved release managers.

The master signing key should ideally be generated and kept on a
dedicated machine, disconnected from the network. In reality, it might
be reasonable to create a dedicated server with limited SSH access to
keep the key there and grant only few "master key admins" access to that
server.

The biggest organizational challenge would probably be how to choose the
"master key admins", i.e. the people that have unlimited access to the
master signing private key. To chose such people, we should ask a
question who really leads the KDE project? Who has the power to e.g.
modify the front WWW website, who accepts the long-term development
road-map, etc. Perhaps the community could vote to choose, say three,
people that would become the master key admins?

It might be also desirable to have several master signing keys, for
different KDE software. E.g. one key for the "core" packages (kdelibs,
kdebase, etc), other keys for other, more optional software, such as
kdegames, kdevelop, koffice, etc. The idea would be that the policy to
sign developer's keys with the "core" master key would be more
conservative, than for other keys (a backdoor in a core software has
dramatically bigger impact).

The public portions of the master signing key(s) should be published in
several locations, e.g. on the kde.org website, sent to some mailing
lists (e.g. kde-devel), and also uploaded to one or more PGP keyservers.
This should create a reasonably secure key distribution method, allowing
users (KDE packagers) to verify digital signatures authenticity with
satisfactory level of trust.

III. Trusting the Release Managers and the community
======================================================

For the whole scheme to make sense, we should trust release managers.
The release manager should be responsible for ensuring that the tarball
he/she creates and signs matches the code that is in the subversion
repository (e.g. the release manager should not silently add extra code).

It would be naive to expect that the release manager can review all the
commits and find all potentially malicious/buggy code. This is simple
not possible. Instead, the release manager trusts the development
community, and that the community would spot potentially malicious
commits during the development process. (If the community was unable to
spot malicious commits, the project would be losing credibility, and
people would stop trusting the software it releases, even if everything
was properly signed).

The release manager should, however, in his or her best interest, have a
reliable method to verify that the sources he or she checks out from the
repository is indeed the same software that the community has put there.
This means the release manager should be able to detect a situation when
the software in the repository has been compromised, e.g. because the
attacker has gained unauthorized access to the machine where the
repository is kept. Or that somebody is running a targeted
Man-In-The-Middle attack against the release manager, who perhaps uses a
plaintext connection to retrieve the sources from the repository.

How release managers would ensure integrity of the software they check
out form the repository is probably a subject for another discussion.
I'm not an expert on Subversion, so I would expect others to dicuss it.
In case of other version control systems, such as Git or Mercurial, it
is possible to digitally sign individual commits, which is a good way to
solve this problem.

It's expected that those release managers that would be doing their job
poorly, e.g. letting some malicious code to slip through, would be
loosing credibility over time. So, a more security conscious users
(system builders) might choose not to incorporate the packages that are
signed by less creditable release managers. The KDE project might also
spot such release managers and decide not to sing their future keys with
the master signing key (as hinted earlier, typically each developer's
key should have a validity of say 1 year only).

IV. Alternative Approaches
===========================

Sometimes people advocate alternative approaches to ensure file
authenticity. They are discussed below, together with explanation why
they are inferior to digital signatures:

1) Publishing the files via HTTPS or SFTP
-------------------------------------------

This allows to eliminate all the attacks "In the Middle", such as
compromised routers, "last mile" attacks on the WiFi, attacks on DNS
protocols, etc. But an attacker (or malicious employee at the hosting
provider) can still subvert the files on the server, without the
community knowing about it (e.g. no signs in the commit history).

2) Publishing MD5/SHA1 hashes of the files
--------------------------------------------

If the hashes are published on a plain HTTP website, than there is
likely no security benefit at all, because the attacker that already
managed to subvert the tarballs, in most cases would also have the
ability to subvert the contents of the HTTP website that displays the
hash (e.g. in case the attack is placed somewhere in the middle).

If the hashes are published on the HTTPS website, than this solution has
exactly the same security advantages/disadvantages as if we published
the whole tarballs files via HTTPS (see above).

Regards,
joanna.

-- 
Joanna Rutkowska
Invisible Things Lab, The Qubes Project
http://invisiblethingslab.com/
http://www.qubes-os.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 226 bytes
Desc: OpenPGP digital signature
Url : http://mail.kde.org/pipermail/release-team/attachments/20100526/6344dd12/attachment.sig