DE102016106819A1

DE102016106819A1 - Verfahren zur Aktualisierung einer Firmware-Komponente und Gerät der Mess- und Regeltechnik

Info

Publication number: DE102016106819A1
Application number: DE102016106819.5A
Authority: DE
Inventors: Björn Haase
Original assignee: Endress & Hauser Conducta & Co Kg GmbH; Endress and Hauser Conducta GmbH and Co KG
Current assignee: Endress & Hauser Conducta & Co Kg GmbH; Endress and Hauser Conducta GmbH and Co KG
Priority date: 2016-04-11
Filing date: 2016-04-13
Publication date: 2017-10-26
Also published as: CN107368744B; CN107368744A

Abstract

Die Erfindung betrifft ein Verfahren zum Aktualisieren einer die Funktionalität eines Geräts der Mess- und Regeltechnik bereitstellenden ersten Firmware-Komponente, welche in einen Mikrocontroller des Geräts eingebettet ist, umfassend: – Segmentweises Empfangen eines ersten Firmware-Images über ein mit einem externen Gerät verbundenes Dateninterface des Mikrocontrollers, wobei das erste Firmware-Image einen Datenbereich und ein Signaturfeld umfasst, und wobei der Datenbereich zur Aktualisierung der ersten Firmware-Komponente dienende, einen Firmware-Programmcode umfassende Daten enthält und das Signaturfeld eine nach einem ersten Kryptoverfahren erzeugte erste Authentifizierungsinformation enthält; – Durchführen einer Authentifizierung des ersten Firmware-Images anhand der ersten Authentifizierungsinformation mittels eines von der ersten Firmware-Komponente umfassten Authentifizierungs-Algorithmus nach dem ersten Kryptoverfahren; – Erzeugen einer zweiten Authentifizierungsinformation für die im Datenbereich des ersten Firmware-Images enthaltenen Daten mittels eines von der ersten Firmware-Komponente umfassten Algorithmus zur Erzeugung der zweiten Authentifizierungsinformation nach einem von dem ersten Kryptoverfahren verschiedenen, zweiten Kryptoverfahren; – nach erfolgreicher Authentifizierung des ersten Firmware-Images Speichern der zweiten Authentifizierungsinformation in einem persistenten Speicher des Geräts; – Löschen der ersten Firmware-Komponente, wobei das Löschen durch eine in den Mikrocontroller eingebettete zweite Firmware-Komponente gesteuert wird; – erneute Übertragung der zur Aktualisierung der ersten Firmware-Komponente dienenden Daten als Bestandteil eines zweiten Firmware-Images unter Beteiligung der zweiten Firmware-Komponente über das Dateninterface an den Mikrocontroller und Speichern der Daten im persistenten Speicher des Mikrocontrollers; – Durchführen einer Authentifizierung des bei der erneuten Übertragung empfangenen zweiten Firmware-Images anhand der in dem Mikrocontroller gespeicherten zweiten Authentifizierungsinformation mittels eines von der zweiten Firmware-Komponente umfassten Authentifizierungs-Algorithmus nach dem zweiten Kryptoverfahren, und – für den Fall einer erfolgreichen Authentifizierung des zweiten Firmware-Images Aktivschalten und Ausführen des mit dem zweiten Firmware-Image übertragenen und gespeicherten Firmware-Programmcodes als neue erste Firmware-Komponente.

Description

Die Erfindung betrifft ein Verfahren zum Aktualisieren einer die Funktionalität eines Geräts der Mess- und Regeltechnik bereitstellenden Firmware-Komponente und ein Gerät der Mess- und Regeltechnik.
Mess- und Regelaufgaben im Industriebereich sind häufig sicherheitskritisch. Die Kundenanwendungen erfordern die Sicherstellung der Korrektheit und Verfügbarkeit von Mess- und Regelgrößen der jeweiligen Automatisierung. Integrität und Verfügbarkeit der Daten ist in den meisten Fällen von höherer Relevanz als die ebenfalls wichtige Vertraulichkeit. Die besondere Sicherheitsrelevanz von Geräten der Mess- und Regeltechnik, wie Messgeräten, Steuerungen, Sensoren, Aktoren, Überwachungsschaltungen, Warnanzeigen, Feldbus-Netzwerktechnik etc. erwächst dadurch, dass die Folge von Fehlfunktionen oder Manipulationen an diesen Geräten Gefahren, wie Explosionen, Austritt von Gefahrstoffen/Gasen, etc., sein können.
Automatisierungslösungen bestehen aus einer Vielzahl von unabhängigen Teilkomponenten, wie Steuerungen, Sensoren, Netzwerk-Infrastrukturkomponenten wie Router, etc.. Diese Teilkomponenten können jeweils für sich als einzelnes Gerät der Mess- und Regeltechnik ausgestaltet sein oder auch mindestens teilweise in einem Gerät zusammengefasst sein. Jede dieser Teilkomponenten enthält heute in der Regel eigene Softwarekomponenten, sogenannte Firmwares. Noch dazu kann wiederum jedes einzelne Gerät, z.B. ein Feldgerät zur pH-Wertmessung, aus mehreren Teilmodulen bestehen, die jeweils eine eigene Firmware enthalten, z.B. ein Untersystem mit je einem Mikrocontroller für ein Feldbusinterface, ein Untersystem für die Messwert-Signalverarbeitung sowie ein Untersystem für die Analog-Digitalwandlung. Die Firmware ist jeweils in die Mikrocontroller eingebettet. Neben der Integrität der Datenübertragung auf den Kommunikationsschnittstellen (Feldbus, Ethernet, Wireless-Hart etc.) der Geräte oder Teilkomponenten ist auch die Integrität der Messwertverarbeitung in den Teilkomponenten (Transmitter, Sensor) für die Korrektheit der Messwerte entscheidend.
Ein mögliches Angriffs-Szenario besteht darin, dass ein Angreifer dem Betreiber einer Automatisierungsanlage manipulierte Firmware-Komponenten unterschiebt. So könnten beispielsweise innerhalb eines Temperatursensors die vom Sensor gemessenen Temperaturmesswerte bewusst innerhalb der Firmware manipuliert werden, so dass dem mit dem Sensor verbundenen Leitsystem eine für den Betrieb der Anlage unkritische Temperatur gemeldet wird, während in Wahrheit der überwachte Prozess stark erhöhte Temperaturen aufweist, die z.B. zu einer Explosion eines Tanks führen können.
Für einen erfolgreichen Angriff reicht es in der Regel aus, innerhalb eines angegriffenen Geräts oder eines eine Vielzahl von Geräten umfassenden angegriffenen Systems die Firmware einer beliebigen Teilkomponente zu manipulieren.
Ein konkretes Beispiel anhand einer pH-Messstelle: Eine pH-Messstelle umfasst in der Regel einen pH- und einen Temperaturmesswandler, die häufig in einem einzigen Gerät zusammengefasst sind. Das Gerät umfasst weiter eine mit den Messwandlern verbundene Geräteelektronik. Diese kann beispielsweise einen oder mehrere Mikrocontroller zur Analog-Digitalwandlung der Ausgangssignale der Messwandler, einen weiteren Mikrocontroller für die Messsignalverarbeitung, ein Feldbusinterface zur Übertragung der Messsignale über einen Feldbus und ein System, welches sich um die Bedienung des Feldbusinterfaces kümmert, umfassen. Möchte ein Angreifer beispielsweise die übermittelten Temperaturmesswerte einer solchen pH-Messstelle manipulieren, so kann er das Ziel dadurch erreichen, dass wahlweise die Firmware innerhalb des Mikrokontrollers zur Analog-Digitalwandlung des Ausgangssignals des Temperaturmesswandlers oder die Firmware einer der anderen Teilkomponenten des Geräts manipuliert wird.
Das sichere Abwehren eines vermittels manipulierter Firmware-Komponenten gestarteten Angriffs setzt somit voraus, dass die Firmware aller beteiligten Subsysteme und Teilkomponenten überprüft werden muss.
In der Vergangenheit war es häufig üblich, dass die Integrität der Firmware aus solchen Sicherheitserwägungen nicht betrachtet werden musste, weil eine Programmierung der Firmware über sogenannte Metallmasken bei der Herstellung der Chips erfolgte oder im Fall sogenannter Flash-Speicherbereiche eine Umprogrammierung konstruktiv bedingt nur auf den Fertigungsanlagen des Geräteherstellers einer Komponente möglich war. Heute ist jedoch Stand der Technik, dass auch im Feldeinsatz das Einspielen einer neuen Firmware auf alle Teilkomponenten, ein sogenanntes Firmware-Update, jederzeit zur Laufzeit möglich ist.
Zur Sicherstellung der Gesamtintegrität des Systems ist somit die Sicherstellung der Integrität ausnahmslos aller beteiligten Firmware-Komponenten entscheidend.
Das hat zur Konsequenz, dass sowohl „große“ Systeme mit viel Speicher als auch sehr rechenschwache Mikrocontroller-Systeme abgesichert werden müssen. Im kryptographischen Kontext wird dabei von der erforderlichen sogenannten Authentizität der Firmware gesprochen, bei der das empfangende System überprüft, dass die im Rahmen des Updates zu empfangende Firmware-Komponente authentisch ist, d.h. z.B. wirklich vom Gerätehersteller und nicht von einem möglichen Angreifer erstellt wurde.
Bezüglich der kryptographischen Authentizitätsprüfung lassen sich zwei große Familien unterscheiden

– Symmetrische Prüfsummenverfahren mit Authentifizierungscodes (sogenannte Message Authentication Codes, Abkürzung: MAC), wie AES-CBC, HMAC-MD5, HMAC-SHA256, Chaskey, Chaskey-LTS, Galois-Feldbasierte MACs wie die Authentifizierungskomponente in AES-GCM, sowie Primzahlbasierte Verfahren wie Poly1305, etc.
– Asymmetrische Signaturverfahren, wie RSA-basierte Signaturen, ECDH-Signaturen auf elliptischen Kurven, EdDSA-Signaturen, Hash-Basierte Signaturverfahren, DSA-Signaturen, etc.

Beide Verfahrensklassen können dazu genutzt werden mittels kryptographischer Verfahren, im Folgenden auch als Kryptoverfahren bezeichnet, eine Authentifizierungsinformation, z.B. eine Prüfsumme oder eine digitale Signatur, zu generieren, die zusammen mit der der Firmware-Aktualisierung eines Systems dienenden Firmware-Komponente ausgeliefert werden kann. Das empfangende System kann dann anhand der Authentifizierungsinformation und von Schlüsselinformationen überprüfen, ob die gelieferte Firmware-Komponente authentisch ist oder nicht.
Die beiden oben genannten Verfahrensklassen unterscheiden sich auf der einen Seite dadurch, dass bei symmetrischen Verfahren sowohl für die Generierung der Authentifizierungsinformation als auch für die Prüfung der Authentifizierungsinformation exakt der gleiche Schlüssel zum Einsatz kommt, während bei asymmetrischen Verfahren verschiedene Schlüssel verwendet werden. Auf der anderen Seite unterscheiden sich die beiden Verfahrensklassen in ihrer Komplexität und entsprechend ihrem Bedarf an Rechenzeit und/oder Speicher und der Codegröße der in Software implementierten Verfahren.
Bei symmetrischen Verfahren ist jede Entität, die in der Lage ist eine Authentizitätsprüfung durchzuführen, selbst ebenfalls in der Lage eine korrekte Prüfsumme als Authentifizierungsinformation zu generieren, da der verwendete Schlüssel „symmetrisch“ beiden beteiligten Partnern zur Verfügung stehen muss. Bei den asymmetrischen Verfahren liegen auf beiden Seiten (Generierung und Prüfung) unterschiedliche Schlüssel vor.
Die symmetrischen Prüfsummenverfahren sind heute aus Sicht vieler Kryptographen so stabil und sicher, dass mathematische Angriffe auf die Basisalgorithmen praktisch ausgeschlossen werden können, wenn Schlüssellängen von mehr als 80 Bits verwendet werden. Häufig werden heute symmetrische Schlüssel von mindestens 128 oder 256 Bit Länge empfohlen.
Im Kontext von Systemen mit kleinen Mikrocontrollern besteht jedoch bei symmetrischen Verfahren ein wesentliches Problem. Für die Prüfung der Authentizität einer neu angebotenen Firmware-Komponente ist es nötig, dass der symmetrische Schlüssel im persistenten Speicher des Systems vorgehalten wird. Bei konventionellen Mikrocontrollern kann dieser Speicher jedoch nicht wirksam gegen unberechtigtes Auslesen geschützt werden. Zwar gibt es elektronische Bausteine aus der sogenannten Smart-Card-IC-Klasse, die z.B. durch spezielle Metallüberdeckungen von Speicherbereichen und ausgefeilte Schutzmechanismen den persistenten Speicher eines Controllers gegen unberechtigten Zugriff schützen. In handelsüblichen Mikrocontrollern sind solche Gegenmaßnahmen jedoch nicht umgesetzt.
Damit wird einem Angreifer relativ leicht ermöglicht, sich die symmetrische Schlüsselinformation unberechtigterweise zu beschaffen, z.B. durch Öffnen des Gehäuses oder durch Umgehung der Zugangsbeschränkung eines Interfaces zur Software-Fehlersuche (Debugger-Interface). Der Angreifer kann dann leicht eine korrekte Prüfsumme für seine manipulierte Firmware-Komponente generieren und diese einem Teilsystem ohne Verursachen eines Fehlers unterschieben.
Der wesentliche Vorteil der symmetrischen Verfahren besteht darin, dass diese auch auf Systemen mit geringer Rechenleistung effizient implementiert werden können. Insbesondere wird hierfür nur sehr wenig Quellcode und CPU-Leistung benötigt. So kann beispielsweise ein MAC-Algorithmus wie Chaskey-LTS auf einer ARM-Cortex-M0 CPU bereits mit ca. 512 Bytes Programmlänge implementiert werden. Im Unterschied zu asymmetrischen Signaturverfahren wird z.B. nicht zwingend ein sogenannter kollisionsresistenter Hash-Algorithmus als Teilkomponente benötigt, der typisch größere Konstantentabellen und relativ viel Programmcode erfordert.
Der wesentliche Unterschied zwischen symmetrischen und asymmetrischen Verfahren besteht darin, dass bei asymmetrischen Verfahren für die Generierung einer Signatur als Authentifizierungsinformation ein anderer Schlüssel zum Einsatz kommt, als für die Überprüfung der Signatur. Dabei wird in der Regel der Schlüssel für die Signaturgenerierung als „privater“ Schlüssel bezeichnet und der für die Überprüfung der Signatur verwendete Schlüssel als „öffentlicher“ Schlüssel. Der zur Signatur einer Firmware-Komponente verwendete private Schlüssel kann so ausschließlich in einer sicheren Umgebung behalten werden, z.B. innerhalb eines zugangsbeschränkten Bereichs innerhalb der Entwicklungsabteilung beim Gerätehersteller. Dieser private Schlüssel kann somit viel effektiver vor potentiellen Angreifern geschützt werden als ein in einem ungeschützten Speicher in einem Feldgerät abgelegter Schlüssel. Innerhalb des persistenten Speichers der Mikrocontroller umfassenden Systeme der Geräte befindet sich bei Nutzung einer asymmetrischen Signatur nur der unkritische öffentliche Schlüssel, der von einem Angreifer nicht dazu verwendet werden kann, selbst eine manipulierte Firmware zu signieren.
Für asymmetrische Verfahren sind aus Betrachtung der möglichen Angriffe gegen die mathematischen Verfahren heute Schlüssellängen von mindestens 2048 Bits (bei Verfahren wie DSA oder RSA auf Basis von Verfahren auf Basis der Faktorisierung großer Zahlen und Gruppen auf Primzahlkörpern) oder > 230 Bits für Verfahren auf Basis von elliptischen Kurven erforderlich. Alternative Verfahren, wie z.B. die sogenannten Merkle-Signaturen auf Basis von Hash-Bäumen, Code-Basierte Signaturen (McEliece) oder sogenannte gitterbasierte Signaturverfahren (z.B. LWE, Learning with Errors) erfordern noch weit längere Schlüssel von 10 kByte und mehr und werden deswegen in der Praxis nicht häufig eingesetzt. Im Kontext von rechenleistungsstarken Systemen, wie z.B. Webservern im Internet finden Signaturen auf Basis von Verfahren wie RSA, DSA oder ECDSA weiten Einsatz, z.B. bei sogenannten Zertifikaten, wie sie bei verschlüsselten Protokollen wie HTTPs oder TLS zum Einsatz kommen.
Die Herausforderung besteht darin, dass diese Verfahren wegen der aufwändigen Algorithmen und großen Schlüssellängen erheblich mehr Rechenressourcen benötigen, als symmetrische Verfahren. So braucht z.B. selbst eine hoch optimierte Software-Implementierung von asymmetrischer Kryptographie auf kleinen Microcontrollern bereits ca. 10 kByte Speicher (Des. Codes Cryptogr. (2015) 77:493–514). Es ist im Vergleich zu symmetrischen Verfahren daher mindestens mit einem 10 bis 100fachen Speicherbedarf für den zugehörigen Programmcode zu rechnen.
Innerhalb eines industriellen Steuerungsgeräts gibt es typisch einzelne Komponenten, welche für die Standardverfahren ausreichende Ressourcen bereitstellen. Z.B. könnte innerhalb eines pH-Sensors eine für die Feldbuskommunikation verantwortliche CPU über ausreichend Speicher und Rechenleistung verfügen. Wie oben ausgeführt, reicht jedoch die Absicherung eines einzelnen Teilsystems nicht aus. Vielmehr müssen alle beteiligten Firmware-Komponenten geschützt werden, auch in den kleineren Subsystemen, z.B. für die Analog-Digitalwandlung nahe beim physikalischen Messwandler.
Die Auslagerung der Signaturprüfung allein auf die rechenstarken CPUs einer Komponente birgt die Gefahr, dass Fehler innerhalb der Protokolle innerhalb einer Komponente sich auf die anderen Komponenten auswirken können. D.h. die Sicherheit einer Firmware-Komponente (z.B. zur A/D-Wandlung) hängt dann von der Korrektheit einer anderen Firmware-Komponente (z.B. Feldbus-CPU) ab, die ggf. unter Kontrolle einer anderen Organisationseinheit oder sogar einer Fremdfirma steht und nicht überprüft werden kann. Das erhöht die Menge möglicher Fehlerquellen bei Konzept und Implementierung.
Für das Merkmal der Sicherheit sind immer Systeme geringer Komplexität anzustreben. Diese ist in der Praxis vielfach nur dann erreicht, wenn jede CPU bei einem Firmware-Update vollständig selbst für die Firmware-Authentizitätsprüfung verantwortlich ist, die Prüfung also dezentral erfolgt. In der Praxis können häufig nur so sichere Systeme designt werden.
Für den Prozess eines Firmware-Updates in einem eingebetteten System sind folgende Betrachtungen bedeutsam. Das Rechensystem besteht in der Regel aus einer Recheneinheit sowie einem RAM – Speicher für dynamische Daten und einem (Flash-)ROM-Speicher für zu persistierende Daten. Die Recheneinheit (CPU) bezieht aus dem ROM-Speicher die Maschineninstruktionen und legt dort auch persistente Daten, wie z.B. kryptographische Schlüssel ab. Heute ist Stand der Technik, dass Mikrocontroller über einen integrierten ROM-Speicher in sogenannter Flash-Technik verfügen. In der Regel dominiert der Flash-Speicher die Silizium-Fläche der Mikrocontroller und ist damit der entscheidende Kostenfaktor bei der Herstellung der Mikrocontroller-Chips. Aus Kostengründen werden daher in der Regel Bausteine eingesetzt, welche genau auf den gerade eben benötigten Speicherbedarf zugeschnitten sind. Ein typisches eingebettetes System verfügt damit in der Regel nicht über ausreichend RAM- und Flash-ROM-Speicher um während eines Firmware-Updates temporär sowohl die bisherige als auch die „neue“ Firmware-Komponente ablegen zu können.
Aus diesem Grund wird in der Regel zwischen zwei Firmware-Komponenten, einer sogenannten Bootloader-Komponente (im Folgenden auch kurz als Bootloader bezeichnet) und einer Applikations-Komponente (im Folgenden auch kurz als Applikation bezeichnet), unterschieden. Bei einem typischen Mikrocontroller mit z.B. 64 kByte Flash-Speicher insgesamt besteht die Gesamtfirmware z.B. aus einem Bootloader mit z.B. 4 kByte Flash und einer Applikation mit 59 kByte Flash und 1 kByte Datenspeicher.
Die Aufgabe des Bootloaders besteht dabei darin, einen Austausch der Applikations-Firmware zu ermöglichen. Zu diesem Zweck wird vom Bootloader der Applikationsbereich des Flashs zunächst gelöscht. Vielfach wird in Microcontrollern dabei hardwaremäßig das Flash in eine sogenannte „Bootloader“-Sektion und eine „Applikations“-Sektion getrennt, wobei Bootloader- und Applikationsteile separat gelöscht werden können. In solchen Systemen ist damit die maximal mögliche Größe des Bootloaders durch die Hardware auf Längen von typisch 4 oder 8 kByte beschränkt. Nach dem Löschvorgang ist die Applikation nicht mehr verfügbar. Anschließend wird dem Bootloader über ein externes Dateninterface eine neue Applikations-Firmware übermittelt und dann in den Flash-Speicher neu abgelegt.
Wichtig im Kontext der Generierung und/oder Prüfung kryptographischer Authentifizierungsinformationen ist dabei, dass für die Generierung und die Überprüfung einer Authentifizierungsinformation die vollständige beim Update übermittelte Firmware-Komponente herangezogen werden muss. Aus offensichtlichen Gründen ist bei der voranstehend beschriebenen Form des Firmware-Updates eine Überprüfung der Authentifizierungsinformation vom Bootloader-Teil der Software erforderlich.
Wie man leicht aus dem oben genannten typischen Beispiel entnehmen kann ist es absehbar nicht möglich, sichere asymmetrische Kryptographieverfahren (mit typisch mindestens 10 kByte Codelänge) unter den Randbedingungen der Codegrößen-Beschränkungen des Bootloaders zu implementieren. Im Kontext der normalen Applikation (im Beispiel 59 kByte Code) sind solche Verfahren jedoch sehr wohl umzusetzen.
Die Aufgabe der Erfindung besteht zusammenfassend darin, im genannten Kontext, eine dezentrale, sichere, asymmetrische Signaturprüfung zu ermöglichen, auch in Teilkomponenten mit geringer Rechenleistung, insbesondere unter den Beschränkungen einer Bootloader-Firmware.
Diese Aufgabe wird gelöst durch ein Verfahren mit den Merkmalen des Anspruchs 1 und ein Gerät der Mess- und Regeltechnik gemäß Anspruch 11. Vorteilhafte Ausgestaltungen sind in den Unteransprüchen angegeben.
Das erfindungsgemäße Verfahren zum Aktualisieren einer die Funktionalität eines Geräts der Mess- und Regeltechnik bereitstellenden ersten Firmware-Komponente, welche in einen Mikrocontroller des Geräts eingebettet ist, umfasst:

– Segmentweises Empfangen eines ersten Firmware-Images über ein mit einem externen Gerät verbundenes Dateninterface des Mikrocontrollers, wobei das erste Firmware-Image einen Datenbereich und ein Signaturfeld umfasst, und wobei der Datenbereich zur Aktualisierung der ersten Firmware-Komponente dienende, einen Firmware-Programmcode umfassende Daten enthält und das Signaturfeld eine nach einem ersten Kryptoverfahren erzeugte erste Authentifizierungsinformation enthält;
– Durchführen einer Authentifizierung des ersten Firmware-Images anhand der ersten Authentifizierungsinformation mittels eines von der ersten Firmware-Komponente umfassten Authentifizierungs-Algorithmus nach dem ersten Kryptoverfahren;
– Erzeugen einer zweiten Authentifizierungsinformation für die im Datenbereich des ersten Firmware-images enthaltenen Daten mittels eines von der ersten Firmware-Komponente umfassten Algorithmus zur Erzeugung der zweiten Authentifizierungsinformation nach einem von dem ersten Kryptoverfahren verschiedenen, zweiten Kryptoverfahren;
– nach erfolgreicher Authentifizierung des ersten Firmware-Images Speichern der zweiten Authentifizierungsinformation in einem persistenten Speicher des Geräts;
– Löschen der ersten Firmware-Komponente, wobei das Löschen durch eine in den Mikrocontroller eingebettete zweite Firmware-Komponente gesteuert wird;
– erneute Übertragung der zur Aktualisierung der ersten Firmware-Komponente dienenden Daten als Bestandteil eines zweiten Firmware-Images unter Beteiligung der zweiten Firmware-Komponente über das Dateninterface an den Mikrocontroller und Speichern der Daten im persistenten Speicher des Mikrocontrollers;
– Durchführen einer Authentifizierung des bei der erneuten Übertragung empfangenen zweiten Firmware-Images anhand der in dem Mikrocontroller gespeicherten zweiten Authentifizierungsinformation mittels eines von der zweiten Firmware-Komponente umfassten Authentifizierungs-Algorithmus nach dem zweiten Kryptoverfahren, und
– für den Fall einer erfolgreichen Authentifizierung des zweiten Firmware-Images Aktivschalten und Ausführen des mit dem zweiten Firmware-Image übertragenen und gespeicherten Firmware-Programmcodes als neue erste Firmware-Komponente.

Der Erfindung liegt die Erkenntnis zugrunde, dass für eine ressourcenbeschränkte Firmware-Komponente, wie z.B. den einleitend beschriebenen Bootloader, im Unterschied zu asymmetrischen Kryptoverfahren, weniger aufwändige Kryptoverfahren, wie z.B. symmetrische Prüfsummenverfahren zur Prüfsummenüberprüfung sehr wohl in Reichweite liegen. Dies gilt insbesondere bei Nutzung sogenannter „lightweight“-Algorithmen wie Chaskey, Chaskey-LTS oder sogenannte Cipher Block Chaining(CBC)-Authentifizierungs-Codes auf Basis von light-weight Block-Cipher-Algorithmen wie „Simon“ oder „Speck“ (siehe auch National Institute Of Standards and Technology NIST), oder für den Fall, dass der entsprechende Mikrocontroller Crypto-Beschleuniger-Hardware enthält, z.B. für AES.
Indem die erste Firmware-Komponente eine Authentifizierung des ersten Firmware-Images nach einem Authentifizierungs-Algorithmus basierend auf einem ersten Kryptoverfahren durchführt, gleichzeitig unter Verwendung des ersten Firmware-Images eine Authentifizierungsinformation nach einem vom ersten Kryptoverfahren verschiedenen, zweiten Kryptoverfahren generiert, und die bei der erneuten Übertragung mit dem zweite Firmware-Image erhaltenen Daten von der zweiten Firmware-Komponente anhand der von der ersten Firmware-Komponente generierten Authentifizierungsinformation authentifiziert werden können, bietet sich die Möglichkeit, als erstes Kryptoverfahren ein komplexeres, und damit sichereres, Kryptoverfahren zu verwenden, und als zweites Kryptoverfahren ein einfacheres und damit weniger Ressourcen benötigendes Kryptoverfahren zu verwenden. Die Authentifizierung durch die erste Firmware-Komponente kann somit durch ein aufwändiges, beispielsweise asymmetrisches, Kryptoverfahren sicherstellen, dass bei der ersten Übertragung der Daten mit dem ersten Firmware-Image Manipulationen durch einen Angreifer ausgeschlossen sind. Die Authentifizierung durch die zweite Firmware-Komponente stellt sicher, dass die beim erneuten Übersenden mit dem zweiten Firmware-Image erhaltenen Daten mit den bei der ersten Übertragung erhaltenen Daten des ersten Firmware-Images identisch sind. Somit genügt hierfür ein weniger aufwändiges, z.B. ein symmetrisches, Kryptoverfahren.
Das Verfahren lässt sich daher vorteilhaft bei einem Firmware-Update, wie es eingangs beschrieben wurde, anwenden. In diesem Fall entspricht die erste Firmware-Komponente der Applikation, die zweite Firmware-Komponente dem Bootloader.
Mit dem Begriff Firmware-Image wird hier eine geeignete Kombination eines Datenbereichs, der einen Firmware-Programmcode und konstante Daten enthalten kann, und einem optional vorhandenen Signaturfeld bezeichnet. Die in dem Datenbereich enthaltenen Daten werden im Folgenden auch als Firmware-Daten oder kurz als Firmware bezeichnet. Das erste Firmware-Image umfasst ein Signaturfeld, das die erste Authentifizierungsinformation enthält. Das zweite Firmware-Image kann ein Signaturfeld mit einer Authentifizierungsinformation, insbesondere der ersten Authentifizierungsinformation, enthalten. Insbesondere kann es mit dem ersten Firmware-Image vollständig übereinstimmen, d.h. dass bei dem oben beschriebenen Verfahren ein und dasselbe Firmware-Image zweimal übertragen wird, nämlich beim ersten Mal an die erste Firmwarekomponente zur Authentifizierung nach dem ersten Kryptoverfahren und zur Generierung der zweiten Authentifizierungsinformation und beim zweiten Mal an die zweite Firmwarekomponente zur beschriebenen Authentifizierung anhand der von der ersten Firmwarekomponente generierten zweiten Authentifizierungsinformation. Es ist aber auch möglich, dass das zweite Firmware-Image nur einen Datenbereich mit den Firmware-Daten enthält.
Das Verfahren kann weiter umfassen:
für den Fall einer nicht erfolgreichen Authentifizierung des zweiten Firmware-Images, Löschen der mit dem zweiten Firmware-Image übertragenen und gespeicherten Daten, insbesondere des gespeicherten Firmware-Programmcodes.
Unter einer erfolgreichen Authentifizierung wird hier verstanden, dass der Authentifizierungsalgorithmus zu dem Ergebnis führt, dass das zu authentifizierende Firmware-Image bzw die enthaltenen Daten authentisch ist/sind.
In einer vorteilhaften Ausgestaltung erfordert der von der ersten Firmware-Komponente umfasste Authentifizierungs-Algorithmus nach dem ersten Kryptoverfahren einen Speicherbedarf von mehr als 5 kByte ROM und von 512 Bytes RAM.
In einer weiteren vorteilhaften Ausgestaltung erfordert der von der ersten Firmware-Komponente umfasste Algorithmus zur Erzeugung der zweiten Authentifizierungsinformation nach dem zweiten Kryptoverfahren und der von der zweiten Firmware-Komponente umfasste Authentifizierungs-Algorithmus nach dem zweiten Kryptoverfahren einen Speicherbedarf von weniger als 512 Bytes RAM und 1 kBytes ROM.
Das erste Kryptoverfahren kann beispielsweise ein asymmetrisches Kryptoverfahren sein. In Frage kommt z.B. ein Verfahren auf Basis von Elliptischen Kurven, insbesondere auf Basis des EdDSA-Algorithmus auf der elliptischen Kurve Curve25519, eines Verfahrens der ECDSA-Standardfamilie oder ein Verfahren auf der Basis von Primzahlkörpern, insbesondere ein RSA- oder DSA-Verfahren.
Das zweite Kryptoverfahren kann beispielsweise ein symmetrisches Kryptoverfahren sein. Geeignet ist beispielsweise ein MAC-Verfahren auf Basis eines Blockverschlüsselungsalgorithmus, insbesondere ein Verfahren auf Basis der Algorithmenfamilie Chaskey oder AES128-CBC.
Die erste Authentifizierungsinformation kann eine mit einem privaten Schlüssel unter Verwendung der in dem Datenbereich enthaltenen Daten, insbesondere des Firmware-Programmcodes, erzeugte digitale Signatur sein, wobei das Durchführen der Authentifizierung des ersten Firmware-Images eine Überprüfung der digitalen Signatur mittels eines in einem persistenten Speicher des Mikrocontrollers gespeicherten öffentlichen Schlüssels umfasst.
Das Erzeugen der zweiten Authentifizierungsinformation umfasst in einer Ausgestaltung das Erzeugen einer als zweite Authentifizierungsinformation dienenden Prüfsumme nach dem zweiten Kryptoverfahren aus einem mittels eines von der ersten Firmware-Komponente umfassten Schlüsselgenerators erzeugten Schlüssels und der in dem Datenbereich enthaltenen Daten, insbesondere dem von dem ersten Firmware-Image umfassten Firmware-Programmcode.
Der mittels des Schlüsselgenerators erzeugte Schlüssel kann in einem persistenten Speicher des Mikrocontrollers abgespeichert werden, wobei das Durchführen einer Authentifizierung des zweiten Firmware-Images anhand der zweiten Authentifizierungsinformation folgende Schritte umfasst: Erzeugen einer Prüfsumme nach dem zweiten Kryptoverfahren aus dem mittels des Schlüsselgenerators erzeugten Schlüssel und der von dem zweiten Firmware-Image umfassten Daten, insbesondere dem von dem zweiten Firmware-Image umfassten Firmware-Programmcode; und Vergleichen der Prüfsumme mit der zweiten Authentifizierungsinformation, wobei die Authentifizierung erfolgreich ist, wenn die Prüfsumme mit der zweiten Authentifizierungsinformation übereinstimmt.
In seltenen Fällen könnte es erstrebenswert sein, innerhalb des Firmware-Images auch Abschnitte zu definieren, welche zwar mit übertragen werden sollen, jedoch nicht kryptographisch abzugesichern sind, d.h. Abschnitte die bewusst nicht für die Berechnungen der Authentifizierungsinformationen herangezogen werden. Das könnte z.B. Datenbereiche umfassen, in denen nach erfolgter Signaturgenerierung erklärende Hinweistexte zur Firmware, wie z.B. eine nach Auslieferung der Software ergänzte Liste bekannter Fehler-Issues mit Beschreibung und empfohlenen Maßnahmen ergänzt werden. Diese Datenabschnitte können ggfs. von der Signaturprüfung nach dem ersten Kryptoverfahren bzw. von der Prüfsummengenerierung und Authentifizierung nach dem zweiten Kryptoverfahren ausgenommen werden.
Der Schlüsselgenerator kann beispielsweise einen Zufallszahlengenerator umfassen, wobei der Schlüssel eine Zufallszahlensequenz von vorzugsweise mindestens 80 Bits ist.
Der Firmware-Programmcode des ersten und des zweiten Firmware-Images kann optional verschlüsselt sein. Das Verfahren umfasst in diesem Fall zusätzlich das Entschlüsseln des Firmware-Programmcodes mittels eines zusätzlichen Entschlüsselungs-Algorithmus der ersten und/oder der zweiten Firmware-Komponente. Hierfür würde vorteilhafterweise ein symmetrisches Verschlüsselungsverfahren zum Einsatz kommen, dessen Schlüssel im persistenten Speicher des Mikrocontrollers abgelegt ist.
Die Erfindung umfasst auch ein Gerät der Mess- und Regeltechnik umfassend:
eine Geräteelektronik mit mindestens einem Mikrocontroller;
wobei der mindestens eine Mikrocontroller eine eingebettete Firmware umfasst, welche mindestens eine erste Firmware-Komponente und eine zweite Firmware-Komponente aufweist,
und wobei die erste Firmware-Komponente umfasst:

– einen oder mehrere Algorithmen zur Bereitstellung von Funktionalitäten des Geräts;
– einen Algorithmus zum Empfang eines ersten Firmware-Images, welches einen Datenbereich und ein Signaturfeld umfasst, wobei der Datenbereich zur Aktualisierung der ersten Firmware-Komponente dienende, einen Firmware-Programmcode umfassende, Daten enthält, und wobei das Signaturfeld eine nach einem ersten Kryptoverfahren erzeugte erste Authentifizierungsinformation enthält;
– einen Authentifizierungs-Algorithmus zur Authentifizierung des ersten Firmware-Images anhand der ersten Authentifizierungsinformation nach einem ersten Kryptoverfahren;
– einen Algorithmus zur Erzeugung einer zweiten Authentifizierungsinformation aus den in dem Datenbereich enthaltenen Daten, insbesondere dem Firmware-Programmcode, nach einem von dem ersten Kryptoverfahren verschiedenen, zweiten Kryptoverfahren; und
– einen Algorithmus zur Ablage der zweiten Authentifizierungsinformation in einem persistenten Speicher des Microcontrollers; und wobei die zweite Firmware-Komponente umfasst:
– einen Algorithmus zum Empfangen eines zweiten Firmware-Images, welches die zur Aktualisierung der ersten Firmware-Komponente dienenden Daten, insbesondere einen zur Aktualisierung der ersten Firmware-Komponente dienenden Firmware-Programmcode, umfasst;
– einen Algorithmus zum Löschen der ersten Firmware-Komponente und zum Speichern des von dem zweiten Firmware-Image umfassten Firmware-Programmcodes als neue ersten Firmware-Komponente;
– einen Algorithmus zum Auslesen der zweiten Authentifizierungsinformation aus dem persistenten Speicher;
– einen Authentifizierungsalgorithmus nach dem zweiten Kryptoverfahren zur Authentifizierung des zweiten Firmware-Images anhand der zweiten Authentifizierungsinformation und der von dem zweiten Firmware-Image umfassten Daten, insbesondere des Firmware-Programmcodes; und
– einen Algorithmus zum Aktivschalten der neuen ersten Firmware-Komponente.

Das Gerät kann mithin zur Ausführung des voranstehend beschriebenen Verfahrens ausgestaltet sein.
Das erste Kryptoverfahren kann ein asymmetrisches Kryptoverfahren und das zweite Kryptoverfahren ein symmetrisches Kryptoverfahren sein. Die erste Firmware-Komponente kann weiter umfassen: einen einen Zufallszahlengenerator umfassenden Schlüsselgenerator und einen Algorithmus zur Ablage eines mittels des Schlüsselgenerators erzeugten Schlüssels für das zweite Kryptoverfahren in einem persistenten Speicher des Mikrocontrollers. Der Authentifizierungs-Algorithmus nach dem zweiten Kryptoverfahren kann dazu ausgestaltet sein, aus dem gespeicherten Schlüssel und dem Firmware-Programmcode eine Prüfsumme zu erzeugen und diese mit der zweiten Authentifizierungsinformation zu vergleichen.
Die erste und/oder die zweite Firmware-Komponente können zusätzlich einen weiteren Algorithmus zur Entschlüsselung eines Firmware-Images oder der Daten, die in dem von dem Firmware-Image umfassten Datenbereich enthalten sind, insbesondere eines von dem Firmware-Image umfassten Firmware-Programmcodes, insbesondere mit einem symmetrischen Verschlüsselungsverfahren, umfassen.
Die Übermittlung des ersten und/oder zweiten Firmware-Images an das Gerät kann auch unter Nutzung eines leicht angreifbaren Datenübermittlungskanals erfolgen, insbesondere unter Nutzung eines Fernwartungs- oder Funkinterfaces oder unter Verwendung eines transportablen Speichermediums, wie eines USB-Sticks oder einer SD-Karte.
Das Gerät kann insbesondere ein Messgerät sein, welches einen Messwandler aufweist, welcher von einer Messgröße abhängige, insbesondere digitale, Messsignale erzeugt. In dieser Ausgestaltung kann die Geräteelektronik eine mit dem Messwandler zum Empfang der Messsignale, insbesondere lösbar oder nicht lösbar, verbundene Messelektronik umfassen, welche dazu ausgestaltet ist, die Messsignale zu verarbeiten und die verarbeiteten Messsignale an eine übergeordnete Einheit auszugeben.
Die Erfindung wird im Folgenden im Detail anhand des in der Figur dargestellten Beispiels beschrieben.
Die 1 zeigt eine Schemazeichnung eines Geräts der Mess- und Regeltechnik.
Das in 1 schematisch dargestellte Gerät 1 ist ein Messgerät mit einem Messwandler 2 und einer Sensorelektronik 3. Die Sensorelektronik 3 umfasst einen A/D-Wandler 4, der die von dem Messwandler 2 erzeugten analogen Signale digitalisiert, einen Mikrocontroller 5, der die digitalisierten Messsignale empfängt und weiter verarbeitet, und eine Datenschnittstelle 6, über die der Mikrocontroller 5 die verarbeiteten Messsignale und/oder andere Informationen über Funk 7 oder über eine Leiterschleife 8 an eine übergeordnete Einheit 9, 10 ausgeben kann. Bei der übergeordneten Einheit 10 handelt es sich im vorliegenden Beispiel um einen tragbaren Computer, z.B. ein Smartphone. Die übergeordnete Einheit 9 kann beispielsweise eine Prozessleitstelle eines industriellen Prozesses sein. Das Gerät 1 weist außerdem eine Schnittstelle 11 zum Anschluss eines Speichermediums, z.B. einer SD-Karte 12, auf. Das Gerät 1 kann wahlweise mit der übergeordneten Einheit 9 und/oder der übergeordneten Einheit 10 verbunden werden. Um ein Firmware-Update durchzuführen, kann ein Firmware-Image, das den Programmcode der neuen Firmware enthält, von der Einheit 9 über die Leiterschleife 8 oder von der Einheit 10 über Funk 7 oder von der über die Schnittstelle 11 mit dem Gerät 1 verbundenen SD-Karte 12 an das Gerät 1, konkret über die Datenschnittstelle 6 an den Mikrocontroller 5, übertragen werden.
Der Mikrocontroller 5 weist einen Flash-Speicher mit einer Firmware 13 auf, die mindestens zwei Firmware-Komponenten A, B umfasst. Die erste Komponente ist eine Applikations-Komponente, im Folgenden kurz als Applikation A bezeichnet. Die zweite Komponente ist eine Bootloader-Komponente, im Folgenden kurz als Bootloader B bezeichnet. Die Applikation A stellt Grundfunktionalitäten des Geräts 1 zur Verfügung. Der Bootloader B dient zur Aktualisierung der Applikation A in Form eines Firmware-Updates nach dem in der Einleitung beschriebenen Verfahren. Weiter besitzt das Gerät 1 einen persistenten Speicher 16, der im vorliegenden Beispiel als Teil des Mikrocontrollers 5 dargestellt ist. Im persistenten Speicher des Gerätes 16 befindet sich ein öffentlicher Schlüssel PK eines asymmetrischen Signaturverfahrens abgelegt.
Die Firmware-Komponente A weist die folgenden Komponenten auf:

– Eine Entropiequelle 17, beispielsweise einen Zufallszahlengenerator
– Einen Algorithmus 18 zum, insbesondere segementweisen, Empfang eines neuen Firmware-Images
– Einen Algorithmus 19 zur asymmetrischen Signaturprüfung
– Einen Algorithmus 20 zur Generierung einer als Authentifizierungsinformation dienenden symmetrischen Prüfsumme MAC nach einem symmetrischen Kryptoverfahren, z.B. einen MAC-Algorithmus
– Eine Software-Komponente zur Ablage eines symmetrischen Schlüssels SK und einer generierten symmetrischen Prüfsumme MAC im persistenten Speicher 16

Die Firmware-Komponente B enthält dabei die folgenden Komponenten

– Einen Algorithmus 21 zum Empfang eines neuen Firmware-Images
– Einen Algorithmus 22 zum Auslesen des symmetrischen Schlüssels SK und MAC aus einem Speicher 16 und zur Errechnung und Prüfung einer symmetrischen Prüfsumme MAC der mit dem neuen Firmware-Image übermittelten neuen Firmware.

Optional enthalten die Komponenten A und/oder B noch zusätzlich einen Algorithmus zur Entschlüsselung eines Firmware-Images bzw. eines in dem Firmware-Image enthaltenen Firmware-Programmcodes mit einem symmetrischen Schlüssel (nicht in 1 dargestellt). Diese Verschlüsselungskomponente dient jedoch lediglich zum Know-How-Schutz des Geräteherstellers der Automatisierungskomponente, und nicht in erster Linie zum Schutz eines Anlagenbetreibers vor einem Datensicherheitsangriff. Sie ist daher optional.
Das Verfahren zur Aktualisierung der Firmware 13, insbesondere der Applikation A, besteht darin, dass der authentische Gerätehersteller sich einen asymmetrischen Signaturalgorithmus auswählt und für diesen Algorithmus ein öffentliches/privates Schlüsselpaar erzeugt. Er stellt dabei mit ausreichender Sorgfalt sicher, dass nur berechtigte Personen, die für die Freigabe einer authentischen Software verantwortlich sind, Verfügungsgewalt über den privaten Schlüssel erlangen können. Der zugehörige öffentliche Schlüssel PK wird dann bekannt gemacht und unter anderem im Speicher 16 des ausgelieferten Gerätes 1 abgelegt, so dass dieser öffentliche Schlüssel PK für den Prozess des Firmware-Updates dort verfügbar ist.
In der Firmware-Komponente A sind dann für das Firmware-Update die folgenden Verfahrensschritte implementiert:

1. Zunächst wird mit dem Zufallszahlengenerator 17 eine unvorhersagbare Zufallszahlensequenz SK von vorzugsweise mindestens 80 Bits generiert und im Speicher persistiert. Diese Zufallszahlensequenz dient in einem weiteren Verfahrensschritt als symmetrischer Schlüssel SK für einen symmetrischen MAC-Algorithmus.
2. Dann wird über das externe Dateninterface 6 ein erstes Mal die neue Firmware als Bestandteil eines Firmware-Images von einem externen Gerät, z.B. einer der übergeordneten Einheiten 9, 10 oder von der SC-Karte 12 übertragen. Die empfangenen Firmware-Daten werden dabei von dem Algorithmus 18 segmentweise empfangen und nur an die zwei unten beschriebenen Kryptographiealgorithmen weiter geleitet und anschließend verworfen und nicht weiter gespeichert. Dadurch muss der Mikrocontroller 5 keinen wesentlichen Speicherplatz für den Empfang und die Authentifizierung der neuen Firmware bereitstellen.
3. Mit den eingegangenen Firmware-Daten wird parallel zur Übertragung der symmetrische MAC-Prüfsummenalgorithmus 20 durchgeführt. Dieser erhält neben den empfangenen zu prüfenden Firmware-Daten als Eingabegröße den soeben neu generierten Schlüssel SK aus dem Speicher 16. Zeitgleich erfolgt die asymmetrische Signaturprüfung durch den Algorithmus 19 unter Verwendung des im Speicher 16 abgelegten öffentlichen Schlüssels PK.
4. Nach vollständig erfolgter Übertragung des neuen Firmware-Images liegt das Ergebnis der asymmetrischen Signaturprüfung vor. Ebenfalls liegt die auf Basis des gerade eben selbst generierten Schlüssels SK errechnete, einfach zu verifizierende symmetrische MAC-Prüfsumme MAC vor.
5. Sofern die asymmetrische Signaturprüfung erfolgreich war, wird die zugehörige symmetrische MAC-Prüfsumme im Speicher 16 persistiert. Dort liegen also nun ein frisch generierter symmetrischer Schlüssel SK und der für diesen Schlüssel generierte symmetrische Prüfsumme MAC für die im Rahmen des asymmetrischen Verfahren als „authentisch“ erkannte neue Firmware. Besonders vorteilhaft ist dabei, dass der für die symmetrische Prüfsummenberechnung verwendete Schlüssel SK für einen Angreifer nicht vorhersagbar ist.

Im Anschluss wird dann nach den erfolgreich abgearbeiteten obigen Schritten die Kontrolle an den Bootloader B übergeben. Dort erfolgen dann die Schritte:

1. Der Speicherbereich, in den die neue Firmware abgelegt werden soll, wird vorbereitet (gelöscht). Dieser Speicherbereich wurde vorher eventuell von der Applikation A zumindest teilweise beansprucht.
2. Anschließend wird die neue Firmware als Bestandteil eines weiteren Firmware-Images ein zweites Mal von dem externen Gerät über die Datenschnittstelle 6 übertragen und jetzt während des Empfangs in dem vorbereiteten Speicherbereich persistiert. In diesem Schritt erfolgt auch die optionale Entschlüsselung des Firmware-Programmcodes (um den Firmware-Code vertraulich zu halten und Know-How z.B. des Geräteherstellers zu schützen).
3. Parallel zu dieser zweiten Übertragung wird auf Basis des persistierten Schlüssels SK und des mit geringem Speicherbedarf implementierbaren symmetrischen MAC-Algorithmus 22 die symmetrische Prüfsumme errechnet.
4. Nach Empfang des vollständigen Firmware-Images wird anschließend geprüft, dass die vom Bootloader B errechnete MAC-Prüfsumme mit der von der Applikation A entsprechend errechneten und im Speicher 16 abgelegten Prüfsumme MAC übereinstimmt. Übereinstimmung der MAC-Prüfsummen impliziert die Übereinstimmung des von dem Bootloader B bei der zweiten Übertragung empfangenen Firmware-Daten mit den zuvor bei der ersten Übertragung von der Applikation A empfangenen und mittels des Algorithmus 19 zur asymmetrischen Signaturprüfung authentifizierten Firmware-Daten. Liegt diese Übereinstimmung vor, ist gleichzeitig die Authentizität des an den Bootloader B bei der zweiten Übertragung übertragenen Firmware-Images bzw. der darin enthaltenen Firmware-Daten sichergestellt.
5. Sofern die von den Firmware-Komponenten A und B errechneten symmetrischen Prüfsummen identisch sind, wird die neu empfangene und jetzt auch im Speicher persistierte Firmware aktiv geschaltet und ausgeführt. Anderenfalls wird erneut Schritt 1 aus dieser Aufführung ausgeführt und die offenbar nichtauthentische Firmware wieder gelöscht.

Beachtlich ist, dass im Fall der als Option beschriebenen Kombination von Firmware-Signatur (Authentizität) und Firmware-Verschlüsselung (Vertraulichkeit) die Reihenfolge von Signatur-Errechnung und Verschlüsselung austauschbar sind und für das hier beschriebene Verfahren die Reihenfolge nicht relevant ist. Vorzugsweise wird empfohlen, die Firmware zunächst zu verschlüsseln und die Signatur über die verschlüsselte Firmware zu errechnen.
Im konkreten Ausführungsbeispiel besteht das in dem Gerät 1 enthaltene System, an das eine neue Firmware übertragen werden soll, aus einem Mikrocontroller 5 mit 64 kByte Flash-Speicher. Dieser Speicher wird aufgeteilt in 59k Applikations-Programm (Komponente A), 1 kByte Datensektion z.B. für kryptographische Schlüssel und MAC-Codes (Speicher 16) und 4 kByte Bootloader (Komponente B). In vielen Fällen ist der Speicher des Mikrocontrollers direkt integriert, bei manchen Systemen wird der Speicher des Mikrocontrollers über einen externen Speicherchip außerhalb des Gehäuses der CPU angebunden.
Kandidaten für diesen Mikrocontroller wären z.B. 8-Bit CPUs der Hersteller Atmel aus der Serie AVR oder ARM-basierte Mikrocontroller der Hersteller Texas Instruments, NXP oder ST-Microelectronics mit vergleichbarem Speicherausbau. Diese Systeme verfügen typisch über 8 bis 16 kByte RAM-Speicher.
Der Bootloader B integriert dabei neben den Routinen für den Empfang der Firmware über ein serielles SPI oder UART-Interface Routinen zum partiellen Löschen des Flashs.
Die Daten für das Firmware-Update werden über ein geeignetes Interface so ins Gerät 1 übertragen, dass das Teilsystem, welches ein Firmware-Update erhalten soll, diese Daten über das serielle Interface übermittelt werden können. Diese Übertragung kann z.B. funkbasiert über Bluetooth oder WLAN übers Internet über einen Fernwartungszugang oder über ein Feldbus-Interface erfolgen. In diesem Fall kann ein Angreifer, der zumindest partiell Kontrolle über den Datenkanal erhält, dem Feldgerät ein nicht authentisches Firmware-Image übermitteln.
Beachtlich ist, dass insbesondere im Fall von Funk oder Internetverbindungen, die Übermittlung der Firmware-Daten vollkommen unbeobachtet manipuliert werden könnte und in diesem Fall die Authentizitätsprüfung der Firmware über eine asymmetrische Firmware-Signatur ggf. besonders wichtig wird.
Alternativ ist möglich, die Daten über ein transportables Speichermedium, wie z.B. SD-Karten oder USB-Sticks zu übermitteln. Auch hier hat ein Angreifer mit zumindest temporärem Zugang zum Messgerät die Möglichkeit, zu versuchen, ein nichtauthentisches Firmware-Image zu übermitteln.
Es ist ggf. vorteilhaft, die Daten der neuen Firmware in einem ggf. verfügbaren „größeren“ Mikroprozessorsystem des gleichen Messgeräts temporär lokal abzulegen (zu cachen), bevor sie dem kleinen Mikrocontroller über das serielle Interface übermittelt werden. In diesem Fall besteht vom Mikrocontroller eine serielle Datenverbindung zum „größeren“ Partner-Controller, der das ggf. gecachte Firmware-Image weiterreicht.
Der Bootloader B implementiert einen symmetrischen MAC-Algorithmus (Algorithmus 22) zur Prüfsummenerrechnung. Als konkretes Ausführungsbeispiel wird die Implementierung des Algorithmus Chaskey-LTS vorgeschlagen, alternativ die Verwendung eines MAC-Verfahrens auf Basis des Algorithmus AES128-CBC, für den Fall dass z.B. im Mikrocontroller eine Hardware-Beschleunigereinheit für AES128 zur Verfügung stehen sollte oder anderer Prüfsummenverfahren, wie z.B. aus der Siphash-Familie. Diese Algorithmen lassen sich mit einem RAM-Bedarf in der Größenordnung von 64 Bytes und einem Flash-Bedarf in der Größenordnung von 512 Bytes implementieren und sind damit kompatibel mit dem Gesamt-Speicherbudget des Bootloaders B von 4 kByte.
Die Applikation A implementiert den gleichen symmetrischen MAC-Algorithmus (Algorithmus 20) und zusätzlich ein asymmetrisches Verfahren zur Signaturprüfung (Algorithmus 19). Für die dort während des Firmware-Updates verwendete zusätzliche asymmetrische Signaturprüfung wird dort z.B. ein Verfahren auf Basis von Elliptischen Kurven eingesetzt. Z.B. der Algorithmus EdDSA auf der elliptischen Kurve Curve25519. Die Nutzung der Kurve Curve25519 und EdDSA ermöglicht dabei eine besonders Code- und ressourcensparende Implementierung der Signaturprüfung.
Alternativ zu EdDSA auf Edwards-Kurven sind ebenso sogenannte Koblitz-Kurven auf Galois-Körpern oder sogenannte „Short-Weierstrass“ Kurven aus den Standards des NIST, der SECP-Gruppe oder der sogenannten Brainpool-Arbeitsgruppen verwendbar, für die unter dem Namen ECDSA asymmetrische Signaturverfahren standardisiert sind (siehe z.B. Standard ANS X9.62, http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf). Der EdDSA Algorithmus verwendet neben einer sogenannten Skalarmultiplikation auf der elliptischen Kurve einen kryptographisch sicheren, kollisionsresistenten HASH-Algorithmus, z.B. SHA512 oder SHA-3. Der Signaturprüfungsalgorithmus EdDSA auf Curve25519 (inklusive SHA512) erfordert einen Speicherbedarf von ca. 15 kByte ROM und ca. 512 Bytes RAM und ist kann damit im Speicherbudget der Applikationsfirmware A implementiert werden.
Alternativ sind für die Applikation A auch Implementierungen asymmetrischer Signaturen auf Basis von Primzahlkörpern möglich, z.B. RSA- oder DSA-Basierte Signaturen. Im Vergleich mit Signaturalgorithmen auf Basis elliptischer Kurven (ECDSA, EdDSA) besteht der Vorteil letzterer darin, dass die Signaturfelder deutlich kürzer sind als bei RSA- oder DSA-Algorithmen und im Vergleich mit RSA-basierten Signaturen nur unwesentlich langsamer und mit geringerem Speicherbedarf an RAM errechnet werden können.
Der für die Signaturprüfung erforderliche öffentliche Schlüssel PK ist vorzugsweise in jedes ausgelieferte Firmware-Image fest eincompiliert. Er könnte jedoch auch unabhängig vom Firmware-Image in einen definierten Speicherbereich des Mikrocontrollers abgelegt werden, z.B. in dem erwähnten 1 kByte-Bereich (Speicher 16) welcher für Daten reserviert ist.
Die Zufallszahlengenerierung zur Erzeugung eines für jedes Firmware-Update frisch generierten geräteindividuellen Schlüssels SK erfolgt auf Basis der bekannten Verfahren für kryptographisch sichere Zufallszahlengenerierung. Insbesondere wird im Ausführungsbeispiel der Zufallszahlengenerator unter anderem durch einen während der Gerätefertigung einmalig übermittelten sogenannten Seed-Wert parametriert, sowie zusätzlich durch im Gerät verfügbare Entropiequellen, wie rauschbehaftete Messwerte, unvorhersagbare Zeitstempel und ggf. Hardware-Zufallszahlengeneratoren.
Beispielsweise wird vorgeschlagen, die Zufallszahlen dadurch zu generieren, dass zunächst die verschiedenen Entropiequellen, wie initiales geräteindividuelles Factory-Randomseed FRS (in der Gerätefertigung initial vom Prüfplatz des Herstellers errechnet und im Flash abgelegt), Boot-Zähler BC, rauschbehaftete ADC-Werte ADCNOISE, etc. mittels eines sogenannten kryptographischen Hash-Algorithmus wie SHA512 zu einer Zahl RS = SHA512(FRS || BC || ADCNOISE) zusammengemischt werden. Das Ergebnis RS kann dann selbst als Zufallszahl verwendet werden, oder als Schlüssel für eine sogenannten Stream-Cipher-Algorithmus, wie AES128-CTR, Salsa20, Chacha20 genutzt werden, der dann für die Generierung der Zufallszahlen genutzt wird. Dieses Vorgehen stellt sicher, dass ein potentieller Angreifer den genauen Wert des im Zuge des Firmware-Updates verwendeten Schlüssels SK nicht vorhersagen kann und damit auch keine Möglichkeit hat, ein Firmware-Image mit manipulierten Daten zu generieren das bei der oben beschriebenen zweiten Übertragung über die externe Datenschnittstelle an den Bootloader B fälschlich als authentisch erkannt wird.
Für eine neu zu übertragende Firmware zur Aktualisierung der Firmware des Systems im Gerät 1 wird mit Hilfe des privaten Schlüssels ein Signaturfeld generiert. Dieser Schlüssel ist nur beim Gerätehersteller ausgewählten Personenkreisen verfügbar. An den Programmcode und ggf. zugehörigen konstanten Datenbereiche der Firmware wird anschließend die daraus errechnete EdDSA-Signatur AS angehängt. Mit dem Begriff Firmware-Image wird hier eine geeignete Kombination von Datenbereich (Firmware-Programmcode + konstante Daten) und einem optional vorhandenen Signaturfeld AS bezeichnet. Die im Datenbereich enthaltenen Daten werden auch als Firmware oder als Firmware-Daten bezeichnet. Im Stand der Technik sind verschiedene sogenannte Container-Formate bekannt, um an einen Datenblock ein Signatur-Feld anzuhängen, z.B. unter dem ITU-T Standard X.509, wie er für Internet-Zertifikate verwendet wird. Für solche Container-Formate gibt es z.B. fertige Standard-Programme zur Überprüfung des Signaturfelds. Für den hier beschriebenen Fall reicht es aber beispielsweise auch vollkommen aus, das Firmware-Image dadurch zu generieren, dass dem Datenbereich eine Längenangabe vorangestellt und an den Datenbereich das Signaturfeld angehängt wird.
Für das Firmware-Update wird von der Applikation A im Mikrocontroller 5 ein frischer Schlüssel SK ermittelt. Anschließend wird das Firmware-Image dem asymmetrischen Signaturprüfungsalgorithmus 19 zugeführt und parallel auch dem symmetrischen MAC-Algorithmus 20 (z.B. Chaskey-LTS). Letzterer verwendet für die Prüfsummenerrechnung den symmetrischen Schlüssel SK, der anhand des Zufallszahlengenerators frisch erzeugt wurde und im Speicher 16 persistiert wird. Dabei ist der Aspekt wichtig, dass es weder für die Signaturprüfung noch für das symmetrische Prüfsummenverfahren erforderlich ist, dass das Firmware-Image zu einem gegebenen Zeitpunkt in Gänze im RAM-Speicher des Mikrocontrollers verfügbar ist. Es reicht vielmehr aus, die Daten des Firmware-Images segmentweise nach und nach zu verarbeiten, beispielsweise in Blöcken von 16 oder 128 Bytes. Es wird dabei jeweils nacheinander ein solches Teilsegment für die Prüfsummenverfahren herangezogen und anschließend im Speicher ggf. vom darauf folgenden Datensegment überschrieben. In der Fachsprache spricht man hierbei häufig davon, dass die beiden Kryptographie-Verfahren über ein speichersparendes sogenanntes „streaming“-Applikations-Interface implementiert werden können, bei dem die Daten in Form eines sequentiellen „Stroms“ von kleineren Teilsegmenten übermittelt werden.
Im Zuge der Übermittlung des vollständigen Firmware-Images empfängt die Applikation A auch das an das Firmware-Image angehängte generierte Signaturfeld AS über das serielle Interface. Dieser von extern empfangene Wert AS wird mittels des EdDSA-Algorithmus 19 unter Zuhilfenahme des verfügbaren öffentlichen Schlüssels des Geräteherstellers auf Authentizität überprüft.
Sofern die Signaturprüfung erfolgreich verlaufen sein sollte, wird der mit dem symmetrischen Schlüssel SK errechnete symmetrische Prüfsummenwert MAC für die Daten des gerade empfangenen Firmware-Images im Flash-Speicher 16 abgelegt und die Kontrolle der CPU an die Bootloader-Firmware B abgegeben.
Diese löscht anschließend den vormals von der Applikation A belegten Speicherbereich im Flash. Sie findet im Speicher 16 den für den symmetrischen Algorithmus 22 (z.B. Chaskey) zu verwendenden Schlüssel SK und das richtige Ergebnis der Prüfsumme MAC vor, das die Firmware-Komponente A gerade eben errechnet hat. Diese Prüfsumme MAC ist für niemanden vorhersagbar, auch nicht für den Gerätehersteller, da in diesen Wert der unvorhersagbare Schlüssel SK mit eingeht.
Anschließend fordert der Bootloader B erneut die Übertragung der kompletten Firmware-Daten an, empfängt ein daraufhin übertragenes zweites, die Firmware-Daten enthaltendes Firmware-Image, führt mit den empfangenen Firmware-Daten die symmetrische Prüfsummenberechnung durch und verifiziert die Korrektheit des erneut übertragenen Firmware-Images anhand der erforderlichen Übereinstimmung mit dem entsprechenden Ergebnis der alten Applikation A (die jetzt im Flash nicht mehr verfügbar ist). Während dieser zweiten Übertragung erfolgt also die symmetrische Prüfsummenberechnung und die Ablage der Daten im vorbereiteten gelöschten Flashbereich.
Nach vollständiger erneuter Übertragung des neuen Firmware-Images erfolgt die Überprüfung der symmetrischen Prüfsumme. Sofern das Ergebnis mit dem von der alten Applikation A errechneten Prüfsumme übereinstimmt, wird auf Authentizität erkannt und die neue Firmware als gültig gewertet und aktiv geschaltet. Sie ersetzt somit die zuvor gelöschte, alte Applikation A. Anschließend übergibt der Bootloader die Kontrolle an die neue Applikation und löscht den Speicherbereich des Speichers 16, in dem beim letzten Update die Schlüssel SK und die symmetrische Prüfsumme abgelegt waren.
Der Vorteil dieses Verfahrens besteht darin, dass nun auch unter der Rahmenbedingung eines begrenzten Speicherbudgets einer Bootloader-Firmware eine verlässliche und robuste asymmetrische Signaturprüfung erfolgreich umgesetzt werden kann.
Der Fachmann wird neben der oben beschriebenen Variante ohne Verschlüsselung der Firmware auch Varianten betrachten, bei denen nicht nur eine Firmware-Authentizitätsprüfung erfolgt, sondern auch die Firmware selbst verschlüsselt wird. Dazu wird zusätzlich zum öffentlichen Schlüssel des Geräteherstellers aus dem Signaturalgorithmus auch noch ein (geheim zu haltender) symmetrischer Schlüssel für die Firmware-Entschlüsselung abgelegt. Die Signaturprüfung erfolgt vorzugsweise für die verschlüsselte Firmware, kann jedoch auch für die entschlüsselte Firmware in anderer Reihenfolge durchgeführt werden.
Beachtlich ist, dass nach Durchführung des Verfahrensschritts 1.) in der Bootloader-Komponente B ein Firmware-Update nur noch mit exakt der gleichen Firmware möglich ist, die zuvor in der Applikation als korrekt verifiziert wurde. Vorteilhafterweise wird deswegen zusammen mit dem Schlüssel SK und der von der Applikation errechneten symmetrischen MAC-Prüfsumme auch eine Firmware-Kennung im Flash-Speicher abgelegt, welche die zu übertragende Firmware-Daten eindeutig identifiziert, z.B. eine Firmware-Versionsnummer. Mittels dieser Firmware-Versionsnummer kann so z.B. die Bootloader-Software der übertragenden Gegenstelle über das Dateninterface 6 mitteilen, exakt welche Firmware-Version jetzt erwartet wird. Dies kann z.B. dann relevant sein, wenn ein Firmware-Update abgebrochen wurde (z.B. wegen eines Stromausfalls) und zu einem späteren Zeitpunkt wieder aufgenommen werden soll.
Zusammenfassend wird mit der Erfindung die Möglichkeit eröffnet, sichere asymmetrische Signaturen für die Absicherung von Firmware-Updates auch in kleinsten Microcontroller-Systemen mit begrenztem Speicherbudget durchzuführen.
Dieser Vorteil wird im Wesentlichen nur durch den Nachteil erkauft, dass die Firmware nicht nur einmalig, sondern zweimalig übertragen werden muss und im ersten Schritt die Signaturprüfung erfolgt und die Ablage des Image und das Überschreiben des bisherigen Speichers erst im nachfolgenden Schritt.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

Des. Codes Cryptogr. (2015) 77:493–514 [0021]
Standard ANS X9.62, http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf [0075]
ITU-T Standard X.509 [0080]

Claims

Verfahren zum Aktualisieren einer die Funktionalität eines Geräts der Mess- und Regeltechnik bereitstellenden ersten Firmware-Komponente, welche in einen Mikrocontroller des Geräts eingebettet ist, umfassend: – Segmentweises Empfangen eines ersten Firmware-Images über ein mit einem externen Gerät verbundenes Dateninterface des Mikrocontrollers, wobei das erste Firmware-Image einen Datenbereich und ein Signaturfeld umfasst, und wobei der Datenbereich zur Aktualisierung der ersten Firmware-Komponente dienende, einen Firmware-Programmcode umfassende Daten enthält und das Signaturfeld eine nach einem ersten Kryptoverfahren erzeugte erste Authentifizierungsinformation enthält; – Durchführen einer Authentifizierung des ersten Firmware-Images anhand der ersten Authentifizierungsinformation mittels eines von der ersten Firmware-Komponente umfassten Authentifizierungs-Algorithmus nach dem ersten Kryptoverfahren; – Erzeugen einer zweiten Authentifizierungsinformation für die im Datenbereich des ersten Firmware-Images enthaltenen Daten mittels eines von der ersten Firmware-Komponente umfassten Algorithmus zur Erzeugung der zweiten Authentifizierungsinformation nach einem von dem ersten Kryptoverfahren verschiedenen, zweiten Kryptoverfahren; – nach erfolgreicher Authentifizierung des ersten Firmware-Images Speichern der zweiten Authentifizierungsinformation in einem persistenten Speicher des Geräts; – Löschen der ersten Firmware-Komponente, wobei das Löschen durch eine in den Mikrocontroller eingebettete zweite Firmware-Komponente gesteuert wird; – erneute Übertragung der zur Aktualisierung der ersten Firmware-Komponente dienenden Daten als Bestandteil eines zweiten Firmware-Images unter Beteiligung der zweiten Firmware-Komponente über das Dateninterface an den Mikrocontroller und Speichern der Daten im persistenten Speicher des Mikrocontrollers; – Durchführen einer Authentifizierung des bei der erneuten Übertragung empfangenen zweiten Firmware-Images anhand der in dem Mikrocontroller gespeicherten zweiten Authentifizierungsinformation mittels eines von der zweiten Firmware-Komponente umfassten Authentifizierungs-Algorithmus nach dem zweiten Kryptoverfahren, und – für den Fall einer erfolgreichen Authentifizierung des zweiten Firmware-Images Aktivschalten und Ausführen des mit dem zweiten Firmware-Image übertragenen und gespeicherten Firmware-Programmcodes als neue erste Firmware-Komponente.
Verfahren nach Anspruch 1, weiter umfassend: für den Fall einer nicht erfolgreichen Authentifizierung des zweiten Firmware-Images, Löschen der mit dem zweiten Firmware-Image übertragenen und gespeicherten Daten, insbesondere des gespeicherten Firmware-Programmcodes.
Verfahren nach Anspruch 1 oder 2, wobei das erste Kryptoverfahren ein asymmetrisches Kryptoverfahren ist, beispielsweise ein Verfahren auf Basis von Elliptischen Kurven, insbesondere auf Basis des EdDSA-Algorithmus auf der elliptischen Kurve Curve25519, eines Verfahrens der ECDSA-Standardfamilie oder ein Verfahren auf der Basis von Primzahlkörpern, insbesondere ein RSA- oder DSA-Verfahren.
Verfahren nach Anspruch 3, wobei das zweite Kryptoverfahren ein symmetrisches Kryptoverfahren ist, beispielsweise ein MAC-Verfahren auf Basis eines Blockverschlüsselungsalgorithmus, insbesondere ein Verfahren auf Basis der Algorithmenfamilie Chaskey oder AES128-CBC.
Verfahren nach Anspruch 4, wobei das symmetrische Kryptoverfahren keinen kollisionsresistenten Hash-Algorithmus als Teilkomponente umfasst.
Verfahren nach einem der Ansprüche 3 bis 5, wobei die erste Authentifizierungsinformation eine mit einem privaten Schlüssel unter Verwendung der in dem Datenbereich enthaltenen Daten, insbesondere des Firmware-Programmcodes, erzeugte digitale Signatur ist; und wobei das Durchführen der Authentifizierung des ersten Firmware-Images eine Überprüfung der digitalen Signatur mittels eines in einem persistenten Speicher des Mikrocontrollers gespeicherten öffentlichen Schlüssels umfasst.
Verfahren nach einem der Ansprüche 4 bis 6, wobei das Erzeugen der zweiten Authentifizierungsinformation umfasst: Erzeugen einer als zweite Authentifizierungsinformation dienenden Prüfsumme nach dem zweiten Kryptoverfahren aus einem mittels eines von der ersten Firmware-Komponente umfassten Schlüsselgenerators erzeugten Schlüssels und der in dem Datenbereich enthaltenen Daten, insbesondere dem von dem ersten Firmware-Image umfassten Firmware-Programmcode.
Verfahren nach Anspruch 7, wobei der mittels des Schlüsselgenerators erzeugte Schlüssel in einem persistenten Speicher des Mikrocontrollers abgespeichert wird, und wobei das Durchführen einer Authentifizierung des zweiten Firmware-Images anhand der zweiten Authentifizierungsinformation umfasst: Erzeugen einer Prüfsumme nach dem zweiten Kryptoverfahren aus dem mittels des Schlüsselgenerators erzeugten Schlüssel und der von dem zweiten Firmware-Image umfassten Daten, insbesondere dem von dem zweiten Firmware-Image umfassten Firmware-Programmcode; und Vergleichen der Prüfsumme mit der zweiten Authentifizierungsinformation, wobei die Authentifizierung erfolgreich ist, wenn die Prüfsumme mit der zweiten Authentifizierungsinformation übereinstimmt.
Verfahren nach Anspruch 7 oder 8, wobei der Schlüsselgenerator einen Zufallszahlengenerator umfasst und wobei der Schlüssel eine Zufallszahlensequenz, insbesondere von mindestens 80 Bits, ist.
Verfahren nach einem der Ansprüche 1 bis 9, wobei der Firmware-Programmcode des ersten und des zweiten Firmware-Images verschlüsselt ist und wobei das Verfahren weiter umfasst: Entschlüsseln des Firmware-Programmcodes mittels eines zusätzlichen Entschlüsselungsalgorithmus der ersten und/oder der zweiten Firmware-Komponente.
Gerät der Mess- und Regeltechnik umfassend: eine Geräteelektronik mit mindestens einem Mikrocontroller; wobei der mindestens eine Mikrocontroller eine eingebettete Firmware umfasst, welche mindestens eine erste Firmware-Komponente und eine zweite Firmware-Komponente aufweist, und wobei die erste Firmware-Komponente umfasst: – einen oder mehrere Algorithmen zur Bereitstellung von Funktionalitäten des Geräts; – einen Algorithmus zum Empfang eines ersten Firmware-Images, welches einen Datenbereich und ein Signaturfeld umfasst, wobei der Datenbereich zur Aktualisierung der ersten Firmware-Komponente dienende, einen Firmware-Programmcode umfassende, Daten enthält, und wobei das Signaturfeld eine nach einem ersten Kryptoverfahren erzeugte erste Authentifizierungsinformation enthält; – einen Authentifizierungs-Algorithmus zur Authentifizierung des ersten Firmware-Images anhand der ersten Authentifizierungsinformation nach einem ersten Kryptoverfahren; – einen Algorithmus zur Erzeugung einer zweiten Authentifizierungsinformation aus den in dem Datenbereich enthaltenen Daten, insbesondere dem Firmware-Programmcode, nach einem von dem ersten Kryptoverfahren verschiedenen, zweiten Kryptoverfahren; und – einen Algorithmus zur Ablage der zweiten Authentifizierungsinformation in einem persistenten Speicher des Microcontrollers; und wobei die zweite Firmware-Komponente umfasst: – einen Algorithmus zum Empfangen eines zweiten Firmware-Images, welches die zur Aktualisierung der ersten Firmware-Komponente dienenden Daten, insbesondere einen zur Aktualisierung der ersten Firmware-Komponente dienenden Firmware-Programmcode, umfasst; – einen Algorithmus zum Löschen der ersten Firmware-Komponente und zum Speichern des von dem zweiten Firmware-Image umfassten Firmware-Programmcodes als neue erste Firmware-Komponente; – einen Algorithmus zum Auslesen der zweiten Authentifizierungsinformation aus dem persistenten Speicher; – einen Authentifizierungsalgorithmus nach dem zweiten Kryptoverfahren zur Authentifizierung des zweiten Firmware-Images anhand der zweiten Authentifizierungsinformation und der von dem zweiten Firmware-Image umfassten Daten, insbesondere des Firmware-Programmcodes; und – einen Algorithmus zum Aktivschalten der neuen ersten Firmware-Komponente.
Gerät nach Anspruch 11, wobei das erste Kryptoverfahren ein asymmetrisches Kryptoverfahren ist und das zweite Kryptoverfahren ein symmetrisches Kryptoverfahren ist, und wobei die erste Firmware-Komponente weiter umfasst: einen einen Zufallszahlengenerator umfassenden Schlüsselgenerator und einen Algorithmus zur Ablage eines mittels des Schlüsselgenerators erzeugten Schlüssels für das zweite Kryptoverfahren in einem persistenten Speicher des Mikrocontrollers; und wobei der Authentifizierungs-Algorithmus nach dem zweiten Kryptoverfahren dazu ausgestaltet ist, aus dem gespeicherten Schlüssel und den von dem zweiten Firmware-Image umfassten Daten, insbesondere dem Firmware-Programmcode, eine Prüfsumme zu erzeugen und diese mit der zweiten Authentifizierungsinformation zu vergleichen.
Gerät nach Anspruch 11 oder 12, wobei die erste und/oder die zweite Firmware-Komponente einen weiteren Algorithmus zur Entschlüsselung eines Firmware-Images oder der Daten, die in dem von dem Firmware-Image umfassten Datenbereich enthalten sind, insbesondere eines von dem Firmware-Image umfassten Firmware-Programmcodes, insbesondere mit einem symmetrischen Verschlüsselungsverfahren, umfassen.
Gerät nach einem der Ansprüche 11 bis 13, wobei die Übermittlung des ersten und/oder zweiten Firmware-Images an das Gerät unter Nutzung eines leicht angreifbaren Datenübermittlungskanals erfolgt, insbesondere unter Nutzung eines Fernwartungs- oder Funkinterfaces oder unter Verwendung eines transportablen Speichermediums, wie eines USB-Sticks oder einer SD-Karte.
Gerät nach einem der Ansprüche 11 bis 14, wobei das Gerät einen Messwandler aufweist, welcher von einer Messgröße abhängige, insbesondere digitale, Messsignale erzeugt; und die Geräteelektronik eine mit dem Messwandler zum Empfang der Messsignale, insbesondere lösbar oder nicht lösbar, verbundene Messelektronik umfasst, welche dazu ausgestaltet ist, die Messsignale zu verarbeiten und die verarbeiteten Messsignale an eine übergeordnete Einheit auszugeben.