Public Key Infrastructure

Public-Key-Infrastrukturen

Public-Key-Infrastrukturen versuchen das Problem zu lösen, zu überprüfen, ob ein öffentlicher Schlüssel zu einer bestimmten Einheit gehört, um Man-in-the-Middle-Angriffe zu verhindern.

Ansätze

1. Certificate Authorities
2. Web of Trust

Zertifizierungsstellen (CA)

• signieren die Zertifikate von Endteilnehmern und verknüpfen so eine Art von Identität (z. B. einen Domänennamen oder eine E-Mail-Adresse) mit einem öffentlichen Schlüssel.
• CAs werden mit TLS- und S/MIME-Zertifikaten verwendet, und das CA-System hat eine lange Liste möglicher und tatsächlicher Probleme, die im Abschnitt Hardening PKI und (Durumeric, Kasten, Bailey, & Halderman, 2013) zusammengefasst sind.

Web of Trust

Das Web of Trust ist ein dezentralisiertes System, bei dem Menschen gegenseitig ihre Schlüssel signieren, so dass die Wahrscheinlichkeit hoch ist, dass es einen "Vertrauenspfad" von einem Schlüssel zum anderen gibt.

• Es wird mit PGP-Schlüsseln verwendet, und obwohl es die meisten Probleme des CA-Systems vermeidet, ist es umständlicher.

Alternativen

Als Alternativen zu diesen öffentlichen Systemen gibt es zwei weitere Möglichkeiten

• Die Verwendung einer privaten Zertifizierungsstelle und das manuelle Vertrauen in Schlüssel (wie es bei SSH-Schlüsseln oder manuell vertrauenswürdigen Schlüsseln in Webbrowsern verwendet wird).
  • Der erste Teil dieses Abschnitts befasst sich damit, wie man ein Zertifikat im CA-System erhält.
• Der zweite Teil enthält Empfehlungen, wie Sie die Sicherheit Ihrer PKI verbessern können.

Zertifizierungsstellen

Um ein Zertifikat zu erhalten, können Sie eine externe Zertifizierungsstelle finden, die bereit ist, ein Zertifikat für Sie auszustellen, Ihre eigene Zertifizierungsstelle betreiben oder selbst signierte Zertifikate verwenden.

• Wie immer gibt es Vor- und Nachteile für jede dieser Optionen; es muss ein Gleichgewicht zwischen Sicherheit und Benutzerfreundlichkeit gefunden werden.

Zertifikate von einer externen Zertifizierungsstelle

Es gibt eine ziemlich große Anzahl kommerzieller Zertifizierungsstellen, die gegen Geld Zertifikate ausstellen.

• Einige der bekanntesten kommerziellen CAs sind Verisign, GoDaddy und Teletrust.
• Es gibt jedoch auch CAs, die kostenlose Zertifikate anbieten.
• Die bekanntesten Beispiele sind StartSSL, ein Unternehmen, das einige Arten von Zertifikaten kostenlos anbietet, und CAcert, eine gemeinnützige, ehrenamtlich tätige Organisation, die für die Ausstellung von Zertifikaten keinerlei Gebühren erhebt.
• Im Forschungs- und Bildungsbereich schließlich gibt es eine Reihe von Zertifizierungsstellen, die in der Regel in der Hochschulgemeinschaft bekannt und akzeptiert sind.

Eine große Anzahl von Zertifizierungsstellen ist in den Vertrauensspeichern von Client-Software oder Betriebssystemen vorinstalliert; je nach Anwendung müssen Sie Ihre Zertifizierungsstelle entsprechend auswählen oder über einen Mechanismus verfügen, um das Stammzertifikat der gewählten Zertifizierungsstelle an die Clients zu verteilen. Wenn Sie ein Zertifikat bei einer CA beantragen, müssen Sie das Schlüsselpaar unbedingt selbst erzeugen.

• Vor allem der private Schlüssel sollte der CA niemals bekannt sein.
• Wenn eine Zertifizierungsstelle anbietet, das Schlüsselpaar für Sie zu erzeugen, sollten Sie dieser Zertifizierungsstelle nicht vertrauen.

Die Erzeugung eines Schlüsselpaares und einer Zertifikatsanforderung kann mit einer Reihe von Werkzeugen durchgeführt werden.

• Auf Unix-ähnlichen Systemen ist es wahrscheinlich, dass Ihnen die OpenSSL-Suite zur Verfügung steht.

In diesem Fall können Sie einen privaten Schlüssel und eine entsprechende Zertifikatsanforderung wie folgt erzeugen:

$ openssl req -new -nodes -keyout <servername>.key -out <servername>.csr -newkey rsa:<keysize> -sha256
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Bavaria
Locality Name (eg, city) []:Munich
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Example
Organizational Unit Name (eg, section) []:Example Section
Common Name (e.g. server FQDN or YOUR name) []:example.com
Email Address []:admin@example.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Setting Up Your Own Certificate Authority

In manchen Situationen ist es ratsam, eine eigene Zertifizierungsstelle zu betreiben.

• Ob dies eine gute Idee ist, hängt von den genauen Umständen ab.
• Im Allgemeinen gilt: Je zentralisierter die Kontrolle der Systeme in Ihrer Umgebung ist, desto weniger Aufwand müssen Sie für die Einrichtung Ihrer eigenen Zertifizierungsstelle betreiben.
• Andererseits maximiert der Betrieb einer eigenen Zertifizierungsstelle das Vertrauensniveau, das Sie erreichen können, da externe Abhängigkeiten minimiert werden.

Wiederum unter Verwendung von OpenSSL als Beispiel, können Sie Ihre eigene CA mit den folgenden Befehlen auf einem Debian-System einrichten:

$ cd /usr/lib/ssl/misc
$ sudo ./CA.pl -newca
Answer the questions according to your setup. 

• Now that you have configured your basic settings and issued a new root certificate, you can issue new certificates as follows:

$ cd /usr/lib/ssl/misc
$ sudo ./CA.pl -newreq

Alternativ gibt es Software wie TinyCA, die als "Wrapper" um OpenSSL herum agiert und versucht, das Leben einfacher zu machen.

Creating a Self-Signed Certificate

Wenn das gewünschte Vertrauensniveau sehr hoch und die Anzahl der beteiligten Systeme begrenzt ist, kann der einfachste Weg, eine sichere Umgebung einzurichten, die Verwendung selbst signierter Zertifikate sein.

• Ein selbstsigniertes Zertifikat wird nicht von einer Zertifizierungsstelle ausgestellt, sondern von der Einrichtung, für die es ausgestellt wurde, signiert.
• Auf diese Weise entfällt der organisatorische Aufwand, der mit dem Betrieb einer Zertifizierungsstelle verbunden ist, auf Kosten der Notwendigkeit, alle Vertrauensbeziehungen zwischen Entitäten manuell herzustellen.

Mit OpenSSL können Sie ein zuvor erstelltes Zertifikat mit diesem Befehl selbst signieren:

$ openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095

Sie können auch ein selbstsigniertes Zertifikat mit nur einem Befehl erstellen:

$ openssl req -new -x509 -keyout privkey.pem -out cacert.pem -days 1095 -nodes -newkey rsa:<keysize> -sha256

Das daraus resultierende Zertifikat wird standardmäßig von niemandem als vertrauenswürdig eingestuft. Um also nützlich zu sein, muss das Zertifikat allen Parteien, die damit in Berührung kommen könnten, a priori bekannt gemacht werden.

Härtung der PKI

In den letzten Jahren wurden mehrere Zertifizierungsstellen von Angreifern kompromittiert, um an vertrauenswürdige Zertifikate für böswillige Aktivitäten heranzukommen.

• Im Jahr 2011 wurde die niederländische Zertifizierungsstelle Diginotar gehackt und alle Zertifikate wurden widerrufen (Elinor Mills, 2011).
• Kürzlich fand Google auf sie ausgestellte Zertifikate, die von dem Unternehmen nicht verwendet wurden (Damon Poeter, 2011).
• Das Konzept der PKI hängt stark von der Sicherheit der Zertifizierungsstellen ab.
• Wenn diese kompromittiert werden, fällt das gesamte PKI-System aus.
• Einige Zertifizierungsstellen neigen dazu, fälschlicherweise Zertifikate auszustellen, die für eine andere Aufgabe als die von der Zertifizierungsstelle vorgesehene bestimmt sind (Adam Langley, et. al., 2013).

