Grundwissen Verschlüsselung

Ich unterrichte immer mal wieder. Und sehe natürlich auch fremdes Kursmaterial, Bücher, oder Internetseiten, die mich oft nicht überzeugen. Oft viele Details, wenig Überblick. Also will ich Mal das Thema Verschlüsselung im Überblick beleuchten. Für Details verlinke ich auf Wikipedia. Man weiß nie was morgen dort steht, aber das meiste ist brauchbar, und damit kann ich mir die Wiederholung von Bekanntem ersparen.

• Begriffe
• Verschlüsselungsverfahren
• Schlüsselmanagement
• Zusammenfassung

Begriffe

Es geht schon damit los, dass ganz oft die Bedeutung von Begriffen nicht erklärt wird oder diese geeignet definiert werden. Die deutsche Wikipedia hatte längere Zeit einen Artikel zu Verschlüsselung und einen inzwischen gelöschten zu Verschlüsselungsverfahren. Einen Artikel zu Verschlüsselungsprotokoll gibt es noch, der verlinkt aber nicht mit dem Artikel zu Verschlüsselung. Wie das zusammenhängt erschließt sich also nicht. An vielen Stellen wird auch auf irgendwas mit Kryptographie verwiesen. Schade.

Die folgende Begriffsdefinition muss nicht perfekt sein, aber in meinem Unterricht und meinen Vorträgen hat sie sich als brauchbar herausgestellt. Und weil ich auch Modellierung unterrichte erst einmal ein UML-Klassendiagramm. Die Rechtecke stehen dabei für Begriffe, die Pfeile haben zwar eine Bedeutung, sind aber zunächst nicht so wichtig. Den unteren Bereich des Bilds muss ein Laie nicht unbedingt verstehen, der ITler sollte nicht mehr als die Komplexität darunter verstehen und allenfalls geeignete Verschlüsselungsverfahren, -algorithmen und Schlüssellängen auswählen können, wofür es aber Hilfestellungen von Mozilla in Server-Side-TLS oder dem Bundesamt für Sicherheit in der Informationstechnik (BSI) in TR-02102 gibt.

Die Tonspur zu diesem Diagramm ist dann in etwa: eine Anwendung verwendet Verschlüsselungsverfahren, die wiederum (meist mehrere) kryptographische Algorithmen. Kryptographische Algorithmen sind: Hashfunktion, Zufallszahlen, u.s.w.. Auf Details wie die Unterscheidung von Streamciphers und Blockciphers oder Blockmodes verzichte ich hier.

Auf Basis der Pfeile kann man schon erkennen, dass Digitale Signaturen wiederum eine Hashfunktion und eine asymmetrische Verschlüsselung verwenden.

Weder Verschlüsselungsalgorithmen noch -verfahren sollte man selbst erfinden (Schneiers Gesetz) oder auch nur implementieren (Lehre aus Heartbleed). Und der Geheimhaltung sollen lediglich die Schlüssel, nicht aber die Algorithmen oder Verfahren unterliegen (Kerckhoffs Prinzip) (s.a. Security by Obscurity).

Und mit diesen Hinweisen darf ich auch Ausführungen zu Post-Quanten-Kryptographie zurückstellen. Noch gibt es keine Quantencomputer die hinreichend leistungsfähig sind, aktuelle Schlüssellängen zu brechen, und wir wissen nicht, wann es so weit ist. Dass die NSA oder irgendjemand anderes all unsere Kommunikation speichert um sie später zu entschlüsseln – ich glaube es nicht. Aber natürlich ist es gut, wenn sich Experten heute überlegen, wie Verschlüsselung dann aussehen müsste und uns geeignete neue Algorithmen und Verfahren bereitstellen – die werde ich natürlich einsetzen. Als kritisch betrachte ich nur, wenn digital signierte Daten über einen sehr langen Zeitraum aufbewahrt werden sollen, denn da kann man nicht einfach rückwirkend neu signieren. Artikel mit aktuellen Informationen dazu finden sich z.B. in iX 04/2024.

Auch homomorphe Verschlüsselung sollte man beobachten, aber sie erfordert m.W. noch einen deutlich höheren Rechenaufwand (so z.B. Comprehensive Performance Analysis ofHomomorphic Cryptosystems for Practical Data Processing) als unverschlüsselte Berechnungen.

Verschlüsselungsverfahren

Hat man erst einmal Ordnung in diese untere Ebene gebracht, können wir uns exemplarisch ein paar Verschlüsselungsverfahren ansehen. Natürlich werde ich nicht jedes Verfahren einzeln erläutern sondern auf passende Seiten verlinken.

Bild und Liste sind natürlich unvollständig. Schon wenn ich mit meiner eigenen Infrastruktur vergleiche fehlen einige Verfahren, aber für einen Überblick soll es reichen.

