Proposal: Secure Key revocation for APT repositories
Keys are usually delivered in keyring packages, and a repository
is signed with one or more (sub)keys. In the event that one of the
signing keys is compromised, an attacker will be able to continously
serve a repository with the compromised key, until the user updated
and upgraded their keyring packages once (or the repository uses
key pinning and removed the (sub) key from the list of allowed
keys).
If private key and Release file are on the same host, compromising
the key and compromising the Release file is essentially the same
and there is no way for repository owners to revoke the key until
they regain control of the machine. Also, single compromise of a
real machine allows an attacker to later MITM everyone else by
once crafting a Release file without a Valid-Until field (AFAIK).
# Proposal
What we essentially need is a out of band way to signal key
revocation. My idea is the following:
A new Release file key, called Key-Revocation-List is added. This
field contains a http(s) URL (and https URIs has its advantages,
but some users do not want to enable the TLS stack, so it probably
has to be http-only in practice).
At the URL, an inline signed GPG file is available. It is like
a Release file, but only contains the following keys:
* Date
* Valid-Until
* Signed-By
* Revoked-Keys
The signed-by field should be a different set of (sub)keys than
the one used to sign the repository - it describes the keys used
to sign the key revocation list file, they should be kept offline
(whereas the repository keys are usually online). Alternatively,
it probably makes more sense to move the Signed-By into the
Release file as Key-Revocation-List-Signed-By, so we do not
need to distribute a KRL if no key has been revoked yet (on the
other hand, we probably don't want it to ever 404, that could
cause issues).
The revoked-keys file is a multiline field. The ": " shall be
followed by a newline, and then each line shall be indented by
one space and contain the fingerprint of a subkey that is revoked.
# How to use it
Before updating a repository, we first update our copy of the
revocation key file URL.
When fetching the release file of a repository, we consult the
KRL file and ignore any valid signature for any subkey listed
in the KRL file.
# Related
This is somewhat inspired by the multiple keys/roles in TUF, but
TUF does not provide a solution to our problem of key revocation
(where the keys used to sign the repository data are always
online).
--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
| Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline'). Thank you.
Reply to: