DE112017004786T5

DE112017004786T5 - Verfahren und vorrichtung zur verwendung eines sicherheits-coprozessors für firmwareschutz

Info

Publication number: DE112017004786T5
Application number: DE112017004786.2T
Authority: DE
Inventors: Pawel SZYMANSKI; Igor Tatourian; Marek Zmuda; Justyna Zander
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2016-09-23
Filing date: 2017-08-17
Publication date: 2019-06-19
Also published as: WO2018057167A1; CN109564606B; US20180089435A1; US10242197B2; CN109564606A

Abstract

Datenverarbeitungssystem (DPS) stellt Schutz für Firmware bereit, Das DPS umfasst (a) ein Host-Modul, umfassend eine Management-Engine und (b) ein Sicherheitsmodul in Kommunikation mit dem Host-Modul. Das Sicherheitsmodul umfasst einen Sicherheits-Coprozessor und eine geheime Kennung für das Sicherheitsmodul. The DPS umfasst auch zumindest ein maschinenzugängliches Medium, umfassend Host-Firmware und Sicherheits-Firmware. Die Host-Firmware, wenn durch die Management-Engine ausgeführt, ermöglicht der Management-Engine zu bestimmen, ob das Sicherheitsmodul mit dem Host-Modul in Kommunikation steht, basierend auf der geheimen Kennung für das Sicherheitsmodul. Die Sicherheits-Firmware, wenn durch den Sicherheits-Coprozessor ausgeführt, ermöglicht dem Sicherheits-Coprozessor, (a) die Integrität der Host-Firmware zu verifizieren und (b) zu verhindern, dass das Host-Modul mit der Host-Firmware bootet, als Reaktion auf eine Bestimmung, dass die Host-Firmware Integrität verloren hat. Andere Ausführungsformen sind beschrieben und beansprucht.

Description

QUERVERWEIS AUF VERWANDTE US PATENTANMELDUNG
Die vorliegende Anmeldung beansprucht Priorität gegenüber US Gebrauchsmusterpatentanmeldung Seriennr. 15/273,997, mit dem Titel „Methods and Apparatus to use a Security Coprocessor for Firmware Protection“, die am 23. September 2016 eingereicht wurde.
TECHNISCHES GEBIET
Diese Offenbarung betrifft im Allgemeinen Sicherheit für Datenverarbeitungssysteme und insbesondere Verfahren und Vorrichtungen, die einen Sicherheits-Coprozessor für Firmwareschutz verwenden.
ALLGEMEINER STAND DER TECHNIK
Ein eingebettetes System ist ein Datenverarbeitungssystem, das innerhalb einer größeren mechanischen oder elektrischen Einheit liegt und das ein oder mehrere verschiedene Module zur Durchführung einer oder mehrerer dedizierter Funktionen enthält. Zusätzlich kann sein, dass eine oder mehrere dieser dedizierten Funktionen Echtzeitberechnungs-, (Real-Time Computing, RTC), Einschränkungen erfüllen müssen. Beispielsweise kann sein, dass Funktionen innerhalb einer Größenordnung von Millisekunden oder Mikrosekunden reagieren müssen.
Es können viele verschiedene Arten von Einheiten in eingebetteten Systemen enthalten sein. Beispielsweise können eingebettete Systeme in Gebäuden, in Robotern, in Fahrzeugen usw. verwendet werden. Solche Fahrzeuge können, ohne Einschränkung, herkömmliche Autos und Lastkraftwägen, unbemannte („autonome“) Autos und Lastkraftwägen, bemannte Luftfahrzeuge, unbemannte Luftfahrzeuge („Dronen“), Raumfahrzeuge usw. enthalten. Ein Fahrzeug kann beispielsweise ein eingebettetes System enthalten, das ein zentrales Host-Modul und verschiedene Hilfsmodule enthält, wie eine Motorsteuereinheit (Engine Control Unit, ECU), Reifendrucküberwachungssensoren (Tire Pressure Monitoring Sensors, TPMSs) usw. Zusätzlich kann das eingebettete System des Fahrzeugs zum Implementieren eines hochentwickelten Fahrerassistenzsystems (Advanced Driver Assistance System, ADAS), Module wie Kameras, Sicht-Coprozessoren, Maschinenlernmodule usw. enthalten. Für den Zweck dieser Offenbarung kann eine Einheit mit einem eingebetteten System als eine „smarte Einheit“ bezeichnet werden.
Typischerweise wird von einem Modul in einem eingebetteten System erwartet oder verlangt, eine oder mehrere spezifische Funktionen durchzuführen. Beispielsweise kann ein eingebettetes System für ein smartes Fahrzeug eine ECU enthalten, von der erwartet oder verlangt wird, einen Motor zu steuern und verschiedene Motorleistungsmetriken einem Host-Modul zu berichten. Auch wenn ein eingebettetes System eingeschaltet oder aktiviert wird, kann notwendig sein, dass eines oder mehrere der Module im System mit Software initialisiert werden, die diesen Modulen ermöglicht, ihre erforderlichen Funktionen durchzuführen. Mit anderen Worten, ein Modul kann Software zum Durchführen einer oder mehrerer Funktionen verwenden. Für den Zweck dieser Offenbarung kann die Software, die ein Modul verwendet, als „Firmware“ bezeichnet werden. Und jedes verschiedene Modul kann verschiedene Firmware verwenden. Überdies kann ein Modul einige Teile seiner Firmware nur während des Initialisierungsprozesses verwenden und das Modul kann andere Teile seiner Firmware nach Initialisierung, während einer Durchführung der erwarteten oder erforderlichen Funktionen des Moduls im eingebetteten System verwenden. Die Teile von Firmware, die zur Initialisierung verwendet werden, können als „Boot-Code“ bezeichnet werden.
Überdies kann es in einigen Situationen wünschenswert sein, die Firmware für ein oder mehrere Module in einem eingebetteten System zu ändern oder zu aktualisieren. Das Versagen eines oder mehrerer Module in einem eingebetteten System kann jedoch gefährliche oder katastrophale Ergebnisse bewirken. Daher ist es wichtig, eingebettete Systeme vor nicht autorisierten Aktualisierungen und vor anderen Arten einer Manipulation zu schützen, wie einem nicht autorisierten Entfernen oder Ersetzen eines oder mehrerer Module. Mit anderen Worten, es ist wichtig, einen Schutz vor netzwerkbasierten Angriff und physischen Angriffen bereitzustellen.
Die vorliegende Offenbarung beschreibt Verfahren und Vorrichtungen zum Bereitstellen eines Firmwareschutzes in eingebetteten Systemen. Insbesondere beschreibt die vorliegende Offenbarung ein oder mehrere eingebettete Systeme, die einen Sicherheits-Coprozessor verwenden, um Firmwareschutz bereitzustellen.
Figurenliste

1 ist ein Blockdiagramm einer beispielhaften Ausführungsform eines eingebetteten Systems mit Firmwareschutz.
2A und 2B zeigen ein Flussdiagramm eines beispielhaften Prozesses zum Schutz von Firmware in einem eingebetteten System, wobei zumindest einige Operationen durch ein Sicherheitsmodul durchzuführen sind.
3 zeigt ein Flussdiagramm eines beispielhaften Prozesses zum Schutz von Firmware in einem eingebetteten System, wobei zumindest einige Operationen durch ein Host-Modul durchzuführen sind.

BESCHREIBUNG VON AUSFÜHRUNGSFORMEN
Eines der Sicherheitsrisiken, welchen ein eingebettetes System ausgesetzt ist, ist das Risiko, dass der Code und andere Daten, die sich in dem System befinden oder durch dieses laufen, manipuliert werden könnten. Falls beispielsweise ein Angreifer die Firmware einer oder mehrerer Komponenten eines eingebetteten Systems verändert, könnte der Angreifer den Ausführungsfluss des System schädlich verändert. Es kann jedoch eine Bedarf oder Wunsch bestehen, autorisierte Aktualisierung an der Firmware einer oder mehrerer Komponenten vorzunehmen. Folglich ist es wichtig, nicht autorisierte Firmware-Aktualisierungen zu verhindern, während autorisierte Aktualisierungen erlaubt sind.
Ein weiteres Sicherheitsrisiko, dem ein eingebettetes System ausgesetzt ist, ist das Risiko, dass das Design einer oder mehrerer Komponenten des Systems schädlich verändert werden könnte, beispielsweise durch Ersetzen einer Originalkomponente durch eine verfälschte Komponente. Ein weiteres Risiko ist, dass Daten in Echtzeit gestohlen werden könnten. Hier beschriebene Ausführungsformen können ein, einige oder alle dieser Risiken behandeln.
Wie in der Folge ausführlicher beschrieben ist, kann gemäß der vorliegenden Offenbarung ein eingebettetes System ein Host-Modul, ein Sicherheitsmodul und ein oder mehrere Hilfsmodule enthalten. Das Sicherheitsmodul kann Sicherheitsrichtlinien durchsetzen und die Integrität von Code und anderen Daten überwachen, die durch das Host-Modul verwendet werden. Beispielsweise kann das Sicherheitsmodul Priorität im Initialisierungsprozess für das eingebetteten System haben und das Sicherheitsmodul kann eine Integrität der Firmware für das Sicherheitsmodul und der Firmware für das Host-Modul verifizieren, bevor eine Fertigstellung des Boot-Prozesses erlaubt wird. Das Sicherheitsmodul kann ein Booten abbrechen, falls eine Integritätsprüfung fehlschlägt, indem die relevante Firmware mit einer Sicherungskopie ersetzt wird und dann das relevante Modul zurückgesetzt wird. Das Sicherheitsmodul kann auch die Integrität der Firmware und andere Daten auf einem, einigen oder allen der Hilfsmodule überwachen.
Das Sicherheitsmodul kann während der Boot-Sequenz Ereignisse empfangen und das Sicherheitsmodul kann auf Basis dieser Ereignisse bestimmen, ob Betriebssicherheits- oder Sicherheitsmängel vorliegen, die korrigiert werden müssen. Zusätzlich kann das Sicherheitsmodul 20 die Integrität der Firmware in jeder Phase nach dem Booten prüfen, wie als Reaktion auf ein intern generiertes Herzschlagereignis, als Reaktion auf gewisse externe und vertrauenswürdige Auslöser oder als Reaktion auf Anfragen von anderen Quellen.
Das Sicherheitsmodul kann auch Leistungsregler oder Leistungseinheiten verwalten, Systemleistung bei einem oder mehreren Modulen abschalten, falls ein Eindringen oder ein anderes unerwünschtes Verhalten erfasst wird. Falls das Sicherheitsmodul ein anderes Modul sperrt (z.B. durch Beenden einer Leistung zu diesem anderen Modul), kann das gesperrte Modul als aus dem Netzwerk entfernt bezeichnet werden. Ebenso können für den Zweck dieser Offenbarung Begriffe wie „Modul“, „Einrichtung“ und „Komponente“ untereinander austauschbar verwendet werden.
Zusätzlich kann das Sicherheitsmodul eng an das Host-Modul gekoppelt sein, wie in der Folge ausführlicher beschrieben ist.
1 ist ein Blockdiagramm einer beispielhaften Ausführungsform eines eingebetteten Systems 10 mit Firmwareschutz. In der Ausführungsform von 1 ist das eingebettete System 10 ein Datenverarbeitungssystem, das ein Host-Modul 40, ein Sicherheitsmodul 20, einen eingebetteten Speicher 30, eine Leistungseinheit 60 und verschiedene Hilfseinrichtungen enthält. Andere Ausführungsformen können auch verschiedene Anzahlen und Arten von Modulen enthalten, wie mehrere Leistungseinheiten, zusätzliche oder weniger Hilfseinrichtungen usw.
In der Ausführungsform von 1 enthalten die Hilfseinrichtungen eine externe Einrichtung 90 und einen Beschleuniger 94. Externe Einrichtungen können, ohne Einschränkung, Kameras, Radareinheiten, Lidareinheiten, Reifendrucküberwachungssensoren, Motorsteuerungseinheiten (ECUs) usw. enthalten. Beschleuniger können, ohne Einschränkung, Sicht-Coprozessoren, Maschinenlerncoprozessoren usw. enthalten. Hilfseinrichtungen können unter Verwendung von feldprogrammierbaren Gate Arrays (FPGAs), Digitalsignalprozessoren (DSPs), anwendungsspezifischen integrierten Schaltungen (ASICs) und jeder anderen geeigneten Technologie implementiert sein.
Host-Modul 40, Sicherheitsmodul 20 und Beschleuniger 94 können verschiedene Designblöcke innerhalb einer einzigen integrierten Schaltung oder innerhalb verschiedener integrierter Schaltungen innerhalb eines Packages integrierter Schaltungen sein. Master-Modul 80 stellt eine solche integrierte Schaltung oder ein solches Package integrierter Schaltungen dar. In anderen Ausführungsformen können sich Host-Module und Sicherheitsmodule in verschiedenen Packages befinden. Ebenso ist in einer Ausführungsform das Host-Modul als ein System-auf-einem-Chip (SoC) oder ein System-auf-einem-Package (SoP) implementiert und das Sicherheitsmodul ist als ein FPGA implementiert. In anderen Ausführungsformen jedoch können andere Technologien zum Implementieren des Host-Moduls und des Sicherheitsmoduls verwendet werden.
Wie später ausführlicher beschrieben wird, enthält Sicherheitsmodul 20 einen Sicherheits-Coprozessor 22, einen statischen Direktzugriffspeicher (Static Direct Access Memory, SRAM) 26 und eine geheime Kennung für Sicherheitsmodul 20. 1 zeigt diese geheime Kennung als Sicherheitsmodulkennung (Security Module Identifier, SMID) 29 innerhalb einer physischen, nicht klonierbaren Funktion (Physical Unclonable Function, PUF) 28.
Wie später ausführlicher beschrieben wird, enthält Host-Modul 40 einen Host-Prozessor 42, eine Management-Engine 44 und eine geheime Kennung 49 für das Host-Modul 40. 1 zeigt diese geheime Kennung als Host-Modulkennung (Host Module Identifier, HMID) 49 innerhalb der PUF 48. Management-Engine 44 kann als eine konvergierte Sicherheits- und Verwaltungsfunktions-Engine (Converged Security and Managability Engine, CSME) oder als jede andere geeignete Technologie implementiert sein.
Master-Modul 80 enthält auch verschiedene Kommunikationsleitungen, um Modulen zu ermöglichen, miteinander zu kommunizieren. In der Ausführungsform von 1 enthalten diese Leitungen einen Satz aus zwei, drei oder mehr redundanten Leitungen 74, die durch einen Wähler 54 gesteuert werden, der verhindert, dass Daten das Host-Modul 40 erreichen, falls nicht eine Mehrheit redundanter Leitungen 74 synchron dieselben Daten führt. In der Ausführungsform von 1 wird jede der Leitungen redundanter Leitungen 74 durch einen separaten Mikroprozessor gesteuert und Wähler 54 überwacht alle diese Leitungen um sicherzustellen, dass das eingebettete System 10 nicht manipuliert wurde. Überdies, falls Wähler 54 Daten erfasst, die nicht übereinstimmen, kann Wähler 54 veranlassen, dass ein oder mehrere der relevanten Module Abhilfemaßnahmen ergreifen, wie Laufenlassen eines Selbsttestprogramms um zu bestimmen, warum eine Leitung aus dem Ruder läuft, Durchführen einer Rücksetzung usw. In einer anderen Ausführungsform kann der Wähler an verschiedenen Stellen liegen. Beispielsweise kann sich der Wähler in der Management-Engine des Host-Moduls oder im Inneren einer kleinen vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment, TEE) innerhalb einer externen Einrichtung oder eines Beschleunigers befinden.
Das eingebettete System 10 enthält auch zusätzliche Kommunikationsleitungen, um dem Sicherheitsmodul 20 und Host-Modul zu ermöglichen, mit einer externen Einrichtung 90, Leistungseinheit 60 usw. zu kommunizieren. Beispielsweise ermöglicht Kommunikationsleitung 92 dem Sicherheitsmodul 20 und Host-Modul 40, mit der externen Einrichtung 90 zu kommunizieren, während Kommunikationsleitung 96 dem Sicherheitsmodul 20 und Host-Modul 40 ermöglicht, mit Beschleuniger 94 zu kommunizieren. Ebenso ermöglicht Kommunikationsleitung 62 dem Sicherheitsmodul 20 zu steuern, zu welchen Einrichtungen die Leistungseinheit 60 Leistung sendet. Daher zeigen die gestrichelten Linien 64, 66 und 68, dass das Sicherheitsmodul 20 die Leistungseinheit 60 veranlassen kann, Leistung zum Host-Modul 40, Beschleuniger 94 bzw. der externen Einrichtung 90 zu beenden. Zusätzlich oder alternativ können Module drahtlos kommunizieren. Das eingebettete System 10 kann auch als ein „eingebettetes Netzwerk“ bezeichnet werden. Jedes Modul kann auch einen oder mehrere Kommunikationsanschlüsse enthalten, um diesem Modul zu ermöglichen, mit anderen Modulen im Netzwerk zu kommunizieren.
Wenn das eingebettete System 10 startet oder zurückgesetzt wird, können einige oder alle der Module und Einrichtungen Initialisierungsprozesse durchführen. Zum Beispiel kann Host-Prozessor 42 einen Boot-Code innerhalb von Host-Firmware 52 durchführen und Sicherheits-Coprozessor 22 kann einen Boot-Code innerhalb von Sicherheits-Firmware 32 ausführen. Wie in der Folge ausführlicher beschrieben ist, hält jedoch in einer Ausführungsform Sicherheitsmodul 20 das Host-Modul 40 und einige oder alle anderen Einrichtungen in einem Rücksetzzustand, bis Sicherheits-Coprozessor 22 einen Teil oder den gesamten Boot-Prozess beendet. Alternativ kann Sicherheitsmodul 20 verhindern, dass einige oder alle anderen Module und Einrichtungen Leistung von der Leistungseinheit 60 empfangen, bis der Sicherheits-Coprozessor 22 einen Teil oder den gesamten Boot-Prozess beendet hat.
In der Ausführungsform von 1 befinden sich Host-Firmware 52 und Sicherheits-Firmware 32 im eingebetteten Speicher 30. Host-Prozessor 42 kann jedoch Host-Firmware 52 über Sicherheitsmodul 20 erhalten. Beispielsweise, wie in der Folge ausführlicher beschrieben ist, bevor das Sicherheitsmodul 20 dem Host-Modul 40 erlaubt zu booten, kann das Sicherheitsmodul 20 die Host-Firmware 52 validieren. Nachdem das Sicherheitsmodul 20 die Host-Firmware 52 validiert hat, kann das Sicherheitsmodul 20 dem Host-Modul 40 erlauben zu booten, und das Host-Modul 40 kann dann Host-Firmware 52 von einer Quelle abrufen, die dem Host-Modul 40 als Flash-Speicher erscheint, wie der eingebettete Speicher 30. Das Sicherheitsmodul 20 kann jedoch tatsächlich als die Quelle dienen. Beispielsweise kann das Sicherheitsmodul 20 die validierte Host-Firmware 52 im SRAM 26 speichern und Sicherheitsmodul 20 kann die Leseanfragen bedienen, die Host-Modul 40 zum eingebetteten Speicher lenkt. Daher kann das Sicherheitsmodul 20 als virtueller Flash-Speicher für Host-Modul 40 dienen. Zum Beispiel kann Sicherheitsmodul 20 NVM 24 zum Emulieren eines sicheren Flash oder eines seriellen peripheren Schnittstellen-, (Serial Peripheral Interface, SPI), Flash für Host-Modul 40 verwenden. Daher ist Host-Firmware 52 mit einer strichlierten Kontur in SRAM 26 und in SRAM 46 dargestellt.
In einer alternativen Ausführungsform kann das Sicherheitsmodul die Host-Firmware validieren und dann die Host-Firmware in einen nicht flüchtigen Speicher (NVM) im Host-Modul kopieren, bevor dem Host-Modul erlaubt wird zu booten. In einer anderen alternativen Ausführungsform kann ein Master-Modul einen dualen Eingangs-/Ausgangs-, (Input/Output, I/O), Flash-Speicher in Kommunikation mit dem Sicherheitsprozessor und dem Host-Prozessor enthalten und die Host-Firmware kann sich in diesem Flash-Speicher befinden. Nachdem das Sicherheitsmodul die Host-Firmware validiert hat, kann der Host-Prozessor die validierte Host-Firmware von diesem Flash-Speicher erhalten. In anderen Ausführungsformen kann die Sicherheits-Firmware im internen NVM des Sicherheitsmoduls 20 oder im externen einmalig programmierbaren (One-Time Programmable, OTP) Speicher gespeichert sein.
Zusätzlich enthält Sicherheitsmodul 20 in der Ausführungsform von 1 den NVM 24 und der Hersteller von Master-Modul 80 hat Sicherheitsrichtlinien und Daten (Security Policies and Data, SPD) 25 in NVM 24 geladen. SPD 25 enthält Daten, um der Sicherheits-Firmware 32 zu ermöglichen, die Integrität von Sicherheits-Firmware 32 und die Integrität von Host-Firmware 52 zu verifizieren. Beispielsweise kann SPD 25 einen Hash von Sicherheits-Firmware 32, einen Hash von Host-Firmware 52 und eine Kopie von HMID 49 enthalten. Zusätzlich kann SPD 25 Hash-Werte oder andere Daten enthalten, um Sicherheits-Firmware 32 zu ermöglichen, die Integrität eines, einiger oder aller der Hilfsmodule zu verifizieren. Zusätzlich kann NVM 24 als sicherer Datenspeicher implementiert sein. Und Sicherheitsmodul 20 kann Sicherheits-Firmware 32 vom NVM 24 in einer alternativen Ausführungsform erhalten. Ebenso enthält Host-Modul den NVM 56 und der Hersteller kann den NVM 56 mit SPD 58 bestücken. SPD kann beispielsweise eine Kopie von SMID 29 enthalten. Wie unten angegeben, kann Host-Prozessor 42 anschließend diese Kopie von SMID 29 zum Bestimmen verwenden, ob das autorisierte Sicherheitsmodul noch mit dem Host-Modul 40 verbunden ist.
In der Ausführungsform von 1 hat der Hersteller das Sicherheitsmodul 20 mit SMID 29 vorkonfiguriert, das durch PUF 29 zu produzieren ist. Der Hersteller hat das Host-Modul 40 auch mit HMID 49 vorkonfiguriert, die durch PUF 48 zu produzieren ist. In einer Ausführungsform ist SMID 29 eine einzigartige Einrichtungskennung, die im Sicherheitsmodul 20 gespeichert ist, und HMID 49 ist eine einzigartige Einrichtungskennung, die im Host-Modul 40 gespeichert ist. PUF 29 kann beispielsweise mit Sicherungen im Sicherheitsmodul 20 implementiert sein, die der Hersteller verwendet, um die gegebene SMID in das Sicherheitsmodul 20 zu brennen. Folglich kann die SMID 29 unveränderbar, aber auch für nicht autorisierte Einheiten nicht erkennbar sein. HMID 49 kann auf ähnliche Weise implementiert sein.
Wie später ausführlicher beschrieben wird, kann Sicherheitsmodul 20 die HMID 49 prüfen um sicherzustellen, dass Host-Modul 40 nicht gesperrt oder durch andere Hardware ersetzt ist, und Host-Modul 40 kann die SMID 29 prüfen um sicherzustellen, dass Sicherheitsmodul 20 nicht gesperrt oder durch andere Hardware ersetzt ist. Daher werden SMID 29 und HMID 49 verwendet, um eine enge Kopplung zwischen Host-Modul 40 und Sicherheitsmodul 20 sicherzustellen.
Ebenso kann während der Systembereitstellung das Sicherheitsmodul 20 einen einzigartigen Master-Schlüssel generieren, der zum Errichten der sicheren Kommunikation zwischen Sicherheitsmodul 20 und Host-Modul 40 verwendet wird. Alternativ kann ein solcher Master-Schlüssel generiert und in das Sicherheitsmodul 20 und Host-Modul 40 durch ein zertifiziertes und sicheres Werkzeug eingesetzt und darin gespeichert werden.
In der Ausführungsform von 1 hat der Hersteller auch den eingebetteten Speicher 30 mit Sicherheits-Firmware 32 und Host-Firmware 52 wie auch Sicherungskopien von Firmware 34 vorkonfiguriert. Diese Sicherungskopien können Kopien von Host-Firmware 52 und Sicherheits-Firmware 32 wie auch Kopien von Firmware für ein, einige oder alle Hilfsmodule, wie externe Einrichtung 90 und Beschleuniger 94, enthalten. Überdies können die Sicherungskopien in verschlüsselter Form gespeichert werden, sodass sie nur das Sicherheitsmodul 20 entschlüsseln kann.
Zusätzlich, wenn eine Firmware auf eine neue Version aktualisiert wird, kann Sicherheits-Coprozessor 22 eine Kopie der alten Version als eine Sicherungskopie 34 speichern und Sicherheits-Coprozessor 22 kann den Hash-Wert für die alte Version in SPD 25 speichern. Ein solcher Hash-Wert kann als Sicherungs-Hash-Wert bezeichnet werden. Sicherheitsmodul 20 hält somit eine sichere Speicherung und Versionierung der Firmware aufrecht.
2A und 2B zeigen ein Flussdiagramm eines beispielhaften Prozesses zum Bereitstellen eines Firmwareschutzes im eingebetteten System 10, wobei zumindest einige Operationen durch das Sicherheitsmodul 20 durchgeführt werden. Der Prozess von 2A kann damit starten, dass das eingebettete System 10 startet oder hochfährt.
Wie in Block 110 dargestellt, wenn Sicherheitsmodul 20 das erste Mal Leistung empfängt, kann Sicherheits-Coprozessor 22 Sicherheits-Firmware 32 in den SRAM 26 laden, wie in Block 110 dargestellt. Zusätzlich, wie in Block 112 dargestellt, kann Sicherheits-Coprozessor 22 Host-Prozessor 42 und ein, einige oder alle der Hilfsmodule in einem Rücksetzzustand halten, wie in Block 112 dargestellt. Sicherheits-Coprozessor 22 kann dann die Integrität oder Gültigkeit von Sicherheits-Firmware 32 prüfen, wie in Block 120 dargestellt. Beispielsweise kann Sicherheits-Coprozessor 22 Sicherheits-Firmware 32 hashen und das Ergebnis mit den entsprechenden Daten in SPD 25 vergleichen. Falls die Integritätsprüfung fehlschlägt, kann Sicherheits-Coprozessor 22 bestimmen, ob dieser Fehlschlag als ein fataler Fehler anzusehen ist, wie in Block 122 dargestellt. Falls beispielsweise Sicherheits-Coprozessor 22 bereits versucht hat, auf Sicherungs-Sicherheits-Firmware zu booten und dieser Versuch erfolglos war (z.B. aufgrund eines anderen Fehlschlags einer Integritätsprüfung) kann Sicherheits-Coprozessor 22 einen fatalen Fehler auslösen. Falls ein fataler Fehler erfasst oder ausgelöst wird, kann Sicherheits-Coprozessor 22 eine passende Fehlernachricht generieren (beispielsweise durch Aufleuchtenlassen eines Warnlichts) und Sicherheits-Coprozessor 22 kann dann den Boot-Prozess beenden, wie in Blöcken 124 und 126 dargestellt.
Falls jedoch kein fataler Fehler erfasst oder ausgelöst wurde, kann der Sicherheits-Coprozessor 22 Sicherheits-Firmware 32 durch eine Sicherungskopie 34 der Sicherheits-Firmware aus dem eingebetteten Speicher 30 ersetzen, wie in Block 130 dargestellt. Der Sicherheits-Coprozessor 22 kann dann das eingebettete System 10 rücksetzen, wie in Block 132 dargestellt. Folglich kann der Prozess zu Block 110 über Verbindung A zurückkehren, wobei Sicherheits-Coprozessor 22 dann andere Module im Rücksetzzustand hält, die (Sicherungskopie von) Sicherheits-Firmware in SRAM 26 lädt und die Firmware, wie oben beschrieben, verifiziert. Sicherheits-Coprozessor 22 kann den passenden Sicherungs-Hash-Wert verwenden, um diese Bestimmung vorzunehmen.
Falls die Sicherheits-Firmware die Integritätsprüfung besteht, kann Sicherheits-Coprozessor 22 dann die Integrität oder Gültigkeit von Host-Firmware 52 prüfen, wie in Block 140 dargestellt. Falls die Integrität überprüft ist, kann der Prozess dann durch Verbindung B zu 2B gehen. Falls jedoch die Host-Firmware 52 die Integritätsprüfung nicht besteht, kann der Sicherheits-Coprozessor 22 dann bestimmen, ob dieser Fehlschlag als ein fataler Fehler zu betrachten ist, wie in Block 142 dargestellt. Falls beispielsweise der Sicherheits-Coprozessor 22 die Host-Firmware 52 bereits durch die Sicherungs-Host-Firmware ersetzt hat und diese Sicherungs-Firmware die Integritätsprüfung nicht bestanden hat, kann der Sicherheits-Coprozessor 22 einen fatalen Fehler auslösen. Falls ein fataler Fehler erfasst oder ausgelöst wird, kann der Sicherheits-Coprozessor 22 eine passende Fehlernachricht generieren (beispielsweise durch Aufleuchtenlassen eines Warnlichts) und der Sicherheits-Coprozessor 22 kann dann den Boot-Prozess beenden, wie in Blöcken 124 und 126 dargestellt.
Falls jedoch der Sicherheits-Coprozessor 22 bestimmt, dass der Integritätsfehlschlag kein fataler Fehler ist, kann der Sicherheits-Coprozessor 22 die Host-Firmware 52 durch eine Sicherungskopie 34 der Host-Firmware aus dem eingebetteten Speicher 30 ersetzen, wie in Block 144 dargestellt. Der Sicherheits-Coprozessor 22 kann dann das eingebettete System 10 rücksetzen, wie in Block 146 dargestellt. Folglich kann der Prozess über Verbindung A zu Block 110 zurückkehren, wobei dann der Sicherheits-Coprozessor 22 die relevanten, oben beschriebenen Operationen ausführen kann und schließlich in Block 140 bestimmt, ob die Sicherungskopie der Host-Firmware gültig ist. Der Sicherheits-Coprozessor 22 kann den passenden Sicherungs-Hash-Wert verwenden, um diese Bestimmung vorzunehmen.
Wie oben angegeben, falls die Integrität geprüft ist, kann der Prozess dann durch Verbindung B zu 2B gehen. Wie in Block 150 dargestellt, kann der Sicherheits-Coprozessor 22 dann die Rücksetzsignale für Host-Modul 40 und für die Hilfsmodule löschen.
Wie in Block 152 dargestellt, kann der Sicherheits-Coprozessor 22 dann gewrappte Schlüssel zum Host-Modul 40 kopieren. Das Host Modul 40 kann diese Schlüssel anschließend zur Sitzungsverwaltung und zum Verschlüsseln oder Entschlüsseln eines zusätzlichen Anwendungscodes verwenden. Wie in Block 154 dargestellt, kann der Sicherheits-Coprozessor 22 dann HMID 49 vom Host-Modul 40 erhalten. Die Anfrage für die HMID 49 kann als eine Herausforderung bezeichnet werden. In Antwort auf diese Herausforderung kann Host-Modul 40 einen der Schlüssel aus dem Sicherheitsmodul 20 (oder einen Schlüssel, der auf einem dieser Schlüssel basiert) zum Verschlüsseln der HMID 49 verwenden, bevor die HMID 49 mit dem Sicherheitsmodul 20 geteilt wird. Wie in Block 160 dargestellt, kann der Sicherheits-Coprozessor 22 dann bestimmen, ob HMID 49 gültig ist (nachdem zuerst die HMID 49 entschlüsselt wurde, falls notwendig). Beispielsweise kann das Sicherheitsmodul 20 HMID 49 mit der Kopie der HIMD vergleichen, die sicher im SPD 25 gespeichert ist. Falls HMID 49 nicht gültig ist (oder falls Sicherheitsmodul 20 nicht imstande ist, eine HMID vom Host-Modul 40 zu erhalten), kann das Sicherheitsmodul 20 eine Fehlernachricht generieren und den Boot-Prozess beenden, wie in Blöcken 162 und 164 dargestellt. Zusätzlich oder alternativ kann das Sicherheitsmodul 20 auf eine Bestimmung antworten, dass Host-Modul 40 mit dem Sicherheitsmodul 20 nicht in Kommunikation steht, indem eine oder mehrere der folgenden Operationen dargestellt werden: Veranlassen einer Rücksetzung des Host-Moduls 20; Veranlassen einer Entfernung des Host-Moduls 20 aus dem Netzwerk; Veranlassen einer Durchführung einer Diagnose an dem Host-Modul 20; Veranlassen einer Durchführung einer Diagnose an dem Sicherheitsmodul 40; und Veranlassen einer Sperre des Host-Moduls 20.
Falls HMID 49 gültig ist, kann das Sicherheitsmodul 20 dann die Integrität der Firmware für ein, einige oder alle der Hilfsmodule prüfen. Beispielsweise, wie in Blöcken 170 und 172 dargestellt, kann das Sicherheitsmodul 20 durch einen Prozess zum Prüfen der Firmware für jedes Hilfsmodul laufen, um zu bestimmen, ob die Firmware gültig ist (z.B. auf Basis von vorbestimmten Hash-Werten für die Firmware). Falls etwas von dieser Firmware ungültig ist, kann das Sicherheitsmodul 20 bestimmen, ob ein fataler Fehler ausgelöst werden sollte, wie in Block 180 dargestellt. Beispielsweise, falls der Sicherheits-Coprozessor 22 bereits Firmware in einem Hilfsmodul durch Sicherungs-Host-Firmware ersetzt hat und diese Sicherungs-Firmware die Integritätsprüfung nicht bestanden hat, kann der Sicherheits-Coprozessor 22 einen fatalen Fehler auslösen. Falls ein fataler Fehler erfasst oder ausgelöst wird, kann der Sicherheits-Coprozessor 22 eine passende Fehlernachricht generieren und der Sicherheits-Coprozessor 22 kann dann den Boot-Prozess beenden, wie in Blöcken 162 und 164 dargestellt.
Falls der Fehler nicht fatal ist, kann der Sicherheits-Coprozessor 22 die Firmware in dem Hilfsmodul durch die Sicherungs-Firmware ersetzen, wie in Block 182 dargestellt. der Prozess kann dann zu Block 172 zurückkehren, wobei der Sicherheits-Coprozessor 22 die Sicherungs-Firmware, wie oben angegeben, prüft.
Unter erneuter Bezugnahme auf Block 170, kann der Initialisierungsprozess, der durch den Sicherheits-Coprozessor 22 verwaltet wird, enden, sobald die Firmware für alle der Hilfsmodule validiert wurde. Wie unten angegeben, kann das Host-Modul 40 jedoch auch einen Initialisierungsprozess durchführen. Hilfsmodule können die Initialisierungsprozesse auch beenden.
Zusätzlich kann das Sicherheitsmodul 20, wie oben angegeben, die Integrität eines, einiger oder aller der Firmware-Bilder in jeder Phase nach dem Booten prüfen, wie als Reaktion auf ein intern generiertes Herzschlagereignis usw.
In einigen Ausführungsforme kann erforderlich sein, dass ein oder mehrere Hilfsmodule sehr rasch auf dem eingebetteten Netzwerk booten. Beispielsweise kann notwendig sein, dass einige Mikrosteuerungseinheiten (Microcontroller Units, MCUs) und einige Sensoren in einem Auto oder Flugzeug rasch booten. Folglich kann das Sicherheitsmodul eine verzögerte Integritätsprüfung bei diesen Hilfsmodulen durchführen. Mit anderen Worten, das Sicherheitsmodul kann diesen Module erlauben unabhängig zu booten, indem sie nicht in einem Rücksetzzustand gehalten werden, sondern ihnen stattdessen erlaubt ist, zu booten, bevor die Integrität ihrer Firmware geprüft wird. Das Sicherheitsmodul kann jedoch das eingebettete System konfigurieren, diese Module in einen nicht vertrauenswürdigen Zustand zu setzen. Wenn ein Modul in einem nicht vertrauenswürdigen Zustand ist, kann es beispielsweise in einem Nur-Lese-Modus arbeiten. Mit anderen Worten, bis die Integritätsprüfung erfolgreich beendet ist, ist dem Modul nur eine Lesemoduszugriff auf das Netzwerk erlaubt, um zu verhindern, dass das Modul ein anderes Modul infiziert. Sobald das Sicherheitsmodul jedoch das Booten beendet hat, kann es Firmware von den Hilfsmodulen lesen, die unabhängig gebootet haben, und das Sicherheitsmodul kann dann Integritätsprüfungen auf dieser Firmware laufen lassen. Zum Beispiel kann das Sicherheitsmodul Hashes berechnen und die Ergebnisse mit Hashes oder Signaturen vergleichen. Falls die Integrität gut ist, kann das Sicherheitsmodul dann die Hilfsmodule in einen vertrauenswürdigen Zustand setzen. Beispielsweise kann das Sicherheitsmodul diesen Module erlauben, zu lesen und zu schreiben. Falls jedoch die Integrität eines solchen Hilfsmoduls nicht gut ist, kann das Sicherheitsmodul die Firmware dieses Hilfsmoduls durch eine Sicherungsversion ersetzen und dieses Hilfsmodul rücksetzen.
3 zeigt ein Flussdiagramm eines beispielhaften Prozesses zum Schutz von Firmware im eingebetteten System 10, wobei zumindest einige Operationen durch Host-Modul 40 durchzuführen sind. Dieser Prozess kann starten, wenn Sicherheitsmodul 20 das Rücksetzsignal für Host-Modul 40 freigibt. Wie in Block 210 dargestellt, kann Host-Prozessor 42 dann Host-Firmware 52 laden. Wie in Block 212 dargestellt, kann Host-Prozessor 42 dann Host-Firmware 52 ausführen, die die SMID 29 vom Sicherheits-Coprozessor 22 erhalten kann. Die Anfrage vom Host-Prozessor 42 nach einer SMID 29 kann als eine Herausforderung bezeichnet werden. In Antwort auf diese Herausforderung, kann das Sicherheitsmodul 20 einen der gemeinsamen Schlüssel (oder einen Schlüssel, der auf einem dieser Schlüssel beruht) zum Verschlüsseln der SMID 29 verwenden, bevor die SMID 29 mit Host-Modul 40 geteilt wird.
Wie in Block 220 dargestellt, kann Host-Prozessor 42 dann bestimmen, ob SMID 29 gültig ist. Beispielsweise kann Host-Prozessor 42 die SIMD, die er vom Sicherheitsmodul 20 empfangen hat, mit einer SIMD für das autorisierte Sicherheitsmodul vergleichen, das zuvor als Teil von SPD 58 im NVM 56 gespeichert wurde. Falls die SMID 29 nicht gültig ist, kann Host-Prozessor 42 eine Fehlernachricht generieren und den Boot-Prozess beenden, wie in Blöcken 222 und 224 dargestellt. Daher stellt SMID 29 eine umgekehrte Kopplung vom Host-Modul 40 zum Sicherheitsmodul 20 bereit. Wie unten angegeben, kann das Sicherheitsmodul 20 die Management-Engine 44 verwenden, um sicherzustellen, dass, falls Sicherheitsmodul 20 abgetrennt oder angegriffen wird, das Host-Modul 40 nicht ohne das gültige Sicherheitsmodul 20 arbeiten wird.
Falls jedoch SMID 29 gültig ist, kann Host-Prozessor 42 dann eine Integritätsprüfung an der Sicherheits-Firmware 32 durchführen, wie in Block 230 dargestellt. Somit kann das Sicherheitsmodul 20 eine reverse Integritätsprüfung des Sicherheitsmoduls 20 durchführen. Falls die Sicherheits-Firmware 32 die Integritätsprüfung nicht besteht, kann der Host-Prozessor 42 eine Fehlernachricht generieren und den Boot-Prozess beenden, wie in Blöcken 222 und 224 dargestellt. Falls die Sicherheits-Firmware 32 jedoch die Integritätsprüfung besteht, kann das Sicherheitsmodul 20 seinen Boot-Prozess beenden und damit fortfahren in einer mehr oder weniger herkömmlichen Weise zu arbeiten.
Ebenso können in anderen Ausführungsformen eine, einige oder alle der Operationen von 3 durch die Management-Engine 44 und nicht den Host-Prozessor 42 durchgeführt werden. Die Management-Engine 44 kann einen vertrauenswürdigen Mikroprozessor enthalten und wie oben angegeben kann die Management-Engine 44 beispielsweise eine CSME implementieren.
Somit kann die Management-Engine 44 im Host-Modul 40 eng an das Sicherheitsmodul 20 gekoppelt sein, um sicherzustellen, dass, falls ein Angreifer Sicherheitsmodul 20 und Host-Modul 40 trennt, das Host-Modul 40 nicht ohne Sicherheitsmodul 20 arbeitet. Wie oben angegeben, sind Technologien wie PUFs eine Option zur Durchsetzung einer solchen engen Kopplung.
Sicherheitsmodul 20 kann auch Firmware-Aktualisierungen für einige oder alle der Module im eingebetteten System 10 verwalten. Beispielsweise kann das Sicherheitsmodul 20 eine Aktualisierung über den Äther für die Firmware für Host-Modul 40 (oder ein anderes Modul) empfangen und Sicherheitsmodul 20 kann dann diese neue Firmwareversion authentifizieren um sicherzustellen, dass sie von einer vertrauenswürdigen Quelle kommt usw. Sicherheitsmodul 20 kann dann die neue Version im eingebetteten Speicher 30 (oder an einer anderen geeigneten Stelle) speichern und Sicherheitsmodul 20 kann die Messung der neuen Version in SPD 25 speichern. Anschließend kann das Sicherheitsmodul 20 während der nächsten Rücksetzung des relevanten Moduls neue Firmware zum Modul, kopieren, die die alte Version ersetzt. Somit stellt das Sicherheitsmodul 20 Hintergrundaktualisierungen bereit, während Host-Modul 40, Beschleuniger 94 und externe Einrichtung 90 arbeiten, und Sicherheitsmodul 20 kann eine authentifizierte Aktualisierung während eines Rücksetzens der Einrichtungen oder Module, die durch das Sicherheitsmodul 20 gesteuert werden, vorantreiben. Alternativ, anstatt auf den nächsten Boot-Zyklus zu warten, kann das Sicherheitsmodul 20 entscheiden, eine Slave-Einrichtung, basierend auf einer anhaltenden Sicherheits- oder Betriebssicherheitsrichtlinie dynamisch rückzusetzen. Hintergrundaktualisierungen oder dynamische Aktualisierungen können für Kraftfahrzeuganwendungen, Luftfahrtanwendungen und andere Anwendungen erforderlich sein. Die oben stehende Methode kann sogar verwendet werden, um Sicherheits-Firmware 32 zu aktualisieren, wodurch die Sicherheitshaltung von Sicherheitsmodul 20 verändert wird. Beispielsweise kann das Sicherheitsmodul 20 eine Aktualisierung an Sicherheits-Firmware 32 anwenden, die eine oder mehrere der Sicherheitsrichtlinien ändert, die durch das Sicherheitsmodul 20 durchgesetzt werden.
Sicherheitsmodul 20 kann das eingebettete System 10 auch vor Programmfehlern schützen. Falls zum Beispiel eine neue Firmwareversion das Host-Modul 40 (oder ein anderes Modul) veranlasst, zu verriegeln oder anzuhalten, kann das Sicherheitsmodul 20 durch Ersetzen der neuen Firmwareversion durch die vorherige Version antworten.
In einer Ausführungsform verwenden das Sicherheitsmodul und das Host-Modul einen oder mehrere Anti-Wiedergabemechanismen, die, ohne Einschränkung, monotone Zähler und Nonces enthält. Ebenso kann das Sicherheitsmodul ein Hilfsmodul oder ein Host-Modul ausschalten, falls das Sicherheitsmodul eine Verletzung von Vertrauenswürdigkeit oder Betriebssicherheit entdeckt.
In einer Ausführungsform enthält das Master-Modul einen sicheren NVM und das Master-Modul verwendet den sicheren NVM, um eine goldene Kopie der Firmware für ein, einige oder alle der Module im eingebetteten System zu speichern, wie auch Sicherheitseinstellungen, Metadaten und sämtliche anderen geeigneten Daten. Falls der eingebettete Speicher versagt, kann das eingebettete System eine oder mehrere der goldenen Kopien verwenden, um ein oder mehrere der Module auf die Fabrikskonfiguration rückzusetzen. Und zur Aufrechterhaltungen von Sicherheit, kann der NVM nur durch manuellen Zugriff oder durch ein spezielles verschlüsseltes Signal zugänglich sein.
Die vorliegenden Lehren können in vielen verschiedenen Arten von eingebettetem System vorteilhaft genutzt werden. Beispielsweise kann ein eingebettetes System für ein Fahrzeug Niederleistungs-ECUs und Sensoren (Kamera, Radar usw.) enthalten, die keinen robusten Hardware-Schutz haben, um Angreifer an einer Manipulation ihrer Firmware zu hindern. Ein Angreifer könnte einen Sensor (zum Beispiel) als Angriffspunkt zum Verbreiten von Malware weiter in das Innere des Fahrzeugs verwenden. Die vorliegenden Lehren können jedoch dem Sicherheitsmodul erlauben, jede Malware zu erfassen, bevor das eingebettete System vollständig gebootet ist, und die Malware zu eliminieren.
Die vorliegenden Offenbarung erklärt, dass Sicherheitsmodule und Host-Module die Integrität von Firmware prüfen können. Zusätzlich oder alternativ kann ein Sicherheitsmodul andere Arten von Daten prüfen, enthaltend, ohne Einschränkung, Algorithmen, Selbsttestcode, Datenbereiche, Trainingssätze und Bilder. Beispielsweise kann ein eingebettetes System in einem Auto ein Bild speichern, das zeigt, wo das Auto geparkt ist, wenn das Auto ausgeschaltet wird. Wenn das Auto wieder gestartet ist, kann das eingebettete System 10 die aktuelle Umgebung mit dem gespeicherten Bild vergleichen um sicherzustellen, dass Kameras, Sicht-Coprozessoren und andere Module korrekt arbeiten.
Angesichts der hier beschriebenen und veranschaulichten Prinzipien und beispielhaften Ausführungsformen wird erkannt werden, dass die veranschaulichten Ausführungsformen in Anordnung und Detail modifiziert werden können, ohne von solchen Prinzipien abzuweichen. Selbst wenn Ausdrücke wie „eine Ausführungsform“, „irgendeine Ausführungsform“ „eine andere Ausführungsform“ oder dergleichen hier verwendet werden, sollen diese Phrasen sich im Allgemeinen auch auf Ausführungsformmöglichkeiten beziehen und sollen die Erfindung nicht auf besondere Ausführungsformkonfigurationen beschränken. Wie hier verwendet, können sich diese Phrasen auf dieselbe Ausführungsform oder verschiedene Ausführungsformen beziehen und diese Ausführungsformen sind zu anderen Ausführungsformen kombinierbar.
Diese Offenbarung kann sich auf Anweisungen, Funktionen, Prozeduren, Datenstrukturen, Anwendungsprogramme, Software, Firmware, Mikrocode, Konfigurationseinstellungen und andere Arten von Daten beziehen. Wie oben beschrieben, wenn auf die Daten durch eine Maschine oder Einrichtung zugegriffen wird, kann die Maschine oder Einrichtung mit einem Durchführen von Aufgaben, Definieren abstrakter Datentypen oder Hardwarekontexten auf niederer Ebene und/oder Durchführen anderer Operationen antworten. Beispielsweise können Datenspeicher, Direktzugriffspeicher (RAM) und/oder Flash-Speicher verschiedene Sätze von Anweisungen enthalten, die, wenn sie ausgeführt werden, verschiedene Operationen durchführen. Solche Sätze von Anweisungen können im Allgemeinen als Software bezeichnet werden. Zusätzlich kann der Begriff „Programm“ verwendet werden, um im Allgemeinen einen weiten Bereich von Softwarekonstrukten abzudecken, enthaltend Anwendungen, Programme, Module, Treiber, Teilprogramme, Prozesse und andere Arten von Softwarekomponenten. Es kann jede geeignete Betriebsumgebung und Programmierungssprache (oder Kombination von Betriebsumgebungen und Programmierungssprachen) zum Implementieren von hier beschriebenen Komponenten verwendet werden.
Einige Einrichtungen können Software enthalten, die auf einem oder mehreren Prozessoren läuft. Eine Einrichtung kann auch Datenspeicher und Hauptspeicher enthalten. Software und andere Daten können vom Datenspeicher in den Speicher kopiert werden. Der Prozessor kann dann die Software vom Speicher ausführen.
Alternative Ausführungsformen enthalten auch maschinenzugängliche Medien, die Anweisungen codieren oder Logik zum Durchführen der hier beschriebenen Operationen steuern. Solche Ausführungsformen können auch als Programmprodukte bezeichnet werden. Solche maschinenzugänglichen Medien können, ohne Einschränkung, greifbare Datenspeichermedien, wie Magnetplatten, Bildplatten, RAM, Nur-Lese-Speicher (ROM) usw., wie auch Prozessoren, Steuerungen und andere Komponenten enthalten, die RAM, ROM und/oder andere Datenspeichereinrichtungen enthalten. Zum Zweck dieser Offenbarung kann der Begriff „ROM“ im Allgemeinen verwendet werden, um sich auf nicht flüchtige Speichereinrichtungen zu beziehen, wie löschbaren programmierbaren ROM (EPROM), elektrisch löschbaren programmierbaren ROM (EEPROM), Flash-ROM, Flash-Speicher usw.
Es sollte klar sein, dass die hier gezeigten Hardware- und Software-Komponenten Funktionselemente darstellen, die angemessen eigenständig sind, sodass jedes im Wesentlichen unabhängig von den anderen gestaltet, konstruiert oder aktualisiert werden kann. In alternativen Ausführungsformen können viele der Komponenten als Hardware, Software oder Kombinationen von Hardware und Software implementiert werden, um die hier beschriebene und veranschaulichte Funktionalität bereitzustellen. In einigen Ausführungsformen kann etwas oder alles der Steuerlogik zum Implementieren der beschriebenen Operationen in Hardwarelogik implementiert sein (z.B. als Teil eines integrierten Schaltungschips, programmierbares Gate Array (PGA), eine ASIC usw.).
In zumindest einer Ausführungsform können die Anweisungen für alle relevanten Komponenten in einem nicht transitorischen maschinenzugänglichen Medium gespeichert werden. In zumindest einer anderen Ausführungsform können zwei oder mehr nicht transitorische maschinenzugängliche Medien zum Speichern der Anweisungen für die relevanten Komponenten verwendet werden. Beispielsweise können Anweisungen für eine Komponente in einem Medium gespeichert werden und Anweisungen einer anderen Komponente können in einem anderen Medium gespeichert werden. Alternativ kann ein Teil der Anweisungen für eine Komponente in einem Medium gespeichert werden und der Rest der Anweisungen für diese Komponente (wie auch Anweisungen für andere Komponenten), kann in einem oder mehreren anderen Medien gespeichert werden. Anweisungen können auch in einer verteilten Umgebung verwendet werden und können lokal und/oder fern für einen Zugriff durch einzelne oder Mehrfach-Prozessormaschinen gespeichert werden. Ebenso können Anwendungen und/oder andere Daten, die sich laut der vorangehenden Beschreibung in einer beispielhaften Ausführungsform auf einer besonderen Einrichtung befinden, in anderen Ausführungsformen auf einer oder mehreren anderen Einrichtungen liegen. Und Rechenoperationen, die laut vorangehender Beschreibung in einer beispielhaften Ausführungsform auf einer besonderen Einrichtung durchgeführt werden, können in anderen Ausführungsformen durch eine oder mehrere andere Einrichtungen ausgeführt werden.
Die vorliegenden Lehren können in vielen verschiedenen Arten von Datenverarbeitungssystemen vorteilhaft verwendet werden. Beispielhafte Datenverarbeitungssysteme können, ohne Einschränkung, SoCs, tragbare Einrichtungen, handgehaltene Einrichtungen, Smartphones, Telefone, Unterhaltungseinrichtungen wie Audioeinrichtungen, Videoeinrichtungen, Audio/Videoeinrichtungen (z.B. Fernsehgeräte und Set Top Boxes), Verarbeitungssysteme in Fahrzeugen, Personal Digital Assistants (PDAs), Tablet-Computer, Laptop-Computer, tragbare Computer, Personal Computer (PCs), Workstations, Server, Client-Server Systeme, verteilte Rechensysteme, Supercomputer, Hochleistungsrechensysteme, Rechencluster, Großrechner, Minicomputer und andere Einrichtungen zur Verarbeitung oder Übertragung von Informationen enthalten. Daher, falls nicht ausdrücklich anderes angegeben oder durch den Kontext bedingt ist, sollte Verweise auf eine bestimmte Art von Datenverarbeitungssystem (z.B. einen PC) so verstanden werden, dass sie auch andere Arten von Datenverarbeitungssystemen umfassen. Ebenso, falls nicht ausdrücklich anderes angegeben ist, müssen Komponenten, die als direkt aneinander gekoppelt, in Kommunikation mit einander, auf einander ansprechend oder dergleichen beschrieben sind, nicht in ständiger Kommunikation miteinander sein und müssen nicht direkt aneinander gekoppelt sein. Ebenso, wenn eine Komponente laut Beschreibung Daten von einer anderen Komponente empfängt oder Daten zu dieser sendet, können diese Daten durch eine oder mehrere dazwischenliegende Komponenten gesendet oder empfangen werden, falls nicht ausdrücklich anderes spezifiziert ist. Zusätzlich können einige Komponenten des Datenverarbeitungssystems als Adapterkarten mit Schnittstellen (z.B. eine Verbindung) zur Kommunikation mit einem Bus implementiert sein. Alternativ können Einrichtungen oder Komponenten als eingebettete Steuerungen unter Verwendung von Komponenten wie programmierbaren oder nicht programmierbaren logischen Einrichtungen oder Arrays, ASICs, eingebetteten Computern, smarten Karten und dergleichen implementiert sein. Zum Zweck dieser Offenbarung enthält der Begriff „Bus“ Pfade, die von mehr als zwei Einrichtungen gemeinsam benutzt werden können, wie auch Punkt-zu-Punkt-Pfade. Ebenso kann zum Zweck dieser Offenbarung ein Prozessor auch als eine Verarbeitungseinheit, ein Verarbeitungselement, eine zentrale Verarbeitungseinheit (CPU) usw. bezeichnet werden.
Obwohl ein oder mehrere beispielhaften Prozesse in Bezug auf besondere Operationen beschrieben wurden, die in einer bestimmten Abfolge durchgeführt werden, könnten auch zahlreiche Modifizierungen an diesen Prozessen angewendet werden, um zahlreiche alternative Ausführungsformen der vorliegenden Erfindung abzuleiten. Zum Beispiel können alternative Ausführungsformen Prozesse, die weniger als alle der offenbarten Operationen enthalten, Prozesse, die zusätzliche Operationen enthalten, und Prozesse, in welchen einzelne, hier offenbarte Operationen kombiniert, unterteilt, neu angeordnet oder auf andere Weise verändert sind, enthalten.
Angesichts der großen Vielzahl nützlicher Änderungen, die leicht aus den beispielhaften, hier beschriebenen Ausführungsformen abgeleitet werden können, soll die ausführliche Beschreibung nur veranschaulichend sein und nicht als Einschränkung des Abdeckungsumfangs verstanden werden.
Die folgenden Beispiele betreffen weitere Ausführungsformen.
Beispiel A1 ist ein Datenverarbeitungssystem mit Schutz für Firmware. Das Datenverarbeitungssystem umfasst (a) ein Host-Modul, umfassend eine Management-Engine; (b) ein Sicherheitsmodul in Kommunikation mit dem Host-Modul, wobei das Sicherheitsmodul einen Sicherheits-Coprozessor und eine geheime Kennung für das Sicherheitsmodul umfasst; und (c) zumindest ein maschinenzugängliches Medium, das auf das Sicherheitsmodul anspricht. Das maschinenzugängliche Medium umfasst Host-Firmware, die, wenn sie auf dem Host-Modul durch die Management-Engine ausgeführt wird, der Management-Engine ermöglicht, basierend auf der geheimen Kennung für das Sicherheitsmodul zu bestimmen, ob das Sicherheitsmodul mit dem Host-Modul in Kommunikation steht. Das maschinenzugängliche Medium umfasst auch Sicherheits-Firmware die, wenn sie auf dem Sicherheitsmodul durch den Sicherheits-Coprozessor ausgeführt wird, dem Sicherheits-Coprozessor ermöglicht, (a) die Integrität der Host-Firmware zu verifizieren und (b) zu verhindern, dass das Host-Modul mit der Host-Firmware bootet, als Reaktion auf eine Bestimmung, dass die Host-Firmware Integrität verloren hat.
Beispiel A2 ist ein Datenverarbeitungssystem gemäß Beispiel A1, wobei die Host-Firmware, wenn ausgeführt, der Management-Engine ermöglicht, auf eine Bestimmung zu reagieren, dass das Sicherheitsmodul nicht mit dem Host-Modul in Kommunikation steht, indem ein erfolgreiches Booten des Host-Moduls verhindert wird.
Beispiel A3 ist ein Datenverarbeitungssystem gemäß Beispiel A1, wobei die Host-Firmware, wenn ausgeführt, der Management-Engine ermöglicht, (a) die Integrität der Sicherheits-Firmware für das Sicherheitsmodul zu verifizieren und (b) und zu verhindern, dass das Sicherheitsmodul mit der Sicherheits-Firmware bootet, als Reaktion auf eine Bestimmung, dass die Sicherheits-Firmware Integrität verloren hat. Beispiel A3 kann auch die Merkmale von Beispiel A2 enthalten.
Beispiel A4 ist ein Datenverarbeitungssystem gemäß Beispiel A1, wobei das Host-Modul eine geheime Kennung für das Host-Modul umfasst und das Sicherheitsmodul einen nicht flüchtigen Datenspeicher mit einer geheimen Kennung für ein genehmigtes Host-Modul umfasst. Die Sicherheits-Firmware, wenn ausgeführt, ermöglicht dem Sicherheits-Coprozessor, (a) die geheime Kennung für das Host-Modul vom Host-Modul zu empfangen und (b) zu bestimmen, ob das genehmigte Host-Modul mit dem Sicherheitsmodul in Kommunikation steht, basierend auf (i) der geheimen Kennung vom Host-Modul und (ii) der geheimen Kennung vom nicht flüchtigen Datenspeicher im Sicherheitsmodul. Beispiel A4 kann auch die Merkmale von einem oder mehreren von Beispielen A2 und A3 enthalten.
Beispiel A5 ist ein Datenverarbeitungssystem gemäß Beispiel A4, wobei das Datenverarbeitungssystem zumindest eine Kommunikationsleitung umfasst, um ein Netzwerk zu unterstützen, das das Host-Modul und das Sicherheitsmodul umfasst. Die Sicherheits-Firmware, wenn ausgeführt, ermöglicht dem Sicherheits-Coprozessor, auf eine Bestimmung zu reagieren, dass das genehmigte Host-Modul nicht mit dem Sicherheitsmodul in Kommunikation steht, indem zumindest eine Operation durchgeführt wird aus der Gruppe bestehend aus: (a) Veranlassen einer Rücksetzung des Host-Moduls; (b) Veranlassen einer Entfernung des Host-Moduls aus dem Netzwerk; (c) Veranlassen einer Durchführung einer Diagnose an dem Host-Modul; (d) Veranlassen einer Durchführung einer Diagnose an dem Sicherheitsmodul; (e) Veranlassen einer Sperre des Host-Moduls; und (f) Veranlassen einer Anzeige eines Fehlerindikators.
Beispiel A6 ist ein Datenverarbeitungssystem gemäß Beispiel A1, wobei die Sicherheits-Firmware, wenn ausgeführt, dem Sicherheitsmodul ermöglicht, (a) automatisch die Host-Firmware durch Sicherungs-Host-Firmware als Reaktion auf eine Bestimmung auszutauschen, dass die Host-Firmware Integrität verloren hat und (b) nach Austausch der Host-Firmware durch die Sicherungs-Host-Firmware, das Host-Modul zu veranlassen, mit der Sicherungs-Host-Firmware zu booten. Beispiel A6 kann auch die Merkmale von einem oder mehreren von Beispielen A2 bis A5 enthalten.
Beispiel A7 ist ein Datenverarbeitungssystem gemäß Beispiel A1, weiter umfassend zumindest eine externe Einrichtung in Kommunikation mit dem Sicherheitsmodul und Einrichtungs-Firmware für die externe Einrichtung. Die Sicherheits-Firmware, wenn ausgeführt, ermöglicht dem Sicherheitsmodul, Integrität der Einrichtungs-Firmware für die externe Einrichtung zu prüfen. Beispiel A7 kann auch die Merkmale von einem oder mehreren von Beispielen A2 bis A6 enthalten.
Beispiel A8 ist ein Datenverarbeitungssystem gemäß Beispiel A7, wobei die Sicherheits-Firmware, wenn ausgeführt, dem Sicherheitsmodul ermöglicht, die Einrichtungs-Firmware zu veranlassen, durch Sicherungs-Einrichtungs-Firmware ersetzt zu werden, als Reaktion auf eine Bestimmung, dass die Einrichtungs-Firmware für die externe Einrichtung Integrität verloren hat.
Beispiel A9 ist ein Datenverarbeitungssystem gemäß Beispiel A7, wobei die Sicherheits-Firmware, wenn ausgeführt, dem Sicherheitsmodul ermöglicht, (a) der externen Einrichtung zu erlauben, zu booten, bevor das Sicherheitsmodul Integrität der Einrichtungs-Firmware verifiziert hat, und (b) die externe Einrichtung zu veranlassen, in einem Nur-Lese-Modus auszuführen, bis das Sicherheitsmodul die Integrität der Einrichtungs-Firmware verifiziert hat. Beispiel A9 kann auch die Merkmale von Beispiel A8 enthalten.
Beispiel A10 ist ein Datenverarbeitungssystem gemäß Beispiel A7, wobei die Sicherheits-Firmware, wenn ausgeführt, dem Sicherheitsmodul ermöglicht, (a) neue Einrichtungs-Firmware für die externe Einrichtung zu empfangen; (b) die neue Einrichtungs-Firmware zu authentifizieren; und (c) als Reaktion auf ein erfolgreiches Authentifizieren der neuen Einrichtungs-Firmware, die Einrichtungs-Firmware für die externe Einrichtung durch die neue Einrichtungs-Firmware zu ersetzen. Beispiel A10 kann auch die Merkmale von einem oder mehreren von Beispielen A8 bis A9 enthalten.
Beispiel A11 ist ein Datenverarbeitungssystem gemäß Beispiel A1, wobei die Sicherheits-Firmware, wenn ausgeführt, dem Sicherheitsmodul ermöglicht, (a) neue Sicherheits-Firmware zu empfangen; (b) die neue Sicherheits-Firmware zu authentifizieren; und (c) als Reaktion auf ein erfolgreiches Authentifizieren der neuen Sicherheits-Firmware die Sicherheits-Firmware durch die neue Sicherheits-Firmware zu ersetzen. Beispiel A11 kann auch die Merkmale von einem oder mehreren von Beispielen A2 bis A10 enthalten.
Beispiel A12 ist ein Datenverarbeitungssystem gemäß Beispiel A1, wobei das zumindest eine maschinenzugängliche Medium einen nicht flüchtigen Speicher (NVM) im Sicherheitsmodul und eingebetteten Speicher außerhalb des Sicherheitsmoduls umfasst. Ebenso liegt die Sicherheits-Firmware im NVM und die Host-Firmware liegt im eingebetteten Speicher. Beispiel A12 kann auch die Merkmale von einem oder mehreren von Beispielen A2 bis A11 enthalten.
Beispiel A13 ist ein Datenverarbeitungssystem gemäß Beispiel A1, wobei das Host-Modul ein System-auf-einem-Chip (SoC) Modul umfasst und der Sicherheits-Coprozessor ein feldprogrammierbares Gate Array umfasst (FPGA). Beispiel A13 kann auch die Merkmale von einem oder mehreren von Beispielen A2 bis A12 enthalten.
Beispiel A14 ist ein Datenverarbeitungssystem gemäß Beispiel A13, weiter umfassend (a) eine einzelne integrierte Schaltung, die das Host-Modul und das Sicherheitsmodul umfasst, und (b) zumindest eine Kommunikationsleitung in der einzelnen integrierten Schaltung, um eine Kommunikation zwischen dem Host-Modul und dem Sicherheitsmodul zu erlauben.
Beispiel B1 ist eine Vorrichtung zum Schutz von Firmware in einem eingebetteten System. Die Vorrichtung umfasst zumindest ein nicht transitorisches maschinenzugängliches Datenspeichermedium, das Sicherheits-Firmware für ein Sicherheitsmodul eines eingebetteten Systems und Host-Firmware für ein Host-Modul des eingebetteten Systems umfasst. Die Sicherheits-Firmware, wenn ausgeführt, ermöglicht dem Sicherheitsmodul, (a) automatisch die Integrität der Host-Firmware zu verifizieren und (b) automatisch zu verhindern, dass das Host-Modul mit der Host-Firmware bootet, als Reaktion auf eine Bestimmung, dass die Host-Firmware Integrität verloren hat. Die Host-Firmware, wenn durch das Host-Modul ausgeführt, ermöglicht dem Host-Modul, automatisch zu bestimmen, ob ein genehmigtes Sicherheitsmodul mit dem Host-Modul in Kommunikation steht, basierend auf einer geheimen Kennung für das genehmigte Sicherheitsmodul.
Beispiel B2 ist eine Vorrichtung gemäß Beispiel B1, wobei die Host-Firmware, wenn durch das Host-Modul ausgeführt, dem Host-Modul ermöglicht, auf eine Bestimmung zu reagieren, dass das genehmigte Sicherheitsmodul nicht mit dem Host-Modul in Kommunikation steht, indem automatisch verhindert wird, dass das Host-Modul erfolgreich bootet.
Beispiel B3 ist eine Vorrichtung gemäß Beispiel B1, wobei die Host-Firmware, wenn durch das Host-Modul ausgeführt, dem Host-Modul ermöglicht, (a) automatisch die Integrität der Sicherheits-Firmware zu verifizieren und (b) automatisch zu verhindern, dass das Sicherheitsmodul mit der Sicherheits-Firmware bootet, als Reaktion auf eine Bestimmung, dass die Sicherheits-Firmware Integrität verloren hat. Beispiel B3 kann auch die Merkmale von Beispiel B2 enthalten.
Beispiel B4 ist eine Vorrichtung gemäß Beispiel B1, wobei die Sicherheits-Firmware, wenn ausgeführt, dem Sicherheitsmodul ermöglicht, (a) eine geheime Kennung für das Host-Modul vom Host-Modul zu erhalten, (b) eine geheime Kennung für das genehmigte Host-Modul vom nicht flüchtigen Datenspeicher im Sicherheitsmodul zu erhalten, und (c) zu bestimmen, ob das genehmigte Host-Modul mit dem Sicherheitsmodul in Kommunikation steht, basierend auf (i) der geheimen Kennung vom Host-Modul und (ii) der geheimen Kennung vom nicht flüchtigen Datenspeicher im Sicherheitsmodul. Beispiel B4 kann auch die Merkmale von einem oder mehreren von Beispielen B2 bis B3 enthalten.
Beispiel B5 ist eine Vorrichtung gemäß Beispiel B1, wobei die Sicherheits-Firmware, wenn ausgeführt, dem Sicherheitsmodul ermöglicht, (a) automatisch die Host-Firmware durch Sicherungs-Host-Firmware als Reaktion auf eine Bestimmung auszutauschen, dass die aktuelle Host-Firmware Integrität verloren hat und (b) nach Austausch der Host-Firmware durch die Sicherungs-Host-Firmware, das Host-Modul zu veranlassen, mit der Sicherungs-Host-Firmware zu booten. Beispiel B5 kann auch die Merkmale von einem oder mehreren von Beispielen B2 bis B4 enthalten.
Beispiel B6 ist eine Vorrichtung gemäß Beispiel B1, wobei die Sicherheits-Firmware, wenn ausgeführt, dem Sicherheitsmodul ermöglicht, die Integrität von Einrichtungs-Firmware für eine externe Einrichtung im eingebetteten System zu prüfen. Beispiel B6 kann auch die Merkmale von einem oder mehreren von Beispielen B2 bis B5 enthalten.
Beispiel B7 ist eine Vorrichtung gemäß Beispiel B6, wobei die Sicherheits-Firmware, wenn ausgeführt, dem Sicherheitsmodul ermöglicht, die Einrichtungs-Firmware zu veranlassen, auf der externen Einrichtung durch Sicherungs-Einrichtungs-Firmware ersetzt zu werden, als Reaktion auf eine Bestimmung, dass die Einrichtungs-Firmware auf der externen Einrichtung Integrität verloren hat.
Beispiel B8 ist eine Vorrichtung gemäß Beispiel B6, wobei die Sicherheits-Firmware, wenn ausgeführt, dem Sicherheitsmodul ermöglicht, (a) neue Einrichtungs-Firmware für die externe Einrichtung zu empfangen; (b) die neue Einrichtungs-Firmware zu authentifizieren; und (c) als Reaktion auf ein erfolgreiches Authentifizieren der neuen Einrichtungs-Firmware, die Einrichtungs-Firmware für die externe Einrichtung durch die neue Einrichtungs-Firmware zu ersetzen. Beispiel B8 kann auch die Merkmale von Beispiel B7 enthalten.
Beispiel B9 ist eine Vorrichtung gemäß Beispiel B6, wobei die Sicherheits-Firmware, wenn ausgeführt, (a) der externe Einrichtung erlaubt zu booten, bevor das Sicherheitsmodul Integrität der Einrichtungs-Firmware verifiziert hat, und (b) die externe Einrichtung veranlasst, in einem Nur-Lese-Modus auszuführen, bis das Sicherheitsmodul die Integrität einer Einrichtungs-Firmware für die externe Einrichtung verifiziert hat. Beispiel B9 kann auch die Merkmale von einem oder mehreren von Beispielen B7 bis B8 enthalten.
Beispiel B10 ist eine Vorrichtung gemäß Beispiel B1, wobei die Sicherheits-Firmware, wenn ausgeführt, dem Sicherheitsmodul ermöglicht, (a) neue Sicherheits-Firmware für das Sicherheitsmodul zu empfangen; (b) die neue Sicherheits-Firmware zu authentifizieren; und (c) als Reaktion auf ein erfolgreiches Authentifizieren der neuen Sicherheits-Firmware die Sicherheits-Firmware für das Sicherheitsmodul durch die neue Sicherheits-Firmware zu ersetzen. Beispiel B10 kann auch die Merkmale von einem oder mehreren von Beispielen B2 bis B9 enthalten.
Beispiel B11 ist eine Vorrichtung gemäß Beispiel B1, wobei das zumindest eine maschinenzugängliche Medium einen nicht flüchtigen Speicher (NVM) im Sicherheitsmodul und einen eingebetteten Speicher außerhalb des Sicherheitsmoduls umfasst. Ebenso liegt die Sicherheits-Firmware im NVM und die Host-Firmware liegt im eingebetteten Speicher. Beispiel B11 kann auch die Merkmale von einem oder mehreren von Beispielen B2 bis B10 enthalten.
Beispiel C1 ist ein Verfahren zum Schützen von Firmware in einem eingebetteten System. Das eingebettete System umfasst ein Sicherheitsmodul und ein Host-Modul. Das Verfahren umfasst während eines Boot-Prozesses für das Sicherheitsmodul (a) automatisches Verifizieren einer Integrität von Host-Firmware für das Host-Modul und (b) automatisches Verhindern, dass das Host-Modul mit der Host-Firmware bootet, als Reaktion auf eine Bestimmung, dass die Host-Firmware Integrität verloren hat. Das Verfahren umfasst ferner, während eines Boot-Prozesses für das Host-Modul, ein automatische Bestimmen, ob ein genehmigtes Sicherheitsmodul mit dem Host-Modul in Kommunikation steht, basierend auf einer geheimen Kennung für das genehmigte Sicherheitsmodul.
Beispiel C2 ist ein Verfahren gemäß Beispiel C1, weiter umfassend, als Reaktion auf eine Bestimmung, dass das genehmigte Sicherheitsmodul nicht mit dem Host-Modul in Kommunikation steht, automatisches Verhindern, dass das Host-Modul erfolgreich bootet.
Beispiel C3 ist ein Verfahren gemäß Beispiel C1, weiter umfassend, während des Boot-Prozesses für das Host-Modul, automatisches Verifizieren einer Integrität der Sicherheits-Firmware für das Sicherheitsmodul. Das Verfahren umfasst ferner ein automatisches Verhindern, dass das Sicherheitsmodul mit der Sicherheits-Firmware bootet, als Reaktion auf eine Bestimmung, dass die Sicherheits-Firmware Integrität verloren hat. Beispiel C3 kann auch die Merkmale von Beispiel C2 enthalten.
Beispiel C4 ist ein Verfahren gemäß Beispiel C1, weiter umfassend (a) Erhalten einer geheimen Kennung für das Host-Modul vom Host-Modul; (b) Erhalten einer geheimen Kennung für das genehmigte Host-Modul vom nicht flüchtigen Datenspeicher im Sicherheitsmodul; und (c) Bestimmen, ob das genehmigte Host-Modul mit dem Sicherheitsmodul in Kommunikation steht, basierend auf (i) der geheimen Kennung vom Host-Modul und (ii) der geheimen Kennung vom nicht flüchtigen Datenspeicher im Sicherheitsmodul. Beispiel C4 kann auch die Merkmale von einem oder mehreren von Beispielen C2 bis C3 enthalten.
Beispiel C5 ist ein Verfahren gemäß Beispiel C1, weiter umfassend Reagieren, durch das Sicherheitsmodul, auf ein Problem mit dem Host-Modul, indem zumindest eine Operation durchgeführt wird aus der Gruppe bestehend aus (a) Veranlassen einer Rücksetzung des Host-Moduls, (b) Veranlassen einer Durchführung einer Diagnose an dem Host-Modul, (c) Veranlassen einer Durchführung einer Diagnose an dem Sicherheitsmodul, (d) Veranlassen einer Sperre des Host-Moduls, und (e) Veranlassen einer Anzeige eines Fehlerindikators. Beispiel C5 kann auch die Merkmale von einem oder mehreren von Beispielen C2 bis C4 enthalten.
Beispiel C6 ist ein Verfahren gemäß Beispiel C1, weiter umfassend (a) als Reaktion auf eine Bestimmung, durch das Sicherheitsmodul, dass die Host-Firmware Integrität verloren hat, automatisches Austauschen der Host-Firmware durch Sicherungs-Host-Firmware; und (b) nach Austausch der Host-Firmware durch die Sicherungs-Host-Firmware, Veranlassen, dass das Host-Modul mit der Sicherungs-Host-Firmware bootet. Beispiel C6 kann auch die Merkmale von einem oder mehreren von Beispielen C2 bis C5 enthalten.
Beispiel C7 ist ein Verfahren gemäß Beispiel C1, weiter umfassend (a) während des Boot-Prozesses für das Sicherheitsmodul, Prüfen einer Integrität von Einrichtungs-Firmware für eine externe Einrichtung im eingebetteten System; und (b) als Reaktion auf eine Bestimmung, dass die Einrichtungs-Firmware auf der externen Einrichtung Integrität verloren hat, automatisches Veranlassen, dass die Einrichtungs-Firmware auf der externen Einrichtung durch Sicherungs-Einrichtungs-Firmware ersetzt wird. Beispiel C7 kann auch die Merkmale von einem oder mehreren von Beispielen C2 bis C6 enthalten.
Beispiel C8 ist ein Verfahren gemäß Beispiel C1, weiter umfassend (a) Empfangen bei dem Sicherheitsmodul, neuer Einrichtungs-Firmware für eine externe Einrichtung im eingebetteten System; (b) Authentifizieren der neuen Einrichtungs-Firmware, und (c) als Reaktion auf ein erfolgreiches Authentifizieren der neuen Einrichtungs-Firmware, Veranlassen der derzeitigen Einrichtungs-Firmware für die externe Einrichtung durch die neue Einrichtungs-Firmware ersetzt zu werden. Beispiel C8 kann auch die Merkmale von einem oder mehreren von Beispielen C2 bis C7 enthalten.
Beispiel D ist zumindest ein maschinenzugängliches Medium, umfassend Computeranweisungen zum Schützen von Firmware in einem eingebetteten System. Die Computeranweisungen ermöglichen, als Reaktion auf ihre Ausführung im eingebetteten System, dem eingebetteten System, ein Verfahren nach einem von Beispielen C1 bis C8 durchzuführen.
Beispiel E ist ein eingebettetes System mit Technologie zum Schützen von Firmware. Das eingebettete System umfasst (a) ein Verarbeitungselement, (b) zumindest ein maschinenzugängliches Medium, das auf das Verarbeitungselement anspricht, und (c) Computeranweisungen, die zumindest teilweise in dem zumindest einen maschinenzugänglichen Medium gespeichert sind. Die Computeranweisungen ermöglichen, als Reaktion auf ihre Ausführung, dem eingebetteten System ein Verfahren nach einem von Beispielen C1 bis C8 auszuführen.
Beispiel F ist ein eingebettetes System mit Technologie zum Schützen von Firmware. Das eingebettete System umfasst Mittel zum Durchführen des Verfahrens nach einem von Beispielen C1 bis C8.

Claims

Datenverarbeitungssystem mit Schutz für Firmware, das Datenverarbeitungssystem umfassend: ein Host-Modul, umfassend eine Management-Engine; ein Sicherheitsmodul in Kommunikation mit dem Host-Modul, wobei das Sicherheitsmodul einen Sicherheits-Coprozessor und eine geheime Kennung für das Sicherheitsmodul umfasst; zumindest ein maschinenzugängliches Medium, das auf das Sicherheitsmodul anspricht; Host-Firmware im maschinenzugänglichen Medium, die, wenn sie auf dem Host-Modul durch die Management-Engine ausgeführt wird, der Management-Engine ermöglicht zu bestimmen, ob das Sicherheitsmodul mit dem Host-Modul in Kommunikation steht, basierend auf der geheimen Kennung für das Sicherheitsmodul; und Sicherheits-Firmware im maschinenzugänglichen Medium, die, wenn sie auf dem Sicherheitsmodul durch den Sicherheits-Coprozessor ausgeführt wird, dem Sicherheits-Coprozessor ermöglicht, (a) die Integrität der Host-Firmware zu verifizieren und (b) zu verhindern, dass das Host-Modul mit der Host-Firmware bootet, als Reaktion auf eine Bestimmung, dass die Host-Firmware Integrität verloren hat.
Datenverarbeitungssystem nach Anspruch 1, wobei die Host-Firmware, wenn ausgeführt, der Management-Engine ermöglicht, auf eine Bestimmung zu reagieren, dass das Sicherheitsmodul nicht mit dem Host-Modul in Kommunikation steht, indem ein erfolgreiches Booten des Host-Moduls verhindert wird.
Datenverarbeitungssystem nach Anspruch 1, wobei die Host-Firmware, wenn ausgeführt, der Management-Engine ermöglicht, (a) die Integrität der Sicherheits-Firmware für das Sicherheitsmodul zu verifizieren und (b) zu verhindern, dass das Sicherheitsmodul mit der Sicherheits-Firmware bootet, als Reaktion auf eine Bestimmung, dass die Sicherheits-Firmware Integrität verloren hat.
Datenverarbeitungssystem nach Anspruch 1, wobei: das Host-Modul eine geheime Kennung für das Host-Modul umfasst; das Sicherheitsmodul einen nicht flüchtigen Datenspeicher mit einer geheimen Kennung für ein genehmigtes Host-Modul umfasst; und die Sicherheits-Firmware, wenn ausgeführt, dem Sicherheits-Coprozessor ermöglicht, (a) die geheime Kennung für das Host-Modul vom Host-Modul zu empfangen und (b) zu bestimmen, ob das genehmigte Host-Modul mit dem Sicherheitsmodul in Kommunikation steht, basierend auf (i) der geheimen Kennung vom Host-Modul und (ii) der geheimen Kennung vom nicht flüchtigen Datenspeicher im Sicherheitsmodul.
Datenverarbeitungssystem nach Anspruch 4, wobei: das Datenverarbeitungssystem zumindest eine Kommunikationsleitung umfasst, um ein Netzwerk zu unterstützen, das das Host-Modul und das Sicherheitsmodul umfasst; und die Sicherheits-Firmware, wenn ausgeführt, dem Sicherheits-Coprozessor ermöglicht, auf eine Bestimmung zu reagieren, dass das genehmigte Host-Modul nicht mit dem Sicherheitsmodul in Kommunikation steht, indem zumindest eine Operation durchgeführt wird aus der Gruppe bestehend aus: Veranlassen einer Rücksetzung des Host-Moduls; Veranlassen einer Entfernung des Host-Moduls aus dem Netzwerk; Veranlassen einer Durchführung einer Diagnose an dem Host-Modul; Veranlassen einer Durchführung einer Diagnose an dem Sicherheitsmodul; Veranlassen einer Sperre des Host-Moduls; und Veranlassen einer Anzeige eines Fehlerindikators.
Datenverarbeitungssystem nach Anspruch 1, wobei die Sicherheits-Firmware, wenn ausgeführt, dem Sicherheitsmodul ermöglicht, (a) automatisch die Host-Firmware durch Sicherungs-Host-Firmware als Reaktion auf eine Bestimmung auszutauschen, dass die Host-Firmware Integrität verloren hat und (b) nach Austausch der Host-Firmware durch die Sicherungs-Host-Firmware, das Host-Modul zu veranlassen, mit der Sicherungs-Host-Firmware zu booten.
Datenverarbeitungssystem nach Anspruch 1, weiter umfassend: zumindest eine externe Einrichtung in Kommunikation mit dem Sicherheitsmodul; und Einrichtungs-Firmware für die externe Einrichtung; und wobei die Sicherheits-Firmware, wenn ausgeführt, dem Sicherheitsmodul ermöglicht, Integrität der Einrichtungs-Firmware für die externe Einrichtung zu prüfen.
Datenverarbeitungssystem nach Anspruch 7, wobei die Sicherheits-Firmware, wenn ausgeführt, dem Sicherheitsmodul ermöglicht, die Einrichtungs-Firmware zu veranlassen, durch Sicherungs-Einrichtungs-Firmware ersetzt zu werden, als Reaktion auf eine Bestimmung, dass die Einrichtungs-Firmware für die externe Einrichtung Integrität verloren hat.
Datenverarbeitungssystem nach Anspruch 7, wobei die Sicherheits-Firmware, wenn ausgeführt, dem Sicherheitsmodul ermöglicht: der externen Einrichtung zu erlauben, zu booten, bevor das Sicherheitsmodul Integrität der Einrichtungs-Firmware verifiziert hat; und die externe Einrichtung zu veranlassen, in einem Nur-Lese-Modus auszuführen, bis das Sicherheitsmodul die Integrität der Einrichtungs-Firmware verifiziert hat.
Datenverarbeitungssystem nach Anspruch 7, wobei die Sicherheits-Firmware, wenn ausgeführt, dem Sicherheitsmodul ermöglicht: neue Einrichtungs-Firmware für die externe Einrichtung zu empfangen; die neue Einrichtungs-Firmware zu authentifizieren; und als Reaktion auf ein erfolgreiches Authentifizieren der neuen Einrichtungs-Firmware, zu veranlassen, dass die Einrichtungs-Firmware für die externe Einrichtung durch die neue Einrichtungs-Firmware ersetzt wird.
Datenverarbeitungssystem nach Anspruch 1, wobei die Sicherheits-Firmware, wenn ausgeführt, dem Sicherheitsmodul ermöglicht: neue Sicherheits-Firmware zu empfangen; die neue Sicherheits-Firmware zu authentifizieren; und als Reaktion auf ein erfolgreiches Authentifizieren der neuen Sicherheits-Firmware die Sicherheits-Firmware durch die neue Sicherheits-Firmware zu ersetzen.
Datenverarbeitungssystem nach Anspruch 1, wobei: das zumindest eine maschinenzugängliche Medium umfasst: nicht flüchtigen Speicher (NVM) im Sicherheitsmodul; und eingebetteten Speicher außerhalb des Sicherheitsmoduls; die Sicherheits-Firmware im NVM liegt; und die Host-Firmware im eingebetteten Speicher liegt.
Datenverarbeitungssystem nach Anspruch 11, wobei: das Host-Modul ein System-auf-einem-Chip (SoC) Modul umfasst; und der Sicherheits-Coprozessor ein feldprogrammierbares Gate Array umfasst (FPGA).
Datenverarbeitungssystem nach Anspruch 13, weiter umfassend: eine einzelne integrierte Schaltung, die das Host-Modul und das Sicherheitsmodul umfasst; und zumindest eine Kommunikationsleitung in der einzelnen integrierten Schaltung, um eine Kommunikation zwischen dem Host-Modul und dem Sicherheitsmodul zu ermöglichen.
Verfahren zum Schützen von Firmware in einem eingebetteten System, das Verfahren umfassend: in einem eingebetteten System, das ein Sicherheitsmodul und ein Host-Modul umfasst, während eines Boot-Prozesses für das Sicherheitsmodul (a) automatisches Verifizieren einer Integrität von Host-Firmware für das Host-Modul und (b) automatisches Verhindern, dass das Host-Modul mit der Host-Firmware bootet, als Reaktion auf eine Bestimmung, dass die Host-Firmware Integrität verloren hat; und während eines Boot-Prozesses für das Host-Modul, automatisches Bestimmen, ob ein genehmigtes Sicherheitsmodul mit dem Host-Modul in Kommunikation steht, basierend auf einer geheimen Kennung für das genehmigte Sicherheitsmodul.
Verfahren nach Anspruch 15, weiter umfassend: als Reaktion auf eine Bestimmung, dass das genehmigte Sicherheitsmodul nicht mit dem Host-Modul in Kommunikation steht, automatisches Verhindern, dass das Host-Modul erfolgreich bootet.
Verfahren nach Anspruch 15, weiter umfassend: während des Boot-Prozesses für das Host-Modul, automatisches Verifizieren einer Integrität der Sicherheits-Firmware für das Sicherheitsmodul; und automatisches Verhindern, dass das Sicherheitsmodul mit der Sicherheits-Firmware bootet, als Reaktion auf eine Bestimmung, dass die Sicherheits-Firmware Integrität verloren hat.
Verfahren nach Anspruch 15, weiter umfassend: Erhalten einer geheimen Kennung für das Host-Modul vom Host-Modul; Erhalten einer geheimen Kennung für das genehmigte Host-Modul vom nicht flüchtigen Datenspeicher im Sicherheitsmodul; und Bestimmen, ob das genehmigte Host-Modul mit dem Sicherheitsmodul in Kommunikation steht, basierend auf (i) der geheimen Kennung vom Host-Modul und (ii) der geheimen Kennung vom nicht flüchtigen Datenspeicher im Sicherheitsmodul.
Verfahren nach Anspruch 15, weiter umfassend: Reagieren, durch das Sicherheitsmodul, auf ein Problem mit dem Host-Modul, indem zumindest eine Operation durchgeführt wird aus der Gruppe bestehend aus: Veranlassen einer Rücksetzung des Host-Moduls; Veranlassen einer Durchführung einer Diagnose an dem Host-Modul; Veranlassen einer Durchführung einer Diagnose an dem Sicherheitsmodul; Veranlassen einer Sperre des Host-Moduls; und Veranlassen einer Anzeige eines Fehlerindikators.
Verfahren nach Anspruch 15, weiter umfassend: als Reaktion auf eine Bestimmung, durch das Sicherheitsmodul, dass die Host-Firmware Integrität verloren hat, automatisches Austauschen der Host-Firmware mit Sicherungs-Host-Firmware; und nach Austausch der Host-Firmware durch die Sicherungs-Host-Firmware, Veranlassen, dass das Host-Modul mit der Sicherungs-Host-Firmware bootet.
Verfahren nach Anspruch 15, weiter umfassend: während des Boot-Prozesses für das Sicherheitsmodul, Prüfen einer Integrität von Einrichtungs-Firmware für eine externe Einrichtung im eingebetteten System; und als Reaktion auf eine Bestimmung, dass die Einrichtungs-Firmware auf der externen Einrichtung Integrität verloren hat, automatisches Veranlassen, dass die Einrichtungs-Firmware auf der externen Einrichtung durch Sicherungs-Einrichtungs-Firmware ersetzt wird.
Verfahren nach Anspruch 15, weiter umfassend: Empfangen, beim Sicherheitsmodul, neuer Einrichtungs-Firmware für eine externe Einrichtung im eingebetteten System; Authentifizieren der neuen Einrichtungs-Firmware; und als Reaktion auf ein erfolgreiches Authentifizieren der neuen Einrichtungs-Firmware, Veranlassen, dass eine aktuelle Einrichtungs-Firmware für die externe Einrichtung durch die neue Einrichtungs-Firmware ersetzt wird.
Zumindest ein maschinenzugängliches Medium, umfassend Computeranweisungen zum Schützen von Firmware in einem eingebetteten System, wobei die Computeranweisungen, als Reaktion auf ihre Ausführung im eingebetteten System, dem eingebetteten System ermöglichen, ein Verfahren nach einem der Ansprüche 15 bis 22 durchzuführen.
Eingebettetes System mit Technologie zum Schützen von Firmware, das eingebettete System umfassend: ein Verarbeitungselement; zumindest ein maschinenzugängliches Medium, das auf das Verarbeitungselement anspricht; und Computeranweisungen, die zumindest teilweise in dem zumindest einen maschinenzugänglichen Medium gespeichert sind, wobei die Computeranweisungen, als Reaktion auf ihre Ausführung, dem eingebetteten System ermöglichen, ein Verfahren nach einem der Ansprüche 15 bis 22 durchzuführen.
Eingebettetes System mit Technologie zum Schützen von Firmware, das eingebettete System umfassend: Mittel zum Durchführen des Verfahrens nach einem der Ansprüche 15 bis 22.