Daher wurden verschiedene Sicherheitsverbesserungen von verschiedenen Organisationen und Anbietern eingeführt (H. Tschofenig und E. Lear, 2013).

• Derzeit werden zwei Methoden verwendet, DANE (Hoffman & Schlyter, 2012) und Certificate Pinning (C. Evans und C. Palmer, 2013).
• Google hat kürzlich ein neues System zur Erkennung bösartiger CAs und Zertifikate namens Certificate Transparency (Adam Langley, Ben Laurie, Emilia Kasper, 2013) vorgeschlagen.
• Darüber hinaus beschreibt RFC 6844 Certification Authorization Records, einen Mechanismus, mit dem Inhaber von Domänennamen angeben können, welche Zertifizierungsstellen berechtigt sind, Zertifikate für ihre Domäne auszustellen.

Certification Authorization Records

RFC 6844 beschreibt Certification Authorization Records, einen Mechanismus, mit dem Inhaber von Domänennamen angeben können, welche Zertifizierungsstellen berechtigt sind, Zertifikate für ihre Domäne auszustellen. Wenn ein CAA-Datensatz für eine bestimmte Domäne definiert ist, gibt er an, dass der Domäneninhaber die Zertifizierungsstellen auffordert, jede Anfrage anhand des CAA-Datensatzes zu validieren.

• Wenn der Zertifikatsaussteller nicht im CAA-Eintrag aufgeführt ist, sollte er das Zertifikat nicht ausstellen.

Der RFC erlaubt auch Zertifikatsauswertern, ein ausgestelltes Zertifikat anhand des CAA-Datensatzes zu prüfen, wobei jedoch Vorsicht geboten ist, da sich der CAA-Datensatz während der Lebensdauer eines Zertifikats ändern kann, ohne dessen Gültigkeit zu beeinträchtigen. CAA unterstützt auch einen iodef-Eigenschaftstyp, der von einer Zertifizierungsstelle angefordert werden kann, um Anträge auf Ausstellung von Zertifikaten zu melden, die nicht mit der Zertifikatsrichtlinie des Ausstellers übereinstimmen.

Configuration of CAA records

BIND unterstützt CAA-Records ab Version 9.9.6. Ein CAA-Eintrag kann konfiguriert werden, indem er zur Zonendatei hinzugefügt wird:

$ORIGIN example.com
      CAA 0 issue "ca1.example"
      CAA 0 iodef "mailto:security@example.com"

Wenn Ihr Unternehmen mehrere CAs verwendet, können Sie mehrere Datensätze konfigurieren:

     CAA 0 issue "ca1.example"
     CAA 0 issue "ca2.example"

"ca1.example" und "ca2.example" sind eindeutige Bezeichner für die CA, die Sie verwenden möchten.

• Diese Zeichenfolgen können von Ihrer Zertifizierungsstelle bezogen werden und sind in der Regel die Top-Level-Domain.
• Ein Beispiel ist "letsencrypt.org" für die von der Internet Security Research Group betriebene Let's Encrypt CA.Knot-DNS unterstützt CAA-Einträge ab Version 2.2.0.

Validation of CAA records

Sobald ein CAA-Datensatz bereitgestellt wurde, kann er mit der folgenden Abfrage validiert werden:

$ dig CAA google.com
; <<>> DiG 9.10.3-P4-Debian <<>> CAA google.com
;; ANSWER SECTION:
google.com.          3600 IN   CAA  0 issue "symantec.com"

Bei älteren Versionen von Dig, die keine CAA-Datensätze unterstützen, können Sie die Datensatzart manuell abfragen:

$ dig +short -t TYPE257 google.com
\# 19 0005697373756573796D616E7465632E636F6D

Weblinks

1. https://bettercrypto.org/