Mikrocontroller-Sicherheit Kryptographie-Schlüssel sicher injizieren und nutzen

Autor / Redakteur: Giancarlo Parodi * / Michael Eckstein

Eine manipulationsgeschützte Schlüsselverwaltung ab Werk ist essenziell für Controller, die in vernetzten Geräten zum Einsatz kommen. Renesas hat dafür die Secure Crypto Engine entwickelt.

Firmen zum Thema

Schlüsselspezialist: Der RA6M4 ist die erste MCU der RA-Familie in der neuen Generation von Security-fokussierten MCUs von Renesas.
Schlüsselspezialist: Der RA6M4 ist die erste MCU der RA-Familie in der neuen Generation von Security-fokussierten MCUs von Renesas.
(Bild: Renesas Electronics)

Die zunehmende Nutzung vernetzter Geräte führt zu einer verstärkten Nachfrage nach Daten- und Informationssicherheit. So müssen etwa die Kommunikationskanäle und die lokalen Speicher der Geräte gesichert werden, um die Vertraulichkeit und Integrität der Benutzerdaten zu schützen. Entwickler von Embedded Devices stehen vor der Frage, wie sie die Möglichkeiten ihrer Anwendungen weiterentwickeln können, um diese neuen Anforderungen zu erfüllen.

Gesucht ist auch ein geeigneter Migrationspfad für vorhandene, aber veraltete Lösungen. Der Umgang mit Krypto-Schlüsseln ist dabei ein Problem, besonders deren Verwaltung in der Produktion – etwa wenn Fertigungsanlagen bislang ohne spezifische Security-Maßnahmen gearbeitet haben.

Ein Ansatz besteht darin, alle erforderlichen kryptografischen Funktionen mit Hilfe einer Software-Bibliothek zu implementieren, die entweder kommerziell unterstützt oder von der Open-Source-Gemeinschaft übernommen wird. Dies ist der wohl einfachste Ansatz, hat jedoch einige Nachteile. Typischerweise verbraucht eine solche Lösung eine beträchtliche Menge an CPU-Ressourcen, was den Stromverbrauch und die Systemlatenz erhöht.

Je nach Prozessortyp und Taktfrequenz nehmen viele Operationen mit asymmetrischer Kryptographie wie dem Setup einer TLS-verschlüsselten Verbindung zum Aufbau eines sicheren Kanals zwischen dem Gerät und einem Server recht viel Zeit in Anspruch, wodurch sich die Verbindungsleistung verlangsamt.

Das Integrieren eines Sicherheitscontrollers (Secure Element, SE) scheint das Problem zu lösen. Ein SE ist ein geschlossenes, isoliertes Subsystem und bietet höchstmöglichen physischen Manipulationsschutz. Entwickler müssen sich nicht um die kryptographische Implementierung kümmern, was den Aufwand reduziert. Es gibt aber auch Schwachstellen. Der zusätzliche Chip kostet Geld. Die Verbindung zur MCU über einen seriellen Bus wie I2C oder SPI ist ein Single-Point-of-Failure mit geringer Bandbreite.

Ein SE hat nur wenig Speicherplatz für Benutzerschlüssel. Oft ist der – meist geringe – Durchsatz der implementierten Krypto-Algorithmen nicht dokumentiert. Eine AES-Beschleunigung etwa zum Verarbeiten von Massendaten (z.B. eines verschlüsselten Firmware-Updates) ist möglicherweise überhaupt nicht verfügbar.

Hinzu kommt: Die im Chip implementierte Funktionalität lässt sich später nicht mehr aktualisieren. Und: Das Einfügen des Schlüssels in das SE erfordert möglicherweise zusätzliche Tools, die in den Produktionsfluss integriert werden müssen. Programmierhäuser könnten einen Teil des Aufwands abkürzen und einen sicheren Programmierservice anbieten, was aber ebenfalls die Kosten treiben würde.

Bild 1: Implementierung der Secure Crypto Engine mit eigenem RAM und Kryptographie-Prozessor.
Bild 1: Implementierung der Secure Crypto Engine mit eigenem RAM und Kryptographie-Prozessor.
(Bild: Renesas Electronics)

