DE10393662T5

DE10393662T5 - Bereitstellen eines sicheren Ausführungsmodus in einer Preboot-Umgebung

Info

Publication number: DE10393662T5
Application number: DE10393662T
Authority: DE
Inventors: Bryant Scottsdale Bigbee; Mark Olympia Doran; Andrew Olympia Fish; Vincent Federal Way Zimmer
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2002-11-27
Filing date: 2003-10-20
Publication date: 2005-08-25
Also published as: US9026773B2; WO2004051444A3; CN100511086C; TWI238357B; GB0604785D0; GB2411989B; CN1714331A; GB2421612B; TW200414052A; GB2421612A; US10275598B2; AU2003286519A1; GB0506997D0; US20110271090A1; US20040103299A1; GB2411989A; US20150213269A1; HK1075509A1; US7974416B2; WO2004051444A2

Abstract

Verfahren, das umfaßt:
Herstellen einer sicheren Preboot-Umgebung in einem Computersystem; und
Durchführen mindestens einer sicheren Operation in der sicheren Preboot-Umgebung.

Description

Stand der Technik
Die vorliegende Erfindung betrifft den Betrieb eines Computersystems und im Speziellen den Betrieb eines solchen Systems in einer Preboot-Umgebung.
Wenn ein Computersystem eingeschaltet wird, kann es die von einem Benutzer gewünschten Funktionen erst ausführen, nachdem es initialisiert wurde und die Fähigkeit zum Kommunizieren mit dem Benutzer erlangt hat. Dieser Initialisierungsvorgang umfaßt im allgemeinen einen Boot-Vorgang, der typischerweise von der Boot-Firmware durchgeführt wird. Bei der Boot-Firmware kann es sich um ein Betriebssystem ("BS"), einen Teil des BS, das BIOS ("Basic Input/Output System") oder andere Software handeln.
Die Boot-Firmware wird typischerweise in einer Art von nichtflüchtigem Speicher abgelegt und ermöglicht einer zentralen Verarbeitungseinheit ("CPU") die Ausführung von Aufgaben, wie etwa Initialisierung, Diagnose, Laden des Betriebssystemkernels von einem Massenspeicher und Eingabe-/Ausgabe-Routinefunktionen ("E/A"). Die Boot-Firmware kann in löschbarem, programmierbarem Festwertspeicher ("EPROM") oder einem ähnlichen Flash-Halbleiterspeicher abgelegt werden.
In dieser Preboot-Umgebung stehen typischerweise wenige oder gar keine Sicherheitsmaßnahmen zur Verfügung (der gesamte Code läuft im primitiven, physischen Ring-0-Modus); auch besteht typischerweise keine Möglichkeit zum Speichern eines Geheimnisses in der Preboot-Umgebung. Weiterhin besteht beim Einspringen in die BS-Umgebung von der Preboot-Umgebung aus keine Möglichkeit zur Herstellung einer sogenannten Vertrauenswurzel von der Preboot-Umgebung bis zur BS-Umgebung. Bei einer Trusted Computing Platform (TCP) gemäß der Hauptspezifikation der Trusted Computing Platform Alliance (TCPA), Version 1.16, veröffentlicht am 22. Februar 2002, kann eine derartige Vertrauenswurzel wünschenswert sein, die zuverlässige Informationen über sich selbst und ihre laufenden Softwareprozesse sowie Attestierungen bezüglich des Betriebs ihrer Softwareprozesse liefert.
Kurze Beschreibung der Zeichnungen
1 ist ein Flußdiagramm eines beispielhaften Programmflusses gemäß einer Ausführungsform der vorliegenden Erfindung.
2 ist ein Flußdiagramm einer beispielhaften Firmwareoperation gemäß einer Ausführungsform der vorliegenden Erfindung.
3 ist ein Flußdiagramm des Betriebs einer Preboot-Umgebung gemäß einer Ausführungsform der vorliegenden Erfindung.
4 ist ein Blockdiagramm eines Systems gemäß einer Ausführungsform der vorliegenden Erfindung.
Detaillierte Beschreibung
Bei einer Ausführungsform kann die vorliegende Erfindung dazu benutzt werden, eine sichere Preboot-Ausführungsumgebung eines Computersystems herzustellen. Der Begriff "Computersystem" kann sich hier und im folgenden auf eine beliebige Art von prozessorbasiertem System beziehen, wie etwa auf einen Desktop-Computer, einen Laptop-Computer, einen Server-Computer, eine Appliance, eine Set-Top-Box u. dgl. m. In bestimmten Ausführungsformen kann das Computersystem einen Prozessor in der sogenannten Intel-Architektur (IA) aufweisen, wie etwa einen IA32-Prozessor, erhältlich von der Intel Corporation, Santa Clara, Kalifornien. Es versteht sich jedoch, daß die vorliegende Erfindung in anderen Ausführungsformen in Verbindung mit anderen, derzeit bekannten oder in Zukunft aufkommenden CPU-Mikroarchitekturen benutzt werden kann.
In einer Ausführungsform kann die sichere Preboot-Ausführungsumgebung in Firmware implementiert werden, die zu der EFI-Spezifikation (engl. "Extensible Firmware Interface", dt. "erweiterbare Firmwareschnittstelle"), Version 1.02, veröffentlicht am 12. Dezember 2000 von der Intel Corporation, Santa Clara, Kalifornien konform ist.
Eine sichere Preboot-Ausführungsumgebung eines Computersystems gemäß einer Ausführungsform kann benutzt werden, um sichere Operationen durchzuführen, beispielsweise die sichere Speicherung des Geheimnisses und den anschließenden Zugriff auf das Geheimnis; dies ist auch als sichere oder isolierte Speicherung bekannt. Hier und im folgenden ist mit "Geheimnis" jede beliebige Information (Daten, Anweisungen o.a.) gemeint, die vor dem Computersystem und dem Benutzer außerhalb der sicheren Preboot-Umgebung versteckt gehalten wird. Bei solchen Geheimnissen kann es sich beispielsweise um Schlüssel, Paßwörter, Finanzinformationen, Krankenakten u. dgl. m. handeln. Der sichere Preboot-Modus kann zudem für isoliertes Ausführen benutzt werden. So wird ein Mittel bereitgestellt, um nicht vertrauenswürdigen, fehlerhaften oder böswilligen Code (kollektiv als "schädlicher Code" bezeichnet) von anderem vertrauenswürdigem, überprüfbarem Code zu trennen.
1 ist ein Flußdiagramm eines beispielhaften Programmflusses gemäß einer Ausführungsform der vorliegenden Erfindung. Wie in 1 gezeigt, bestimmt die Firmware beim Neustart eines Computersystems (Block 5), ob eine CPU dazu in der Lage ist, im Preboot-Modus einen sicheren Betrieb zu gewährleisten, d.h., ob es sich um eine CPU mit Sicherheitsfunktion handelt (Raute 10). Falls eine solche CPU vorhanden ist, kann Sicherheitsinitialisierungssoftware ausgeführt werden (Block 15). Als nächstes kann ein BIOS-SVMM (sicherer Virtual-Machine-Monitor) installiert werden (Block 20), und es kann in eine SVMM-Preboot-Umgebung eingesprungen werden. Hier und im folgenden ist mit dem Begriff "sicherer Virtual-Machine-Monitor" oder "SVMM" eine sichere Umgebung gemeint, in der auf einer einzelnen Plattform eine oder mehrere Betriebsumgebungen existieren. Im SVMM können beliebige gewünschte sichere Operationen durchgeführt werden, wie etwa sicheres Speichern und sicherer Zugriff, Aktualisierungen von Flashspeicher u. dgl. m.
Es versteht sich, daß eine "virtuelle Maschine" nicht zwingend erforderlich ist; statt dessen kann es sich bei der Software um einen sicheren Monitor handeln, wobei der "Monitor"-Gesichtspunkt die Fähigkeit zum Erkennen und Berechtigen von Zugriffen von nicht vertrauenswürdigem Code benennt. In bestimmten Ausführungsformen kann der SVMM eine Trusted-Computing-Basis (TCB) bilden; bei einer TCB handelt es sich um eine kleine, überprüfte Untermenge von Code, die von dem restlichen Code isoliert werden und dessen Verhalten steuern kann. Eine TCB kann klein entworfen werden, um eine formelle Nachprüfung der Sicherheits- und Schutzattribute durch Dritte zu begünstigen.
Als nächstes oder wenn kein Prozessor mit sicherem Modus verfügbar ist, kann der Selbsttest bei Einschalten (POST, engl. "Power on Self Test") abgeschlossen werden, und die Preboot-Umgebung wird darauf vorbereitet, das BS zu laden (Block 25). Es wird bestimmt, ob ein vertrauenswürdiger BS-Ladevorgang möglich ist (Raute 30). Wenn ein solcher Ladevorgang möglich ist, wird der BIOS-SVMM entladen (Block 35). In beiden Fällen kann das BS daraufhin die Kontrolle über das Computersystem übernehmen (Block 40).
Es versteht sich, daß der frühe Aufruf eines sicheren Betriebsmodus der CPU nicht auf einen Entwurf mit einem Virtual-Machine-Monitor (VMM), wie etwa den SVMM, beschränkt ist, sondern auch in Verbindung mit anderen CPU-Sicherheitsmodi benutzt werden kann.
In einer Ausführungsform kann die Firmware die Preboot-Operationen in einer Abfolge von Phasen durchführen. 2 ist ein Flußdiagramm einer beispielhaften Firmwareoperation gemäß einer Ausführungsform der vorliegenden Erfindung. Wie in 2 gezeigt, kann beim Starten oder Neustarten der Maschine eine Sicherheitsphase durchgeführt werden (Block 110). In der Sicherheitsphase können anfängliche Operationen nach dem Rücksetzen bzw. Einschalten der Plattform durchgeführt werden, um zu gewährleisten, daß die Integrität der Firmware intakt ist. Als nächstes kann eine Prä-EFI-Initialisierungsphase (PEI-Phase) durchgeführt werden (Block 120). In der PEI-Phase kann der Code eine minimale Konfiguration von Prozessorchipsatz und Plattform durchführen, um so das Auffinden von Speicher zu unterstützen.
Als nächstes kann eine Treiber-Ausführungsphase (DXE-Phase, engl. "driver execution") durchgeführt werden (Block 130). Dies ist die Phase, in der eine Mehrheit des Firmwarecodes in der Preboot-Umgebung arbeiten kann. In einer Ausführungsform kann der Code in Form einer Anzahl von Treibern implementiert werden, die die Initialisierung der Plattform und der Bauelemente abschließen. Schließlich kann eine Betriebssystem-Ladephase durchgeführt werden (Block 140). In dieser Phase wird das Betriebssystem geladen, und bei Abschluß dieser Phase übernimmt das Betriebssystem die Kontrolle über die Plattform.
In einer Ausführungsform kann die Firmware einen Virtual-Machine-Monitor-Treiber (VMM-Treiber) starten. Dieser Treiber kann eine Instanz des VMM-Protokolls veröffentlichen. In bestimmten Ausführungsformen kann der Treiber frühzeitig in der DXE-Phase gestartet werden und zum Zweck des Zugriffs auf den Start einer sicheren Umgebung einen SENTER-Befehl ausführen.
In einer Ausführungsform kann der VMM-Treiber einen SVMM verwirklichen, der in bestimmten Ausführungsformen skalierbare Merkmale aufweisen kann. Die Skalierbarkeit erwächst daraus, daß der VMM-Treiber befähigt ist, das Laden nachfolgender Treiber in einen sicheren Ausführungsmodus zuzulassen (diese werden hier und im folgenden als "Virtual-Machine-Erweiterungen" oder "VMX" bezeichnet). In bestimmten Ausführungsformen kann der SVMM auf einer Ebene mit höchster Privilegierung (z.B. Ring 0P in einem IA32-Verarbeitungssystem) ausgeführt werden. Alle anschließend geladenen Treiber können auf einer Ebene mit niedrigerer Privilegierung (z.B. Ring 3P in einem IA32-Verarbeitungssystem) ausgeführt werden. Des weiteren kann in Ring 3P auch aller sonstiger Code ausgeführt werden, der dazu ausgelegt ist, in der sicheren Preboot-Umgebung zu laufen, wie etwa gastgehostete Systemverwaltungsmodus-Treiber (SMM-Treiber, engl. "System Management Mode Driver") u. dgl. m.
In verschiedenen Ausführungsformen können diese nachfolgenden Treiber über einen authentifizierten Treiberlademechanismus gestartet werden, um zu gewährleisten, daß nur vertrauenswürdige Treiber in die von dem SVMM verwaltete sichere Preboot-Umgebung geladen werden. In einer solchen Ausführungsform kann der Authentifizierungsvorgang die Verwendung einer Infrastruktur auf Basis öffentlicher Schlüssel (PKI-Infrastruktur, engl. "Public Key Infrastructure") beinhalten, um zu gewährleisten, daß nur vertrauenswürdige Treiber in die VMX-Umgebung geladen werden. Alternativ hierzu kann zum Starten des SVMM eine Kern-Vertrauenswurzel gepflegt werden, wozu insbesondere eine transitive Vertrauensübergabe von einem Rücksetzvektor über die Sicherheitsphase und die PEI-Phase an die DXE-Phase zählt, wie vorstehend beschrieben.
Der SVMM-Treiber, der das VMM-Protokoll veröffentlicht, kann in bestimmten Ausführungsformen mehrere Rollen haben. Erstens kann er der erste Agent auf einer Plattform sein, der den SENTER-Befehl absetzt, und er kann somit auch für den Empfang nachfolgender Aktivierungen von Systemverwaltungsinterrupts (SMI) verantwortlich werden. In bestimmten Ausführungsformen, beispielsweise bei älteren Betriebssystemen, kann diese Rolle zur Laufzeit des BS beibehalten werden, wohingegen diese Rolle in anderen Ausführungsformen (z.B. EFI-kompatible BS) auf einen vom Betriebssystem bereitgestellten SVMM übertragen werden kann.
In bestimmten Ausführungsformen kann der SVMM zusätzliche VMX-Treiber laden. Bei diesen Treibern kann es sich um Codefolgen handeln, die danach trachten, von den VMX-Attributen, d.h. von isolierter Speicherung und Ausführung, zu profitieren; zu diesen Treibern können insbesondere zählen: ein BIOS-Integritätsdiensttreiber, erhältlich von der Intel Corporation; Authentifizierungsdienste, wie etwa Kerberos, erhältlich vom Massachusetts Institute of Technology, Cambridge, Massachusetts, oder anderer Sicherheitscode, wie etwa Preboot-Implementierungen kryptographischer Algorithmen, wie etwa Agenten, die asymmetrische kryptographische Berechnungen durchführen, zum Beispiel Rivest Shamir Adleman (RSA), erhältlich von RSA Security, Bedford, Massachusetts. Der Sinn des Isolierens des vorstehend genannten Codes besteht darin, daß die Integrität des Codes (d.h., daß er nicht unbefugt modifiziert wurde) erwünscht ist, um die Sicherheitsdeklarationen des Treiberverhaltens zu erfüllen.
Es wird nun auf 3 Bezug genommen, in der ein Flußdiagramm des Betriebs einer Preboot-Umgebung gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt wird. Wie in 3 gezeigt, wird der Firmware die Kontrolle über das System erlaubt (Block 210). Eine derartige Steuerung kann beim Einschalten, nach einem Systemzustandsereignis (z.B. S3-Schlafzustand) oder anderweitig auftreten. Als nächstes kann die Plattform initialisiert werden (Block 220). In bestimmten Ausführungsformen kann zu einer derartigen Initialisierung die minimale Konfiguration von Prozessor, Chipsatz und Speicher zählen.
Als nächstes kann, wie in 3 gezeigt, eine sichere Umgebung initialisiert und erstellt werden Block 230). Zu einer solchen Initialisierung kann das Auslesen des sicheren Codes aus einem persistenten Speicherbauelement zählen. In einer Ausführungsform kann der sichere Code auf einem Flashspeicher-Bauelement abgelegt werden, das dauerhaft und fest mit einer Hauptplatine des Systems verbunden ist. Da dieser Code in einem persistenten Speicherbauelement gespeichert ist und als sicheres Bauelement bekannt ist, verfügt die Preboot-Umgebung über ein Maß an Integrität. Des weiteren kann zur Initialisierung in einer Ausführungsform das Ausführen von Code im Chipsatz zählen, um zu gewährleisten, daß sich der Chipsatz in einem für den sicheren Preboot-Betrieb zulässigen Zustand befindet. In einer Ausführungsform kann die sichere Initialisierung erreicht werden, indem ein Lade-SINIT-Befehl ausgeführt wird.
Das Erstellen der sicheren Umgebung kann in einer Ausführungsform das Erzeugen einer Zusammenfassung in einem festen Token umfassen (dies wird nachstehend näher erörtert), das Informationen über die Plattform in der sicheren Umgebung bereitstellt. Des weiteren kann das Erstellen der sicheren Umgebung das Einrichten eines Speicherstapels umfassen. In einer Ausführungsform kann die sichere Umgebung erstellt werden, indem ein SVMM geladen wird, wie obenstehend erörtert wurde.
Als nächstes können in der Preboot-Umgebung sichere Operationen durchgeführt werden (Block 240). Wie vorliegend erörtert wird, kann zu derartigen Operationen beispielsweise das Versiegeln und Entsiegeln von Geheimnissen mit Hilfe eines festen Tokens zählen. Eine weitere Verwendung der sicheren Umgebung kann darin bestehen, den Flashspeicher zu aktualisieren. Weiterhin können derartige Operationen das Ausführen sicherer oder vertrauenswürdiger Treiber und die Attestierung von Protokollen/Signaturen umfassen. Eine derartige Attestierung von Signaturen kann beispielsweise an einen Kontrolleur (engl. "Challenger") ausgehändigt werden.
Nachdem die gewünschten Operationen in der Preboot-Umgebung durchgeführt worden sind, kann in die Boot-Umgebung eingesprungen werden (Block 250). In einer Ausführungsform kann eine transitive Übergabe von der sicheren Preboot-Umgebung an eine vertrauenswürdige BS-Umgebung bereitgestellt werden. In anderen Ausführungsformen kann die sichere Preboot-Umgebung vor dem Starten des BS niedergerissen werden. Alternativ hierzu kann in anderen Ausführungsformen in eine Boot-Umgebung eingesprungen werden, wobei der sichere Modus im Hintergrund beibehalten wird, um zum Beispiel die Plattformintegrität durchzuführen bzw. aufrechtzuerhalten. Die Erörterung erfolgte unter Bezugnahme auf einen einzelnen Prozessor, jedoch kann in anderen Ausführungsformen eine (logische oder reale) Mehrprozessorumgebung vorliegen.
In einer Ausführungsform kann die sichere Preboot-Umgebung ein Geheimnis bewahren, das dann von der Plattform-Firmware benutzt werden kann. Bei einem ersten Start kann die si chere Preboot-Umgebung ein solches Geheimnis in Form eines Wurzelschlüssels erzeugen, der sich für Algorithmen und Protokolle eignet, die von der sicheren Preboot-Umgebung unterstützt werden. Sobald dieser Wurzelschlüssel erzeugt worden ist, kann er geschützt werden, so daß der geschützte Wurzelschlüssel fortan nur an dieselbe, auf derselben Plattform laufende sichere Preboot-Umgebung freigegeben wird.
Dieser Schutz kann in bestimmten Ausführungsformen mit Hilfe einer Trusted Computing Platform (TCP) (oder eines gleichwertigen "Hardware-Safes") erzielt werden. In einer Ausführungsform kann der Wurzelschlüssel der sicheren Preboot-Umgebung mit Hilfe von Einrichtungen in Form fester Token versiegelt werden. In einer Ausführungsform kann es sich bei einer Einrichtung in Form eines festen Tokens um einen Chip handeln, der an der Hauptplatine des Computersystems angebracht ist und in Verbindung mit der CPU steht; dies wird nachstehend näher erörtert.
In einer Ausführungsform kann die Erzeugung eines Geheimnisses unter Verwendung einer Versiegelungsoperation erzielt werden, die mit Hilfe eines Schlüssels, der nur dem festen Token zugänglich ist, sowohl den Wurzelschlüssel als auch die registrierte Identität der sicheren Preboot-Umgebung verschlüsselt. Diese verschlüsselten Daten (das Schlüssel-"„BLOB", engl. "Binary Large Object", dt. "großes Binärobjekt") können daraufhin auf Massenspeicher (z.B. einer Festplatte des Computersystems) abgelegt werden. Beim Starten der sicheren Preboot-Umgebung, beispielsweise während eines späteren Bootens der Plattform, kann das Schlüssel-BLOB an das feste Token zurückgegeben werden, welches das BLOB entschlüsselt und mit der für die laufende sichere Preboot-Umgebung registrierten Identität vergleicht. Falls die Identität der laufenden sicheren Preboot-Umgebung mit der in dem BLOB eingebetteten Identität übereinstimmt, wird der Wurzelschlüssel an die sichere Preboot-Umgebung freigegeben.
In einer Ausführungsform erlaubt die Versiegelungsoperation der Software, explizit die zukünftige "vertrauenswürdige" Konfiguration anzugeben, in der sich die Plattform befinden muß, damit das Geheimnis offenbart wird. Die Versiegelungsoperation schließt implizit auch die zum Zeitpunkt des Durchführens der Versiegelungsoperation relevante Plattformkonfiguration (d.h., die Werte der Plattformkonfigurationsregister (PCR)) ein. Die Versiegelungsoperation kann einen im voraus ausgewählten Wert benutzen, um das BLOB an eine individuelle TCP zu binden.
Falls die Entsiegelungsoperation Erfolg hat, können an den Aufrufer ein Beleg über die Plattformkonfiguration, die zu dem Zeitpunkt vorlag, als die Versiegelungsoperation ausgeführt wurde, sowie die geheimen Daten zurückgegeben werden.
In bestimmten Ausführungsformen kann die sichere Preboot-Umgebung außerdem einen ausskalierenden Entwurf zulassen, wobei zusätzliche Sicherheitsmerkmale und -unterstützung über ladbare Treiber bereitgestellt werden können. In einer Ausführungsform kann es sich bei den Treibern um EFI-Laufzeittreiber handeln. Zu diesen Treibern können insbesondere sichere Speicherschnittstellen sowie Treiber für das Ausführen von sicherem Code zählen. Solche Treiber können, jeweils innerhalb einer gehärteten Umgebung, die Authentifizierung von Benutzern, Kontrolleure (engl. "Challengers") für die Integrität entfernter Images sowie attestierten Booten bereitstellen.
In einer Ausführungsform kann die sichere Preboot-Umgebung die Systemverwaltungs-Basisadresse (SMBASE) absichern, so daß keine andere Preboot-Komponente den SENTER-Befehl ausführen und dadurch den Systemverwaltungs-Direktzugriffsspeicher (SMRAM) einsehen kann.
Auf diese Weise kann die sichere Preboot-Umgebung in einer solchen Ausführungsform alle SMI-Aktivierungen nach dem Start empfangen. Mittels des frühzeitigen Starts der sicheren Preboot-Umgebung wird aufgrund der zugehörigen Aktivierung des Systemverwaltungsmodus-Speichers (SMMEM) die Fähigkeit von böswilliger Software, einen SENTER-Befehl auszuführen und den SMRAM einzusehen, verringert.
In verschiedenen Ausführungsformen kann die sichere Preboot-Umgebung mehrere Entladeoptionen aufweisen. Im Fall des Bootens eines EFI-kompatiblen BS kann die sichere Preboot-Umgebung die sichere Umgebung niederreißen. Alternativ hierzu kann die sichere Preboot-Umgebung bestehen bleiben, bis ein späterer "Entlade"-Service aufgerufen wird.
Zum Beispiel kann die sichere Preboot-Umgebung eine verwaltete Übergabe an einen BS-SVMM bereitstellen. Dies eröffnet eine Möglichkeit dazu, vom Preboot an eine Vertrauenswurzel herzustellen, die ungebrochen an das Betriebssystem transferiert werden kann, wodurch zusätzliche Gewißheit über die Stabilität der Plattform bereitgestellt wird, die über die Gewißheit hinausgeht, die das BS aus dem Laden seines eigenen SVMM beim Booten ableiten kann, sowie größere Gewißheit über die Herkunft des SMM-Codes der Plattform, der zur Laufzeit des Betriebssystems unter der Kontrolle eines OS-SVMM weiter Bestand hat.
In verschiedenen Ausführungsformen kann die vorliegende Erfindung eine sichere Betriebsumgebung für Code im Preboot-Raum bereitstellen. Eine solche Umgebung eröffnet Möglichkeiten, die Handhabungsweise von Operationen, die für die Integrität der Plattform kritisch sind, zu verändern und so den Entwurfsrahmen der Plattform zu erweitern und deren Nützlichkeit für den Benutzer zu verbessern.
Zum Beispiel kann in der sicheren Preboot-Umgebung eine Aktualisierung des Flashspeichers durchgeführt werden, ohne einen "Init"-Befehl zu erzwingen, da der Schreibzugriff auf den Flashspeicher von vertrauenswürdigem Code, der innerhalb der sicheren Preboot-Umgebung abläuft, geöffnet werden kann. Insbesondere können von einem SVMM Sicherheit schaffende Speicherverwaltungseinheits-Operationen eingerichtet werden, wie etwa insbesondere Speicherschutz auf Seitenebene, um ausschließlich vertrauenswürdige Parteien zum Zugriff auf den Flashbereich zu berechtigen. Zu diesen Parteien kann insbesondere der Aktualisierungscode des Plattformeigners zählen.
In einer weiteren Ausführungsform kann eine Aktualisierung des Flashspeichers von einem vertrauenswürdigen BS in einer Boot-Umgebung durchgeführt werden. In einer solchen Umgebung kann die CPU, solange sie sich in der sicheren Preboot-Umgebung befindet, den Flashspeicherbereich über Speicherschutzmechanismen auf Seitenebene schützen. Wenn eine transitive Übergabe von der sicheren Preboot-Umgebung aus stattfindet, können dem BS dieselben geschützten Speicherbereiche bereitgestellt werden. Folglich können in einer Boot-Umgebung der Zugriff auf und die Aktualisierung des geschützten Speichers (d.h., des Flashspeichers) entsprechend erfolgen.
In bestimmten Ausführungsformen kann der SVMM zur Laufzeit des Betriebssystems (BS) benutzt werden und neben dem SVMM des Betriebssystems weiterlaufen. Der BIOS-SVMM kann plattformspezifisches Verhalten bereitstellen, wie etwa Verläßlichkeit-Verfügbarkeit-Wartbarkeit (RAS, engl. "Reliability-Availability-Serviceability"). Hierzu kann die Handhabung spezieller Plattformfehler zählen, wie etwa das Schreiben auf eine physikalische Speicherseite mit einem vom Fehlerkorrekturcode (ECC, engl. "Error-Correcting Code") gemeldeten Einzelbitfehler (SBE, engl. "Single-Bit Error"). Ein vom Chipsatz erkannter SBE führt oft dazu, daß zum Aktualisieren der betroffenen Bits durch Lesen und anschließendes Zurückschreiben der Zugriff auf einen Speicherbereich notwendig wird. Es gibt keinen standardisierten Weg, um ein Betriebssystem von einer solchen Fehlfunktion und der nötigen Reaktion in Kenntnis zu setzen, und zur Laufzeit des Betriebssystems kontrolliert das BS den gesamten Speicher. Somit sorgt ein BIOS-SVMM als Partner des BS-SVMM für plattformspezifische Aktivitäten, die vormals im Systemverwaltungsmodus (SMM) vorgenommen wurden; der SMM hatte vor dem Aufkommen von sicheren Betriebssystemen vollen Zugriff auf das System.
Außerdem nehmen heutige Betriebssysteme eine stillschweigende Vertrauensdeklaration bezüglich der Plattform vor. Zum Beispiel erstellt das BIOS Tabellen, die nicht zählbare Ressourcen beschreiben, wie etwa das gesamte Speicherabbild, feste Ports, die Adresse des lokalen APIC (engl. "Advanced Programmable Interrupt Controller", dt. "erweiterter programmierbarer Interrupt-Controller"), die Wegewahl für Interrupts und andere Ressourcen. Diese Tabellen werden lediglich durch simple Prüfsummen geschützt. Für vertrauenswürdige Plattformen könnten diese Tabellen, die heute in unverschlüsseltem Speicher abgelegt werden, einen Angriffspunkt darstellen. Der Angreifer könnte den Wert, der die Plattform beschreibt, austauschen und das Betriebssystem belügen; im Rahmen dieses Angriffs könnte Speicher versteckt werden; es könnten Ports vorgetäuscht werden u. dgl. m. Eine Preboot-Umgebung kann benutzt werden, um diese Tabellen zu erzeugen, deren Inhalte zu signieren, und sie transitiv an einen OS-SVMM mit einer Vertrauensdeklaration zu übergeben, u. dgl. m.
Ausführungsformen können in einem Computerprogramm implementiert werden. Somit können diese Ausführungsformen auf einem Speichermedium abgelegt werden, auf dem Anweisungen gespeichert sind, die benutzt werden können, um ein Computersystem dazu zu programmieren, die Ausführungsformen auszuführen. Als Speichermedium können insbesondere dienen: jede Art von Speicherplatte einschließlich Disketten, optischen Speicherplatten, als Festwertspeicher ausgeführten Compact Discs (CD-ROM), wiederbeschreibbaren Compact Discs (CD-RW) und magnetooptischen Platten, Halbleiterbauelemente wie etwa Festwertspeicher (ROM), Speicher mit wahlfreiem Zugriff (RAM), löschbare programmierbare Festwertspeicher (EPROM), elektrisch löschbare und programmierbare Festwertspeicher (EEPROM), Flashspeicher, magnetische oder optische Karten oder jede beliebige, zum Speichern von elektronischen Anweisungen geeignete Medienart. Ebenso können Ausführungsformen als Softwaremodule implementiert werden, die von einem programmierbaren Steuerungsbauelement ausgeführt werden. Bei einem programmierbaren Steuerungsbauelement kann es sich um einen Computerprozessor oder eine aufgabenspezifische Ablaufsteuereinheit handeln. Aufgabenspezifische Ablaufsteuereinheiten können als Hardwarebauelement ausgeführt werden, wie etwa als Platine mit diskreter Logik, als integrierte Schaltungen oder als speziell entworfene anwendungsspezifische integrierte Schaltungen (ASIC, engl. "Application Specific Integrated Circuit").
Ausführungsbeispiele können in Software implementiert werden, die durch ein geeignetes Datenverarbeitungssystem ausgeführt wird, das mit einer geeigneten Kombination aus Hardwarebauelementen konfiguriert ist. 4 ist ein Blockdiagramm eines repräsentativen Datenverarbeitungssystems, nämlich des Computersystems 300, mit dem Ausführungsformen der Erfindung benutzt werden können.
Es wird nun auf 4 Bezug genommen. In einer Ausführungsform weist das Computersystem 300 einen Prozessor 310 auf, der einen Allzweckprozessor oder Spezialprozessor, wie etwa einen Mikroprozessor, Mikrocontroller, ASIC, ein programmierbares Gate-Array (PGA) u. dgl. m., aufweisen kann.
Der Prozessor 310 kann in einer Ausführungsform über einen Host-Bus 315 an einen Speicherhub 320 gekoppelt sein, welcher über einen Speicherbus 325 an einen Systemspeicher 330 gekoppelt sein kann. Wie in 4 gezeigt, kann der Systemspeicher 330 in bestimmten Ausführungsformen geschützte Speicherseiten aufweisen. Zu solchen Seiten können beispielsweise Seiten im Zusammenhang mit dem SVMM und anderen vertrauenswürdigen virtuellen Maschinen zählen. In bestimmten Ausführungsformen kann der Speicherhub 320 so konfiguriert sein, daß er den Zugriff auf mindestens gewisse Abschnitte der geschützten Speicherseiten des Systemspeichers 330 blockiert. Der Speicherhub 320 kann außerdem über einen AGP-Bus 333 (engl. "Advanced Graphics Port") an einen Videocontroller 335 gekoppelt sein, der an eine Anzeige 337 gekoppelt sein kann. Der AGP-Bus 333 kann der "Accelerated Graphics Port Interface"-Spezifikation in der Revision 2.0 entsprechen, die am 4. Mai 1998 von der Intel Corporation, Santa Clara, Kalifornien veröffentlicht wurde.
Der Speicherhub 320 kann zudem (über eine Hubverbindung 338) an einen Eingabe/Ausgabe-Hub (E/A-Hub) 340 gekoppelt sein, der an einen Eingabe/Ausgabe-Erweiterungsbus (E/A-Erweiterungsbus) 342 und einen PCI-Bus 344 (engl. "Peripheral Component Interconnect") entsprechend der Festlegung aus der "PCI Local Bus"-Spezifikation, Produktionsversion, Revision 2.1 vom Juni 1995 gekoppelt ist. Der E/A-Erweiterungsbus 342 kann an einen E/A-Controller 346 gekoppelt sein, der den Zugriff auf ein oder mehrere E/A-Bauelemente kontrolliert. Wie in 4 gezeigt, können zu diesen Bauelementen in einer Ausführungsform Speicherbauelemente, wie etwa ein Diskettenlaufwerk 350, und Eingabebauelemente, wie etwa eine Tastatur 352 und Maus 354, zählen. An den E/A-Erweiterungsbus 342 kann ebenfalls ein Flashspeicher 341 gekoppelt sein, der in einer Ausführungsform den sicheren Code für die Preboot-Umgebung dauerhaft speichern kann. Der E/A-Hub 340 kann zum Beispiel auch an ein Festplattenlaufwerk 356 gekoppelt sein, wie in 4 gezeigt. Es versteht sich, daß in das System auch andere Speichermedien aufgenommen werden können.
An den E/A-Erweiterungsbus 342 kann ebenfalls ein festes Token 343 gekoppelt sein. In einer Ausführungsform kann das feste Token 343 permanent an eine Hauptplatine des Computersystems 300 gebunden sein. Das feste Token 343, bei dem es sich um einen Allzweckprozessor, ASIC oder dergleichen handeln kann, kann grundlegende sogenannte "Smartcard"-Merkmale aufweisen. In bestimmten Ausführungsformen können zu diesen Merkmale kryptographische Fähigkeiten, wie etwa Schlüssel, Speicher, Signieren und Verschlüsselung, zählen. In verschiedenen Ausführungsformen kann das feste Token 343 zur Attestierung und zum Versiegeln/Entsiegeln von Geheimnissen benutzt werden. Solche Attestierungen können das Attestieren der Konformität der Plattform und des Ladezustands spezifischer Monitore/Applets umfassen. Bezüglich des Versiegelns von Geheimnissen kann das feste Token 343 so programmiert sein, daß es Geheimnisse an dieselbe Umgebung oder an eine ausgewählte Umgebung versiegelt/entsiegelt.
In bestimmten Ausführungsformen kann ein portables Token 358 an den E/A-Hub 340 gekoppelt sein. Es versteht sich, daß eine solche Kopplung über beliebige Standardverbindungen erfolgen kann, wie beispielsweise etwa über Universal Serial Bus (USB). In einer Ausführungsform kann das portable Token 358 Merkmale aufweisen, die denen des festen Tokens 343 ähneln. Zum Beispiel kann das portable Token 358 benutzt werden, um das System auf einen Benutzer hin zu überprüfen, um portable Benutzergeheimnisse bereitzustellen, um anonyme Identifikationen bereitzustellen u. dgl. m.
In einer alternativen Ausführungsform können der E/A-Controller 346 wie auch andere Kontrollfunktionen in den E/A-Hub 340 integriert sein. Der PCI-Bus 344 kann außerdem an verschiedene Komponenten gekoppelt sein, insbesondere zum Beispiel an einen Netzwerkcontroller 360, der an einen Netzwerkport (nicht gezeigt) gekoppelt ist.
Zusätzliche Bauelemente können an den E/A-Erweiterungsbus 342 und den PCI-Bus 344 gekoppelt sein, wie etwa eine Eingabe/Ausgabe-Steuerschaltung, die an einen parallelen oder seriellen Port gekoppelt ist, ein nichtflüchtiger Speicher u. dgl. m.
Die Beschreibung nimmt zwar auf spezifische Komponenten des Systems 300 Bezug; es wird jedoch in Betracht gezogen, daß zahlreiche Modifikationen und Abwandlungen der beschriebenen und dargestellten Ausführungsformen möglich sein können. Zum Beispiel könnten anstelle der Speicher- und E/A-Hubs ein Hostbrückencontroller und ein Systembrückencontroller gleichwertige Funktionen bereitstellen. Außerdem können beliebige Busprotokolle aus einer Anzahl möglicher Busprotokolle implementiert sein.
Zwar wurde die vorliegende Erfindung unter Bezugnahme auf eine begrenzte Anzahl von Ausführungsformen beschrieben; der Fachmann wird jedoch zahlreiche Modifikationen und Abwandlungen hiervon erkennen. Es ist beabsichtigt, daß die beigefügten Ansprüche alle Modifikationen und Abwandlungen abdecken, die in den Rahmen des Gedankens und des Umfangs der vorliegenden Erfindung fallen.
ZUSAMMENFASSUNG
In einer Ausführungsform weist die vorliegende Erfindung ein Verfahren zum Herstellen einer sicheren Preboot-Umgebung in einem Computersystem und zum Durchführen mindestens einer sicheren Operation in der sicheren Umgebung auf. In einer Ausführungsform kann es sich bei der sicheren Operation um das Speichern eines Geheimnisses in der sicheren Preboot-Umgebung handeln.

