Kryptografisch beweisen Open-Source-Quellcode des Servers
Ich möchte beweisen, dass der von mir verwendete Quellcode mit der Open-Source-Version identisch ist, die öffentlich verfügbar ist. Meine Idee war es, einen Hash der Open-Source-Version zu veröffentlichen und ihn beim Booten mit dem Hash des bereitgestellten Servers zu vergleichen. Da der Open-Source-Hash jedoch vor der Bereitstellung verfügbar ist, kann ein fehlerhafter Akteur den Hash hart in den Server codieren und die Hash-Funktion vermeiden.
Gibt es eine Möglichkeit, dies zu verhindern? Ich fand heraus, dass Heroku einen ähnlichen Ansatz verwendet, bei dem sie den Commit-Hash abrufen. Ist das manipulationssicher? Und wenn ja, wie unterscheidet sich das von meinem Ansatz?
Antworten
Dies ist im Wesentlichen eine unmögliche Aufgabe.
Wenn Sie Ken Thompsons " Reflections on Trusting Trust " gelesen haben , wissen Sie bereits alles, was ich sagen werde. Wenn nicht, lesen Sie bitte weiter:
Stellen Sie sich vor, ich veröffentliche ein Open-Source-Projekt, das in einer bestimmten Sprache geschrieben ist, nimmt einfach Eingaben entgegen und gibt die Eingaben unverändert zurück - wie eine sehr einfache Version von echo. Sie laden meinen Quellcode herunter, lesen alles durch (es ist sowieso nur ein paar Zeilen lang) und kompilieren es dann. Sie können sicher sein, dass Ihr Programm genau das tut, was Sie denken, oder?
Falsch.
Woher wissen Sie, dass Ihr Compiler keine zusätzlichen Anweisungen hinzugefügt hat, z. B. zu überprüfen, ob der sha-256-Hash der Eingabe vorhanden ist oder nicht, e257f6eccac764b6cea785a0272e34d3dbc56419eac2ad436b9fb4bddcd10494und wenn dies der Fall ist, etwas Unerwartetes zu tun.
Sie könnten sagen, dass dies unwahrscheinlich ist, aber Sie können sich dessen nie ganz sicher sein. Aber vielleicht möchten Sie sich dessen ganz sicher sein, oder? Schließlich möchten Sie kryptografisch beweisen, dass die von Ihnen ausgeführte Software genau das tut, was der Quellcode vorschreibt. Sie überprüfen die Binärdatei also mit einem Reverse-Engineering-Tool wie Ghidra oder IDA Pro. Aber ... wie können Sie sicher sein, dass diese Tools das tun, was Sie denken? Sicher, auf den ersten Blick scheinen sie Ihnen die Binärdatei so zu zeigen, wie sie ist, aber wie können Sie sicher sein, dass sie den böswillig eingefügten Code nicht vor Ihnen verbergen?
Sie könnten vollständig auf vorhandene Compiler verzichten und Ihre eigenen in Bytecode, Byte für Byte, Anweisung für Anweisung schreiben, aber wie würden Sie das tun? Sie benötigen ein Programm, das diese Bytes auf die Festplatte schreibt. Woher wissen Sie, dass diese nicht infiziert sind und einige zusätzliche Bytes schreiben?
Und selbst wenn Sie vollständig auf Programme verzichten und nur eine magnetisierte Nadel und eine ruhige Hand verwenden , wie können Sie sicher sein, dass Ihre CPU tatsächlich die Anweisungen ausführt, die sie ausführen soll, und keine zusätzlichen Anweisungen ausführt? Immerhin laufen CPUs heutzutage mit Mikrocode, was schwer zu überprüfen ist.
In Summe...
... es ist extrem schwer zu beweisen, dass ein Computer das tut, was wir denken. Können Sie einen Hash eines Quellcodes oder eines Bereitstellungsstatus anzeigen, um Ihren Kunden etwas anzuzeigen? Natürlich kannst du. Aber das hat wirklich nichts zu bedeuten.
Wenn ich verstehe, dass Sie richtig fragen, ist das, was Sie fragen, unmöglich, da sich ein Server wie eine Art "Black Box" verhält und normale Benutzer keine Möglichkeit haben, zu überprüfen, was wirklich vor sich geht.
Sie müssen nicht nur beweisen , dass Sie etwas haben, oder dass Sie etwas wissen: Sie würden tatsächlich beweisen müssen, dass Sie verwenden etwas genau wie erwartet, auch jeden einzelnen Schritt und jedes einzelne Detail des Prozesses. Der Nachweis des genauen Verhaltens einer Black Box erfordert viele Analysen und Inspektionen, die normale Benutzer nicht durchführen dürfen.
Mit anderen Worten, um ein einfaches Beispiel zu nennen: StackExchange kann uns auf keinen Fall davon überzeugen, dass Kennwörter mithilfe einer bestimmten Implementierung einer sicheren Hash-Funktion wirklich sicher gespeichert werden. Einige Dinge könnten uns jedoch überzeugen: Zum Beispiel ein kontinuierliches und gründliches Auditsystem, das von einigen externen vertrauenswürdigen Behörden erstellt wurde. Wenn wir dann den externen Prüfern vertrauen können, können wir alles, was sie melden, als Beweis betrachten. Die vollständige Einhaltung wird jedoch niemals vollständig garantiert (die Prüfer sind möglicherweise beschädigt). Wie Sie sehen können, ist das Problem ziemlich kompliziert.
Gute Frage!
Dies ist möglicherweise nicht zu 100% bewiesen, aber Sie können versuchen, der Transparenz näher zu kommen. Was getan werden könnte, ist, ein gewisses Maß an Überwachung des Stapels zu ermöglichen. Zum Beispiel, um öffentlich zu sehen, wie prozesslos (schreibgeschützte Shell?) Und welche Binärdateien (schreibgeschütztes FTP?) Ausgeführt werden. Dann kann jeder die Binärdatei herunterladen, die Prüfsumme durchführen und mit Vendor-One vergleichen.