S 5.63 Use of GnuPG or PGP

Initiation responsibility: IT Security Management, Administrator

Implementation responsibility: IT users, Administrator

GNU Privacy Guard (GnuPG) and Pretty Good Privacy (PGP) are widely used programs by means of which messages and files can be encrypted and decrypted and digitally (or electronically) signed. Both tools implement functions which are defined in the OpenPGP standard (RFC 2440). Encryption is a means of protecting the confidentiality of information, while digital signatures make it possible to check whether a file or message is authentic and has not been tampered with. Key management tasks, such as adding and removing keys, can also be carried out with both GnuPG and PGP.

Encryption and digital signatures

GnuPG and PGP make use of symmetric and asymmetric cryptographic procedures. Symmetric procedures such as AES and IDEA are used for data encryption, while asymmetric procedures such as Diffie-Hellmann are used for the exchange of keys and RSA or DSA/DSS for signature generation.

Both tools create and use public and private keys in pairs of keys. For every private key, there is exactly one public key. It is practically impossible to determine the private key simply on the basis of the public one. A message that has been encrypted with a public key or signed with the private key can only be decrypted with the corresponding private key or verified with the originator's public key. The public key can be revealed to anyone. Its purpose is to encrypt messages sent to the owner of the private key.

To provide proof of unauthorised tampering and hence to protect messages against modification, GnuPG and PGP use the originator's private key to calculate a cryptographic checksum for the message - the digital signature. Using the public key belonging to the message originator, every communication partner can determine whether the cryptographic checksum at the end of the message is valid or whether the message has been modified without authorisation.

When using GnuPG or PGP it is advisable to use a combination of the two functions described above. For maximum protection the standard procedure should be for messages and files to be encrypted with the recipient's public key first and then signed with the originator's private key.

Versions

Both GnuPG and PGP are available on the most common computer platforms (UNIX, Linux, MS Windows). There are also versions of PGP which run under MacOS. GnuPG is an example of Open Source Software. The latest version is 1.0.5.

Versions of PGP currently in demand are 2.6.3i, 5.x, 6.x and 7.x. Versions 5.x onwards have a graphical user interface, but they are not completely downward-compatible with the preceding versions.

In view of the lack of downward compatibility, it is advisable to enquire which version of PGP will be used by communication partners before exchanging encrypted messages. Version 2.6.3i is still in widespread use. This version is command-line oriented, but it can also be integrated into graphical user interfaces and e-mail clients with add-on programs. PGP can be obtained from various sources; among others, freeware versions are available from numerous WWW, FTP and e-mail servers.

GnuPG and PGP are not currently entirely interoperable. This is due to a combination of software patents (the IDEA algorithm routinely used by some versions of PGP is patented) and small departures from the OpenPGP standard. However, now that the RSA patent has expired, one significant hurdle is out of the way. RSA is supported by GnuPG from version 1.0.3. The interoperability between GnuPG and PGP therefore depends on the program versions used and possibly on the use of particular options. Further information can be obtained from Frequently Asked Questions listed on the WWW pages of the GnuPG project, www.gnupg.org. To circumvent these problems, if possible only one of the two tools should be used.

The controversial Corporate Message Recovery (CMR) function was introduced in Version 5 of PGP. CMR offers the option of making it possible for a third person to decrypt files or messages that have been encrypted by one person for a second. The use of such a "third key" can be made mandatory by the Administrator in the configuration.

PGP version 7 contains two additional functions which under certain circumstances allow security functions to be circumvented. The first of the two new functions introduced is a server-based recovery mechanism that enables users to reuse keys when, for example, they have forgotten the associated passphrase. The second function is "passphrase caching", under which the passphrase is temporarily stored so that when it is exchanged between different PGP part systems it does not have to be re-entered by the user every time. There is a similar mechanism in version 2.6.3i also, under which the passphrase can be stored in an environment variable. This mechanism should not be used.

Especially when GnuPG or PGP are used in conjunction with operating systems from the Windows family, it should be borne in mind that it may be possible to circumvent the security mechanisms of these tools by exploiting security deficiencies in the operating system.

Secure installation and operation

Although GnuPG and PGP make use of cryptographic procedures that are recognised as being secure, incorrect configuration or operator error may result in lowering of the level of security. As with most relatively complex crypto products, installation and configuration of GnuPG and PGP, including key generation, is not entirely easy. To prevent the possibility of user error creeping in, familiarisation with the relevant product and with certain basic cryptographic terms is essential.

