Professional Articles

Herausforderungen

Schon heute sind viele Funktionen in Automobilen vollständig oder teilweise automatisiert; Fahrerassistenzsysteme wie Abstandswarner, Rückfahrkameras oder Einparkhilfen finden Zugang in die Serienproduktion selbst kleiner und mittlerer Fahrzeuge. Komplett autonom fahrende PKW, Busse und auch LKW sind auf öffentlichen Straßen im Testbetrieb; erste Serienfahrzeuge können sich zumindest teilautonom bewegen. Das Auto der Zukunft wird noch mehr Elektronik und Rechenleistung benötigen – einerseits, um die Sicherheit zu erhöhen (Fahrerassistenzsysteme) und andererseits, um den Anforderungen der Passagiere nach Komfort, Unterhaltung und Kommunikation zu entsprechen. Das Internet of Things, das Geräten innerhalb des Fahrzeugs die dafür notwendige Konnektivität verleiht, bringt dabei erhebliche neue Herausforderungen an die Sicherheit mit sich. Sicherheitsaspekte bestimmen daher zunehmend das Software-Design, und Zertifizierungsstandards werden im Automobilbau bald eine ähnlich wichtige Rolle spielen wie heute in der Flugzeugindustrie. Neben der funktionalen Sicherheit (Safety) treten dabei auch Aspekte der IT-Sicherheit (Security) und des Datenschutzes in den Vordergrund.

Safety und Security

Safety befasst sich mit der funktionalen Sicherheit und damit der Vermeidung von Systemausfällen, die zu Gesundheitsschäden und zu Beeinträchtigungen der Umwelt führen können. Mit der IEC 61508 gibt es hier eine branchenunabhängige Basisnorm für die funktionale Sicherheit elektrischer, elektronischer und programmierbarer Systeme mit Sicherheitsbezug. IEC 61508 unterscheidet zwischen vier Kritikalitätsstufen, SIL-4 bis SIL-1 (Safety Integrity Level). Aufbauend auf dieser Norm definiert ISO 26262 speziell die Anforderungen an die funktionale Sicherheit für Fahrzeuge im Straßenverkehr. Angelehnt die Sicherheitsintegritätslevel der EN 61508 und abhängig von der tolerierbaren Ausfallhäufigkeit definiert sie vier ASIL-Level D-A, wobei D für die kritischsten Systeme steht (Abbildung 1).

Abbildung 1: Je nach Funktion sind unterschiedliche ASIL-Level erforderlich. D ist der stringenteste

Bei der IT-Sicherheit geht es dabei vor allem darum, kritische Systeme vor unerlaubten Zugriffen zu schützen und damit vor Manipulation, aber auch vor dem unbefugten Zugriff auf personenbezogene Daten. Auch in der Security gibt es internationale Standards für sicherheitskritische Systeme. Der weltweit wichtigste ist die ISO 15408, besser bekannt als CC oder Common Criteria (for information technology security evaluation) für die Prüfung und Bewertung der Sicherheitseigenschaften von IT-Produkten. Er führt sieben Evaluation Assurance Levels (EAL 1-7) für die Vertrauenswürdigkeit ein. Im Bereich der Automobilindustrie arbeitet die SAE (ehemals Society of Automotive Engineers) derzeit an einer Reihe von Standards zu unterschiedlichen Aspekten von IT-Systemen in Automobilen und führt dabei im 2016 veröffentlichten Draft J3061 angelehnt an die Safety Integrity Levels auch den Begriff ACsIL (Automotive Cybersecurity Integrity Level) ein. In der ISO wird zudem an der ISO 21434 (Road Vehicles - Cybersecurity Engineering) gearbeitet. Es steht zu erwarten, dass nach Verabschiedung dieser Standards für viele Produkte auch eine entsprechende Zertifizierung erforderlich werden wird. Schon heute besitzen einige Produkte eine Zertifizierung nach Common Criteria. Dies bedeutet jedoch nicht automatisch, dass sie deswegen sicher sind - es muss auf jeden Fall detailliert darauf geachtet werden, was hier genau zertifiziert wurde.

Safety und Security lassen sich am einfachsten gewährleisten, wenn sämtliche IT-Systeme strikt voneinander getrennt sind und sich daher nicht gegenseitig beeinflussen können. Doch heute werden in Fahrzeugen immer mehr sicherheitskritische und unkritische Anwendungen betrieben, und um Kosten und Gewicht zu sparen, dient eine Hardware als Plattform für unterschiedlichste Funktionen auch verschiedener Kritikalitätsstufen. Dieser Trend birgt erhebliche Risiken. Erhält beispielsweise ein Angreifer Zugriff auf ein vergleichsweise unsicheres Entertainment-System auf Basis von Android und kann er über dieses Einfallstor auch auf sicherheitskritische Systeme zugreifen, hat das unter Umständen sehr gravierende Konsequenzen. Es ist daher unabdingbar, Anwendungen mit unterschiedlichen Kritikalitäts-Levels strikt voneinander zu trennen, auch wenn sie auf der gleichen Hardware laufen. Hier kann die Automobilindustrie von den Erfahrungen in der Luft- und Raumfahrt mit ihren extremen Anforderungen profitieren, in der sich bereits Hypervisor-basierte Lösungen durchgesetzt haben.

Mehrere Partitionen statt multipler CPUs

Ein Hypervisor kann auf einem Controller unterschiedliche Funktionen in mehreren Partitionen hosten, die bisher separate CPUs erforderten. Allerdings muss dabei absolut sichergestellt werden, dass die Software, die die Hypervisor-Funktionalität zur Verfügung stellt, tatsächlich eine strikte Trennung zwischen den Partitionen garantiert. Ansonsten hat man zwar eine einheitliche Hardware-Plattform, aber möglicherweise Interaktionen zwischen kritischen und nicht kritischen Anwendungen wie etwa Audiosystem und Bremsen. Eine Zertifizierung nach ASIL-D und ISO 26262 gibt hier die Sicherheit, dass Funktionen in unterschiedlichen Partitionen tatsächlich so voneinander getrennt sind, als liefen sie auf unterschiedlichen CPUs.

Insbesondere auf Multicore-Systemen ist der Einsatz von Hypervisoren grundsätzlich eine geeignete Möglichkeit, den Herausforderungen beim System-Design zu begegnen. Primär werden solche CPUs zwar aus Performance-Gründen verwendet, doch sie können auch die verlangte Trennung einzelner Funktionen unterstützen. Allerdings ist die Zertifizierung von Multicore-Systemen sehr komplex, und viele zertifizierte Systeme nutzen tatsächlich nur einen Kern. Werden allerdings unterschiedliche Funktionen in einer einzelnen Software gebündelt, die unter einem Echtzeit-Betriebssystem auf nur einem CPU-Kern läuft, können sehr leicht Interferenzen zwischen den Funktionen auftreten – die strikte Trennung ist nicht gewährleistet. Beispielsweise kann die Auswirkung einer Anwendung auf das Laufzeitverhalten einer anderen Anwendung zu Sicherheitsproblemen führen, etwa das Überschreiten von Fristen bei Echtzeitanwendungen. Auf ähnliche Weise können Timing-Effekte aufgrund der gemeinsamen Nutzung der Systemressourcen, wie z.B. Caches und Speicherbusse, zu verborgenen Informationskanälen führen, die gegen die Vertraulichkeitsanforderungen der Anwendung verstoßen. Diese potentiellen Probleme rühren vor allem daher, dass die meisten Hypervisoren nachträglich einem RTOS (Real Time Operating System) zugefügt werden, das vom eigenen Design her eine solche Trennung nicht unterstützt. Gerade in sicherheitskritischen Anwendungen ist es aber wichtig, dass bereits das RTOS speziell für die getrennte Ausführung unterschiedlicher Funktionen ausgelegt ist, es also vom Design her eher ein Separation Kernel ist denn ein simples RTOS.

Räumliche und zeitliche Trennung

Ein solcher Separation Kernel ermöglicht die räumliche und zeitliche Trennung zwischen Anwendungen und stellt die Partitionen für die Ausführung von Benutzeranwendungen bereit. Die zeitliche Trennung erfolgt dabei durch Zeitpartitionierung, bei der die CPU-Zeit während der Konfiguration in Zeitpartitionen aufgeteilt wird. Räumliche Trennung erfolgt durch Ressourcenpartitionierung, bei der die Systemressourcen wie Hauptspeicher, Dateien, Geräte, sichere Kommunikationskanäle und Kerne partitioniert und Containern, den so genannten Ressourcenpartitionen, statisch zugewiesen werden. Benutzeranwendungen werden dabei im Kontext einer Ressourcenpartition ausgeführt.

