DE112019005701T5

DE112019005701T5 - Sichere boot-unterstützung für vorrichtungen und zugehörige systeme, verfahren und vorrichtungen

Info

Publication number: DE112019005701T5
Application number: DE112019005701.4T
Authority: DE
Inventors: Kerry Maletsky; David Paul Arnold; Nicolas Auguste Constant Schieli; Bryan Hunt
Original assignee: Microchip Technology Inc
Current assignee: Microchip Technology Inc
Priority date: 2018-11-13
Filing date: 2019-10-15
Publication date: 2021-07-29
Also published as: US20200151336A1; WO2020101832A1; US11455397B2; US20230020278A1; CN113039545A

Abstract

Systeme, Verfahren und Vorrichtungen der Offenbarung beziehen sich im Allgemeinen auf die Sicherung der Bootunterstützung für Vorrichtungen. In einer oder mehreren Ausführungsformen schließt eine erste Vorrichtung Firmware ein, die als Teil eines sicheren Boot-Prozesses als sicher verifiziert werden muss, und eine zweite Vorrichtung unterstützt die erste Vorrichtung, um den sicheren Boot-Prozess zu sichern. In einigen Ausführungsformen verifiziert die zweite Vorrichtung die Sicherheit der Firmware als Reaktion auf Sicherheitsdaten, die von der ersten Vorrichtung bereitgestellt werden, oder verifiziert die Sicherheit eines Programms, das von der ersten Vorrichtung bereitgestellt wird, wobei das Programm zum Verifizieren der Sicherheit der Firmware dient. In einigen Ausführungsformen stellt die zweite Vorrichtung ein Programm zum Verifizieren der Sicherheit der Firmware für die erste Vorrichtung bereit.

Description

PRIORITÄTSANSPRUCH
Diese Anmeldung beansprucht den Nutzen der an dem Anmeldetag eingereichten vorläufigen US-Patentanmeldung mit Seriennummer 62/760.636 , eingereicht am 13. November 2018, für „SECURE BOOT ASIST FOR MICROCONTROLLERS AND RELATED SYSTEMS, METHOD AND DEVICES‟ und beansprucht den Nutzen der an dem Anmeldetag eingereichten US-Patentanmeldung mit Seriennummer 16/364.391 , eingereicht am 26. März 2019, für „SECURE BOOT ASSIST FOR DEVICES, AND RELATED SYSTEMS, METHODS AND DEVICES‟, anhängig, deren Offenbarung jeweils hiermit durch Bezugnahme darauf aufgenommen ist.
TECHNISCHES GEBIET
Die vorliegende Offenbarung bezieht sich allgemein darauf, sicherzustellen, dass Firmware, die auf einer Zielvorrichtung ausgeführt werden soll, sicher ist; und insbesondere beziehen sich einige Ausführungsformen allgemein auf die Verwendung einer sicheren Vorrichtung außerhalb einer Zielvorrichtung, um sicherzustellen, dass ein Programm zum Verifizieren von Firmware an der Zielvorrichtung sicher ist; und noch spezieller beziehen sich einige Ausführungsformen allgemein auf die Verwendung einer sicheren Vorrichtung außerhalb einer Zielvorrichtung, um mindestens einen Teil eines sicheren Boot-Prozesses an der Zielvorrichtung zu steuern, um sicherzustellen, dass Firmware, die an der Zielvorrichtung ausgeführt werden soll, sicher ist.
STAND DER TECHNIK
Manchmal muss die Firmware, auf der Vorrichtungen wie Mikrocontroller-Einheiten (MCUs) laufen, „vor Ort“ aktualisiert werden (d. h. nachdem die Vorrichtung das Werk verlassen hat), zum Beispiel, weil ein Hersteller eine neue Version von Firmware freigibt, um Fehler zu korrigieren oder Funktionalität hinzuzufügen. Viele Vorrichtungen verwenden Flash-Speicher oder andere nichtflüchtige Speicher, um Firmware zu speichern, da der Flash-Speicher durch Firmware selbst modifiziert werden kann.
Figurenliste
Während diese Offenbarung mit Ansprüchen endet, die bestimmte Ausführungsformen besonders hervorheben und eindeutig beanspruchen, können verschiedene Merkmale und Vorteile von Ausführungsformen innerhalb des Umfangs dieser Offenbarung leichter aus der folgenden Beschreibung erkundet werden, wenn sie in Verbindung mit den beigefügten Zeichnungen gelesen werden, in denen:

1 ist ein vereinfachtes Blockdiagramm eines Computersystems gemäß einer oder mehreren Ausführungsformen der Offenbarung;
2 ist ein vereinfachtes Blockdiagramm eines Systems zur Sicherstellung der Authentizität einer MCU-Anwendung gemäß einer oder mehreren Ausführungsformen der Offenbarung;
3 ist ein beispielhafter Prozess für die nachfolgende Authentizität einer MCU-Anwendung gemäß einer oder mehreren Ausführungsformen der Offenbarung;
4 ist ein vereinfachtes Blockdiagramm eines Systems zur Sicherstellung der Authentizität einer MCU-Anwendung gemäß einer oder mehreren Ausführungsformen der Offenbarung;
5 ist ein beispielhafter Prozess für die nachfolgende Authentizität einer MCU-Anwendung gemäß einer oder mehreren Ausführungsformen der Offenbarung;
6 ist ein vereinfachtes Blockdiagramm eines Systems zur Sicherstellung der Authentizität einer MCU-Anwendung gemäß einer oder mehreren Ausführungsformen der Offenbarung;
7 ist ein beispielhafter Prozess für die nachfolgende Authentizität einer MCU-Anwendung gemäß einer oder mehreren Ausführungsformen der Offenbarung;

