Startseite > Automotive > Elektromobilität > Elektrofahrzeuge vor Manipulationen von außen schützen

Auf den sicheren Code kommt es an

Elektrofahrzeuge vor Manipulationen von außen schützen

28. Oktober 2019, 13:25 Uhr | Von Mark Pitchford

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Sicheren Applikations-Code entwickeln

Zur Verdeutlichung dieses Prinzips ist es sinnvoll, sich auf zwei Beispiele zu konzentrieren, die Separation unterschiedlicher Bereich und die Anwendung sicherer Codierpraktiken.

Bereichsseparation und Hochrisikobereiche

Es ist nicht praktikabel, die Sicherheit in sämtlichen Teilen aller Systeme zu maximieren, besonders wenn zum Beispiel ein Linux-basiertes Betriebssystem einer Head Unit im Spiel ist, mit einem enormen Umfang sowie Software unbekannter Herkunft. Pragmatischer ist es dagegen, die Aufmerksamkeit gezielt auf die besonders gefährdeten Bestandteile des Systems zu richten, wie es der »Threat Analysis and Risk Assessment«-Prozess der Norm SAE J3061 skizziert. Einige Beispiele für solche Hochrisikobereiche sind:

Dateien von außerhalb des Netzwerks
Abwärtskompatible Schnittstellen zu anderen Systemen, wie etwa alte Protokolle, alter Code und alte Bibliotheken, deren Pflege und Test in verschiedenen Versionen sich schwierig gestaltet
Individuelle APIs, deren Design und Implementierung Fehler beinhalten kann
Security-Code, darunter alles, was mit Kryptografie, Authentifizierung, Autorisierung (Zugangskontrolle) und Sitzungsmanagement zu tun hat.

Betrachtet man das Prinzip im Vergleich zu einem System, in dem die Technik der Bereichsseparation angewandt wird – in diesem Fall mit einem Separations-Kernel oder Hypervisor (Bild 1) –, dann sieht man, dass es nicht schwierig ist, in diesem Szenario Hochrisikobereiche auszumachen.

Jobangebote+ passend zum Thema

Regional Key Account (m/w/d) für Elektronische Bauteile

KOA Europe GmbH, Dägeling

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Ein Beispiel ist die Gateway-Virtual-Machine (VM). Wie sicher sind ihre Verschlüsselungsalgorithmen? Wie gründlich validiert sie die aus der Cloud kommenden Daten? Wie gut validiert sie Daten, die an die verschiedenen Bereiche übermittelt werden?

Hinzu kommen die Daten-Endpunkte (Bild 2). Ist es möglich, aggressive Daten einzu-schleusen? Wie ist der Applikations-Code konfiguriert, um das sicher zu verhindern?

Eine weitere potenzielle Schwachstelle resultiert daraus, dass viele Systeme bereichsübergreifend kommunizieren müssen. Ein Beispiel ist die Zentralverriegelung, die eigentlich einem relativ unkritischen Bereich angehört. Allerdings kommt es zum Beispiel in einer Notsituation nach einem Unfall darauf an, dass die Türen entriegelt werden – und das erfordert die Kommunikation mit einem sicherheitskritischen Bereich. Wie immer man eine solche Kommunikation zwischen verschiedenen virtuellen Maschinen auch gestaltet, es ist zwingend erforderlich, dass die Implementierung sicher ist.

Nachdem diese mit einem hohen Risiko behafteten Software-Komponenten identifiziert sind, kann die Aufmerksamkeit auf den damit zusammenhängenden Code gerichtet werden. Das Resultat ist ein System, in dem der sichere Code nicht nur als eine zusätzliche Verteidigungslinie fungiert, sondern aktiv zur Effizienz der zugrunde liegenden Architektur beiträgt, indem ihre Schwachpunkte gestärkt werden. Damit die Sicherheit dieses Applikations-Codes optimiert werden kann, sind die kombinierten Beiträge einer ganzen Reihe von Faktoren erforderlich, die den vielfältigen Security-Ansatz des Systems als Ganzes widerspiegeln.

Sichere Codierpraktiken

Die Computer-Emergency-Readiness-Team-Abteilung (CERT) des Software Engineering Institute (SEI) hat insgesamt zwölf sichere Codierpraktiken angeführt, die in dem Code des in Bild 1 skizzierten Automobilsystems alle eine Rolle spielen. Dazu diese Beispiele:

Praktikern wird empfohlen, eine »Software-Architektur zu schaffen und ihre Software so zu entwickeln, dass Security-Konventionen implementiert und durchgesetzt werden«. Die Norm ISO 26262 verlangt, dass Anforderungen spezifiziert werden und dass für eine bidirektionale Rückverfolgbarkeit zwischen diesen Anforderungen, den Software-Design-Artefakten, dem Quell-Code und den Tests gesorgt wird. Die SAE J3061 schlägt ergänzend vor, diese Prinzipien abgesehen von den Safety-Anforderungen auch auf Security-Anforderungen anzuwenden. Werkzeuge können dabei helfen, den administrativen Aufwand im Zusammenhang mit dieser Rückverfolgbarkeit zu entschärfen (Bild 3).

Sichere Codierpraktiken, Bilder 3-5

Alle Bilder anzeigen (3)

Viele Entwickler neigen dazu, sich bei der Entwicklung nur um Compiler-Fehler zu kümmern und Warnungen zu ignorieren. Die Warnungen sollten auf die höchste verfügbare Stufe eingestellt werden, und alle sollten beachtet werden. Statische Analysewerkzeuge (Bild 4) sind dafür vorgesehen, zusätzliche, subtilere Probleme zu identifizieren.
Das Code-Design sollte so einfach und klein wie möglich gehalten werden. Es gibt zahlreiche Komplexitätsmetriken, die den Entwicklern bei der Evaluierung ihres Codes helfen können. Automatisierte statische Analysewerkzeuge (Bild 5) leisten dabei Hilfestellung, indem sie diese Metriken automatisch evaluieren.

Es sollte ein sicherer Codierstandard angewandt werden. CERT C und MISRA C:2012 sind zwei Beispiele für solche Standards – abweichend von der gängigen Fehleinschätzung, dass der letztere Standard nur für Safety-relevante Entwicklungen ausgelegt ist. Zusätzlich gestärkt wurde seine Eignung als sicherer Codierstandard durch die Einführung von MISRA C:2012 Amendment 1 mit den darin enthaltenen 14 zusätzlichen Richtlinien sowie durch deren kürzliche Einbindung in MISRA C:2012 (3. Edition, 1. Revision).

Ausblick

Kein vernetztes Automobilsystem wird jemals sowohl nützlich als auch absolut unangreifbar sein. Es ist sinnvoll, das jeweilige System proportional zu dem Risiko abzusichern, das im Fall seiner Kompromittierung droht. Das wiederum verlangt nach der Anwendung mehrerer Schutzebenen, damit beim Ausfall einer Ebene die anderen weiterhin zur Verfügung stehen. Weil die speziellen Systeme von Elektrofahrzeugen besonders verwundbar sein können, sollte ihnen besondere Beachtung geschenkt werden.

Die Separation der einzelnen Bereiche sowie die Verwendung von sicherem Applikations-Code sind zwei Beispiele für derartige Verteidigungslinien. Der Aufwand, der zur Realisierung eines hinreichend sicheren Systems getrieben werden muss, lässt sich optimieren, indem man die besonders risikobehafteten Elemente der Architektur identifiziert und bei der Entwicklung des Applikations-Codes, der mit diesen Elementen in Zusammenhang steht, sichere Codiertechniken anwendet.

Elektrofahrzeuge sind, wie das Beispiel Tesla gezeigt hat, gegen böswillige Zeitgenossen ebenso anfällig wie Fahrzeuge mit Verbrennungsmotor. Effektive Abwehrmaßnahmen gegen solche Akteure haben höchste Priorität, wenn der Trend zur vermehrten Verbreitung von Elektrofahrzeugen nicht durch potenzielle Sicherheitsrisiken ausgebremst werden soll.

Der Autor

Mark Pitchford

erwarb seinen Abschluss als Bachelor of Science an der Trent University, Nottingham, und ist seit mehr als 20 Jahren Diplomingenieur. Von 2007 bis 2014 arbeitete er als FAE bei LDRA. Im Anschluss wechselte er als Technical Manager für den Bereich EMEA zu Lynx Software Technologies, bevor er im Februar 2017 zu LDRA zurückkehrte. Dort ist Pitchford als Technical Specialist tätig.