IoT Blog

IoT Conference | Build. Create. Connect … Things!
Internet of Things Conference | 13. - 16. März 2017, München
23
Nov

Connected Car: Wie sich Sicherheit, Design und Funktionalität kombinieren lassen

Sicherheit ist ein wichtiger Aspekt in der Welt der selbstfahrenden und vernetzten Automobile, denn die Nutzung solcher bedingt Vertrauen. Im Interview spricht IoT-Con-Speakerin Alissa Valentina Knight über die Sicherheitsprobleme von Connected Cars und wieso gerade die Kommunikation mit dem Backend-System so anfällig für Angriffe ist. Außerdem gibt sie einen Einblick, wie sich Sicherheit, Design und Funktionalität vereinen lassen.

Die Diskussion um selbstfahrende Autos ist schon seit einigen Jahren im Gange – worin siehst du die größten Herausforderungen für die Zukunft? Welchen Einfluss werden selbstfahrende Autos auf die gesamte Branche haben?

Alissa Knight: Ich sehe die größte Herausforderung darin, dass der durchschnittliche Kunde einem Auto das autonome Fahren zutrauen muss, wenn er mit seiner Familie darin sitzt. Kunden wünschen sich durchaus Konnektivität und Technologie, die Sicherheit der eigenen Familie hat aber immer oberste Priorität. Die erste Generation selbstfahrender Autos wird weiterhin Lenkrädern haben, mit denen menschliche Fahrer die Kontrolle übernehmen können. Die jüngsten Nachrichten in Betracht gezogen, ist aber fraglich, ob dafür vor einem Unfall überhaupt genug Zeit zum Eingreifen bleiben würde.

Eine weitere Herausforderung für die Automobilbranche liegt darin, dass verschiedene Stakeholder an der Herstellung eines Autos beteiligt sind. Was der Kunde nicht versteht, ist, dass TCUs und ECUs (Anm.: Getriebe- und Motorsteuergeräte) meist aus einem uneinheitlichen Teile-Gemisch von verschiedenen Herstellern bestehen. Wie kann die Automobilbranche ihre Produkte aber schützen, wenn eine lange Zuliefererkette zu Schwachstellen führen kann, von denen der Autohersteller selbst gar nichts weiß? Im Urteil der Öffentlichkeit wird die Schuld am Ende doch dem Autofabrikanten zugeschrieben, wenn ein Auto gehackt wird, nicht den Zulieferern der TCUs oder ECUs. Dazu muss man sich nur einmal die neusten Berichte über Jeep und andere Autohersteller ansehen. Wir diskutieren über die Automarke, nicht das Bauteil, wenn es um einen Hack geht.

Noch eine Schwierigkeit liegt in der wachsenden Zahl von ECUs, die Autos hinzugefügt werden, und der Einschränkungen der verfügbaren Bandbreite aufgrund alter Technologien wie CAN. Durch die vielen neuen telematischen Systeme werden immer größere Bandbreiten notwendig; neue ECUs in Autos erfordern eine immer höhere Daten-Durchflussrate, die von den gegenwärtigen Technologien nicht zur Verfügung gestellt werden kann.

Lass uns ein wenig über das Hacken von vernetzten Autos sprechen, vom Infotainment-System bis hin zu den Steuereinheiten: Kannst du die Schwachstellen kurz darstellen?

 

In der Kommunikationsinfrastruktur liegen die wunden Punkte der Technologie

Alissa Knight: Vernetzte Autos sind von einer Kommunikationsinfrastruktur mit der Außenwelt abhängig. Genau dort liegen die wunden Punkte der Technologie. Die meisten TCUs verfügen über eine Mobilfunkverbindung zur Kommunikation mit dem Backend, die prinzipiell allen Signalen vertraut, die von den Mobilfunkmasten oder der Basisstation kommen, über die sie ihre Daten beziehen. Genau daraus entsteht die Angreifbarkeit über Man-in-the-Middle-Attacken und die Gefahr für die Authentifizierung von Daten. Diese und andere Schwachstellen sind aus dem gegenwärtigen IPv4-Protocol-Standard bekannt.

VANNETS (Vehicle-to-Vehicle-Communication) bezeichnet eine Art von Ad-hoc-Netzwerken, die zwischen an einander vorbeifahrenden Fahrzeugen aufgebaut werden. So lassen sich relevante Daten zu gegenwärtigen Sicherheitsrisiken im Straßenverkehr und andere Informationen von einem Wagen auf den nächsten übertragen. Dazu werden Standard-WLAN-Technologien verwendet, die natürlich genau so angreifbar sind, wie WLAN-Technologien in traditionellen Computernetzwerken.

In den meisten Fällen, aber nicht allen, nutzen TCUs eine Verschlüsselung des Datentransfers zwischen dem Backend und ihnen selbst. Die Gültigkeitsdauer von Keys für diese OEMs muss aber diskutiert werden. In vielen unserer Tests haben wir Schwachstellen identifiziert, die auf symmetrischen Keys beruhen, die über 12 bis 24 Monate hinweg gültig bleiben.

In deiner Session hast du die These aufgestellt, dass Sicherheit nach Design und Funktionalität kommt. Wie meinst du das?

 

Es ist schwer, den Sicherheitsansprüchen der Nutzer in gleicher Weise gerecht zu werden, wie das bei Innovation und Konnektivität der Fall ist

Alissa Knight: Die Geschichte wiederholt sich bedauerlicherweise immer wieder. Wir haben in den vergangenen 15 bis 20 Jahren oft erlebt, dass Funktionen und Features entwickelt wurden, ohne über die Sicherheit nachzudenken. Da war beispielsweise der Fall eines Herstellers, der HTTP und nicht HTTPS für die Kommunikation verwendete, sodass das Auto angreifbar für Sniffing und Man-in-the-Middle-Attacken war. In anderen Tests haben wir festgestellt, dass keine Verschlüsselung für SMS-Nachrichten des Herstellers verwendet wurde, die Befehle an die TCU enthielten oder Informationen von der TCU an den Hersteller übermittelten. Man verließ sich ganz auf die Sicherheit des mobilen Netzes. Aus Sicherheitsperspektive ist es immer schwer, den Ansprüchen der Nutzer genauso gerecht zu werden, wie das bei Innovation und Konnektivität der Fall ist. In einem weiteren Test haben wir die fest einprogrammierten Dateinamen zum Import von Dateien als Schwachstelle identifiziert, über die das System so ausgetrickst werden konnte, dass sich eine Dateiversion mit Backdoor einschleusen ließ.

Wie lassen sich Sicherheit, Design und Funktionalität kombinieren?

Alissa Knight: Hier gelten die gleichen Sicherheitsprinzipien, die für die Entwicklung von Web-Anwendungen genutzt werden (OWASP TOP 10). ECU/TCU-Anwendungen sollten genauso abgesichert werden, wie Webanwendungen für klassische Server.

  • Man muss gewährleisten, dass die Sicherheit in den SDLC Process eingebunden ist.
  • Ingenieure und Entwickler müssen ein Training in sicherer Entwicklung bekommen.
  • Es müssen Code Reviews mit Sicherheitsfokus stattfinden.
  • Sicherheitsmodelle auf Layer-basis müssen genutzt werden.
  • Statische Code-Analysen der SCU und TCU-Anwendungen müssen stattfinden.
  • Vertrauen zwischen Systemteilen unterbinden – alle Übertragungen sollten authentifiziert werden müssen.

Das Global System for Mobile Communications, kurz GSM, ist ein Standard für Mobilfunknetze. Steht der Standard auch für andere Bereiche als der mobilen Telefonie bereit?

Alissa Knight: Bedauerlicherweise erlebt die Automobilindustrie gerade eine “Schwachstellenflut”: Es wurden viele Exploits des GSM bekannt, die sich zum Abfangen von Anrufen und SMS-Kurznachrichten und zur Erstellung kostenfreier mobiler GSM-Netzwerke eignen. Die gleichen Schwachstellen sind auch eine potentielle Schwachstelle vernetzter Autos, die GSM zur Kommunikation mit dem OEM verwenden. Autohersteller und OEMs müssen sich mit den Mobilfunkgesellschaften zusammensetzen, um diese Schwachstellen des GSM gemeinsam zu beheben. Dadurch kämen verschiedene Branchen zusammen, um sicherere Autos zu bauen. Es ist nicht alleine Aufgabe der Autohersteller, diese Probleme zu lösen. Es müssen auch Brücken zwischen den verschiedenen Branchen gebaut werden, um Risiken abzubauen.

Leave a Reply

BEHIND THE TRACKS 2017

 

IoT Trends & Business
Wissen für das Business von morgen

IoT Networking & Systems Architecture
Infrastructure & Architecture

Programming 
Softwareentwicklung für das IoT