Trust Nothing: RTOS Security without Run-Time Software TCB (Extended Version)

Dieses Papier stellt eine neue Capability-Architektur vor, die auf einer FPGA-Implementierung und einem disaggregierten Zephyr-Betriebssystem basiert, um Echtzeit-Embedded-Systeme ohne vertrauenswürdigen Software-Kernel (TCB) gegen Angriffe von Anwendungen, dem Betriebssystem und Peripheriegeräten zu schützen.

Das Wesentliche

Hier ist eine einfache Erklärung der Forschungspapiere von Eric Ackermann und Sven Bugiel, die sich mit der Sicherheit von eingebetteten Geräten (wie Smart Home-Geräten, Autos oder Industriesteuerungen) befasst.

Stellen Sie sich vor, Sie bauen ein hochsicheres Schloss für Ihr Haus. Normalerweise vertrauen Sie dem Schlossmacher (dem Betriebssystem-Kernel), dem Hausmeister (dem Treiber) und den Nachbarn (den Anwendungen), dass sie alle ehrlich sind. Wenn einer von ihnen verrückt wird, ist das ganze Haus unsicher.

Diese Forscher sagen: „Vertraue niemandem!"

Hier ist die Geschichte ihrer Lösung, namens Skadi (das Betriebssystem) und Bredi (die Hardware), erzählt mit einfachen Analogien.

1. Das Problem: Ein unsicheres Haus

Eingebettete Geräte sind heute voller Software. Das ist gut, weil es billig und flexibel ist. Aber es ist auch ein Albtraum für Hacker:

• Die Anwendung (der Mieter) könnte einen Fehler haben.
• Das Betriebssystem (der Hausmeister) könnte gehackt werden.
• Die Peripheriegeräte (der Briefkasten oder die Türklingel) könnten manipuliert sein und direkt in den Tresor greifen.

Bisherige Sicherheitsmethoden waren wie ein Haus, bei dem man entweder dem Hausmeister vertraut (aber nicht dem Mieter) ODER dem Mieter vertraut (aber nicht dem Hausmeister). Niemand konnte beides gleichzeitig schützen, ohne das ganze Haus neu zu bauen.

2. Die Lösung: Das „Token-System" (Northcape)

Die Forscher nutzen eine alte Idee aus den 1960ern, die sie mit moderner Technik neu erfinden: Capabilities (Fähigkeiten/Tokens).

Stellen Sie sich vor, statt eines Hausschlüssels, der alles öffnet, gibt es für jeden Raum nur einen kleinen, speziellen Zettel (ein Token).

• Wenn Sie in die Küche wollen, brauchen Sie den „Küchen-Zettel".
• Wenn Sie in den Keller wollen, brauchen Sie den „Keller-Zettel".
• Der Zettel sagt genau: „Du darfst nur bis hierher gehen und nur das anfassen."

Das Besondere an ihrer Idee (Northcape) ist, dass diese Zettel nicht vom Hausmeister kontrolliert werden, sondern direkt vom Türschloss selbst (der Hardware) geprüft werden. Selbst wenn der Hausmeister verrückt wird, kann er keinen Zettel fälschen, weil das Schloss die Echtheit prüft.

3. Die Hardware: Bredi (Der neue Türsteher)

Bredi ist die physische Umsetzung dieses Systems auf einem Chip (einem FPGA).

• Der Türsteher: Normalerweise schaut der Computer (CPU) auf die Zettel. Bei Bredi schaut ein extra eingebauter „Türsteher" (Northbridge) auf jeden einzelnen Datenverkehr.
• Der Trick: Wenn ein Gerät (wie eine Kamera oder ein WLAN-Chip) Daten senden will, muss es seinen Zettel vorzeigen. Der Türsteher prüft: „Darfst du wirklich hier lang?" Wenn nicht, blockiert er es sofort.
• Kein Vertrauen nötig: Selbst wenn der Computer (CPU) gehackt ist, kann er nicht durch den Türsteher kommen, weil der Türsteher die Zettel selbst prüft.

4. Die Software: Skadi (Das zerlegte Haus)

Skadi ist das Betriebssystem, das auf dieser Hardware läuft. Es ist eine modifizierte Version von Zephyr, einem beliebten Echtzeit-Betriebssystem.

