Embedded Security Schutz externer Speicher und Software-IP

Anbieter zum Thema

Renesas Electronics Germany GmbH

Bürklin GmbH & Co. KG

MES Electronic Connect GmbH & Co. KG

Cadlog Group

Externer Speicher bringt Flexibilität – aber auch Risiken. Daher verfügen moderne Mikrocontroller über Schutzmechanismen wie DOTF nutzen, um Code und IP sicher auszuführen.

Der Vernetzungsgrad und die Komplexität von Embedded-Systemen steigt kontinuierlich an. Damit geht auch eine Zunahme des Speicherbedarfs einher. Viele der auf dem Markt erhältlichen Mikrocontroller bieten eine Speicherdichte im Bereich von wenigen Megabyte, da dies bis vor einem Jahrzehnt für eine durchschnittliche Anwendung noch als mehr als ausreichend und zukunftssicher galt. Heute existiert die Option für die Integration von mehr nichtflüchtigem Speicher, was aber eine relativ große Siliziumfläche erfordert und sich erheblich auf die Produktkosten auswirkt.

Eine geeignete Alternative ist die Verwendung von externem Speicher, der in großen Mengen zu relativ niedrigen Preisen zur Verfügung steht und in verschiedenen Optionen für die Speicherdichte erhältlich ist. In der Regel sind Speicherkapazitäten ab wenigen bis zu hunderten von Megabytes verfügbar.

Die externe Speicherlösung eignet sich nicht nur zur Speicherung von Anwendungsdaten, sondern auch von Anwendungscode. Damit gibt es keine Bedenken, was die Roadmap des Anbieters betrifft, um zukünftige Anforderungen erfüllen zu können. Andererseits müssen zusätzliche Aspekte berücksichtigt werden. Hierzu zählen die Leistung des Programms, das auf dem externen Speicher ausgeführt wird, und wie dieser geschützt werden kann, um nicht geklont oder verändert zu werden.

Datensicherheit bei hohen Durchsatzraten

Die Lösung für das erste Problem ist die Verwendung eines Speichers mit einer breiten Schnittstelle, die den physikalischen Durchsatz für die seriellen Leitungen erhöht. Speicher mit oktaler Schnittstelle bieten einen der besten Kompromisse zwischen der Zahl der I/O-Verbindungen und der erreichbaren Durchsatzsteigerung. Verglichen mit herkömmlichen Quad-SPI-Schnittstelle kann der Durchsatz verdoppelt werden. Meist unterstützen moderne Speicher auch höhere Betriebsfrequenzen, wodurch die Leistungssteigerung noch deutlicher ausfällt.

Um den Inhalt des Speichers zu schützen, sind Verschlüsselungstechniken zum Schutz des Codes notwendig. Andernfalls wäre es für einen Angreifer trivial, sich mit dem Speicher zu verbinden und die gespeicherten Informationen mit geringem Aufwand auszulesen. Um Wartezeiten für den Entschlüsselungsprozess zu vermeiden, gilt es, Lösungen zu nutzen, die schnell und im Einklang mit dem Befehlsabrufprozess ausgeführt werden. Das heißt, sie müssen aus Sicht der CPU transparent sein.

Die neuesten MCUs von Renesas, wie z. B. die RA8x1-Serie, implementieren eine sogenannte DOTF-Architektur (Decryption on the Fly), die genau diesen Zweck erfüllt. Eine konzeptionelle Darstellung der Lösung zeigt Bild 1. Das Prinzip ist relativ einfach und basiert auf dem AES-Verschlüsselungs-/Entschlüsselungsstandard unter Verwendung des Counter-Modus (CTR) gemäß NIST SP800-38A. Bild 2 zeigt das Prinzip des CTR-Modus.

CTR-Modus: Präemptive Verschlüsselung

Im CTR-Modus wird eine Reihe von Zählern als Eingabe für eine Blockchiffrierfunktion verwendet, um eine geheime Ausgabe zu erzeugen. Diese wird dann mit dem Klartext (oder Chiffretext) durch eine exclusive-ORed-Verknüpfung verbunden, um die Daten der Nachrichten zu verschlüsseln (oder zu entschlüsseln). Die Reihenfolge der Zähler muss so gewählt werden, dass jeder Eingabeblock des Datensatzes unterschiedlich und eindeutig ist. Diese Anforderung gilt für alle „Nachrichten“ (d. h. Datenelemente), die mit demselben Schlüssel codiert werden.

Eine besonders nützliche Eigenschaft des CTR-Modus ist, dass die mit dem Zähler verbundenen Verschlüsselungsfunktionen unabhängig voneinander im Voraus ausgeführt werden können. Es muss nicht gewartet werden, bis der Datenblock verfügbar ist. Dadurch verringert sich die Latenz beim Auslesen der verschlüsselten Daten aus dem Octa-Speicher, da die Generierung des Ausgabeblocks parallel erfolgen kann. Außerdem lässt sich ein bestimmter Klartextblock unabhängig von allen anderen Blöcken wiederherstellen. Dies ist für das Auslesen von Programmdaten nützlich, da der Prozessor je nach Programmablauf das Ausführen des Programms an nicht aufeinanderfolgenden Adresspositionen anfordern kann.

Die zur Definition der Zähler verwendeten Parameter müssen sorgfältig ausgewählt werden, um ihre Eindeutigkeit zu gewährleisten. Ein AES-Block ist 16 Byte (128 Bit) lang, daher muss der Zähler ebenfalls 128 Bit lang sein. Jeder kodierte Block im Speicher ist ebenfalls auf 16 Bytes ausgerichtet. Um einen eindeutigen Zähler zu generieren, kann eine Verkettung aus einem Initialwert und der Speicheradresse genutzt werden.

