[gentoo-dev] Signing everything, for fun and for profit

[gentoo-dev] Signing everything, for fun and for profit

[Patrick Lauer]

[-- Attachment #1: Type: text/plain, Size: 9588 bytes --]

Hello all,

I flood you again with a looooong email. Apologies to all that don't
want to read so much, but it is a problem of rather high importance that
has not really been fixed, and the first discussions happened in 2003 as
far as I can tell. Time to FIX IT!!!

The problem, in short, is how to handle the checksumming and signing of
gentoo-provided files so that manipulation by external entities becomes
difficult. I expect many disagreements on the "best" strategy to
implement, but I hope that a sensible compromise will be reached so that
this can finally be implemented.

All the lazy people may stop reading here ;-)

Short overview:
The Problem
The Attacker
Defending
Policies and open problems



The Problem:
============

A malicious person could modify the files provided by Gentoo to 
manipulate and take over the computers of Gentoo users. To avoid such 
problems all files provided and used by Gentoo need to be identifiable 
as "correct" - we need integrity checks.

An attacker should not be able to easily circumvent these checks. There 
are some attacks that can't be prevented, so we also have to see the 
practical limits of any scheme we define - for example an attacker
could 
be a Gentoo dev with full access to all ressources, stopping that
person 
will be more difficult (if not impossible) than stopping a random
script 
kiddie that hax0rs a distfile mirror with a 0-day exploit.

The files
=========

There are two groups of files at the moment that need to be secured:
- distfiles: The large archives of source code and binary blobs from 
which we install a package
- "the tree": metadata, ebuilds and patches containing all the 
information to manage the local software installation.

The default distribution methods are rsync for the tree and http/ftp
for 
distfiles. As there are too many users for a single server theservers
are 
provided by external contributors and are not directly controlled by 
Gentoo. In almost all cases a fallback to the original download
location 
of a file is provided.

The Attacker
============

Any security policy has to take into account how strong an attacker is. 
For example securing against your grandmother with checksums signed by 
multiple independent persons is most likely overkill. A simple checksum 
would most likely be enough there.
On the other end of the spectrum we have aliens that can crack any 
encryption scheme in roughly two minutes, obviously we can't do
anything 
to really stop them.

What attackers are then reasonable?
- the script kiddie that takes over one single mirror
- a large multinational monopolist that tries to sabotage any potential 
competitors
- a mirror operator that has a bad days and manipulates files for fun
- a really strong hax0r that takes over the Gentoo CVS server
- a social hacker that takes a dev hostage and forces that dev to
insert 
evil bad data

This is by far not a complete list, it should only help with figuring 
out what can go wrong.

Now let's classify the attackers:
* local attacker ("your roommate") - nothing we can defend against,
your 
responsability.
* single compromised mirror - only with checksums can this be found. If 
the checksums are distributed on a different path than the distfiles 
a single compromised mirror has a very low impact as checksums don't 
match.
* compromised rsync mirror - now the checksums can be forged. The 
attacker will have to change the SRC_URI too so that only the 
compromised distfiles are transferred. Also changes in the ebuilds must 
be considered - a "rm -rf" in the right place in an ebuild will have a 
large impact and can't be caught with checksums (since those could be 
forged by the same attacker). We need signed checksums here.
* compromised developer - this is hard to detect, but once detected all 
files involved can be checked and corrected. The impact of this is very 
high, it is very difficult to avoid. (So we just assume that no dev
will 
go berserk and look for low-impact methods that allow us to clean up if 
that ever happens)

Note: a possible defense against rogue devs would be multi-signing, i.e.
having all commits checked by at least one other person. This does not
help much as there can be collusion between devs and the impact on all
devs is very high. It would effectively deadlock Gentoo and prevent any
useful progress.

Defense methods
===============

1) Checksums
A Checksum is a one-way function that returns a constant-length 
identifier. The checksum is designed so that changing one bit in the 
input totally changes the output (quite simplified, but that's all that 
matters). Thus any changes to a file lead to a bad checksum, finding a 
collision (two files with the same checksum) is hard.
Some checksum algorithms have known weaknesses, so relying on a single 
algorithm is not advised. For example MD5 suffers from precomputation 
attacks where one can generate two files with equal checksums (but it
is 
not possible to find a matching second file to a given file).

2) Signatures
Using GPG it is possible to sign a file. The signature is similar to a 
checksum, but it can only be created with a private key that is kept 
secret. The public key allows to verify this signature. Deducing the 
private key from the public key is hard to do. (very simplified)
The public key is provided online, in a keyring (collection of keys) or
included in the downloadable media. If the public key is trusted it can
be used to verify that all files have a correct signature, effectively
saying that the files are exactly the same as the ones committed by a
dev.

Some readers may point out that it doesn't prevent a dev from injecting
"bad" files and sign them, but this prevents tampering by external
parties. 

3) Manifest / Manifest2

This is an implementation of a checksum / signature scheme. It is
described in GLEP 44:

http://www.gentoo.org/proj/en/glep/glep-0044.html

Right now SHA1, SHA256, RMD160 are the default checksum algorithms

While manifest2 should take care of all executable bits in the tree it
does not yet cover eclasses and profiles. As long as this is not taken
care off any attacker can just override an eclass on the rsync mirror or
modify the profiles. This has a severe negative impact on signing
effectivity.

Any "good" solution should sign all data files in the tree, so I ask for
an extension of the Manifest2 protocol to include _every_ data file with
no exception.

Key policies
============

To make signing relevant and verifiable all devs should use the same
parameters - key length, key type, validity.
Once that is agreed upon a key distribution strategy is needed so that
users can get the key(s) on a verifiable path.

Signing strategies
==================

Once there is an agreement on what files to sign with what kind of keys
there remains the question how to sign it. There are at least three
strategies:

Method "simple":
----------------

Use one central key that is kept on a secure box. Signing is done 
automatically after a commit. The key distribution is simple since
there 
is only one key that has to be pushed.
Problems are security (single point of failure, single target for 
compromising)

Method "complex":
-----------------

Let every dev sign the files he adds or modifies. A keyring is 
maintained on gentoo infrastructure and is distributed over multiple 
paths.
Problems: Need support for multi-signing. If one file is added the 
manifest should not be only signed by the last editor, only the change 
should be signed. At the same time it needs to be kept simple and fast, 
ssigning each file on its own or keeping infinite history must be 
avoided. Keyring managment needs to be defined. Key revocation etc. 
needs to be defined.

Method "hybrid":
----------------

Let every dev sign, add automatic server-side signing with a master key.
Gives you bits of both. Normal users can trust the master key.
Paranoid users can trust the dev keys.


Earlier Discussions:

http://article.gmane.org/gmane.linux.gentoo.devel/16876
2004.1 discussion

http://www.gentoo.org/proj/en/devrel/manager-meetings/logs/2004/20040531.txt
manager meeting

Some selected problems from there:

* Access Control Lists could be used so that only toolchain people can
commit to glibc. Do we want that level of micromanagment? Does it offer
any security benefits?

* key revocation may be impractical - what methods for handling retired
devs and rogue devs are there?

* how to verify from an install  CD ?

* in tree or out of band? Storing the keys in the tree is easy, but a
potential security problem

With this I hope to get the discussion started. There are many areas
where I am unsure what is the best strategy - every decision has obvious
disadvantages, either security, code complexity or developer workload.
Any solution should try to keep the workload low while offering the
highest level of security that does not halt all progress.

I hope that discussion can stay focussed on the implementation aspects.
When you suggest something (for example multiple signatures) please
explain what it gains us (protection against single rogue devs) and at
what price (having to sign everything by at least two persons). That
should make it easier to see if the workload impact of that idea is
worth it.

Take care,

Patrick

-- 
Stand still, and let the rest of the universe move

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Signing everything, for fun and for profit

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 2391 bytes --]

On Thu, 18 May 2006 23:45:17 +0200
Patrick Lauer <patrick@gentoo.org> wrote:

> Note: a possible defense against rogue devs would be multi-signing,

I don't think it's worth trying to defend against rogue devs.  We have
to have some level of trust amongst devs; anyone abusing that trust
will be ejected sooner or later and any breakage will be fixed.


On key management - I wouldn't get too excited about gold standard key
management.  Using the "web of trust" seems good enough to me. The
default chain depth of 5 seems enough to reach around the globe.
Publish the top-level public key(s) and fingerprint(s) on the web
server, have the secret keys held by infra, revocation certificates by
infra and council.  Anyone not wishing to trust the web server can
locate a nearby dev whose identity they can trust with a chain back
to the top and obtain the public key from that dev. Perhaps we
could take a more proactive approach to getting devs keys onto the
chain.


I wanted to mention the currently un-signed portions of the tree.
I'm sure we've discussed this before although I couldn't find it.

Unsigned bits of the rsync tree are:

eclass
licenses
metadata
profiles
header.txt
scripts
skel.*

obviously header.txt and skel.* aren't important.  scripts isn't too
important either, although a manifest-style file in there wouldn't be
difficult.  licenses and metadata don't have any security impact so
there's little point there, also.

do profiles present a security risk?  Perhaps by masking/unmasking
fixed/vulnerable versions of packages.  Here, a Manifest in each
directory seems most sensible (it might be useful to move the global
data around a bit; fex move *desc into the desc subdirectory).

eclass - not so easy.  A per-eclass detached signature would clutter
the directoryup too much, doubling the file count.  A single Manifest
for the whole directory could be awkward if enough eclass editing goes
on simultaneously, but it might be workable. I think that's where the
last discussion ended up - a single manifest for the whole eclass
directory.  If GLEP33 ever gets implemented, this issue is obvious as
each subdirectory would have its own manifest.

Obviously the best way to add this sort of thing is to add support to
repoman, which has been mentioned before for profiles at least, for QA.

-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] Signing everything, for fun and for profit

[Ciaran McCreesh]

On Fri, 19 May 2006 01:53:29 +0200 "Kevin F. Quinn"
<kevquinn@gentoo.org> wrote:
| obviously header.txt and skel.* aren't important.  scripts isn't too
| important either, although a manifest-style file in there wouldn't be
| difficult.  licenses and metadata don't have any security impact so
| there's little point there, also.

metadata has security impact.

| do profiles present a security risk?  Perhaps by masking/unmasking
| fixed/vulnerable versions of packages.

Or by using a bashrc, perhaps? Profiles most definitely do have
security impact.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Signing everything, for fun and for profit

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 13593 bytes --]

This email is a discussion on why we need to care about more than the simple
key parameters, and why - this includes things like changing the validity of an
existing key. We also need to consider: location of key (primary key vs.
subkey), expiry policies (expiries are only one element of key validity), key
signatures, and revoking elements in a key.

I've tried very hard to ensure absolutely all of the following is
completely fact, and that I have not entered any of my opinions into it,
except where I've explictly marked it as such.

On Thu, May 18, 2006 at 11:45:17PM +0200, Patrick Lauer wrote:
> Key policies
> ============
> To make signing relevant and verifiable all devs should use the same
> parameters - key length, key type, validity.
No, the simple parameters of the have little bearing on how they are used.
While we do care about them in terms of managing file signatures, some
understanding is needed first.

Introduction
------------
The following is an introduction into some of the OpenPGP standard, with a
focus on how it affects file signing, key signing, management of keys (for
the complex style listed), and revocation.

It's important as to what attacks against a key can lead to what results.

Breakdown of what is a 'key' is
-------------------------------
A 'key' under PGP/GnuPG (OpenPGP) consists of several important entities:
1. *actual cryptographic primary keys and secondary keys (subkeys) [pub/sub]
2. *user ids - one uid per email address [uid]
3. signatures, each attached to one uid [sig]
4. revocations of any of the above items [rev]
I've included the packet type name in the [] at the end.
The first two items marked with a * are the core entities, and items are
associated with only one element of them.
There are a few more packet types, but they aren't important to our
discussion.

After this point, I will use the term 'cryptokey' to refer to the actual
cryptographic keys, and the generic term 'key' to refer to the collection of
above items.

To see the various elements of the above, try this:
"gpg --list-sig SOMEDEV@gentoo.org"
If you look at my key, it goes on for a few pages (but isn't quite as
long as the Paludis thread).

The first column has the information type, and you'll see the types I
mentioned above.

Now let's focus on a single key for a moment:

# gpg --edit-key robbat@gentoo.org
...
pub  1024D/34884E85  created: 2002-08-27  expires: 2008-03-09  usage: CS  
                     trust: ultimate      validity: ultimate
sub  2048g/CA05A397  created: 2002-08-27  expires: 2008-03-09  usage: E   
sub  2048g/67592A1F  created: 2003-04-12  expires: 2008-03-09  usage: E   
This key was revoked on 2004-09-09 by DSA key 34884E85 Robin Hugh Johnson <robbat2@orbis-terrarum.net>
sub  1024D/FB33B3A4  created: 2002-08-27  revoked: 2004-09-09  usage: SA  
This key was revoked on 2004-09-09 by DSA key 34884E85 Robin Hugh Johnson <robbat2@orbis-terrarum.net>
sub  2048g/CC772FC3  created: 2002-08-27  revoked: 2004-09-09  usage: E   
sub  1024D/3233C22C  created: 2004-08-29  expires: 2008-03-09  usage: S   
[ultimate] (1). Robin Hugh Johnson <robbat2@orbis-terrarum.net>
[ revoked] (2)  Robin Hugh Johnson <rjohnsob@sfu.ca>
[ultimate] (3)  Robin Hugh Johnson <robbat2@users.sourceforge.net>
[ultimate] (4)  Robin Hugh Johnson <robbat2@gentoo.org>
[ revoked] (5)  Robin Hugh Johnson <rhj@sfu.ca>
[ revoked] (6)  Robin Hugh Johnson <robbat2@sfu.ca>
[ revoked] (7)  Robin Hugh Johnson <robbat2@hotmail.com>
[ revoked] (8)  Robin Hugh Johnson <robin@corasen.com>
[ revoked] (9)  Robin Hugh Johnson <robbat2@net-conex.com>

The important bit here is the 'usage:' bit at the end of the cryptokeys.
There are 4 letters that will appear here:
C - Certify
S - Sign
E - Encrypt
A - Authenticate

We are interested in two of these only: Certify and Sign.
We aren't dealing with encrypted data at the moment, and usage of authenticate
is not implemented in gpg-1.4.

'Certify' is the terminology used for signing uids.
'Sign' is the terminology used for digitally signing files/data.

If you attend a keysigning event, you are certifying that a uid does indeed
belong to a person (more on this in a moment, in how we can gain from it).

From this point forward, I will use 'certify' to indicate signing of a
key, and signing to indicate other data signing.

Only the primary cryptokey [pub] will ever be marked with Certify.
The primary cryptokey is used for all uid signatures made with your key.
It also protects your key itself from some modifications by attackers.

Having multiple UIDs allows a person to go over several email addresses
over time, without having to invalidate old correspondence, or identify
themselves to any given third party more than once.

Choice of Length/Type:
----------------------
Any of the cryptokeys marked with Sign will be used in signing Manifest/digest
data.
We have a few choices for these - I'm limiting this to what is implemented in
upstream GnuPG, and not anything added by external patches.
CryptoKey types: DSA, RSA.
CryptoKey lengths: 
- DSA provides a length of 1024 bits only (gnupg does not allow you to chose
  anything else without special options, and that is only weaker keys).
- RSA lengths between 1024 and 4096 bits available.

The following is a small speed comparison produced with 'openssl bench rsa
dsa', run single-threaded, and excluding the variants (DSA512, DSA2048) not
available in GnuPG.

32-bit x86 (Athlon XP)
         sign/s verify/s
DSA1024   592.2    501.3
RSA1024   264.7   5581.9
RSA2048    48.0   1763.5
RSA4096     7.6    510.1

Apple G5, Quad:
         sign/s verify/s
DSA1024  2125.7   1735.8
RSA1024  1032.4  18829.6
RSA2048   171.0   5988.2
RSA4096    26.3   1754.4

Not reflected in this is generation time for keys as that is a one time
occurrence, the time it takes is mostly irrelevant, but for the record, RSA is
several times slower for equivalent key lengths.

Note: these speeds would not be affected by the size of the data - as GnuPG
signs a hash of the data only.

There are 11k packages in the tree now, and if we assume 2 signatures per
package for the moment, that's ~40 seconds to verify the entire tree (assuming
no other bottlenecks, which is completely unreasonable) with RSA4096 on a
slower machine.

For the question of key length - I ask the security folk - what do you consider
reasonable without being paranoid?

<opinion>
It's pretty obvious in this, that RSA is slow for signing, but fast for
verifying. Unless we have a specific need for high speed signing, I'd suggest
we go with RSA.
</opinion>

Location of the cryptokey:
--------------------------
If we require that a Gentoo developer has a primary key for that is used for
signing, we lose the ability to add web of trust to our system later.

Additionally, if the developer uses the singular primary key for a lot of
stuff, it is more vulnerable to attack.

<opinion>
Instead, the developer should create a subkey that is used for signing Gentoo
work only. They should not sign anything else with this, including their Gentoo
email.

They may have an additional subkey for signing their Gentoo email if they wish.
</opinion>

Q: What are the potential downsides to this?
A: There are some older keyservers out there that do not correctly deal with
   subkeys - but this should not affect us as we are intending to distribute
   public cryptokeys ourselves.

Choosing cryptokey expiry times:
--------------------------------
GnuPG and the OpenPGP standard in general allow you to change the expiry date
on a cryptokey, after it is created. With that in mind, what does it having an
expired cryptokey imply:
1. GnuPG will not use that cryptokey for new creation actions (sign/encrypt/certify).
2. GnuPG will correctly validate/decrypt anything signed/encrypted by that
   cryptokey, provided that the data timestamp is older than the key expiry
   timestamp.

#1 is a logical behavior.
#2 protects us when data hasn't changed for a long time - but we have to be
   careful about accurate timestamps (evil can get in here).

Q: What do we actually gain from expiry times in encryption setups?
A: It would indicate to others which key to use.

Q: What do we actually gain from expiry times in data signing setups?
A: Marginal protection against attacks from large datasets that might allow
   compromise of the key, but only by encouraging us to have multiple keys over
   time. Is this really a concern? No, we aren't signing large amounts of data.

Q: Is there anything else we gain from expiry times?
A: Yes. If a practice of using medium-term expiry times, and updating them
   regularly is undertaken, the keys provide an indication of who is still paying
   attention.

<opinion>
For the last reason alone, expiry times are worthwhile, and I would like to
suggest that a period of 6 months is used.
</opinion>

Revocating of cryptokeys also has the same implications as an expired
cryptokey, with the exception that you cannot under a revocation.

Other validity elements:
------------------------
Now we lead into some more complex areas. Beyond cryptokey expiry dates, there
are several other methods for key validity. Of primary importance to us are uid
signatures.

UID signatures:
---------------
As I wrote last year, these may take several forms.
We are concerned with several properties that they may have:

Expiry dates of signatures:
Unlike expiry dates of cryptokeys, these may not be changed - by default, they
take on the expiry date of the certifying cryptokey, although a lower value may be
set. If you have an existing signature that has expired, you need to get your
uid signed again.

Revocation of signatures:
A signature may be revoked by the certifying cryptokey only.
(TODO: need to check that the same rules of validity apply here).

Trust markings:
This is not of immediate concern, but instead offers future options for the
very paranoid portion of our userbase. They can implement things like only
trusting a specific web-of-trust of developers.

Using UID signatures:
---------------------
Q: How can we use signatures to our advantage, for the hybrid or complex schemes?
1. Take the master key as defined by the 'Simple' proposal.
2. Use it to create uid signatures to each trusted developer key.
3. In verifying, designate said master key as the top level of trust (this is
   the same as the simple scheme), and verify all file signatures by developers
   as you go along.

This schema is extensible to N master keys, by telling GnuPG that it
needs signatures from M masters before data is considered trusted.

Revoking keys:
--------------
<opinion>
When a developer leaves Gentoo, he should not revoke the subkey used to
sign (indeed, he may not be able to, think being hit by a bus).
Instead, any signatures made by a valid master key should be revoked.
This ensure control remains in the hands of the keymasters (infra, devrel,
whoever).
</opinion>

Summary:
-----------
This is a brief summary of the suggestions and choices above.
This summary outline is assuming a model such as the hybrid or complex
models.

- Each developer shall have a GnuPG key.
- Each developer key shall contain at least one uid, with name and Gentoo email
  address of the developer.
- Each developer must create a secondary cryptokey with the following
  parameters (designated as their Gentoo signing cryptokey):
  Key Type: RSA
  Key Length: 2048 or 4096
  Expiry time: Set at 6 months out
  Usage: Marked as signing only.
- Each developer shall regularly update the expiry time (GnuPG enforces
  this) of the cryptokey, keeping it no further than 6 months ahead of
  the present date, except where otherwise decided.
- Each developer should have a revocation certificate for their key, and
  store two copies in a secure offline location (I suggest two CD-RWs,
  of different brands, stored in separate locations, refreshed every 6
  months, but floppy disks would work as well).
- Each developer will sign all of their commits with their Gentoo
  signing cryptokey only. They should not sign anything else, nor use
  other cryptokeys for signing Gentoo commits.
- (Optional, for those creating new keys only) a best practice would be
  to have a primary key that is marked as certifying only.

(This part here needs more discussion, which may end up that N=1 is
valid).
- There will be N master keys. 
- A master key will have a secondary cryptokey conforming to the same
  requirements as the developer Gentoo signing cryptokey.
- A master key will certify all Gentoo developer keys on a regular
  basis. This can be done on 4 month intervals safely, with once-off
  events to sign keys of incoming developers, or other special cases.
- When a developer leaves, the certification on their key shall be
  revoked.
- Both infra and the council should hold the revocation control for a
  master key in some way so that cooperation is needed to actually revoke
  a master key.

(For future stuff:)
For performing releases of Gentoo (releng), a designated key be used,
and be certified by the master key.

Outstanding points:
-------------------
- Discussion of how the keymaster(s) should operate to maintain the
  keyring.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 241 bytes --]

Re: [gentoo-dev] Signing everything, for fun and for profit

[Chris Bainbridge]

[-- Attachment #1: Type: text/plain, Size: 1764 bytes --]

The only attack most people really care about is a compromised rsync server.
There is no practical way to protect against the other attacks - and at the
end of the day, if a developer gets compromised it doesn't matter whether
it's a gpg key or ssh key, the effect is the same. The discussion about
which files to sign is pointless - the extra computational cost of signing
all files in the tree is insignificant, and how are we supposed to know how
future tools will handle things like the licenses? Just do it properly now
and sign every file.

We already trust the master cvs server admins (and they could just replace
the whole tree anyway), so what benefit does a distributed signing system
like gpg actually give to the developers or users? I can't see any that are
worth the costs of key management (and there are costs, otherwise a system
would've been put into place years ago).

So my simple proposal would be to use a single key, and a post-commit cvs
hook to sign the whole tree. It takes me 1.5 seconds with gnupg to generate
a signature covering the whole tree on my desktop here. I don't know how
many commits per day there are (and maybe that would be reduced with an
atomic commit system like svn), so I don't know if this is an acceptable
cost. I think it probably is, but if not, then signing could be done
per-directory.

The benefits of this would be that changes are minimised - developers and
users act the same, the impact on the tree is a 191 byte signature, and yet
it will protect against the most likely and most practical form of attack. I
was much more pro-distributed trust system in 2003 (or whenever this was
last discussed), but I think the right solution now is the practical, easy
to implement one.

[-- Attachment #2: Type: text/html, Size: 1767 bytes --]

Re: [gentoo-dev] Signing everything, for fun and for profit

[Patrick Lauer]

[-- Attachment #1: Type: text/plain, Size: 3214 bytes --]

On Fri, 2006-05-19 at 10:46 +0100, Chris Bainbridge wrote:
> The only attack most people really care about is a compromised rsync
> server. There is no practical way to protect against the other attacks
> - and at the end of the day, if a developer gets compromised it
> doesn't matter whether it's a gpg key or ssh key, the effect is the
> same. 
The difference is how you handle any problems. You can't avoid it, but
you can reduce the impact.

> The discussion about which files to sign is pointless - the extra
> computational cost of signing all files in the tree is insignificant,
> and how are we supposed to know how future tools will handle things
> like the licenses? Just do it properly now and sign every file. 
In theory yes.
Practically you have to find a non-intrusive way so signatures are per
file.
There are potential problems with "special" files like package.mask that
will be modified often by different people ... signing that is a bit
silly

> We already trust the master cvs server admins (and they could just
> replace the whole tree anyway), so what benefit does a distributed
> signing system like gpg actually give to the developers or users? I
> can't see any that are worth the costs of key management (and there
> are costs, otherwise a system would've been put into place years
> ago). 
No central authority --> no single point of failure

Give me a central server and I will focus on hacking that ... hacking 50
developers is much harder ;-)

> So my simple proposal would be to use a single key, and a post-commit
> cvs hook to sign the whole tree. It takes me 1.5 seconds with gnupg to
> generate a signature covering the whole tree on my desktop here. I
> don't know how many commits per day there are (and maybe that would be
> reduced with an atomic commit system like svn), so I don't know if
> this is an acceptable cost. I think it probably is, but if not, then
> signing could be done per-directory. 
I don't see what that gains you ... what exactly does this signature
express?
and 1.5sec doesn't appear realistic to me, I'd expect it to take ~1
minute even on a fast system

> The benefits of this would be that changes are minimised - developers
> and users act the same, the impact on the tree is a 191 byte
> signature, and yet it will protect against the most likely and most
> practical form of attack. 
So ... DoS scenario
I just add one byte to the tree and the signature fails ... what then? 

> I was much more pro-distributed trust system in 2003 (or whenever this
> was last discussed), but I think the right solution now is the
> practical, easy to implement one.
I think I'd prefer a hybrid.

One possibillity would be:
- every dev signs as it is done now
- post commit an automated signature from a master key is added

so the normal user can check the master signature, and the paranoid
people can use the per-dev keys.

Where I fully agree is "practical" and "low impact" - it should be easy
to use so that everyone can use it without lots of configuring. This of
course limits the complexity that we can allow.


wkr,
 Patrick
-- 
Stand still, and let the rest of the universe move

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Signing everything, for fun and for profit

[Thomas Cort]

[-- Attachment #1: Type: text/plain, Size: 520 bytes --]

On Fri, 19 May 2006 17:10:53 +0100
"Chris Bainbridge" <chris.bainbridge@gmail.com> wrote:
> Well, that would be incompatible with a single signature. I don't
> really see that point, but then I've been spoiled with broadband for
> years. Do we really have many users on dialup that it would
> inconvenience?

It doesn't only affect dialup users. I exclude all of the x11/gnustep/gnome/kde/games/xfce/... stuff on some servers I run. It cuts down a little on bandwidth, sync time, and saves disk space.

~tcort

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] Signing everything, for fun and for profit

[Chris Bainbridge]

On 19/05/06, Patrick Lauer <patrick@gentoo.org> wrote:
> On Fri, 2006-05-19 at 10:46 +0100, Chris Bainbridge wrote:
> > We already trust the master cvs server admins (and they could just
> > replace the whole tree anyway), so what benefit does a distributed
> > signing system like gpg actually give to the developers or users? I
> > can't see any that are worth the costs of key management (and there
> > are costs, otherwise a system would've been put into place years
> > ago).
> No central authority --> no single point of failure
> Give me a central server and I will focus on hacking that ... hacking 50
> developers is much harder ;-)

There are now several hundred gentoo developers. It is more likely
that one of them has a security lapse than cvs.gentoo.org.

> > So my simple proposal would be to use a single key, and a post-commit
> > cvs hook to sign the whole tree. It takes me 1.5 seconds with gnupg to
> > generate a signature covering the whole tree on my desktop here. I
> > don't know how many commits per day there are (and maybe that would be
> > reduced with an atomic commit system like svn), so I don't know if
> > this is an acceptable cost. I think it probably is, but if not, then
> > signing could be done per-directory.
> I don't see what that gains you ... what exactly does this signature
> express?
> and 1.5sec doesn't appear realistic to me, I'd expect it to take ~1
> minute even on a fast system

It is a single signature across the entire portage tree. It means that
after rsync emerge can check the signature against the retrieved tree
to validate the whole tree (or overlay).

Instead of guessing performance, test it. We can assume that disk
activity is negligible  - we have a dedicated server, and the portage
tree is ~115MB, so most of it will be cached in main memory. In
particular there is no disk seek latency. To simulate that we can
gather everything into a single file (which also has the side effect
of pulling into the cache) and then gpg sign that file:

find /usr/portage -path '/usr/portage/metadata' -prune -o -path
'/usr/portage/distfiles' -prune -o -path '/usr/portage/packages'
-prune -o -type f -exec cat {} > /tmp/blah \;
time gpg --detach-sign -a /tmp/blah

I get 1.5 seconds on a desktop and 6.5 seconds on a laptop.

> > The benefits of this would be that changes are minimised - developers
> > and users act the same, the impact on the tree is a 191 byte
> > signature, and yet it will protect against the most likely and most
> > practical form of attack.
> So ... DoS scenario
> I just add one byte to the tree and the signature fails ... what then?

Emerge informs the user that the rsync server has been corrupted and
terminates. How would this be any different with distributed file
signing? You have to rsync the entire tree, and then verify it - at
that point the tree is already corrupt. Ideally overlayfs (or just
plain old keeping a backup) could be used to restore the pre-sync
tree.

> > I was much more pro-distributed trust system in 2003 (or whenever this
> > was last discussed), but I think the right solution now is the
> > practical, easy to implement one.
> I think I'd prefer a hybrid.

It could be done in stages. Start with the (easier) central key, then
later add distributed keys. I think a hybrid system would be the ideal
system, but realistically, bug #5902 has been around since March 2003
and no real progress has been made. The main sticking point seems to
be disagreements over key management and policies. I would hope that
most people could agree that a single key with a post-commit signing
is better than what we have now, and could be easily implemented,
whilst leaving open the option of a hybrid system implementation at a
later date.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Signing everything, for fun and for profit

[Andrew Gaffney]

Chris Bainbridge wrote:
> It is a single signature across the entire portage tree. It means that
> after rsync emerge can check the signature against the retrieved tree
> to validate the whole tree (or overlay).

This idea has been brought up before and shot down. Signing the whole tree does 
not work, since we allow users to only sync parts of the tree.

-- 
Andrew Gaffney                            http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer                                   Installer Project

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Signing everything, for fun and for profit

[Chris Bainbridge]

On 19/05/06, Andrew Gaffney <agaffney@gentoo.org> wrote:
> Chris Bainbridge wrote:
> > It is a single signature across the entire portage tree. It means that
> > after rsync emerge can check the signature against the retrieved tree
> > to validate the whole tree (or overlay).
>
> This idea has been brought up before and shot down. Signing the whole tree does
> not work, since we allow users to only sync parts of the tree.

We do? What option to emerge enables this behaviour?

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Signing everything, for fun and for profit

[Patrick Lauer]

[-- Attachment #1: Type: text/plain, Size: 3649 bytes --]

On Fri, 2006-05-19 at 15:13 +0100, Chris Bainbridge wrote:
> There are now several hundred gentoo developers. It is more likely
> that one of them has a security lapse than cvs.gentoo.org.
One is a "local" bug, the other one "global".
I'd prefer a system that is resilient against two devs going crazy -
right now the "right" persons could stage a manipulation that would be
hard to detect and where your (single central) signature fails quite
nicely.

> It is a single signature across the entire portage tree. It means that
> after rsync emerge can check the signature against the retrieved tree
> to validate the whole tree (or overlay).
It's very coarse - Yes / No
Doesn't tell you what failed how ... so I DoS it by inserting one bit on
any rsync mirror and it will "fail". You don't know what fails where ...

> Instead of guessing performance, test it. We can assume that disk
> activity is negligible  - we have a dedicated server, and the portage
> tree is ~115MB, so most of it will be cached in main memory. In
> particular there is no disk seek latency. To simulate that we can
> gather everything into a single file (which also has the side effect
> of pulling into the cache) and then gpg sign that file:
> 
> find /usr/portage -path '/usr/portage/metadata' -prune -o -path
> '/usr/portage/distfiles' -prune -o -path '/usr/portage/packages'
> -prune -o -type f -exec cat {} > /tmp/blah \;
> time gpg --detach-sign -a /tmp/blah
> 
> I get 1.5 seconds on a desktop and 6.5 seconds on a laptop.
ok

> > > The benefits of this would be that changes are minimised - developers
> > > and users act the same, the impact on the tree is a 191 byte
> > > signature, and yet it will protect against the most likely and most
> > > practical form of attack.
> > So ... DoS scenario
> > I just add one byte to the tree and the signature fails ... what then?
> 
> Emerge informs the user that the rsync server has been corrupted and
> terminates. How would this be any different with distributed file
> signing?
You can't upgrade and you don't know what fails where ...

>  You have to rsync the entire tree, and then verify it - at
> that point the tree is already corrupt. Ideally overlayfs (or just
> plain old keeping a backup) could be used to restore the pre-sync
> tree.
Right, but ... what caused the error?

> It could be done in stages. Start with the (easier) central key, then
> later add distributed keys. I think a hybrid system would be the ideal
> system, but realistically, bug #5902 has been around since March 2003
> and no real progress has been made.
That bug appears quite unrelated to me ... how does FEATURES="userpriv"
relate to signing?

>  The main sticking point seems to
> be disagreements over key management and policies. I would hope that
> most people could agree that a single key with a post-commit signing
> is better than what we have now, 
debatable
> and could be easily implemented,
yes
> whilst leaving open the option of a hybrid system implementation at a
> later date.
yes

but that's not a cure. You'd have to sign _each file_ to get a
reasonable tampering detection, or at least per-directory. You add a
single point of failure and give attackers a high-profile target.

It's like security checks at the airport: It gives you the illusion of
security, it inconveniences everybody ... and it's easier for me to
smuggle a bomb aboard because noone thinks it's possible. (It's easy,
use a sidechannel attack on the baggage transports, they have bad
security ...)

Patrick
-- 
Stand still, and let the rest of the universe move

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Signing everything, for fun and for profit

[John Myers]

[-- Attachment #1: Type: text/plain, Size: 666 bytes --]

On Friday 19 May 2006 08:17, Chris Bainbridge wrote:
> On 19/05/06, Andrew Gaffney <agaffney@gentoo.org> wrote:
> > Chris Bainbridge wrote:
> > > It is a single signature across the entire portage tree. It means that
> > > after rsync emerge can check the signature against the retrieved tree
> > > to validate the whole tree (or overlay).
> >
> > This idea has been brought up before and shot down. Signing the whole
> > tree does not work, since we allow users to only sync parts of the tree.
>
> We do? What option to emerge enables this behaviour?
RSYNC_EXCLUDES is the name, IIRC...
-- 
# 
# electronerd, the electronerdian from electronerdia
#

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Signing everything, for fun and for profit

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 720 bytes --]

On Fri, 2006-05-19 at 16:17 +0100, Chris Bainbridge wrote:
> On 19/05/06, Andrew Gaffney <agaffney@gentoo.org> wrote:
> > Chris Bainbridge wrote:
> > > It is a single signature across the entire portage tree. It means that
> > > after rsync emerge can check the signature against the retrieved tree
> > > to validate the whole tree (or overlay).
> >
> > This idea has been brought up before and shot down. Signing the whole tree does
> > not work, since we allow users to only sync parts of the tree.
> 
> We do? What option to emerge enables this behaviour?

RSYNC_EXCLUDES in make.conf

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Signing everything, for fun and for profit

[Harald van Dijk]

On Fri, May 19, 2006 at 04:17:38PM +0100, Chris Bainbridge wrote:
> On 19/05/06, Andrew Gaffney <agaffney@gentoo.org> wrote:
> >Chris Bainbridge wrote:
> >> It is a single signature across the entire portage tree. It means that
> >> after rsync emerge can check the signature against the retrieved tree
> >> to validate the whole tree (or overlay).
> >
> >This idea has been brought up before and shot down. Signing the whole tree 
> >does
> >not work, since we allow users to only sync parts of the tree.
> 
> We do? What option to emerge enables this behaviour?

The PORTAGE_RSYNC_EXTRA_OPTS variable does. (Or RSYNC_EXCLUDEFROM with
older versions of portage.)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Signing everything, for fun and for profit

[Chris Bainbridge]

On 19/05/06, Patrick Lauer <patrick@gentoo.org> wrote:
> On Fri, 2006-05-19 at 15:13 +0100, Chris Bainbridge wrote:
> > There are now several hundred gentoo developers. It is more likely
> > that one of them has a security lapse than cvs.gentoo.org.
> One is a "local" bug, the other one "global".
> I'd prefer a system that is resilient against two devs going crazy -
> right now the "right" persons could stage a manipulation that would be
> hard to detect and where your (single central) signature fails quite
> nicely.

Realistically, you have to trust the gentoo devs. The only system that
won't fail against the rogue developer threat is to have multiple
sign-off on commits. Most developers don't want that. Even if it were
required, it would only raise the bar slightly - all a rogue developer
would have to do is to establish a new id, fix some bugs, and
"recruit" themselves.

> It's very coarse - Yes / No

> Doesn't tell you what failed how ... so I DoS it by inserting one bit on
> any rsync mirror and it will "fail". You don't know what fails where ...

> You can't upgrade and you don't know what fails where ...
> Right, but ... what caused the error?

It doesn't matter which bit in which file was changed - if an attacker
has access to corrupt the tree, then the whole tree is suspect and
can't be trusted. From a users point of view - they don't care what
caused the error, they just sync again with a different server.. From
a developers point of view - you can just diff the corrupt server
against your local tree and look for exploit code.

> > It could be done in stages. Start with the (easier) central key, then
> > later add distributed keys. I think a hybrid system would be the ideal
> > system, but realistically, bug #5902 has been around since March 2003
> > and no real progress has been made.
> That bug appears quite unrelated to me ... how does FEATURES="userpriv"
> relate to signing?

#5902 is "emerge security - running as root and digital signatures".
Digital signatures have something to do with signing ;-) Actually, the
bug has been open since August 2002...

> >  The main sticking point seems to
> > be disagreements over key management and policies. I would hope that
> > most people could agree that a single key with a post-commit signing
> > is better than what we have now,
> debatable

It's debatable that a centralised signing the tree is better than not
having any security at all?

> > and could be easily implemented,
> yes
> > whilst leaving open the option of a hybrid system implementation at a
> > later date.
> yes
>
> but that's not a cure. You'd have to sign _each file_ to get a
> reasonable tampering detection, or at least per-directory. You add a
> single point of failure and give attackers a high-profile target.

It depends... what is the purpose of signing individual files? If it's
to find the point of corruption, then you can just diff the corrupt
tree against a good one and look for any exploit like code. Look at it
this way - when emerge detects a corrupt tar.gz in distfiles, it
doesn't tell you exactly what file in the package is corrupt. It just
downloads it from someplace else. The same principle can be applied to
the portage tree.

I'm open to the possibility of signing every file/directory
individually if there's a good reason, but I don't see one at the
moment.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Signing everything, for fun and for profit

[Chris Bainbridge]

On 19/05/06, John Myers <electronerd@electronerdia.net> wrote:
> On Friday 19 May 2006 08:17, Chris Bainbridge wrote:
> >
> > We do? What option to emerge enables this behaviour?
> RSYNC_EXCLUDES is the name, IIRC...

Well, that would be incompatible with a single signature. I don't
really see that point, but then I've been spoiled with broadband for
years. Do we really have many users on dialup that it would
inconvenience? Surely the massive size of the distfiles you have to
download makes the impact of rsyncing the portage tree negligible
compared to actually fetching everything you want to install?

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Signing everything, for fun and for profit

[Peter]

On Thu, 18 May 2006 23:45:17 +0200, Patrick Lauer wrote:

> Hello all,

snip...

I have a question about package Manifests. On reviewing portage, some
Manifests are signed by various GPG keys, and others are not signed at all!

I submitted something to Patrick off list (largely because I'm not a dev,
nor a great security expert) which uses a hash of all Manifest files as a
basis for portage validation. However, the signing of the Manifest files
themselves are inconsistent which poses a few problems.

Who signs the Manifests? Why are some unsigned? Is there a single Gentoo
Security Key (like I know Slackware has and some other distros to ensure
the authenticity of their files)?

TIA

-- 
Peter


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Signing everything, for fun and for profit

[Chris Bainbridge]

On 19/05/06, Peter <pete4abw@comcast.net> wrote:
> Who signs the Manifests? Why are some unsigned? Is there a single Gentoo
> Security Key (like I know Slackware has and some other distros to ensure
> the authenticity of their files)?

Individual developers sign the manifests with their own gpg keys. Some
are unsigned because there is no policy or techical requirement for
them to be signed, so many developers don't. There is no single Gentoo
key.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Signing everything, for fun and for profit

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 648 bytes --]

On Fri, 19 May 2006 15:13:15 +0100
"Chris Bainbridge" <chris.bainbridge@gmail.com> wrote:

> find /usr/portage -path '/usr/portage/metadata' -prune -o -path
> '/usr/portage/distfiles' -prune -o -path '/usr/portage/packages'
> -prune -o -type f -exec cat {} > /tmp/blah \;
> time gpg --detach-sign -a /tmp/blah
> 
> I get 1.5 seconds on a desktop and 6.5 seconds on a laptop.

Because you're only checking the last file returned by find ;)

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Signing everything, for fun and for profit

[Stephen Bennett]

On Fri, 19 May 2006 12:28:04 -0400
Peter <pete4abw@comcast.net> wrote:

> Who signs the Manifests?

The dev who commits it.

> Why are some unsigned?

Because some devs don't sign Manifests.

> Is there a single
> Gentoo Security Key (like I know Slackware has and some other distros
> to ensure the authenticity of their files)?

There's a releng key for the release media, but otherwise no, AFAIK.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Signing everything, for fun and for profit

[Harald van Dijk]