ART(EN) DER AUSFÜHRUNG DER ERFINDUNG
In der folgenden detaillierten Beschreibung wird auf die beigefügten Zeichnungen Bezug genommen, die einen Teil hiervon bilden und in denen zur Veranschaulichung spezifische Beispiele von Ausführungsformen gezeigt sind, in denen die vorliegende Offenbarung ausgeführt werden kann. Diese Ausführungsformen werden ausreichend detailliert beschrieben, um es einem Durchschnittsfachmann zu ermöglichen, die vorliegende Offenbarung in die Praxis umzusetzen. Es können jedoch auch andere Ausführungsformen verwendet werden und Änderungen der Struktur, des Materials und des Prozesses können vorgenommen werden, ohne vom Schutzumfang der Offenbarung abzuweichen.
Die hierin dargestellten Veranschaulichungen sollen keine tatsächlichen Ansichten eines bestimmten Verfahrens oder Systems oder einer bestimmten Vorrichtung oder Struktur sein, sondern sind lediglich idealisierte Darstellungen, die zur Beschreibung der Ausführungsformen der vorliegenden Offenbarung verwendet werden. Die hierin dargestellten Zeichnungen sind nicht notwendigerweise maßstabsgetreu. Ähnliche Strukturen oder Komponenten in den verschiedenen Zeichnungen können zur Vereinfachung für den Leser die gleiche oder eine ähnliche Nummerierung beibehalten; die Ähnlichkeit in der Nummerierung bedeutet jedoch nicht, dass die Strukturen oder Komponenten notwendigerweise in Größe, Zusammensetzung, Konfiguration oder einer anderen Eigenschaft identisch sind.
Es versteht sich von selbst, dass die Komponenten der Ausführungsformen, wie sie hierin allgemein beschrieben und in der Zeichnung veranschaulicht sind, in einer Vielzahl unterschiedlicher Konfigurationen angeordnet und gestaltet werden können. Somit soll die folgende Beschreibung verschiedener Ausführungsformen den Schutzumfang der vorliegenden Offenbarung nicht einschränken, sondern ist lediglich repräsentativ für verschiedene Ausführungsformen.
Die folgende Beschreibung kann Beispiele einschließen, um es einem Durchschnittsfachmann zu ermöglichen, die offenbarten Ausführungsformen auszuführen. Die Verwendung der Begriffe „beispielhaft“, „als Beispiel“, „zum Beispiel“ und dergleichen bedeutet, dass die zugehörige Beschreibung erläuternd ist, und während der Schutzumfang der Offenbarung die Beispiele und ihre rechtlichen Äquivalente umfassen soll, ist die Verwendung solcher Begriffe nicht dazu bestimmt, den Schutzumfang einer Ausführungsform oder dieser Offenbarung auf die spezifizierten Komponenten, Schritte, Merkmale, Funktionen oder dergleichen einzuschränken.
Somit sind die gezeigten und beschriebenen spezifischen Implementierungen nur Beispiele und sollten nicht als die einzige Möglichkeit zur Implementierung der vorliegenden Offenbarung ausgelegt werden, sofern hierin nicht anders angegeben.
Elemente, Schaltungen und Funktionen können in Blockdiagrammform gezeigt sein, um die vorliegende Offenbarung nicht durch unnötige Details undeutlich werden zu lassen. Umgekehrt sind gezeigte und beschriebene spezifische Implementierungen nur beispielhaft und sollten nicht als die einzige Möglichkeit zur Implementierung der vorliegenden Offenbarung ausgelegt werden, sofern hierin nicht anders angegeben. Außerdem sind Blockdefinitionen und die Aufteilung von Logik zwischen verschiedenen Blöcken beispielhaft für eine spezifische Implementierung. Es ist für den Fachmann ohne Weiteres ersichtlich, dass die vorliegende Offenbarung durch zahlreiche andere Aufteilungslösungen ausgeführt werden kann. Details bezüglich Zeitüberlegungen und dergleichen wurden größtenteils weggelassen, wenn solche Details nicht notwendig sind, um ein vollständiges Verständnis der vorliegenden Offenbarung zu erhalten, und diese innerhalb der Fähigkeiten eines Durchschnittsfachmanns liegen.
Der Durchschnittsfachmann würde verstehen, dass Informationen und Signale unter Verwendung einer Vielfalt verschiedener Technologien und Techniken dargestellt werden können. Zum Beispiel können Daten, Anweisungen, Befehle, Informationen, Signale, Bits und Symbole, auf die in dieser Beschreibung Bezug genommen werden kann, durch Spannungen, Ströme, elektromagnetische Wellen, Magnetfelder oder -partikel, optische Felder oder Partikel oder eine beliebige Kombination davon dargestellt werden. Einige Zeichnungen können Signale zur Übersichtlichkeit der Darstellung und Beschreibung als ein einzelnes Signal veranschaulichen. Es ist für einen Durchschnittsfachmann ersichtlich, dass das Signal einen Bus von Signalen darstellen kann, wobei der Bus eine Vielfalt von Bitbreiten aufweisen kann und die vorliegende Offenbarung auf einer beliebigen Anzahl von Datensignalen, einschließlich eines einzelnen Datensignals, implementiert werden kann.
Die verschiedenen veranschaulichenden logischen Blöcke, Module und Schaltungen, die in Verbindung mit den hierin offenbarten Ausführungsformen beschrieben werden, können mit einem Universalprozessor, einem Spezialprozessor, einem digitalen Signalprozessor (Digital Signal Processor, DSP), einer integrierten Schaltung (Integrated Circuit, IC), einer anwendungsspezifischen integrierten Schaltung (Application Specific Integrated Circuit, ASIC), einer anwenderprogrammierbaren Gatteranordnung (Field Programmable Gate Array, FPGA) oder einer anderen programmierbaren Logikvorrichtung, einer diskreten Gate- oder Transistorlogik, diskreten Hardwarekomponenten oder einer beliebigen Kombination davon, die zum Durchführen der hierin beschriebenen Funktionen ausgelegt sind, implementiert oder durchgeführt werden. Ein Allzweckprozessor (der hierin auch als Host-Prozessor oder einfach als Host bezeichnet werden kann) kann ein Mikroprozessor sein, alternativ kann der Prozessor jedoch ein beliebiger herkömmlicher Prozessor, Controller, Mikrocontroller oder Zustandsautomat sein. Ein Prozessor kann auch als eine Kombination von Rechenvorrichtungen, wie eine Kombination aus einem DSP und einem Mikroprozessor, eine Vielzahl von Mikroprozessoren, ein oder mehrere Mikroprozessoren in Verbindung mit einem DSP-Kern oder eine beliebige andere derartige Konfiguration implementiert sein. Ein Universalcomputer einschließlich eines Prozessors wird als Spezialcomputer angesehen, während der Universalcomputer so konfiguriert ist, dass er Rechenanweisungen (z. B. einen Softwarecode) ausführt, die sich auf Ausführungsformen der vorliegenden Offenbarung beziehen. Obwohl Code hierin als so konfiguriert beschrieben werden kann, dass er es einem Prozessor ermöglicht, bestimmte Funktionen oder Operationen durchzuführen, kann die Beschreibung eines Prozessors in einigen Fällen weggelassen werden, da die Erfinder glauben, dass eine wiederholte Angabe eines Prozessors Details von offenbarten Ausführungsformen verschleiern kann. Zum Beispiel kann Code manchmal als Funktionen oder Operationen ausführend beschrieben oder so konfiguriert werden, dass er Funktionen oder Operationen der offenbarten Ausführungsformen durchführt, ohne spezifisch darauf hinzuweisen, dass die Funktionen oder Operationen von einem Prozessor durchgeführt werden, der den Code ausführt.
Die Ausführungsformen können in Bezug auf einen Prozess beschrieben sein, der als ein Flussdiagramm, ein Fließschema, ein Strukturdiagramm oder ein Blockdiagramm dargestellt ist. Obwohl ein Flussdiagramm Betriebsvorgänge als einen sequentiellen Prozess beschreiben kann, können viele dieser Vorgänge in einer anderen Sequenz, parallel oder im Wesentlichen gleichzeitig durchgeführt werden. Außerdem kann die Reihenfolge der Vorgänge neu angeordnet werden. Ein Prozess kann einem Verfahren, einem Thread, einer Funktion, einer Prozedur, einer Unterroutine, einem Unterprogramm usw. entsprechen. Weiterhin können die hierin offenbarten Verfahren in Hardware, Software oder beiden implementiert sein. Bei Implementierung in Software können die Funktionen als eine oder mehrere Anweisungen oder ein Code auf computerlesbaren Medien gespeichert oder übertragen werden. Computerlesbare Medien schließen sowohl Computerspeichermedien als auch Kommunikationsmedien, einschließlich aller Medien, die die Übertragung eines Computerprogramms von einem Ort zu einem anderen unterstützen, ein.
Jede Bezugnahme auf ein Element hierin unter Verwendung einer Bezeichnung, wie „erste/r/s“, „zweite/r/s“ usw. schränkt die Menge oder Reihenfolge dieser Elemente nicht ein, es sei denn, eine solche Einschränkung wird ausdrücklich angegeben. Vielmehr können diese Bezeichnungen hierin als ein zweckmäßiges Verfahren zum Unterscheiden zwischen zwei oder mehr Elementen oder Instanzen eines Elements verwendet werden. Ein Verweis auf ein erstes und ein zweites Element bedeutet also nicht, dass dort nur zwei Elemente eingesetzt werden dürfen oder dass das erste Element dem zweiten Element in irgendeiner Weise vorhergehen muss. Außerdem kann ein Satz von Elementen, sofern nicht anders angegeben, ein oder mehrere Elemente umfassen.
Wie hierin verwendet, bedeutet der Begriff „im Wesentlichen“ in Bezug auf einen gegebenen Parameter, eine gegebene Eigenschaft oder eine gegebene Bedingung und schließt in einem für den Durchschnittsfachmann verständlichen Ausmaß ein, dass der gegebene Parameter, die gegebene Eigenschaft oder die gegebene Bedingung mit einem geringen Maß an Varianz, wie zum Beispiel innerhalb annehmbarer Fertigungstoleranzen, erfüllt ist. Beispielhaft kann in Abhängigkeit von dem bestimmten Parameter, der bestimmten Eigenschaft oder der bestimmten Bedingung, der bzw. die im Wesentlichen erfüllt ist, der Parameter, die Eigenschaft oder die Bedingung zu mindestens 90 % erfüllt, zu mindestens 95 % erfüllt oder sogar zu mindestens 99 % erfüllt sein.
Wie in der vorliegenden Offenbarung verwendet, können sich die Begriffe „Einheit“, „Modul“ oder „Komponente“ auf spezifische Hardware-Implementierungen beziehen, die so konfiguriert sind, dass sie die Aktionen des Moduls oder der Komponente und/oder Softwareobjekte oder Softwareroutinen durchführen, die auf Universalhardware (z. B. computerlesbare Medien, Verarbeitungsvorrichtungen etc.) des Computersystems gespeichert und/oder von dieser ausgeführt werden können. In einigen Ausführungsformen können die unterschiedlichen Einheiten, Komponenten, Module, Engines und Dienste, die in der vorliegenden Offenbarung beschrieben sind, als Objekte oder Prozesse implementiert werden, die auf dem Computersystem (z. B. als separate Threads) ausgeführt werden. Obwohl einige der in der vorliegenden Offenbarung beschriebenen Systeme und Verfahren allgemein als in Software implementiert (gespeichert auf und/oder ausgeführt durch Universalhardware) beschrieben sind, sind spezifische Hardware-Implementierungen oder eine Kombination von Software und spezifischen Hardware-Implementierungen ebenfalls möglich und werden in Betracht gezogen.
Bootcode wird häufig in Verbindung mit der Vor-Ort-Programmierung einer Vorrichtung verwendet. Bootcode ist ein kleiner Codeabschnitt (d. h. Block) (im Vergleich zum Anwendungscode), der zum Betriebscode hinzugefügt (d. h. im Flash-Speicher gespeichert) wird, der Systemfunktionen ausführt, zum Beispiel wenn eine Vorrichtung eingeschaltet wird oder wenn die Vorrichtung einen Reset durchführt. In einem üblichen eingebetteten System, insbesondere jenen, die Flash-Speicher verwenden, kann Bootcode Aufgaben durchführen, wie Überprüfen von Inhalten des Flash-Speichers und Systeminitialisierungsaufgaben. Der Betriebscode kann dafür verantwortlich sein, neue Firmware zu dem eingebetteten System zu bewegen und alte Firmware zu ersetzen, und kann einen Teil der Bootcode-Funktionalität zum Prüfen eines neuen Firmware-Abbildes teilen oder kann sich auf den Bootcode stützen, um ein neues Firmware-Abbild zu prüfen.
Um einer Vorrichtung mitzuteilen, sich darauf vorzubereiten, neue Firmware zu empfangen, werden üblicherweise Hardware- und/oder Softwarebedingungen verwendet. Ein Beispiel für eine Hardwarebedingung kann das Drücken einer Schaltfläche während des Resets einer Vorrichtung sein, und ein Beispiel für eine Softwarebedingung kann das Erfassen eines Fehlens einer gültigen Anwendung, die auf einer Vorrichtung gespeichert ist, während des Resets sein. Wenn Bootcode als eine Aktualisierungsbedingung erkannt wird (üblicherweise ein beim Systemstart durchgeführter Bootcode), versucht die Installationsanwendung oder der Bootcode, sich mit einem Host (z. B., einem Personalcomputer oder Programmiertool, ohne darauf beschränkt zu sein) zu verbinden, und wartet darauf, ein Abbild der neuen Firmware zu empfangen. Sobald neue Firmware zu einer Vorrichtung bewegt wird und alte Firmware ersetzt, kann der neue Code dann von der Vorrichtung ausgeführt werden.
Ein Problem, das manchmal bei der Vor-Ort-Programmierung einer Vorrichtung auftritt, besteht darin, dass neue Firmware möglicherweise nicht authentisch ist, zum Beispiel kann sie von einem unberechtigten Dritten entworfen oder bereitgestellt werden, d. h. nicht von einem berechtigten Teilnehmer wie dem Originalhersteller oder einem vom Originalhersteller berechtigten Dritten. So könnte die neue Firmware für eine bösartige Verwendung, z. B., entwickelt werden, um den Sicherheitsschutz zu umgehen oder eine kritische Funktionalität einer Vorrichtung illegal zu verwenden, ohne sich darauf zu beschränken. Darüber hinaus könnte neue Firmware von einem berechtigten Teilnehmer bereitgestellt werden, aber für eine andere Vorrichtung beabsichtigt sein.
Ein weiteres Problem besteht darin, dass die Integrität neuer Firmware beeinträchtigt werden kann. Das heißt, Daten neuer Firmware können gegenüber ihrer ursprünglichen Form manchmal nur geringfügig modifiziert werden. Modifizierte Firmware kann immer noch echt erscheinen, aber die Modifikationen können die gleichen Sicherheitsprobleme erleichtern, die oben erwähnt wurden, nämlich die Umgehung von Sicherheitsschutzmaßnahmen oder die illegale Verwendung kritischer Funktionalität einer Vorrichtung. Darüber hinaus kann beeinträchtigte Firmware die Firmware der Außenwelt aussetzen und Dritten ermöglichen, die Firmware eines Herstellers zu kopieren und/oder zu reversieren.
Ein weiteres Problem besteht darin, dass der Datenschutz beeinträchtigt werden kann, wenn ein Abbild neuer Firmware (die elektronischen Kopien der Firmware, die an Vorrichtungen verteilt werden) freigelegt oder zugänglich ist. Firmware könnte von einem Dritten während des Transports zur Zielvorrichtung dekompiliert oder von Dritten analysiert werden, und proprietäre Informationen, die in der Firmware oder über die Firmware gespeichert sind, könnten erfasst werden.
Bootcode ist ein kritischer Teil der Aufrechterhaltung der Sicherheit von Firmware (d. h. Authentizität, Integrität und/oder Datenschutz). Firmware-Sicherheit wird manchmal durch Bootcode in einer Sequenz von Operationen verifiziert, die allgemein als „sichere Boot-Sequenz“ bezeichnet wird. Zum Beispiel ist in einer üblichen sicheren Bootsequenz der Bootcode der erste Code, der ausgeführt wird, nachdem der Prozessor zurückgesetzt oder hochgefahren wurde, der Bootcode verifiziert dann die Sicherheit der neuen Firmware, die im Programmspeicher gespeichert ist, und wenn die neue Firmware verifiziert wird, initiiert der Bootcode das Laden und Ausführen der Firmware.
Das Verifizieren der Firmware-Sicherheit beinhaltet üblicherweise das Authentifizieren einer Quelle neuen Anwendungscodes und das Bestätigen der Integrität der Firmware. Digitale Signaturen und/oder die Verwendung eines Message Authentication Codes (MAC), die für berechtigte Teilnehmer einzigartig sind, werden häufig verwendet, um eine Quelle der Firmware zu authentifizieren, zum Beispiel bei einer digitalen Signatur unter Verwendung eines entsprechenden Public Keys oder bei einem MAC unter Verwendung eines Private Keys, der verwendet wurde, um den MAC zu berechnen.
Um die Integrität zu bestätigen, werden häufig Hash-Funktionen verwendet, wenn Firmware generiert wird, um einen Digest (auch manchmal als „Message Digest“ bezeichnet) zu erzeugen, welcher der erstellten Firmware entspricht. Es wird angenommen, dass die Hash-Funktionen, die verwendet werden, um den Digest zu erstellen, dieselben sind wie Hash-Funktionen, die auf den Zielvorrichtungen gespeichert sind, wenn sie hergestellt wurden. Dieser „erste“ Digest kann zum Beispiel unter Verwendung von Public-Key-Kryptografietechniken verschlüsselt werden, um eine digitale Signatur zu erhalten. Diese digitale Signatur kann mit neuer Firmware zur Vor-Ort-Programmierung von Vorrichtungen verteilt werden. Wenn eine Vorrichtung die Firmware und die erste digitale Signatur empfängt, berechnet sie einen zweiten Digest aus der empfangenen Firmware unter Verwendung lokal gespeicherter Hash-Funktion(en), die gleiche Hash-Funktion(en) sein sollten, die zum Erstellen des ersten Digests verwendet werden. Der Empfänger verschlüsselt den zweiten Digest, um eine zweite digitale Signatur zu erhalten, und vergleicht die zweite digitale Signatur mit der ersten digitalen Signatur, um zu bestimmen, ob die digitalen Signaturen übereinstimmen. Wenn die Firmware modifiziert wurde, sogar geringfügig, dann stimmt theoretisch (statistisch ist die Wahrscheinlichkeit einer Kollision, d. h. Erhalten des gleichen Digests bei Verwendung der gleichen Hash-Funktion(en) mit unterschiedlicher Firmware sehr gering) der zweite Digest nicht mit dem ersten Digest überein, so dass die erste digitale Signatur nicht mit der zweiten digitalen Signatur übereinstimmt.
In einigen Fällen kann Bootcode einen öffentlichen Schlüssel verwenden, der einem privaten Schlüssel entspricht, der verwendet wird, um die erste digitale Signatur zu erzeugen, um die erste digitale Signatur zu entschlüsseln und den ersten Digest wiederherzustellen. Ein Bootcode kann dann einen zweiten Digest wie hierin beschrieben erzeugen und den ersten Digest und den zweiten Digest vergleichen, um zu bestimmen, ob sie übereinstimmen. MAC-Codes, die unter Verwendung der Private-Key-Kryptografietechniken erzeugt werden, werden manchmal anstelle oder zusätzlich zu digitalen Signaturen verwendet. Insbesondere dient die Verschlüsselung auch dazu, eine Zielvorrichtung implizit zu verifizieren, d. h. zu verifizieren, dass diese echt oder eine beabsichtigte Zielvorrichtung für Firmware ist.
Die Verifizierung, dass Firmware sicher ist, hängt mindestens teilweise davon ab, dass ein „Root of Trust“ eingerichtet wird, dass ein ursprüngliches Programm, wie ein Bootcode, das für die Authentifizierung, die Bestätigung der Integrität und/oder Entschlüsselung verantwortlich ist, selbst sicher ist. Eine herkömmliche Technik zum Einrichten einer anfänglichen Root of Trust besteht darin, Bootcode in einem Nurlesespeicher (ROM) einer Zielvorrichtung zu speichern und für einen sicheren Boot-Prozess entweder den Bootcode direkt aus ROM auszuführen oder den gespeicherten Bootcode in einen Programmspeicher zu kopieren und als einen anfänglichen Schritt die Sicherheit des kopierten Bootcodes unter Verwendung des gespeicherten Bootcodes zu verifizieren. In beiden Fällen richtet der ROM eine anfängliche Root of Trust ein.
Sichere Boot-Fähigkeiten werden zunehmend in Vorrichtungen wie MCUs verwendet, aber viele bestehende Vorrichtungen verfügen nicht über einen Boot-ROM (d. h. ROM mit einem darauf gespeicherten Bootcode), um eine anfängliche Root of Trust einzurichten und sichere Boot-Prozesse zu implementieren. Einige Vorrichtungen, wie Mikroprozessoren (MPUs), implementieren einen separaten Chip, der zwischen einem Prozessor und einem Speicher sitzt, jedoch ist eine solche Technik für Vorrichtungen, die integrierten Codespeicher aufweisen (d. h. gleichen Speicher für Betriebscode und Bootcode), nicht praktikabel. Darüber hinaus wäre im Fall von MCUs das Wechseln eines Maskensatzes für jede MCU, um ein Boot-ROM einzuschließen, prohibitiv und teuer in Bezug auf Kosten und Zeit.
Somit erkennen die Erfinder dieser Offenbarung einen Bedarf an Systemen, Verfahren und Vorrichtungen, um Zielvorrichtungen bei sicheren Boot-Prozessen zu unterstützen. In einigen Ausführungsformen können solche Systeme, Verfahren und Vorrichtungen eine Root of Trust zum Implementieren eines sicheren Boots an Zielvorrichtungen ohne Boot-ROMs oder andere Hardware zum Einrichten einer Root of Trust einrichten. Darüber hinaus erkennen die Erfinder dieser Offenbarung einen Bedarf an Systemen, Verfahren und Vorrichtungen zum Implementieren sicherer Boot-Prozesse in Zielvorrichtungen, die ursprünglich keine sichere Boot-Fähigkeit aufwiesen oder die eine stärkere Root of Trust benötigen.
Eine oder mehrere Ausführungsformen der Offenbarung beziehen sich im Allgemeinen auf die Verwendung einer sicheren externen Vorrichtung (z. B., eines Chips oder Mikrocontrollers, ohne darauf beschränkt zu sein) zum Validieren von Bootcode einer Hostvorrichtung oder zum Bereitstellen von Bootcode für eine Hostvorrichtung, so dass die Hostvorrichtung einen sicheren Boot-Prozess ausführen kann. In einer oder mehreren Ausführungsformen kann ein Hardwareausgang der sicheren Vorrichtung operativ mit einem Hardwareeingang der Hostvorrichtung gekoppelt sein, wobei der Hardwareeingang ein einziger Auslöser zum Initiieren eines eingeschränkten Betriebsmodus an der Hostvorrichtung ist, und die Hostvorrichtung während des eingeschränkten Modus keinen lokalen Code (z. B. Bootcode oder Betriebscode, ohne darauf beschränkt zu sein) unabhängig ausführen kann und E/A-Anschlüsse deaktiviert sind, mit Ausnahme einer Schnittstelle der Hostvorrichtung, die eine Gruppe von E/A-Anschlüssen aufweist, die nur durch die sichere externe Vorrichtung zugänglich sind und die durch diese gesteuert werden. In einer oder mehreren Ausführungsformen können Verbindungen für den Hardwareeingang und die Schnittstelle physisch isoliert sein, sodass sie von außen nicht zugänglich sind, zum Beispiel durch Stapeln und/oder Verpacken der sicheren Vorrichtung zusammen mit der Hostvorrichtung in einem Modul, sodass Verbindungen zwischen der sicheren Vorrichtung und der Hostvorrichtung „versteckt“ sind. Auf diese Weise kann ein Hardwareeingang einer Hostvorrichtung als ein „Vertrauensanker“ zwischen einer sicheren Vorrichtung und einer Hostvorrichtung gekennzeichnet sein.
1 zeigt ein vereinfachtes Blockdiagramm eines Computersystems 100, das die sichere Vorrichtung 110 und die Hostvorrichtung 130 gemäß einer oder mehreren Ausführungsformen der Offenbarung einschließt. Als nicht einschränkende Beispiele kann das Computersystem 100 Teil eines eingebetteten Systems vom Mikrocontrollertyp, eines Computers vom Benutzertyp, eines Dateiservers, eines Computerservers, eines Notebook-Computers, eines Tablets, einer tragbaren Vorrichtung, einer mobilen Vorrichtung, einer drahtlosen Ohrhörervorrichtung oder Kopfhörervorrichtung, einer drahtgebundenen Ohrhörer- oder Kopfhörervorrichtung, eines Geräts, eines Automobilteilsystems oder anderer Computersysteme zum Ausführen von Software sein oder diese einschließen. Computer, Computersystem und Server können hierin austauschbar verwendet werden, um ein System zum Praktizieren von Ausführungsformen der vorliegenden Offenbarung anzugeben. Das Computersystem 100 kann zum Ausführen von Softwareprogrammen konfiguriert sein, die Computeranweisungen enthalten, und kann einen oder mehrere Prozessoren, Speicher, Benutzerschnittstellenelemente und eines oder mehrere Kommunikationselemente oder Kombinationen davon einschließen.
In einer oder mehreren Ausführungsformen kann die Hostvorrichtung 130 eine zentrale Verarbeitungseinheit (CPU) 140, Flash 136 (d. h. Flash-Speicher), CPU-Schnittstelle 134, RAM 146, Eingabe/Ausgabe (I/O) -Anschlüsse 132 und Peripheriegeräte 148 einschließen. Flash 136 kann zum Beispiel ein Programmspeicher sein und verwendet werden, um Computeranweisungen, Datenstrukturen und andere Informationen zum Durchführen einer großen Vielfalt von Aufgaben zu halten, einschließlich des Durchführens von Ausführungsformen der vorliegenden Offenbarung, die hierin gemeinsam als „Firmware“ bezeichnet werden. Beispielhaft kann Firmware einen Betriebscode und einen Bootcode einschließen. Als weiteres Beispiel kann der Betriebscode Code für ein integriertes eingebettetes System, ein Betriebssystem, einen Betriebssystemlader, individuell installierte Anwendungen und Kombinationen davon einschließen. Flash 136 ist ein nicht einschränkendes Beispiel eines nichtflüchtigen Speichers, wobei es sich versteht, dass jeder nichtflüchtige Speicher anstelle eines Flash-Speichers verwendet werden kann, einschließlich siliciumnitridbasierter Charge-Trap-Vorrichtungen und resistiver Speicher, ohne den Umfang dieser Offenbarung zu überschreiten, ohne darauf beschränkt zu sein. RAM 146 kann von CPU 140 in Verbindung mit der Durchführung von Berechnungen und anderen Operationen an Daten verwendet werden, einschließlich der Durchführung von Ausführungsformen der vorliegenden Offenbarung.
Die CPU 140 kann konfiguriert sein, um eine große Vielfalt von Software auszuführen, wie Betriebssysteme und/oder Anwendungen, einschließlich Computeranweisungen zum Durchführen aller oder von Teilen von Ausführungsformen der vorliegenden Offenbarung. Die CPU 140 kann ein Einzel- oder Mehrkernprozessor sein, und der Kern oder die Kerne können eine beliebige Kombination aus spezifischem Zweck (z. B. DSP oder ASIC, ohne darauf beschränkt zu sein) und allgemeinem Zweck sein, konfiguriert und/oder programmiert, um eine oder mehrere der in dieser Offenbarung beschriebenen Funktionen durchzuführen. In Mehrkern-Ausführungsformen können die Kerne unabhängig und wechselseitig arbeiten, einschließlich, ohne darauf beschränkt zu sein, in einer Master-Slave-Anordnung. Die CPU 140 schließt eine Steuereinheit 142 ein, welche die Steuerung der CPU 140 über die CPU-Schnittstelle 134 ermöglicht. Beispielhaft kann die Steuereinheit 142 verwendet werden, um die CPU 140 zu steuern, um Flash 136 und RAM 146 zu lesen und zu schreiben, um Software (ganz oder teilweise) auszuführen, die auf Flash 136 und/oder RAM 146 gespeichert ist, um E/A-Anschlüsse 132 der Hostvorrichtung 130 zu aktivieren/deaktivieren, um einen internen Zustand oder Variablen der CPU 140 zu untersuchen und/oder um Kontrollpunkte, Unterbrechungspunkte und Überwachungspunkte zu setzen. Solche Funktionen können für eine Vielfalt von Anwendungen verwendet werden, einschließlich Testen/Debuggen des Computersystems 100, Aktualisieren des Computersystems 100, Schützen des Computersystems 100 vor unsicherem Code und allgemeiner Durchführen von Ausführungsformen der Offenbarung, ohne darauf beschränkt zu sein. Jeder hierin verwendete Deskriptor, wie „Debug“, „Test“, „Verifizieren“ oder „Authentifizieren“, soll die allgemeine Anwendbarkeit einer solchen Schaltung nicht einschränken.
In dem in 1 gezeigten Beispiel kommuniziert die CPU 140 mit dem Flash 136, dem RAM 146 und den E/A-Anschlüssen 132 über eine Anzahl von Bussen, die in 1 als Bus 144 markiert sind. Beispielhaft kann Bus 144 verschiedene Busse einschließen, die eine oder mehrere Funktionen eines Adressbusses, eines Datenbusses, eines Peripheriebusses, eines Ereignisbusses, eines Testbusses und eines Programmbusses durchführen, ohne darauf beschränkt zu sein.
Die Steuereinheit 142 ist in der CPU 140 integriert und über die CPU-Schnittstelle 134 direkt zugänglich. Die CPU-Schnittstelle 134 kommuniziert mit den E/A-Anschlüssen 132 über den Bus 144 und kommuniziert mit externen Vorrichtungen, wie der sicheren Vorrichtung 110 oder einem Host-Computer über die E/A-Anschlüsse 132. E/A-Anschlüsse 132 können eine Vielzahl von Eingangs- und Ausgangsanschlüssen einschließen, die in Hardware und/oder Software implementiert sind. In verschiedenen Ausführungsformen können E/A-Anschlüsse 132 E/A-Anschlüsse für allgemeine Zwecke und spezielle Zwecke (GPIO & SPIO) zum Senden und Empfangen von Nachrichten und Signalen, Software-Anschlüsse zum Kommunizieren mit der CPU-Schnittstelle 134, Anschlüsse zum Empfangen eines aktivierten Resets der sicheren Vorrichtung 110 vom Computersystem 100 und andere Anschlüsse einschließen.
Peripheriegeräte 148 sind so konfiguriert, dass sie eine Vielfalt von Unterstützungsfunktionen der Peripheriegeräte in Verbindung mit und/oder unabhängig von der CPU 140 durchführen, einschließlich zum Beispiel analoger Ein- und Ausgabe, serieller Ein-/Ausgabe, Zeitgebern und Schwellenwerterfassungsschaltungen. Obwohl in 1 als ein eigenes Modul gezeigt, können einer oder mehrere Anschlüsse von den E/A-Anschlüssen 132 als ein Peripheriegerät 148 implementiert sein, zum Beispiel kann GPIO als ein Peripheriegerät 148 implementiert sein. In einer oder mehreren Ausführungsformen können die Peripheriegeräte 148 ein Peripheriegerät einschließen, das so konfiguriert ist, dass es die CPU 140 in einen Reset-Modus versetzt und/oder darin hält, wodurch die CPU 140 nicht in der Lage ist, den „normalen“ Betrieb zu starten. Während zum Beispiel in einem Reset-Modus die CPU 140 keine Speicheradresse einer ersten Anweisung in einen Programmzähler lädt oder als ein anderes Beispiel keine erste Anweisung an einer Speicheradresse von Flash 136 abruft. Solch ein Peripheriegerät kann die CPU 140 als Reaktion auf das Erfassen des Einschaltens des Computersystems 100 und/oder der CPU 140 oder das Erfassen einer Bedingung, die wie ein Einschalten des Computersystems 100 behandelt wird, wie ein Reset, das durch Bestätigen eines Hardwareeingangs der E/A-Anschlüsse 132 bewirkt wird, in einen Reset-Modus versetzen und/oder darin halten.
In einer oder mehreren Ausführungsformen schließt die sichere Vorrichtung 110 die Schaltung für vertrauenswürdige Sequenzen 112, die Kryptografie-(Krypto)schaltung 114, ROM 116 und E/A-Anschlüsse 118 ein. Die Schaltung für vertrauenswürdige Sequenzen 112 kann im Allgemeinen so konfiguriert sein, dass sie Funktionen und andere Operationen zum Verifizieren von Bootcode und/oder Firmware gemäß Ausführungsformen dieser Offenbarung durchführt. Die Kryptoschaltung 114 kann im Allgemeinen so konfiguriert sein, dass sie asymmetrische und/oder kryptografische Operationen wie Signaturvalidierung, MAC-Erzeugung/Validierung, Hash-Digest-Berechnungsverschlüsselung/-entschlüsselung oder andere Operationen unter Verwendung gespeicherter öffentlicher, privater oder geheimer Schlüssel gemäß Ausführungsformen dieser Offenbarung durchführt. Genauer kann die Kryptoschaltung 114 so konfiguriert sein, dass sie einen oder mehrere öffentliche und/oder private Kryptografiedienste bereitstellt, um die Vorrichtung 110 und/oder das Computersystem 100 mehr allgemein zu sichern. In einer oder mehreren Ausführungsformen kann die Kryptoschaltung 114 eine analoge Schaltung, eine integrierte Schaltung, Software oder Kombinationen davon sein. Der ROM 116 kann Daten und Code speichern, die beim Durchführen einer oder mehrerer Ausführungsformen dieser Offenbarung verwendet werden, einschließlich zum Beispiel einer vertrauenswürdigen Kopie von Bootcode.
In dem in 1 gezeigten Beispiel sind die E/A-Anschlüsse 118 der sicheren Vorrichtung 110 und E/A-Anschlüsse 132 der Hostvorrichtung 130 durch eine bidirektionale Verbindung 122 operativ gekoppelt, um die Übertragung von Nachrichten und Daten zwischen den zwei Vorrichtungen zu erleichtern, einschließlich des Durchführens einer oder mehrerer Ausführungsformen der Offenbarung.
2 zeigt ein vereinfachtes Blockdiagramm eines beispielhaften Systems 200 zum Unterstützen eines sicheren Boot-Prozesses an einer Hostvorrichtung eines Rechensystems gemäß einer oder mehreren Ausführungsformen der Offenbarung. In Ausführungsformen, die in 2 gezeigt sind, wird ein Programm, das konfiguriert ist, um zu verifizieren, dass die MCU-Anwendung 234 sicher ist, gespeichert und der MCU 230 durch die sichere Vorrichtung 210 bereitgestellt.
In einer oder mehreren Ausführungsformen schließt die MCU 230 einen nativen Bootcode 236 ein, der im Programmspeicher 232 gespeichert ist. In einer oder mehreren Ausführungsformen darf nativer Bootcode 236 nicht so konfiguriert sein, dass er verifiziert, dass die MCU-Anwendung 234 sicher ist, oder darf nicht vertrauenswürdig sein, um zu verifizieren, dass die MCU-Anwendung 234 sicher ist. Die sichere Vorrichtung 210 weist einen Low-Level-Bootcode 218-Bootcode auf, der im persistenten Speicher 216 gespeichert ist, und stellt eine Kopie 220 des Low-Level-Bootcodes 218 (d. h. ein Abbild des Low-Level-Bootcodes 218) an die MCU 230 bereit. In einer oder mehreren Ausführungsformen kann der Low-Level-Bootcode 218 ein Programm sein, das, wenn es von einem Prozessor, wie einer CPU 248, ausgeführt wird, so konfiguriert ist, dass es verifiziert, dass die Firmware sicher ist, einschließlich des Verifizierens, dass die MCU-Anwendung 234 sicher ist. Anders gekennzeichnet, kann ein Low-Level-Bootcode 218 so konfiguriert sein, dass er mindestens einige Operationen eines sicheren Boot-Prozesses durchführt, und in diesem Beispiel Operationen durchführt, für deren Durchführung entweder der native Bootcode 236 nicht konfiguriert ist oder dieser nicht vertrauenswürdig ist, um den nativen Bootcode 236 durchzuführen. Beispielhaft kann der Low-Level-Bootcode 218 konfiguriert sein, um zu verifizieren, dass der native Bootcode 236 sicher ist, die MCU-Anwendung 234 sicher ist oder zu verifizieren, dass sowohl der native Bootcode 236 als auch die MCU-Anwendung 234 sicher sind.
In einer oder mehreren Ausführungsformen kann Low-Level-Bootcode 218 so konfiguriert sein, dass er es einem Prozessor ermöglicht, Operationen zum Verifizieren durchzuführen, dass Firmware sicher ist, sowie Daten in Bezug auf das Durchführen dieser Operationen einschließen, einschließlich, eines oder mehrerer von Digests, Hash-Funktionen und öffentlichen und/oder privaten Verschlüsselungsschlüsseln, ohne darauf beschränkt zu sein.
In einer oder mehreren Ausführungsformen kann die Schaltung für vertrauenswürdige Sequenzen 214 im Allgemeinen so konfiguriert sein, dass sie einen eingeschränkten Betriebsmodus bei MCU 230 (z. B. einen Reset-Modus, ohne darauf beschränkt zu sein) initiiert, um eine Kopie 220 des Low-Level-Bootcodes 218 an die MCU 230 zu senden und die Ausführung von Kopie 220 des Low-Level-Bootcodes 218 bei der MCU 230 zu initiieren. In einer Ausführungsform kann die Schaltung für vertrauenswürdige Sequenzen 214 so konfiguriert sein, dass sie die CPU 248 anweist, die Ausführung der Kopie 220 des Low-Level-Bootcodes 218 bei Eintritt in einen bekannten Zustand zu initiieren und dann das Reset 244 zu deaktivieren, wodurch die MCU 230 in einen solchen bekannten Zustand, z. B. einen normalen Betriebsmodus, wie ein normales Booten oder Reset, versetzt wird. Nachdem die MCU 230 in den resetinitiierten (d. h. durch Deaktivieren des Resets 244) bekannten Zustand eintritt, versucht das Kopieren 220 des Low-Level-Bootcodes 218, die MCU-Anwendung 234 und/oder den nativen Bootcode 236 ohne weitere Hilfe von der sicheren Vorrichtung 210 zu verifizieren.
In einer anderen Ausführungsform kann die Schaltung für vertrauenswürdige Sequenzen 214 so konfiguriert sein, dass sie Verifizierungsergebnisse 246 empfängt und verarbeitet, die von der Kopie 220 des Low-Level-Bootcodes 218 empfangen werden, der bei der MCU 230 ausgeführt wird und von der Debug-Funktionsschaltung 242 als Nachrichten 222 an die Schaltung für vertrauenswürdige Sequenzen 214 übertragen wird. Die Schaltung für vertrauenswürdige Sequenzen 214 kann konfiguriert sein, um den Austritt aus dem initiierten eingeschränkten Betriebsmodus an der MCU 230 als Reaktion auf das Verifizierungsergebnis 246 zu steuern. In einer oder mehreren Ausführungsformen kann das Verifizierungsergebnis 246 im Allgemeinen angeben, ob die Verifizierung von Firmware erfolgreich war oder fehlgeschlagen ist. In einer oder mehreren Ausführungsformen kann das Verifizierungsergebnis 246 angeben, ob der native Bootcode 236 und/oder die MCU-Anwendung 234 als sicher verifiziert wurden.
Wenn die Verifizierung fehlgeschlagen ist, kann das Verifizierungsergebnis 246 in einigen Ausführungsformen eine Angabe der Ursache der fehlgeschlagenen Verifizierung einschließen, wie einen Fehlercode.
In einer oder mehreren Ausführungsformen kann die Schaltung für vertrauenswürdige Sequenzen 214 operativ mit dem Reset 244 und der Debug-Funktionsschaltung 242 der MCU 230 operativ gekoppelt sein, zum Beispiel durch die E/A-Anschlüsse 118 und die E/A-Anschlüsse 132 von 1. Das Reset 244 kann ein Peripheriegerät der MCU 230 sein, so dass, wenn ein Hardwareeingang für Reset 244 aktiviert wird, das Reset 244 so konfiguriert ist, dass es eine Hardwarebedingung an der MCU 230 auslöst, die bewirkt, dass MCU 230 in einen eingeschränkten Modus eintritt, zum Beispiel in einen in dieser Offenbarung beschriebenen Reset-Modus. Während die MCU 230 im eingeschränkten Modus ist, kann die CPU 248 möglicherweise nicht in der Lage sein, Folgendes durchzuführen: unabhängiges Initiieren der Ausführung von lokaler Software und/oder Empfangen oder Senden von Daten über einige Eingangs- und Ausgangsanschlüsse oder Antworten auf Signale, die an einigen Eingangsanschlüssen empfangen werden. Die CPU 248 kann jedoch angewiesen werden, Software über die Debug-Funktionsschaltung 242 auszuführen, zum Beispiel durch die Schaltung für vertrauenswürdige Sequenzen 214 unter Verwendung der Debug-Funktionsschaltung 242.
Während sich die MCU 230 im eingeschränkten Modus befindet, kann die Schaltung für vertrauenswürdige Sequenzen 214 über die Debug-Funktionsschaltung 242 auf SRAM 238 und genauer auf den Coderaum 240 zugreifen. Ferner kann die Schaltung für vertrauenswürdige Sequenzen 214 die Debug-Funktionsschaltung 242 verwenden, um die Kopie 220 des Low-Level-Bootcodes 218 in den Coderaum 240 zu verschieben, kann die CPU 248 anweisen, den im Coderaum 240 gespeicherten Code auszuführen (d. h. die Kopie 220 des Low-Level-Bootcodes 218) und das Verifizierungsergebnis 246 empfangen.
In einer oder mehreren Ausführungsformen kann die Schaltung für vertrauenswürdige Sequenzen 214 so konfiguriert sein, dass sie die Debug-Funktionsschaltung 242 verwendet, um die CPU 248 anzuweisen, nativen Bootcode 236 auszuführen, um einige Systeminitialisierungsfunktionen durchzuführen. Genauer gesagt kann die Schaltung für vertrauenswürdige Sequenzen 214 die CPU 248 anweisen, eine begrenzte Anzahl von Funktionen des nativen Bootcodes 236 in Bezug auf die Systeminitialisierung auszuführen. In einer Ausführungsform kann die Schaltung für vertrauenswürdige Sequenzen 214 die Kopie 220 des Low-Level-Bootcodes 218 an die MCU 230 übertragen, nachdem alle Funktionen, die von Software auf der MCU 230 (z. B. durch den nativen Bootcode 236, ohne darauf beschränkt zu sein) durchgeführt werden, falls vorhanden, abgeschlossen sind, so dass die Integrität der Kopie 220 des Low-Level-Bootcodes 218 nicht beeinträchtigt wird.
In einer oder mehreren Ausführungsformen kann die Schaltung für vertrauenswürdige Sequenzen 214 so konfiguriert sein, dass sie die Debug-Funktionsschaltung 242 verwendet, um die CPU 248 anzuweisen, Code (d. h. die Kopie 220 des Low-Level-Bootcodes 218 auszuführen) an Adressräumen auszuführen, die dem Coderaum 240 entsprechen, um die Kopie 220 des Low-Level-Bootcodes 218 auszuführen und die MCU-Anwendung 234 zu verifizieren.
In einer oder mehreren Ausführungsformen kann die Debug-Funktionsschaltung 242 eine Hardware- und/oder Software-CPU-Schnittstelle und/oder Steuereinheit zum Kommunizieren mit und Steuern der CPU 248 sein, zum Beispiel gemäß einem Joint Test Action Group (JTAG)-Standard, oder eine Spezialhardware-/Software-CPU-Schnittstelle und/oder Steuereinheit zum Ausführen derselben. Obwohl verschiedene Ausführungsformen dieser Offenbarung eine Debug-Funktionsschaltung als „On-Chip“ zeigen oder beschreiben können, ist diese Offenbarung nicht auf eine On-Chip-Implementierung beschränkt, zum Beispiel würde ein Fachmann verstehen, dass schaltkreisinterne Techniken, bei denen eine CPU außerhalb des Chips emuliert wird, ebenfalls verwendet werden können und offenbarte Ausführungsformen darauf anwendbar sind.
In dem in 2 gezeigten beispielhaften System 200 schließt die sichere Vorrichtung 210 die Kryptografieeinheit 212 zum Verschlüsseln und Entschlüsseln von Nachrichten 222 zwischen der sicheren Vorrichtung 210 und der MCU 230 ein. Die Verschlüsselung und Entschlüsselung von Nachrichten 222 zwischen einer sicheren Vorrichtung 210 und einer MCU 230 ist nicht unbedingt erforderlich, so dass in einigen Ausführungsformen des beispielhaften Systems 200 speziell in Betracht gezogen wird, dass die Kryptografieeinheit 212 weggelassen werden kann.
3 zeigt einen Prozess 300 zur sicheren Bootunterstützung, wobei eine sichere Vorrichtung 302 einen Low-Level-Bootcode für eine Hostvorrichtung bereitstellt, die durch die MCU 304 dargestellt wird, wobei der Low-Level-Bootcode konfiguriert ist, um zu verifizieren, ob Firmware der Hostvorrichtung der MCU 304 gemäß einer oder mehreren Ausführungsformen der Offenbarung sicher ist. In dem von 3 in Betracht gezogenen Beispiel wurde eine MCU-Anwendung bereits an der MCU 304 empfangen und in den Programmspeicher geladen, so dass, während Schritte zum Verbinden mit einer Quelle und zum Herunterladen einer MCU-Anwendung nicht unter Bezugnahme auf 3 beschrieben werden, die Integration solcher Schritte in offenbarte Ausführungsformen speziell in Betracht gezogen wird.
In Operation 310 aktiviert und hält die sichere Vorrichtung 302 einen Reset an der MCU 304. In Operation 312 tritt die MCU 304 als Reaktion darauf, dass die sichere Vorrichtung 302 einen Reset aktiviert, in einen Reset-Modus ein, und während der Reset aktiviert ist, wird in Operation 312 die MCU 304 im Reset-Modus gehalten und daran gehindert, Software alleine auszuführen. In der optionalen Operation 314 wird eine Debug-Funktion (z. B. Debug-Funktionsschaltung 242, ohne darauf beschränkt zu sein) der MCU 304 authentifiziert, zum Beispiel unter Verwendung einer digitalen Signatur, die unter Verwendung von Public-Key-Kryptografietechniken erzeugt wird. In einer oder mehreren Ausführungsformen kann das Authentifizieren der Debug-Funktion dazu dienen, um zu bestätigen, dass die Debug-Funktion nicht modifiziert wurde oder dass die sichere Vorrichtung 302 nicht mit einer unzulässigen MCU gekoppelt wurde. In Ausführungsformen, in denen die Debug-Funktion hauptsächlich Hardware und/oder Software ist, die in einem nichtflüchtigen Speicher gespeichert ist, und die sichere Vorrichtung 302 nicht von der MCU 304 trennbar ist, kann ein Schritt des Authentifizierens einer Debug-Funktion weggelassen werden.
In Operation 316 wird Low-Level-Bootcode aus dem persistenten Speicher der sicheren Vorrichtung 302 abgerufen. In Operation 318 wird der abgerufene Low-Level-Bootcode (oder eine Kopie davon) unter Verwendung einer Debug-Funktion von MCU 304 an MCU 304 gesendet. In Operation 320 empfängt die MCU 304 den gesendeten Low-Level-Bootcode, und der Low-Level-Bootcode wird im SRAM gespeichert. In Operation 322 verwendet die sichere Vorrichtung 302 die Debug-Funktion der MCU 304, um die MCU 304 anzuweisen, den im SRAM gespeicherten Low-Level-Bootcode auszuführen. In Operation 324 wird eine versuchte Verifizierung mindestens eines Teils der MCU-Anwendung 234 durch den Low-Level-Bootcode durchgeführt, und in Operation 326 wird ein Verifizierungsergebnis über die Debug-Funktion der MCU 304 an die sichere Vorrichtung 302 gesendet. In Operation 328 empfängt die sichere Vorrichtung 302 das Verifizierungsergebnis über die Debug-Funktion der MCU 304. Wenn die Verifizierung fehlgeschlagen ist, aktiviert die sichere Vorrichtung 302 im Betrieb 330 den Reset weiter, bis erkannt wird, dass vertrauenswürdiger Code auf der MCU 304 installiert wurde. In einer Ausführungsform kann die sichere Vorrichtung 302 die MCU 304 wiederholt neu starten, bis der Low-Level-Bootcode erfasst, dass die MCU-Anwendung sicher ist (z. B. sendet der Low-Level-Bootcode Verifizierungsergebnisse der sicheren Vorrichtung 302, die angeben, dass der Betriebscode sicher ist). Wenn die Verifizierung erfolgreich war, dann stoppt in Operation 332 die sichere Vorrichtung 302 das Aktivieren des Resets, und in Operation 334 tritt die MCU 304 in einen bekannten Betriebszustand ein, aus dem sie die mindestens teilweise verifizierte MCU-Anwendung von Operation 324 ausführen kann.
In einer oder mehreren Ausführungsformen kann ein Low-Level-Bootcode von einer sicheren Vorrichtung konfiguriert sein, um zu versuchen, eine MCU-Anwendung, einen nativen Bootcode oder beides zu verifizieren. In Ausführungsformen, in denen ein Low-Level-Bootcode versucht zu verifizieren, dass ein nativer Bootcode sicher ist, kann, wenn ein nativer Bootcode verifiziert wird, der verifizierte native Bootcode ausgeführt werden, um zu verifizieren, dass andere Firmware sicher ist, einschließlich einer MCU-Anwendung.
Abhängig von einer Implementierung kann eine neue MCU-Anwendung nativen Bootcode an einer MCU überschreiben oder nicht (d. h. der native Bootcode kann bleiben). In jedem Fall kann in einer oder mehreren Ausführungsformen, wenn ein Low-Level-Bootcode, der von einer vertrauenswürdigen Vorrichtung geladen wird, versucht zu verifizieren, dass ein MCU-Anwendungscode sicher ist, dieser so konfiguriert sein, dass er sowohl den MCU-Anwendungscode als auch den nativen Bootcode zusammen oder getrennt verifiziert. Zum Beispiel kann der Low-Level-Bootcode 218 die MCU-Anwendung 234 und den nativen Bootcode 236 (2) verwenden, um eine digitale Signatur zum Verifizieren der Sicherheit zu erstellen.
Eine oder mehrere Ausführungsformen beziehen sich im Allgemeinen auf Systeme und Verfahren zur sicheren Bootunterstützung, wobei ein natives Programm Sicherheitsdaten für Firmware erzeugt und eine Schaltung an einer sicheren Vorrichtung die Sicherheitsdaten mit vertrauenswürdigen Sicherheitsdaten vergleicht, die an der sicheren Vorrichtung gespeichert sind, um zu bestimmen, ob die Firmware sicher und vertrauenswürdig ist.
4 zeigt ein vereinfachtes Blockdiagramm eines beispielhaften Systems 400 zum Unterstützen eines sicheren Boot-Prozesses an einer Hostvorrichtung eines Rechensystems, das hier als MCU 430 implementiert ist, gemäß einer oder mehreren Ausführungsformen der Offenbarung. In den Ausführungsformen, die in 4 gezeigt sind, schließt die MCU 430 nativen Bootcode 438 ein, der im Programmspeicher 432 gespeichert ist, und nativer Bootcode 438 ist so konfiguriert, dass er Sicherheitsdaten generiert, die mindestens teilweise auf der MCU-Anwendung 434 basieren. Sicherheitsdaten können zum Beispiel digitale Signaturen, die unter Verwendung von Verschlüsselungstechniken mit Public/Private-Key-Verschlüsselungstechniken generiert werden, Digests, die unter Verwendung von Hash-Funktionen generiert werden, und MAC-Codes einschließen. Insbesondere ist in den Ausführungsformen, die in 4 gezeigt sind, der native Bootcode 438 nicht so konfiguriert, oder eine solche Funktionalität ist nicht so vertrauenswürdig, dass sie die Gültigkeit von Sicherheitsdaten bestätigen und/oder eine endgültige Entscheidung treffen, dass die MCU-Anwendung 434 sicher ist. Genauer gesagt hat der native Bootcode 438 in einer oder mehreren Ausführungsformen keine vertrauenswürdigen Digests 420, die auf dem persistenten Speicher 418 der sicheren Vorrichtung 410 gespeichert sind, oder hat Zugriff auf diese. In dem in 4 gezeigten Beispiel ist der native Bootcode 438 so konfiguriert, dass er den Digest 446 von der MCU-Anwendung 434 erhält, die Signatur 448 von der MCU-App-Signatur 436 generiert und den Digest 446 und die Signatur 448 über die Debug-Funktionsschaltung 442 als gesendete Nachrichten 422 an die Schaltung für vertrauenswürdige Sequenzen 416 sendet, er verifiziert jedoch nicht, ob der Digest 446 oder die Signatur 448 sicher sind.
In einer alternativen Ausführungsform kann die Schaltung für vertrauenswürdige Sequenzen 416 so konfiguriert sein, dass sie den Digest 446 und die Signatur 448 von einem Ort im Programmspeicher 432 oder einem anderen Speicher, an dem er durch den nativen Bootcode 438 gespeichert wurde, mittels der Debug-Funktionsschaltung 442 liest. Mit anderen Worten wird in einigen Ausführungsformen in Betracht gezogen, dass nativer Bootcode 438 konfiguriert sein kann, um ein Digest 446 und/oder eine Signatur 448 an die sichere Vorrichtung 410 zu senden, und in einigen Ausführungsformen wird in Betracht gezogen, dass die Schaltung für vertrauenswürdige Sequenzen 416 konfiguriert sein kann, um die Debug-Funktionsschaltung 442 zu verwenden, um einen Digest 446 und/oder eine Signatur 448 von der MCU 430 abzurufen. Zum Beispiel kann die Schaltung 416 der vertrauenswürdigen Sequenz Unterbrechungspunkte in den nativen Bootcode 438 unter Verwendung der Debug-Funktionsschaltung 442 einfügen, die Ausführung des nativen Bootcodes 438 stoppen, sobald der Digest 446 und/oder die Signatur 448 berechnet sind, und die berechneten Werte abrufen.
In einer oder mehreren Ausführungsformen kann die Schaltung für vertrauenswürdige Sequenzen 416 konfiguriert sein, um das Reset 444 der MCU 430 über das Resetsignal 424 zu aktivieren (das Reset 444 ist konfiguriert, um zu bewirken, dass die MCU 430 in einen eingeschränkten Betriebsmodus versetzt wird), und um die Debug-Funktionsschaltung 442 zu verwenden, um die CPU 440 anzuweisen, nativen Bootcode 438 auszuführen und den Digest 446 und die Signatur 448 zu empfangen (oder abzurufen). In einer oder mehreren Ausführungsformen kann die Schaltung für vertrauenswürdige Sequenzen 416 im Allgemeinen konfiguriert sein, um zu verifizieren, dass die MCU-Anwendung 434 unter Verwendung von einem oder mehreren von Digest 446 und Signatur 448 sicher ist. Genauer gesagt kann die Schaltung für vertrauenswürdige Sequenzen 416 konfiguriert sein, um in Verbindung mit der Kryptografieeinheit 414 eine Quelle der MCU-Anwendung 434 unter Verwendung der Signatur 448 zu authentifizieren und die Integrität der MCU-Anwendung 434 unter Verwendung des vertrauenswürdigen Digest 420 zu bestätigen.
In einer oder mehreren Ausführungsformen kann die Kryptografieeinheit 414 im Allgemeinen konfiguriert sein, um die Signatur 448 unter Verwendung von Public- und/oder Private-Key-Kryptografietechniken zu verifizieren. In dem beispielhaften System 400, das in 4 gezeigt ist, schließt die sichere Vorrichtung 410 den Public Key 412 ein, und die Kryptografieeinheit 414 verwendet den Public Key 412, um die Signatur 448 zu decodieren. Die Schaltung für vertrauenswürdige Sequenzen 416 kann die Identität einer Quelle der MCU-Anwendung 434 als Reaktion auf die decodierte Signatur 448 verifizieren und bestätigen, dass die MCU-Anwendung 434 einem berechtigten Teilnehmer zugeordnet ist. Die Schaltung für vertrauenswürdige Sequenzen 416 kann bestätigen, dass der Digest 446 mit einem der vertrauenswürdigen Digests 420 übereinstimmt, und als Reaktion darauf bestätigen, dass die Integrität der MCU-Anwendung 434 bestätigt wird.
5 zeigt einen Prozess 500 zur sicheren Bootunterstützung, wobei eine sichere Vorrichtung 502 eine Verifizierung eines durch einen Bootcode erzeugten Digests bei der Implementierung der MCU 504 einer Hostvorrichtung gemäß einer oder mehreren Ausführungsformen der Offenbarung durchführt.
In dem in 5 in Betracht gezogenen Beispiel wurde bereits eine neue MCU-Anwendung an der MCU 504 empfangen und in den Programmspeicher geladen, so dass, während Schritte zum Verbinden mit einem Host und zum Herunterladen der MCU-Anwendung nicht ausführlich beschrieben sind, Ausführungsformen einschließlich solcher Schritte speziell in Betracht gezogen werden.
In Operation 510 aktiviert und hält die sichere Vorrichtung 502 einen Reset an der MCU 504. In Operation 512 tritt die MCU 504 als Reaktion darauf, dass die sichere Vorrichtung 502 den Reset aktiviert, in einen Reset-Modus ein, und während der Reset aktiviert ist, wird die MCU 504 im Reset-Modus gehalten und daran gehindert, Software alleine auszuführen. In der optionalen Operation 514 wird eine Debug-Funktion (z. B., Debug-Funktionsschaltung 442, ohne darauf beschränkt zu sein) der MCU 504 authentifiziert, zum Beispiel unter Verwendung einer digitalen Signatur, die unter Verwendung von Public-Key-Kryptografietechniken generiert wird. Wie bei Prozess 300 (3) kann in einigen Ausführungsformen die Authentifizierung einer Debug-Funktion weggelassen werden. In Operation 516 verwendet die sichere Vorrichtung 502 eine Debug-Funktion, um MCU 504 anzuweisen, einen unter MCU 504 gespeicherten Bootcode auszuführen. In Operation 518 erzeugt der Bootcode einen Digest und eine Signatur von einer MCU-Anwendung, die unter MCU 504 gespeichert ist. In einer oder mehreren Ausführungsformen kann die Signatur eine MCU-Signatur sein, die in der MCU-Anwendung eingeschlossen ist oder durch den Bootcode erstellt wird. In Operation 520 sendet die MCU 504 die Signatur und den Digest unter Verwendung der Debug-Funktion an das sichere Vorrichtung 502.
In Operation 522 empfängt die sichere Vorrichtung 502 die Signatur und den Digest über die Debug-Funktion der MCU. In Operation 524 versucht die sichere Vorrichtung 502, die empfangene Signatur zu authentifizieren. In Operation 526 versucht die sichere Vorrichtung 502, den empfangenen Digest zu verifizieren. In einer Ausführungsform verifiziert die sichere Vorrichtung 502 den Digest unter Verwendung eines vertrauenswürdigen Digests, der lokal gespeichert ist (d. h. in einem persistenten Speicher der sicheren Vorrichtung 502 gespeichert ist). In einer Ausführungsform versucht die sichere Vorrichtung 502, den Digest nur nach erfolgreicher Authentifizierung der Signatur zu verifizieren. Wenn die Signatur nicht authentisch ist oder der Digest nicht verifiziert wird, aktiviert die sichere Vorrichtung 502 in Operation 528 den Reset, bis sie erfasst, dass vertrauenswürdiger Code an der MCU 504 installiert wurde. Wenn die Signatur authentisch ist und der Digest verifiziert wird, stoppt die sichere Vorrichtung 502 in Operation 530 das Aktivieren des Resets, und in Operation 532 tritt die MCU 504 in einen bekannten Betriebszustand ein, aus dem sie die neue MCU-Anwendung ausführen kann, die nun verifiziert wurde.
6 zeigt ein vereinfachtes Blockdiagramm eines beispielhaften Systems 600 zum Unterstützen eines sicheren Boost-Prozesses an einer Hostvorrichtung eines Rechensystems, das hier als MCU 630 implementiert ist, gemäß einer oder mehreren Ausführungsformen der Offenbarung. In Ausführungsformen, die in 6 gezeigt sind, ist ein nativer Bootcode 636, der in dem Programmspeicher 632 bei der MCU 630 gespeichert ist, so konfiguriert, dass er verifiziert, dass die MCU-Anwendung 634 sicher ist, da der native Bootcode 636 jedoch auf irgendwie beeinträchtigt sein kann, ist die sichere Vorrichtung 610 konfiguriert, um zu verifizieren, dass der native Bootcode 636 unter Verwendung des vertrauenswürdigen Bootcodes 618, der in dem persistenten Speicher 616 der sicheren Vorrichtung 610 gespeichert ist, sicher ist. In einer oder mehreren Ausführungsformen ist die Schaltung für vertrauenswürdige Sequenzen 614 so konfiguriert, dass sie ein Resetsignal 622 zu Reset 642 aktiviert, und das Reset 642 ist so konfiguriert, dass es durch Versetzen der MCU 630 in einen eingeschränkten Betriebsmodus reagiert und eine Kopie 644 des nativen Bootcodes 636 unter Verwendung der Debug-Funktionsschaltung 640 abruft, zum Beispiel unter Verwendung von Sende- und Empfangsnachrichten 620. Die Schaltung 614 für vertrauenswürdige Sequenzen ist konfiguriert, um zu bestimmen, ob die abgerufene Kopie 644 des Bootcodes 636 mit dem vertrauenswürdigen Bootcode 618 übereinstimmt. Wenn die abgerufene Kopie 644 des nativen Bootcodes 636 mit dem vertrauenswürdigen Bootcode 618 übereinstimmt, dann ist der Bootcode 636 erfolgreich verifiziert und die Schaltung 614 für die vertrauenswürdige Sequenz bestimmt, dass der Bootcode 636 sicher ist.
In dem beispielhaften System 600, das in 6 gezeigt ist, wird der vertrauenswürdige Bootcode 618 in dem persistenten Speicher 616 der sicheren Vorrichtung 610 gespeichert, aber andere Sicherheitsinformationen können verwendet werden, um den nativen Bootcode 636 zusätzlich oder alternativ zu dem vertrauenswürdigen Bootcode 618 zu verifizieren. In einer Ausführungsform können vertrauenswürdige Sicherheitsdaten, wie eine vertrauenswürdige digitale Signatur, ein vertrauenswürdiger Digest oder ein vertrauenswürdiger MAC-Code, im persistenten Speicher 616 gespeichert werden.
Wie in dieser Offenbarung beschrieben, kann in einigen Fällen ein Risiko bestehen, dass die Debug-Funktionsschaltung, wie die Debug-Funktionsschaltung 640, beeinträchtigt wird. Wenn beeinträchtigt, kann die Debug-Funktionsschaltung 640 die Kopie 644 des nativen Bootcodes 636 modifizieren, bevor sie an die sichere Vorrichtung 610 gesendet wird, um Unterschiede zwischen dem nativen Bootcode 636 und dem vertrauenswürdigen Bootcode 618 zu verdecken. So kann in einer oder mehreren Ausführungsformen die Schaltung 614 mit vertrauenswürdiger Sequenz in Verbindung mit der Kryptografieeinheit 612 versuchen, die Debug-Funktionsschaltung 640 zu authentifizieren, zum Beispiel unter Verwendung verschiedener Public- und/Private-Key-Verschlüsselungstechniken, und versucht nur den nativen Bootcode 636 als Reaktion auf die erfolgreiche Authentifizierung der Debug-Funktionsschaltung 640 zu verifizieren. Beispielhaft kann die Schaltung für vertrauenswürdige Sequenzen 614 eine Signatur von der Debug-Funktionsschaltung 640 anfordern und empfangen (z. B. unter Verwendung der Nachrichten 620, ohne darauf beschränkt zu sein) und die empfangene Signatur unter Verwendung eines Public Keys authentifizieren.
Nach erfolgreicher Verifizierung des nativen Bootcodes 636 kann die Schaltung für vertrauenswürdige Sequenzen 614 so konfiguriert sein, dass sie die Debug-Funktionsschaltung 640 verwendet, um die CPU 638 anzuweisen, den Bootcode 636 auszuführen, wenn sie einen eingeschränkten Modus verlässt, und dann das Aktivieren des Einschalt-Resetsignals 622 beim Reset 642 zu stoppen. Die CPU 638 führt nativen Bootcode 636 bei Deaktivierung des Resetsignals 622 an dem Reset 642 aus, und der native Bootcode 636 versucht zu verifizieren, ob die MCU-Anwendung 634 sicher ist.
7 zeigt einen Prozess 700 zur sicheren Bootunterstützung, wobei eine sichere Vorrichtung 702 eine Verifizierung eines Bootcodes einer Hostvorrichtung, implementiert als MCU 704, gemäß einer oder mehreren Ausführungsformen der Offenbarung durchführt.
Im betrachteten Beispiel wurde eine neue MCU-Anwendung bereits an der MCU 704 empfangen und in den Programmspeicher geladen, so dass, während Schritte zum Verbinden mit einer Quelle neuer Firmware und zum Herunterladen der MCU-Anwendung nicht ausführlich beschrieben werden, diese speziell in Betracht gezogen werden.
In Operation 710 aktiviert und hält die sichere Vorrichtung 702 einen Reset bei MCU 704. In Operation 712 tritt die MCU 704 als Reaktion darauf, dass die sichere Vorrichtung 702 den Reset aktiviert, in einen Reset-Modus ein, und während der Reset aktiviert ist, wird die MCU 704 im Reset-Modus gehalten und daran gehindert, Software alleine auszuführen. In der optionalen Operation 714 wird eine Debug-Funktion der MCU 704 authentifiziert, zum Beispiel unter Verwendung einer digitalen Signatur, die unter Verwendung von Public-Key-Kryptologietechniken erzeugt wird. Wie bei Prozess 300 (3) und Prozess 500 (5) kann in einigen Ausführungsformen auf die Authentifizierung einer Debug-Funktion verzichtet werden. In Operation 716 verwendet die sichere Vorrichtung 702 eine Debug-Funktion, um die MCU 704 anzuweisen, eine Kopie des in der MCU 704 gespeicherten Bootcodes an die sichere Vorrichtung 702 zu senden. In Operation 718 liest die MCU 704 nativen Bootcode und sendet in Operation 720 eine Kopie des nativen Bootcodes über die Debug-Funktion an die sichere Vorrichtung 702. In Operation 722 empfängt die sichere Vorrichtung 702 die Kopie des Bootcodes über die Debug-Funktion und versucht, den nativen Bootcode der MCU 704 als Reaktion auf die Kopie des nativen Bootcodes und einen vertrauenswürdigen Bootcode, der lokal auf der sicheren Vorrichtung 702 gespeichert ist, zu verifizieren. In einer oder mehreren Ausführungsformen kann die Kopie des Bootcodes und des vertrauenswürdigen Bootcodes unter Verwendung einer beliebigen geeigneten Technik verglichen werden, einschließlich, aber nicht beschränkt auf, Bit-für-Bit-Vergleich oder unter Verwendung von Hashes. Wenn der Bootcode nicht erfolgreich verifiziert wird, dann hält die sichere Vorrichtung 702 in Operation 724 die MCU 704 weiterhin zurückgesetzt, bis sie erfasst, dass vertrauenswürdiger Bootcode an der MCU 704 installiert wurde. Wenn der native Bootcode der MCU in Operation 722 erfolgreich verifiziert wird, dann weist die sichere Vorrichtung 702 in Operation 726 die MCU 704 an, den nativen Bootcode beim Verlassen des Reset-Modus auszuführen, und deaktiviert den Reset an der MCU 704. In Operation 728 führt sich der Bootcode bei der MCU 704 aus, nachdem er den Reset-Modus verlassen hat, und versucht zu verifizieren, dass eine MCU-Anwendung sicher ist.
In einer oder mehreren Ausführungsformen kann ein Rechensystem so konfiguriert sein, das es als Reaktion auf eine Anzahl von Betriebsmodi arbeitet. Ein erster Modus kann Ausführungsformen entsprechen, die unter Bezugnahme auf 2 und 3 beschrieben werden, ein zweiter Modus kann Ausführungsformen entsprechen, die unter Bezugnahme auf 4 und 5 beschrieben werden, und ein dritter Modus kann Ausführungsformen entsprechen, die unter Bezugnahme auf 6 und 7 beschrieben werden. Mit anderen Worten kann ein sicheres Bootunterstützungssystem so konfiguriert sein, dass es eine sichere Bootunterstützung unter Verwendung eines Low-Level-Bootcodes durchführt, der von einer sicheren Vorrichtung gemäß einem ersten Betriebsmodus bereitgestellt wird, eine sichere Bootunterstützung unter Verwendung eines vertrauenswürdigen Digests, der durch einen nativen Bootcode generiert wird, gemäß einem zweiten Betriebsmodus durchführt, und eine sichere Bootunterstützung unter Verwendung eines verifizierten nativen Bootcodes, gemäß einem dritten Betriebsmodus durchführt.
Ein solches System kann so konfiguriert sein, dass es als Reaktion auf eine erkannte Moduseinstellung gemäß dem ersten, zweiten oder dritten Betriebsmodus arbeitet. In einigen Ausführungsformen kann ein Modus eines Systems mindestens teilweise basierend auf einem Kontext und spezieller einer potenziellen Beschädigung durch Sicherheitsbrüche in einem spezifischen Kontext eingestellt werden. Mit anderen Worten kann ein eingeschränkterer Betriebsmodus für Kontexte mit hohem Risiko verwendet werden, und ein weniger eingeschränkter Betriebsmodus kann für Kontexte mit niedrigem Risiko verwendet werden.
Beispielhaft kann eine Bootunterstützungsschaltung, die in einer medizinischen Vorrichtung oder autonomen Fahrzeugsteuerung verwendet wird, so konfiguriert sein, dass sie eine sichere Bootunterstützung unter Verwendung eines vertrauenswürdigen Digests durchführt, wenn Firmware an einem autorisierten Dienststandort oder unter Verwendung autorisierter Dienstausrüstung in einer Werkstatt oder einem Büro eines medizinischen Anbieters aktualisiert wird. Eine solche Bootunterstützungsschaltung kann konfiguriert sein, um eine sichere Bootunterstützung unter Verwendung eines Low-Level-Bootcodes durchzuführen und eine Authentifizierung der Debug-Funktionsschaltung zu erfordern, wenn Firmware an einem anderen Ort als einem autorisierten Dienstort oder unter Verwendung einer unautorisierten Dienstausrüstung, zum Beispiel unter Verwendung eines unsicheren Personalcomputers, aktualisiert wird.
Eine oder mehrere Ausführungsformen der Offenbarung beziehen sich auf eine vorgesehene „sichere“ Implementierung, wobei ein Computersystem, wie das Computersystem 100 von 1, eine sichere Vorrichtung umfasst, die auf einer Hostvorrichtung gestapelt ist, zum Beispiel unter Verwendung eines Moduls oder einer System-in-Package (SiP)-Anordnung. Bei Stapelung können die vertrauenswürdige Vorrichtung und die Hostvorrichtung relativ zueinander so angeordnet sein, dass Software-Debug-Pins und/oder Hardware-Reset-Pins der Hostvorrichtung versteckt sind, d. h. für die sichere Vorrichtung zugänglich sind, aber nicht außerhalb des Moduls zugänglich sind.
Ein Fachmann wird viele Vorteile und Nutzen aus den verschiedenen in dieser Offenbarung beschriebenen Ausführungsformen erkennen. Zum Beispiel können ein oder mehrere Nutzen und Vorteile einschließen: starke Isolierung zwischen Bootcode und dem Anwendungscode einer MCU; keine Software-Angriffsverfahren über die, die mit einem Boot-ROM selbst verfügbar gewesen wären, hinaus; beschleunigte Verfügbarkeit von Modulen/SIP-Lösungen über einen weiten Bereich von MCU-Fähigkeiten auch ohne dass hierfür neue Maskensätze und zugehörige Entwicklungszeiten erforderlich sind; Verbessern der sicheren Boot-Fähigkeiten von MCUs mit vorhandener sicherer Boot-Fähigkeit, ohne neue Maskensätze und zugehörige Entwicklungszeit zu benötigen; Hinzufügen der Fähigkeit, eine asymmetrische Signatur rechtzeitig an einer MCU, die bereits ein Boot-ROM hatte, angemessen zu verifizieren.
Jede Charakterisierung in dieser Offenbarung von etwas als „üblich“, „herkömmlich“ oder „bekannt“ bedeutet nicht notwendigerweise, dass sie im Stand der Technik offenbart ist oder dass die erörterten Gesichtspunkte nach dem Stand der Technik anerkannt werden. Es bedeutet auch nicht notwendigerweise, dass es auf dem betreffenden Gebiet weithin bekannt und wohlverstanden ist oder routinemäßig verwendet wird.
Obwohl die vorliegende Offenbarung hierin in Bezug auf bestimmte veranschaulichte Ausführungsformen beschrieben wurde, wird der Fachmann erkennen und anerkennen, dass die vorliegende Erfindung nicht darauf beschränkt ist. Vielmehr können viele Ergänzungen, Löschungen und Modifikationen an den veranschaulichten und beschriebenen Ausführungsformen vorgenommen werden, ohne vom Schutzumfang der Erfindung abzuweichen, wie nachfolgend zusammen mit ihren rechtlichen Äquivalenten beansprucht wird. Zusätzlich können Merkmale von einer Ausführungsform mit Merkmalen einer anderen Ausführungsform kombiniert werden, während sie immer noch innerhalb des Schutzumfangs der Erfindung enthalten sind, wie er vom Erfinder in Betracht gezogen wird.
Zusätzliche, nicht einschränkende Ausführungsformen der Offenbarung schließen ein:

