Startseite > Automotive > Eine Security-Architektur muss her

Infineon Technologies

Eine Security-Architektur muss her

23. August 2018, 10:29 Uhr | Iris Stroh

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Hierarchische Systeme lassen sich leichter absichern

Laut Adlkofers Aussage setzen die meisten OEMs inzwischen auf eine zentrale T-Box; damit ist die erste Hierarchiestufe schon mal im Fahrzeug. Über welche technische Schnittstelle dann Software-Updates durchgeführt werden, ist prinzipiell egal. In jedem Fall muss im ersten Schritt überprüft und verifiziert werden, wer mit der T-Box kommuniziert. Adlkofer: »Mit der T-Box hat der OEM einen klar definierten Zugang und kann festlegen, wer mit wem kommunizieren darf. Dann ist der Kanal, über den die Kommunikation stattfindet, schon einmal gesichert.«

Oft gibt es von der T-Box eine 1:1-Verbindung zu einem Gateway, wobei Adlkofer hinzufügt, dass im Gegensatz zur T-Box deutlich weniger OEMs in der Vergangenheit die Absicherung des Gateways für notwendig hielten. Adlkofer: »Ohne entsprechende Schutzvorkehrungen am Gateway ist es leicht, das Fahrzeug zu übernehmen. In dem Moment, in dem die erste Firewall überwunden ist, haben die Hacker Zugriff auf alle Systeme.« Wobei die Gateway-Funktionen natürlich auch in der T-Box implementiert werden könnten, Hauptsache sie sind implementiert. Das Gateway übernimmt folgende Überprüfungen: Der Inhalt wird überprüft und die Autorisierung des Senders. Damit wird das Gateway zu der Instanz, die entscheidet, ob ein Software-Paket zur ECU A, B oder C übertragen wird. »Das können heute noch nicht alle Gateways, aber da müssen wir hin«, so Adlkofer weiter.

In der ECU findet dann die nächste Überprüfung statt, wobei hier verschiedene Ansätze möglich sind. Auf alle Fälle muss sichergestellt werden, dass die Software vom OEM kommt, sprich: die Signatur bzw. das Zertifikat muss überprüft werden. Darüber hinaus könnten aber auch Informationen übertragen werden, um welche Software-Variante es sich handelt, sodass die ECU weiß, ob diese Software-Variante überhaupt für sie zulässig ist. Adlkofer weiter: »Da kann der OEM viele Doppelchecks einbauen, um beispielsweise zu verhindern, dass, einfach gesagt, die Software für Modell A auf Modell B aufgespielt wird.«

Dabei stellt sich aber doch die Frage, warum die ECU die Signatur überhaupt noch einmal überprüfen muss. Denn es wurde ja bereits überprüft, ob der Inhalt und der Sender ok sind. Schon richtig, aber »dann geht man davon aus, dass in der Fahrzeugvernetzung alles ok ist. Aber ein Hacker könnte sich auch in eine Leitung im Netz einklinken und beispielsweise ein Software-Update blockieren, um so die Freigabe selbst zu erhalten, und dann einen Trojaner aufspielen«, so Adlkofer weiter.

Deshalb fordert Adlkofer abermals, jeder OEM muss sich überlegen, welche Angriffsfälle möglich sind. Wenn ein OEM sagen kann, dass es nur einen einzigen Zugang zum Fahrzeug gibt und dieser entsprechend abgesichert ist, dann kann er auch behaupten, genügend getan zu haben, um das System zu sichern. Wenn er aber sagen muss, dass es beispielsweise noch über eine andere Schnittstelle möglich ist, Zugriff auf das Fahrzeug zu bekommen, dann müssen weitere Sicherheitsmaßnahmen implementiert werden.

Wie Adlkofer oben bereits erwähnt hat, ist daher neben den Security-Komponenten vor allem das Security-Verständnis beim OEM entscheidend. Wer nicht weiß, welche Gefahren bestehen, kann sich auch nicht entsprechend dagegen schützen. Hinzu kommt noch, dass im Gegensatz zu ISO 26262 niemals ein Zustand erreicht werden kann, bei dem das Fahrzeug zu 100 Prozent sicher ist. Security ist im Vergleich zur Safety ein bewegliches Ziel, das sich im Laufe der Zeit ändert. Adlkofer: »Die gute Nachricht: Wir haben für die heutigen Probleme Lösungen. Die schlechte Nachricht: Das Rennen geht weiter.«