Vertrauen ist gut, Kontrolle ist besser Wenn Apps ins Fahrzeug kommen, dann stellen sich ganz neue Fragen in punkto Security (intrinsische Datensicherheit), denn die Safety (hier: Fahrsicherheit) darf nie beeinträchtigt werden. AUTOMOBIL-ELEKTRONIK zeigt, wie sich die SECURITY KONSEQUENT UMSETZEN lässt.

D ie heute zwölfjährigen sind die Autokäufer von morgen. Sie sind mit dem Internet aufgewachsen

und selbstverständlich permanent on-line. Für sie ist es alltäglich, Kontakt zu ihrem sozialen Netzwerk zu halten und sich die neusten Anwendungen aus Appstores aus dem Internet herunter zu laden. Um diesen Kunden von morgen attraktive Fahrzeuge anbieten zu kön-nen, wird das schnelle Nachladen von neuen und trendigen Applikationen zum Standardumfang der nächsten Fahrzeug-generationen gehören. Dabei wird die Attraktivität dieser Fahrzeuge noch zu-sätzlich gesteigert, indem die nachlad-baren Applikationen das Fahren beque-mer, ansprechender oder auch unterhalt-samer machen.

Welche Applikationen hier denkbar sind, hat der Wettbewerb „App my Ride“ von Volkswagen gezeigt, dessen Ergeb-nisse im Internet veröffentlicht sind. Da-bei wird bei der Analyse dieser Applika-tionen, die zum größten Teil auf das Fahr-erlebnis zielen, klar, dass hierfür eine Ver-

bindung dieser Applikationen zum Fahr-zeugbordnetz notwendig ist – zum Bei-spiel, um aktuelle Informationen über den Tankinhalt, Motordrehzahl, Ge-schwindigkeit etc. zu erhalten.

Beim Design dieser Funktionen kann daher nicht davon ausgegangen werden, dass keinerlei Verbindung zwischen den Internetservices beziehungsweise den Applikationen und den Safety-kritischen Teilen des Fahrzeugs wie etwa der Fahr-werkskontrolle besteht. Vielmehr wird es zwischen dem Steuergerät im Fahrzeug, auf dem die nachladbaren Applikationen ausgeführt werden, und dem Fahrzeug-bordnetz eine physikalische Verbindung geben, über die Daten zwischen dem Fahrzeug und dem Internet ausgetauscht werden (Bild 1).

Zugriff bösartiger Applikationen? Sofort stellt sich die Frage, wie der An-schluss des Internets an Fahrzeuge reali-siert werden kann, ohne die Sicherheit des Bordnetzes zu gefährden, denn es werden in Zukunft nicht nur Applikatio-

nen auf die Fahrzeuge zugreifen, die von den Fahrzeugherstellern selbst program-miert und getestet wurden. Im zuneh-menden Maße werden auch Applikatio-nen von Drittherstellern, die diese Appli-kationen nicht primär unter dem Fokus der Safety des Fahrzeugs entwickelt ha-ben, angeboten werden, um eine anspre-chende Funktionalität anzubieten.

In Zukunft könnten also fehlerhafte oder sogar bösartige Applikationen Zu-griff auf das Fahrzeug bekommen, wenn die Schnittstelle nicht sorgfältig abge-sichert wird. Was in so einem Fall passie-ren kann, wenn bösartiger Code dauer-haft Zugriff aufs Fahrzeugbordnetz er-hält, zeigen die empirischen Unter-suchungen einer amerikanischen For-schergruppe, der es gelungen ist, aktiv in die Fahrsicherheit des Fahrzeugs ein-zugreifen. Ihnen ist es zum Beispiel ge-lungen, ohne Einflussnahmemöglichkeit des Fahrers Räder einzeln abzubremsen. In realen Fahrsituationen könnte das ka-tastrophale Folgen für Leib und Leben der Passagiere des Fahrzeugs und die

SECURITY

32 AUTOMOBIL-ELEKTRONIK � Dezember 2010

Umgebung des Autos haben. Es zeigt sich also, dass neben der Wahl der richtigen Applikationen für die Automobilherstel-ler auch die richtige Vorsorge gegen An-griffe von Malware von essentieller Be-deutung ist. Es müssen Antworten gege-ben werden, wie die Ausweitung der An-griffsfläche eines Fahrzeugs, zum Beispiel durch Fernangriffe aus dem Internet, von den safety-kritischen Teilen des Bordnet-zes ferngehalten werden kann – und das vor dem Hintergrund, dass Ingenieure weniger Zeit zum Testen, als Angreifer zum Entwickeln einer Malware haben.

Diese Asymmetrie ist in der Regel ein Vorteil für die Angreifer: Sie haben mehr Zeit, eine einzige erfolgreiche Angriffs-möglichkeit zu finden, als die Entwick-lungsingenieure, um die Security des Systems zu generieren. Zum einen ist Se-curity nur eine von mehreren non-funk-tionalen Anforderungen, wobei die Funktionsentwicklung den größten Teil des jeweiligen Einzelaufwands bean-sprucht. Zum anderen werden die Fahr-zeug-Produktzyklen immer kürzer.

