Strategies for offline PGP key storage
lwn.net
lwn.net
I use intermediate certs for my internal CA and do keep those private keys online for quick and easy generation of new certs but the root cert private key only exists in physical form under my control. It's a bit of a pain to convert the root key back into digital form but I only have to do this every couple of years when the intermediate cert expires.
I got into a habit of writing shell scripts for every certificate related task to make it easier. I use the dialog(1) utility to prompt me for input when that's needed. If things are easy, you're more likely to do them.
As you mentioned fire-resistance, do you also use some sort of fire resistant paper? Because I don't think anything in made of paper would survive an actual fire.
You want a pen plotter. Or its cheaper, more expensive cousin, the Axidraw.
> As you mentioned fire-resistance, do you also use some sort of fire resistant paper? Because I don't think anything in made of paper would survive an actual fire.
Actually there are document safes with built-in insulation which will keep regular paper documents safe for time X under fire conditions Y (it's some EU standard classification). Certain ways of mounting safes makes them intrinsically fire-safe(r) as well.
Huh. It's cheaper (worse quality) but costs more money?
[1] https://www.amazon.com/pen-plotter/s?ie=UTF8&page=1&rh=i%3Aa...
Elliptic curves are nice because they allow short keys, for example curve25519 uses 32 byte keys that are pretty reasonable to copy manually (44 base64 chars or 64 hexs).
Meaning you could use PBKDF2 of your favorite passphrase as your private key, then keep it in organic memory.
Personally, I would love to see a strategy for generating a private from an analog picture.. But I don't see a good way to do it reliably.. Maybe one could generate it from error correction bits in a QR code.
I'm working on a blog post on deterministic passwords (i.e. not keys for ECC), but I guess that if you really want determinism you can do something similar, maybe sha3.512 and "cut" a 256-bit ECC key.
This is the post, still a draft. Hopefully I'll publish it next week, but if you have any comments, they are more than welcome! https://medium.com/@0x0ece/how-i-manage-my-passwords-technic...
Not clear exactly what you meant, but but deriving a key from a photograph shouldn't be that difficult. A good perceptual hash should work, maybe some preprocessing is needed (straighten/crop/normalize/resize). It helps that the amount of data in an image is absolutely massive compared to typical key size.
So you can do something similar. Pick a deterministically generated bit string, and use as key the next prime number (you need to do it twice, for p and q).
You certainly get less security and I unfortunately don't have any reference to quantify that.
As I was saying in another post, I'm writing about deterministic password generation (i.e. not RSA keys). Draft here: https://medium.com/@0x0ece/how-i-manage-my-passwords-technic...
Before: 2^2048, After: 256^20 = 2^160 (when using a 20 key password. Obviously you could use looong random generated passphrases, but then you could just base64encode your key?)
Symetric and asymmetric encryption don't have the same key length standards.
It'd be amusing if someone stole your vault, but left its contents.
Having moved 5+ times in the last decade, I'd dread thinking about having to move that safe you linked to.
> old man driving a pick up truck literally carted it away
hmm emoji.
http://ftknox.com/wp-content/uploads/2013/09/ANCHOR-LAYOUT-D...
https://www.amazon.com/US-Mint-Quarter-Covert-Compartment/dp...
Once in a blue moon when the intermediate cert expires, I pull out the QR code and scan it and convert it to a PEM on a burner laptop, VM, or phone. There I generate a new intermediate and securely delete the root PEM file and put the QR back in the vault. Then I copy the inermediate off the burner machine and go about my business.
- the latter is a joke ofcourse! :)
For plausible deniability it's a lot less controversial to mix a broken yubikey in concrete and cast it as pavement.
$ gpg2 --export-private-keys
"Optar stands for OPTical ARchiver. It's a codec for encoding data on paper or free software 2D barcode in other words. Optar fits 200kB on an A4 page, then you print it with a laser printer. If you want to read the recording, scan it with a scanner and feed into the decoder program. A practical level of reliability is ensured using forward error correction code (FEC). Automated processing of page batches facilitates storage of files larger than 200kB."
But for elliptic curves you only need a few bytes.
If you ever need to restore it, yes it will take ~45 minutes to hand type the key back into a new computer. Oh well, that's the tax you pay for restoring your backup or making a new subkey.
Civilization has long figured out how to store paper. I've grown to respect how powerful a printer and some patience can be for key backups.
EDIT: I think most of the replies are missing the point. I want to keep things barebones. The only thing that should be required to recover is a copy of GPG. No qr decoder, script, or other nonsense. If you depend on something else for recovery, you are putting your trust in that. I trust GPG, paper, and my eyeballs.
Also: https://xkcd.com/1319/
It's just a python script that converts a piece of text of arbitrary length, into a series of QR codes.
I then plan to work on the "decoder" side, which takes a series of QR codes and outputs the original text. Basically just a concat of the QRs.
The idea is that I'll print my private keys in both text and QRs so that I can easily recover the digital form if needed (and if that doesn't work, then I'll type it... Ugh).
Hopefully I'll be able to finish it and do a Show HN sometime this year.. (or maybe the next).
We just need the decoder then! :)
So I'm guessing there's definitely some need for a tool like this, right? I mean, being able to "QR-codify" any text and later getting it back could simplify some of these offline-storage actions, right?
HTTPS://github.com/matheusd/pypaperbak
I might play with Tesseract[1] this weekend and see if this is even a feasible idea. If so, it makes the paper key storage a lot more palatable.
I never got even close to getting useful results. I tried limiting the alphabet, disabling language models as far as I could and at most I could get a few recognizable character sequences right out of the whole page. I got the impression that the whole thing very much depends on being able to split text into English words and have easily separated paragraphs.
A keycard will avoid (with very high probability) the theft of the private keys, but in most cases this is not that important, if an attacker can do individual sign/decrypt/encrypt operations on demand it will be more than enough for him.
Unfortunately for some reason it looks like almost all the recent affordable key-handling devices lack an external keypad. There's either some misconception about their security or some wilful scheme to give a false sense of security to the people who use them (I wrote it tongue-in-cheek but actually we've seen worse...).
Also, it's not true that "a key generated on a keycard cannot be backed up", most devices permit the export and re-import of keys by first encrypting them with a key known only by the device (and not exportable); these will effectively be back-ups, although they're only useful against the accidental deletion of the keys, not against the loss/damage of the device. By the way, this feature is also notable for being the source of vulnerabilities in many devices that made it possible to extract the raw keys.
P.S. I don't know why the author uses that unusual "keycard" term, I assumed he means smartcards or dongles
For what I can remember when I looked into them, a few months ago, keys/data storage, signing and decrytpion where at least as much advertised as authentication.
And in most cases external confirmation is useful/strongly advised for authentication as well.
Case in point, I personally needed a token for code signing, it's almost impossible to find one with a pinpad. It's easier if you settle on a smartcard + smartcard reader (which I don't think many developers do).
It's not perfect, but security is always a balance between the risks involved in practical solutions and then risk that users side-step convoluted solutions :)
I really don't like the idea of storing anything really critical on a usb drive or an airgapped system.
I don't have an airgapped computer just laying around that I can store secrets on (and keep alive), and I don't trust a usb drive to last.
I really wish there was something like a clean way to store an encrypted printout that could be scanned years later if neccesary, ie a method of storage that I actually have faith would reliably survive for a decade or more.
Alternatively, if this is a "oh, shit" backup solution, you could just print and laminate the key, and enter it by hand years later, if necessary.
(This is just me thinking off the top of my head, mid-coffee. Ideas may be less valuable than they appear.)
I'll actually be doing this soon I think. Previously I used http://www.jabberwocky.com/software/paperkey/ which is quite good, but it's like two pieces of A4 filled with text which would be a huge pain to restore.
But either way, you can print to paper and store it in a fireproof safe (or probably better still -- a safety deposit box). There are lots of methods for ensuring printed paper survives for a long time -- if you google it, I'm sure you'll find more than you want to know.
My personal method is storing passphrase encrypted on multiple USB drives (they're cheap) and replacing them every year or so (they're cheap).
I think a more interesting question is: how do I provide access to my non-technical wife in case I am incapacitated or dead? Especially, how do I convince her not to put the passphrase on a sticky note on the fridge?
The replacing every year or so sounds like the most robust way to do it with current best practices but that requires a lot of maintenance.
That would probably be the most robust method to withstand fire, rust and anything else.
You'd need access to a laser metal cutting machine for that though - or drill each hole one by one heh.
Using IBM 80-column cards you'd need just about 10 cards to store a 4096-bit key with three subkeys in binary mode. More if using char mode (might be preferred if you have to type them using keyboard). The key can be condensed for backup if needed. OTP and/or Shamir's method could be added to the mix to improve security, increasing the number of cards required, but even without Shamir you can split the deck in half and store in different places.
Longer, possibly foldable, punch tape is yet another option. If it has the same width as IBM 80-column cards then most of DYI equipment designed for the latter can still be used. It can't be metal though, only paper or plastic.
A bit of obscurity helps too, it's not like a deck of cards screams "this is an important secret" or possible attackers have card scanners with them when they invade your backup facility (although they can make photos and decipher them later so it's not real protection, just a small bonus.)
Now, how would we solve a problem of rubber-hose cryptoanalysis with it?
I have found that splitting the key in 256 bytes chunks, then QrCoding them is sufficient for my usage:
https://gist.github.com/Gui13/5e5fe0c7c67d55373767d4965b1638...
With that script, a 2048 bits key in PEM is about 4 pages (+ 5 others if I print it in text format), which I can store in a safe, and conveniently rescan using zbarcam anytime.
Kingston makes a fairly decent one. It's how we manage our root of trust right now. Two of those with root identity and reciprocally signed exec identities. All of the artifacts stored in git RSL repos on the HSM, the two HSMs sync'd via signed commits and merges so we have an audit trail, one HSM is stored on-site and the other off-site, and one can be checked against the other to measure for tampering. All of the initial provisioning happens on an air-gapped machine with intermediate artifacts that only live in a temporary RAM disk that itself is encrypted with a 4096 byte key that is never known to anyone (it's fed straight into the ecrypt tooling and discarded).
The next layer out from that is all Yubikey based.
It's an extremely cumbersome process to do normally, but we invested a fair bit of time in creating automated key ceremonies of different shapes to handle different parts of the process.
I looked at the Kingston website and nothing I saw looked like any HSM I've ever worked with. Just encrypted USB drives.
Adding to the insult, there actually exist many cheap USB proper cryptographic tokens, that really do all the operations internally and have even FIPS 140 level 3 certifications. They are just slower and have less physical protection, features and storage than "proper" thousands-dollars HSMs.
Note that the FIPS certification of those Kingston drives means just that the key with which the data is encrypted cannot (easily) be extracted.
Actually I've never looked before into "encrypted drives" and I don't know what do they do or what purpose exactly do they serve, I must have written that thinking about HSMs and other signing devices.
It does seem indeed that at least those Kingston drives do not store the encryption key (actually, they store it but encrypted with the password).
I'm not sure what purpose do the FIPS certification and all those physical protections serve, then.
The whole idea behind an actual HSM is that you never trust any computer it is plugged into, it is designed to be impossible to retrieve the key stored in the device via any means. All signing operations are done internally in the device itself - you simply can't mess up and accidentally leak key information.
This need not be a problem if the machines are truly air-gapped, and all interactions are conducted by typing & reading the screen. This is impractical for OpenPGP or X.509 keys & certificates, and generally for any system using RSA, but it's quite practical for SPKI certificates[0] and systems using Ed25519.
Updates aren't nearly so important with an air-gapped system: after all, there are no network attacks to worry about, and physical attacks can be dealt with physically.
Note that a truly airgapped machine does not have data transferred to or from it, even via a USB key. The whole point of an air gap is an air … gap.
[0] An SPKI certificate is human-readable and hence human-typeable. An example (taken from http://people.csail.mit.edu/rivest/spki-examples.txt) is below:
(sequence
(public-key
(rsa-pkcs1-md5
(e #11#)
(n
|ALNdAXftavTBG2zHV7BEV59gntNlxtJYqfWIi2kTcFIgIPSjKlHleyi9s
5dDcQbVNMzjRjF+z8TrICEn9Msy0vXB00WYRtw/7aH2WAZx+x8erOWR+yn
1CTRLS/68IWB6Wc1x8hiPycMbiICAbSYjHC/ghq2mwCZO7VQXJENzYr45|
)))
(do hash md5)
(cert
(issuer (hash md5 |+gbUgUltGysNgewRwu/3hQ==|))
(subject
(keyholder (hash md5 |+gbUgUltGysNgewRwu/3hQ==|)))
(tag
(* set
(name "Carl M. Ellison")
(street "207 Grindall St.")
(city "Baltimore MD")
(zip "21230-4103")))
(not-after "1998-04-15_00:00:00"))
(signature
(hash md5 |54LeOBILOUpskE5xRTSmmA==|)
(hash md5 |+gbUgUltGysNgewRwu/3hQ==|)
|HU6ptoaEd7v4rTKBiRrpJBqDKWX9fBfLY/MeHyJRryS8iA34+nixf+8Yh/
buBin9xgcu1lIZ3Gu9UPLnu5bSbiJGDXwKlOuhTRG+lolZWHaAd5YnqmV9h
Khws7UM4KoenAhfouKshc8Wgb3RmMepi6t80Arcc6vIuAF4PCP+zxc=|)))
I think you could probably do it for something like Ed25519, which has the nice property that any 32-bit string is a valid key, so all you have to do is type exactly 64 hex characters. But SPKI seems like a huge attack surface.
An SPKI parser + a manual keyboard operated by a trusted user is an incredibly small attack surface.
The process is surprisingly involved, and there's a lot of opportunity for error given gpg's dreadful user interface (not saving to keep the key on both the host and the keycard? wtf?).
I think there would be a lot of value in creating tooling around the "best-practice" setup, even if it's just wrappers around gpg commands. Scripts to setup the main key & subkeys, revocation certs, smartcards and backups, all that jazz. A Raspberry Pi image to act as an "air-gapped" computer for sensitive operations might also be part of this.
The 8GB Aegis drives are around $80. Unlock is performed via PIN entry. The drives are small and have a sliding case to protect the PIN pad, making them pocketable. The hardware is capable of wipe upon failed unlock attempts. Pairing these drives with a software-encrypted filesystem reduces the likelihood that a single-vendor fault could allow bypass and data access. This is a strong option for primary always-on-hand instances of offline data, which could be paired with some other secondary backup option from another vendor (like paper in a safe, HSM or additional encrypted USB keys).
When you start thinking about the storage of data offline over a decade, bit rot becomes a very real problem.
[1]: https://keysafe.branchable.com/ [2]: https://www.youtube.com/watch?v=AYegjnDWvww
https://wiki.fsfe.org/TechDocs/CardHowtos/CardWithSubkeysUsi...
Bitcoin Paper Wallets (2015) | https://news.ycombinator.com/item?id=15302500 (Sep 2017, 64 comments)
I wouldn't consider an option that didn't have a keypad. Are there any others?
But really it's largely enough to have a confirmation system, and that is supported also by the YubiKey 4, for example.
This assumes the attacker also knows the key's password. And we all use very strong, unique passwords on keys, right?
On this note, I have to say I'm a proud supporter of LWN. Their content is really top-notch, and at $7/mo, it feels like a steal.
I don't read a lot of LWN, but I LOVE the work they're doing. I maybe read an article a month, maybe even less, but I think that their model is great and appreciate their work. I used to subscribe at the regular rate, but never read LWN much and let it lapse when it was up for renewal and my history showed that I hadn't visited in 3+ months.
Would it be frowned upon to buy the starving hacker subscription, even if I am probably not a starving hacker, given that I rarely read it and just want to support them? $42/year just seems easier to stomach for something I know I'll never use, than $84. First world problem, I know, but curious what others think.
The LWN model seems an awful lot like public radio in the US, but without the annoying pledge drives. Like you, I both read and subscribe in bursts of activity and inactivity. If it's something that you feel is valuable, and needs support, don't let the names get in the way of donating at the level that you feel you use it.
As a note to anyone reading this, as a former LWN subscriber a couple years ago, and as someone who will probably renew at the $40/year level here today again, definitely consider throwing them a subscription. It's one of the best tech publications on the web.