Re: dedicated live CD for PGP master key management
On 25/04/16 19:03, Christian Seiler wrote:
> On 04/25/2016 06:38 PM, Daniel Pocock wrote:
>> On 25/04/16 17:34, Christian Seiler wrote:
>>> Am 2016-04-25 17:24, schrieb Daniel Pocock:
>>>> On 25/04/16 16:23, Holger Levsen wrote:
>>>>> On Mon, Apr 25, 2016 at 04:03:26PM +0200, Daniel Pocock
>>>>> wrote:
>>>>>> I had already made up some live CDs for ready-to-run VoIP
>>>>>> and remote hands purposes, so I can probably do some of
>>>>>> what is required, but it seems like a good idea to avoid
>>>>>> duplicating any other efforts in this area too.
>>>>>
>>>>> shouldn't most of the functionality of this go into (a)
>>>>> dedicated package(s) which then can be used by several, eg
>>>>> by tails and grml and debian live-cds?
>>>>>
>>>> Some parts of such a project could probably be packaged
>>>>
>>>> One of the ideas I had is that it should have a kernel
>>>> compiled without any networking support, then it may not make
>>>> sense to mix bits of the solution with other live CDs
>>>
>>> Well, as Debian kernels are modularized, why not simply create
>>> a package that blacklists all network drivers? Then you don't
>>> have to compile an own kernel, but just make sure that the list
>>> of networking-related kernel modules is up to date, which seems
>>> to me to be a lot less work (especially since you can
>>> potentially automate that by looking for stuff in
>>> drivers/net).
>>>
>>> Plus a tool that looks at the list of loaded modules and
>>> checks that there isn't any network driver loaded.
>>>
>>
>> I agree that is probably easier for development, although from a
>> security point of view the strategy would be to avoid having any
>> networking code in the environment at all
>
> Well, your live CD creator script could also drop the networking
> modules from the image, then they aren't available on the live
> CD/USB key at all. Unless there is some driver compiled into the
> kernel (I haven't checked), this should also be sufficient.
>
>> I've progressed the whole concept from vapourware to wikiware
>> now:
>>
>> https://wiki.debian.org/OpenPGP/CleanRoomLiveEnvironment
>>
>> 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.
The solution you describe is feasible but would possibly require more
manual effort if one of the flash drives fail or if they become out of
sync by way of human error.
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.
> By the way, in addition to the passphrase for the GPG key, my SD
> cards are also encrypted via LUKS (with a different passphrase) to
> provide an additional layer of security. (For example, if gpg had
> some bug that left some information behind in .gnupg pertaining to
> the key, this would still prevent people that get a hold of the
> card to access those.) LUKS should probably be optional, but
> something to think about.
>
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.
Regards,
Daniel
Reply to: