Ein fälschungssicherer Steuerkanal: TOFU + asymmetrische Signatur

Wenn ein System Kommandos an die Rechner von Kunden senden kann, ist die wichtigste Frage: Wer ist wirklich autorisiert, sie zu senden? Die intuitive Antwort — „ein geheimes internes Passwort" — ist schwächer, als sie scheint. Hier ist, warum wir uns für etwas Stärkeres entschieden haben.

Die intuitive Idee: ein gemeinsames Geheimnis

Die naheliegende Idee: Es gibt ein „internes Passwort", das nur das System kennt, und jedes Kommando wird dagegen verifiziert. Wenn etwas Fremdes versuchen würde, ein Kommando einzuschleusen — es kennt das Geheimnis nicht, also scheitert es. Klingt vernünftig.

Aber es gibt hier eine Schwäche: Um ein Kommando zu verifizieren, muss das Geheimnis am Verifizierungspunkt vorhanden sein. Wenn unsere Cloud oder der Rechner kompromittiert wird — ist das Geheimnis lesbar, und der Angreifer fälscht Kommandos nach Belieben. Ein gemeinsames Geheimnis (selbst ein rotierendes) bricht in dem Moment, in dem jemand es sieht.

Was wir gewählt haben: asymmetrische Signatur

Statt eines gemeinsamen Geheimnisses haben wir ein asymmetrisches Schlüsselpaar verwendet. Der Betreiber hat einen privaten Schlüssel, der ihn nie verlässt, und jedes Kommando wird damit signiert. Der Agent auf dem Rechner hält nur den öffentlichen Schlüssel — der eine Signatur verifizieren, aber keine fälschen kann.

Der Unterschied ist grundlegend: Ein vollständiger Einbruch sowohl in unsere Cloud als auch in den Rechner des Kunden kann kein Kommando fälschen, weil der private Schlüssel an keinem dieser Orte vorhanden ist. Unsere Cloud leitet nur das signierte Kommando weiter — sie verifiziert nichts und führt nichts aus.

Zweite Härtung: TOFU — Schlüssel-Pinning

Aber was, wenn ein Angreifer, der unsere Cloud kompromittiert hat, den öffentlichen Schlüssel gegen seinen eigenen austauscht? Dann könnte er selbst signieren. Um das zu verhindern, haben wir TOFU hinzugefügt (Trust On First Use): Der Agent pinnt den Schlüssel des Betreibers einmalig, bei der ersten Registrierung. Bei jeder späteren Prüfung verifiziert er, dass der Schlüssel, den die Cloud präsentiert, mit dem gepinnten identisch ist — und wenn nicht, verweigert er.

Das Rotieren des Schlüssels ist daher eine bewusste Out-of-Band-Handlung, kein stilles Überschreiben aus der Cloud. Ein Angreifer, der unsere Cloud übernommen hat, kann den gepinnten Schlüssel nicht austauschen — der Agent akzeptiert den Austausch schlicht nicht.

Dritte Härtung: keine freie Shell

Selbst wenn eine gültige Signatur irgendwie erzeugt würde, wollten wir den möglichen Schaden begrenzen. Deshalb sind die Aktionen eine endliche, parametrische Positivliste (etwa Neustart oder Dienst neu starten) — und es gibt keine Aktion „beliebiges Kommando ausführen". Wir haben bewusst jeden Pfad entfernt, der eine Zeichenkette an eine Shell übergibt. Selbst eine gültige Signatur erreicht nie eine Root-Shell.

Wie wir getestet haben

Wir haben das Modell im Verhalten verifiziert, nicht nur in der Theorie: Wir haben das Szenario simuliert, in dem die Cloud einen anderen Schlüssel als den gepinnten präsentiert, und bestätigt, dass der Agent tatsächlich verweigert (rc=2) und nicht ausführt. Dieses Muster — pinnen → verifizieren → verweigern — ist der Kern unserer Supply-Chain-Resilienz.

Dieser Artikel beschreibt das Vertrauensmodell auf Prinzipienebene — und das ist tatsächlich eine Stärke, es zu veröffentlichen, denn zu wissen, wie die Verteidigung funktioniert, hilft einem Angreifer nicht (der private Schlüssel wird nicht offengelegt). Es gibt hier keine Schlüssel, Geheimnisse oder sensiblen Implementierungsdetails.