Mikrokernbasierte Plattform für zukünftige Sicherheitsarchitekturen

Ordnungsmerkmale

erschienen in: <kes> 2004^#5, Seite 51

Zusammenfassung: Zukünftige Architekturen unterschiedlichster Bereiche der Informationstechnik werden aufgrund ihrer steigenden Komplexität und breiten Anwendungsanforderungen die Aspekte der Sicherheit und Vertrauenswürdigkeit in einer mikrokernbasierten Plattform verankern. Unabhängig von zusätzlicher Hardwareunterstützung der Sicherheitsmechanismen dieser Plattform bieten Mikrokerne der zweiten Generation bereits ausreichende Instrumente der Zugriffskontrolle und des Speicherschutzes sowie eine effiziente Kommunikationsinfrastruktur. Eine Virtualisierungsschicht ermöglicht den transparenten Einsatz von so genannten Legacy-Betriebssystemen.

Autor: Von Dr. Thomas Östreich, BSI

Dieser Artikel gibt eine kurze Übersicht über aktuelle Entwicklungen auf dem Gebiet einer mikrokernbasierten Plattform für zukünftige Sicherheitsarchitekturen, wie sie unter anderem vom BSI in Projektvorhaben entwickelt wird. Teile dieser Plattform befinden sich noch im aktiven Entwicklungsstadium oder liegen bereits als Prototypen vor. Die Bestrebungen des BSI zielen hier auf die Entwicklung einer zukünftigen hochgradig modularen Architektur für hohe Sicherheitsanforderungen, die Anwendern unter anderem auch den Einsatz von Legacy-Betriebssystemen bietet, deren Evaluierbarkeit nahezu ausgeschlossen ist. Dem BSI liegen dabei umfangreiche Erfahrungen aus der Entwicklung einer sicheren Inter-Netzwerk-Architektur (SINA) [1] und dem Forschungsprojekt µSINA [2] vor, einer ersten mikrokernbasierten Erweiterung von SINA. Zu den Komponenten der Plattform zählen neben dem Mikrokern eine Reihe von spezifischen vertrauenswürdigen Applikationen, ein oder mehrere Betriebssysteme und eine optionale Anwendung, die für die Virtualisierung der Hardware zuständig ist und Nutzern eine Migration proprietärer Anwendungen auf die neue Sicherheitsplattform ermöglichen wird.

Ein Mikrokern nutzt separate Adressräume für die Kapselung von Systemkomponenten. Dabei ist der Mikrokern die zentrale Komponente, die als einzige mit den höchsten verfügbaren Privilegien ausgestattet wird. Unter Systemkomponenten versteht man zum einen schlanke Applikationen, so genannte Trusted Service Provider (TSP), die für eine spezielle Aufgabe konzipiert sind, und zum anderen vollständige Betriebssysteme (OS), die direkt an die Mikrokernschnittstelle ankoppeln. Die Kommunikationsinfrastruktur, die von einem Mikrokern bereitgestellt wird, besteht im Wesentlichen aus hochoptimierter nachrichtenbasierter Inter-Prozess-Kommunikation (IPC). In der Regel sind aus Komplexitätsgründen nur essenzielle Dienste der Plattform innerhalb der Codebasis des Mikrokerns implementiert. Zusätzlich zu der erwähnten IPC ist der Mikrokern für die Verwaltung verallgemeinerter Prozesse, so genannter Threads, und des vorhandenen physikalischen Speichers verantwortlich.

Mikrokerne der ersten Generation, zum Beispiel MACH [3], litten unter einer schlechten Performanz und ungenügender Zuverlässigkeit. Diese Mängel basierten auf dem gewählten Zugang der sukzessiven Verkleinerung bestehender umfangreicher monolithischer Betriebssysteme. Dieses so genannte Top-Down-Verfahren führte zwangsläufig zu einer Konservierung vorhandener Defizite der Systeme. Die zweite Generation Mikrokerne wurde von Grund auf neu konzipiert und mit der Anforderung entwickelt, nur solche Mechanismen innerhalb des Mikrokerns zu implementieren, die nicht mit ausreichender Sicherheit oder Effizienz im so genannten Nutzerraum, mit entsprechend niedrigeren Privilegien ausgestattet, als TSP implementiert werden konnten. Das führte dazu, dass die Mikrokerne der zweiten Generation mit wenigen Systemaufrufen eine sehr kleine und effiziente Schnittstelle für andere Komponenten bereitstellten. Zusammen mit der Optimierung der IPC sind sie damit um Größenordnungen schneller als ihre Vorgänger. Zum Beispiel bietet die vom BSI favorisierte und in µSINA eingesetzte L4/FIASCO- Implementierung der Technischen Universität Dresden (TUD) [4] als weit verbreitete Implementierung an Universitäten und Entwicklungslabors etwa sieben Systemaufrufe.

Der Mikrokern ist die einzige privilegierte Systemkomponente, die mit Priorität 0, das heißt der höchsten verfügbaren Priorität auf der weit verbreiteten Intel-Architektur IA32, betrieben wird. Jede weitere Systemkomponente oder Applikation läuft im Nutzerraum unter der vollständigen Kontrolle des Mikrokerns. In einem monolithischen Betriebssystemkern können Systemaufrufe uneingeschränkt auf den Kernspeicher zugreifen, was unter gewissen Umständen dazu führen kann, dass unbemerkte Programmierfehler oder bösartige Kernel-Module zu einer Kompromittierung des gesamten Systems führen. Unter einem Mikrokern sind diese Szenarien zwar nicht ausgeschlossen, können aber nicht ohne weiteres Schaden anrichten. Ladbare Kernmodule können bevorzugt in separate Adressräume geladen und ausgeführt werden, was man als Kapselung der Komponente versteht. Der Mikrokern kann durch das Einblenden von Speicherseiten einen Zugriff auf ausgewählte Kernspeicherbereiche ermöglichen. Durch die IPC ist zudem die Möglichkeit gegeben, Systemaufrufe zu protokollieren und ein umfassendes Systemaudit auf unterster Systemebene zu realisieren. Durch die Vererbung von Zugriffsrechten an Anwendungen ist die Möglichkeit eines hierarchischen Systems einer so genannten Mandatory Access Control (MAC) gegeben.

Für die Installation eines Mikrokerns und funktionierende Kapselung sind die folgenden Aspekte zu berücksichtigen: Der initiale Bootvorgang eines Mikrokerns sowie das weitere nachfolgende Laden von Sicherheitskomponenten und anderer TSP müssen durch einen unabhängigen sicheren Bootmechanismus kontrolliert werden. Idealerweise bieten sich hier so genannte Bottom-Up-Authentifizierungsketten an, die entweder durch eine Smartcard oder alternativ mit dem Trusted Platform Module (TPM) durchgeführt werden können. In beiden Fällen braucht es neben der Hardwarekomponente auch eine entsprechende vertrauenswürdige BIOS-Komponente, die in Abwesenheit des Mikrokerns und entsprechender Gerätetreiber eine Ansteuerung der Komponenten durchführt und als Root-of-Trust fungiert. Der sichere Bootvorgang besteht im Wesentlichen aus einer wohldefinierten Abfolge des Ladens von essenziellen Programmkomponenten mit steigender Komplexität, an die nach erfolgreicher Authentifizierung jeweils die weitere Kontrolle des Bootvorgangs abgegeben wird.

Ein kritischer Sicherheitsaspekt ist die Verwendung von Direct Memory Access (DMA) Transfers. DMA-Transfers ermöglichen Geräten, die über diese Fähigkeit verfügen, den direkten Zugriff auf Speichereinheiten unter vollständiger Umgehung der CPU und damit des Mikrokerns. Für Anwendungen mit Hochsicherheitsanforderugnen muss diese Art des Datentransfers für Applikationen unterbunden werden. Solange man Bus-Master-fähigen Geräten nicht vollständig vertrauen kann, müssen zusätzliche Hardwareschutzmechanismen installiert werden.

Abbildung 1: Schichtstruktur einer mikrokernbasierten Plattform. Der Mikrokern setzt direkt auf die Hardware auf und ist mit höchsten Privilegien ausgestattet. Weitere Komponenten der Trusted Computing Base bilden vertrauenswürdige so genannte Trusted Service Provider (TSP) für spezielle Aufgaben. Legacy-Betriebssysteme können über einen Virtual Machine Monitor (VMM) auf den Mikrokern zugreifen, andere Betriebssysteme (L4-Linux, µSINA) besitzen eine direkte Schnittstelle zum Mikrokern. Gerätetreiber nehmen aufgrund ihrer Komplexität eine Sonderstellung ein.

Betriebssystem(e)

