Concepts/OpenPGP Getting Started/de

Einleitung

Wenn Sie einen OpenPGP-Schlüssel erzeugen, dann treffen Sie (bewusst oder unbewusst) einige technische und organisatorische Entscheidungen, die starken Einfluss auf die Sicherheit und Nutzbarkeit Ihres Schlüssels und damit auf dessen Lebensdauer haben. Manche dieser Entscheidungen sind irreversibel. Aus mehreren Gründen ist es erstrebenswert, dass auch normale Schlüssel – auch weniger sichere – eine lange Lebensdauer haben (jedenfalls der Kern der Schlüssel).

Deshalb soll dieser Artikel Sie mit den wichtigen Aspekten der Schlüsselerzeugung vertraut machen und Ihnen dabei helfen, einen guten Schlüssel zu erzeugen, den Sie viele Jahre lang nutzen können. Dieser Artikel behandelt nur die Konzepte, mit denen Sie vertraut sein sollten, er enthält keine Schritt-für-Schritt-Anleitung weil dies unterschiedliche Phasen sein sollten: Verstehen und planen Sie zunächst, was Sie tun werden. Wenn Sie damit fertig sind, schauen Sie sich den Artikel zur Erzeugung von OpenPGP-Schlüsseln an.

Wie Sie anfangen sollten

Sie können sich leicht einen Schlüssel zum rumspielen erzeugen. Aber wenn Sie andere diesen Schlüssel verifizieren lassen, dann riskieren Sie, Arbeit zunichte zu machen. Ihr Ziel sollte sein, einen oder mehrere langlebige Schlüssel zu erzeugen. Der beste Rat ist: Versuchen Sie das nicht alleine, wenn es sich vermeiden lässt. Wenden Sie sich statt dessen an Experten, wenn Sie können; an Leute, die schon mal einen eigenen Schlüssel ersetzt und daraus gelernt haben. Erzeugen Sie den Schlüssel in einer sicheren Umgebung, verwenden Sie einen Offline-Hauptschlüssel, und geben Sie sowohl dem Hauptschlüssel als auch den Unterschlüsseln ein Ablaufdatum (nicht mehr als ein Jahr). Entscheiden Sie sich für eine Schlüsselrichtlinie (die die Sicherheitsniveaus und Verwendungszwecke des Hauptschlüssels und der Unterschlüssel beschreibt) und halten Sie diese strikt ein. Wenn Sie andere Schlüssel zertifizieren, bevor Sie sich für eine Zertifizierungsrichtlinie entschieden haben, dann zertifizieren Sie sie nicht für die Öffentlichkeit, sondern nur lokal (d.h. nicht exportierbar). Vermeiden Sie es generell, neue Aktionen auszuführen, bevor Sie gut verstanden haben, was sie bedeuten.

Merken Sie sich dies:

1. Was komfortabel ist, bedroht (fast immer) Ihre Sicherheit.
2. Mehr Sicherheit ist nicht in jedem Fall besser. Seien Sie sich aber der Konsequenzen bewusst (in beide Richtungen).

Willkommen in der Welt der Kryptpgrafie!

Schlüsselsicherheit

Wenn Schlüssel involviert sind, ist die wichtigste Frage: Wie sicher / verlässlich sind sie und ihre Verwendung? Die wichtigste Regel der Kryptografie ist nicht "Machen Sie es noch sicherer", sondern "(1) Denken Sie darüber nach, wie viel Sicherheit Sie benötigen. (2) Entscheiden Sie, welcher technische Aufwand sowohl notwendig (untere Grenze) als auch vernünftig (obere Grenze) erscheint, um diesen Anforderungen gerecht zu werden. (3) Halten Sie die Regeln, die Sie festgelegt haben (Schreiben Sie sie auf!), strikt ein. (4) Wenn weitere Personen involviert sind (was fast immer der Fall ist), lassen Sie diese präzise und sicher wissen, was die Grenzen der Nutzung und das Sicherheitsniveau des jeweiligen Schlüssels sind." Die meisten der folgenden Überlegungen beziehen sich entweder auf die Sicherheit oder auf die Transparenz der Sicherheit und der Bedeutung von Schlüsseln.

Niemand knackt Schlüssel durch Brute-force-Angriffe. Das ist sogar für eher kurze Schlüssel (etwa 1024 Bit) innerhalb der nächsten Jahrzehnte schlicht und ergreifend unmöglich für alles unterhalb einer Regierungseinrichtung eines reichen Landes. Es würde vor allem keinen Sinn ergeben: Es ist so einfach, die Schlüssel einfach zu klauen. Mit größter Wahrscheinlichkeit ist das System, mit dem Sie diesen Text lesen (falls Sie ihn nicht ausgedruckt haben...) nicht sonderlich sicher. De facto ist überhaupt kein System sicher, das für das Lesen von Webseiten oder E-Mail verwendet wird. Diskutieren Sie darüber nicht, nehmen Sie das so hin. Wenn Sie das nicht tun, kompromittieren Sie sich wahrscheinlich selber. Ein Schlüssel ist nie sicherer als das unsicherste System, auf dem er mal verwendet wurde (das schließt seine Erzeugung ein); und er ist nur um seine Passphrase sicherer als das unsicherste System, auf dem er gespeichert wurde, was kein Schutz vor einem Brute-force-Angriff ist, wenn die Passphrase nicht rein zufällig oder kürzer als 16 Stellen (Klein- und Großbuchstaben (ohne Umlaute) und Ziffern) ist.

Es ist völlig in Ordnung, OpenPGP auf unsicheren Systemen zu verwenden. Sie (und Ihre Kommunikationspartner!) müssen sich aber immer des Sicherheitsniveaus bewusst sein. Der nächste Sicherheitslevel sind Smartcards. Man kann Schlüssel von einer Smartcard zwar nicht klauen, sie aber missbrauchen, wenn man das System kontrolliert, an das die Smartcard angeschlossen ist. Der nächste Level nach Smartcards sind sichere Systeme: Trennen Sie die Verbindung zu Ihrer Festplatte, USB-Sticks (usw.) und Netzwerken, dann booten Sie von einem sicheren Medium wie einer Linux-Live-CD (natürlich aus einer vertrauenswürdigen Quelle!). Verwenden Sie Hochsicherheitsschlüssel nur in einer solchen Umgebung (und womöglich auch nur mit ungefährlichen Dokumenten, also etwa reinen Textdateien oder HTML-Dokumenten).

Hauptschlüssel und Unterschlüssel

Die meisten OpenPGP-Schlüssel haben mindestens einen Unterschlüssel (alle haben genau einen Hauptschlüssel). Sie brauchen sich normalerweise nicht um diesen Unterschied zu kümmern; Ihre Anwendung (oder genauer: die Basisanwendung, typischerweise GnuPG) wählt automatisch die richtige Schlüsselkomponente aus. Der Hauptschlüssel ist derjenige, auf den sich der Fingerprint bezieht, und nur nur er kann zertifizieren: die eigenen Unterschlüssel und User-IDs sowie die User-IDs anderer Schlüssel. Die Unterschlüssel können alles andere (vor allem entschlüsseln und signieren), wenn man sie entsprechend konfiguriert. Der Grund dafür, dass der Unterschied zwischen Haupt- und Unterschlüsseln hier angesprochen wird, ist, dass er für die Schlüsselerzeugung sehr wichtig ist: Man kann den geheimen Hauptschlüssel von den geheimen Unterschlüsseln trennen (mit GnuPG ist das möglich; es ist nicht Teil des OpenPGP-Standards!). Die Unterschlüssel können später ersetzt werden, der Hauptschlüssel nicht (das wäre dann ein neuer Schlüssel, nicht bloß ein modifizierter). Deshalb kann man einen Hauptschlüssel durchaus für "immer" (20 Jahre) verwenden, wenn man ihn bei der Schlüsselerzeugung sowohl mit einer kryptografisch sicheren Passphrase schützt als auch ihn als Offline-Hauptschlüssel abtrennt und anschließend zumindest die Passphrase sicher speichert und den Hauptschlüssel nur in sicheren Umgebungen verwendet. Das ist auch für Alltagsschlüssel wichtig. Hochsicherheitsschlüssel haben weniger Bedarf an dieser Trennung (brauchen üblicherweise gar keine Unterschlüssel). Sie sollten für jede Aktion einen eigenen Unterschlüssel erzeugen: für Signaturen, für Entschlüsselungen und bei Bedarf auch für Authentifizierung (SSH).

Sichere Umgebung

Der Schlüssel soll in einer sicheren Umgebung erzeugt werden, und der Hauptschlüssel soll nie in einer unsicheren Umgebung verwendet werden. Aber was ist eine sichere Umgebung? Das hängt vom Sicherheitsniveau des Schlüssels ab. Wenn man die Abschusscodes für Nuklearwaffen sichern will, stellt man daran höhere Anforderungen als wenn man nur seine Affäre geheimhalten möchte.

