elektrobit-bild-1.jpg

Die Komplexität der Softwaresysteme im Auto steigt, und die Vernetzung des Fahrzeugs in sich sowie mit der Umwelt nimmt zu. Die Kunden fordern verstärkt die Integration von mobilen Endgeräten, Internet und Apps, mit deren Entwicklung die Automobilsoftware in immer kürzeren Innovationszyklen Schritt halten muss. Das bedeutet, dass immer mehr Systeme und Sensoren im Auto miteinander und mit externen Stellen kommunizieren müssen (Bild 1).

Bild 1: Die Vernetzungsmöglichkeiten von Mensch und Auto nehmen stetig zu.

Bild 1: Die Vernetzungsmöglichkeiten von Mensch und Auto nehmen stetig zu.Elektrobit

Die dabei ausgetauschten Signale kommen sowohl in Anwendungen der funktionalen Sicherheit (Safety) zum Einsatz als auch in solchen, die mit Fragen der IT-Sicherheit (Security) konfrontiert sind. Typische Anwendungsfälle sind Lösungen für Fahrerassistenzsysteme bis hin zum autonomen Fahren, wie zum Beispiel der Austausch von Verkehrs- und Gefahrenmeldungen zwischen Fahrzeugen und Straßen-Infrastruktur.

Safety- und Security-Aspekte beeinflussen sich dabei stark gegenseitig, was inzwischen auch von gängigen Standards für funktionale Sicherheit, IEC 61508 und ISO 26262, aufgegriffen wird. Darüber hinaus setzen mittlerweile sogar politische Institutionen wie beispielsweise die EU-Kommission die beiden Sicherheitsaspekte zueinander in direkte Verbindung. José Manuel Durão Barroso brachte es in einer Rede über die Sicherheit von Kernenergie 2012 treffend auf den Punkt: „… There is no safety without security and vice-versa“. Die Systeme im Auto müssen deshalb mit einer schlüssigen Argumentation sowohl hinsichtlich Aspekten der Safety als auch der Security nach dem jeweiligen Stand der Technik aufwarten können.

Integritäts- und Safety-Mechanismen

Bild 2: Safety-Architektur eines Autosar-Steuergeräts auf Basis von EB tresos.

Bild 2: Safety-Architektur eines Autosar-Steuergeräts auf Basis von EB tresos. Elektrobit

Die Basissoftware eines Systems mit funktionalen Sicherheitsanforderungen muss Mechanismen bereitstellen, die es ermöglichen, die Integrität eines Systems aus Software-Sicht zu gewährleisten. Diese grundlegenden Mechanismen sind inzwischen gut im Autosar-Framework etabliert und zum Beispiel in der ISO 26262 beschrieben. Darin wird zwischen drei verschiedenen Arten von Rückwirkungsfreiheit – dem Ziel der funktionalen Sicherheit – unterschieden:

  • „Spatial Freedom from Interference“ besagt, dass die Daten sicherheitskritischer Komponenten vor dem Zugriff anderer Komponenten geschützt sein müssen. In den meisten Software-Architekturen stellt das Betriebssystem Mechanismen zur Speicheraufteilung bereit. Bild 2 zeigt eine Beispielarchitektur mit Schutzmechanismen für funktionale Sicherheit auf Basis von Autosar. Der Speicherschutz wird vom „Safety OS“ bereitgestellt.
  • Die „Temporal Freedom from Interference“ behandelt die zeitliche Komponente: Es muss sichergestellt sein, dass die sicherheitskritische Software auch die benötigte Rechenzeit erhält und in der erwarteten Reihenfolge ausgeführt wird. In Bild 2 ist dies durch das Modul „Safety TimE Protection“ dargestellt.
  • Als dritten Bereich, für den Rückwirkungsfreiheit gewährleistet sein muss, nennt die ISO 26262 den „Exchange of Information“. Sicherheitskritische Daten und Signale müssen so abgesichert sein, dass verfälschte oder fehlende Daten erkannt werden. Innerhalb eines Steuergerätes lässt sich die Absicherung direkt über die „Runtime-Environment“ (Safety RTE in Bild 2) vornehmen.

Security-Mechanismen

Während Safety-kritische Systeme Fehler minimieren, die aus dem System selbst hervorgehen, müssen Security-Mechanismen das System vor Schaden schützen, der durch unautorisierten Zugriff von außen entstehen könnte. Das Bedrohungsmodell eines Security-relevanten Systems ist daher hochdynamisch, da sich die Bedrohungen über die Systemlaufzeit massiv ändern und die Angriffsmethoden zum Zeitpunkt des Systemdesigns höchstwahrscheinlich noch nicht bekannt sind. Die entscheidenden Faktoren sind hier in erster Linie die Verfügbarkeit stetig wachsender Rechenleistung sowie der Einfallsreichtum der Angreifer.