On Fri, May 19, 2006 at 06:50:34PM +0200, Marius Mauch wrote:
> On Fri, 19 May 2006 15:13:15 +0100
> "Chris Bainbridge" <chris.bainbridge@gmail.com> wrote:
> 
> > find /usr/portage -path '/usr/portage/metadata' -prune -o -path
> > '/usr/portage/distfiles' -prune -o -path '/usr/portage/packages'
> > -prune -o -type f -exec cat {} > /tmp/blah \;
> > time gpg --detach-sign -a /tmp/blah
> > 
> > I get 1.5 seconds on a desktop and 6.5 seconds on a laptop.
> 
> Because you're only checking the last file returned by find ;)

'> /tmp/blah' is a shell construct, and while it is (hopefully
unintentionally) strangely written, it is applied to find, not to cat,
even though it's between {} and \;. So all files are added together,
and then gpg is run on the result.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Signing everything, for fun and for profit

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 734 bytes --]

On Fri, 19 May 2006 12:28:04 -0400
Peter <pete4abw@comcast.net> wrote:

> Who signs the Manifests? Why are some unsigned? Is there a single
> Gentoo Security Key (like I know Slackware has and some other distros
> to ensure the authenticity of their files)?

Because the whole signing stuff isn't official, there has been a
(partial) implementation plan a few years back, some people started to
use it but is has never become official, the implementation is
incomplete and there it can't and won't be enforced yet.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Signing everything, for fun and for profit

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 4331 bytes --]

Disclaimer: I'll only targeting technical aspects here, I won't go into
any security analysis.

On Thu, 18 May 2006 23:45:17 +0200
Patrick Lauer <patrick@gentoo.org> wrote:

> 3) Manifest / Manifest2
> 
> This is an implementation of a checksum / signature scheme. It is
> described in GLEP 44:
> 
> http://www.gentoo.org/proj/en/glep/glep-0044.html
> 
> Right now SHA1, SHA256, RMD160 are the default checksum algorithms

> 
> While manifest2 should take care of all executable bits in the tree it
> does not yet cover eclasses and profiles. As long as this is not taken
> care off any attacker can just override an eclass on the rsync mirror
> or modify the profiles. This has a severe negative impact on signing
> effectivity.
> 
> Any "good" solution should sign all data files in the tree, so I ask
> for an extension of the Manifest2 protocol to include _every_ data
> file with no exception.

partially covered with glep 33, definitely needs a repoman rewrite.

> Key policies
> ============
> 
> To make signing relevant and verifiable all devs should use the same
> parameters - key length, key type, validity.
> Once that is agreed upon a key distribution strategy is needed so that
> users can get the key(s) on a verifiable path.

From an implementation point of view the main questions here are:
- how do we get the keys? (keyserver, stored in tree, ...)
- how do we validate a key?

> Signing strategies
> ==================
> 
> Once there is an agreement on what files to sign with what kind of
> keys there remains the question how to sign it. There are at least
> three strategies:
> 
> Method "simple":
> ----------------
> 
> Use one central key that is kept on a secure box. Signing is done 
> automatically after a commit. The key distribution is simple since
> there 
> is only one key that has to be pushed.
> Problems are security (single point of failure, single target for 
> compromising)
> 
> Method "complex":
> -----------------
> 
> Let every dev sign the files he adds or modifies. A keyring is 
> maintained on gentoo infrastructure and is distributed over multiple 
> paths.
> Problems: Need support for multi-signing. If one file is added the 
> manifest should not be only signed by the last editor, only the
> change should be signed. At the same time it needs to be kept simple
> and fast, ssigning each file on its own or keeping infinite history
> must be avoided. Keyring managment needs to be defined. Key
> revocation etc. needs to be defined.
> 
> Method "hybrid":
> ----------------
> 
> Let every dev sign, add automatic server-side signing with a master
> key. Gives you bits of both. Normal users can trust the master key.
> Paranoid users can trust the dev keys.

You're missing one option, the one currently in use:
Any change to a package dir requires the package Manifest to be signed
by the committing dev, including all files even if not changed by the
commit.

From an implementation POV it's desirable to only have one signature
in a file, multiple signatures are problemtatic for parsing (for
partial signatures) and verification (for both partial signatures and
multiple full signatures). Detached signatures would make that easier,
but are not an option due to overhead (>20k new files in the tree).

Therefore I'd avoid the "complex" and "hybrid" solutions.

> Some selected problems from there:
> 
> * Access Control Lists could be used so that only toolchain people can
> commit to glibc. Do we want that level of micromanagment? Does it
> offer any security benefits?

More a QA thing IMO, I don't see any security benefits. We've explicitly
not done this in the past (technically it's not a problem, ACLs are
used in other cvs modules).

> * key revocation may be impractical - what methods for handling
> retired devs and rogue devs are there?

Part of the key policy.

> * how to verify from an install  CD ?

key policy.

> * in tree or out of band? Storing the keys in the tree is easy, but a
> potential security problem

key policy again.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Signing everything, for fun and for profit

[Ned Ludd]

If there is anything you or genone need to make signing happening you
have to the full support of the council/infra/hardened/security.


