Schon 2009 erwähnte Manfred Broy, Professor für Informatik an der TU München, 70 bis 100, in der Oberklasse bis 120 Prozessoren und 100 Millionen Codezeilen pro Fahrzeug. Das zeugt von ausgefeilter Technik, aber es spricht auch für hohe Komplexität. Dabei stehen wir erst am Anfang der Intelligenz des Autos. Immer neue Funktionen und Assistenzsysteme kommen hinzu. Mit Macht drängt die Mobilfunkindustrie in die Automobilelektronik und bietet Konnektivität zwischen den Fahrzeugen sowie der Verkehrsinfrastruktur. Die EU-Kommission unterstützt sie dabei mit ihren Planungen zum eCall, der ab 2015 für alle Neuwagen einen automatischen Notruf aus dem Auto im Falle eines Verkehrsunfalls verlangt. Eine von der Industrievereinigung der GSM-Mobilfunkanbieter (GSMA) in Auftrag gegebene Studie spricht von einer Verdreifachung des Marktes für mobilfunkbasierte Services im Auto zwischen 2012 und 2018 auf 40 Milliarden Euro pro Jahr weltweit. Transparency Market Research stellt in seiner neuesten Studie zur Automobilindustrie 2012-2018 fest, dass elektronische Komponenten heute bereits 30 Prozent der Produktionskosten betragen, Tendenz steigend. Wenn sich nichts ändert, wird es voll unter der Motorhaube – und kompliziert.
Neue Konzepte in der Automobilindustrie
Die Automobilzulieferer stehen vor der Aufgabe, Platz zu schaffen für vielfältige neue Funktionen und Assistenzsysteme bis hin zum autonomen Fahren in einer heterogenen Verkehrslandschaft. Gleichzeitig müssen sie die Technik vorbereiten auf neue softwaregestützte Geschäftsmodelle wie Car-to-Go, Versicherungsprämien nach Nutzung und Fahrverhalten sowie für App-Stores für zusätzliche Funktionen im Auto, die dynamisch in der Werkstatt oder gar vom Nutzer selbst geladen werden können. Auch für sichere Update- und Upgrade-Konzepte über die Lebensdauer des Fahrzeugs hinweg und für vieles mehr, was heute vielleicht noch gar nicht bekannt oder gedacht ist, müssen sie Vorbereitungen treffen.
Der Automobilzulieferer Continental setzt auf die Reduzierung der Steuergeräte und ihre Eingliederung in eine zentrale Einheit im Cockpit, die vielfältige Funktionen auf einem Hypervisor und einer Multi-Core-Plattform zusammenfasst. Auf dieser Grundlage trennt die „Interior Domain Integration“ sichere von unsicheren und vertrauenswürdige von nicht vertrauenswürdigen Funktionen, die auf Basis heterogener Betriebssysteme, Programmierschnittstellen (APIs) und Laufzeitumgebungen (RTEs) laufen. Dabei weist das System ihnen zur Ausführung unterschiedliche Kerne der Multi-Core-Hardware zu (Bild 1).
Bild 1: Continental ordnet die Applikationen auf dem Hypervisor nach den Kriterien sicher/unsicher und vertrauenwürdig/nicht vetrauenswürdig.Sysgo
Auf der Hardwareseite kommt dabei ein leistungsfähiger ARM-Quad-Core-Prozessor zum Einsatz, und auf der Softwareseite basiert das System auf dem Hypervisor PikeOS.
Das Konzept einer integrierten Plattform ist nicht unbekannt. Es wurde bereits seit den 90er Jahren in der Avionik als „Integrated Modular Avionics (IMA)“ diskutiert und für die Boeing 777 sowie im Airbus A380 erstmals umgesetzt.
Ordnung schaffen im System: per Hypervisor
Was kann nun ein Hypervisor wie PikeOS zum neuen Konzept beitragen? Ein Hypervisor ist zunächst einmal nichts anderes als ein Computerprogramm, das virtuelle Maschinen bereitstellt, die Instanzen unterschiedlicher Gast-Betriebssysteme mit ihren jeweiligen Applikationen enthalten. PikeOS verfügt über Schnittstellen zu automobilspezifischen Betriebssystemen, die von Android für Multimediaanwendungen bis zu Autosar, PikeOS Native und Posix für echtzeitkritische Steuerungsaufgaben reichen. Das passt schon mal ganz gut zu den Anforderungen von Continental, mehrere Funktionen auf Basis unterschiedlicher Betriebssysteme, APIs und RTEs auf einer Plattform zu integrieren.
Bild 2: Beispiel einer PikeOS-Systemarchitektur für die Automobilelektronik.Sysgo
Ein Ziel der neuen Plattform von Continental ist damit erreicht: Mehrere Funktionen befinden sich auf einer Hardware und ersetzen eine Reihe zuvor physikalisch getrennter Steuergeräte (ECUs). Die Echtzeit- und Hypervisorqualitäten von PikeOS reichen jedoch noch nicht aus, die neue Plattform auch sicher zu betreiben.
Safety
Funktionale Sicherheit, der Schutz von Mensch und Umwelt vor Fehlern oder Versagen der Maschine, ist seit Langem ein Thema in der Automobilindustrie. Wo früher in erster Linie physikalische Probleme im Vordergrund standen, kommen heute Fragen der korrekten Ausführung von Software hinzu. 2011 wurde mit der ISO 26262 eine automobilspezifische Variante der IEC 61508 veröffentlicht, die heute als Standard für funktionale Sicherheit der Automobilelektronik gilt. Sie definiert ein Vorgehensmodell, Aktivitäten und anzuwendende Methoden bei der Entwicklung und Produktion von sicherheitsrelevanten elektrischen und elektronischen Systemen in Kraftfahrzeugen. Was heißt das für die integrierte Plattform von Continental? Welche zusätzlichen Qualitäten muss der Hypervisor PikeOS mitbringen?
Alle Anwendungen auf der Plattform müssen strikt voneinander getrennt werden, denn sie dürfen sich keinesfalls gegenseitig beeinträchtigen. Für diese Sicherheit sorgt der sogenannte Separation-Kernel. Seine Aufgabe besteht darin, eine Umgebung zu schaffen, die sich aus Sicht der einzelnen Applikation nicht von einem physikalisch verteilten System unterscheidet. Eingekapselt in eine virtuelle Maschine steht sie für sich allein und „sieht“ die anderen nicht. Sie nutzt ausschließlich die ihr vom Separation-Kernel explizit zugeteilten Hardwareressourcen wie Speicherbereiche, Ressourcen und Applikationssets und kommuniziert mit anderen Anwendungen über festgelegte Kanäle, die einen Informationsfluss nur zwischen bekannten und akzeptierten Instanzen zulassen.
Die Sicherheitsrisiken werden für jede Anwendung separat entsprechend der ISO 26262 eingestuft. Dabei unterscheidet man zwischen QM (kein Risiko) und ASIL A bis D (geringes bis hohes Risiko). Die Software jeder Anwendung wird anschließend separat nach dem jeweils festgestellten Risiko von unabhängigen Agenturen zertifiziert. Es ist einer der zentralen Vorteile der strikten Trennung aller Applikationen, dass sie eine separate Zertifizierung zulässt. Gäbe es sie nicht, müssten alle Anwendungen nach der höchsten Risikostufe zertifiziert werden, die auf der Plattform vorhanden ist.
Die integrierte Plattform von Continental hostet nun mehrere Anwendungen, deren funktionale Sicherheit von unkritisch bis sehr kritisch eingestuft ist. Der Separation-Kernel von PikeOS trennt sie so voneinander, dass sie sich gegenseitig nicht sehen und nicht beeinträchtigen. Alle Anwendungen sind entsprechend ihrer individuellen Kritikalität zertifiziert. PikeOS selbst muss diesen Sicherheitskriterien ebenfalls entsprechen. Das heterogene Gesamtsystem entspricht damit den Anforderungen der funktionalen Sicherheit nach ISO 26262. Wenn nun beispielsweise ein unkritisches Multimediasystem unter Android einen Fehler verursacht und abstürzt, wird dadurch ein hoch-priores kritisches Assistenzsystem nicht behindert, sondern läuft ohne Störung weiter.
Security
Ein weiteres großes Feld der Sicherheit der Automobilelektronik ist die Security oder Vertrauenswürdigkeit der Elektronik des Autos. Hier geht es um den Schutz des Systems vor den Menschen, das heißt vor feindlichen Angriffen und absichtlichen Manipulationen. Ein Fahrzeug verfügt nicht nur über vielfältige Assistenzsysteme, Komfortfunktionen und Multimediaanwendungen, sondern ist zukünftig auch in die Verkehrs- und Mobilfunkinfrastruktur eingebunden. Für viele dieser Anwendungen ist Android das bevorzugte Betriebssystem, insbesondere bei den Smartphones, die zukünftig eine wichtige Rolle in der Kommunikation des Fahrzeugs mit der Verkehrsinfrastruktur spielen sollen. Kasperskys Security Bulletin von 2013/2014 weist Android mit 98 Prozent als Hauptziel für Schadprogramm-Attacken aus. Daher werden für Applikationen im Auto auch die Regeln der IT-Security wichtig und müssen von dem darunterliegenden Hypervisor unterstützt werden.
Dafür gibt es seit Langem das Konzept der Multiple Independent Levels of Security, kurz MILS. Es stammt ursprünglich aus dem militärischen Bereich, wo man mit monolithischen Systemen für sichere Anwendungen scheiterte, weil sie wegen ihrer Größe und Komplexität nicht mehr zertifiziert werden konnten. Seit den 1990er Jahren kommt die MILS-Idee auch in der Avionik im Standard ARINC 653 zum Einsatz, um Hardware, System- und Anwendungssoftware voneinander zu trennen. Das MILS-Konzept ist domänenübergreifend in PikeOS implementiert. Im Rahmen des EU-Forschungsprojekts EURO-MILS wird PikeOS für eine Security-Zertifizierung nach Common Criteria für hohe Evaluation Assurance Level (EAL) vorbereitet.
Nach MILS werden Systeme in drei horizontale Ebenen mit unterschiedlichen Rechten und Stufen der Vertrauenswürdigkeit getrennt (Bild 3).
Bild 3: Die MILS Architektur unterscheidet drei Sicherheitszonen.Sysgo
Die unterste Ebene bildet die Hardware mit weiteren Plattform- und Security-Modulen. Auf Level 2 befindet sich der Separation-Kernel, der die gesamte Kommunikation im System kontrolliert und Rechenzeit sowie Speicherzugriffe an die einzelnen Anwendungen zuteilt. Nur er ist für Hardwarezugriffe privilegiert (Kernel Mode) und gilt hinsichtlich der Security als vertrauenswürdig (Trusted). Ebenfalls vertrauenswürdig, jedoch nicht für Hardwarezugriffe privilegiert sind alle weiteren Module der Systemsoftware der zweiten Ebene. Mit ihrer Hilfe wird das Gesamtsystem konfiguriert, organisiert und seine Funktionsfähigkeit überwacht. Alle Applikationen mit ihren APIs sind der dritten Ebene zugeordnet, die allesamt als nicht vertrauenswürdig (Untrusted) gelten und im User-Mode laufen.
Sicherheitsrichtlinien nach MILS
Das MILS-Konzept formuliert für den Separation-Kernel die konsequente und einheitliche Durchsetzung von Sicherheitsrichtlinien, um die Vertrauenswürdigkeit des Systems zu sichern und zu erhalten. Diese Sicherheitsrichtlinien des Separation-Kernels werden durch Sicherheitsfunktionen durchgesetzt, deren Implementierung auf ein absolutes Minimum reduziert ist, damit ihre Evaluierung und Zertifizierung möglich bleibt. Die Sicherheitsfunktionen umfassen unter anderem:
- Informationsfluss: Der Separation-Kernel muss den Informationsfluss zwischen Hardware, Systemsoftware und Applikationen ermöglichen und jederzeit kontrollieren;
- Datenisolierung: Der Separation-Kernel sorgt für eine Isolierung der Speicherbereiche und Ressourcen, die für die einzelnen Anwendungen vorgesehen sind;
- Säubern der CPU-Register: Der Separation-Kernel löscht alle Einträge in den CPU-Registern, bevor eine andere Anwendung die CPU nutzen darf;
- Schadensbegrenzung: Der Separation-Kernel begrenzt Fehlfunktionen einer Applikation auf ihre Partition. Alle anderen Applikationen, die Systemsoftware und der Separation-Kernel selbst werden nicht beeinträchtigt.
Aus diesen Sicherheitsfunktionen ergeben sich für den Separation-Kernel eine Reihe von Eigenschaften, die im Englischen mit der Formel NEAT sehr griffig zusammengefasst sind:
- Non-bypassable: Der Separation-Kernel muss die gesamte Kommunikation kontrollieren und darf unter keinen Umständen umgangen werden (können).
- Evaluatable: Die Sicherheitsfunktionen müssen einfach und der Umfang des Codes gering sein, damit sie bewertet und nach IT-Security-Standard Common Criteria oder nationalen Richtlinien formal verifiziert beziehungsweise zertifiziert werden können.
- Always Invoked: Die Sicherheitsfunktionen müssen immer aktiv sein.
- Tamperproof: Sicherheitsfunktionen dürfen unter keinen Umständen von bösartigem Code verändert werden, sodass Ressourcen wie zum Beispiel Buffer erschöpft werden und Fehler auslösen.
Nach Mobilfunk und Avionik wird die Automobilelektronik das nächste komplexe System sein, das in eine größere Infrastruktur eingebunden ist. Viele Fragen der damit verbundenen IT-Security, insbesondere der Datenschutz, sind noch nicht abschließend geregelt. Der Separation-Kernel von PikeOS stellt schon jetzt eine Sicherheitsarchitektur mit grundsätzlichen Funktionen zur Festlegung von Sicherheitsrichtlinien und Mechanismen zu ihrer Durchsetzung zur Verfügung, die auf zukünftige Standards und gesetzliche Regelungen angepasst werden können.
Die „Interior Domain Integration“ von Continental führt vielfältige, heterogene Funktionen auf einer ARM-Multi-Core-Hardware zusammen. Die Softwareplattform muss die damit einhergehenden Sicherheitsprobleme lösen.
Chris Berg
(av)
