<ul><li>ZF – Sanfte Fahrt dank vorausschauendem Fahrwerk (S. 10)</li><li>Infineon – Sicherheit entscheidet sich im Gateway (S. 18)</li><li>Softing – Diagnose und Security: Schöne neue Welt (S. 60)</li></ul>

Ein Qualitätsmerkmal, das entscheidend für die Sicherheit steht, ist die durchschnittliche Anzahl von Fehlern pro 1.000 Lines of Code: Je mehr Fehler Software enthält, desto größer ist auch die Anzahl potenzieller Schwachstellen

Ein Qualitätsmerkmal, das entscheidend für die Sicherheit steht, ist die durchschnittliche Anzahl von Fehlern pro 1.000 Lines of Code: Je mehr Fehler Software enthält, desto größer ist auch die Anzahl potenzieller Schwachstellen. Angesichts von mehr als 100 Millionen Zeilen Code in modernen Fahrzeugen erscheint fehlerfreie Software weder technisch noch wirtschaftlich darstellbar. In Verbindung mit der Vielzahl unterschiedlicher Netzwerkschnittstellen eröffnet sich dadurch eine breite Angriffsfläche. Doch wo stecken die Risiken und welche Schwächen bieten Hackern Angriffspunkte und wie kann man sich davor schützen?

AUTOSAR stellt zwar heute bereits grundlegende IT-Sicherheitsfunktionen für die standardisierte Software-Architektur bereit. Dabei zielt AUTOSAR Classic auf die sichere CAN-Kommunikation, während AUTOSAR Adaptive die Absicherung von Ethernet-Kommunikation und Domänencontrollern geprägten Bordnetzarchitekturen in den Blick nimmt. Klar ist aber heute schon: Die Angreifer werden fortlaufend ihre Methoden perfektionieren, sodass Angriffe auch während der Betriebsphase des Fahrzeugs zuverlässig erkannt werden müssen. Und hier reichen die in AUTOSAR enthaltenen Security-Bausteine als solche zur Absicherung der ECUs und ihrer Applikationen nicht aus! Im Fachbeitrag ab Seite 24 gehen die Autoren von ESCRYPT auf diese Problematik ein und skizzieren konkrete Lösungsvorschläge.

Erschwerend kommt bei der Entwicklung solcher Architekturen hinzu, dass Safety und Security sogar gegeneinander arbeiten können, wie die exida-Autoren in ihrem Beitrag auf Seite 32 erläutern: Funktionale Sicherheit kämpft gegen Fehler, die aus der Natur der Technik resultieren. Cybersecurity hingegen kämpft gegen die böswillige menschliche Intelligenz, und der Gegner wird von Tag zu Tag schlauer und mächtiger. Ein „secure“ Produkt muss lebenslang aktualisiert werden. Ein Produkt, dessen „Safety“ einmal nachgewiesen wurde, möchte man möglichst nicht mehr ändern: Security erfordert Patches, Safety vermeidet Patches. Und jeder „Patch“ schließt zwar eine Security-Lücke, öffnet aber eventuell ein neues Safety-Problem.

Während Funktionale Sicherheit im Prinzip bekannt und seit 2011 etabliert ist, lernt die Automotive-Community jetzt erst, was Cybersecurity bedeutet. Die Veröffentlichung der ISO/SAE 21434 ist erst für 2020 geplant. Es ist also dringend notwendig den Erkenntnisweg anderer Security-orientierten Branchen im Automotive-Umfeld beschleunigt zu durchlaufen. Das „IT-Sprichwort“: „Man kann nicht schützen, was man nicht sehen kann“, gilt auch für die Fahrzeugsicherheit. Und die Sichtbarkeit beginnt dort, wo OEMs noch ihren „blinden Fleck“ haben: In den vielen Millionen Zeilen Code.

Editorial Oertel

Oertel, Klaus

ZF hat ein Fahrwerkkonzept entwickelt, das alle Längs-, Quer- und Vertikalbewegungen des Fahrzeugs vollständig kontrollieren kann. Die Schaltzentrale bildet das Steuerungssystem cubiX, wo ein Regelalgorithmus die aktiven und semiaktiven Aktuatoren vernetzt und koordiniert. Noch ein Stück weiter geht ein neuer KI- Algorithmus, der, basierend auf Fahrdynamikdaten und physiologische Marker der Reisekrankheit, eine präventive Fahrweise für autonome Fahrzeuge erlernt.

ZF hat ein Fahrwerkkonzept entwickelt, das alle Längs-, Quer- und Vertikalbewegungen des Fahrzeugs vollständig kontrollieren kann. Die Schaltzentrale bildet das Steuerungssystem cubiX.

Im Auto konzentriert arbeiten, lesen oder einen Film schauen – das ist technisch zwar längst möglich, für viele Menschen aber dennoch undenkbar. Denn Aufbaubewegungen etwa infolge von Schlaglöchern, Bodenwellen oder Kurven beeinträchtigen den Fahrkomfort. Wenn die Insassen nicht auf die Straßen- und Verkehrsbedingungen achten, stören starke Fahrwerkbewegungen besonders. Damit automatisierte Fahrzeuge tatsächlich als rollende Wohnzimmer oder Büros fungieren, hat ZF das Fahrwerksystem „Flying Carpet 2.0“ entwickelt, das Kurven, Bodenwellen oder Schlaglöcher vorausschauend ausgleicht. „Bei der Entwicklung hin zum vollautomatisierten und Autonomen Fahren kommt dem Fahrwerk eine Schlüsselrolle zu“, erklärte Dr. Christoph Elbers, Vice President Car Chassis Technology Development anlässlich eines Tech-Day bei ZF.

Technische Grundlage dafür ist die Kombination verschiedener aktiver und semi-aktiver Systeme, die störende Karosseriebewegungen vorausschauend ausgleichen. Herzstück ist dabei das aktive Dämpfungssystem sMOTION, das mit vier Aktuatoren das Ein- und Ausfedern radindividuell jeder Fahrsituation und Straßenbeschaffenheit anpasst. Diese Aktuatoren verfügen über eine kompakte, außenliegende Elektromotor-Pumpen-Einheit mit integrierter Elektronik, die als bidirektionaler Steller arbeitet. So können sie jedes Rad einzeln und aktiv sowohl nach oben ziehen als auch nach unten drücken. In einer Kurve beispielsweise lassen sich die beiden inneren Räder einziehen und die äußeren ausfahren, sodass der Pkw nahezu waagrecht bleibt. Auf die gleiche Weise wirkt das System Nick-, Wank- und Hubbewegungen entgegen.

Ein weiterer Baustein des Fahrwerkkonzepts ist das modulare Hinterachssystem mSTARS (modular Semi-Trailing Arm Rear Suspension), das Anbindungsmöglichkeiten an elektrische Achsantriebe, Hybrid- und Verbrennermotoren bietet. Das ZF-Versuchsfahrzeug integriert in mSTARS die aktive Hinterachslenkung AKC (Active Kinematics Control) für mehr Sicherheit, Dynamik und Wendigkeit und erhöhte Richtungsstabilität.

Die Schaltzentrale dieser Fahrwerktechnik bildet das Steuerungssystem cubiX. Das skalierbare System ist modular ausgelegt und ermöglicht es die Steuerung der Komponenten per Algorithmus aufeinander abzustimmen und individuell an die Anforderungen jedes Automobilherstellers anzupassen. Der Regelalgorithmus kann sowohl auf einem zentralen Steuergerät installiert werden als auch dezentral auf den einzelnen Systemdomains.

Die Daten erhält die Steuerung erstens von einem Sensorset an jedem Rad. Dieses besteht aus je einem Beschleunigungssensor an der Achse und oberhalb des Aktuators sowie aus einem Höhenstandsensor. Im Verbund mit Kamerasystemen kann sich die Aktuatorik auf die bevorstehenden Bewegungen vorbereiten – und beim Verlassen von Ortschaften sogar je nach Präferenz des Fahrers automatisch eine sportliche oder komfortable Fahreinstellung wählen. Der ZF-Regelalgorithmus empfängt dabei die Sensor- und Statussignale der einzelnen Komponenten, gleicht sie miteinander ab und entwickelt daraus ineinandergreifende Handlungsanweisungen. Die größte Herausforderung war für die Entwickler dabei die „Übersetzung“ der Signale, die von den Einzelkomponenten ausgehen. Dementsprechend aufwendig war die Abstimmung der Schnittstellen. Die Kommunikation zwischen den Einzelkomponenten erfolgt im vorgestellten Innovationsfahrzeug über eine Kombination aus dem bestehenden CAN-Bus-System, Private-CAN zwischen den neu verbauten Komponenten und Ethernet-CAN-Verbindungen.

Der Verbund all dieser integralen Fahrwerkkomponenten mit dem zentralen Steueralgorithmus ermöglicht eine optimale Reaktion auf nahezu jede Fahrsituation durchzuführen. Während ZF jede einzelne Komponente liefern und zu einem Gesamtsystem vernetzen kann, wäre das Fahrwerkkonzept aber auch mit Bauteilen anderer Zulieferer kompatibel; dazu müsste der steuernde Regelalgorithmus jedoch individuell programmiert werden.

ZF-Ingenieure haben für das Innovationsfahrzeug sieben beispielhafte Funktionen entworfen, welche die Möglichkeiten des Fahrwerkkonzepts illustrieren:

<ul><li>Track Preview: Per Frontkamera erkennt das System Ortsschilder und andere Verkehrszeichen. Beim Einfahren in die Stadt etwa wird die Lenkempfindlichkeit des Fahrzeugs angepasst.</li><li>Corner Feel Shaping: Eine Funktion zur Steigerung des Insassenkomforts, bei der längs-, quer- und vertikaldynamische Komponenten beim Einfahren in die Kurve den Wankwinkel sowie Rollbewegungen der Karosserie vermindern.</li><li>Safe Lane Changing: Beim Spurwechsel auf glatten oder nassen Fahrbahnen verhindern Hinterachslenkung und Dämpfsystem im Zusammenspiel mit dem aktiven Brake-by-Wire-System Integrated Brake Control (IBC) potenziell gefährliche Gier- und Wankbewegungen, durch die das Fahrzeug ins Schlingern geraten könnte.</li><li>Easy Ticketing: Bei geringen Geschwindigkeiten unter 5 km/h verstärkt die Hinterachslenkung die Lenkeinschläge des Fahrers. Zusätzlich erkennt das Fahrzeug per Kamera oder per GPS, wenn es sich an einer Mautstation oder am Parkscheinautomaten einer Tiefgarage bzw. Parkhauses befindet. Dabei hebt die sMOTION-Dämpfung das Fahrzeug auf die optimale Höhe, was das Ziehen eines Tickets für den Fahrer erleichtert.</li><li>Pitch/Brake Compensation: Für mehr Insassenkomfort arbeiten Brems- und Dämpfsystem zusammen, um die Nickbewegung der Karosserie beim Bremsen auszugleichen.</li><li>Flying Carpet 2.0: Diese Funktion erkennt durch Frontkamera, Weg- und Beschleunigungssensoren Fahrbahnunebenheiten, worauf das Fahrwerk den Aufbaubewegungen der Karosserie aktive Kräfte entgegenstellt.</li><li>Easy Coupling: Die Rückwärtskamera erkennt, wenn das Fahrzeug an einen Anhänger manövrieren will. Die Dämpfung senkt bzw. hebt das Fahrzeug beim Annähern an die Anhängerkupplung.</li></ul>

