########################## DIY Offline Key Management ########################## I have a Pogoplug V4 running Debian (as per :ref:`sysadmin_embcomp_pogo4-hardware_debian`) which I use for offline key juggling tasks. This machine has never been directly connected to a computer network since it was installed and had sensitive key material on it. It has two very simple, controllable interfaces to the outside world: * a CD-ROM drive, for bulk data imports. * a serial terminal with limited memory for small interactive imports and exports. I have used this setup to generate (and manipulate) my :download:`new PGP key ` and my :doc:`OpenVPN keying material `, to date. It was, if nothing else, an exercise to see if I *could*. It is presented here in hopes that it is useful to someone else, but of course I cannot warrant that it is a sensible thing to do or that it actually lives up to its intended purpose. .. note:: The Marvell Kirkwood chipset in the Pogoplug is very, very friendly as I've briefly documented elsewhere. It doesn't really do the whole trusted boot thing, which makes this perhaps more of a toy than it could otherwise be, or at least means that physical security of the machine is more important than I'd like. Attack Model ############ I am worried about easy attacks like software being compromised and much less so worried about aggressive attacks like breaking into my apartment or RF emissions monitoring. I am reasonably sure that anyone who really meant it could defeat this system trivially ($5 wrench?) but it at least raises the bar to "they have to want to." It is, hopefully, a few steps better than "kid-sister" security. Theory of Operation ################### The basic idea is that this box lives in a safe 100% of the time it's not being used and, when it is being used, it's offline except for strictly human-mediated interactions with the outside world. The box is driven through a portable serial console that also spends its offline time in the safe with the box itself. To help ensure human mediation of data transfers, *only* configured smart-cards and the serial console are permitted to repeatedly visit both the networked world and the secure box. Most data flows only from the networked world to the secure box and never leaves. It's imperfect (programs could slowly leak state through subliminal channels such as padding within transferred files or through conspiring smartcards) but it's pretty OK. Bill Of Materials ################# * Fireproof safe (I use a SentrySafe with 4-number analog dial and key.), * Pogoplug v4 and power supply ($15 or so), * 32GB microSD card ($10), * 2 USB RS232 cable ($5 ea), * Psion 5, AA batteries, coin cell battery, serial cable. ($50) * Laptop SATA CD-ROM drive and USB slim-line SATA CD-ROM cable ($10, but of course a USB CD-ROM drive is isomorphic. I had these on hand.) * A piece of paper on which I have *manually* written down a large random passphrase which gets used to encrypt the device configuration for export to the insecure world. * Optional, but highly recommended, a supercapacitor-backed I2C RTC ($5). I recommend the use of two USB/serial bridges so that one does not visit both the secure and insecure world repeatedly; USB is a remarkably complex protocol and presents a larger attack surface than a terminal emulator and RS232. Alternate Serial Devices ======================== While I love my Psion for this, I recognize that perhaps they're harder to find than I'd like. Similar devices that I strongly suspect would work (feedback welcome) include * HP 95LX/100LX/200LX/1000CX (DOS) * HP 300LX/320LX/360LX (WinCE 1/2) * HP Jornada 680/720/728 (WinCE 2.11/3) * Philips Velo 1 (WinCE 2) * Psion 3/5/5mx * Sharp HC-4500 You'll want something that... * is easily stored with the device (so, tiny is better) * has a reasonable keyboard (you'll be typing for short periods) * has a reasonable terminal emulator, ideally with ``XMODEM`` built in (or at the very least the ability to selectively copy and paste; ``base64`` would then be your friend) * ideally has a back-lit display (I find them much easier to read) You'll want to avoid anything with WiFi or Bluetooth connectivity, just to keep your attack surface down, which pretty much limits your options to vintage gear. (Note that XMODEM is not the greatest transfer protocol, but it appears to be the best I can get on my Psion device. I often end up ASCII-armoring or base64-coding the data to be transferred, because it is not a very reliable channel otherwise. This does slow transfers down by about 30%, but they're not that big to begin with.) Typical Interactions #################### Common Startup Steps ==================== * cable up and boot machine * log in * Unlock and mount the encrypted partition containing keys:: cryptsetup luksOpen /dev/mmcblk0p2 /dev/encpart mount /dev/encpart /media/encpart Common Shutdown Steps ===================== * Power down and pack up the secure machine:: umount /media/encpart cryptsetup luksClose /dev/encpart halt Configuring a Smart Card ======================== * Start up the secure machine * generate keys on the device, possibly with ``gpg2 --gen-key`` * load them onto a smartcard (see, e.g., :doc:`/sysadmin/openvpn-piv`, or ``gpg edit-key``'s ``keytocard``) * use ``XMODEM`` to send the *public* components to the serial terminal:: sx pubkey * encrypt the private keys (under a backup key) and send that blob to the serial terminal:: gpg -c --passphrase /media/encpart/backup-key-phrase -o privkey.crypt privkey sx privkey.crypt * Power down the secure machine * Move the serial console's link to the insecure world and use ``XMODEM`` again to move the public keys and encrypted private keys to the insecure world. I like CKermit on the insecure side for this :: recieve /protocol:xmodem privkey.crypt Signing a PGP Key ================= * Use ``XMODEM`` to transfer the key you wish to sign to the serial terminal. * Start up the secure machine * Use ``XMODEM`` to transfer the key from the serial terminal to the secure machine ``rx newkey.pgp`` * Import the key: ``gpg2 --import newkey.pgp`` * Edit and sign the key * Export the signed key: ``gpg2 --armor --export ... > newkey.pgp`` (The use of ``--armor`` may not be requisite, but it doesn't hurt much) * Use ``XMODEM`` to transfer the exported key back to the serial terminal:: ``sx newkey.pgp``. * Shut down the secure machine * Use ``XMODEM`` to transfer the signed key blob to the insecure world. Upgrading ========= Ah, now here's where the CD-ROM comes in real handy. Burn the Debian upgrade DVDs, haul them over to the secure machine, upgrade via ``apt-cdrom`` and all that, and optionally destroy the disks if you're feeling especially paranoid. System Configuration #################### * I built a custom u-boot that knows how to boot off mmc ext4. You can grab it from my :doc:`page about the pogo v4 hardware `. * The SD card is partitioned into an 8GB root partition, which is naked ext4, and the rest is a LUKS cryptographic partition housing another ext4 filesystem. * The root partition holds a pretty stock Debian Stretch kirkwood install. I've installed a few packages which make the device useful in its role as a cryptographic key manager: * ``haveged`` helps keep the system entropy pool topped off. I believe this is perfectly secure, but you're free to leave this package off! * ``lrzsz`` for exchanging files over ``XMODEM`` with the Psion 5. * ``easy-rsa`` for generating TLS PKI goo, notably for OpenVPN. * ``gnupg2`` of course, notably for configuring OpenPGP smartcards. * ``yubikey-piv-tool`` for configuring the Yubikey PIV application. One does have to tell systemd to spawn a console on ``/dev/ttyACM0``, the serial port used by the serial console. .. todo:: Write how Setting up the LUKS partition is straightforward. .. todo:: Write how The RTC, if you attach one, can be brought up more or less automagically at boot by writing into ``/etc/rc.local`` these lines or whatever is appropriate for your system:: echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-0/new_device hwclock -u -s Since the machine is offline and has no other way of synchronizing time, you might wish to occasonally check it and update the RTC with ``hwclock -u -w`` as root.