Safety, Security und Availability

Vor allem auf dem Weg zum autonomen Fahren spielt die Sicherstellung dauerhafter Verfügbarkeit (Availability) von kritischen Systemfunktionen eine entscheidende Rolle. Neben verschiedenen Mechanismen in Software ist dabei auch die entsprechende Unterstützung durch die Hardware entscheidend. Das mittelfristige Ziel ist deshalb die Entwicklung eines Systems, welches die drei Aspekte Safety, Security und Availability in sich vereint und damit ein sich selbst schützendes System bildet.

Die Hauptaufgabe der Basissoftware bleibt in jedem Fall die Bereitstellung von Mechanismen zur Sicherstellung der Systemintegrität. Dies kann sowohl durch die Erweiterung von Mechanismen für Safety-Systeme als auch durch die Ergänzung von Security-relevanten Maßnahmen erreicht werden. Da die Analysen beider Aspekte auf Risikomodellen basieren, ist es entscheidend, Synergien aus beiden zu erkennen und zu nutzen. So kann die Suche nach Security-Lücken neue Safety-Aspekte ans Tageslicht bringen und umgekehrt.

Ein gutes Beispiel für Sicherheitslücken, die sowohl Safety- als auch Security-Auswirkungen haben, sind sogenannte Stack-Overflows. Sie kommen entweder durch einen Fehler in der Software zustande – ein Safety-Problem – oder sie werden durch einen gezielten Angriff stimuliert: eine Security-Lücke. In beiden Fällen müsste ein solches Szenario während der jeweiligen Analyse identifiziert und durch ein geeignetes Software-Design verhindert beziehungsweise wenigstens zur Laufzeit erkannt werden.

Derartige Fehler und Angriffe lassen sich durch den oben beschriebenen Speicherschutzmechanismus „Spatial Freedom from Interference“ verhindern. Zwar schützt diese Maßnahme alleine noch nicht gegen Denial-of-Service-Angriffe, jedoch ist sichergestellt, dass das System nicht in einen undefinierten Zustand, sondern in einen zuvor definierten Fehlerzustand übergeht. Mithilfe der „Freedom from Interference“-Argumentation ist es darüber hinaus möglich, die Safety-relevanten Softwareteile von den durch äußere Einwirkungen besonders gefährdeten Teilen zuverlässig zu trennen. Neben einem reinen Schreibschutz mittels MPU bieten moderne CPUs zum einen auch die Möglichkeit, Leserechte zu vergeben. Diese Maßnahme sorgt dafür, dass nur entsprechend privilegierte Module Security-relevante Daten wie kryptografische Schlüssel lesen können. Zum anderen lassen sich Ausführungsrechte gezielt setzen beziehungsweise entziehen.

So kann Code, der auf die sensiblen Security-Daten zugreift, so lange als nicht-ausführbar markiert werden und die Daten nicht verwenden, bis er wirklich nach Plan ausgeführt werden soll. Die Vergabe von entsprechend eingeschränkten Ausführungsrechten auf den Stack verhindert darüber hinaus das unerwünschte Ausführen von Code aus fremdem Kontext. Die Kombination beider Mechanismen schützt also bereits vor zwei typischen Angriffsvektoren.

Nachrichtenabsicherung durch Security-Maßnahmen

Bild 3: Authentizitätsprüfung einer Nachricht durch Message Authentication Code (MAC).

Bild 3: Authentizitätsprüfung einer Nachricht durch Message Authentication Code (MAC).Elektrobit

Im Safety-Kontext müssen sich sicherheitskritische Anwendungen auf die empfangenen Nachrichten verlassen können. Deren Schutz ist Aufgabe der Security: Die Authentizität der Kommunikationspartner sowie der ausgetauschten Nachrichten, die Integrität der Daten sowie Aktualität und Vertraulichkeit des Nachrichteninhalts müssen sichergestellt werden.

Die Sicherstellung der korrekten Nachrichtenquelle sowie der Authentizität des Inhalts beinhaltet eine Überprüfung der Unversehrtheit der empfangenen Daten, um eine Manipulation der Nachricht auszuschließen. Das gängigste Verfahren zur Sicherstellung von Authentizität und Integrität ist die Verwendung eines Message Authentication Code (MAC). Ein für die kommende Version des Autosar-Standards vorgeschlagener Vertreter davon ist der Cipher-Based Message Authentication Code (CMAC). Ihm liegt der symmetrische AES-Algorithmus (Advanced Encryption Standard) mit entsprechendem kryptografischem Schlüssel zugrunde. Der ursprünglichen Nachricht wird vor dem Versand der berechnete MAC ganz oder teilweise angehängt. Der Empfänger kann die Unversehrtheit der Nachricht überprüfen, indem er die gleichen Berechnungen durchführt wie auf Senderseite und dann die beiden Ergebnisse vergleicht (Bild 3).

