<ul><li>Schutz vor Cyber-Attacken aus dem Quantencomputer</li><li>Schlüsselelement für Sensorfusion</li><li>Kollaboratives Ökosystem im Fokus</li><li>Validierung einer GNSS-basierten Fahrzeuglokalisierung unter Jamming und Spoofing</li></ul>

Scheuer ade – scheiden tut kein bisschen weh

Haben Sie es am 26. Oktober 2021, um 17:54 Uhr, auch gehört – das gemeinschaftliche Aufatmen, das sich durch ganz Deutschland zog?

Haben Sie es am 26. Oktober 2021, um 17:54 Uhr, auch gehört – das gemeinschaftliche Aufatmen, das sich durch ganz Deutschland zog? Denn zu diesem Zeitpunkt erhielt Verkehrsminister Andreas Scheuer von Bundespräsident Frank-Walter Steinmeier seine Entlassungsurkunde.

 Natürlich bringt die Bevölkerung dem Amt des Verkehrsministers von jeher nicht sonderlich viel Liebe entgegen. Schließlich gibt es knapp 43 Millionen selbst ernannte Verkehrsminister – denn so viele Autofahrer werden derzeit in Deutschland statistisch erfasst. Und jeder einzelne trifft selbstverständlich intelligentere Entscheidungen. Immer. Auch Scheuers (CSU-)Vorgänger Ramsauer und Dobrindt zählten sicherlich nicht zu den Lieblingsministern der Deutschen.

Doch was Andreas Scheuer an die Spitze der Unbeliebtheit katapultierte, lässt sich in einem Wort festhalten: Mautdesaster. Scheuer wollte derjenige sein, der das langjährige CSU-Projekt Pkw-Maut durchsetzt – und zwar um jeden Preis. So schloss er Ende 2018 Betreiberverträge, noch bevor endgültige Rechtssicherheit beim Europäischen Gerichtshof (EuGH) bestand. Der EuGH jedoch stufte das Modell wegen Diskriminierung als rechtswidrig ein und kippte es im Juni 2019. Die Betreiber fordern mehr als eine halbe Milliarde Schadensersatz und für den nunmehr seit zwei Jahren andauernden Rechtsstreit fallen darüber hinaus Millionen an. Ebenfalls lange wurde die Frage diskutiert, wie rechtswidrig Scheuer gehandelt hat. Der 2. Untersuchungsausschuss des Deutschen Bundestags kam zum Schluss, dass das Bundesverkehrsministerium zwar keine offensichtlichen Rechtsverstöße begangen hat, aber weiterhin viele Fragen rund um die Pkw-Maut offen sind. Die nach wie vor unbeantwortet sind. Konsequenzen gab es keine – trotz sehr lauter Rücktrittsforderungen.

Auch beim Bußgeld-Katalog stand sein Verkehrsministerium nicht gut da. Die ursprünglich im April 2020 eingeführte StVO-Novelle musste aufgrund eines Formfehlers wenig später teilweise wieder außer Kraft gesetzt werden.

Was bleibt sonst von Scheuer? Nicht viel Positives. Er tat wenig in puncto Klimaschutz, versuchte sogar zu Beginn der Coronakrise Kaufprämien für angeblich saubere Verbrenner durchzusetzen. Für die deutsche Bahn hatte er keine Strategie und beim Gesetz zum autonomen Fahren wurden zunächst Rechtsfehler gemacht, die den Prozess aufhielten – auch wenn der gesetzliche Rahmen insgesamt gelang. Fazit: Egal, wer Andreas Scheuer im Amt nachfolgt, an dem Päckchen Verkehrswende hat sie oder er sicherlich schwer zu tragen, denn in der Verkehrspolitik sind viele gute Ideen notwendig. Aber immerhin, viele Sympathien dürfte die oder der Neue auf jeden Fall haben.

Stefanie Eckardt, Chefredakteurin   HANSER automotive

16:9

Editorial - Hauptartikel

Validierung einer GNSS-basierten Fahrzeuglokalisierung

Beim automatisierten Fahren spielt GNSS für die Positionierung und Zeitsynchronisation des gesamten Systems eine wichtige Rolle. Die wachsende Abhängigkeit verschiedener Anwendungen von GNSS geht mit einer zunehmenden Wahrscheinlichkeit von Angriffen auf diese Informationsquelle einher. Bosch und IABG arbeiten gemeinsam an Signalangriffs- und Teststrategien, um Gegenmaßnahmen ergreifen zu können.

Beim automatisierten Fahren spielt GNSS für die Positionierung und Zeitsynchronisation des gesamten Systems eine wichtige Rolle.

Aufgrund der raschen Entwicklung und der zunehmenden Verfügbarkeit mehrerer unabhängiger globaler Satellitennavigationssysteme (GNSS) in den letzten Jahrzehnten basieren immer mehr Anwendungen aus den verschiedenen Industriebereichen auf GNSS. Im Automobilsektor spielt die Satellitennavigation eine zentrale Rolle, weil diese eine globale absolute Positionsbestimmung ermöglicht. Vor allem beim automatisierten Fahren ist GNSS für die Positionierung und Zeitsynchronisation des gesamten Systems essenziell. Die wachsende Abhängigkeit verschiedener Anwendungen von GNSS geht mit gezielten Cyber-Angriffen auf die vom Satelliten frei zugänglich abgestrahlten Navigationssignale einher. Die absichtliche Verhinderung des Signalempfangs, bekannt als Jamming, ist eine ernsthafte Bedrohung, da die mit schwacher Leistung auf der Erdoberfläche eintreffenden Signale sehr leicht gestört werden können. Hinzu kommt, dass die hierfür benötigten GNSS-Störgeräte preiswert und problemlos im Internet erhältlich sind. Bleibt Spoofing, also das absichtliche Aussenden von gefälschten Signalen unerkannt, führt das zu einem Verlust der Integrität der Positionslösung. Dies stellt im Hinblick auf die Sicherheit des automatisierten Fahrens eine sehr ernstzunehmende Gefahr dar. Aus diesem Grund haben sich IABG und Bosch zusammengeschlossen mit dem Ziel, gemeinsam Signalangriffs- und Teststrategien zu entwickeln. Diese sollen es ermöglichen, die Robustheit von GNSS-Systemen in Kraftfahrzeugen gegen GNSS-basierte Cyber-Angriffe zu testen und zu bewerten. Die Testergebnisse bilden die Grundlage für die Weiterentwicklung und Umsetzung von Jamming- und Spoofing-Gegenmaßnahmen GNSS-gestützter Anwendungen im Bereich Automotive.

Weil GNSS auf dem Gebiet des autonomen Fahrens an Bedeutung zunehmen wird, werden in Zukunft auch Angriffe auf die GNSS-Signalebene immer wahrscheinlicher. Daher ist es notwendig, die negativen Auswirkungen dieser Angriffe auf die berechnete Positions-, Navigations- und Zeitlösung (PNZ) zu analysieren und zu bewerten. Es gibt verschiedene Arten von Angriffen. Die einfachste ist Jamming, d. h. es werden Störsignale ausgesendet, um den GNSS-Signalempfang zu blockieren. Ein raffinierterer Angriff ist Spoofing, bei dem der Angreifer die PNZ-Lösung eines GNSS-Empfängers zu verfälschen versucht, ohne dass der Empfänger das bemerkt. Meaconing ist eine dritte Angriffsmethode, die sich als Unterkategorie von Spoofing einordnen lässt. Hier wird das Originalsignal vom Satelliten empfangen und mit geringfügigen Verfälschungen der Signalstruktur erneut ausgestrahlt – mit der Absicht, die PNZ des Opfer-Empfängers zu täuschen. Die Motive, GNSS-Signale zu stören, sind vielfältig. Sie reichen von der Verhinderung der Ortung durch ein auf GNSS-basiertes Flottenmanagementsystem bis hin zur Vortäuschung einer sicheren Fahrweise, um beim sogenannten „Pay-as-you-drive“ Kfz-Versicherungsbeiträge zu sparen. Die Stör- und Spoofing-Bedrohungen [1, 2] zeigen, dass GNSS-Angriffe in Zukunft vermehrt auftreten werden, da die Verarbeitungsleistung der Hardware-Plattformen ständig zunimmt und die Technologie preiswerter wird, zum Beispiel durch Verwendung kostengünstiger Software Defined Radios (SDR) [3].

Für das hochautomatisierte Fahren hat Bosch ein präzises und sicheres Positionierungssystem namens „Vehicle Motion and Position Sensor“ (VMPS) entwickelt [4]. Der VMPS verarbeitet GNSS-Signale aus mehreren Konstellationen und in verschiedenen Frequenzbändern in Kombination mit hochgenauen und sicheren Trägheitssensormessungen. Der Empfänger wurde in Übereinstimmung mit der Sicherheitsnorm ISO 26262 und unter Berücksichtigung der SOTIF-Norm ISO/PAS 21448 entwickelt. Durch die Zusammenarbeit mit der IABG kann auf deren spezifisches Fachwissen über GNSS und Sensorfusion [5] im Hinblick auf Sicherheitsmaßnahmen zurückgegriffen werden. Das Team der IABG verfügt über einschlägige Erfahrungen im Bereich von GNSS-Cyber-Attacken sowie über effektive Methoden, um diese Bedrohungen unter kontrollierten Bedingungen in ihren Versuchseinrichtungen in Ottobrunn und Lichtenau zu testen und zu bewerten [6].

Um GNSS-Cyber-Attacken vorzubeugen, werden als erstes Angriffsszenarien entwickelt.

 GNSS-Jamming: Störszenario und Störgeräteauswahl

Typische Störsender, die in Kraftfahrzeugen eingesetzt werden können, sind sogenannte Personal Privacy Devices (PPD) [7]. Bild 1 zeigt ein PPD mit einer Antenne und einem Zigarettenanzünderanschluss für die 12-V-Gleichstromversorgung. Das Störsignal ist breitbandig und deckt das komplette obere L-Frequenzband von 1559 bis 1610 MHz ab, in dem u. a. die frei zugänglichen Satellitennavigationssignale für GPS, Galileo und GLONASS liegen.

Für die Analyse und Evaluierung des Verhaltens des VMPS wurde zunächst ein Störszenario entwickelt, bei dem das zu testende Fahrzeug mit dem integrierten VMPS das angreifende Fahrzeug mit dem installierten Störsender überholt. In Bild 2 ist dieses Szenario veranschaulicht. Es wurden mehrere Testfälle mit unterschiedlichen Relativgeschwindigkeiten definiert, um die Auswirkungen der Störung auf die PNZ-Lösung des VMPS für unterschiedlich lange Störzeiten zu analysieren.

GNSS-Spoofing: Szenario mit Geräteauswahl

Anstelle eines leistungsstarken Laptops mit speziellen Software-Paketen für die GNSS-Signalsimulation unter Verwendung von SDR-Hardware wurde für die Erzeugung des Spoofing-Signals ein handelsüblicher GNSS-Konstellationssimulator gewählt. Die Vorteile eines solchen Simulators im Vergleich zu einer SDR-basierten Lösung liegen in der Flexibilität bei der GNSS-Szenariogenerierung. In Bild 3 ist die Verschaltung des Simulators mit zusätzlichen externen Hardwareeinheiten zu sehen. Um die Synchronisation des gefälschten Signals mit den authentisch abgestrahlten Satellitensignalen sowohl bezüglich der Frequenz als auch der Zeit sicherzustellen, kam eine GPS-gesteuerte Uhr zum Einsatz, die auf Basis der Atomuhrgenauigkeit der Satellitenzeit ein 10 MHz Referenzfrequenz- und ein sogenanntes Pulse-Per-Second-Signal in den GNSS-Simulator einspeiste. Unentbehrlich für die Generierung des Täuschungssignals mit authentischen Navigationsdatenbits war die Verwendung eines gültigen Satzes von Satellitenbahn- und Uhrenkorrekturdaten. Diese wurden von einem separaten GNSS-Empfänger extrahiert und dem Simulator zur Verfügung gestellt. Zur Kompensation von Signalausbreitungsverlusten wurde ein HF-Verstärker mit einer einstellbaren Verstärkung von bis zu 40 dB verwendet.

Es wurde ein Spoofing-Szenario gewählt, wie es auch in alltäglichen Situationen auftreten könnte: Ein Fahrzeug steht im Stau oder wartet an der Ampel auf Grün. Ein Angreifer möchte die Position des Fahrzeugs manipulieren, indem er gefälschte Signale von einem Fahrzeug in unmittelbarer Nähe aussendet. Bild 4 stellt die Situation, bei der sich der VMPS und das angreifende Fahrzeug nebeneinander befinden, dar. Der Täuscher möchte die Position des VMPS-Fahrzeugs gezielt verfälschen und beginnt, GNSS-Signale mit einer gefälschten Trajektorie zu erzeugen, die nicht dem beabsichtigten Fahrweg des VMPS-Fahrzeugs entsprechen. Die Trajektorie des Spoofers wurde so gewählt, dass diese am Standort des anzugreifenden Fahrzeugs beginnt und mit konstanter Geschwindigkeit in einer Seitwärtsrichtung wegzieht.

Als Testgelände zur Durchführung der Angriffsszenarien wurde das Fahrtestzentrum von Bosch in Boxberg [8] gewählt. Weil das beabsichtigte Stören und Täuschen von GNSS-Signalen verboten ist, wurde für die Durchführung dieser Versuchsreihe eine Versuchsfunkgenehmigung bei der Bundesnetzagentur eingeholt.

Versuchsaufbau und Ergebnisse: GNSS-Jamming

Das mit dem VMPS versehene Fahrzeug ist mit einem hochgenauen Referenzpositionierungssystem ausgestattet, in dem neben GNSS-Sensorik eine präzise Trägheitsmesseinheit integriert ist, sodass mittels Vorwärts- und Rückwärtsfilterung im Postprocessing eine hochgenaue Referenzposition bestimmt wird. Das Referenzsystem dient als Bezugsquelle, um die Positionsfehler des VMPS zu bestimmen. Bild 5 zeigt den zeitlichen Verlauf des Positionsfehlers in seitlicher Fahrzeugrichtung und die vom VMPS ermittelte Integrität der Position. Das sogenannte Protection Level (PL) spiegelt die Obergrenze des Positionsfehlers wider und dient als Maß für die Vertrauenswürdigkeit der ermittelten Position. Je höher das PL, desto geringer die Vertrauenswürdigkeit der aktuellen Positionsausgabe. Die vertikale Linie gibt den Zeitpunkt an, an dem sich das VMPS-Fahrzeug auf gleicher Höhe mit dem Störfahrzeug befindet.

Während des Überholvorgangs beträgt der seitliche Positionsfehler weniger als 0,5 m und bleibt somit innerhalb der PL-Grenzen, d. h. der berechneten Position des VMPS kann grundsätzlich vertraut werden. Es ist hervorzuheben, dass sich der Fehler der VMPS-Position in unmittelbarer Reichweite zum Störer nicht verschlechtert, sondern eher geringer wird, u. a. durch Detektion und Ausschluss gestörter Messungen. Ein guter Hinweis darauf, dass die Qualität der GNSS-Messgrößen während der Störung abnimmt, ist der Anstieg des PLs auf einen Wert von ± 3,2 m. Der VMPS bewertet die Störung mit einer Abnahme der Vertrauenswürdigkeit der Positionslösung und reagiert damit auf die verschlechterten GNSS-Empfangsverhältnisse. Nach etwa 100 m Entfernung zum Störfahrzeug kehren die PLs auf ihren ursprünglichen Wert zurück, da der GNSS-Empfang vom Störer nicht mehr oder nur noch unwesentlich beeinflusst wird und der VMPS die Situation korrekterweise wieder als ausreichend sicher einstuft.

Versuchsaufbau und Ergebnisse: GNSS-Spoofing

 Der Spoofer war mit einer GNSS-Richtantenne ausgestattet, die auf das VMPS-Fahrzeug ausgerichtet wurde. Der seitliche Abstand zwischen Spoofer- und VMPS-Fahrzeug betrug 5 m. In Bild 6 sind die X-, Y- und Z-Koordinaten in einem sogenannten Earth-Centered-Earth-Fixed-Koordinatensystem (ECEF) von getäuschter Trajektorie, VMPS-Position und Positionsinformation, die ausschließlich auf GNSS (GNSS only) beruht, aufgetragen. Die reine GNSS-Positionslösung ist eine VMPS-interne Information, die unabhängig vom Sensorfusionsfilter gerechnet wird. Die Positionen sind relativ zur Referenzposition des VMPS-Fahrzeugs aufgetragen.

Während der ersten 5 s war der Spoofer inaktiv. Danach setzte eine statische Spoofing-Attacke an der Position des VMPS-Fahrzeugs für die Dauer von 2,5 s ein. Nach 7,5 s wurde eine Positionsverschiebung mit einer konstanten Geschwindigkeit von 3,5 m/s eingeleitet. Beim Start des Spoofings traten keine Unterbrechungen der reinen GNSS-Position auf. Das deutet darauf hin, dass die Leistung des Spoofing-Signals nur geringfügig höher war als die der echten Signale, jedoch immer noch stark genug, um eine Wirkung auszuüben. Es ist zu erkennen, dass die reine GNSS-Position des VMPS in Richtung der verfälschten Position wandert, während die VMPS-Position der Sensorfusionslösung unbeeinflusst bleibt. Das VMPS hat den Täuschungsangriff im Prozessierungspfad der Sensorfusion somit erfolgreich detektiert und den Einfluss mitigiert.

Die Ergebnisse der durchgeführten Jamming- und Spoofing-Tests zeigen deutlich, wie leicht GNSS-Signale gestört und getäuscht werden können. Die Fusionierung mehrerer unabhängiger Sensordaten und geeignete Plausibilitätschecks der Daten sind ein wirksames Mittel, um einen Angriff zu erkennen und den Schutz der Verfügbarkeit, Kontinuität und Integrität des Gesamtsystems zu gewährleisten. Die Tests zeigten, dass der VMPS die Integrität der Positionslösung bei GNSS-Signalverlust und -verfälschung wahrt.

In Zukunft wird die Automobilindustrie in besonderem Maße gefordert sein, Gegenmaßnahmen für GNSS-Angriffe zu entwickeln. Zum einen muss der Fokus auf die Erkennung und Mitigation von Jamming und Spoofing gelegt werden. Zum anderen wird von staatlichen Institutionen erwartet, dass sie wirksame Maßnahmen ergreifen, um potenzielle Jamming- und Spoofing-Angriffe zu unterbinden. Neben dem sofortigen Ausfindigmachen von Angreifern sollte sowohl national als auch international der Schwerpunkt auf Maßnahmen zur wirksamen Bekämpfung von GNSS Jamming- und Spoofing-Attacken gelegt werden. Eine der größten Herausforderungen ist in diesem Zusammenhang die Entwicklung eines Industriestandards für ein Test- und Freigabeverfahren, das eine sichere GNSS-Positionierung im Automobilsektor zum Gegenstand hat. Darüber hinaus müssen zukünftige Entwicklungen der Jamming- und Spoofing-Bedrohungslage ständig überwacht und gemeldet werden. Nur so können rechtzeitig neue Angriffsmethoden in Standardisierungsarbeitsgruppen diskutiert und in einschlägigen Normen berücksichtigt werden. (eck)

Dr. Marco Limberger ist SOTIF Experte und Function Owner Integrity bei der Robert Bosch GmbH. Michael Baus war Projektdirektor für GNSS-Positionierung und ist seit 2021 Abteilungsleiter in der Forschung und Vorausentwicklung bei Robert Bosch. Ann-Kathrin Eisenhardt ist Teamleiter für den System Test bei der Robert Bosch GmbH. Dr. Boubeker Belabbas ist Fachreferent für Satellitennavigation und Integrity bei der Robert Bosch GmbH. Dr. Stefan Baumann arbeitet als Programm-Manager im Fachbereich der Satellitennavigation bei der IABG. Nikolas Dütsch ist Elektrotechnik-ingeneur und Fachexperte im Bereich von GNSS Jamming- undSpoofing-Untersuchungen im Satellitennavigationsteam bei der IABG. Matthias Reitenhardt ist Experte im Bereich der Satellitennavigation und Sensorfusion und arbeitet im Satellitennavigationsbereich der IABG.

[1] C4ADS, „Above us only stars,“ 09 07 2021. [Online]. Available: <a href="https://www.c4reports.org/aboveusonlystars">https://www.c4reports.org/aboveusonlystars</a>.

[2] STRIKE3 Consortium under EU-H2020 co-funded by European GNSS Agency, „STRIKE3,“ 09 07 2021. [Online]. Available: <a href="http://gnss-strike3.eu/">http://gnss-strike3.eu/</a>.

[3]  T. E. H. e. al., „Assessing the Spoofing Threat: Development of a Portable GPS Civilian Spoofer,“ ION GNSS Conference, 16 – 19 09 2008.

[4] Robert Bosch GmbH, 09 07 2021. [Online]. Available: <a href="https://www.bosch-mobility-solutions.com/en/solutions/">https://www.bosch-mobility-solutions.com/en/solutions/</a> sensors/vehicle-motion-and-position-sensor/. [Zugriff am 09 07 2021].

[5]  iABG mbH Reitenhardt, Matthias, Independent Testbed for Positioning, Navigation, and Timing in GNSS-denied / degraded environments for the development of cost-effective (military or commercial) sensor platforms, DEFTECH Konferenz armasuisse, August 2021.

[6]  DLR Raumfahrtmanagement Abteilung Navigation, Galileo Thementag Jamming & Spoofing von GNSS-Signalen, Virtuelle Veranstaltung, 2021.

[7]  Oliver Towlson (NSL); David Payne (NSL); Patrik Eliardsson (FOI);Venkatesh Manikundalam (GNSS labs), „STRIKE3 D6.2: THREAT DATABASE ANALYSIS REPORT,“ Galileo Space Agency, 2019.

[8] Robert Bosch GmbH, „Prüfzentrum Boxberg,“ [Online]. Available: <a href="https://www.bosch-mobility-solutions.com/de/loesungen/entwicklungs-services/pruefzentren/">https://www.bosch-mobility-solutions.com/de/loesungen/entwicklungs-services/pruefzentren/</a> pruefzentrum-boxberg/. [Zugriff am 15 7 2021].

Bild 4: Schematische Darstellung des  Spoofing-Szenarios mit VMPS und Angreiferfahrzeug (beide statisch)  und einer dynamischen Testumgebung  

Bild 5: Positionsfehler in lateraler Fahrzeugrichtung (durchgezogene Linie) und den PLs über der Zeit für einen Überholvorgang. 

Bild 6: ECEF-Positionsabweichungen in X-, Y- und Z-Richtung von der Antenne des Opferempfängers für die reine GNSS-basierte Position (GNSS only), VMPS-Position (Fused) und Spoofer-Trajektorie in Abhängigkeit von der Zeit

Dr. Marco Limberger ist SOTIF Experte und Function Owner Integrity bei der Robert Bosch GmbH.

Michael Baus war Projektdirektor für GNSS-Positionierung und ist seit 2021 Abteilungsleiter in der Forschung und Vorausentwicklung bei Robert Bosch. © Bosch

Ann-Kathrin Eisenhardt ist Teamleiter für den System Test bei der Robert Bosch GmbH. © Bosch

Dr. Boubeker Belabbas ist Fachreferent für Satellitennavigation und Integrity bei der Robert Bosch GmbH. © Bosch

Dr. Stefan Baumann arbeitet als Programm-Manager im Fachbereich der Satellitennavigation bei der IABG. © IABG

Nikolas Dütsch ist Elektrotechnik-ingeneur und Fachexperte im Bereich von GNSS Jamming- undSpoofing-Untersuchungen im Satellitennavigationsteam bei der IABG.  © IABG

 Matthias Reitenhardt ist Experte im Bereich der Satellitennavigation und Sensorfusion und arbeitet im Satellitennavigationsbereich der IABG. © IABG

Bild 1: PPD-Störsender mit einer Sendeantenne zum Stören des oberen L-Bandes

Bild 2: Schematische Darstellung des GNSS-Störszenarios mit VMPS-Testfahrzeug und Fahrzeug mit installiertem Störsender

Bild 3: Komponentenübersicht mit Verbindungen zwischen dem GNSS-Signalsimulator, GPS-gesteuerter Uhr, GNSS-Empfänger zur Gewinnung der aktuell ausgestrahlten Navigationsnachricht und Verstärker sowie Empfangs- und Sendeantenne

Robert Bosch

Safety / Security

Elektronik

Kfz-Elektronik

Fahrerassistenzsysteme / Automatisiertes Fahren

Vernetzte Fahrzeuge vor Cyberangriffen schützen

Quantencomputer gelten als nächste Revolution in der Informationstechnik. Noch sind die Rechnersysteme, die mithilfe von Quantentechnologie heutige Cybersecurity-Mechanismen spielend überwinden, nicht verfügbar.

Quantencomputer gelten als nächste Revolution in der Informationstechnik. Noch sind die Rechnersysteme, die mithilfe von Quantentechnologie heutige Cybersecurity-Mechanismen spielend überwinden, nicht verfügbar. Doch jetzige Fahrzeuge sind mindestens 15 Jahre und länger auf der Straße. Wie lassen sich diese gegen mögliche künftigen Cyberattacken aus dem Quantencomputer wappnen? Den Anfang machen erste Post-Quantum Algorithmen in Automotive-spezifischen Krypto-Bibliotheken.

Die Absicherung von vernetzten Fahrzeugen und Fahrzeugsystemen gegen Cyberangriffe, Manipulation und unerlaubten Zugriff ist bekanntermaßen Grundvoraussetzung für ihre Funktions- und Verkehrssicherheit. Die vernetzte Mobilität der nahen Zukunft ist ohne Cybersecurity schlichtweg nicht denkbar. Neue Regularien und Standards wie die UN R155 oder die ISO/SAE 21434 sowie zunehmende Anstrengungen der Autohersteller hin zu Security by Design, wirksameren Security-Funktionen im Fahrzeug und kontinuierlichem Risikomanagement belegen das.

Asymmetrische Kryptografie versus Quantenmechanik

Die Cybersicherheit im und um das Fahrzeug wird heute vornehmlich mithilfe digitaler Signaturen und Zertifikate gewährleistet. Diese werden mittels asymmetrischer Algorithmen erstellt, die dementsprechend heute in vielen eingebetteten Systemen im Fahrzeug zur Anwendung kommen. So werden zum Beispiel Over-the-air-Updates (OTA), V2X-Kommunikation und sichere Diagnoseschnittstellen per asymmetrischer Kryptografie vor unerlaubten Zugriff geschützt. Nicht minder wichtig, beispielsweise für die TLS-Kommunikation, ist die Public-Key-Verschlüsselung. Signatur und Schlüsselgenerierung erfolgen dabei über bekannte Algorithmen wie RSA, ECDSA und ECDH, die auf mathematische Problemstellungen, die Primfaktorzerlegung und die Lösung diskreter Logarithmen auf elliptischen Kurven, zurückgreifen. Diese kryptografischen Hürden sind für herkömmliche Computer mit vertretbarem Aufwand nicht zu überwinden (Bild 1).

Quantenalgorithmen indes sind heute bereits in der Lage diese klassischen asymmetrischen Algorithmen zu knacken. Die gute Nachricht: Noch fehlt es an kryptografisch relevanten Quantencomputern, die in der Praxis solche Operationen ausführen könnten. Tatsächlich sind die ersten funktionsfähigen Rechnersysteme, die auf Quantenmechanik beruhen, bislang nur unter extrem großem Aufwand und unter Laborbedingungen zu betreiben. Die Entwicklung jedoch ist vorgezeichnet: Die mit Qubits statt Bits arbeitenden Quantenrechner werden heutige Supercomputer in ihrer Rechenleistung für bestimmte Operationen exponentiell übertreffen. Realistische Annahmen gehen davon aus, dass sie in ca. 15 bis 20 Jahren verfügbar sind – unweigerlich auch für böswillige Angriffe auf IT-Systeme. Spätestens dann werden herkömmliche asymmetrische Algorithmen keine ausreichende Sicherheit mehr bieten können. Eine sichere Vergabe von Zertifikaten wird in dieser künftigen Post-Quantum-Ära nur mit neuen, Quantencomputer-resistenten Algorithmen zu gewährleisten sein (Bild 2).

Lange Fahrzeuglebensdauer erfordert Schutz

Fahrzeuge, die in den kommenden Jahren vom Band laufen, sind demnach von dieser Entwicklung bereits konkret betroffen. Lebensspannen von 15 Jahren oder mehr sind hier ja die Regel; bei batterieelektrischen Fahrzeugen rechnet man gar mit noch längeren Lebenszyklen. Damit stellt sich die Frage, welche Maßnahmen bereits heute bei der Entwicklung der Fahrzeugarchitektur zu berücksichtigen sind, um im Sinne eines lebenslangen Cyberschutzes und kontinuierlichen Risikomanagements sicherzustellen, dass die Fahrzeugsysteme auch im Post-Quantum-Zeitalter noch vor Angriffen und unerlaubtem Zugriff gefeit bleiben. Post-Quantum-Kryptografie (Post Quantum Cryptography, PQC) muss idealerweise heute schon konzeptionell in die Fahrzeugentwicklung mit einbezogen werden – entweder indem die Signatur- und Verschlüsselungsmechanismen und die Auswahl kryptografischer Algorithmen bereits quantensicher erfolgen, oder indem die Security-Funktionen so konzipiert und ausgelegt sind, dass sie jederzeit und in ausreichendem Maße auf Quantencomputer-Resistenz hin Upgrade-fähig sind.

NIST-Ausschreibung für quantensichere Algorithmen

 Als Richtschnur für die Auswahl geeigneter PQC können dafür die bereits vorliegenden Ergebnisse aus dem laufenden NIST-Post-Quantum-Projekt herangezogen werden. Das amerikanische National Institute of Standards and Technology (NIST) ruft seit einigen Jahren zur Einreichung geeigneter Public-Key-Verschlüsselungs- und Signaturverfahren auf. Infolgedessen gibt es mittlerweile erste Post-Quantum-reife kryptografische Algorithmen; bis Ende 2021 wird die Standardisierung einer ersten Auswahl solch quantensicherer Algorithmen durch das NIST erwartet. Dabei werden voraussichtlich mehrere Algorithmen für die unterschiedlichen Kategorien – Public-Key-Verschlüsselungsmechanismen, Key Encapsulation Mechanisms (KEM) und digitale Signatur – standardisiert.

Die Wahl der geeigneten verfügbaren Algorithmen für die Implementierung Post-Quantum-resistenter Cybersecurity orientiert sich dann an folgenden Fragestellungen:

<ul><li>Wie muss die Struktur der Security-Funktionen angepasst werden, um die neuen Algorithmen mit einbeziehen zu können?</li><li>Welcher Hardware-Erfordernisse bedarf es dafür in Zukunft?</li><li>Wie wird eine Public-Key-Infrastruktur (PKI) mit quantensicheren Algorithmen aussehen?</li></ul>

Quantensichere Algorithmen für Automotive Krypto-Bibliothek

Auf dieser Basis hat Escrypt im Rahmen des Projektes Full-Lifecycle-Post-Quantum (FLOQI-PKI, Info-Box) die aus der NIST-Ausschreibung hervorgegangenen quantensicheren Algorithmen im Hinblick auf ihre Eignung für den Automotive-spezifischen Einsatz evaluiert. Die erste Wahl fiel dabei auf zwei gitterbasierten Algorithmen:

<ul><li>CRYSTALS-Dilithium als Signaturalgorithmus und</li><li>CRYSTALS-Kyber als KEM.</li></ul>

Beide Algorithmen finden sich auch in der finalen Auswahlrunde der NIST-Verfahrens. Ausgewählt als gute Kandidaten für die Anwendungsfälle im Automobilbereich wurden sie insbesondere aufgrund ihrer Leistung und ihres konstanten Ressourcenverbrauchs (Bild 3).

Um diese beiden Post-Quantum-Algorithmen heute schon für die Automotive-Anwendungen verfügbar zu machen, hat Escrypt sie jüngst in seine Automotive-spezifische Krypto-Bibliothek implementiert. Solch eine kryptografische Bibliothek ist Kernkomponente der Cybersicherheit im Fahrzeug. Sie stellt die nötigen kryptografischen Algorithmen, Formate und Verschlüsselungsprotokolle für die meisten Security-Anwendungen bereit. So greift beispielsweise die digitale Signaturverifikation, etwa für Flash-Lösungen oder die Aktivierung von Secure Boot, auf eine Krypto-Bibliothek zurück. Automotive Crypto Libraries sind außerdem auf die speziellen Anwendungen und Anforderungen des Fahrzeugs und seiner Infrastruktur hin entwickelt. Das bedeutet, dass die Algorithmen gemäß ASPICE Level 2 und ISO 262662 (bis ASIL D) implementiert werden, wobei die begrenzten Ressourcen und erforderliche Leistung der eingebetteten Systeme Fahrzeug besondere Berücksichtigung finden.

Mit einer derartigen PQC-fähigen Krypto-Bibliothek können Automobilhersteller und -zulieferer einen ersten entscheidenden Schritt hin zu einer Post-Quantum-resistenten Cybersicherheit ihrer Fahrzeuge und Fahrzeugkomponenten vollziehen. Sie können auf diese Weise bereits heute damit beginnen, Post-Quantum-Algorithmen auf ihren Zielsystemen zu evaluieren und im Zuge eines Proof-of-Concept ermitteln, wie diese sich in der angewandten Praxis verhalten und welche Anforderungen die Post-Quantum-Kryptografie an die Hardware stellt.

Gerade weil dieses Entwicklungsfeld noch neu ist und zum Teil anderen mathematischen Theorien folgt als die bisher verwendeten kryptografischen Algorithmen, ist es wichtig, Qualität und Wirksamkeit der Implementierung zu verifizieren – und zwar über die etablierten Entwicklungsprozesse hinaus. Nur so lässt sich beispielsweise herausfinden, ob die Zielsysteme mit ihren implementierten quantensicheren Algorithmen in der angewandten Praxis auch Seitenkanalangriffen standhalten. Security-Anbieter, Forschung und Anwender im Automotive-Bereich werden hier über die kommenden Jahre laufend gegenseitigen Erfahrungsaustausch pflegen müssen, um die Qualität der PQC für Automotive Anwendungsfälle weiter zu verbessern.

Quantenresistente Hardware-Security-Module

Die Post-Quantum-Ära hat gerade erst begonnen. Mit ihr wird die Absicherung vernetzter Fahrzeuge und Flotten gegen Cyberattacken neu verhandelt. Die Industrie muss sich zügig die notwendigen Grundlagen erarbeiten und neue Fahrzeugarchitekturen und -systeme auf zukünftige Quantensicherheit hin auslegen. Mit der um die ersten quantensicheren Algorithmen Dilithium und Kyber erweiterten Krypto-Bibliothek können Automobilhersteller und Zulieferer den Fahrzeugsystemen heute schon erste Teile der notwendigen Automotive-Security-DNA dafür mitgeben – und diese dann gemäß jeweils aktueller Erkenntnisse und Best-Practices um weitere Post-Quantum-Algorithmen erweitern.

Vor allem jedoch ist damit der Weg geebnet hin zu einer erweiterten Quantencomputer-widerständigen Absicherung des Fahrzeugs. Denn in der Folge lassen sich so auch die Security-Funktionen im Hardware-Security-Modul (HSM) auf den Mikrocontrollern und -prozessoren der künftigen ECUs, DCUs und Vehicle Computer quantensicher ausführen. Voraussetzung auf der HSM-Hardware-Seite sind leistungsstarke Acceleratoren. So machen zum Beispiel Hashing-Algorithmen (SHA3 oder auch SHA2–256) bis zu 80 Prozent des Rechenbedarfs der asymmetrischen PQC-Verfahren aus. Aber auch ein leistungsstarker AES-256 für die symmetrische Kryptografie wird zum absoluten Muss-Kriterium im Post-Quantum-Zeitalter. Folgerichtig braucht es einen leistungsfähigen Security-Stack auf dem HSM, der die entsprechenden Hardware-Acceleratoren unterstützt und sie in sicherheitsrelevante Funktionen und Protokolle integriert, die dann der Applikations-Software zur Verfügung gestellt werden. Solchermaßen mit Post-Quantum-fähigem HSM bestückte Mikrocontroller und Mikroprozessoren werden die notwenige Cybersicherheit für das Fahrzeug bis in die Ära der Quantencomputer hinein gewährleisten können. (eck)

Dr. Efstathia Katsigianni arbeitet als Security Consultant Post Quantum Cryptography bei Escrypt in Berlin. Dipl.-Math. Sandra Weigl ist Product Manager Crypto Library bei Escrypt in Stuttgart.

Bild 2: Die Entwicklung von Quantencomputer macht derzeit große Fortschritte. Die IT-Sicherheit in einer zunehmend vernetzten Welt stellt dies vor große Herausforderungen.

Bild 3: Die ausgewählten Algorithmen des NIST-Wettbewerbs weisen große Unterschiede bei Schlüssel- und Signaturgrößen auf. Für Automotive-Anwendungen sind nicht alle gleich gut geeignet. 

 Dr. Efstathia Katsigianni arbeitet als Security Consultant Post Quantum Cryptography bei Escrypt in Berlin.© Escrypt

Dipl.-Math. Sandra Weigl ist  Product Manager Crypto Library bei Escrypt in Stuttgart. © Escrypt

Bild 1: Fahrzeuge sind künftig vielfältig vernetzt. Digitale Signaturen und Zertifikate werden die Authentizität beim Datenaustausch in Zukunft auch quantensicher nachweisen müssen.

Escrypt

FLOQI: Forschungsprojekt für Post-Quantum-Security

Das vom Bundesministerium für Bildung und Forschung förderten Forschungsvorhaben FLOQI zielt auf die Entwicklung einer Quantencomputer-widerständigen Public-Key-Infrastruktur, die in einer künftigen Post-Quantum-Ära über ihren gesamten Lebenszyklus hinweg die sichere Vergabe von Zertifikaten gewährleistet. Die Technische Universität Berlin, das Fraunhofer AISEC, BMW, Bosch, Nixdorf, Escrypt und andere setzen dabei Post-Quantum-Verfahren auf unterschiedlichen Plattformen um und erproben deren Einsatz – insbesondere auch für die Automobilbranche. Die Ergebnisse sollen dann in internationale Standards einfließen.

Connectivity (Bussysteme, Telekommunikation, 4G / 5G, WLAN)

Security von Beginn an im Design-Prozess verankern

Mehr Sicherheit  für vernetzte Fahrzeuge

Angesichts der Zunahme von künstlicher Intelligenz und autonomen Systemen, die Entscheidungen aufgrund von in Echtzeit erfassten Daten treffen und der Tatsache, dass die meisten kritischen Systeme im Fahrzeug als Signal übertragen werden, ist es unerlässlich, die Elektronik im Auto von Anfang an auf Security & Safety zu trimmen.

Angesichts der Zunahme von künstlicher Intelligenz und autonomen Systemen, die Entscheidungen auf der Grundlage von in Echtzeit erfassten Daten treffen und der Tatsache, dass die meisten kritischen Systeme im Fahrzeug als Signal übertragen werden, ist es unerlässlich, die Elektronik im Auto von Anfang an auf Security & Safety zu trimmen. Security lässt sich nicht nachträglich in den Entwicklungsprozess einpflegen.

Im Wettbewerb, den Nutzern immer anspruchsvollere Erfahrungen zu bieten, entwickeln Fahrzeughersteller und Zulieferer immer komplexere Software für das Auto. Dieses verfügt nun über mehrere Kommunikationsschnittstellen mit den Insassen, dem OEM und der Verkehrsinfrastruktur – von Musik und Video bis über Over-the-Air-Software-Updates und V2X-Kommunikation (Bild 1). Alle diese Schnittstellen können das Risiko eines Cyberangriffs bergen, der die gesamte Produktion des Modelljahres betrifft. Die Fahrzeughersteller sind sich des Risikos bewusst, und es gibt Schwachstellen. Wie lässt sich jedoch das richtige Verfahren für Cybersicherheit, Risikobewertung und -analyse durchführen? Was soll unternommen werden, wenn jemand eine Schwachstelle findet? Wie lassen sich die Auswirkungen auf die Sicherheit der Kunden und auf die Marke minimieren?

Sicherheitsbedenken im Automotive-Bereich

In den letzten zehn Jahren wurden viele schwerwiegende Schwachstellen mit sicherheitskritischen Folgen aufgedeckt. Ein Angriff auf das System über anfällige Kommunikationsschnittstellen wie Bluetooth, Wi-Fi (WLAN) und LTE ist die Standardmethode, um Zugang zu den kritischen Systemen zu erhalten, die intern miteinander vernetzt sind.

Angreifer nutzen meist eine der Schwachstellen in der Informations-Hub, weil auf dem Infotainment-System häufig ein Allzweck-Betriebssystem wie Linux oder Android ausgeführt wird. Nachdem sie sich Zugang auf das System verschafft haben, wird eine Schad-Software aufgespielt, die versucht, auf den CAN-Bus oder ein ähnliches Busprotokoll wie FlexRay oder LIN zuzugreifen. Weil der CAN-Bus ein Standard-Automotive-Protokoll ist und definiert wurde, bevor die Cybersicherheit des Fahrzeugs überhaupt von Bedeutung war, kann er sicherheitskritische Module wie Motorsensoren, Bremse und Getriebe umfassen. Hat man Zugriff auf ein Fahrzeug, kann der CAN-Bus ausgespäht und das Protokoll analysiert werden. Ein typischer Angriff besteht aus zwei Teilen (Bild 2). Im ersten Schritt wird das Infotainment-System angegriffen; im zweiten der Fahrzeugbus-Prozessor. Automobilhersteller setzen Firewalls und Isolation zwischen den Systemen ein, um die Sicherheit des Systems zu erhöhen – dies muss jedoch richtig konzipiert und bewertet werden.

Wie können Entwickler bei der Vielzahl komplexer Software-Module im Fahrzeug, die auch von Drittanbietern und Open Source wie Linux/Android stammen, kritische Systemausfälle minimieren? Ein korrekter Software-Entwurf und -Entwicklungsprozess kann Schwachstellen verhindern. Entwickler müssen dabei jede Komponente bewerten und den Code sowie die Interaktionen mit anderen Komponenten verfolgen.

In der Vergangenheit gab es keine Standards für die Cybersicherheit in der Automotive-Branche und Unternehmen entwickelten ihren eigenen Verfahren, um Cybersecurity genüge zu tragen. Wird eine Schwachstelle aufgedeckt, müssen Kunden und andere Beteiligte informiert und ein Patch erstellt und bereitgestellt werden. Andere mögliche Schwachstellen müssen angegangen werden, um die wichtigsten und kritischsten Module vor weiteren Angriffen zu schützen.

Die ISO 26262 ist ein etablierter Standard für funktionale Sicherheit, der die Bewertung von Software-Komponenten vorschreibt. Sie berücksichtigt jedoch nicht den Software-Lebenszyklus wie OTA-Updates und wurde nicht als Norm für Security entwickelt.

Im Gegensatz dazu ist die ISO 21434 ein Rahmenwerk, das sich direkt auf die Cybersicherheit im Automotive-Bereich bezieht. Sie ist einer der Sicherheitsstandards, die vom Echtzeit-Betriebssystem (Real-time Operating System, RTOS) Integrity von Green Hills Software unterstützt werden. Die ISO 21434 gewinnt zunehmend an Bedeutung, weil verschiedene Regionen weltweit die Anforderungen des UNECE WP.29 Automotive Cybersecurity Management Systems (CSMS) in ihre Gesetzgebung übernehmen. Sie ist ein relevanter Standard für die Umsetzung der UNECE-WP.29-CSMS-Anforderungen in die Praxis.

Das Rahmenwerk deckt das Cybersicherheitsmanagement vom Konzept über die Fertigung bis zum Betrieb ab und definiert eine gemeinsame Sprache für Cybersicherheit. Der Standard hilft zu verstehen, was falsch laufen könnte, wie Unternehmen die Abteilung für Cybersicherheit organisieren können, was sie überprüfen sollten und wie man Probleme handhabt. Es definiert Begriffe, die im Zusammenhang mit Cybersicherheitsrisiken verwendet werden. Das ist wichtig, weil die Verwendung derselben Terminologie für die klare Kommunikation zwischen Organisationen und Unternehmen unerlässlich ist.

Die ISO 21434 bezieht sich eher auf das Lebenszyklusmanagement als auf eine bestimmte Technik, Methode oder ein System. Das traditionelle Sicherheitsmanagement geht nicht weit über die Serienfertigung hinaus. Sobald die Entwicklung abgeschlossen und zertifiziert ist, wird der Code eingefroren. Das Lebenszyklusmanagement deckt einen größeren Bereich ab, der auch den Betrieb und die Wartung umfasst. Die ISO 21434 beschreibt auch, wie Risikobewertungen rund um die Cybersicherheit in jedem Teil des Lebenszyklus angewendet werden können.

Der Standard dient als Leitfaden, um schützenswerte Assets, Bedrohungsszenarien und Risiken zu identifizieren und zu bewerten: Welche Möglichkeiten gibt es, in das Fahrzeugnetz einzudringen? Kann das aus der Ferne erfolgen oder muss sich der Angreifer in der Nähe des Fahrzeugs befinden? Müssen sich Angreifer physisch Zugang zum Fahrzeug verschaffen?

Einige Assets stehen in direktem Zusammenhang mit der Sicherheit, andere nicht. Der Diebstahl persönlicher Daten ist ein Problem, aber kein sicherheitskritisches Ereignis. Wenn jedoch das Bremssystem nicht mehr funktioniert, kann das schwerwiegende Folgen haben. Der Standard hilft bei der Risikobewertung und bietet Hilfsmittel zur Bewertung verschiedener Auswirkungen.

Sicherheitszertifiziertes RTOS ist unerlässlich

 Die richtigen Tools und Prozesse erleichtern die Verwaltung des Produktlebenszyklus. Ein sicherheitszertifiziertes Echtzeit-Betriebssystem ist unerlässlich, um undurchdringbare Module im Fahrzeug zu verbauen. Ein solches RTOS (oder Separation Kernel) verwendet Hardware-Speicherschutz, um Treiber, Software von Drittanbietern, Kommunikation, Embedded-Anwendungen zu isolieren und zu schützen sowie eine oder mehrere Instanzen von Android oder Linux zu hosten. Sichere Partitionen garantieren die Trennung von Benutzeraufgaben und sind robuster als sie normalerweise in Universal-Betriebssystemen wie Linux zu finden sind. Der Heap wird beispielsweise getrennt, sodass ein Speicherleck in einer Anwendung keine Auswirkungen auf andere Adressräume hat. Die minimierte Störanfälligkeit zwischen den Anwendungen macht die Risikobewertung überschaubarer und bietet mehr Möglichkeiten, das Risiko zu mindern und zu priorisieren.

Die zuverlässige Echtzeit-Trennungs-Partitionsarchitektur führt neben kritischen Echtzeit-Software-Funktionen mehrere beliebige Gastbetriebssysteme aus (Bild 3). Anwendungen und Gastbetriebssysteme werden effizient auf einen oder mehrere Cores verteilt und können gemäß einem strengen Zugriffskontrollmodell effizient miteinander kommunizieren und Systemperipherie wie die GPU oder Ethernet gemeinsam nutzen. Durch die getrennte Architektur kann das RTOS eine klare Trennung zwischen den Partitionen gewährleisten. Wenn nur eine Anzahl begrenzter Module mit der Fahrzeugbusschnittstelle kommunizieren kann, erhöht das die Systemtrennung und Sicherheit.

Neben dem Betriebssystem sind nach ISO 26262 zertifizierte Entwicklungswerkzeuge wichtige Komponenten für den Aufbau eines sicheren Systems für Cybersicherheit. Die ISO 21434 erwähnt einige Codierungsrichtlinien wie MISRA C, die zur Risikominderung beitragen. MISRA identifiziert Aspekte der C-Programmiersprache, die aufgrund ihrer Mehrdeutigkeit und Anfälligkeit für häufige Sprachfehler vermieden werden sollten. Zum Beispiel im folgenden Code:

Die ursprüngliche Absicht des Codes ist wohl „total == num++“, nicht „total = num++“. Der Programmierer hat das zusätzliche Zeichen „=“ übersehen. Daher wird der Code nicht wie erwartet ausgeführt. Selbst wenn der Fehler bemerkt und „=“ in „==“ geändert wird, wird „num“ dann erhöht? Die Antwort lautet ja und nein, denn wenn das Flag falsch ist, wird „num“ nicht erhöht. Die MISRA-Richtlinien helfen, diese Art von Fehlern zu vermeiden.

MISRA C ist ein Leitfaden für Software-Entwickler und keine Spezifikation für einen Compiler. Die manuelle Überprüfung des Codes wäre ein mühsamer Prozess. Daher ist es besser, einige dieser Schritte zu automatisieren, um eine einheitliche Durchsetzung zu gewährleisten. Aus diesem Grund kommt es auf die Wahl eines C-Compilers an, der MISRA C 1998, MISRA C:2004 und die neue Version MISRA C:2012 für die gängigsten Automotive-Systemprozessoren wie Arm, RH850, Power Architecture, MIPS und Intel unterstützt.

Mit einer wachsenden Zahl externer Kommunikationsschnittstellen und einer Vielzahl von Software-Anwendungen und Betriebssystemen bieten moderne Fahrzeuge eine große Angriffsfläche für Hacker. Selbst wenn Schwachstellen identifiziert und Gegenmaßnahmen eingeleitet werden, ist der Prozess der Aktualisierung von Systemen und sicheren Installation von Patches in großem Umfang äußerst kostspielig und schwierig.

Der Standard ISO/SAE 21434, veröffentlicht im August 2021, bietet einen Rahmen, der speziell für die Cybersicherheit im Automotive-Bereich entwickelt wurde. Die ISO 21434 ist entscheidend für die Umsetzung der UNECE-WP.29-CSMS-Anforderungen (die jetzt weltweit übernommen werden) in die Praxis. Es ist daher unerlässlich, ein Safety- und Security-zertifiziertes RTOS wie Green Hills INTEGRITY zu verwenden, das die ISO 21434 unterstützt. Auch eine zertifizierte und kompatible Toolchain sollte zum Einsatz kommen, um die Sicherheit bei der Entwicklung von Embedded-Systemen für Anwendungen im Fahrzeug zu gewährleisten. (eck)

Ryan Kojima ist Embedded Software Consultant, Advanced Products bei Green Hills Software.

Bild 1: Gefährdete Schnittstellen im Fahrzeug

Bild 2: Typischer Angriffsweg eines Hackers 

Bild 3: Beispiel eines Safety- und Security-zertifizierten Echtzeit-Betriebssystems mit Trennung

Ryan Kojima ist Embedded Software Consultant, Advanced Products bei Green Hills Software. © Green Hills Software

Green Hills Software

Software / Betriebssysteme / KI

Unfälle durch bestmöglichen Sicherheitsstandard vermeiden

Ein Safety Management System für automatisierte Fahrzeuge?

Dieser Artikel beschäftigt sich mit den Möglichkeiten und Vorteilen, die ein Safety Management System bringen kann.

In automatisierten Fahrzeugen übernehmen Fahrerassistenzsysteme teilweise die Fahraufgabe, in autonomen Fahrzeugen wird der Fahrer sogar vollständig ersetzt. Doch wenn kein Verantwortlicher mehr das Fahrzeug führt, wer ist dann für die Sicherheit während des Betriebs zuständig? Dieser Artikel beschäftigt sich mit den Möglichkeiten und Vorteilen, die ein Safety Management System bringen kann.

Nach mehreren Zwischenfällen bei der Erprobung von automatisierten Fahrzeugen wird die Anwendung eines Safety Management Systems (SMS) für automatisierte Fahrzeuge vermehrt diskutiert und empfohlen. Beispielsweise hat das National Transportation Safety Board (NTSB) nach der Evaluierung eines tödlichen Unfalls bei der Erprobung eines automatisierten Fahrzeugs der Advanced Technologie Group von Uber Technologies, Inc. die Einführung eines Safety Management Systems befürwortet [1].

Safety Management Systeme werden bereits in anderen sicherheitskritischen Domänen wie der Luftfahrt, Schifffahrt und dem Schienenverkehr angewendet. Nach der Australian Civil Aviation Safety Authority (CASA) wird ein Safety Management System wie folgt definiert: „Ein Sicherheitsmanagementsystem ist ein systematischer Ansatz für das Sicherheitsmanagement, einschließlich Organisationsstrukturen, Verantwortlichkeiten, Richtlinien und Verfahren. Ein SMS ist skalierbar, sodass es an die Größe und Komplexität des Unternehmens angepasst werden kann“ [2].

Das Modell der Luftfahrt beruht auf vier Komponenten – Safety Policy, Safety Risk Management, Safety Assurance, Safety Promotion – und fünfzehn Elementen, die nach dem Standard der International Civil Aviation Organization (ICAO) vorgeschrieben werden [3].

Selbst wenn das Rahmenwerk des Safety Management Systems aus der Luftfahrt auf die Automobilindustrie und die Anwendung für automatisierte Fahrzeuge übertragen werden kann, sind zur Optimierung eventuelle Anpassungen notwendig. Tabelle 1 zeigt eine detaillierte Zusammenstellung der Elemente, inklusive Ergänzungen für die Automobilindustrie.

Allgemein ist die Safety Policy für das Management-Engagement und die Definition von Prozessen und organisatorischen Strukturen zuständig. Das Safety Risk Management dient der Identifizierung von Gefährdungen und dem Bewerten und Mildern von Risiken. Die Safety Assurance ist für das Bewerten der kontinuierlichen Effektivität der Risikomanagementstrategien da und die Safety Promotion trägt zur Verbreitung einer positiven Sicherheitskultur durch Training, Kommunikation und andere Aktionen bei [4].

SMS vs. Einsatz bekannter Sicherheitsstandards

Bestehende Sicherheitsstandards, die in der Automobilindustrie zum Einsatz kommen, sind gut etabliert und beinhalten unter anderem das Safety Management. Wozu wird dann ein Safety Management System benötigt?

Functional Safety Management wird nach dem Standard für funktionale Sicherheit von elektronischen-sicherheitsrelevanten Systemen definiert. Alle Aktivitäten, die während der Phasen des Produkt-/Prozesslebenszyklus der funktionalen Sicherheit erforderlich sind, werden hierzu beschrieben. Neben Aktivitäten werden auch Verantwortlichkeiten im Rahmen des Functional Safety Management definiert. Diese sind spezifisch für Personen und Positionen, Abteilungen und Organisationen. [5]

Für den sicheren Betrieb eines automatisierten Fahrzeugs wird eine allgemeine Sicherheit des Systems inklusive äußerer Einflüsse benötigt. Die funktionale Sicherheit von Straßenfahrzeugen beschreibt die „Abwesenheit eines unangemessenen Risikos aufgrund von Gefährdungen durch Fehlverhalten von E/E-Systemen“ [6].

Demnach behandelt die funktionale Sicherheit Risiken bei Systemausfällen, deckt aber keine Sicherheitsrisiken ab, die ohne Systemausfall entstehen. Um den weiteren Gefährdungsbereich abzudecken, wurde der Standard „Safety Of The Intended Functionality“ (SOTIF) eingeführt. Diese Norm soll zur Sicherheit in Situationen ohne Systemausfall beitragen und betrachtet hierfür System und Operational Design Domain (ODD). Der spezifizierte Betriebsbereich beinhaltet beispielsweise Parameter wie Straßentypen, Geschwindigkeitsbereich und Umgebungsbedingungen, in dem das automatisierte Fahrzeug operiert.

Im Rahmen der SOTIF wird zwischen vorhersehbaren und unvorhersehbaren Gefährdungen ohne Systemausfall unterschieden. Außerdem werden Gefährdungen auf Grundlage von vorsätzlichem Missbrauch des Systems betrachtet [7].

Selbst wenn das Safety Management in den Sicherheitsstandards erwähnt wird, ist dieses nicht für das komplexe System eines automatisierten Fahrzeugs ausgelegt. Einige Elemente, Definitionen und Methoden stimmen mit den Inhalten des vorgesehenen Safety Management Systems überein, sind aber nicht ausreichend, um die allgemeine Sicherheit während der Entwicklung, Operation und Rückgang des automatisierten Fahrzeuges zu gewährleisten.

Ziele und Vorteile eines Safety Management Systems

 Zusätzlich zum bereits erwähnten Ziel, den bestmöglichen Sicherheitsstandard für automatisierte Fahrzeuge zu gewährleisten, soll die allgemeine Sicherheit des Fahrsystems, sowie das Safety Management System an sich, kontinuierlich verbessert werden.

Eine höhere Sicherheit macht sich durch weniger Vorfälle und Unfälle bemerkbar. Des Weiteren ist die Schwere des Ereignisses neben der Auftretenswahrscheinlichkeit zu beachten. Die Stärken eines Safety Management Systems werden in anderen sicherheitskritischen Domänen bereits dokumentiert. Ein Rückgang an Vorfällen  und Unfällen, eine Reduzierung von direkten und indirekten Kosten, Versicherungsprämien, Verbesserung der Mitarbeiterproduktivität und eine nachweisliche Sorgfalt bei rechtlichen  und behördlichen Sicherheitsuntersuchungen, ist in der Luftfahrt zu verzeichnen [8].

Um solche Ergebnisse auch beim automatisierten Fahren zu erreichen, sind spezifische Anpassungen der Struktur notwendig. Idealerweise ist ein Rahmenwerk mit einem generischen Aufbau des Safety Management Systems vorhanden, das von jeder Organisation und für jedes Projekt angewendet und individuell erweitert werden kann. Diese Herangehensweise wird in Bild 1 veranschaulicht [9].

Um eine systematische und durchsichtige Struktur zu erhalten, werden das organisatorische, regulatorische, projekt- und produktspezifische Safety Management mit einbezogen. Anschließend werden die Gefährdungen bestimmt, um das individuelle Risiko-Management zu gestalten. Auf Basis der konkreten Gefährdungen lässt sich ein spezifisches SMS-Konzept zur Erreichung der Ziele definieren, bevor mit der Entwicklung und Bereitstellung begonnen wird.

Einige methodische Vorgehensweisen des Safety Management Systems sind bereits in den Unternehmen der Automobilindustrie etabliert und lassen sich somit einfach in die neue SMS-Struktur einbinden. Die zuvor erwähnten vier Komponenten können in organisatorisch und sicherheitsrelevant untergliedert werden. Somit beziehen sich die Safety Policy and Objectives, sowie die Safety Promotion auf die organisatorischen Strukturen und Bereitstellungen in einem Unternehmen. Das Risikomanagement und die Sicherheitsgarantie umfassen ständige Bearbeitung der Ereignisse, kontinuierliche Verbesserungen und methodische Arbeitsweisen. Bild 2 gibt eine Anregung, welche bekannten Hilfsmittel und Techniken angewandt werden können, um die Elemente der SMS-Komponenten umzusetzen.

Die organisatorischen Komponenten hingegen stellen sicher, dass die Inhalte systematisch, strukturiert und transparent umgesetzt und dokumentiert werden. Die Implementierung neuer Sicherheitsziele und die Annahme anderer Rollen, Positionen, Verantwortlichkeiten und Kommunikationswege kann in einem Unternehmen eine größere Herausforderung darstellen. Dennoch ist es von großem Interesse, ein Safety Management System in der Automobilindustrie, insbesondere für automatisierte Fahrzeuge zu etablieren, weil der Schutz aller Verkehrsteilnehmer als größtes Sicherheitsziel angesehen wird. Das ist auch der ursprüngliche Grund für die Entwicklung von automatisierten Fahrzeugen gewesen. Laut des statistischen Bundesamtes werden rund 98 Prozent der Unfälle mindestens teilweise von Menschen verursacht [10].

Durch automatisierte oder zukünftig auch autonome Fahrzeuge sollen die Verkehrsunfälle auf Basis von menschlichem Versagen ausgeschlossen werden. (eck)

[1] National Transportation Safety Board, “Collision between Vehicle Controlled by Developmental Automated Driving System and Pedestrian,” Washington D.C., National Transportation Safety Board Public Meeting of November 19, 2019.

[2] CASA, “Australian Goverment Civil Aviation Safety Authority,”: <a href="http://www.casa.gov.au/safety-management/safety">www.casa.gov.au/safety-management/safety</a> management-systems/what-safety-management-and-safety-management-systems, Last modified 26th March 2020

[3]  International Civil Aviation Organization, “Safety Management Manual (SMM),” ICAO publication, 2012.

[4]  D. A. Ludwig, C. R. Andrews, N. R.-t. Veen and C. Laqui, “ACRP Report 1 Safety Management System for Airports,” Washington D.C., Transportation Research Board, 2007.

[5]  IEC 61508, “Functional safety of electrical/electronic/programmable electronic safety-related systems – Part 1: General requirements,” iso-org, 2010.

[6]  ISO 26262–1, “Road vehicles — Functional safety: Concept Phase,” iso-org, 2018.

[7]  ISO/PAS 21448:2019, “Road vehicles — Safety of the intended functionality,” iso-org, 2019.

[8]  R. Yeun, P. Bates and P. Murray, “Aviation safety management systems,” in World Review of Intermodal Transportation Research, South East Queensland, Griffith University, Vol. 5, pp. 6, 2014.

