Warum vertrauen wir Zertifizierungsstellen?
Im August 2011 berichtet ein iranischer Internetnutzer von einer Browser-Warnung, wenn er sich zu seinem Gmail-Konto einloggen will. Der Nutzer des Chrome-Browsers wendet sich damit in einem Forum direkt an Google und fragt, ob es sich um einen MITM-Angriff auf die Verschlüsselung handeln könnte. Google untersucht daraufhin die Situation und bestätigt seine Vermutung: es gab Angriffe auf die Verschlüsselung der Kommunikation, wovon primär Internetnutzer im Iran betroffen waren. Die Zertifizierungsstelle DigiNotar habe unter anderem für google.com nicht autorisierte Zertifikate ausgestellt, die von Browsern anstandslos akzeptiert wurden. Allein der kurz vor dem Vorfall veröffentlichten Sicherheitsfunktion des Chrome-Browsers sei es zu verdanken, dass das missbräuchlich verwendete Zertifikat bemerkt wurde. Die neue Sicherheitsfunktion prüfe für den Google E-Mail-Dienst Gmail nicht nur, ob das Zertifikat gültig ist, sondern auch ob es von einer autorisierten Zertifizierungsstelle ausgestellt wurde.
In Chrome und anderen Browsern wurden sofort alle Zertifikate gesperrt, die von DigiNotar ausgestellt wurden. Die Zertifizierungsstelle, die seit Juli 2011 von den nicht autorisierten Zertifikaten für Domains von Google, dem CIA, dem Mossad, dem MI6 und anderen wusste, wurde unter die Aufsicht niederländischer Behörden gestellt und es wurde ein Ermittlungsverfahren eingeleitet.
Weshalb wir auf Zertifizierungsstellen angewiesen sind
Der Fall von DigiNotar wiegt schwer und lässt die Frage aufkommen, weshalb es überhaupt Zertifizierungsstellen gibt. Um dies zu verstehen, betrachten wir zunächst verschlüsselte Kommunikation im Allgemeinen. Möchten die zwei Kommunikationspartner Alice und Bob sicher miteinander kommunizieren, müssen sie sich zunächst auf ein Verschlüsselungsverfahren einigen, das nach heutigen Maßstäben als sicher erachtet wird. Das bedeutet, dass keine Wege bekannt sein dürfen, durch die die Verschlüsselung in akzeptabler Zeit gebrochen werden kann. Anschließend müssen sich beide auf einen geheimen Schlüssel (beispielsweise ein Kennwort aus Buchstaben und Zahlen) einigen. Hierfür existieren Verfahren, wodurch Alice und Bob einen gemeinsamen Schlüssel vereinbaren können, ohne sich selbst persönlich treffen oder den Schlüssel durch einen Boten austauschen lassen zu müssen. Mit dem Schlüssel, den Alice durch ein solches Verfahren erhalten hat, könnte sie Bob nun eine verschlüsselte Information zusenden. Doch eine Frage bleibt bei diesen Verfahren offen: stammt der Schlüssel tatsächlich von Bob?
Abbildung 1 zeigt eine Situation, in der Schlüssel ausgetauscht werden. Alice erhält einen Schlüssel und geht davon aus, dass dieser von Bob stammt (und umgekehrt aus der Sicht von Bob). Tatsächlich jedoch klinkt sich der Angreifer Mallory in die Kommunikation ein und sendet Alice und Bob jeweils seinen Schlüssel. Alice und Bob haben keine Möglichkeit mit Sicherheit festzustellen, ob sie den richtigen Schlüssel besitzen.
Dieses Authentizitätsproblem kann durch vertrauenswürdige Zertifizierungsstellen gelöst werden, denen alle Kommunikationsteilnehmer vertrauen. Jeder Teilnehmer lässt seinen Schlüssel von der Zertifizierungsstelle signieren. Den Schlüssel und die Signatur versenden die Teilnehmer als Zertifikat an die Gegenstelle. Diese kann die Signatur prüfen und die Echtheit des Schlüssels bestätigen. Abbildung 2 zeigt diese Situation für Alice und Bob: Bob lässt seinen Schlüssel von der Zertifizierungsstelle signieren und sendet ihn Alice. Alice vertraut auf die Prüfung durch die Zertifizierungsstelle; sie kann sich durch die Signatur sicher sein, dass sie Bobs Schlüssel erhalten hat. Mallory kann sich mit seinem Schlüssel nicht als Bob ausgeben, da er hierfür keine gültiges Zertifikat vorweisen kann.
Im World Wide Web findet der Austausch von Schlüsseln für eine sichere Kommunikation ähnlich statt. Ein Webseitenbetreiber weist für seine Domain, beispielsweise example.com, den Besitz gegenüber der Zertifizierungsstelle nach. Diese stellt ihm dafür ein Zertifikat aus, das der Webseitenbetreiber für die verschlüsselte Kommunikation mit seinen Benutzern verwendet. Da die Benutzer (vielmehr ihre Browser) allen gültigen Zertifikaten der Zertifizierungsstelle vertrauen, können sie die Echtheit des Schlüssels bestätigen und ihn verwenden.
Zertifizierungsstellen sind eine wesentliche Komponente in diesem Vertrauensmodell. Von ihnen gibt es weltweit mehrere Dutzend. Nutzer des Browsers Firefox beispielsweise vertrauen implizit 92 Zertifizierungsstellen (Stand 20.03.2017). Doch wie im Beispiel von DigiNotar eingangs erwähnt, gibt es Zertifizierungsstellen, die – gewollt oder ungewollt – nicht autorisierte Zertifikate ausstellen. Der Fall von DigiNotar ist nämlich kein Einzelfall; andere Beispiele sind DigiCert (2011), das National Informatics Centre of India (2014), Comodo (2015), Thawte (2015), Symantec (2017), WoSign (diverse) et cetera. Die Gründe für das Ausstellen nicht autorisierter Zertifikate sind vielfältig. Sie reichen von einer Missachtung von Standards über gehackte Zertifizierungsstellen bis hin zu Missbrauch durch Geheimdienste oder Regierungen.
Kommt ein Angreifer in den Besitz eines nicht autorisierten aber gültigen Zertifikats, sind verschlüsselte Verbindungen nicht mehr sicher. Der Angreifer würde sich mit einem Man-in-the-Middle-Angriff zwischen zwei Kommunikationspartner setzen und das gültige Zertifikat präsentieren. Dieses wird akzeptiert, da der Client Zertifikaten der nicht mehr vertrauenswürdigen Zertifizierungsstelle vertraut. Die Kommunikation wird abgehört.
Absicherung gegen falsche Zertifikate
Das Problem mit Zertifikaten ist nicht neu. Aus diesem Grund wurden in der Vergangenheit mehrere Möglichkeiten zur Absicherung gegen falsche Zertifikate vorgeschlagen. Diese können in die folgenden vier Klassen eingeteilt werden:
- DNS-basierte Ansätze
- Certification Authority Authorization (CAA)
- DNS-based Authentication of Named Entities (DANE)
- Notar-basierte Ansätze
- Perspectives
- Convergence
- Pinning-basierte Ansätze
- HTTP Public Key Pinning (HPKP)
- Trust Assertions for Certificate Keys (TACK)
- DNSChain
- Transparenz-basierte Ansätze
- Certificate Transparency (CT)
- Sovereign Keys
Die aufgezählten Verfahren werden in nachfolgenden Artikeln beschrieben und miteinander verglichen.
Blindes Vertrauen gegenüber Zertifizierungsstellen?!
In diesem Beitrag wurde erklärt, welche Rolle Zertifizierungsstellen für verschlüsselte Kommunikation spielen. Sie bestätigen durch Zertifikate die Authentizität von Schlüsseln. Die Vergangenheit hat jedoch gezeigt, dass auch nicht autorisierte Zertifikate ausgestellt wurden und demnach offenbar nicht alle Zertifizierungsstellen vertrauenswürdig sind. Ein blindes Vertrauen gegenüber diesen Stellen wäre also falsch, weshalb neue Verfahren entwickelt werden, um das System zu verbessern. Diese Verfahren werden in zukünftigen Beiträgen im aramido-Blog vorgestellt und diskutiert.