Ein Beispiel für eine Softwareumgebung mit strikter Trennung von Anwendungen ist PikeOS von SYSGO, das sich bereits in der Flugzeugindustrie bewährt hat. PikeOS bietet sowohl ein volles Echtzeit-Betriebssystem (Hard RTOS) als auch ein Virtualisierungs- und Partitionierungssystem, um die besonderen Anforderungen von Anwendungen in der Automobilindustrie zu unterstützen (Abbildung 2).

Figure 2: Der Separation Kernel von PikeOS sorgt für eine sichere Trennung der verschiedenen Partitionen

Die Basis der PikeOS-Plattform ist ein kleiner Microkernel, der eine Virtualisierungs-Infrastruktur zur Verfügung stellt. Damit ist es möglich, verschiedene Anwendungen und Ressourcen in sicheren, individuellen Partitionen zu platzieren. Diese können in den verschiedensten Umgebungen laufen - von POSIX über Linux und Android bis AUTOSAR oder GENIVI (Abbildung 3). Dank der integrierten Zeit-Partitionierung ist es dabei unerheblich, ob es sich um Echtzeit-Applikationen handelt oder nicht. Der Separation Kernel von PikeOS 4.2.2 ist derzeit weltweit der einzige, der eine Zertifizierung nach Common Criteria EAL 3+ besitzt (für die verbreiteten Plattformen X86_64, ARMv7 und ARMv8).

Figure 3: PikeOS in an automotive application based on the Renesas R-Car H3

Gerade in gemischten Umgebungen mit relativ schlecht gesicherten Betriebssystemen wie Android und kritischen Umgebungen wie AUTOSAR kann ein Separation Kernel auch eine wichtige Sicherheitsfunktion erfüllen, um Angriffe zu erschweren. Dieser Kernel, der als Hypervisor für die unterschiedlichen Gastbetriebssysteme agiert, ist in der Lage, privilegierte Systemaufrufe der Gastsysteme abzufangen und zunächst auf die erforderlichen Berechtigungen zu prüfen, bevor sie tatsächlich ausgeführt werden. Während übliche Desktop-Betriebssysteme alle Gerätetreiber im Kernel integriert haben, kann man so eine Umgebung schaffen, in der nur ein sehr kleines Set von Diensten im „Priviledged Mode“ im Kernel abläuft – etwa Scheduling, Context Switching, Prozesskommunikation und -synchronisation und Interrupt-Handling. Gerätetreiber werden dann ohne Privilegien im ganz normalen User-Modus ausgeführt wie jeder andere Anwendungscode. Auf diese Weise wird die Angriffsfläche des gesamten Systems deutlich reduziert.

Sicherheit und Zertifizierung

Der PikeOS Hypervisor selbst ist nach höchsten Industriestandards zertifiziert und damit eine geeignete Grundlage für kritische Systeme, in denen sowohl funktionale Sicherheit als auch IT-Sicherheit gewährleistet sein müssen. Die Schutzmechanismen basieren dabei im Wesentlichen auf zwei Grundsätzen strikte Trennung der Anwendungen durch Zeit- und Ressourcen-Partitionierung sowie Steuerung der Kommunikations-Kanäle. Die einzelnen Anwendungen innerhalb des Gesamtsystems können dabei unterschiedliche Kritikalitäts-Level besitzen.

Aufgrund dieser Schutzmechanismen von PikeOS kann die Zertifizierung nach branchenspezifischen Safety- und Security-Standards für jede Anwendung separat durchgeführt werden - ein wesentliches Merkmal, um die Kosten unter Kontrolle zu halten. Zudem war PikeOS die erste Plattform, die auch eine SIL 4-Zertifizierung in Multicore-Umgebungen erhielt.

Um die Anforderungen der ISO 26262 zu erfüllen, wird PikeOS optional mit einem Automotive Certification Kit angeboten, in das die langjährige und umfassende Zertifizierungs-Expertise von SYSGO eingeflossen ist. Das Zertifizierungskit enthält einen ISO 26262 Teil 6 konformen PikeOS Hypervisor sowie umfassende Dokumentationshilfen für Entwicklung und Test. Weiterhin können zusätzliche Sicherheitsinformationen bereitgestellt werden, um ISO 26262-konforme Systeme zu erreichen. Wichtige Bestandteile dieser Zertifizierungskits sind ein Sicherheitshandbuch mit Richtlinien für die Verwendung von PikeOS in sicherheitskritischen Designs von Systemen, sowie eine Fallstudie mit charakteristischen funktionalen Sicherheitsanforderungen entsprechend der jeweils erforderlichen Automotive Safety Integrity Levels (ASIL).

Mehr Informationen unter www.sysgo.com/pikeos