Davon unabhängig lässt sich das vorausschauende Fahrwerkkonzept auf zwei Wegen erweitern: Fahrzeug-fokussiert mithilfe KI-fähiger Steuergeräte und Insassen-fokussiert, unter anderem durch den Einsatz von Innenraumsensorik.

Die erste Variante ließe sich beispielsweise durch das KI-Steuergerät ZF ProAI RoboThink ermöglichen. Deren Leistung (600 Tera-OPS) erlaubt es dem Regelalgorithmus, Daten der Umfeldsensorik, cloudbasierten Input und Car-to-X-Kommunikation in Echtzeit zu verarbeiten. Damit würde das vorausschauende Fahrwerkkonzept auch autonome Fahrzeuge ab Level 4 im öffentlichen Verkehr sicher betreiben. Die notwendigen ADAS-Schnittstellen sind bereits im Versuchsträger verfügbar.

Für die zweite Herangehensweise antizipiert ZF neue Formen der Mobilität im Zeitalter des automatisierten und Autonomen Fahrens. Sitzt der Mensch am Lenkrad, sind spürbare Fahrwerkbewegungen ein wichtiges Feedback für das Steuern des Fahrzeugs. Liegt die Aufmerksamkeit hingegen nicht auf der Strecke, beeinträchtigen Aufbaubewegungen der Karosserie den Fahrkomfort massiv und können zu Überlkeit und Reisekrankheit führen.

Für viele Menschen sind lange Autofahrten heute noch gleichbedeutend mit Schwindel, Kopfschmerzen und Übelkeit – kurz gesagt, mit Reisekrankheit. ZF arbeitet nun gemeinsam mit Neurotechnologen an Möglichkeiten, die Symptome für Reisekrankheit früh zu erkennen und daraus intelligente Fahrfunktionen abzuleiten, die dieser entgegenwirken. Die wissenschaftliche Basis für dieses Konzept liefern gemeinsam mit der Systems Neuroscience & Neurotechnology Unit (SNNU) an der Universität des Saarlandes und der htw saar durchgeführte Probandenstudien.

Manövriert ein Fahrzeug über längere Strecken eigenständig, leiden nach einer Untersuchung neun von zehn Passagieren an Schwindel, Kopfschmerzen und Übelkeit. Verursacht wird diese Reise- oder Bewegungskrankheit, fachsprachlich Kinetose, durch eine Diskrepanz in der Wahrnehmung: Das im Innenohr liegende Gleichgewichtsorgan fühlt eine Bewegung, die von anderen Sinnesorganen wie den Augen nicht bestätigt wird – das passiert insbesondere, wenn der Passagier konzentriert auf einen Bildschirm oder ein Buch blickt. Der menschliche Körper reagiert in dieser Situation ähnlich wie auf eine Vergiftung.

Soll das Fahrwerk diesen Symptomen entgegenwirken, müssen entsprechende Funktionsparameter für die Fahrdynamik auf einer wissenschaftlichen Basis fußen. In mehreren Probandenstudien analysierten die Forscher im realen Straßenverkehr, welche physiologischen Marker die höchste Korrelation mit dem subjektiven Reisekrankheit-Empfinden des Menschen aufweisen und welcher Zusammenhang zur Fahrdynamik des Fahrzeugs besteht.

„Unser Motion Sickness Research Vehicle erlaubt uns, mithilfe eines Hochleistungsrechners die Vielzahl an physiologischen Messdaten, Kameradaten sowie auch Fahrdynamik-Messwerte aufzuzeichnen (Bild 1). Gleichzeitig dient das Fahrzeug als Plattform zur Entwicklung und Validierung der Algorithmen“, erklärte Florian Dauth, in der ZF-Vorentwicklung verantwortlich für Aktivitäten im Bereich Human Centered Vehicle Motion Control. Ein Sensorset im Innenraum des Fahrzeugs sowie Wearables, welche die Probanden zur nicht-invasiven Messung am Körper tragen, sind aktuell Bestandteil der Forschung (Bild 2). Für einen möglichen Serieneinsatz werden Sensorsysteme entwickelt, die eine kontaktfreie Erfassung der relevanten, psychophysiologischen Marker erlauben.

Jeder Mensch reagiert unterschiedlich auf Fahrzeugbewegungen und besitzt ein individuelles Empfinden für Fahrkomfort. Diese Tatsache bildet ZF in einem Algorithmus ab, der basierend auf KI-Methoden die Körperreaktionen des Passagiers einlernt und somit ein personalisiertes Profil erstellt. Da somit für jeden Mitfahrer individuelle Daten vorliegen, wären automatisierte Fahrzeuge sogar in der Lage, den bevorzugten Fahrstil jedes Passagiers umzusetzen.

Mit seinem Innovationsfahrzeug zeigt ZF eine funktionale Vernetzung des Fahrwerks. Ein neuer, eigens entwickelter Regelalgorithmus ermöglicht es, bislang singulär agierende Sicherheits-, Komfort- und Dynamikfunktionen intelligent und optimal aufeinander abzustimmen. Dank verfügbarer Schnittstellen ist eine Erweiterung um Umfeldsensorik für umfassende automatisierte bzw. autonome Fahrfunktionen möglich.

Mit dem Konzept des „Flying Carpet 2.0“ von ZF lassen sich alle Längs-, Quer- und Vertikalbewegungen des Fahrzeugs vollständig kontrollieren.

16:9

Bild 1: ZF und Neurotechnologen entwickeln mit künstlicher Intelligenz präventive Fahrstile, die der Reisekrankheit entgegenwirken können.

Bild 2: Bei mehr als zehntausend Fahrkilometern sammelte das Forschungsteam über fünfzigtausend Gigabyte an physiologischen Markern des zentralen und autonomen Nervensystems als Thermografie-, Bild- und Fahrdynamikdaten.

Hauptartikel

Klaus Oertel, Chefredakteur der Hanser automotive, nach Unterlagen der ZF Friedrichshafen AG

ADAS-SoC-Prozessor  für das A- und B-Segment

Der SoC-Prozessor TDA3x von Texas Instruments baut auf der SoC-Familie TDA auf, die letztes Jahr vorgestellt wurde, und ermöglicht aufgrund neuer  Features die Entwicklung von NCAP-konformen ADAS-Anwendungen für Unter- und Mittelklassefahrzeuge.

Der SoC-Prozessor TDA3x ebnet den Weg für kostensensible ADAS-Algorithmen wie etwa autonome Notbremsungen, Spurhalteassistent, Abstandsregeltempomat, Verkehrszeichenerkennung, Fußgänger- und Objekterkennung usw. Die Spanne reicht hier von der Frontkamera über die Parkassistenz, Rundumsicht und Radar bis zu intelligenten Heckkameras (Bild 1).

Die Unterstützung des TDA3x für die Peripheriefunktion CSI2 ermöglicht den Anschluss der neuesten Bildsensor-Generation für den Automotive-Bereich. Der parallele Videoeingang ist zusätzlich noch vorhanden, damit SoC auch an ältere Bildsensoren angeschlossen werden kann. Im Interesse der Datenintegrität unterstützt das External Memory Interface (EMIF) optional die SECDED-Funktion (Single Error Correct Double Error Detect). Ist dieses Feature aktiviert, werden die ECC-Bits für alle in den per ECC geschützten Adressbereich fallenden Zugriffe berechnet und in einem separaten Speicherbaustein gespeichert (siehe Bild 2).

Zwei DSP-Cores vom Typ TMS320C66x und das Vision AccelerationPac von TI auf Basis der Embedded Vision Engine (EVE) stellen die Rechenleistung für Frontkamera-Anwendungen zur Verfügung und ermöglichen die gleichzeitige Ausführung mehrerer Frontkamera-Funktionen wie zum Beispiel intelligente Scheinwerfer, Verkehrszeichenerkennung, Spurhalte-Assistent, Objekterkennung usw.

Das SoC unterstützt eine Instanz des früheren parallelen Videoeingangs des SoC-Prozessors TDA2x. Der Video Input Port (VIP) ermöglicht den Anschluss von vier 8-bit-Bildsensoren über FPD Link Serializer/Deserializer von TI, was stromverbrauchs- und größenoptimierte, einfache Surround-View-Anwendungen zulässt. Der ISP-Hardwarebeschleuniger (Image Signal Processor) reduziert die Stromaufnahme des TDA3x-Prozessors, indem diese Bildverarbeitungs-Aufgaben aus dem DSP-Core und dem Vision AccelerationPac (EVE) ausgelagert werden können. Das Display-Subsystem (DSS) des TDA3x-SoC kann den DSP und die EVE außerdem von verschiedenen Surround-View-spezifischen Pixelverarbeitungs-Aufgaben (z. B. Skalierung, Farbraum-Umwandlung, Filterung, Mischung, Color-Keying-Einblendung von Grafiken usw.) entlasten.

Die heute üblichen Rückfahrkamera-Systeme beschränken sich nicht auf die Übertragung eines einfachen Videosignals von der Heckkamera an das Display im Cockpit. Durch die Fusion mit Radar und Ultraschall für sicheres Rückwärtsfahren, sind die Analyse- und Verarbeitungsanforderungen anspruchsvoller als je zuvor. Der SoC-Prozessor TDA3x bewältigt diese Verarbeitungsanforderungen z. B. für Fußgängererkennung und dynamische Fahrspurmarkierungen mit hoher Effizienz. Denn infolge der von OEMs geforderten kleinen Systemabmessungen und des Fehlens jeglicher Art von aktiver Kühlung kommt es ferner darauf an, die Verlustleistung eines Heckkamera-SoC zu minimieren. Die im TDA3x enthaltenen Hardwarebeschleuniger wie der ISP und der DSS machen genau dies möglich, indem sie dem DSP-Core und der EVE die Bildverarbeitungsaufgaben abnehmen.

C66x-DSP und EVE können ihre Stärken bei den Verarbeitungsaufgaben für Radarsysteme ausspielen. Der TDA3x eignet sich für Radarsysteme für mittlere bis große Distanzen. Das Blockschaltbild in Bild 3 zeigt ein auf dem TDA3x-SoC basierendes Radarsystem für große Entfernungen mit vier Sendern und acht Empfängern. Die Ausgänge der beiden AD-Wandler sind über zwei parallele Videoeingänge mit dem TDA3x-SoC verbunden. Das auf früherer Technik basierende VIP ermöglicht die Anbindung an zwei 13-bit-Ausgänge zweier AD-Wandler.

Die TDAx-Familie und insbesondere der TDA3x ermöglichen Fusionslösungen für verschiedene Sensoren wie etwa Kamera und Radar. Der C66x-DSP und die EVE bieten Verarbeitungsfunktionen für Bild- und Radarsensoren, wodurch sich die TDAx-Architektur für Fusionsanwendungen eignet.

Der TDA3x beruht auf der gleichen Architektur wie frühere SoCs der TDAx-Plattform, sodass Hersteller ihre Produktinvestitionen skalieren und ein vielfältiges Produktportfolio mit kompatibler Hard- und Software anbieten können. Grundlage ist eine heterogene, skalierbare Architektur, die zwei TMS320C66x DSP-Cores für Fest- und Gleitkomma-Arithmetik, ein programmierbares Vision AccelerationPac mit EVE, zwei ARM Cortex-M4-Cores sowie einen Image Signal Processor (ISP) und eine Vielzahl von Peripheriefunktionen umfasst.

Die zusätzliche Peripherie-Ausstattung gegenüber dem TDA2x-SoC sind ein 10-bit-AD-Wandler, ein Video-DA-Wandler (DAC) in Standard Definition und vier Videoeingänge (CSI2 oder HiSPI).

ISP-Integration verringert die Systemkosten

Durch die Integration eines ISP mit Unterstützung für Raw-/Bayer-Sensoren bringt es der TDA3x-Prozessor auf eine verbesserte Bildqualität, ohne dass sich die Abmessungen, die Kosten oder die Komplexität der Lösung erhöhen. Varianten des TDA3x-SoC besitzen zudem einen ISP mit Rauschfiltern, Farbfilter-Array, Video Noise Temporal Filtering (VNTF), Belichtungs- und Weißabgleich-Regelung sowie optionale Unterstützung für einen weiten Dynamikbereich. Der ISP unterstützt ferner Kombinationen für Mono, Stereo und bis zu vier Kameraeingänge.

Der TDA3x wurde dafür entwickelt, die einschlägigen Anforderungen der ISO 26262 zu erfüllen. Hierfür kommen verschiedene Diagnosefunktionen der Safety-MCU-Familie Hercules TMS570 von TI zum Einsatz, um das Safety-Konzept der TDA2x-Plattform zu ergänzen. Die Kombination aus Hardware, Software, Tools und Support hilft den Anwendern bei der Entwicklung von Systemen, die anspruchsvolle Functional-Safety-Anforderungen zu erfüllen

Unterstützt wird die TDA-Familie durch das TI Vision SDK und lizenzfreie Softwarebibliotheken. Damit lassen sich Produkte vom Kleinwagen bis zum Luxusmodell auf der Basis einer einheitlichen Plattform entwickeln. Das TI Vision SDK beruht auf dem RTOS SYS/BIOS von TI und ist umgehend verfügbar. Ferner ist das Evaluation Module (EVM) verfügbar, das wichtige Peripheriefunktionen wie etwa Ethernet, FPD Link und HDMI enthält.

Mit dem SoC-Prozessor TDA3x von TI ermöglicht die Entwicklung von NCAP-konformen Fahrassistenzsystem für den Einsatz in Klein- und Mittelklasse-Fahrzeugen. Durch die Integration eines Image Signal Processor werden die Schaltungen kleiner und die Stromaufnahme reduziert. Erweiterte Features für Funktionale Sicherheit machen es zudem möglich, höhere ASILs zu erreichen.

<a href="http://www.ti.com/adastda">www.ti.com/adastda</a>

Bild 1: Das TDA3x-SoC ist auf der gleichen Architektur wie die vorigen TDA-SoCs entwickelt, und unterstützt nun auch Heckkamera- und Radar-Anwendungen.

Bild 2: Blockschaltbild eines Frontkamerasystems mit dem SoC-Prozessor TDA3x. 

Bild 3: Radar-Implementierung mit dem TDA3x-SoC. 

Zoran Nikolic ist Lead Engineer, Anshuman Saxena und Gaurav Agarwal sind Marketing Manager bei Texas Instruments.

Heute reden wir noch über erneute Führerscheinprüfungen für Senioren, aber schon morgen werden wir über die Feststellung der Fahrtauglichkeit von gealterter Künstlicher Intelligenz in Fahrzeugen reden müssen!

Sensoren sind die Augen und Ohren autonom fahrender Fahrzeuge. Was passiert also, wenn Sensoren uns im Stich lassen? Der Komplettausfall eines Sensors kann in der Regel gut erkannt werden. Deutlich schwerer ist es zu bemerken, wenn ein Sensor zwar Daten sendet, diese aber fehlerhaft sind, etwa aufgrund von Verschmutzung, Fehlpositionierung oder Fehlern in der Fahrzeugsoftware. Invalide Sensordaten verzerren die Wahrnehmung der KI-Modelle, auf denen Autonomes Fahren basiert. Die Modelle werden kurzsichtig oder schwerhörig, und ihre Entscheidungen werden ungenauer. Daraus resultierende Fehleinschätzungen können gefährliche Fahrmanöver oder sogar Unfälle hervorrufen.

Wird ein Mensch schwerhörig oder kurzsichtig, erkennt er dies selbst oft nicht gleich. Häufig braucht er einen Beifahrer, um ihn auf den Umstand hinzuweisen, dass er im Vergleich viel später abbremst als andere Verkehrsteilnehmer, sich nicht im Verkehrsfluss bewegt oder erst sehr spät auf ein Martinshorn reagiert. Genau wie ein Mensch ist eine KI oft nicht selbst in der Lage zu beurteilen, ob sich ihre Fahrweise mittlerweile signifikant von der Norm unterscheidet. Auch sie braucht einen Beifahrer, der sie darauf hinweist!

Für eine KI kann ein Predictive AI Maintenance (PAM) System die Rolle des Beifahrers übernehmen. Ein PAM-System untersucht und vergleicht kontinuierlich die Fahreigenschaften und Fahrweisen großer Fahrzeugflotten. Dadurch identifiziert es durch mögliche Sensorschwächen gealterte AI und bestellt diese frühzeitig zu einem Wartungstermin ein, bevor ein Unfall geschehen kann. Die Nordsys GmbH baut für ihre Kunden PAM-Systeme auf und entwickelt diese im Rahmen von Forschungsprojekten für die Anwendungsfälle der Zukunft weiter.

PAM-Systeme werten ihre Daten „online“ in Near Real-Time mittels Stream Processing aus. Denn wenn es um die Verkehrssicherheit eines autonomen Fahrzeugs geht, ist jede Sekunde kostbar und „Offline“-Systeme, die Daten zunächst speichern und erst später auswerten, sind dafür nicht schnell genug. Dazu haben PAM-Systeme eine ganze Reihe von Eigenschaften, die viele „Offline“-Systeme nicht mitbringen: Sie werten große Datenmengen zeitnah aus und gehen mit Sendelücken und potenziell unvollständigen Daten um. Sie sind skalierbar, um mit Schwankungen in der Flottengröße, etwa zu Ferienbeginn, umgehen zu können und bieten eine hohe Zuverlässigkeit, um die kontinuierliche Bewertung der Verkehrstüchtigkeit autonomer KI-Systeme zu gewährlisten. Weiterhin bewältigen sie Herausforderungen, die auf Abweichungen von Systemuhren, asynchrone Kommunikation und Sendelücken in ländlichen Gebieten zurückgehen.

Die Zukunft auf unseren Straßen wird Fahrzeugen gehören, die durch komplexere Sensoren und Systeme immer selbstständiger fahren werden. Die Absicherung dieser Fahrzeuge ist eine Herausforderung, die überwunden werden muss, bevor diese Zukunft eintritt. Damit Fahrzeuge morgen autonom fahren können, müssen wir uns heute bereits Gedanken darüber machen, wie wir den Verkehr der Zukunft gestalten und auch kontrollieren wollen. W (oe)

<a href="http://www.nordsys.de">www.nordsys.de</a>

Ein PAM-System untersucht und vergleicht kontinuierlich die Fahreigenschaften und Fahrweisen großer Fahrzeugflotten.

Hauptartiklel

Philipp Wille ist Computer Scientist und Software Developer bei Nordsys.

Mit der Automatisierung des Fahrens, Shared Mobility und der Fahrzeugvernetzung rückt Automotive Cybersecurity stärker in den Fokus. Die Anzahl der externen Schnittstellen im Auto steigt ebenso wie die Komplexität der Fahrzeugelektronik. Eine Schlüsselrolle für Automotive Security nimmt das zentrale Gateway ein.

Mit der Automatisierung des Fahrens, Shared Mobility und der Fahrzeugvernetzung rückt Automotive Cybersecurity immer stärker in den Fokus. Die Anzahl der externen Schnittstellen im Auto steigt ebenso wie die Komplexität der Fahrzeugelektronik insgesamt. Eine Schlüsselrolle für Automotive Security nimmt das zentrale Gateway ein.

Um die Komplexität der E/E-Architektur zu reduzieren und eine weitere Fahrzeugautomatisierung zu ermöglichen, werden Domain-Architekturen eingeführt. Diese bestehen aus wenigen zentralen, dafür hochperformanten Domainrechnern sowie einer größeren Anzahl an spezialisierten ECUs, Sensoren und Aktoren in den einzelnen Netzwerkdomänen [1]. Ein vereinfachtes Beispiel einer solchen Referenz-Architektur ist in Bild 1 dargestellt. Die Ziele solcher Architekturen sind vielfältig: Zentralisierung komplexer Funktionen in leistungsfähigen Domänencontrollern, domänenübergreifendes Kommunikationsrouting, Kosten- und Kabelbaumreduzierung sowie bessere Integration von Funktionen über die Domänengrenzen hinweg. Die Verbindung der verschiedenen Fahrzeugdomänen und die Weiterleitung der entsprechenden Datenströme erfolgt dabei über zentrale Instanzen (zentrales Gateway bzw. Domaincontroller). Diese bieten physische Isolierung und Protokollübersetzung, um Nachrichten zwischen den verschiedenen Funktionsdomänen weiterzuleiten sowie die Schnittstelle für den externen Zugriff auf die nachfolgende Netzwerkebene. Darüber hinaus fungiert das zentrale Gateway vielfach als zentrale Kontroll- und Überwachungsinstanz für drahtlose Software-Updates Over-the-Air (SOTA) und externen Diagnosezugriff auf das Fahrzeugnetzwerk. Demnach ist für diese Komponenten – als zentraler Knotenpunkte in der E/E-Architektur – ein entsprechend erhöhter Schutzbedarf gegeben. Folglich müssen Domaincontroller und das zentrale Gateway eine besonders hohe Resistenz – und daraus resultierend entsprechende Schutzmaßnahmen – gegen unbefugte Zugriffe, Manipulationen und Cyber-Angriffe aufweisen, um die Kommunikation zwischen den ECUs der verschiedenen Fahrzeugdomänen abzusichern.

