Embedded-Sicherheit durch Hypervisor und Hardware-Virtualisierung

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Parasoft® Deutschland GmbH

Das Internet der Dinge erfordert die Vernetzung verschiedenster Komponenten und Systeme. Gleichzeitig muss die Sicherheit gewahrt bleiben. Ein Spagat, den es zu bewältigen gilt.

Vernetzte Einrichtungen im Internet der Dinge (Internet of Things; IoT), in Gateway Routern, IPTV, Mobilgeräten und Automotive-Systemen müssen daraufhin ausgelegt sein, außergewöhnliche Anwendungen, verschiedene Inhalte und Software-Updates von Dienstleistern und Betreibern im Feld zu unterstützen. Gleichzeitig sind die Privatsphäre und der Datenschutz zu gewährleisten. Da heute verschiedene Anwendungen und die dazugehörigen Daten alle auf dem gleichen SoC koexistieren, müssen sie vor externen Hacker-Angriffen als auch voneinander geschützt werden.

Im Automotivebereich wird die Kommunikation immer enger mit Smartphones gekoppelt, was Dienste von Drittanbietern in die Automotive-Infrastruktur erfordert. Mit der Unterstützung kommender Anwendungen wie automatisches Einparken und autonomes Fahren muss ein hochsicherer Betrieb gewährleistet sein, um die ADAS-Anforderungen (Advanced Driver Assistance Systems) zu erfüllen.

Bildergalerie

Bildergalerie mit 6 Bildern

Statisch basierte Ansätze für Embedded-Sicherheitssysteme, die sichere und nicht sichere Bereiche durch Partitionierung separater Hardware-Subsysteme für jeden Bereich definieren, sind heute generell sehr wirksam. Die heutigen Ansätze sind allerdings CPU-zentrisch-binär – mit einem sicheren Bereich und einem nicht sicheren Bereich – und schwierig zu implementieren.

Diese Lösungen lassen sich nicht für die anspruchsvollen Anwendungen und Dienstleistungen skalieren, die mit den kommenden vernetzten Einrichtungen und der Cloud einhergehen. Daher sind besser skalierbare kosteneffiziente Ansätze erforderlich, um die Anforderungen neuerer Systeme zu erfüllen, auf denen mehrere Anwendungen über verschiedene sichere Umgebungen/Domains laufen.

Hardware-Virtualisierung, Basis für Embedded-Sicherheit

Hardware-Virtualisierung kann die erforderlichen vertrauenswürdigen skalierbaren Umgebungen für sichere Embedded-Systeme ermöglichen. Virtualisierung erzeugt mehrere isolierte Umgebungen, die verschiedene Gast-Betriebssysteme und/oder Anwendungen über eine gemeinsame Hardware-Ressource wie ein CPU-Subsystem betreiben.

Diese Technik kommt bereits in Datencentern und Servern zum Einsatz und kann eine kosten- und stromsparende Grundlage für mehr Sicherheit in zahlreichen Einrichtungen bieten, einschließlich Embedded-Systemen.

Mit Hardware-Virtualisierungssupport in der CPU, GPU und in anderen Prozessoren eines SoC können Unternehmen mehrere isolierte Domains schaffen, in denen jede Anwendung von der anderen geschützt ist. Bild 1 zeigt Imaginations hardwaregestützte Virtualisierung OmniShield, die ein System mit mehreren Domains unterstützt.

Der Hypervisor, Verwalter der SoC-Ressourcen

Für eine Embedded-Anwendung ist der Hypervisor ein kleiner privilegierter Code, der sich über der Hardware befindet und die SoC-Ressourcen verwaltet, indem er Zugriffrechte für jede Ausführungsdomäne definiert, genannt Virtual Machines (VMs) oder Guests (Gäste).

Mit Imaginations OmniShield-fähigen CPUs und GPUs können 255 VMs vom Single-Core bis zu mehreren Cores innerhalb eines Clusters oder mehrerer Cluster definiert werden. Unternehmen haben hohes Interesse daran, in vertikalen Segmenten das Konzept hardwaregestützter Virtualisierung zu verwenden, um mehrere unabhängige Domains bereitzustellen, die voneinander isoliert sind.

Damit erhöht sich die Sicherheit und Zuverlässigkeit, die Programmierung vereinfacht sich, genauso wie die letztendliche Umsetzung der Anwendung. Es bleibt allerdings die Frage, wie Embedded-Sicherheit mittels Hypervisor garantiert wird und wie diese sicher mit der Hardware verankert werden können, um vertrauenswürdig zu erscheinen.

Hardwaregestützter Hypervisor und sicherer Hypervisor

In einem Embedded-System wird ein TLB (Translation Lookaside Buffer) von der Memory Management Hardware in hierarchischer Weise verwendet, um die Übersetzungsgeschwindigkeit der virtuellen Adresse zu verbessern.

In Systemen mit hardwaregestützter Virtualisierung ermöglicht eine 2-stufige TLB eine Isolation bei vergleichbarer Leistungsfähigkeit. Die Hierarchie besteht aus zwei Ebenen: erstens, dem Gast-TLB; und zweitens, dem Root TLB. Jede/r VM/Gast arbeitet im herkömmlichen User Mode (siehe Bildergalerie; Bild 1a; linke Seite), wobei der Gast-TLB (G.TLB) genauso konfiguriert wird wie ein herkömmlicher TLB.

Dabei sind nur wenig oder gar keine Änderungen am Gast-Kernel erforderlich. Der Hypervisor steuert im privilegierten Modus den Root TLB (R.TLB) und leitet den Gast-Zugriff auf die richtige physikalische Adresse um. Damit überwacht der Hypervisor alle CPU-Bus-Transaktionen durch vorgegebene Zugriffsrechte und stellt sicher, dass jeder Gast innerhalb der vom Hypervisor vorgegebenen Grenzen arbeitet.

In anderen Worten: der Root TLB, als Teil der Hierarchie der Memory Management Units (Root MMU) und unter der Kontrolle des Hypervisors, sorgt für die Isolation zwischen den Gästen. Die Gast-MMU wird dabei vollständig vom Gast-OS verwaltet, um Gast-Anwendungen/User zu isolieren.

Die Isolation zwischen der Gast-Anwendung und dem privilegierten Root Kernel ist der erste Schritt bei der Sicherung des Hypervisors. Es muss auch sichergestellt sein, dass die „Attack Surface Area“ des Root-Kernels so klein wie möglich ist und alle Root-Kernel-Zugänge durch den Vorder- und Hintereingang eingeschränkt sind und unter strenger Beobachtung des Hypervisors stehen.

Für eine Embedded-Plattform ist daher ein Hypervisor mit kleiner Codegröße wünschenswert. Dafür stehen heute viele Hypervisor von Drittanbietern zur Verfügung.

Bild 2 beschreibt, wie R.TLB einen unerlaubten Zugriff des benachbarten Gasts verhindert. Der R.TLB wird so konfiguriert, dass DDR-Speicherbereiche für jeden Gast-n und Gast-m vollständig isoliert sind.

Der Gast-n Write Request (WR-req) an den Gast-n DDR-Speicherbereich wird genehmigt, während der Gast-m Read Request (RD-req) vom Gast-n DDR-Speicherbereich durch das R.TLB blockiert wird. Eine Ausnahme kann für den Hypervisor erzeugt werden, um entsprechende Aktionen vorzunehmen (Bild 2; siehe Bildergalerie).

Verankerung des Embedded-Systems

Ein vertrauenswürdiger Hypervisor ist entscheidend für die Gesamtsicherheit der Embedded-Plattform. Um einen solchen Hypervisor zu erhalten, ist jedoch zusätzliches IP erforderlich (Bild 3; siehe Bildergalerie). Weitere Bestandteile wie ein sicheres NoC, eine sichere GPU etc. spielen eine wichtige Rolle bei der Entwicklung eines sicheren SoC. Um eine Embedded-Plattform zu sichern, ist ein vertrauenswürdiger Anker erforderlich. In diesem Fall fungiert die Root of Trust (RoT) als Anker (Bild 3).

Bildergalerie

Bildergalerie mit 6 Bildern

Die RoT soll folgendes erzwingen:

• Authentifizierung des Ursprungs und der Integrität der Hypervisor Images vor der Ausführung;

• Booten des Systems im sicheren Hypervisor-Zustand und sicherstellen, dass nur vertrauenswürdiger Code läuft; anschließend wird der Hypervisor als Vertrauenskette aufgebaut.

Sicherheit durch Hypervisor-Einsatz

Bild 4 (siehe Bildergalerie) beschreibt den Aufbau eines Embedded-Systems, das mehrere isolierte und sichere Umgebungen benötigt. Der Hypervisor und alle gemeinsamen Treiber und Bibliotheken sind von den Gast-Kernels und zugehörigen Nutzerumgebungen isoliert und geschützt. Anschließend wird jeder Gast von den benachbarten Gästen isoliert und geschützt.

Wie bereits erwähnt, erfolgt dies durch die MMU-/TLB-Hierarchie (Gast und Root TLB). Hinzu kommt, dass die durch das Trusted Element verankerte RoT (Bild 4) die gleiche oder eine höhere Berechtigungsstufe hat als der Hypervisor, der die Vertrauenskette durchsetzt.

Vertrauen in den Hypervisor: sichere Boot-Sequenz

