tmacuk

Hello all. In case any of you are wondering, the title is in fact a reference to the classic pseudo-hacking game ‘Uplink’, one of my favourite games. Nevertheless it holds true for this situation, when it comes to cryptography, the problem of trust is a weakness. However, before we deal with the problem of trust, let us first address a simpler matter.

Obtaining Other People’s Keys

If you wish to send an encrypted message to someone using GnuPG, or wish to validate a signature of theirs on a message, you will need your own copy of their public key. GnuPG stores the public keys you have collected (including those corresponding to your private keys) in a ‘keyring’. This keyring is really just a single file containing each public key.

To ‘export’ an individual public key (essentially just splitting part of the keyring out into a separate file) we can use the --export command of GnuPG. For example, to export your key you might use:

gpg --armor --output MyKey.asc --export $GPGKEY

(N.B. Unless you have like me configured the BASH variable $GPGKEY to point to your KeyID, you will need to replace this with the KeyID of the key you wish to export)

This will create the file MyKey.asc containing a complete copy of your public key (but of course not your private key). This file can be stored, sent in an e-mail, whatever (and remember, it only contains public information, so need not be secret). This can be used as one method of distributing your key, typically by uploading this file to your webserver and making it available there for people to download. Anybody with a copy of your key can execute:

gpg --import MyKey.asc

Running this command will export your public key into their keyring, and they will then be able to use it to send encrypted messages to you, and/or verify your signature on messages. However, this method of distribution is not usually very convenient, and there is a better option.

Keyservers

Keyservers are, exactly as the name suggests, public servers on the internet, to which people can publish their private keys, and from which people may retrieve any public key. We briefly met keyservers when we generated our keypair, when I showed you quickly how to upload your key to a keyserver. But as a quick recap:

gpg --keyserver pgp.mit.edu --send-keys $GPGKEY

This sends a copy of your public key to the keyserver specified. Almost all keyservers sync with each other, so within a few minutes to hours your key should be available on most public keyservers. This means that anyone should be able to retrieve your key from many keyservers.

Keyservers can make it very easy for people to retrieve your key. Firstly, if they receive a message sent by you they can easily get your public key to verify it. By default GnuPG will not decode the signature, and inform the user of the KeyID they require to validate the signature. The user can then run:

gpg --keyserver pgp.mit.edu --recv-keys {KEYID}

This will retrieve the key specified by that key id, and the user can then verify your signature. It is also possible to configure GnuPG to do this automatically for you, although it is usually not recommended (for reasons you will meet further down).

A user can also search for keys in a keyserver by name, e-mail address, or key id. You can do this using the command:

gpg --keyserver pgp.mit.edu --search-keys {SEARCH}

However, this must be treated with great caution, due to the problem of trust.

Trust’s Weakness

The main problem with the security of GnuPG is not the security of the ciphers, which is strong enough that they should remain relatively unbreakable (providing you use custom options such as those I have discussed) until there are major advances in technology and/or mathematics (although it should be noted, these could feasibly occur at any time – security can never be perfect).

The problem is this. I have of course my own GnuPG key, which I created. When I created it, I entered my name and e-mail addresses correctly, and I know my own identity. So I know that my particular private key (and the corresponding public key) verifies that something has been signed or can only be read by me, Matthew Gadd. However, how can anyone else be sure?

The thing is, that although no-one can forge a message with a signature by my KeyID, they can very easily create their own key, and put my name instead of theirs, and then create messages that are supposedly from ‘Matthew Gadd’. They will have a different KeyID, but face with the two KeyIDs claiming to be me, how can anyone know which is correct?

To illustrate this problem further, here is a key search I performed on one of my e-mail addresses. Note that there are 5 different keys returned, which could all be me (or none of them).

gpg --keyserver pgp.mit.edu --search-keys hello@darkotter.com

gpg: searching for "hello@darkotter.com" from hkp server pgp.mit.edu
(1)	Matthew Gadd (Dark Otter)
	Matthew Gadd (Dark Otter)
	Matthew Gadd (Dark Otter)
	Matthew Gadd (Dark Otter)
	  4096 bit RSA key C6E53A2D, created: 2010-01-31
