S 5.63 Use of GnuPG or PGP

Initiation responsibility: Administrator, IT Security Officer

Implementation responsibility: User

GNU Privacy Guard (GnuPG) and Pretty Good Privacy (PGP) are common programs that can be used to encrypt and decrypt, as well as to add a digital signature (also electronic signature) to messages and files. Both tools implement functions defined in the OpenPGP standard (RFC 2440). Encryption is used to protect the confidentiality of information and digital signatures are used to check whether a file and/or message is authentic and has not been manipulated. Furthermore, both GnuPG and PGP can be used to assume the tasks of key management such as adding or removing keys.

Encryption and digital signature

For GnuPG and PGP, symmetric and asymmetric cryptographic procedures are used. Symmetric procedures such as AES and IDEA serve for data encryption; asymmetric procedures such as ElGamal, RSA, and DSA/DSS server for key management and/or signature generation.

Both tools generate and use public and private keys in so-called key pairs. There is exactly one public key for every private key. It is practically impossible to calculate the private key when only the public key is known. A message encrypted with a public key and/or signed with the private key can only be decrypted with the related private key and/or verified with the public key of the sender. The public key may be disclosed to everybody. It serves for encrypting messages to the owner of the private key.

In order to demonstrate unauthorised manipulations and therefore to provide protection against changes to a message, GnuPG and/or PGP calculates a check code for the message, the digital signature, using the private key of the sender . Each communication partner may use the public key of the sender of the message in order to determine whether the check code at the end of the message matches the received message or whether the message was changed in an unauthorised manner.

At a technical level, the keys for digital signatures and the keys for encryption are normally separated for reasons of security. This is usually transparent for the user.

When using GnuPG or PGP, it is recommendable to combine both functionalities described above. By default, messages and/or files should initially be signed with the private key of the sender and then encrypted with the public key of the recipient in order to attain the highest possible protection.

Versions

Both GnuPG and PGP are available for the most commonly used computer platforms (Unix, GNU/Linux, Microsoft Windows). PGP also includes versions for MacOS. GnuPG is a free software/open source and the currently latest version is 1.2.3.

Commonly used versions of PGP include 2.6.3i and 5.x to 8.x. The versions 5.x and higher are equipped with a graphical user interface, but not entirely backward compatible with the previous versions.

Due to the lack of backwards compatibility, it is recommendable to ask the communication partners which PGP version they use before exchanging encrypted messages. The still commonly used version 2.6.3i is command line oriented, but may be integrated into graphical user interfaces and email clients by means of additional programs. PGP may be obtained from different sources, amongst other things freeware versions from diverse WWW, FTP, or email servers.

GnuPG and PGP are currently not entirely interoperable with each other either. The reasons for this include software patents (the IDEA algorithm used by some PGP versions by default is patented) on the one hand, and minor deviations from the OpenPGP standard on the other hand. However, a significant obstacle is no longer applicable now the RSA patent has expired. RSA is supported by GnuPG in the version 1.0.3 and higher.

In order to avoid these problems, only one of the tools should be used, if possible. If this is not possible, only OpenPGP compatible keys should be used. This way, it is also ensured that the communication partners have a common symmetric algorithm with Triple-DES. The interoperability issue relating to the use of IDEA described above is not applicable in this case. Further information can be found in the frequently asked questions section on the website of the GnuPG project at www.gnupg.org And www.gnupg.de.

In Version 5 and higher of PGP the controversial Corporate Message Recovery (CMR) function was introduced. CMR provides the option of simultaneously making files or messages encrypted by one person for a second person decryptable for a third person. Using such a "third party key" may be specified mandatorily in the configuration by the administrator.

The PGP version 7 contains two further functions that can be used to circumvent security functions. On the one hand, a server-based recovery mechanism for keys was introduced that can be used by the users in order to reuse keys if they have forgotten the related passphrase, for example. The other function is called Passphrase Caching, within the framework of which the passphrase is cached so that it is not necessary for the user to enter the phrase every time when switching between different PGP subsystems. A comparable mechanism is also available in version 2.6.3i where the passphrase can be stored in an environmental variable. This mechanism should not be used.

Particularly when using GnuPG or PGP in operating systems of the Windows family, it must be observed that the security mechanisms of these tools may be circumvented by using security shortcomings of the operating system.

Secure installation and use

GnuPG and PGP use cryptographic procedures acknowledged as being secure, but the level of security may be lowered by improper configuration or incorrect operation. Installation and configuration, including key generation, of GnuPG and PGP is quite difficult, as with most more complex encryption products. In order to avoid incorrect operation, familiarisation with the respective product and with some basic cryptographic terms is necessary.

Therefore, one employee of the organisation should become familiar with the operation of the tool and should be available as contact person. This employee should then instruct other users with regard to the secure operation of GnuPG and/or PGP; encryption, signature, and key management should be trained intensively in particular before a user can use the program. Furthermore, it is recommendable to use a uniform program version within individual organisations in order to avoid the compatibility issues described above. Both GnuPG and PGP come with a comprehensive documentation which should be read before use. Since experience has shown that not all users are patient enough to read the entire documentation, it is recommendable to draw up written instructions adapted to the organisational units.

Should the users have any questions regarding GnuPG or PGP exceeding the supplied documentation, there are various options:

Key generation

For GnuPG and PGP, every user generates his/her "key pair" self dependently. In doing so, the following aspects should be taken into consideration:

Storage of keys

The private keys are stored in the SECRING.* file. A deciding factor for the secure use is that the content of this file remains confidential and is protected against manipulation. Access to this file is protected by means of the passphrase, but it should nevertheless not be stored in local networks, not even on insufficiently secured standalone systems. Key rings (collections of keys) should be stored to a diskette the user must store carefully. The use of chip cards for storing the key should be preferred.

Furthermore, a backup copy of the SECRING.* file should be created and the passphrase should be written down. The backup copy and the passphrase should be stored securely and ideally separate from each other so that the private key is not lost due to a hard disk crash or incorrect operation. Messages encrypted with the public key can no longer be decrypted in this case.

Writing down and depositing the passphrase at a protected location should be considered a critical process which exclusively serves for contingency planning. The locked drawer of a desk or similar "secure" locations can in no event be recommended as a storage location for the confidential key or the passphrase.

Revocation certificate

After having generated the key, a so-called Revocation Certificate should be generated and printed out and/or stored to a diskette. This can be used to revoke the public key if the passphrase is forgotten or the private key is no longer available for other reasons. The Revocation Certificate should be stored securely so that the public key cannot be revoked in an unauthorised manner.

Key distribution

For a recipient to be able to verify the digital signature of the sender of a file and/or for the sender of the message to be able to encrypt a message for a certain recipient, they require the public key of their communication partner. The public key can be obtained by different means, e.g. via email attachment or from a WWW server; however, it must be ensured that this key actually belongs to the corresponding person. In order to assign a person to his/her public key in a cryptographically secured manner, certificates issued by a trustworthy third party are used.

For GnuPG and PGP, each user may certify the public keys of another person by means of certificates. However, a user should only certify a public key if he/she knows or has checked the identity of the key owner and if the public key was transferred in person.

Alternatively, the authenticity of a public key may also be verified using the so-called Fingerprint. Here, a numerical sequence (hash value) from the public key is calculated and attached to the public key. After a public key was sent, this numerical sequence can now be compared with the sender via telephone, for example, in order to certify the sent public key after the fingerprint has been confirmed.

Certification hierarchy - Web of Trust - Internet-Keyserver

As a matter of principle, GnuPG and PGP can be used both in a certification hierarchy and in a Web of Trust. In the Web of Trust, the certificates of other users are trusted; in a certification hierarchy, trustworthy third parties, so called certificate authorities certify the keys of all users in a reliable and comprehensible manner.

A certification hierarchy should be established on the intranet of a company or government agency. The administrator should certify all keys for his/her organisational area and/or for the entire organisation. The certified public keys should be available to all employees on a server on the intranet; access to this area should be read-only in this. The Web of Trust method should only be used for private communication.

Public keys can be made available on so-called key servers on the internet. However, these servers must not be mistaken for certificate authorities. Key servers receive the keys from any location and further distribute the keys upon request. It should be clear that keys received by a key server were not checked by the server in any way.

In order to verify the authenticity of a public key made available on a key server, this should be performed with the help of the previously mentioned fingerprints.

Self-signature of the public key

By self-signing the public key, only the user IT is signed by GnuPG and/or PGP as part of the public key. With the help of self-signature, it is possible to detect a denial-of-service attack (see T 5.28 Denial of services); however, this attack may not be prevented by self-signing the public key. Since the user ID of a public key is not encrypted, it may be falsified. As a consequence, the encrypted emails would no longer be received by the owner of the key when using this "falsified" key, since they are redirected to a different email address. The confidentiality of the encrypted message is not endangered by the aforementioned, since the message may only be decrypted with the private key.

Key recovery

If the keys used for the purpose of encryption are lost, the data protected with the help of the keys is generally lost as well. In the commercial versions 5.0 and higher, PGP offers data recovery functions for cases like this. These functions are also called key recovery. This functionality may avoid a loss of data by restoring stored, encrypted data if the key or the access password was lost.

For older PGP versions, errors in the ADK implementation (Additional Decryption Key) have become known that may be used for attacks. This particularly applies to the PGP predecessor versions of 6.5.8. Therefore, a sufficiently recent version should be used, in which as many security-relevant errors as possible have been eliminated. GnuPG ignores all ADKs as a matter of principle.

If the recovery function of PGP is to be used, one or two additional keys (ADK, Additional Decryption Keys) must be generated. During key generation, these "duplicate keys" are attached to the newly generated keys and all data encrypted using the new keys is additionally encrypted with the session key using the ADKs. This way, it is possible to decrypt the data using these ADKs in cases of emergency without using the genuine key. Therefore, PGP offers the Message Recovery function without central storage of the recovery information.

Using the Key recovery function may be made mandatory by corresponding pre-settings of the clients so that this functionality cannot be circumvented by individual users. However, the security of the entire encryption depends on the confidentiality of the ADKs. If these are disclosed, they can be used to decrypt all data.

In order to prevent this highly sensitive function from being misused, it is absolutely necessary to protect the ADKs with a password selected particularly carefully and stored particularly safely. Additionally, keys may also be divided into parts in PGP version 6.0 and higher so that several persons must take actions in order to use the keys. This form of the two-man rule should absolutely be used when using ADKs. The users being warned every time they encrypt data with a key containing attached ADKs may provide additional protection.

Before PGP, including Key recovery, is used, the advantages and disadvantages should be weighted. On the one hand, loss of data caused by the key being lost is prevented, but a central weakness of the encryption system is introduced on the other hand. Therefore, this function should only be used if PGP is used for encrypting stored data. When using PGP only for protecting communication, the email may simply be requested again when the key is lost. It should also be checked whether depositing the password at a secure location in a sealed envelope and the generation of backup copies of the private key files would be preferable as an alternative.

Key reconstruction

Version 7 of PGP offers another option to prevent problems caused by lost keys, for example by forgetting the passphrase. For this, the key is divided into several parts, protected by a second encryption, and stored to the recovery server. While depositing, the user defines five question/answer combinations. The user must provide the correct answers for at least three of the five questions in order to be able to restore his/her key.

This function entails the risk of users defining questions the answers to which may be guessed or determined by third parties, for example the names of relatives or birth dates. As a consequence, third parties may be able to access keys of the user. Since the quality of the question/answer combinations can normally not be checked either, this function should not be used. Instead, it is recommendable to create a backup copy of the private key files on a data medium and to store the data medium at a secure location. The related passphrase also must be deposited in a sealed envelope (see S 2.22 Escrow of passwords).

Single sign on

Under the terms Single Sign-On and Passphrase Caching, PGP offers a mechanism of caching the passphrase entered by the user in version 7 and higher so that the user does not have to re-enter this information for each action. This entails the risk that unauthorised persons are able be encrypt or decrypt and/or digitally sign documents using the identity of the user when the user leaves his/her workplace for a short period of time.

If the Passphrase Caching function of PGP is to be used, it must therefore be made sure in any case that the computer of the user is locked immediately even if the workplace is left for short periods of time. For example, this may be performed using the Lock workstation function of Windows NT, if a strong user password has been assigned, or with the help of a chip card solution for user authentication. In all other cases, the Do not cache passphrase option should be activated in the PGP Options dialogue.

Review questions:

© Federal Office for Information Security. All rights reserved.