arrow arrow--cut calendar callback check chevron chevron--large cross cross--large download filter kununu linkedin magnifier mail marker menu minus Flieger phone play plus quote share

Trust me if you can

Untersuchung des hierarchischen Vertrauensmodells

Dieser Beitrag stellt die Frage nach dem Vertrauen – wann vertrauen sich IT-Systeme und wieso?

Konkret wird das hierarchische Vertrauensmodell untersucht, andere Ansätze wie „Web of Trust“ werden nicht berücksichtigt. Dieser Beitrag behandelt X.509 v3 Zertifikate, spezifiziert sind diese Zertifikate und die dazugehörige PKI im Standard X.509, der meist in der Version V3 angewendet wird und in RFCs spezifiziert ist.

Um diesen Blogbeitrag lesen zu können, braucht es aber nicht die Kenntnis der standardisierenden Request for comments (RFC). Grundlegende Prinzipien und Funktionsweisen von Zertifikaten werden in diesem Beitrag erläutert und kryptografische Zusammenhänge stark vereinfacht dargestellt.

Foto von Benjamin Horvat
Benjamin Horvat

Security Consultant

Wozu benutzt man Zertifikate?

X.509v3 Zertifikate werden in der IT eingesetzt, um Vertrauen herzustellen (engl.: Trust). Dabei bedeutet Vertrauen in diesem Kontext lediglich, dass die vorgegebene Identität eines Akteurs prüfbar wird. Dies kann mittels der Verwendung von Zertifikaten und deren Prüfung geleistet werden. Es gibt dazu weitere Möglichkeiten wie z.B. die Nutzung von Shared Secrets, die Abfrage von Passwörtern oder biometrische Methoden. Zertifikate sind aber eine vergleichsweise starke und weit verbreitete Maßnahme. In Kombination mit einer PKI sind sie außerdem flexibel, da sie es ermöglichen, Vertrauen zwischen Akteuren zu etablieren, die sich zuvor nie getroffen haben – und somit auch noch keine Geheimnisse austauschen konnten. Die Abbildung zeigt, wie diese Art der indirekten Vertrauensbeziehung funktioniert. Dabei kennt Bob zwar Alice nicht, vertraut aber der Organisation „Trusted CA (Certificate Authority)“. Alice weist gegenüber Bob durch die Kenntnis des privaten Schlüssels die Eigentümerschaft des Zertifikates nach und die Trusted CA bestätigt Bob erstens die Echtheit des Zertifikates und zweitens (bis zu einem definierten Grad) die Korrektheit der Attribute, die im Zertifikat enthalten sind. In der Folge kann Bob auf die ihm genannte Identität von Alice vertrauen.

Da X.509v3 Zertifikate technologisch auf kryptografischem Schlüsselmaterial basieren, unterstützen sie noch weitere Use Cases, die Herstellung von Trust auf der Basis eines hierarchischen Vertrauensmodelles ist aber ein sehr grundlegender.

Was sind Zertifikate?

Um Zertifikate zu erklären, müssen kurz einige Grundlagen asymmetrischer Kryptografie skizziert werden, wobei die mathematischen Grundlagen an dieser Stelle unberücksichtigt bleiben. Asymmetrische Kryptografie basiert auf einem Schlüsselpaar, das aus einem öffentlichen Schlüssel und einem privaten Schlüssel besteht. Die beiden sind ein Paar, weil ein Plaintext (Klartext), der mit dem einen Schlüssel verschlüsselt wird, eine Chiffre ergibt, die ausschließlich mit dem dazugehörigen anderen Schlüssel entschlüsselt werden kann. Stark verbreitete, zugrunde liegenden Algorithmen sind RSA und ECC (Eliptic Curve Cryptography).

Soll in der Kommunikation zwischen Alice und Bob die Vertraulichkeit eines Geheimnisses geschützt werden, kann Bob dieses Geheimnis mit dem öffentlichen Schlüssel von Alice verschlüsseln. Wenn Alice nun ihren privaten Schlüssel sorgfältig geheim gehalten hat, ist im Prinzip nur sie in der Lage, das Geheimnis zu entschlüsseln. „Im Prinzip“ deshalb, weil es auch für RSA theoretische Angriffsmöglichkeiten gibt, sowie die Gefahr, dass Algorithmen im Zeitverlauf schwach werden können. Aktuell gilt RSA jedoch als starker und sicherer Algorithmus, wenn er richtig konfiguriert und verwendet wird. Wichtig ist in diesem Zusammenhang auch die Länge der verwendeten Schlüssel.

