I have a Pogoplug V4 running Debian (as per How to Install 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:

I have used this setup to generate (and manipulate) my new PGP key and my 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.


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

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

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., Using Yubikey 4 for OpenVPN, 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.


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

One does have to tell systemd to spawn a console on /dev/ttyACM0, the serial port used by the serial console.


Write how

Setting up the LUKS partition is straightforward.


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.