IT-Sicherheit für Privatanwender: Grundsätze: Was ist Verschlüsselung?

Hoch zum Abschnitt Grundsätze

In der IT-Sicherheit stößt man oft auf den Begriff „Verschlüsselung“. Verschlüsselung zur Gewährleistung des Schutzziels Vertraulichkeit gab es allerdings schon vor mehreren tausend Jahren. In der Praxis verwendet man verschiedene Algorithmen zusammen als Protokoll, um mehrere Schutzziele zu erfüllen und sonst auftretende Schwächen zu beseitigen.

Die „Zutaten“ für eine Verschlüsselung

Um etwas zu verschlüsseln, hat man immer identische „Zutaten“:

• Klartext: Nachricht, die verschlüsselt werden soll
• Schlüssel (Art variiert nach Verfahren, siehe unten)
• Algorithmus: Anleitung, wie der Klartext mit dem Schlüssel verschlüsselt werden soll

Hier ergeben sich einige Probleme: Wie kann der Schlüssel über das unsichere Internet ausgetauscht werden? Was ist, wenn der Algorithmus gebrochen wird? Wie kann ich überhaupt jemandem vertrauen, den ich nicht kenne?

Verschlüsselung im Laufe der Zeit

Schematische Darstellung einer Verschiebechiffre mit Verschiebung um drei Buchstaben

Ein bekanntes Beispiel ist die sogenannte Caesar-Verschlüsselung. Hierbei wird jeder Buchstabe eines Alphabets auf einen anderen abgebildet. Dies geschieht, in dem man alle Buchstaben um x Stellen nach rechts verschiebt. Dabei handelt es sich um ein symmetrisches Verschlüsselungsverfahren. Alle symmetrischen Verschlüsselungsverfahren haben die Gemeinsamkeit, dass Sender und Empfänger einen identischen geheimen Schlüssel nutzen, um die Nachricht zu ver- oder zu entschlüsseln.

Unabhängig davon, dass dieses einfache Verfahren heutzutage schnell geknackt werden kann, lässt sich ein wesentlicher Nachteil erkennen, der auf alle symmetrischen Verfahren zutrifft: Person A (Alice) und Person B (Bob) müssen über einen sicheren Kanal den gemeinsamen geheimen Schlüssel ausgetauscht haben. Wenn der Schlüssel beim Schlüsselaustausch einem Angreifer bekannt wird, ist die Verschlüsselung nutzlos. Gerade das Internet ist aber kein „sicherer Kanal“.

Seit vergleichsweise sehr kurzer Zeit gibt es deshalb asymmetrische Verschlüsselungsverfahren, die das Problem des Schlüsselaustausches lösen: Alice und Bob haben jeweils einen privaten geheimen Schlüssel und einen öffentlichen Schlüssel. Der öffentliche Schlüssel kann beliebig verteilt werden. Er wird vom Sender der Nachricht genutzt, um an den Eigentümer des dazugehörigen privaten Schlüssels eine damit verschlüsselte Nachricht zu senden.

Verschlüsselung mit öffentlichem Schlüssel und Entschlüsselung mit privatem Schlüssel

Asymmetrische Verschlüsselung ist allerdings im Vergleich mit symmetrischer Verschlüsselung sehr langsam. Deshalb war es einige Zeit üblich, einen symmetrischen Schlüssel mit einem asymmetrischen Verfahren zu verschlüsseln, diesem dem Kommunikationspartner zukommen zu lassen und anschließend symmetrisch verschlüsselt zu kommunizieren.

Spätestens seit Snowden ist ein Problem offensichtlich geworden: Angreifer können sämtliche Kommunikation aufzeichnen. Irgendwann kann es passieren, dass das asymmetrische Verschlüsselungsverfahren gebrochen wird, der Angreifer den privaten Schlüssel berechnen kann oder aber diesen erhält. Hier sind viele Szenarien vorstellbar: Private Schlüssel können durch Implementierungsfehler (Heartbleed) oder Benutzerfehler (Adobe veröffentlichte versehentlich im September 2017 einen privaten GnuPG-Schlüssel) bekannt werden.

Die Lösung ist Perfect Forward Secrecy. Hierbei werden die vereinbarten symmetrischen Schlüssel zu definierten Zeitpunkten ausgewechselt, sodass ein Angreifer bei Bekanntwerden des Langzeitschlüssels nur die Nachrichten entschlüsseln kann, die mit dem aktuellen symmetrischen Schlüssel verschlüsselt worden sind. Diese symmetrischen Schlüssel sind dabei nicht aus einem Langzeitschlüssel ableitbar.

Beispiel: GnuPG bei E-Mails

