Security
Embedded-Software-Schutz auf mehreren Ebenen
Fortsetzung des Artikels von Teil 1
Isolation durch Hypervisor
Ein Hypervisor kann dazu benutzt werden, zwei unterschiedliche Funktionen zu separieren – den sicherheitskritischen Aspekt und die Netzwerkanbindung. Ein Gast in Form einer virtuellen Maschine (VM-Gast) stellt das sicherheitskritische System dar, der andere VM-Gast sorgt für die Fähigkeit zur Fernüberwachung. Ein Datenkanal dient der Kommunikation der beiden VMs untereinander. Das sicherheitskritische System braucht seinen TCP/IP Stack dann nicht mehr, was zum einen eine große Angriffsoberfläche beseitigt und gleichzeitig auch sein Systemdesign vereinfacht. Bild 3 veranschaulicht, wie solch ein Design unter Einsatz der drei verschiedenen Hypervisor-Typen aussehen könnte.
Jobangebote+ passend zum Thema
Typ-2-Hypervisor: So sicher wie das Host-System
In diesem Szenario ist das vernetzte System und daher auch das Host-Betriebssystem an das Internet angebunden. Sicherheitsschwachstellen des Host-Betriebssystems oder einer seiner Anwendungen können somit von Hackern ausgenutzt werden, sodass das Fundament des Systems, das funktional sicher sein soll, kompromittiert wird. Grundsätzlich ist das sicherheitskritische System den Sicherheitslöchern des Host-Betriebssystems und der darauf ausgeführten Anwendungen ausgesetzt – eine große potenzielle Angriffsfläche.
Außerdem käme einem solchen sicherheitskritischen System der Determinismus abhanden. Die Universalbetriebssysteme, die typischerweise zum Hosten von Typ-2-Hypervisoren eingesetzt werden, sind nicht deterministisch, denn sie wurden im Hinblick auf Benutzerfreundlichkeit entwickelt, nicht hinsichtlich ihrer Vorhersagbarkeit. Ein Universalbetriebssystem wird die CPU-Zyklen lieber Anwendungen mit nachrangiger Priorität zuteilen, die für ein möglichst angenehmes Nutzererlebnis sorgen oder um bestimmte Prozesse im Hintergrund auszuführen. Deterministische Systeme hingegen führen immer die wichtigste Aufgabe mit höchster Priorität zuerst aus – zuungunsten der weniger wichtigen. Ein deterministisches System lässt sich aber nicht auf ein nichtdeterministisches aufpfropfen mit der Erwartung, weiterhin deterministisch zu sein. Ein Typ-2-Hypervisor wird hier nicht funktionieren. Weder erhöht er die Sicherheit, noch sorgt er für die Einhaltung der notwendigen Vorhersagbarkeit, die sicherheitskritische Systeme verlangen.
Typ-1-Hypervisor: nicht deterministisch
Der Typ-1-Hypervisor ist nicht den möglichen Sicherheitslücken seiner Host-Anwendungen ausgesetzt wie einer vom Typ 2. Das bedeutet eine verringerte Angriffsfläche, ein Plus für diesen Typ. Dennoch beinhaltet Typ 1 als potenzielle Sicherheitsschwachstelle durch das Hilfs-OS immer noch den dynamischen Speichermanager und Scheduler, das Prozessmodell und Dateisystem, den Netzwerk-Stack und Gerätetreiber, die System-API und Anwendungs-ABI.
Was den für sicherheitskritische Systeme benötigten Determinismus betrifft, so unterliegen Typ-1- wie auch Typ-2-Hypervisoren den gleichen Problemen. Typ 1 kann durch die bedingte Funktionalität eines Universalbetriebssystems nichtdeterministisch sein; also geht der Determinismus für beide Varianten dadurch verloren, dass diese Wunscheigenschaft in einer nichtdeterministischen Umgebung stattfinden soll.
Typ-0-Hypervisor – der Least Privilege Separation Kernel
Die typischen Typ-2- und Typ-1-Hypervisoren können in sicherheitskritischen Embedded-Systemen also offensichtlich nicht für den notwendigen Sicherheitsgrad und Determinismus sorgen. Gefragt ist ein Hypervisor, dessen primäre Funktion ist, Systemressourcen wie CPU-Kerne, angeschlossene Peripherie (I/O-Geräte) und Speicher effizient unter den Gast-Betriebssystemen aufzuteilen und dann den Datenfluss streng zu kontrollieren. Gerätetreiber- und Netzwerkfunktionen müssen in den Stack eines Gast-Betriebssystems geschoben werden, denn dies verringert die Menge an privilegiertem Code. Ist all dies der Fall, kann man von einem Least Privilege Separation Kernel sprechen.
Ein Least Privilege Separation Kernel setzt das Prinzip der geringst möglichen Privilegien um: Das sicherheitskritische System und die Netzwerkanbindung werden als separate „Gäste“ platziert. Als Typ-0-Hypervisor sitzt der Least Privilege Separation Kernel direkt auf der Hardware, ohne ein Hilfs-Betriebssystem zur Virtualisierung zu benötigen. Das bedeutet, dass es keine Gast-OS-Anwendungen gibt, die mögliche Angriffsflächen bieten könnten.
Da auf den Netzwerk-Stack für das funktional sichere System verzichtet wird, reduziert sich dessen Kommunikation mit der Außenwelt auf seine Sensoren, Aktuatoren und den streng überwachten Datenkanal. Dies wiederum reduziert die Angriffsfläche auf ein absolutes Minimum. Durch die Platzierung des funktional sicheren Systems innerhalb des Least Privilege Separation Kernel wird es isoliert, was die (Angriffs-)Sicherheit des Designs verbessert.
Was passiert aber, wenn das mit dem Netz verbundene Überwachungssystem angegriffen wird? Da der Least Privilege Separation Kernel die Hardware auf seine Gäste verteilt, ist die Hardware des Überwachungssystems von der des funktional sicheren Systems separiert. Das mit dem Netz verbundene Überwachungssystem kann nicht auf die Hardware und Ressourcen des sicherheitskritischen Systems zugreifen. Wird das mit dem Netz verbundene Überwachungssystem also gehackt oder angegriffen, arbeitet das sicherheitskritische System ungehindert weiter. Außerdem gibt es ja – da der Least Privilege Separation Kernel nur die Hardware-Ressourcen des Systems partitioniert und für einen streng überwachten Datenkanal sorgt – keine Treiber, Scheduler, Netzwerk-Stacks oder andere Angriffsoberflächen, die das infizierte System nutzen könnte, um in den Least Privilege Separation Kernel hineinzukommen. Sowohl der Least Privilege Separation Kernel als auch das sicherheitskritische System sind vor dem infizierten, mit dem Netz verbundenen Überwachungssystem geschützt.
Was den Determinismus betrifft, so hat ein Least Privilege Separation Kernel ja keine Elemente, die den Determinismus der Gäste behindern könnten. Er kann sowohl deterministisch, mit nur 25.000 Codezeilen aber auch klein sein. Ein sicherheitskritisches System innerhalb eines deterministischen Least Privilege Separation Kernel auszuführen kann den Determinismus des sicherheitskritischen Systems aufrechterhalten.
Streng getrennt
Die Hauptaufgabe eines Least Privilege Separation Kernel ist es, die Hardware-Ressourcen eines Systems unter den Gästen aufzuteilen und die Datenströme zwischen ihnen streng zu kontrollieren. Es isoliert die Gast-Systeme in separate virtuelle Maschinen, sodass sie sich gegenseitig nicht beeinträchtigen können. Außerdem sieht ein Least Privilege Separation Kernel keine Betriebssystem-typischen Scheduler vor oder Kernel Services, Gerätetreiber, Dateisysteme, Netzwerk-Stacks usw., die dazu genutzt werden könnten, um ein System zu kompromittieren.
Ein Least Privilege Separation Kernel als zusätzliche Schicht für funktional sichere Software sorgt für die Sicherheit vor Angriffen, die Embedded-Systeme benötigen. Die Sicherheit beruht auf Systemisolierung zuzüglich der Sicherstellung des deterministischen Verhaltens, wie es wiederum die funktional sichere Funktionen verlangen.
Der Autor
| James Deutch |
|---|
verfügt über 25 Jahre Erfahrung in der Software-Entwicklung, die von der Erstellung von Assemblersprachen-Firmware bis hin zu Java- und C/C++-Server-Software reicht. Er war beruflich weltweit tätig und ist Mitinhaber zahlreicher Patente. Seit 2014 ist er bei Lynx Software Technologies in San José, Kalifornien, als Produktspezialist für die echtzeitfähigen Betriebssysteme LynxOS und LynxOS-178 beschäftigt. |
- Embedded-Software-Schutz auf mehreren Ebenen
- Isolation durch Hypervisor
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Zertifikate von der Telekom
Sichere Identitäten für die »Dinge«
Software-Unterstützung
Asymmetrisches Multiprocessing auf i.MX6
Betriebssystem
Windows 7 für Embedded-Systeme bis 2024
Sicherheit im Internet der Dinge
Vom smarten Haushalt zur smarten Bastion
Betriebssystem
Sysgo stellt PikeOS 4.1 vor
