[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dedicated live CD for PGP master key management

On 04/25/2016 08:54 PM, Daniel Pocock wrote:
> On 25/04/16 19:03, Christian Seiler wrote:
>>> Does the workflow make sense?
>> In principle yes, however it doesn't quite fit with my the
>> workflow I'd like to use something like that for: my master key is
>> on a two separate SD cards, and I only have one SD card reader. So
>> what I do when I need to change something on the key is to insert
>> one SD card, copy the .gnupg directory to a tmpfs, do the
>> modifications, copy the directory back to the first SD card, and
>> then copy the directory back to the second SD card. Any RAID
>> solution wouldn't work for me, as I can't insert both cards at the
>> same time. (Also, many people only have a limited amount of USB
>> ports, and not every person wants to buy a hub just for this, so
>> even with USB keys RAID might not always be easily possible,
>> especially if you need one port for booting the system.)
> We could make it work that way
> One of the things that appeals to me about BtrFS is that if one flash
> drive returns bad data, BtrFS will know which one has the good data
> and the application won't have to compensate for that.

Yes, but you'd still have to somehow communicate to the user that
one of the drives was bad and that it has to be replaced, so the
application will need to provide some kind of interface here.

Also, in this case, if there really is corruption in essential
data by the flash drive, this will immediately show up - as the
public and private keys won't match in that case.

> The solution you describe is feasible but would possibly require more
> manual effort if one of the flash drives fail

I don't believe so. btrfs replacement only works well if you have
both the failed and the new drive plugged in (and at least the
headers are accessible and good), otherwise you have to mount the
device in degraded mode, manually add the new drive and then
remove the missing one. Doable, but in my view this appears to be
more complicated than a manual copy logic of a directory.

> or if they become out of sync by way of human error.

Yes, this would be the only advantage.

On the other hand, at least with GnuPG 2.1+ (if I understand it
correctly) the private keys are now just the mathematical
paraemters required for usage. This in turn means that only the
public keyring carries all the information (uids, expiry, etc.).
And public keys can be merged without a problem.

So for nearly all operations you could conceivably do (renewal,
recovation, adding new subkeys [*], signing other people's keys)
you don't actually need to keep them in sync explicitly, because
you always take your public key with you to your normal system,
so every time you boot the master key mgmt live CD, you have the
master key drives as input for the secret key, but the public
key can also come from the USB stick you use to interface the
live CD with the rest of the world.

I therefore don't see any real issue with synchronizing them.
Additionally, I think there is a perfectly valid workflow where
you don't modify all of the copies of the master key disk. For
example, let's say I want to store one of the copies with family
or in a safety deposit box, just as an additional backup against
the house burning down or so. Then I generate the GPG key, make
3 copies, keep 1 of those copies for myself, store one in a
safety deposit box at a local bank and give the other to e.g. my
parents for safekeeping. For daily usage I just use my own copy
of the master key, but if that fails (due to e.g. the flash
drive giving up), I can use one of the other backups.

> The Live DVD will have a terminal, like the installer, so anybody who
> doesn't want to use the workflow can drop into the shell and do
> whatever they want using the utilities that are present in the filesystem.

Sure. I still think semi-automatic copies are easier to handle
from an application standpoint than filesystem or block device

Think of it this way: you need to put in 3 flash drives (be it
USB sticks or SD cards) for normal operation if you only have a
single copy: one for booting the live key management (unless you
still have a CD drive, which my laptop e.g. doesn't), one that
contains the master key, and one for exchanging data with the
outside world.

But if you just use copies, this is far easier: at the beginning
you ask the user to plug in the master key flash drive. The
.gnupg directory is then copied to a tmpfs ramdisk. The user is
then told that they can remove the master key flash drive again
and may now insert the flash drive used for data exchange with
the outside world. The user then performs the operations they
want to do (key renewal, signing of other users' keys, etc.). At
the end they are asked to insert the master key flash drive again,
causing the program to write any changes from the ram disk back.
Then they are asked if they have additional copies of the master
key flash drive and want to repeat the save operation. And if the
user decides to create an additional copy for some reason, they
can trivially do so at this step. I think this logic is far
simpler and much more transparent for the user.

>> [LUKS]
> That is a valid consideration but maybe it should be a wishlist item.


>> Finally, I'm not sure I'd trust btrfs enough for this - especially 
>> in RAID mode if both devices are your only copy. I can't think of 
>> any feature in btrfs that might be required for this use case, so 
>> I'd rather stick with a plain ext4, at least by default. When it 
>> comes to this I'd rather be conservative.
> The BtrFS features I'm after are the RAID1 support and checksumming.
> MD and ext4 can do RAID1 but without checksumming.

But I don't think checksumming is required here: if there is
corruption in any relevant parts, it can immediately be detected
by the application. Just let GPG check the self-signatures at
the very beginning.

And I also think that RAID is not the right way to go here. I
think using simple copies is way more obvious than a RAID setup,
especially if stuff goes wrong.

Just my 2c.


[*] Either you don't actually store the secret sub key because
you use a token, or you do store it, but you then need to make it
accessible for everyday usage, so it's not only kept on the USB
stick or SD card that contains the master key, but also on the
machine you intend to using it from. And I don't see a use case
for a subkey where the private key is only stored together with
the master private key.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: