DE10392528T5

DE10392528T5 - Microcode-Patch-Authentifizierung

Info

Publication number: DE10392528T5
Application number: DE10392528T
Authority: DE
Inventors: James II. Portland Sutton
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2002-04-12
Filing date: 2003-03-28
Publication date: 2005-09-15
Also published as: AU2003224803A1; TWI268449B; HK1068423A1; GB2419990A; CN1659494A; GB2403047A; TW200402659A; WO2003088019A3; CN1659494B; US20030196096A1; WO2003088019A2; GB0602345D0; GB2419990B; GB0422098D0; GB2403047B

Abstract

Maschinenlesbares Medium, das Befehle bereitstellt, die, wenn sie von einem Satz von einem oder mehreren Prozessoren ausgeführt werden, bewirken, daß der Satz von Prozessoren Vorgänge durchführt, die Folgendes umfassen:
Erstellen eines Hash-Digests für einen Mikrocodepatch;
Verschlüsseln des Hash-Digests zum Erstellen einer digitalen Signatur; und
Kombinieren der digitalen Signatur und des Mikrocodepatchs zum Liefern an einen Zielprozessor, um Mikrocode im Zielprozessor zu patchen.

Description

BESCHREIBUNG

ALLGEMEINER STAND DER TECHNIK

Ein typischer Befehl in einem Computerprozessor führt eine Reihe von Vorgängen aus, wobei Mikrobefehle, die jeden Vorgang definieren, in einem nichtflüchtigen Speicherbereich in Form von Mikrocode codiert werden. Der Mikrocode definiert alles oder einen Teil des ausführbaren Befehlssatzes für den Prozessor und kann auch interne Vorgänge definieren, die nicht in durch Software zugänglichen Code umgesetzt sind. Der Mikrocode wird in der Regel in einen Festspeicher (read-only memory, ROM) im Prozessor gesetzt, wenn der Prozessor gefertigt wird. Mikrocode muß jedoch manchmal modifiziert werden, nachdem der Prozessor gefertigt und sogar nachdem der Prozessor in Betrieb genommen wurde.

Mikrocodepatches ermöglichen eine derartige Modifikation durch Einfügen neuer Mikrobefehle anstelle der ursprünglichen Mikrobefehle. Die Mikrocodepatches können über verschiedene Wege (wie beispielsweise durch Herunterladen über einen Nachrichtenkanal, Installieren durch einen Servicetechniker oder Bereitstellung mit einem Betriebssystem) dem Prozessor geliefert werden und werden dann im Prozessor zur Verwendung im Betrieb gespeichert.

Da der Mikrocode-ROM nicht einfach verändert werden kann, werden Mikrocodepatches in der Regel in einen Patch-Speicher im Prozessor, wie beispielsweise einen Direktzugriffsspeicher (random-access memory, RAM), gesetzt und Hinweise auf die modifizierten Mikrobefehle werden zum Patch-RAM anstatt zum ROM umgeleitet. Da der Patch-RAM flüchtig sein kann, werden die Mikrocode-Patches für gewöhnlich entweder auf Festplatte oder im BIOS (Basic Input-Output System, einfaches Eingabe-/Ausgabesystem) gespeichert und werden in den Patch-RAM geladen, wenn das System gestartet wird.

Wenn ein Prozessor in einer sicheren Umgebung verwendet werden soll, sollten verschiedene Sicherheitsvorkehrungen beim Design der Software und/oder Hardware vorgenommen werden, um einen Schutz gegen das Manipulieren des Betriebs der sicheren Funktionen bereitzustellen. Die Möglichkeit zum Einfügen von nicht autorisierten Mikrocodepatches in einen Prozessor stellt einen Weg dar, mit dem ein feindseliger Angreifer herkömmlichen Sicherheitsmaßnahmen entgegenwirken kann.

