Im Zusammenhang mit geeigneten technischen und organisatorischen Maßnahmen (TOMs) gemäß Art. 32 Abs. 1 lit. a und lit. b DSGVO wird regelmäßig die Transportverschlüsselung eingesetzt. Dieser Artikel beleuchtet aus der Perspektive der Informationssicherheit, was darunter zu verstehen ist und wo die Tücken in der datenschutzrechtlichen Bewertung liegen.

Vertraulichkeit und Integrität: Schutzziele der Informationssicherheit

Informationssicherheit hat zum Ziel, die Sicherheit von Informationen zu wahren. „Sicherheit“ wird durch die Gewährleistung von Schutzzielen erreicht. Zwei übliche Schutzziele der Informationssicherheit sind Vertraulichkeit und Integrität, d. h. es muss vermieden werden, dass unbefugte Dritte Kenntnis von den zu schützenden Informationen erlangen oder die Informationen unbemerkt verändert werden. Weitere Schutzziele, wie Verfügbarkeit oder Authentizität, spielen für diesen Artikel eine untergeordnete Rolle.

Zur Verdeutlichung, welche Tücken es bei der Transportverschlüsselung gibt, wird im Folgenden die Anwendung „E-Mail“ als Beispiel herangezogen. Die getroffenen Aussagen gelten in gleichem Maße aber auch für andere Anwendungen. So könnte auch der Abruf und die Anzeige von Webseiten als Betrachtungsobjekt genutzt werden.

Ende-zu-Ende-Verschlüsselung

Dieser Artikel beleuchtet den Schutz von Informationen, die zwischen zwei Kommunikationspartnern ausgetauscht werden. Die Zielsetzung einer solchen Kommunikation ist der Informationsaustausch zwischen Menschen. Zur Erreichung dieses Ziels nutzen kommunizierende Menschen technische Komponenten zur Telekommunikation, also Informationstechnologien wie Computer oder sonstige Endgeräte mit Software.

Im Sinne der Betrachtung der Kommunikation von Informationen auf der Ebene der Informationstechnologie wird zwischen einer sendenden Komponente („Sender“) und einer empfangenden Komponente („Empfänger“) datentechnisch kommuniziert. Solche Komponenten können Software oder Hardware sein. Die Kommunikation kann z. B. der Versand bzw. Empfang einer E-Mail sein. Dies wird hier als „Kommunikation auf Anwendungsebene“ bezeichnet.

Sender und Empfänger (die Komponenten, nicht die Personen!) sind im Sinne dieses Artikels deshalb die Endpunkte der betrachteten Kommunikation (auf Anwendungsebene). Wenn die oben genannten Sicherheitsziele gewährleistet werden sollen, kann zwischen diesen Endpunkten der (technischen) Kommunikation die dafür nötige Datenübertragung geschützt werden. Zu diesem Zweck wird die Ende-zu-Ende-Verschlüsselung eingesetzt, also eine Verschlüsselung, die nur durch den Sender und den Empfänger auf der Anwendungsebene vorgenommen bzw. rückgängig gemacht werden kann.

Bedauerlicherweise ist die Ende-zu-Ende-Verschlüsselung nicht für alle Anwendungen Stand der Technik. Insbesondere für E-Mails sind Ende-zu-Ende-verschlüsselte E-Mails die Ausnahme. Die überwiegende Zahl der E-Mails wird ohne Ende-zu-Ende-Verschlüsselung übertragen. Dieses Defizit wird zu einem Risiko für die Kommunikation zwischen den Partnern, wenn man sich vergegenwärtigt, wie diese Kommunikation zwischen Sender und Empfänger eigentlich funktioniert.

Transportverschlüsselung am Beispiel einer E-Mail

Zu diesem Zweck muss man eine Abstraktionsebene „hinabsteigen“ und betrachten, wie die Daten der Anwendung vom Sender zum Empfänger kommen. Für den Datentransport sind „Vermittler“ zuständig, die die zu transportierenden Daten vom Sender entgegennehmen, sie anhand von Adressinformationen zum nächsten Vermittler in einer Kette von Vermittlern weiterleiten, bis der letzte Vermittler die Informationen dem Empfänger übergibt.

Im Beispiel der E-Mail-Übertragung sind die Vermittler die E-Mail-Relay-Server, die die E-Mail untereinander auf Basis der Ziel-E-Mail-Adresse Sprung für Sprung von Server zu Server transportieren, bis der Empfänger – der E-Mail-Client auf dem Endgerät des Menschen, für den die E-Mail bestimmt ist – sie im Sinne der Anwendung, also der ursprünglichen Zielsetzung der Kommunikation, entgegennimmt und der nutzenden Person als E-Mail präsentiert.

Es bestehen also zwei Betrachtungsebenen: Die Kommunikation einer E-Mail vom Sender zum Empfänger, hier als „Anwendungsebene“ bezeichnet, und die sprungweise Übertragung der Kommunikationsdaten zwischen vermittelnden Servern („Vermittlern“), hier als „Transportebene“ bezeichnet. Auf beiden Ebenen werden Daten übertragen. Deshalb ist es bei Analysen wichtig zu unterscheiden, welche Daten für eine bestimmte Fragestellung auf welcher Ebene betrachtet werden.

Datenübertragung bei einer E-Mail

Für den eben beschriebenen Anwendungsfall E-Mail werden die Daten, die eine E-Mail auf der Anwendungsebene ausmachen, mangels Ende-zu-Ende-Verschlüsselung üblicherweise im Klartext übertragen. Damit sind die Vertraulichkeit und die Integrität der Daten auf dem Kommunikationsweg zwischen Sender und Empfänger gefährdet, da die übertragenen Daten durch jeden Vermittler (hier: E-Mail-Relay-Server) eingesehen werden können.

Aber auch jede Stelle, die auf die zwischen den Vermittlern bestehenden Kommunikationsverbindungen zugreifen kann, kann die darüber kommunizierten Daten einsehen und verändern. Datenverbindungen sind üblicherweise die verbindenden Datennetze oder im einfachsten Fall die Kabel zwischen vermittelnden Systemen.

Hier könnten wieder Betrachtungsebenen „hinabgestiegen“ werden, um bspw. die darunter liegende Datenkommunikation in Datennetzen und wiederum darunter in Kabelverteilungen in gleichem Sinne zu betrachten, darauf wird hier aber zu Gunsten der Übersichtlichkeit verzichtet. Die Funktionsprinzipien mit ihren Folgen wären aber die gleichen!

Um die Datenverbindungen zwischen den „Vermittlern“ der Kommunikation gegen Ausspähen und Veränderung zu schützen, verwenden diese untereinander Mechanismen, die die kommunizierten Daten dagegen schützen. Dieser Schutz wird durch Transportverschlüsselung erreicht. Bei einer Transportverschlüsselung schützt also ein Vermittler die Daten für den Übertragungsweg bis zum nächsten Übermittler.

Gefährdungen bei der Transportverschlüsselung

An dieser Stelle fällt auf: Schützen zwei Vermittler untereinander die Kommunikation, haben sie selbst trotzdem Zugriff auf die Daten, die sie weiterleiten! Der Schutz, den die Vermittler mittels Transportverschlüsselung herstellen, wirkt nur auf dem Übertragungsweg ZUM nächsten Vermittler. Der Schutz wirkt nicht VOR dem nächsten Vermittler oder bei der versendenden Komponente selbst.

Weiterhin fällt auf: Die Transportverschlüsselung zwischen zwei Vermittlern wirkt nur zwischen genau diesen Vermittlern, nicht davor oder danach. Das bedeutet, um alle Übertragungswege zwischen allen Vermittlern mittels Transportverschlüsselung abzusichern, muss jeder Vermittler mit jedem nächsten Vermittler eine Transportverschlüsselung benutzen. Umgekehrt ist eine Transportverschlüsselung zwischen zwei Vermittlern kein Garant für eine Transportverschlüsselung zwischen beliebig vielen anderen Vermittlern.

Die Vermittler sind in ihren Schutzmechanismen alle voneinander unabhängig und nur bestimmt durch ihre eigene, lokale Geräteeinstellung. Eine Zusicherung, dass alle Vermittler vom Sender bis zum Empfänger diese Absicherung vornehmen, ist nicht durchsetzbar. Schlimmer noch: Auf der Ebene „darüber“, also der Anwendungsebene von Sender und Empfänger, sind diese Einzelentscheidungen weder vorherbestimmbar noch transparent. Sender und Empfänger können nur die Kommunikationsabsicherung mit ihrem unmittelbaren Vermittler mitbestimmen, aber keine andere!

Es gibt einen weiteren, sprachlichen Fallstrick: „Vergisst“ man die eingangs aufgestellte Betrachtungsebene der Anwendungsebene und betrachtet nur und ausschließlich die Kommunikation zwischen einem Vermittler und dem unmittelbar nächsten Vermittler, könnte man den Schutz dieses Übertragungsweges in einem gewissen Sinne als Ende-zu-Ende-Verschlüsselung beschreiben, da auf der niedrigeren Betrachtungsebene der übermittelnde Vermittler nun der „Sender“ ist und der nächstgelegene Vermittler wäre dann der „Empfänger“ der Anwendung „Vermittlung“. Auf der gewählten Betrachtungsebene ist das zwar korrekt, bei der Gesamtbetrachtung der zu erzielenden und zu schützenden Kommunikation zwischen (zwei) Menschen ist die Verwendung des Begriffs Ende-zu-Ende-Verschlüsselung aber sehr verwirrend und sollte vermieden werden, siehe auch [0].

Zwischenfazit

Zusammenfassend ist festzustellen: Eine durchgängige Kette von Transportverschlüsselungen vom Sender über alle Vermittler bis zum Empfänger ist weder durchsetzbar, noch schützt sie die Vertraulichkeit und Integrität der Informationen vor den Vermittlern selbst. Deshalb ist Transportverschlüsselung KEIN ERSATZ für eine Ende-zu-Ende-Verschlüsselung. Eine Transportverschlüsselung kann nur gegen Gefahren auf dem Weg zwischen zwei Vermittlern schützen, nicht mehr.

Anzumerken sei noch, dass selbst bei eingesetzter Ende-zu-Ende-Verschlüsselung zwischen Sender und Empfänger mindestens die Zieladresse der Kommunikation für alle „Vermittler“ im Klartext vorliegen muss, da diese sonst ihre vermittelnde, weiterleitende Funktion nicht ausüben können. Für die Rück-Vermittlung von Fehlermeldungen liegt üblicherweise auch die Sender-Adresse vor. Alle beteiligten Vermittler „wissen“ also von der stattfindenden Kommunikation zwischen Sender und Empfänger und können die Teilnehmer adressieren. Diese Vermittler protokollieren ihre Tätigkeit üblicherweise, sodass auch nach Abschluss der Kommunikation die Kenntnis darüber weiterbesteht. Dies wird als Metadaten der Kommunikation bezeichnet, oder auch – rechtlich relevant – als die „Umstände der Kommunikation“. Diese stehen also auch bei Verwendung von Ende-zu-Ende-Verschlüsselung zur Verfügung und können abgefragt und ausgewertet werden, selbst ohne Kenntnis der kommunizierten Inhalte!

Bei der Betrachtung der „Sicherheit“ einer Kommunikation ist es also unabdingbar, exakt zu klären, was die untersuchte „Kommunikation“ eigentlich ist: Erfolgt die Analyse auf Anwendungsebene, also z. B. der Inhalt einer E-Mail von Nutzer zu Nutzer? Dafür wäre Ende-zu-Ende-Verschlüsselung zu betrachten. Oder liegt der Fokus auf dem Transportweg einer E-Mail von einer beteiligten technischen Komponente zur nächsten – in der langen Kette der jeweils vermittelnden, miteinander kommunizierenden Komponenten? In diesem Fall ist die Transportverschlüsselung zu untersuchen.

Wichtig zur Beurteilung der Sicherheit ist ebenfalls zu bestimmen, was mit Sicherheit jeweils gemeint ist. So schützt eine Ende-zu-Ende-Verschlüsselung zwar die Inhalte im Hinblick auf ihre Vertraulichkeit und Integrität, aber die Umstände der Kommunikation oder weitere, vielleicht erhoffte Eigenschaften sind dadurch trotzdem nicht geschützt.

„Sender“ und „Empfänger“ sind „Endpunkte“ einer Kommunikation: Abhängig von der betrachteten Ebene können das für die Kommunikation die Endpunkte einer Ende-zu-Ende-Verschlüsselung auf der Anwendungsebene sein, oder bei der Betrachtung der Transportebene die Endpunkte einer Transportverschlüsselung zwischen zwei Vermittlern. Bei Nutzung dieser Begriffe ist also Sorgfalt zu wahren und immer die betrachtete Ebene eindeutig zu klären, in deren Kontext die Verwendung erfolgt.

Transportverschlüsselung: Schutz der Vertraulichkeit und Integrität der Daten

Wie vorangehend dargelegt, dient eine Transportverschlüsselung der Absicherung einer Kommunikation auf der Transportebene zwischen zwei vermittelnden technischen Geräten gegen eine Gefährdung der Vertraulichkeit und Integrität auf dem Übertragungsweg der Daten. Für jeden „Schritt“ der Vermittlung zwischen einer Komponente und der nächsten Komponente ist eine separate Transportverschlüsselung nötig.

Wenn im Folgenden von Kommunikationspartnern und Endpunkten gesprochen wird, sind damit die an einer Transportverschlüsselung als Sender und Empfänger beteiligten Endpunkte auf der Transportebene gemeint, also die „Vermittler“. Dies sind nicht die Endpunkte einer Ende-zu-Ende-Verschlüsselung!

Für die Transportverschlüsselung sind die damit transportierten Daten selbst transparent und irrelevant; sie könnten auch Ende-zu-Ende-verschlüsselt sein, dies macht für die Transportverschlüsselung selbst keinen Unterschied. Transportverschlüsselung schützt verschlüsselte Ende-zu-Ende-Kommunikation genauso wie Daten im Klartext.

Transportverschlüsselung für Daten, die bereits auf der Anwendungsebene geschützt sind, also bspw. eine Ende-zu-Ende-verschlüsselte E-Mail, ist für die Gesamtsicherheit der Kommunikation “eigentlich“ unnötig. Allerdings ist nur eine geringe Anzahl von E-Mails entsprechend geschützt, eine generelle Verschlüsselungsregelung auf der Transportebene ist deshalb ratsam. Auch wäre die Transportebene nicht in der Lage, zwischen geschützten und ungeschützten Daten der Anwendungsebene zu unterscheiden, daher ist es besser, geschützte Daten unbeabsichtigt erneut zu schützen, anstatt ungeschützte Daten beabsichtigt nicht zu schützen.

Protokolle für die Transportverschlüsselung

Um die genannten Ziele zu realisieren, erfolgt die technische Umsetzung einer Transportverschlüsselung durch ein Protokoll. Ein Protokoll legt – wie im richtigen Leben – fest, wie die beteiligten Parteien miteinander umgehen, um ein gemeinsames Kommunikationsziel zu erreichen. Ein Protokoll wird in Standards festgelegt. Ein Standard kann für ein Protokoll eine Menge unterschiedlicher Algorithmen und Parameter vorgeben.

Beide Kommunikationspartner einer üblichen Transportverschlüsselung implementieren meist mehrere Standards, Protokollversionen und zugehörige Parametersätze. Die Transportverschlüsselung zwischen zwei Parteien beginnt mit der „Aushandlung“ des zu verwendenden Standards und der damit genutzten Algorithmen und ihrer Parameter. Eine erfolgreiche Kommunikation kann nur zustande kommen, wenn beide Seiten denselben Standard verwenden können, also eine gemeinsame Schnittmenge der verwendeten Protokolle, Algorithmen und Parameter implementieren.

Standards sind das Ergebnis eines Standardisierungsprozesses. Diesem liegen die Erkenntnisse zum Zeitpunkt der Entwicklung des Standards zugrunde. Im Laufe der Zeit kommen neue Erkenntnisse hinzu, die durchaus frühere Erkenntnisse und darauf basierende Entscheidungen negieren, und eine Revision erfordern können, und sie teils außer Kraft setzen müssen. Damit ändert sich kontinuierlich der Stand der Technik und dies erfordert eine ständige Anpassung der Standards und Protokolle und damit der Konfigurationen und Produkte.

SSL (Secure Sockets Layer-Protokoll)

Der historische Standard für Transportverschlüsselung ist das Secure Sockets Layer-Protokoll, abgekürzt SSL. Die erste öffentliche Version ist SSL 2.0 und stammt von 1995. Allerdings ist aufgrund fortschreitender Erkenntnisse mittlerweile selbst der letzte Namensnachfolger SSL 3.0 seit 2015 als Standard zurückgezogen („deprecated“, also veraltet). Dieser entspricht nicht mehr dem Stand der Technik und sollte demnach auch nicht mehr eingesetzt werden. Dennoch findet sich in vielen Anpreisungen und TOM-Erklärungen noch heute die Aussage, SSL werde als Transportverschlüsselung eingesetzt. Solche Aussagen in Beschreibungen und Verträgen sollten immer stutzig machen.

Der Grund für die Erwähnung in solchen Erklärungen mag sein, bei der lesenden Person Vertrautheit hervorzurufen. Wer allerdings den Stand der Technik kennt, wird hier eine rote Flagge sehen. Es ergeben sich zwei Möglichkeiten:

  • Wenn wirklich SSL eingesetzt wird, ist das nicht Stand der Technik, demnach sollte das Produkt in dieser Konfiguration nicht mehr verwendet werden.
  • Wenn jedoch in Wirklichkeit das Nachfolgeprotokoll TLS eingesetzt wird, ist die Dokumentation falsch. Und wenn die Dokumentation falsch ist und seit Jahren nicht angepasst wurde, wirft das kein gutes Licht auf die Entwicklungs- und Vermarktungsprozesse des Herstellers bzw. Anbieters.

In jedem Fall empfiehlt sich eine kritische Nachfrage und Klärung des Sachverhalts beim Anbieter.

TLS (Transport Layer Security-Protokoll)

Das Nachfolgeprotokoll zu SSL ist das Transport Layer Security-Protokoll, abgekürzt TLS. Auch dieses hat bereits mehrere Neuerungen durchlaufen.[1] Das Bundesamt für Sicherheit in der Informationstechnik (BSI) empfiehlt nur TLS 1.2 und TLS 1.3, diese sind deshalb als Stand der Technik zu werten.[2]

Ältere Versionen entsprechend nicht mehr dem Stand der Technik und damit auch aus datenschutzrechtlicher Sicht nicht den Anforderungen des Art. 32 Abs. 1 und 2 DSGVO.

Im TLS-Protokoll werden insbesondere drei Funktionen umgesetzt:

  • Schlüsselaushandlung
  • Verschlüsselung
  • Integrität

Für eine wirksame Transportverschlüsselung ist deshalb nicht nur die bloße Festlegung des Standards relevant, sondern auch die Konfiguration verschiedener Parameter und die Auswahl der in dem Protokoll verwendeten Algorithmen. Diese werden in den nächsten Abschnitten beschrieben.

Schlüsselaushandlung im TLS-Protokoll

Um Daten effizient und effektiv zu verschlüsseln bedarf es eines Schlüssels, welcher Sender und Empfänger gleichermaßen bekannt ist. Zu Beginn einer transportverschlüsselten Verbindung wird deshalb zwischen beiden Parteien ein Schlüssel „ausgehandelt“. Auch für diese Aushandlung bedarf es der gegenseitigen Festlegung eines Algorithmus. Dies geschieht üblicherweise durch eine Vorschlagsliste eines Kommunikationspartners mit Algorithmen, die die Seite unterstützt. Die Gegenseite wählt aus der Liste einen Algorithmus aus, der im Folgenden von beiden Parteien verwendet wird.

Dafür geben die Standards eine reichhaltige Liste vor, die den aushandelnden Parteien zur Verfügung steht. Dabei macht TLS 1.2 den Eindruck eines sicheren Protokolls, dennoch sind zwei Einträge als unsicher gekennzeichnet.[1] Neben der bloßen Wahl von TLS 1.2 als Transportverschlüsselung kommt es also bereits darauf an, auf beiden Seiten die Konfiguration so einzustellen, dass nur die als sicher markierten Algorithmen verwendet werden. Dabei bieten einige der Algorithmen mehr Sicherheitseigenschaften („forward secrecy“, in etwa „vorwärts gerichtete Geheimhaltung“) als andere, weswegen diese bevorzugt konfiguriert werden sollten.

Der Standard TLS 1.3 hat den Vorteil, dass nur als sicher eingeschätzte Algorithmen unterstützt werden. Weiterhin werden nur Algorithmen unterstützt, die erweiterte Sicherheitseigenschaften aufweisen. Unabhängig von der konkreten Konfiguration, kann TLS 1.3 also als sicher betrachtet werden und ist immer mindestens genauso gut wie TLS 1.2.

Verschlüsselung im TLS-Protokoll

Nachdem ein gemeinsamer Schlüssel zwischen den kommunizierenden Parteien ausgehandelt wurde, ist die eigentliche Funktion der Transportverschlüsselung möglich: die Verschlüsselung der transportierten Daten und die Entschlüsselung auf der empfangenden Seite. Auch dafür gibt es verschiedene Algorithmen, die von den unterschiedlichen Standards unterstützt werden.

Dabei wird deutlich, dass TLS 1.1 und ältere Standards ausschließlich unsichere oder kompliziert korrekt einzusetzende Algorithmen und Betriebsmodi unterstützen, weshalb sie nicht mehr Stand der Technik sind und nicht eingesetzt werden sollten. Selbst TLS 1.2 unterstützt viele unsichere und problematische Verschlüsselungen.[1] Bei der Konfiguration einer Anwendung, die TLS 1.2 verwendet, sollten deshalb die verwendeten Chiffren/Modi durch angemessene Konfiguration auf die als sicher markierten beschränkt werden. TLS 1.3 sticht durch Minimalismus hervor: Für Block- und Stromchiffre wird jeweils nur ein Algorithmus unterstützt (die Blockchiffre in zwei Betriebsmodi), und diese sind alle als sicher anzusehen.

Eine genauere Betrachtung von (Block-)Chiffren, Schlüssellängen und Betriebsmodi findet sich in [3].

Schutz der Integrität der Daten durch den Einsatz von HMAC

De facto leistet eine übliche Transportverschlüsselung mehr als lediglich Verschlüsselung, i. e. das Sicherheitsziel der Vertraulichkeit zu gewährleisten. Eine Transportverschlüsselung stellt auch sicher, dass die übermittelten Daten zwischen den Vermittlern nicht unbemerkt verändert werden können, dadurch wird das Schutzziel der Integrität sichergestellt.

Die Prüfung der Integrität der Daten erfolgt typischerweise durch den Einsatz von Hashes, also kryptografischen Prüfsummen, auch als HMAC abgekürzt. HMAC steht für Keyed-Hash Message Authentication Code. Der Sender berechnet diese Prüfsumme und übermittelt sie verschlüsselt, der Empfänger berechnet ebenfalls eine Prüfsumme der Daten und vergleicht sie mit der vom Sender geschickten. Stimmen die Prüfsummen überein, sind die Daten unverändert. Bei einem Angriff – der erst die Verschlüsselung brechen müsste – könnte für veränderte Daten die korrekte Prüfsumme nicht errechnet werden, da dafür ein nur dem Sender und dem Empfänger bekanntes Geheimnis fehlt.

Wieder stehen für die Berechnung von kryptografischen Prüfsummen verschiedene Möglichkeiten zur Verfügung: TLS 1.2 bietet erneut eine Palette von Algorithmen, die verwendet werden können.[1] Allerdings sind sowohl gegen MD5 (Message-Digest Algorithm) als auch gegen SHA1 (Secure Hash Algorithm) Angriffsformen bekannt. Deshalb sind diese Algorithmen für die Berechnung von kryptografischen Prüfsummen zwar durch das BSI zurzeit noch zulässig und deshalb als Stand der Technik zu werten, es wird aber ausdrücklich von deren Verwendung abgeraten.[5] TLS 1.3 stellt Integrität nicht durch eine separate Prüfsumme sicher, sondern integriert die Integritätsbestimmung in die Verschlüsselung. Dafür ist nur ein Algorithmus zulässig.

Fazit

Zur Erinnerung: Eine Transportverschlüsselung dient (i. d. R.) nicht der Ende-zu-Ende-Kommunikation zwischen Personen und hilft nicht, kommunizierte Inhalte vor den Endpunkten der Transportverschlüsselung zu verbergen und schützt auch nicht die Umstände der Kommunikation.

Die Realität steht – wie so oft – der Bewertbarkeit von TOMs und dem technischen Optimum entgegen. Einerseits ist eine so detaillierte Analyse, wie hier ausgeführt, in der Praxis bei der Prüfung von TOMs kaum möglich, da Hersteller oder Verwender von Produkten selten die nötigen Informationen darlegen. Werbung für und selbst Erklärungen der umgesetzten TOMs sind meist abstrakt und bestenfalls oberflächlich dargestellt. Aus pragmatisch-technischer Sicht können kritische Nachfragen hilfreich sein. Zertifizierungen nach ISO/IEC 27001, die immerhin ein Krypto-Konzept vorschreiben, nähren die Hoffnung, dass nur sichere Algorithmen verwendet werden. Die Ungewissheit, ob die dokumentierten Maßnahmen auch wirklich korrekt und konsequent umgesetzt sind (vgl. auch [4] bzgl. kooperierender Dienstanbieter), verbleibt immer.

Andererseits scheitert die Umsetzung der technisch optimalen Lösung TLS 1.3 an den Interessen der an der Kommunikation beteiligten Parteien. Setzt der Dienstanbietende ausschließlich den modernsten, nicht abwärtskompatiblen Standard ein, kann ein Teil der erwarteten Kundschaft mangels kompatibler Endgeräte den Dienst nicht nutzen. Damit sinkt der Umsatz bzw. der Wert der Dienstleistung. Umgekehrt nützt der Kundschaft die sicherste Transportverschlüsselung nichts, wenn damit der benötigte oder gewünschte Dienst, nicht genutzt werden kann, weil er diese nicht unterstützt, und so durch garantierte Nichtverfügbarkeit unabwendbare Nachteile in der Sache entstehen, um dadurch abstrakte, relativ unwahrscheinliche Gefahrenpotenziale zu vermeiden.

Idealerweise setzen beide Parteien nur TLS 1.3 ein. Aus pragmatischen Gründen kann auch TLS 1.2 verwendet werden, wobei eine sorgfältige Konfiguration zur Minimierung der Verfahren auf die als sicher anerkannten erfolgen sollte. Dadurch ist höchstmögliche Sicherheit bei gleichzeitig größtmöglicher Kompatibilität gegeben und der Stand der Technik ist eingehalten. Ältere Versionen von TLS oder gar SSL sollten nicht verwendet werden. Die Konfiguration sollte regelmäßig überprüft und an den Stand der Technik angepasst werden, was durch die Implementierung eines Informationssicherheits-Managementsystems (ISMS) erreicht werden kann.

Es bleibt zu hoffen, dass sowohl Dienstanbietende als auch Kunden und Produzenten zügig ihre jeweilige Fähigkeit erhöhen, um einen kürzeren Innovationszyklus reibungslos zu realisieren. Dadurch kann schnell auf zukünftige Sicherheitslücken reagiert und daraus resultierende neue Standards können zügig breitflächig eingesetzt werden.

Quellen

[0] arstechnica: “ Zoom lied to users about end-to-end encryption for years, FTC says”, abgerufen 2021-07-09, online unter https://arstechnica.com/tech-policy/2020/11/zoom-lied-to-users-about-end-to-end-encryption-for-years-ftc-says/

[1] Wikipedia: „Transport Layer Security“, abgerufen 2021-07-06, online unter https://en.wikipedia.org/wiki/Transport_Layer_Security

[2] Bundesamt für Sicherheit in der Informationstechnik (BSI): „Kryptographische Verfahren: Empfehlungen und Schlüssellängen“, „Teil 2 – Verwendung von Transport Layer Security (TLS)“, TR-02102-2, Version 2021-01

[3] datenschutz notizen: „Die Tücken der Blockchiffren in TOMs“, abgerufen 2021-07-06, online unter https://www.datenschutz-notizen.de/die-tuecken-der-blockchiffren-in-toms-2925487/

[4] datenschutz notizen: „Wie sicher sind verschlüsselnde Cloud-Speicher-Dienste?“, abgerufen 2021-07-06, online unter https://www.datenschutz-notizen.de/wie-sicher-sind-verschluesselnde-cloud-speicher-dienste-0526776/

[5] Bundesamt für Sicherheit in der Informationstechnik (BSI): „Kryptographische Verfahren: Empfehlungen und Schlüssellängen“, TR-02102-1, Version 2021-01

 

| | | , , , , , , , ,