Handelt es sich bei den Schutzumfängen auf ECU-Ebene im Wesentlichen um Secured Boot, geschützte Buskommunikation, sowie Schutz der Diagnoseschnittstelle vor unbefugter Speichermanipulation, kommen bei den Domaincontrollern und insbesondere dem zentralen Gateway eine Reihe weiterer Schutzmechanismen hinzu. Zu diesen zählt das Management von Software-Updates, die Überprüfung und Filterung des Datenverkehrs (Firewall), Angriffserkennung und Abwehr (IDS/IPS), Schlüssel- und Zertifikatsmanagement, Datenerfassung (Blackbox) sowie die Absicherung kommerzieller Transaktionen – beispielsweise bei Ladesäulen, kostenpflichtigen Funktionserweiterungen oder Carsharing.

Neben reinen Mikrocontroller Lösungen wird aus Performance-Gründen zunehmend auf die Kombination von Mikrocontroller und Applikationsprozessor zurückgegriffen. Dies impliziert – insbesondere bei linux-basierten Systemen – auch den Einsatz von Open Source Software, deren Qualität stark von der Beteiligung am jeweiligen Softwareprojekt abhängt. Ein Qualitätsmerkmal, das entscheidend für die Sicherheit steht, ist die durchschnittliche Anzahl von Bugs/KLOC (Fehler je 1.000 Lines of Code), denn grundsätzlich gilt: Je mehr Fehler Software enthält, desto größer ist auch die Anzahl potenzieller Schwachstellen. Insofern kann diese Kenngröße als Gradmesser für die Sicherheit einer Software angesehen werden. Selbst im Umfeld von Militär, Luft- und Raumfahrt finden sich im Schnitt noch Fehlerraten im einstelligen KLOC-Bereich. Somit steigt die Anzahl von Schwachstellen – unabhängig von open oder closed source (Bild 2).

Dem gegenüber steht die enorme Code-Basis moderner Fahrzeuge von mehr als 100 Millionen Zeilen Code – ein Vielfaches verglichen mit anderen Systemen, etwa aus der Avionik. Angesichts dieser enormen Komplexität erscheint fehlerfreie (und damit Bug-freie) Software weder technisch noch wirtschaftlich vertretbar. In Verbindung mit der Vielzahl unterschiedlicher Netzwerkschnittstellen eröffnet sich dadurch, für Fahrzeuge, eine breite Angriffsfläche. Darüber hinaus spielen Angriffe auf die Hardware eine zunehmend größere Rolle, da der physische Zugriff auf das Fahrzeug – und damit auch die verbaute Hardware – im Gegensatz zu physikalisch abgeschotteten IT-Systemen nicht beschränkt ist. Ein Angreifer, der sich beispielsweise Zugriff auf die Software einer ECU (mittels Hardware- oder Remote-Attacken) verschafft hat, kann darin Schwachstellen finden, welche er im Anschluss für großflächige Remote-Angriffe ausnutzen kann. Besonders kritisch ist dabei der Zugriff auf kryptografische Schlüssel in der ECU, die zur Implementierung von entsprechenden Schutzmaßnahmen dienen – etwa zum Schutz vor unberechtigtem Zugriff auf vertrauliche Daten oder zur Absicherung von Kommunikation nach außen. Diesen Schlüsseln kommt sprichwörtlich eine Schlüsselrolle zu: Zum einen stellen sie ein interessantes Angriffsziel dar, zum anderen kann im Nachhinein nicht mehr zwischen Original und Kopie unterschieden werden, sobald ein Schlüssel unbefugt ausgelesen und dupliziert wurde. Daraus lässt sich ein höherer Schutzbedarf ableiten, der mit rein Software-gestützten Maßnahmen nicht erreicht werden kann. Der Einsatz von Hardware-basierter Sicherheit in Form diskreter Security Controller ergänzt daher bestehende Hardware-Lösungen durch Schutz gegen unbefugtes Auslesen mittels physikalischer Angriffe (von Fehlerinjektion über Seitenkanalangriffe bis hin zu invasiven Angriffen und Reverse Engineering) und ermöglicht somit vertrauenswürdige Software [2]. Dabei ist eine ganzheitliche Betrachtung der Sicherheitsarchitektur essenziell. Dies beinhaltet insbesondere die Umsetzung des sogenannten „Defense-in-Depth“-Ansatzes, also der Implementierung mehrerer, voneinander unabhängiger Verteidigungslinien. Zudem spielen wirtschaftliche Überlegungen eine Rolle, d. h. die Kosten-Nutzen-Relation für einen erfolgreichen Angriff und entsprechende Gegenmaßnahmen. Der erforderliche Schutzbedarf, die zugehörigen Maßnahmen sowie deren Ineinandergreifen werden vom OEM festgelegt. Im Kontext des zentralen Gateways kommt zunehmend die Kombination eines Mikrocontroller mit EVITA HSM und eines ergänzenden diskreten Security Controller zum Einsatz.

Wie dies in Anbetracht neuer Angriffsszenarien und als konsequente Weiterentwicklung von EVITA durch ein verteiltes Sicherheitskonzept basierend auf Applikationsprozessor, TPM 2.0 und EVITA HSM bewerkstelligt werden kann, wird nachfolgend für die in Bild 1 dargestellte Referenzarchitektur am Beispiel SOTA aufgezeigt [3]. Neben einfacher Integration und hoher Wiederverwendbarkeit für eine Vielzahl unterschiedlicher Sicherheitsapplikationen sollen die von EVITA vorgestellten Sicherheitsumfänge im Hinblick auf neue Angriffsszenarien möglichst zielführend und kostengünstig erweitert werden.

Die Hauptkomponenten von Infineon für das zentrale Gateway sind die Mikrocontroller-Familie AURIX 32-bit sowie das OPTIGA Trusted Platform Module (TPM) 2.0 (Bild 3).

Heute sind SOTA-Updates vor allem für Infotainment (IVI) und Telematik-ECUs (TCU) verfügbar während ADAS, Fahrwerk oder Antriebsstrang meist noch über den On-Board-Diagnose (OBD)-Anschluss aktualisiert werden. In den nächsten Jahren werden diese ECUs aber auch durch drahtlose Kommunikation zwischen dem in der Cloud befindlichen Firmware-Server und dem zentralen Gateway, das als OTA-Manager fungiert, aktualisiert. Dieser ist u. a. für die Steuerung und Überwachung der zulässigen Firmware-Version für jede ECU, das Herunterladen der neuesten Firmware von den OEM-OTA-Cloud-Servern, das Entschlüsseln, Authentifizieren und Überprüfen der empfangenen Firmware, das Entpacken und Aufteilen des empfangenen Service-Pakets auf einzelne ECUs, das Einrichten eines sicheren Übertragungskanals zu diesen ECUs, das Aktualisieren und Zurücksetzen von Software Images, sowie die Aufforderung an das IVI, Aktualisierungsdetails für den Fahrer anzuzeigen, verantwortlich.

Neben Sicherheitsaspekten spielt aus Gründen der Fahrzeugverfügbarkeit vor allem Zeit eine wichtige Rolle. Durch den Einsatz eines performanten Automotive Mikrocontrollers, wie AURIX, als OTA-Manager, können die Updates entsprechend effizient und abgesichert durchgeführt werden. Dabei ist sicherzustellen, dass die Firmware der jeweiligen ECUs (inklusive des OTA-Managers) nicht unbefugt verändert wurde und dass sie von einer vertrauenswürdigen Quelle stammt. Die AURIX-Familie bietet alle gängigen Automotive-Schnittstellen (Gbit Ethernet, FlexRay, CAN, CAN-FD, LIN) und kann für Safety-kritische Anwendungen bis ASIL-D eingesetzt werden. Zudem ist ein Hardware Security Module (EVITA Full HSM) integriert. Das HSM im Zusammenspiel mit gespiegelten embedded Flash Banks vereinfacht zudem die Implementierung einer SOTA Lösung (A/B Swap). Der Applikationsprozessor übernimmt in diesem Setup beispielsweise die Angriffserkennung und Abwehr (IDS/IPS) oder das Management des Modems in einer kombinierten Telematik-/Central-Gateway Lösung. Da die Schutzumfänge des Applikationsprozessors begrenzt sind (z. B. fehlendes NVM als Schlüsselspeicher, begrenzter Schutz gegen physikalische Attacken), kommt als Ergänzung ein OPTIGA TPM SLI 9670 zum Einsatz. Dabei handelt es sich um ein gehärtetes TPM für Automotive-Anwendungen, welches aus einem angriffsresistenten Sicherheitschip und einer leistungsstarken Firmware besteht. Mithilfe der Firmware kann eine Reihe von Sicherheitsfunktionen wie Ver- und Entschlüsselung, Signatur und Verifikation sofort genutzt werden. Der SLI 9670 entspricht dem Standard der Trusted Computing Group TPM 2.0, ist sicherheitszertifiziert nach Common Criteria EAL4 und Automotive qualifiziert nach AEC-Q100. Der ebenfalls von Infineon bereitgestellten Open-Source-Software-Stack (TSS Stack) für den Host-Prozessor erleichtert die Integration des TPM, indem er als Middleware die Ausführung der Kommandos und die Verwaltung der Schlüssel für den Host übernimmt. Der TSS Stack lässt sich über APIs auf verschiedenen Ebenen ansprechen und stellt eine standardisierte Schnittstelle und Bibliotheken für gängige Open-Source-Software zur Verfügung. Beispielsweise ist eine Anwendung des SSL/TLS Protokolls mit OpenSSL und durch die vom TPM geschützten Schlüssel und den TSS Stack möglich. Dabei schützt das TPM die Authentifizierungsdaten für die SSL/TLS-Sitzung.

Im vorliegendem Anwendungsszenario (SOTA) wird die SSL-/TLS-Kommunikation mit TPM eingesetzt, um den Datenaustausch zwischen Backend und Fahrzeug abzusichern. Im Rahmen des SSL-/TLS-Handshakes wird geprüft, dass das Software-Update am richtigen Fahrzeug erfolgt. Wurde die SSL-/TLS-Kommunikation erfolgreich aufgebaut, kann das Software Update Image durch den geschützten SSL-/TLS-Kanal an das Fahrzeug übertragen werden. Somit bildet das TPM den zentralen Vertrauensanker des verteilten Sicherheitskonzepts und fungiert als vertrauenswürdiger Endpunkt für die Kommunikation mit dem Fahrzeug. Sobald der OTA-Manager (AURIX) die Firmware heruntergeladen hat, verteilt er sie an die entsprechenden ECUs. Dabei übernimmt er die Protokollübersetzung zwischen der TCP/IP-Welt und den Automotive-Kommunikationsprotokollen. Wenn dies von den zu aktualisierenden ECUs unterstützt wird, kann die Firmware übertragen werden, und die Entschlüsselung, Authentifizierung und Dekompression der Inhalte erfolgt dann in den zu aktualisierenden ECUs. Zusätzlich kann die Kommunikation zwischen OTA-Manager und Ziel-ECU beispielsweise mittels SecOC weiter abgesichert werden. Andernfalls muss der OTA-Manager selbst das Update authentifizieren und entschlüsseln.

Neben SOTA als Anwendungsbeispiel für ein verteiltes Sicherheitskonzept lassen sich noch eine Reihe weiterer möglicher Anwendungsfälle in der beschriebenen Systempartitionierung effizient absichern – beispielsweise Carsharing, Black Box- und OBD-II Zugriffsprotokollierung, zentrale Schlüsselverwaltung, Fahrzeugzugang und Wegfahrsperre, nutzungsbasierte Versicherung sowie kostenpflichtige Funktionserweiterungen. W (oe)

<a href="http://www.infineon.com">www.infineon.com</a>

[1] T. Liebetrau and R. Schulze, “Eine leistungsfähige Entwicklungsplattform für die Einführung neuer Netzwerktechnologien in den Fahrzeug-Architekturen,” ATZ Elektronik, 2019

[2] P. Laackmann and M. Janke, “How secure is your chip?” <a href="http://Security-News.TV">Security-News.TV</a>, 2012.

[3] B. Steurich, K. Scheibert, A. Freiwald, and M. Klimke, “Feasibility Study for a Secure and Seamless Integration of Over the Air Software Update Capability in an Advanced Board Net Architecture.” SAE International , 2016.

Bild 1: Vereinfachtes Beispiel einer Domain-Architektur.

20:7

Bild 2: Anzahl identifizierter Schwachstellen.

Dr. Karel Heurtefeux ist Lead Application Engineer and Expert Connected Gateway / Telematics, Martin Brunner ist Principal Automotive Security und Bjoern Steurich ist Projektleiter Automotive Security bei Infineon Technologies.

Mit AUTOSAR zu  ganzheitlichem Fahrzeugschutz

Die Zeit weitgehend statischer Fahrzeugnetzwerke neigt sich dem Ende. Automatisierte Fahrfunktionen und stärkere Vernetzung erlangen nach flexiblerer Software-Architektur – und mehr IT-Sicherheit. AUTOSAR trägt dem Rechnung – mit der Adaptive Plattform und der Bereitstellung wichtiger Security-Komponenten. Weiteren Handlungsbedarf gibt es trotzdem.

Die Zeit weitgehend statischer Fahrzeugnetzwerke neigt sich dem Ende. Automatisierte Fahrfunktionen und stärkere Vernetzung zur Außenwelt verlangen nach flexiblerer Software-Architektur – und einem hohen Grad an IT-Sicherheit. AUTOSAR trägt dem Rechnung – mit der Adaptive Plattform und der Bereitstellung wichtiger Security-Komponenten. Weiteren Handlungsbedarf gibt es trotzdem.

Mobilität und Fahrzeugbau sind derzeit mit drastischen Veränderungen konfrontiert. Insbesondere die Entwicklung hin zum vernetzten und automatisierten Fahren bringt einen fundamentalen Wandel in der E/E-Architektur des Fahrzeuges mit sich. Viele anwendungsspezifische ECUs weichen wenigen hochperformanten Domänencontrollern,, in denen zuvor verteilte Funktionalitäten gebündelt werden. Dieser Umbruch forciert zwei technologische Erfordernisse: Die Konsolidierung von Automotive Cybersecurity und die Wachablösung bei AUTOSAR.

Noch erfüllt AUTOSAR Classic als Standard-Middleware für die meisten Fahrzeugplattformen die gängigen Anforderungen an ein Echtzeitbetriebssystem und Funktionale Sicherheit. Zumal AUTOSAR Classic über die Jahre kontinuierlich weiterentwickelt wurde und folgerichtig auch eine Palette an Security-Tools, etwa für sichere Onboard-Kommunikation oder Schlüssel- und Zertifikatsmanagement bereitstellt.

Im Hinblick auf hochautomatisiertes oder gar Autonomes Fahren und V2X-Kommunikation jedoch werden Vehicle Computer bzw. Domänencontroller als zentrale Instanzen künftige E/E-Architekturen prägen und das Fahrzeug wird zu einem Software-dominierten System. Es gilt deutlich mehr, umfangreichere und unterschiedlichere Applikationen zu integrieren. Der klassische AUTOSAR-Standard stößt hier an seine Grenzen und wird nach und nach von AUTOSAR Adaptive als neuem zukunftsweisenden Regelwerk abgelöst. Im Gegensatz zu AUTOSAR Classic basiert AUTOSAR Adaptive auf einem LINUX-verwandten Betriebssystem und die Applikationen nutzen hier die „AUTOSAR Runtime for Adaptive Applications“, kurz ARA. Zudem bietet die Adaptive-Plattform eine per Hypervisor vorkonfigurierte Partitionierung, die es ermöglicht, von unterschiedlichen Anbietern unabhängig voneinander entwickelte Software-Komponenten verschiedener ASIL-Kategorien auf Vehicle Computern zu integrieren und sicher zu betreiben (Bild 1). Entsprechend seiner Service-orientierten Architektur und zusätzlichen Features wie etwa granularen Updates Over-the-Air setzt AUTOSAR Adaptive auch bei der Automotive Security auf zusätzliche Maßnahmen und neue Standards.

AUTOSAR beinhaltet verschiedene IT-Sicherheitsanwendungen, beispielsweise zur Absicherung der fahrzeuginternen Kommunikation oder auch zum Schutz vertraulicher Daten. Aufgrund ihrer unterschiedlichen Architekturen bieten Classic und Adaptive AUTOSAR allerdings teils gleiche, teils unterschiedliche Security-Anwendungen (Bild 2).

Sowohl in der Classic- als auch in der Adaptive-Variante wird der für Security-relevante Anwendungen notwendige Zugriff auf kryptografische Primitive, Schlüssel und Zertifikate über den AUTOSAR-eigenen Crypto Stack abgewickelt. Dieser eruiert die implementierten kryptografischen Verfahren und Schlüsselspeicher (Hardware-Security-Modul, Krypto-Bibliothek etc.) und stellt den verschiedenen Applikationen über einheitliche Schnittstellen das nötige Schlüsselmaterial zur Verfügung. Die Applikationen greifen hernach, unabhängig von ihren jeweiligen Krypto-Implementierungen, nur auf die bereitgestellten Schnittstellen zu und bleiben auf verschiedene ECUs portierbar.

Sichere Kommunikation: SecOC, TLS und IPsec

Zur Absicherung der Kommunikation – fahrzeugintern als auch nach außen (z. B. Backend, Diagnosetester) unterstützt AUTOSAR aufgrund der vielfältigen Anwendungsfälle und Bus-Systeme im Fahrzeug gleich mehrere Protokolle: SecOC, TLS und IPsec. Dabei dient SecOC als AUTOSAR-Classic-spezifisches Protokoll speziell der Absicherung der CAN-Kommunikation. SecOC gewährleistet Authentizität, jedoch keine Vertraulichkeit und erlaubt OEMs, Sicherheitsstufen äußerst granular, bis hin zu einzelnen Nachrichten anzupassen. TLS und IPsec dagegen werden mit dem Einzug von Automotive Ethernet ins Fahrzeug zunehmend bedeutsam. Beide Standards unterstützen authentische und vertrauliche Kommunikation, wobei TLS für die fahrzeuginterne und externe Kommunikation gleichermaßen geeignet ist. TLS findet sich sowohl in Classic als auch in Adaptive AUTOSAR, IPsec hingegen nur in AUTOSAR Adaptive.

Im Fahrzeugnetzwerk ist es in der Regel nicht wünschenswert, die begrenzten Systemressourcen, wie z. B. persistente Speicher, Übertragungswege oder kryptografische Schlüssel, dem Zugriff aller Applikationen auszusetzen. Das AUTOSAR-Modul „Identity- & Accessmanagement“ sorgt daher dafür, dass nur autorisierte Anwendungen auf bestimmte Ressourcen zugreifen. Diese Zugriffsrechte können in AUTOSAR frei konfiguriert und jederzeit upgedatet werden. Derzeit ist das Identity- & Access-Management nur in AUTOSAR Adaptive verfügbar.

Wichtig ist, sicherheitsrelevante Ereignisse im Fahrzeugnetzwerk (unerlaubter Zugriff, fehlgeschlagener Aufbau eines sicheren Kanals u. ä.) zu erfassen, um sie anschließend auswerten und debuggen zu können. Gleichzeitig müssen diese Informationen selbst so geschützt sein, dass Angreifer nicht auf sie zugreifen und Einblicke ins System erlangen können. Daher unterstützt AUTOSAR zum einen das Logging von IT-Sicherheitsereignissen in sicheren Speichern. Zum anderen wacht AUTOSAR über den autorisierten Zugriff auf diese Daten mittels der UDS-Dienste 0x27 (SecurityAccess) und 0x29 (Authentication).

Absicherung der ECU  und E/E-Architektur am Beispiel SecOC

Die in AUTOSAR enthaltenen Security-Bausteine als solche reichen natürlich zur Absicherung der ECUs und ihrer Applikationen nicht aus. Entscheidend ist, sie zur Anwendung zu bringen und entsprechend dem spezifischen Security-Bedarf der jeweiligen Fahrzeugplattform individuell anzupassen. Das heißt, AUTOSAR muss durchgängig in den Security-Engineering-Prozess integriert werden. Drei Schritte sind dabei von ausschlaggebender Bedeutung: Risikoanalyse, Konfiguration und Testing. Für SecOC würde sich das Security-Engineering dann beispielhaft wie folgt darstellen:

Risikoanalyse: Die Absicherung aller Nachrichten einer ECU ist zwar technisch möglich, bindet aber unnötig viele Hardware-Ressourcen. Deutlich effizienter ist es, zunächst eine Risikoanalyse aller Nachrichten durchzuführen, um diejenigen zu identifizieren, die per SecOC geschützt werden müssen. Sind unterschiedliche Security-Profile hinterlegt (z. B. basierend auf unterschiedlichen MAC-Längen), dann wird die Nachricht unmittelbar dem richtigen Profil zugeordnet.

Konfiguration: Im nächsten Schritt gilt es, SecOC und den Crypto Stack bei allen am Datenaustausch beteiligten ECUs gemäß der vorgenommenen Risikobewertung und Security-Profile zu konfigurieren. Gerade wegen der Vielzahl an Konfigurationsparametern, die SecOC in AUTOSAR bietet, ist dabei größte Sorgfalt geboten. Denn die Fehlkonfiguration in einer einzigen ECU kann zur Folge haben, dass gesicherte Nachrichten nicht verifiziert und damit verworfen werden. Die SecOC-Konfiguration umfasst dann zum Beispiel nicht nur MAC-Längen, sondern auch die zum Erzeugen der Authentifizierungs-Tags notwendigen Schlüssel, für deren Verwaltung und Abgleich über die verschiedenen ECUs hinweg in aller Regel das Key-Management-System des OEM verantwortlich zeichnet.

