Signaturen und Schlüssel
Alles zwischen Controller und Anlage läuft bereits verschlüsselt über TLS. Trotzdem wird zusätzlich auf Anwendungsebene signiert. Diese Seite erklärt, warum das kein Gürtel-und-Hosenträger ist, sondern eine andere Frage beantwortet.
TLS beantwortet: Kann jemand mitlesen oder verändern, was über die Leitung geht?
Die Signatur beantwortet: Stammt diese Nachricht wirklich von dem, für den ich ihn halte – auch
dann, wenn die TLS-Endstelle nicht mehr vertrauenswürdig ist?
Zwei Schlüsselpaare
Es gibt genau zwei Schlüsselpaare, und beide sind Ed25519 – ein moderner, schneller und kompakter Signaturalgorithmus ohne die typischen Fehlbedienungsmöglichkeiten älterer Verfahren.
| Schlüsselpaar | Privater Teil liegt | Wofür |
|---|---|---|
| Anlagen-Schlüssel | ausschließlich auf der Anlage | Die Anlage weist sich damit aus |
| Controller-Schlüssel | ausschließlich im Controller | Der Controller signiert damit Kommandos und das Begrüßungs-Frame |
Zentral wird jeweils nur der öffentliche Teil gespeichert. Das ist der Grund, warum hier Schlüsselpaare und keine geteilten Zugangstoken verwendet werden.
Angenommen, die Datenbank des Controllers wird vollständig kopiert. Der Angreifer erhält damit: Anlagennamen, Inventarstände, öffentliche Schlüssel. Was er nicht erhält, ist irgendetwas, womit er sich als eine Ihrer Anlagen ausgeben könnte. Bei geteilten Bearer-Token wäre genau das der Fall – sie stehen zwangsläufig auf beiden Seiten.
Zusätzliche Bindung auf der Anlage
Der private Schlüssel der Anlage verlässt die Anlage nie. Er wird dort verschlüsselt abgelegt und zusätzlich an die Modul-Kennung und die Hardware-Kennung der Anlage gebunden. Eine kopierte Konfiguration allein ergibt auf fremder Hardware keine verwendbare Identität.
Wie sich die Anlage ausweist
Bei jedem Verbindungsaufbau legt die Anlage eine kurzlebige, signierte Bescheinigung vor. Sie enthält:
| Feld | Bedeutung |
|---|---|
| Betreff | die eigene Anlagen-Kennung |
| Zielgruppe | der Endpunkt, für den die Bescheinigung gilt |
| Ausstellungs- und Ablaufzeit | das Gültigkeitsfenster |
| Einmal-Kennung | die Nummer, die nur ein einziges Mal verwendet werden darf |
Der Controller prüft vier Dinge, bevor überhaupt eine Nachricht ausgetauscht wird:
- Die Signatur gegen den hinterlegten öffentlichen Schlüssel dieser Anlage.
Verhindert: dass sich jemand ohne den privaten Schlüssel als die Anlage ausgibt. - Die Zielgruppe gegen den eigenen Endpunkt.
Verhindert: dass eine gegen einen anderen Controller ausgestellte Bescheinigung hier funktioniert. - Die Ablaufzeit. Das akzeptierte Fenster ist auf höchstens zwei Minuten begrenzt.
Verhindert: dass eine abgefangene Bescheinigung noch Stunden später brauchbar ist. - Die Einmal-Kennung gegen eine Liste bereits gesehener Kennungen.
Verhindert: dass dieselbe Bescheinigung innerhalb ihres Fensters ein zweites Mal eingespielt wird.
Schlägt eine dieser Prüfungen fehl, wird der Verbindungsaufbau abgewiesen. Eine unbekannte, gesperrte oder widerrufene Anlage bekommt dabei dieselbe Antwort wie eine mit falscher Signatur – der Aufrufer soll die Fälle nicht auseinanderhalten können.
Wie sich ein Kommando ausweist
Jedes Kommando vom Controller zur Anlage ist signiert. Die Anlage prüft die Signatur gegen den beim Einrichten gepinnten Schlüssel und lehnt bei Abweichung ab – ohne die Verbindung zu beenden, aber mit einem Eintrag im lokalen Protokoll.
Zwei Felder im Kommando sind dabei besonders wichtig:
Die Ziel-Anlage ist Teil der Signatur
Jedes Kommando nennt die Anlage, für die es bestimmt ist, und dieses Feld wird mitsigniert. Die Anlage lehnt ab, wenn der Wert nicht zu ihrer eigenen Kennung passt.
Verhindert: dass ein für Anlage A signiertes Kommando auf Anlage B gültig wird – was sonst genau dann passieren könnte, wenn dort zufällig dieselbe Berechtigung existiert.
Das Ablaufdatum ist Pflicht
Jedes Kommando trägt ein Ablaufdatum. Fehlt es oder ist es leer, wird das Kommando abgewiesen. „Kein Ablauf" gibt es nicht.
Verhindert: zweierlei. Erstens, dass ein Kommando an einer drei Wochen offline gewesenen Anlage bei deren Rückkehr unerwartet zündet. Zweitens, dass ein mitgeschnittenes, gültig signiertes Kommando unbegrenzt wiederholbar bleibt.
Das Begrüßungs-Frame – und warum es signiert ist
Nach dem Verbindungsaufbau schickt der Controller eine Begrüßung. Sie enthält die aktuell gültigen Controller-Schlüssel und die aktuelle Endpunktliste – und die Anlage übernimmt beides dauerhaft. Das ist der reguläre Weg für Schlüsselrotation und Umzüge.
Damit ist diese eine Nachricht zugleich die gefährlichste des gesamten Protokolls: Sie tauscht den Vertrauensanker aus. Deshalb gelten drei Regeln:
- Die Begrüßung ist signiert, mit dem Schlüssel, den die Anlage bereits akzeptiert.
- Die Anlage prüft vor jeder Übernahme. Schlägt die Prüfung fehl, wird die Nachricht verworfen und die Verbindung geschlossen – ohne dass irgendetwas übernommen wird.
- Ein neuer Schlüssel wird ausschließlich unter dem alten übernommen, und er trägt eine Frist. Nach deren Ablauf akzeptiert die Anlage ihn nicht mehr.
Da bewusst kein TLS-Zertifikat gepinnt wird, genügte ohne die Signatur eine kompromittierte TLS-Endstelle oder ein fehlausgestelltes Zertifikat, um einer Anlage einen fremden Signaturschlüssel unterzuschieben – und sie damit dauerhaft auf einen fremden Controller zu ziehen. Die Prüfung beim Einrichten schützt nur die Erstanbindung, nicht die spätere Rotation.
Schlüsselrotation
Die Anlage hält zwei akzeptierte Controller-Schlüssel gleichzeitig: den aktuellen und einen nachfolgenden, mit Ablaufdatum. Ein Schlüsselwechsel ist dadurch ein Überlappungsfenster und kein Stichtag, an dem alle Anlagen gleichzeitig die Verbindung verlieren.
Dieselbe Mechanik trägt einen Anbieterwechsel: Wer vom gehosteten Betrieb auf einen eigenen Controller umzieht, kann Schlüssel und Endpunktliste über das laufende Überlappungsfenster übergeben.
Die Anlagenseite akzeptiert zwei Schlüssel bereits. Der Controller kündigt aktuell noch keinen Nachfolgeschlüssel an – solange die Regel „neuer Schlüssel nur unter dem alten" nicht auf beiden Seiten abgeschlossen ist, wird bewusst nichts zum Übernehmen ausgeliefert.
Warum die Signatur nicht alles löst
Die Signatur schützt nicht gegen einen kompromittierten Controller – wer dessen privaten Schlüssel besitzt, kann gültige Kommandos erzeugen. Ihr Wert liegt woanders:
- Nichtabstreitbarkeit gegenüber dem Kunden. Was auf einer Anlage passiert ist, lässt sich einem Aussteller zuordnen.
- Schutz vor einer kompromittierten Zwischenstelle. Alles, was TLS terminiert – Proxys, Load-Balancer, Edge-Dienste – kann Kommandos weder erzeugen noch verändern.
Genau deshalb liegt die eigentliche Durchsetzung nicht beim Controller, sondern auf der Anlage. Das beschreibt die nächste Seite.
Kurz zusammengefasst
| Geprüft wird | Wo | Was es verhindert |
|---|---|---|
| Signatur der Anlagen-Bescheinigung | Controller, vor dem ersten Frame | Übernahme einer Anlagenidentität |
| Zielgruppe der Bescheinigung | Controller | Wiederverwendung gegen einen anderen Controller |
| Gültigkeitsfenster (max. 2 Minuten) | Controller | Späteres Einspielen einer abgefangenen Bescheinigung |
| Einmal-Kennung | Controller | Zweites Einspielen innerhalb des Fensters |
| Signatur des Kommandos | Anlage | Manipulierte oder untergeschobene Kommandos |
| Ziel-Anlage im Kommando | Anlage | Gültigkeit eines Kommandos auf der falschen Anlage |
| Ablaufdatum | Anlage | Unbegrenzte Wiederholbarkeit; verspätetes Zünden |
| Signatur der Begrüßung | Anlage | Austausch des Vertrauensankers durch Dritte |
Weiter mit Rechte und Not-Aus.