Kann eine vollständig homomorphe Verschlüsselung verwendet werden, um die Ausführung von Code zu vergessen?

Nachdem ich diese Antwort vor einiger Zeit gelesen hatte, interessierte ich mich für eine vollständig homomorphe Verschlüsselung. Nachdem ich die Einleitung zu Gentrys These gelesen hatte, fragte ich mich, ob sein Verschlüsselungsschema für die unbewusste Codeausführung verwendet werden könnte, wie im dritten Absatz definiert.

In einem vollständig homomorphen Verschlüsselungsschema verschlüsseln wir normalerweise einige Daten und senden sie an eine feindliche Umgebung, in der eine bestimmte Funktion für die Daten berechnet wird, deren Ergebnis dann zurückgesendet (verschlüsselt) wird, ohne dass der Gegner herausfindet, was die empfangenen Daten sind oder Das Ergebnis der Funktion ist.

Mit vergessener Codeausführung meine ich, dass wir einen Teil des Codes verschlüsseln , um ein Problem zu lösen, und ihn an eine feindliche Umgebung senden. Der Gegner möchte , um zu lösen , aber wir möchten nicht, dass er weiß, wie funktioniert. Wenn er eine Eingabe für , kann er verschlüsseln und dann (ein Verschlüsselungsschema auf) mit , was dann die (nicht verschlüsselte) Ausgabe (die Lösung von für die Eingabe ) zurückgibtP C P C I P I C I O P $C$$P$$C$$P$$C$$I$$P$$I$$C$$I$$O$$P$$I$). Das Verschlüsselungsschema stellt sicher, dass der Gegner nie herausfindet, wie der Code funktioniert, dh für ihn funktioniert er wie ein Orakel.

Die hauptsächliche praktische Verwendung (ich kann mir vorstellen) für ein solches Verschlüsselungsschema wäre, Piraterie schwieriger oder sogar unmöglich zu machen.

Der Grund, warum ich denke, dass dies mit einem vollständig homomorphen Verschlüsselungsschema möglich sein könnte, ist, dass wir beliebige Schaltungen für verschlüsselte Daten ausführen können, insbesondere für eine universelle Turing-Maschine. Wir könnten dann den Code verschlüsseln, als ob es Daten wären, und dann die Schaltung für eine universelle Turing-Maschine für diese verschlüsselten Daten verwenden, um den Code auszuführen.

Ich stelle das hier als Frage, weil ich nicht weiß, ob diese Idee brauchbar ist: Ich bin nie viel weiter gekommen als bis zur Einführung von Gentrys These, und mein Wissen über Kryptographie ist begrenzt. Außerdem weiß ich nicht, ob es bereits einen häufig verwendeten Begriff für die unbeabsichtigte Codeausführung gibt: Ich habe versucht, Google nach der Idee zu durchsuchen, aber nicht den richtigen Begriff gefunden.

Ich kann mir mehrere Probleme vorstellen, die bei diesem Ansatz Probleme verursachen können. Erstens würde das Ergebnis der Berechnung ( ) verschlüsselt , wenn wir eine vollständig homomorphe Verschlüsselung ohne Änderung verwenden . Es wäre daher nutzlos für den Gegner, der Ihren Code verwenden möchte, um zu lösen . Dies könnte zum Beispiel für Cloud Computing noch nützlich sein, aber das ist nicht das, was ich erreichen möchte.$O$$P$

Zweitens, weil wir Schaltkreise und keine willkürlichen Turing-Maschinen verwenden, können wir keine willkürlichen Speichermengen verwenden: Wir sind auf eine vorbestimmte Speichermenge beschränkt. Das heißt, wenn wir ein Programm auf diese Weise ausführen möchten, ist der Speicherbedarf immer derselbe, nämlich die maximale Speichernutzung.

Schließlich würden die beteiligten Konstanten mit ziemlicher Sicherheit jeden praktischen Einsatz eines solchen Systems zunichte machen, aber ich halte die Idee dennoch für interessant.

Leider gibt es ein Ergebnis, das theoretisch die "unbewusste Ausführung von Code" verbietet:

Boas Barak, Oded Goldreich, Russell Impagliazzo, Steven Rudich, Amit Sahai, Salil Vadhan und Ke Yang. Über die ( Un- ) Möglichkeit der Verschleierung von Programmen , ADVANCES IN CRYPTOLOGY - CRYPTO 2001.

Hier sind die Links:

• http://www.wisdom.weizmann.ac.il/~oded/p_obfuscate.html
• http://eprint.iacr.org/2001/069
• http://www.springerlink.com/content/telalqdcx3n600uf/

Das Abstract lautet:

Informell ist ein Obfuscator ein (effizienter, probabilistischer) "Compiler", der ein Programm (oder eine Schaltung) als Eingabe nimmt und ein neues Programm , das die gleiche Funktionalität wie hat, jedoch "nicht lesbar" ist " auf gewisse Art und Weise. Obfuscatoren würden, falls vorhanden, eine Vielzahl von kryptografischen und komplexitätstheoretischen Anwendungen haben, die von Softwareschutz über homomorphe Verschlüsselung bis zu komplexitätstheoretischen Analoga von Rices Theorem reichen. Die meisten dieser Anwendungen basieren auf einer Interpretation der Unlesbarkeitsbedingung in der Verschleierung, die besagt, dass eine "virtuelle Blackbox" ist, in dem Sinne, dass alles, was man effizient berechnen kann,P O ( P ) P O ( P ) O ( P ) $\cal O$$P$$\cal O(P)$$P$$\cal O(P)$$\cal O(P)$könnte man auch einen gegebenen Orakelzugriff auf effizient berechnen .$P$

In dieser Arbeit initiieren wir eine theoretische Untersuchung der Verschleierung. Unser Hauptergebnis ist, dass selbst bei sehr schwachen Formalisierungen der obigen Intuition eine Verschleierung unmöglich ist. Wir beweisen dies durch die Konstruktion einer Familie von Funktionen , die in folgendem Sinne inhärent unauffällig sind: Es gibt ein Prädikat so dass (a) für jedes Programm, das eine Funktion in berechnet , der Wert effizient berechnet werden, noch (b) gegeben Oracle Zugriff auf eine (zufällig ausgewählt) Funktion in , kein effizienten Algorithmus berechnet viel besser als zufällige erraten.π f F π ( f ) f F π ( f $\cal F$$\pi$$f$$\cal F$$\pi(f)$$f$$\cal F$$\pi(f)$

Wir erweitern unsere Unmöglichkeit Ergebnis in einer Reihe von Möglichkeiten, darunter auch obfuscators , dass (a) nicht notwendigerweise berechenbare in Polynomialzeit, (b) nur etwa die Funktionalität erhalten, und (c) nur für sehr eingeschränkte Rechenmodelle zur Arbeit benötigen ). Wir schließen auch mehrere mögliche Anwendungen von Verschleierungsmitteln aus, indem wir "nicht verschleierungsfähige" Signaturschemata, Verschlüsselungsschemata und Pseudozufallsfunktionsfamilien konstruieren.$\rm{TC}$ $0$

Während eine vollständig homomorphe Verschlüsselung sehr nützlich ist, um Code zwischen mehreren nicht vertrauenswürdigen Parteien auszuführen (siehe z. B. dieses Dokument ), benötigen Sie eine Art Interaktion, wenn die Partei, die die verschlüsselte Ausgabe berechnet, diese an die Partei sendet, die den geheimen Schlüssel kennt .

Der Begriff, nach dem Sie suchen, klingt verdächtig ähnlich wie die Verschleierung von Software, für die wir das oben erwähnte Unmöglichkeitsergebnis bewiesen haben. Ich habe auch einmal einen informellen Überblick über dieses Papier geschrieben, den manche Leute vielleicht nützlich finden.

Angesichts dieses Unmöglichkeitsergebnisses gibt es zwei (nicht disjunkte) Möglichkeiten, die Definition zu lockern: Entweder durch Einschränkung der Klassen von Programmen / Funktionen, die verschleiert werden sollen, oder durch Verschleierung des Sicherheitsbegriffs.

Der zweite Ansatz ist vielleicht möglich, und wir bemerken in unserer Arbeit einige schwache, verschleierungsähnliche Begriffe. Beachten Sie jedoch, dass unser Angriff den ursprünglichen Quellcode eines Programms vollständig wiederherstellt, unabhängig davon, wie verschleiert es ist. Sie müssten also irgendwie eine Sicherheitsdefinition erstellen, die für den Fall unserer Gegenbeispiele trivialisiert ist.

Der erste Ansatz wurde für alle eingeschränkten Funktionalitäten (z. B. Punktfunktionen) durchgeführt, aber auch hier muss sichergestellt werden, dass die Klasse unser Gegenbeispiel nicht enthält, was ungefähr bedeutet, dass sie keine Pseudozufallsfunktionen enthalten sollte.