Eine Alternative ist das sichere Subsystem der Renesas Secure Crypto Engine (SCE, Bild 1). Bei zum SE vergleichbarer Funktion stellt es viel mehr Rechenleistung bereit. Es unterstützt AES-, RSA-, ECC- und Hashing-Algorithmen sowie eine echte Zufallszahlengenerierung (TRNG; True Random Number Generation) innerhalb einer isolierten On-Chip-Umgebung. Die SCE ermöglicht eine sichere, unbegrenzte Schlüsselspeicherung unter Verwendung eines werkseitig programmierten 256-Bit Hardware Unique Key (HUK) zur Ableitung von Keyschlüsseln, die zum Wrapping (Verschlüsseln) der Kundenschlüssel verwendet werden können.

Das Kryptosubsystem Secure Crypto Engine (SCE9) ist vollständig in der MCU enthalten und durch einen Access Management Circuit geschützt, der die Kryptoengine bei illegalen Zugriffsversuchen abschalten kann. Es führt alle Klartext-Krypto-Operationen unter Verwendung seines eigenen dedizierten internen Speicherbereichs durch, auf den kein CPU- oder DMA-zugänglicher Bus zugreifen kann. Die erweiterten Schlüsselspeicher- und Schlüsselverarbeitungsfunktionen der SCE9 stellen sicher, dass keine Klartextschlüssel jemals offengelegt oder im CPU-zugänglichen RAM oder nichtflüchtigen externen Speicher gespeichert werden.

Das Renesas-Subsystem Secure Crypto Engine

Die RA-Mikrocontroller-Familie umfasst die SCE in allen konnektivitätsfähigen Gruppen wie die RA6- und RA4-Derivate. Der RA6M4 ist die erste MCU der RA-Familie in der neuen Generation von Security-fokussierten MCUs von Renesas. Die implementierten Security-Features kombiniert mit umfassender Peripherie-IP sowie Funktions- und Pin-Kompatibilität zwischen den MCU-Serien machen die MCUs der RA-Familie zur geeigneten Wahl für nahezu jede vernetzte Embedded-Lösung.

Bei einer Security-fokussierten Anwendung besteht die Herausforderung schließlich nach wie vor darin, wie die Schlüssel- bereitstellung durchgeführt werden kann, ohne den Schlüsselinhalt während der Produktionsphase offenzulegen. Ein Ansatz ist die Verwendung eines Hardware-Security-Moduls (HSM), eines Programmier-Tools, das die Anwendungsschlüssel sicher verwalten und mit einer Provisioning-Backbone-Infrastruktur kommunizieren kann. Eine andere Möglichkeit ist die Verwendung eines Programmierdienstes in einem Highspeed-Programmier-Equipment, das viele ähnliche Bausteine in einem Batch für hochvolumige Anwendungen bereitstellen könnte.

Bild 2: Über ein dediziertes Befehlsprotokoll lässt sich ein Installationsschlüssel und eine verschlüsselte Nutzlast über die Boot-Firmware an die SCE übergeben.
Bild 2: Über ein dediziertes Befehlsprotokoll lässt sich ein Installationsschlüssel und eine verschlüsselte Nutzlast über die Boot-Firmware an die SCE übergeben.
(Bild: Renesas Electronics)

Alle MCUs von Renesas unterstützen bereits das werkseitige Programmieren über serielle und USB-Schnittstellen – und damit einen zuverlässigen und kostengünstigen Mechanismus für die Massenproduktion. Über diese Schnittstelle lassen sich Anwendungen samt ihrer Parameter programmieren. Renesas hat nun die integrierten Funktionen seiner Mikrocontroller der - und Folgeserien so erweitert, dass sie das Bereitstellen von Schlüsseln über die gewohnten Programmierschnittstellen unterstützen. Ein dediziertes Befehlsprotokoll ermöglicht es dem Anwender, einen Installationsschlüssel und eine verschlüsselte Nutzlast (der Anwendungsschlüssel wird injiziert) über die Boot-Firmware an die SCE-Grenze zu übergeben (Bild 2).

