CHERIoT: Wie Microsoft und Cambridge Embedded-Systeme endlich speichersicher machen wollen
Die Zahl vernetzter Embedded-Systeme wächst rasant. Vom Smart-Home-Gerät über industrielle Steuerungen bis hin zu autonomen Fahrzeugen laufen heute Milliarden Geräte dauerhaft mit dem Internet verbunden. Gleichzeitig basiert ein großer Teil dieser Systeme noch immer auf klassischem C- oder C++-Code – und damit auf einer Technologie, die seit Jahrzehnten für Sicherheitsprobleme wie Buffer Overflows, Use-after-Free-Fehler oder Speicherkorruption bekannt ist.
Genau hier setzt CHERIoT an: eine neue Sicherheitsarchitektur für Mikrocontroller und Echtzeitbetriebssysteme, entwickelt unter anderem von Microsoft Research und der University of Cambridge. Das Ziel ist ambitioniert: vollständige Speichersicherheit auf ressourcenbeschränkten Embedded-Systemen – ohne auf Echtzeitfähigkeit oder bestehende Software verzichten zu müssen.

Warum Speichersicherheit bei Embedded-Systemen so schwierig ist
In klassischen Desktop- oder Server-Systemen existieren zahlreiche Sicherheitsmechanismen:
- virtuelle Speicherverwaltung,
- Memory Protection Units,
- moderne Betriebssysteme,
- Address Sanitizer,
- sichere Laufzeitumgebungen,
- oder speichersichere Programmiersprachen wie Rust.
Viele dieser Ansätze funktionieren in Embedded-Systemen jedoch nur eingeschränkt oder gar nicht. Mikrocontroller besitzen oft:
- nur wenige hundert Kilobyte RAM,
- sehr begrenzte CPU-Leistung,
- harte Echtzeitanforderungen,
- geringe Energie- und Kostenbudgets.
Ein zusätzlicher Sicherheitsmechanismus darf also weder zu viel Speicher benötigen noch unvorhersehbare Verzögerungen verursachen.
Das Ergebnis: Viele IoT- und Embedded-Geräte arbeiten bis heute mit nur minimalem Speicherschutz – obwohl gerade diese Systeme immer häufiger Ziel von Angriffen werden.
Was ist CHERIoT?
CHERIoT basiert auf der sogenannten CHERI-Architektur („Capability Hardware Enhanced RISC Instructions“).
Die Grundidee ist revolutionär einfach:
Anstatt Speicher nur über rohe Adressen anzusprechen, verwendet das System spezielle „Capabilities“. Diese enthalten zusätzlich:
- erlaubte Speichergrenzen,
- Zugriffsrechte,
- Gültigkeitsinformationen,
- Typinformationen.
Ein Pointer wird dadurch zu einem hardwaregeschützten Sicherheitsobjekt.
Die CPU überprüft bei jedem Zugriff automatisch:
- Darf dieser Speicherbereich gelesen werden?
- Darf er beschrieben werden?
- Liegt der Zugriff innerhalb der erlaubten Grenzen?
- Ist der Speicher überhaupt noch gültig?
Dadurch lassen sich ganze Klassen von Sicherheitslücken hardwareseitig verhindern.

Schutz vor den gefährlichsten Speicherfehlern
CHERIoT adressiert insbesondere drei große Problemfelder.
1. Buffer Overflows
Bei klassischen Speicherfehlern schreibt ein Programm über die Grenzen eines Puffers hinaus.
Mit CHERIoT besitzen Pointer feste Hardwaregrenzen. Ein Zugriff außerhalb dieser Grenzen wird sofort blockiert.
Das verhindert viele der gefährlichsten Exploits bereits auf CPU-Ebene.
2. Use-after-Free
Ein besonders kritischer Fehler entsteht, wenn Software weiterhin auf Speicher zugreift, der bereits freigegeben wurde.
CHERIoT führt dafür sogenannte Revocation Bits ein:
- freigegebene Speicherbereiche werden markiert,
- ungültige Referenzen automatisch erkannt,
- veraltete Pointer hardwareseitig deaktiviert.
Dadurch wird verhindert, dass alte Referenzen erneut missbraucht werden können.
3. Isolation kompromittierter Software
CHERIoT teilt Anwendungen in sogenannte Compartments auf.
Jedes Compartment:
- besitzt eigene Daten,
- besitzt eigenen Code,
- darf nur definierte Schnittstellen verwenden,
- kann nicht beliebig auf andere Bereiche zugreifen.
Wird ein Teil der Software kompromittiert, bleibt der Schaden lokal begrenzt.
Gerade bei IoT-Geräten mit Komponenten verschiedener Hersteller ist das ein enormer Sicherheitsgewinn.
Warum CHERIoT für Echtzeitsysteme interessant ist
Viele klassische Sicherheitsmechanismen sind für Echtzeitsysteme ungeeignet, weil sie unvorhersehbare Laufzeiten erzeugen.
CHERIoT wurde dagegen speziell für deterministisches Verhalten entwickelt:
- keine komplexen Page Tables,
- keine MMU-Abhängigkeiten,
- keine großen Sicherheits-Overheads,
- keine unkontrollierbaren Speicherlatenzen.
Dadurch bleibt das System auch für:
- industrielle Steuerungen,
- Automotive-Anwendungen,
- Medizintechnik,
- Luftfahrt,
- sicherheitskritische IoT-Geräte
interessant.
Überraschend geringe Hardwarekosten
Besonders spannend: Die zusätzlichen Hardwarekosten bleiben vergleichsweise moderat.
Laut den veröffentlichten Messungen:
- steigt die Chipfläche zwar messbar an,
- bleibt aber innerhalb realistischer Embedded-Grenzen,
- während die Performanceverluste typischerweise nur im niedrigen zweistelligen Prozentbereich liegen.
Für viele sicherheitskritische Anwendungen ist dieser Kompromiss äußerst attraktiv.
Warum CHERIoT ein möglicher Wendepunkt sein könnte
Die Embedded-Welt steht vor einem ähnlichen Problem wie die klassische IT vor 20 Jahren:
Immer mehr Vernetzung trifft auf veraltete Sicherheitsmodelle.
CHERIoT zeigt erstmals überzeugend, dass vollständige Speichersicherheit auch auf kleinen Mikrocontrollern möglich ist:
- ohne komplett neue Programmiersprachen,
- ohne gigantische Hardware,
- ohne Aufgabe der Echtzeitfähigkeit,
- und weiterhin kompatibel zu bestehendem C/C++-Code.
Gerade weil viele Unternehmen ihre bestehende Embedded-Software nicht vollständig neu entwickeln können, könnte genau dieser Punkt entscheidend sein.
Fazit
CHERIoT ist weit mehr als ein akademisches Forschungsprojekt. Die Architektur zeigt einen realistischen Weg, wie zukünftige Embedded- und IoT-Systeme deutlich widerstandsfähiger gegen Speicherangriffe werden könnten.
Die Kombination aus:
- hardwarebasierter Speichersicherheit,
- feingranularer Isolation,
- Echtzeitfähigkeit,
- und Kompatibilität zu bestehender Software
macht CHERIoT zu einem der spannendsten Sicherheitsansätze im Embedded-Bereich der letzten Jahre.
Sollte sich die Technologie in zukünftigen Mikrocontroller-Generationen etablieren, könnte sie langfristig denselben Einfluss auf Embedded-Systeme haben, den moderne Speicherverwaltung einst auf klassische Betriebssysteme hatte.