KURZBESCHREIBUNG DER ZEICHNUNGEN
Die Erfindung kann durch Bezugnahme auf die folgende Beschreibung und die begleitenden Zeichnungen, die zum Veranschaulichen von Ausführungsformen der Erfindung verwendet werden, verstanden werden.
1 zeigt ein Blockschema eines Systems zum Validieren und Installieren von Mikrocodepatches gemäß einer Ausführungsform der Erfindung.
2 zeigt ein Blockschema eines Systems zum Umwandeln von Mikrocodepatches in eine für die Lieferung sichere Form gemäß einer Ausführungsform der Erfindung.
3 zeigt ein Patchpaket, das vom System von 2 zum System von 1 gelieferte Elemente enthält, gemäß einer Ausführungsform der Erfindung.
4 zeigt ein Ablaufdiagramm eines Gesamtprozesses zum Vorbereiten, Liefern und Validieren eines Patchpakets gemäß einer Ausführungsform der Erfindung.
5 zeigt ein Ablaufdiagramm eines Prozesses zum Vorbereiten eines Patchpakets gemäß einer Ausführungsform der Erfindung.
6 zeigt ein Ablaufdiagramm eines Prozesses zum Validieren eines Patchpakets gemäß einer Ausführungsform der Erfindung.
AUSFÜHRLICHE BESCHREIBUNG
In der folgenden Beschreibung sind zahlreiche spezifische Einzelheiten ausgeführt. Es versteht sich jedoch, daß Ausführungsformen der Erfindung ohne diese spezifischen Einzelheiten ausgeübt werden können. In anderen Beispielen sind wohl bekannte Schaltkreise, Strukturen und Techniken nicht im Detail gezeigt, um nicht ein Verständnis dieser Beschreibung zu verschleiern.
Hinweise auf "eine Ausführungsform", "Ausführungsbeispiel", "verschiedene Ausführungsformen" usw. weisen darauf hin, daß die beschriebene(n) Ausführungsformen) ein bestimmtes Merkmal, eine bestimmte Struktur oder eine bestimmte Eigenschaft aufweisen kann/können, aber nicht notwendigerweise jede Ausführungsform das bestimmte Merkmal, die bestimmte Struktur oder die bestimmte Eigenschaft beinhaltet. Des Weiteren können die für unterschiedliche Ausführungsformen beschriebenen Merkmale, Strukturen oder Eigenschaften in einer einzigen Ausführungsform kombiniert werden. Weiterhin bezieht sich die wiederholte Verwendung des Ausdrucks "in einer Ausführungsform" nicht notwendigerweise auf dieselbe Ausführungsform, was jedoch möglich ist.
Bezugnahmen hierin auf Kryptographie können Verschlüsselung und/oder Entschlüsselung beinhalten. Bezugnahmen hierin auf "symmetrische" Kryptographie, Schlüssel, Verschlüsselung oder Entschlüsselung beziehen sich auf kryptographische Techniken, in denen derselbe Schlüssel für die Verschlüsselung und die zugehörige Entschlüsselung verwendet wird. Der wohl bekannte Data Encryption Standard (DES, Datenverschlüsselungsstandard), der 1993 als Federal Information Publishing Standard FIPS PUB 46-2 veröffentlicht wurde, und der Advanced Encryption Standard (AES, erweiterter Verschlüsselungsstandard), der 2001 als FIPS PUB 197 veröffentlicht wurde, sind Beispiele von symmetrischer Kryptographie. Bezugnahmen hierin auf "asymmetrische" Kryptographie, Schlüssel, Verschlüsselung oder Entschlüsselung beziehen sich auf kryptographische Techniken, in denen verschiedene, aber anverwandte Schlüssel für die Verschlüsselung und die zugehörige Entschlüsselung verwendet werden. Kryptographische Techniken mit sogenanntem "öffentlichen Schlüssel", einschließlich der wohl bekannten Rivest-Shamir-Adleman-Technik (RSA-Technik), sind Beispiele asymmetrischer Kryptographie. Einer von zwei anverwandten Schlüsseln eines asymmetrischen kryptographischen Prozesses wird hierin als ein privater Schlüssel (da er im Allgemeinen geheimgehalten wird) und der andere Schlüssel als ein öffentlicher Schlüssel (da er im Allgemeinen frei verfügbar gemacht wird) bezeichnet. In manchen Ausführungsform kann entweder der private oder der öffentliche Schlüssel zur Verschlüsselung verwendet werden, während der andere Schlüssel bei der zugehörigen Entschlüsselung verwendet wird.
Ausführungsformen der Erfindung können in einer Hardware, Firmware oder Software oder einer Kombination dieser umgesetzt sein.
Ausführungsformen der Erfindung können auch als auf einem maschinenlesbaren Medium gespeicherte Befehle umgesetzt sein, die von mindestens einem Prozessor zum Durchführen der oben beschriebenen Vorgänge gelesen und ausgeführt werden. Ein maschinenlesbares Medium kann einen beliebigen Mechanismus zum Speichern oder Übertragen von Informationen in einer von einer Maschine (z. B. einem Computer) lesbaren Form beinhalten. Ein maschinenlesbares Medium kann beispielsweise Festspeicher (read-only memory, ROM); Direktzugriffsspeicher (random-access memory, RAM); Magnetplattenspeichermedien; optische Speichermedien; Flash-Speichervorrichtungen; elektrische, optische, akustische oder eine andere Form von verbreiteten Signalen (z. B. Trägerwellen, Infrarotsignale, Digitalsignale usw.) und andere beinhalten.
Verschiedene Ausführungsformen der Erfindung umfassen das Codieren und/oder Decodieren eines Mikrocodepatchs (hierin auch einfach als ein "Patch" bezeichnet), so daß der Patch als gültig authentifiziert werden kann, bevor er in einem Zielprozessor (einem Prozessor, in dem der Patch verwendet werden soll) installiert wird. Das Codieren/Decodieren kann einen oder mehrere der folgenden Vorgänge umfassen: 1) Verschlüsselung/Entschlüsselung, 2) die Verwendung von kryptographischen Hash-Funktionen, 3) die Verwendung von digitalen Signaturen, 4) usw. Ein Zielsystem ist das System, in dem der Patch installiert werden soll, während es sich bei einem Herkunftssystem um das System handelt, das den Patch für die sichere Lieferung zum Zielsystem vorbereitet. In einer Ausführungsform wird ein üblicher Satz von Patches für einen bestimmten Computersystemtyp erstellt, wobei "Typ" auf eine bestimmte Generation, eine bestimmte Modellnummer, eine beliebige Kategorie innerhalb der Modellnummer usw. hinweisen kann. Nachdem ein Patch erstellt wurde, kann er vor der Lieferung an jedes der Zielsysteme, für die er gedacht ist, auf die hierin beschriebene Art und Weise codiert werden. In jedem Zielsystem können ein oder mehrere Patches decodiert und wie hierin beschrieben installiert werden, so daß die Patches zu einem betriebsbereiten Teil des Zielsystems werden.
Es kann ein beliebiges praktisches Verfahren zur Lieferung verwendet werden, einschließlich u. a. Lieferung über eine Nachrichtenstrecke, Installieren durch einen Techniker, Einbindung in ein Betriebssystem durch den Hersteller dieses Betriebssystems, Einbindung in ein BIOS (basic Input-output System, einfaches Eingabe-/Ausgabesystem) usw. Nachdem der Patch geliefert wurde, kann er in seiner codierten Form gespeichert werden, bis er betriebsbereit installiert wird. Die betriebsbereite Installation beinhaltet das Decodieren des codierten Patchs, das Validieren, daß der Patch autorisiert ist, und das Setzen des Patchs in einen Patch-Speicher. Das Validieren kann einen der oder beide folgenden Vorgänge beinhalten: 1) Bestimmen, daß der Patch nicht modifiziert worden ist, seit er im Herkunftssystem für die Lieferung vorbereitet wurde, und 2) Bestimmen, daß der Patch in einem autorisierten System vorbereitet wurde. In einer Ausführungsform wird der codierte Patch auf der Festplatte oder im BIOS des Zielsystems gespeichert, um jedes Mal, wenn das System gestartet wird, in einem flüchtigen Patch-RAM betriebsbereit installiert zu werden. In einer anderen Ausführungsform wird der codierte Patch in einem nichtflüchtigen Patch-Speicher betriebsbereit installiert und nicht während nachfolgender Startvorgänge neu installiert.
1 zeigt ein Blockschema eines Systems zum Validieren und Installieren von Mikrocodepatches gemäß einer Ausführungsform der Erfindung. In der dargestellten Ausführungsform von 1 enthält das System 100 einen Prozessor 110, einen Chipsatz 130, eine Festplatte 140, einen Hauptspeicher 150 und eine Kommunikationsschnittstelle 160. Der Prozessor 110 kann einen Mikrocode-ROM 112, einen Patch-Speicher 114, einen sicheren Speicher 118 und einen oder mehrere Schlüssel 116 enthalten. Der Chipsatz 130 kann ein BIOS 132 enthalten. Ein Patchpaket (im Folgenden beschrieben) kann auf der Festplatte 140, im BIOS 132 und/oder in einem anderen Teil des Systems 100, der nichtflüchtigen Speicher enthält, gespeichert werden.
In manchen Ausführungsformen können die Vorgänge des Decodierens, Validierens und Installierens des Patchs mittels einer im Mikrocode-ROM 112 enthaltenen Sequenz von Mikro befehlen durchgeführt werden. In einer bestimmten Ausführungsform wird die Sequenz durch Ausführen eines speziellen Befehls eingeleitet, der die Ausführung auf die Einsprungstelle der Sequenz überträgt. In einer anderen bestimmten Ausführungsform wird die Sequenz als Reaktion auf das Schreiben eines vorbestimmten Werts in einen vorbestimmten Abschnitt eines maschinenspezifischen Register (MSR) eingeleitet. Es können auch andere Verfahren zum Einleiten der Sequenz verwendet werden.
Die Daten, an denen während des Decodierens, Validierens und Installierens des Patchs gearbeitet wird, können sich im sicheren Speicher 118 befinden, der so gesichert sein kann, daß er gegenüber Zugriff durch einen nicht sicheren Code nicht verfügbar ist. In manchen Ausführungsformen kann der sichere Speicher 118 zu verschiedenen Zeitpunkten den codierten Patch, den decodierten Patch und Zwischenprodukte, die während der Decodierung des codierten Patchs erstellt wurden, enthalten. In einer Ausführungsform weist der sichere Speicher 118 nicht genügend Speichervermögen auf, um alle zuvor erwähnten Patches und/oder Zwischenprodukte aufzunehmen, und kann gleichzeitig lediglich Teile des codierten Patchs, des decodierten Patchs und/oder der Zwischenprodukte enthalten.
In einer Ausführungsform ist der sichere Speicher 118 ein fest zugeordneter RAM-Speicher, der entweder im Prozessor 110 oder außerhalb des Prozessors 118, der nur für sichere Vorgänge verwendet wird, angeordnet sein kann. In einer anderen Ausführungsform ist der sichere Speicher 118 ein fest zugeordneter Cache-Speicher des Prozessors 110 und der Zugriff auf den fest zugeordneten Cache-Speicher ist für alle anderen Vorgänge während des Decodierens, Validierens und Installierens des Patchs blockiert. Andere Ausführungsformen können andere Verfahren zur Bereitstellung des sicheren Speichers 118 während der beschriebenen Vorgänge anwenden.
Obwohl das System 100 eine bestimmte Ausführungsform darstellt, können auch andere Ausführungsformen verwendet werden. In einer Ausführungsform beispielsweise kann das BIOS 132 in den Prozessor 110 eingebunden sein und eine andere Ausführungsform weist möglicherweise keinen Chipsatz 130 auf.
In einer Ausführungsform sind die Schlüssel 116 ein oder mehrere Sicherheitsschlüssel (Werte, die beim Codieren und/oder Decodieren verwendet werden), die in den Prozessor 110 eingebettet worden sind. Eingebettete "Schlüssel" werden im Prozessor 110 auf eine derartige Weise eingebaut, daß verhindert wird, daß sie von der Software des Systems 100 geändert und von nicht sicherer Software gelesen werden. In einer bestimmten Ausführungsform können eingebettete Schlüssel nicht direkt von einer beliebigen Software gelesen werden, ein oder mehrere bestimmte Befehle können jedoch bewirken, daß ein spezifischer eingebetteter Schlüssel zur Verwendung in einer Decodiersequenz in eine andere Hardware übertragen wird.
In einer Ausführungsform ist ein bestimmter eingebetteter Schlüssel einer der zwei Schlüssel für einen asymmetrischen kryptographischen Algorithmus, wobei der andere der zwei Schlüssel in dem Patch-Herkunftssystem unter sicherer Kontrolle behalten wird. In einer anderen Ausführungsform enthält ein bestimmter eingebetteter Schlüssel einen Hash-Wert eines öffentlichen Schlüssels für einen asymmetrischen kryptographischen Algorithmus, wobei der öffentliche Schlüssel mit dem zugehörigen Patch geliefert wird. Andere Ausführungsformen können andere Arten von Schlüsseln als eingebettete Schlüssel beinhalten.
In manchen Ausführungsformen befindet sich der Mikrocode 112 in einem nichtflüchtigem Speicher, wie beispielsweise einem Festspeicher (read-only memory, ROM), und kann nach der Herstellung nicht direkt geändert werden. Ein Patch kann in den Patch-Speicher 114 für den Systembetrieb gesetzt werden, so daß, als Reaktion auf einen Hinweis auf einen Abschnitt des modifizierten Mikrocodes, der Hinweis zum Patch-Speicher 114 umgeleitet wird, um auf den modifizierten Mikrocode zuzugreifen. In einer Ausführungsform enthält der Patch-Speicher 114 einen RAM und der Patch wird jedes Mal, wenn das System 100 zurückgesetzt und/oder neu gestartet wird, im RAM des Patch-Speichers 114 installiert. In einer anderen Ausführungsform enthält der Patch-Speicher 114 eine nichtflüchtige Speicherform, wie beispielsweise einen Flash-Speicher, und jeder Patch bleibt, nachdem er installiert wurde, im Patch-Speicher 114 intakt, bis der Patch durch einen nachfolgenden Patch ersetzt wird.
Vor der Installation kann ein codierter Patch in einem nichtflüchtigen Speicher, wie beispielsweise dem BIOS 132 oder auf der Festplatte 140, gespeichert werden, um jedes Mal, wenn der Patch im Patch-Speicher 114 installiert wird, decodiert und validiert zu werden. In einer Ausführungsform kann ein Patch von einem BIOS-Anbieter im BIOS 132 gespeichert und mittels BIOS-residentem Code während eines anfänglichen Startvorgangs installiert werden. In einer anderen Ausführungsform kann ein Patch von einem Betriebssystem-Anbieter auf der Festplatte gespeichert und zu einem späteren Zeitpunkt beim Startvorgang mittels eines Betriebssystemstart-Ladeprogramms installiert werden. Beide Ausführungsformen können im selben System kombiniert werden.
In einer Ausführungsform werden Patches über eine Kommunikationsverbindung (z. B. das Internet) geliefert, über die Kommunikationsschnittstelle 160 empfangen und zur Verwendung gespeichert. In anderen Ausführungsformen können Patches über andere Mittel geliefert werden.
2 zeigt ein Blockschema eines Systems zum Umwandeln von Patches in eine für die Lieferung sichere Form gemäß einer Ausführungsform der Erfindung. In der dargestellten Ausführungsform von 2 enthält das System 200 einen Prozessor 210, einen Chipsatz 230, eine Festplatte 240, einen Hauptspeicher 250 und eine Kommunikationsschnittstelle 260. Die grundlegenden Funktionen jeder dieser Einrichtungen können ihren Gegenstücken in 1 ähnlich sein. Das System 200 befindet sich jedoch, als Ausgangspunkt von Patches, in einer Ausführungsform in einer schätzbaren zentralisierten Installation, in der ein Schutz gegen Angreifer für das gesamte System 200 bereitgestellt werden kann. In der dargestellten Ausführungsform kann dieser Schutz durch einen sicheren Perimeter 270 bereitgestellt sein. Der Ausdruck "Perimeter" bedeutet, so wie er hierin verwendet wird, eher konzeptionell als physisch und der sichere Perimeter 270 kann zahlreiche Schutzmaßnahmen enthalten, einschließlich u. a. physischem Schutz des Systems 200, beschränktem Zugriff vom Personal auf das System 200, einer Firewall oder anderer Schutzsoftwareeinrichtungen, um nicht autorisierten Eingriff in das System durch die Kommunikationsschnittstelle 260 usw. zu verhindern. Das System 200 kann auch interne Sicherheitsfunktionen, die den in 1 gezeigten ähneln, einsetzen. In einer Ausführungsform wird das System 200 zum Erstellen von Patchpaketen für eine einzige Art von Zielsystem verwendet. In einer anderen Ausführungsform wird das System 200 zum Erstellen unterschiedlicher Patchpakete für mehrere Arten von Zielsystemen verwendet.
Der Code für die Patches kann entweder im System 200 erstellt werden oder an anderer Stelle erstellt und zum System 200 zur Vorbereitung der zugehörigen Patchpakete geliefert werden. Zu verwendende und im System 200 zu speichernde Informationen können u. a. nicht verschlüsselte Patches 244, verschlüsselte Patches 242 und/oder zugehörige Schlüssel 246 enthalten, die alle als auf der Festplatte 240 gespeichert gezeigt sind. Da unterschiedliche Zielsysteme unterschiedliche Patches erfordern können und unterschiedliche Schlüssel umfassen, kann die Festplatte 240 in verschiedene Speicherbereiche segmentiert werden, wobei jeder Speicherbereich für einen separaten Satz von Patches und zugehörigem Schlüssel/zugehörigen Schlüsseln ist.
3 zeigt ein Patchpaket, das vom System von 2 zum System von 1 lieferbare Elemente enthält, gemäß einer Ausführungsform der Erfindung. In einer Ausführungsform enthält ein Patchpaket 300 einen Patchkopf 310, ein Patch 320 und eine digitale Signatur 330. Eine andere Ausführungsform kann auch einen oder mehrere lieferbare Schlüssel 340 beinhalten. Der Patchkopf 310 enthält identifizierende Informationen, die u. a. eine oder mehrere der folgenden Informationen identifizieren können: die Art des Zielsystems, für das der Patch gedacht ist, die Art des Patchs, wo der Patch verwendet werden soll, wie der Patch verwendet werden soll und eine beliebige andere relevante Information, die von dem Zielsystem 100 möglicherweise benötigt wird. In einer Ausführungsform ist der Patchkopf 310 nicht verschlüsselt, um die Identifizierung und Anordnung des Patchpakets 300 durch das Zielsystem 100 vor der Authentifizierung und/oder Entschlüsselung des Patchs zu erleichtern. Der Patch 320 enthält den Mikrocode zum Setzen in den Patch-Speicher 114, obwohl der Patch 320 in verschlüsselter Form sein kann, während er sich im Patchpaket 300 befindet. Die Verschlüsselung des Patchs 320 kann verwendet werden, um Geschäftsgeheimnisse oder andere vertrauliche Informationen, die vom Patch selbst abgeleitet sein könnten, zu schützen. Die digitale Signatur 330 beinhaltet Daten zum Validieren der Authentizität des zu installierenden Patchs, so daß eine Änderung des Patchs nach der Vorbereitung des Patchpakets erkannt werden kann. In einer Ausführungsform wird die digitale Signatur 330 lediglich für den Patch 320 erstellt. In einer anderen Ausführungsform wird die digitale Signatur 330 sowohl für den Patch 320 als auch für den Patchkopf 310 erstellt, so daß eine nicht autorisierte Veränderung an einem dieser beiden vom Zielsystem 100 erkannt werden kann. In noch anderen Ausführungsformen kann die digitale Signatur 330 auch für andere Komponenten des Patchpakets 300 erstellt werden.
In einer Ausführungsform werden alle vom Zielsystem 100 benötigten Schlüssel bei der Herstellung in den Prozessor 110 eingebettet. Bei einer bestimmten derartigen Ausführungsform enthält das Patchpaket 300 keinerlei Schlüssel, die zum Decodieren des Patchs verwendet weiden sollen. In einer anderen bestimmten Ausführungsform werden einer oder mehrere der vom System 100 zu verwendenden Schlüssel als ein Teil des Patchpakets 300 an das System 100 geliefert und werden hierin als lieferbare Schlüssel 340 (der Plural des Ausdrucks "Schlüssel" umfasst ebenfalls Ausführungsformen, die nur einen einzigen lieferbaren Schlüssel aufweisen) bezeichnet. Die lieferbaren Schlüssel 340 können anderen Schlüsseln, die entweder im Zielsystem 100 oder im Herkunftssystem 200 verwendet werden, zugeordnet sein. In einer bestimmten Ausführungsform beispielsweise enthält ein lieferbarer Schlüssel den öffentlichen Schlüssel eines Paars aus öffentlichem Schlüssel und privatem Schlüssel in einem asymmetrischen kryptographischen Algorithmus, wobei der private Schlüssel im Herkunftssystem 200 verbleibt, und ein vom öffentlichen Schlüssel abgeleiteter Hash-Wert wird in den Prozessor 100 eingebettet und zum Validieren der Authentizität des gelieferten öffentlichen Schlüssels verwendet. Ein eingebetteter Hash-Wert kann auch zum Validieren eines oder mehrerer Schlüssel verwendet werden, die durch andere Mittel bereitgestellt wurden, z. B. ein oder mehrere mit einem Betriebssystem-Upgrade auf die Festplatte gesetzte oder mit einem BIOS-Upgrade in das BIOS gesetzte Schlüssel. Andere Ausführungsformen können andere Kombinationen aus Schlüsseln und Verschlüsselungsschemata verwenden. Jedes der Elemente des Patchpakets 300 wird in der Offenbarung im Folgenden ausführlicher beschrieben.
In noch einer anderen Ausführungsform kann ein eingebetteter Schlüssel oder Hash-Wert mit einer Kette von Schlüsselzertifikaten verwendet werden. In einer derartigen Ausführungsform wird der eingebettete Schlüssel bzw. Hash-Wert zum Validieren eines zweiten Schlüssels verwendet, der zum Validieren eines dritten Schlüssels verwendet wird, usw., wodurch mehrere Sicherheitsschichten bereitgestellt werden, wobei jeder Schlüssel einer bestimmten Schicht zugeordnet ist. Die Schlüssel können über eines oder mehrere der zuvor erwähnten Lieferverfahren und/oder über nicht beschriebene Verfahren geliefert werden.
4 zeigt ein Ablaufdiagramm eines Gesamtprozesses zum Vorbereiten, Liefern und Validieren eines Patchpakets gemäß einer Ausführungsform der Erfindung. In der dargestellten Ausführungsform von 4 weist das Ablaufdiagramm 400 zwei Teile auf. Die Blöcke 410 bis 430 zeigen einen Patchschaffungsprozess, in dem ein Patch-Herkunftssystem einen bestehenden Patch für eine sichere Lieferung vorbereitet. Die Blöcke 440 bis 495 zeigen einen Patchvalidierungs- und -installationsprozess, der im Zielsystem durchgeführt wird.
In einer Ausführungsform beginnt der Patchschaffungsprozess mit dem Verschlüsseln des Patchs in Block 410. Wie zuvor erwähnt, verschlüsseln manche Ausführungsformen den Patch möglicherweise nicht, da der Inhalt des Patchs nicht als vertraulich erachtet wird und keinen Schutz benötigt. Gleich ob der Patch verschlüsselt ist oder nicht, können die Vorgänge der Blöcke 420 und 430 zum Zulassen des Erkennens einer Manipulation des Patchs vor seiner Installation im Zielsystem verwendet werden. In Block 420 wird eine digitale Signatur für den Patch erstellt. In einer Ausführungsform wird die digitale Signatur sowohl für den Patchkopf als auch den Patch erstellt, so daß keiner dieser beiden manipuliert werden kann, ohne daß dies erkannt wird. In einer anderen Ausführungsform wird die digitale Signatur für den Patch, nicht jedoch für den Patchkopf erstellt. In noch einer anderen Ausführungsform wird die digitale Signatur auch für die lieferbaren Schlüssel erstellt. In Block 430 werden die digitale Signatur und der Patch, zusammen mit beliebigen anderen eingebundenen Elementen, kombiniert, um ein Patchpaket zu bilden.
Wenn der Patch in Block 410 verschlüsselt wurde, wird der verschlüsselte Patch in Block 430 eingebunden.
Nachdem das Patchpaket erstellt wurde, kann das Patchpaket über ein beliebiges praktikables Mittel an das Zielsystem geliefert werden. Der Patchvalidierungs- und -installationsprozess, der im Zielsystem stattfindet, beginnt in Block 440 damit, daß das Patchpaket empfangen und gespeichert wird. Das Patchpaket kann auf der Festplatte 140, im BIOS 132 oder in einem beliebigen praktikablen Speicherort im Zielsystem 100 gespeichert werden.
In einer Ausführungsform werden Patches nicht in einem betriebsbereiten Zustand installiert, bevor das System gestartet wird; ein Prozess, der in Block 450 beginnt. In Block 460 wird die digitale Signatur aus dem Patchpaket entschlüsselt und in Block 470 zum Validieren des Patchs verwendet. Die Entschlüsselung und Validierung kann eine beliebige von mehreren im Folgenden beschriebenen Formen annehmen. Wenn der Patch in Block 410 verschlüsselt wurde, wird er in Block 480 entschlüsselt, um den tatsächlichen Patch freizulegen. In Block 490 wird der freigelegte Patch im Prozessor 110 so installiert, daß er betriebsbereit gemacht wird. In Block 495 kann der Prozessor 110 unter Verwendung des gepatchten Mikrocodes arbeiten.
5 zeigt ein Ablaufdiagramm eines Prozesses zum Vorbereiten eines Patchpakets gemäß einer Ausführungsform der Erfindung. Das Ablaufdiagramm 500 zeigt eine detailliertere Beschreibung des Patchschaffungsprozesses von 4. Die in 5 gezeigte Ausführungsform beinhaltet ein Verschlüsseln des Patchs und das Erstellen eines Digests (Auszugs), der zum Validieren, daß der empfangene Patch korrekt ist, verwendet werden soll. In einer Ausführungsform wird die Verschlüsselung des Patchs mit einem symmetrischen Verschlüsselungsalgorithmus (z. B. AES, DES usw.) durchgeführt. Ein Digest, so wie er hierin verwendet wird, ist ein Parameter, der beim Durchführen eines Vorgangs an einem Datenblock erhalten wurde, wobei identische Datenblöcke identischen Digests erzeugen, eine beliebige Änderung des Datenblocks jedoch wahrscheinlich einen anderen Digest erzeugt. In einer Ausführungsform ist der Digest ein Hash-Digest, d. h. ein Digest, der beim Anwenden eines Hashing-Algorithmußes auf den Patch erstellt wurde. In einer Ausführungsform wird zunächst der Digest erstellt und dann der Patch verschlüsselt, während in einer anderen Ausführungsform zunächst der Patch verschlüsselt und dann der Digest für den verschlüsselten Patch erstellt wird.
5 zeigt beide Ausführungsformen. In der ersten Ausführungsform werden der unverschlüsselte Patch und der Patchkopf in Block 510 einem Hash-Prozess unterzogen, um einen Digest zu erstellen. In einer bestimmten Ausführungsform verwendet der Hash-Prozess den Secure Hash Algorithm (SHA-1, sicherer Hash-Algorithmus), der 1994 unter der Bezeichnung Federal Information Publishing Standard FIPS PUB 180-1 veröffentlicht wurde. Anschließend wird der Patch in Block 520 verschlüsselt. Wenn der Patch nicht verschlüsselt werden soll, kann Block 520 weggelassen werden. In der zweiten Ausführungsform wird der Patch in Block 530 zunächst verschlüsselt und der verschlüsselte Patch und der Patchkopf werden in Block 540 dem Hash-Prozess unterzogen, um den Digest zu erstellen. In beiden Ausführungsformen kann der Digest, wenn ein anschließender Vorgang erforderlich macht, daß der Digest aus einer bestimmten Anzahl von Bits besteht, in Block 550 aufgefüllt werden (d. h. ihm werden Daten hinzugefügt), um die Anzahl von Bits nach Bedarf zu erhöhen. Die Auffüllung kann aus vorbestimmten Daten oder Zufallsdaten bestehen. Der aufgefüllte Digest wird in Block 560 verschlüsselt, um eine digitale Signatur zu erstellen. In einem Beispiel wird der aufgefüllte Digest unter Verwendung des privaten Schlüssels eines Paars aus öffentlichem Schlüssel und privatem Schlüssel in einem asymmetrischen Verschlüsselungsprozess verschlüsselt. In einer bestimmten Ausführungsform hält die Verschlüsselung den RSA-Verschlüsselungsprozess unter Verwendung eines privaten Schlüssels von 2048 Bit ein. Wie wohl bekannt ist, weisen der Schlüssel und die verschlüsselte Nachricht im RSA-Verschlüsselungsprozess die gleiche Anzahl von Bits auf, was erforderlich macht, daß der Digest in Block 550 aufgefüllt wird, wenn der Digest kleiner als der Schlüssel ist. In einer anderen Ausführungsform weisen der Digest und der Schlüssel bereits die gleiche Größe auf und das Auffüllen in Block 550 kann eliminiert werden. In noch einer anderen Ausführungsform wird ein Verschlüsselungsverfahren verwendet, in dem der Schlüssel und die Nachricht nicht die gleiche Größe aufweisen müssen, wobei in diesem Fall das Auffüllen in Block 550 ebenfalls eliminiert werden kann. Die digitale Signatur, der Patch (verschlüsselt oder unverschlüsselt) und der Patchkopf werden in Block 570 zu einem Patchpaket für eine Lieferung an das Zielsystem kombiniert. In einer Ausführungsform kann das Patchpaket außerdem je nach den Systemanforderungen andere Informationen enthalten.
6 zeigt ein Ablaufdiagramm eines Prozesses zum Validieren eines Patchpakets gemäß einer Ausführungsform der Erfindung. Das Ablaufdiagramm 600 zeigt eine detailliertere Beschreibung des Patchvalidierungs- und -Installationsprozesses von 4. Das Patchpaket wird in Block 610 aus dem Zielsystem bezogen. In einer Ausführungsform wurde das Patchpaket zuvor vom Zielsystem empfangen und in den Speicher gesetzt und wird aus diesem Speicher bezogen. In einer anderen Ausführungsform wird das Patchpaket in Block 610 bezogen, sobald es vom Zielsystem empfangen wird, ohne daß es zwischengespeichert wird. Während in einer Ausführungsform das gesamte Patchpaket, so wie es vom Herkunftssystem geliefert wurde, bezogen wird, werden in einer anderen Ausführungsform etwaige nicht erforderliche Elemente des Pakets herausgezogen, bevor das Patchpaket bezogen wird.
In einer Ausführungsform, in der ein Schlüssel im Patchpaket geliefert wird, kann in Block 612 ein Hash-Wert für den Schlüssel berechnet werden. Wenn dieser berechnete Hash-Wert mit einem im Prozessor 110 eingebetteten, zugehörigen Hash-Wert übereinstimmt, ist der Schlüssel validiert worden und kann in nachfolgenden Validierungsvorgängen verwendet werden. Wenn der berechnete Hash-Wert nicht mit dem eingebetteten Hash-Wert übereinstimmt, schlägt die Validierung fehl und die Steuerung kann zum Block 690 fortschreiten, der im Folgenden beschrieben wird. In einer Ausführungsform, die keinen gelieferten Schlüssel umfasst, können die Vorgänge der Blöcke 612 und 614 weggelassen werden.
Die digitale Signatur wird in Block 620 entschlüsselt, um den im Herkunftssystem erstellten Digest zu beziehen. In einer Ausführungsform wurde die digitale Signatur mit einem asymmetrischen Verschlüsselungsalgorithmus unter Verwendung des privaten Schlüssels eines Paars aus öffentlichem Schlüssel und privatem Schlüssel erstellt und die Entschlüsselung des Blocks 620 wird unter Verwendung des zugehörigen öffentlichen Schlüssels durchgeführt. Wenn der Digest während der Erstellung aufgefüllt wurde, bezieht der Vorgang des Blocks 620 den aufgefüllten Digest und die Auffüllung wird in Block 630 entfernt, um den Digest freizulegen, der zuvor in Block 510 oder 540 erstellt wurde. Wenn der Digest während der Erstellung nicht aufgefüllt wurde, erzeugt der Vorgang des Blocks 620 einen nicht-aufgefüllten Digest und der Block 630 kann weggelassen werden.
Zu diesem Zeitpunkt folgte der Prozess in Abhängigkeit davon, ob der Digest erstellt wurde, bevor oder nachdem der Patch im Ablaufdiagramm 500 verschlüsselt wurde. In einer Ausführungsform, in der der Digest vor der wie in den Blöcken 510 und 520 gezeigten Verschlüsselung erstellt wurde, wird der Patch in Block 640 entschlüsselt und es wird in Block 650 eine Hash-Funktion am entschlüsselten Patch und Patchkopf durchgeführt, um einen berechneten Digest zu erhalten. Der berechnete Digest wird in Block 660 mit dem tatsächlichen, in den Blöcken 620–630 bezogenen Digest verglichen, um zu überprüfen, ob die zwei Digests übereinstimmen. Wenn die zwei Digests gleichwertig sind, ist der Patch validiert worden und kann in Block 680 installiert werden. In einer Ausführungsform beinhaltet das Installieren des Patchs das Setzen des Patchs in den Patch-Speicher 114 des Prozessors 110, so daß ein etwaiger versuchter Zugriff auf den gepatchten Mikrocode anstatt zum ursprünglichen Mikrocode 112 zum Patch-Speicher 114 geleitet wird.
Nun wieder mit Bezugnahme auf Block 630 kann in einer Ausführungsform, in der der Patch vor der Erstellung des Digests in den Blöcken 530 und 540 verschlüsselt wurde, der verschlüsselte Patch und Kopf in Block 645 einem Hash-Vorgang unterzogen werden, um den berechneten Digest zu erhalten. Der berechnete Digest kann in Block 665 mit dem tatsächlichen, in Block 630 aufgedeckten Digest verglichen werden, um zu überprüfen, ob sie übereinstimmen. Wenn festgestellt wird, daß sie gleichwertig sind, ist der Patch validiert worden und kann in Block 670 entschlüsselt werden. Der validierte und entschlüsselte Patch kann dann in Block 680 installiert werden. In beiden Ausführungsformen handelt es sich bei dem in den Blöcken 645, 650 verwendeten Hash-Vorgang um denselben Hash-Vorgang, der in den Blöcken 510, 540 verwendet wurde.
Wenn der berechnete Digest in entweder Block 660 oder Block 665 nicht mit dem tatsächlichen Digest übereinstimmt, weist dies darauf hin, daß das Patchpaket seit dessen Erstellung verändert wurde oder auf andere Weise für die Installation nicht geeignet ist. Eine derartige Veränderung/Nichteignung kann mehrere Ursachen haben, einschließlich u. a.: eines vorsätzlichen Versuchs von einer nicht autorisierten Person, den Patch zu ändern, eines nicht erkannten/nicht korrigierten Datenübertragungsfehlers während der Lieferung, der Lieferung des Patchpakets an ein falsches Zielsystem, eines Software- oder Hardwareversagens oder menschlichen Versagens. Ungeachtet der Ursache kann der Patchinstallationsprozess, wenn der tatsächliche Digest nicht mit dem berechneten Digest übereinstimmt, in Block 690 abgebrochen werden, indem der nicht validierte Patch nicht installiert wird. Das Abbrechen der Patchinstallation kann mehrere Formen annehmen, einschließlich u. a.: I) des Versuchs, den Patch neu zu installieren, 2) des Auslassens des defekten Patchs, aber Installieren anderer Patches, 3) des Zurücksetzens auf eine vorherige Version des Patchs, 4) des Herunterfahrens des Systems, 5) des Neustarts des Systems, 6) usw.
In einer Ausführungsform wird der Validierungsprozess der Blöcke 610–670 für den gesamten Patch im sicheren Speicher 118 durchgeführt und der gesamte Patch wird nach der Validierung in Block 680 im Patch-Speicher 114 installiert. In einer anderen Ausführungsform, in der der sichere Speicher 118 nicht genügend Speichervermögen aufweist, um den gesamten Validierungsprozess auszuführen, kann der Validierungsprozess der Blöcke 610–670 schrittweise an separaten Abschnitten des Patchs durchgeführt werden. Wenn ein beliebiger Abschnitt nicht auf diese Weise validiert wird, kann der Prozess in Block 690 wie zuvor beschrieben abgebrochen werden. Wenn alle Abschnitte auf diese Weise validiert werden, kann der Patch ein zweites Mal schrittweise validiert werden, wobei jeder Abschnitt im Patch-Speicher 114 installiert wird, wenn er validiert wird. Wenn ein beliebiger Abschnitt des Patchs beim zweiten Durchgang nicht validiert wird (was darauf hinweisen könnte, daß er nach der ersten Validierung manipuliert wurde), kann der Prozess in Block 690 abgebrochen werden. Wenn der Patch teilweise installiert worden ist, bevor in Block 690 abgebrochen wurde, kann der Abbruchprozess des Blocks 690 zusätzlich zu einem oder mehreren der zuvor aufgeführten Abbruchprozesse das Entfernen des neu installierten Patchs vom Patch-Speicher 114 beinhalten.
Die vorhergehende Beschreibung soll veranschaulichend und nicht einschränkend sein. Fachmännern werden Variationen in den Sinn kommen. Diese Variationen sollen Teil der verschiedenen Ausführungsformen der Erfindung sein, wobei diese Erfindung nur durch den Sinn und Schutzumfang der angehängten Ansprüche eingeschränkt ist.
ZUSAMMENFASSUNG
Mikrocodepatches werden vor der Lieferung zu einem Zielprozessor codiert, der die Mikrocodepatches installieren soll. Der Zielprozessor validiert die Mikrocodepatches vor der Installation. Die Sicherheit des Prozessors kann durch eine oder mehrere der folgenden Maßnahmen verbessert werden: (1) Ausführen der Validierung in einem sicheren Speicher, (2) Verwenden eines öffentlich/privaten Schlüsselpaars für die Verschlüsselung und Entschlüsselung des Mikrocodepatchs, (3) Verwenden mindestens eines Schlüssels, der in dem Zielprozessor eingebettet ist und durch nicht sichere Software nicht gelesen werden kann und (4) Verwenden eines Hash-Werts, der in dem Zielprozessor eingebettet ist, um zumindest einen nicht eingebetteten Schlüssel zu validieren.

