Viewable With ANY Browser

Note: My Web pages are best viewed with style sheets enabled.

Unrated

PGP: Key Management

Copyright © 2008, 2010, 2020, 2022 by David E. Ross

Distributing a Public Key

Replacing a Key Pair

Transferring a Key Pair


Distributing a Public Key

As explained elsewhere, using OpenPGP to exchange encrypted messages or files requires that others possess the user's public key and that the user possesses the public keys of others. Also explained elsewhere, using OpenPGP to verify someone's digital signature requires possession of the signer's public key. Finally, as explained elsewhere, you do not care who has your public key; you actually want your public key to be widely distributed.

Distributing Via a Public Key Server

The simplest way to distribute a public key is to upload it to a public key server. Be aware of the following when using a key server:

Distributing Via a Web Page

Another way to distribute a public key is to put it on a Web page of your own.

Distributing Via E-Mail

Distributing a public key via E-mail generally fails to make the key "widely distributed". If you nevertheless wish to distribute your public key via E-mail, it should not be embedded within the message. E-mail clients too often make subtle changes (e.g., line-breaks) in messages, changes that corrupt OpenPGP keys.


Replacing a Key Pair

Some users generate their key-pairs with an expiration date; after that date, a new key-pair is needed because the old one is no longer valid. Other users decide to replace an existing key-pair when changing E-mail address, although a new address can easily be added to an existing key-pair. Then there is the situation when a key-pair must be revoked because it has been compromised, again requiring the generation of a new key-pair. An RSA v.3 key signed by a DH/DSS or RSA v.4 key will be treated as invalid by an OpenPGP application that handles only RSA v.3 keys (e.g., PGP v.2.6) and should be replaced.

Generating a new key-pair is simple. Just follow the user instructions for whatever OpenPGP application you are using. However, additional considerations apply beyond merely generating a new key-pair.

Note that an expired or revoked key can still be used to verify a message or file signature made before key's expiration or revocation. However, an expired or revoked key cannot be used to verify another key.

A Case Study

If you don't want to wade through a lengthy, tedious description, just go to the summary at the end of this section.

US-CERT (United States Computer Emergency Readiness Team) is an agency of the U.S. Department of Homeland Security. Among other activities, US-CERT tracks and reports on computer vulnerabilities, such as viruses and susceptibility to hacking attacks. US-CERT failed to heed any of the points above, causing problems for users of its reports.

To allow verification of the authenticity of its reports on vulnerabilities (since many such reports are hoaxes written by others) and the integrity of those reports (since some hackers might want to alter the reports), US-CERT uses OpenPGP to digitally sign its reports. The signature is generated by US-CERT's Publications Key. To aid users in validating its various keys, US-CERT also has a Master Key-Signing Key, which is used to sign all other US-CERT keys — including the Publications Key. Having verified the authenticity of the Master Key-Signing Key, I signed it when I added it to my keyring.

On or about 16 September 2008, US-CERT released "Technical Cyber Security Alert TA08-260A". This report described a vulnerability affecting Apple computers, which my daughter uses. Before reading the report, I decided to verify the signature on it. The verification failed because the report was signed by a relatively new Publications Key that I did not have. I downloaded the new Publications Key from the US-CERT Web site; but I could not verify the new key it because it had been signed by the Master Key-Signing Key, which had expired.

*** Begin Right Sidebar ***

Why did I call the US-CERT "hotline"? After all, the fingerprint on the Web page matched the fingerprint on the Master Key-Signing Key that I downloaded from a public key server.

The Web page was defective. The link to the Master Key-Signing Key was broken. That made me suspect the authenticity and integrity of the entire page, including the fingerprint documented there.

*** End Right Sidebar ***

Returning to the US-CERT Web site, I then attempted to download the new Master Key-Signing Key cited there. However, the link was 404 (a broken link to a non-existent Web page). I finally downloaded the new Master Key-Signing Key from a public key server. For two reasons, the new Master Key-Signing Key was useless to me. First of all, the Publications Key had not been signed by the new Master Key-Signing Key. More important, I could not verify the new Master Key-Signing Key. The Web page for downloading US-CERT keys (the page with the 404 link) contained a toll-free phone number for a "hotline" through which I could obtain the key's fingerprint (a 32-digit hexadecimal number). However, no one at that phone number knew anything about PGP keys.

