Die voreingestellten Algorithmen und Stärken entsprechen den aktuellen Empfehlungen. Eine Anpassung ist üblicherweise nicht erforderlich.

Stärkere Algorithmen zu verwenden (z.B. RSA-4096 statt RSA-3072) bringt keinen relevanten Sicherheitsgewinn, aber unter Umständen Nachteile mit sich. Ver- und Entschlüsselung mit RSA-4096 z.B. ist deutlich langsamer und es gibt Smartcards, welche mit solchen Schlüssellängen nicht umgehen können.

Falls sie OpenPGP Keys auf Smartcards nutzen wollen, sollten sie jedoch erwägen, für bessere Performance- und Sicherheitseigenschaften „ECDSA/EdDSA“ (bzw. brainpool) statt RSA-3072 zu wählen. Dies kann aber zu Kompatibilitätsproblemen mit veralteter, nicht VS-NfD-konformer Software führen. Auch bei Kommunikation zwischen verschiedenen Ländern mit verschiedenen zugelassenen Algorithmen muss man u.U. darauf achten, einen gemeinsamen Nenner zu finden. Da ist RSA i.d.R. am unproblematischsten.

Es gibt es auch die Möglichkeit, mehrere unterschiedliche Algorithmen in einem Zertifikat anzulegen und damit unterschiedlichen Empfängern gerecht zu werden. Allerdings müssen im VS-NfD Kontext alle Algorithmen (für Verschlüsselung und Signatur) VS konform sein, damit das Zertifikat als VS-NfD konform akzeptiert wird.

Hintergrund Information: Ein Zertifikat kann eine oder mehrere Benutzerkennungen (auch User-ID genannt) haben. Diese hat maximal die folgende Form: Mein Name (Kommentar) <email@adresse.test>

Wenn sich der Name oder die Email-Adresse, die zu einem OpenPGP-Schlüssel gehört, ändert, empfehlen wir, dem Schlüssel bzw. Zertifikat eine neue Benutzerkennung hinzuzufügen. Diese wird automatisch zur primären Benutzerkennung und prominenter angezeigt.

Der Vorteil einer weiteren neuen Benutzerkennung gegenüber der Erstellung eines neuen OpenPGP Keys ist die Beibehaltung des ursprünglichen Fingerprints, so das dieser von den Kommunikationspartnern bei der Beglaubigung der neuen Benutzerkennung nicht erneut abgeglichen werden muss. Außerdem können so bereits vorhandene verschlüsselte Dokumente und Mails weiterhin mit demselben Schlüssel entschlüsselt werden, der aktuell in Gebrauch ist.

Bei Bedarf kann man die alte Benutzerkennung widerrufen, was Sinn macht, wenn eine alte Email-Adresse nicht umgeleitet wird.

Im folgenden Beispiel ändert sich der Domainname der Email-Adresse.

Kleopatra öffnen.

Rechtsklick auf den eigenen OpenPGP Schlüssel in der Zertifikatsliste von Kleopatra und „Benutzerkennung hinzufügen“ auswählen.

Dann den gewünschten neuen Namen und die neue Email-Adresse angeben. In der Regel sind die Angaben der bisherigen Nutzerkennung vorbelegt, so dass im Beispiel nur der Domainname geändert werden muss. Nach Änderung mit OK bestätigen.

Im Passworteingabefenster das Passwort des Schlüssels eingeben und mit OK bestätigen.

Jetzt wird in der Zertifikatsliste die neue Benutzerkennung angezeigt, nur in den Zertifikatsdetails ist auch die alte Benutzerkennung aufgelistet:

Falls sie keinen eigenen Schlüsselserver in ihrem Active Directory integriert haben:

Das so geänderte Zertifikat per Rechtsklick -> Exportieren in eine Datei abspeichern. Der vorgeschlagene Name endet immer auf "public.asc".

Dann die exportierte Datei den Kommunikationspartnern auf dem bei ihnen vorgesehenen Weg zukommen lassen. Dies kann z.B. per einfacher E-Mail erfolgen, da es sich um einem öffentlichen Schlüssel handelt.

Für den Import gibt es mehrere Möglichkeiten. Man kann im Normalfall einfach auf die empfangene Datei doppelklicken, damit sie in Kleopatra importiert wird.

Im Folgenden die Import-Methode aus Kleopatra heraus, die Zertifikatsdatei liegt im Dateisystem des Empfängers:

Kleopatra öffnen.

In der Werkzeugleiste auf "Importieren" klicken.

Die erhaltene Zertifikatsdatei auswählen und mit "Öffnen" bestätigen.

Wenn das "alte" Zertifikat bereits in der Zertifikatsliste des Empfängers vorhanden war, erfolgt beim Import keine automatische Nachfrage, ob das Zertifikat beglaubigt werden soll.

Daher wird es nach dem Import als "nicht konform" (rot hinterlegt) angezeigt:

Jetzt muss die neue Benutzerkennung beglaubigt werden:

Da der Fingerprint der alten Benutzerkennung bereits in der Vergangenheit überprüft wurde, müssen sie nun nur prüfen, dass die geänderte Benutzerkennung plausibel ist, bevor sie die Beglaubigung durchführen:

Nach der Beglaubigung wird das Zertifikat wieder als "VS-NfD konform" (grün hinterlegt) angezeigt:

