6

I have a couple of private keys that I use to administer Amazon EC2 instances.

I recently lost these keys when I did a re-install of my computer and I found out that the CD-RW I'd backed them up to was unreadable. So, I'm looking for a slightly more robust backup solution and I'm thinking about using something like Dropbox, because it uses SSL for confidentiality of transport and then my data is stored securely.

Is the risk I take backing up my keys on a service like this purely that the provider could screw up or be corrupt, or have I missed something else?

Update: The private keys have a pass phrase.

brabster
  • 173
  • 1
  • 7
  • 7
    I'd encrypt the keys prior to shipping them to any third party, but that's just me. I'm not very trusting of infrastructure I don't support. – Evan Anderson Mar 13 '12 at 21:15
  • 1
    @EvanAnderson Of course, then you have to store the encryption keys somewhere. – ceejayoz Mar 13 '12 at 21:41
  • Brabster, these private keys are ordinarily stored encrypted to a passphrase known only to you, yes? Or are you asking us about the wisdom of storing **unencrypted** private keys on a cloud service? – MadHatter Mar 13 '12 at 21:42
  • @ceejayoz: I'm talking about encrypting them with a passphrase known only to me and storing that key in my head. – Evan Anderson Mar 13 '12 at 21:59
  • Yes, using a pass phrase on my keys. – brabster Mar 14 '12 at 21:46

2 Answers2

14

There's also the whole "Dropbox can read your stuff" problem.

What you should do is encrypt everything before putting it into Dropbox. Use something like KeePass as a secrets vault. Put a good password on it. KeePass will encrypt locally, before putting your stuff into Dropbox. You will then use KeePass on other computers to access those secrets.

Take a look at:

https://superuser.com/questions/351525/is-keeping-a-keepass-file-in-dropbox-safe

So, in summary, encrypt locally. Use Dropbox to sync those encrypted files.

Community
  • 1
cjc
  • 24,916
  • 3
  • 51
  • 70
  • 1
    But that gets you into a chicken-and-egg problem; the private keys you encrypt have themselves to be encrypted to a private key. Where do you keep copies of **that** private key? – MadHatter Mar 13 '12 at 21:30
  • 2
    You keep the master password in your head. Maybe also on a slip of paper in a bank vault if you get hit by a bus, and your wife needs to open the files. – cjc Mar 13 '12 at 21:30
  • Unless I'm gravely mistaken, **very** few things that offer decent encryption actually encrypt to a passphrase; few human beings can reliably remember passphrases with enough entropy. Instead, they create nonce keys, encrypt to those, and store the encrypted nonce key under the passphrase. That given, where do you keep that nonce key? – MadHatter Mar 13 '12 at 21:32
  • Well, the discussion of the KeePass's key derivation is at http://keepass.info/help/base/security.html#seckeyhash and my passphrase is 30+ characters long. Yes, the passphrase has less entropy than a properly generated encryption key, but I believe it's more than sufficient for this purpose. – cjc Mar 13 '12 at 21:36
  • And that's a fair enough belief. But if you hold it, then where's the harm in uploading encrypted private keys to the cloud as-is, as the original poster proposed to do? – MadHatter Mar 13 '12 at 21:40
  • The OP offered no indication that the private keys were encrypted. – cjc Mar 13 '12 at 21:43
  • cjc, you are right, and I've asked for clarification on that. If he is indeed proposing to store unencrypted private keys in the cloud, then I freely concede that your suggestion is much more secure than *that*. But assuming that he's asking about storing encrypted private keys in a cloud service, then I'm not convinced that your suggestion is both more robust and more secure than his proposal. – MadHatter Mar 13 '12 at 21:45
  • Yes, I agree with you. A container like KeePass will not be significantly more secure than simply encrypting the private keys. I think we were talking at crosspurposes because we had different interpretations of what the OP was planning. – cjc Mar 13 '12 at 21:55
  • Agreed - anything that goes in my Dropbox acct is either worthless data, or goes into a 1Password or Truecrypt volume. – EEAA Mar 13 '12 at 22:04
  • @MadHatter: To solve your chicken-and-egg problem, you can use public/private key encryption rather than symmetric encryption. On the destination computer, make a new key just for transferring (make it expire in a few days). Put the PUBLIC key in Dropbox to get it to the source computer. Source computer encrypts with public key and drops encrypted file in Dropbox. On destination computer, decrypt with PRIVATE key (making sure to not output the decrypted output into the Dropbox folder). – MidnightLightning Feb 29 '16 at 22:24
  • @MidnightLightning you may wish to read the question, answer, and subsequent exchange of comments above more carefully, as we are all already talking about asymmetric cryptography. The question is about where, and how, to store offsite copies of the public keys that must eventually underpin such a strategy. – MadHatter Mar 01 '16 at 06:59
  • @MadHatter: Ah yes, "symmetric" is the wrong term; some were speaking of password-encrypted private keys. My suggestion works for temporarily getting private keys moved around, but for long-term storage I see your point, and I'll clarify my suggestion in an answer of its own. – MidnightLightning Mar 01 '16 at 14:15
  • In my comment above, "public keys" should of course read "private keys". Sorry. My bad. – MadHatter Mar 01 '16 at 14:35
