Absichern von offenen E/E-Systemen mit Hilfe virtueller Prototypen

| Autor / Redakteur: Thomas Kuhn und Pablo Oliveira Antonino de Assis * / Sebastian Gerstl

In Zeiten vernetzter und zunehmend "offener" E/E-Systeme in Automobilen spielt der Sicherheitsaspekt eine signifikant größere Rolle. Daher sollten moderne Elektrik- und Elektronik-Plattformen ausgiebig anhand virtueller Prototypen getestet werden.
In Zeiten vernetzter und zunehmend "offener" E/E-Systeme in Automobilen spielt der Sicherheitsaspekt eine signifikant größere Rolle. Daher sollten moderne Elektrik- und Elektronik-Plattformen ausgiebig anhand virtueller Prototypen getestet werden. (Bild: Clipdealer)

Früher waren Elektrik- und Elektronik-Systeme im Automotive-Bereich wenig vernetzt; es galt das „security by obscurity” – Prinzip. Doch in Zeiten zunehmender Vernetzung und offener Plattformen birgt ein solcher Ansatz große Risiken. Worauf es beim Schutz moderner E/E-Systeme ankommt, lesen Sie hier.

In der Vergangenheit wurde die Sicherheit vor Angriffen im Bereich der Fahrzeugarchitekturen von Entwicklern häufig als nicht relevant betrachtet, da es nur eine geringe Konnektivität und damit auch nur geringe Angriffsflächen gab. Dies ändert sich, da sich Fahrzeuge immer stärker vernetzen, und Daten miteinander und mit anderen Systemen austauschen. Beispiele hierfür sind die Fernwartung und entfernte Updates.

Einfache Sicherheitskonzepte basierten in der Regel auf „security by obscurity” oder auf unsystematischen Gegenmaßnahmen, die keine vollständige Sicherheit vor Angriffen ermöglichten. Die nächste Generation ECUs (Electronic Control Units) muss stärker geschützt sein. Dieser Schutz umfasst zum Beispiel die Integrität der eigenen Software und der Konfiguration, die Vertraulichkeit von IP und Nutzerdaten und das Durchsetzen von Lizenzbedingungen und gewährleistungsrelevanten Einschränkungen.

Gefährdungsanalyse: Ermittlung der erforderlichen Sicherheitsmaßnahmen für E/E-Systeme

Die Gefährdungssituation ermittelt die Anzahl und Art der Sicherheitsmaßnahmen, die Steuergeräte benötigen um eine akzeptable Sicherheit zu ermöglichen. Sicherheitsmaßnahmen umfassen zum Beispiel eine Absicherung des Startvorgangs, oder die Absicherung der Kommunikation von Steuergeräte untereinander.

Als ersten Schritt bei der Gefährdungsanalyse werden die gefährdeten Komponenten (Assets) identifiziert. Grundsätzlich werden alle Komponenten betrachtet, die als Systemkomponenten relevant sind. Es gibt drei Kategorien von Komponenten, die von den ISO/IEC-Standards ISO/IEC 15408:2009 und ISO/IEC TR 15446:2009 vorgeschlagen werden:

  • Informationen: Diese Kategorie enthält Daten und Code. Ebenfalls umfasst diese Kategorie relevante Prüfprotokolle des Systems.
  • Funktionen: Diese Kategorie umfasst relevante Systemfunktionen, wie zum Beispiel Kommunikation, Datensuche, Datenanalyse, oder Datenspeicherung.
  • Physikalische Komponenten: Diese Kategorie umfasst Hardware, zum Beispiel Server, mobile Endgeräte, oder Steuergeräte. Dinge können auf verschiedenen Granularitätsebenen definiert werden. Zum Beispiel kann auch ein vollständiges Rechenzentrum als eine Komponente erfasst werden.

In einem zweiten Schritt werden Gefährdungsagenten identifiziert. Dieses Wissen ermöglicht es die Ressourcen die ein Angreifer verfügbar hat zu ermitteln. Ein Angreifer der nur einen Remote-Zugang zu einer Komponente hat kann keine Angriffe durchführen, die einen physischen Zugang zu diesem erfordern. Andererseits können Remote-Angriffe gleichzeitig auf eine Vielzahl von Komponenten durchgeführt werden, währen die Anzahl der Komponenten, die durch einen Angriff gefährdet sind der einen physischen Zugang erfordert deutlich geringer ist. Verschiedene Angreifer könnten unterschiedliche Motivationen haben um einen Angriff durchzuführen. Der Besitzer eines Fahrzeugs wird dieses nicht durch einen Angriff beschädigen, könnte jedoch versuchen zusätzliche Fähigkeiten zu aktivieren ohne diese zu erwerben. Konkurrierende Fahrzeughersteller könnten versuchen Intellectual Property, zum Beispiel Steuergerätecode, zu stehlen.

Wie in ISO/IEC 15408:2009 und ISO/IEC TR 15446:2009 beschrieben kann eine Gefährdung durch einen Tripel (Angreifer, Ding, Aktion) definiert werden. Eine Aktion wird von einem Angreifer an einem Ding durchgeführt um die Interessen eines Stakeholders negativ zu beeinflussen. Diese Aktionen können ebenfalls in Kategorien eingeteilt werden. Diese Kategorien sind hilfreich um bei der Gefährdungsanalyse fokussiert zu bleiben. Sie werden durch ISO/IEC TR 15446:2009 wie folgt vorgeschlagen:

  • Unerlaubter Zugriff (Abfragen, veröffentlichen, verändern, löschen)
  • Unerlaubte Änderung von Zugriffsprivilegien
  • Verhindern von legitimen Zugriffen, bspw. durch Denial of Service Angriffe
  • Verhindern von Dokumentation, bspw. das Vorspiegeln einer falschen Identität

Die Identifikation von unerlaubten Aktionen startet mit diesen Kategorien, werden dann jedoch abhängig vom Typ der untersuchten Komponente angepasst. Handelt es sich um eine physische Komponente, spricht man anstatt von Löschen von der Zerstörung der Komponente.

Verfolgbarkeitsmatrix

ISO/IEC 15408:2009 und ISO/IEC TR 15446:2009 definieren ein Sicherheitsstatement als den Willen einen Angriff abzuwehren, eine Sicherheitsrichtlinie zu erfüllen, oder um eine Sicherheitsannahme zu erfüllen. Eine Sicherheitsrichtlinie besteht aus Regeln und Prozessen die das System oder die Umgebung betreffen in der es eingesetzt wird. Eine Annahme wird im Sinne der Sicherheitsanalyse als gegeben betrachtet.

Wir nutzen eine TPAxO Matrix um Gefährdungen, Sicherheitsrichtlinien und Annahmen miteinander zu verbinden. Bild 1 zeigt eine beispielhafte Matrix. Zeilen enthalten die erkannten Gefährdungen (Threats), Sicherheitsrichtlinien (Policies) und Annahmen (Assumptions). Jedes Sicherheitsziel das notwendig ist um diese zu adressieren wird als Spalte hinzugefügt. In jeder Spalte werden die Zeilen markiert, die durch das Sicherheitsziel adressiert werden mit einem ‚x‘.

Die TPAxO Matrix definiert zwei Bereiche von Zeilen für Systemziele und für Umgebungsziele. Systemziele müssen in dem analysierten System realisiert werden; Umgebungsziele werden in der Umgebung realisiert. Diese Ziele umfassen zum Beispiel Einschränkungen beim physischen Zugang zu dem System. Annahmen umfassen immer Umgebungsziele, da diese Annahmen als gegeben vorausgesetzt werden. Es werden keine Prüfungen Aufwände realisiert um Annahmen zu realisieren oder deren Erfülltheit zu prüfen. Gefährdungen und Richtlinien werden durch System- oder Umgebungsziele abgedeckt.

Sicherheitskonzepte müssen Gefährdungen, Richtlinien oder Annahmen mit mindestens einem Sicherheitsziel adressieren. Ebenfalls muss jedes Ziel durch mindestens eine Gefährdung, Richtlinie oder Annahme motiviert werden. Daher muss in jeder Spalte und Zeile mindestens ein ‚x‘ markiert sein.

Virtueller Prototyp

Die Integration von Sicherheitsmaßnahmen in Systemkonzepte kann Auswirkungen auf zentrale Eigenschaften des Systems haben. Hierzu zählt zum Beispiel die Performanz oder die Erweiterbarkeit. Wir nutzen virtuelle Prototypen um Angriffe und Systemfunktionen simuliert um Auswirkungen von Sicherheitskonzepten auf die Eigenschaften des sich in der Entwicklung befindlichen Systems zu untersuchen. Virtuelle Prototypen integrieren Architekturkonzepte, Sicherheitskonzepte, Plattformmodelle und bestehende Funktionsimplementierungen in ein ausführbares Modell. Evaluierungsszenarien untersuchen ausgewählte Situationen und das Verhalten des Systems in diesen Situationen.

