Security in Mikrocontrollern

Was muss beachtet werden, damit die Security passt?

4. Februar 2022, 9:31 Uhr | Von Giancarlo Parodi
Embedded-Systeme entwicklen sich von eigenständigen Anwendungen zu vernetzten Systemen. Security-Software immer wichtiger, das gilt selbst für die kleinsten Implementierungen
© adobe.stock.com

Security in Embedded-Systemen wird immer wichtiger, da sie sich von eigenständigen zu vernetzten Systemen entwickeln. Sie speichern, empfangen und übertragen Daten, aktualisieren sich selbst mit neuer Software, werden fernüberwacht etc. – das gilt selbst für die kleinsten Implementierungen.

Die meisten Entwickler von Embedded-Systemen halten bereits kryptografische Themen für zu komplex. Tatsächlich aber umfasst Security viele Aspekte der Software und der Chip-Architektur, die speziell entwickelt werden und nahtlos zusammenarbeiten müssen, um ihre Ziele zu erreichen. Dieser Artikel befasst sich mit den wichtigsten Aspekten, die in Bezug auf die Security-Implementierungen von Mikrocontrollern für kleine Embedded-Systeme – mit geringen Rechenleistung und Speicherressourcen – zu berücksichtigen sind.

Anbieter zum Thema

zu Matchmaker+

Wer darf zugreifen?

Einer der ersten Schritte, um den Zugang zu einem wichtigen »Asset« zu sichern, besteht darin, dieses im Rahmen einer bestimmten Nutzungsrichtlinie verfügbar zu machen. Eine solche Regelung könnte z. B. einschränken, welcher Teil der Anwendungssoftware das Asset nutzen kann. Außerdem könnte die Nutzung über eine definierte funktionale Schnittstelle erzwungen werden, die nicht umgangen werden kann, und ideal in Hardware implementiert ist.

TrustZone-Zugriffsregel
Bild 1. TrustZone-Zugriffsregel.
© Renesas

Ein Beispiel für eine solche Isolationsfunktion ist die Technologie »TrustZone« von ARM. Diese ermöglicht eine Trennung der Benutzeranwendung in eine sogenannte »sichere« und »nicht sichere« Systemumgebung innerhalb der CPU. Aber wo wird die Richtlinie umgesetzt? In einer speziellen Stufe, bevor eine Speichertransaktion auf den internen Bus übertragen wird – dazu später mehr. Bei Regelverletzungen wird ein Ereignis (Exception) ausgelöst, wie in Bild 1 dargestellt: Die Anwendung kann reaktiv entscheiden, eine geeignete Aktion durchzuführen, wie z. B. einen Dienst neu zu starten, das Ereignis zu protokollieren, einen Fehler zu melden usw.

Bild 1 zeigt, dass »nicht sichere« Software nur auf »nicht sichere« Ressourcen zugreifen kann. Aber wie können die beiden Welten miteinander kommunizieren? Mithilfe eines Mechanismus: Um eine »Secure«-Funktion auszuführen, kann die CPU ihren Zustand über einen speziellen Befehl namens »Secure Gateway« (SG) in einen sicheren Zustand ändern. Ein SG-Befehl wird gepaart mit einer unmittelbar folgenden Verzweigung (Branch, d. h. einem sogenannten »Jump«) zur Adresse der gewünschten Secure-Funktion. Wenn die Secure-Funktion aus dem sicheren Modus zurückkehrt, wird der Prozessor wieder in den »nicht sicheren« Modus versetzt.

Nicht sichere abrufbare Funktionen
Bild 2. Nicht sichere abrufbare Funktionen
© Renesas

Ein Beispiel für die Ressourcenzuweisung zwischen sicherer und nicht sicherer Systemumgebung zeigt Bild 2: Kombinationen von SG und Branch-Adresse werden einem speziellen Bereich zugewiesen, der als »nicht sicher, abrufbar« (non-secure callable) definiert ist. Alle Parameter, wie z. B. Speicher-Pointer, die von den »nicht sicheren, abrufbaren« Funktionen übertragen werden, können einen speziellen »test target«-Befehl verwenden. So lässt sich z. B. sicherstellen, dass sich ein Speicherpuffer im nicht sicheren Speicherbereich befindet und sich nicht mit dem sicheren Speicherbereich überschneidet, um Datenlecks zu vermeiden.
Im sicheren Modus kann es erforderlich sein, eine nicht sichere Funktion zurückzurufen, um z. B. die Caller-Funktion über den Status der Anfrage zu informieren, RTOS-bezogene Benachrichtigungen auszugeben usw. Der Compiler erzeugt den speziellen Branch-Befehl, der den Zustand vor dem Aufruf auf »nicht sicher« setzt, und die Return-Adresse auf den sicheren Stack überträgt.

Embedded-Systeme sind stark Interrupt-gesteuert: wenn ein »nicht sicherer« Interrupt auftritt, während sich die CPU im sicheren Modus (»Secure Mode«) befindet, werden die Register standardmäßig auf dem sicheren Stack gespeichert und ihr Inhalt wird automatisch gelöscht. Damit soll verhindert werden, dass Informationen aus dem sicheren Bereich unbeabsichtigt preisgegeben werden. Die Aufteilung der Exceptions innerhalb jeder Systemumgebung wird durch eine eigene Interrupt-Vektortabelle für jede Systemumgebung unterstützt. In ähnlicher Weise gibt es eine separate Implementierung der Stack-Pointer, Systick-Timer usw.

Das hört sich alles sehr gut an, aber wie lassen sich diese sicheren Speicherbereiche und Abgrenzungen definieren? Es gibt zwei Einheiten, die parallel abgefragt werden: die SAU (Security Attribution Unit) und die IDAU (Implementation-Defined Attribution Unit). Bei jedem CPU-Zugriff antworten beide mit dem Security-Attribut, das mit dieser Adresse verbunden ist. Ihre kombinierte Antwort definiert das endgültige Adressattribut, wobei das restriktivste der beiden sich durchsetzt – ein sicherer Bereich kann nicht durch ein weniger sicheres Attribut außer Kraft gesetzt werden. Schließlich wird das Ergebnis anhand der in Tabelle 1 definierten Richtlinie bewertet. Wenn der Zugriff legitim ist, kann er fortgesetzt werden, andernfalls wird er blockiert und eine Exception ausgelöst.

TrustZone und MPU-Partitionierung
Bild 3. TrustZone und MPU-Partitionierung
© Renesas

Die Konfiguration der SAU – wie viele Bereiche werden unterstützt, die Standardeinstellungen usw. – kann zur Entwurfszeit erfolgen, während die Implementierung der IDAU implementierungsspezifisch, d. h. dem Gerätehersteller überlassen ist.

Memory Protection Units (MPUs) innerhalb jeder Domäne schützen einzelne Threads voreinander und erhöhen so die allgemeine Stabilität der Software. Bild 3 zeigt ein Beispiel für die Partitionierung auf einem Mikrocontroller, der TrustZone unterstützt.

Es stellt sich die Frage, ob bisher irgendein Security-bezogenes Ziel erreicht wurde? Eigentlich noch nicht. Die TrustZone kann Application Threads, die im sicheren Modus ausgeführt werden, von den nicht sicheren isolieren. Sie bietet aber keine Security per se und kann die Legitimität eines Zugriffs nicht erzwingen. Sie verhindert eher unbeabsichtigte Nutzung oder direkten Zugriff.


  1. Was muss beachtet werden, damit die Security passt?
  2. Der Entwickler ist gefragt

Das könnte Sie auch interessieren

Verwandte Artikel

Renesas Electronics Europe GmbH