Man sollte alte Schlüssel nicht löschen, sondern behalten. Auch wenn sie abgelaufen oder widerrufen sind, kann man damit immer noch die alten Daten entschlüsseln.

Das gilt auch die Zertifikate anderer Personen, damit kann man immer noch alte Signaturen überprüfen.

Es gibt keine Vorgaben dazu, wann man seinen Schlüssel erneuern bzw. austauschen sollte.

Die Empfehlung des BSI ist lediglich, dass Schlüsselpaare eine maximal 3 Jahre lange Gültigkeitsdauer haben sollten. Wenn es keinen Grund für die Annahme gibt, dass ein Schlüssel kompromittiert wurde, kann man ihn (immer wieder) verlängern und muss keinen neuen erstellen.

Ein Ablaufdatum sorgt dafür, dass ein verlorener Schlüssel nach einiger Zeit nicht mehr verwendet werden wird, selbst falls man ihn nicht mehr zurückrufen kann.

Wenn man vermeiden will, dass zu viele Daten mit dem gleichen (Unter-) Schlüssel verschlüsselt sind, kann man seinem Schlüssel auch nach gewissen Zeiträumen einen neuen Unterschlüssel für die Verschlüsselung hinzufügen und nur den Signaturschlüssel verlängern. Dies geht von der Annahme aus, dass Schlüssel und Passwort einem Angreifer bekannt werden und mit dem Wechsel des Schlüsselmaterials dieser dann von weiterer Kommunikation ausgeschlossen wird. Diese Annahme und das Vorgehen bringen eine Reihe weiterer Implikationen mit sich, auf die wir hier nicht eingehen können. Bei einem sorgfältigen Umgang mit dem Schlüsselmaterial ist ein solches Vorgehen nicht notwendig.

Eine Alterung des Schlüsselmaterials gibt es nicht. Aktuelle Algorithmen sind aller Voraussicht nach auch nach Jahrtausenden nicht mit "Brute Force" Methoden zu brechen.

Solange aus der Sicherheitscommunity die Sicherheit des verwendeten Algorithmus nicht angezweifelt wird, kann er weiter verwendet werden. Das BSI und wir würden natürlich informieren, wenn ein Algorithmus nicht mehr verwendet werden und man neue Schlüsselpaare erstellen sollte.

Ja, bei einem geänderten Schlüssel muss der öffentliche Schlüssel (=Zertifikat) an die Kommunikationspartner verteilt werden, die ihn dann erneut importieren müssen. Dies gilt auch für eine Änderung des Ablaufdatums.

Nur, falls die Benutzerkennung geändert wurde, muss auch eine neue Beglaubigung erfolgen (Siehe "Vorgehen bei Änderungen von Name oder Email".)

Es gibt verschiedene Möglichkeiten.

Werfen Sie gerne einen Blick auf unsere Website unter "GnuPG Infrastructure Services" und "GnuPG actium". Wir empfehlen, sich entweder unser Whitepaper "Zertifikatsverwaltung mit GnuPG" zum Thema anzuschauen und/oder das Dokument "Beglaubigungsmanagement mit GnuPG VS-Desktop" (zu finden in Kleopatra unter Hilfe -> "Weitere Dokumentation"). Letzteres hat den Praxisteil aus dem Whitepaper mehr im Fokus.

Im Anschluss können Sie dann gezielter zu der Vorgehensweise nachfragen, die Ihnen für ihre Organisation am geeignetsten erscheint.

Eine Möglichkeit ist, den geheimen Schlüssel auf einem als VS-NfD gekennzeichneten USB-Stick zu kopieren und persönlich zu übergeben. Eventuell käme auch der Postweg mit garantierter persönlicher Zustellung in Frage. Wir empfehlen, das dazugehörige Passwort in dem Fall separat auf einem anderen Wege zu übergeben.

Sie können den geheimen Schlüssel aber auch VS-NfD konform verschlüsselt in einem geteilten Ordner ablegen oder per Mail versenden, wie andere VS-NfD Daten auch. Dafür müssen die Personen, die den Funktionspostfach-Schlüssel benötigen, auch einen eigenen OpenPGP Schlüssel haben, an den die geheime Schlüsseldatei verschlüsselt wird.

Auf diese Weise können auch Passwörter für symmetrisch verschlüsselte Dateien sicher und einfach verteilt werden, statt sie per Einschreiben zu versenden.

Für Projektgruppen bietet sich in der Regel die Nutzung der Gruppenfunktion von GnuPG [VS-]Desktop/Kleopatra an. Dabei ist die Größe der Gruppe (mehr oder weniger) unerheblich. Die Daten werden bei Auswahl der Gruppe als Empfänger für jeden der Teilnehmer verschlüsselt.

Die Gruppen werden in Kleopatra verwaltet. Dabei sollte ein Gruppenname vergeben werden, der einem Team oder Projekt entspricht. Falls es eine E-Mailadresse für die Projektgruppe gibt, sollte diese als Name verwendet werden. Dann wird eine verschlüsselte Mail an diese Adresse mit allen der Gruppe zugeordneten Zertifikaten verschlüsselt.

Es sollte darauf geachtet werden, dass eine Person die Gruppe "pflegt", so dass nur berechtigte Personen in der Gruppe sind und bei Änderungen der Liste die neue Gruppendefinition schnell allen Teilnehmern zur Verfügung gestellt wird.

Eine ausführliche Dokumentation ist in Kleopatra unter "Hilfe" zu finden.