Linux Security Cookbook [Electronic resources] نسخه متنی

Recipe 7.21 Obtaining Keys from a Keyserver

7.21.1 Problem

You want to obtain a public key from a
keyserver.

7.21.2 Solution

If you have the key ID, you can import it immediately:

$ gpg --keyserver keyserver --recv-keys key_ID

Otherwise, to search for a key by the owner's name
or email address, and match keys before importing them, use:

$ gpg --keyserver keyserver --search-keys string_to_match

To specify a default keyserver, so you need not use the
--keyserver option above:

 ~/.gnupg/options:
keyserver keyserver_DNS_name_or_IP_address 

To have GnuPG automatically contact a keyserver and import keys
whenever needed:

 ~/.gnupg/options:
keyserver keyserver_DNS_name_or_IP_address 
keyserver-options auto-key-retrieve

With this configuration, for example, if you were to verify the
signature on some downloaded software signed with a key you
didn't have (gpg verify
foo.tar.gz.sig), GnuPG would automatically download and
import that key from your keyserver, if available.

Additionally, most keyservers have a web-based interface for adding
and locating keys.

Remember to check the key fingerprint with the owner before trusting
it. [Recipe 7.9]

7.21.3 Discussion

Importing a
key does not verify its validityit does not verify that the
claimed binding between a user identity (name, email address, etc.)
and the public key is legitimate. For example, if you use
gpg verify to check the signature of a key
imported from a keyserver, GnuPG may still produce the following
warning, even if the signature itself is good:

gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.

A keyserver does

absolutely nothing to assure
the ownership of keys. Anyone can add a key to a keyserver, at any
time, with any name whatsoever. A keyserver is only a convenient way
to share keys and their associated certificates; all responsibility
for checking keys against identities rests with you, the GnuPG user,
employing the normal GnuPG web-of-trust techniques. To trust a
given key

K , either you must trust

K directly, or you must trust another key which
has signed

K , and thus whose owner (recursively)
trusts

K .

The ultimate way to verify a key is to check its
fingerprint with
the key owner directly. [Recipe 7.9] If you need to
verify a key and do not have a chain of previously verified and
trusted keys leading to it, then anything you do to verify it
involving only computers has some degree of uncertainty;
it's just a question of how paranoid you are and how
sure you want to be.

This situation comes up often when
verifying signatures on
downloaded software. [Recipe 7.15] You should

always verify such signatures, since servers do
get hacked and Trojan horses
do get planted in commonly-used software packages. A server that
contains some software (foo.tar.gz) and a
signature (commonly foo.tar.gz.asc or
foo.tar.gz.sig) should also have somewhere on it
the public key used to generate the signature. If you have not
previously obtained and verified this key, download it now and add it
to your keyring. [Recipe 7.10] If the key is signed by
other keys you already trust, you're set. If not,
don't trust it simply because it came from the same
server as the software! If the server were compromised and software
modified, a savvy attacker would also have replaced the public key
and generated new, valid signatures using that key. In this case, it
is wise to check the key against as many other sources as possible.
For instance:

• Check the key fingerprint against copies of the key stored elsewhere.
  [Recipe 7.9]




• Look who signed the key in question:

  $ gpg --list-sigs keyname

  Obtain those public keys, and verify these signatures. Try to pick
  well-known people or organizations.




• For both these operations, obtain the keys not only from keyservers,
  but also from web sites or other repositories belonging to the key
  owners. Use secure web sites if available (HTTPS/SSL), and verify the
  certificates and DNS names involved.

Try several of the above avenues together. None of them provides
absolute assurance. But the more smartly selected checks you make,
the more independent servers and systems an attacker would have to
subvert in order to trick youand thus the less likely it is
that such an attack has actually occurred.

This process will also merge new signatures into an existing key on your key ring, if any are available from the keyserver.

7.21.4 See Also

For more information on the http://webber.dewinter.com/gnupg_howto/english/GPGMiniHowto-1l.