Bundesamt für Sicherheit in der Informationstechnik

M 5.63 Einsatz von GnuPG oder PGP

Verantwortlich für Initiierung: Administrator, IT-Sicherheitsbeauftragter

Verantwortlich für Umsetzung: Administrator, Benutzer

GNU Privacy Guard (GnuPG) und Pretty Good Privacy (PGP) sind weit verbreitete Programme, mit denen Nachrichten und Dateien ver- und entschlüsselt sowie mit einer digitalen Signatur (auch elektronische Unterschrift genannt) versehen werden können. Beide Tools implementieren Funktionen, die im OpenPGP-Standard (RFC 2440) definiert sind. Durch Verschlüsselung kann die Vertraulichkeit von Informationen geschützt werden, mit digitalen Signaturen kann überprüft werden, ob eine Datei bzw. eine Nachricht authentisch ist und nicht manipuliert wurde. Sowohl mit GnuPG als auch mit PGP können weiterhin die Aufgaben des Schlüsselmanagements, wie z. B. Hinzufügen und Entfernen von Schlüsseln, wahrgenommen werden.

Verschlüsselung und digitale Signatur

Bei GnuPG und PGP werden symmetrische und asymmetrische kryptographische Verfahren eingesetzt. Symmetrische, wie AES und IDEA, dienen zur Datenverschlüsselung, asymmetrische wie ElGamal, RSA und DSA/DSS zum Schlüsselmanagement bzw. zur Signaturbildung.

Beide Tools erzeugen und verwenden öffentliche und private Schlüssel in so genannten Schlüsselpaaren. Zu jedem privaten Schlüssel gibt es genau einen öffentlichen Schlüssel. Es ist praktisch ausgeschlossen, nur mit Kenntnis des öffentlichen Schlüssels den privaten Schlüssel zu errechnen. Eine Nachricht, die mit einem öffentlichen Schlüssel verschlüsselt bzw. mit dem privaten Schlüssel signiert wurde, kann nur mit dem zugehörigen privaten Schlüssel entschlüsselt bzw. mit dem öffentlichen Schlüssel des Absenders verifiziert werden. Der öffentliche Schlüssel kann jedem bekannt gemacht werden. Er dient dazu, Nachrichten an den Besitzer des privaten Schlüssels zu verschlüsseln.

Zum Nachweis von unautorisierten Manipulationen und somit zum Schutz vor Veränderungen einer Nachricht berechnet GnuPG bzw. PGP unter Zuhilfenahme des privaten Schlüssels des Absenders einen Prüfcode über die Nachricht, die digitale Signatur. Jeder Kommunikationspartner kann mit Hilfe des öffentlichen Schlüssels des Absenders der Nachricht feststellen, ob der am Ende der Nachricht stehende Prüfcode zu der erhaltenen Nachricht passt oder ob die Nachricht unautorisiert verändert wurde.

Auf technischer Ebene findet aus Sicherheitsgründen in der Regel eine Trennung zwischen den Schlüsseln für digitale Signaturen und den Schlüsseln für Verschlüsselung statt. Dies ist für den Benutzer meist transparent.

Empfehlenswert beim Einsatz von GnuPG oder PGP ist die Kombination der beiden zuvor beschriebenen Funktionalitäten. Nachrichten bzw. Dateien sollten standardmäßig zunächst mit dem privaten Schlüssel des Absenders signiert und anschließend mit dem öffentlichen Schlüssel des Empfängers verschlüsselt werden, um einen höchstmöglichen Schutz zu erreichen.

Versionen

Sowohl GnuPG als auch PGP stehen für die gängigsten Rechnerplattformen (Unix, GNU/Linux, Microsoft Windows) zur Verfügung. Von PGP gibt es auch Versionen für MacOS. Bei GnuPG handelt es sich um Freie Software/Open Source, die derzeit aktuelle Version ist 1.2.3.

Gängige Versionen von PGP sind 2.6.3i, und 5.x bis 8.x. Die Versionen ab 5.x sind mit einer graphischen Benutzeroberfläche ausgestattet, aber nicht vollständig abwärtskompatibel zu den Vorgängerversionen.

Aufgrund der fehlenden Abwärtskompatibilität ist es empfehlenswert, vor dem Austausch von verschlüsselten Nachrichten nachzufragen, welche PGP-Version von den Kommunikationspartnern verwendet wird. Die nach wie vor weit verbreitete Version 2.6.3i ist kommandozeilenorientiert, kann aber mit Zusatzprogrammen in graphische Benutzeroberflächen und E-Mail-Clients eingebunden werden. PGP kann über verschiedene Quellen bezogen werden, u. a. Freeware-Versionen von diversen WWW-, FTP - oder E-Mail-Servern.

Auch untereinander sind GnuPG und PGP derzeit nicht vollständig interoperabel. Ursache hierfür sind einerseits Software-Patente (der von einigen PGP-Versionen standardmäßig verwendete Algorithmus IDEA ist patentiert) und andererseits kleine Abweichungen vom OpenPGP-Standard. Mit dem Auslaufen des RSA-Patents ist jedoch eine wesentliche Hürde weggefallen. RSA wird von GnuPG ab der Version 1.0.3 unterstützt.

Um diese Probleme zu umgehen, sollte - wenn möglich - nur eines der beiden Tools eingesetzt werden. Falls dies nicht möglich ist, sollten ausschließlich OpenPGP-kompatible Schlüssel verwendet werden. Auf diese Weise wird auch sichergestellt, dass die Kommunikationspartner mit Triple- DES über einen gemeinsamen symmetrischen Algorithmus verfügen. Das oben beschriebene Interoperabilitätsproblem durch die Verwendung von IDEA tritt dann nicht auf. Näheres hierzu findet sich in der Liste der häufig gestellten Fragen und Antworten auf der WWW-Seite des GnuPG-Projekts www.gnupg.org und www.gnupg.de.

Ab der Version 5 von PGP wurde die umstrittene Funktion Corporate Message Recovery ( CMR ) eingeführt. CMR bietet die Möglichkeit, Dateien oder Nachrichten, die von einer Person für eine Zweite verschlüsselt wurden, gleichzeitig für eine dritte Person entschlüsselbar zu machen. Die Verwendung eines solchen "Drittschlüssels" kann durch die Konfiguration vom Administrator zwingend vorgegeben werden.

Die PGP-Version 7 enthält zwei weitere Funktionen, mit denen unter Umständen Sicherheitsfunktionen unterlaufen werden können. Zum einen wurde ein Server-basierter Wiederherstellungsmechanismus für Schlüssel eingeführt, mit dem ein Benutzer Schlüssel weiterverwenden kann, wenn er beispielsweise die zugehörige Passphrase vergessen hat. Die andere Funktion ist das Passphrase Caching, bei dem die Passphrase zwischengespeichert wird, damit diese beim Wechsel zwischen verschiedenen PGP-Teilsystemen nicht jedes Mal neu durch den Benutzer eingegeben werden muss. Einen vergleichbaren Mechanismus gibt es auch in der Version 2.6.3i, bei der die Passphrase in einer Umgebungsvariable gespeichert werden kann. Dieser Mechanismus sollte nicht verwendet werden.

Insbesondere beim Einsatz von GnuPG oder PGP unter Betriebssystemen der Windows-Familie ist zu beachten, dass die Sicherheitsmechanismen dieser Tools durch die Ausnutzung von Sicherheitsmängeln des Betriebssystems möglicherweise unterlaufen werden können.

Sichere Installation und Bedienung

Bei GnuPG und PGP werden zwar als sicher anerkannte kryptographische Verfahren eingesetzt, durch falsche Konfiguration oder Fehlbedienung kann es aber zu einer Abschwächung des Sicherheitsniveaus kommen. Die Installation und Konfiguration inklusive der Schlüsselgenerierung ist bei GnuPG und PGP wie bei den meisten komplexeren Kryptoprodukten nicht ganz einfach. Damit sich keine Bedienungsfehler einschleichen können, ist die Einarbeitung in das jeweilige Produkt und in einige kryptographische Grundbegriffe notwendig.

Daher sollte sich in Organisationen ein Mitarbeiter in den Umgang mit dem Tool einarbeiten und als Ansprechpartner zur Verfügung stehen. Dieser sollte dann die anderen Benutzer in die sichere Bedienung von GnuPG bzw. PGP einweisen, insbesondere sollten Verschlüsselung, Signatur und Schlüsselmanagement intensiv geübt werden, bevor ein Benutzer das Programm verwendet. Weiterhin ist es empfehlenswert, dass innerhalb einzelner Organisationen eine einheitliche Programmversion verwendet wird, um die zuvor beschriebenen Kompatibilitätsprobleme zu vermeiden. Sowohl zu GnuPG als auch zu PGP gehört eine umfangreiche Dokumentation, die vor der Verwendung gelesen werden sollte. Da erfahrungsgemäß nicht alle Benutzer die Geduld aufbringen, diese zu lesen, empfiehlt es sich, eine schriftliche Einweisung auszuarbeiten, die auf die Organisationseigenheiten angepasst ist.

Falls Benutzer Fragen zu GnuPG oder PGP haben, die über die mitgelieferte Dokumentation hinausgehen, gibt es diverse Möglichkeiten:

  • Zunächst gibt es im Internet eine Sammlung der häufigsten Fragen und Antworten (Frequently Asked Questions - FAQ ) zu GnuPG (z. B. unter www.gnupg.org) und PGP (z. B. unter www.pgpi.org bzw. www.pgp.com) sowie deutschsprachige Anleitungen und Ausführungen.
  • Über Newsgruppen wie alt.security.pgp, de.comp.security, sci.crypt oder Mailinglisten ist es sehr schnell möglich, Antworten zu Problemen zu bekommen.
  • Es gibt mehrere Bücher zu PGP.

Schlüsselgenerierung

Jeder Benutzer erzeugt bei GnuPG und PGP sein "Schlüsselpaar" selbst. Hierbei sollten folgende Punkte beachtet werden:

  • Bei der Generierung der DSA/DSS- bzw. RSA-Schlüssel können verschiedene Schlüssellängen gewählt werden. Hierbei ist zu beachten, dass mit der Schlüssellänge die Entzifferungsresistenz zunimmt, aber auch die Performance sinkt. Als Schlüssellänge sollte daher 1024 Bit gewählt werden.
  • Bei der Schlüsselerzeugung muss eine so genannte Passphrase (auch Mantra genannt) eingegeben werden, die die Datei mit den privaten Schlüsseln vor unbefugtem Zugriff schützt. Wie jedes Passwort sollte auch dieses nicht leicht zu erraten sein.
    Es kursieren z. B. trojanische Pferde, die gezielt die Datei mit den privaten Schlüsseln (SECRING.*) suchen und an Externe per E-Mail senden. Wenn dann die Passphrase zu einfach gewählt war, bietet sie Brute-Force-Angriffen (automatisiertes Passwortraten) keinen ausreichenden Widerstand. Daher sollte die Passphrase mindestens aus zehn Zeichen bestehen und Sonderzeichen enthalten.
    Trojanische Pferde werden zwar in der Regel von Viren-Schutzprogrammen erkannt, dies setzt jedoch voraus, dass das beim Benutzer installierte Programm (bzw. dessen Datenbasis) hinreichend aktuell ist.
  • Zu den öffentlichen Schlüsseln gehört eine Benutzer-ID, die möglichst eindeutig sein sollte und zudem die E-Mail-Adresse enthält, z. B. benutzer@bsi.bund.de.
  • Zur Schlüsselgenerierung benötigen GnuPG und PGP möglichst zufällige Startwerte. Die einzelnen Programme und Versionen verwenden unterschiedliche Verfahren, um diese zufälligen Werte zu erzeugen. Beispielsweise wird der Benutzer gebeten, beliebigen Text einzutippen. Hierbei sollte besser "echter" Text eingegeben werden, z. B. kann dieser Absatz abgetippt werden. Einfach auf der Tastatur "herumklimpern" erzeugt meist schlechtere Ergebnisse, da die zeitlichen Abstände zwischen den Tastendrücken u. U. zu kurz und zu regelmäßig sind.

Schlüsselaufbewahrung

Die privaten Schlüssel werden in der Datei SECRING.* gespeichert. Entscheidend für den sicheren Betrieb ist, dass der Inhalt dieser Datei vertraulich bleibt und vor Manipulationen geschützt wird. Der Zugriff auf diese Datei ist zwar durch die Passphrase geschützt, trotzdem sollte sie nicht auf lokalen Netzen gehalten werden, nicht einmal auf nicht genügend gesicherten Stand-Alone-Systemen. Schlüsselringe (Sammlungen von Schlüsseln) sollten auf Diskette gespeichert werden, die der Benutzer sorgfältig verwahren muss. Der Einsatz von Chipkarten zur Schlüsselspeicherung ist vorzuziehen.

Weiterhin sollte eine Sicherungskopie der Datei SECRING.* angelegt, sowie die Passphrase notiert werden. Die Sicherungskopie und die Passphrase sollten sicher und am besten getrennt verwahrt werden, damit nicht durch einen Festplattencrash oder durch Fehlbedienung der private Schlüssel verloren geht. Nachrichten, die mit dem öffentlichen Schlüssel verschlüsselt worden sind, lassen sich in diesem Fall nicht mehr entschlüsseln.

Das Aufschreiben und Hinterlegen der Passphrase an einem gesicherten Ort sollten hierbei als kritischer Vorgang betrachtet werden, die ausschließlich der Notfallvorsorge dienen. Die abgeschlossene Schublade eines Schreibtisches oder ähnlich "sichere" Orte können keinesfalls als Aufbewahrungsort für den geheimen Schlüssel oder für die Passphrase empfohlen werden.

Revocation Certificate

Nach der Schlüsselgenerierung sollte ein so genanntes Revocation Certificate erzeugt und ausgedruckt oder auf einer Diskette gespeichert werden. Damit kann der öffentliche Schlüssel widerrufen werden, wenn die Passphrase vergessen wird oder der private Schlüssel aus anderen Gründen nicht mehr zur Verfügung steht. Das Revocation Certificate sollte sicher verwahrt werden, damit der öffentliche Schlüssel nicht unberechtigt widerrufen werden kann.

Schlüsselverteilung

Damit ein Empfänger die digitale Signatur eines Senders einer Datei überprüfen kann bzw. damit der Sender eine Nachricht für einen bestimmten Empfänger verschlüsseln kann, benötigt er den öffentlichen Schlüssel seines Kommunikationspartners. Diesen kann er auf verschiedene Weisen erhalten, z. B. per Attachment einer E-Mail oder von einem WWW-Server, er muss sich aber davon überzeugen, dass dieser Schlüssel wirklich zu der angegebenen Person gehört. Für eine kryptographisch abgesicherte Zuordnung einer Person zu ihrem öffentlichen Schlüssel werden Zertifikate verwendet, die ein vertrauenswürdiger Dritter vergibt.

Bei GnuPG und PGP kann jeder Benutzer die öffentlichen Schlüssel anderer Personen mit Zertifikaten beglaubigen. Ein Benutzer sollte einen öffentlichen Schlüssel aber nur dann zertifizieren, wenn er die Identität des Schlüsselinhabers kennt oder überprüft hat und der öffentliche Schlüssel persönlich übergeben wurde.

Alternativ kann die Echtheit eines öffentlichen Schlüssels auch über den so genannten Fingerprint verifiziert werden. Hierbei wird eine Zahlenfolge (Hashwert) aus dem öffentlichen Schlüssel berechnet und an diesen angehängt. Nach Übersendung eines öffentlichen Schlüssels kann nun mit dem Absender diese Zahlenfolge, z. B. telefonisch, verglichen werden, um nach der Bestätigung des Fingerprints den übersandten öffentlichen Schlüssel zu zertifizieren.

Zertifizierungshierarchie - Web of Trust - Internet-Keyserver

Prinzipiell können GnuPG und PGP sowohl in einer Zertifizierungshierarchie als auch in einem Web of Trust eingesetzt werden. Beim Web of Trust wird auf die Zertifikate anderer Benutzer vertraut, in einer Zertifizierungshierarchie beglaubigen vertrauenswürdige Dritte, so genannte Zertifizierungsstellen, die Schlüssel aller ihrer Benutzer auf zuverlässige und nachvollziehbare Weise.

In einem Unternehmen oder einer Behörde sollte im Intranet eine Zertifizierungshierarchie aufgebaut werden. Der Betreuer sollte alle Schlüssel für seinen Organisationsbereich bzw. für die gesamte Organisation zertifizieren. Die zertifizierten öffentlichen Schlüssel sollten im Intranet auf einem Server allen Mitarbeitern zugänglich sein, der Zugriff auf diesen Bereich sollte dabei ausschließlich lesend (Read-only) sein. Die Methode des Web of Trust sollte nur für die private Kommunikation benutzt werden.

Im Internet können öffentliche Schlüssel auf so genannten Keyservern eingestellt werden. Diese dürfen aber keinesfalls mit Zertifizierungsstellen verwechselt werden. Keyserver nehmen Schlüssel von überall in Empfang und verteilen sie auf Anfrage weiter. Es sollte klar sein, dass Schlüssel, die man von einem Keyserver erhält, von diesem in keiner Weise überprüft wurden.