Statt eines riesigen, alles kontrollierenden Hausmeisters (Kernel), hat Skadi das Haus in viele kleine, voneinander getrennte Räume zerlegt:

• Der Scheduler (Wer macht was?) ist in einem Raum.
• Der Speicher-Manager (Wo liegen die Daten?) ist in einem anderen Raum.
• Die Treiber (Kamera, WLAN) sind in eigenen Räumen.

Wie kommunizieren sie?
Sie können nicht einfach durch die Wände reden. Sie müssen durch eine spezielle Tür (Subsystem-Call).

• Wenn Raum A zu Raum B sprechen will, gibt er einen Zettel ab.
• Der Türsteher prüft den Zettel.
• Raum A darf nur das tun, was auf dem Zettel steht. Er kann nicht plötzlich die Wände von Raum B einreißen.

Das Geniale: Sobald das Haus fertig eingerichtet ist, wird der ursprüngliche Hausmeister (der Loader) entlassen und das Haus verriegelt. Es gibt keinen vertrauenswürdigen Hausmeister mehr, der im Betrieb noch Zugriff hat. Wenn ein Raum gehackt wird, bleibt der Rest des Hauses sicher.

5. Was passiert bei Angriffen?

• Ein Hacker hackt die WLAN-Karte: Die Karte versucht, auf den Speicher des Schedulers zuzugreifen. Der Türsteher (Bredi) sieht den Zettel der Karte, prüft ihn und sagt: „Nein, du darfst nur Daten senden, nicht auf den Speicher zugreifen." Der Angriff scheitert.
• Ein Hacker hackt das Betriebssystem: Da das OS in viele kleine Räume zerlegt ist, kann der Hacker nur diesen einen Raum übernehmen. Er kann nicht auf den Scheduler oder den Speicher zugreifen, weil er die richtigen Zettel nicht hat.

6. Die Kosten (Performance)

Natürlich kostet dieses ständige Prüfen von Zetteln Zeit.

• Bei einfachen Aufgaben (Rechnen) ist es fast genauso schnell wie ein normales System.
• Bei vielen kleinen Aufgaben (Netzwerk, Daten senden) wird es etwas langsamer (etwa 2- bis 4-mal langsamer als ein unsicheres System).
• Aber: Die Forscher sagen, dass die Sicherheit das Risiko wert ist. Für kritische Geräte (wie 5G-Masten oder medizinische Geräte) ist es besser, etwas langsamer zu sein, als komplett gehackt zu werden.

Fazit

Die Forscher haben ein System gebaut, das niemandem vertraut.

• Die Hardware (Bredi) ist der unbestechliche Türsteher.
• Die Software (Skadi) ist ein Haus, das in viele kleine, abgeschottete Zellen zerlegt ist.
• Selbst wenn der Hausmeister, der Mieter oder der Briefträger verrückt werden, bleibt das Haus sicher.

Es ist wie ein Banktresor, bei dem jeder einzelne Dollar einen eigenen, unverfälschbaren Ausweis hat, der von der Bank selbst geprüft wird – egal, wer gerade in der Bank ist.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „Trust Nothing: RTOS Security without Run-Time Software TCB (Extended Version)" auf Deutsch:

1. Problemstellung

Eingebettete Geräte stehen vor einer sich ständig erweiternden Bedrohungslandschaft. Sicherheitslücken können in drei Hauptbereichen auftreten:

1. Anwendungssoftware: Häufige Schwachstellen in Firmware (z. B. bei Druckern).
2. Betriebssystemkern: In vielen RTOS (wie Zephyr) ist die Trennung zwischen Kernel und User-Space optional oder nicht auf allen SoCs verfügbar. Ein Kompromittieren des Kernels führt zum vollständigen Systemverlust.
3. Peripheriegeräte (DMA): Geräte mit Direct Memory Access (DMA) können als Trojaner missbraucht werden, um Speicherbereiche zu manipulieren, auf die sie eigentlich keinen Zugriff haben sollten (z. B. Thunderclap-Angriffe).

Die Lücke: Bestehende Sicherheitsarchitekturen schützen typischerweise nur gegen zwei dieser drei Vektoren gleichzeitig.