[9]  M. Khatun, F. Wagner, R. Jung and M. Glaß, “An Approach of a Safety Management System for Highly Automated Driving System,” Upcoming conference proceedings-5th International Conference on System Reliability and Safety (ICSRS), Manuscript Accepted September 2021.

[10] Statistisches Bundesamt (DESTATIS). Fachserie 8, Reihe 7, Verkehr, Verkehrsunfälle 2017. Germany, 2018.

Florence Wagner, Safety Management und Funktionale Sicherheit, IFM – Institut für Fahrerassistenz und vernetzte Mobilität an der Hochschule Kempten. Unterstützt durch Prof. Dr. Rolf Jung und Marzana Khatun, Institut für Fahrerassistenz und vernetzte Mobiliät an der Hochschule Kempten.

Tabelle 1: SMS-Komponenten und -Elemente für automatisierte Fahrzeuge

Bild 1: Systematische Herangehensweise für ein Safety Management System

Bild 2: Detaillierte SMS-Komponenten, -Elemente und -Methoden 

 Florence Wagner, Safety Management und Funktionale Sicherheit, IFM – Institut für Fahrerassistenz und vernetzte Mobilität an der Hochschule Kempten. © Hochschule Kempten

Hochschule Kempten

Harmonisierung von Cybersecurity mit Safety and System Engineering

V2X-Kommunikation ermöglicht autonomes Fahren, mehr Sicherheit im Straßenverkehr, Energieeinsparungen und eine angenehme User Experience.

V2X-Kommunikation ermöglicht autonomes Fahren, mehr Sicherheit im Straßenverkehr, Energieeinsparungen und eine angenehme User Experience. Sie bringt aber auch neue Herausforderungen und Bedrohungen für die persönliche Sicherheit und den Schutz der Privatsphäre mit sich.

Die UNECE WP.29-Verordnung R155 für Cybersecurity-Managementsysteme (CSMS) ist in der Europäischen Union verpflichtend. R155 empfiehlt, die Anforderungen an das CSMS anhand von Normen wie der kürzlich veröffentlichten ISO/SAE 21434 umzusetzen. Es gibt weitere verbindliche oder empfohlene Normen und bewährte Verfahren zur Gewährleistung der Cybersecurity in der Automobilindustrie, beispielsweise ASPICE.

Ein systematischer Prozess und Methoden für die Entwicklung einer Automobilplattform und von Steuergeräten tragen dazu bei, die gesetzlichen Anforderungen zu erfüllen, die verschiedenen Sicherheitsstandards im Automobilbereich einzuhalten und die angestrebten Sicherheitsstufen für die Cybersecurity zu erreichen.

Dabei wird dem klassischen V-Engineering-Modell gefolgt und der ASPICE-Security-Engineering-Prozess und -Gruppen integriert. Für den Nachweis und die Bewertung der kritischen Phasen des CSMS werden Arbeitsergebnisse gemäß ISO/SAE 21434 erstellt. Eine Reihe von Cybersecurity-Aktivitäten, die über die Serienproduktion hinausgehen, werden durchgeführt, um neu entdeckte Schwachstellen zu erkennen und zu beheben. Als Teil des Vorgehensmodells wird die Integration des Security-Prozesses in den Safety-Prozess skizziert, um die Wahrscheinlichkeit von fehlenden Themen zu Beginn der Entwicklung zu reduzieren.

Die Durchführung einer Bedrohungs- und Risikoanalyse (Threat Analysis and Risk Analysis, TARA) ist ein iterativer Prozess, und sollte erst beendet werden, wenn die Anlagen ausreichend gegen Bedrohungen und gegen elektrische oder elektronische Komponenten geschützt sind. Mit dem Prozessmodell kann die iterative TARA nahtlos mit anderen Prozessmodellen integriert werden.

Verschiedene Themen wie autonomes Fahren, V2X-Konnektivität, Elektrifizierung und Shared Mobility wirken sich auf die Fahrzeugsicherheit aus. UNECE-Bestimmungen, Standards wie ISO/SAE 21434, ASPICE und andere bestehende Standards für die Cybersicherheit im Automobilbereich regulieren und leiten die Entwicklung und Sicherung von Fahrzeugen.

Die gesamte Wertschöpfungskette, einschließlich der Automobilhersteller (OEMs) und der -Zulieferer auf allen Ebenen, muss die Vorschriften der UNECE R155 und R156 einhalten. OEMs sind juristische Personen, die sich für CSMS- und SUMS-Audits registrieren lassen müssen. OEMs müssen sicherstellen, dass ihre Partner in der Wertschöpfungskette Cybersicherheitspraktiken befolgen und umsetzen.

Trotzdem wird dringend empfohlen, ISO/SAE 21434 und ISO 27001 für Cybersicherheit und ISO/CD 24089 für Software-Update-Engineering zu befolgen. Auf welche Weise können Cybersecurity-Engineering-Aktivitäten in ASPICE-basierte Entwicklungszyklen integriert werden? In den folgenden Abschnitten wird ein ganzheitlicher Ansatz für die Cybersecurity in der Automobilindustrie skizziert.

 Im Folgenden wird ein integriertes Prozessübersichtsdiagramm für die Entwicklung eines sicheren Kfz-Steuergeräts dargestellt. Die Aufnahme von Cybersicherheitsaktivitäten für ein Projekt erfordert ein etabliertes Cybersecurity-Managementsystem (CSMS) gemäß ISO/SAE 21434, Absatz 05, und ein Software-Update-Managementsystem (SUMS) gemäß ISO/CD 24089. Das CSMS muss Cybersecurity-Richtlinien, Regeln, Kompetenzmanagement für Ressourcen, kontinuierliches Management, Toolmanagement und Prozesse definieren. Das SUMS muss auch den notwendigen Prozess spezifizieren, um Rückverfolgbarkeit, Konsistenz, einen eindeutigen Identifikator, Interdependenz und Kompatibilität während des Software-Aktualisierungsprozesses sicherzustellen (Bild 1).

Für die Entwicklung und Produktion von Automotive-Steuergeräten müssen eine Hochsicherheitseinrichtung zum Schutz sensibler Daten sowie eine Infrastruktur und Verfahren eingerichtet werden. Das lässt sich als Teil eines CSMS auf Organisationsebene handhaben.

Die nachfolgenden Abschnitte behandeln projektspezifische Cybersecurity-Aktivitäten, die parallel zu anderen Produktentwicklungsaktivitäten durchgeführt werden müssen, um die gesetzlichen Anforderungen zu erfüllen, die Industriestandards für die Sicherheit in der Automobilindustrie einzuhalten und das angestrebte Sicherheitsniveau für die Cybersecurity zu erreichen.

Der projektabhängige Plan für Cybersecurity-Aktivitäten und die Verantwortlichkeiten müssen gemäß ISO/SAE 21434, Abschnitt 06, festgelegt werden. Die Kontrolle und der Plan müssen sicherstellen, dass der Lieferant alle Vorschriften und Normen zur verteilten Entwicklung einhält. Innerhalb des projektspezifischen CSMS müssen Cybersecurity-Fälle eröffnet werden, um die Arbeitsergebnisse zu verfolgen, zu aktualisieren, während des Projekts zu überprüfen und mit einem Bewertungsbericht abzuschließen, bevor die Produktion freigegeben wird. Der in ASPICE definierte Prozess des Cybersecurity-Risikomanagements kann als Teil des CSMS betrachtet werden. Das CSMS muss Aktivitäten im Zusammenhang mit der Produktions- und Betriebssicherheit begrenzen. Für Software-Updates muss SUMS befolgt werden.

Die Entwicklung von Cybersecurity beginnt mit der Konzeptphase, in der die Sicherheitsanforderungen (Bild 2) ermittelt werden. Die Aktivitäten müssen gemäß ISO/SAE 21434, Abschnitt 09, durchgeführt werden und sind dem in ASPICE definierten SEC.1-Prozess ähnlich. In der Konzeptphase wird die Bedrohungsanalyse für ein Element, ein Bauteil oder ein Set durchgeführt, das eine Funktion auf Fahrzeugebene implementiert. Er lässt sich zusammen mit dem SYS.1-Prozess ausführen. Danach können die Prozesse SYS.2 und SYS.3 folgen. Der ASPICE-SYS.3-Prozess kann zum Einsatz kommen, um die Architektur für Cybersecurity-Systemelemente auf Grundlage der Systemanforderungen zu bestimmen.

Die Risikobewertung für Cybersecurity (TARA) lässt sich mit verschiedenen Methoden durchführen. Ein EVITA- oder STRIDE-Modell (E-Safety Vehicle Intrusion Protected Applications) kann zur Bewertung der Sicherheit in der Konzeptphase zum Einsatz kommen. Die Modellierung und Bewertung kann mit dem Microsoft Thread Modeling Tool mit einer auf die Automobilindustrie zugeschnittenen Vorlage durchgeführt werden.