Um die Echtheit eines öffentlichen Schlüssels, der auf einem Keyserver eingestellt wurde, nachzuprüfen, sollte dies mit Hilfe des bereits erwähnten Fingerprints durchgeführt werden.

Eigensignatur des öffentlichen Schlüssels

Durch die Selbstsignatur des öffentlichen Schlüssels wird nur die Benutzer-ID als Teil eines öffentlichen Schlüssels von GnuPG bzw. PGP unterschrieben. Mit Hilfe dieser Selbstsignatur ist es möglich, einen Denial-of-Service-Angriff (siehe G 5.28 Verhinderung von Diensten ) zu entdecken, dieser kann jedoch durch die Selbstsignatur des öffentlichen Schlüssels nicht verhindert werden. Da die Benutzer-ID eines öffentlichen Schlüssels nicht verschlüsselt ist, kann sie verfälscht werden. Dies hätte zur Folge, dass bei Verwendung dieses "verfälschten" Schlüssels, die verschlüsselten E-Mails den Eigentümer dieses Schlüssels nicht mehr erreichen, da sie an eine andere E-Mail-Adresse umgeleitet werden. Die Vertraulichkeit der verschlüsselten Nachricht wird hierdurch nicht gefährdet, da das Entschlüsseln der Nachricht ausschließlich mit dem privaten Schlüssel erfolgen kann.

Key Recovery

Falls die zur Verschlüsselung benutzten Schlüssel verloren gehen, sind im Allgemeinen auch die damit geschützten Daten verloren. In den kommerziellen Versionen ab 5.0 bietet PGP Funktionen zur Datenwiedergewinnung für solche Fälle an. Diese Funktionen werden auch als Key Recovery bezeichnet. Diese Funktionalität kann durch Wiederherstellung gespeicherter, verschlüsselter Daten einem Datenverlust vorbeugen, wenn ein Schlüssel oder das Zugriffspaßwort verloren ging.

Bei älteren Versionen von PGP sind Fehler in der ADK-Implementierung (Additional Decryption Key) bekannt geworden, die für Angriffe ausgenutzt werden können. Hiervon sind insbesondere die PGP-Versionen vor 6.5.8 betroffen. Es sollte daher eine hinreichend aktuelle Version eingesetzt werden, bei der möglichst alle bekannt gewordenen sicherheitsrelevanten Fehler beseitigt sind. GnuPG ignoriert grundsätzlich alle ADKs.

Wenn die Wiedergewinnungsfunktion von PGP genutzt werden soll, müssen ein oder zwei zusätzliche Schlüssel (ADK, Additional Decryption Keys) erzeugt werden. Bei der Schlüsselgenerierung werden diese "Nachschlüssel" an die neu erzeugten Schlüssel angebunden und alle Daten, die mit den neuen Schlüsseln verschlüsselt werden, enthalten zusätzlich eine Verschlüsselung des Sitzungsschlüssels mit den ADKs. So ist es im Notfall möglich, die Daten unter Verwendung dieser ADKs, ohne Nutzung des Originalschlüssels zu entschlüsseln. Damit bietet PGP die Funktion Message Recovery ohne zentrale Speicherung der Wiederherstellungsinformationen.

Die Nutzung des Key Recovery kann durch entsprechende Voreinstellungen der Clients erzwungen werden, so dass diese Funktionalität nicht von den einzelnen Benutzern unterlaufen werden kann. Allerdings hängt dann die Sicherheit der gesamten Verschlüsselung von der Vertraulichkeit der ADKs ab. Sind diese offen gelegt, können alle Daten mit ihnen entschlüsselt werden.

Um einem Missbrauch dieser höchst sensitiven Funktion vorzubeugen, ist es unabdingbar, dass die ADKs durch ein besonders sorgfältig ausgewähltes, sicher verwahrtes Passwort geschützt werden. Zusätzlich können ab der PGP-Version 6.0 Schlüssel auch in Teile aufgeteilt werden, so dass zu ihrer Nutzung mehrere Personen gemeinsam aktiv werden müssen. Diese Form der Vier-Augen-Kontrolle sollte bei Einsatz von ADKs unbedingt genutzt werden. Als weiterer Schutz kann vorgesehen werden, dass Benutzer jedes Mal gewarnt werden, wenn sie Daten mit einem Schlüssel verschlüsseln, an den ADKs angebunden werden.

