In der Security Analyse haben wir festgestellt, dass der Flash Speicher des verwendeten EPS32 Controllers ausgelesen und manipuliert werden kann. Als Gegenmaßnahme ist ein Hardware- und Software-Schutz am ESP32 erforderlich, wie zum Beispiel „Secure Boot“. Das Ziel dieses Verfahrens ist es, die Integrität der auf dem Gerät ausgeführten Software durch Signaturen zu schützen.
Unmittelbar nach dem Einschalten des ESP32 durchläuft der Controller mehrere Boot-Phasen, bevor die eigentliche Software des Gerätes ausgeführt wird. In der ersten Boot-Phase wird der sog. ROM-Code geladen, eine vom Hersteller fest eingebrannte Software. Dieser Code ist unveränderlich und bietet unter anderem dadurch eine sogenannte Root-of-Trust für die nachfolgenden Boot-Phasen. Die Aufgabe des ROM-Codes ist es u.a. die Signatur des mitgelieferten Bootloaders zu verifizieren und diesen dann im Anschluss auszuführen.
Der Bootloader stellt die zweite Boot-Phase dar. In dieser zweiten Phase wird wiederum die eigentliche Applikations-Software verifiziert und gestartet. Insgesamt ergibt sich so eine abgesicherte Boot-Kette.
„Eine höhere Sicherheit gegenüber der ersten Variante."
Je nach Hardware-Revision des ESP32 stehen unterschiedliche Signaturverfahren zur Verfügung. In früheren Revisionen wird das sog. Secure Boot V1 verwendet. Dabei wurde der Bootloader noch durch einen symmetrischen Schlüssel signiert, die Applikation bereits durch ein asymmetrisches Verfahren. In der aktuellen Secure Boot V2 Variante werden jeweils der Bootloader und die Applikation durch ein asymmetrisches Verfahren mit einem 3072bit RSA-Schlüssel signiert. Der Vorteil der zweiten Variante besteht u.a. darin, dass der geheime symmetrische Schlüssel nicht selbst auf dem ESP32 gespeichert werden muss. Stattdessen wird nur der öffentliche Teil eines asymmetrischen Schlüsselpaares abgelegt. Dadurch bietet sich eine höhere Sicherheit gegenüber der ersten Variante, weshalb im Folgenden nur noch die zweite Variante betrachtet und verwendet wird.
Aktiviert wird Secure Boot in den sogenannten eFuses des ESP32, einem nur ein einziges Mal beschreibbaren Speicherbereich. Darüber hinaus wird in den eFuses auch der Hashwert des öffentlichen Schlüssels eingebrannt, in diesem Falle eine SHA256 Hash-Summe.
Der öffentliche Teil des Schlüssels wird jeweils dem Bootloader und der Applikation angehangen und im Flash gespeichert.
In der ersten Bootphase wird der öffentliche Schlüssel aus dem Flash gelesen, dessen Hash-Summe berechnet und mit dem Wert verglichen, der in den eFuses gespeichert ist. Stimmt dieser überein, wird als nächstes die Signatur des Bootloaders mit dem öffentlichen Schlüssel überprüft. Die Validierung der Applikation erfolgt anschließend in der zweiten Bootphase äquivalent zu der Validierung des Bootloaders.
„Eine Herausforderung ist es, das Key-Management in einen etablierten Entwicklungs- und Produktionsprozess einzubinden.“
Im vorherigen Artikel wurde eine Security Analyse mit CONCRY am ESP32 beschrieben. In dieser Analyse wurde das Secure Boot und die Verschlüsselung des Flash Speichers als erforderliche Maßnahmen identifiziert. Ersteres wurde in diesem Artikel näher beschrieben und kann über das IoT Development Framework, der zugehörigen Entwicklungsumgebung von Espressif, komfortabel konfiguriert werden. Der ESP32 verfügt damit über ein einfach zu konfigurierendes Secure Boot Verfahren, das nach heutigem Stand der Technik* als ausreichend sicher erachtet wird. Als Herausforderung bleibt, das Key-Management in einen etablierten Entwicklungs- und Produktionsprozess einzubinden. Dazu gehört beispielsweise, dass während der Entwicklung ein anderer Key zur Signaturerzeugung verwendet wird als für das ausgelieferte Endprodukt. Diese und weitere Fragestellungen wurden ebenfalls im Rahmen der Security Analyse mit CONCRY bereits untersucht.
Im nächsten Artikel dieser Reihe zum IoTürschild wird die Verschlüsselung des Flashspeichers näher untersucht.
*) BSI TR-02102-1: „Kryptographische Verfahren: Empfehlungen und Schlüssellängen“ vom BSI
