Security Embedded-Software-Schutz auf mehreren Ebenen

Schutzmechanismus in den Embedded-Systemen.
Schutzmechanismus in den Embedded-Systemen.

Ein Schutzmechanismus aus mehreren Ebenen sorgt für die IT-Sicherheit, die vernetzte, sicherheitskritische Embedded-Systeme brauchen. Das funktioniert üblicherweise mit einem Hypervisor. Bei der Auswahl kommt es aber auf die Arbeitsweise des Hypervisor an.

Funktional sichere Embedded-Umgebungen sind heute immer öfter mit der Außenwelt verbunden. Das anhaltende Wachstum von Internet und IoT-Lösungen wird auch in absehbarer Zukunft die Anforderungen an funktional sichere Systeme weiter bestimmen und vorantreiben. Luftfahrt, Verteidigung, Automotive, Medizintechnik und industrielle Steuerungen sind nur einige vertikale Märkte, die dank des Internet und der Möglichkeit der Fernsteuerung von Geräten wachsen werden.

Die Vorzüge, sicherheitskritische Embedded-Geräte überwachen und steuern zu können, sind real greifbar. Von der Fernüberwachung und -steuerung sicherheitskritischer Geräte profitieren nicht nur militärische Anwendungen wie z.B. die Überwachung von Drohnen und gefährlichen Ladungen, sondern auch der private Konsument, indem beispielsweise mobile oder implantierbare Medizingeräte die persönliche Mobilität erhöhen und eine Fahrzeug-zu-Fahrzeug-Kommunikation die Sicherheit im Straßenverkehr verbessert. Um innovativ und wettbewerbsfähig zu bleiben, werden Gerätehersteller in ihren Angeboten zunehmend die Vernetzung ihrer sicherheitskritischen Geräte berücksichtigen müssen. Doch mit dieser Zunahme an miteinander verbundenen Geräten müssen sich Entwickler sicherheitskritischer Systeme zusätzlich zur funktionalen Sicherheit auch mit Fragen der Angriffssicherheit befassen.

Safety und Security gehören ­zusammen

Entwickler von sicherheitskritischer Embedded-Software dürfen den Bereich der Datensicherheit (Security) nicht länger als getrennt vom Bereich der funktionalen Sicherheit (Safety) sehen. Jedes System, das mit der Außenwelt verbunden ist, weist potenziell Sicherheitslücken auf. Die Verbindung zwischen Security und Safety erkennen auch sicherheitsbezogene Prozessstandards an. Angesichts der potenziellen Schwachstellen verlangen Standards wie IEC/EN 61508 (Prozesstechnik), ISO 26262 (Automotive), IEC/EN 62304 (Medizin), IEC 62278/EN 50128 (Bahntechnik) und DO-178 (Luftfahrt) nach bestimmten funktionalen Sicherheitsmaßnahmen. Jede dieser Normen stellt Anforderungen an die Identifizierung, Spezifizierung, Klassifizierung, den Entwurf, die Entwicklung und Verifikation einer Funktion, um konform zu den Systemsicherheitsanforderungen zu sein.

Bei den Sicherheitslücken in funktional sicheren Systemen handelt es sich nicht bloß um akademische Konzepte. Es gibt veröffentlichte Beispiele dafür, dass funktional sichere Systeme sich aufgrund von Designfehlern innerhalb der Systemsicherheit als anfällig erwiesen haben. 2011 wies Sicherheitsforscher Barnaby Jack die Möglichkeit nach, implantierbare Insulinpumpen drahtlos anzugreifen, und zeigte, wie diese Pumpe eine tödliche Dosis Insulin ausschütten kann. 2014 konnten Forscher der University of Michigan aufgrund einer Reihe von Designfehlern eine derzeit in den USA eingesetzte netzwerkfähige Ampelanlage übernehmen. In unserer heutigen Netzwelt sind Hacker – ob vor Ort oder am anderen Ende des Erdballs – eine potenzielle Bedrohung, wenn es um medizinische Geräte oder lokale Ampelsysteme geht.

Gefahr durch nachgerüstete ­Netzwerkanbindung