Soll nicht die Vertraulichkeit, sondern die Integrität eines Dokumentes während der Übertragung über ein unsicheres Netz geschützt werden, kommen Signaturen zum Einsatz. Hierzu wird ein Hashwert des zu schützenden Dokumentes durch den signierenden Akteur (Sender) mit seinem privaten Schlüssel verschlüsselt. Der prüfende Akteur (Empfänger) entschlüsselt die Chiffre und erzeugt außerdem einen eigenen Hashwert des Dokumentes. Stimmen beide Werte überein, so ist das Dokument nicht verändert worden. Außerdem hat in diesem Vorgang der Sender nachgewiesen, dass er über den privaten Schlüssel des verwendeten Schlüsselpaares verfügt.

Ein Zertifikat bindet den öffentlichen Schlüssel an eine Identität. Dies geschieht, indem der öffentliche Schlüssel gemeinsam mit ausgewählten Attributen in einem definierten Datenformat gespeichert und durch eine vertrauenswürdige Organsiation elektronisch signiert wird. Diese vertrauenswürdige Organisation weist ihre Identität wiederum mit einem Zertifikat nach. Es ergibt sich eine Zertifikatskette (Certificate Chain).

Für diesen Beitrag soll festgehalten werden, dass in solchen Zertifikatsketten häufig drei Typen von X.509 Zertifikaten vorkommen:

  • End-Entity Zertifikate sind die Blätter im Zertifikatsbaum. Sie sind das letzte Glied der Kette und werden operativ eingesetzt, um z.B. ein Dokument zu signieren oder eine TLS-Kommunikation abzusichern.
  • Intermediate Zertifikate sind CA (Certificate Authority) Zertifikate. Sie dienen dazu, Segmente im Zertifikatsbaum abzubilden und können wiederum Zertifikate ausgeben. Sie sind durch andere CA Zertifikate signiert.
  • Root-CA Zertifikate bilden das erste, oberste Glied einer Zertifikatskette. Entsprechend sind sie durch sich selbst signiert (self-signed). Sie haben den Zweck, weitere Zertifikate zu erzeugen.

Möchte nun der Empfänger in unserem Szenario nicht nur die Integrität der übertragenen Daten prüfen, sondern auch die Authentizität, muss er zuerst die Signatur des Dokumentes mit dem öffentlichen Schlüssel des Zertifikates, das durch den Sender in der Signatur referenziert wird, prüfen. Anschließend kann er die Identitätsdaten aus dem Zertifikat auslesen, das durch den Sender in der Signatur referenziert wird. Nun muss er das verwendete Zertifikat noch prüfen. Dazu sollte er (mindestens und vereinfacht) folgende Schritte durchführen:

  1. Prüfung des Zertifikates auf zeitliche Gültigkeit
  2. Prüfung der Critical Extensions und weiterer Attribute des Zertifikates gemäß Standard
  3. Prüfung des Revocation Status des Zertifikates (z.B. OCSP oder CRL)
  4. Ggf. Prüfung der Aktualität der verwendeten Algorithmen und Schlüssellängen
  5. Prüfung der Signatur des Zertifikates
  6. Prüfung des Vertrauensstatus des Zertifikates. Hierzu wird geprüft, ob das Zertifikat des Senders im eigenen Vertrauensraum enthalten ist. Ist nicht bereits das EE-Zertifikat Teil des eigenen Vertrauensraumes, muss sich die Prüfroutine durch die Zertifikatskette nach oben arbeiten (GOTO 1), bis sie auf ein Zertifikat stößt, dass dem eigenen Vertrauensraum zugeordnet ist.

Für die vollständige Spezifikation einer Certification Path Validation sei wiederum auf den Standard RFC 5280 verwiesen. Die Prüfung des Zertifikates auf die Zugehörigkeit zum eigenen Vertrauensraum ist Gegenstand der nachfolgenden Abschnitte.

Default Truststores

Vertrauen vorkonfiguriert

Anhand der oben erläuterten Zusammenhänge wird klar, dass die Prüfung des Vertrauensraumes grundlegend ist für die Prüfung der Identität eines Kommunikationspartners (Authentizität). Somit stellt der Vertrauensstatus eines Zertifikates auch die Basis für die sichere Kommunikation zwischen Akteuren, z.B. zwischen einem Browser und einer Banking-Website dar.

Wo wird nun dieser wichtige Vertrauensraum definiert?

Es gibt verschiedene Varianten für die Definition des Vertrauensraums. Plattformen wie Java nutzen meist einen sogenannten Truststore. Auch Windows bringt einen Truststore mit, ebenso wie einige Browser. Im Prinzip handelt es sich um eine Liste von CA-Zertifikaten, die per definitionem als vertrauenswürdig erklärt werden.

In unserem Versuchsaufbau wurde über apt-get ein OpenJDK 10.0.2 installiert (2018-07-17). Mit keytool können die Inhalte des Truststores abgefragt werden.