Ehe PGP mit Key Recovery eingesetzt wird, sollten die Vor- und Nachteile gegeneinander abgewogen werden. Auf der einen Seite wird zwar einem Datenverlust durch Verlust des Schlüssels vorgebeugt, auf der anderen Seite entsteht ein zentraler Schwachpunkt des Verschlüsselungssystems. Diese Funktion sollte daher nur dann genutzt werden, wenn PGP zur Verschlüsselung gespeicherter Daten eingesetzt wird. Bei einer Nutzung rein für die Kommunikationssicherung kann bei einem Schlüsselverlust auch einfach erneut die E-Mail angefordert werden. Es sollte auch geprüft werden, ob als Alternative die Hinterlegung des Passworts an einer sicheren Stelle in einem geschlossenen Umschlag und die Erstellung von Sicherheitskopien der privaten Schlüsseldateien nicht zu bevorzugen wäre.

Key Reconstruction

Die Version 7 von PGP bietet eine weitere Möglichkeit, Problemen durch verloren gegangene Schlüssel, beispielsweise durch vergessene Passphrase, vorzubeugen. Hierzu wird der Schlüssel in mehrere Teile aufgespalten, überschlüsselt und auf einem Wiederherstellungs-Server abgespeichert. Bei der Hinterlegung legt der Benutzer fünf Frage/Antwort-Kombinationen fest. Mindestens drei der fünf Fragen muss der Benutzer korrekt beantworten, um seinen Schlüssel wiederherstellen zu können.

Bei dieser Funktion besteht die Gefahr, dass Benutzer Fragen festlegen, deren Antworten durch Dritte erraten oder ermittelt werden können, beispielsweise Namen von Verwandten oder Geburtsdaten. Als Folge können u. U. Dritte unberechtigt auf Schlüssel des Benutzers zugreifen. Da sich die Qualität der Frage/Antwort-Kombinationen in der Regel auch nicht überprüfen lässt, sollte diese Funktion nicht genutzt werden. Stattdessen wird empfohlen, eine Sicherheitskopie der privaten Schlüsseldateien auf einem Datenträger anzufertigen und den Datenträger an einem abgesicherten Ort zu verwahren. Auch die zugehörige Passphrase ist in einem geschlossenen Umschlag zu hinterlegen (siehe M 2.22 Hinterlegen des Passwortes ).

Single Sign-On

Unter den Bezeichnungen Single Sign-On und Passphrase Caching bietet PGP ab der Version 7 einen Mechanismus an, die vom Benutzer eingegebene Passphrase zwischenzuspeichern, damit der Benutzer sie nicht bei jeder Aktion neu eingeben muss. Hierdurch besteht die Gefahr, dass unberechtigte Personen mit der Identität des Benutzers Dokumente ver- oder entschlüsseln bzw. digital signieren können, wenn der Benutzer kurzzeitig seinen Arbeitsplatz verlässt.

Falls die Funktion Passphrase Caching von PGP genutzt werden soll, muss daher auf jeden Fall sichergestellt sein, dass der Rechner des Benutzers auch bei kurzzeitigem Verlassen des Arbeitsplatzes unmittelbar gesperrt wird. Dies kann beispielsweise mit der Funktion Arbeitsstation sperren von Windows NT erfolgen, sofern ein starkes Benutzerpasswort vergeben ist, oder mit Hilfe einer Chipkartenlösung zur Benutzer-Authentisierung. In allen anderen Fällen sollte im Dialogfeld PGP Options die Option Do not cache passphrase aktiviert werden.

Prüffragen:

  • Werden hinreichend aktuelle Versionen eingesetzt, wobei die Kompatibilität intern und mit etwaigen Kommunikationspartnern sichergestellt ist?

  • Werden Benutzer für das Produkt einschließlich notwendiger kryptographischer Grundlagen geschult?

  • Wird bei der Schlüsselgenerierung für ausreichend lange Schlüssel und Passphrases gesorgt?

  • Gibt es Regelungen zur Aufbewahrung von Schlüsseln gegen deren Verlust und Kompromittierung?

  • Werden öffentliche Schlüssel nur dann zertifiziert, wenn diese zuvor persönlich übergeben oder der Fingerprint sicher verifiziert wurde?

  • Wird Passphrase Caching unterbunden oder zumindest durch begleitende Maßnahmen abgesichert?

Stand: 13. EL Stand 2013