Im Rahmen einer Fallstudie haben wir einen virtuellen Prototyp erstellt um ein Sicherheitskonzept für die Inter-Steuergerätekommunikation zu testen. Gesendete Nachrichten werden mit Hilfe eines asymmetrischen Verfahrens verschlüsselt. Zusätzlich werden die übertragenen Nachrichten mit einer laufenden Nummer, sogenannten „Freshness Countern“ „gesalzen“ um Replay-Angriffe zu vermeiden. Bei dieser Art Angriff werden vorab aufgezeichnete und korrekt verschlüsselte Nachrichten abgespielt um das vom Angreifer gewünschte Systemverhalten zu erreichen. Kommunikationsteilnehmer tolerieren daher keine Nachrichten mit alten Freshness Countern. Zur Realisierung gibt es zwei Optionen:

  • Option 1: Ein eigener Freshness Counter pro Nachrichtentyp des Fahrzeugs
  • Option 2: Ein gemeinsamer Freshness Counter für alle Nachrichten des Fahrzeugs (globaler Freshness Counter)

Die erste Option benötigt eine große Anzahl von Nachrichtentypen. Die meisten Fahrzeugnetzwerke erfordern, dass jede Nachrichten-ID genau einem Sender zugeordnet wird. Da die Zuordnung von Funktionen die Nachrichten erzeugen zu Steuergeräten zwischen Fahrzeugtypen variieren kann, muss jeder Freshness Counter potentiell mit einem eigenen Nachrichtentyp synchronisiert werden. Dies erfordert eine große Anzahl zusätzlicher Nachrichtentypen. Dies ist wiederum problematisch, da die Anzahl von möglichen Nachrichtentypen durch die meisten Kommunikationssysteme begrenzt wird. Eine Performanzsimulation stellt sicher, dass die zusätzlich genutzten und potentiell von mehreren Steuergeräten gesendeten Nachrichten zur Re-Synchronisation der individuellen Freshness Counter nicht die akzeptablen Kommunikationsverzögerungen für Nutzdaten verletzen. Ebenfalls kann überprüft werden ob eine Re-synchronisation in einer akzeptablen Zeit durchgeführt werden kann, da sonst Nachrichten an Steuergeräte über einen langen Zeitraum nicht akzeptiert werden.

Option 2 erfordert, dass ein Steuergerät alle Nachrichten auf dem Fahrzeugbus empfängt um den globalen Freshness Counter zu pflegen. Ein Filtern von nicht genutzten Nachrichtentypen ist nicht möglich. Ebenfalls müssen signifikante Anstrengungen unternommen werden, wenn mehrere Busse in einem Fahrzeug genutzt werden. Dies ist die Regel in modernen Fahrzeugarchitekturen. Hier zeigt der virtuelle Prototyp Wechselwirkungen zwischen dem Sicherheitskonzept und dem Netzwerkprotokoll. Zum Beispiel definiert CAN ein Zugriffsverfahren, bei dem die Nachricht mit der höchsten Priorität zuerst übertragen wird. Nachrichten werden daher in einer anderen Reihenfolge gesendet, in der sie generiert werden. Dies hat Einfluss auf den Freshness-Counter, der Werte aus der Vergangenheit ausreichend lange akzeptieren muss, gleichzeitig aber auch Replay-Angriffe abwehren können muss.

Kongresstipp: ESE Kongress Jedes Jahr in der ersten Dezemberwoche findet in Sindelfingen mit dem Embedded Software Engineering Kongress Deutschlands Leitkongress für Embedded Software Enginneering statt. Das Progamm umfasst 100 Vorträge, Kompaktseminare und Rahmenprogramm an fünf Tagen. Im letzten Jahr kamen über 1200 Teilnehmer nach Sindelfingen. Der Kongress wird von einer Fachausstellung mit über 50 renommierten Firmen begleitet. Programm und Information.

Fazit

Schon bei relativ einfachen Sicherheitsmaßnahmen zeigen sich Wechselwirkungen mit Performanzanforderungen und Plattformen. Bei komplexeren Maßnahmen werden diese Wechselwirkungen komplexer. Virtuelle Prototypen können diese Wechselwirkungen schon frühzeitig, während der Architekturentwicklung prüfen und ermöglichen es Entwurfsentscheidungen abzusichern, bevor Komponenten realisiert werden.

* Thomas Kuhn ist Hauptabteilungsleiter Embedded Systems des Fraunhofer IESE in Kaiserslautern. Pablo Oliveira Antonino de Assis ist Department Head „Embedded Software Engineering” des Fraunhofer IESE in Kaiserslautern.

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45627554 / Safety & Security)