Claims

Verfahren, das umfaßt: Herstellen einer sicheren Preboot-Umgebung in einem Computersystem; und Durchführen mindestens einer sicheren Operation in der sicheren Preboot-Umgebung.
Verfahren nach Anspruch 1, wobei das Durchführen der mindestens einen sicheren Operation das Speichern eines Geheimnisses umfaßt.
Verfahren nach Anspruch 1, das ferner ein Transferieren des Computersystems von der sicheren Preboot-Umgebung in eine Betriebssystem-Umgebung umfaßt.
Verfahren nach Anspruch 1, das ferner ein Starten eines sicheren Virtual-Machine-Monitors in der sicheren Preboot-Umgebung umfaßt.
Verfahren nach Anspruch 1, das ferner ein Aktualisieren eines Flashspeichers in der sicheren Preboot-Umgebung umfaßt.
Verfahren nach Anspruch 1, das ferner ein Absetzen eines Systemverwaltungsbefehls in der sicheren Preboot-Umgebung umfaßt.
Verfahren nach Anspruch 1, das ferner ein Empfangen von Systemverwaltungsinterrupts in der sicheren Preboot-Umgebung umfaßt.
Verfahren nach Anspruch 2, das ferner ein Erzeugen des Geheimnisses in der Form eines Wurzelschlüssels, der über ein festes Token versiegelt wird, umfaßt.
Verfahren nach Anspruch 8, das ferner ein Freigeben des Wurzelschlüssels an das Computersystem ausschließlich in der sicheren Preboot-Umgebung umfaßt.
Verfahren nach Anspruch 1, das ferner ein Isolieren eines schädlichen Codes von überprüfbarem Code umfaßt.
Verfahren, das umfaßt: Bereitstellen einer Firmware-Steuerung eines Computersystems in einer Preboot-Umgebung, Erstellen einer sicheren Umgebung in der Preboot-Umgebung; und Durchführen mindestens einer sicheren Operation in der sicheren Umgebung.
Verfahren nach Anspruch 11, das ferner ein Eintreten in eine Boot-Umgebung aus der Preboot-Umgebung umfaßt.
Verfahren nach Anspruch 12, das ferner ein Beibehalten der sicheren Umgebung in einem Hintergrund der Boot-Umgebung umfaßt.
Verfahren nach Anspruch 12, das ferner ein Niederreißen der sicheren Umgebung umfaßt, falls die Boot-Umgebung eine vertrauenswürdige Boot-Umgebung ist.
Verfahren nach Anspruch 11, wobei das Durchführen der mindestens einen sicheren Operation in der sicheren Umgebung ein Speichern eines Geheimnisses in der sicheren Umgebung umfaßt.
Verfahren nach Anspruch 15, das ferner ein Benutzen eines festen Tokens zum Speichern des Geheimnisses umfaßt.
Verfahren nach Anspruch 15, das ferner ein Zugreifen auf das Geheimnis in einem anderen Eintrittspunkt der sicheren Umgebung in der Preboot-Umgebung umfaßt.
Verfahren nach Anspruch 13, das ferner ein Benutzen der sicheren Umgebung zum Durchführen von Zuverlässigkeit-Verfügbarkeit-Wartbarkeit umfaßt.
Verfahren nach Anspruch 12, das ferner das Erzeugen von Tabellen in der Preboot-Umgebung und das Bereitstellen der Tabellen an die Boot-Umgebung mit einer Vertrauensdeklaration umfaßt.
Erzeugnis, das ein maschinenlesbares Speichermedium umfaßt, das Anweisungen enthält, die bei ihrer Ausführung ein System in die Lage zu folgendem versetzen: Herstellen einer sicheren Preboot-Umgebung in einem Computersystem und Durchführen mindestens einer sicheren Operation in der sicheren Preboot-Umgebung.
Erzeugnis nach Anspruch 20, das ferner Anweisungen umfaßt, die bei ihrer Ausführung das System in die Lage zum Speichern eines Geheimnisses in der sicheren Preboot-Umgebung versetzen.
Erzeugnis nach Anspruch 21, das ferner Anweisungen umfaßt, die bei ihrer Ausführung das System in die Lage versetzen, das Geheimnis in Form eines Wurzelschlüssels, der über ein festes Token versiegelt wird, zu erzeugen.
Erzeugnis nach Anspruch 22, das ferner Anweisungen umfaßt, die bei ihrer Ausführung das System in die Lage versetzen, den Wurzelschlüssel ausschließlich in der sicheren Preboot-Umgebung an das Computersystem freizugeben.
System, das umfaßt: mindestens ein Speicherelement, das Anweisungen enthält, die bei ihrer Ausführung das System in die Lage versetzen, eine sichere Preboot-Umgebung in einem Computersystem herzustellen und mindestens eine sichere Operation in der sicheren Preboot-Umgebung durchzuführen, und einen Prozessor, der an das mindestens eine Speicherbauelement gekoppelt ist und die Anweisungen ausführt.
System nach Anspruch 24, das ferner Anweisungen umfaßt, die bei ihrer Ausführung das System in die Lage versetzen, ein Geheimnis in der sicheren Preboot-Umgebung zu speichern.
System nach Anspruch 24, das ferner einen Flashspeicher umfaßt, der einen sicheren BIOS-Code enthält.
System nach Anspruch 24, das ferner ein festes Token umfaßt, das an den Prozessor gekoppelt ist.
System nach Anspruch 27, wobei das feste Token mindestens einen Wurzelschlüssel für eine geheimnisbasierte Sicherheit umfaßt.