Hardware-Root-Key ist außerhalb der SCE nicht zugänglich

Das SCE-Subsystem enthält einen Hardware-Root-Key (HRK), mit dem sich Key Encryption Keys (KEKs) ableiten lassen. Mit diesen KEKs lassen sich Benutzerschlüssel verschlüsselt innerhalb der SCE übertragen. In der sicheren Umgebung erfolgt die Entschlüsselung während des Installationsprozesses. Wir bezeichnen den aus dem Verfahren KDF (HRK) resultierenden KEK als HRK*. Der HRK selbst ist abgesichert und außerhalb der SCE nicht zugänglich. Auch der HRK* existiert nur innerhalb der SCE.

Bild 3: Ablauf der Schlüsselinstallation mithilfe des DLM-Servers.
Bild 3: Ablauf der Schlüsselinstallation mithilfe des DLM-Servers.
(Bild: Renesas Electronics)

Wie bereitet ein Anwender also seinen Anwendungsschlüssel vor, der über die Boot-F/W-Schnittstelle im Werk eingespeist wird? Bild 3 zeigt diesen Vorgang. Der erste Schritt ist das Generieren eines Installationsschlüssels (grüner Schlüssel) und des Anwendungsschlüssels (gelber Schlüssel). Der Installationsschlüssel ist ein symmetrischer AES-Schlüssel, der Anwendungsschlüssel kann, muss aber nicht symmetrisch sein. Er muss lediglich ein von der SCE unterstützes Format haben.

Dieser Vorgang muss in einer sicheren Umgebung erfolgen. Der Anwendungsschlüssel ist die Nutzlast und wird mit dem Installationsschlüssel verschlüsselt. Natürlich muss auch der Installationsschlüssel verschlüsselt werden. Ansonsten kann jeder den Anwendungsschlüssel dechiffrieren, der die Protokollkommunikation abfängt oder die Installationsdaten kopiert, die in dem Programmier-Equipment der Fabrikanlage gespeichert sind.

Der Schlüsseldienst kommt kostenlos

Aber woher weiß der Anwender von der HRK*, um den Installationsschlüssel damit zu verschlüsseln? Das kann er nicht. Wie also teilt Renesas das Geheimnis, ohne es mitzuteilen? Um den Installationsschlüssel mit der HRK* zu verschlüsseln, ohne die inhaltlichen Informationen über die HRK selbst preiszugeben, bietet Renesas seinen Kunden einen kostenlosen Service an. Dieser Service wird über einen dedizierten sicheren Server zur Unterstützung des MCU Device Lifecycle Management (DLM-Server) bereitgestellt. Jeder Benutzer kann sich für den Dienst registrieren und die erforderlichen Daten für den Programmiervorgang generieren.

Die gesamte Kommunikation zwischen dem Anwender und dem Server ist sicher und über PGP verschlüsselt. Bei diesem Schema sendet der Benutzer den Installationsschlüssel (niemals den Anwendungsschlüssel!) sicher an den DLM-Server und erhält die verschlüsselte Version des HRK* zurück. Dies wird in dem Bild durch den grünen Schlüssel dargestellt, der in den blauen Schlüssel eingebettet ist. Nachdem der Anwender den verschlüsselten Installationsschlüssel (über das Programmierschnittstellenprotokoll) an die MCU weitergegeben hat, lässt sich der Installationsschlüssel innerhalb der SCE entschlüsseln.

Der grüne Installationsschlüssel ist innerhalb der SCE sicher übertragen worden. Nun kann der Installationsschlüssel wiederum zur Entschlüsselung des gelben Schlüssels innerhalb der SCE genutzt werden. An diesem Punkt ist der gelbe Schlüssel innerhalb der SCE sicher übertragen und rekonstruiert worden.

So gelangt der Anwendungsschlüssel in den MCU-Speicher

