49100.jpg

33587.jpg

Fotolia/Fraunhofer

Die Vernetzung von Fahrzeugen nimmt zu: Über zukünftige Standardschnittstellen wie eCall wird bald jedes Fahrzeug vernetzt sein. Bei den Pkw wird die Entwicklung vornehmlich durch den Infotainment- und Telematik-Bereich getrieben. Für Nutzfahrzeuge bieten sich darüber hinaus vielfältige Möglichkeiten zur Integration in Arbeits- und Geschäftsprozesse. Ist die Integration ins Netz erst vorhanden, stellen sich einige Fragen: Wie sicher ist die Fahrzeugschnittstelle gegenüber Angriffen von außen? Kann ein Angreifer womöglich über die internen Fahrzeugbusse auch andere Steuergeräte beeinflussen?

Eingriffe in die Fahrzeugelektronik von außen sind nichts Neues; das Erschleichen von Zusatzleistungen durch Parameteränderungen (zum Beispiel Chip-Tuning), Fahrtenschreibermanipulationen oder schlichtweg Vandalismus gab es bisher auch, nur war die Zahl der Vorfälle sehr gering und die Angriffe fanden meist über den direkten Zugriff auf das Fahrzeug statt.

Auf einen Blick

Integriertes Safety/Security-Konzept

Die Investition in IT-Security im Fahrzeug lässt sich derzeit nur schwer mit den aus den Risiken resultierenden Schäden motivieren; bisher ist in der Praxis noch kein größerer Schadensfall eingetreten. Dass dieser Fall kommen wird, ist so gut wie sicher. Bis dahin investieren Hersteller und 1st-Tier gerade so viel, um möglichst nicht als Erste einem Security-Zwischenfall zum Opfer zu fallen. Dabei gibt es methodische und technische Möglichkeiten, die Angriffssicherheit zu erhöhen, und das auch schon mit moderatem Aufwand. Insofern gilt es bereits heute, über alle Entwicklungsbereiche hinweg eine Sensibilisierung zu erreichen, um durch eine frühzeitige Betrachtung dieses Qualitätsaspekts spätere teure Änderungen und Korrekturen zu vermeiden.

Über das Internet oder andere eingebrachte Geräte (beispielsweise Mobiltelefone, Tablets oder mobile Datenträger) sind nun aber auch großflächige Angriffe aus der Ferne prinzipiell möglich. Bei Bekanntwerden eines entsprechenden Vorfalls wäre der Imageschaden immens: Welcher Hersteller möchte in der Tageszeitung stehen, wenn eine ganze Baureihe über die gehackte Diebstahlsicherung stillgelegt wird? Dabei reichen die Motive für Angriffe vom technischen Spieltrieb eines Einzelnen über Interessen zur Erhöhung des persönlichen Nutzens bis hin zur Wirtschaftskriminalität. Zwar ist der technische Aufwand bisher recht hoch, jedoch können auch über bisher vermeintlich sichere Systeme Angriffe erfolgen, wie beispielsweise über eine mit einer Schadsoftware präparierte Audio-CD, die eine Sicherheitsschwäche des Mediaplayers ausnutzt, um die volle Kontrolle über den CAN-Bus zu erlangen.

Security-Mängel beeinträchtigen die Safety

Die Beispiele illustrieren, dass Security-Mängel safety-relevante Komponentenfehler auslösen können. Daher muss bei der Analyse der funktionalen Sicherheit zunehmend auch die Security eines Fahrzeugs berücksichtigt werden. Zunächst scheint es nahezuliegen, die gewohnten Safety-Analysetechniken wie zum Beispiel Fehlerbaumanalyse einfach auf Security-Fehler zu übertragen. Es zeigt sich aber, dass sich Security grundsätzlich von Safety unterscheidet, was eine differenziertere Betrachtung erfordert.

Safety-Betrachtung von Elektronik und Software

Die funktionale Sicherheit eines Kraftfahrzeugs war schon immer ein wichtiger Aspekt in der Automobilbranche. Seit gut einem Jahr reguliert nun auch die aktuelle Automotive-Norm ISO 26262 die Entwicklung sicherheitsrelevanter Funktionen und Komponenten für E/E-Systeme.

Bild 1: Das Grundsätzliche Vorgehen bei Safety- und Security-Analysen ist gleich.

Bild 1: Das Grundsätzliche Vorgehen bei Safety- und Security-Analysen ist gleich.Fraunhofer IESE

Zentraler Aspekt der Anforderungen dort ist eine Gefährdungs- und Risikoanalyse, bei der die Auftrittswahrscheinlichkeit von Einzelfehlern und die Fehlerpropagierung im System betrachtet werden. Durch ein entsprechendes Sicherheitskonzept und dessen nachvollziehbare Analyse ist nachzuweisen, dass die Restrisiken in einem akzeptablen Bereich liegen. Klassische Analysetechniken sind hier deduktive (zum Beispiel Fehlerbaumanalyse) und induktive (zum Beispiel Failure Mode and Effects Analysis) Analysetechniken. Neben dem eigentlichen Safety-Engineering wird durch die Norm jedoch auch ein „gutes“ Engineering im klassischen Sinne gefordert.

Security-Bewertung von Elektronik und Software

Am Beginn jeder Security-Analyse steht eine Risikobetrachtung (Threat Analysis), bei der die relevanten Bedrohungen (Threats) ermittelt werden, gegen die das System geschützt werden muss. Eine Bedrohung ist durch die Attribute Threat Agent, Asset und Adverse Action definiert: Der Threat Agent charakterisiert den Angreifer mit seinen (angenommenen) Angriffsfähigkeiten und verfügbaren Ressourcen; das Asset bezeichnet ein schützenswertes Gut, wobei es sich sowohl um ein materielles wie ein ideelles Gut handeln kann (beispielsweise „Verlust der Bremsfunktion“, „Vertraulichkeit von Informationen“); die Adverse Action bezeichnet schließlich die sicherheitsgefährdende Aktion des Angreifers, also den konkret genutzten Angriffsvektor.

Schon die Begrifflichkeiten verdeutlichen die Unterschiede zwischen Safety und Security. Safety geht von der potenziellen Schadhaftigkeit des technischen Systems aus und adressiert die Reduktion des Risikos, das vom System für den Menschen ausgeht. Die technische Schadhaftigkeit kann hierbei durch Alterung oder Verschleiß, aber auch rein durch systematische Fehler in der Entwicklung entstehen. Grob gesagt adressiert Safety somit die Wirkung des Systems auf den Menschen; Security im Gegensatz die Wirkung des Menschen auf das System. Der Mensch ist hierbei natürlich nur schwer vorhersagbar. Ob ein Angriff stattfindet, hängt maßgeblich von der Motivation pozentieller Angreifer ab und von ihrer Erwartung, ungestraft davon zu kommen. Ob der Angriff Erfolg hat und die Sicherheit des Systems tatsächlich beeinträchtigt, ist unter anderem von dem Wissen, der Beharrlichkeit und der materiellen Ausstattung des Angreifers abhängig sowie von zufälligen begünstigenden oder widrigen Umständen – allesamt Merkmale, die einer systematischen Analyse schlecht zugänglich sind.

Die Erfolgswahrscheinlichkeit für einen Security-Angriff steigt in dem Maße, wie neue Angriffstechniken bekannt werden, leistungsfähigere oder billigere Angriffswerkzeuge erscheinen, oder wie sich Angreifer wirtschaftlich lukrativere „Vermarktungsmöglichkeiten“ für ihre Angriffe ausdenken, die einen höheren Ressourceneinsatz rechtfertigen. Daher unterliegt das Security-Design eines Systems – im Gegensatz zur Safety-Architektur – einem Alterungsprozess. Für langlebige Güter bedeutet dies, dass man Security-Konzepte mit einem erheblichen „Sicherheitspuffer“ versehen muss, damit der erforderliche Schutz auch zum Ende der Einsatzdauer des Systems noch gewährleistet ist.

Systematische Integration von Safety und Security

Bild 2: Vorschlag für die Berücksichtigung von Safety und Security in einem gemeinsamen Entwicklungsprozess nach Eherer.

Bild 2: Vorschlag für die Berücksichtigung von Safety und Security in einem gemeinsamen Entwicklungsprozess nach Eherer.Fraunhofer IESE

Obwohl die Perspektiven zunächst gegensätzlich zu sein scheinen, ist das abstrakte Vorgehen im Safety- und Security-Engineering letztlich doch ähnlich (Bild 1).

Somit ist es auch nicht erstaunlich, dass schon Ansätze existieren, Safety und Security in einem Prozess zu kombinieren. Als Beispiel sei hier der Vorschlag von Eherer genannt, der auf der ESCAR-Konferenz 2010 vorgestellt wurde (Bild 2).

Eine integrative Betrachtung auf Prozessebene ist ein guter Anfang. Die Erfahrung hat gezeigt, dass sich gerade im Bereich der technischen Absicherung Synergien zwischen Safety und Security nutzen lassen.

Konstruktive Verfahren zur Erhöhung der Funktions- und  Angriffssicherheit

Mit Hilfe konstruktiver Verfahren können einzelne Steuergeräte und Funktionen gegenüber Funktionsfehlern und Angriffen „gestählt“ werden. Dabei lassen sich die folgenden grundlegenden Ansätze unterscheiden:

  • Zugriffsbeschränkung zu internen Fahrzeugnetzen. Man erreicht eine Abschottung durch die Isolierung von Bussegmenten, den Einsatz dedizierter Gateways mit Firewall-Funktion, die Verwendung starker Kryptografie, den besonderen Schutz der Schlüssel und Zugangsdaten sowie durch strenge Authentisierung der Kommunikationspartner.
  • Logische Trennung von Funktionen mit Schnittstellen zur Außenwelt (zum Beispiel Infotainment, Diagnose) und Safety-Funktionen. Dies ist ein grundlegendes Vorgehen im Safety-Engineering, um mögliche Fehler möglichst lokal zu begrenzen und deren Streuung auf andere Funktionen zu verhindern. Wird die Trennung unter Berücksichtigung von Security-Aspekten umgesetzt, ist dies eine weitere Maßnahme zur technischen Bewältigung von Safety- und Security-Problemen. Heutige Virtualisierungslösungen (wie ein Hypervisor) erfüllen diese integrativen Anforderungen bereits.
  • Komponentenidentifikation und Integritätsprüfung. Diese Maßnahme soll das das System vor „fremden“ Komponenten schützen. Die Lösung ist auch für die Erkennung und Isolierung schadhafter Komponenten (im Sinne der Safety) nutzbar, wenn neben der Identifizierung auch eine Safety-Integritätsprüfung durchgeführt wird. Dies wird in zunehmendem Maße relevant, wenn man Car2X-Szenarien mit kooperativer Bewältigung sicherheitsrelevanter Funktionen betrachtet.
  • Anomalie-Erkennung. Sie ermöglicht zum Beispiel die Erkennung einer Nachrichtenverfälschung auf dem Bus. Wird die Absicherung entsprechend geschickt gewählt, lassen sich sowohl zufällig verfälsche Nachrichten (durch Systemfehler verursachte Safety-Ereignisse) als auch gezielt manipulierte Nachrichten (im Sinne einer Security-Attacke) erkennen.
  • Abschaltung nicht benötigter Funktionen. Damit kann man unzulässigen Manipulationsversuchen vorbeugen, etwa dem drahtlosen Flashen eines Bremsensteuergeräts, während das Fahrzeug in Bewegung ist.
  • Erhöhung der Robustheit des Programmcodes. Die Absicherung der Schnittstellen gegen Speicherüberläufe und Bereichsüberschreitungen beugt einerseits der Entstehung und Ausbreitung von Fehlern (Safety) vor, andererseits vermindert er die potenzielle Angriffsfläche des Systems (Security).
  • Hardware mit speziellen Sicherheitseigenschaften. Inzwischen sind Mikrocontroller mit hardware-unterstützter Verschlüsselung, deaktivierbaren Diagnose-Schnittstellen und gegen unbefugtes Auslesen geschütztem Speicher am Markt verfügbar, mit denen besonders exponierte Systemfunktionen auch konstruktiv gegen Angriffe gehärtet werden können.