Wie sieht die Entwicklung eines sicherheitskritischen Embedded-Systems mit Netzwerküberwachung aus? Das gewöhnliche Vorgehen bestünde darin, einem eingebetteten Design mit Sensoren und Aktuatoren einfach Netzwerkfähigkeit hinzuzufügen. Der sicherheitskritische Teil wäre normalerweise eine Anwendung, der netzwerkfähige Teil eine andere. Beide Anwendungen würden dann unter Verwendung eines Mechanismus der Interprozess-Kommunikation koordiniert. Bild 1 zeigt grob, wie aus einer simplen Anwendung eine netzwerküberwachte sicherheitskritische Embedded-Anwendung werden kann.

Was die Sicherheit angeht, so sorgt bereits die Trennung des sicherheitskritischen Teils von der Netzwerkanbindung für eine gewisse Angriffssicherheit. Dennoch können Hacker ein an das Netzwerk angebundenes System über das Internet anpeilen und Schwachstellen in einer Anwendung, im TCP/IP Stack, in Gerätetreibern oder im Betriebssystem ausnutzen. Jedes hiervon kann Angreifern eine große Zielfläche bieten. Außerdem: Gelangt ein Angreifer über das Netzwerk erst einmal ins System, ist das Gesamtsystem potenziell gefährdet. Typische Mikrokernel-Architekturen, die Anwendungen für ausführbare Single-Binary-Dateien mit dem Kernel verbinden, weisen keinen Schutzwall zwischen Nutzeranwendung und Kernel-Bereich auf. Ist ein Hacker erst einmal in das System eingedrungen, ist alles gefährdet und ausbeutbar.

Schutz durch mehrschichtige Software

Ein Ansatz aus mehreren Software-Schichten ist eine pragmatische Weise, an Sicherheitsfragen heranzugehen. Sicherheitskritische Embedded-Systeme verlangen jedoch auch ein deterministisches Echtzeit-Verhalten. Determinismus bedeutet Vorhersagbarkeit der Reaktionszeit. Hält ein System seine zugewiesene Reaktionszeit nicht ein, ist es nicht mehr deterministisch. Beim Layered-Software-Ansatz ist es daher wichtig sicherzustellen, dass das deterministische Verhalten aufrechterhalten und die Angriffssicherheit verbessert wird. Die Auswahl der falschen Software-Schicht kann gleichermaßen Determinismus und Sicherheit beeinträchtigen.

Beim mehrschichtigen Software-Ansatz für funktional sichere Embedded-Systeme sorgen Hypervisoren für noch mehr Sicherheit. Ihre Hardware-Isolierung und -Virtualisierung trennt die sicherheitskritischen Funktionen vom restlichen System und schützt es so vor Bedrohungen. Man unterscheidet typischerweise Typ-2-, Typ-1- und Typ-0-Hypervisoren. Der Typ-2-Hypervisor sitzt auf dem Betriebssystem (OS) und virtualisiert andere Betriebssysteme, die dadurch auf dem Host-Betriebssystem aufbauend eingerichtet werden können. Der Typ-1-Hypervisor verwendet ein virtualisiertes Hilfs-Betriebssystem, das direkt auf die Hardware zugreift. Das Hilfsbetriebssystem für einen Typ-1-Hypervisor ist so nicht sichtbar, weist aber dennoch einen dynamischen Speichermanager, ein Prozessmodell, einen dynamischen Scheduler, ein Dateisystem, Netzwerk-Stack, Gerätetreiber, System-API, Anwendungs-ABI, usw. auf – genauso wie das Host-Betriebssystem des Typ-2-Hypervisors. Musterbeispiele für Typ 2 und Typ 1 sind die typischen Desktop-Hypervisoren. Der Typ-0-Hypervisor wird auf der blanken Hardware installiert (‚bare metal‘). Doch im Unterschied zu Typ 1 benötigt er kein Hilfs-OS. Ein Least Privilege Separation Kernel ist solch ein Typ-0-Hypervisor. Er teilt die Ressourcen eines Systems zwischen den Gastbetriebssystemen erst effizient auf und kontrolliert dann streng die Datenströme zwischen ihnen. Das Hauptaugenmerk bei seiner Entwicklung liegt auf (Angriffs-)Sicherheit bei minimaler Auswirkung auf die Performance. Bild 2 zeigt die drei Hypervisor-Typen.