Was bleibt jetzt noch zu tun? Der gelbe Anwendungsschlüssel muss in den Speicher der MCU gelangen, andernfalls geht er verloren, wenn die Stromversorgung unterbrochen wird. Doch er darf nicht im Klartext exportiert werden, sonst ist die Vertraulichkeit des Schlüssels nicht mehr gewährleistet. Dafür hat die SCE-Implementierung noch eine weitere Funktion vorgesehen, die zum Bereitstellen einer sicheren Speicherfunktionalität eingesetzt wird: den Hardware Unique Key (HUK). Der HUK ist ein schreibgeschützter 256-Bit-Schlüssel, auf den ausschließlich der SCE-Access-Management-Circuit über einen dedizierten Bus zugreifen kann.

Wie beim HRK können KDFs den Hardware Unique Key mit der Schlüsselgenerierungsinformation kombinieren. Solche abgeleiteten Schlüssel implementieren das Schlüsselwrapping zum sicheren Speichern von Benutzerschlüsseln. Der HUK selbst wird in verschlüsseltem (Non-Plain) Format in einem isolierten Speicherbereich gespeichert. Daher ist er vor unerlaubtem Zugriff und Kopieren geschützt.

Bevor sich der gelbe Schlüssel aus dem SCE-Subsystem exportieren lässt, wird er mit einem vom HUK abgeleiteten Schlüssel umhüllt, so dass sein Inhalt in jedem Speicherbereich der MCU gespeichert werden kann. Bemerkenswerterweise hat der Installationsschlüssel nach der werkseitigen Programmierphase keinen Wert mehr, was bedeutet, dass er nicht mehr auf der MCU gespeichert werden muss (und in der Regel auch nicht mehr gespeichert wird).

Die SCE-Treiber stellen zusätzliche APIs zur Verfügung, um mit werkseitig installierten geschützten Schlüsseln eine Schlüsselaktualisierung im Feld durchzuführen. Dies wiederum bedeutet, dass nach Abschluss der werkseitigen Programmierung keine Abhängigkeit vom DLM-Serverdienst besteht. Diese Lösung bietet mehrere Vorteile:

  • Der gesamte Programm- und Daten-Flash der RA6M4-MCUs eignet sich zum Speichern des geschützten Schlüssels. Die Einzigartigkeit des HUK verhindert das Klonen und Kopieren von Schlüsseln auf eine andere MCU. Der Speicherort für den geschützten Schlüssel ist in den Programmierbefehlsparametern enthalten.
  • Durch den DLM-Server in Kombination mit der Programmierschnittstelle entfällt die Anforderung, einen sicheren Bereich innerhalb der Fabrikanlage zu implementieren, da alle schlüsselbezogenen Daten verschlüsselt gehandhabt werden.
  • Entwickler haben die volle Kontrolle über die verwendeten Anwendungsschlüssel. Diese werden niemals an Renesas übermittelt und dürfen die sichere Umgebung des Kunden niemals verlassen.
  • Eine Online-Kommunikation zwischen dem Programmier-Tool im Werk und dem DLM-Server ist nicht nötig. Der Installationsschlüssel ist entweder derselbe für eine bestimmte programmierte Firmware-Version oder derselbe für einen bestimmten Programmier-Batch von Schlüsseln. Daher können die Anwendungsschlüssel und die Installationsschlüssel „offline“ vorbereitet werden, bevor die Programmierung der Produktion beginnt.
  • Anwendung und Schlüsselmaterial werden über eine Schnittstelle programmiert. Renesas bietet Tools zur Unterstützung der Werksprogrammierung, etwa den Produktionsprogrammier PG-FP6 und den Renesas Flash Programmer (ein PC-basiertes, skriptfähiges Tool, das für Prototypen und Vorserien verwendet werden kann).

Diesen Beitrag lesen Sie auch in der Fachzeitschrift ELEKTRONIKPRAXIS Ausgabe 4/2021 (Download PDF)

Zusammenfassend lässt sich feststellen, dass Renesas eine kostengünstige und benutzerfreundliche Lösung bietet, die Entwickler bei der Migration auf höhere Security-Stufen in ihren Anwendungen unterstützt. Diese Funktionalität steht ab der RA6M4-MCU und den kommenden Cortex-M33-basierten Mikrocontrollern der RA6- und RA4-Serie zur Verfügung.

* Giancarlo Parodi ist Principal Engineer bei Renesas Electronics

(ID:47087047)