Claims

Maschinenlesbares Medium, das Befehle bereitstellt, die, wenn sie von einem Satz von einem oder mehreren Prozessoren ausgeführt werden, bewirken, daß der Satz von Prozessoren Vorgänge durchführt, die Folgendes umfassen: Erstellen eines Hash-Digests für einen Mikrocodepatch; Verschlüsseln des Hash-Digests zum Erstellen einer digitalen Signatur; und Kombinieren der digitalen Signatur und des Mikrocodepatchs zum Liefern an einen Zielprozessor, um Mikrocode im Zielprozessor zu patchen.
Medium nach Anspruch 1, wobei: das Kombinieren das Kombinieren eines Schlüssels mit der digitalen Signatur und dem Mikrocodepatch für die Lieferung an den Zielprozessor beinhaltet.
Medium nach Anspruch 1, wobei: das Kombinieren das Kombinieren eines Hash-Werts eines Schlüssels mit der digitalen Signatur und dem Mikrocodepatch für die Lieferung an den Zielprozessor beinhaltet.
Verfahren, das Folgendes umfaßt: Erstellen eines Hash-Digests für einen Mikrocodepatch; Verschlüsseln des Hash-Digests mit einem privaten Schlüssel für einen asymmetrischen kryptographischen Algorithmus, um eine digitale Signatur zu erstellen; und Kombinieren der digitalen Signatur und des Mikrocodepatchs zum Liefern an einen Prozessor, um Mikrocode des Prozessors zu patchen.
Verfahren nach Anspruch 4, das weiterhin Folgendes umfaßt: Verschlüsseln des Mikrocodepatchs; wobei das Erstellen des Hash-Digests das Erstellen des Hash-Digests vor dem Verschlüsseln des Mikrocodepatchs beinhaltet; und wobei das Kombinieren das Kombinieren der digitalen Signatur mit dem verschlüsselten Mikrocodepatch beinhaltet.
Verfahren nach Anspruch 4, das weiterhin Folgendes umfaßt: Verschlüsseln des Mikrocodepatchs; wobei das Erstellen des Hash-Digests das Erstellen des Hash-Digests nach dem Ver schlüsseln des Mikrocodepatchs beinhaltet; und wobei das Kombinieren das Kombinieren der digitalen Signatur mit dem verschlüsselten Mikrocodepatch beinhaltet.
Maschinenlesbares Medium, das Daten enthält, die Folgendes umfassen: einen Mikrocodepatch zum Patchen von Mikrocode in einem Zielsystem; und eine digitale Signatur, die durch Verschlüsseln eines Digests, der durch Ausführen eines Hash-Vorgangs am Mikrocodepatch erstellt wurde, erzeugt wurde.
Medium nach Anspruch 7, wobei die Daten weiterhin Folgendes umfassen: einen Schlüssel zum Entschlüsseln der digitalen Signatur, um den Digest zu erzeugen.
Medium nach Anspruch 7, wobei die Daten weiterhin Folgendes umfassen: einen Hash-Wert eines Schlüssels zum Validieren des Mikrocodepatchs.
Medium nach Anspruch 7, wobei: der Mikrocodepatch verschlüsselt ist.
Gerät, das Folgendes umfaßt: einen Prozessor, der Mikrocode aufweist; einen sicheren Speicher, der mit dem Prozessor gekoppelt ist, um einen codierten Mikrocodepatch zu decodieren; und einen Mikrocodepatch-Speicher, der an den Mikrocode gekoppelt ist, um den decodierten Mikrocodepatch zu enthalten.
Gerät nach Anspruch 11, wobei: der Mikrocode Mikrobefehle enthält, um den codierten Mikrocodepatch zu decodieren; und der sichere Speicher den codierten Mikrocodepatch, den decodierten Mikrocodepatch und/oder Zwischenprodukte während des Decodierens des Mikrocodepatchs zu enthalten hat.
Gerät nach Anspruch 11, wobei: der Mikrocode Mikrobefehle enthält, um den codierten Mikrocodepatch zu decodieren; und der sichere Speicher gleichzeitig nicht mehr als einen Abschnitt des codierten Mikrocodepatchs, des decodierten Mikrocodepatchs und/oder von Zwischenprodukten während des Decodierens des Mikrocodepatchs zu enthalten hat.
Gerät nach Anspruch 11, wobei: der Prozessor einen eingebetteten Schlüssel zur Verwendung zum Decodieren des codierten Mikrocodepatchs enthält.
Gerät nach Anspruch 14, wobei: der eingebettete Schlüssel ein öffentlicher Schlüssel in einem asymmetrischen kryptographischen Algorithmus ist.
Verfahren, das Folgendes umfaßt: Beziehen eines Mikrocodepatchs und einer zugehörigen digitalen Signatur; Entschlüsseln der digitalen Signatur in einem sicheren Speicher, um einen ersten Hash-Digest zu erhalten; Berechnen eines zweiten Hash-Digests mit dem Mikrocodepatch; Vergleichen des ersten Hash-Digests mit dem zweiten Hash-Digest; und Installieren des Mikrocodepatchs in einem Mikrocodepatch-Speicher in Reaktion auf eine Übereinstimmung zwischen dem ersten und dem zweiten Hash-Digest.
Verfahren nach Anspruch 16, das weiterhin Folgendes umfaßt: Entschlüsseln des Mikrocodepatchs; wobei das Berechnen des zweiten Hash-Digests das Berechnen des zweiten Hash-Digests mit einer verschlüsselten Version des Mikrocodepatchs beinhaltet.
Verfahren nach Anspruch 16, das weiterhin Folgendes umfaßt: Entschlüsseln des Mikrocodepatchs; wobei das Berechnen des zweiten Hash-Digests das Berechnen des zweiten Hash-Digests mit einer entschlüsselten Version des Mikrocodepatchs beinhaltet.
Verfahren nach Anspruch 16, wobei: das Entschlüsseln der digitalen Signatur das Durchführen einer asymmetrischen Entschlüsselung unter Verwendung eines öffentlichen Schlüssels beinhaltet.
Verfahren nach Anspruch 16, wobei: das Entschlüsseln der digitalen Signatur das Verwenden eines eingebetteten Schlüssels beinhaltet.
Verfahren nach Anspruch 16, wobei: das Entschlüsseln der digitalen Signatur das Durchführen einer asymmetrischen Entschlüsselung unter Verwendung eines mit dem Mikrocodepatch bereitgestellten Schlüssels beinhaltet.
Maschinenlesbares Medium, das Befehle bereitstellt, die, wenn sie von einem Satz von einem oder mehreren Prozessoren ausgeführt werden, bewirken, daß der Satz von Prozessoren Vorgänge durchführt, die Folgendes umfassen: Beziehen eines Mikrocodepatchs und einer zugehörigen digitalen Signatur; Entschlüsseln der digitalen Signatur, um einen ersten Hash-Digest zu erhalten; Berechnen eines zweiten Hash-Digests mit dem Mikrocodepatch; Vergleichen des ersten Hash-Digests mit dem zweiten Hash-Digest; und Installieren des Mikrocodepatchs in Reaktion auf eine Übereinstimmung zwischen dem ersten und dem zweiten Hash-Digest.
Medium nach Anspruch 22, das weiterhin Folgendes umfaßt: Entschlüsseln des Mikrocodepatchs; wobei das Berechnen des zweiten Hash-Digests das Berechnen des zweiten Hash-Digests mit einer verschlüsselten Version des Mikrocodepatchs beinhaltet.
Medium nach Anspruch 22, das weiterhin Folgendes umfaßt: Entschlüsseln des Mikrocodepatchs; wobei das Berechnen des zweiten Hash-Digests das Berechnen des zweiten Hash-Digests mit einer entschlüsselten Version des Mikrocodepatchs beinhaltet.
Medium nach Anspruch 22, wobei: das Entschlüsseln der digitalen Signatur das Durchführen einer asymmetrischen Entschlüsselung unter Verwendung eines öffentlichen Schlüssels beinhaltet.
Medium nach Anspruch 22, wobei: das Entschlüsseln der digitalen Signatur das Durchführen einer asymmetrischen Entschlüsselung unter Verwendung eines eingebetteten Schlüssels beinhaltet.
Medium nach Anspruch 22, wobei: das Entschlüsseln der digitalen Signatur das Durchführen einer asymmetrischen Entschlüsselung unter Verwendung eines mit dem Mikrocodepatch und der zugehörigen digitalen Signatur bereitgestellten Schlüssels beinhaltet.
System, das Folgendes umfaßt: einen Prozessor, der Mikrocode und einen eingebetteten Schlüssel aufweist; und ein Mikrocodepatchpaket, das sich in einer Speichereinrichtung und/oder einem BIOS (basic input-output system, einfaches Eingabe/Ausgabesystem) befindet, die/das mit dem Prozessor gekoppelt ist, wobei das Mikrocodepatchpaket einen Mikrocodepatch zum Patchen des Mikrocodes und eine digitale Signatur zum Validieren des Mikrocodepatchs unter Verwendung des eingebetteten Schlüssels enthält.
System nach Anspruch 28, wobei: der Mikrocodepatch in einer verschlüsselten Form im Mikrocodepatchpaket vorliegt.
System nach Anspruch 28, das weiterhin Folgendes umfaßt: einen sicheren Speicher zum Enthalten des Mikrocodepatchs während der Validierung.