Ausführungsform 1: Verfahren zum Unterstützen einer Vorrichtung beim Durchführen eines sicheren Boot-Prozesses, wobei das Verfahren umfasst: Versetzen und Halten einer Vorrichtung in einem eingeschränkten Betriebsmodus; Senden eines Programms an die Vorrichtung unter Verwendung einer Schnittstelle zum Steuern einer zentralen Verarbeitungseinheit (CPU) der Vorrichtung, Initiieren der Ausführung des Programms an der Vorrichtung unter Verwendung der Schnittstelle zum Steuern der CPU; und Versuchen, die Sicherheit von Firmware, die in der Vorrichtung gespeichert ist, als Reaktion auf die initiierte Ausführung des Programms zu verifizieren.
Ausführungsform 2: Verfahren nach Ausführungsform 1, wobei das Senden des Programms an die Vorrichtung das Senden eines Low-Level-Bootcodes an die Vorrichtung umfasst.
Ausführungsform 3: Verfahren nach Ausführungsformen 1 und 2, wobei das Versetzen und Halten der Vorrichtung in dem eingeschränkten Betriebsmodus das Deaktivieren der unabhängigen Initiierung der Ausführung von Code an der Vorrichtung als Reaktion auf das Erfassen, dass neue Firmware an der Vorrichtung empfangen wurde, umfasst.
Ausführungsform 4: Verfahren nach Ausführungsformen 1 bis 3, wobei das Versuchen, die Sicherheit der Firmware, die auf der Vorrichtung gespeichert ist, als Reaktion auf die initiierte Ausführung des Programms zu verifizieren, Folgendes umfasst: Durchführen einer Hash-Funktion auf einem Betriebscode, der auf einem Programmspeicher der Vorrichtung gespeichert ist, um Sicherheitsdaten zu erhalten; Vergleichen der erhaltenen Sicherheitsdaten mit vertrauenswürdigen Sicherheitsdaten; und Versuchen, zu verifizieren, dass der Betriebscode sicher ist, als Reaktion auf das Vergleichen der erhaltenen Sicherheitsdaten mit den vertrauenswürdigen Sicherheitsdaten.
Ausführungsform 5: Verfahren nach Ausführungsformen 1 bis 4, ferner umfassend das Verifizieren, dass der Betriebscode als Reaktion auf das Erkennen, dass die erhaltenen Sicherheitsdaten mit den vertrauenswürdigen Sicherheitsdaten übereinstimmen, sicher ist.
Ausführungsform 6: Verfahren nach Ausführungsformen 1 bis 5, ferner umfassend das Bestimmen, dass der Betriebscode unsicher ist, als Reaktion auf das Erfassen, dass die erhaltenen Sicherheitsdaten nicht mit den vertrauenswürdigen Sicherheitsdaten übereinstimmen.
Ausführungsform 7: Verfahren nach Ausführungsformen 1 bis 6, ferner umfassend das Halten der Vorrichtung in dem eingeschränkten Betriebsmodus, bis das Programm erfasst, dass sicherer Betriebscode an der Vorrichtung installiert ist.
Ausführungsform 8: Verfahren nach Ausführungsformen 1 bis 7, ferner umfassend das Neustarten der Vorrichtung, bis das Programm erfasst, dass sicherer Betriebscode an der Vorrichtung installiert ist.
Ausführungsform 9: Verfahren nach Ausführungsformen 1 bis 8, wobei das Initiieren der Ausführung des Programms an der Vorrichtung unter Verwendung der Schnittstelle zum Steuern der CPU umfasst: Anweisen der Vorrichtung, das Programm auszuführen, nachdem die Vorrichtung den eingeschränkten Betriebsmodus verlassen hat; und Freigeben der Vorrichtung aus dem eingeschränkten Betriebsmodus.
Ausführungsform 10: Verfahren nach Ausführungsformen 1 bis 9, ferner umfassend: Empfangen eines ersten Verifizierungsergebnisses als Reaktion auf das Verifizieren, dass die Firmware sicher ist; und Empfangen eines zweiten Verifizierungsergebnisses als Reaktion auf das Bestimmen, dass die Firmware nicht sicher ist.
Ausführungsform 11: Verfahren nach Ausführungsformen 1 bis 10, ferner umfassend, als Reaktion auf das Empfangen des ersten Verifizierungsergebnisses: Anweisen der Vorrichtung, die Firmware beim Verlassen des eingeschränkten Betriebsmodus auszuführen; und Freigeben der Vorrichtung aus dem eingeschränkten Betriebsmodus.
Ausführungsform 12: Verfahren nach Ausführungsformen 1 bis 11, ferner umfassend, als Reaktion auf das Empfangen des zweiten Verifizierungsergebnisses: Halten der Vorrichtung in dem eingeschränkten Betriebsmodus, bis erfasst wird, dass die Sicherheit der auf der Vorrichtung gespeicherten Firmware verifiziert ist.
Ausführungsform 13: Sicheres bootunterstütztes System, umfassend: eine erste Vorrichtung, umfassend: einen Programmspeicher, der so konfiguriert ist, dass er die Firmware für die erste Vorrichtung speichert; einen Prozessor; und eine Schnittstelle zum Zugreifen auf den und Steuern des Prozessors; eine zweite Vorrichtung, die mit der ersten Vorrichtung operativ gekoppelt ist, wobei die zweite Vorrichtung umfasst: einen persistenten Speicher, auf dem ein Programm gespeichert ist, das, wenn es von dem Prozessor der ersten Vorrichtung ausgeführt wird, konfiguriert ist, um dem Prozessor zu ermöglichen, zu versuchen, die Sicherheit von Firmware, die in dem Programmspeicher der ersten Vorrichtung gespeichert ist, zu verifizieren; und eine Schaltung für vertrauenswürdige Sequenzen, die so konfiguriert ist, dass sie die Schnittstelle verwendet, um das Programm an die erste Vorrichtung zu senden und die Ausführung des Programms an der ersten Vorrichtung initiiert, und wobei die Schaltung für vertrauenswürdige Sequenzen so konfiguriert ist, dass sie die erste Vorrichtung in einem eingeschränkten Betriebsmodus hält, während versucht wird, die Sicherheit der gespeicherten Firmware für die erste Vorrichtung zu verifizieren.
Ausführungsform 14: System nach Ausführungsform 13, wobei die Schaltung für vertrauenswürdige Sequenzen so konfiguriert ist, dass sie ein Signal an einem Hardwareeingang der ersten Vorrichtung als Reaktion auf das Erfassen, dass neue Firmware an der ersten Vorrichtung gespeichert ist, aktiviert, und wobei ferner die erste Vorrichtung so konfiguriert ist, dass sie in dem eingeschränkten Betriebsmodus arbeitet, während der Hardwareeingang aktiviert ist.
Ausführungsform 15: System nach Ausführungsformen 13 und 14, wobei die Schaltung für vertrauenswürdige Sequenzen so konfiguriert ist, dass sie die Schnittstelle der ersten Vorrichtung steuert, um mindestens einige Funktionalität der ersten Vorrichtung zu verhindern.
Ausführungsform 16: System nach Ausführungsformen 13 bis 15, wobei der Prozessor der ersten Vorrichtung so konfiguriert ist, dass sie als Reaktion auf Steuersignale ausführt, die von der Schnittstelle als Reaktion darauf bereitgestellt werden, dass sich die erste Vorrichtung in dem eingeschränkten Betriebsmodus befindet.
Ausführungsform 17: System nach Ausführungsformen 13 bis 16, wobei die Schaltung für vertrauenswürdige Sequenzen der zweiten Vorrichtung so konfiguriert ist, dass sie als Reaktion auf das Speichern des Programms auf der ersten Vorrichtung: die Schnittstelle verwendet, um die erste Vorrichtung anzuweisen, die Ausführung des Programms beim Verlassen des eingeschränkten Betriebsmodus zu initiieren; und die erste Vorrichtung aus dem eingeschränkten Betriebsmodus freizugeben.
Ausführungsform 18: System nach Ausführungsformen 13 bis 17, wobei die Firmware Betriebscode und das Programm umfasst, die wenn sie durch den Prozessor ausgeführt werden, so konfiguriert sind, dass sie es dem Prozessor ermöglichen: Hashen des im Programmspeicher der ersten Vorrichtung gespeicherten Betriebscodes, um einen ersten Digest zu erhalten; Vergleichen des ersten Digests mit einem zweiten Digest; und Versuchen, zu verifizieren, dass der Betriebscode als Reaktion auf den Vergleich des ersten Digests und des zweiten Digests sicher ist.
Ausführungsform 19: System nach Ausführungsformen 13 bis 18, wobei das Programm, wenn es durch den Prozessor ausgeführt wird, konfiguriert ist zum:Bestimmen, dass der Betriebscode sicher ist, als Reaktion auf das Erfassen, dass der erste Digest mit dem zweiten Digest übereinstimmt; und Bestimmen, dass der Betriebscode nicht sicher ist, als Reaktion auf das Erfassen, dass der erste Digest nicht mit der zweiten Digest übereinstimmt.
Ausführungsform 20: System nach Ausführungsformen 13 bis 19, wobei die Schaltung für vertrauenswürdige Sequenzen der zweiten Vorrichtung so konfiguriert ist, dass sie als Reaktion auf das Installieren des Programms auf der zweiten Vorrichtung die Schnittstelle verwendet, um die erste Vorrichtung anzuweisen, die Ausführung des Programms zu initiieren.
Ausführungsform 21: System nach Ausführungsformen 13 bis 20, wobei das Programm, wenn es durch den Prozessor ausgeführt wird, konfiguriert ist zum: Bereitstellen eines ersten Verifizierungsergebnisses als Reaktion auf das Verifizieren, dass der Betriebscode sicher ist; und Bereitstellen eines zweiten Verifizierungsergebnisses als Reaktion auf das Bestimmen, dass der Betriebscode nicht sicher ist.
Ausführungsform 22: System nach Ausführungsformen 13 bis 21, wobei die Firmware Betriebscode umfasst und die Schaltung für vertrauenswürdige Sequenzen der zweiten Vorrichtung so konfiguriert ist, dass sie als Reaktion auf das Empfangen des ersten Verifizierungsergebnisses: die Schnittstelle verwendet, um die erste Vorrichtung anzuweisen, die Ausführung des Betriebscodes beim Verlassen des eingeschränkten Betriebsmodus zu initiieren; und die erste Vorrichtung aus dem eingeschränkten Betriebsmodus freizugeben.
Ausführungsform 23: System nach Ausführungsformen 13 bis 22, wobei die Schaltung für vertrauenswürdige Sequenzen der zweiten Vorrichtung so konfiguriert ist, dass sie als Reaktion auf das Empfangen des zweiten Verifizierungsergebnisses die erste Vorrichtung in dem eingeschränkten Betriebsmodus hält, bis erfasst wird, dass sichere Firmware an der ersten Vorrichtung installiert ist.
Ausführungsform 24: System nach Ausführungsformen 13 bis 23, wobei die Firmware Code umfasst für: ein integriertes eingebettetes System und/oder ein Betriebssystem und/oder einen Betriebssystemlader und individuell installierte Anwendungen.
Ausführungsform 25: Verfahren zum Unterstützen einer Vorrichtung beim Durchführen eines sicheren Boot-Prozesses, umfassend: Versetzen und Halten einer Vorrichtung in einem eingeschränkten Betriebsmodus; Kopieren von Code, der in einem Programmspeicher der Vorrichtung gespeichert ist, auf eine andere Vorrichtung unter Verwendung einer Schnittstelle zum Steuern einer zentralen Verarbeitungseinheit (CPU) der Vorrichtung; und Versuchen, zu verifizieren, dass der kopierte Code sicher ist.
Ausführungsform 26: Verfahren nach Ausführungsform 25, wobei das Versetzen und Halten der Vorrichtung in den/dem eingeschränkten Betriebsmodus das Deaktivieren der unabhängigen Initiierung der Ausführung von Code an der Vorrichtung umfasst.
Ausführungsform 27: Verfahren nach Ausführungsformen 25 und 26, wobei das Versuchen, zu verifizieren, dass der kopierte Code sicher ist, umfasst: Durchführen einer Hash-Funktion an dem kopierten Code, um erste Sicherheitsdaten zu erhalten; und Versuchen, zu verifizieren, dass der kopierte Code sicher ist, als Reaktion auf die ersten Sicherheitsdaten.
Ausführungsform 28: Verfahren nach Ausführungsformen 25 bis 27, wobei das Versuchen, zu verifizieren, dass der kopierte Code sicher ist, als Reaktion auf die ersten Sicherheitsdaten, umfasst: Vergleichen der ersten Sicherheitsdaten mit zweiten Sicherheitsdaten, die auf der anderen Vorrichtung gespeichert sind; und Versuchen, den kopierten Code als Reaktion auf das Vergleichen zu verifizieren.
Ausführungsform 29: Verfahren nach Ausführungsform s 25 bis 28, wobei das Versuchen, zu verifizieren dass der kopierte Code sicher ist, als Reaktion auf die ersten Sicherheitsdaten, das Versuchen umfasst, den kopierten Code durch Durchführen einer Signaturvalidierung an den ersten Sicherheitsdaten zu verifizieren.
Ausführungsform 30: Verfahren nach Ausführungsform s 25 bis 29, ferner umfassend: Verifizieren, dass der kopierte Code sicher ist; Anweisen der Vorrichtung, den Code auszuführen, der dem kopierten Code entspricht, wenn der eingeschränkte Betriebsmodus verlassen wird, und Freigeben der Vorrichtung aus dem eingeschränkten Betriebsmodus.
Ausführungsform 31: Verfahren nach Ausführungsform s 25 bis 30, ferner umfassend: Bestimmen, dass der kopierte Code unsicher als Reaktion ist; und Halten der Vorrichtung in dem eingeschränkten Betriebsmodus, bis verifiziert ist, dass Code, der an der Vorrichtung installiert ist, sicher ist.
Ausführungsform 32: Verfahren nach Ausführungsform s 25 bis 31, wobei das Kopieren des im Programmspeicher der Vorrichtung gespeicherten Codes das Kopieren des im Programmspeicher der Vorrichtung gespeicherten Bootcodes umfasst.
Ausführungsform 33: Verfahren nach Ausführungsform s 25 bis 32, wobei das Kopieren des im Programmspeicher der Vorrichtung gespeicherten Codes umfasst: Kopieren eines Teils des im Programmspeicher der Vorrichtung gespeicherten Betriebscodes, wobei die Vorrichtung so konfiguriert ist, dass sie den kopierten Teil des Betriebscodes bei einem Hochfahren der Vorrichtung oder bei einem Resetzustand der Vorrichtung ausführt.
Ausführungsform 34: Sicheres bootunterstütztes System, umfassend: eine erste Vorrichtung, umfassend: einen Programmspeicher, der so konfiguriert ist, dass er den Code für Firmware der ersten Vorrichtung speichert; einen Prozessor; und eine Schnittstelle zum Zugreifen auf den und Steuern des Prozessors; eine zweite Vorrichtung, die mit der ersten Vorrichtung operativ gekoppelt ist, wobei die zweite Vorrichtung umfasst: einen persistenten Speicher mit darauf gespeicherten Sicherheitsinformationen zum Verifizieren der Sicherheit des Codes, der in der ersten Vorrichtung gespeichert ist; und eine Schaltung für vertrauenswürdige Sequenzen, die konfiguriert ist, um die Debug-Funktionsschaltung zu verwenden, um den Code von der ersten Vorrichtung zu kopieren und zu versuchen, unter Verwendung der Sicherheitsinformationen zu verifizieren, dass der kopierte Code sicher ist, wobei die Schaltung für vertrauenswürdige Sequenzen konfiguriert ist, um die erste Vorrichtung in einem eingeschränkten Betriebsmodus zu halten, während versucht wird, zu verifizieren, dass der kopierte Code sicher ist.
Ausführungsform 35: System nach Ausführungsform 34, wobei die Schaltung für vertrauenswürdige Sequenzen so konfiguriert ist, dass sie einen Hardwareeingang der ersten Vorrichtung als Reaktion auf das Erfassen, dass neue Firmware an der ersten Vorrichtung installiert ist, aktiviert, und wobei ferner die erste Vorrichtung so konfiguriert ist, dass sie in dem eingeschränkten Betriebsmodus arbeitet, während der Hardwareeingang aktiviert ist.
Ausführungsform 36: System nach Ausführungsformen 34 und 35, wobei die Schaltung für vertrauenswürdige Sequenzen so konfiguriert ist, dass sie die Schnittstelle der ersten Vorrichtung steuert, um mindestens einige Funktionalität der ersten Vorrichtung zu verhindern.
Ausführungsform 37: System nach Ausführungsformen 34 bis 36, wobei der Prozessor der ersten Vorrichtung so konfiguriert ist, dass er als Reaktion auf Steuersignale ausführt, die von der Schnittstelle als Reaktion darauf bereitgestellt werden, dass sich die erste Vorrichtung in dem eingeschränkten Betriebsmodus befindet.
Ausführungsform 38: System nach Ausführungsformen 34 bis 37, wobei die Sicherheitsinformationen vertrauenswürdige Sicherheitsdaten umfassen und die Schaltung für vertrauenswürdige Sequenzen so konfiguriert ist: dass sie eine Hash-Funktion an dem kopierten Code durchführt, um erste Sicherheitsdaten zu erhalten; und versucht, zu verifizieren, dass der kopierte Code sicher ist, als Reaktion auf die erhaltenen Sicherheitsdaten und die vertrauenswürdigen Sicherheitsdaten.
Ausführungsform 39: System nach Ausführungsformen 34 bis 38, wobei die Sicherheitsinformationen vertrauenswürdigen Code umfassen und die Schaltung für vertrauenswürdige Sequenzen der zweiten Vorrichtung so konfiguriert ist: dass sie eine Hash-Funktion an dem kopierten Code durchführt, um erste Sicherheitsdaten zu erhalten; die Hash-Funktion an dem vertrauenswürdigen Code durchführt, um zweite Sicherheitsdaten zu erhalten; die ersten Sicherheitsdaten mit den zweiten Sicherheitsdaten vergleicht; und versucht, zu verifizieren, dass der kopierte Code sicher ist, als Reaktion auf das Vergleichen der ersten Sicherheitsdaten mit den zweiten Sicherheitsdaten.
Ausführungsform 40: System nach Ausführungsformen 34 bis 39, wobei die Schaltung für vertrauenswürdige Sequenzen der zweiten Vorrichtung als Reaktion auf das Verifizieren, dass der kopierte Code sicher ist, so konfiguriert ist, dass sie: die Schnittstelle verwendet, um die erste Vorrichtung anzuweisen, Code auszuführen, der dem kopierten Code entspricht, wenn der eingeschränkte Betriebsmodus verlassen wird; und die erste Vorrichtung aus dem eingeschränkten Betriebsmodus freizugeben. Ausführungsform 41: System nach Ausführungsformen 34 bis 40, wobei die Schaltung für vertrauenswürdige Sequenzen der zweiten Vorrichtung so konfiguriert ist, dass sie als Reaktion auf das Bestimmen, dass der kopierte Code nicht sicher ist, die erste Vorrichtung in dem eingeschränkten Betriebsmodus hält, bis erfasst wird, dass sicherer Code an der ersten Vorrichtung installiert ist.
Ausführungsform 42: System nach Ausführungsformen 34 bis 41, wobei die Sicherheitsinformationen vertrauenswürdigen Code umfassen und die Schaltung für vertrauenswürdige Sequenzen der zweiten Vorrichtung so konfiguriert ist, dass sie den kopierten Code mit dem vertrauenswürdigen Code vergleicht und versucht, zu verifizieren, dass der kopierte Code sicher ist, als Reaktion auf den Vergleich.
Ausführungsform 43: Verfahren zum Unterstützen einer Vorrichtung beim Durchführen eines sicheren Boot-Prozesses, umfassend: Versetzen und Halten einer Vorrichtung in einem eingeschränkten Betriebsmodus; Initiieren der Ausführung von nativem Bootcode, der in der Vorrichtung gespeichert ist, unter Verwendung einer Schnittstelle zum Steuern einer zentralen Verarbeitungseinheit (CPU) der Vorrichtung; Empfangen von Sicherheitsdaten unter Verwendung der Schnittstelle zum Steuern der CPU der Vorrichtung als Reaktion auf das Initiieren der Ausführung des nativen Bootcodes, wobei die empfangenen Sicherheitsdaten für Firmware der Vorrichtung repräsentativ sind; und Versuchen, zu verifizieren, dass die Firmware der Vorrichtung sicher ist, als Reaktion auf die empfangenen Sicherheitsdaten und vertrauenswürdige Sicherheitsdaten, die außerhalb der Vorrichtung gespeichert sind.
Ausführungsform 44: Verfahren nach Ausführungsform 43, ferner umfassend: Durchführen einer Hash-Funktion auf Code der Firmware der Vorrichtung, um die Sicherheitsdaten zu erhalten; und Senden der erhaltenen Sicherheitsdaten an eine andere Vorrichtung zur Verifizierung, dass die Firmware der Vorrichtung sicher ist.
Ausführungsform 45: Verfahren nach Ausführungsformen 43 und 44, ferner umfassend: Verifizieren, dass die Firmware der Vorrichtung sicher ist, als Reaktion auf das Erfassen, dass die empfangenen Sicherheitsdaten mit den vertrauenswürdigen Sicherheitsdaten übereinstimmen; Anweisen der Vorrichtung, den nativen Bootcode beim Verlassen des eingeschränkten Betriebsmodus auszuführen; und Freigeben der Vorrichtung aus dem eingeschränkten Betriebsmodus.
Ausführungsform 46: Verfahren nach Ausführungsformen 43 bis 45, ferner umfassend: Bestimmen, dass die Firmware unsicher ist, als Reaktion auf das Erfassen, dass die empfangenen Sicherheitsdaten nicht mit den vertrauenswürdigen Sicherheitsdaten übereinstimmen; und Halten der Vorrichtung in dem eingeschränkten Betriebsmodus, bis erfasst wird, dass sichere Firmware an der Vorrichtung installiert ist.
Ausführungsform 47: Sicheres bootunterstütztes System, umfassend: eine erste Vorrichtung, umfassend: einen Programmspeicher, der so konfiguriert ist, dass er den Code für die erste Vorrichtung speichert; einen Prozessor; und eine Schnittstelle zum Zugreifen auf den und Steuern des Prozessors; eine zweite Vorrichtung, die mit der ersten Vorrichtung operativ gekoppelt ist, wobei die zweite Vorrichtung umfasst: einen persistenten Speicher, auf dem vertrauenswürdige Sicherheitsdaten zum Verifizieren der Sicherheit des Codes gespeichert sind, der auf der ersten Vorrichtung gespeichert ist; und eine Schaltung für vertrauenswürdige Sequenzen, die konfiguriert ist zum: Initiieren einer Ausführung eines nativen Bootcodes, der an der ersten Vorrichtung gespeichert ist, unter Verwendung der Schnittstelle; Empfangen von Sicherheitsdaten unter Verwendung der Schnittstelle zum Steuern der CPU der Vorrichtung als Reaktion auf das Initiieren der Ausführung des nativen Bootcodes, wobei die empfangenen Sicherheitsdaten für Firmware der ersten Vorrichtung repräsentativ sind; und Versuchen, unter Verwendung der empfangenen Sicherheitsdaten und der vertrauenswürdigen Sicherheitsdaten zu verifizieren, dass die Firmware der Vorrichtung sicher ist, wobei die Schaltung für vertrauenswürdige Sequenzen so konfiguriert ist, dass sie die erste Vorrichtung in einem eingeschränkten Betriebsmodus hält, während versucht wird, zu verifizieren, dass die Firmware sicher ist.
Ausführungsform 48: System nach Ausführungsform 47, wobei die Schaltung für vertrauenswürdige Sequenzen so konfiguriert ist, dass sie einen Hardwareeingang der ersten Vorrichtung als Reaktion auf das Erfassen, dass neue Firmware an der ersten Vorrichtung installiert ist, aktiviert, und wobei ferner die erste Vorrichtung so konfiguriert ist, dass sie in dem eingeschränkten Betriebsmodus arbeitet, während die Hardwareeingang aktiviert ist.
Ausführungsform 49: System nach Ausführungsformen 47 und 48, wobei die Schaltung für vertrauenswürdige Sequenzen so konfiguriert ist, dass sie die Schnittstelle der ersten Vorrichtung steuert, um mindestens einige Funktionalität der ersten Vorrichtung zu verhindern.
Ausführungsform 50: System nach Ausführungsformen 47 bis 49, wobei der Prozessor so konfiguriert ist, dass er Reaktionen auf Steuersignale ausführt, die von der Schnittstelle als Reaktion darauf bereitgestellt werden, dass sich die erste Vorrichtung in dem eingeschränkten Betriebsmodus befindet.
Ausführungsform 51: System nach Ausführungsformen 47 bis 50, wobei der native Bootcode, wenn er durch den Prozessor ausgeführt wird, konfiguriert ist zum: Durchführen einer Hash-Funktion auf Code der Firmware der ersten Vorrichtung, um die Sicherheitsdaten zu erhalten; und Senden der erhaltenen Sicherheitsdaten an die zweite Vorrichtung zur Verifizierung, dass die Firmware der ersten Vorrichtung sicher ist.
Ausführungsform 52: System nach Ausführungsformen 47 bis 51, wobei die Schaltung für vertrauenswürdige Sequenzen konfiguriert ist, als Reaktion auf das Verifizieren, dass die Firmware der ersten Vorrichtung sicher ist, zum: Anweisen der ersten Vorrichtung, den Betriebscode der ersten Vorrichtung nach Verlassen des eingeschränkten Betriebsmodus auszuführen, und Freigeben der ersten Vorrichtung aus dem eingeschränkten Betriebsmodus.
Ausführungsform 53: System nach Ausführungsformen 47 bis 52, wobei die Schaltung für vertrauenswürdige Sequenzen so konfiguriert dass sie ist, als Reaktion auf das Bestimmen, dass die Firmware der ersten Vorrichtung nicht sicher ist, die erste Vorrichtung in dem eingeschränkten Betriebsmodus hält, bis erfasst wird, dass sichere Firmware an der ersten Vorrichtung installiert ist.

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 Patentliteratur