Den Begriff hybride Verschlüsselung oder ähnliches verwende ich sehr ungern. Die meisten hybriden Verfahren verwenden nämlich auch andere kryptographische Algorithmen als nur Verschlüsselung. Auch unterscheide ich nicht zwischen Verschlüsselungs- und Authentifizierungsverfahren, denn auch das tritt oft in Kombination auf. Bei PGP nicht explizit, aber nur ein richtiger Empfänger kennt seinen privaten Schlüssel und kann damit den zufällig gewählten Schlüssel für die symmetrische Verschlüsselung ermitteln. Bei TLS erfolgt Authentifizierung dadurch, dass der Server (z.B. eine Webseite) ein Zertifikat liefert, dieses vom Client (z.B. einem Browser) nach RFC 5280 geprüft wird, und außerdem der Server beweist, dass er den privaten Schlüssel hat. Bei DNSSEC dadurch, dass die Signatur der Information mit dem öffentlichen Schlüssel des zuständigen DNS-Servers geprüft wird. Bis Snowden hat man sogar relativ strikt argumentiert, Verschlüsselung ohne Authentifizierung bringt nichts, seitdem sagt man besser mit dem falschen verschlüsselt kommunizieren als alle mitlesen lassen. Aber nur eine authentifizierte und verschlüsselte Verbindung stellt sicher, dass ich mit dem richtigen vertraulich kommuniziere. Daher empfehle ich auch in Digitale Selbstverteidigung immer auf Verschlüsselung und Authentifizierung zu achten. Über die Unzulänglichkeit des Grundschutzes zum Thema Verschlüsselung und Authentifizierung habe ich mich schon in Bundesamt für (Un)Sicherheit ausgelassen.

Wie Bild und Erläuterungen andeuten können Verfahren durchaus kombiniert werden. Eine PGP-verschlüsselte Email kann über eine TLS-verschlüsselte Verbindung übertragen werden, wobei der sendende Server dann per DKIM und der empfangende Server per DANE oder MTA-STS authentifiziert werden kann. Dazu mehr in Sichere Kommunikation bei Email.

Schlüsselmanagement

Verschlüsselung ohne Schlüsselmanagement – das geht nicht. Auch wenn der Landesbeauftragte für den Datenschutz und die Informationsfreiheit Baden-Württemberg im Beschwerdeverfahren zur Verschlüsselung von Corona-Schnelltestergebnissen mit dem Geburtsdatum schreibt:

Dem muss ich widersprechen: zwar ist es für die Sicherheit nicht zwingend erforderlich öffentliche Schlüssel geheimzuhalten, aber zumindest Ihre Authentizität und Integrität muss gewährleistet werden. Der Abruf von Schlüsseldaten sollte meiner Meinung nach darüberhinaus auch verschlüsselt stattfinden (z.B. mittels DoT), weil sonst Kommunikationsmetadaten sichtbar werden (leaken). Zumindest was die Authentizität der Schlüssel angeht, verlangt das auch die Datenschutzkonferenz:

Leider ist eine Authentifizierung des Servers bei Web Key Directory (WKD) weder vorgeschrieben noch von gnupg implementiert, die zitierte Anforderung 3 wird also nicht erfüllt. Anforderung 4 wäre dann organisatorisch zu erfüllen, und ich kenne niemanden der das konsequent macht. Man könnte RFC 7929 und damit DNSSEC/DANE verwenden, aber ich kenne niemanden der RFC 7929 verwendet.

Das zeigt zumindest Mal, dass sicheres Schlüsselmanagement nicht ganz einfach zu verstehen und umzusetzen ist.

Die Edition 2023 des Grundschutzkompendium fordert:

In A1 ist nicht wirklich klar, ob es – im Sinne meiner Begriffsdefinition – um Verschlüsselungsalgorithmen oder um Verschlüsselungsverfahren geht. Ich bevorzuge es, nach Anwendungsfall und Verschlüsselungsverfahren vorzugehen – aber dann müssten die entsprechenden Hinweise im Kompendium eigentlich in ganz anderen, auch den in Abschnitt 1.3 referenzierten Kapiteln stehen. Ich darf vermuten, dass das BSI aus diesem Grund auch nicht die Frage beantwortet, auf was sich ein Schlüssel eigentlich bezieht. Bei X.509 Zertifikaten habe ich oben geschrieben, dass sie eine Identität mit dem zugehörigen öffentlichen Schlüssel verknüpfen. Das kann eine Webseite oder ein anderer Dienst, ein System oder Gerät, eine Einrichtung oder auch eine Person sein.