-1

If you have a private key you wish to keep safe (I'll call it Key A, which could also be a collection of private keys tarred together into one file to keep safe), create another public/private key pair (Key B).

Securely copy Key B around to multiple computers that you trust. This can be done by creating a temporary public/private key pair (Key C) on the destination computer, transfer the Public Key C to the original computer, encrypt Private Key B with Public Key C, and transfer the encrypted file back to the destination computer where Private Key C can decrypt it.

With Private Key B on several machines you trust, encrypt Private Key A with Public Key B, and place that file in secure storage (could be on a location you don't trust, like Dropbox).

So, then if ever Key A gets lost/corrupted on your local workstation, it's an easy/quick restore to grab the Key-B-encrypted-Key-A file from Dropbox and decrypt it to restore.

If Key B gets lost/corrupted, you still have Key A, so you could just create a new Key D to replace Key B and do the setup again, or go grab a copy of Key B off one of the other computers you trust you made copies of it on.

If your whole computer is lost (you lose Key A and Key B at the same time), you will need to go to one of the other computers with Key B on it and grab the Key-B-encrypted-Key-A file from Dropbox and decrypt it to restore Key A.

So, this plan allows Key A to be kept safe using traditional backup options copying the file to many (possibly untrusted) locations, which opens up offsite, offshore, and off-planet options. It also means Key A can be restored quickly if need be, as the Key-B-encrypted-Key-A file can be passed around untrusted, so can be attached to emails or whatnot.

It keeps Key B safe by being on multiple trusted locations. This being ServerFault and not SuperUser, we're likely talking in a corporate setting, so hopefully the corporation has local servers and co-located servers they trust that can host such things. In addition to live, running servers, copies of Key B can be put on offline storage (tape backups, archival CD, etc.) in a bank vault or similar. Restoring Key B then becomes a slower process as you may have to visit the bank vault to go get a copy, and you should be checking those offline backups periodically, so you can catch the situation like the original post where the CD went bad.

MidnightLightning
  • 315
  • 3
  • 9
  • "*With Private Key B on several machines you trust*" **if you have safe places to keep copies of a private key, you don't have the original problem**, which is about how to safely keep distributed copies of private keys. – MadHatter Mar 01 '16 at 14:42
  • True, you could just keep Key A in those locations. But then with the same trade-offs: slower turnaround time to restore, and possibly increased risk of losing all copies at once if not done well. – MidnightLightning Mar 01 '16 at 15:01
  • The latter applies equally to key B. And why it is slower to restore by directly getting key A, than by getting key B from the same places then using that to decrypt a local copy of key A? – MadHatter Mar 01 '16 at 15:32
  • "the latter" meaning "losing all copies at once"? In this scheme, the encrypted Key A can be stored in an untrusted location, which everyone has inherently more of than trusted locations. Therefore the risk of losing all the encrypted Key A copies is less. In a typical restore setting, yes, speed would be the same if you have a local copy of Key B. However, in the situation of losing a whole computer, driving to the bank to get a copy of Key B out of the vault is slower than going to any working computer and logging into Dropbox to get another copy of the encrypted Key A. – MidnightLightning Mar 01 '16 at 15:39
  • I don't particularly want to get into a lengthy discussion on alternatives to a four-year-old question with an accepted, upvoted answer, so perhaps I should leave it at "*I am unsatisfied with your answer*". – MadHatter Mar 01 '16 at 15:59
  • Fair enough; I elaborated to hopefully patch a hole you poked in cjc's answer, which you apparently still think is a hole, so I'll leave it at that. – MidnightLightning Mar 01 '16 at 17:38