(2)	Matthew Gadd
	Matthew Gadd
	Matthew Gadd (Dark Otter)
	  1024 bit DSA key 94D59FB5, created: 2009-05-11 (revoked)
(3)	Matthew Gadd
	Matthew Gadd
	Matthew Gadd (Dark Otter)
	  1024 bit DSA key 3779C483, created: 2008-12-15 (revoked)
(4)	Matthew Gadd (Dark Otter)
	Matthew Gadd (Dark Otter)
	Matthew Gadd (Dark Otter)
	Matthew Gadd (Dark Otter)
	  1024 bit DSA key 17E0BBB9, created: 2008-07-11 (revoked)
(5)	Dark Otter (Dark Otter)
	Matthew Gadd (Dark Otter)
	  1024 bit DSA key 2D0BBF83, created: 2008-07-01 (revoked)

(N.B. Some e-mail addresses have been removed – each of the duplicate names originally had a different e-mail address, printed after it)

So, supposing someone wanted to send me an e-mail securely. Which key should they download and use? Can they really trust any of them? This is the problem of trust.

However, like most problems, GNU and PGP developers have come up with a way to attempt to solve this. Like any security system, it cannot guarantee perfect trust, but it can get somewhere much closer to it than nothing. The basis of this system is key signing.

Suppose I am working with a person, let’s call them Bob. We both have GnuPG, and our own keys, and we want to be able to send secure messages to each other. So, I write down a copy of my key fingerprint (the longer form of my KeyID), and take my passport (or other identification), and he does the same. We both meet up, and check each others passports to ensure our identities are real. We then each take the copy of the other persons key fingerprint.

I now know exactly which GnuPG is guaranteed to be Bob (because the key fingerprint is absolutely unique to a key, note that KeyIDs are sometimes the same), and so I can trust this key. So, when I get home, I download this key from the keyserver, for example:

gpg --keyserver pgp.mit.edu --recv-key 0xDB0A62087277450569F32DDE7F5FC5A5A0503C60

Because I can absolutely trust this key to be bob, I now sign the key:

gpg --sign-key 0xDB0A62087277450569F32DDE7F5FC5A5A0503C60

pub  4096R/A0503C60  created: 2010-02-02  expires: never       usage: SC
                     trust: unknown       validity: unknown
sub  4096R/9875F234  created: 2010-02-02  expires: never       usage: E
[ unknown] (1). Test User (Do Not Use)

pub  4096R/A0503C60  created: 2010-02-02  expires: never       usage: SC
                     trust: unknown       validity: unknown
 Primary key fingerprint: DB0A 6208 7277 4505 69F3  2DDE 7F5F C5A5 A050 3C60

     Test User (Do Not Use)

Are you sure that you want to sign this key with your
key "Matthew Gadd (Dark Otter) " (C6E53A2D)

Really sign? (y/N) y

This indicates to me, and anyone else, that I trust this key to be Bob’s real key. I then give the signature back to bob, either by exporting his public key from my keyring and then sending him the exported key (which will contain my signature), or by uploading the new version to a keyserver for him to retrieve (this is considered less polite than the former option however). Bob can re-import his key from either source, and GnuPG will import the signature I made, but preserve any modifications he has made separately.

If I sign Bob’s key, and he signs mine, we now can communicate securely with trust. But what if I want to communicate suddenly with Alice? I have never met Alice, so I neither know her public key, nor can trust any of the keys available for her e-mail address. However, the second part of the solution deals with this.

GnuPG (and PGP) both keep a trust database, which builds up a web of trust. After having signed any new keys (or after having downloaded updated public keys from a keyserver) I run:

gpg --update-trustdb

This tells GnuPG to process your trust database and signatures, semi-interactively. If there are any keys which you have signed and not yet set ‘owner-trust’ it will prompt you to set it. Owner-trust is distinct from trust/validity. Whereas trust/validity indicate how well I can trust Bob’s key to be his, owner-trust indicates, as the name suggests, how much I trust Bob. I can choose to trust him fully, marginally, or not at all to sign other peoples keys. If I trust him fully or marginally (partially) then I can start to build my web of trust.

For the example, if I decide I know Bob well and he is careful, I decide to trust his key fully. Then, when I want to send an e-mail to Alice, fortunately Bob has verified and signed Alice’s key. Because I have decided to trust Bob’s signatures (including the one on Alice’s key), I know which key is Alice’s real key, and I can send her a message easily without having met her.

This particular example does seem pretty tortuous, but given that you can have your key signed by an unlimited number of people, and they can also sign the keys of many people, it is possible to build up a large enough ‘web of trust’ to be useful. It would require many key-signings between you and other people, but gradually one can be built up. If you have your keys signed by people who are already part of other webs of trust, your area of trust can grow rapidly.

The difference between full and marginal trust depends to a certain extent on user customisation. You can customise the options for how many signatures and of what level a key needs to be considered valid by GnuPG. By default, if a key has either been signed by one user you fully trust, or 3 people you trust marginally, GnuPG will consider it valid. But these options can be changed to make GnuPG more or less paranoid, even requiring multiple fully trusted signatures to consider a key valid.

Community Responsibility

However there is one responsibility that comes with all this.

You must NEVER sign a key unless you are really sure it is genuine

Allow me to explain a little. You can set owner-trust values to whatever you like, as these are only used by you, and are not exported to other people. However, when you sign a key, this signature is visible to the world.

The problem would occur like this. Suppose I have signed Bob’s key, and decided I trust him fully. However, what if he now betrays my trust in him by signing a key without carefully verifying it. Eve wants to read Margery’s messages, and so she creates a fake key for Margery. She takes this key to Bob, and claims she’s forgotten her passport. Bob, rather than being careful decides to sign her key anyway. Here Bob is violating the responsibilities of the community, because he has not checked that the key belongs to Margery. Because I fully trust Bob, the key supposedly for Margery will be valid according to my GnuPG, and if I try to send her a message, Eve will be able to intercept and read it.

This is why you must only ever sign a key if you’ve checked it carefully. You can set owner-trust to anything you like, and you can actually set owner-trust without signing a key if you want to treat a key as valid (and as part of your web of trust) but without making a public signature. As much as this is insecure for you, GnuPG is flexible and will let you use whatever level of security you elect to. However, it is important you never sign a key unless you have carefully checked it, because this is the one action in GnuPG that can compromise security for people other than yourself.

Next Time

That conludes today’s post, and with that post I have now completed the first part of this guest series, dealing with GnuPG. I have now (I hope) covered the basics of GnuPG, if any of you have any questions feel free to contact me. There are things I intentionalyl have not covered, such as revoking GnuPG keys, and I may cover some of these topics if any of you wish me to later.

I’m going to be away for a few days, so my next post may (or may not) be a bit delayed. When it does come I intend to write it on methods for estimating password strength. So stay tuned for that. Until it does come however, I’m sure TmacUK himself will keep you entertained with his many posts and bugs, and have fun using GnuPG.

My GnuPG Key

As mentioned above, I’m perfectly willing to take questions by e-mail, and I may even check the comments on this site occasionally. However, as we’ve just been using gnuPG, why not use it to send me a message? As of course you have not met me, you cannot trust (and absolutely musn’t sign) my key. However, you can still send messages with an untrusted key (although GnuPG will warn you about doing this).

If any of you wish to acquire my key, there are two easy ways. The first is to get it from a keyserver:

gpg --keyserver pgp.mit.edu --recv-keys 0x6D5922FB54465F55CB17662D43741CE0C6E53A2D

Or, if you prefer a more direct approach, you can obtain it from my blog (as described there):

wget -q -O- 'http://montemazuma.wordpress.com/about/' | gpg --import

This is actually quite a neat hack, because the page at http://montemazuma.wordpress.com/about/ is both a valid HTML page (with its own content apart fom the key), and a valid copy of my GPG public key.

Either way, once you have obtained my GnuPG key, you can use it to encrypt a message to me at hello@darkotter.com. Enjoy, DO out.