Re: dedicated live CD for PGP master key management
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 25/04/16 23:06, Christian Seiler wrote:
> 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 RAID.
>
> 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.
>
> Ack.
>
>>> 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.
>
> Regards, Christian
>
> [*] 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.
>
Some code is now available for building the bootable CD/DVD image:
https://wiki.debian.org/OpenPGP/CleanRoomLiveEnvironment#Code
It ensures the dependencies are all present, other workflow stuff is
not implemented yet
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJXHx3RAAoJEGxlgOd711bE0ZoQAKjX53q3kKmUBgDhKgI7/CRu
ebnq0m17cwwjDAOBg0RWBUXtBMVlUng9dwA7OHaGqTpx/cgOMWkdDqfAjB/QvAw9
QO6O6HqJtEe/zB5xEGyL3RoiyC0GJ+J2IfOVgZ650Zkk+tqWPtr6RdKvx1ZfFiVX
ycaUzGWhYCKX93kCCNE87cBzFRaL4+rEs95nQ7QvyHlsP/QXLSV8xVQCFOxUaEjR
lfPIZeUdmHsRL8txgM4/mn4udSLw55fYv4uwp6kGfau82O7voEybl9jskDrOtWum
oSQmxqrKwukRGCefmSuc2rma60CRsuGUqcIhQ0729miuoJ608pLfAYf9d/8UC7NI
SMaf6H/gi1exQjpGICR0ecOWWaF6duFQr7NUbVN21OCfd/ybOY8QasVCUqXvbJbz
OgAk6tuDRyRLXdyYnLQ9rntn5oHKWe1jIaaocAgnrPaxtz45uK15FTkUC3exMMzm
xZdckJ93kBjYAO5QNHP4h1vOGNdR+2wLRCq2tslREqJB7Bt70hr2Dfctq86DHWzu
VYAxAs3Qi4OrTVq2nycI5Go/M8fMnH/xKDP9DIrzwF6NuM55gmhCkGweTBcJj1gH
qQv5MNKMrD8vbU7u3RXOZaPbkwZdID7MQVAnVol8S5rMOLWrDW/Mkh/Mv6C5MrMs
+UUKqIPdkIORScF9Ssmg
=9n2u
-----END PGP SIGNATURE-----
Reply to: