Encryption GnuPG
John Lane explores the convoluted world of PGP key validation.
John Lane expands your worldview with a dive into GnuPG’s key-based trust model.
PGP means “Pretty Good Privacy”. Not perfect then, but, perhaps, a pretty good way to encrypt messages and other documents or to prove that they have not been altered by anyone. If you can understand its so-called “Web of Trust”, that is. Many Linux users will at some point encounter the Gnu Privacy Guard ( GnuPG), an implementation of the OpenPGP standard, but getting the most from it requires untangling that web.
You use someone’s key to send them an encrypted message or document, or to verify the authenticity of a signed message or document that they’ve sent you. But anybody can create a key for any identity, so before using a key, you need to be sure that whoever created it is who they claim to be and that their identity is correctly represented. Which is where it gets complicated. You can either do this yourself or trust the efforts of other people.
OpenPGP defines a trust model called the Web of Trust (WoT), which GnuPG usually uses. It also supports alternative models including simple trust and Trust On First Use (TOFU), but WoT is the core trust principle behind OpenPGP. Unfortunately, it can be difficult to understand its model of verification, trust and validity.
In this tutorial we will explore the dark art of key validation and explain what it means to verify, sign and certify a key, or to place trust in a key or its owner. Keys, in this context, are public OpenPGP keys (we’ll assume some prior knowledge of
GnuPG and how it uses public-key asymmetric cryptography). Verification, trust and validity affect public, not private, keys, so when we refer to a key in this tutorial, we mean the public key.
The best way to get someone’s key is by meeting them in person so that they can personally transfer their key file to you, perhaps by handing you a USB key or CD-ROM. That way, you can be sure it’s authentic. In practice people may use other methods such as publishing their key on their web site or to a public key server. These are services on the internet, some of which are web-based, that you can query to obtain other people’s keys. However, because anyone can create and upload keys, it is unwise to trust their authenticity without verifying it first.
Elvis has left the building
To illustrate this point you can consult one of the OpenPGP key servers available on the web. Point your browser to https://sks-keyservers.net/i and search for “Elvis Aaron Presley”. You’ll find some keys there despite the fact that their purported owner passed away several years before the first version of PGP saw the light of day. If you want something more contemporary, try searching for “Linus Torvalds” – sure, some of those will be genuine but others clearly aren’t, although they serve as good examples of why you need to trust any keys you use! You need to believe in a key’s
authenticity before trusting it, so the most basic trust principle is verification. This is an investigative process where you take the steps that you feel are appropriate to confirm a key’s authenticity by verifying who owns it and proving their identity. Notice how this is a subjective definition and, therefore, personal to you. Individuals may take very different approaches to this, from casual observation to insistence on meeting in person and physically verifying formally issued documents such as passports or other government-issued identification (a driver’s licence being a popular choice).
You should only consider a key to be authentic when you are certain that it belongs to its purported owner and you know that its owner is who they claim to be.
You sign a key to certify that you consider it to be authentic, and you may use it after doing so because GnuPG trusts that you are happy with your own approach to verification and, thus, accepts that keys you sign are valid.
We say “sign” a key but the certification is also bound to a “UID” – a user id, which can be a name, email address and comment triple or, perhaps, a photo. Certifications remain valid until the key and/or associated UID value are revoked even if other changes occur, but separate certifications are needed for each UID.
If a key has multiple UID values then GnuPG will warn you and ask whether you want to sign all of them at once. If you don’t then you can select and certify them individually. The examples that follow have one UID value.
GnuPG maintains your key-ring where it stores the keys you collect and any certifications you apply to them. Your keyring represents your personal Web of Trust.
To demonstrate certification, we’ll imagine receiving an encrypted document from our friend Alice who likes helping with examples. She would have used your public key to encrypt it and you can decrypt it straight away (you don’t even need her key). $ gpg --decrypt document But if she also signed it then you would need her key to confirm the document is authentic, as gpg would tell you: gpg: Can’t check signature: No public key
It will, however, verify the signature once the key is in your key-ring even without you certifying it, but it will also warn you about that: gpg: Good signature from “Alice <alice@example.org>” [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. The “unknown” presented in brackets is the validity that GnuPG calculates for Alice’s key. It’s also displayed if you list your copy of her key from your keyring: $ gpg --list-key alice pub rsa2048 2017-01-16 [SC] [expires: 2019-01-16] UID [ unknown] Alice <alice@example.org> sub rsa2048 2017-01-16 [E] [expires: 2019-01-16]
The calculated validity can be one of “unknown”, “full” or, for your own key, “ultimate”. You should verify Alice’s key using whatever approach you find acceptable and then certify its authenticity by signing: $ gpg --edit-key alice gpg> sign
Quit the editor and save changes when prompted. If you list the key again you’ll see that its calculated validity is now reported as “full": UID [ full ] Alice <alice@example.org> and that will produce a good signature report: $ gpg --decrypt document gpg: Good signature from “Alice <alice@example.org>” [full]
You can also record within the certification signature how carefully you verified the key owner’s identity. If you add the
--ask-cert-level option to the gpg command, the signing process will request you choose a certification level from: I will not answer I have not checked at all. I have done casual checking. I have done very careful checking.
The OpenPGP standard calls these certification levels “Generic”, “Persona”, “Casual” and “Positive” and they are identified as levels 0 thru 3 on GnuPG’s signature output. This example shows a carefully checked certification ("3"): $ gpg --list-sigs alice UID [ full ] Alice <alice@example.org> sig 3 814EE2DB21D58552 ... How one interprets certification levels is subjective but the OpenPGP specification (RFC4880, section 5.2.1) describes
them as follows:
Generic certification applies where the level of verification, if any, is unknown or unspecified. Persona certification is where no verification has been done. Casual certification applies where some casual verification has been done
Positive certification applies where substantial verification of the claim of identity has been achieved.
GnuPG applies the generic level 0 certification unless requested otherwise (-- ask-cert-level) except for selfcert ifications( signing one’s own key) where positive level 3 certification is used. It normally ignores persona certification when calculating a key’s validity but you can use its --min
cert-level option should you desire to change this behaviour. Having certified someone’s key, it is customary to export a copy and send it to them ( --armour exports printable characters (a base-64 encoding) that are easy to email): $ gpg --armour --export alice | mail alice@example.org
That person may, at their discretion, upload that copy to a public key server. If they do this then anyone else using that key can also see your certification and they can decide to trust it rather than verifying the key’s authenticity themselves. Bear in mind that it is considered rude to upload someone else’s key to a key server – you should send keys you certify to their owners and let them decide whether to publicly accept your certification.
Who you gonna trust?
Although you can certify a key, our example illustrates that it is GnuPG, not you, that decides whether a key is valid. It does so by accepting that you trust that whoever certified it verified its authenticity in a manner acceptable to you. That’s all trust means in the PGP world – your trust in someone’s approach to verification of others’ identities; it doesn’t necessarily mean you’d entrust them with your life savings!
So far, we only have the trust inherent in our own key, so, beyond that, the only valid keys in our key ring are those we certify. But we can extend trust to keys in our key ring whose owners also perform verification in an acceptable manner, which will allow GnuPG to also validate keys certified by them. Like your attitude towards verification, such trust is also a subjective and personal value; you decide how you trust – here are some examples: I trust my own key I trust your key like my own I trust your key but not on its own I do not trust your key
You can convey such trust in two ways: “owner trust” – the original Classic Trust Model – or, with the newer PGP Trust Model, “trust signatures”. You explicitly assign owner trust to a key separately from any certification and it is stored in your private trust database, whereas trust signatures are certifications that assert trust in addition to authenticity. Being certifications, they are stored in your keyring and are included when a key is exported and published to key servers; trust signatures can therefore be made public.
The given examples are known as Trust Levels; they are “ultimate”, “full”, “marginal”, “never” and, if you have not assigned a level, “unknown”. If you feel unable to trust a key but don’t want to go as far as denying it then there is another level, “undefined”, that you can use.
The key editing mode of the GnuPG command-line tool is also used to assign owner trust. If you had Alice’s key in your keyring and wanted to trust it: $ gpg --edit-key alice gpg> trust GnuPG then offers five options for your trust selection: “I don’t know or won’t say” -> “undefined” “I do NOT trust” -> “never” “I trust marginally” -> “marginal” “I trust fully” -> “full” “I trust ultimately” -> “ultimate” If you chose the fourth option to assign full trust, assuming Alice certified Blake’s key, that would also be valid for you: $ gpg --list-sigs blake UID [ full ] Blake <blake@example.org>
You consider Alice an “introducer” of Blake’s key because she certified it. By trusting Alice to verify that key you would also consider him to be a “trusted introducer”.
Question time...
Use tsign instead of sign if you want make a trust signature. GnuPG will extend the signing process with some additional trust questions: $ gpg --edit-key alice gpg> tsign
The first such question asks how you trust the key owner to verify other’s keys in a similar way to the owner trust question previously described, except that your options are limited to “marginal” or “full”.
The second question is about “Delegated Trust” which allows you to trust-sign a key so that any keys that it signs are also trusted (eg, I trust you and anyone that you trust, but not those they trust). Such a trust signature has two levels of delegated trust: trust in the key you sign plus one further connection beyond it. Trust signatures may be given up to five levels of delegated trust, where one level of delegated trust is equivalent to owner trust.
As with owner trust, keys signed with trust signatures having one level of delegated trust are trusted introducers. Keys signed with two levels of delegated trust are called “Meta Introducers” and those at level three are known as “Meta-meta Introducers”.
The third and final question asks you to enter a domain to restrict the signature. You can leave this blank (no restriction) or enter a domain (such as example.com) to limit the delegated trust to.
Another subtle difference between owner trust and a trust signature is that you certify a UID whereas owner trust is applied to a key. Owner trust can be applied to a key that has a trust signature but only to upgrade its trust level.
However you assign trust (you can use either owner trust, trust signatures or a mixture of both), GnuPG uses it to determine a key’s validity and maintains it in your trust database. A key is “Fully Valid” if it is certified by at least one key with either ultimate or full trust, or by three keys with marginal trust. Those are the standard parameters but you can change them by adding entries to your GnuPG configuration file.
GnuPG automatically maintains your trust database, but you can request an immediate update and this is a good way to see a summary of it:
The first line confirms the parameters described in the previous paragraph and that the PGP trust model is in use. The following lines summarise the your web of trust. The “depth” represents steps away from you; there is one key at depth 0 – your own – which is valid, signed and has ultimate trust. The trust values are counts of keys with unknown (q), no (n), marginal (m), full (f) or ultimate (u) trust.
Trust the Web of Trust?
One of the defining properties of the Web of Trust is that keys and their certifications are publicised, typically by uploading them to public key servers. Keys contain personal data (names, email addresses, photos and whatever is written in comment fields) that you may not want on a public server. Also, the certifications on your key leak information about your social graph – those you know and what your interests and associations are. And if you include certification levels when you sign a key then your approach to certification is also revealed to anyone data-mining the key servers.
Key servers also have an important property that you shouldn’t overlook – keys cannot be deleted from them! You can revoke keys or certifications but they still leave an indelible footprint. So you should think carefully before uploading your key to a key server; this also helps explain why it is completely wrong to upload somebody else’s key.
An important part of the trust process is to also protect yourself, so you should consider both positive and negative aspects of the web of trust to reach a balanced view of their benefits to your workflow and the cost in terms of privacy. Even if you decide against using key servers you can still maintain a private web of trust, privately distributing keys between your contacts and certifying them discreetly. If you want to certify a key for your own use without ever exporting it then you can use a lsign ("local sign") variant of the key signing command that we used in our examples. It works the same way but prevents you accidentally exporting certifications that you’d rather retain privately.
But, on the other hand, should you wish to build your web of trust publicly then upload your key to a key server such as
https://sks-keyservers.net. Key servers synchronise to others, propagating uploaded keys among them. You may also like to advertise your willingness to sign others’ keys (and have them certify yours) by using sites such as: http://www.biglumber.com.
In summary…
For those times when you aren’t sure if it’s verify or validate...
The “owner” of an OpenPGP key has the identity stated within it; a name, email or photo. A key is “authentic” if the stated owner actually owns it. You “verify” a key to prove its authenticity. You “sign” a key to “certify” that you have verified it. You call a signature on a key a “certification” to distinguish it from a document signature made with a key.
You can “trust” a key’s owner and accept their certifications, either on their own ("full”) or with others ("marginal” trust).
A key having sufficiently trusted certifications (one full or three marginal) is “valid”.
You can “delegate” trust decisions to the owner of a valid key that you trust.