One person in the organisation should familiarise himself/herself with using the tool and be available to the others as a contact person. This person should then instruct the other users in the secure operation of GnuPG/PGP. In particular, users should have intensive practice in encryption, signatures and key management before they use the software themselves. It is also recommended that the same program version should be used throughout a given organisation in order to avoid any of the compatibility problems described above. Both GnuPG and PGP come with extensive documentation, which should be read prior to use. Experience shows, though, that not all users have the patience to read the documentation, so it is advisable to draw up written instructions that are adapted to the specifics of the organisation concerned.

If users have any questions about GnuPG or PGP which go beyond the scope of the supplied documentation, there are various means of obtaining answers:

• Firstly there is a collection of the most commonly asked questions about PGP and answers to these questions (Frequently Asked Questions - FAQ) on GnuPG (e.g. at www.gnupg.org) and PGP (e.g. at www.pgpi.org or www.pgp.com) on the Internet, as well as guides and explanations on the subject.

• It is possible to obtain answers to problems very quickly via newsgroups such as alt.security.pgp, de.comp.security or sci.crypt or on mailing lists.

• There are several books on PGP.

Key generation

With GnuPG and PGP, all users generate their own "key pair" themselves. The following points should be borne in mind in this connection:

• When generating DSA/DSS or RSA keys it is possible to select between various key lengths. It should be remembered that although resistance to deciphering increases with key length, performance also declines. 1024 bits should therefore be chosen as the key length.

• A passphrase (also referred to as a "mantra") must be entered when generating a key; this protects the file with the private keys from unauthorised access. As with every password, this should also not be easy to guess.

There are Trojan horses in circulation, for example, which selectively target the file with the private keys (SECRING.*) and send it to external addresses by e-mail. If the chosen passphrase is too simple, it will not be sufficiently resilient to brute force attacks (automated password guessing). The passphrase should therefore consist of at least ten characters and contain special characters.

• The public keys include a user ID, which if possible should be unique and also contain the e-mail address, e.g. userA@bsi.de.

• To generate keys, GnuPG and PGP require seeds that are as random as possible. The individual programs and versions use different methods to generate these random numbers. For example, the user is asked to type in any text. It is better in this case to enter "real" text; for example, it would be possible to type in this paragraph. Simply tinkering around on the keyboard usually generates poor results, as the time intervals between the keystrokes may be too short and too regular, for example.

Safekeeping of keys

Private keys are stored in the file named SECRING.*. It is critical for secure operation that the contents of this file remain confidential and are protected from tampering. Although access to this file is protected by the passphrase, it should not be stored on local networks, nor on insufficiently secure standalone systems. Key rings (collections of keys) should be stored on a floppy disk, which the user must keep in a safe place. The use of smart cards for storing keys is to be preferred.

A backup copy of the SECRING.* file should also be created, and a note made of the passphrase. The backup copy and the passphrase should be stored securely, and best of all separately, to ensure that the private key cannot be lost as a result of a hard disk crash or because of a user error. Messages which have been encrypted with the public key can no longer be decrypted if this happens.

Writing down the passphrase and placing it in safekeeping in a secure location should be seen as a critical process serving solely the purpose of contingency planning. A locked drawer in a desk or a similar "secure" location can under no circumstances be recommended as a storage location for the secret key or for the passphrase.

Distribution of keys

For a recipient to be able to check the digital signature of the originator of a file or for the originator to be able encrypt a message for a particular recipient, it is necessary to have the public key of the communication partner in each case. This can be obtained in various ways, for example, as an attachment to an e-mail or from a WWW server. However, the user must satisfy himself that the key really belongs to the specified person. Certificates are used to ensure the cryptographically secure assignment of a person to a public key. The certificates are issued by a trusted third party.

With GnuPG and PGP, every user can authenticate the public keys of other people with certificates. However, a user should only certify a public key if he or she knows or has checked the identity of the owner of the key and the public key was handed over personally.

Alternatively, the authenticity of a public key can also be verified with the aid of the "fingerprint". This involves calculating a number sequence (hash value) from the public key and appending it to the key. After a public key has been sent, the recipient can contact the originator to compare the number sequence, for example by telephone, in order to certify the public key after confirmation of the fingerprint.

Certification hierarchy - web of trust - Internet key server

Essentially, GnuPG and PGP can be used both in a certification hierarchy and in a "web of trust". In a web of trust, the certificates of other users are relied upon to be trustworthy, whereas in a certification hierarchy trusted third parties, known as certification authorities, authenticate the keys of all of their users in a reliable and demonstrable way.

Within a company or an agency, a certification hierarchy should be established in the intranet. The support person should certify all the keys for his or her area of the organisation or for the organisation as a whole. The certified public keys should be accessible to all members of staff on a server in the intranet. Access to this area should be exclusively read-only, however. The web of trust method should only be used for private communications.

In the Internet, public keys can be made available on key servers. These must in no way be confused with certification authorities, however. Key servers receive keys from anywhere, and distribute them on request. It should be made clear that keys which are obtained from a key server are not checked by the key server in any way.

To verify the authenticity of a public key that has been made available on a key server, the fingerprint technique mentioned above should be used.

The public key's self signed certificate

Of the parts of a GnuPG or PGP public key, only the user ID is signed by the public key's self signature. The use of self signed cerificates makes it possible to detect a denial-of-service attack (see T 5.28 Denial of services), but it does not prevent such an attack. As the user ID of a public key is not encrypted, it can become corrupted. The consequence of this would be that, if a "corrupt" key is used, the encrypted e-mails would no longer reach the owner of the key because they would be redirected to a different e-mail address. The confidentiality of the encrypted message is not put at risk because of this, as the message can only be decrypted using the private key.

Key recovery

If the keys used for encryption are lost, this generally also means that the data protected by the keys is also lost. In the commercial versions, 5.0 or higher, PGP includes functions for retrieving data in such instances. These functions are also referred to as key recovery functions. The functionality they offer can prevent the loss of data by recovering stored, encrypted data in the event of a key or access password being lost.

If it is intended to use the recovery function of PGP, either one or two additional decryption keys (ADKs) must be generated. During key generation, these additional keys are attached to the newly created keys, and all the data that is encrypted with the new keys additionally incorporates encryption of the session key with the ADKs. In this way it is possible in an emergency to decrypt the data using the ADKs, without using the original key. PGP is thus able to offer a message recovery function without the need for central storage of the recovery information.

Use of key recovery can be enforced through appropriate default settings on the clients, ensuring that this functionality cannot be circumvented by individual users. In that case, however, the security of the whole encryption system is dependent on the confidentiality of the ADKs. If the ADKs are disclosed, they can be used to decrypt all of the data.

To prevent misuse of this highly sensitive function it is essential that the ADKs are protected with a particularly carefully chosen password that is kept in a safe place. In addition, as of PGP Version 6.0, keys can also be divided into several parts, which means that several people have to take action jointly in order to use them. This form of two-person control rule should always be used when ADKs are used. To give further protection, provision can be made for users to be warned every time that they encrypt data with a key to which ADKs are attached.

Before PGP is used with key recovery, the advantages and disadvantages should be weighed up against each other. On the one hand it protects against loss of data as a result of losing a key, but on the other it creates a central weak point in the encryption system. This function should therefore only be used if PGP is used for encrypting stored data. If it is used solely for securing communications, in the event of the loss of a key it is also possible simply to request that the e-mail be sent again. It should also be examined whether as an alternative lodging the password in a safe place in a sealed envelope and creating backup copies of the private key files would not be preferable to the use of ADKs.

Key Reconstruction

Version 7 PGP offers another possibility of guarding against losing the key, for example through the forgetting of passphrases. The key is split into several portions, superencrypted and stored on a recovery server. During key escrow, the user-specifies five question-answer combinations. The user must answer at least three of the five questions correctly in order to recover his key.

Under this approach there is a danger that users will specify questions whose answers could be guessed or worked out by third parties, for example, the names of relatives or dates of birth. As a result a third party could gain unauthorised access to the user's keys. As the quality of the question/answer combinations generally can not be checked, this function should not be used. Instead it is recommended taking a backup copy of the private key files on a data medium and keeping this in a secure place. The associated passphrase must also be lodged in a sealed envelope (see S 2.22 Escrow of passwords).

Single Sign On

Under the names of "Single Sign-On" and "Passphrase caching" from version 7 PGP offers a mechanism for temporarily holding the passphrase entered by the user so that the user does not have to enter it for every action. But this creates the danger that unauthorised persons could encrypt or decrypt documents or sign documents digitally using the identity of the user when the user is temporarily away from his desk

If PGP's passphrase caching function is to be used, it is therefore imperative that the user's computer is directly blocked even when he is away from his desk for only a short time. This can be achieved, for example, using the Lock computer function within Windows NT as long as a strong user password is in use or with the aid of a smart card user authentication solution. In all other cases the option "Do not cache passphrase" should be activated in the "PGP Options" dialogue box.

Additional controls:

• Are users trained in the use of GnuPG/PGP?

• Are the data and keys stored separately?

• Are backup copies made of the private keys? Are these kept in a secure location?