Re: [gentoo-dev] Redux: 2004.1 will not include a secure portage.

[Paul de Vrieze]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 25 March 2004 02:45, Robin H. Johnson wrote:
> OK, after reading this entire thread, I've been thinking about a
> usable implementation from both the administrative and developer
> perspective. One of the most important things to remember in designing
> this, is that while you can prevent damage from most individual
> attacks, no system in existence can withstand a multi-faceted all-out
> assault.
>
> Goals:
> ------
> - protect against compromised developer box / rogue developer
> - protect against compromised rsync server
>
> Required operations:
> --------------------
> 1. add a key to trusted list
> 2. remove a key from trusted list
> 3. verify that a package has not been tampered with
> 4. sign a package
5. Make sure that people do not have an old trusted list which has
   compromised keys on it
6. Ensure that a compromise of the key(s) signing the trusted list can be
   handled without requiring users to build up the trust from start.
7. Handle a case in which a developer leaves the project (and his key
   removed from the list for signatures after some time) without
   invalidating snapshots that legally contain signatures from him/her.

>
> General idea:
> -------------
> we have a list (single file) distributed via rsync with all of keyids
> known good for signing manifests. this file is must also signed, with
> at least one (two or three required for more security) master key that
> has it's public part widely published and it's private part kept
> secure. the verifiable signatures on the trust list make it trusted.
> The signature for the list should be available individually so that it
> can be checked frequently by portage for changes (and if it has
> changed, download the list again). Some other users have suggested
> using expiry times in various ways but that ignores the fact that a
> portage tree snapshot taken in a known good state remains in that
> known good state until altered.

For rsync we want to verify at *sync time* that the list has a recent 
signature. While a second channel can increase security, I think relying 
on it is wrong. Because of that if the signing key has a lifetime of a 
day it would mean that the rsync list will become invalid after this 
day. To make sure that the repository on the local machine will stay 
valid we can have portage add a local signature of list that verifies 
that the list was valid at the moment of syncing. (or without a 
signature verify that the time of the last sync was within the validity 
time of the key)

The lifetime of the signature on the list is needed for the following 
case:
- - The hacker has access to an rsync mirror
- - The hacker has access to the private key that is on the list
- - The hacker can do a DOS on the second channel (or has access to it)

As the hacker has access to the rsync mirror he can prevent updates of 
the list that would invalidate his key.
As the hacker can perform a DOS on the second channel a user cannot know 
that the second channel signature on the list has changed.
The private key is used to sign malicious code that compromises gentoo 
machines (that can be used in the DOS)

> Signing a package:
> ------------------
> manifests are signed as clear-text INSIDE the Manifest file (my
> prototype already did this). this is important not to bloat the tree
> with more files. This also allows multiple signatures on a Manifest
> (basically it just nests). add a command to repoman, 'repoman sign'
> that signs a manifest and have repoman commit check that a valid
> signature is present before committing (and automatically does the
> sign stage on commit if required).
>
> to add a key to the trusted list:
> ---------------------------------
> 1. add keyid into list
> 2. resign modified list with all required master keys
>
> to remove a key from the trusted list:
> --------------------------------------
> 1. remove keyid from list
> 2. resign modified list with all required master keys
>
> to verified that a package has not been tampered with:
> ------------------------------------------------------
> 1. read in manifest file, check that the signature(s) are valid.
> 2. grab the keyid(s) that it was signed with, and compare them against
> the trusted list (and optionally a LOCAL list for users to have their
> own trusted key structure)
>
> users can specify how many signatures a package needs to have for them
> to trust it, eg a really paranoid user may require each manifest has
> at least 3 signatures.

This is all correct. My only concern are the keys used for signing the 
trusted list. My opinion is that the only strategy for the list of 
trusted keys is that it should become invalid unless something is done. 
This could indeed end up in a DOS on users, but it is to be preferrable 
to having a blockage end up in compromise on users.

For packaged snapshots (tarballs of portage trees, like used with 
emerge-webrsync) we can have extra signatures that verify that the whole 
tarball is valid which would then bypass the lifetime of the signing key 
of the key list.

Case 4:
The list signing key is compromised:
A security announcement needs to be made. The proposal as made by robbat2 
would require that users acquire in some trusted way a new list signing 
public key.
In my idea with a master and a list signing key (or multiple ones for 
different machines), the master key would be able to prove that the new 
list signing key is valid. As the list signing key is shortlived it 
would also be less advantageous to compromise the list.

(we could have devrel people monitor the changes to the contents of the 
list so a compromise to the list signing key is easilly detected)

Case 5:
The master key (in my proposal) is compromised:
This would suck big time. However as this master key is infrequently 
(especially with an intermediate key) used it can be secured by storing 
it on a usb key (and available to only a few people) which is only used 
when signing keys need to be signed.

> Plan for incremental implementation:
> ------------------------------------
> 1. roll out portage with a cleaned up version of my prototype for
> repoman and simple verification code for manifests ONLY.
> 2. create the trusted list and roll out a portage with support for it.

Agreed completely.

Let me lay out again what I would propose (I will not discuss signing the 
packages or verification)

- - We have a master key on a USB flash key managed by drobbins.

- - We have N monthly intermediate keys that are signed by the master key
  (so the master key would only be needed once per month)

- - These intermediate keys are distributed to N different computers.

- - The N different computers daily generate a signing key with a one day
  lifetime. Each signing key is signed by the intermediate key belonging
  to this computer.

- - The N different computers immediately after generating the signing key
  use it to sign the key list.

- - The public key of the N signing keys are made public in the tree where
  it is used

- - The secret key of the N signing keys can be forgotten immediately after
  signing the key list, so the secret keys have a lifetime less than 5
  minutes

At rsync time the following happens:

- - The client computer checks the current date/time

- - The rsync gets performed

- - The current time is recorded in a file

At list verification time the following happens.

- - The amount of signing keys is verified (in an unspecified way)

- - If the last rsync is longer ago than M days a warning is given to the
  user

- - The N signing key signatures are verified to come from the N
  intermediate keys

- - The N intermediate keys are verified to the master public key

- - The validity period of all signing keys (which are provided by rsync)
  is compared to the recorded rsync time.

- - When all signing public keys have been found to be valid they are used
  to verify the key list.

The the biggest issue is the security of the intermediate private keys. 
They need to be machine useable so either the passphrase must be stored 
on those machines, or there would to be an empty passphrase. For this it 
might be possible to use gpg-agent to ensure that access to the secret 
key file would not mean that the key would be compromised. The use of N 
different machines that generate signing keys might be a way to lessen 
this risk.

Paul

- -- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@g.o
Homepage: http://www.devrieze.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAYrqObKx5DBjWFdsRAsmJAKCyW2DG1Q9YjA1Y/9QSNZPU8+4aWACeOcDZ
KrDzFQxJjKBrO2BZ2vhz8II=
=EyxJ
-----END PGP SIGNATURE-----

--
gentoo-dev@g.o mailing list