Re: [gentoo-dev] Signing everything, for fun and for profit
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: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp9kZlwpXPE4.pgp Description: PGP signature
Re: [gentoo-dev] Signing everything, for fun and for profit
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. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Signing everything, for fun and for profit
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
Re: [gentoo-dev] Signing everything, for fun and for profit
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 N1: 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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Signing everything, for fun and for profit
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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Signing everything, for fun and for profit
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 [EMAIL PROTECTED] Now he wants my signature for [EMAIL PROTECTED] 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 : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgp0905KBwRTc.pgp Description: PGP signature
Re: [gentoo-dev] Signing everything, for fun and for profit
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.
Re: [gentoo-dev] Signing everything, for fun and for profit
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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Signing everything, for fun and for profit
On 19/05/06, Patrick Lauer [EMAIL PROTECTED] 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
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 Gaffneyhttp://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
On 19/05/06, Andrew Gaffney [EMAIL PROTECTED] 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
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
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Signing everything, for fun and for profit
On Friday 19 May 2006 08:17, Chris Bainbridge wrote: On 19/05/06, Andrew Gaffney [EMAIL PROTECTED] 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 # pgp9semJpQyl7.pgp Description: PGP signature
Re: [gentoo-dev] Signing everything, for fun and for profit
On Fri, May 19, 2006 at 04:17:38PM +0100, Chris Bainbridge wrote: On 19/05/06, Andrew Gaffney [EMAIL PROTECTED] 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
On Fri, 2006-05-19 at 16:17 +0100, Chris Bainbridge wrote: On 19/05/06, Andrew Gaffney [EMAIL PROTECTED] 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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Signing everything, for fun and for profit
On 19/05/06, Patrick Lauer [EMAIL PROTECTED] 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
On 19/05/06, John Myers [EMAIL PROTECTED] 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
Re: [gentoo-dev] Signing everything, for fun and for profit
On Fri, 19 May 2006 15:13:15 +0100
Chris Bainbridge [EMAIL PROTECTED] 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.
signature.asc
Description: PGP signature
Re: [gentoo-dev] Signing everything, for fun and for profit
On Fri, May 19, 2006 at 06:50:34PM +0200, Marius Mauch wrote:
On Fri, 19 May 2006 15:13:15 +0100
Chris Bainbridge [EMAIL PROTECTED] 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] Signing everything, for fun and for profit
On Fri, 19 May 2006 17:10:53 +0100 Chris Bainbridge [EMAIL PROTECTED] 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 pgphnXlOB0hPR.pgp Description: PGP signature
Re: [gentoo-dev] Signing everything, for fun and for profit
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 [EMAIL PROTECTED] 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. signature.asc Description: PGP signature
Re: [gentoo-dev] Signing everything, for fun and for profit
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] ... 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] [ revoked] (2) Robin Hugh Johnson [EMAIL PROTECTED] [ultimate] (3) Robin Hugh Johnson [EMAIL PROTECTED] [ultimate] (4) Robin Hugh Johnson [EMAIL PROTECTED] [ revoked] (5) Robin Hugh Johnson [EMAIL PROTECTED] [ revoked] (6) Robin Hugh Johnson [EMAIL PROTECTED] [ revoked] (7) Robin Hugh Johnson [EMAIL PROTECTED] [ revoked] (8) Robin Hugh Johnson [EMAIL PROTECTED] [ revoked] (9) Robin Hugh Johnson [EMAIL PROTECTED] 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:
[gentoo-dev] Signing everything, for fun and for profit
Hello all, I flood you again with a long 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)
Re: [gentoo-dev] Signing everything, for fun and for profit
On Thu, 18 May 2006 23:45:17 +0200 Patrick Lauer [EMAIL PROTECTED] 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 signature.asc Description: PGP signature
Re: [gentoo-dev] Signing everything, for fun and for profit
On Fri, 19 May 2006 01:53:29 +0200 Kevin F. Quinn [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] ... 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] [ revoked] (2) Robin Hugh Johnson [EMAIL PROTECTED] [ultimate] (3) Robin Hugh Johnson [EMAIL PROTECTED] [ultimate] (4) Robin Hugh Johnson [EMAIL PROTECTED] [ revoked] (5) Robin Hugh Johnson [EMAIL PROTECTED] [ revoked] (6) Robin Hugh Johnson [EMAIL PROTECTED] [ revoked] (7) Robin Hugh Johnson [EMAIL PROTECTED] [ revoked] (8) Robin Hugh Johnson [EMAIL PROTECTED] [ revoked] (9) Robin Hugh Johnson [EMAIL PROTECTED] 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