Dazu dient der Befehl

Keytool meldet 134 Einträge im Keystore.

Ein weiteres System im Versuchsaufbau ist eine Windows 10 Installation mit Java in der Version openjdk 11.0.2 2019-01-15. Keytool meldet hier 93 Einträge im Keystore. Offensichtlich kann der Vertrauensraum je nach Installation stark voneinander abweichen. Beiden Installationen gemein ist jedoch die große Anzahl von vertrauenswürdigen CA-Zertifikaten. Auch Microsoft Windows 10 bringt einen Truststore mit einer vorkonfigurierten Liste an CA-Zertifikaten mit.

Als Nutzer einer solchen Default-Konfiguration ist wichtig zu verstehen, dass jedes EE-Zertifikat, welches direkt oder über eine Intermediate-CA auf eine CA dieser Liste zurückgeführt werden kann, dem eigenen Vertrauensraum zugerechnet wird. Dies sind unter Umständen sehr viele. Die Sicherheit der eigenen Anwendung hängt dann maßgeblich davon ab, dass alle diese CA-Zertifikate ihre privaten Schlüssel schützen und außerdem sichere Prozesse umsetzen und starke Algorithmen einsetzen. Die Versuche des Autors zeigen, dass in Truststores häufig Zertifikate zu finden sind, die als Signaturhashalgorithmus SHA1 oder sogar MD5 verwenden.

Was kann ich tun?

Wir haben die große Zahl von CA-Zertifikaten in unseren Truststores als mögliches Sicherheitsproblem erkannt. Ob und wie diese Anzahl eingeschränkt werden kann, hängt vom konkreten Projekt-Setting ab. Sehr häufig ist die Aufgabe nicht, Vertrauen zwischen unbekannten Akteuren herzustellen, sondern die Kommunikation zwischen bereits bekannten Akteuren durch gegenseitige Authentifizierung abzusichern. In diesem Fall gibt es mehrere Möglichkeiten, den Vertrauensraum einzuschränken, indem nur einer einzigen CA oder wenigen CA-Zertifikaten vertraut wird. Die Vorteile liegen auf der Hand: Die Sicherheit der Kommunikation ist nicht mehr abhängig von der Sicherheit und Qualität aller Root-CA-Zertifikate in der Liste der öffentlichen Truststores.

Eine vergleichsweise einfache Möglichkeit dazu ist die Implementierung eines Zertifikats-Pinning. Dazu wird ein Akteur (Host oder Communication Peer) mit einem Zertifikat, einer CA oder (bei Public Key Pinning) einem öffentlichen Schlüssel assoziiert. Die Authentizität von Nachrichten wird nur dann bestätigt, wenn sie mit dem assoziierten Schlüssel nachgewiesen wird. Standardisiert ist nur eine spezielle Form des Pinnings, das http Pinning (RFC 7469). Eine Übersicht zu Pinning Ansätzen bietet OWASP „Certificate and Public Key Pinning“ (https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning)

Als Alternative zu Pinning gibt es die Möglichkeit, einen individuellen Truststore zu erstellen in dem nur die notwendigen und vertrauenswürdigen CA Zertifikate enthalten sind, die für das eigene Szenario benötigt werden. Es muss hierzu verstanden werden, wie die verwendeten Tools funktionieren und wie die Algorithmen zur Zertifikatsprüfung funktionieren.

Die CA-Zertifikate in einem individuell konfigurierten Truststore können sogar durch den Betreiber selbst herausgegeben und verwaltet werden. In diesem Fall muss das Vertrauen gar nicht mehr auf eine dritte Organisation ausgeweitet werden. Der sichere Betrieb einer eigenen CA ist jedoch eine größere Herausforderung. Wer sich für diesen Weg entscheidet, benötigt ein solides Konzept, eine sichere Infrastruktur und sichere Prozesse.

Was muss ich noch wissen?

Der Themenbereich PKI ist komplex, aber sehr relevant innerhalb der IT Security. Es lohnt sich, hier ein tiefergehendes Verständnis für die Standards und deren Implementierungen aufzubauen. Dieser Beitrag bietet dabei nur einen Einblick in einen Teilaspekt von X.509 Zertifikaten. Für weiterführende Informationen als Basis und guter Ausgangspunkt für die weitere Recherche sei auf RFC 5280 verwiesen. Weitere solide Quellen zum Thema sind die Veröffentlichungen des National Institute of Standards and Technology (NIST) und des Bundesamt für Sicherheit in der Informationstechnik (BSI) zum Thema X.509 und PKI. Einen praxisorientierten Zugang bietet die OWASP Foundation mit einigen gut zugänglichen Beiträgen.