Die in Bild 5 (siehe Bildergalerie) aufgeführten Schritte beschreiben, wie ein Hypervisor in einen vertrauenswürdigen oder sicheren Zustand gebootet wird. Danach erfolgt das Erstellen verschiedener isolierter VM/Gäste in mehreren sicheren Umgebungen.

Auf diese Art wird der Hypervisor unter der Kontrolle des Trusted Element geladen und mit der SoC RoT verankert. Der Hypervisor lädt und authentifiziert zugehörige Software für jede/n VM/Gast und nutzt dabei den gleichen sicheren Boot-Vorgang.

Der schrittweise Prozess läuft wie folgt ab:

• Root-Kernel Modus-Ausführung

• Erster Boot Loader wird am Reset Exception Vector platziert – entspricht der ersten Ausführung aus dem ROM oder OTP-ROM

• Der erste Boot Loader lädt den zweiten Boot Loader in das On-Chip RAM (OCM)

• Der erste Boot Loader authentifiziert den zweiten Boot Loader

• Die Kontrolle wird nun an den zweiten Boot Loader übergeben, der sich nun im OCM befindet

• Der zweite Boot Loader lädt den Hypervisor in das für ihn vorgesehene RAM

• Der zweite Boot Loader authentifiziert das Hypervisor Image mit dem Trusted Element

• Die Kontrolle wird an den Hypervisor als Vertrauenskette übergeben, der nun im isolierten Bereich des DRAM läuft

• Der Hypervisor erstellt die Root TLB für mehrere VMs/Gäste

• Der Hypervisor lädt das Linux-0 Image in das für VM0 vorgesehene DRAM

• Der Hypervisor authentifiziert das Linux-0 Image mit dem Trusted Element

• Schritte (a) & (b) werden für VM1/Linux-1 wiederholt

• Schritte (a) & (b) werden für VM2/Linux-2 wiederholt

• Schritte (a) & (b) werden für VM3/Linux-3 wiederholt

• Der Hypervisor betreibt das VM/Gast Context Switching (CS) nach den festgelegten Richtlinien

Fazit: Hardwareerzwungene Trennung, Schutz für den SoC

Um Embedded-Plattformen abzusichern, stehen heute viele Möglichkeiten zur Verfügung. Per Definition enthält eine Embedded-Plattform in der Regel proprietäre Software, die von OEMs auf Basis von Referenzdesigns und Entwicklungskits des SoC-Herstellers entwickelt wurde. Daher sind die meisten Sicherheitstechniken ebenfalls proprietär.

Da Embedded-Plattformen nun aber immer häufiger für Software von Drittanbietern offenstehen, muss die proprietäre Software isoliert sowie geschützt und gleichzeitig auch die neue Software unterstützt werden. OEMs müssen daher neue Wege finden, diese Anforderungen zu adressieren – und das zu einem gleichen Kosten-, Leistungs- und Stromverbrauchsverhältnis wie bei bestehenden Lösungen.

Kommende Lösungen müssen über binäre Ansätze hinausgehen, um mehrere sichere Domänen zu schaffen, in denen jede(s) sichere/nicht-sichere Anwendung/Betriebssystem unabhängig in seiner eigenen Umgebung betrieben werden kann. Diese Plattformen müssen die Skalierbarkeit adressieren, die von heterogenen Architekturen verlangt wird. Dabei müssen alle Prozessoren in einem SoC (einschließlich CPU, GPU u.a.) geschützt werden.

In einer heterogenen Architektur teilen sich die Anwendungsdaten und Ressourcen die gleiche CPU sowie andere Prozessoren im System. Diese Prozessoren sind nun genauso anfällig wie die CPU und müssen mit dem gleichen Schutz versehen werden.

Hardwaregestützte Virtualisierung bietet eine bewährte Lösung für die Hardware-Befähigung und Erweiterung, die für zukünftige Embedded-Sicherheit erforderlich ist. Ein Sicherheitsansatz mit Hardware-Virtualisierung wie ihn OmniShield von Imagination bietet, gewährleistet, dass Anwendungen, die gesichert werden müssen, effektiv und zuverlässig voneinander isoliert und vor nicht-sicheren Anwendungen geschützt sind.

Gleichzeitig werden die Forderungen hinsichtlich der Funktionalität, Leistungsfähigkeit, Kosten und des Stromverbrauchs erfüllt. Zusammen mit einem vertrauenswürdigen Hypervisor für OmniShield und anderem OmniShield-kompatiblem IP können Unternehmen eine sichere heterogene Multi-Domain-Anwendungsumgebung implementieren, die eine hardwareerzwungene Trennung und somit Schutz für den gesamten SoC garantiert.

* Majid Bemanian ist Director of Segment Marketing, Imagination Technologies

(ID:43586849)