In den bisherigen Teilen unserer Artikelserie ging es im Wesentlichen um technische Aspekte der Verschlüsselung. Im Folgenden möchte ich mich mit den Grenzen der Verschlüsselung beschäftigen – diese sind häufig weniger technischer als organisatorischer Natur.

In diesem Artikel lesen Sie mehr zu den Themen:

• Aufwand und Nutzen bei der Verschlüsselung
• Verarbeitung verschlüsselter Daten
• Schwierigkeiten der Verschlüsselung bei der Zusammenarbeit
• Rechtliche Schranken der Verschlüsselung
• Hindernisse bei der Anwendung von Verschlüsselungstechnologien für normale User

Aufwand vs. Nutzen

Solange nur kleine Datenmengen wie kurze Nachrichten oder überschaubar große Dateien verschlüsselt werden müssen, ist der damit verbundene Rechenaufwand meist keine große Herausforderung. Anders sieht es aus, wenn sehr große Datenmengen zu chiffrieren sind – oder wenn an die Verschlüsselung zeitlich hohe Anforderungen gestellt werden. Ein Beispiel: Bei der Echtzeit-Verarbeitung von Daten muss ein System auf ein äußeres Ereignis innerhalb eines eng definierten Zeitrahmens reagieren, weil anderenfalls die Systemantwort zu spät kommt. Die Verschlüsselung einer Datei kann diesen Rahmen leicht sprengen, wenn der Systemdesigner die Randparameter der Verarbeitung innerhalb der geforderten Antwortzeit nicht zu 100 Prozent im Griff hat. Die Verschlüsselung per Software ist hierbei häufig nicht das Optimum – spezialisierte Chips sind die bessere Wahl.

Offensichtlich ist das Problem bei der Chiffrierung sehr großer Datenmengen „am Stück“. Diese kann dazu führen, dass bestimmte zeitkritische Verarbeitungsschritte nicht in der zur Verfügung stehenden Zeit (Beispiel: Backup-Fenster) fertig werden. Bei interaktiven Operationen könnte zudem der Anwender in Folge der Wartezeit die Geduld verlieren. Gerade bei Cloud-Anwendungen, die sich beim Antwortzeitverhalten immer mit lokal installierten vergleichen lassen müssen, ist das möglicherweise ein Thema. Entweder wird die Anwendung langsam, oder sie wird teuer, weil der Provider jede Menge CPU-Leistung „just in case“ bereit halten muss. So könnten etwa Hunderte Benutzer gleichzeitig ihren Lieblingsfilm verschlüsselt ablegen wollen. Der Akzeptanz ist beides abträglich. Gleiches gilt für schwache Prozessoren bei eigentlich überschaubaren Datenmengen wie in Mobiltelefonen.

Wie verarbeitet man verschlüsselte Daten?

Geradezu unmöglich ist es, Daten verschlüsselt zu halten, die gerade verarbeitet werden sollen. Schließlich müssen die Daten zum Bearbeiten unverschlüsselt vorliegen. Im Cloud-Kontext bedeutet das: Der Dienstanbieter muss in solchen Momenten Zugriff auf die Daten haben. Dabei sorgen „lediglich“ andere technisch-organisatorische Maßnahmen für die Datensicherheit. Wenn Sie beispielsweise eine Datei bearbeiten wollen, die in SharePoint Online liegt und dort im Backend verschlüsselt ist, muss diese zum Bearbeiten – etwa mit Word oder Excel – ausgepackt werden. In diesem Moment hat Microsoft Zugriff auf diese Daten.

Einschränkungen muss man ebenfalls hinnehmen, wenn es aufgrund des darunterliegenden Protokolls technisch unvermeidlich ist. Ein Beispiel hierfür ist De-Mail, das auf SMTP basiert und zwischen dem Absender und dem De-Mail-Server sowie zwischen letzterem und dem Empfänger verschlüsselt ist. Auf dem De-Mail-Server selbst muss die Mail jedoch für einen kurzen Moment unverschlüsselt vorliegen, damit der Server die Routing-Informationen (Headerzeilen, wie im zweiten Teil der Serie angesprochen) lesen kann. Eine Ende-zu-Ende-Verschlüsselung ist das demzufolge nicht, aber das ist E-Mail wegen der Eigenheiten von SMTP ohnehin nie. Die konkreten Auswirkungen werden von den Kritikern der De-Mail oft übertrieben dargestellt. Vor allem, da die bei den „Diensten“ so begehrten Metadaten auch bei Verschlüsselungen wie PGP (Pretty Good Privacy) oder S/MIME (Secure/Multipurpose Internet Mail Extensions) unverschlüsselt vorliegen.

Zusammenarbeit nicht ganz einfach

Schwierig wird es auch, wenn mehrere Mitarbeiter einer Arbeitsgruppe gemeinsam auf Daten zugreifen wollen, die verschlüsselt in einer Cloud-Anwendung liegen. Zumindest, wenn es richtig gemacht werden soll. Dann muss eine solcherart gelagerte Datei gegen die Schlüssel aller Mitarbeiter verschlüsselt werden, die darauf zugreifen sollen. Kommt ein Mitarbeiter hinzu, muss dessen Schlüssel hinzugefügt werden. Wenn ein Mitarbeiter die Arbeitsgruppe verlässt, muss der Schlüssel wieder entfernt werden. Das bedeutet in vielen Fällen: Die Datei oder zumindest der Session Key muss entschlüsselt und mit dem aktualisierten Satz Schlüssel wieder verschlüsselt werden. Locking ist das nächste Thema, das durch Verschlüsselung nicht einfacher wird. Dass sich alle Mitarbeiter denselben Schlüssel teilen, ist keine Option. Bei einer gewissen Fluktuation der Teammitglieder könnte dies nicht mehr kontrolliert werden.

Verschlüsselung hat ihre Grenzen – gerade bei der Zusammenarbeit im Team

Nahezu unmöglich wird Kollaboration, wenn die Teilnehmer einer Kommunikation oder Verschlüsselung unterschiedliche Verfahren verwenden. Ein oft zitiertes Beispiel ist PGP, das in der Frühzeit häufig mit dem Schlüsselverfahren IDEA (International Data Encryption Algorithm) verwendet wurde. IDEA ist aber patentiert und damit nicht frei, daher wurde es schon sehr früh durch andere Chiffres ersetzt.  Bekommt ein Anwender eine Mail, die mit einer alten PGP-Version mit IDEA verschlüsselt worden ist, kann er sie möglicherweise gar nicht entschlüsseln. Das ist auch der Fall, wenn Sie früher mit einer alten PGP-Version gearbeitet (2.6.3 zum Beispiel) und noch einige verschlüsselte Mails in Ihrem Mailfolder liegen haben.

David und Goliath

Eine schwache Verschlüsselung ist für einen Anwender besonders unangenehm, wenn ein potenzieller Angreifer über nahezu unbegrenzte Rechen-Ressourcen verfügt. Nicht umsonst war lange Zeit der Export von Verschlüsselungstechnologien aus den USA auf Schlüssellängen von 40 Bit beschränkt – die Exportversion von Lotus Notes lässt grüßen. Ähnliches trifft auf DES-56 zu, das seit Langem als gebrochen gilt und damit heute nur noch Spielerei ist. Anwender sollten daher unbedingt auf als sicher angesehene Verfahren und Schlüssellängen zurückgreifen.

Rechtliche Schranken …

Rechtliche Schranken für die Verschlüsselung existieren ebenfalls. In Deutschland müssen die Zugangsdaten – beispielsweise zu einem verschlüsselten Datencontainer – auf richterliche Anordnung herausgeben werden. Auf der anderen Seite sind Provider verpflichtet, auf richterliche Anordnung Daten herauszugeben, die Gegenstand polizeilicher Ermittlungen sind. Im Moment gibt es dafür hierzulande noch einen Richtervorbehalt.

Ebenso nutzlos wird Verschlüsselung in Ländern, in denen die Behörden sich grundsätzlich das Recht vorbehalten, Daten zu Ermittlungszwecken einzusehen. Helfen kann man sich dagegen nur, wenn man auf Cloud-Speichern eine eigene Verschlüsselung wie Boxcryptor einsetzt. Bei Cloud-Anwendungen, die in den USA gehostet werden, nützt das allerdings nichts.

Manche Behörden wollen zu Zwecken der Prävention sogar von vorneherein rechtliche Einschränkungen für Verschlüsselung einführen. So war es in Frankreich jahrelang verboten, überhaupt zu verschlüsseln.

Bei Schlüsselverlust sind Admins machtlos?

Gravierend ist der Verlust der Zugangsdaten für selbst verschlüsselte Daten auf einem Storage. Den Anruf beim für den Storage zuständigen Admin kann man sich sparen. Für seinen Schlüssel ist jeder Benutzer selbst verantwortlich – anders als im Falle der Haustür, bei der gewöhnlich noch der freundliche Schlüsseldienst helfen kann. Bei Fort Knox wäre der aber auch machtlos. Weg ist weg, und die gespeicherten Daten gleich mit. Das trifft auch zu, wenn beispielsweise ein Truecrypt-Container an der falschen Stelle beschädigt wird. Umso wichtiger sind in diesem Zusammenhang regelmäßige Backups!

Verschlüsselung für Otto Normaluser?

Ein großes Hindernis für die breite Einführung und Nutzung von starker Verschlüsselung ist nach wie vor der Umstand, dass die meiste Software für normale Benutzer nur sperrig zu verwenden ist. Versuche, Verschlüsselung für Anwender ohne Informatik-Diplom zugänglicher zu machen, gab und gibt es viele, aber keine der vorgeschlagenen Methoden hat sich bisher wirklich in der Breite durchsetzen können. Dem entgegen stehen nach wie vor einige der im vorigen Beitrag angesprochenen Themen wie „Transparenz“, die Komplexität der Thematik, die Inkompatibilität verschiedener Kryptosysteme sowie die Benutzerfreundlichkeit.

Überhaupt: Usability ist ein ganz großer Verhinderer für Verschlüsselung. Angenommen, der langjährige Linux-Anwender David konnte seine Familie, eingeschlossen Onkel, Tanten und die Oma überzeugen, Mails nur noch verschlüsselt per PGP zu verschicken. Der Rest der Familie benutzt aber über Outlook, Eudora oder Apple-Mail ganz andere Mailsoftware – und nicht etwa Thunderbird. Bei jedem dieser Systeme gibt es unterschiedliche Möglichkeiten, PGP einzuhängen – mit unterschiedlichen Abhängigkeiten und Bedienungsphilosophien. Das Einzige, was David davon am Ende hätte, ist ein Vollzeitjob als unbezahlter Familien-Sysadmin.

Falsche Sicherheit ist gar keine Sicherheit

Selbst wenn sich ein Benutzer dazu entschließt, starke Kryptografie zu verwenden, besteht die Gefahr, dass er einer falschen Sicherheit aufsitzt. Etwa weil er das System nicht durchschaut oder Nebeneffekte nicht kennt beziehungsweise übersieht. Beim inzwischen hinlänglich bekannten „The Onion Router“ (Tor) ist zwar der Zugang zum Tor Entry Node (dem ersten, zu dem ein Anwender eine Verbindung aufbaut) verschlüsselt. Ebenso alle Verbindungen der Gateway Nodes untereinander, aber möglicherweise nicht die Verbindung vom Tor Exit Node zum Zielsystem. Das ist genau dann nicht der Fall, wenn der Ziel-Webserver kein HTTPS unterstützt, sondern nur HTTP ohne SSL/TLS. In dem Fall werden Zugangsdaten und Nutzdaten ab dem Tor Exit Node unverschlüsselt übertragen. Alles, was ein Angreifer tun muss (und auch nachweislich schon getan hat), ist ein paar Tor Exit Nodes aufzustellen und den Datenverkehr mitzuschneiden. Da gerade kleinere Webseiten häufig kein SSL unterstützen, schon gar nicht als automatischen Redirect von Port 80 auf 443, und viele Anwender nicht darauf achten (HTTPS Everywhere ist hier wärmstens zu empfehlen), fallen dem Angreifer im Laufe der Zeit massenhaft valide Zugangsdaten in den Schoß, die er sich für „irgendwann“ aufheben, weiterverkaufen oder systematisch und möglicherweise automatisiert für Webseiten, Mailkonten etc. nutzen kann.

TOR funktioniert durchgehend verschlüsselt - außer am Ende, wenn die ursprüngliche Verbindungsanfrage unverschlüsselt war

Die TOR-Dokumentation warnt explizit vor diesem Umstand. Aber seien wir ehrlich, wer liest schon Dokumentationen? Und das auch noch überwiegend in Englisch. Es gibt sie auch in anderen Sprachen, aber die muss Otto Normaluser erst mal finden (wollen).

Richtig verwirrend wird letzterer Umstand dadurch, dass selbst die Netzgemeinde sich darüber uneins ist, ob man solche mit Vorsicht zu genießenden Systeme normalen Anwendern empfehlen soll oder nicht. Manche sagen, der Anwender gewänne trotzdem an Sicherheit. Andere sagen, dass falsche Sicherheit so gut wie gar keine Sicherheit sei – siehe diesen Twitter-Thread sowie diesen Blog-Beitrag zum Thema Tor. Der Internetaktivist Alvar Freude überspitzt das hier aus dramaturgischen Gründen sicherlich ein wenig, aber das sperrige „end of discussion“ seitens des Netzaktivisten Padeluun ist ganz sicher nicht hilfreich. So verständlich der Wunsch nach einfach benutzbarer Krypto ist – ein bisschen verhält es sich damit wie mit dem Autofahren. Einfach kaufen, reinsetzen und losfahren ist unter Umständen keine so gute Idee. Eines Führerscheins – und zuvor eines guten Fahrlehrers – bedarf es schon.

Dieser Teil der Verschlüsselungsreihe fiel nicht sehr „wolkig“ aus. Der nächste wird sich daher stärker mit der Verschlüsselung in der Cloud beschäftigen.