Leider nirgends ausdrücklich erwähnt oder verboten sind Pre-shared Keys oder geteilte Geheimnisse. Das ist deswegen wichtig weil der in A4 geforderte Austausch bei geteilten Geheimnissen nahezu zwangsläufig zu einer zumindest kurzzeitigen Betriebsunterbrechung (Downtime) führt, weil es unmöglich ist den Schlüssel bei allen Teilnehmern gleichzeitig zu ändern. Das gilt auch für Schlüssel bei ECC, denn bei denen wird der öffentliche Schlüssel aus dem privaten berechnet, die Änderung des privaten Schlüssels ändert also gleichzeitig den öffentlichen Schlüssel. Davon ist dann z.B. WireGuard betroffen. Da muss man sich dann überlegen ob man wartet bis ein Schlüssel kompromittiert wurde oder die empfohlene Verwendungsdauer von Schlüssel erreicht ist, oder ob man eine andere Lösung versucht. Ein Versuch WireGuard mit X.509 Zertifikaten zusammenzubringen ist in Incorporating Certificates with the Wireguard VPN Protocol beschrieben. Auch bei Kerberos wird ein geteiltes Geheimnis verwendet, aber die Domänen Controller speichern auch den Vorgängerschlüssel, so dass für eine Übergangszeit beide funktionieren.

Richtig ärgerlich wird es beispielsweise, wenn in einem kleinen Unternehmen ein Mitarbeiter das Unternehmen verlässt. Man muss eigentlich auch das WLAN-Passwort ändern. Das führt dann dazu, dass alle verblieben Mitarbeiter auf allen Geräten das neue Passwort eingeben müssen, und daher unterbleibt diese Änderung oft. Mit 802.1X wäre das Problem vermeidbar, aber das wird in kleinen Organisationen selten eingesetzt.

Hier liegt einer der großen Vorteile von X.509 Zertifikaten: es kann für die gleiche Identität mehrere Zertifikate auch mit unterschiedlichen Schlüsseln geben, die zeitlich überlappen, und dadurch einen Schlüsselwechsel ohne Unterbrechung ermöglichen. Der größte Nachteil von X.509 Zertifikaten ist, dass aufgrund der Vertrauensketten und Caching ein gezielter Rückruf eines Zertifikats langwierig sein kann. Durch die Kombination von Zertifikaten mit DNSSEC/DANE lassen sich zum einen eigene Zertifikate als vertrauenswürdig deklarieren, zum anderen können über TLSA-Records jederzeit neue Zertifikate hinzugefügt und abgelaufene Zertifikate gezielt gewechselt und deren TLSA-Record gelöscht werden (s.a. DNSSEC als Alternative zur klassischen CA).

In meinen Sicherheitsanforderungen fordere ich:

Denn immer wenn ich ein anderes oder gar selbst implementiertes Verschlüsselungs-, Authentifizierungsverfahren oder digitale Signaturen verwende, muss ich mir auch über ein geeignetes Schlüsselmanagement nachdenken, und das ist erheblicher Aufwand, während die Verwendung von X.509 Zertifikaten oder Kerberos, ggfs. im Rahmen eines Single-Sign-On-Verfahrens (z.B. mittels LDAP, SAML oder OAuth) das Problem auf existierende Lösungen abwälzt. Das ist schon alleine deswegen sinnvoll, weil wenn in diesen Standardlösungen eine Schwachstelle entdeckt wird, dann ist man wenigstens nicht alleine in dieser Situation, also nicht der einzig dumme, was lange nicht so schlecht fürs Image ist, wie wenn man alleine ein Problem hat. Alle Abweichungen von den Anforderungen – z.B. die bei WireGuard – sind in meinem Sicherheitskonzept bei der jeweiligen Anwendung dokumentiert.

Zusammenfassung

Für den Normalbenutzer

Verschlüsselung muss man nicht im Detail aber als Notwendigkeit verstehen, damit Daten und Passwörter nicht in die falschen Hände kommen. Dazu gehört auch, einen Dienst zu authentifizieren bevor ich das Passwort eintippe. Besonders kritisch muss ich sein, wenn eine URL in einer Mail enthalten ist, denn möglicherweise kann der Dienst sich authentifizieren, ist aber nicht der richtige – die falsche Identität. Und natürlich muss ich meine privaten Schlüssel selbst erzeugen, geheimhalten, und nach A2 eine Sicherung (Backup) der Schlüssel durchführen, und den öffentlichen Schlüssel geeignet veröffentlichen, so dass sich Verwender von der Integrität und Authentizität überzeugen können. Für die meisten Privatanwender ist das alles eine Herausforderung.

Für den ITler

Verschlüsselung und Authentifizierung sind Pflicht. Am besten man verwendet etablierte Standards wie TLS in aktuellen Versionen und X.509 Zertifikate. Aus meiner Sicht empfiehlt es sich, nach Anwendungen und Verschlüsselungsverfahren vorzugehen und die jeweilige Lösung zu dokumentieren.