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

[Daniel Kahn Gillmor]

On 09/23/2014 02:33 PM, Werner Koch wrote:
> I will definitely do that as soon as a cheap device is available which
> can be used to hold and somehow backup the offline key.  Using an > 15
> year old laptop for this task like me, can't be suggested to average
> users.

i don't know how cheap a "cheap device" needs to be, but having a
functional and easy software path to use it would certainly increase the
likelihood of uptake.  There is a bit of a chicken and egg problem here.

> I doubt that it is currently possible to design, produce, and sell such
> a device.  It is just not sexy enough for a crowdfunding campaign ("just
> for storing some part of the key - why can't I use my smartphone for
> it"?).  Such a device needs to be dedicated and resistant to remote
> exploits (USB stack, side channels) and may not have any extra gadgets.
> It needs a little screen and a small keyboard, though.

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.

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.

-------


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).

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!).

Regards,

	--dkg

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