Auf keinen Fall sollten Sie von Ihrer normalen Festplatte booten (sie idealerweise vom System abtrennen), sondern von einem vertrauenswürdigen Medium. Das ist typischerweise eine Linux CD/DVD. Sie sollten darauf achten, dass dieses Medium aus einer sicheren Quelle kommt. Einfach irgendwas aus dem Internet runterzuladen und auf CD zu brennen schafft noch keine sichere Umgebung. Im allgemeinen sind gepresste Medien vertrauenswürdiger als gebrannte.

Auch die Hardware ist wichtig. Wenn man ein System verwendet, von dem vorab bekannt war, dass es für die Erzeugung wertvoller Schlüssel genutzt wird, dann mag jemand auf die Idee gekommen sein, einen Hardware-Keylogger zu installieren. Achten Sie auch auf eher triviale Angriffe: Verhindern Sie, dass jemand Sie bei der Eingabe Ihrer Hauptschlüssel-Passphrase beobachtet (und sei es durchs Fenster) oder den Zettel sehen kann, auf dem die Passphrase notiert ist. Starten Sie das System nach der Schlüsselerzeugung neu oder (besser) schalten Sie es für ca. drei Minuten aus.

User-IDs

User IDs are formally just arbitrary strings but expected to consist of a name, an optional comment, and an email address. This structure allows email software to find the suitable key for a recipient address (which most programs require you to confirm for obvious reasons). An OpenPGP public key (more precise: certificate) must have a user ID but can have as many as you like. Thus you can use the same key for several email addresses (which makes sense only if these addresses shall be used at the same security level). Combining addresses has advantages and disadvantages. The main advantage is that you need less keys and thus you and others have less work with certifications. The main disadvantages are that you can revoke user IDs but they keep visible forever and that such a combined key allows to make a trivial connections between different roles of you which you may not want connected: private person, business, other organizations (associations, political parties, whatever). You may want to keep these groups separate. And there are even reasons to keep addresses from the same group separate: reputable addresses ([email protected]), anonymous addresses ([email protected]), fun addresses ([email protected]). It also may be that you have no reason to ever use OpenPGP with certain addresses; such addresses should not be part of a user ID, of course. The decision to add an address to a key and publish that key is forever. But it is easy to add an address later. Thus consider this well before you generate the key. In case of doubt start with fewer addresses.

It makes sense to have a special user ID without an email address. With most email addresses you cannot be sure to have them forever. If you revoke a User ID because you don't use the address any more then you lose all the certifications for this user ID. But you will never lose your name (even if you marry or the like there is usually little reason to revoke that user ID). So you keep the certifications for this ID at any rate. And you can use the comment for this ID for a statement about the key itself: "everyday key with secure offline main key and key policy"

Key type and length

The well supported key types are DSA (signatures only), ElGamal (encryption only) and RSA (both); ECDSA (elliptic curves) is going to be added soon. GnuPG offers the creation of keys with a length from 1024 to 4096 bit. This is the current situation (2013).

The differences in security, execution time, signature size, and being required or just considered optional by the standard (rfc4880) are irrelevant for most scenarios. The one relevant difference is: The g10 smartcard supports RSA only. Thus generate an RSA key unless you have concrete and good reason for a different decision. 1024 bit keys are considered breakable by certain well known government agencies today or in the near future. 2048 bit keys are considered safe for decades. But remember: These well known agencies would not waste their time and money by computing your key. They would steal your key. Thus if you want a larger key in order to be safe against this kind of opponent then make sure that they cannot steal it. This obviously requires profound knowledge, discipline and probably some money. The practical reasons against very long keys are: Commonly used versions of GnuPG do not support keys with more than 2048 or 3072 bit respectively length. Operations with asymmetric keys are costly in general. To make it worse: Operation with twice the key size take eight times as long. And it takes long to generate huge keys. For mobile devices this CPU load can become a problem.

Thus: Unless you have concrete and good reason for a different decision stick to 2048 bit (at least for everyday keys).

Key expiration

The main key can set (and change) the expiration date for itself and its subkeys. The only "disadvantage" of an expiration date for others is that they have to update the key to keep it usable. But keys shall be updated regularly anyway so you may consider that an advantage as well. The main advantage of an expiration date (for the main key, too) is that keys which are not used any more can easily be recognized as such. The "official" way is another, of course. If a key is abandoned then a revocation certificate should be published. But this may be impossible (key or passphrase lost and no certificate created before (or lost, too)) or you may simply forget to do so (or to publish it everywhere). The "right" validity period is a compromise between reducing disturbance by expired keys (on both sides; remember that you need a secure environment to change the expiration date with an offline main key) and the time which a key still appears valid. One year may be a good choice.

