Theoretischer Begriff der White-Box

Oct 02 2020

Gibt es eine theoretisch sichere Vorstellung von White-Box?

Ich habe kürzlich über White-Box [ 1 , 2 , 3 ] gelesen . Es scheint, dass White-Box sich mit Code-Verschleierung befasst und nicht bekannt ist, ob es eine perfekte White-Box gibt.

Ich bin neugierig auf theoretische Begriffe dahinter. Für eine Stream-Chiffre lautet der theoretische Begriff PRF. Für die Blockverschlüsselung ist es PRP. Bei einer Hash-Funktion handelt es sich um eine Einwegfunktion. Gibt es etwas Vergleichbares für White-Box?

Ich bin auf der Suche nach etwas, das nicht unbedingt praktisch ist, aber wir können tatsächlich zeigen, dass dies eine perfekte White-Box erreicht, wie ein wirklich verschlüsselter Code oder so.

AKTUALISIEREN. Ich erinnere mich vage, etwas in der Zeile von gelesen zu haben

White-Box wäre möglich, wenn ein sehr großer Speicher vorhanden wäre. Der Speicher könnte als Nachschlagetabelle mit den Klartexten als Nachschlageschlüsseln und den Chiffretexten als Nachschlagewerten geladen werden. Da der Verschlüsselungsschlüssel nicht in der Nachschlagetabelle enthalten ist (er wurde zuvor zum Erstellen der Nachschlagetabelle verwendet), kann er nicht wiederhergestellt werden, eine Verschlüsselung wäre jedoch weiterhin möglich.

Aber ich konnte die Quelle nicht abrufen. Weiß jemand etwas darüber?

Antworten

6 Serpent27 Oct 02 2020 at 07:28

Da wir dies vermutlich als Kryptofrage und nicht als Reverse Engineering unterhalten, werde ich eine formelle Antwort geben.

Der allgemein akzeptierte Zweck der White-Box-Krypto besteht darin, den Schlüssel zu verbergen, der zum Ausführen einer kryptografischen Operation verwendet wird. Das Problem bei einem solchen System ist, dass der Algorithmus selbst den Schlüssel kennen muss; Es ist ziemlich schwierig, etwas mit einem Schlüssel, den Sie nicht kennen, erfolgreich zu verschlüsseln oder zu entschlüsseln.

In jedem Fall, in dem der Algorithmus den Schlüssel kennt, mit dem kryptografische Operationen ausgeführt werden, kann ein Reverse Engineer den Schlüssel einfach aus dem Speicher des Algorithmus abrufen. Sie können versuchen, den Versuch des Reverse Engineers zu behindern, aber Reverse Engineering ist kein NP-vollständiges Problem. Es ist eigentlich ganz einfach für jemanden mit den notwendigen Fähigkeiten.

Vielleicht laden Sie den Schlüssel nicht, aber eine Einwegoperation basierend auf dem Schlüssel ... Herzlichen Glückwunsch! Sie verwenden einfach einen anderen Schlüssel und haben keinerlei Sicherheitseigenschaften geändert.

Angenommen, Sie verwenden eine Eingabe, führen einige nicht entzifferbare Berechnungen durch und verwenden den resultierenden Wert als Schlüssel ... Herzlichen Glückwunsch! Sie haben auch nichts getan, da die gesamte Aufgabe eines Reverse Engineers darin besteht, scheinbar "nicht entschlüsselbaren" Code zu entschlüsseln, und sie sind in der Regel recht gut darin.

Außerdem hindert sie nichts daran, die Berechnungen einfach selbst auszuführen. Sie müssen den Code nicht verstehen, um ihn auszuführen. Sie können verschiedene Techniken ausprobieren, um dies zu verhindern. Dies wird als Anti-Reverse-Engineering bezeichnet. Aber es ist weder theoretisch noch praktisch in der Lage, einen anständigen Reverse Engineer aufzuhalten.

Vor ein paar Tagen wurde ich mit dem Reverse Engineering eines Malware-Beispiels beauftragt, das versuchte, ein solches White-Box-System zu verwenden, um zu verhindern, dass ich verstehe, was es tut. Ich habe jede verschlüsselte Zeichenfolge im Beispiel entschlüsselt und muss derzeit die Genehmigung zum Hochladen des rückentwickelten Beispiels auf meinen öffentlichen GitHub ausstehen.

Kurz gesagt, White-Box-Krypto funktioniert nicht.

6 fgrieu Oct 02 2020 at 06:53

Achtung: Die White-Box-Kryptographie befindet sich außerhalb meiner Komfortzone und ich habe die neuesten Entwicklungen auf diesem Gebiet nicht verfolgt. Das Folgende ist meine aktuelle Meinung, die ich in der Hoffnung präsentiere, sie in Frage zu stellen und dabei zu lernen.

Aus meiner Sicht besteht das traditionelle Ziel der White-Box-Kryptographie (und das, das die Branche am liebsten hätte) darin, Software zu entwickeln, die eine standardmäßige kryptografische Transformation mit öffentlichem Schlüssel (z. B. ein PRP mit Schlüssel, idealerweise AES) mit einer bestimmten Instanz von berechnet In die Software eingebetteter geheimer Schlüssel, so dass durch das Durchsickern der Software der Schlüssel nicht verloren geht.

Ich kenne keine ernsthafte Behauptung, dass dies überhaupt erreicht werden kann. Im Gegenteil, WBC-Wettbewerbe, die sich mit AES als PRP auf das oben genannte Ziel konzentrierten, haben AFAIK alle mit einer schnellen Schlüsselextraktion beendet.

In Bezug auf dieses Ziel scheinen wir nicht einmal praktisch sichere WBC und damit viel weniger theoretisch sichere WBC zu haben. Im Gegensatz zu der besseren Situation in der symmetrischen Krypto, wo wir praktisch sichere PRPs und PRFs haben, aber wohl keine theoretisch sichere Konstruktion nach ersten Prinzipien.

Eine Variante von WBC wie oben definiert ist jedoch praktisch machbar, wenn wir die Schlüsseltransformation unter Berücksichtigung von WBC konstruieren lassen: Zum Beispiel ist es trivial, eine praktisch sichere WBC-Implementierung des AES-256-ähnlichen WES-256 durchzuführen, definiert als: $$\begin{align} \text{WES-256}:\quad&\{0,1\}^{256}\times\{0,1\}^{128}\to\{0,1\}^{128}\\ &P\mapsto\text{WES-256}(K,P)\underset{\text{def}}=\text{AES-256}(\text{SHA-256}(K),P) \end{align}$$

Wenn wir diese Variantendefinition verwenden, folgt die Sicherheit von WBC der von traditionelleren Konstrukten.

Mein Fazit ist, dass ich keine gute Definition des theoretischen Ziels von WBC kenne und daher die Frage nicht beantworten kann!

2 Fractalic Oct 04 2020 at 13:50

Nicht die Hauptantwort, aber etwas Nützliches.

Es gibt einen Begriff der Inkomprimierbarkeit , der erfordert, dass es schwierig ist, eine absichtlich große White-Box-Implementierung sinnvoll zu komprimieren. Während es für vorhandene Chiffren schwer zu erreichen ist, ist es einfach, neue symmetrische Chiffren mit inkompressiblen Implementierungen zu entwerfen.

Warum? Die Hauptidee besteht wahrscheinlich darin, Code-Lifting-Angriffe zu verhindern: Das Extrahieren von beispielsweise 1 GB von einem Mobiltelefon ist viel schwieriger als 128 Bit des geheimen Schlüssels. Insbesondere bei einem massiven Angriff, beispielsweise durch Malware. In der Praxis zögert die Industrie natürlich, solche Implementierungen zu verwenden, da niemand 1 GB Speicherplatz für nichts essen möchte.

Wie? Stellen Sie sich beispielsweise ein Feistel-Netzwerk vor, in dem Feistel-Funktionen abgeschnittene AES-Instanzen sind (mithilfe des Hauptschlüssels oder besser abgeleitet davon). In der inkompressiblen Implementierung wird diese Funktion als Nachschlagetabelle eingefügt (wir kürzen sie, um die gewünschte Größe zu erhalten). Es ist nicht schwer zu zeigen, dass das Komprimieren des Schemas eine Nicht-Zufälligkeit von AES impliziert, sodass die Inkomprimierbarkeit auf die AES-Sicherheit reduziert wird.