Mit GnuPG können Privatanwender verschlüsselte und/oder signierte E-Mails austauschen. Grundsätzlich erzeugen Gesprächspartner – wie bei einem asymmetrischen Verfahren üblich – einen privaten und einen öffentlichen Schlüssel. Wenn Alice an Bob eine E-Mail senden will, nutzt sie seinen öffentlichen Schlüssel, um diese zu verschlüsseln und zu signieren. Nur Bob kann mit seinem privaten Schlüssel die Nachricht wieder entschlüsseln.

GnuPG unterstützt allerdings keine Perfect Forward Secrecy. Gerade die zeitlich unbefristete Nutzung desselben Schlüsselpaars kann langfristig zum Bekanntwerden des gesamten Kommunikationsinhaltes führen.

Beispiel: TLS bei Internetseiten

Moderne TLS-Konfigurationen unterstützen Perfect Forward Secrecy, da asymmetrische Verfahren zum Schlüsselaustausch (bspw. Diffie-Hellman-Schlüsselaustausch) und nicht zur Verschlüsselung verwendet werden.

Man-in-the-Middle

Illustration eines Man-in-the-Middle

In beiden Beispielen kann sich ein Man-in-the-Middle in die Verbindung einbringen. Alice will mit Bob kommunizieren, kommuniziert aber mit dem Angreifer (Mallory). Bob denkt wiederum, dass er mit Alice kommuniziert, kommuniziert aber eigentlich auch mit Mallory.

Um dies zu unterbinden, muss bei einem asymmetrischen Verfahren immer überprüft werden, ob ein öffentlicher Schlüssel wirklich dem mutmaßlichen Eigentümer gehört. Bei GnuPG muss dies manuell erfolgen, indem Alice und Bob über einen anderen sicheren Kanal die Fingerabdrucke ihrer öffentlichen Schlüssel vergleichen.

Digitale Zertifikate

Bei TLS ist dieses Verfahren etwas komplizierter. Hier werden digitale Zertifikate genutzt, deren Funktion sich leichter mit einem Alltagsbeispiel nachvollziehen lässt:

Alice ist Verkäuferin in einem Supermarkt. Bob will Alkohol kaufen und muss sich gegenüber Alice ausweisen. Alice vertraut Bob nicht, aber dem Ausweisdokument. Das Ausweisdokument bekam Bob von der zuständigen Behörde, die dieses im Namen eines Staates ausgestellt hat. Staaten vertrauen sich gegenseitig, damit Ausweisdokumente wie Reisepässe in anderen Staaten akzeptiert werden.

Genauso ist es bei digitalen Zertifikaten: Bob generiert ein Schlüsselpaar. Eine Zertifizierungsstelle (certificate authority, CA) überprüft die Identität von Bob und beglaubigt den öffentlichen Schlüssel mit der eigenen Signatur auf einem Zertifikat. (Im Realfall gibt es mehrere Abstufungen der CAs.) Wenn Alice die Webseite von Bob aufruft, muss sie der Zertifizierungsstelle vertrauen. Dies geschieht, indem öffentliche Schlüssel vertrauenswürdiger Zertifizierungsstellen standardmäßig in Webbrowsern und Betriebssystemen hinterlegt werden.

Anschließend erfolgt der Schlüsselaustausch, bei dem Alice anhand signierter Parameter überprüfen kann, ob diese wirklich von Bob kamen. (Wobei zu beachten ist, dass Bob als Server umgekehrt nicht ohne Weiteres die Identität von Alice als Client überprüfen kann.)

Replay-Angriffe

In dem eben genannten Szenario kann allerdings der Angreifer während des Schlüsselaustausches Parameter mitlesen (diese sind bekanntlich nur signiert, also im Klartext) und einfach wiederverwenden. Dies nennt man Replay-Angriff, den man sich mit einem weiteren Alltagsbeispiel verdeutlichen kann:

Alice hat ein Auto und eine Garage. Zur Garage gehört eine Fernbedienung, mit der sie das Tor per Knopfdruck öffnen und schließen kann. Dazu sendet die Fernbedienung die Nachricht OPEN an das Tor, damit sich dies öffnet oder CLOSE, damit es sich schließt. Ein Angreifer kann dieses Funksignal aufzeichnen und später einfach selbst das Signal an das Tor senden.

Eine erste Lösung wäre, dass das Tor und die Fernbedienung ein gemeinsames Geheimnis haben und die Fernbedienung einen Hash-Wert bildet: Hash(GEHEIMNIS|ANWEISUNG). Auch dies bleibt für den Replay-Angriff anfällig, da der Angreifer einfach den Hash-Wert aufzeichnet und an das Tor sendet. Er muss das Geheimnis gar nicht kennen.