Darüber hinaus empfiehlt sich eine Überprüfung der AUTOSAR-Konfiguration der zugelieferten ECUs durch den OEM, um eine Diskrepanz zu der vom OEM selbst vorgenommenen Risikoanalyse und Zuordnung der Security-Profile auszuschließen.

Testing: Aus Security-Perspektive müssen vor Freigabe einer ECU für die Serienproduktion mehrere Tests durchgeführt werden:

<ul><li>Code Review der Security-kritischen Komponenten (z. B. SecOC-Modul, CryptoStack), um Schwachstellen im Code auszuräumen.</li><li>Penetration Test der ECU, um bestmögliche IT-Sicherheit der ECU zu gewährleisten.</li><li>Funktionstest des SecOC-Moduls, um sicherzustellen, dass die MACs korrekt generiert und verifiziert werden und die Fehlercodes richtig hinterlegt sind.</li></ul>

Gefragt ist hier ein Security-erfahrenes Testing-Team, das in der Lage ist, spezifische Problemstellungen vorwegzunehmen (z. B. beabsichtigtes Verhalten, falls kein Schlüssel vorhanden) und die Testergebnisse bezüglich ihrer Auswirkungen auf die IT-Sicherheit der E/E-Architektur valide zu bewerten.

Ganzheitliche Automotive Security jenseits von AUTOSAR

AUTOSAR Classic und Adaptive stellen heute wichtige Bausteine für den Schutz der Fahrzeug-Software und -Daten vor Manipulation und unerlaubtem Zugriff bereit. Für eine ganzheitliche Absicherung des Fahrzeugnetzwerkes und einen umfassenden Schutz des Fahrzeugs im vernetzten Umfeld jedoch sind Maßnahmen jenseits der AUTOSAR-Spezifikationen vonnöten. (Bild 3).

Eine davon zielt in das Herz der Bordelektronik: Es gilt für alle (Safety-)kritischen Anwendungen einen Hardware-gestützten Vertrauensanker zu implementieren. Die Wahl fällt hier immer häufiger auf ein Hardware-Security-Modul (HSM). Das HSM kapselt das Schlüsselmaterial physikalisch ab und ermöglicht es, die kryptografischen Schlüssel getrennt von den zahlreichen (ggf. nicht vertrauenswürdigen) Anwendungen zu speichern und zu verwalten. Die Entscheidung für ein HSM hängt dabei von den spezifischen Anforderungen an Timing (Ausführung kryptografischer Algorithmen), Kosteneffizienz (Anzahl auszustattender Steuergeräte) und Manipulationsschutz (z. B. Vermeidung von Glitching- oder anderen Seitenkanalangriffen) ab.

Gleichzeitig entstehen mit zunehmender Vernetzung des Fahrzeugs neue Angriffsvektoren, während zugleich die Angreifer fortlaufend ihre Methoden perfektionieren. Es muss daher sichergestellt sein, dass Angriffe auch während der Betriebsphase des Fahrzeugs zuverlässig erkannt und analysiert werden, um geeignete Gegenmaßnahmen einzuleiten. Das erfordert – jenseits von AUTOSAR – die Implementierung eines umfänglichen Intrusion-Detection-and-Prevention-Systems (IDPS) mit aufeinander abgestimmten Komponenten zur Angriffserkennung im Fahrzeug (IDS, Automotive Firewall), zur Auswertung und Forensik im Backend sowie zur Response per Security-Update via Firmware Over-the-Air (FOTA) für die gesamte Fahrzeugflotte.

Darüber hinaus setzen alle genannten Maßnahmen voraus, dass die Steuergeräte bereits bei der Produktion mit einem kryptografischen Schlüsselsatz versehen werden.

Mit der Entwicklung hin zum vernetzten, automatisierten Fahren steigt unweigerlich die Zahl Safety-relevanter Funktionen im Fahrzeug. Gemäß dem Grundsatz „No Safety without Security“ werden damit elaboriertere Security-Maßnahmen und ein hohes Security-Level der Fahrzeugplattformen höchst bedeutsam. Hinzu kommt, dass die OEMs künftig vermehrt neue, auf hoher Konnektivität basierende Geschäftsmodelle (z. B. Remote Feature Activation) etablieren, die es abzusichern gilt. Für die weitere Entwicklung von AUTOSAR Adaptive besteht daher der klare Arbeitsauftrag, Security-Anwendungen viel stärker zu integrieren als es bei der Classic-Variante der Fall war.

Richtschnur für AUTOSAR Adaptive muss hier ein ganzheitlicher Automotive Security-Ansatz sein: Zusätzliche IT-Sicherheitskomponenten wie Hardware-Security-Module und eine mögliche Implementierung von Intrusion-Detection-and-Prevention-Lösungen müssen bei der Weiterentwicklung von AUTOSAR Adaptive Berücksichtigung finden. (oe)

<a href="http://www.escrypt.com">www.escrypt.com</a>

Bild 1: Von AUTOSAR Classic zu AUTOSAR Adaptive. 

Bild 2: Security-Anwendung in AUTOSAR Classic und Adaptive (Stand August 2019).

Bild 3: Ganzheitliche Automotive Security unter Einbeziehung von ECU-Produktion und Security Backend.

Dr. Alexandre Berthold ist als Teamleiter für Consulting und Engineering mit Schwerpunkt Automotive Security für ESCRYPT in Berlin tätig.

Dr. Michael Peter Schneider arbeitet als Project Manager mit Schwerpunkt AUTOSAR-Security bei ESCRYPT in Berlin.

Motor-Controller mit Diagnose- und Schutzfunktionen

Durch die zunehmende Bedeutung der Funktionalen Sicherheit haben sich auch die Anforderungen an die Eigendiagnosefähigkeit komplexer Motorcontroller-ASSPs stetig erhöht. Von TDK-Micronas kommt nun der embedded Motor-Controller HVC 4420F, der umfangreiche Diagnose- und Schutzmechanismen beinhaltet und in Systemen mit sicherheitskritischen Funktionen eingesetzt werden kann.

Der embedded Motor-Controller HVC 4420F, der unter der Produktmarke Micronas vertrieben wird und mit dem die erweiterten Anforderungen an die Diagnosefähigkeit innerhalb einer eingebetteten Elektromotorsteuerung abgebildet werden können, verfügt über eine 32-bit ARM-Cortex-M3 CPU mit MPU, 64 KB integriertem Flash-Speicher und 4 KB SRAM, Spannungsregler, eine Vielzahl flexibler Peripherieblöcke sowie integrierte Motorbrücken für die direkte Steuerung von BLDC-Motoren, Schrittmotoren oder bürstenbehafteten DC-Motoren.

Die Diagnose- und Schutzfunktionen werden auf der obersten Anwendungsschicht durch Software abgebildet. Dazu zählen die Auswertung von Spannungen, Strömen oder Temperaturen, die mit dem AD-Wandler oder anderen Peripherien gemessen und durch die Anwendungssoftware ausgewertet werden. In der darunterliegenden Schicht sind reine Hardwareschutzmechanismen implementiert, welche Software-unabhängige Schutz- und Diagnosefunktionen beinhalten. Diese können zum Teil durch die Anwendungssoftware konfiguriert aber nicht in ihrer Wirkung beeinflusst werden und bringen den entsprechenden Funktionsblock oder das gesamte IC in einen Fail-Safe-Zustand. Dies kann z. B. das Abschalten der Motorbrücke durch ein Überstromereignis oder ein System-Reset durch den Digital/Window-Watchdog sein. Die Umsetzung der im Safety Manual beschriebenen Schutzmechanismen durch den Kunden hinsichtlich Programmierung, Konfiguration und Beschaltung erlauben eine definierte Diagnoseabdeckung. Im Folgenden werden die Diagnose- und Schutzfunktionen genauer beschrieben.

Der HVC 4420F kann direkt am 12-V-Bordnetz betrieben werden und ist ISO-Puls-konform (ISO 7637–2 und ISO 16750–2). Der Verpolungsschutz erfolgt durch eine vorgeschaltete Diode. Regler für die untergeordneten Versorgungsdomänen sind komplett integriert.

Die Stromversorgung umfasst zwei Diagnosehauptkonzepte. Das erste dieser Konzepte ist die laufende Überwachung der internen Versorgungsspannung VBVDD. Die Spannungsüberwachung erzeugt Steuersignale zur Konfiguration des analogen und digitalen Stromversorgungssystems für verschiedene Spannungsbereiche. Unter den verfügbaren Spannungsversorgungsbereichen des HVC 4420F ist speziell der sogenannte RETENTION-Modus zu erwähnen, welcher unter Bedingungen wie „Kaltstart“ oder „Start-Stopp“ aktiviert wird, also im Falle einer zu niedrigen BVDD-Spannung. In diesem Modus werden alle Analogperipherien ​​einschließlich des Analogreglers und der Motorfunktionen abgeschaltet, die digitalen Peripheriegeräte und die CPU zurückgesetzt und kein Programm ausgeführt. Speicherinhalte werden jedoch beibehalten. Bei der Rückkehr aus dem RETENTION-Modus erfolgt ein System-Reset. Die Anwendungssoftware kann durch Auslesen eines Statusregisters die letzte Reset-Ursache erkennen und entsprechende Vorkehrungen treffen.

Ein Überspannungsfall wird ebenso durch ein Systemregisterflag angezeigt. Das IC ist bis maximal 40 V funktionsfähig, allerdings ist ein längerer Betrieb unter Überspannung aufgrund der steigenden Sperrschichttemperatur kritisch und lebensdauermindernd. Das Überspannungsflag ist eine Software-gestützte Sicherheitsfunktion, die von der Anwendungssoftware verwendet werden sollte, um z. B. die Stromaufnahme zu begrenzen und das Verlustleistungsbudget einzuhalten. Dies kann durch Ausschalten von Peripheriemodulen oder die Absenkung der CPU-Taktfrequenz erfolgen.

Eine zusätzliche Software-gestützte Diagnose der Versorgungsspannung kann durch den internen 12-bit-ADC erfolgen, indem die Batteriespannung (VBAT) und zusätzlich die Spannung nach dem Verpolungsschutz (VBVDD) zyklisch gemessen wird. Die Messung der beiden Spannungen ermöglicht die Reaktion auf Bordnetzinstabilitäten oder Überschwingern, bevor die interne Versorgung beeinflusst wird. Anwendungsspezifische Über- und Unterspannungszustände können vorzeitig erkannt und durch die vorhandenen Interruptquellen in der Software unmittelbar reagiert werden, sodass das IC in einen ausfallsicheren Zustand versetzt werden kann.