Revocation certificate

A revocation certificate is a file (or print-out) which you may create preventively to later revoke a whole key in case you have no access to the secret main key any more. This is a huge advantage if you have not just lost access to the key but someone else has! The disadvantage is: You should protect this file / print-out similarly well as the secret main key itself. It can be serious damage if you have only one (suitable) key, need it urgently and someone else destroys it right then. Obviously a main key revocation is forever (cannot be superseded by a newer self-signature).

If you (or someone else you really trust) have another key which is secure enough then you may add this key as a designated revoker to yours (you need not publish this). A designated revoker can revoke another key. Of course, the signature for the designated revoker must be available when this shall be used. If you have not given it to the other person and lost it together with your key then this is useless. If you prefer security over availability then you may make friend A your designated revoker, encrypt this signature for friend B and ask friend C to store it.

Passphrase, safe storage, and backup

You should think about where you will store the passphrase for the main key and the revocation certificate file or print-out. Secure passphrases are hard to remember. You will most probably have to write it down. You really should not use a passphrase you have ever typed on an insecure system (and, of course, you really should not ever do so in the future). You should choose something like rsbBwNl137LcWP33RI: 18 chars consisting of lower and upper case letters and digits. Don't use special chars or umlauts. You gain little security (if you cannot remember 18 random chars then you probably cannot remember 15, too) but may get problems if you are ever forced to use the key on a rescue system (text mode Linux) with "wrong" keyboard settings. You improve security if you memorize a part of the passphrase and write down just the rest or if you write down both halves of it separately and store them in different places (one in your wallet, the other one at home). But if you store an 18 chars passphrase in two parts and an attacker gets one of them then the remaining 9 chars are not a secure protection any more. If you have created a revocation certificate then you have to store that in a safe place, too.

And, of course, you should have reliable backups of your key. It is nice if you need not be afraid that somebody has stolen your key but it is probably very unpleasant if you cannot decrypt your data any more. If you have a secure passphrase then you may even put a backup of your secret main key on your web site.

Key policy and policy URL

You should write a document (plain text or HTML) which describes the intended usage and security of your key and (maybe added later) your criteria for certifying the keys of other people. You can write one or more URLs at which this document can (later) be found into the key and in every signature you make. This key component is called a policy URL. It is a good idea to publish only user ID signatures which contain this policy URL(s). It is important that the users of your key can check whether a certain document belongs to a policy URL (the web server download is not safe, not even over HTTPS). Thus you should change the policy URL every time you change the document and mention the URL well visible in the document. You may use this pattern: http://yourdomain.example.org/openpgp/0x12345678__policy.1.html This document should have a detached signature (or a cleartext signature if it is plain text) by the offline main key. You should link the detached signature from the document.

Preferred key server

Like the policy URL a key server URL can be written into the key. You should decide which key server shall be authoritative for your key so that the users of your key know where they have to search for the "officially current version" of your key. This should be the key server which you upload key updates to first. This should be the one you configure in the GnuPG config file (--keyserver) for key searches and uploads. This address should mainly be available for a long time and have only few and short outages. You may even use your own web site: http://yourdomain.example.org/openpgp/0x12345678.asc

Availability is improved if a server pool (with the same DNS address) is used. If you have no better idea then you may use hkp://pool.sks-keyservers.net or one of the more local pools hkp://eu.pool.sks-keyservers.net (Europe), hkp://na.pool.sks-keyservers.net (North America) or hkp://sa.pool.sks-keyservers.net (South America). See http://sks-keyservers.net/overview-of-pools.php

Algorithm preferences

You can also write into your key (for others) and into your config file (for your actions) in which order you prefer the cipher and digest algorithms. You should do this before you generate the key (this is easier than changing it afterwards). It makes sense to avoid SHA-1. Please be aware that you cannot prevent that GnuPG creates SHA-1 signatures with your key (because that is the only digest required by the standard). You may want to put lines like these in your gpg.conf (due to design flaws AES256 and AES192 are less secure than AES(128) is currently believed to be...):

personal-cipher-preferences AES,AES256,AES192,CAST5,3DES
personal-digest-preferences SHA512,SHA384,SHA256,SHA224,RIPEMD160,SHA1
cert-digest-algo SHA512
default-preference-list AES,AES256,AES192,CAST5,3DES,SHA512,SHA384,SHA256,SHA224,RIPEMD160,SHA1,ZLIB,BZIP2,ZIP

Further reading

• KGpg

• KMail PGP/MIME

• KMail gpg

• OpenPGP For Beginners

• OpenPGP For Advanced Users