Gleichzeitig verlängert sich der Nut-zungszeitraum eines Fahrzeugs.

Risikoklassifizierung Der Zeitraum für die Entwicklung eines erfolgreichen Angriffs wird somit immer länger. Klassische Sicherheitsbewertun-gen sind an dieser Stelle problematisch, da neue Bedrohungen durch unbekann-te Applikationen nicht berücksichtigt werden können. Es bedarf daher einer vollständigen Risikoklassifizierung von Applikationen und Daten, die vor dem Einsatz im Fahrzeug festgelegt werden kann, um Fahrzeuge wirksam und dau-erhaft vor Malware, auch unbekannter, zu schützen.

Ein geeignetes Konzept zur Klassifika-tion von Anwendungen und Daten ist die Vertrauenswürdigkeit. Dabei reicht das Spektrum von keinem Vertrauen bis hin zu vollem Vertrauen. Um daraus für eine konkrete Anwendung effizient abzulei-ten, wie vertrauenswürdig diese ist, ist ei-ne Diskretisierung des oben genannten Vertrauensspektrums notwendig, die die

Bild 1: Zukünftige Anwendungen im Fahrzeug erfordern eine Verbindung des Autos mit dem Internet.

möglichen Schattierungen zwischen kei-nem und vollem Vertrauen durch eine begrenzte Anzahl von sogenannten Trustdomains ersetzt. Aus Sicht eines Fahrzeugherstellers können beispiels-weise drei Trustdomains gebildet werden (Bild 2). Geringes beziehungsweise kein Vertrauen haben unbekannte Applika-tionen oder unbekannte Dienste. Einge-schränktes Vertrauen genießen etwa Ap-plikationen von Drittherstellern oder der Zugriff durch bekannte Server, die aber nicht der Kontrolle des Fahrzeugherstel-lers unterliegen. Volles Vertrauen hin-gegen können zum Beispiel Infotain-mentanwendungen, die vom Fahrzeug-hersteller selbst oder von einem Tier-1-Zulieferer erstellt wurden, und die Bordnetzapplikationen selbst genießen.

Security-Mechanismen Auf Basis dieser Einteilung müssen die Security-Mechanismen für eine konkrete Umsetzung dieser Trustdomänen auf ei-ner Infotainment-Plattform im Fahrzeug nicht zur Abwehr einer spezifischen Be-

AUTOMOBIL-ELEKTRONIK � Dezember 2010 33

Bild 2: Klassifizierung von Anwendungen nach Vertrauenswürdigkeit.

SECURITY

Alle

Gra

fiken

: Sec

unet

drohung entwickelt werden. Es reicht aus, dies für die einzelnen Trustdomains zu tun. Hauptziel ist es dabei, eine Verlet-zung der Integrität des Fahrzeugbordnet-zes zu verhindern. In der daraus abgelei-teten Lösung von Secunet werden die einzelnen Trustdomains zunächst logisch streng voneinander getrennt. Durch eine Verankerung dieser Trennung in der Hardware der Infotainment-Plattform kann diese Trennung selbst nicht durch eine bösartige Anwendung aufgehoben werden. Dennoch ist es möglich, zwi-schen den einzelnen Trustdomains Nach-richten auszutauschen, wie es in Bild 2 dargestellt ist.

Dort ist eine kontrollierte Kommuni-kation von weniger vertrauenswürdigen Domänen in die nächst höhere erlaubt. Die Übertragung von Applikationen ist dabei nicht zulässig. Dies wird von einer Kontrollinstanz überprüft, die selbst dem Zugriff der Anwendungen in den einzel-nen Trustdomänen entzogen sind. In Bild 2 wird diese Kontrollinstanz durch eine Mauer symbolisiert.

Somit ist es im obigen Beispiel nicht möglich, dass in der Domäne einge-schränkten Vertrauens unbekannte Ap-plikationen zur Ausführung kommen. Während also Vertrauen gut für die Klas-sifizierung von Applikationen ist, ist Kontrolle besser für die Überwachung er-laubten Kommunikationsverhaltens zwischen den einzelnen Trustdomänen.

wie bereits erwähnt, die Nachricht nicht weitergeleitet. Darüber hinaus neutrali-siert die Kontrollinstanz die Applikation, von der das unerwünschte Verhalten ausgeht, und stellt neben der Integrität des Bordnetzes auch die Verfügbarkeit der Infotainment-Plattform sicher. Ein Angreifer kann so die Funktionen der In-fotainment-Plattform selbst nicht dauer-haft lahmlegen.

Fahrzeughersteller haben die Mög-lichkeit, ohne den Einsatz von Spezial-hardware und ohne Implementierung zusätzlicher Security-Funktionen, neue vernetzte Applikationen in ihren Fahr-zeugen auszurollen und schnell und fle-xibel auf die Anforderungen der Märkte zu reagieren. Sie müssen dabei keine Ab-striche bei der Security zu machen, da lo-kal gefährliches Verhalten, zum Beispiel durch einen herunter geladenen Virus durch die strikte Trennung der Trustdo-mains isoliert wird und die Safety des Bordnetzes nicht kompromittiert wird. Es gilt auch bei der Umsetzung von kom-plexen technischen Usecases: Vertrauen ist gut, Kontrolle ist besser.

Dr. Marc Lindlbauer ist Bereichsleiter Embed-ded Security und Automotive Security bei der Secunet Security Networks AG

Dabei fällt die Kontrollinstanz anhand ei-ner Policy die Entscheidung, ob Nach-richten in die nächste vertrauenswürdi-gere Trustdomäne weitergeleitet werden oder ob das Datum geblockt wird. Eine Policy für eine bestimmte Trustdomäne besteht dabei aus einem Satz von Ent-scheidungsregeln, die sich immer aus den Erfordernissen der nächst höheren Trust-domäne ableiten.

So bestimmt nicht etwa eine Anwen-dung eingeschränkten Vertrauens, wel-che Daten sie aus dem Bordnetz auslesen darf oder welche Informationen in das Bordnetz übertragen werden. Allein die im Bordnetz erlaubten Nachrichten, die zum Zeitpunkt der Übertragung die Safety des Fahrzeugs nicht beeinträchti-gen können, dienen als Grundlage für die Regeln der Policy, welche den Zugriff er-lauben.

Auch kann auf diese Weise kontrol-liert werden, ob personenbezogene Da-ten eines Fahrers, die im Fahrzeug selbst gespeichert werden, aus dem Bordnetz übertragen werden dürfen. Darunter würde zum Beispiel die aktuelle Position eines bestimmten Fahrzeugs fallen. Es wird sichergestellt, dass niemals uner-laubte Nachrichten übertragen werden und die Kontrollentscheidungen immer unabhängig von den Anwendungen der kontrollierten Trustdomäne sind. Falls die Kontrollinstanz ein solches uner-wünschtes Verhalten feststellt, so wird,

infoDIREC www.all-electronics.de Link zu Secunet 341AEL0610

34 AUTOMOBIL-ELEKTRONIK � Dezember 2010

SECURITY

V850-Mikrocontroller der 4. Generation: 74 neue ICs Renesas Electronics hat die vierte Generati-on seiner V850-Mikrocontroller-Serienfür Automobilanwendungen auf den Markt ge-bracht – und zwar in vier Produktserien: Die P-Serie für Chassis- und Sicherheitsanwen-dungen gemäß ASIL D/SIL3, die D-Serie für Armaturenbrett-Applikationen, die F-Serie für Karosserie-Anwendungen und die S-Se-rie für Kfz-Audiosysteme. Die Serienfer-tigung ist für das zweite Quartal des Ge-schäftsjahres 2011 geplant. Die mit dem 32-bit-CPU-Core V850E2 und 90-nm-Mo-nos-Flash ausgestatteten Mikrocontroller liefern eine Rechenleistung von 2,5 DMIPS/MHz, was einem Leistungsbereich von 48 MHz (120 MIPS), 80 MHz (200 MIPS) bis 160 MHz (400 MIPS) entspricht. Dabei ist jede Produktserie skalierbar in Bezug auf Spei-cherumfang, Peripherieelemente, Pinzahl und Leistung. Dies ermöglicht vollständige Soft- und Hardware-Kompatibilität inner-halb jeder Produktserie. Insbesondere ist ei-ne Software-Wiederverwendung auch zwi-schen den vier Produktserien gewährleistet,

da die gleichen Peripherieelemente jeweils über dieselben Register angesprochen wer-den. Für sämtliche Bausteine der vierten MCU-Generation sind vollständig verifizier-te Autosar-V3.0/3.1-MCAL-Softwaretreiber verfügbar. Um den Autosar-Anforderungen gerecht zu werden, ist in der neuen X4-Ge-neration eine neue SPF-Funktion (System Protection Functionality) implementiert, die aus einer Memory Protection Unit

infoDIRECT www.all-electronics.de Link zu Renesas 373AEL0610

(MPU), einer Peripheral Regis-ter Protection Unit (PPU), ei-ner System Register Protecti-on Unit (SRP) und einer Ti-ming Supervision Unit (TSU) zur Überwachung der CPU-Ausführungszeit beseht. Als Nachfolgeprodukt der be-kannten V850ES/Fx3 MCUs bieten die V850ES/Fx4 MCUs CPU-Taktraten von 48 bis 160 MHz sowie Flash-Speicher von 256 kB bis 4 MB in Gehäu-sen mit 64 bis 256 Pins. Zu-

sätzlich wurde ein erweiterter Satz an Peri-pheriefunktionen implementiert, ein-schließlich FlexRay, Ethernet, MOST sowie PWM-Generierung/Diagnose, ein Span-nungskomparator mit Hysterese und LIN-Master.