Das Taktsystem verfügt über zwei unabhängige On-Chip-Oszillatoren, den Haupt- und den Hilfsoszillator. Der Hauptoszillator stellt den 40-MHz-Haupttakt des Systems bereit und dient als Basis für Takte der Analog- und Digitalmodule. Die Versorgung des Hauptoszillators erfolgt durch den analogen Regler, wohingegen der Hilfsoszillator unabhängig vom Standby-Regler versorgt wird. Der Hilfsoszillator dient als Taktquelle für den Window-Watchdog (WWDG), der sowohl die Oszillatoren als auch den Programmfluss überwacht. Das Auslösen des WWDG erzeugt einen Systemreset.

Neben dem WWDG verfügt der HVC 4420F auch über einen Digitalen Watchdog (DWDG) für die Überwachung der korrekten Programmausführung. Im Gegensatz zum WWDG wird der DWDG vom Hauptoszillator getaktet. Jeder Fehler in der Programmausführung, der das erneute Auslösen des DWDG innerhalb einer programmierbaren Zeit verhindert, führt zu einem System-Reset.

In allen Fällen kann nach dem Aufstarten des ICs die Ursache des letzten Resets durch Auslesen des Systemstatus ausgewertet werden.

Der HVC 4420F verfügt über 3,3-V-I/O-Ports (für Debugging, digitale/analoge Funktionen), LIN-Bus-Interface, einen geschalteten Versorgungspin (HSBVDD) sowie Ports für die direkte BLDC- und Schrittmotorsteuerung.

Der HSBVDD-Anschluss ist z. B. für die Versorgung externer Sensoren bis zu einem Nennausgangsstrom von 15 mA ausgelegt. Der Port ist ein High-Side-Schalter zu BVDD mit integriertem Überstromschutz, welcher bei Überschreitung der Portstromgrenze automatisch abgeschaltet wird.

Der LIN-Port dient zur Kommunikation mit externen Geräten über den LIN-Bus und erfüllt die Anforderungen des LIN-2.2-Standards. Der LIN-Port kann aber auch für proprietäre Kommunikationsprotokolle (z. B. PWM) verwendet werden. Er verfügt über einen 8-kV-ESD-Schutz und eine Überstromabschaltung, welche bei Erreichen der Überstromgrenze den Pin in einen rezessiven Zustand schaltet. Der LIN-Pin ist in den Modi RETENTION und Power-Saving, bei thermischer Abschaltung sowie nach einem Systemreset automatisch rezessiv.

Sowohl für den HSBVDD-Port als auch für den LIN-Port wird ein aufgetretenes Überstromereignis durch ein Überstromflag in den Portregistern angezeigt und kann von der Anwendungs-Software entsprechend bewertet werden. Darüber hinaus können die Überstromereignisse von der Anwendungssoftware durch Interrupts ausgewertet und geeignete Sicherheitsmaßnahmen unmittelbar eingeleitet werden.

Der HVC 4420F verfügt über vier Temperatursensoren für die Überwachung der Sperrschichttemperatur. Zwei Temperatursensoren können bei Überschreitung des Übertemperaturlimits direkt eine thermische Abschaltung (TSD) des IC auslösen. Der TSD ist ein ausfallsicherer Zustand, in dem alle analogen und digitalen Module ausgeschaltet werden, um die interne Verlustleistung zu minimieren und Fehlfunktionen des Geräts zu vermeiden. Ein weiterer Temperatursensor, welcher vom Standby-Regler versorgt wird, überwacht die Sperrschichttemperatur nach einem TSD, um das IC bei Unterschreitung einer festgelegten Sperrschichttemperatur wieder zu reaktivieren. Nach Rückkehr aus dem TSD wird ein Systemstatusflag gesetzt, das von der Anwendungs-Software ausgewertet werden kann, um entsprechende Maßnahmen, wie Selbsttest o. ä., einzuleiten.

Der letzte der vier Temperatursensoren kann über den AD-Wandler ausgelesen werden. Eine zyklische Temperaturüberwachung ermöglicht die Reaktion auf steigende Sperrschichttemperaturen durch Maßnahmen wie das Ausschalten bestimmter Module, das Verringern der CPU-Taktfrequenz oder das Versetzen des Geräts in einen der Energiesparmodi.

Motorbrücke Diagnose- und Schutzfunktionen

Der HVC 4420F verfügt über sechs integrierte Halbbrücken zum direkten Anschluss von BLDC- oder Schrittmotoren ohne zusätzliche externe Komponenten. Jeder der Ports verfügt über einen internen Überstromschutz durch Drain-Source Spannungsüberwachung und programmierbarer Reaktionszeit, sowie Interlocking durch Überwachen der Gate-Spannungen der Brückentransistoren. Bei Überschreitung der Überstromschwelle wird ein Interrupt generiert und durch geeignete Flags der Port identifiziert, an dem der Überstrom auftrat. Es können entweder alle Halbbrücken oder nur die durch den Überstrom betroffenen Halbbrücken deaktiviert werden. Eine Halbbrücke kann erst dann wieder aktiviert werden, wenn das Überstromflag von der Anwendungssoftware gelöscht wurde. Zur Gewährleistung des Safe States werden alle Brückentransistoren während des RETENTION-, Energiespar- oder TSD-Modus sowie nach einem System-Reset auf tri-state gesetzt.

Zusätzlich zu den integrierten Diagnosefunktionen der Motorbrücken enthält der HVC 4420F Software-gestützte Sicherheitsfunktionen für die Anpassung an den spezifischen Motor- bzw. Anwendungsfall. Durch die integrierten Back-EMF-Komparatoren kann die Generatorische Spannung des Motors ausgewertet und beispielsweise mit der Rückmeldung der Rotorpositionssensoren verglichen werden. Zudem können die Verbindungen zu den Motorphasen überprüft werden durch die Auswertung der Gegen-EMK an der nicht erregten Motorphase. Speziell für Schrittmotoranwendungen können über den 12-bit-AD-Wandler die EMK-Spannungen an beiden Motorphasen gemessen und damit die Drehmomentbelastung des Motors überprüft werden. Dadurch kann in der Anwendungssoftware z. B. eine abgestimmte Blockier-Erkennung implementiert werden. Durch den Anschluss eines externen Shunt-Widerstands kann über den A/D-Wandler der Motorstrom ermittelt werden, um zusätzlich zur Motorregelung auch Motordiagnosefunktionen zu realisieren.

Der HVC 4420F bietet mehrere On-Chip-Speicherblöcke. Ein 1-KB-Start-Up-ROM enthält die Startsequenz, die Interrupt-Tabelle, Flash-Utility-Funktionen und diverse Testroutinen. Die Programmdaten werden im 4-KB-SRAM gespeichert. Ein 64-KB-Flash-Speicher steht für Anwendungsprogramme zur Verfügung, insbesondere auch um den erhöhten Speicherbedarf durch Diagnosefunktionen abzudecken. Das IC verfügt auch über einen 512-Byte-NVRAM zur Speicherung nichtflüchtiger Anwendungsdaten. Durch einen Schreibschutz kann ein Missbrauch der Daten verhindert werden.

Der Flash-Hauptspeicher enthält auch einen Schreib-/Löschschutz und es können darüber hinaus Doppel- und Einzelbitfehler erkannt und Einzelbitfehler korrigiert werden. Im Falle einer Einzelbit- oder Doppelbit-Fehlererkennung wird der spezifische Fehlertyp auslesbar und es kann ein Interrupt ausgelöst werden, sodass die Anwendungssoftware schnell durch eine anwendungsspezifische Fehleranalyse oder -korrektur reagieren kann.

Die integrierte Memory Protection Unit (MPU) ermöglicht den gezielten Schutz der im IC enthaltenen Speicherbereiche. Die MPU löst beim Verletzen der Zugriffsrechte eine Exception aus, ähnlich einem Interrupt. Ein Handler wird angesprungen und man kann auf den Fehler reagieren. Dies ist insbesondere interessant beim Einsatz von Echtzeitbetriebssystemen. Die MPU kann genutzt werden für die erhöhte Sicherheit bei der Code-Ausführung, Implementierung verschiedener Privilegien-Level in einer Anwendung oder der strikten Trennung von Code, Daten und Stack (z. B. auch zwischen verschiedenen Betriebssystemtasks).

Der embedded Motor-Controller HVC 4420F von TDK-Micronas beinhaltet umfangreiche Diagnose- und Schutzmechanismen, um in Systemen mit sicherheitskritischen Funktionen eingesetzt zu werden. Der Kunde erhält für die Auslegung seines Systems und für die Erfüllung des „Safety Goals“ relevante Datenblätter, einen FMEDA Summary Report mit den Fehlermetriken und Base Failure Rates sowie entsprechende Safety Manuals. Die abgestimmte Diagnose-Aabdeckung wird im HVC 4420F durch die Interaktion von Hardware- und Software-Funktionen erreicht. Dies bietet dem Kunden die Möglichkeit der Anpassung an anwendungsspezifische Funktionen und Konfigurationen für die Sicherheitsanforderungen der Anwendung. W (oe)

<a href="http://www.micronas.com">www.micronas.com</a>

Bild 1: Hardware- und Software-Systeminteraktion.

Bild 2: Spannungs- und Temperaturüberwachung.

Bild 3: Überwachung von Systemtakt und Programmausführung.

Bild 4: Motorbrücke Diagnose- und Schutzfunktionen.

Adriano de Rosa ist IC Architect bei TDK-Micronas.

Die Automobilindustrie steht bezüglich Security vor einer gigantischen Herausforderung. Was eigentlich jetzt schon benötigt wird, ist noch in Entwicklung. Viele Lösungen müssen erst noch gefunden und Defizite der verfügbaren HW und SW durch Übergangslösungen abgefangen werden.

Die Automobilindustrie steht bezüglich Security vor einer gigantischen Herausforderung. Was eigentlich jetzt schon benötigt wird, ist noch in Entwicklung. Hinzu kommt: Bei Security stehen die Entwickler auf ähnlich „freien Feld“ wie bei Safety vor fast zehn Jahren: Viele Lösungen müssen erst noch gefunden und Defizite der verfügbaren HW und SW durch Übergangslösungen abgefangen werden.

Dass ein selbstfahrendes Auto sicher sein muss, ist jedem sofort klar. Jedes falsche Fahrmanöver kann zum Unfall führen – das ist der erste Gedanke, und auf diesem Gebiet laufen allerorts höchste Anstrengungen. Das betrifft die Gefahrlosigkeit bei normalem Gebrauch des fehlerfreien Produkts (Gebrauchssicherheit, Safety-in-Use, SOTIF) als auch die gefahrlose Toleranz von Fehlern im Produkt, mit welchen man praktisch immer rechnen muss („Funktionale Sicherheit“, kurz „Safety“). Aber es gibt noch einen anderen Bereich, der auch „sicher“ sein muss: Die IT-Sicherheit oder „Cybersecurity“ (hier kurz „Security“), bei der es um Robustheit gegen Hackerangriffe geht. Wieso gerade im autonomen Fahrzeug?