• Herkömmliche MMU-basierte Ansätze vertrauen dem Kernel, um die MMU korrekt zu konfigurieren (kein „No-TCB"-Ansatz).
• Capability-basierte Architekturen (z. B. CHERI) reduzieren den vertrauenswürdigen Software-Teil (TCB), schließen aber oft DMA-Geräte aus dem Bedrohungsmodell aus oder vertrauen deren Treibern.

Das Ziel ist ein eingebettetes System, das gleichzeitig gegen bösartige Anwendungssoftware, einen kompromittierten Kernel und bösartige Peripheriegeräte geschützt ist, ohne einen vertrauenswürdigen Software-TCB zur Laufzeit zu benötigen, und dabei Soft-Real-Time-Garantien bietet.

2. Methodik: Hardware-Software-Co-Design

Die Autoren lösen das Problem durch eine enge Verzahnung von Hardware und Software, bestehend aus zwei Hauptkomponenten:

A. Bredi (Hardware-Implementierung von Northcape)

Bredi ist die erste Hardware-Implementierung des theoretischen Konzepts „Northcape". Es basiert auf dem RISC-V-Prozessor cva6 und einem FPGA.

• Capability-Architektur: Northcape verschiebt die Zugriffskontrolle von der CPU auf den Systembus (Northbridge). Speicherzugriffe werden nicht über Adressen, sondern über Capability-Tokens gesteuert.
• Token-Format: Ein Token besteht aus einem Offset, einer Capability-Nummer und einem Nonce. Die Metadaten (Grenzen, Berechtigungen) liegen in einer zentralen Capability Metadata Table (CMT) im DRAM.
• Hardware-Enforcement: Ein Northcape MMU (für die CPU) und ein AXI MMU (für DMA-Geräte) übersetzen Tokens in physische Adressen und prüfen Berechtigungen. DMA-Geräte können keine Speicherbereiche außerhalb ihrer zugewiesenen Capabilities erreichen.
• Unterbrechungsbehandlung (ISR): Um den TCB zu eliminieren, werden Interrupt Service Routines (ISRs) als unvertrauenswürdig behandelt.
  • Register Stacking: Der CPU-Kontext wird bei Interrupts in ein separates Register-Set kopiert, um Leaks zu verhindern.
  • Interrupt Vectoring: Interrupts führen zu einem „Subsystem Call" in einen isolierten ISR-Subsystem, nicht in den Kernel.
  • Non-Maskable Interrupts (NMI): Kritische Interrupts können nicht deaktiviert werden, um Verfügbarkeit (Availability) zu garantieren.

B. Skadi (RTOS-Implementierung)

Skadi ist ein modifiziertes Zephyr RTOS, das die Northcape-Operationen nutzt, um das gesamte System in gegenseitig misstrauische Subsysteme zu zerlegen.

• Kein Kernel: Es gibt keinen privilegierten Kernel. Alle Funktionen (Scheduler, Allocator, Treiber, Netzwerk-Stack) sind isolierte Subsysteme.
• Subsystem Calls: Der einzige Mechanismus zur Interaktion ist der „Subsystem Call". Dieser ändert atomar den Subsystem-ID-Register und den Programmzähler. Caller und Callee sind strikt voneinander isoliert (keine gemeinsamen Register, keine gemeinsamen Speicherbereiche, es sei denn, Capabilities werden explizit delegiert).
• Kein Laufzeit-TCB: Der einzige vertrauenswürdige Teil ist der Skadi Loader, der beim Booten Subsysteme lädt, Capabilities verteilt und sich danach selbst zerstört (durch Übergabe an ein „Trapdoor"-Subsystem und Vernichtung der Root-Capability). Nach dem Booten existiert kein vertrauenswürdiger Software-Teil mehr.
• DMA-Sicherheit: DMA-Treiber sind ebenfalls ungetraute Subsysteme. Sie erhalten nur Capabilities für die spezifischen Puffer, die sie bearbeiten dürfen.

3. Schlüsselbeiträge

1. Erste vollständige Implementierung von Northcape: Bredi ist die erste Hardware-Realisierung, die Northcape von einer Theorie in ein funktionierendes FPGA-System überführt.
2. Eliminierung des Laufzeit-TCB: Skadi erreicht einen Zustand, in dem weder Kernel noch Treiber oder Scheduler zur Laufzeit vertrauenswürdig sein müssen. Das System bleibt sicher, selbst wenn diese Komponenten kompromittiert sind.
3. Schutz vor DMA-Angriffen ohne Hardware-Änderungen an Peripherie: Durch den AXI MMU werden DMA-Geräte in das Capability-Modell integriert, ohne dass die Geräte selbst modifiziert werden müssen.
4. Real-Time-Fähigkeit: Trotz der strengen Isolation wurde ein Soft-Real-Time-System implementiert, das durch NMI und spezielle Interrupt-Handling-Mechanismen (Register Stacking, Voluntary Preemption) Verfügbarkeit garantiert.
5. Verbesserungen gegenüber Northcape:
   • Einführung von Subsystems-ID-Bound Restrictions, um Guessing-Attacken auf Capabilities zu verhindern (ein Nonce allein reicht nicht aus; die Subsystem-ID muss ebenfalls passen).
   • Unterstützung von Lock-Holder Capabilities für exklusiven Zugriff, um TOCTOU-Angriffe zu verhindern.
   • Hardware-Unterstützung für NMI und Register Stacking zur Sicherung der ISR-Isolation.

4. Ergebnisse und Evaluation

Die Autoren bewerteten das System auf einem Digilent Genesys 2 FPGA Board.

• Sicherheit: Das System bietet räumliche und zeitliche Sicherheit für alle Subsysteme, den Kernel und DMA-Geräte. Ein Angriff auf ein Subsystem (z. B. einen Treiber) kann nicht auf andere Subsysteme übergreifen oder den Speicher des Kernels manipulieren.
• Performance (Compute):
  • In rechenintensiven Benchmarks (Coremark, Stream) ist Skadi nahezu gleich schnell wie das ungeschützte Zephyr-Referenzsystem (Unterschied < 0,2 %). Dies liegt an der hohen Trefferquote (100 %) im Level-1 Capability TLB (NTLB L1).
  • Im Vergleich zu Linux auf demselben Hardware-Setup liegt Skadi in derselben Größenordnung.
• Performance (I/O & Netzwerk):
  • Bei I/O-lastigen Szenarien (Ping, TCP-Throughput, MQTT) entsteht ein Overhead von ca. 3- bis 4-fach im Vergleich zu Zephyr. Dies ist auf die hohe Anzahl an Subsystem Calls zurückzuführen, die für die Isolation notwendig sind.
  • Dennoch bleiben die absoluten Latenzzeiten (z. B. Ping-Latenz im Millisekundenbereich) für die meisten eingebetteten Anwendungen akzeptabel.
• Real-Time-Eigenschaften:
  • Die Interrupt-Latenz ist höher als bei Zephyr (Faktor 3–7), liegt aber im Bereich von Mikrosekunden bis zu einem Zehntel Millisekunde.
  • Der Scheduler-Benchmark zeigt Overheads von Faktor 3 bis 10, was für Soft-Real-Time-Anwendungen als ausreichend bewertet wird.
• Code-Größe: Der Overhead durch Metadaten, Trampoline und Relokation ist signifikant (Faktor 2–3 gegenüber Zephyr), aber für moderne eingebettete Systeme mit begrenztem Energiebudget (nicht Kosten) noch tragbar.

5. Bedeutung und Ausblick

Dieses Paper demonstriert, dass es möglich ist, ein sicheres, eingebettetes Echtzeitsystem zu entwerfen, das keine vertrauenswürdige Software zur Laufzeit benötigt.

• Paradigmenwechsel: Es beweist, dass die Kombination aus Capability-Architekturen und Hardware-Enforcement am Systembus eine praktikable Alternative zu traditionellen, auf Vertrauen in den Kernel basierenden Modellen ist.
• Anwendungsgebiete: Besonders relevant für sicherheitskritische Infrastruktur (z. B. 5G-Basisstationen, industrielle Steuerungssysteme), wo die Kompromittierung eines Treibers oder einer Anwendung katastrophale Folgen haben kann.
• Zukunft: Die Architektur bietet eine solide Basis für zukünftige Optimierungen (z. B. Compiler-Optimierungen, Zusammenfassen von Subsystemen), um den Performance-Overhead weiter zu reduzieren, während die Sicherheitsgarantien erhalten bleiben.

Zusammenfassend bietet „Trust Nothing" einen fundamentalen Baustein für „Security-by-Design" in der nächsten Generation eingebetteter Systeme, indem es die Angriffsfläche auf ein Minimum reduziert, das rein hardwarebasiert und nicht auf Software-Vertrauen angewiesen ist.