// RESEARCH HANDOFF
Übergabe des aktuellen Forschungsstands: was untersucht wurde, was bewiesen ist, was offen bleibt, und was die nächste Forschungsstufe braucht.
In fast allen Systemen gilt: sobald eine Änderung ausgeführt wurde, zählt sie sofort als wahr. Es gibt keinen Abstand zwischen „es ist passiert“ und „es gilt“. Genau diese Null-Distanz nutzen reale Angriffe aus, von signiertem Schadcode (SolarWinds, 2020) bis zu als legitim eingeschleusten Hintertüren (xz, 2024). Die Forschungsfrage: lässt sich für eine kleine Zahl kritischer Zustände ein unabhängiger, unbestechlicher Zeuge bauen, der zwischen „ausgeführt“ und „gültig“ sitzt, jede unerlaubte Änderung an diesen Zuständen aufdeckt und unfälschbar beweist, ohne selbst manipulierbar zu sein?
HALVETH ist kein klassischer Wächter, der vor einer Tür steht. HALVETH ist ein unabhängiger Zeuge, der zwischen zwei Zuständen sitzt: dem Zustand vor einer Änderung und dem Zustand danach. Er beobachtet wenige, bewusst eng gewählte „Kronjuwelen“ (Signaturschlüssel, Zertifikat-Speicher, Boot-Messwerte, Integritäts-Baselines), stellt Abweichungen zwischen zwei Zuständen fest, dokumentiert sie signiert und hash-verkettet, und schlägt eine Rückführung vor. Er verhindert Angriffe nicht, er macht sie nicht folgenlos leugbar. Diese Trennung ist bewusst: ein System, das „unfehlbar verhindert“ behauptet, würde eine eigene Kompromittierung nicht bemerken.
Vollständige Tabelle mit Quellen, Daten und Erkenntnisklassen: Audit-Berichte und Ergebnisse.
Blinde Rot-Team-Läufe (Angreifer- und Richter-Rolle nicht aus derselben Konstruktion), gepaarte Fallen (jeder Angriff hat einen legitimen Zwilling zur Fehlalarm-Kontrolle), live erneut ausgeführte Testsuiten, unabhängiges Nachrechnen kryptografischer Hashes und Signaturen gegen die rohen Beweisdateien. Keine externe Prüfung durch Dritte.
HALVETH erkennt keine Absicht, nur ungültige oder unerklärte Herkunft: ein autorisierter, aber böswilliger Insider mit dem echten Schlüssel ist per Definition kein Erkennungsversagen. HALVETH fängt nicht den Angriffsweg. Der „Root of Trust“ bleibt projektweit offen, wörtlich im Code vermerkt. Das TPM ist virtuell, keine diskrete Hardware. Der Off-Box-Zeuge verifiziert eingehende Beweise nicht kryptografisch und leert seinen Speicher bei jedem Neustart. Kein externes Audit. Ergebnisse gelten nur für die isolierte Laborumgebung. Ausführlich: Grenzen-Seite.
Forschungsfrage, nicht Tatsache: welche zusätzlichen Möglichkeiten entstehen, wenn HALVETH an einer tieferen, vertrauenswürdigen Systemgrenze zwischen relevanten Ereignissen sitzt? Erforderlich wären mindestens formale Verifikation, reproduzierbare Builds, unabhängige Audits, gesonderte Antworten für Linux/Ubuntu- und Windows-Architekturen. Eine Kernel-Schwachstelle würde alles betreffen, fehlerhafte Updates und Treibersignaturen zählten neu. Das erzeugt keine 98 Prozent Sicherheit und macht keine andere Sicherheitsmaßnahme überflüssig. Microsoft, Canonical/Ubuntu, Hochschulen oder Sicherheitsforschung sind ausschließlich als mögliche zukünftige Adressaten gemeint, nicht als bestehende Partner.
Minimale Leserechte, physisch oder logisch getrennte Instanz, unveränderbare oder zumindest nachvollziehbare Ablage außerhalb des überwachten Systems, abgesicherte und minimierte Verbindung, damit eine Kompromittierung des Zielsystems die Beweise nicht automatisch mitzerstört. Ein erster Schritt (Raspberry Pi) existiert real, verifiziert eingehende Beweise aber noch nicht kryptografisch.
Eine nur lesende Instanz hat eine andere Risikoklasse als eine reparierende. Automatisierte Rücksetzung braucht privilegierte Rechte, die missbraucht werden können. Ein kompromittierter Reparaturmechanismus könnte selbst Schaden anrichten. Heute hat kein geprüfter Codepfad Schreibzugriff auf ein reales System. Ausführlich: Grenzen-Seite, Abschnitt Schreibrechte.
Die Bausteine 1–6 existieren einzeln; das durchgängige, geprüfte Gesamtmodell ist ein Forschungsvorschlag.
Ausschließlich als langfristiges Hochrisiko-Forschungsthema: formale Definition zulässiger Zustände, sichere Vertrauensanker, eng begrenzte Änderungsfenster, kryptografisch prüfbare Freigaben, Mehrparteienfreigaben, sichere Rollback-Mechanismen, Schutz vor Replay- und Downgrade-Angriffen, manipulationsresistente Logs, unabhängige Zeitquellen, Fail-safe-Konzepte, Notfallabschaltung, Redundanz, nachvollziehbare Governance, externe Sicherheitsprüfung, Fehlalarm-Tests, geklärte Haftungsfragen. Eine Konsens-/Blockchain-Architektur nur, wenn klar ist, welches konkrete Problem sie löst.
Formale Spezifikation der Zustandsübergänge (erster Rahmen existiert), maschinell geprüfte Beweise für die Kerneigenschaften (bislang nur testbasiert), reproduzierbare Builds, projektweite statische Analyse gegen verbotene Seiteneffekte (heute nur für den Kern).
Ein Dritter müsste: den vTPM/Windows-11-VM-Aufbau nachbauen, die vorliegenden Skripte gegen einen eigenen Zertifikat-Speicher laufen lassen, die Kern- und Dashboard-Testsuiten selbst ausführen, die Off-Box-Übertragung selbst prüfen. Der bekannte Pfadfehler in der Kontrollschale müsste vorher behoben werden.
Wie lässt sich der Off-Box-Zeuge selbst gegen Manipulation absichern, ohne zum neuen Angriffsziel zu werden? Welche minimale Kernel-Schnittstelle ermöglicht echte Prävention, ohne die Angriffsfläche des Kernels unvertretbar zu vergrößern? Lässt sich das Finality-Modell formal beweisen statt nur testbasiert abgesichert? Wie lässt sich eine reale Fehlerrate außerhalb des Labors messen, ohne die frühere Zirkularität (Tier2-Forschung) zu wiederholen?
Kernel-/Betriebssystementwicklung, Kryptografie-Ingenieurwesen, formale Verifikation, verteilte Systeme, digitale Forensik, Sicherheits-Governance und Recht, UX für Sicherheitswarnungen.
Ausschließlich als zukünftige, nicht bestehende Adressaten: Kernel-/Plattformanbieter (z. B. Microsoft, Canonical/Ubuntu), akademische Sicherheitsforschung, unabhängige Auditfirmen. Keine dieser Organisationen hat HALVETH geprüft, bestätigt oder unterstützt.
Juri Janovski · info@halveth.de · Anschrift siehe Impressum.
Noch nicht abschließend festgelegt. Bis zur Klärung ausdrücklich erwünscht: Lesen, Zitieren mit Quellenangabe, wissenschaftliche Weiterverwendung und Reproduktion der beschriebenen Tests. Für andere Nutzung bitte vorab Kontakt aufnehmen.
Diese Übergabe beschreibt den Stand vom 14. Juli 2026. Frühere Stände: Fortschritt-Logbuch.
Vollständige Beweismatrix, rohe Belegdateien und Quellcode liegen im internen Projektarchiv (HALVETH-GOLD/, Ordner 20_BEWEISE_GOLD/ und 10_CORE_CODE/), nicht öffentlich in diesem Verzeichnis gehostet. Öffentlich einsehbar sind die verdichteten Fassungen unter Ergebnisse und Audits.