Zukünftige Sicherheitsarchitekturen benötigen weiterhin Betriebssysteme, die etwa Gerätetreiber zur Verfügung stellen und Nutzerapplikationen und -speicher verwalten. Die natürlichste Einbettung eines oder mehrerer Betriebssysteme in verschiedene Partitionen ist die Anpassung eines vorhandenen Betriebssystems an die Schnittstelle des Mikrokerns, zum Beispiel L4-Linux [5]. Damit ist eine direkte Kommunikation mit dem Mikrokern gegeben, was eine schnelle und effiziente Kommunikation ermöglicht. Diese Lösung mit wenig Overhead hat aber den Nachteil, dass die Modifikationen bei jeder Änderung der Betriebssysteme nachgezogen werden müssen. Proprietäre Betriebssysteme werden diesen Weg sicherlich nicht so einfach beschreiten. Innerhalb der Betriebssystemumgebung kann der den Betriebssystemen zugewiesene Speicher von diesen an Nutzerapplikationen in gewohnter Weise vergeben werden. Eine Kompromittierung des Betriebssystems, das durch seine monolithische Struktur und Komplexität anfällig für Fehler ist, hat aufgrund der Kapselung durch den Mikrokern und niedriger Laufzeitpriorität keine direkten Auswirkungen auf die Sicherheit des Gesamtsystems, wohl aber wird ein Neustart dieser betroffenen Komponente erforderlich sein. Damit ist die Stabilität anderer Anwendungen, die etwa in weiteren Partitionen laufen, nicht betroffen. Als Beispiel sei hier die Mobilfunkkomponente eines PDAs erwähnt, die im Falle des Versagens des Betriebssystems weiterhin eine unterbrechungsfreie Kommunikation ermöglichen würde.

Im Zuge einer durchdachten Modularisierung des Gesamtsystems ist eine weitere Extraktion von Diensten des Betriebssystems erwünscht. Ladbare Kernmodule sind ein Paradebeispiel für separate TSP, die einem Kollektiv von Betriebssystemen zur Verfügung gestellt werden können. Dabei spielen auch Gerätetreiber eine wesentliche Rolle. Eine Verlagerung einiger Gerätetreiber in separate Adressräume erhöht nicht nur die Stabilität des Gesamtsystems, sondern würde auch unterschiedlichen Betriebssystemen eine hardwareunabhängige Schnittstelle zu vorhandener Peripherie anbieten. Ein weiterer Vorteil dieser Modularisierung ist die Evaluierbarkeit dieser Komponenten, die sonst als Bestandteil eines nicht-vertrauenswürdigen Betriebssystems keinen besonderen Status erlangen könnten. Aufgrund der hohen Komplexität einiger Gerätetreiber bietet es sich auch an, diesen als nicht vertrauenswürdigen Applikationen zum Beispiel nur die Verarbeitung von verschlüsselten Datenströmen zu erlauben, wie es bei Netzwerktreibern möglich ist. Ein Aufbrechen des monolithischen Betriebssystems und eine Auslagerung integraler Kernkomponenten würden insgesamt weitere Komponenten in das so genannte Trusted Subsystem des Gesamtsystems verlagern. Diese Option ist aus Performanzgründen zu bevorzugen. Beispiele dieser Vorgehensweise findet man in der Portierung von Linux auf die L4-Schnittstelle (L4-Linux) der TUD, in dem GNU/Hurd Derivat oder in MacOS X, die beide auf dem MACH-Mikrokern aufsetzen.

Trusted Service Provider (TSP)

Unter einem Trusted Service Provider (TSP) versteht man einen Bestandteil des Trusted Subsystems oder auch der Trusted Computing Base, welcher im Wesentlichen ein verallgemeinertes Sicherheitsmodul im Nutzerraum des Mikrokerns ist. Als vertrauenswürdige Komponente hat sie einen wohldefinierten Funktionsumfang und nutzt die Mikrokernmechanismen zur Kommunikation mit der Außenwelt. Dafür genießt der TSP die Kapselung und den überwachten Zugriffsschutz des Mikrokerns und erweitert dessen Funktionsumfang.

Als Beispiel wurden bereits Gerätetreiber erwähnt, die in dieser Konstellation die Fehlertoleranz des Gesamtsystems erhöhen. Weitere TSP können Treiber verschiedener Dateisysteme sein, Netzwerk-Protokollstapel oder wie im Folgenden noch ausführlich beschrieben, der Virtual Machine Monitor (VMM). Zu den wesentlichen TSP, die im Kontext des L4-Mikrokerns auch als L4-Server bezeichnet werden, gehört das Speichermanagement. Für diesen TSP wird der gesamte für Anwendungen nutzbare Speicher durch den Mikrokern eingeblendet, um im Weiteren von diesem Server verwaltet werden zu können. Dieser TSP hat die Aufgabe, den Speicher in den virtuellen Adressraum der Anwendungen einzublenden. Die meisten TSP haben einen überschaubaren Codeumfang und eignen sich daher auch für Zertifizierungen. Kritische Anwendungen, die Echtzeit-Eigenschaften fordern, können neben nicht-kritischen Anwendungen laufen. Multimediaanwendungen erfordern in vielen Fällen eine garantierte Bandbreite, etwa bei der Aufnahme auf ein Speichermedium.

