In welcher Beziehung steht die Theoretische Informatik zur Sicherheit?

Wenn ich an unsichere Software denke, denke ich, dass sie "zu nützlich" ist und von einem Angreifer missbraucht werden kann. In gewissem Sinne bedeutet das Sichern von Software, dass Software weniger nützlich ist. In der Theoretischen Informatik arbeiten Sie nicht mit der realen Welt. Gibt es also Sicherheitsbedenken bei der Arbeit mit reiner Theorie? Oder auf der anderen Seite der Medaille: Beeinflusst die Theoretische Informatik die reale Welt der Menschen, die gehackt werden? Wenn ja, welche Sicherheitsthemen gelten als theoretisch?

Ihre Intuition, dass "Unsicherheit" auf Software zurückzuführen ist, die "zu nützlich" ist, ist in gewissem Sinne richtig. Es gibt eine große und wachsende theoretische Literatur zum Thema "Differential Privacy", die Ihre Intuition formalisiert. Siehe zum Beispiel hier: research.microsoft.com/en-us/projects/databaseprivacy/dwork.pdf

Hier stellen wir uns die Eingabe in einen Algorithmus als "Datenbank" vor, und der Algorithmus ist "unsicher", wenn er zu viele Informationen über die Daten einer Person in der Datenbank enthält. Ein Algorithmus ist -differenziell privat, wenn die Ausgabe des Algorithmus nicht stark von einer Eingabe abhängt: Insbesondere sollte das Ändern eines einzelnen Eintrags in der Eingabedatenbank die Wahrscheinlichkeit einer Ausgabe des Algorithmus nur um höchstens ein ändern Faktor.e $\epsilon$$e^\epsilon$

Wenn Sie einen Algorithmus privat machen, ist dies natürlich weniger nützlich: Ein differenziell privater Algorithmus erzeugt Ausgaben, die überhaupt nicht von den Eingaben abhängen! Es stellt sich jedoch heraus, dass Sie versuchen können, den Kompromiss zwischen Datenschutz und Nutzen sorgfältig auszugleichen, und sehr private Algorithmen erhalten können, die dennoch nicht trivial nützlich sind.$0$

Auf verschiedener Weise:

• Kryptographie (eine enorm breite Verallgemeinerung der Informationssicherheit, die von Datenschutz bis Verschlüsselung reicht)
• Formale Überprüfung des Codes (siehe auch das seL4-Projekt )
• Fehlertoleranz und Fehlerkorrektur
• Theoretische Möglichkeiten zur Verhinderung von Malware (einer anderen ), einschließlich Codesignatur
• Manipulationssichere Hardware
• Punktverschleierung (ein theoretischer Ansatz zur informationstheoretisch sicheren Codeverschleierung)
• Maschinelles Lernen hilft, Hackversuche in Echtzeit zu verhindern und zu alarmieren (denken Sie an Active Wardens und Spam Filtering ).
• Viel viel mehr.

Betrachten Sie das Beispiel Wired Equivalent Privacy , das in der Realität nicht der Fall ist : Aufgrund peinlich grundlegender theoretischer Versehen (pdf) ist WEP innerhalb von Minuten knackbar.

Bruce Schneier witzelte in „Warum Computer unsicher sind“

Sicherheitstechnik beinhaltet die Programmierung von Satans Computer.

Und Satans Computer ist schwer zu testen.

Es gibt eine Menge realer Motivation für das Studium von Streaming-Algorithmen, die aus der Erkennung von Netzwerkeinbrüchen stammen. Das folgende Papier verwendet Streaming-Algorithmen für die empirische Entropie, um Anomolien in Ihrem Netzwerkverkehr zu erkennen.

Yu Gu, Andrew McCallum und Don Towsley. Erkennen von Anomalien im Netzwerkverkehr mithilfe der maximalen Entropieschätzung. In IMC '05: Proceedings der 5. ACM SIGCOMM-Konferenz zur Internetmessung, Seiten 1–6, 2005