US 62/760636 [0001]
US 16/364391 [0001]

Zitierte Nicht-Patentliteratur

3. November 2018, für „SECURE BOOT ASIST FOR MICROCONTROLLERS AND RELATED SYSTEMS, METHOD AND DEVICES‟ [0001]
26. März 2019, für „SECURE BOOT ASSIST FOR DEVICES, AND RELATED SYSTEMS, METHODS AND DEVICES‟ [0001]

Claims

Verfahren zum Unterstützen einer Vorrichtung beim Durchführen eines sicheren Boot-Prozesses, wobei das Verfahren umfasst: Versetzen und Halten einer Vorrichtung in einem eingeschränkten Betriebsmodus; Senden eines Programms an die Vorrichtung unter Verwendung einer Schnittstelle zum Steuern einer zentralen Verarbeitungseinheit (CPU) der Vorrichtung; Initiieren der Ausführung des Programms an der Vorrichtung unter Verwendung der Schnittstelle zum Steuern der CPU; und Versuchen, die Sicherheit von Firmware, die in der Vorrichtung gespeichert ist, als Reaktion auf die initiierte Ausführung des Programms zu verifizieren.
Verfahren nach Anspruch 1, wobei das Senden des Programms an die Vorrichtung das Senden eines Low-Level-Bootcodes an die Vorrichtung umfasst.
Verfahren nach Anspruch 1, wobei das Versetzen und Halten der Vorrichtung in dem eingeschränkten Betriebsmodus das Deaktivieren der unabhängigen Initiierung der Ausführung von Code an der Vorrichtung als Reaktion auf das Erfassen, dass neue Firmware an der Vorrichtung empfangen wurde, umfasst.
Verfahren nach Anspruch 1, wobei das Versuchen, die Sicherheit der Firmware, die auf der Vorrichtung gespeichert ist, als Reaktion auf die initiierte Ausführung des Programms zu verifizieren, umfasst: Durchführen einer Hash-Funktion an einem in einem Programmspeicher der Vorrichtung gespeicherten Betriebscode, um Sicherheitsdaten zu erhalten; Vergleichen der erhaltenen Sicherheitsdaten mit vertrauenswürdigen Sicherheitsdaten; und Versuchen, zu verifizieren, dass der Betriebscode sicher ist, als Reaktion auf das Vergleichen der erhaltenen Sicherheitsdaten mit den vertrauenswürdigen Sicherheitsdaten.
Verfahren nach Anspruch 4, ferner umfassend das Verifizieren, dass der Betriebscode als Reaktion auf das Erfassen, dass die erhaltenen Sicherheitsdaten mit den vertrauenswürdigen Sicherheitsdaten übereinstimmen, sicher ist.
Verfahren nach Anspruch 4, ferner umfassend das Bestimmen, dass der Betriebscode unsicher ist, als Reaktion auf das Erfassen, dass die erhaltenen Sicherheitsdaten nicht mit den vertrauenswürdigen Sicherheitsdaten übereinstimmen.
Verfahren nach Anspruch 6, ferner umfassend das Halten der Vorrichtung in dem eingeschränkten Betriebsmodus, bis das Programm erfasst, dass sicherer Betriebscode an der Vorrichtung installiert ist.
Verfahren nach Anspruch 6, ferner umfassend das Neustarten der Vorrichtung, bis das Programm erfasst, dass sicherer Betriebscode an der Vorrichtung installiert ist.
Verfahren nach Anspruch 1, wobei das Initiieren der Ausführung des Programms an der Vorrichtung unter Verwendung der Schnittstelle zum Steuern der CPU umfasst: Anweisen der Vorrichtung, das Programm auszuführen, nachdem die Vorrichtung den eingeschränkten Betriebsmodus verlassen hat; und Freigeben der Vorrichtung aus dem eingeschränkten Betriebsmodus.
Verfahren nach Anspruch 1, ferner umfassend: Empfangen eines ersten Verifizierungsergebnisses als Reaktion auf das Verifizieren, dass die Firmware sicher ist, und Empfangen eines zweiten Verifizierungsergebnisses als Reaktion auf das Bestimmen, dass die Firmware nicht sicher ist.
Verfahren nach Anspruch 10, ferner umfassend, als Reaktion auf das Empfangen des ersten Verifizierungsergebnisses: Anweisen der Vorrichtung, die Firmware beim Verlassen des eingeschränkten Betriebsmodus auszuführen; und Freigeben der Vorrichtung aus dem eingeschränkten Betriebsmodus.
Verfahren nach Anspruch 10, ferner umfassend, als Reaktion auf das Empfangen des zweiten Verifizierungsergebnisses: Halten der Vorrichtung in dem eingeschränkten Betriebsmodus, bis erfasst wird, dass die Sicherheit der in der Vorrichtung gespeicherten Firmware verifiziert ist.
Sicheres bootunterstütztes System, umfassend: eine erste Vorrichtung, umfassend: einen Programmspeicher, der so konfiguriert ist, dass er Firmware für die erste Vorrichtung speichert; einen Prozessor; und eine Schnittstelle zum Zugreifen auf den und Steuern des Prozessors; eine zweite Vorrichtung, die mit der ersten Vorrichtung operativ gekoppelt ist, wobei die zweite Vorrichtung umfasst: einen persistenten Speicher, auf dem ein Programm gespeichert ist, das, wenn es von dem Prozessor der ersten Vorrichtung ausgeführt wird, so konfiguriert ist, dass es dem Prozessor ermöglicht, zu versuchen, die Sicherheit von Firmware, die in dem Programmspeicher der ersten Vorrichtung gespeichert ist, zu verifizieren; und eine Schaltung für vertrauenswürdige Sequenzen, die konfiguriert ist, um die Schnittstelle zu verwenden, um das Programm an die erste Vorrichtung zu senden und die Ausführung des Programms auf der ersten Vorrichtung zu initiieren, und wobei die Schaltung für vertrauenswürdige Sequenzen so konfiguriert ist, dass sie die erste Vorrichtung in einem eingeschränkten Betriebsmodus hält, während versucht wird, die Sicherheit der gespeicherten Firmware für die erste Vorrichtung zu verifizieren.
System nach Anspruch 13, wobei die Schaltung für vertrauenswürdige Sequenzen so konfiguriert ist, dass sie ein Signal an einem Hardwareeingang der ersten Vorrichtung als Reaktion auf das Erkennen, dass neue Firmware an der ersten Vorrichtung gespeichert ist, aktiviert, und wobei ferner die erste Vorrichtung so konfiguriert ist, dass sie in dem eingeschränkten Betriebsmodus arbeitet, während der Hardwareeingang aktiviert ist.
System nach Anspruch 14, wobei die Schaltung für vertrauenswürdige Sequenzen so konfiguriert ist, dass sie die Schnittstelle der ersten Vorrichtung steuert, um mindestens eine gewisse Funktionalität der ersten Vorrichtung zu verhindern.
System nach Anspruch 14, wobei der Prozessor der ersten Vorrichtung so konfiguriert ist, dass er Reaktionen auf Steuersignale ausführt, die von der Schnittstelle als Reaktion darauf bereitgestellt werden, dass sich die erste Vorrichtung in dem eingeschränkten Betriebsmodus befindet.
System nach Anspruch 13, wobei die Schaltung für vertrauenswürdige Sequenzen der zweiten Vorrichtung konfiguriert ist zum: Verwenden der Schnittstelle zum Anweisen der ersten Vorrichtung zum Initiieren der Ausführung des Programms nach Verlassen des eingeschränkten Betriebsmodus; und Freigeben der ersten Vorrichtung aus dem eingeschränkten Betriebsmodus.
System nach Anspruch 17, wobei die Firmware den Betriebscode umfasst und das Programm, wenn es durch den Prozessor ausgeführt wird, so konfiguriert ist, dass es dem Prozessor ermöglicht: Hashen des im Programmspeicher der ersten Vorrichtung gespeicherten Betriebscodes, um einen ersten Digest zu erhalten; Vergleichen des ersten Digests mit einem zweiten Digest; und Versuchen, zu verifizieren, dass der Betriebscode sicher ist, als Reaktion auf einen Vergleich des ersten Digests mit dem zweiten Digest.
System nach Anspruch 18, wobei das Programm, wenn es durch den Prozessor ausgeführt wird, konfiguriert ist zum: Bestimmen, dass der Betriebscode sicher ist, als Reaktion auf das Erfassen, dass der erste Digest mit der zweiten Digest übereinstimmt; und Bestimmen, dass der Betriebscode nicht sicher ist, als Reaktion auf das Erfassen, dass der erste Digest nicht mit der zweiten Digest übereinstimmt.
System nach Anspruch 13, wobei die Schaltung für vertrauenswürdige Sequenzen der zweiten Vorrichtung so konfiguriert ist, dass sie als Reaktion auf das Installieren des Programms auf der zweiten Vorrichtung die Schnittstelle verwendet, um die erste Vorrichtung anzuweisen, die Ausführung des Programms zu initiieren.
System nach Anspruch 20, wobei das Programm, wenn es durch den Prozessor ausgeführt wird, konfiguriert ist zum: Bereitstellen eines ersten Verifizierungsergebnisses als Reaktion auf das Verifizieren, dass ein Betriebscode sicher ist, und Bereitstellen eines zweiten Verifizierungsergebnisses als Reaktion auf das Bestimmen, dass der Betriebscode nicht sicher ist.
System nach Anspruch 21, wobei die Firmware Betriebscode umfasst und die Schaltung für vertrauenswürdige Sequenzen der zweiten Vorrichtung als Reaktion auf das Empfangen des ersten Verifizierungsergebnisses konfiguriert ist zum: Verwenden der Schnittstelle, um die erste Vorrichtung anzuweisen, die Ausführung des Betriebscodes beim Verlassen des eingeschränkten Betriebsmodus zu initiieren; und Freigeben der ersten Vorrichtung aus dem eingeschränkten Betriebsmodus.
System nach Anspruch 21, wobei die Schaltung für vertrauenswürdige Sequenzen der zweiten Vorrichtung so konfiguriert ist, das sie, als Reaktion auf das Empfangen des zweiten Verifizierungsergebnisses, die erste Vorrichtung in dem eingeschränkten Betriebsmodus hält, bis erfasst wird, dass sichere Firmware an der ersten Vorrichtung installiert ist.
System nach Anspruch 13, wobei die Firmware den Code umfasst für eines oder mehrere von Folgenden: ein integriertes eingebettetes System und/oder ein Betriebssystem und/oder einen Betriebssystemlader und individuell installierte Anwendungen.
Verfahren zum Unterstützen einer Vorrichtung beim Durchführen eines sicheren Boot-Prozesses, umfassend: Versetzen und Halten einer Vorrichtung in einem eingeschränkten Betriebsmodus; Kopieren von Code, der in einem Programmspeicher der Vorrichtung gespeichert ist, auf eine andere Vorrichtung unter Verwendung einer Schnittstelle zum Steuern einer zentralen Verarbeitungseinheit (CPU) der Vorrichtung; und Versuchen, zu verifizieren, dass der kopierte Code sicher ist.
Verfahren nach Anspruch 25, wobei das Versetzen und Halten der Vorrichtung in dem eingeschränkten Betriebsmodus das Deaktivieren der unabhängigen Initiierung der Ausführung von Code an der Vorrichtung umfasst.
Verfahren nach Anspruch 25, wobei das Versuchen, zu verifizieren, dass der kopierte Code sicher ist, umfasst: Durchführen einer Hash-Funktion an dem kopierten Code, um erste Sicherheitsdaten zu erhalten; und Versuchen, zu verifizieren, dass der kopierte Code sicher ist, als Reaktion auf die ersten Sicherheitsdaten.
Verfahren nach Anspruch 27, wobei das Versuchen, zu verifizieren, dass der kopierte Code sicher ist, als Reaktion auf die ersten Sicherheitsdaten umfasst: Vergleichen der ersten Sicherheitsdaten mit zweiten Sicherheitsdaten, die auf der anderen Vorrichtung gespeichert sind; und Versuchen, den kopierten Code als Reaktion auf das Vergleichen zu verifizieren.
Verfahren nach Anspruch 27, wobei das Versuchen, zu verifizieren dass der kopierte Code sicher ist, als Reaktion auf die ersten Sicherheitsdaten, das Versuchen umfasst, den kopierten Code durch Durchführen einer Signaturvalidierung an den ersten Sicherheitsdaten zu verifizieren.
Verfahren nach Anspruch 27, ferner umfassend: Verifizieren, dass der kopierte Code sicher ist; Anweisen der Vorrichtung, den Code auszuführen, der dem kopierten Code entspricht, wenn der eingeschränkte Betriebsmodus verlassen wird; und Freigeben der Vorrichtung aus dem eingeschränkten Betriebsmodus.
Verfahren nach Anspruch 27, ferner umfassend: Bestimmen, dass der kopierte Code unsicher als Reaktion ist; und Halten der Vorrichtung in dem eingeschränkten Betriebsmodus, bis verifiziert ist, dass Code, der an der Vorrichtung installiert ist, sicher ist.
Verfahren nach Anspruch 25, wobei das Kopieren des im Programmspeicher der Vorrichtung gespeicherten Codes das Kopieren des im Programmspeicher der Vorrichtung gespeicherten Bootcodes umfasst.
Verfahren nach Anspruch 25, wobei das Kopieren des im Programmspeicher der Vorrichtung gespeicherten Codes umfasst: Kopieren eines Teils des im Programmspeicher der Vorrichtung gespeicherten Betriebscodes, wobei die Vorrichtung so konfiguriert ist, dass sie den kopierten Teil des Betriebscodes bei einem Hochfahren der Vorrichtung oder bei einem Resetzustand der Vorrichtung ausführt.