Friday, April 15, 2011

Key backup for the paranoid

When doing this GPG key work, I realized that if by some chance drives failed and USB keys no longer worked right, I'd be unable to access tons of data backed up encrypted with them. I wouldn't want to backup the GPG keys in the same way as my other data due to the sensitivity.

Some conventional methods of backup that can be used as a "standard" item to handle recovery:

  • CD/DVD backup
  • USB Flash Drive
  • Hard Drive
Hard drive backup is somewhat out of the question as using an entire hard drive for backup and putting in a safe is out of my budget. USB flash drives paired with optical backup work great as a "fast" recovery mechanism in case something goes wrong. The problem with these is that testing them as backups is somewhat tedious.

Here's where paper comes in. You print out your key data in some form that can be input back into the computer in a reasonable manner. Now this may seem backwards, but it is quite useful for backup. You can easily print say, 10 copies of the key, slip them in something to reduce air exposure, and put them in safe deposit boxes / home safe / etc. For recovery check, you can visually inspect them to make sure that they are not degrading. To test thoroughly, you can take a small sample (ex: 1 from each backup location) and attempt a recovery. Redundancy with paper backup is quite trivial.

Now... how do you put the key on paper. You could print it in hex or base64-encode it and OCR or manually type it in... but that is tedious and error-prone. For high-density machine-readable data storage on paper you can use 2D barcodes. These typically have error-codes builtin to help manage slight flaws in the paper or scan. A good article at Coding Horror, The Paper Data Storage Option illustrates some mechanisms for paper backup. I tried stuffing backup data into QR codes and datamatrix blocks, but found that the encoding/decoding software available were quite finicky. Another problem with these formats was that they are not intended to store bulk data. There must be some other good way of encoding data for printing and recovering...

In steps in the mentioned Windows application PaperBack by Oleh Yuschuk. This tool takes an input file and prints out dotted pages arranged in blocks to store your data. It provides redundancy through duplicating blocks and arranging throughout the pages as well as error-checking codes within each individual block.

I also tried the Twibright Optar paper backup mechanism, but ran into the problem that it expected a high quality printing medium and I found it hard to tweak it to work with my readily available inkjet. Of course for final usage, laser printing would likely yield high enough quality to meet my needs.

The two backup mechanisms have their pros and cons.

PaperBack
Pros:

  • Easy to use - builtin printing and scanning capabilities
  • Visual display of the quality of the scan, permitting visual detection of where your backup may be degrading
  • Easy customization of DPI, dot-size, redundancy
  • Good reliability even in the face of injected errors through gimp
Cons:
  • Windows only - right now
  • Imports/Exports only as bitmap if not using direct print/scan

Twibright Optar
Pros:

  • Linux-compatible
  • Provided documentation describes the theory of how the encoding works well
  • Better data density
  • PNG input support
Cons:
  • Needs hand-edited code to change dot-size
  • Seems to be very sensitive to artificially introduced errors through whole-image noise/damage/rotation

I selected PaperBack as my primary backup mechanism since it met my needs and provided an easy way to tell how "bad" my backup was. I took my GPG secret key blob, sent it to PaperBack for handling and was able to pack on less than a single sheet of paper with the lowest DPI (80) and a redundancy of 10 block copies, and AES encryption of the entire data blob (beyond what GPG protects the key data with). Recovering was fast, however showed errors right from the start. These errors were quite recoverable and well within the range were errors could be recovered from. Seeing how useful paper/image-based data transfer is, I intend on using a QR or datamatrix code that has my public key information (ID/thumbprint) to help make key signing & simple detection of what key should be used for verification/encrypted-email.

With a paper copy in protected locations, I can be even more certain that the lifetime of my GPG keys will be beyond the lifetime of the machine in which they came from. The sort of thing becomes quite important when protecting information that may by chance or specifically on purpose outlive you.

No comments: