Moeglichkeiten.tex

\section{Einschränkungen der Honey Encryption}
\label{sec:probleme}

Durch die hohe Sicherheit der Verschlüsselung ergeben sich vor allem Anwendungsfälle, bei denen hochsensible Daten verschlüsselt werden sollen. Juels und Ristenpart geben dafür einige Beispiele, wie das Verschlüsseln von RSA-Schlüsseln oder Kreditkartennummern (siehe \cite{EURO2014, IEEE2014}). Ebenfalls könnten Passwort-Safes/-Manager mit Honey Encryption vor Zugriffen von außen geschützt werden. Generell ist diese Verschlüsselungsmethode auf strukturierte Daten anwendbar, von denen die Generierung und der Aufbau bekannt sind. Dies ist schließlich, wie in Abschnitt \ref{sec:dte} beschrieben, notwendig zur Konstruktion einer sicheren und invertierbaren DTE. Dementsprechend ist Honey Encryption nicht oder nur eingeschränkt für Freitext, wie Notizen oder E-Mails, geeignet. Ein Grund dafür ist die Tatsache, dass die Menge aller Nachrichten bekannt sein muss. Diese ist bei Freitext quasi unbegrenzt.

Es muss nicht nur die Menge aller Nachrichten bekannt sein, sondern auch die Verteilung ihrer Wahrscheinlichkeiten. Bei Passwort-Managern beispielsweise ist die Menge der vom Nutzer verschlüsselten Passwörter meist abhängig vom Nutzer selbst. Falls der Nutzer nämlich keine zufällig generierten Passwörter verwendet, sind Passwörter, die Teile des Namens, des Geburtsdatums, des Namens der Lieblingsband, des Haustieres oder anderer persönlicher Daten beinhalten, sehr wahrscheinlich. Die Verteilung der Wahrscheinlichkeiten der Nachrichten, in diesem Fall der Passwörter des Nutzers, sind also von Nutzer zu Nutzer unterschiedlich. Diese muss aber zur Konstruktion einer guten DTE bekannt sein.

Ebenfalls sollte beachtet werden, dass für jeden Anwendungsbereich, in dem Honey Encryption genutzt werden soll, eine eigene DTE konstruiert werden muss. Ein universaler Ansatz existiert dazu nicht.

% SOLLTE IN FUNKTIONSWEISE BEACHTET WERDEN; EIN PROBLEM IST DAS JA NICHT.
% ----------------------------------------------------------------------------------------------------------
%Was passiert aber, wenn die DTE nicht optimal gewählt ist und es für einen Angreifer erkennbar ist, dass er die richtige Lösung, zum Beispiel die Passwörter des Nutzers im Safe, gefunden hat? Dann fällt die Methode auf eine Brute-Force-Attacke zurück. Der Angreifer muss also jede Passwort-Kombination für den Safe ausprobieren, bis er das richtige Passwort gefunden hat. Die Sicherheit von Honey Encryption ist dann ähnlich der Sicherheit von herkömmlichen Verschlüsselungsmethoden, wie zum Beispiel AES. Zwar gibt es bei Honey Encryption mehrere Passwörter, die aufgrund der Hash-Funktion von Passwort auf Seed-Space die gleiche Nachricht erzeugen, was die Wahrscheinlichkeit erhöht, dass ein solches Passwort bei einem Brute-Force-Angriff gefunden wird. Allerdings wird im Gegensatz zu beispielsweise AES nie direkt angegeben, ob das eingegebene Passwort korrekt ist. Der Angreifer hat also einen enormen Mehraufwand, wenn er überprüfen will, ob er ein korrektes Passwort gefunden hat. Schließlich muss er bei jedem Versuch erneut überprüfen, ob die resultierende Nachricht sinnvoll ist oder nicht. Je schlechter die DTE gewählt ist, desto einfacher fällt es dem Angreifer. Dennoch ist es schwer, die Nachrichten auf Plausibilität zu prüfen.

Neben der Erstellung der DTE ist auch die Speicherung der DTE ein Problem. Da sie eine Funktion ist, die für jeden Anwendungsfall neu erstellt werden muss, muss sie auch für jeden Anwendungsfall gespeichert werden. Gibt es keine Funktion, die aus einem Seed eine Nachricht und zurück berechnen kann, so muss eine Datenstruktur gespeichert werden, die sowohl alle Nachrichten als auch alle Seeds speichern muss. Diese tabellen-ähnliche Struktur ist für einen ausreichend großen Message Space sehr umfangreich. Ist die Anzahl der Nachrichten im Message Space gleich $n$ und die Speicherung einer Nachricht benötigt $m$ Bits, dann werden \emph{mindestens}
$$(\lceil\log_2(n)\rceil + m) \cdot n$$
Bits zur Speicherung der Datenstruktur benötigt.\\
\textbf{Beispiel:} Es existieren $n = 2^{16} = 65536$ mögliche Nachrichten, die gleichverteilt auf den Seed Space abgebildet werden sollen. Dabei soll jeder Nachricht nur ein Seed zugewiesen werden. Für jede Nachricht ist zudem ein String mit maximal 10 ASCII-Zeichen nötig, also ein Speicherbedarf von $m = 10$ Bytes, also $80$ Bits. Die Datenstruktur zum Speichern aller Nachrichten --- mit ihrem Index als Seed --- wird dann mindestens
\begin{align*}
(\lceil\log_2(65536)\rceil + 80) \cdot 65536 &= (16 + 80) \cdot 65536\\
&= 96 \cdot 65536\\
&= 6 291 456
\end{align*}
Bits benötigen. Das sind $786 432$ Bytes, also ungefähr 800 Kilobytes. Um eine Nachricht aus dem Message Space zu verschlüsseln, wird also Speicherplatz für die DTE (inklusive ihrer Datenstruktur) und den resultierenden Ciphertext (nach Abschnitt \ref{sec:schema}) benötigt. Einen String von maximal 10 ASCII-Zeichen aus der Menge der Nachrichten zu verschlüsseln, führt zu einem fast ein Megabyte großen Paket. Gerade das Verschicken von geheimen Nachrichten wird dadurch extrem erschwert, da dieses Paket bei neuen Anwendungsfällen erneut erstellt und übermittelt werden muss. Dieses vergleichsweise große Datenverhältnis zwischen \emph{Verfahren zum Ver- und Entschlüsseln} und \emph{Ciphertext} relativiert sich aber bei steigender Anzahl von übermittelten Ciphertexten. Ist die Länge der Nachrichten relativ lang, werden diese aber auf kurze Seeds abgebildet, so sind die Ciphertexte (abhängig von der gewählten symmetrischen Verschlüsselung) kürzer als bei anderen Verschlüsselungsverfahren. Mit steigender Anzahl an zu speichernden oder zu übertragenden Ciphertexten teilt sich die Größe der Ver- und Entschlüsselungsmethoden auf die einzelnen Cyphertexte auf und es ergeben sich möglicherweise zum Schluss immer noch kleinere zu speichernde Datenmengen als bei anderen Verschlüsselungsverfahren mit gleicher Ciphertextanzahl.

Es sei noch einmal explizit darauf hingewiesen, dass eine solche, wie oben beschriebene Datenstruktur nicht vonnöten ist, wenn sich eine Funktion finden lässt, die die Aufgaben der DTE ohne größeren Speicherplatzbedarf erfüllen kann. Hierfür sei ein Beispiel die beschriebene Verschlüsselung von RSA-Schlüsseln in Abschnitt \ref{sec:dte-rsa}.

%Ein anderer Bereich für Probleme von Honey Encryption ist die Erstellung der Hashfunktion, die vom Key Space auf den Seed Space abbildet. Da die Größe des Seed Spaces für jede Menge von Nachrichten unterschiedlich ist, muss auch die Hashfunktion an die Größe des Seed Spaces angepasst werden. Wie bei jeder Hashfunktion muss ebenfalls sicher gestellt werden, dass Werte aus dem Definitionsbereich durch die Funktion nur in den erlaubten Wertebereich abgebildet werden. Außerhalb des Definitionsbereichs ist das Resultat der Hashfunktion egal. Wird zum Beispiel ein vierstelliger Pin zum Ver- und Entschlüsseln von einer Nachricht verlangt, so muss unsere Hashfunktion lediglich die gültige Menge aller Zeichenkette --- ``0000'' bis ``9999'' --- berücksichtigen. Alle Werte außerhalb dieses Bereichs, beispielsweise Zeichenketten mit mehr oder weniger Zeichen, müssen nicht beachtet werden. Dies stellt zwar eine kleine Erleichterung für den Ersteller der Hashfunktion dar, allerdings ist die Generierung einer guten Hashfunktion, die die Anforderungen aus Abschnitt \ref{sec:schema} erfüllen, wie schon das Erstellen einer guten DTE, extrem aufwändig.

Einer der größten Vorteile von Honey Encryption ist gleichzeitig auch einer ihrer größten Nachteile. Die Tatsache, dass unter Eingabe jedes möglichen Schlüssels ein plausibler Klartext angezeigt wird, könnte dem Nutzererlebnis schaden. Gibt nämlich ein Nutzer das Passwort falsch ein, bekommt er bei herkömmlichen AE- und PBE-Schemata den Hinweis, dass die Eingabe nicht korrekt ist. Bei Honey Encryption wird dem Nutzer diese Hilfestellung nicht gegeben. Der Nutzer weiß gar nicht, ob er das Passwort richtig eingegeben hat, bzw. ob er überhaupt im Besitz des richtigen Passwortes ist (falls ihm das oben erwähnte Paket von einer anderen Person geschickt wurde --- der Schlüssel ist dabei beispielsweise mündlich übertragen worden). Diese Problematik lässt sich nicht einfach lösen. Juels und Ristenpart stellen in \cite{CRCS2014, EURO2014} insgesamt drei Ansätze vor, die sogenannte \emph{Typo-Safety} zu gewährleisten. 

Einerseits könnte zum Ciphertext eine Prüfsumme des Passwortes gespeichert werden. So würden nach einer Fehleingabe des Passwortes die Prüfsummen nicht mehr übereinstimmen und der Nutzer könnte entsprechend gewarnt werden. Logischerweise schränkt dies jedoch den Key Space ein, da die Anzahl der möglichen Schlüssel dezimiert wird. Diese Möglichkeit bietet also weniger Schutz für eine bessere Benutzbarkeit. Allerdings wäre es möglich, diese Technik zum Beispiel im Online-Bereich anzuwenden. Durch eine passend gewählte Anzahl von maximalen Anmeldeversuchen wäre es für einen Dienstleister möglich zu erkennen, wann ein Angreifer versucht, das Passwort für ein Konto zu erraten. Schließlich probiert dieser nur Passwörter, für die die Prüfsumme stimmt. Ein Vertippen des wahren Nutzers beim Passwort würde im wahrscheinlichsten Fall eine falsche Prüfsumme hervorrufen. 

Ein weiterer Ansatz ist die Online-Überprüfung der entschlüsselten Daten. Dies klappt aber nur bei Daten wie Kreditkarten, bei denen der Anbieter überprüfen kann, ob die Nummer eine gültige und zum Kunden gehörende ist. Damit der Anbieter sicherstellen kann, dass ein Kunde und nicht ein Angreifer auf den Dienst zugreift, wäre es nach Juels und Ristenpart möglich, beispielsweise die ersten beiden Ziffern der Kreditkartennummer als Klartext im Honey Encryption-Verfahren zu speichern. Will ein Angreifer die richtige Kreditkartennummer erraten, würde dieser auf jeden Fall die beiden im Klartext gespeicherten Ziffern übernehmen. Bei einem Tippfehler des Nutzers hingegen wären die Ziffern sehr wahrscheinlich nicht korrekt. Der Dienstleister kann also durch die Korrektheit der ersten beiden Ziffern in Verbindung mit einem falschen Rest erkennen, dass mit hoher Wahrscheinlichkeit ein Angriff stattfindet. Stimmen die ersten beiden Ziffern nicht überein, liegt höchstwahrscheinlich ein Schreibfehler vor und der Dienstleister kann den Nutzer bitten, die Passworteingabe erneut zu tätigen. Bei dieser Methode wird der Message Space verkleinert, was auch zu weniger Sicherheit führt. Wie schon bei dem ersten Ansatz sollte diese Methode dementsprechend mit Vorsicht angewendet werden. 

Der dritte und letzte Vorschlag seitens der beiden Autoren ist es, eine Farbe, ein Bild oder ein Muster mit den anderen Informationen zusammen zu verschlüsseln. Diese Komponente wird ebenfalls wieder hergestellt, wenn das richtige Passwort eingegeben wurde, und der Ciphertext wird zu einer anderen, aber plausibel wirkenden Komponente entschlüsselt, wenn es eine Fehleingabe gab (beispielsweise \emph{blau} statt \emph{rot}). Es wird also der größte Vorteil der Honey Encryption angewendet, um dem Nutzer einen Hinweis darauf zu geben, ob er den richtigen Schlüssel eingegeben hat. Ein Angreifer kennt auch das Muster nicht, welches mit gespeichert wurde, der Nutzer hingegen kann sich daran erinnern. Er muss sich allerdings die ursprüngliche Komponente merken, bzw. sie wieder erkennen. Dies ist jedoch leichter, als sich den viel komplizierteren Klartext der Nachricht zu merken, da hierbei das visuelle Gedächtnis des Nutzers angesprochen wird. Diese Methode bringt allerdings nicht nur Vorteile. So wird dem Nutzer bei jeder Verschlüsselung, die er vornimmt, ein neues Muster präsentiert. Bei der Unmenge an Logins, die jeder Mensch heutzutage tätigt, könnte das für Verwirrung sorgen. Dass der Nutzer diese Komponente selbst belegen darf, wäre hier ein Sicherheitsrisiko. Schließlich nutzen viele Menschen für ihre unterschiedlichen Benutzerkonten dasselbe Passwort, weil sie sich nicht mehrere Passwörter merken wollen. Dies wäre bei Farben, Bildern oder Mustern nicht anders. Ein Angreifer kann also die Menge der Nachrichten einschränken, \emph{wenn} er die Wahl des Nutzers bei anderen Verschlüsselungen mithilfe von Honey Encryption kennt. Bei einem einzigen Login, wie zum Beispiel im Falle eines Passwort-Managers, kann diese Methode aber sehr hilfreich sein.

Honey Encryption funktioniert nur dann, wenn ein Angreifer keine Informationen über die verschlüsselte Nachricht besitzt. Das Beispiel im Abschnitt \ref{sec:dte-rsa} macht deutlich, dass Honey Encryption nur so lange eine starke Verschlüsselung für private RSA-Schlüssel bietet, wie der Angreifer den öffentlichen Schlüssel nicht kennt. Ist dieser im Besitz des Angreifers, kann er sehr leicht überprüfen, ob er den richtigen Klartext entschlüsselt hat. Die auf die herkömmliche Verschlüsselungsmethode aufbauende Honey Encryption wäre dann nutzlos. Die Sicherheit würde auf das Level der verwendeten Verschlüsselungsmethode und damit einer PBE-Verschlüsselung zurückfallen.

Ähnliches geschieht auch, wenn die Nachrichten und die Schlüssel korreliert sind und dies dem Angreifer bekannt sind. Schlüssel, die in Abhängigkeit zur Nachricht gewählt werden, helfen dem Angreifer beim Überprüfen der Plausibilität einer Schlüssel-Nachricht-Konstellation. Dadurch kann der Angreifer viele, wenn nicht sogar alle bis auf eine, Kombinationen herausfiltern. Das Gleiche gilt für korrelierte Nachrichten, die mit demselben Schlüssel verschlüsselt wurden. Beispielsweise sind Chatverläufe abhängig voneinander, da sich Nachrichten meist auf die Nachrichten davor beziehen. Ein Angreifer würde dann die Plausibilität des Verlaufs leichter überprüfen können. Unabhängige Nachrichten mit demselben Schlüssel zu verschlüsseln, gilt aber als sicher, da die Nachrichten in jedem Fall keinen Zusammenhang haben.