Autor: Dr.-Ing. Kristian Trenkel
EU-Datenschutz und Hackerangriffe, gestohlene Daten bei Facebook und automatisch fahrende Autos. Sicherheit rückt immer mehr in den Fokus. Weil die Systeme immer komplizierter werden und immer mehr Schnittstellen besitzen, steigen die Anforderungen an die Entwicklung und das Testen von Software. Der Sicherheit in der Entwicklung und dem Test eingebetteter Systeme kommt dabei eine zentrale Rolle zu.
Die Entwicklung und die Tests eingebetteter Systeme bei Steuergeräten im Automobilbereich unterliegen einem rasanten technischen Fortschritt. Die Komplexität der Systeme und damit der Entwicklungs- und der Testaufwand steigen stetig an.
Mit dem Einzug von Funktionen, wie dem autonomen Fahren und der Car2x-Kommunikation, wird – neben der Sicherheit im Sinn der Safety – auch die Sicherheit im Sinne der Security immer wichtiger. Safety ist dabei mit den einschlägigen Normen, wie zum Beispiel IEC 61508 und ISO 26262, und den darauf aufbauenden Entwicklungs-prozessen gut abgedeckt. Das Thema Security dagegen ist im Bereich der eingebetteten Systeme hingegen noch kaum berücksichtigt.
Test eingebetteter Systeme
Eingebettete Systeme erfüllen typischerweise spezielle Steuerungs- bzw. Regelungs-aufgaben. Dabei müssen sie nicht zwingend eine direkte Schnittstelle zum Nutzer aufweisen. Mit Hilfe von Sensoren werden Werte der Umwelt, wie zum Beispiel die Feuchtigkeit und Temperatur der Straße, gemessen. Über die Aktoren (beispielsweise Elektromotoren oder Ventile) werden dann Reaktionen des eingebetteten Systems – wie zum Beispiel die automatische Drosselung der Geschwindigkeit des Fahrzeugs – ausgeführt.
Der Eingriff eines Menschen ist nicht mehr notwendig. Weiterhin steht heute das Thema Vernetzung dieser Systeme – meist über einfache Bussysteme – im Zentrum. In Abbildung 1 ist der Aufbau eines typischen eingebetteten Systems am Beispiel eines Automobil-Steuergeräts dargestellt.
Für den Test von eingebetteten Systemen kommt heute oft der Hardware
in the Loop (HIL)-Test zum Einsatz. Der Aufbau eines solchen HIL-Testsystems ist in Abbildung 2 dargestellt. Die zentrale Komponente des Testsystems stellt der Echtzeitrechner dar. Dieses System führt die Umgebungssimulation in Echtzeit (typische Zykluszeit 500 µs bis 1 ms) aus.
Neben der Ausführung der Simulation stellt dieses System auch die Schnittstellen zum Device Under Test (DUT, dem zu testenden Steuergerät) zur Verfügung. Diese Schnittstellen können auf der einen Seite analoge, digitale oder PWM-Kanäle sein. Auf der anderen Seite kommen verschiedene Bussysteme, wie zum Beispiel CAN, FlexRay oder Ethernet, zum Einsatz. Die Signale der Schnittstellen dienen der Nachbildung der Umgebung des DUT.
Analoge Signale können die Werte analoger Sensoren (z. B. Beschleunigungs- oder Höhenstandssensoren) widerspiegeln. Ein weiterer Teil des Testsystems umfasst die Lastsimulation. Lasten sind dabei alle angesteuerten Aktoren (z. B. Ventile oder Motoren). Diese Lasten können als Originalteil verbaut sein oder durch Simulationen (z. B. elektronische Lastsimulation) ersetzt sein.
Die Ansteuerung der Lastsimulation erfolgt über den Echtzeitrechner. Zwischen der Lastsimulation und dem DUT befindet sich die Fehlerinjektion. Diese ermöglicht es, Kurzschlüsse und Unterbrechungen an den Lasten zu schalten, um die Fehlererkennung und Fehlerreaktion des DUT zu prüfen. Die Steuerung der Fehlerinjektion erfolgt ebenfalls über den Echtzeitrechner. Ein weiteres Element des Testsystems ist der Steuerrechner. Dieser Computer ist meist Windows-basiert. Er dient der Ausführung der automatisierten Tests sowie der Steuerung des Testsystems für manuelle Tests. Die Automatisierung der Tests kann mit verschiedenen Tools (z. B. iSyst iTestStudio oder sepp.med MBT-Suite) und in verschiedenen Beschreibungssprachen (z. B. Python oder UML) erfolgen.
Des Weiteren sind oft Tools für das Messen der Buskommunikation (z. B. Vector CANalyzer) oder Tools für den Zugriff in die Steuergerätesoftware zur Laufzeit (z. B. Vector CANape, iSYSTEM WinIDEA oder Lauterbach TRACE32) im Einsatz. Diese Tools erweitern die Möglichkeiten und die Abdeckung der Tests.
Heutzutage steckt ein großer Teil des Aufwandes für die Realisierung des HIL-Testsystems im Umgebungsmodell. Dieses Modell muss die reale Umgebung des DUTs so exakt nachbilden, dass das Steuergerät keinen Unterschied zur realen Einsatzumgebung feststellen kann. Dabei entfällt mittlerweile ein großer Anteil des Aufwands auf die Nachbildung der Buskommunikation – Restbus-Simulation genannt.
Es ist möglich, dass für ein einzelnes DUT mehrere 100 Botschaften mit zusammen mehreren 1.000 Datensignalen darzustellen sind. Außerdem müssen die HIL-Testsysteme so ausgelegt sein, dass per Fehlerinjektion alle denkbaren Fehler realisiert werden können. Dies beginnt bei dem Ausfall einzelner elektrischer Signale, geht über das Schalten von Kurzschlüssen an Aktoren und Sensoren bis hin zum Test des Ausfalls einzelner Botschaften bzw. fehlerhafter Werte einzelner Signale innerhalb der Buskommunikation. Ziel ist es dabei, alle Fehlerreaktionen des DUTs in simulierter Umgebung zu prüfen, um das Risiko für Mensch und Maschine bei der Erprobung zu minimieren und die Safety (also die funktionale Sicherheit) sicherzustellen.
Aufbauend auf den Möglichkeiten des HIL-Testsystems ist es heutzutage zwingend erforderlich, die durchzuführenden Tests zu automatisieren. Anforderung für ein eingebettetes System ist ein manueller (System-) Test nicht mehr sinnvoll möglich. Aber vor allem die Buskommunikation mit tausenden von Testfällen (z. B. falsche Werte für jedes Signal, Ausfall einer Botschaft, …) macht eine Testautomatisierung unabdingbar. Bisher beziehen sich die gesamten Testaufwände meist auf die Erfüllung der Anforderungen mit dem Blick auf die funktionale Sicherheit. Weiterhin zielen die Tests auf die Einhaltung von Qualitätszielen, wie zum Beispiel Anzahl offener Fehler zum Release, ab.
Eine vollständige Automatisierung der Test findet in der Praxis selten statt. Im Bereich der eingebetteten Systeme werden Methoden zur Sicherstellung der Security (also der Sicherheit der Software – damit niemand auf diese von außen zugreifen kann) kaum bzw.
gar nicht angewendet.
Security im Embedded Umfeld
Es zeigen sich immer häufiger Security-Probleme bei eingebetteten Systemen, die auch von einem breiteren Publikum wahrgenommen werden. Beispielhaft sei hier der DistributedDenial-of-Service-Angriff (DDoS) im Jahr 2016 genannt. Hier wurde zum Angriff auf Server-Systeme internationaler Konzerne ein Bot-Netzwerk bestehend aus IP-Kameras, Routern und digitalen Videorekordern eingesetzt. Weitere Beispiele, wie Industriesteuerungen oder Heizungssysteme für Einfamilienhäuser, die über das Internet zugreifbar sind, waren auch mehrfach in der Berichterstattung.
Bei diesen Fällen kamen immer wieder die gleichen Probleme zum Vorschein:
- Es kommen oft veraltete Versionen von Bibliotheken oder auch Betriebssystemen auf den eingebetteten Systemen zum Einsatz. Die Systeme sind meist auch nicht speziell gegen Angriffe gehärtet.
- Zugänge über Netzwerke werden meist nur unzureichend geschützt. Zum Teil
werden fest einprogrammierte Benutzernamen und Passwörter verwendet, wenn überhaupt ein Login notwendig ist. - Meist fehlt eine Strategie für den weiteren Support im Feld. Es ist nicht vorgesehen, dass nach der Entwicklung Sicherheitslücken bzw. Fehler behoben werden.
- Es fehlt eine Möglichkeit zum Update der Software auf dem eingebetteten System. Ohne eine einfach nutzbare Möglichkeit zum Software-Update ist das Schließen von Sicherheitslücken unmöglich. In Zukunft werden die Anforderungen an die Security von eingebetteten Systemen noch weiter steigen. Vor allem die steigende Vernetzung in den Bereichen IoT, Industrie 4.0 und Car2X-Kommunikation erhöhen die Möglichkeiten von Angriffen dramatisch. Des Weiteren führt die Anbindung an „Cloud“-Dienste zu einer immer weiter reichenden Vernetzung der Systeme. Der damit verbundene Einsatz von Webservices erweitert die Problemstellung der Sicherheit im Sinne der Security bis hin zu Aspekten der Datensicherheit und des Datenschutzes auch im Bereich der eingebetteten Systeme.
Herausforderungen für den Test
Die beschriebenen Probleme haben dabei direkte Auswirkungen auf den Test.
Die bisherigen Ansätze und Methoden für den Test eingebetteter Systeme konzentrieren sich auf die funktionalen Anforderungen. Dabei sind im Normalfall klare Kriterien für die
Bewertung der korrekten Funktionalität vorhanden. Im Bereich des Security-Testings kommen hingegen andere Methoden zum Einsatz. Beispielhaft seien hier Fuzzing und genetische Algorithmen zu nennen.
Diese Methoden werden im IT-Umfeld erfolgreich eingesetzt. Dabei wird der Test als erfolgreich (PASSED) angesehen, wenn die zu testende Applikation nicht abstürzt. Im Bereich der eingebetteten Systeme können diese Methoden ebenfalls angewendet werden. Das Problem liegt hier aber in der Festlegung des PASSED-Kriteriums für einen erfolgreichen Test. Der Absturz ist hier kein sinnvolles Kriterium. Es muss sichergestellt werden, dass das System weiterhin seine Funktion erfüllt und Ziele der funktionalen Sicherheit (Safety Goals) nicht verletzt werden. Dies ist eine komplexe Problemstellung, für die es bisher keine allgemeingültigen Lösungsansätze gibt.
In der Praxis zeigen sich noch weitere Probleme. Vor allem die Verfügbarkeit von Entwicklern und Testern mit dem notwendigen Know-How ist schwierig. Des Weiteren ist die Reproduzierbarkeit von Test mit Fuzzing und genetischen Algorithmen nur schwer zu
realisieren. Es müssen alle Ausgabedaten des Testsystems aufgezeichnet werden, um diese später wieder abspielen zu können. Dies führt wiederum zu einer fast unüberschaubaren Menge an Testdaten. Auch die Verfügbarkeit von Tools für die automatisierte Durchführung dieser Tests stellt ein Problem dar.
Diese Werkzeuge sind auf den Einsatz im IT Umfeld ausgerichtet und lassen sich damit nur schwer im Bereich der eingebetteten Systeme einsetzen. Abschließend ist noch die Integration von Security-Funktionen in die Umgebungssimulation der HIL-Testsysteme zu betrachten. Beispielsweise ist es vorgesehen, die Kommunikation zwischen verschiedenen eingebetteten Systemen zu verschlüsseln bzw. die Datenkommunikation zu signieren. Im Automobil-Bereich steht dafür der Standard SecOC aus dem AUTOSARKonsortium zur Verfügung. Die Integration der eigentlichen Algorithmen in die Testsysteme stellt dabei kein Problem dar.
Für die Umgebungssimulation ist es notwendig, die Kommunikationspartner des DUTs zu simulieren. Hierfür ist es aber notwendig, dass das Testsystem die Schlüssel aller zu simulierenden Steuergeräte kennt. Das wiederum wirft die Frage auf, wie sicherzustellen ist, dass die Schlüssel nicht in die Hände unbefugter Personen geraten. Ebenso ist die Aufzeichnung der Buskommunikation bei Versuchsfahrten nicht mehr direkt möglich. Die Aufzeichnungssysteme müssen die Möglichkeit zur Entschlüsselung der Daten haben, ohne dabei die Security zu schwächen.
Fazit
Bisher ist das Thema Security in der Entwicklung und dem Test von eingebetteten Systemen kaum präsent. Viele Problemstellungen, vor allem im Bereich des Tests, sind bisher nicht zufriedenstellend geklärt. Die absehbaren Entwicklungen im Bereich der eingebetteten Systeme machen eine rasche Diskussion und Klärung dieser Fragen zwingend erforderlich. Andernfalls kann weder die Safety noch die Security solcher Systeme sichergestellt werden. Dies kann und wird Auswirkung in allen Bereichen der Wirtschaft und der Gesellschaft haben.