Die Kosten können sogar sinken

Solche konstruktiven Ansätze erhöhen die Entwicklungskosten und die Stückkosten der Hardware. Insofern gilt es, die in der Analyse identifizierten Risiken gegen den erforderlichen Mehraufwand abzuwägen. Allerdings ist zu erwarten, dass beispielsweise der Aufpreis für entsprechende Hardware in Zukunft stark sinken wird. Qualitätssichernde Maßnahmen bei der Software-Entwicklung können sogar kostensenkende Effekte haben, da hierdurch auch andere Funktionsfehler verringert und die langfristige Wartbarkeit des Codes verbessert werden.

Methodische Integration

Neben diesen technischen, synergetisch positiven Absicherungskonzepten ist aber auch eine methodische Integration wichtig, um durch Nutzung von Synergien Entwicklungsaufwand einzusparen. Im Bereich der integrierten Analysen existieren bereits Ansätze, die Fehlerbäume mit Angriffsbäumen, also Safety-Analyse-Modelle und Security-Analyse-Modelle, integrieren.

Der Ansatz nutzt die strukturelle Ähnlichkeit der Modelle, um jeweils einen Baum als Unterbaum für den anderen einzusetzen. Somit kann man sich ein Angriffsszenario als Ursachen-Unterbaum für ein Safety-Ereignis vorstellen. Die Methode wurde im vom BMBF geförderten Projekt ViERforES (Virtuelle und Erweiterte Realität für höchste Sicherheit und Zuverlässigkeit von Eingebetteten Systemen) entwickelt und dokumentiert.

Sicherheitskonzept

Einen anderen Zugang bietet das Sicherheitskonzept. Dieses ist häufig das zentrale Dokument eines Sicherheitsingenieurs, sowohl im Bereich der Safety als auch der Security. Daher bietet es sich an, auf konzeptioneller Ebene ein integriertes Safety/Security-Konzept zur erstellen. Eine bessere Integration rückt gerade auch durch aktuelle Trends in der Fahrzeugentwicklung, etwa die erwarteten Car2X-Szenarien, stärker in den Blickpunkt.

Dadurch, dass die Systeme offener und komplexer werden, wird auch eine modulare Betrachtung von Safety und Security wichtiger. Mit Ansätzen wie den Conditional Safety Certificates (ConSerts) des Fraunhofer IESE soll ermöglicht werden, die finale Safety-Bewertung dem kooperativen System zur Laufzeit zu überlassen. Voraussetzung hierfür ist die formale Spezifikation von Fehlermodellen und Fehlerpropagierungsregeln für das Gesamtsystem, so dass eine automatische Überprüfung möglich wird.

In Entstehung befindliche Standards, wie die ISO/DIS 15118 zur Kommunikation von Fahrzeugen mit der Infrastruktur, berücksichtigen Security als einen zentralen Aspekt. Um die Verankerung von Security-Betrachtungen im eigentlichen Entwicklungsprozess wird daher kein Zulieferer oder Hersteller herumkommen, um security-bedingte Risiken in Bezug auf ihre Auswirkungen auf die funktionale Sicherheit bewerten und beherrschen zu können.

Sören Kemmann

ist Abteilungsleiter für Embedded Systems Quality Assurance am Fraunhofer-Institut für experimentelles Software Engineering (IESE).

Ralf Kalmar

ist Geschäftsfeldleiter für Automobil- und Transportsysteme am Fraunhofer IESE.

Dr. Reinhard Schwarz

ist Leiter des Teams Security am Fraunhofer IESE.

(av)

Sie möchten gerne weiterlesen?