Der Initialwert ist im Wesentlichen eine Nonce (einmalige Zufallszahl, die nur einmal verwendet wird). Die Adresse des gelesenen verschlüsselten Blocks hat die 4 LSBs ausgeblendet, um den Zählerwert nach folgendem Schema zu erzeugen: Zähler [127:0] = Initialwert [127:28] || (Speicheradresse [31:4] >> 4).

Flexible Anpassbarkeit der Lösung

Die Implementierung enthält einige weitere interessante Funktionen, die sehr nützlich sind, um eine flexible und benutzerfreundliche Lösung zu schaffen. Zunächst kann die Anwendung eine Adressgrenze definieren, für die die Entschlüsselung im laufenden Betrieb angewendet oder auf andere Weise umgangen wird (siehe Bild 3).

Dies ist praktisch, wenn die Anwendung den Flash-Inhalt in Code und andere Daten aufteilen möchte. Hierbei wird der Code während der Ausführung entschlüsselt und Daten werden ohne Entschlüsselung gelesen. Das ermöglicht es der Anwendung zudem, einen anderen Schlüssel oder Verschlüsselungsmodus für die Daten zu nutzen. Ebenso kann vermieden werden, dass der Schlüssel für die Ver- und Entschlüsselung des Anwendungscodes für mehrere Zwecke gemeinsam zum Einsatz kommt.

Für die Ausrichtung des DOTF-Bereichs gilt: obwohl der AES-Verschlüsselungsstandard eine minimale Ausrichtung von 16 Bytes voraussetzt, sollte der Schutzmechanismus angesichts der typischen Struktur eines Flash-Speichers eher auf einer Sektor- oder Blockgröße basieren (die Mindestgröße einer Flash-Einheit, die beim Programmieren gelöscht werden kann). Bei Implementierung kann die DOTF-Begrenzung auf eine Adressausrichtung von 4 KByte konfiguriert werden. In der Praxis sollte die Anwendung aber vermeiden, dass in einem Speicherblock sowohl DOTF- als auch Nicht-DOTF-Daten gespeichert werden. Dies würde Updates im laufenden Betrieb sowie die werksseitige Programmierung unnötig erschweren.

Der Flash-Speicher wird linear in den adressierbaren Bereich der MCU abgebildet. Die Octa-IP sorgt für die Ausgabe der entsprechenden Lesebefehle. Diese Betriebsart wird als XiP (Execute-in-Place) bezeichnet. Für den verschlüsselten Bereich kann jeder Zugriff auf die angeforderten 16-Byte-Blöcke effizient erfolgen. Die gewünschte Adresse muss dabei nur einmal angegeben werden. Dann werden die Daten kontinuierlich gelesen, was den Overhead des OctaSPI-Protokolls auf ein Minimum reduziert.

Ein weiterer Aspekt ist die Handhabung und das Laden des Entschlüsselungsschlüssels. In DOTF-fähigen Bausteinen ist eine dedizierte AES-Engine in der IP implementiert. Der Schlüssel für den Entschlüsselungsprozess wird jedoch über eine eigene Busverbindung zur Secure IP von Renesas (RSIP) geladen. Dies verhindert, dass der Schlüsselwert über die interne MCU-Busverbindung offengelegt wird. Darüber hinaus sind die von der Secure IP von Renesas verwalteten Schlüssel selbst verschlüsselt. Somit können sie sicher im Speicher abgelegt werden, ohne dessen Vertraulichkeit und Integrität zu gefährden.

Die DOTF-Engine unterstützt 128-, 192- und 256-Bit-Schlüssel für maximale Flexibilität und Zukunftssicherheit. Es gibt keine Begrenzung für die Anzahl der verschiedenen Schlüssel, die zur Entschlüsselung eines bestimmten Images verwendet werden können. Das bedeutet, dass für jedes Firmware-Update auf Wunsch ein anderer Schlüssel verwendet werden kann. Es ist nicht erforderlich, denselben Schlüssel für verschiedene MCUs zu verwenden. Die Erstellung des neuen Images kann bequem offline auf einem sicheren Host erfolgen, bevor das Image-Update an ein Endgerät oder das verschlüsselte Image zur Programmierung an einen Vertragshersteller gesendet wird. Der ursprüngliche Entschlüsselungsschlüssel oder ein „Key Update Key“ (zur Aktualisierung des Entschlüsselungsschlüssels während des Betriebs) kann während der Produktion sicher in die MCU eingespeist werden. Die injizierten Schlüssel sind sowohl während des Betriebs als auch in der Produktionsphase immer an die spezifische MCU gebunden, um klonen zu verhindern. Darüber hinaus bietet die IP zusätzliche Gegenmaßnahmen zum Schutz vor Seitenkanalangriffen.

Alle Laufzeitoperationen werden transparent von der Hardware ausgeführt. Die mitgelieferten Softwaretreiber sorgen dafür, dass die Parameter für die DOTF-Operation (Initialwert, Begrenzungen) und der Schlüssel initialisiert und geladen werden, bevor die Operation gestartet werden kann. Alle MCUs, die eine Speichererweiterung und komplexe Anwendungsanforderungen erfordern, profitieren von einer solchen Lösung. Sie bietet MCU-Entwicklern eine solide Anwendungs-Roadmap und schützt gleichzeitig Software-Investitionen.  (sg)

(ID:50374017)