// DIE VISION
Der „drumherum“-Einwand hat eine radikale Antwort.
Nicht ein paar Türen bewachen, sondern zwischen allen Zuständen sitzen. Nicht einzelne Punkte, sondern die Harmonie des Ganzen prüfen, und sobald eine Sache ins Kritische kippt, wird sie zurückgerollt, auf den letzten sauberen, versiegelten Stand. Das hat echte Verwandte: Integritäts-Wächter über den ganzen Zustand, Invarianten-Prüfung und selbst-heilende Systeme.
Der ehrliche Haken: das Problem verschwindet nicht, es wandert nach oben. Statt „welche Punkte bewache ich“ heißt es dann „wie definiere ich Harmonie für alles“. Ist die Definition lückenhaft, sitzt die Lücke jetzt dort. Man kann nicht alles zurückrollen, und der Insider mit dem Schlüssel gewinnt weiter. Stärkere Vision, kein Zauber, und noch nicht gebaut.
// REIFEGRAD
Kein fehlendes Produkt, sondern ein ehrlich verorteter Punkt auf einem Weg.
Hält unerlaubte Änderungen nach der Wirkung, geprüft gegen drei blinde Angriffswellen. Im Labor, im Speicher.
Der Signier-Schlüssel lebt jetzt in einem virtuellen TPM (Hyper-V), nicht exportierbar. Ein Raspberry Pi als unabhängiger, physisch getrennter Zeuge. Weiterhin Labor, ein einzelner Rechner.
Der Schlüssel in verteilter Hardware, die niemand aus Software auslesen kann, und die Versiegelung auf mehrere unabhängige Parteien verteilt. Baut auf dem 13.07.-Beweis auf, geht aber über eine einzelne VM hinaus.
Nicht mehr einzelne Anker, sondern die Harmonie des gesamten kritischen Zustands, mit Rückrollen. Der große ungebaute Sprung.
// FORSCHUNG · DIE NÄCHSTEN GROSSEN FRAGEN
Vier offene Baustellen, jede ehrlich als Hypothese oder Forschungsvorschlag markiert, keine als fertige Aussage.
Ein erster Schritt ist bereits real: ein Raspberry Pi als physisch getrennter Off-Box-Zeuge hält eine Kopie, die in der beobachteten VM nicht löschbar ist, erprobt am 13.07. Vollständig ausgebaut wäre eine Instanz mit nur minimalen Leserechten, unveränderbarer Ablage und abgesicherter Verbindung, so dass eine Kompromittierung des Zielsystems die Beweise nicht automatisch mitzerstört. Heute prüft der Halter eingehende Beweise noch nicht kryptografisch nach und leert sich bei jedem Neustart, das ist der nächste Schritt, keine gelöste Aufgabe.
Der realistischste nächste Schritt: HALVETH erkennt eine kritische Änderung, dokumentiert sie menschenlesbar, alarmiert eine zuständige Stelle, und ein ausdrücklich autorisierter Mensch löst den Rückbau aus, revisionssicher protokolliert. Die Bausteine dafür existieren bereits einzeln (Vorschlag statt Handlung, exakter Bestätigungscode, siehe Grenzen-Seite), das ganze Modell als durchgängiger, geprüfter Ablauf ist ein Forschungsvorschlag, kein fertiges Feature.
Die Vision eines Zeugen, der eine nicht autorisierte Änderung in einer sehr eng definierten Umgebung selbst verhindert oder sofort zurückführt, ist ein langfristiges Hochrisiko-Forschungsthema, kein Bauplan. Es bräuchte mindestens: formale Definition zulässiger Zustände, sichere Vertrauensanker, eng begrenzte Änderungsfenster, kryptografisch prüfbare Freigaben, Mehrparteien-Freigaben, sichere Rollback-Mechanismen, Schutz vor Replay- und Downgrade-Angriffen, manipulationsresistente Logs, unabhängige Zeitquellen, Fail-safe- und Fail-operational-Konzepte, Notfallabschaltung, Redundanz, nachvollziehbare Governance, externe Sicherheitsprüfung, umfangreiche Fehlalarm-Tests und geklärte Haftungsfragen. Eine verteilte Konsens-Architektur würde nur dann erwähnt, wenn klar ist, welches konkrete Problem sie löst, nie als allgemeines Sicherheitsversprechen.
Die Forschungsfrage: welche zusätzlichen Möglichkeiten entstehen, wenn HALVETH an einer tieferen, vertrauenswürdigen Systemgrenze zwischen relevanten Ereignissen sitzt? Mögliche Vorteile stehen neben echten neuen Risiken: eine Kernel-Schwachstelle würde alles betreffen, fehlerhafte Updates und Treibersignaturen würden neu zählen, Performance und Stabilität wären betroffen. Notwendig wären formale Verifikation, reproduzierbare Builds und unabhängige Audits, mit unterschiedlichen Antworten für Linux/Ubuntu- und Windows-Architekturen. Klar dazu: das erzeugt keine 98 Prozent Sicherheit und macht keine andere Sicherheitsmaßnahme überflüssig. Microsoft, Canonical/Ubuntu, Hochschulen oder Sicherheitsforschung sind hier ausschließlich als mögliche zukünftige Adressaten einer technischen Übergabe gemeint, nicht als bestehende Partner.
Der vollständige Übergabe-Stand mit allen Quellen, Grenzen und offenen Fragen steht im Research Handoff.
// EHRLICHE FRAGEN
Ja, ständig. SolarWinds (2020) signierte Schadcode mit einem echten Schlüssel. Die xz-Hintertür (2024) wurde als „legitim“ eingeschleust. Ransomware manipuliert am Ende fast immer Backups und Boot-Konfiguration. Das alte Beispiel ist nur das Bild, die Klasse ist aktuell.
HALVETH fängt den Umweg nicht, das ist Aufgabe anderer Werkzeuge. Aber jeder Umweg hat ein Ziel: am Ende will der Angreifer etwas Änderungsfestes tun. Genau dort steht HALVETH. Es verlagert den Kampf von „kein Reinkommen“ auf „keine Endgültigkeit ohne echten Schlüssel“.
Es gibt keine unknackbare Mauer, für nichts. HALVETH macht die letzte, folgenschwere Tat teurer: der Angreifer braucht den echten Schlüssel. In der heutigen Form ist das ein Schlüssel, also noch schwach. Erst mit Hardware und mehreren Parteien wird es teuer genug, um zu zählen. Genau das steht ehrlich in der Roadmap.
// SCHRIFT
In Vorbereitung ist ein Whitepaper, das die Idee, die Philosophie und den ehrlichen Stand beschreibt. Es erzählt, was HALVETH fragt und warum, wo die Antwort heute trägt und wo sie offen bleibt. Nicht enthalten ist das Rezept: kein Mechanismus, keine Bauanleitung.
Whitepaper · in Vorbereitung// HERKUNFT
Ehrlich getrennt: das Folgende ist persönliche Inspiration, nicht Teil der Sicherheits-Behauptung oben. Es erklärt nur, warum die Form so aussieht. Am Anfang stand ein Gedanke über Realität als Folge von Zuständen, in Schichten, und dass das Entscheidende nicht in den Dingen liegt, sondern im Dazwischen, im Übergang. Aus diesem Bild wuchs die Frage: was, wenn man genau diesen Übergang bewachen könnte?
Ich wollte in Richtung der 1 gehen, ohne je zu behaupten, ich hätte sie erreicht.
Diese Verbindung ist für mich sinnstiftend, aber sie ist keine technische Begründung. HALVETH steht oben auf Sicherheits-Logik allein. Die Philosophie lebt in ihrem eigenen Zuhause. Zur Forschung „Realität als Zustand“ →
Ich bin kein ausgebildeter Programmierer. HALVETH ist aus Intuition, aus Bildern und aus enger Zusammenarbeit mit einer KI entstanden, nicht aus einer Informatik-Ausbildung. Genau deshalb ist mir Nachprüfbarkeit wichtiger als ein glattes Verkaufsversprechen: was hier steht, ist der Stand einer Eigenprüfung, offen für jeden, der einen Fehler darin findet. Das wäre kein Rückschlag, sondern genau der Sinn der Veröffentlichung. Der nächste Schritt, eine tiefere Verankerung im Betriebssystem, liegt jetzt nicht mehr allein in meiner Hand. Deshalb veröffentliche ich den Stand so transparent, dass andere ihn prüfen, reproduzieren und weiterführen können.
Der Mensch dahinter · Juri Janovski
// NACHBARSCHAFT
Getrennt gehalten, nur nachbarschaftlich erwähnt.
// SCHWESTERPROJEKT
Eine deutschsprachige Lern-App, um Programmieren von 0 an zu lernen. Ein eigenes Projekt, das nichts mit dem Torwart zu tun hat.
// FORSCHUNG
Die Wurzel-Hypothese hinter HALVETH, mit Livemodell und Wissenschaftsseite. Zur Forschung →