Die „Trust-Transfer“-Klemme für verifizierbare KI
Als ich technische Dokumentation gelesen habe, bin ich auf einen Satz gestoßen: Bei jedem Schlussfolgern erhält man „verifizierbare Beweise“, und der eigentliche Ankerpunkt des Vertrauens liegt am Ende bei der Signatur von AWS – nicht bei der Mathematik.
Dieser Satz hat mich kurz innehalten lassen. Wenn ein TEE-Node auf der Kette registriert wird, besteht die Verifizierungslogik darin, zu prüfen, ob der Beweis von der AWS-Nitro-Root-CA signiert wurde. Ganz offen gesagt: Das ist kein „ohne Vertrauen“, sondern ein Transfer des Vertrauens vom Projektträger zu AWS.
Noch beunruhigender ist die Sicherheitsgeschichte der TEE selbst. Intel SGX wurde 2015 eingeführt und 2022 von Intel eingestellt – in diesen 7 Jahren gab es so viele Schwachstellen, dass es auf „Sieb“-Niveau gebracht wurde. L1TF/Foreshadow konnten über Side-Channels direkt Daten aus dem SGX-Isolationsbereich auslesen, und Plundervolt konnte die Integrität des Isolationsbereichs durch Manipulation der Spannung direkt zerstören.
Die Verifikationsebene von OPG ist nicht robuster als die ihrer Vorgänger. Aber am meisten beunruhigt die Inhaber nicht einmal die Hardware-Schwachstelle an sich, sondern ein noch grundlegenderes Logikproblem: Ein TEE kann beweisen, dass „Code im Enklave läuft und nicht manipuliert wurde“, aber es kann nicht beweisen, dass „dieser Code selbst keine Bugs hat“. Wenn auf der Seite des Schlussfolgerungs-Nodes die auszuführende Software logische Schwachstellen aufweist, signiert und veröffentlicht das TEE sie trotzdem auf der Kette.
Die „verifizierbaren Beweise“, die du erhältst, verifizieren nur „der Code wurde nicht von jemandem angefasst“, nicht aber „der Code rechnet richtig“. Sobald ein TEE kompromittiert wird, sind die Privatsphäre und Integrität der gesamten Verifikationsebene in einem Moment dahin.
Du vertraust nicht der Mathematik, sondern einem Chip, der jederzeit Probleme bereiten kann.
#OPG $OPG @OpenGradient $BTC
Als ich technische Dokumentation gelesen habe, bin ich auf einen Satz gestoßen: Bei jedem Schlussfolgern erhält man „verifizierbare Beweise“, und der eigentliche Ankerpunkt des Vertrauens liegt am Ende bei der Signatur von AWS – nicht bei der Mathematik.
Dieser Satz hat mich kurz innehalten lassen. Wenn ein TEE-Node auf der Kette registriert wird, besteht die Verifizierungslogik darin, zu prüfen, ob der Beweis von der AWS-Nitro-Root-CA signiert wurde. Ganz offen gesagt: Das ist kein „ohne Vertrauen“, sondern ein Transfer des Vertrauens vom Projektträger zu AWS.
Noch beunruhigender ist die Sicherheitsgeschichte der TEE selbst. Intel SGX wurde 2015 eingeführt und 2022 von Intel eingestellt – in diesen 7 Jahren gab es so viele Schwachstellen, dass es auf „Sieb“-Niveau gebracht wurde. L1TF/Foreshadow konnten über Side-Channels direkt Daten aus dem SGX-Isolationsbereich auslesen, und Plundervolt konnte die Integrität des Isolationsbereichs durch Manipulation der Spannung direkt zerstören.
Die Verifikationsebene von OPG ist nicht robuster als die ihrer Vorgänger. Aber am meisten beunruhigt die Inhaber nicht einmal die Hardware-Schwachstelle an sich, sondern ein noch grundlegenderes Logikproblem: Ein TEE kann beweisen, dass „Code im Enklave läuft und nicht manipuliert wurde“, aber es kann nicht beweisen, dass „dieser Code selbst keine Bugs hat“. Wenn auf der Seite des Schlussfolgerungs-Nodes die auszuführende Software logische Schwachstellen aufweist, signiert und veröffentlicht das TEE sie trotzdem auf der Kette.
Die „verifizierbaren Beweise“, die du erhältst, verifizieren nur „der Code wurde nicht von jemandem angefasst“, nicht aber „der Code rechnet richtig“. Sobald ein TEE kompromittiert wird, sind die Privatsphäre und Integrität der gesamten Verifikationsebene in einem Moment dahin.
Du vertraust nicht der Mathematik, sondern einem Chip, der jederzeit Probleme bereiten kann.
#OPG $OPG @OpenGradient $BTC