offline primary keys [was: Re: Why 2.1 is delayed for so long]

[Ximin Luo]

On 23/09/14 22:51, Daniel Kahn Gillmor wrote:
> fwiw, there is security to be gained just from moving the master key to
> a USB stick without any screen or keyboard -- just having the key be
> inaccessible when the USB stick is unplugged defends against one whole
> class of attack (though obviously there are others that it does not
> defend against).  Using this with a dedicated user account that doesn't
> have access to a graphical session is a plausible step toward limiting a
> range of other attacks.
> 

One step better, that is cheaper but less secure than getting a new computer (or the things you mention below), is to put the master key on an encrypted USB device that is only unlocked from a readonly non-networked live OS. Of course this doesn't stop firmware/BIOS malware, but those are more costly to develop and deploy.

> Stepping up from there, using a GnuK or a Neo OpenPGP device without any
> physical UI makes the key itself inaccessible even when online, and
> reduces attackers to just making requests but not stealing the key itself.
> 
> an upgraded GnuK or Neo with a single LED lamp (for "i have been asked
> to make a signature") and a single button (for "ok, make the signature")
> is still more of an improvement.
> 
> Anyway, all of this is to say that "offline primary key" is more of a
> spectrum than a boolean concept, and that software improvements in
> making it easier to move to offline primary keys are all worth making
> even if the absolute ideal piece of kit doesn't exist yet.
> 

Right. Hardware support would be ideal in the future, but it doesn't mean we should ignore efforts in complementary areas.

> -------
> 
> 
> As for Ximin's goals: I think the transition process could look like this:
> 
>  0) add a signing-capable subkey
>  1) remove signing-capability from primary key
>  2) move primary key offline
> 
> this raises some protocol questions and some usability questions.
> 
> step 0 is relatively easy to do right now.
> 
> step 1 i know how to do, but only with hoop-jumping and custom code
> --not for the faint of heart.  i also don't know what would happen to
> old messages that i had signed with the primary key.  are they no longer
> correctly-signed?  I guess i should experiment with this.
> 
> step 2 i know how to do with hoop-jumping and maybe less custom code
> than step 1, but i think it's still not for the faint of heart.  I think
> it involves --export-secret-keys, then --export-secret-subkeys, then
> --delete-secret-key, then --import, then move the full keys, etc.  If
> this is a workflow we want to support for real humans, it needs some
> serious usability attention (maybe the answer is "that happens outside
> gnupg", and that's fine, as long as gnupg can be used to do that).
> 

Step 0 and 2 can be scripted easily. Step 1 can in theory by script, but it's optional and has the long-lasting caveat you mentioned; I think it would be easier to just generate a new master key, hence my suggestion.

> If the default certificate was changed to Ximin's proposed C+S+A key
> (which does address real needs), that would resolve steps 0 and 1.  We
> still have to grapple with step 2 no matter what (unless i'm just
> ignorant of an already-existing easy process for step 2 -- please tell me!).
> 

I was not proposing a CSA master key, I think that is a horrible idea. :p Rather, I was pointing out that, arguments in favour of supporting a CS master key can be extended to support a CSA master key, so the fact we don't do the latter means these arguments are not great arguments. (Although it looks like something else, possibly GPGTools for Mac, generates these by default.)

Of course you can still move your master key offline if it is CS or CSA, you just have some extra steps to do, your key looks confusing to people, naive software might get confused, and the data scheme is unnecessarily complex.

IMO the fact that multiple uses for a key is even allowed is a design flaw in OpenPGP, but especially the fact a key can be used for C and something else. C is for identity management, the others are for 3rd-party applications; so the keys should be separated appropriately. Even without the history of legal bullshit, from a clean-engineering point of view, separate C/S/A keys would be the best design, as well as separate name/email UIDs. But maybe this is just hindsight bias.

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140924/d569bfce/attachment.sig>