On Thu, 2006-05-18 at 21:26 -0700, Robin H. Johnson wrote:
> This email is a discussion on why we need to care about more than the simple
> key parameters, and why - this includes things like changing the validity of an
> existing key. We also need to consider: location of key (primary key vs.
> subkey), expiry policies (expiries are only one element of key validity), key
> signatures, and revoking elements in a key.
> 
> I've tried very hard to ensure absolutely all of the following is
> completely fact, and that I have not entered any of my opinions into it,
> except where I've explictly marked it as such.
> 
> On Thu, May 18, 2006 at 11:45:17PM +0200, Patrick Lauer wrote:
> > Key policies
> > ============
> > To make signing relevant and verifiable all devs should use the same
> > parameters - key length, key type, validity.
> No, the simple parameters of the have little bearing on how they are used.
> While we do care about them in terms of managing file signatures, some
> understanding is needed first.
> 
> Introduction
> ------------
> The following is an introduction into some of the OpenPGP standard, with a
> focus on how it affects file signing, key signing, management of keys (for
> the complex style listed), and revocation.
> 
> It's important as to what attacks against a key can lead to what results.
> 
> Breakdown of what is a 'key' is
> -------------------------------
> A 'key' under PGP/GnuPG (OpenPGP) consists of several important entities:
> 1. *actual cryptographic primary keys and secondary keys (subkeys) [pub/sub]
> 2. *user ids - one uid per email address [uid]
> 3. signatures, each attached to one uid [sig]
> 4. revocations of any of the above items [rev]
> I've included the packet type name in the [] at the end.
> The first two items marked with a * are the core entities, and items are
> associated with only one element of them.
> There are a few more packet types, but they aren't important to our
> discussion.
> 
> After this point, I will use the term 'cryptokey' to refer to the actual
> cryptographic keys, and the generic term 'key' to refer to the collection of
> above items.
> 
> To see the various elements of the above, try this:
> "gpg --list-sig SOMEDEV@gentoo.org"
> If you look at my key, it goes on for a few pages (but isn't quite as
> long as the Paludis thread).
> 
> The first column has the information type, and you'll see the types I
> mentioned above.
> 
> Now let's focus on a single key for a moment:
> 
> # gpg --edit-key robbat@gentoo.org
> ...
> pub  1024D/34884E85  created: 2002-08-27  expires: 2008-03-09  usage: CS  
>                      trust: ultimate      validity: ultimate
> sub  2048g/CA05A397  created: 2002-08-27  expires: 2008-03-09  usage: E   
> sub  2048g/67592A1F  created: 2003-04-12  expires: 2008-03-09  usage: E   
> This key was revoked on 2004-09-09 by DSA key 34884E85 Robin Hugh Johnson <robbat2@orbis-terrarum.net>
> sub  1024D/FB33B3A4  created: 2002-08-27  revoked: 2004-09-09  usage: SA  
> This key was revoked on 2004-09-09 by DSA key 34884E85 Robin Hugh Johnson <robbat2@orbis-terrarum.net>
> sub  2048g/CC772FC3  created: 2002-08-27  revoked: 2004-09-09  usage: E   
> sub  1024D/3233C22C  created: 2004-08-29  expires: 2008-03-09  usage: S   
> [ultimate] (1). Robin Hugh Johnson <robbat2@orbis-terrarum.net>
> [ revoked] (2)  Robin Hugh Johnson <rjohnsob@sfu.ca>
> [ultimate] (3)  Robin Hugh Johnson <robbat2@users.sourceforge.net>
> [ultimate] (4)  Robin Hugh Johnson <robbat2@gentoo.org>
> [ revoked] (5)  Robin Hugh Johnson <rhj@sfu.ca>
> [ revoked] (6)  Robin Hugh Johnson <robbat2@sfu.ca>
> [ revoked] (7)  Robin Hugh Johnson <robbat2@hotmail.com>
> [ revoked] (8)  Robin Hugh Johnson <robin@corasen.com>
> [ revoked] (9)  Robin Hugh Johnson <robbat2@net-conex.com>
> 
> The important bit here is the 'usage:' bit at the end of the cryptokeys.
> There are 4 letters that will appear here:
> C - Certify
> S - Sign
> E - Encrypt
> A - Authenticate
> 
> We are interested in two of these only: Certify and Sign.
> We aren't dealing with encrypted data at the moment, and usage of authenticate
> is not implemented in gpg-1.4.
> 
> 'Certify' is the terminology used for signing uids.
> 'Sign' is the terminology used for digitally signing files/data.
> 
> If you attend a keysigning event, you are certifying that a uid does indeed
> belong to a person (more on this in a moment, in how we can gain from it).
> 
> From this point forward, I will use 'certify' to indicate signing of a
> key, and signing to indicate other data signing.
> 
> Only the primary cryptokey [pub] will ever be marked with Certify.
> The primary cryptokey is used for all uid signatures made with your key.
> It also protects your key itself from some modifications by attackers.
> 
> Having multiple UIDs allows a person to go over several email addresses
> over time, without having to invalidate old correspondence, or identify
> themselves to any given third party more than once.
> 
> Choice of Length/Type:
> ----------------------
> Any of the cryptokeys marked with Sign will be used in signing Manifest/digest
> data.
> We have a few choices for these - I'm limiting this to what is implemented in
> upstream GnuPG, and not anything added by external patches.
> CryptoKey types: DSA, RSA.
> CryptoKey lengths: 
> - DSA provides a length of 1024 bits only (gnupg does not allow you to chose
>   anything else without special options, and that is only weaker keys).
> - RSA lengths between 1024 and 4096 bits available.
> 
> The following is a small speed comparison produced with 'openssl bench rsa
> dsa', run single-threaded, and excluding the variants (DSA512, DSA2048) not
> available in GnuPG.
> 
> 32-bit x86 (Athlon XP)
>          sign/s verify/s
> DSA1024   592.2    501.3
> RSA1024   264.7   5581.9
> RSA2048    48.0   1763.5
> RSA4096     7.6    510.1
> 
> Apple G5, Quad:
>          sign/s verify/s
> DSA1024  2125.7   1735.8
> RSA1024  1032.4  18829.6
> RSA2048   171.0   5988.2
> RSA4096    26.3   1754.4
> 
> Not reflected in this is generation time for keys as that is a one time
> occurrence, the time it takes is mostly irrelevant, but for the record, RSA is
> several times slower for equivalent key lengths.
> 
> Note: these speeds would not be affected by the size of the data - as GnuPG
> signs a hash of the data only.
> 
> There are 11k packages in the tree now, and if we assume 2 signatures per
> package for the moment, that's ~40 seconds to verify the entire tree (assuming
> no other bottlenecks, which is completely unreasonable) with RSA4096 on a
> slower machine.
> 
> For the question of key length - I ask the security folk - what do you consider
> reasonable without being paranoid?
> 
> <opinion>
> It's pretty obvious in this, that RSA is slow for signing, but fast for
> verifying. Unless we have a specific need for high speed signing, I'd suggest
> we go with RSA.
> </opinion>
> 
> Location of the cryptokey:
> --------------------------
> If we require that a Gentoo developer has a primary key for that is used for
> signing, we lose the ability to add web of trust to our system later.
> 
> Additionally, if the developer uses the singular primary key for a lot of
> stuff, it is more vulnerable to attack.
> 
> <opinion>
> Instead, the developer should create a subkey that is used for signing Gentoo
> work only. They should not sign anything else with this, including their Gentoo
> email.
> 
> They may have an additional subkey for signing their Gentoo email if they wish.
> </opinion>
> 
> Q: What are the potential downsides to this?
> A: There are some older keyservers out there that do not correctly deal with
>    subkeys - but this should not affect us as we are intending to distribute
>    public cryptokeys ourselves.
> 
> Choosing cryptokey expiry times:
> --------------------------------
> GnuPG and the OpenPGP standard in general allow you to change the expiry date
> on a cryptokey, after it is created. With that in mind, what does it having an
> expired cryptokey imply:
> 1. GnuPG will not use that cryptokey for new creation actions (sign/encrypt/certify).
> 2. GnuPG will correctly validate/decrypt anything signed/encrypted by that
>    cryptokey, provided that the data timestamp is older than the key expiry
>    timestamp.
> 
> #1 is a logical behavior.
> #2 protects us when data hasn't changed for a long time - but we have to be
>    careful about accurate timestamps (evil can get in here).
> 
> Q: What do we actually gain from expiry times in encryption setups?
> A: It would indicate to others which key to use.
> 
> Q: What do we actually gain from expiry times in data signing setups?
> A: Marginal protection against attacks from large datasets that might allow
>    compromise of the key, but only by encouraging us to have multiple keys over
>    time. Is this really a concern? No, we aren't signing large amounts of data.
> 
> Q: Is there anything else we gain from expiry times?
> A: Yes. If a practice of using medium-term expiry times, and updating them
>    regularly is undertaken, the keys provide an indication of who is still paying
>    attention.
> 
> <opinion>
> For the last reason alone, expiry times are worthwhile, and I would like to
> suggest that a period of 6 months is used.
> </opinion>
> 
> Revocating of cryptokeys also has the same implications as an expired
> cryptokey, with the exception that you cannot under a revocation.
> 
> Other validity elements:
> ------------------------
> Now we lead into some more complex areas. Beyond cryptokey expiry dates, there
> are several other methods for key validity. Of primary importance to us are uid
> signatures.
> 
> UID signatures:
> ---------------
> As I wrote last year, these may take several forms.
> We are concerned with several properties that they may have:
> 
> Expiry dates of signatures:
> Unlike expiry dates of cryptokeys, these may not be changed - by default, they
> take on the expiry date of the certifying cryptokey, although a lower value may be
> set. If you have an existing signature that has expired, you need to get your
> uid signed again.
> 
> Revocation of signatures:
> A signature may be revoked by the certifying cryptokey only.
> (TODO: need to check that the same rules of validity apply here).
> 
> Trust markings:
> This is not of immediate concern, but instead offers future options for the
> very paranoid portion of our userbase. They can implement things like only
> trusting a specific web-of-trust of developers.
> 
> Using UID signatures:
> ---------------------
> Q: How can we use signatures to our advantage, for the hybrid or complex schemes?
> 1. Take the master key as defined by the 'Simple' proposal.
> 2. Use it to create uid signatures to each trusted developer key.
> 3. In verifying, designate said master key as the top level of trust (this is
>    the same as the simple scheme), and verify all file signatures by developers
>    as you go along.
> 
> This schema is extensible to N master keys, by telling GnuPG that it
> needs signatures from M masters before data is considered trusted.
> 
> Revoking keys:
> --------------
> <opinion>
> When a developer leaves Gentoo, he should not revoke the subkey used to
> sign (indeed, he may not be able to, think being hit by a bus).
> Instead, any signatures made by a valid master key should be revoked.
> This ensure control remains in the hands of the keymasters (infra, devrel,
> whoever).
> </opinion>
> 
> Summary:
> -----------
> This is a brief summary of the suggestions and choices above.
> This summary outline is assuming a model such as the hybrid or complex
> models.
> 
> - Each developer shall have a GnuPG key.
> - Each developer key shall contain at least one uid, with name and Gentoo email
>   address of the developer.
> - Each developer must create a secondary cryptokey with the following
>   parameters (designated as their Gentoo signing cryptokey):
>   Key Type: RSA
>   Key Length: 2048 or 4096
>   Expiry time: Set at 6 months out
>   Usage: Marked as signing only.
> - Each developer shall regularly update the expiry time (GnuPG enforces
>   this) of the cryptokey, keeping it no further than 6 months ahead of
>   the present date, except where otherwise decided.
> - Each developer should have a revocation certificate for their key, and
>   store two copies in a secure offline location (I suggest two CD-RWs,
>   of different brands, stored in separate locations, refreshed every 6
>   months, but floppy disks would work as well).
> - Each developer will sign all of their commits with their Gentoo
>   signing cryptokey only. They should not sign anything else, nor use
>   other cryptokeys for signing Gentoo commits.
> - (Optional, for those creating new keys only) a best practice would be
>   to have a primary key that is marked as certifying only.
> 
> (This part here needs more discussion, which may end up that N=1 is
> valid).
> - There will be N master keys. 
> - A master key will have a secondary cryptokey conforming to the same
>   requirements as the developer Gentoo signing cryptokey.
> - A master key will certify all Gentoo developer keys on a regular
>   basis. This can be done on 4 month intervals safely, with once-off
>   events to sign keys of incoming developers, or other special cases.
> - When a developer leaves, the certification on their key shall be
>   revoked.
> - Both infra and the council should hold the revocation control for a
>   master key in some way so that cooperation is needed to actually revoke
>   a master key.
> 
> (For future stuff:)
> For performing releases of Gentoo (releng), a designated key be used,
> and be certified by the master key.
> 
> Outstanding points:
> -------------------
> - Discussion of how the keymaster(s) should operate to maintain the
>   keyring.
> 
-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Signing everything, for fun and for profit

[Lance Albertson]

[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]

Marius Mauch wrote:
> On Fri, 19 May 2006 12:28:04 -0400
> Peter <pete4abw@comcast.net> wrote:
> 
>> Who signs the Manifests? Why are some unsigned? Is there a single
>> Gentoo Security Key (like I know Slackware has and some other distros
>> to ensure the authenticity of their files)?
> 
> Because the whole signing stuff isn't official, there has been a
> (partial) implementation plan a few years back, some people started to
> use it but is has never become official, the implementation is
> incomplete and there it can't and won't be enforced yet.

iirc, infra implemented signing of the daily portage snapshots. It was a
crude/simple way to get our tree 'signed', but its far from a scalable
nor proper solution. I think we only provided it since it didn't take
much effort for us to at least implement it and it gave the anal people
the ability to at least have some form of validity. It is one of the
options I know of currently.

Cheers-

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: [gentoo-dev] Signing everything, for fun and for profit

[Alin Nastac]

[-- Attachment #1: Type: text/plain, Size: 537 bytes --]

Chris Bainbridge wrote:

> ...
> Do we really have many users on dialup that it would
> inconvenience? Surely the massive size of the distfiles you have to
> download makes the impact of rsyncing the portage tree negligible
> compared to actually fetching everything you want to install?
>
It is hardly a matter of bandwidth. A reduced to the minimum tree would
sync faster because the thousands of files checked (and pottentially
updated) by rsync are cutted in half.
Also, the other emerge operations will work faster because of that.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 258 bytes --]

Re: [gentoo-dev] Signing everything, for fun and for profit

[Thierry Carrez]

Patrick Lauer wrote:

> Signing strategies
> ==================
> 
> Once there is an agreement on what files to sign with what kind of keys
> there remains the question how to sign it. There are at least three
> strategies:
> [...]

I prefer a semi-secure solution appearing soon rather than waiting
another three+ years for a potentially better solution.

Currently users only have two choices :

- masterkey-signed portage snapshots
- unsigned (and so, insecure) rsync mirrors

This is obviously not satisfying.

It has taken years to try to get per-developer signing implemented,
without success. We should try to do masterkey signing ("simple" method)
and see if we go somewhere. It's is so much better than nothing.

So I would rather work on ensuring everything in portage gets properly
signed rather than designing key policies, cross-signing strategies and
ways to force developers to sign properly. Given the current state of
Gentoo it is a much more reachable goal.

-- 
Thierry Carrez (Koon)
Gentoo Security Team and Gentoo Council Member
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Signing everything, for fun and for profit

[Peter]

On Thu, 18 May 2006 23:45:17 +0200, Patrick Lauer wrote:

>The problem, in short, is how to handle the checksumming and signing of
>gentoo-provided files so that manipulation by external entities becomes
>difficult.

all snip...

PMFJI, but as a user, not a security expert, I had a few thoughts that I'd
like to throw in. Thanks to Patrick, he helped me to drill down some of
the ideas and I present them for consideration. It's just a framework, so
I will be brief.

Here are the main requirements of this scheme:

1) I believe there should be a gentoo uber-key. One, similar to Slackware
Security, which is used to authenticate everything coming from Gentoo.

2) Every first or second level directory in portage should have a Manifest
of all files in it and below, not just ebuilds. All ebuilds have Manifest
files, but eclass does not, and profiles does not AFAIK. These Manifest
files, like now, will contain checksums of all files in and below its
directory.

(right now, signing of Manifests is woefully inconsistent. There are 5400
signed Manifests and the remainder unsigned. Who they are signed by is
unclear. Some I cannot even find on public key servers!)

3) Similar to what is done at keysigning parties, a hash of all Manifest
files would be generated and signed by the uber-key. This hash should be
generated from the actual portage tree prior to being propogated through
the mirror system.

Just an example, but I tried this in ${PORTDIR}

# find . -name "Manifest" -exec openssl dgst -ripemd160 {} ";" >MasterManifestFile.txt

(of course, gpg, md5sum, or related commands could be used. or a perl or
python substitute used. The above was just for illustration).

(where this master file gets stored is not settled now. I think it
should not be propogated, but kept off the mirrors. Others disagree. But
the concept is that it exists and gets signed)

4) When a user emerges an ebuild, he/she would check the hash of
the Manifest in the ebuild he or she is downloading against the
MasterManifestFile.txt file.

The rationale is that if Joe Bad Guy uploads a malicious ebuild to a
mirror he has access to, complete with a new manifest, it won't checksum
correctly against the master list, and the user can be protected. Having a
single hash of all Manifest files protects against intrusion into
parts of the distribution system. It also makes it OK for a user to download 
files that are not affected easily. And, since all directories would have
Manifests, and I would include profiles and eclass as well, they are
protected too.

And, since the MasterManifestFile.txt file is signed by the uber Gentoo
key, tampering with it would be difficult.

5) Every time a new file is added to the main tree, new Manifests must be
generated and a new master list created.

Essentially, what this scheme accomplishes is a double check on Manifests.
What it does not deal with is who signs each Manifest. I am not sure about
that. For example, some Manifest files are signed by now-revoked keys.
Some I can't find on keyservers. And, signing a Manifest file only does
not deal with all the other files. I'm not sure Manifests need to be
signed, but that's out of my realm of expertise and really is a policy
decision. I'm also not sure of the benefit of signing all files either.
Right now, signing of Manifest files is not enforced. How could you
enforce signing all files then?

Here's a snippet of what a Master file could look like using just one
directory, x11-base:

find -name "Manifest" -exec -ripemd160 \{} ";" | gpg --clearsign -

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

RIPEMD160(./xdirectfb/Manifest)= ca5398a78e9f92cff3c704255caec2b6589b0ccb
RIPEMD160(./xorg-x11/Manifest)= 527c1977c0e799aa41dbfa7e5ff3d4fa1026e8be
RIPEMD160(./x11-drm/Manifest)= 2836d93a85c0b7dcb58e3b2dc924d9bd9d8f8cf8
RIPEMD160(./xorg-server/Manifest)= 281e13187104e89525d081a92dc81b3e8b018dce
RIPEMD160(./kdrive/Manifest)= 2559c92f4a94063271959557bf6c084c4da03b53
RIPEMD160(./opengl-update/Manifest)= 534ec81aa9485b020c07cd7800fb60588d141e35
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEbvHJTTfGLUZ/v30RA5AKAKDJFRKIB3GwxYC4iUEVLMg+uuZ6gACgsIco
gSaCIOauDmFjtJNoK0f7bPs=
=Qm0N
-----END PGP SIGNATURE-----

A benefit of this scheme, is that instead of checksumming the thousands of
individual files in portage, we're only interested in the Manifests. The
entire tree of Manifests is <1Mb. Grepping a file would be fast, needing 
only the ebuild name and the word Manifest.

What would need to be determined is what checksumming method to use, and
to require gpg as a dependancy of portage so that signature verification
can be done on the Master File.

I also believe that live cds and other output from gentoo should be signed
as well. I looked at the 2006.0 cd and saw nothing on it.

Here's the Slackware approach that I am very familiar with. On the root
directory of each CD is a list of checksums called CHECKSUMS.md5. Pat
(Volkerding) then creates a detached signature of that file using the
Slackware Security Key. This way, the user can be assured that the list of
md5 checksums is authentic and check any file's checksum (or all) he/she
wants.

snippet of CHECKSUMS.md5

These are the MD5 message digests for the files in this directory.
If you want to test your files, use 'md5sum' and compare the values to
the ones listed here.

To test all these files, use this command:

md5sum -c CHECKSUMS.md5 | less

'md5sum' can be found in the GNU coreutils package on ftp.gnu.org in
/pub/gnu, or at any GNU mirror site.

MD5 message digest                Filename
3b6703583ac87b4ab8cd23aafadb1c2c  ./ANNOUNCE.10_2
470d6328592a31a8bed773e849317895  ./BOOTING.TXT
18810669f13b87348459e611d31ab760  ./COPYING
50aa19e2a2f983eca992d7775b11393c  ./COPYRIGHT.TXT
4e76de599428a3536b4e4e3288456d32  ./CRYPTO_NOTICE.TXT
f8f15922110049f42c8a1d3693e22272  ./ChangeLog.txt

peter@mars ~ $ gpg --search-keys Slackware\ Security
gpg: searching for "Slackware Security" from hkp server cryptonomicon.mit.edu
(1)     GUS-BR Security Team <security@slackware.org.br>
          1024 bit DSA key B181EC7C, created: 2004-11-18
(2)     Slackware Linux Project <security@slackware.com>
        Slackware Linux Project <security@slackware.com>
          1024 bit DSA key 40102233, created: 2003-02-26

Slackware publishes its uber key on public key servers for all to see. GUS
is authorized by Pat.

Gentoo can do similar with its output also.

Sorry. I said this would be brief, and I suppose I lied. However, I hope
someone might get a good thought or two from this (or a good laugh at my
naivete!). And thanks Patrick for helping with your feedback and getting
me to focus on some of these ideas a little more. HTH

-- 
Peter


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Signing everything, for fun and for profit

[Patrick Lauer]