Eine Lösung ist die Verwendung einer Nonce. Dies ist ein einmaliger Zufallswert. Die Fernbedienung könnte beim Tor nach Knopfdruck eine Nonce anfordern und diese dann ebenfalls in den Hash-Wert einbeziehen: Hash(GEHEIMNIS|ANWEISUNG|NONCE). Da das Tor Geheimnis und Nonce kennt, kann es selbst den Hash-Wert bilden und nachvollziehen. Danach wird die Nonce ungültig. Zeichnet der Angreifer so ein Funksignal auf, kann er dies trotzdem an das Tor senden. Dieses würde allerdings feststellen, dass die Nonce ungültig ist. Das gemeinsame Geheimnis sorgt weiter dafür, dass nicht irgendeine andere Fernbedienung, die das Protokoll beherrscht, das Tor öffnen kann.

In der Praxis sendet bei TLS der Client an den Server eine Nonce, die dieser im Rahmen seiner Antwort mit weiteren Parametern zurücksendet. Umgekehrt erhält der Client vom Server eine Nonce und muss diese ebenfalls in seine Antwort einbeziehen. TLS als Gesamtpaket gewährleistet folglich Vertraulichkeit, Integrität und Authentizität.

Zufälliger Zufall

Da demnach Zufall eine wichtige Rolle für Noncen und auch insgesamt in der Kryptografie spielt, muss dieser vorhanden sein. Computer sind aber nicht für Zufall gebaut worden. Computer sollen Befehle eindeutig ausführen. Man spricht deswegen von Pseudozufall bzw. Pseudozufallszahlen. Generatoren, die solche Zahlen erzeugen und sich für Kryptografie eignen, nennt man CSPRNG. Auch hier gab es in der Vergangenheit Hintertüren, die einem Unbefugten letztendlich die Entschlüsselung von Kommunikation ermöglichen, bspw. bei Dual_EC_DRBG.

Signaturen

Eine Signatur beweist, dass die derjenige, der die Daten signiert hat, Hoheit über einen bestimmten Schlüssel hat.

Sicherheit von Verschlüsselung

Zuletzt muss noch bedacht werden, dass Algorithmen öffentlich bekannt und wohluntersucht sein müssen. Man sollte niemals auf die Idee kommen, selbst kryptografische Verfahren zu entwickeln. Die Stärke der Verschlüsselung hängt im Wesentlichen von der Stärke des verwendeten Schlüssels ab. Die Stärke ergibt sich aus der Schlüssellänge und dem Zufall.

Allerdings werden kryptografische Verfahren mit der Zeit ebenso unsicher (bspw. DES, 3DES, RC4, SHA-1, MD5) und Schlüssellängen zu kurz (nicht mehr sicher sind bspw. 64 Bit bei symmetrischer Verschlüsselung oder 1024 Bit bei asymmetrischer Verschlüsselung).

Als Privatanwender sollte man sich folglich stets über die aktuell empfehlenswerten Schlüssellängen informieren (bspw. bei dem BSI), gängige Open Source Passwortmanager zum Generieren von Passwörtern nutzen und Software aktuell halten. Der letzte Punkt ist besonders wichtig, da (wie bereits vorgestellt) Implementierungsfehler in Software für das Bekanntwerden des privaten Schlüssels sorgen können.

Zusammenfassung

Symmetrische Verschlüsselung (bspw. AES) bedeutet, dass beide Kommunikationspartner einen identischen geheimen Schlüssel haben. Das Hauptproblem ist ein Schlüsselaustausch über unsichere Kanäle. Asymmetrische Verschlüsselung (bspw. RSA) löst das Problem des Schlüsselaustauschs, ist aber wesentlich langsamer, weshalb man beide Verfahren kombinieren müsste.

Da dies aber keine Perfect Forward Secrecy ermöglicht, nutzt man asymmetrische Verfahren zum Schlüsselaustausch (bspw. DH) und signiert die ausgetauschten Parameter mit einem von einer dritten vertrauenswürdigen Stelle beglaubigten Signaturschlüssel (bspw. digitales Zertifikat). Dies schließt Man-in-the-Middle-Angriffe aus. Um Replay-Angriffe zu verhindern, kommen Noncen ins Spiel, die mindestens kryptografisch sicheren Pseudozufall voraussetzen.

In der Praxis werden demnach neben dem eigentlichen Verschlüsselungsverfahren noch Verfahren zum Schlüsselaustausch, Nachweis der Authentizität und Integritätssicherung eingesetzt.

Weiterführende Literatur

• Aumasson: Serious Cryptography – A Practical Introduction to Modern Encryption. ISBN 978-1-59327-826-7, No Starch Press, 2018.
• Paar, Pelzl: Kryptografie verständlich – Ein Lehrbuch für Studierende und Anwender. ISBN 978-3-662-49296-3, Springer Vieweg, 2016.