To summarize:

A government agency involved in keeping the United States secure was very slipshod in maintaining its own infrastructure for the security of its Internet communications.


Transferring a Key Pair

The following assumes that both the source and target computers are physically and electronically secure even if communication between them is not secure.

You have a computer at home and another one at work. You would like to use the same key-pair at both locations. How do you safely transfer the key-pair from the computer where it was generated to the other computer without compromising it? Different computer configurations require different methods.

The three methods below provide a secure process for transferring a key-pair. The first two involve the owner of the key-pair physically carrying removable media from the source computer to the target computer without allowing anyone else access to the media. The third involves encrypting the key-pair so that it may be sent over a non-secure communication channel (generally an electronic channel but also by another person carrying removable media).

Two Similar Computers With Removable Media

Both computers are of the same type (e.g., both PCs or both Macs), and both have equivalent operating systems (e.g., both Windows). Both can use the same type of removable media (e.g., floppy disc, flash drive (memory stick)).

There are two simple ways to transfer:

When the transfer is completed, several issues must be addressed:

Two Dissimilar Computers With Removable Media

The computers are of a different type (e.g., one a PC and the other a Mac) or have different operating systems (e.g., one with Windows and the other with Linux). Both can use the same type of removable media.

The method is the same as in the second bullet under Two Similar Computers With Removable Media. However, when exporting the key-pair from the source computer, it must be done in ASCII format (the default for some OpenPGP applications). The first bullet under Two Similar Computers With Removable Media cannot be used because file formats might be different.

When the transfer is completed, the same issues must be addressed as under Two Similar Computers With Removable Media.

Two Computers Without Removable Media

The computers might be of the same type with the equivalent operating systems, or they might not. Here the issue is that removable media cannot be used. There might not be any medium that is common and compatible between the two computers. One computer (or both) might have all capabilities for removable media disabled because of security concerns. One computer (or both) might not be physically accessible (accessible only via a remote terminal). Instead, communication between the two computers is over the Internet, an intranet, or a local-area network (LAN) none of which is secure.

The following sequence of steps will provide secure transfer of a key-pair from the source computer to the target computer through non-secure electronic communication:

  1. If there is no key-pair already existing on the target computer, use the OpenPGP application to create a key-pair there.
  2. Using the OpenPGP application on the target computer, export only the public key from that computer's key pair to that same computer's local hard drive.
  3. Transmit the target computer's exported public key to the source computer. Since this is a public key, it can be done via a non-secure method (e.g., E-mail, FTP, parking it on a LAN's file server).
  4. Using the OpenPGP application on the source computer, import the public key from the target computer into the source computer's keyring.
  5. Using OpenPGP applications on both the source and target computers, verify that the correct public key was imported by comparing the fingerprints of the key on both computers.
  6. Using the OpenPGP application on the source computer, export the desired key-pair to the hard drive of that same computer. Be sure to include the private key. The option for an ASCII-formatted file should be selected.
  7. Rename the export file on the source computer to remove the file extension.
  8. Using the OpenPGP application on the source computer, encrypt the export file using the public key from the target computer. This should be in ASCII format (not the default with some OpenPGP applications).
  9. On the source computer, thoroughly and securely erase the unencrypted export file.
  10. Transmit the encrypted export file from the source computer to the target computer. Since the file is encrypted, this can be done via a non-secure method.
  11. Using the OpenPGP application on the target computer, decrypt the transferred file using the private key related to the public key cited in step #2.
  12. On the target computer, rename the decrypted export file to restore the file extension.
  13. Using the OpenPGP application on the target computer, import the renamed export file into that same computer's keyring.
  14. On the target computer, thoroughly and securely erase the unencrypted export file.

(I actually used this method more than once where the two computers were dissimilar and where I could access one of them only through a remote terminal.)

When the transfer is completed, the issues to be addressed in this case are:

This third method may also be used with a removable medium if another person must be involved in carrying the medium between the two computers. In this case, to ensure that a bogus key-pair was not substituted for the actual key-pair, a test message should be signed on one computer and the signature verified on the other computer, both operations using the same key-pair. While the fingerprints of the two keys may be compared, the use of the keys for signing and verifying the signature gives far more assurance that the keys are identical.

29 October 2008
Updated 29 January 2022