Beim Smartphone ist jedem inzwischen klar, dass wir schon beim Herumtragen wertvolle Daten preisgeben, erst recht wenn wir damit im Internet surfen. Autonome Fahrzeuge werden irgendwann genauso präsent sein wie heute Handys. Sie werden die rollende Zentrale sein, in der wir arbeiten, lesen, schlafen, einkaufen, etc. Beim assistierten Fahren für SAE-Level 3 und 4 muss der Fahrer notfalls eingreifen können. Dass er dazu überhaupt in der Lage ist, muss das Fahrzeug schon heute Puls, Lidschlag, Reaktionsvermögen und Müdigkeit überwachen. Sprachkommandos sind bequem – dafür ist das Mikrofon ständig aktiviert.

Das Auto von morgen wird ähnlich viel über uns wissen wie Smartphones heute. Aber es gibt drastischere Gefahren: Schon 2015 wurde eine Cybersecurity-Attacke auf einen Jeep Cherokee veröffentlicht, die es dem Hacker erlaubte, vom Wohnzimmersessel aus und gegen den Willen des Fahrers das Fahrzeug beliebig zu steuern. Je autonomer das Fahrzeug, desto mehr Möglichkeiten gibt es für kreative Attacken, die im schlimmsten Fall auch auf Menschenleben abzielen können.

Cybersecurity ist eine notwendige Voraussetzung, damit autonome Fahrzeuge nicht Leben und Gesundheit gefährden. Wir müssen alle drei Bereiche beherrschen: Security, Safety und Safety-in-Use.

Doch wie ist es um die Datensicherheit im autonomen Fahrzeug bestellt? Auf den ersten Blick scheinen die Technologien vorhanden zu sein. Datenverschlüsselung und -zertifikate, trickreiche Hardwaremethoden, Freischaltcodes für SW-basierte Zusatzfeatures, elektronische Wegfahrsperren und Keyless Entry. Doch bei letzterem stellte der ADAC bereits 2016 fest, dass sich manche Fahrzeugen mit einer einfachen, bekannten Relais-Attacke stehlen lassen.

Schauen wir genauer hin: Moderne Mikroprozessoren bieten SHE-Module (Secure Hardware Extension) und HSM (Hardware Security Module), die bei der Implementierung von Crypto-Algorithmen nützlich sind und besonders gegen verschiedene Attacken gesichert sind. Geheime Schlüssel sind dort geschützt gespeichert. Diese Module können Daten ver- und entschlüsseln sowie andere, zu schützende Algorithmen ausführen. Ein Haken dabei: Inzwischen sind mehr Daten und Algorithmen Security-relevant, als die begrenzten HW-Resourcen aufnehmen können. Speicher und Rechenleistung dieser Module sind winzig im Vergleich zu denen der ungeschützten Hauptkerne. Attacken wie der oben genannte Hack oder der Heartbleed-Bug nutzen Schwächen in der SW.

Theoretisch hilft eine „Zone-and-Conduit“-Architektur, um Angriffe über SW-Schwächen deutlich zu erschweren. Doch es ist nicht leicht, den riesigen Berg an Legacy-SW für diese Architekturen umzustellen. Dafür bedarf es zusätzlich geeigneter Betriebssysteme, die sich nicht auf die Schnelle umstellen lassen, wenn sie denn überhaupt für die eingesetzten Mikroprozessoren zur Verfügung stehen. Von PCs und Handys wissen wir: Der Wettlauf zwischen Hacker und Entwickler erfordert alle paar Wochen einen (sicheren) Update – das wird auch beim autonomen Fahrzeug so sein.

Die Automobilindustrie steht bezüglich Security vor einer gigantischen Herausforderung. Was eigentlich schon gebraucht wird, ist noch in Entwicklung. Da liegt die Frage nahe, in wie weit sich Maßnahmen für Functional Safety und Security überhaupt unterscheiden?

 Aus der Sicht der Prozesse sehen sich funktionale Sicherheit und Cybersecurity sehr ähnlich: SAE J3061 ist stark an ISO 26262 angelehnt. HARA (Hazard Analysis and Risk Assessment) wird durch TARA (Thread Analysis and Risk Assessment) ersetzt, ein Konzept wird erstellt, auf Komponenten abgebildet, verifiziert, getestet und analysiert. Es sieht fast so aus, als müsse man nur ein paar Prozesse erweitern, etwas andere Maßnahmen implementieren und die Mitarbeiter schulen. Schon ist unser Produkt nicht nur „safe“ sondern auch „secure“.

Doch diese Sicht enthält einen entscheidenden Fehler: Bei der abstrahierenden Betrachtung der Prozesse übersehen wir signifikante Unterschiede und sogar konträre Anforderungen, die dazu führen können, dass Safety und Security gegeneinander arbeiten.

Ein Kernpunkt liegt schon in der Ursache für Risiken: Funktionale Sicherheit kämpft gegen Fehler, die aus der Natur der Technik resultieren. Dazu zählen physikalische Defekte (Kurzschlüsse, Oxidation, etc.) wie auch die Folgen menschlicher Irrtümer (lückenhafte Spezifikationen, etc.). Cybersecurity hingegen kämpft gegen die böswillige menschliche Intelligenz.

Das ist ein riesiger Unterschied: Bei ersterem ist der „Gegner“ groß, aber statisch – irgendwann kennt und beherrscht man alle praktisch relevanten Probleme. Bei Cybersecurity jedoch wird der Gegner von Tag zu Tag schlauer und mächtiger: Was gestern noch „secure“ war, ist heute schon geknackt.

Während im Bereich der Funktionalen Sicherheit durch eine gute HARA die allermeisten Gefahren bereits zur Entwicklungszeit bekannt sind, ist die TARA gerade einmal ein guter Startpunkt.

Obwohl die Prozessschritte „HARA“ und „TARA“ in beiden Bereichen notwendig sind, erreicht man damit bei Security deutlich weniger. Erkenntnis: Es gibt große technische Unterschiede trotz ähnlicher Prozesse.

Ein „secure“ Produkt muss lebenslang aktualisiert werden. Ein Produkt, dessen „Safety“ einmal nachgewiesen wurde, möchte man möglichst nicht mehr ändern: Jeder „Patch“ oder „Update“ schließt zwar eine Security-Lücke, öffnet aber eventuell ein neues Safety-Problem. Deshalb ist ein aktualisierter Sicherheitsnachweis notwendig, was Mehraufwand bedeutet. Die Kollision: Security braucht Patches, Safety vermeidet Patches.

Die Notwendigkeit zur Aktualisierung rührt an einem weiteren neuralgischen Punkt, nämlich die Kalkulierbarkeit und Optimierung der Systemkosten zur Entwicklungszeit. Die System-Architektur muss von vorneherein genug Reserven haben, um auf neue Angriffe reagieren zu können. Heute werden in fast jedem Steuergerät Speicherplatz und Rechenleistung zu über 90% ausgelastet. Für Patches bräuchte man aber mehr als 50% Reserve. Safety benötigt ebenfalls mehr Resourcen: Ein harter Kampf um wertvolle Resourcen in der höchst kostensensitiven Automobilindustrie.

Eine ganz andere Kollision passiert auf der menschlichen Ebene: Es treffen Experten verschiedener Generationen und Kulturen aufeinander. Safety predigt primär saubere Entwicklung, doch Security lernt heute am meisten von „enfants terribles“, die scharf, aber auch quer denken.

Es hilft nicht, diese Konflikte auszublenden. Man muss sie benennen, um zu Lösungen zu kommen. Einige davon skizzieren wir im Folgenden.

Gemeinsamkeiten – auf dem Weg zu Lösungen

Wir greifen nur zwei wichtig Aspekte heraus: Architektur und Analyse:

Notwendigkeit einer gemeinsamen Architektur: Um Rückwirkungsfreiheit (FFI, Freedom from Interference) zwischen Bereichen mit unterschiedlicher ASIL-Klassifikation zu erreichen, sind Partitionierungsmechanismen nützlich. Ähnliches gilt für die Unabhängigkeit von Security-Schichten (Zonen). Damit der Security-Patch möglichst wenige Safety-Bereiche beeinflusst, sollten sich die Bereiche nicht partiell überschneiden (Bild 1). Die „Access Control“-Grenzen zwischen Security-Zonen und die „Independence“-Grenzen zwischen ASIL- und QM-Komponenten sollten kreuzungsfrei verlaufen.

Gemeinsamkeit bei der Analyse: Die „Shared Resources“, gemeinsam genutzte Ressourcen, sind die Schwachstellen, über die sich Fehler unerwartet ausbreiten und die gleichzeitig als „Tunnel“ für Security-Angriffe dienen. Man kann das vergleichen mit dem Kanalisationssystem einer Stadt: Es verbindet unterirdisch scheinbar getrennte Gebäude und Stadtteile, zugleich dringen auf diesen Wegen bevorzugt „Bugs“ und andere unerwünschte Mitbewohner ein.

 ISO 26262 und ISO/SAE 21434 – zwei ungleiche Brüder

Der industrieübergreifende Standard zu Funktionaler Sicherheit, IEC 61508, war ein Vorläufer der ISO 26262, die speziell für die Automobilindustrie entwickelt wurde. Genau das soll ISO/SAE 21434 für Cybersecurity leisten.

Wir dürfen jedoch nicht vergessen, dass die erste Version von ISO 26262 schon 2011 veröffentlich wurde, während das bei ISO/SAE 21434 für 2020 geplant ist. Dieser zeitliche Vorsprung von neun Jahren spiegelt sich auch in der Entwicklung wieder: Während Funktionale Sicherheit im Prinzip bekannt ist, lernt die Community jetzt erst, was Cybersecurity bedeutet. Sie hinkt der IT-Security hinterher. Gleiches gilt für Werkzeuge, Betriebssysteme, SW-Pakete und auch Mikrocontroller. Während mehrere „Safety Processors“ seit Jahren am Markt verfügbar sind, sind „Security Processors“ im automotiven Umfeld kaum zu finden.

Bei Security stehen die Entwickler auf ähnlich „freien Feld“ wie bei Safety vor fast zehn Jahren. Es ist dringend notwendig den 20-jährigen Erkenntnisweg anderer Securitybereiche beschleunigt im automotive Umfeld zu durchlaufen. Hacker haben diesen Vorsprung bereits. Viele Lösungen müssen erst noch gefunden und Defizite der verfügbaren HW und SW durch Übergangslösungen abgefangen werden.

<a href="http://www.exida.eu">www.exida.eu</a>

Dieser Fachbeitrag basiert auf dem Vortrag, den die Autoren bei der Fachtagung „Safety meets Security“ (7.11.2019, Fellbach) halten werden.

Florian Bogenberger ist Managing Safety Consultant bei exida.com GmbH in 85579 Neubiberg.