Die alleinige Verwendung von MACs schützt noch nicht davor, dass valide Nachrichten zu einem beliebigen Zeitpunkt aufgezeichnet und später (erneut) gesendet werden. Um das System vor einem solchen Eingriff zu schützen, muss jeder Nachweis der Authentizität individuell erfolgen und als solcher vom Empfänger überprüfbar sein. Dies lässt sich durch einen Aktualitätswert bei der Erzeugung des MACs erreichen, zum Beispiel durch einfache monotone Zähler oder verlässliche und manipulationssichere Zeitstempel.

Verschlüsselung kann die Vertraulichkeit der Nachricht, also den Schutz des Nachrichteninhalts vor der Einsicht durch Dritte, sicherstellen. Das gängigste Verfahren dazu ist das symmetrische Verfahren AES (Advanced Encryption Standard).

System- und Softwareentwicklung

Zur Analyse funktionaler Sicherheitsaspekte gibt es eine Reihe etablierter und in der Praxis bewährter Vorgehensweisen. Sie basieren meist auf einer klassischen Risikoanalyse; spezielle Techniken, beispielsweise zur Analyse der Softwarearchitektur und der eigentlichen Implementierung, ergänzen sie. Risikoanalysen des Systems und der Implementierung stellen daher die wichtigsten Erweiterungen für die Entwicklung von Safety-Anwendungen dar.

Analysen hinsichtlich Security sind im Standardentwicklungsprozess für Steuergeräte aus dem Automobilbereich bisher eher die Ausnahme. Safety- und Security-Analysen haben jedoch viel gemein, da beide risikobasiert sind. Je mehr sich die Analysen der eigentlichen Implementierung nähern, desto ähnlicher werden sie sich. Die formalen Inspektionen, angefangen beim Software-Design, sind bereits fast identisch. Beide Bereiche erfordern letztendlich gewissenhafte Softwareentwicklung. So lassen sich viele Bedrohungen aus den Bereichen Safety und Security bereits mit den heute gängigen Methoden und Prozessen verhindern oder minimieren.

Safety und Security in Autosar-Steuergeräten

elektrobit-aufmacher.jpg

Elektrobit

Für Steuergeräte mit Anforderungen sowohl hinsichtlich funktionaler als auch IT-Sicherheit lassen sich bestehende Autosar-Architekturen mit etablierten Safety-Mechanismen konsequent weiter verwenden. Für gängige Security-Anforderungen besteht die Möglichkeit, entsprechende Anwendungsfälle durch Module wie zum Beispiel EB tresos SecOC um Absicherungskomponenten für Buskommunikation zu erweitern. Zusätzlich lassen sich individuelle Maßnahmen wie weitreichendere Integritätsschutzmechanismen oder Maßnahmen zur Wahrung der Vertraulichkeit ergänzen.

Durch die gegenseitige Beeinflussung von Safety- und Security ist es wichtig, die beiden Disziplinen gemeinsam zu betrachten und Synergien in Prozessen und Methoden zu identifizieren. Etliche Security-Aspekte erweitern das Safety-Engineering und ergänzen es um zusätzliche Absicherungsschritte. Umgekehrt muss untersucht werden, inwieweit konkrete Absicherungsmaßnahmen für Security solche für Safety bereits beinhalten.

Denkt man einen Schritt weiter, spielt vor allem auf dem Weg zum autonomen Fahren die Sicherstellung dauerhafter Verfügbarkeit (Availability) von kritischen Systemfunktionen eine entscheidende Rolle. Der sichere Zustand, in den ein System bei Erkennung einer Gefahr nach Safety oder Security heutzutage oft übergeht, ist schlicht die Abschaltung. Bei selbstfahrenden Autos ist dies jedoch nicht akzeptabel, denn schließlich muss die Grundfunktionalität in ausnahmslos jeder Situation gewährleistet sein. Um diese vollständige Verfügbarkeit sicherzustellen, ist neben verschiedenen Mechanismen in Software auch die entsprechende Unterstützung durch die Hardware entscheidend. Das mittelfristige Ziel ist deshalb die Entwicklung eines Systems, welches die drei Aspekte Safety, Security und Availability in sich vereint und damit ein sich selbst schützendes System bildet.

Martin Böhner

ist Senior Project Manager Security bei der Elektrobit Automotive GmbH.

Dr. Alexander Mattausch

ist Senior Project Manager Functional Safety bei der Elektrobit Automotive GmbH.

Alexander Much

ist Quality and Safety Manager bei der Elektrobit Automotive GmbH.

(av)

Sie möchten gerne weiterlesen?

Unternehmen

Elektrobit Automotive GmbH

Am Wolfsmantel 46
91058 Erlangen
Germany