| 1 |
On Thursday 25 March 2004 10:54, Paul de Vrieze wrote: |
| 2 |
> |
| 3 |
> Let me lay out again what I would propose (I will not discuss signing the |
| 4 |
> packages or verification) |
| 5 |
> |
| 6 |
> - - We have a master key on a USB flash key managed by drobbins. |
| 7 |
|
| 8 |
You just turned drobbins and his household into a prime target for a physical |
| 9 |
attack. His computer, too, when it interfaces to the flash key |
| 10 |
|
| 11 |
>- - The public key of the N signing keys are made public in the tree where |
| 12 |
> it is used |
| 13 |
|
| 14 |
Why not distribute public intermediate keys and signing keys of all the valid |
| 15 |
servers and signatures of the current days keylist together? |
| 16 |
|
| 17 |
> - - The secret key of the N signing keys can be forgotten immediately after |
| 18 |
> signing the key list, so the secret keys have a lifetime less than 5 |
| 19 |
> minutes |
| 20 |
|
| 21 |
The lifetime of the signing key is irrelevant - as long as we have the |
| 22 |
intermediate key on this computer we can generate new signing keys. Given |
| 23 |
this, I'm not sure whether there is any point in having signing keys rather |
| 24 |
than using the intermediate keys. |
| 25 |
|
| 26 |
> The the biggest issue is the security of the intermediate private keys. |
| 27 |
> They need to be machine useable so either the passphrase must be stored |
| 28 |
> on those machines, or there would to be an empty passphrase. For this it |
| 29 |
> might be possible to use gpg-agent to ensure that access to the secret |
| 30 |
> key file would not mean that the key would be compromised. |
| 31 |
|
| 32 |
Once the machine is compromised there is no way to protect the intermediate |
| 33 |
key, as it is held in memory, and root can access it. |
| 34 |
|
| 35 |
> The use of N |
| 36 |
> different machines that generate signing keys might be a way to lessen |
| 37 |
> this risk. |
| 38 |
|
| 39 |
The n of m signature check here is a good thing - it requires an attacker to |
| 40 |
compromise n machines holding intermediate keys. If the client chooses the n |
| 41 |
randomly then the chance of choosing the permutation that has been attacked |
| 42 |
is unlikely. |
| 43 |
|
| 44 |
An attack against the key list is possible here. Whoever has access to update |
| 45 |
the key list has complete control over the system, as if they are compromised |
| 46 |
an attacker can submit a new key list to the signing servers, which will sign |
| 47 |
them. |
| 48 |
|
| 49 |
-- |
| 50 |
gentoo-dev@g.o mailing list |
Archives