In light of BadUSB, storing private keys on a USB flash drive is not the best way. What about writing private keys to a CD?

What I am worried about is whenever I plug my private key storage device into the machine, it opens up the possibility that any rogue process may take over and steal the keys.

I have a private key used to encrypt all my other passwords and keys. This way I have a single key to worry about protecting. but it also opens up a single point of failure.

How can I securely store this key?

I was thinking that a QR code printed on paper may be a great way to password protect a private key. But then that leads to how to securely decode the QR code and decrypt the private key.

  • In that case, you'd still be plugging a compromised USB drive into your machine - badusb itself isn't a requirement. So existing attacks should still work just fine (ie, Stuxnext didn't need it to do its work). badusb is really more about how firmware isn't properly protected, meaning you have some extra ways to hide/attack... but you still have to hit the USB key in the first place. Nov 29 '14 at 14:09
  • Don't forget that the dyes used in recordable CDs have a limited lifetime. It would be a revolting development if the one and only medium with that key became unreadable.
    – Bob Brown
    Jan 24 '15 at 2:29

You want to investigate a Hardware Security Module. This offloads the keys (and the crypto processing) to a hardened device from which the keys cannot be extracted.

The best known ones are from Thales and Safenet, and they offer versions that are local PCI boards, locally attached (via USB) and network-attached.

If you only have one or two keys, you can also use a USB token, which is a small, low-end HSM in a form-factor similar to a thumb-drive. Another alternative is a smart-card or CAC, which is the chip from a token in a PVC card that is the same size as a drivers license or passport card, or like a very chubby credit card.

In any of these cases, you would install a driver and engine (both are software constructs) to access the device. From here, you would not have access to the key, and would instead access it via the PKCS#11 API interface or the Windows CryptoAPI, which would wrap the request to have the encryption/decryption on your behalf in hardware.

I would also recommend to have three of these devices, of the same type. When you gen and import the keys, do it on all of them, and then test-encrypt the same string with each and compare the output. If it does not match, beware. The first one is for online use. The second is for near-line backup (if it were pocket-sized, in your safe or in your secretary's locking filecabinet) . The last one is your DR/BC copy, and that should stay with your lawyer, with written instructions about when and to whom it can be released. Put simply, over a long enough time, these devices can fail, but are statistically unlikely to all fail together.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.