Verschlüsseln, signieren, vertrauen
Grundwissen: asymmetrische Kryptografie in der Praxis, Teil 1
S/MIME-Nutzer brauchen sie genau wie Admins: Schlüsselpaare, Zertifikate und Signierungsanforderungen. Public-Key-Infrastruktur ist elementar für die Sicherheit im Internet, und doch geraten die Details gern in Vergessenheit. Zeit für eine ausführliche Übersicht.
QWACs (Qualified Website Authentication Certificates), eine neue Gattung von Zertifikaten, die Politiker in der EU gerade per Gesetz in Browsern erzwingen wollen, waren der Hauptdarsteller unserer Titelgeschichte der Ausgabe 29/2023 [1]. In diesem Zusammenhang haben wir uns genauer angesehen, wo Browser und Betriebssysteme ihre Stammzertifikate verwalten und wie Sie einzelnen Zertifikaten gezielt misstrauen können. Viele Details konnten wir hierbei nur anreißen, weil man zu Public-Key-Infrastruktur ganze Bücherregale füllen kann. Und auch diese Artikelreihe erhebt keinen Anspruch auf Vollständigkeit. Sie versucht vielmehr, den Umgang mit asymmetrischer Kryptografie – um die geht es hier – anhand von typischen Szenarien zu beschreiben und auf dem Weg wichtiges theoretisches Wissen zu liefern. Teil 1 befasst sich mit öffentlichen und privaten Schlüsseln, in einer der nächsten Ausgaben werden daraus Zertifikate.
Werkzeugkasten
Das populärste Werkzeug für den Umgang mit privaten und öffentlichen Schlüsseln, mit Zertifikaten und Zertifizierungsanfragen, ist der Kommandozeilenbefehl openssl auf der Kommandozeile. Aber nicht überall, wo sich openssl meldet, muss auch die Bibliothek OpenSSL drin stecken. Im Jahr 2014, nachdem die schwere OpenSSL-Sicherheitslücke Heartbleed publik wurde, entstand unter anderem der Fork LibreSSL mit dem Anspruch, den Code mal gründlich aufzuräumen und Fehler zu beseitigen. Um die Softwarebibliothek soll es im Folgenden aber nicht gehen, sondern um den Kommandozeilenbefehl, der auch dann openssl heißt, wenn im Hintergrund LibreSSL arbeitet. Mit openssl version erfahren Sie, welche Bibliothek installiert ist.