Autor: Giancarlo Parodi, leitender Produktmarketing-Ingenieur, Renesas Electronics
Übersetzung: Samantha Navarro
Heutzutage steigen die Speicheranforderungen eingebetteter Systeme aufgrund zunehmender Konnektivitätsfunktionen und Komplexität auf Anwendungsebene ständig. Viele Mikrocontroller auf dem Markt bieten eine Speicherdichte in der Größenordnung von einigen Megabyte, was noch vor einem Jahrzehnt als mehr als ausreichend und zukunftssicher für eine durchschnittliche Anwendung galt. Andererseits erfordert die Integration noch mehr nichtflüchtiger Speicher eine relativ große Siliziumfläche, was sich erheblich auf die Kosten des Produkts auswirkt. Eine geeignete Lösung besteht darin, externen Speicher zu verwenden, der in großen Mengen zu vergleichsweise günstigeren Preisen und mit verschiedenen Dichteoptionen erworben werden kann, die typischerweise von einigen wenigen bis zu mehreren zehn Megabyte reichen.
Die externe Speicherlösung eignet sich nicht nur zum Speichern von Anwendungsdaten, sondern auch von Anwendungscode, sodass keine Bedenken hinsichtlich der Roadmap des Anbieters zur Erfüllung zukünftiger Anforderungen bestehen. Andererseits müssen einige zusätzliche Aspekte berücksichtigt werden, beispielsweise die Leistung von Code, der aus dem externen Speicher ausgeführt wird, und wie der Anwendungscode vor Klonen oder Änderungen geschützt werden kann.
Für das erste Problem besteht die Lösung darin, Speicher mit einer breiten Schnittstelle zu verwenden, die die physikalische Leistung der seriellen Leitungen erhöht. Speicher mit einer Oktalschnittstelle bieten eine der besten Optionen im Hinblick auf das Gleichgewicht zwischen der Anzahl der E/A-Verbindungen und der erreichbaren Leistungssteigerung um das Zweifache im Vergleich zur alten Quad-SPI-Schnittstelle. Typischerweise unterstützen diese modernen Speicher auch etwas höhere Betriebsfrequenzen, was die Leistungsverbesserung noch deutlicher macht.
Der Schutz des Speicherinhalts erfordert den Einsatz kryptografischer Techniken zur Verschlüsselung des Codes, da es sonst für einen Angreifer einfach wäre, sich mit geringem Aufwand in den Speicher einzuloggen und die gespeicherten Informationen auszulesen. Um Latenzen im Entschlüsselungsprozess zu vermeiden, ist es notwendig, Designlösungen zu verwenden, die schnell sind und im Einklang mit dem Befehlsabrufprozess laufen, also aus Sicht der CPU transparent sind. Die neuesten MCUs von Renesas, wie beispielsweise die RA8x1-Serie, implementieren eine Architektur namens „Decode-on-the-Fly“ (DOTF), die genau diesem Zweck dient. Eine konzeptionelle Darstellung der Lösung ist in Abbildung 1 zu sehen.
Abbildung 1. DOTF-Architektur
Das Prinzip ist recht einfach und basiert auf dem AES-Verschlüsselungs-/Entschlüsselungsstandard unter Verwendung des Zählermodus (CTR) gemäß NIST SP800-38A. Das Funktionsprinzip des CTR-Modus ist in Abbildung 2 dargestellt.
Abbildung 2. CTR-Modus (Quelle: NIST SP800-38A)
Im CTR-Modus wird eine Reihe von Zählern als Eingabe für eine Blockverschlüsselungsfunktion verwendet, um eine geheime Ausgabe zu generieren, die dann mit dem Klartext (oder Chiffretext) kombiniert wird, um die Nachrichtendaten zu verschlüsseln (oder zu entschlüsseln). Die Reihenfolge der Zähler sollte so gewählt werden, dass jeder Eingabeblock im Satz anders und einzigartig ist. Diese Anforderung gilt für alle „Nachrichten“ (also Datenelemente), die mit demselben Schlüssel verschlüsselt werden.
Eine interessante Eigenschaft des CTR-Modus besteht darin, dass die mit dem Zähler verbundenen Verschlüsselungsfunktionen unabhängig voneinander im Voraus ausgeführt werden können und nicht darauf gewartet werden muss, dass der Datenblock verfügbar wird. Dies trägt dazu bei, die Latenz beim Lesen verschlüsselter Daten aus dem Oktalspeicher zu reduzieren, da die Ausgabeblockgenerierung parallel erfolgen kann. Darüber hinaus kann ein einfacher Textblock unabhängig von jedem anderen Block abgerufen werden, was zum Erhalten von Programmdaten geeignet ist, da der Prozessor je nach Programmablauf möglicherweise anfordert, Code an nicht sequentiellen Adressstellen zu lesen.
Die zur Definition der Zähler verwendeten Parameter müssen sorgfältig ausgewählt werden, um ihre Einzigartigkeit sicherzustellen. Ein AES-Block hat eine Größe von 16 Bytes (128 Bit); daher muss der Zähler auch 128 Bit breit sein. Jeder verschlüsselte Block im Speicher ist außerdem 16-Byte-ausgerichtet, und eine Verkettung eines Anfangswerts und der Speicheradresse kann verwendet werden, um einen eindeutigen Zähler zu erstellen.
Der Anfangswert ist im Wesentlichen eine „Nonce“ (eindeutige Zufallszahl, die einmal verwendet wird) und die Adresse des verschlüsselten Blocks, der gelesen wird, hat die 4 LSBs maskiert, um den Zählerwert gemäß dem folgenden Schema zu erstellen: Zähler [ 127:0] = Anfangswert [127:28] || (Speicheradresse [31:4] >> 4).
Die Implementierung umfasst einige zusätzliche coole Funktionen, die sehr hilfreich sind, um sie zu einer flexiblen und benutzerfreundlichen Lösung zu machen. Erstens kann die Anwendung eine Adressgrenze definieren, für die die On-the-Fly-Entschlüsselung verwendet oder auf andere Weise umgangen wird, wie in Abbildung 3 dargestellt.
Abbildung 3. DOTF-Grenzwerte
Dies ist sehr praktisch, wenn die Anwendung den Inhalt des Flash-Speichers zwischen Code und anderen Daten aufteilen möchte, wobei der Code im laufenden Betrieb entschlüsselt wird und die Daten einfach gelesen werden, ohne entschlüsselt zu werden. Letzteres ermöglicht der Anwendung auch die Verwendung eines anderen Verschlüsselungsschlüssels oder -modus für die Daten und vermeidet die gemeinsame Nutzung des Verschlüsselungs-/Entschlüsselungsschlüssels des Anwendungscodes für mehrere Zwecke.
Was die Ausrichtung des DOTF-Bereichs anbelangt, so wird der AES-Verschlüsselungsstandard zwar eine Mindestausrichtung von 16 Bytes vorsehen, angesichts der typischen Organisation eines Flash-Speichers wird die Grenze jedoch auf eine Sektor- oder Blockgröße (die Mindestgröße des Flash-Laufwerks) gelegt kann während der Programmierung gelöscht werden). Bei der Implementierung kann die DOTF-Grenze für eine 4-KB-Adressausrichtung konfiguriert werden; Tatsächlich vermeidet die Anwendung ohnehin einen Speicherblock, der DOTF- und Nicht-DOTF-Daten speichert, was Feldaktualisierungen und Werksprogrammierung unnötig erschweren würde. Das Flash-Speichergerät wird linear dem adressierbaren Raum der MCU zugeordnet, und der IP-Octa ist für die Ausgabe der entsprechenden Lesebefehle verantwortlich; Dies wird allgemein als XiP-Betriebsart (Execution in Place) bezeichnet. Für den verschlüsselten Bereich kann jeder Zugriff auf die angeforderten 16-Byte-Blöcke effizient durchgeführt werden, indem die erforderliche Adresse einmal ausgegeben und die Daten dann kontinuierlich gelesen werden, wodurch der Overhead des OctaSPI-Protokolls minimiert wird.
Ein weiterer wichtiger Aspekt ist die Handhabung und das Laden des Entschlüsselungsschlüssels. Auf Geräten, die DOTF unterstützen, ist eine dedizierte AES-Engine in der IP implementiert, der Schlüssel für den Entschlüsselungsprozess wird jedoch über eine private Busverbindung auf die sichere IP von Renesas hochgeladen; Dadurch wird verhindert, dass der Schlüsselwert über die interne Busverbindung der MCU verloren geht. Darüber hinaus sind die von Renesas Secure IP verarbeiteten Schlüssel verschlüsselt, sodass sie ohne Vertraulichkeits- und Integritätsprobleme sicher im Speicher gespeichert werden können. Die DOTF-Engine unterstützt 128-, 192- und 256-Bit-Schlüsselgrößen für maximale Flexibilität und zukunftssichere Optionen, und es gibt keine Begrenzung für die Anzahl verschiedener Schlüssel, die zum Entschlüsseln eines bestimmten Bildes verwendet werden können. Letzteres bedeutet, dass bei jedem Firmware-Update bei Bedarf ein anderer Schlüssel verwendet werden kann und es nicht erforderlich ist, denselben Schlüssel zwischen verschiedenen MCUs zu teilen. Die Vorbereitung des neuen Images kann bequem offline auf einem sicheren Host erfolgen, bevor das Image-Update an ein Gerät im Feld gesendet oder das verschlüsselte Image zur Programmierung an einen Vertragshersteller gesendet wird. Der anfängliche Entschlüsselungsschlüssel oder ein „Schlüsselaktualisierungsschlüssel“ (zur Aktualisierung des Entschlüsselungsschlüssels vor Ort) kann während der Produktion sicher in die MCU eingefügt werden. Injizierte Schlüssel, ob im Feld oder in der Produktion, sind immer an die spezifische MCU gebunden, sodass ein Klonen vermieden wird.
Darüber hinaus bietet IP Gegenmaßnahmen zum Schutz vor Seitenkanalangriffen.
Der gesamte Laufzeitvorgang wird transparent von der Hardware ausgeführt, und die bereitgestellten Softwaretreiber sind für die Initialisierung und das Laden der Parameter für den DOTF-Vorgang (Anfangswert, Grenzwerte) und des Schlüssels verantwortlich, bevor der Vorgang beginnen kann.
Alle MCUs, die eine Speichererweiterbarkeit und komplexe Anwendungsanforderungen benötigen, profitieren von dieser Art von Lösung und stellen sicher, dass der MCU-Entwickler von einer robusten Anwendungs-Roadmap profitiert und gleichzeitig die Softwareinvestitionen schützt. Weitere Informationen zur MCU RA-Familie finden Sie unter www.renesas.com/ra.
