CANopen-Lift, CRA und Cybersecurity

Cyber-Kriminalität ist die drittgrößte Wirtschaft nach den USA und China: Sie beträgt nach Schätzungen rund 10,5 Trillionen US-Dollar im nächsten Jahr. Deshalb ist Cybersecurity ein heißes Thema – auch für CAN-Netzwerke, die in vielen Aufzügen eingesetzt werden.

Die Befürchtung ist, dass jemand ein Gerät an das Netzwerk anschließt, das die Kommunikation korrumpiert und zu fehlerhaftem Verhalten des Aufzugs führt. Es gibt sicherlich noch weitere Szenarien, die aber nicht das Thema dieses Artikels sind.

Von Holger Zeltwanger

Nationale, regionale und internationale Institutionen haben bereits Gesetze und Vorschriften zur Cybersecurity erlassen. Eines davon ist der europäische Cyber-Resilienz-Act (CRA): Dabei handelt es sich um ein Rahmenwerk, das die Anforderungen an die Cybersicherheit von Hard- und Software beschreibt, die in Europa erfüllt werden müssen.

Hersteller sind verpflichtet, Maßnahmen gegen Cyberangriffe während des gesamten Lebenszyklus eines digitalen Produkts zu ergreifen (siehe auch unsere Online-Artikel "Höhere Cybersicherheit für Produkte"). Was Hersteller und Anwender im Einzelnen tun müssen, ist jedoch noch unklar. Es gibt viele Fragen und Unsicherheiten. CAN-Netzwerke bestehen aus Hardware und Software, sie fallen also unter den europäischen Cyber-Resilienz-Act.

CAN-Netzwerke sind nicht per se gegen Cyber-Angriffe geschützt. Dies muss hinzugefügt werden. Mit anderen Worten: CAN ist wie eine Tür ohne Schloss. Abhängig von der Anwendung und den zu erwartenden Risiken, muss man entsprechende Maßnahmen ergreifen. Das international genormte OSI-Modell (Open Systems Interconnection) beschreibt entsprechende Security-Maßnahmen (ISO 7498-2:1998). Es modelliert die sichere Kommunikation zwischen den vernetzten Geräten. Theoretisch kann jede der sieben Kommunikationsschichten Security-Maßnahmen implementieren.

Cybersecurity bei CiA

CANopen-Lift ist in der CiA-Dokumentenreihe CiA 417 spezifiziert. Danach entwickelte Geräte brauchen eventuell zusätzlich Funktionen, um vor Cyberangriffen geschützt zu werden.

Im eingetragenen Verein CiA (CAN in Automation) gibt es derzeit zwei Gruppen, die sich mit Cybersecurity beschäftigen:
• Die Special Interest Group (SIG) 01 der Interest Group (IG) 04 entwickelt den CANsec-Sublayer für CAN XL. Es ist vorgesehen, ihn in den CAN-XL-Controllern in Hardware zu implementieren.
• Im Juli dieses Jahres wurde die SIG "Higher-layer protocol"-Security gegründet. Das Ziel ist, Security-Maßnahmen für die oberen OSI-Schichten (Layer 3 bis Layer 7) zu spezifizieren, die auf den Datenverbindungsprotokollen CAN-CC und CAN FD basieren (eine Software-Lösung). Sie soll auch für CANopen-Lift-Netzwerke anwendbar sein.

Bei CAN-CC-Rahmentelegrammen mit einer maximalen Datenfeldlänge von acht Byte muss man sicherlich Kompromisse eingehen. Für einen höheren Schutz muss man auf das CAN-FD-Protokoll umsteigen, welches Datenfeldlängen bis 64 Byte ermöglicht. Das Technische Komitee des CiAs modelliert diese beiden Optionen in einer Task-Force entsprechend ISO 7498-2. Wenn all diese Aufgaben erledigt sind, können die CANopen-Lift-Experten diese Lösungen in den CiA-417-Dokumenten einpflegen.

Der Autor ist Managing Director des Vereins CAN in Automation (CiA).

CAN in Automation (CiA): Am 5. März 1992 wurde der eingetragene Verein CAN in Automation (CiA) auf Initiative von Holger Zeltwanger gegründet, er hat heute über 700 Mitglieder. Er dient als neutrale Plattform für Anwender und Hersteller des Controller Area Network (CAN). Der Verein hat das CAN-open-Lift-Protokoll (CiA 417) entwickelt, das eine standardisierte Vernetzung von Aufzugskomponenten ermöglicht.

can-cia.org

Politische Diskussion nötig: Diese Dinge müssen aber auch politisch diskutiert werden. Nach meiner Meinung kann es auch ausreichend sein, dass in speziellen Anwendungen eine mechanische Absicherung genügt, wenn beispielsweise die CANopen-Lift-Netzwerke nicht zugänglich sind (zum Beispiel in einem Schacht oder einem nicht öffentlich zugänglichen Gebäude).

In anderen Anwendungen kann eventuell eine Ende-zu-Ende-Absicherung auf Applikationsebene ausreichend sein (die Kommunikation ist dann sozusagen transparent).