Security in Mikrocontrollern
Was muss beachtet werden, damit die Security passt?
Fortsetzung des Artikels von Teil 1
Der Entwickler ist gefragt
Der Entwickler muss entscheiden, welche Anwendungsbereiche isoliert werden sollen. Die TustZone ist hilfreich und kann im Vergleich zu einer klassischen MPU in der Software nicht umgangen werden. Daher sind Routinen im Zusammenhang mit kryptografischen Operationen eine gute Wahl. In jedem Fall muss das System die TrustZone-Einstellungen gleich zu Beginn der Ausführung anwenden und die Manipulation solcher Abgrenzungen verhindern – z. B. durch Speicherung in einem Bereich, der von der CPU nicht direkt verändert werden kann.
Bewährte Praxis ist es, den Umfang der Funktionen, die in der sicheren System- umgebung implementiert sind, möglichst gering zu halten. Dies senkt die Wahrscheinlich für mögliche Bugs, Laufzeitfehler und die missbräuchliche Ausnutzung von Softwarefehlern. Ein Nebeneffekt ist, dass die Validierung der Funktionalität während der Fehlersuche und des Tests viel einfacher wird.
Welche Krypto-bezogenen Ressourcen soll eine MCU bereitstellen? Das hängt von der Komplexität der Anwendung ab. Für eine Einstiegslösung könnte eine reine Softwareroutine ausreichen. Die Unterstützung von Kryptoalgorithmen durch Hardware reduziert jedoch den Stromverbrauch und die Code- größe bei höherer Ausführungsgeschwindigkeit.
Der erste Building-Block der meisten kryptografischen Protokolle ist ein TRNG (True Random Number Generator), der auf seine Entropie-Eigenschaften und die Qualität des Zufalls geprüft werden muss, da ein fehlerhafter RNG die Security eines jeden Algorithmus, der ihn nutzt, beeinträchtigen kann.
Für die lokale Speicherung ist die Unterstützung symmetrischer Algorithmen wie AES mit mehreren Betriebsmodi nahezu obligatorisch, um große Datenmengen zu ver- und entschlüsseln. In Kombination mit Hash-Algorithmen (»kryptografisch sichere Prüfsummen«) wie SHA-2 oder SHA-3 kann die Anwendung einfache Authentifizierungsprüfungen durchführen und nachweisen, dass die Dateninhalte nicht verändert wurden.
Für hoch entwickelte Konnektivität können asymmetrische Verschlüsselungsalgorithmen wie RSA oder ECC die Identitätsüberprüfung in Client/Server-Verbindungen unterstützen, bei der Ableitung ephemerer Session-Keys helfen oder die Quelle und Legitimität eines Firmware-Updates checken. Solche Beschleuniger müssen auch in der Lage sein, Schlüssel auf dem Chip für die lokale Nutzung zu generieren.
Die eigentliche Herausforderung ist jedoch die Schlüsselverwaltung, da die Schlüssel vertraulich, integer und verfügbar gehalten werden müssen. Dafür müssen viele Szenarien berücksichtigt werden: Wann wird der Schlüssel in die MCU eingespeist/gespeichert, wie wird er übertragen, wie wird er in die Krypto-Hardware geladen und wie wird er vor unbefugtem Zugriff geschützt?
Idealerweise sollte die Anwendung niemals Schlüssel im Klartext verarbeiten, um eine gefährliche Darstellung zu vermeiden. Eine einfache Möglichkeit, dies zu verhindern, besteht darin, die Schlüssel innerhalb des sicheren Bereichs der TrustZone zu speichern, am besten jedoch in einem speziellen, isolierten On-Chip-Subsystem. Sind die Schlüssel erst einmal im nichtflüchtigen Speicher abgelegt, helfen Technologien wie das Schlüssel-Wrapping (Key Encryption), die Privatsphäre zu schützen. Indem die verschlüsselten Daten auf jeder MCU einmalig sind, wird das Risiko eines Schlüsselverlusts weiter verringert und die Gefahr des Klonens beseitigt. Für einen solchen Mechanismus ist eine »Root-of-Trust« für die Speicherung erforderlich. Dabei handelt es sich um einen exklusiven »Key Encryption Key«, der für jede MCU einzigartig ist. Das stellt sicher, dass die Kompromittierung eines bestimmten Bausteins keinen Angriff auf alle ähnlichen Bausteine ermöglicht.
DPA- und SPA-Angriffe protokollieren und analysieren den Leistungsverbrauch, um den Schlüsselwert zurückzuverfolgen. Diese Angriffe lassen sich zunehmend kostengünstig und schnell umsetzen, selbst für wenig erfahrene Angreifer mit begrenzten Ressourcen. Wenn der physische Zugriff auf den Baustein bedenklich ist, sind ohne andere Zugriffskontrollen im System Gegenmaßnahmen gegen diese Bedrohungen in den Krypto-Engines erforderlich. Äußerst empfehlenswert ist darüber hinaus eine Überwachung von Signalen, die mit dem Gehäuse verbunden sind und die MCU benachrichtigen sowie möglicherweise einen Zeitstempel des Manipulationsereignisses vornehmen können.
Das isolierte Subsystem soll es dem Anwender ermöglichen, ausgewählte Schlüssel in den Baustein einzubringen und diese verschlüsselt und sicher zu speichern, sodass sie für die spätere Nutzung durch die Anwendung bereit sind. Die MCU sollte zudem eine Schnittstelle unterstützen, über die dies sowohl im Feld als auch werkseitig erfolgen kann, sodass eine einfache erstmalige Bereitstellung und spätere Aktualisierung im Feld möglich sind. Diese Schritte müssen abgesichert sein und dürfen keine Schlüsselinhalte während der Übertragung offenlegen.
In modernen MCUs sind diverse Funktionseinheiten in der Lage, selbstständig Daten zum und vom Speicher oder von der Peripherie zu übertragen, um die Leistung zu verbessern und die verfügbare Bandbreite effizient zu nutzen. Einige Beispiele sind DMA-Engines, Grafik-Controller, Ethernet-Controller und dergleichen. Es ist von entscheidender Bedeutung, dass die MCU die Security-Attribute solcher Einheiten festlegen und spezifische »Zugriffsfilter« für die Kommunikationsendpunkte, wie Speicher und im Speicher abgebildete Peripherie, implementieren kann.
Jeder Prozessor ist ohne die Möglichkeit der Eingabe und Ausgabe von Signalen nutzlos. Der Schutz solcher Schnittstellen vor Missbrauch ist eine grundlegende Voraussetzung, um Ma- nipulationen zu verhindern, da das nun einmal das übliche Verfahren zur Interaktion mit der MCU ist. Der vorausschauende Entwickler sollte prüfen, ob die MCU den Zugriff auf sichere I/O-Ports und die Peripherie einschränken kann. Dadurch lässt sich verhindern, dass Software missbräuchlich die Kontrolle übernimmt, die Kommunikation stört oder ausspäht. Gleichzeitig sollten die Ports und die Peripherie voneinander isoliert bleiben.
Während der Entwicklung ist zum Tes- ten der Software ein Jtag-basierter De- bugger fast unverzichtbar. Eine solche Schnittstelle kann auf die meisten Ressourcen des Chips zugreifen und stellt daher eine kritische Hintertür für jede im Feld eingesetzte Anwendung dar. Die Anwendungsfälle zur Absicherung der Jtag-Schnittstelle sind sehr unterschiedlich: Entweder wird sie dauerhaft gesperrt oder die Debugging-Funktion bleibt im Feld erhalten, aber der Zugriff wird geschützt. Unabhängig von der gewählten Strategie darf der Schutz nicht umgangen werden, indem die ordnungsgemäße Autorisierung über einen Authentifizierungsschlüssel erzwungen wird und der Zugriff nur nach erfolgreichem Abschluss eines Challenge-Response-Protokolls möglich ist. Schließlich muss der Baustein auch noch einen Mechanismus unterstützen und sichern, mit dem er im Falle einer Fehleranalyse an das Werk zurückgeschickt werden kann. Dabei müssen möglicherweise alle gespeicherten geheimen Daten gelöscht werden, während die Schnittstelle bis zum Erreichen des Bestimmungsortes gesichert bleibt.
Das endgültige Application-Image muss nach dem Einsatz im Feld möglicherweise in einigen Bereichen unveränderlich gemacht werden, um zu gewährleisten, dass es sich jederzeit in einem bekannten Zustand befindet. Um diese Anforderung zu erfüllen, muss der Mikrocontroller in der Lage sein, benutzerdefinierte Bereiche des nichtflüchtigen Speichers dauerhaft vor Änderungen zu schützen.
Darüber hinaus muss beachtet werden, dass jeder Mikrocontroller vor der Auslieferung ein langwieriges Testverfahren durchläuft. Viele solcher Testergebnisse (Trimmwerte, produktionsspezifische Daten etc.) sowie andere Einstellungen werden auf dem Baustein gespeichert. Dieser spezielle Testmodus ist zwar für einen Endanwender nicht von Bedeutung, aber er kann auf alle Chip-Ressourcen zugreifen, sie kontrol- lieren und möglicherweise manipulieren. Der Mikrocontroller-Hersteller sollte sicherstellen, dass eine solche potenzielle Sicherheitslücke nicht böswillig oder versehentlich genutzt werden kann, sobald der Baustein das Werk verlassen hat und sich in den Händen des Kunden befindet.
Jobangebote+ passend zum Thema
RA-Serie unterstützt alle Security-Anforderungen
Die Suche nach einem Mikrocontroller, der die oben genannten Anforderungen erfüllt, kann eine schwierige Aufgabe sein. Aber Renesas hat die Mikrocontroller der RA-Serie genau für diese Anforderungen entwickelt. Die RA6- und RA4-Serien umfassen Bausteine mit einer ARM Cortex-M33-CPU mit TrustZone und Secure MPUs. Sie ermöglichen die einfache Programmierung sicherer Bereiche für alle eingebauten Speichertypen. Sie enthalten die Secure Crypto Engine, ein Krypto-Subsystem (Bild 4), das Secure-Funktionen bei hoher Leistung und geringen Stücklistenkosten bietet. Die SCE umfasst hochmoderne kryptografische Beschleuniger, einen TRNG, unterstützt die Schlüsselgenerierung, die Schlüssel-Injektion, implementiert SPA/DPA-Gegenmaßnahmen und einen Hardware Unique Key als Root-of-Trust. Die DMA-Controller, Bus-Master, Peripherien und I/O-Ports verfügen über dedizierte Security-Attribute. Zudem ist eine Manipulationserkennungsfunktion implementiert. Das inte- grierte Device-Lifecycle-Management beherrscht sicheres/nicht sicheres Debugging, Programmierung, unterstützt Return-Material-Prozeduren und schützt den Testmodus. Nichtflüchtige Speicher können nach Wahl des Anwenders blockweise dauerhaft geschützt werden.
Der Autor
Giancarlo Parodi
ist Principal Engineer bei Renesas Electronics. Er verfügt über mehr als 20 Jahre Erfahrung in der Applikationsentwicklung und im technischen Support bei Halbleiterherstellern sowie in der Entwicklungsarbeit in der Telekommunikations- und Mobilfunkbranche. Mit seinem umfangreichen Know-how in 32-Bit-High-End-Mikrocontroller- und Mikroprozessor-Plattformen ist er derzeit bei Renesas für verschiedene technische und sicherheitsrelevante Aspekte von ARM-basierten MCUs der nächsten Generation verantwortlich.
- Was muss beachtet werden, damit die Security passt?
- Der Entwickler ist gefragt
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Neues SoC für ADAS- und AD-Funktionen
Level 2+ und Level 3 für das Volumensegment
Renesas/Fixstars
Automotive SW Platform Lab für Deep Learning
Renesas Electronics
Knapp 40 Prozent Umsatzwachstum
MCUs für die Motorsteuerung
Zielanwendungen: Inverter, Gebäudeautomatisierung und Industrie
Renesas Electronics
Übernahme von Celeno abgeschlossen
Auto-OS
Hardware und Software entkoppeln
16-Bit-MCUs
Mehr Security, Konnektivität und funktionale Sicherheit
Renesas Electronics
Einstieg in den FPGA-Markt
