Wednesday, July 06, 2011

Securing your passw^H^H^H^Hgp private key


I saw this article today by @DSchwartzberg at Sophos about Google indexing PGP private keys, easily found if you know what to search for. It reminded me that I had to finish this old blog post which has been waiting in line for some months now. Lets get straight to the point: How do you protect your GPG/PGP private key?

I use GPG/PGP myself, both at work as well as at home, even though Bruce Schneier says in his book "Secrets & Lies": "Digital certificates provide no actual security for electronic commerce; it's a complete sham." Made me smile when I read it. Of course there are many ways to interpret that statement by itself, with perhaps an interesting view being that a digital certificate identifies an electronic identity, and not necessarily a physical person. DNA testing does that these days. Even more; identifying somebody really doesn't tell you much if they are Alice, Bob or Eve. Well, unless they already have a record, or become subjects of Ethnic Profiling of course.


We have a law here in Norway that says that I am legally bound by anything signed by my #BankID, and similar solutions. BankID is a bank-issued digital certificate, where a single commercial company - owned by various banks - keeps my private keys in their possession, and will NOT give it to me electronically!


Anyway, lets not wake up Auguste Kerckhoff from the dead.


What I am curious about - of course this blog post is about passwords - is how people go about protecting their GPG/PGP secret keys? Do people use strong passphrases? Do they ever change them? What about the password/phrase for shared secret keys, such as those belonging to various CERTs, IRTs, CSIRTs and so on? What if somebody leaves such a team - do they create a brand new key, do they just change the password (Now that's a risk!), or what?


Allow me to quote from the gnupg manual:
"Protecting your private key is the most important job you have to use GnuPG correctly. If someone obtains your private key, then all data encrypted to the private key can be decrypted and signatures can be made in your name. If you lose your private key, then you will no longer be able to decrypt documents encrypted to you in the future or in the past, and you will not be able to make signatures. Losing sole possession of your private key is catastrophic."
If you use PGP Microsoft Windows in a corporate environment, the default configuration will store your keyring, including your private key, under "My Documents". That folder will again probably be stored centrally on a server, making your keyring more easily available 24x7 to lots of other people. Oops - replace "other people" with "unauthorized people" in that last sentence there. It's your secret key, it should be kept in safe storage by you, nobody else (at least not Google's search engine :-))
--

(I'm sorry #BankID, but I want my private key!)

I'd like to hear your opinion, ideas, challenges or risk analysis on this subject. Shoot!

4 comments:

  1. I think GPG passwords are likely to be of higher quality than a run of the mill password. Though, for the most part the people that are actively using GPG generally already have better baseline standards for even run of the mill passwords, except for the people that have their private key on google.

    For physical key security it would be great to have something like the YubiHSM for gpg. (Two factor GPG authentication with Yubikey maybe?) For the current time I keep my key on a usb thumb drive that contains it in an encrypted file system using cryptsetup/LUKS. (This format, software, etc. are 100% open source and even have a windows implementation but wouldn't recommend using windows for something like your GPG private key.) Additionally, I keep a backup in an encrypted container at home and an offsite backup of that encrypted container which has a 3rd layer of encryption.

    Any active use of my key falls under my standard policy for my home directories that are encrypted containers: wipe key from memory for anything more than a bathroom trip at the office. I don't suspend/hibernate my laptop, when I am finished using it then it either gets powered off or the home directory container is closed (if leaving it running at home.) Leaving for work means closing my home directory container for my workstation at home and I unlock my home directory container when I arrive at work. For an added bonus swap gets a new key at every system boot.

    Newer versions of cryptsetup/LUKS have a very useful option: luksSuspend and luksResume. These actually allow you to close the container and securely wipe the key from memory *without* having to close all your apps but I have not had the time to explore them enough to switch my current policy. This option also should allow being able to change to a fixed key for swap and do a hibernate or suspend that wipes the keys from ram prior to dumping the hibernate file and then prompts for unlocking the key on resume. I guess I need to add encrypted disk usage to my things to blog about list and will stop hijacking your blog and my response now ;)

    I would suspect that once people have made their awesome password that they are even less likely to change it than other passwords. I doubt most people even change passwords unless required to. I also doubt most gpg users actually do a proper keyspace and entropy calculation on the password they create.

    As a related aside I did a search for "BEGIN RSA PRIVATE KEY" filetype:pem and that looks to be an area for further study. The format is anything from SSL certs to ssh keys to a lot of other things. Older ssh versions store the private key (id_rsa/id_dsa default names) using 3DES (112-bit effective security) and the new versions use AES. I already planned to do a blog post on ssh re-keying to get people to stop having default 1024-bit DSA or RSA keys that are years old and in some cases not that old. Also, I'm going to write about re-keying in the sense of moving off of the 3DES construction for the private keys.

    Norwegian law when it comes to banking, certs/private keys, phone registration, etc. is just plain weird to me. So your bank generates some SSL style certificate pair for you and you get to put a password on the private key but you never get your private key? Are there write ups about this technology in English and/or google translate at least gives me some clues?

    ReplyDelete
  2. When your comment is longer than my blog post, it probably should have been written as a stand-alone blog post at your own blog James! :-)

    Anyway; you misunderstood or I didn't explain well enough: there is a Norwegian law for digital certificates. The #BankID system (www.bankid.no) are public/private keys generated for you, you get to set a password for it. The commercial company on behalf of banks and others will keep your keypair (they won't give it to you!), and whenever you use it at some site that uses BankID for authentication, digital signing etc, you enter your OTP (usually through hardware or on paper/plastic) and your personal password.

    Use whatever-translation-service and look at www.bankid.no. Not that much info available I'm afraid.

    ReplyDelete
  3. finaly someone explains this! thanks for posting, ive looked everywhere for a good explanation

    ReplyDelete

All comments will be moderated, primarily for spam. You are welcome to disagree with my posts of course.