making a Debian Live CD for managing GnuPG master key and smartcards

[Daniel Pocock]

On 27/04/16 15:39, Peter Lebbing wrote:
> On 26/04/16 09:53, Daniel Pocock wrote:
>> There has been some discussion on debian-devel[1] about making a
>> bootable Debian Live CD specifically for GnuPG
> 
> I think this is interesting, and I would probably use it. But I'm just
> doing it out of interest, not because I have particular security needs
> (other than protect my network and the hosts on it from network-based
> hackers).
> 
>> - has anybody already seen anything like this?  Nobody likes
>> re-inventing the wheel
> 
> I'm not personally familiar with them, and I see Tails is even mentioned
> on the wiki, so you're already aware of it.
> 
>> - can we call all the necessary GnuPG commands from a script without the
>> user interacting directly with GnuPG, using "--batch" / unattanded
>> operation?  The sequence of commands involved would be similar to this
>> blog[3]
> 
> A bunch of stuff can be sanely scripted, but unfortunately there are
> also cases where this can lead to a very suboptimal or kludgy solution
> and GPGME would be the better way to go.
> 
> I notice in the blog this person used GnuPG 1.4.x. I don't know why he
> does that; I would recommend GnuPG 2.0.x. GnuPG 2.1 introduces some more
> commands and features that are well suited to scripting, but I think it
> could well be too new for a Debian Live CD. You mgi
> 

Debian jessie (stable) has 2.0

2.1.x is in testing and could potentially go to backports if it is
necessary to use it.

https://packages.qa.debian.org/g/gnupg2.html

> In fact, you mention ECC keys on the wiki. GnuPG 1.4 does not and will
> never support ECC keys.
> 
> Incidentally, when you use GnuPG 2.x, you can drop the 'use-agent'
> statement from the configuration file which is a 1.4 thing: 2.x always
> uses the agent.
> 

Thanks for pointing that out, removed from the wiki

You are very welcome to sign up for a wiki account too if you would like
to tweak it directly

>> - what would be the preferred way for the GUI to obtain and keep the
>> master key passphrase without prompting the user to re-enter it for
>> every operation?
> 
> I am of the strong opinion that this should be left to the default GnuPG
> mechanism: the agent, combined with a (stock) pinentry. The agent will
> remember passphrases for 10 minutes by default, but it is configurable
> (not to an unlimited number, but there is some number like INT_MAX or
> similar to emulate it).
> 
> The pinentry is responsible for securely querying the user and the agent
> for securely keeping the secret in memory. They have been expressly
> designed with this purpose. In your specific use case, with swap and
> network disabled, I suppose it would matter less, but if you find agent
> and pinentry unsatisfactory, perhaps the correct course would be to
> discuss improvements to them rather than spin your own solution.
> 

So far there has been discussion about using text-based UIs such as
whiptail (shell scripting) or Urwid (Python)

Can anybody point me to an example of using pinentry with either of
those?  Or will it just work on the basic black and white console?

>> - would anybody else like to suggest improvements to the workflow?
> 
> I have some suggestions.
> 
> You state that a smartcard reader with dedicated PIN-pad protects from
> keyloggers. While there is some truth to it, it is not a panacea. The
> firmware of the reader should not have a security issue where it accepts
> rogue firmware updates, for instance. Or you could turn on the
> microphone and listen for the cadence of the keypresses, or pop up a
> message to the user saying that the PIN-pad of the particular reader is
> not supported and request them to type on the regular keyboard. The
> latter could take the form of a downgrade attack, where the malware
> strips the part of the USB configuration descriptor describing the
> PIN-pad support. In fact, I think this is the most low-tech solution
> that would work pretty well in practice, so I'm putting my money on this
> "solution". It works equally well with a hardware dongle hidden in the
> connector of the smartcard reader, like a hardware keylogger in the
> keyboard cable.
> 
> You save the private keys to flash storage. I'd like an option to use
> writable optical storage. It's cheaper (per storage unit), you can
> refresh it every so often for a low price (completely disintegrating the
> old disc and throwing it out).
> 
> Additionally, I think paperkey[1] would make an excellent addition to
> the software installed. Although I heard that a 4096-bit RSA key[2]
> would take a lot of typing if it didn't scan with OCR. Oh, a good
> OCR-font for printing, also good to include. Anyway, I considered a
> 2048-bit RSA key quite typable in an emergency; I have paper backups of
> my master and my encryption keys. The signature key is unneeded as you
> can just create a new one when you lose it.
> 

paperkey is already listed in the wiki and printing is mentioned, it
should have been in the workflow too, now it is added there.

> I'd recommend a reading of the questions in the GnuPG FAQ[3], and
> checking whether any apply to your project. Thought, discussion and
> consensus have gone into the drafting of the FAQ, it is a valuable
> source of information.
> 
> I'd suggest to support only OpenPGP smartcards, not PKCS #11 tokens. The
> latter requires a lot of tinkering to get to work, and to make it into a
> Live CD that runs on a fair multitude of systems? I think it would be
> difficult, and the cost/benefit tradeoff seems bad. OpenPGP compatible
> cards are not expensive. They were designed to offer a good alternative
> to PKCS #11 in the first place.
> 

This was raised on another list.  I would potentially start with OpenPGP
cards and then anybody keen on PKCS#11 could add support for that later.

> Regarding expiry periods, I think they are too soon. I think the main
> feature of expiry is to eventually disable a key to which the private
> part has been lost. The purpose of this is to ease the selection process
> when fetching a key from the keyservers. I consider several years to be
> sufficient for this purpose, and subkeys need not expire sooner than
> master keys.

Some people actually want shorter expiry, every 1 - 3 months, although I
am not advocating that so far.

One goal of making this simple with a Live CD is that people can
regularly boot into it and extend their expiry without having to think
about the commands to execute.

> 
> Finally, I'll finish with how I've done it myself:
> 
> - I burned a generic Linux Live CD; I'm fairly sure it was Knoppix.

Did this have all the necessary things (GnuPG 2.x, paperkey, smartcard
support) in the image?

> - I removed the cables from any hard disks and unplugged everything that
> was not needed, especially network cables. I didn't have any wireless
> communication in the system, otherwise it would have been removed if
> possible. I didn't remove any expansion cards.
> - I booted the Live CD, and created RSA keys with GnuPG.
> - I burned the private keys to a DVD-R, passwordless.
> - I printed a paperkey backup, passwordless. I don't have a revocation
> certificate as I can revoke the key with the private key material, which
> I intend not to lose. It was a personal choice, it is not a recommendation.
> - I transferred the keys to smartcards. I use a setup with a smartcard
> holding the master key and another two holding (identical) signature and
> encryption keys. One of those two also has an auth subkey.
> Unfortunately, the multi-smartcard solution requires packet surgery on
> the private key files to work in GnuPG 1.4 and 2.0: otherwise it will
> only ever accept either the master key one or a subkey one, but never both.
> - I deleted all private key material.
> - I inserted a USB stick, mounted it, and copied the public keys to it.
> - I turned the PC off.
> 
> It was a few years ago, I might have a mistake in the details. The DVD-R
> and the printout are stored in a secure location. I decided that I
> didn't want to forget the passphrase to them and that a very simple
> password would not offer any real security, so I'm depending on the
> physical security of the storage. By now, I'm used to using a password
> manager, and I think I would never forget the password I currently use
> for that (difficulty: you've already memorized it, per XKCD[4]), so I
> might use that instead.
> 
> I hope this will be of use to you. I don't have any experience with a
> situation where I depended on the security of it all, nor experience
> with the other side of the equation, trying to break someone else's
> security. I'm just a hobbyist. But a lot of thought has gone into it,
> and I vied to keep the thought process academical and well-funded, and
> not based on gut feeling. No warranties though...
> 
> Thanks for your efforts! I appreciate them; Debian in general and this
> Live CD in particular.
> 

Thanks for sharing your own experience with this.  I hope that this
effort will evolve to capture the best bits of everybody's experience.

Regards,

Daniel