Ein weiteres Beispiel für Sicherheitsserver im Sinne der TSP sind Kryptokomponenten. Kryptoalgorithmen oder -module sowie Schlüsselmaterial oder Zertifikate können in separaten Adressräumen sicher verwahrt werden. Krypto-Service-Provider bieten Applikationen in höheren Schichten generische Schnittstellen für die Verschlüsselung oder Signierung von Daten an, während in niedrigen Schichten ein Pool von Modulen die eigentlichen kryptographischen Algorithmen ausführt oder Treiber von hardwarebasierten Kryptogeräten ansteuert. Diese transparente Schnittstelle kann als universelle Schnittstelle nicht nur beliebigen Betriebssystemen zur Verfügung stehen, sondern auch von parallel laufenden TSP, wie etwa den Treibern der Dateisysteme, als Backend für eine Medienverschlüsselung herangezogen werden. Weitere Beispiele sind ein Trusted Viewer für Dokumente und Dateien oder eine vertrauenswürdige Signaturkomponente. Dieses Modularisierungskonzept setzt eine sehr schnelle und effiziente Implementierung einer IPC voraus.

Virtual Machine Monitor (VMM)

Der Virtual Machine Monitor (VMM) ist ein spezieller TSP, der für die Virtualisierung der Hardware verantwortlich ist. Der VMM ermöglicht das Ausführen so genannter Legacy-Betriebssysteme, zum Beispiel Windows XP, für die eine Portierung auf die Mikrokernschnittstelle nicht ohne Weiteres möglich oder nicht erwünscht ist. Das Prinzip der Hardware-Virtualisierung zur Kapselung eines im Allgemeinen nicht vertrauenswürdigen Gastbetriebssystems sorgt für einen zusätzlichen Schutz des Hostbetriebssystems. Im Falle eines mikrokernbasierten Systems ist dieser Schutzmechanismus durch die fundamentale Kapselung des VMM durch den Mikrokern deutlich verstärkt.

Zugriffe des Gastbetriebssystems werden von dem VMM ausschließlich über die vom Mikrokern bereitgestellte Kommunikationsinfrastruktur durchgeführt. Der Mikrokern benötigt zusätzlich eine funktionale Erweiterung, die die Virtualisierung der Hardware unterstützt. Die erhöhte Sicherheit führt zu einem zusätzlichen Overhead, der von dem VMM möglichst klein gehalten werden muss und nur mit einer effizienten IPC realisiert werden kann. Innerhalb des Gastbetriebssystems können Anwender auf unmodifizierte Applikationen zurückgreifen. Insgesamt bietet der VMM einen transparenten Zugriff auf die Hardware und die Systemressourcen. Im Gegensatz zu Betriebssystemen, die direkt an die Mikrokernschnittstelle angepasst sind, sind Updates innerhalb der Gastbetriebssysteme problemloser, da im Allgemeinen keine Modifikationen innerhalb der Codebasis notwendig werden. Ein weiterer Aspekt für die Realisierbarkeit dieses Konzepts ist die Bereitschaft eines Gastbetriebssystems, innerhalb einer virtualisierten Umgebung zu operieren.

Fazit

Das BSI legt besonderen Wert auf den Einsatz von Open Source in möglichst vielen Komponenten der Sicherheitsarchitektur SINA. Mit dieser Strategie erhalten Sicherheitslösungen im Allgemeinen ein erhöhtes Maß an Vertrauenswürdigkeit und Zuverlässigkeit. Mit der präferierten Open-Source-Implementierung des L4/Fiasco-Mikrokerns der TUD wird dieses Konzept auch im vorhandenen µSINA-Prototypen realisiert. Die hier skizzierte hochgradig modulare mikrokernbasierte Plattform für zukünftige Sicherheitsarchitekturen ist eine konsequente Fortsetzung dieses Konzepts. Durch eine performante Hardware-Virtualisierung können Legacy-Betriebssysteme transparent in die Sicherheitsarchitektur integriert werden. Diese generische Lösung eignet sich nicht nur für den Einsatz in Hochsicherheitsszenarien des Bundes, sondern ist auch von öffentlichem Interesse für Anforderungen bezüglich einer vertrauenswürdigen Umgebung eines IT-Systems. Vergleichbare Ansätze findet man auch in der PERSEUS-Architektur [6] oder XEN [7].

Mikrokerne der zweiten Generation bilden den zentralen Bestandteil der Plattform und garantieren eine Kapselung von TSP und Betriebssystemen. Angriffe oder Ausnahmefehler innerhalb einer gekapselten Anwendung führen nicht mehr zur Kompromittierung des Gesamtsystems, sondern bleiben lokal beschränkt und können durch den Neustart der betreffenden Komponente behoben werden. Die angestrebte Modularisierung verringert die Komplexität des Gesamtsystems, ermöglicht eine effiziente Evaluierung und erleichtert die Anpassung an ein breites Hardwarespektrum.

zurück zum Inhalt
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2004^#5, Seite 51