Im Gegensatz zu den anderen Antworten handelt es sich hier eher um "Dinge, über die wir uns Sorgen machen sollten, wenn wir sagen, dass etwas" nachweislich sicher "ist", als um Orte, an denen TCS für die Sicherheit verwendet wurde. Damit wird die erste Frage der Sicherheitsbedenken bei der Arbeit mit der Theorie angesprochen.

Wie Hacker sagen, sind theoretische Ergebnisse oft tangential zur realen Sicherheit. Diese Art von Argumentation wurde von Alfred Menezes und Neal Koblitz in ihrer Reihe von " Another Look " -Papieren theoretischer, wissenschaftlicher und präziser formuliert (Warnung: Die Website scheint mir ein wenig konfrontativ zu sein, aber ich denke, die Grundidee, Annahmen in Frage zu stellen ist sehr wichtig). Sie weisen auf Schwachstellen bei Standardannahmen in der Kryptographie hin, selbst in wegweisenden Arbeiten.

Einige Beispiele (Zitieren / Paraphrasieren einiger Punkte von ihrer Site):

1. Ein Sicherheitssatz ist bedingt - er setzt die Unlösbarkeit eines mathematischen Problems voraus.

2. Oft wird die Unlösbarkeitsannahme für ein kompliziertes und erfundenes Problem gemacht: In einigen Fällen entspricht das Problem trivial dem Kryptoanalyseproblem für das Protokoll, dessen Sicherheit "bewiesen" wird.

3. Manchmal hat ein Proof eine große Dichtheitslücke, aber es werden immer noch Parametergrößen empfohlen, als ob der Proof dicht gewesen wäre. In solchen Fällen gibt der Beweis normalerweise eine nutzlose Untergrenze für die Laufzeit eines erfolgreichen Angriffs. Darüber hinaus bietet ein asymptotisches Ergebnis nicht unbedingt eine Sicherheit für Parameter in dem in der Praxis verwendeten Bereich.

4. Ein Sicherheitssatz verwendet ein bestimmtes Sicherheitsmodell. Bestimmte Angriffe - insbesondere Seitenkanalangriffe - sind sehr schwer zu modellieren, und die vorgeschlagenen Modelle sind absolut unzureichend.

Theoremprüfer wurden in gewissem Umfang verwendet, um die Richtigkeit von Software, Hardware und Protokollen zu beweisen. Siehe zum Beispiel hier oder hier .

Das Problem, dass Daten auf unerwünschte Weise durch Programme fließen (und somit ein potenzielles Leck verursachen), wurde theoretisch unter Verwendung des Begriffs (Nicht-) Interferenz modelliert. erhalten Zeiger hier .

Entscheidbarkeit ist ein zentrales Anliegen in der Programmiersprachenforschung. Das heißt, es werden große Anstrengungen unternommen, um Programmiersprachen zu erstellen, die nur Code akzeptieren, der bestimmte Eigenschaften erfüllt. Typische statische Sprachen bieten nur schwache Garantien, z. B. das Ablehnen eines Programms, wenn bestimmte Methoden nicht vorhanden sind. Stellen Sie sich jedoch vor, die Sprache könnte auch Programme ausgeben, die beispielsweise Mutexe nicht ordnungsgemäß verwenden oder versuchen, über das Ende der Speicherbereiche hinaus zu lesen. Es ist klar, dass Entscheidbarkeitsprobleme schnell auftreten (einfachstes Szenario: Geben Sie an, dass Ihr Compiler nur das Beenden von Programmen akzeptieren soll), und es gibt sicherlich Effizienzprobleme (der ML-Typprüfer hat doppelt exponentielle Fälle).

In jedem Fall ist die PL-Forschungsgemeinschaft sehr an Sicherheit interessiert (vertrauen Sie darauf, dass Ihr Browser beliebigen Fremdcode ausführt?!), Und ihre Fragen führen zu vielen Fragen der klassischen CS-Theorie.