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

[Peter Lebbing]

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

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.

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

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

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.

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.

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

HTH,

Peter.

[1] http://www.jabberwocky.com/software/paperkey/
[2] I'm not going to debate recommended key lengths. But please be aware
that the GnuPG FAQ[3] has a section about it.
[3] https://gnupg.org/faq/gnupg-faq.html
[4] http://xkcd.com/936/

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>