diff --git a/doc/manual/gpg4win-compendium-en.org b/doc/manual/gpg4win-compendium-en.org index e8f85a60..c1b864fc 100644 --- a/doc/manual/gpg4win-compendium-en.org +++ b/doc/manual/gpg4win-compendium-en.org @@ -1,5378 +1,5378 @@ #+STARTUP: showall indent #+TITLE: The Gpg4win Compendium #+AUTHOR: A publication of the Gpg4win Initiative #+DATE: November 2013 # #+OPTIONS: toc:nil #+LaTeX_CLASS: book #+LaTeX_CLASS_OPTIONS: [a4paper,10pt,twoside,openright,titlepage] #+LATEX_HEADER: \usepackage{times} # LATEX_HEADER: \usepackage{fancyhdr} #+LATEX_HEADER: \usepackage{makeidx} #+LATEX_HEADER_EXTRA: \DeclareUnicodeCharacter{21A9}{$\hookleftarrow$} #+macro: Button /[\thinsp{}$1\thinsp]/ #+macro: Menu /$1/ #+macro: MarginPGP @@latex:\marginpar{\includegraphics[width=1.5cm]{openpgp-icon.png}}@@ #+macro: MarginCMS @@latex:\marginpar{\includegraphics[width=1.5cm]{smime-icon.png}}@@ #+BEGIN_LaTeX \parindent 0cm \parskip\medskipamount \frontmatter \begin{titlepage} \begin{center} - \includegraphics[width=0.8\textwidth]{gpg4win-logo.png} + \includegraphics[width=0.8\textwidth]{images-compendium/gpg4win-logo.png} \\[10mm] \LARGE The Gpg4win Compendium \\[3mm] \Large \textmd{Secure mail and file encryption\\ using GnuPG for Windows} \\[10mm] \vspace*{100mm} \small A publication of the Gpg4win Initiative \\[10mm] \large November 2013 \end{center} \begin{titlepage} #+END_LaTeX ** Publisher’s details #+LaTeX: \thispagestyle{empty} Copyright © 2002 Bundesministerium für Wirtschaft und Technologie [1]\\ Copyright © 2009, 2010 Intevation GmbH\\ Copyright © 2005, 2013 g10 Code GmbH\\ Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”. -------------- This book is based on a version by Ute Bahn Karl Bihlmeier, Manfred J. Heinze, Isabel Kramer and Dr. Francis Wray. It has been extensively revised by Werner Koch, Florian v. Samson, Emanuel Schütze and Dr. Jan-Oliver Wagner. It has been translated from the German original by Brigitte Hamilton. #+LaTeX:\newpage ** About this compendium The Gpg4win Compendium consists of three parts: - *Part [[#part:Novices][“For Novices”]]*: A quick course in Gpg4win. - *Part [[#part:AdvancedUsers][“For Advanced Users”]]*: Background information for Gpg4win. - *[[#part:Annex][Annex]]*: Additional technical information about Gpg4win. *Part [[#part:Novices][“For Novices”]]* provides a brief guide for the installation and daily use of Gpg4win program components. The practice robot *Adele* will help you with this process and allow you to practice the de- and encryption process (using OpenPGP) until you have become familiar with Gpg4win. The amount of time required to work through this brief guide will depend on your knowledge of your computer and Windows. It should take about one hour. *Part [[#part:AdvancedUsers][“For Advanced Users”]]* provides background information which illustrates the basic mechanisms on which Gpg4win is based, and also explains some of its less commonly used capabilities. Part I and II can be used independently of each other. However, to achieve an optimum understanding, you should read both parts in the indicated sequence, if possible. The *[[#part:Annex][Annex]]* contains details regarding the specific technical issues surrounding Gpg4win, including the GpgOL Outlook program extension. Just like the cryptography program package Gpg4win, this compendium was not written for mathematicians, secret service agents or cryptographers, but rather was written to be read and understood *by anyone.* The Gpg4win program package and compendium can be obtained at: [[http://www.gpg4win.org]] #+LaTeX:\newpage ** Typographical conventions This compendium uses the following text markers: - /Italics/ are used for text that appears on a screen (e.g. in menus or dialogs). In addition, square brackets are used to mark {{{Button(buttons)}}}. Sometimes italics will also be used for individual words in the text, if their meaning in a sentence is to be highlighted without disrupting the text flow, by using *bold* fond (e.g. /only/ OpenPGP). - *Bold* is used for individual words or sentences which are deemed particularly important and hence must be highlighted. These characteristics make it easier for readers to quickly pick up highlighted key terms and important phrases. - =Typewriter font= is used for all file names, paths, URLs, source codes, as well as inputs and outputs (e.g. for command lines). - A left arrow with a hook (↩) at the end of a line indicates that the line is continued at the next line without an actual line break. #+TOC: headlines 3 #+LaTeX: \mainmatter * For Novices :PROPERTIES: :CUSTOM_ID: part:Novices :END: # This part provides a brief guide for the installation and daily use of # Gpg4win program components. The practice robot *Adele* will help you # with this process and allow you to practice the de- and encryption # process (using OpenPGP) until you have become familiar with Gpg4win. # # The amount of time required to work through this brief guide will # depend on your knowledge of your computer and Windows. It should take # about one hour. ** Gpg4win --- Cryptography for Everyone #+index: Cryptography What is Gpg4win? Wikipedia answers this question as follows: #+BEGIN_QUOTE Gpg4win is an installation package for Windows (2000/XP/2003/Vista) with computer programs and handbooks for emailand file encryption. It includes the GnuPG encryption software, as well as several applications and documentation. Gpg4win itself and the programs contained in Gpg4win are Free Software. #+END_QUOTE The "Novices" and "Advanced Users" handbooks have been combined for this second version under the name "Compendium". In Version 2, Gpg4win includes the following programs: #+index: GnuPG - GnuPG :: GnuPG forms the heart of Gpg4win --- the actual encryption software. #+index: Kleopatra - Kleopatra :: #+index: Certificate Administration The central certificate administration of Gpg4win, which ensures uniform user navigation for all cryptographic operations. #+index: GNU Privacy Assistant|see GPA #+index: GPA - GNU Privacy Assistant (GPA) :: is an alternative program for managing certificates, in addition to Kleopatra. #+index: GnuPG for Outlook|see GpgOL #+index: GpgOL - GnuPG for Outlook (GpgOL) :: is an extension for Microsoft Outlook 2003 and 2007, which is used to sign and encrypt messages. #+index: GPG Explorer eXtension|see GpgEX #+index: GpgEX #+index: Windows-Explorer - GPG Explorer eXtension (GpgEX) :: is an extension for Windows Explorer which can be used to sign and encrypt files using the context menu. #+index: Claws Mail - Claws Mail :: is a full email program that offers very good support for GnuPG. Using the GnuPG (GNU Privacy Guard) encryption program, anyone can encrypt emails securely, easily and at no cost. GnuPG can be used privately or commercially without any restrictions. The encryption technology used by GnuPG is secure, and cannot be broken based on today's state of technology and research. #+index: Free Software GnuPG is *Free Software* [2]. That means that each person has the right to use this software for private or commercial use. Each person may and can study the source code of the programs and --- if they have the required technical knowledge --- make modifications and forward these to others. With regard to security software, this level of transparency --- guaranteed access to the source code --- forms an indispensable foundation. It is the only way of actually checking the trustworthiness of the programming and the program itself. #+index: OpenPGP #+index: S/MIME #+index: X.509 GnuPG is based on the international standard *OpenPGP* (RFC 4880), which is fully compatible with PGP and also uses the same infrastructure (certificate server etc.) as the latter. Since Version 2 of GnuPG, the cryptographic standard *S/MIME* (IETF RFC 3851, ITU-T X.509 and ISIS-MTT/Common PKI) are also supported. #+index: PGP PGP ("Pretty Good Privacy") is not Free Software; many years ago, it was briefly available at the same conditions as GnuPG. However, this version has not corresponded with the latest state of technology for some time. #+index: Bundesministerium für Wirtschaft und Technologie #+index: Bundesamt für Sicherheit in der Informationstechnik Gpg4win's predecessors were supported by the Bundesministerium für Wirtschaft und Technologie as part of the Security on the Internet initiative. Gpg4win and Gpg4win2 were supported by the Bundesamt für Sicherheit in der Informationstechnik (BSI). Additional information on GnuPG and other projects undertaken by the Federal Government for security on the Internet can be found on the webpages http://www.bsi.de and http://www.bsi-fuer-buerger.de of the Bundesamt für Sicherheit in der Informationstechnik. ** Encrypting emails: because the envelope is missing :PROPERTIES: :CUSTOM_ID: ch:why :END: #+index: Envelope The encryption of messages is sometimes described as the second-oldest profession in the world. Encryption techniques were used as far back as Egypt's pharaoh Khnumhotep II, and during Herodot's and Cesar's time. Thanks to Gpg4win, encryption is no longer the reserve of kings, but is accessible to everyone, for free. #+ATTR_HTML: width=300 #+ATTR_LaTeX: width=0.9\textwidth [[file:images-compendium/egyptian-stone.png]] Computer technology has provided us with some excellent tools to communicate around the globe and obtain information. However, rights and freedoms which are taken for granted with other forms of communication must still be secured when it comes to new technologies. The Internet has developed with such speed and at such a scale that it has been difficult to keep up with maintaining our rights. With the old-fashioned way of writing a letter, written contents are protected by an envelope. The envelope protects messages from prying eyes, and it is easy to see if an envelope has been manipulated. Only if the information is not important, do we write it on an unprotected post card, which can also be read by the mail carrier and others. You and no one else decides whether the message is important, confidential or secret. emails do not provide this kind of freedom. An email is like a post card - always open, and always accessible to the electronic mailman and others. It gets even worse: while computer technology offers the option of transporting and distributing millions of emails, it also provides people with the option of checking them. #+index: Echelon system Previously, no one would have seriously thought about collecting all letters and postcards, analyse their contents or monitor senders and recipients. It would not only have been unfeasiable, it would have also taken too long. However, modern computer technology has made this a technical possibility. There are indications that this is already being done on a large scale. A Wikipedia article on the Echelon system [3] provides interesting background information on this topic. Why is this an issue --- because the envelope is missing. #+ATTR_HTML: width=300 #+ATTR_LaTeX: width=0.5\textwidth [[file:images-compendium/sealed-envelope.png]] What we are suggesting here is essentially an "envelope" for your electronic mail. Whether you use it, when or for whom and how often - that is entirely up to you. Software such as Gpg4win merely returns the right to choose to you. The right to choose whether you think a message is important and requires protection. #+index: Telecommunication secrecy #+index: Mail secrecy #+index: Correspondence secrecy This is the key aspect of the right to privacy of correspondence, post and telecommunications in the Basic Law, and the Gpg4win program package allows you to exercise this right. You do not have to use this software, just as you are not required to use an envelope. But you have the right. To secure this right, Gpg4win offers a so-called "strong encryption technology". "Strong" in this sense means that it cannot be broken with known tools. Until recently, strong encryption methods used to be reserved for military and government circles in many countries. The right to make them accessible to all citizens was championed by Internet users, and sometimes also with the help of visionary people in government institutions, as was the case with support for Free Software for encryption purposes. Security experts around the world now view GnuPG as a practical and secure software. *It is up to you how you want to value this type of security.* You alone decide the relationship between the convenience of encryption and the highest possible level of security. These include the few but important precautions you must make to implement to ensure that Gpg4win can be used properly. This compendium will explain this process on a step-by-step basis. ** How Gpg4win works :PROPERTIES: :CUSTOM_ID: ch:FunctionOfGpg4win :END: #+index: public key method The special feature of Gpg4win and its underlying *“Public Key method”* is that anyone can and should understand it. There is nothing secretive about it --- it is not even very difficult to understand. The use of individual Gpg4win program components is very simple, even though the way it works is actually quite complicated. This section will explain how Gpg4win works --- not in all details, but enough to explain the principles behind this software. Once you are familiar with the principles, you will have considerable trust in the security offered by Gpg4win. At the end of this book, in Chapter\ref{ch:themath}, you can also open the remaining secrets surrounding "Public Key" cryptography and discover why it is not possible to break messages encrypted with Gpg4win using current state of technology. **** Lord of the keyrings Anyone wishing to secure something valuable locks it away --- with a key. Even better is a key that is unique and is kept in a safe location. #+ATTR_HTML: width=300 #+ATTR_LaTeX: width=0.5\textwidth [[file:images-compendium/schlapphut-with-key.png]] If the key should ever fall into the wrong hands, the valuables are no longer secure. Their security stands and falls with the security and uniqueness of the key. Therefore the key must be at least as well protected as the valuables themselves. To ensure that it cannot be copied, the exact characteristics of the key must also be kept secret. Secret keys are nothing new in cryptography: it has always been that keys were hidden to protect the secrecy of the messages. Making this process very secure is very cumbersome and also prone to errors. #+ATTR_HTML: width=300 #+ATTR_LaTeX: width=0.5\textwidth -file:tangled-schlapphut.png +[[file:images-compendium/tangled-schlapphut.png]] #+index: Symmetric encryption The basic problem with the "ordinary" secret transmission of messages is that the same key is used for both encryption and decryption, and that both the sender as well as recipient must be familiar with this secret key. For this reason, these types of encryption systems are also called *"symmetric encryption"*. This results in a fairly paradoxical situation: Before we can use this method to communicate a secret (an encrypted message), we must have also communicated another secret in advance: the key. And that is exactly the problem, namely the constantly occuring issue of always having to exchange keys while ensuring that they are not intercepted by third parties. In contrast --- and not including the secret key --- Gpg4win works with another key that is fully accessible and public. It is also described as a "public key" encryption system. This may sound contradictory, but it is not. The clue: It is no longer necessary to exchange a secret key. To the contrary: The secret key can never be exchanged! The only key that can be passed on is the public key (in the public certificate) --- which anyone can know. #+index: Key!pair That means that when you use Gpg4win, you are actually using a pair of keys --- a secret and a second public key. Both key components are inextricably connected with a complex mathematical formula. Based on current scientific and technical knowledge, it is not possible to calculate one key component using the other, and it is therefore impossible to break the method. Section \ref{ch:themath} explains why that is. #+ATTR_LaTeX: width=0.5\textwidth [[file:images-compendium/verleihnix.png]] #+index: public key method The principle behind public key encryption The *secret* or *private key* must be kept secret. The *public key* should be as accessible to the general public as much as possible. Both key components have very different functions: #+BEGIN_QUOTE The secret key component *decrypts* messages. #+END_QUOTE #+ATTR_LaTeX: width=0.75\textwidth -file:key-with-shadow-bit.png +[[file:images-compendium/key-with-shadow-bit.png]] #+BEGIN_QUOTE The public key component *encrypts* messages. #+END_QUOTE **** The public mail strongbox #+index: Mail strongbox #+index: Symmetric encryption #+index: non-public key method|see Symmetric encryption This small exercise is used to explain the difference between the "public key" encryption system and symmetric encryption ("non-public key" method)... *The "secret key method" works like this:* Imagine that you have installed a mail strongbox in front of your house, which you want to use to send secret messages. The strongbox has a lock for which there is only one single key. No one can put anything into or take it out of the box without this key. This way, your secret messages are pretty secure. #+ATTR_LaTeX: width=0.75\textwidth [[file:images-compendium/letter-into-safe.png]] Since there is only one key, the person you are corresponding with must have the same key that you have in order to open and lock the mail strongbox, and to deposit a secret message. You have to give this key to that person via a secret route. #+ATTR_LaTeX: width=0.75\textwidth [[file:images-compendium/secret-key-exchange.png]] They can only open the strongbox and read the secret message once they have the secret key. Therefore everything hinges on this one key: If a third party knows the key, it is the end of the secret messages. Therefore you and the person you are corresponding with *must exchange the key in a manner that is as secret* as the message itself. But actually --- you might just as well give them the secret message when you are giving them the key... *How this applies to email encryption:* Around the world, all participants would have to have secret keys and exchange these keys in secret before they can send secret messages per email. So we might as well forget about this option ... #+ATTR_LaTeX: width=0.75\textwidth -file:letter-out-of-safe.png +[[file:images-compendium/letter-out-of-safe.png]] *Now the "public key" method* #+index: Mail strongbox #+index: Asymmetric encryption You once again install a mail strongbox in front of your house. But unlike the strongbox in the first example, this one is always open. On the box hangs a key --- which is visible to everyone --- and which can be used by anyone to lock the strongbox (asymetric encryption method). *Locking, but not opening:* that is the difference! #+ATTR_LaTeX: width=0.7\textwidth [[file:images-compendium/pk-safe-open.png]] This key is yours and --- as you might have guessed --- it is your public key. If someone wants to leave you a secret message, they put it in the strongbox and lock it with your public key. Anyone can do this, since the key is available to everyone. No one else can open the strongbox and read the message. Even the person that has locked the message in the strongbox cannot unlock it again, e.g. in order to change the message. This is because the public half of the key can only be used for locking purposes. The strongbox can only be opened with one single key: your own secret and private part of the key. *Getting back to how this applies to email encryption:* Anyone can encrypt an email for you. #+index: Key!public #+index: Key!private To do this, they do not need a secret key; quite the opposite, they only need a totally non-secret , "public" key. Only one key can be used to decrypt the email, namely your private and secret key. You can also play this scenario another way: If you want to send someone a secret message, you use their mail strongbox with their own public and freely available key. To do this, you do not need to personally know the person you are writing to, or have to speak to them, because their public key is always accessible, everywhere. One you have placed your message in the strongbox and locked it with the recipient's key, the message is not accessible to anyone, including you. Only the recipient can open the strongbox with his private key and read the message. #+ATTR_LaTeX: width=0.75\textwidth -file:pk-safe-opened-with-sk.png +[[file:images-compendium/pk-safe-opened-with-sk.png]] *But what did we really gain:* There is still a secret key! However, this is quite different from the "non-public key" method: You are the only one who knows and uses your secret key. The key is never forwarded to a third party --- it is not necessary to transfer keys in secret, nor is it advised. Nothing must be passed between sender and recipient in secret --- whether a secret agreement or a secret code. And that is exactly the crux of the matter: All symmetric encryption methods can be broken because a third party has the opportunity to obtain the key while the key is being exchanged. #+index: Key!pair This risk does not apply here, because there is no exchange of secret keys; rather, it can only be found in one and very secure location: your own keyring --- your own memory. #+index: Asymmetric encryption This modern encryption method which uses a non-secret and public key, as well as a secret and private key part is also described as "asymmetric encryption". ** The passphrase :PROPERTIES: :CUSTOM_ID: ch:passphrase :END: #+index: Passphrase As we have seen in the last chapter, the private key is one of the most important components of the "public key" or asymmetric encryption method. While one no longer needs to exchange the key with another party in secret, the security of this key is nevertheless the "key" to the security of the "entire" encryption process. On a technical level, a private key is nothing more than a file which is stored on your computer. To prevent unauthorised access of this file, it is secured in two ways: #+ATTR_LaTeX: width=0.5\textwidth -file:think-passphrase.png +[[file:images-compendium/think-passphrase.png]] #+index: Viruses #+index: Worms #+index: Trojans First, no other user may read or write in the file --- which is difficult to warrant, since computer administrators always have access to all files, and the computer may be lost or attacked by viruses, worms or Trojans. For this reason we need another layer of protection: the passphrase. This is not a password --- a passphrase should not consist of only one word, but a sentence, for example. You really should keep this passphrase "in your head" and never have to write it down. At the same time, it cannot be possible to guess it. This may sound contradictory, but it is not. There are several proven methods of finding very unique and easy to remember passphrases, which cannot be easily guessed. Think of a phrase that is very familiar to you, e.g.: - =People in glass houses should not be throwing stones.= Now, take every third letter of this sentence: - =oegsoehloerisn= == While it may not be easy to remember this sequence of letters, it is also unlikely that you will forget how to arrive at the passphrase as long as you remember the original sentence. Over time, and the more often you use the phrase, you will commit it to memory. No one else can guess the passphrase. Think of an event that you know you will never forget about. Maybe it's a phrase that you will always associate with your child or partner, i.e. it has become "unforgettable". Or a holiday memory or a line of text of a song that is personally important to you. Use capital and small letters, numbers, special characters and spaces, in any order. In principle, anything goes, including umlaute, special characters, digits etc. But remember --- if you want to use your secret key abroad at a different computer, please remember that not all keyboards may have such special characters. For example, you will likely only find umlaute (ä, ö, ü usw.) on German keyboards. You can also make intentional grammar mistakes, e.g. "mustake" instead of "mistake". Of course you also have to be able to remember these "mustakes". Or, change languages in the middle of the phrase. You can change the sentence: - =In München steht ein Hofbräuhaus.= into this passphrase: - =inMinschen stet 1h0f breuhome= Think of a sentence that does not make sense, but you can still remember e.g.: - =The expert lamenting nuclear homes= - =Knitting an accordeon, even during storms.= A passphrase of this length provides good protection for your secret key. It can also be shorter if you use capital letters, for example: - =THe ExPERt laMenTIng NuclEAr hoMES.= While the passphrase is now shorter, it is also more difficult to remember. If you make your passphrase even shorter by using special characters, you will save some time entering the passphrase, but it is also morr likely that you will forget your passphrase. Here is an extreme example of a very short but also very secure passphrase: - =R!Qw"s,UIb *7\$= However, in practice, such sequences of characters have not proven themselves to be very useful, since there are simply too few clues by which to remember them. A *bad passphrase* can be "broken" very quickly, if it ... - ... is already used for another purpose (e.g. for an email account or your mobile phone). The same passphrase would therefore already be known to another, possibly not secure, software. If the hacker is successful, your passphrase becomes virtually worthless. - ... comes from a dictionary. Passphrase finder programs can run a password through complete digital dictionaries in a matter of minutes --- until it matches one of the words. - ... consists of a birth date, a name or other public information. Anyone planning to decrypt your email will obtain this type of information. - ... is a very common quote, such as "to be or not to be". Passphrase finder programs also use quotes like these to break passphrases. - ... consists of only one word or less than 8 characters. It is very important that you think of a longer passphrase. When composing your passphrase, please *do not use* any of the aforementioned examples. Because anyone seriously interested in getting his hands on your passphrase will naturally see if you used one of these examples. *Be creative!* Think of a passphrase now! Unforgettable and unbreakable. In Chapter \ref{ch:CreateKeyPair} you will need this passphrase to create your key pair. But until then, you have to address another problem: Someone has to verify that the person that wants to send you a secret message is real. ** Two methods, one goal: OpenPGP & S/MIME :PROPERTIES: :CUSTOM_ID: ch:openpgpsmime :END: #+index: OpenPGP #+index: S/MIME #+index: Mail strongbox You have seen the importance of the "envelope" for your email and how to provide one using tools of modern information technology: a mail strongbox, in which anyone can deposit encrypted mails which only you, the owner of the strongbox, can decrypt. It is not possible to break the encryption as long as the private key to your "strongbox" remains your secret. #+index: Authenticity Still: If you think about it, there is still another problem. A little further up you read about how --- in contrast to the secret key method --- you do not need to personally meet the person you are corresponding with in order to enable them to send a secret message. But how can you be sure that this person is actually who they say they are? In the case of emails, you only rarely know all of the people you are corresponding with on a personal level --- and it is not usually easy to find out who is really behind an email address. Hence, we not only need to warrant the secrecy of the message, but also the identity of the sender --- specifically *authenticity*. #+index: Authentication #+index: Chain of trust Hence someone must authenticate that the person who wants to send you a secret message is real. In everyday life, we use ID, signatures or certificates authenticated by authorities or notaries for "authentication" purposes. These institutions derive their right to issue notarisations from a higher-ranking authority and finally from legislators. Seen another way, it describes a chain of trust which runs from "the top" to "the bottom", and is described as a *"hierarchical trust concept"*. #+index: Hierarchical trust concept In the case of Gpg4win or other email encryption programs, this concept is found in almost mirror-like fashion in *S/MIME*. Added to this is*OpenPGP*, another concept that only works this way on the Internet. S/MIME and OpenPGP have the same task: the encryption and signing of data. Both use the already familiar public key method. While there are some important differences, in the end, none of these standards offer any general advantage over another. For this reason you can use Gpg4win to use both methods. #+index: Certificate issuer #+index: Certificate Authority (CA) The equivalent of the hierarchical trust concept is called "Secure / Multipurpose Internet Mail Extension" or *S/MIME*. If you use S/MIME, your key must be authenticated by an accredited organisation before it can be used. The certificate of this organisation in turn was authenticated by a higher-ranking organisation etc. --- until we arrive at a so-called root certificate. This hierarchical chain of trust usually has three links: the root certificate, the certificate of the issuer of the certificate (also CA for Certificate Authority), and finally your own user certificate. #+index: Web of Trust A second alternative and non-compatible notarisation method is the *OpenPGP* standard, does not build a trust hierarchy but rather assembles a *"Web of trust"*. The Web of Trust represents the basic structure of the non-hierarchical Internet and its users. For example, if User B trusts User A, then User B could also trust the public key of User C, whom he does not know, if this key has been authenticated by User A. Therefore OpenPGP offers the option of exchanging encrypted data and emails without authentication by a higher-ranking agency. It is sufficient if you trust the email address and associated certificate of the person you are communicating with. Whether with a trust hierarchy or Web of Trust --- the authentication of the sender is at least as important as protecting the message. We will return to this important protection feature later in the compendium. For now, this information should be sufficient to install Gpg4win and understand the following chapters: - Both methods --- *OpenPGP* and *S/MIME* --- offer the required security. - The methods are *not compatible* with each other. They offer two alternate methods for authenticating your secret communication. Therefore they are not deemed to be interoperable. - Gpg4win allows for the convenient *and parallel* use of both methods --- you do not have to choose one or the other for encryption/signing purposes. Chapter \ref{ch:CreateKeyPair} of this compendium, which discusses the creation of the key pair, therefore branches off to discuss both methods. At the end of Chapter\ref{ch:CreateKeyPair} the information is combined again. In this compendium, these two symbols will be used to refer to the two alternative methods: #+ATTR_LaTeX: width=2.5cm [[file:images-compendium/openpgp-icon.png]] #+ATTR_LaTeX: width=2.5cm [[file:images-compendium/smime-icon.png]] ** Installing Gpg4win #+index: Installation Chapters 1 to 5 provided you with information on the background related to encryption. While Gpg4win also works if you do not understand the logic behind it, it is also different from other programs in that you are entrusting your secret correspondence to this program. Therefore it is good to know how it works. With this knowledge you are now ready to install Gpg4win and set up your key pair. If you already have a GnuPG-based application installed on your computer (e.g. GnuPP, GnuPT, WinPT or GnuPG Basics), please refer to the Annex\ref{ch:migration} for information on transferring your existing certificates. You can load and install Gpg4win from the Internet or a CD. To do this, you will need administrator rights to your Windows operating system. If you are downloading Gpg4win from the Internet, please ensure that you obtain the file from a trustworthy site, e.g.: http://www.gpg4win.org. To start the installation, click on the following file after the download: =gpg4win-2.0.0.exe= (or higher version number). If you received Gpg4win on a CD ROM, please open it and click on the "Gpg4win" installation icon. All other installation steps are the same. The response to the question of whether you want to install the program is {{{Button(Yes)}}}. The installation assistant will start and ask you for the language to be used with the installation process: #+ATTR_LaTeX: width=0.5\textwidth [[file:images-compendium/sc-inst-language_en.png]] Confirm your language selection with {{{Button(OK)}}}. Afterwards you will see this welcome dialog: #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-inst-welcome_en.png]] Close all programs that are running on your computer and click on {{{Button(Next)}}}. The next page displays the *licensing agreement* --- it is only important if you wish to modify or forward Gpg4win. If you only want to use the software, you can do this right away --- without reading the license. #+ATTR_LaTeX: width=0.85\textwidth -file:sc-inst-license_en.png +[[file:images-compendium/sc-inst-license_en.png]] Click on {{{Button(Next)}}}. On the page that contains *the selection of components* you can decide which programs you want to install. A default selection has already been made for you. Yo can also install individual components at a later time. Moving your mouse cursor over a component will display a brief description. Another useful feature is the display of required hard drive space for all selected components. #+ATTR_LaTeX: width=0.85\textwidth -file:sc-inst-components_en.png +[[file:images-compendium/sc-inst-components_en.png]] Click on {{{Button(Next)}}}. The system will suggest a folder for the installation, e.g.: =C:\Programme\GNU\GnuPG=. You can accept the suggestion or select a different folder for installing Gpg4win. #+ATTR_LaTeX: width=0.85\textwidth -file:sc-inst-directory_en.png +[[file:images-compendium/sc-inst-directory_en.png]] Then click on {{{Button(Next)}}}. Now you can decide which *links* should be installed --- the system will automatically create a link with the start menu. You can change this link later on using the Windows dashboard settings. #+ATTR_LaTeX: width=0.85\textwidth -file:sc-inst-options_en.png +[[file:images-compendium/sc-inst-options_en.png]] Then click on {{{Button(Next)}}}. If you have selected the default setting --- *link with start menu* --- you can define the name of this start menu on the next page or simply accept the name. #+ATTR_LaTeX: width=0.85\textwidth -file:sc-inst-startmenu_en.png +[[file:images-compendium/sc-inst-startmenu_en.png]] Then click on {{{Button(Install)}}}. During the *installation* process that follows, you will see a progress bar and information on which file is currently being installed. You can press {{{Button(Show~details)}}} at any time to show the installation log. #+ATTR_LaTeX: width=0.85\textwidth -file:sc-inst-progress_en.png +[[file:images-compendium/sc-inst-progress_en.png]] Once you have completed the installation, please click on {{{Button(Next)}}}. The last page of the installation process is shown once the installation has been successfully completed: #+ATTR_LaTeX: width=0.85\textwidth -file:sc-inst-finished_en.png +[[file:images-compendium/sc-inst-finished_en.png]] You have the option of displaying the README file, which contains important information on the Gpg4win version you have just installed. If you do not wish to view this file, deactivate this option. Then click on {{{Button(Finish)}}}. In some cases you may have to restart Windows. In this case, you will see the following page: #+ATTR_LaTeX: width=0.85\textwidth -file:sc-inst-finished2_en.png +[[file:images-compendium/sc-inst-finished2_en.png]] Now you can decide whether Windows should be restarted immediately or manually at a later time. Click on {{{Button(Finish)}}}. Please read the README file which contains up-to-date information on the Gpg4win version that has just been installed. You can find this file e.g. via the start menu: {{{Menu(Start\to{}Programs\to{}Gpg4win\to{}Documentation\to{}Gpg4win README)}}} *And that's it!* You have successfully installed Gpg4win and are ready to work with the program. For information on *automatically installing* Gpg4win, as may be of interest for software distribution systems, please see the Annex\ref{ch:auto} "Automatic installation of Gpg4win". ** Creating a certificate :PROPERTIES: :CUSTOM_ID: ch:CreateKeyPair :END: #+index: Certificate!create #+index: Key!create #+index: Key!pair Now that you have found out why GnuPG is so secure (Chapter\ref{ch:FunctionOfGpg4win}), and how a good passphrase provides protection for your private key (Chapter\ref{ch:passphrase}), you are now ready to create your own key pair. As we saw in Chapter\ref{ch:FunctionOfGpg4win}, a key pair consists of a public and a private key. With the addition of an email address, login name etc., which you enter when creating the pair (so-called meta data), you can obtain your private certificate with the public /and / private key. #+index: X.509 This definition applies to both OpenPGP as well as S/MIME (S/MIME certificates correspond with a standard described as "X.509"). *It would be nice if I could practice this important step of creating a key pair ....* {{{MarginPGP}}}Not to worry, you can do just that --- but only with OpenPGP: #+index: Authentication If you decide for the OpenPGP method of authentication, the "Web of Trust", then you can practice the entire process for creating a key pair, encryption and decryption as often as you like, until you feel very comfortable. This "dry run" will strengtthen your trust in Gpg4win, and the "hot phase" of OpenPGP key pair creation will no longer be a problem for you. #+index: GnuPP Your partner in this exercise is *Adele* . Adele is a test service which is still derived from the GnuPP predecessor project and is still in operation. In this compendium we continue to recommend the use of this practice robot. We would also like to thank the owners of gnupp.de for operating this practice robot. Using Adele, you can practice and test the OpenPGP key pair which you will be creating shortly, before you start using it in earnest. But more on that later. *Let's go!* Open Kleopatra using the Windows start menu: #+ATTR_LaTeX: width=0.7\textwidth [[file:images-compendium/sc-kleopatra-startmenu_en.png]] #+index: Kleopatra #+index: Certificate administration You will see the main Kleopatra screen --- the certificate administration: #+ATTR_LaTeX: width=0.85\textwidth -file:sc-kleopatra-mainwindow-empty_en.png +[[file:images-compendium/sc-kleopatra-mainwindow-empty_en.png]] At the beginning, this overview will be empty, since you have not created or imported any certificates yet. Click on {{{Menu(File\to{}New~Certificate)}}}. In the following dialog you select the format for the certificate. You can choose from the following: *OpenPGP* (PGP/MIME) or *X.509* (S/MIME). The differences and common features of the two formats have already been discussed in Chapter\ref{ch:openpgpsmime}. # <> #+ATTR_LaTeX: width=0.85\textwidth -file:sc-kleopatra-ChooseCertificateFormat_en.png] +[[file:images-compendium/sc-kleopatra-ChooseCertificateFormat_en.png]]] This chapter of the compendium breaks off into two sections for each method at this point. Information is then combined at the end of the Chapter. Depending on whether you chose OpenPGP or X.509 (S/MIME), you can now read either: - Section [[#createKeyPairOpenpgp]]: *Creating an OpenPGP certificate* (see next page) or - Section [[#createKeyPairX509]]: *Creating an X.509 certificate* @@latex:{(see page \pageref{createKeyPairX509})}@@. *** Creating an OpenPGP certificate :PROPERTIES: :CUSTOM_ID: createKeyPairOpenpgp :END: #+index: OpenPGP!create certificate {{{MarginPGP}}}In the certificate option dialog, click on {{{Button(Create personal OpenPGP key pair)}}}. Now enter your email address and your name in the following window. Name and email address will be made publicly visible later. You also have the option of adding a comment for the key pair. Usually this field stays empty, but if you are creating a key for test purposes, you should enter "test" so you do not forget it is a test key. This comment becomes part of your login name, and will become public just like your name and email address. #+ATTR_LaTeX: width=0.85\textwidth -file:sc-kleopatra-openpgp-personalDetails_en.png +[[file:images-compendium/sc-kleopatra-openpgp-personalDetails_en.png]] If you first wish to *test* your OpenPGP key pair, you can simply enter any name and fictional email address, e.g.: =Heinrich Heine= and =heinrich@gpg4win.de= The *Advanced settings are only be required in exceptional* cases. For details, see the Kleopatra handbook (via {{{Menu(Help\to{}Kleopatra handbook)}}}). Click on {{{Button(Next)}}}. You will see a list of all of the main entries and settings for *review purposes*. If you are interested in the (default) expert settings, you can view these via the {{{Menu(All details)}}} option. #+ATTR_LaTeX: width=0.85\textwidth -file:sc-kleopatra-openpgp-reviewParameters_en.png +[[file:images-compendium/sc-kleopatra-openpgp-reviewParameters_en.png]] If everything is correct, click on {{{Button(Create key)}}}. Now to the most important part: entering your *passphrase*! To create a key pair, you must enter your personal passphrase: #+ATTR_LaTeX: width=0.45\textwidth -file:sc-kleopatra-openpgp-pinentry_en.png +[[file:images-compendium/sc-kleopatra-openpgp-pinentry_en.png]] If you have read Chapter\ref{ch:passphrase} you should now have an easy-to-remember but hard to break secret passphrase. Enter it in the dialog displayed at the top. Please note that this window may have been opened in the background and is not visible at first. If the passphrase is not secure enough because it is too short or does not contain any numbers or special characters, the system will tell you. At this point you can also enter a *test passphrase* or start in earnest; it's up to you. To make sure that you did not make any typing errors, the system will prompt you to enter your passphrase twice. Always confirm your entry with {{{Button(OK)}}}. Now your OpenPGP key pair is being created: #+ATTR_LaTeX: width=0.85\textwidth -file:sc-kleopatra-openpgp-createKey_en.png +[[file:images-compendium/sc-kleopatra-openpgp-createKey_en.png]] This may take a couple of minutes. You can assist the creation of the required random numbers by entering information in the lower input field. It does not matter what you type, as the characters will not be used, only the time period between each key stroke. You can also continue working with another application on your computer, which will also slightly increase the quality of the new key pair. As soon as *the key pair creation has been successful*, you will see the following dialog: #+ATTR_LaTeX: width=0.85\textwidth -file:sc-kleopatra-openpgp-keyPairCreated_en.png +[[file:images-compendium/sc-kleopatra-openpgp-keyPairCreated_en.png]] #+index: Fingerprint #+index: Key!ID The 40-digit "fingerprint" of your newly generated OpenPGP certificate is displayed in the results text field. This fingerprint is unique anywhere in the world, i.e. no other person will have a certificate with the same fingerprint. Actually, even at 8 digits it would already be quite unlikely that the same sequence would occur twice anywhere in world. For this reason, it is often only the last 8 digits of a fingerprint which are used or shown, and which are described as the key ID. This fingerprint identifies the identity of the certificate as well as the fingerprint of a person. However, you do not need to remember or write down the fingerprint. You can also display it later in Kleopatra's certificate details. Next, you can activate one or more of the following three buttons: - Creating a backup copy of your (private) certificate... :: Enter the path under which your full certificate (which contains your new key pair, hence the private /and / public key) should be exported: #+ATTR_LaTeX: width=0.5\textwidth [[file:images-compendium/sc-kleopatra-openpgp-exportSecretKey_de.png]] Kleopatra will automatically select the file type and store your certificate as an =.asc= or =.gpg= file --- depending on whether you activate or deactivate the *ASCII armor* option. For export, click on {{{Button(OK)}}}. *Important:* If you save the file on the hard drive, you should copy the file to another data carrier (USB stick, diskette or CD-ROM) as soon as possible, and delete the original file without a trace, i.e. do not leave it in the Recycle bin! Keep this data carrier and back-up copy in a safe place. You can also create a back-up copy later; to do this, select the following from the Kleopatra main menu: {{{Menu(File\to{}Export private certificate...)}}} (see Chapter \ref{ch:ImExport}). - Sending a certificate via email ... :: Clicking on this button should create a new oneemail --- with your new public certificate in the attachment. Your secret Open PGP key will of course /not/ be sent. Enter a recipient email address; you can also add more text to the prepared text for this email. *Please note:* Not all email programs support this function. Of course you can also do this manually: If you do not see a newemail window, shut down the certificate creation assistant, save your public certificate via {{{Menu(File\to{}Export certificate)}}} and sent this file via email to the people you are corresponding with. For more details see Section\ref{sec_publishPerEmail}. - Sending certificates to certificate servers... :: Chapter \ref{fixme} explains how to set up a globally available OpenPGP certificate server in Kleopatra, and how you can publish your public certificate on this server \ref{ch:keyserver}. This completes the creation of your OpenPGP certificate. End the Kleopatra assistant with {{{Button(Finish)}}}. Now let's go to Section [[#sec_finishKeyPairGeneration]] @@latex:{on page \pageref{sec_finishKeyPairGeneration}}@@. Starting at that point, the explanations for OpenPGP and X.509 will again be identical. *** Creating an X.509 certificate :PROPERTIES: :CUSTOM_ID: createKeyPairX509 :END: #+index: X.509!create certificate {{{MarginCMS}}}In the certificate format selection dialog on page \pageref{chooseCertificateFormat} click on the button {{{Button(Create personal X.509 key pair and authentication request)}}}. In the following window, enter your name (CN = common name), your email address (EMAIL), organisation (O) and your country code (C). Optionally, you can also add your location (L = Locality) and department (OU = Organizational Unit). If you first wish to *test* the X.509 key pair creation process, you can enter any information for name, organization and country code, and can also enter a fictional email address, e.g.: : CN=Heinrich Heine,O=Test,C=DE,EMAIL=heinrich@gpg4win.de #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-kleopatra-x509-personalDetails_en.png]] The *Advanced settings will only be required in exceptional* cases. For details, see the Kleopatra handbook (via {{{Menu(Help\to{}Kleopatra handbook)}}}). Click on {{{Button(Next)}}}. You will see a list of all main entries and settings for *review purposes*. If you are interested in the (default) expert settings, you can view these via the {{{Menu(All details)}}} option. #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-kleopatra-x509-reviewParameters_en.png]] Once everything is correct, click on {{{Button(Create key)}}}. Now to the most important part: Entering your *passphrase*! In order to create a key pair, you will be asked to enter your passphrase: #+ATTR_LaTeX: width=0.45\textwidth [[file:images-compendium/sc-kleopatra-x509-pinentry_en.png]] If you have read Chapter \ref{ch:passphrase} you should now have an easy-to-remember but hard to break secret passphrase. Enter it in the dialog displayed at the top! Please note that this window may have been opened in the background, so it may not be visible at first. If the passphrase is not secure enough because it is too short or does not contain any numbers or special characters, the system will let you know. At this point you can also enter a *test passphrase* or start in earnest; it's up to you. #+index: Certificate!request To make sure that you did not make any typing errors, the system will prompt you to enter your passphrase twice. Finally, you will be asked to enter your passphrase a third time: By doing that, you are sending your certificate request to the authenticating instance in charge. Always confirm your entries with {{{Button(OK)}}}. Now your X.509 key pair is being created: #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-kleopatra-x509-createKey_en.png]] This may take a couple of minutes. You can assist the creation of the required random numbers by entering information in the lower input field. It does not matter what you type, as the characters will not be used, only the time period between each key stroke. You can also continue working with other applications on your computer, which will slightly increase the quality of the key pair that is being created. As soon as *the key pair has been successfully* created, you will see the following dialog: #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-kleopatra-x509-keyPairCreated_en.png]] The next steps are triggered with the following buttons: #+index: Certificate Authority (CA) - Save request in file... :: Here, you enter the path under which your X.509 certificate request should be backed up, and confirm your entry. Kleopatra will automatically add the file ending =.p10=} during the saving process. This file can then be sent to an authentication instance (in short CA for Certificate Authority). Further below, we will refer you to cacert.org, which is a non-commercial authentication instance (CA) that issues X.509 certificates free of charge. - Sending an request by email ... :: This creates a new email with the certificate request which has just been created in the attachment. Enter a recippient email address --- usually that of your certificate authority in charge; you can also add more text to the prepared text of this email. *Please note:* Not all email programs support this function. Of course you can also do this manually: If you do not see a new emailwindow, save your request in a file (see above) and send it by email to your certificate authority (CA). As soon as the CA has processed your request, the CA system administrator will send you the completed X.509 certificate, which has been signed by the CA. You only need to import the file into Kleopatra (see Chapter\ref{ch:ImExport}). End the Kleopatra assistant with {{{Button(Finish)}}}. **** Creating an X509 certificate using www.cacert.org #+index: CAcert {{{MarginCMS}}}CAcert is a non-commercial certificate authority which issues X.509 certificates free of charge. It offers an alternative to commercial root CAs, some of which charge very high fees for their certificates. To create a (client) certificate at CAcert, you first have to register at [[http://www.cacert.org]]. Immediately following registration, you can create one or more client certificates on cacert.org: please make sure you have sufficient key length (e.g. 2048 bits). Use the web assistant to define a secure passphrase for your certificate. Your client certificate is now created. Afterwards you will receive an email with two links to your new X.509 certificate and associated CAcert root certificate. Download both certificates. Follow the instructions to install the certificate on your browser. In Firefox, you can use e.g. {{{Menu(Edit\to{}Settings\to{}Advanced\to{}Certificates)}}} to find your installed certificate under the first tab ``Your certificates" with the name (CN) *CAcert WoT User*. You can now issue a personal X.509 certificate which has your name in the CN field. To do this, you must have your CAcert account authenticated by other members of the CACert Web of Trust. Information on obtaining such a confirmation can be found on the Internet pages of CAcert. Then save a backup copy of your personal X.509 certificate. The ending =.p12= will automatically be applied to the backup copy. *Attention:* This =.p12= file contains your public /and / your private key. Please ensure that this file is protected againt unauthorised access. To find out how to import your personal X.509 certificate in Kleopatra, see Chapter\ref{ch:ImExport}. Let's now look at Section \ref{sec_finishKeyPairGeneration} on the next page. This is where explanations for OpenPGP and X.509 are identical again. *** Certificate creation process complete :PROPERTIES: :CUSTOM_ID: sec_finishKeyPairGeneration :END: *This completes the creation of your OpenPGP or X.509 key pair. You now have a unique electronic key.* During the course of this compendium, we will always use an OpenPGP certificate for sample purposes --- however, all information will also apply accordingly to X509 certificates. You are now back in the Kleopatra main window. The OpenPGP certificate which was just created can be found in the certificate administration under the tab Menu{My certificates}: #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-kleopatra-withOpenpgpTestkey_en.png]] Double-click on your new certificate to view all details related to the certificate: #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-kleopatra-openpgp-certificateDetails_en.png]] What do the certificate details mean? Your certificate is valid indefinitely, i.e. it has no "built-in expiry date". To change its validity at a later point, click on {{{Button(Change expiry date)}}}. *For more details about the certificate, see Chapter\ref{ch:CertificateDetails}.* ** Distribution of public certificates :PROPERTIES: :CUSTOM_ID: ch:publishCertificate :END: #+index: Certificate!public When using Gpg4win on a daily basis, it is very practical that for the purpose of encrypting and checking signatures you are always dealing with "public" certificates which only contain public keys. As long as your own secret key and the passphrase which protects it are secure, you have already gone a long way towards ensuring secrecy. Everyone can and should have your public certificate, and you can and should have the public certificates of your correspondence partners --- the more, the better. Because: *To exchange secure emails, both partners must have and use the public certificate of the other person. Of course the recipient will also require a program capable of handling certificates --- such as the Gpg4win software package with Kleopatra certification administration.* Therefore, if you want to send encrypted emails to someone, you must have their public certificate to encrypt the email. In turn, if someone wants to send you encrypted emails, he must have your public certificate and use it for encryption purposes. For this reason you should now allow access to your public certificate. Depending on how many people you corespond with, and which certificate format you are using, you have several options. For example, you can distribute your public certificate ... - ... directly via *email* to specific correspondence partners --- see Section \ref{sec_publishPerEmail}. - ... on an *OpenPGP certificate server* (applies /only / to OpenPGP) --- See Section\ref{sec_publishPerKeyserver}. - ... via your own homepage. - ... in person, e.g. with a USB stick. Let's look at the first two variants on the following pages. *** Publishing per email, with practice for OpenPGP :PROPERTIES: :CUSTOM_ID: sec_publishPerEmail :END: Do you wish to make your public certificate accessible to the person you are corresponding with? Simply send them your exported public certificate per email. This section will show you how this works. {{{MarginPGP}}}Practice this process with your public OpenPGP certificate! Adele can assist you. The following exercises only apply to OpenPGP; for information on publishing public X.509 certificates, please see page \pageref{publishPerEmailx509}. *Adele* is a very nice email robot which you can use to practice correspondence. Because it is usually more pleasant to correspond with a smart human being rather than a piece of software (which is what Adele is, after all), you can imagine Adele this way: #+ATTR_LaTeX: width=0.5\textwidth [[file:images-compendium/adele01.png]] First, send Adele your public OpenPGP certificate. Using the public key in this certificate, Adele will send an encrypted email back to you. You then use your own secret key to decrypt Adele's response. To be able to respond to Adele with an encrypted email, Adele has attached her own public certificate. Adele acts just like a real person you are corresponding with. Of course, Adele's emails are not nearly as interesting as those from the people you are actually corresponding with. On the other hand, you can use Adele to practice as much as you like --- which a real person might find bothersome after a while. So, now you export your public OpenPGP certificate and send it via email to Adele. The following pages how how this works. **** Exporting your public OpenPGP certificate #+index: Certificate!export Select the public certificate to be exported in Kleopatra (by clicking on the corresponding line in the list of certificates) and then click on {{{Menu(File\to{}Export certificates...)}}} in the menu. Select a suitable file folder on your PC and save the public certificate with the file type =.asc= e.g.: =mein-OpenPGP-Zertifikat.asc=. The other file types, which can be selected, =.gpg= or =.pgp=, will save your certificate in binary format. That means that in contrast to an =.asc= file, they cannot be read in the text editor. When you select the menu item, please make sure that you are only exporting your public certificate --- and /not / the certificate of your entire key pair with the associated private key by mistake. Review the file once more by selecting Windows Explorer and selecting the same folder that you indicated for the export. Now *open* the exported certificate file with a text editor, e.g. WordPad. The text editor will display your public OpenPGP certificate as it really looks --- a fairly confusing block of text and numbers: #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-wordpad-editOpenpgpKey_en.png]] When publishing your OpenPGP certificate by email, there are two variants which can take into account whether an email program can send attachments. **** Variant 1: Send public OpenPGP certificate as an email text This option always works, even if you are not able to attach files --- as may be the case with some email services on the Web. Also, it is a way of seeing your public certificate for the first time, knowing exactly what is behind it, and what the certificate actually consists of. *Highlight* the entire public certificate in the text editor from : -----BEGIN PGP PUBLIC KEY BLOCK----- up to : -----END PGP PUBLIC KEY BLOCK----- and *copy* it with the menu command or the key shortcut =Ctrl+C=. Now you have copied the certificate in the memory of your computer (Clipboard in a Windows context). Now you can start your email program --- it does not matter which one you use --- and add your public certificate into an empty email. In Windows, the key command for adding ("Paste") is =Ctrl+V=. You may know this process --- copying and pasting --- as "Copy & Paste". The email program should be set up in such a way that it is possible to send only text messages and not HTML formated messages (see Section\ref{sec_brokenSignature} and Annex \ref{appendix:gpgol}). *Now address this* email to =adele@gnupp.de and write something in the subject line e.g. {{{Menu(My public OpenPGP certificate)}}}. This is approximately what your email will look like: #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-ol-adele-sendOpenpgpKey-inline_en.png]] Now send the email to Adele. Make sure to include your /own/ email address as the sender. Otherwise you will never receive Adele's response ... **** Variant 2: Send public OpenPGP certificate as an email attachment As an alternate to Variant 1, you can also send your exported public OpenPGP certificate directly as an *email file attachment*. This is often the simpler and more commonly used method. Above, you learnt about the "Copy & Paste" method, because it is more transparent and easier to understand. Now write another email to Adele --- this time with the certificate file in the attachment: Add the previously exported certificate file as an attachment to your new email --- just as you would for any other file (e.g. pulling the -file into the emtpy \Emailwindow). Add the recipient (adele@gnupp.de) +file into the emtpy Emailwindow). Add the recipient (adele@gnupp.de) and a subject, e.g.: {{{Menu(My public OpenPGP certificate --- as a file attachment)}}}. Of course you can also add a few explanatory sentences. However, Adele does not need this explanations, because her only purpose is to help you practice this process. Your finished email should look something like this: #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-ol-adele-sendOpenpgpKey-attachment_en.png]] Now send the email and attachment to Adele. **** In short: You have exported your public OpenPGP certificate in Kleopatra into a file. Subsequently, you have also copied the content of the file directly into an email and attached the complete file as an emailattachment. Both emails have been sent to someone else --- in this case, to Adele. The same process applies if you are sending your public certificate to a real email address. Usually, you should send public certificates as a file attachment, as described in Variant 2. This is the easiest way to do it, both for you and the recipient. And it also has the advantage that your recipient can import your certificate file directly into his own certificate administration (e.g. Kleopatra). *** Publish via OpenPGP certificate server :PROPERTIES: :CUSTOM_ID: sec_publishPerKeyserver :END: {{{MarginPGP}}}*Please note: You can only distribute your OpenPGP certificate via an OpenPGP certificate server.* Publishing your public OpenPGP certificate on a public certificate server is always a good idea, even if you are only exchanging encrypted emails with just a few people. This way, your public certificate is accessible to everyone on an Internet server. This saves you time in having to send your certificate email to all of the people you are corresponding with. At the same time, publishing your email address on a certificate server can also make your email address more susceptible to spam. This can only be addressed with good spam protection. *This is how it works:* Select your public OpenPGP certificate in Kleopatra and click on {{{Menu(File\to{}Export certificate to server...)}}}. If you have not defined a certificate server, you will see a warning: #+ATTR_LaTeX: width=0.6\textwidth [[file:images-compendium/sc-kleopatra-exportCertificateToServer_en.png]] The public OpenPGP certificate server already contains keys.gnupg.net} default settings. Click on {{{Button(Continue)}}} to send your selected public certificate to this server. There, your public certificate is distributed to all globally connected certificate servers. Anyone can download your public certificate from one of these OpenPGP certificate servers and use it send you a secure email. If you are only testing this process, please do /not/ send the practice certificate: In the top dialog, click on {{{Button(Cancel)}}}. The test certificate is worthless and cannot be removed by the certificate server. You would not believe how many test certificates with names like "Julius Caesar", "Helmut Kohl" or "Bill Clinton" are already floating around on these servers ... **** In short: Now you know how to publish your public OpenPGP certificate on an OpenPGP certificate server on the Internet. *For information on how to search for the public OpenPGP certificate of people you are corresponding with on a certificate server, see Chapter\ref{ch:keyserver}. You can read this chapter now or later when you need this function.* *** Publishing X.509 certificates :PROPERTIES: :CUSTOM_ID: publishPerEmailx509 :END: {{{MarginCMS}}}In the case of public X.509 certificates, this process is even easier: all you need to do is to send a signed S/MIME email to the person you are corresponding with. Your public X.509 certificate is contained in this signature, and can be imported into the recipient's certificate administration. Unfortunately, you cannot use Adele to practice X.509 certificates since the robot only supports OpenPGP. Therefore you should pick another person to write you, or alternately write to yourself. Some public X.509 certificates are distributed by the certificate authority. This is usually done using X.509 certificate servers, which however do not synchronize on a global basis, as is the case with OpenPGP key servers. #+index: Certificate!chain #+index: Certificate!CA When you export your public X.509 certificate, you can highlight the entire public certificate chain and save it in a file --- generally the root certificate, CA certificate and personal certificate --- or only your public certificate. The first is recommended since the person you are corresponding with may be missing some parts of the chain, which he otherwise would have to find. To do this, click on all elements of the certificate chain in Kleopatra while holding the Shift key, and export the highlighted certificate into a file. If the person you are corresponding with does not have the root certificate, he must indicate that he trusts it, or have an administrator do so, in order to finally also trust you. If this has already been done (e.g. because they are both part of the same "root"), then this shiop is already in place. ** Decrypting emails, practicing for OpenPGP :PROPERTIES: :CUSTOM_ID: ch:decrypt :END: #+index: E-mail!decrypt Gpg4win, the certificate of your key pair and of course your passphrase are all you need to decrypt emails. This Chapter shows you step for step how to decrypt emails in Microsoft Outlook using the Gpg4win program component GpgOL. #+index: Outlook {{{MarginPGP}}}Initially, you can practice this process with Adele and your public OpenPGP certificate. The following exercises again only apply to OpenPGP --- explanations regarding the decryption of S/MIME emails can be found at the end of this chapter on page \pageref{encrypt-smime}. In Section\ref{sec_publishPerEmail} you sent your public OpenPGP certificate to Adele. Using this certificate, Adele will now encrypt an email and send a message back to you. You should receive Adele's response after a short time period. # cartoon: Adele typing and sending a mail #+ATTR_LaTeX: width=0.5\textwidth [[file:images-compendium/adele02.png]] **** Decrypting a message with MS Outlook and GpgOL Most email programs also have special program extensions ("plugins"), which can be used to perform the encryption and decryption process directly in the email program. *GpgOL* is such a program extension for MS Outlook, which is used here to decrypt Adele'semails. For more information on other software solutions, please see Annex\ref{ch:plugins}. You can read this section now, or later when you need this function. Start MS Outlook and open Adele's response email. Until now, you have only known Kleopatra as a certificate administration program. However, the program can do much more than that: It can control the actual GnuPG encryption software and hence not just manage your certificates but also take care of all cryptographic tasks (with GnuPG's assistance). Kleopatra provides the visual user interface, hence the dialogs which you as the user see while you encrypt or decrypt emails. Hence Kleopatra processes Adele's encrypted emails. These emails have been encrypted by Adele using /your/ public OpenPGP key. To decrypt the message, Kleopatra will now ask for your passphrase that protects your private key. Enter your passphrase. The decryption is successful if you do not see an error dialog! You can now read the decrypted email. You can retrieve the exact results dialog of the decryption by clicking on {{{Menu(Extras\to{}GpgOL decryption/check)}}} in the menu of the opened email. However, surely you also want to see the result, namely the decrypted message ... **** The decrypted message Adele's decrypted response will look something like this [4]: #+BEGIN_EXAMPLE Hello Heinrich Heine, here is an encrypted response to your e-mail. I received your public key with the key ID FE7EEC85C93D94BA and the name `Heinrich Heine '. Attached is the public key of adele@gnupp.de, the friendly e-mail robot. Regards, adele@gnupp.de #+END_EXAMPLE The text block that follows is Adele's public certificate. In the next chapter, you will import this certificate and add it to your certificate administration. You can use imported public certificates at any time to encrypt messages to the people you are corresponding with, or to check their signed emails. **** In short: 1. You have decrypted and encrypted an email using your private key. 2. Your correspondence partner has attached his own public certificate, so that you can answer him in encrypted form. **** email decryption using S/MIME :PROPERTIES: :CUSTOM_ID: encrypt-smime :END: {{{MarginCMS}}}So this is how emails are decrypted using the private OpenPGP key --- but how does it work with S/MIME? The answer: The same! To decrypt an encrypted S/MIME email, simply open the message in Outlook and enter your passphrase in the pin entry dialog. You will see a status dialog that is similar to that shown for OpenPGP. After closing this dialog, you will see the decrypted S/MIME email. Differently from OpenPGP decryption, however, when using S/MIME you cannot use Adele to practice, since Adele only supports OpenPGP. ** Importing a public certificate :PROPERTIES: :CUSTOM_ID: ch:importCertificate :END: #+index: Certificate!import The person you are corresponding with does not always have to send their public certificate when they send signed emails to you. You can simply store their public certificate in your certificate administrator --- e.g. Kleopatra. **** Storing a public certificate Before you import a public certificate into Kleopatra, you must save it in a file. Depending on whether you received the certificate as an emailfile attachment or as a block of text contained in your email, please proceed as follows: - If the public certificate was included as an email *file attachment*, save it on your hard drive --- just as you would normally do. - If the public certificate was mailed as a block of text that *was included in the* email, you have to highlighte the entire certificate: In the case of (public) OpenPGP certificates, please highlight the area from : -----BEGIN PGP PUBLIC KEY BLOCK----- up to : -----END PGP PUBLIC KEY BLOCK----- just as we have seen in Section\ref{sec_publishPerEmail}. Now use Copy & Paste to insert the highlighted section into a text editor and save the public certificate. For file endings, you should use =.asc= or =.gpg= for OpenPGP certificates and =.pem= or =.der= for X.509 certificates. **** Importing public certificates into Kleopatra Whether you have saved the public certificate as an email attachment or text block --- in both cases, you will be importing it into your Kleopatra certificate administration. To do this, start Kleopatra if the program is not running already. In the menu, click on {{{Menu(File\to{}Import certificate...)}}}, search for the public certificate you have just saved and import it. You will receive an information dialog showing the result of the import process: #+ATTR_LaTeX: width=0.5\textwidth [[file:images-compendium/sc-kleopatra-import-certificate_en.png]] It displays the imported public certificate in Kleopatra, in a separate tab {{{Menu(Imported certificates)}}} with the title {{{Menu()}}}'': #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-kleopatra-withAdeleKey_en.png]] This tab is used for checking purposes, since a file can contain more than one certificate. You can close the tab using the {{{Menu(Fenster\to{}Close tab)}}} command or via the "Close tab" button on the right side of the window). Now change over to the tab "Other certificates". You should also be able to see the public certificate you have imported. Now you have imported someone else's certificate --- in this case Adele's public OpenPGP certificate --- into your certificate administration. You can use this certificate at any time to send encrypted messages to the owner of the certificate, and to check his signatures. As soon as you are exchanging encrypted email more frequently and with a larger number of persons, you will likely want to search and import for certificates on globally available key servers. To see how this works, please see Chapter\ref{ch:keyserver} . **** Before continuing, an important question: How do you know that the public OpenPGP certificate really came from Adele? It is possible to send emails under someone else's name --- in this respect, merely having the sender's name does not mean anything. So how can you ensure that a public certificate actually belongs to the sender? *This key question related to certificate inspections is explained in the next Chapter\ref{ch:trust}*. ** Certificate inspection :PROPERTIES: :CUSTOM_ID: ch:trust :END: How do you know if a certificate actually belongs to the sender? And vice versa --- why should the person you are writing to believe that the certificate you sent to him is really yours? The sender's name on an email means nothing, just like putting a sender's name on an envelope. If your bank, receives an email with your name, with a request to transfer your entire bank balance to a numbered account in the Bahamas, we should hope that it will refuse to do so --- no matter what the email address is. On its own, an email address itself does not really say anything about the sender's identity. **** Fingerprints #+index: Fingerprint If you are only corresponding with a very small circle of people, it is easy to check their identity: You check the fingerprint of the other certificate. Each certificate features a unique identification, which is even better than someone's fingerprint. For this reason this identification is also referred to as a "fingerprint". If you display the details of a certificate in Kleopatra, e.g. by double-clicking on the certificate, you will see its 40-character fingerprint, among other things: #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-kleopatra-openpgp-certificateDetails_de.png]] The fingerprint of the above OpenPGP certificate is therefore as follows: =7EDC0D141A82250847448E91FE7EEC85C93D94BA= In short --- the fingerprint clearly identifies the certificate and its owner. Simply call the person you are corresponding with and let them read the fingerprint of their certificate to you. If the information matches the certificate you have on hand, you clearly have the right certificate. Of course you can also meet the owner of the certificate in person, or use another method to ensure that certificate and owner can be matched. Frequently, the fingerprint is also printed on business cards; therefore, if you have a business card whose authenticity is guaranteed, you can save yourself a phone call. **** Authenticating an OpenPGP certificate #+index: Certificate!authenticate {{{MarginPGP}}}Once you have obtained confirmation of the authenticity of the certificate "via a fingerprint", you can authenticate it --- but only in OpenPGP. With X.509, users cannot authenticate certificates --- this can only be done by the certificate authorities (CA). By authenticating a certificate, you are letting other (Gpg4win) users know that you are of the opinion that this certificate is real --- hence authentic: You are acting as a kind of "godfather" for this certificate, and help to increase the general level of trust in its authenticity. *So how does the authentication process work?* In Kleopatra, select an OpenPGP certificate that you think is real and would like to authenticate. In the menu, select: {{{Menu(Certificates\to{}Authenticate certificates...)}}} Reconfirm the OpenPGP certificate to be authenticated in the following dialog, using {{{Button(Next)}}}: #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-kleopatra-certifyCertificate1_en.png]] In the next step, select your own OpenPGP certificate, which you will use to authenticate the certificate selected in the last step: #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-kleopatra-certifyCertificate2_en.png]] Here you decide whether to {{{Button(Authenticate for private use only)}}} or or {{{Button(Authenticate and make visible to all)}}}. With the last variant, you have the option of subsequently uploading the authenticated certificate to an OpenPGP certificate server, and hence make an updated and authenticated certificate available to the entire world. Now confirm your selection with {{{Button(Authenticate)}}}. Similar to the process of signing an email, you also have to enter your passphrase when authenticating a certificate (with your private key). The authentication proccess is only complete once this information is entered correctly. Following a successful authentication, the following window appears: #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-kleopatra-certifyCertificate3_en.png]] Do you want to check the authentication one more? To do this, open the certificate details of the certificate you have just authenticated.Select the tab {{{Menu(User ID and authentications)}}} and click on the button {{{Button(Obtain authentications)}}}. You will now see all authentications contained in this certificate, sorted by user ID. You should also be able to see your certificate in this list, if you have just authenticated it. **** Web of trust #+index: Web of Trust {{{MarginPGP}}}The process of authenticating certificates creates a "Web of Trust" (WoT), which extends beyond the group of Gpg4win users and their correspondence, and it means that you are not always required to verify an OpenPGP certificate for its authenticity. #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/key-with-sigs.png]] Naturally, trust in a certificate will increase if it has been authenticated by a lot of people. Your own OpenPGP certificate will receive authentications from other GnuPG users over time. This enables more and more people to trust that this certificate is really yours and not someone else's. The continued weaving of this "Web of Trust" creates a flexible authentication structure. There is one theoretical possibility of making this certificate test null and void: Someone plants a wrong certificate on you. In other words, you have a public OpenPGP key that pretends to be from X but in reality was replaced?? by Y. If this falsified certificate is authenticated, it clearly creates a problem for the "Web of Trust". For this reason it is very important to make sure that prior to authenticating a certifidate, you make absolutely sure the certificate really belongs to the person that purports to own it. But what if a bank or government authority wants to check whether the certificates of their customers are real? Surely, they cannot call them all... **** Authentication instances #+index: Authentication instances #+index: Certificate Authority (CA) In this case, we need a "superordinate" instance that all users can trust. After all, you do not personally check the ID of a person not known to you by phoning the municipal office, but rather trust that the office that issued the ID will have already checked and authenticated these details. {{{MarginPGP}}}These types of authentication instances also exist in the case of OpenPGP certificates. In Germany, for example, the magazine c't has long been offering such a service free of charge, as have many universities. Therefore, if you have received an OpenPGP certificate whose authenticity has been confirmed by such an authentication instance, you should be able to rely on it. {{{MarginCMS}}}Such authentication instances or "Trust Centers" are also provided for in other encryption methods --- such as S/MIME. However, in contrast to the "Web of Trust", these feature a hierarchical structure, with a "top authentication instance" that authenticates additional "sub-instances" and entitles them to authenticate user certificates (see Chapter\ref{ch:openpgpsmime}). #+index: Authentication The best way to describe this infrastructure is to use the example of a seal: The sticker on your license plate can only be provided by an institution that is authorised to issue such stickers, and they have received that right from another superordinate body. On a technical level, an authentication is nothing more than an authenticating party signing a certificate. #+index: Signature law Of course, hierarchical authentication infrastructures are much better suited to the requirements of government and official instances than the loose "Web ofTrust" of GnuPG, which is based on mutual trust. At the same time, the key aspect of the authentication is the same for both: Gpg4win also supports a hierarchical authentication (S/MIME) in addition to the "Web of Trust" (OpenPGP). Accordingly, Gpg4win offers a basis that corresponds with the Signature Act of the Federal Republic of Germany. If you would like to learn more about this topic, the following websites provide more information on this and other IT security topics: - http://www.bsi.de (German) - http://www.bsi-fuer-buerger.de (German) - http://www.gpg4win.org (English) Another, rather technical, information source on the issue of authentication infrastructure is the GnuPG handbook, which can also be found at: http://www.gnupg.org/gph/en/manual.html. ** Encrypting emails :PROPERTIES: :CUSTOM_ID: ch:encrypt :END: #+index: E-mail!encrypt Now it is getting exciting again: You are sending an encrypted email. In this case, you will need Outlook (or another email program that supports cryptography), Kleopatra and of course the public certificate of the person you are correspondign with. *Note for OpenPGP:* {{{MarginPGP}}}You can use Adele to practice the encryption process with OpenPGP; on the other hand, Adele does not support S/MIME. You can send the email to be encrypted to =adele@gnupp.de=. It does not matter what your write in your message, since Adele cannot read it. *Note for S/MIMIE:* {{{MarginCMS}}}Following the installation of Gpg4win, the S/MIME functionality is already activated in GpgOL. If you want to turn off S/MIME (with GnuPG), for example to use Outlook's own S/MIME function, you have to deactivate the option {{{Menu(Activate S/MIME support)}}} in the following GpgOL option dialog under {{{Menu(Extras\to{}Options\to{}GpgOL)}}}: #+ATTR_LaTeX: width=0.55\textwidth [[file:images-compendium/sc-gpgol-options_de.png]] **** Send an encrypted message First, compose a new in Outlook and address it to the person you are writing to. To send your message as in an encrypted form, select the item {{{Menu(Extras\to{}Encrypt message)}}} in the menu of the message window. The button with the lock icon in the tool bar is activated --- you can also click right on the lock. Your Outlook message windows should look something like this: # screenshot: OL composer with Adele's address and body text #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-ol-sendEncryptedMail_en.png]] Now click {{{Button(Send)}}}. # <> Gpg4win will automatically detect the protocol --- OpenPGP or S/MIME --- of the public certificate provided by the person you are corresponding with. As long as there is only one certificate that matches the recipient's email address, your message will be encrypted and sent. **** Selecting certificates #+index: Certificate!selection If Kleopatra is not able to clearly determine a recipient certificate using the lemail address, e.g. if you have an OpenPGP /and/ S/MIME certificate from the person you are corresponding with, a selection dialog which allows you to select the right certificate will be displayed. #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-kleopatra-encrypt-selectCertificate_en.png]] If Kleopatra is not able to find the public certificate of the person you are corresponding with, you probably have not imported it into your certificate administration yet (see Chapter\ref{ch:importCertificate}) or perhaps have not authenticated it yet (for OpenPGP; see Chapter\ref{ch:trust}), or have not expressed your trust in the root certificate of the certification chain (for S/MIME, see Chapter\ref{sec_allow-mark-trusted}). You need the correct public certificate of your correspondence partner to encrypt your messages. Remember the principle in Chapter\ref{ch:FunctionOfGpg4win}: #+BEGIN_QUOTE *You have to use someone's public certificate to send them an an encrypted email.* #+END_QUOTE **** Completing the encryption process Once your message was successfully encrypted and sent, you will receive a confirmation message: #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-kleopatra-encryption-successful_de.png]] *Congratulations! You have encrypted your first email!* ** Signing emails :PROPERTIES: :CUSTOM_ID: ch:sign :END: #+index: E-mail!sign In Chapter\ref{ch:trust} you learnt more about verifying the authenticity of a public OpenPGP certificate, and signing it with your own private OpenPGP key. This chapter also explains how to *sign* a complete *email* rather than only the certificate. That means applying a digital signature to the email --- which is a form of an electronic seal. "Sealed" in this way, the text can still be read by everyone, but it allows the recipient to find out whether the email was manipulated or modified during delivery. The signature tells the recipient that the message is really from you. And: If you are corresponding with someone whose public certificate you do not have (for whatever reason), you can at least "seal" the message with your own private key. #+index: Signature!digital You have probably noticed that this digital signature is not identical to an email "signature", which is sometimes included at the end of an email and includes such items as telephone number, address and website. While these email signatures simply function as a type of business card, a digital signature will protect your email from manipulation and clearly confirms the sender. #+index: Signature!qualified electronic #+index: Signature Act Besides, a digital signature cannot be compared with a qualified electronic signature, as it went into effect as part of the Signature Act (May 22, 2001). However, it serves exactly the same purpose for private or professional email communication. #+ATTR_LaTeX: width=0.35\textwidth [[file:images-compendium/man-with-signed-key.png]] *** Signing with GpgOL In fact, signing an email is even easier than encrypting it (see Chapter\ref{ch:encrypt}). Once you have composed a new email, go through the following steps --- similar to the encryption process: - Send message with signature - Select certificate - Completing the signing process These steps are described in detail on the following pages. **** Sending a signed message First, compose a new email in Outlook and address it to the person you are writing to. Before you send your message, tell the system that your message should be sent with a signature: To do this, activate the button with the signature pen or the menu item {{{Menu(Format\to{}Sign message)}}}. Your email window would then look something like this: #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-ol-sendSignedMail_en.png]] Now click on {{{Button(Send)}}}. **** Selecting certificates Just as is the case for encrypting emails, Gpg4win automatically detects the protocol --- OpenPGP or S/MIME --- for which your own certificate (with the private key for signing) is available. If you have your own OpenPGP /and/ S/MIME certificate with the same email address, Kleopatra will ask you to select a protocol before the email is signed: #+ATTR_LaTeX: width=0.45\textwidth [[file:images-compendium/sc-kleopatra-format-choice_de.png]] If you have several certificates (e.g. two OpenPGP certificates for the same email address) for the selected method,Kleopatra will open a window which displays your certificates (here: OpenPGP), each with its own private key: #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-kleopatra-sign-selectCertificate_en.png]] Confirm your selection with {{{Button(OK)}}}. **** Completing the signing process #+index: Pinentry In order to complete the signing process for your email, you will be asked to enter your secret passphrase in the following pin entry window: #+ATTR_LaTeX: width=0.5\textwidth [[file:images-compendium/sc-kleopatra-sign-OpenpgpPinentry_en.png]] This is required because: #+BEGIN_QUOTE *You can only sign with your own private key.* #+END_QUOTE It makes sense, because only your own private key confirms your identity. The person you are corresponding with can then check your identity using your public certificate, which he already has or can obtain. Because only your private key matches your public certificate. Confirm your passphrase entry with {{{Button(OK)}}}. Your message is now signed and sent. Once your message has been signed successfully, the following dialog appears: #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-kleopatra-sign-successful_de.png]] *Congratulations! You have encrypted your first email!* **** In short: You have learnt how to *sign* an email using your own certificate --- which contains your private key. You know how to *encrypt* an email using the public certificate of the person you are writing to. Now you are familiar with the two most important techniques for sending secure emails: encryption and signatures. Of course you can also combine the two techniques. From now on, each time you send an email, think about how you want to send it --- depending on the importance and required level of protection for your email: - non-encrypted - encrypted - signed - signed and encrypted (more on this in Section\ref{sec_encsig}) You can use these four combinations with either OpenPGP or S/MIME. *** Checking signatures with GpgOL #+index: Check!signature with GpgOL Let's assume you have received a signed email from the person you are corresponding with. It is very easy to check this digital signature. All you need is the public OpenPGP or X.509 certificate of your correspondence partner. You should have already imported his public certificate into your certificate administration prior to performing this check (see Chapter\ref{ch:importCertificate}). To check a signed OpenPGP or S/MIME email, proceed as you would for decrypting an email (see Chapter\ref{ch:decrypt}): Start Outlook and open a signed email. GpgOL will automatically transfer the email to Kleopatra for a signature check. Kleopatra will report the result in a status dialog, e.g.: #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-kleopatra-verifySignedMail_en.png]] The signature check was successful! Now close to the dialog in order to read the signed email. If you want to perform the check again manually, select {{{Menu(Extras\to{}Decrypt/Check GpgOL)}}} in the menu of the open email. If the signature check is not successful, it means that the message was changed during the delivery process. Because of the technical nature of the Internet, it is possible that the email was unintentionally modified because of a defective transmission. That is probably the most likely cause. However, it can also mean that the text was changed intentionally. Section\ref{sec_brokenSignature} has information on how to proceed in such a case. *** Reasons for a broken signature :PROPERTIES: :CUSTOM_ID: sec_brokenSignature :END: #+index: Signature!broken There are several reasons for a broken signature: If you receive the message "Bad signature" or "Check failed", it is a warning that your email may have been manipulated! That means that it is possible that someone changed the email's contents or the subject line. At the same time, a broken signature does not necessarily mean that the email was manipulated. It is also possible that the email was modified due to a defective transmission. In any case, you should always take a broken signature seriously and ask the sender to resend the email! It is recommended that you set your program to only send emails in "text" format and *not* in "HTML" format. However, if you decide to use HTML for signed or encrypted emails, it is possible that formatting information will be lost by the time it reaches the recipient, which can result in a broken signature. In Outlook 2003 and 2007, you can set the message format to {{{Menu(Text only)}}} in {{{Menu(Extras\to{}Options\to{}E-Mail Format)}}}. *** Encryption and signature :PROPERTIES: :CUSTOM_ID: sec_encsig :END: #+index: E-mail!encrypt and sign You know: A message is usually encrypted using the public certificate of your correspondence partner, who then decrypts the email using his private key. The reverse possibility --- encryption with a private key --- does not make sense, since the whole world knows the associated public certificate and could then decrypt the message. However, as you have already seen in this chapter, there is still another method to create a file using your private key --- namely the signature. A digital signature confirms the author --- because if someone successfully applies your public certificate to this file (the signature), this file could only have been encoded by your private key. And only you can have access to this key. You can combine both options, namely encrypting and signing the email: 1. You *sign* the message with your own private key. This proves that you are the author. 2. You then *encrypt* the text using the public certificate of the person you are correpsonding with. This means that the message has two security characteristics: 1. Your seal on the message: the signature with your private key. 2. A solid outer envelope: encryption using the public certificate of the person you are corresponding with. Your correspondence partner opens the outer strong envelope with his own private key. This ensures secrecy, because only this key can be used to decode the text. He reads the seal with your public certificate, which proves that you were the author, because if your public certificate matches, the seal (digital signature) can only have been encoded with your private key. It is pretty tricky when you think about it, but also very simple. ** Archiving emails in an encrypted form :PROPERTIES: :CUSTOM_ID: ch:archive :END: #+index: E-mail!archive in encrypted form You should also archive your important --- and hence possibly encrypted --- emails in only one way: encrypted. Of course you can simply save a clear text version of your texts, but that is actually not required. If your message was supposed to be secret, it should not be stored on your computer in clear text. Therefore you should always store your encrypted sent emails in an /encrypted/ form! You can probably already guess the problem: To decrypt your archived (sent) emails, you will need the private key of the recipient --- and you don't or will ever have it ... So what to do? Very easy: *You also encrypt to yourself!* The message is encrypted once for the actual person you are writing to --- e.g. Adele --- and once more for you, using your own public certificate. This way, you can later make the email legible using your own private key. Gpg4win will automatically encrypt each encrypted message to your own certificate. To do this, Gpg4win uses your sender email address. If you have multiple certificates for an email address, you have to select the certificate to encrypt to during the encryption process. **** In short: 1. You have encrypted an email using the public certificate of the person you are corresponding with, and used it to answer him. 2. Kleopatra additionally encrypts your sent encrypted emails using your own public certificate, so that the messages remain legible for you. \vspace{1cm} *And that's it! At the end of the first part of this compendium, you have gained a lot of introductory knowledge about Gpg4win.* *Welcome to the world of free and secure email encryption!* For an even better understanding of how Gpg4win really works in the background, we recommend that you read the second part of the Gpg4win compendium. It contains even more interesting stuff! * For Advanced Users :PROPERTIES: :CUSTOM_ID: part:AdvancedUsers :END: # This part provides background information which illustrates the basic # mechanisms on which Gpg4win is based, and also explains some of its # less commonly used capabilities. Part I and II can be used # independently of each other. However, to achieve an optimum # understanding, you should read both parts in the indicated sequence, # if possible. ** Certificate details :PROPERTIES: :CUSTOM_ID: CertificateDetails :END: #+index: Certificate!details In Chapter [[#sec_finishKeyPairGeneration]], you have already seen the detailed dialog for the certificate you generated. It contains a lot of information about your certificate. The following section provides a more detailed overview of the most important points, with brief information on the differences between OpenPGP and X.509 certificates, including: #+index: Certificate!User ID - user ID - fingerprints #+index: Key!ID - key ID #+index: Certificate!validity - validity - trust in certificate holders *(OpenPGP only)* - authentications *(OpenPGP only)* - The user ID :: consists of the name and email address which you entered during the certificate creation process, e.g. =Heinrich Heine = For OpenPGP certificates, you can use Kleopatra to add additional user IDs to your certificate using the menu {{{Menu(Certificates\to{}Add user ID...)}}} menu item. This makes sense if, for example, you wish to use the same certificate for another email address. Please note: Kleopatra only allows you to add user IDs for OpenPGP certificates, but not X.509. - Fingerprints :: are used to differentiate multiple certificates from each other. You can use fingerprints to look for (public) certificates, which are stored on a globally available OpenPGP certificate server (key server) or an X.509 certificate server. You can read more about certificate servers in the next chapter. - The key ID :: consists of the last eight characters of the fingerprint and fulfils the same function. While less characters make it easier to handle key IDs, they also increase the risk of multiple hits (different certificates with the same ID). #+index: Expiry date - The validity :: of certificates describes the duration of their validity and their expiry date, if applicable. In the case of OpenPGP certificates, the validity is usually set to {{{Menu(Indefinite)}}}. You can change this in Kleopatra by clicking on {{{Button(Change expiry date)}}} in the certificate details --- or select the {{{Menu(Certificates\to{}Change expiry date)}}} and enter a new date. This means that you can declare the certificate valid for a limited time period, e.g. in order to issue it to outside employees. The validity of X.509 certificates is defined by the certificate authority when the certificate is issued, and cannot be changed by the user. - Trust in the certificate holder :: {{{MarginPGP}}} quantifies your own subjective confidence that the owner of the OpenPGP certificate is real (authentic) and that he will also correctly authenticate other OpenPGP certifictes. You set the trust with {{{Button(Change trust in certificate holder)}}} in the certificate details, or via the menu{{{Menu(Certificates\to{}Change trust status)}}} menu item. The trust status is only relevant for OpenPGP certificates. No such method exists for X.509 certificates. - Authentications :: {{{MarginPGP}}}of your OpenPGP certificate include the user IDs of those certificate holders who are convinced of the authenticity of your certificate and have thus authenticated it. Trust in the authenticity of your certificate increases with the number of authentications you receive from other users. Authentications are only relevant to OpenPGP certificates. This type of trust mechanism does not exist for X.509 certificates. You do not necessarily have to know the certificate details to use Gpg4win on a daily basis, but they do become relevant when you want to receive or change new certificates. You already learnt how to inspect and authenticate someone else's certificate and about the "Web of Trust" in Chapter\ref{ch:trust}. ** The certificate server :PROPERTIES: :CUSTOM_ID: ch:keyserver :END: #+index: Certificate server #+index: Key server|see Certificate server Section\ref{sec_publishPerKeyserver} already provided a lot of information on how to use a certificate server to publish your public (OpenPGP or X.509) certificate. This section will take a closer look at certificate servers, and will show you how to use them with Kleopatra. Key servers can be used by all programs that support the standards OpenPGP or X.509. Kleopatra supports both types, hence both OpenPGP as well as X.509 certificate servers. #+index: Certificate server!OpenPGP #+index: Denial of Service - OpenPGP certificate servers :: {{{MarginPGP}}} (also called /key server/) are organized on a decentralised basis and synchronize each other on a global basis. There are no current statistics about their number of how many OpenPGP certificates they contain. This shared network of OpenPGP certificate servers provides better availability and prevents individual system administrators from deleting certificates which would make secure communication impossible ("Denial of Service" attack). #+ATTR_LaTeX: width=0.5\textwidth [[file:images-compendium/keyserver-world.png]] #+index: Certificate server!X.509 #+index: LDAP - X.509 certificate servers :: {{{MarginCMS}}} are generally made available by the certificate authorities via LDAP and are sometimes also described as directory services for X.509 certificates. *** Key server configuration :PROPERTIES: :CUSTOM_ID: configureCertificateServer :END: #+index: Certificate server!set up Open the configuration dialog in Kleopatra: {{{Menu(Settings\to{}Configure~Kleopatra...)}}} Now set up a new certificate server under the group {{{Menu(Directory~Services)}}} by clicking on the {{{Menu(New)}}} button. Select between {{{Menu(OpenPGP)}}} or {{{Menu(X.509)}}}. In {{{Menu(OpenPGP)}}}, a default OpenPGP certificate server with the server address =hkp://keys.gnupg.net= (Port: 11371, Protokoll: hkp) will be added to the list. You can use this server without making any changes --- or you can use one of the suggested OpenPGP server addresses on the next page. For {{{Menu(X.509)}}} you will see the following default settings for an X.509 certificate server: (Protokoll: ldap, Servername: server, Server-Port: 389). Complete the information on the server name and basic DN of your X.509 certificate server and check the server port. If your certificate server requires a user name and password, activate the option {{{Menu(Requires user authentication)}}} and enter the required information. The screenshot below shows a configured OpenPGP certificate server: #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-kleopatra-configureKeyserver_en.png]] Confirm the configuration by pressing {{{Button(OK)}}}. You have successfully configured your certificate server. To ensure that you have correctly configured the certificate server, it is helpful to start e.g. a certificate search on the server (for instructions, see Section\ref{searchAndImportCertificateFromServer}). #+index: Proxy *Proxy setting:* If you use a proxy in your network, you should add the parameter =http-proxy== to the certificate server address in the {{{Menu(Server name)}}} column. The full server name could therefore look as follows: =keys.gnupg.net http-proxy=proxy.hq= You can also review and if necessary correct the certificate server configurations in the file: =\%APPDATA\%\gnupg\gpg.conf= Explanations regarding the system-wide configuration of X.509 key servers can be found in Section\ref{x509CertificateServers}. **** OpenPGP certificate server addresses {{{MarginPGP}}}We recommend that you only use up-to-date OpenPGP certificate servers, since only they can handle the newer OpenPGP characteristics. Here is a selection of well-functioning certificate servers: - hkp://pks.gpg.cz - hkp://pgp.cns.ualberta.ca - hkp://minsky.surfnet.nl - hkp://keyserver.ubuntu.com - hkp://keyserver.pramberger.at - http://keyserver.pramberger.at - http://gpg-keyserver.de If you have problems with your firewall, it is best to try certificate servers whose URL begins with: =http://= The certificate servers under the addresses - =hkp://keys.gnupg.net= (Kleopatra pre-selection, see screenshot on previous page) - =http://http-keys.gnupg.net= are a collection point for an entire network of these servers; a concrete server will be selected randomly. *Attention:* Do not use =ldap://keyserver.pgp.com= as a certificate server, since it does synchronize with other servers (Status: May 2010). *** Search and import certificates from certificate servers :PROPERTIES: :CUSTOM_ID: searchAndImportCertificateFromServer :END: #+index: Certificate server!search for certificates #+index: Certificate!import Once you have configured at least one certificate server, you can now look for and import certificates. To do this, in Kleopatra click on {{{Menu(File\to{}Search for certificates on server...)}}}. You will see a search dialog with an input field into which you can enter the name of the certificate holder --- or ideally --- the email address of his certificate. #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-kleopatra-certificateSearchOnKeyserver_en.png]] To view the details of a selected certificate, click on the button {{{Button(Details...)}}}. If you wish to add one of the certificates you have found into your local certificate collection, select the certificate from a list of search results and click on {{{Button(Import)}}}. Kleopatra will subsequently display a dialog with the import results. Confirm with {{{Button(OK)}}}. If the import was successful, you will see the selected certificate in Kleopatra's certificate administration. *** Export certificates to OpenPGP certificate servers #+index: Certificate!export {{{MarginPGP}}}If you have configured an OpenPGP certificate server as described in Section \ref{configureCertificateServer}, a click of your mouse will send your public OpenPGP certificate around the world. Select your OpenPGP certificate in Kleopatra and then click on the menu item {{{Menu(File\to{}Export certificate to server...)}}}. You only need to send your certificate to any of the available OpenPGP certificate servers, since almost all of these will synchronize on a global level. It may take one to two days until your OpenPGP certificate is actually available worldwide, but then you will have a ``global" certificate. If you export your certificate without first having configured an OpenPGP certificate server, Kleopatra will suggest the default server =hkp://keys.gnupg.net=. ** Encrypting file attachments #+index: Encrypting file attachments If you want to send an encrypted email and attach files, you generally also want your attachments to be encrypted. Where GnuPG is well integrated into your email program, attachments should be treated just like the actual text of your email, hence they should be signed, encrypted or both. *GpgOL automatically assumes the encryption and signing of attachments.* In the case of encryption tools that are not as well integrated into an email program, you have to be careful: Attachments are often sent along in uncrypted form. What to do in such a case? Easy: you encrypt the attachment separately and then attach it to the email. Therefore this is no different from simply encrypting files, as described in Chapter\ref{ch:EncFiles}. ** Signing and encrypting files :PROPERTIES: :CUSTOM_ID: ch:EncFiles :END: #+index: GpgEX You can use Gpg4win for signing and encrypting not just emails, but also individual files. The principle is the same: - You *sign* a file using your private certificate, to ensure that the file cannot be modified. - Then *encrypt* the file using a public certificate, to prevent unauthorized persons from seeing it. Using the application *GpgEX*, you can sign or encrypt files out of Windows Explorer --- with both OpenPGP or S/MIME. This chapter shows you exactly how this works. If you are sending a file as an email attachment, e.g. GpgOL will automatically look after signing and encrypting your file together with your email. You do not have to do anything else. *** Signing and checking files :PROPERTIES: :CUSTOM_ID: sec_signFile :END: #+index: File!sign When signing a file, you are mainly concerned about making sure it is not changed, rather than keeping it secret (Integrity). #+index: Integrity Signing is very easy using *GpgEX* from the Windows Explorer context menu. Select one or more files or folders and use the right mouse key to select the context menu: #+ATTR_LaTeX: width=0.3\textwidth [[file:images-compendium/sc-gpgex-contextmenu-signEncrypt_de.png]] You will see the {{{Menu(Sign and encrypt)}}} menu. In the following window, select the option {{{Menu(Sign)}}}: #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-kleopatra-signFile1_en.png]] #+index: ASCII armor If required, you can also use the option {{{Menu(Output as text (ASCII armor)}}}. The signature file will receive the file ending =.asc= (OpenPGP) or =.pem= (S/MIME). These file types can be opened with any text editor --- you will however only see the numbers and letters you have already seen before. If this option is not selected, the signature will be created with the ending =.sig= (OpenPGP) or =.p7s= (S/MIME). These files are binary files, and they cannot be viewed in a text editor. Then click on {{{Button(Next)}}}. In the following dialog --- if not already selected by default --- select your private (OpenPGP or S/MIME) certificate with which you want to sign the file. #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-kleopatra-signFile2_en.png]] Now confirm your selection with {{{Button(Sign)}}}. Enter your passphrase in the pin entry dialog. Once the signing process has completed successfully, the following window appears: #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-kleopatra-signFile3_en.png]] You have now successfully signed the file. A "separate" signature is always used to sign a file. That means that your file that is to be signed will remain unchanged and a second file with the actual signature will be created. To verify the signature later on, you will need both files. The example below shows which new file you will receive if you sign your selected file (here =.txt=) using OpenPGP or S/MIME. There are four possible resulting file types: - OpenPGP :: =.txt \to{} .txt\textbf{.sig}= =.txt \to{} .txt\textbf{.asc}= \small(output as text/ASCII-armor) \normalsize - S/MIME :: =.txt \to{} .txt\textbf{.p7s}= =.txt \to{} .txt\textbf{.pem}= \small{ (output as text/ASCII-armor)} \normalsize **** Checking a signature #+index: File!check signature Now check the integrity of the file that has just been signed, i.e. check that it is correct! To check for integrity and authenticity, the signature file --- hence the file with the ending =.sig=, =.asc=, =.p7s= or =.pem= --- and the signed original file (original file) must be in the same file folder. Select the signature file and select the entry {{{Menu(Decrypt and check)}}} from the Windows Explorer context menu: #+ATTR_LaTeX: width=0.3\textwidth [[file:images-compendium/sc-gpgex-contextmenu-verifyDecrypt_de]] You will see the following window: #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-kleopatra-verifyFile1_en.png]] Under {{{Menu(Enter file)}}}, Kleopatra shows the full path to your selected signature file. The option {{{Menu(Input file is a separate signature)}}} is activated since you have signed your original file (here: {{{Menu(Signed file)}}}) with the input file. Kleopatra will automatically find the associated signed original file in the same file folder. The same path is also automatically selected for the {{{Menu(Ouput folder)}}}. It only becomes relevant however once you are processing more than one file simultaneously. Confirm the operations with {{{Button(Decrypt/Check)}}}. Following a successful check of the signature, the following window appears: #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-kleopatra-verifyFile2_en.png]] The result shows that the signature is correct --- therefore you can be sure that the file's integrity has been preserved and therefore the file has *not* been modified. Even if only one character is added to the original file, or is deleted or modified, the signature will be shown as having been broken (Kleopatra displays the result as a red warning): #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-kleopatra-verifyFile2a-badSignature_en.png]] *** Encrypting and decrypting files #+index: File!encrypt Files can be signed and encrypted just like emails. You should practice it once more in the following section using GpgEX and Kleopatra. Select one (or more) file(s) and open the context menu using your right mouse key: #+ATTR_LaTeX: width=0.3\textwidth [[file:images-compendium/sc-gpgex-contextmenu-signEncrypt_de.png]] Select {{{Menu(Sign and encrypt)}}} again. You will see the already familiar dialog from signing a file (see also section\ref{sec_signFile}). In the top field, select the option {{{Menu(Encrypt)}}}: #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-kleopatra-encryptFile1_en.png]] You should only change the encryption settings if this is required: #+index: ASCII armor - Output as text (ASCII armor): :: When you activate this option, you will obtain the encrypted file with the file ending =.asc= (OpenPGP) or =.pem= (S/MIME). These file types can be opened with any text editor --- but you will only see the mixture of letters and characters you have already seen before. If this option is not selected, the system will create an encrypted file with the ending =.gpg= (OpenPGP) or =.p7m= (S/MIME). These files are binary files, so they cannot be viewed with a text editor. - Delete unencrypted original: :: If this option is activated, the selected original file will be deleted after encryption. Click on {{{Button(Next)}}}. Who should the file be encrypted for? Select one or more recipient certificates in the next dialog: #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-kleopatra-encryptFile2_en.png]] To make your selection, choose the required certificates in the top portion and press {{{Button(Add)}}}. You will see all selected certificates in the lower dialog portion for review purposes. Depending on the selected recipient certificate and its type (OpenPGP or S/MIME), your file is then encrypted using OpenPGP and/or S/MIME. So if you selected an OpenPGP certificate /and / an S/MIME certificate, you will receive two encrypted files. The possible file types for the encrypted files are found on the next page. Now click on {{{Button(Encrypt)}}}: The file is encrypted. After a successful encryption, the results window should look something like this: #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-kleopatra-encryptFile3_en.png]] That's it! You have successfully encrypted your file! Similar to signing a file, the result will depend on the selected encryption method (OpenPGP or S/MIME). An encryption of your original file (here =.txt=) can result in four possible file types: - OpenPGP: :: =.txt \to{} .txt\textbf{.gpg}= =.txt \to{} .txt\textbf{.asc}= \small(for output as text/ASCII-armor) \normalsize - S/MIME: :: =.txt \to{} .txt\textbf{.p7m}= =.txt \to{} .txt\textbf{.pem}= \small{ (for output as text/ASCII-armor)} \normalsize You now forward one of these four possible encrypted files to your selected recipient. In contrast to signing a file, the unencrypted original file is of course *not* forwarded. **** Decrypting a file #+index: File!decrypt Now you can decrypt the previously encrypted file for test purposes. To this end, you should also have encrypted to your own certificate during the previous encryption process --- otherwise you cannot decrypt the file with your private key (see Chapter\ref{ch:archive}). Select the encrypted file --- hence one that ends with =.gpg=, =.asc=, =.p7m= or =.pem= --- and select the entry {{{Menu(Decrypt and check)}}} in the Windows Explorer context menu: #+ATTR_LaTeX: width=0.3\textwidth [[file:images-compendium/sc-gpgex-contextmenu-verifyDecrypt_de]] If you like, you can still change the output folder in the following decryption dialog. #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-kleopatra-decryptFile1_en.png]] Click on {{{Button(Decrypt/Check)}}}. Then enter your passphrase. The result shows that the decryption was successful: #+ATTR_LaTeX: width=0.85\textwidth [[file:images-compendium/sc-kleopatra-decryptFile2_en.png]] You should now be able to easily read the decrypted file or use it with a corresponding program. **** In short You have learnt how to do the following using GpgEX: - sign files - check signed files - encrypt files - decrypt files **** Simultaneous encryption and signature You have probably already noticed this option in the corresponding dialogs. If you select it, GpgEX will combine both tasks in one step. Please ensure that /signatures are applied first/, before the encryption process. The signature is therefore always encrypted at the same time. It can only be viewed and checked by those who have successfully decrypted the file. If you want to sign /and/ encrypt the file, you can only do it with OpenPGP at this time. ** Importing and exporting a private certificate :PROPERTIES: :CUSTOM_ID: ch:ImExport :END: #+index: Key!pair Chapters \ref{ch:publishCertificate} and \ref{ch:importCertificate} explained the import and export of certificates. You exported your own certificate in order to publish it, and you have imported the certificate of your correspondence partner and thus attached it to your "key ring" (i.e. accepted it into your certificate administration). This process always referred to *public* keys. However, sometimes it is also necessary to import or export a *private* key. For example, if you wish to continue to use an already existing (OpenPGP or S/MIME) key pair with Gpg4win, you have to import it. Or, if you want to use Gpg4win from another computer, the entire key pair has to be transferred to that computer --- the public and private key. *** Export #+index: Certificate!export You must make up a backup copy using Kleopatra anytime you transfer a private certificate to another computer or want to save it to another hard drive partition or backup medium. You may have already set up such a backup copy at the end of your OpenPGP certificate creation process. Since your OpenPGP certificate may have received additional authentications in the meantinme, you should back it up again if applicable. Open Kleopatra, select your own certificate click on {{{Menu(File\to{}Export private certificate)}}}. #+ATTR_LaTeX: width=0.6\textwidth [[file:images-compendium/sc-kleopatra-openpgp-exportSecretKey_de.png]] Select the path and the file name of the output file. The file type is set automatically. Depending on whether you want to export a private OpenPGP or S/MIME key, the file ending =.gpg= (OpenPGP) or =.p12= (S/MIME)will be selected by default. These are binary files which contain your encrypted certificate (including the private key). #+index: ASCII armor When you activate the option {{{Menu(ASCII-protected (ASCII armor)}}}, the file ending =.asc= (OpenPGP) or =.pem= (S/MIME) will be selected. These file types can be opened with any text editor --- but you will only see the "mess" of numbers and characters that we have already seen before. If this option is not selected, an encrypted file with the ending =.gpg= (OpenPGP) or =.p12= (S/MIME) will be created. These files are binary files, so they cannot be viewed with a text editor. Kleopatra stores both key parts --- private and public --- in *one* private certificate. *Attention:* Please handle this file very carefully. It contains your private key and therefore information that is critical to security! *** Import #+index: Certificate!import To import your previously exported private certificate into Kleopatra, proceed as you would for importing other public certificates (see Chapter\ref{ch:importCertificate}): Click on {{{Menu(File\to{}Import certificate...)}}} and select the file to be imported. If it concerns a PKCS12 file (e.g. type =.p12=), the system will first ask you for a passphrase to unlock the private key: #+ATTR_LaTeX: width=0.5\textwidth [[file:images-compendium/sc-pinentry-p12-import-a_en.png]] Now enter the prassphrase --- which could also be a new one --- that is used to protect your private key after the import is complete: #+ATTR_LaTeX: width=0.5\textwidth [[file:images-compendium/sc-pinentry-p12-import-b_en.png]] Repeat the passphrase entry. If your passphrase is too short or consist only of letters, the system will give you a corresponding warning. Following a successful import, an information window displaying the results of the import process will appear; here is an example of a private OpenPGP certificate: #+ATTR_LaTeX: width=0.6\textwidth [[file:images-compendium/sc-kleopatra-import-openpgp-secret-key_en.png]] Kleopatra has imported both the private as well as the public key from the backup file. Your certificate can be found in "My certificates" in Kleoatra's certificate administration. Please also save the backup copy of your private certificate --- if possible on a physically secured (e.g. in a vault) external medium. Then delete it from your hard drive and also remember to remove the deleted file from your "recycling bin". Otherwise this file poses a great security risk for your secret email encryption. {{{MarginPGP}}}There may be cases when you are not able to import a certificate exported with PGP ("Pretty Good Privacy"). This is because some PGP versions use an algorithm (IDEA) which cannot be supported by GnuPG for legal reasons. To take care of this problem, simply change the passphrase in PGP and export/import the OpenPGP certificate again. If this also does not work, set the passphrase in PGP to "empty", that is, no protection, and export/import again --- in this case you must ensure that you have *securely deleted the file* and then *set up a new real passphrase* in PGP and Gpg4win. *Congratulations! You have successfully exported and reimported your key pair.* ** System-wide configuration and pre-population for \protect{S/MIME} :PROPERTIES: :CUSTOM_ID: ch:smime-configuration :END: {{{MarginCMS}}}As part of a central software distribution or environments in which many users are working on one computer, it makes sense to set up some system-wide specifications and pre-populations for Gpg4win. This relates particularly to S/MIME, because in the case of specified chains of trust it makes sense that users share the information. Some typical system-wide settings include: #+index: Trustworthy root certificates #+index: Root certificates - Trustworthy root certificates :: To avoid a situation where each user must search and install the required root certificates, and check and authenticate the trustworthiness of the same (see Section \ref{sec_allow-mark-trusted}), it is useful to install a system-wide pre-population of the most important root certificates. To this end, the root certificates should be saved --- as described in Section \ref{trustedrootcertsdirmngr} --- and the trustworthy root certificates should be defined --- as described in Section \ref{sec_systemtrustedrootcerts}. #+index: Certificate!CA - Directly available CA certificates :: To save users from searching and importing the certificates of certificate authorities, it also makes sense to pre-populate the system with the most important CA certificates. For a description, see Section \ref{extracertsdirmngr}. #+index: Proxy #+index: Certificate Revocation Lists #+index: CRLs|see Certificate Revocation Lists #+index: OSCP #+index: LDAP #+index: HTTP #+index: Directory Manager|see DirMngr #+index: DirMngr - Proxy for certificate server and certificate revocation list searches :: Internal networks cannot permit individual computers to directly connect to the outside (central firewall), but can provide an acting service, a so-called "proxy". DirMngr can also handle HTTP and LDAP proxies. With respect to validity information, X.509 protocols offer different options. Most certification agencies publish certificate revocation lists (also described as CRLs , supported as per RFC5280) and OSCP (as per RFC2560). OSCP has more recent information, but with the disadvantage that network traffic occurs all the way to the OSCP service, and it is therefore possible to see with whom messages are being exchanged. GnuPG can work with both options; component "DirMngr" that runs as the system-wide service. S/MIME certificates usually contain information on where your certificate revocation list can be picked up externally. Oftentimes it includes HTTP, but also directory services via LDAP. In contrast to OpenPGP, the client cannot pick where to pick up the certificate revocation list, but has to follow the available information. Since some certificates only provide certificate revocation lists via LDAP, it is necessary to allow both HTTP as well as LDAP queries to the outside. If possible, an acting service can ensure, at the content level, that only X.509 certificate revocation lists with correct information are transmitted. If your network requires a proxy for the HTTP and HKP or LDAP queries required for OpenPGP or S/MIME, please follow these steps: 1. Set the X.509 certificate server search to a proxy, as described in Section\ref{x509CertificateServers}. 2. Set the certificate revocation list search to a proxy, also described in Section\ref{x509CertificateServers}. 3. Restart the DirMngr (see Section\ref{dirmngr-restart}). ** Known problems and help #+index: Troubleshooting *** GpgOL menus and dialogs no longer found in Outlook #+index: Outlook It may happen that the menus and dialogs added to Outlook by GpgOL can no longer be found. This may be due to a technical problem that caused Outlook to deactivate the GpgOL component. Reactivate GpgOL via the Outlook menu: Outlook2007: {{{Menu(?\to{}Deactivated components)}}} Outlook2003: {{{Menu(?\to{}Info\to{}Deactivated components)}}} To (de)activate GpgOL manually, use Outlook's add-in manager: - *Outlook2003:* {{{Menu(Extras\to{}Options\to{}Other\to{}Advanced options...\to{}Add-In manager...)}}} - *Outlook2007:* {{{Menu(Extras\to{}Trust relations Center\to{}Add-Ins)}}} --- then select {{{Menu(Exchange --- Client extensions)}}} under {{{Menu(Manage)}}} and click on {{{Button(Go~to...)}}}. *** GpgOL buttons are not on the Outlook 2003 toolbar If there are already a lot of buttons on the toolbar of the message window, Outlook 2003 will not necessarily display GpgOL's signature/encryption icons. You can display these buttons by clicking on the small icon with the arrow pointing downwards on the tool bar ({{{Menu(Options for toolbar)}}}): You will see an overview of all non-displayed buttons. Clicking on an entry will move it into the visible area of the toolbar. *** GpgOL button are listed unter "Add-Ins" (Outlook 2007) Outlook 2007 introduced the so-called "ribbon" interface. This multi-functional bar in the Outlook message window has different tabs. The GpgOL buttons (for encryption, signatures etc.) are organised under the "Add-Ins" tab; Outlook saves all buttons of extensions in that location. It is not possible to integrate the GpgOL buttons under "Messages", for example. You can adjust your {{{Menu(tool bar for quick access)}}} and add the toolbar commands of the Add-Ins tab. *** Errors when starting GpgOL If you have first installed Gpg4win (and hence the GpgOL program component) on a drive, then uninstalled it and re-installed it on another drive? If yes, it is possible that Outlook will continue to search for the GpgOL path on the first (old) drive. This means that the GpgOL program extension is no longer started when Outlook starts, and the following error message appears: /The extension =old path to gpgol.dll= could not be installed or loaded/ The problem can be solved by using 'Detect and repair' in Help, among other things.} You can solve this problem by resetting the internal Outlook (cached) program extension path. To do this, please delete the following file: : %APPDATA%\Lokale Einstellungen\Application data\ ↩ : Microsoft\Outlook\extend.dat *Outlook should not be running during this process.* Then restart Outlook, and it should work fine with GpgOL. *** Installation of Gpg4win on a virtual drive Please note that it is not possible to install Gpg4win on a *virtual drive* simulated with the command =subst=. These virtual drives can only be used locally by the current user. System services, such as DirMngr, do not see these drives. Therefore the installation path is not valid --- the installation will stop with error type =error:StartService: ec=3=. Please install Gpg4win on a drive that is available across the system. *** GpgOL does not check "CryptoEx" InlinePGP emails #+index: CryptoEx To check or decrypt signed or encrypted InlinePGP email(s) sent by the Outlook program extension "CryptoEx", S/MIME support must be activated in the GpgOL options. Make sure that the following option is active in Outlook under {{{Menu(Extras\to{}Options\to{}GpgOL)}}}: {{{Menu(Activate S/MIME support)}}}. *** Does not allow S/MIME operations (system service "DirMngr" not running) :PROPERTIES: :CUSTOM_ID: dirmngr-restart :END: #+index: DirMngr {{{MarginCMS}}}The "Directory Manager" (DirMngr) is a service installed by Gpg4win, which manages access to certificate servers. One task of the DirMngr is to load certificate revocation lists (CRLs) for S/MIME certificates. It is possible that S/MIME operations (signature creation and check, encryption and decryption) cannot be performed because DirMngr is not available. Therefore Gpg4win default settings must ensure that DirMngr checks the revocation lists --- if this is not done, the operation cannot be performed, since it means the potential use of a compromised certificate. To address this problem, the system administrator restarts DirMngr. This is done via {{{Menu(System control\to{}Administration\to{}Services)}}}. You will see DirMngr in the list --- and the service can be restarted via the context menu. *** S/MIME operations not allowed (CRLs not available) :PROPERTIES: :CUSTOM_ID: smime-problem-crl :END: {{{MarginCMS}}}It is possible that S/MIME operations (signature creation and check, encryption and decryption) cannot be performed because the CRLs are not available. Therefore Gpg4win default settings must ensure that revocation lists are checked --- if this is not done, the operation cannot be performed, since it means the potential use of a compromised certificate. Help is provided by setting up an acting service ("proxies")for picking up revocation lists (see Section \ref{x509CertificateServers}). In an emergency (or for testing purposes, CRL checks can also be turned off. To do this, open the Kleopatra menu {{{Menu(Settings\to{}Set up Kleopatra)}}} and then the group {{{Menu(S/MIME check)}}}. Activate the option {{{Menu(Never consult recovation lists)}}}. *Attention:* Be aware that this also means that you run a higher risk of using a compromised certificate. Turning off the revocation list check is never a substitute for setting up a proxy. *** S/MIME operations not allowed (root certificate is not trustworthy) :PROPERTIES: :CUSTOM_ID: smime-problem-rootcertificate :END: #+index: Root certificates #+index: Certificate!chain {{{MarginCMS}}}The respective root certificate must be trusted for a full review of X.509 certificate chains. Otherwise it is not possible to perform S/MIME operations (signature creation and check, encryption and decryption). To express your trust in a root certificate, you have two options. - Write the fingerprint of the corresponding root certificate in a /system-wide/ configuration file. Now the root is trustworthy for all users. To do this, you must have Windows administrator rights. For a detailed description, see Section\ref{sec_systemtrustedrootcerts}. - Root certificate set by user (no system-wide adjustment required). To do this, you must mark the option {{{Menu(Allow marking of root certificates as trustworthy)}}} in Kleopatra's settings. After that, every time you import a new root certificate, you will be asked whether you trust it. For more details, see Section\ref{sec_allow-mark-trusted}. ** Files and settings in Gpg4win *** Personal user settings The personal settings for each user are found in the file folder: =%APPDATA%\gnupg=. Often, this is the following folder: =C:\Documents and settings\\Application data\gnupg\= Please note that this is a hidden file folder. To make it visible, you have to activate the option {{{Menu(Show all files and folders)}}} under the group {{{Menu(Hidden files and folders)}}} in the tab {{{Menu(View)}}} of the Explorer {{{Menu(Extras\to{}Folder options)}}} menu This file folder contains all personal GnuPG data, hence private keys, certificates, trust settings and configurations. This folder is /not/ deleted when Gpg4win is uninstalled. Please ensure that you make regular backup copies of this folder. *** Cached certificate revocation lists #+index: Certificate Revocation Lists #+index: DirMngr {{{MarginCMS}}}The system-wide service Mngr (Directory Manager) also checks whether an X.509 certificate is blocked and can therefore not be used. To this end, certificate revocation lists (CRLs) are picked up from the issuing offices for the certificates (CAs) and cached for the duration of the validity period. The lists are saved under: : C:\Documents and Settings\LocalService\Lokale Settings\ ↩ : Application data\GNU\cache\dirmngr\crls.d\ These are /protected/ files, which Explorer does not display by default. However, if you wish to show these files, deactivate the option {{{Menu(Hide protected system files)}}} in the Window Explorer {{{Menu(View)}}} settings. No changes should be made to this file folder. *** Trustworthy root certificates from DirMngr :PROPERTIES: :CUSTOM_ID: trustedrootcertsdirmngr :END: #+index: DirMngr #+index: Trustworthy root certificates #+index: Root certificates {{{MarginCMS}}}For a full review of X.509 certificates, you must trust the root certificates which were used to sign the revocation lists. The root certificates which the DirMngr should trust across the entire system when performing its checks are stored in the following file folder: : C:\Documents and settings\All Users\Application data\ ↩ : GNU\etc\dirmngr\trusted-certs\ *Important:* The corresponding root certificates must be available as files in DER format in the above file folder, with the file name =.crt= or =.der=. The DirMngr runs as a system-wide service and must be restarted if changes have been made to the "trusted certs" file folder. Afterwards, the root certificates saved in this folder are set to *trustworthy* for all users. Please also see Section \ref{sec_systemtrustedrootcerts} in order to completely trust root certificates (system-wide). *** Other certificates from DirMngr :PROPERTIES: :CUSTOM_ID: extracertsdirmngr :END: {{{MarginCMS}}}Since the X.509 certificate chain must be checked prior to a cryptography operation, the corresponding certificate of the authentication instance ("Certificate Authority", CA) must also be checked. For immediate availability, CA certificates can be saved in this (system-wide) file folder: : C:\Documents and settings\All Users\Application data\ ↩ : GNU\lib\dirmngr\extra-certs\ Certificates that are not available here and/or not available from users must automatically be loaded by X.509 certificate servers. These CA certificates can also be imported manually by a user however. It makes sense to store the most important CA certificates in this folder as part of system-wide specifications. *** System-wide configuration for use of external X.509 certificate servers :PROPERTIES: :CUSTOM_ID: x509CertificateServers :END: {{{MarginCMS}}}GnuPG can be configured in such a way that allows the system to search for missing X.509 certificates or certificate revocation lists on external X.509 certificate servers (see also Chapter \ref{ch:smime-configuration}). To conduct a *X.509 certificate search*, the system service DirMngr uses a list of certificate servers which can be entered in the file : C:\Documents and settings\All Users\Application data\ ↩ : GNU\etc\dirmngr\ldapservers.conf These certificate servers are used for all users (system-wide). In addition, users can also set up additional user-specific certificate servers for certificate searches --- e.g. directly via Kleopatra (see Chapter\ref{configureCertificateServer}). The exact syntax for certificate server entries in the aforementioned configuration file is as follows: : HOSTNAME:PORT:USERNAME:PASSWORD:BASE\_DN #+index: Proxy If access to external X.509 certificate servers is blocked by firewalls in the internal network, it is also possible to configure a proxy service in =ldapservers.conf= for transmitting the certificate search, as illustrated in the following sample line: =proxy.mydomain.example:389:::O=myorg,C=de= #+index: Certificate Revocation Lists With respect to a search of *Certificate Revocation Lists* (CRLs), the same directory contains a configuration file from: : C:\Documents and settings\All Users\Application data\ ↩ : GNU\etc\dirmngr\dirmngr.conf Please note that only administrators can write in this file. You can add the following proxy options to this configuration file (each option in a row): #+index: HTTP - =http-proxy HOST[:PORT]= :: This option uses =HOST= and =PORT= for accessing the certificate server. The environment variable =http_proxy= will be overwritten if this option is activated. Example: : http-proxy http://proxy.mydomain.example:8080 #+index: LDAP - =ldap-proxy HOST[:PORT]= :: This option uses =HOST= and =PORT= for accessing the certificate server. If no port number is listed, the standard LDAP port 389 will be used. This option will overwrite the LDAP URL contained in the certificate, or will use =HOST= and =PORT= if no LDAP URL has been entered. - =only-ldap-proxy= :: This option ensures that DirMngr only uses the proxy configured under =ldap-proxy=. Because otherwise DirMngr will try to use other configured certificate servers, if the connection via =ldap-proxy= is not successful. *** System-wide trustworthy root certificates :PROPERTIES: :CUSTOM_ID: sec_systemtrustedrootcerts :END: #+index: Root certificates #+index: trustlist.txt {{{MarginCMS}}}The pre-populated root certificates which are deemed as trustworthy for the entire system are defined in the file: : C:\Documents and settings\All Users\Application data\ ↩ : GNU\etc\gnupg\trustlist.txt To mark a root certificate as trustworthy, the corresponding fingerprint of the certificate, followed by an empty space and a large =S= must be entered into the above file. A certificate is explicitly marked as not trustworthy if the row beings with the prefix "=!=". You can also enter multiple root certificates. In that case, please ensure that each fingerprint is located in a new row. A row that begins with =#= will be treated as a comment and ignored. Important: The end of the file must be followed by an empty row. An example: #+BEGIN_EXAMPLE # CN=Wurzel ZS 3,O=Intevation GmbH,C=DE A6935DD34EF3087973C706FC311AA2CCF733765B S # CN=PCA-1-Verwaltung-02/O=PKI-1-Verwaltung/C=DE DC:BD:69:25:48:BD:BB:7E:31:6E:BB:80:D3:00:80:35:D4:F8:A6:CD S # CN=Root-CA/O=Schlapphuete/L=Pullach/C=DE !14:56:98:D3:FE:9C:CA:5A:31:6E:BC:81:D3:11:4E:00:90:A3:44:C2 S #+END_EXAMPLE In some cases it is useful to reduce the criteria for checking the root certificate. To do this, you can set an additional flag =relax= after the =S=: = S relax= For more details, see current GnuPG documentation (item "trustlist.txt"): http://www.gnupg.org/documentation/manuals/gnupg/Agent-Configuration.html Therefore the exact syntax for entries in trustlist.txt is as follows: : [!] S [relax] whereby =!= and =relax= are optional. Instead of the flag =S=, the values =P= and =*= are also provided, which are reserved for future use. *Important:* To fully mark root certificates as trustworthy in Kleopatra (certificate is highlighted in blue), the root certificates must also be stored for the DirMngr, as described in Section \ref{trustedrootcertsdirmngr}. # Fixme: With decent GnuPG/Dirmngr version this is not anymore required *** User marking of trustworthiness of root certificates :PROPERTIES: :CUSTOM_ID: sec_allow-mark-trusted :END: #+index: Trustworthy root certificates #+index: Root certificates {{{MarginCMS}}} Root certificates can also be marked as trustworthy by individual users --- this means that a system-wide configuration (see Section \ref{trustedrootcertsdirmngr} and \ref{sec_systemtrustedrootcerts}) is then not required. Open the Kleopatra menu {{{Menu(Settings\to{}Configure Kleopatra)}}} and then the groupo {{{Menu(S/MIME check)}}}. Then activate the option {{{Menu(Allow root certificates to be marked trustworthy)}}}. Now, if you are using a root certificate that has not been previously marked as trustworthy, the system will ask you whether you wish to classify it as trustworthy. Please ensure that the gpg-agent may have to be restarted before a change takes effect (e.g. by logging in and out). #+index: trustlist.txt The root certificates which you have marked as trustworthy (or explicitly marked as non-trustworthy) are automatically stored in the following file: : C:\Dokumente und Einstellungen\\ ↩ : Application data\gnupg\trustlist.txt The same syntax applies to trustlist.txt as described in Section \ref{sec_systemtrustedrootcerts}. ** Detecting problems in Gpg4win programs (log files) #+index: Log file It is possible that one of the Gpg4win program components does not work as expected. Quite often this is due to a feature related to the work environment, which Gpg4win software developers are not able to detect. To assist them with finding the problem, or to allow users to see the detailed technical processes, Gpg4win programs also offer help. Usually though, this type of help must first be activated. One of the most important tools are log files: This is where detailed diagnostic information on internal technical processes is stored. By looking at a log file, a software developer can often quickly detect a problem and the possible solution, even if the program may seem very complex at the beginning. If you wish to send an error report to the software developer, you may this information helpful: http://gpg4win.org/reporting-bugs.html Log files --- described as ,,debug information'' in the above-mentioned URL --- frequently offer valuable information and should therefore be attached to an error report. This chapter describes how to activate program process information (which is what log files essentially are) for individual Gpg4win programs. *** Activating Kleopatra log files #+index: Log file!Kleopatra Kleopatra log data consists of many files, therefore the first step is to create a file folder for the log files, for example: =C:\TEMP\kleologdir= Please note that these are user settings, not system administrator settings. Therefore the settings must be made for each user who wants to create Kleopatra log data, and you must ensure that different =kleologdir= file folders are used. The path to this folder must be noted in the new environment variables =KLEOPATRA\_LOGIDR=: To do this, open the control panel, choose {{{Menu(System)}}}, then the tab {{{Menu(Advanced)}}} and finally the button {{{Button(Environment variables)}}}. Add the following new *user variable*: #+BEGIN_QUOTE Name of variable: =KLEOPATRA\_LOGDIR= Value of variable: =C:\TEMP\kleologdir= #+END_QUOTE Make sure that the entered file folder actually exists. You can also create it afterwards. To ensure the log function goes into effect, Kleopatra must be shut down and restarted, the file folder of log data must exist and must be available for Kleopatra to write on. While Kleopatra is used, it will record process information in the file =kleo-log= (main log file) as well as possibly many files with a name that following this pattern: =pipe-input-