Wie auch der Verkehr zwischen PC-Nutzern und Internetseiten stets verschlüsselt und vor dem "Mithören" abgesichert ist, sollten auch Steuergeräte oder elektronische Devices stets vor dem Mithören durch Fremde gesichert sein. Doch zu oft resultiert die Einfachheit serieller Protokolle wie CAN oder ModBus in blanker Offenheit der Kommunikation.In Geräten, die auf Netzwerken serieller Kommunikation basieren, muss man stets von zwei Angriffsmustern ausgehen.
Zugang über die physikalische Schnittstelle eines Geräts: Ein Angreifer verschafft sich Zugriff auf ein einzelnes Gerät durch eine physische Schnittstelle, wie eine Wartungs- oder Diagnoseverbindung. Dies ermöglicht ihm, das Gerät direkt zu manipulieren oder – in einem vernetzten System – Einfluss auf den gesamten Geräteverbund zu nehmen. Darüber hinaus könnte er die Over-the-Air-Schnittstelle (OTA) des Geräts und die dahinterliegende Infrastruktur ins Visier nehmen, um darüber weiterführende Angriffe durchzuführen.
Zugang über die OTA-Schnittstelle: Ein Angriff über die OTA-Schnittstelle zielt darauf ab, die Kommunikation zum Update-Server oder die Verteilung der Updates selbst zu kompromittieren. Gelingt es einem Angreifer, die OTA-Schnittstelle zu übernehmen, hat er potenziell Zugriff auf eine Vielzahl von Geräten. Über manipulierte Updates in Verbindung mit fehlerhaften oder fehlenden Authentifizierungen kann er vielen Geräten gleichzeitig Schaden zufügen.
Ein Ansatz für eine Kommunikationsstrategie ist daher Zero-Trust. Zero-Trust-Kommunikation bedeutet, dass keine Nachricht im Netzwerk als von vornherein vertrauenswürdig betrachtet wird. Gerade für die Low-Level-Kommunikation über serielle Protokolle ist das für viele Hersteller ein Paradigmenwechsel. Payloads müssen nun stets verifiziert werden, bevor sie akzeptiert werden. Wie bereits im vorherigen Artikel dargestellt, sind Manipulationen über Spoofing und Tampering-Attacken verhältnismäßig einfach umzusetzen, wenn ein Gerät komprommitiert ist. Eine wirksame Methode, um dies zu erreichen, ist die Verschlüsselung von Nachrichten und die Sicherstellung von Integrität über Message Authentication Codes. Wir zeigen zunächst anhand des Beispiels wie Nachrichten auf dem CAN-Bus im Rahmen einer Zero-Trust-Strategie abgesichert werden können.
Modellhaftes Verschlüsselungsverfahren
Wir beschreiben eine mögliche Strategie, wie Nachrichten über den CAN-Bus durch den Einsatz von AES und einer MAC gesichert werden, um Manipulationen und Angriffe abzuwehren.
Der Ausgangspunkt ist ein Klartext-CAN-Frame, der gemäß CAN-Classical wie folgt spezifiziert ist:
- Eine 11- oder 29-Bit-ID
- Ein Data Length Code (DLC) für die Datenlänge (0-8 Bytes)
- Das Nutzlastfeld (Payload)
- Bei CAN-FD sind zudem Nutzdatenlängen bis zu 64 Byte möglich, in 8 weiteren stufenweisen Datenlängen (DLC 9-15).
Ziel ist es, einen Authentifizierungsalgorithmus zu entwickeln, der möglichst wenig zusätzlichen Daten-Overhead generiert. Vorgeschlagen wird daher, dass der verschlüsselte Nachrichtentext später nicht länger als 16 Bytes ist, damit eine Payload von 8 Byte inklusive CMAC und DLC auf zwei Nachrichten aufgeteilt werden kann. Die Sequenzsteuerung kann entweder über eine angepasste ID erfolgen oder eines der Steuerbits im CTRL- oder ID-Datenfeld, je nachdem, ob die vorliegende Bus-Architektur bspw. ein IDE-Frame (Extended ID) erlaubt.
Zur Sicherstellung der Integrität und Authentizität der Nachricht wird ein MAC generiert. Hierfür kann beispielsweise AES-CMAC verwendet werden. Der MAC ist eine kryptografische Prüfsumme, die Änderungen an der Nachricht erkennt. Um das MAC-Feld in die Payload zu gießen, muss der AES-CMAC trunkiert werden. Im vorliegenden Beispiel, wird ein 60-Bit-MAC verwendet, da mit der Größenbegrenzung des Nachrichtenrahmens passt.
Zudem wird ein Freshness-Wert benötigt. Freshness ist ein Sicherheitsmechanismus, der sicherstellt, dass Nachrichten in einem Kommunikationssystem aktuell und einmalig sind, um Replay-Angriffe zu verhindern. Durch die Verwendung eines sogenannten "Freshness-Wertes" (z. B. eine Zähler-ID oder einen Zeitstempel) kann der Empfänger anhand des Abgleich mit bisher empfangenen Messages die Payload zusätzlich invalidieren. Zudem schützt der Freshness-Wert in begrenztem Maße vor Brute-Force-Attacken. Die Freshness kann entweder Teil der Daten-Payload sein oder zusätzlich zu den 16 Bytes erhoben werden.
Nachdem MAC und Freshness erzeugt wurden, wird der gesamte Frame zu einem einzigen 128-Bit-verschlüsselten Nachrichtenblock zusammengefasst. Da ein einzelner CAN-Frame zu klein ist, um die verschlüsselte Nachricht komplett zu übertragen, wird sie auf zwei Frames aufgeteilt. Wichtig ist dabei die angesprochene Prioritätssteuerung, idealerweise direkt über die Arbitrierung. Frame A mit der ersten Hälfte der verschlüsselten Nachricht und höherer Priorität; Frame B mit der zweiten Hälfte der Nachricht und spezieller Markierung in der CAN ID oder per IDE-Bit. Nach der Verschlüsselung werden Frame A und Frame B über den CAN-Bus gesendet, sodass nur autorisierte Geräte, die Zugriff auf den Entschlüsselungsschlüssel haben und den Freshness-Wert verstehen, die Nachricht korrekt entschlüsseln und verifizieren können.
Verschlüsselung von CAN-Nachrichten inklusive MAC-Generierung
Der Empfänger kann aus den beiden übertragenen Frames nun bei vorliegendem Schlüssel den ursprünglichen DLC, die Daten-Payload sowie die MAC heraus entschlüsseln. Voraussetzung dafür ist das Vorhandensein eines eben solches Schlüssels. Potenziell verwendbar ist dabei ein globaler Festwertschlüssel. Ist dieser jedoch einmal entdeckt, gibt es für kein Gerät einen Sicherheitsmechanismus und alle betroffenen Geräte sind potenziell kompromittiert. Sinnvoller daher ist die Vereinbarung eines lokalen Schlüssels zum Datenaustausch.
Der Diffie-Hellman-Schlüsseltausch ist solch ein kryptographisches Verfahren und ermöglicht über eine unsichere Verbindung einen gemeinsamen geheimen Schlüssel zu erstellen, ohne dass dieser jemals direkt übermittelt wird. Beide Parteien wählen zunächst jeweils eine private Zahl und berechnen daraus eine öffentliche Komponente, die sie austauschen. Mithilfe dieser ausgetauschten öffentlichen Werte und ihrer eigenen privaten Zahl können beide unabhängig voneinander denselben gemeinsamen Schlüssel berechnen. Ein Angreifer, der nur die ausgetauschten öffentlichen Werte abfängt, kann den geheimen Schlüssel nicht rekonstruieren, da die Berechnung ohne die privaten Zahlen unmöglich ist. Das Verfahren ist wie folgt beschrieben:
Diffie-Helman-Schlüsselaustausch
Auch, wenn das Verfahren für den CAN-Bus beschrieben wurde, ist eine Verschlüsselung von Nachrichten über Modbus gleichermaßen möglich. Die folgende Grafik zeigt die unterschiedlichen Ausprägungen von Modbus-Kommunikation:
Arten der Modbus-Kommunikation
Modbus RTU ist dabei besonders geeignet für kleinere, lokale Netzwerke mit direkten, punkt-zu-punkt oder Multi-Drop-Verbindungen konzipiert. Die Datenübertragung erfolgt in einem kompakten binären Formatund eignet sich am besten für geschlossene Systeme ohne Verbindung zur Außenwelt. Modbus TCP hingegen nutzt das TCP/IP-Protokoll und ist für Ethernet-Netzwerke konzipiert.
Zusammenfassung
Um Embedded Systems vor Angriffen zu schützen, sind Sicherheitsmaßnahmen unerlässlich, insbesondere bei der Kommunikation über serielle Protokolle wie CAN oder Modbus. Die gängige Offenheit solcher Protokolle birgt erhebliche Risiken, da Angreifer über physische oder OTA-Schnittstellen Zugang zu Geräten erlangen können. Mit dem Ansatz der Zero-Trust-Kommunikation, bei dem jede Nachricht verifiziert wird, bevor sie akzeptiert wird, lässt sich die Sicherheit deutlich erhöhen. Der Einsatz von Verschlüsselung, Message Authentication Codes (MAC) und Freshness-Werten minimiert das Risiko von Replay- und Spoofing-Angriffen. Auch Verfahren wie der Diffie-Hellman-Schlüsseltausch ermöglichen eine sichere Schlüsselaustauschmethode über unsichere Verbindungen. Ob CAN oder Modbus – durch konsequente Absicherung dieser Protokolle können Unternehmen den Anforderungen an moderne Cybersicherheit gerecht werden und ihre Systeme langfristig schützen.
Unsere Artikelserie zu Cyber Resilience von Mikrocontrollern
- Der Cyber Resilience Act und die Bedeutung für eingebettete Elektronik
- Spoofing- und Tampering-Attacken in Bussystemen
- Zero-Trust-Kommunikation auf Low-Level-Bussystemen
- Anti-Denial-of-Service-Maßnahmen für Peripherien (ab 08.11.2024)
- Sichere Updates über Kommunikationsbusse (ab 15.11.2024)
- Lokales und gerätebezogenes Schlüssel-Management (ab 22.11.2024)
Kommentieren