[-- Attachment #1: Type: text/plain, Size: 4004 bytes --]

On Fri, 2006-05-19 at 22:03 -0400, Ned Ludd wrote:
> If there is anything you or genone need to make signing happening you
> have to the full support of the 

> council
That should not be difficult if the proposal is discussed and accepted
by all other groups

> infra
it should be non-invasive and well documented

> hardened/security.
... while offering good security

So I suggest that infra and hardened/security warn of any problems they
see, it would be silly to have a detailed battleplan only to have
someone kill it at the last minute ...

=====

Some short comments on robbat2's proposal:
> > Summary:
> > -----------
> > This is a brief summary of the suggestions and choices above.
> > This summary outline is assuming a model such as the hybrid or complex
> > models.
> > 
> > - Each developer shall have a GnuPG key.
> > - Each developer key shall contain at least one uid, with name and Gentoo email
> >   address of the developer.
> > - Each developer must create a secondary cryptokey with the following
> >   parameters (designated as their Gentoo signing cryptokey):
> >   Key Type: RSA
> >   Key Length: 2048 or 4096
> >   Expiry time: Set at 6 months out
> >   Usage: Marked as signing only.
I think these parameters are acceptable. I can't think of compelling
technical reasons to change them.

> > - Each developer shall regularly update the expiry time (GnuPG enforces
> >   this) of the cryptokey, keeping it no further than 6 months ahead of
> >   the present date, except where otherwise decided.
Enforcing this will be difficult, so I think it should be seen as a
strong guideline (we can't stop you, but please don't mess up)

> > - Each developer should have a revocation certificate for their key, and
> >   store two copies in a secure offline location (I suggest two CD-RWs,
> >   of different brands, stored in separate locations, refreshed every 6
> >   months, but floppy disks would work as well).
No way to enforce this

> > - Each developer will sign all of their commits with their Gentoo
> >   signing cryptokey only. They should not sign anything else, nor use
> >   other cryptokeys for signing Gentoo commits.
> > - (Optional, for those creating new keys only) a best practice would be
> >   to have a primary key that is marked as certifying only.
Sounds reasonable
 
> > (This part here needs more discussion, which may end up that N=1 is
> > valid).
> > - There will be N master keys. 
For N>1: who controls the master keys?

> > - A master key will have a secondary cryptokey conforming to the same
> >   requirements as the developer Gentoo signing cryptokey.
> > - A master key will certify all Gentoo developer keys on a regular
> >   basis. This can be done on 4 month intervals safely, with once-off
> >   events to sign keys of incoming developers, or other special cases.
Why not sync this to the 6 month expiry time?
Also you might want to add:
- All keys and the master key shall be made available on Gentoo media
(install-cd etc) and other ressources (ebuilds, download from known
locations, stored on public keyservers)

> > - When a developer leaves, the certification on their key shall be
> >   revoked.
> > - Both infra and the council should hold the revocation control for a
> >   master key in some way so that cooperation is needed to actually revoke
> >   a master key.
This will be very tricky to implement. 
> > (For future stuff:)
> > For performing releases of Gentoo (releng), a designated key be used,
> > and be certified by the master key.
This should be discussed with releng. While I don't see why they should
disagree I dislike forcing any policy on others.
 
> > Outstanding points:
> > -------------------
> > - Discussion of how the keymaster(s) should operate to maintain the
> >   keyring.
Plus, of course, what to sign, how to sign it, how to handle failures.

Patrick
-- 
Stand still, and let the rest of the universe move

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Signing everything, for fun and for profit

[Patrick Lauer]

[-- Attachment #1: Type: text/plain, Size: 2012 bytes --]

On Sat, 2006-05-20 at 10:13 +0200, Thierry Carrez wrote:
> Patrick Lauer wrote:
> 
> > Signing strategies
> > ==================
> > 
> > Once there is an agreement on what files to sign with what kind of keys
> > there remains the question how to sign it. There are at least three
> > strategies:
> > [...]
> 
> I prefer a semi-secure solution appearing soon rather than waiting
> another three+ years for a potentially better solution.
A staged plan might be best then:
- implement a simple master-key signing
- discuss the more complex distributed models
- implement the distributed models if agreed upon

> Currently users only have two choices :
> 
> - masterkey-signed portage snapshots
> - unsigned (and so, insecure) rsync mirrors
> 
> This is obviously not satisfying.
Yes. It also gives us ~100 single points of attacks as every compromised rsync mirror could go undetected for a long time.

> It has taken years to try to get per-developer signing implemented,
> without success. We should try to do masterkey signing ("simple" method)
> and see if we go somewhere. It's is so much better than nothing.
There is no authority that "forces" signing.
Making signing mandatory should not cause big problems now ...

> So I would rather work on ensuring everything in portage gets properly
> signed rather than designing key policies, cross-signing strategies and
> ways to force developers to sign properly. Given the current state of
> Gentoo it is a much more reachable goal.
"properly signed" implies some standard or policy to measure it against.

So we need to have some agreement what is needed to assure "properly
signed everything" - it looks like the centralized masterkey model will
have the smallest impact on all involved. Then we look at all issues
this model has, try to fix all bugs - then we have a plan to implement,
and I hope that this will happen in a reasonable timeframe.

Patrick
-- 
Stand still, and let the rest of the universe move

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Signing everything, for fun and for profit

[Jan Kundrát]

[-- Attachment #1: Type: text/plain, Size: 1583 bytes --]

Robin H. Johnson wrote:
> Additionally, if the developer uses the singular primary key for a lot of
> stuff, it is more vulnerable to attack.
> 
> <opinion>
> Instead, the developer should create a subkey that is used for signing Gentoo
> work only. They should not sign anything else with this, including their Gentoo
> email.
> 
> They may have an additional subkey for signing their Gentoo email if they wish.
> </opinion>

I don't know much about cryptography, but could you please elaborate on
why is using one subkey for all the stuff considered a Bad Thing?

> UID signatures:
> ---------------
> As I wrote last year, these may take several forms.
> We are concerned with several properties that they may have:
> 
> Expiry dates of signatures:
> Unlike expiry dates of cryptokeys, these may not be changed - by default, they
> take on the expiry date of the certifying cryptokey, although a lower value may be
> set. If you have an existing signature that has expired, you need to get your
> uid signed again.

Off-topic question - I've already met Alice, verified her identity,
signed her keys and now she wants me to sign her new subkey with same
name, e-mail etc because the old one has expired. Alice lives in Canada
so I can't meet her easily. Should I sign it again with the same level
of "trust"?

Another situation - Bob, Alice's boyfriend, lives in Canada. I've met
him before, verified his identity and signed his subkey for
bob@foobar.com. Now he wants my signature for bob@example.org. Should I
sign it?

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 258 bytes --]

Re: [gentoo-dev] Re: Signing everything, for fun and for profit

[Chris Bainbridge]

On 20/05/06, Peter <pete4abw@comcast.net> wrote:
> PMFJI, but as a user, not a security expert, I had a few thoughts that I'd
> like to throw in. Thanks to Patrick, he helped me to drill down some of
> the ideas and I present them for consideration. It's just a framework, so
> I will be brief

Thanks for your input. From a security point of view your scheme is
fine, but as pointed out by others you won't be able to selectively
rsync parts of the tree. That will require a signature for each
manifest, and a manifest for every directory. The problem I see is
that the manifest is going to have to include a hash for each
subdirectory - otherwise you open the possibility of someone replacing
a directory with one from the past that contains some known
insecurity, or corrupting the tree by swapping random directories, and
yet the signatures remain valid. Of course, that hash changes if you
allow people to rsync_exclude directories, and hence the signature
changes. So you can either accept that if you selectively rsync then
you won't be able to verify the signed tree, or accept that there is a
known security problem with having no signed link between parent and
child directories, or come up with a different scheme.

Obviously the manifests also have to be checked to make sure they're
valid - this is currently done for package directories at emerge time,
it would need to be extended to all other directories. I'd prefer the
checks done at sync time since that's a one time cost and you don't
have to figure out exactly what files will be used by each emerge
operation.

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: Signing everything, for fun and for profit

[Peter]

On Sat, 20 May 2006 15:37:54 +0100, Chris Bainbridge wrote:

> On 20/05/06, Peter <pete4abw@comcast.net> wrote:
>> PMFJI, but as a user, not a security expert, I had a few thoughts that I'd
>> like to throw in. Thanks to Patrick, he helped me to drill down some of
>> the ideas and I present them for consideration. It's just a framework, so
>> I will be brief
> 
Thanks for not throwing me overboard to the sharks! I had a few comments.

> Thanks for your input. From a security point of view your scheme is
> fine, but as pointed out by others you won't be able to selectively
> rsync parts of the tree. That will require a signature for each
> manifest, and a manifest for every directory. The problem I see is that
> the manifest is going to have to include a hash for each subdirectory -
> otherwise you open the possibility of someone replacing a directory with
> one from the past that contains some known insecurity, or corrupting the
> tree by swapping random directories, and yet the signatures remain
> valid. Of course, that hash changes if you allow people to rsync_exclude
> directories, and hence the signature changes. So you can either accept
> that if you selectively rsync then you won't be able to verify the
> signed tree, or accept that there is a known security problem with
> having no signed link between parent and child directories, or come up
> with a different scheme.

I'm not sure this is so. Yes, the Manifest file will have to include all
files in it's current and child[ren] directories. However, this is done
now. You would have to include eclass and profiles to have Manifests also.

I do not see how using rsync exclude would affect this scheme. If someone
wants to emerge samba and exclude KDE, the hash of the samba Manifest
will be there to check against. I'm not interested in signing the entire
tree. I am interested in signing the hashes of all Manifests in the tree
as a list. So, during the emerge process, as each package is emerged, the
first thing that occurs is to check the hash of the package Manifest file
against the stored hash in the signed Master Manifest file. Sort of like:

In pigeon bash and pseudo code, here's how I envision the check.
gpg --verify MasterManifestFile
# if error then abort
M_HASH=${grep "samba/Manifest" MasterManifestFile)
# probably need to use cut or something here...
C_HASH=$(md5sum samba/Manifest)
if M_HASH -ne C_HASH then abort

> Obviously the manifests also have to be checked to make sure they're
> valid - this is currently done for package directories at emerge time,
> it would need to be extended to all other directories. I'd prefer the
> checks done at sync time since that's a one time cost and you don't have
> to figure out exactly what files will be used by each emerge operation.

My thought was, that even if someone inserted a rogue package onto one of
the mirrors, a) altering the MasterManifest file would be difficult since
the signed part would not match, b) The Manifest hash would not match, or
if the bad guy did not alter the Manifest, the hash of its files would not
match (such as replacing a source dl location).

Anyway, thanks for taking a look.

-- 
Peter


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Signing everything, for fun and for profit

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 2798 bytes --]

On Sat, May 20, 2006 at 03:21:13PM +0200, Jan Kundr?t wrote:
> I don't know much about cryptography, but could you please elaborate on
> why is using one subkey for all the stuff considered a Bad Thing?
The basic form of it, is a vulnerability towards a class of attacks that
require a large supply of signed/encrypted material.
For a primer on various modes of using block ciphers, see 
Wikipedia: http://tinyurl.com/bbcmf

It's conceivable that (and this is the absolute worst case), under this
class of attack, a lot of signing may ultimately reveal bits of your
key, because the attacker has both the plaintext and ciphertext, and can
ultimately compute it - this can either be brute-force, or
mathematically (consider it solving algebra).

> Off-topic question - I've already met Alice, verified her identity,
> signed her keys and now she wants me to sign her new subkey with same
> name, e-mail etc because the old one has expired. Alice lives in Canada
> so I can't meet her easily. Should I sign it again with the same level
> of "trust"?
I think you missed something in my original email, namely that you don't
sign subkeys, you sign uids.

Since uids don't expire that part is irrelevant, but they can be revoked 
- then this becomes the same as bob's case below.

Note:
Unless you are using the 'tsign' command under GnuPG, the trust question
it asks you is only for it's local database, and is NOT included with
the exported keys that are sent to keyservers or other users. So let's
assume you are using tsign as well.

> Another situation - Bob, Alice's boyfriend, lives in Canada. I've met
> him before, verified his identity and signed his subkey for
> bob@foobar.com. Now he wants my signature for bob@example.org. Should I
> sign it?
Actual answer:
You'll need to rely on your discretion a bit, but you can narrow down
the possibilities for attacks by following a specific process (and there
is a package that makes this much easier, but it's only available in
Debian's SVN at the moment http://tinyurl.com/ggueq).
0. Bob sends you a request about his new uid, signed with his key that
   you can verify.
1. Sign the new uid, and export the uid signature to a file.
2. Delete the signature from your keyring, you don't want it trusted yet
   (you can avoid this is you have a temp clone of your keyring).
3. Send Bob an encrypted email, with the uid signature file attached.
4. Bob needs to be able to decrypt the email using his GnuPG - thus
   associating the email address listed in his key with his key - if she
   can't decrypt the email - she's an imposter that has taken over the
   email account.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 241 bytes --]

Re: [gentoo-dev] Re: Signing everything, for fun and for profit

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 1130 bytes --]

On Sat, May 20, 2006 at 06:54:44AM -0400, Peter wrote:
> On Thu, 18 May 2006 23:45:17 +0200, Patrick Lauer wrote:
> 
> >The problem, in short, is how to handle the checksumming and signing of
> >gentoo-provided files so that manipulation by external entities becomes
> >difficult.
> all snip...
> 
> PMFJI, but as a user, not a security expert, I had a few thoughts that I'd
> like to throw in. Thanks to Patrick, he helped me to drill down some of
> the ideas and I present them for consideration. It's just a framework, so
> I will be brief.
Even larger snip.

I was actually looking at something similar to this, for the 'simple'
portion of Patrick's plan. You have most of the major ideas down, but
missed a few holes, and sticking points.

I'll try to get a writeup of it out later tonight, got a double-date
first ;-).

Thanks for the good writeup of Slackware as well, it's one I didn't
elaborate much on when I previously described the processes of
RPM-distros and Debian.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 241 bytes --]

Re: [gentoo-dev] Signing everything, for fun and for profit

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 848 bytes --]

On Saturday 20 May 2006 22:47, Robin H. Johnson wrote:
> The basic form of it, is a vulnerability towards a class of attacks that
> require a large supply of signed/encrypted material.
> For a primer on various modes of using block ciphers, see
> Wikipedia: http://tinyurl.com/bbcmf
>
> It's conceivable that (and this is the absolute worst case), under this
> class of attack, a lot of signing may ultimately reveal bits of your
> key, because the attacker has both the plaintext and ciphertext, and can
> ultimately compute it - this can either be brute-force, or
> mathematically (consider it solving algebra).

Once one developer has been compromised, there is even a chosen plaintext 
attack path. Making it even worse.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 200 bytes --]

Re: [gentoo-dev] Re: Re: Signing everything, for fun and for profit

[Chris Bainbridge]

On 20/05/06, Peter <pete4abw@comcast.net> wrote:
<snip>

Thanks for the clarification. That scheme looks fine. The master
manifest will add about ~700k to the tree, but since it can be rsynced
the actual bandwidth usage day to day should be reasonable.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Signing everything, for fun and for profit

[Francesco Riosa]

Chris Bainbridge wrote:
> On 20/05/06, Peter <pete4abw@comcast.net> wrote:
> <snip>
> 
> Thanks for the clarification. That scheme looks fine. The master
> manifest will add about ~700k to the tree, but since it can be rsynced
> the actual bandwidth usage day to day should be reasonable.
> 
rsync option for the portage tree include "--whole-file", thus making it
a full download at quite every sync.
-- 
gentoo-dev@gentoo.org mailing list