DE112012000512T5

DE112012000512T5 - Aktualisieren von Software

Info

Publication number: DE112012000512T5
Application number: DE112012000512T
Authority: DE
Inventors: James William Walker; David Haikney; David Alan Gilbert
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2011-01-19
Filing date: 2012-01-10
Publication date: 2013-10-24
Also published as: CN103329093B; US9317276B2; CN103329093A; JP2014503101A; WO2012098478A1; GB2501433B; KR20130114672A; US10108413B2; GB2501433A; US10620936B2; US10007510B2; JP5932837B2; US20180246709A1; US20160162396A1; GB201313795D0; US20140026124A1; US20160162285A1

Abstract

Die vorliegende Erfindung bezieht sich auf ein Verfahren und eine Vorrichtung zum Aktualisieren von Software. Diese Erfindung bezieht sich insbesondere auf ein Verfahren, ein System und ein Computerprogrammprodukt zum Aktualisieren eines Betriebssystems in einem Hypervisor, aufweisend: Feststellen einer neuen Version einer Komponente des Betriebssystems; Installieren der neuen Komponentenversion; Messen eines kennzeichnenden Merkmals der Komponente und Bereitstellen dieser für ein Attestierungssystem; Benachrichtigen des Attestierungssystems, dass eine Komponente auf eine neue Version aktualisiert wurde, wobei, wenn das Attestierungssystem feststellt, dass das kennzeichnenden Merkmal der neuen Komponente nicht mit einem zuvor gespeicherten Attestierungswert übereinstimmt, das System weiß, dass eine zulässige Nichtübereinstimmung aufgetreten sein könnte. Das Installieren der neuen Version der Komponente weist auf: Identifizieren einer Aktualisierungsvorrichtung, die der neuen Version der Komponente zugeordnet ist; Messen eines kennzeichnenden Merkmals der identifizierten Aktualisierungseinrichtung; Laden und Installieren der neuen Version der Komponente; und Bereitstellen sowohl des kennzeichnenden Messwerts der Aktualisierungseinrichtung als auch der neuen Version der Komponente für das Attestierungssystem.

Description

Technisches Gebiet
Die vorliegende Erfindung bezieht sich auf ein Verfahren und eine Vorrichtung zum Aktualisieren von Software. Die Erfindung bezieht sich insbesondere auf Prozesse zum vertrauenswürdigen Booten (Hochfahren) und entfernt ausgeführten Attestieren (remote attestation). Vertrauenswürdige Datenverarbeitung (trusted computing), vertrauenswürdiges Booten und entfernte Attestierung beziehen sich wie in dieser Beschreibung dargelegt allgemein auf Technologiestandards, die von einer Standardisierungsorganisation namens Trusted Computing Group entwickelt wurden.
HINTERGRUND
Vertrauenswürdiges Booten ist ein Verfahren zum Booten und Aufbauen einer Vertrauenskette (chain of trust) in einem vertrauenswürdigen Datenverarbeitungssystem. Boot-Komponenten können kryptografisch gemessen und in einer sicheren Einheit, zum Beispiel einem Trusted Platform Module (TPM, vertrauenswürdiges Plattformmodul), gespeichert werden. Jede Boot-Komponente misst einen charakteristischen Messwert der nächsten Boot-Komponente und speichert diesen Messwert in der sicheren Einheit, wobei der Messwert ermittelt wird, bevor die Steuerung an die gemessene Komponente weitergegeben wird. Sobald das System läuft, können die Messwerte von einem entfernt angeordneten System mit Hilfe eines Prozesses zur entfernt vorgenommenen Attestierung, zum Beispiel Direct Anonymous Attestation (DAA, direkte anonyme Attestierung), zur Prüfung extrahiert werden. Eine Messwertfolge wird als Vertrauenskette bezeichnet.
Computersysteme werden häufig mit neuen Funktionen und Software-Ergänzungen aktualisiert. Für eine Aktualisierung muss unter Umständen eine Boot-Komponente geändert werden, die Teil der Vertrauenskette ist, und nach einer solchen Aktualisierung zeigt die entfernt vorgenommene Attestierung eine Änderung des Messwerts an; die Vertrauenskette ist unterbrochen. Bei vielen Systemen und zahlreichen Aktualisierungen führt dies zu einem größeren, schwierigen Verwaltungsproblem. Die Änderung des Messwerts ”zeigt” sich nur nach mindestens einem erneuten Messwert. Der erneute Messwert kann nur bei einem erneuten Booten oder während der Laufzeit auftreten (je nach Aufbau des Systems).
Es besteht in der Technik somit der Bedarf, das oben genannte Problem zu lösen.
KURZDARSTELLUNG DER ERFINDUNG
Bei einem ersten Aspekt der Erfindung wird ein Verfahren zum Aktualisieren von Code in einer Ausführungsumgebung bereitgestellt, wobei das Verfahren aufweist: Installieren von neuem Code; Messen eines kennzeichnenden Merkmals des neuen Codes und Bereitstellen des kennzeichnenden Merkmals für ein Attestierungssystem; Benachrichtigen des Attestierungssystems, dass der Code auf eine neue Version aktualisiert wurde, wobei, wenn das Attestierungssystem feststellt, dass das kennzeichnende Merkmal des neuen Codes nicht mit einem zuvor gespeicherten Attestierungswert übereinstimmt, das System weiß, dass eine zulässige Nichtübereinstimmung aufgetreten sein könnte.
Bei der bevorzugten Ausführungsform ist der Code eine Komponente, die in dem Boot-Prozess verwendet wird, wobei der Code sich auch auf eine andere Komponente in der Vertrauenskette beziehen könnte, die nicht hochgefahren wird. Bei anderen Ausführungsformen ist der Code vollständig oder zum Teil Firmware, ein Hypervisor, eine virtuelle Maschine, ein Betriebssystem oder eine Anwendung. Bei neuem Code kann es sich um eine neue Version einer Komponente oder eine vollständig neue Komponente handeln.
Ein zuvor gespeicherter Attestierungswert ist ein von dem Attestierungssystem verwendeter Referenzwert, um zu prüfen, ob ein gültiges kennzeichnendes Merkmal einer Systemkomponente vorhanden ist. Der zuvor gespeicherte Attestierungswert wird durch eine Systemverwaltung in dem Attestierungssystem gespeichert oder durch einen Initialisierungsprozess angefordert, wobei ein erstes kennzeichnendes Merkmal einer Komponente vertrauenswürdig ist und von dem Attestierungssystem als Attestierungswert verwendet wird.
Das Verfahren weist vorteilhafterweise auf, dass das Vorhandensein einer neuen Version einer Betriebssystemkomponente festgestellt wird, wobei die Aktualisierungsphase automatisch durchgeführt wird.
Die Erfindung benachrichtigt das Attestierungssystem über die Aktualisierung, Attestierungswerte können jedoch nur von dem Attestierungssystem oder einem Systemadministrator aktualisiert werden. Attestierungswerte könnten nur in einer weniger sicheren Ausführungsform von dem Hypervisor aktualisiert werden. Bei der bevorzugten Ausführungsform hat der Hypervisor außer durch Benachrichtigungen keinen Zugriff auf das Attestierungssystem; das Attestierungssystem muss eine Attestierung unmittelbar nach der Benachrichtigung durchführen, wobei es die Herkunftsquelle der neuen Version der Komponente prüft. Sobald es die Herkunftsquelle der neuen Komponente geprüft hat, kann es nach einem künftigen erneuten Booten den Boot-Messwert der neuen Komponente annehmen, auch wenn der Messwert nicht mit dem gespeicherten Attestierungswert übereinstimmt.
Zu dem bekannten Software-Aktualisierungsprozess kommt noch eine Hypervisor-Benachrichtigungsphase hinzu, so dass die Vertrauenskette mit dem Hypervisor beginnt. Bei der bevorzugten Ausführungsform besteht die Benachrichtigungsphase darin, dass das aktualisierte System dem Attestierungssystem eine Nachricht ”Prüfe mich” sendet, so dass das Attestierungssystem weiß, dass ein neuer Messwert ermittelt wurde. Die Attestierungsbenachrichtigung verhindert, dass das Attestierungssystem in Panik gerät, wenn das attestierte System neu bootet und verschiedene Messwerte feststellt.
Die bevorzugte Ausführungsform kann es einer vertrauenswürdigen Komponente wie beispielsweise dem Hypervisor ermöglichen, an dem Messprozess teilzunehmen und eine andere Komponente zu messen, so dass das Attestierungssystem der gemessenen Komponente vertrauen kann.
Das Installieren der neuen Version (651.N) der Komponente (616.N) weist vorteilhafterweise auf: Identifizieren einer Aktualisierungseinrichtung (612.N), die der neuen Version (651.N) zugeordnet ist; Messen eines kennzeichnenden Merkmals der identifizierten Aktualisierungseinrichtung (612.N); Installieren der neuen Version (651.N) der Einrichtung; und Bereitstellen des kennzeichnenden Messwerts (PCR17) der Aktualisierungseinrichtung für das Attestierungssystem (620), wobei das Attestierungssystem (620) den kennzeichnenden Messwert (PCR17) der Aktualisierungseinrichtung (612.N) mit einem zuvor gespeicherten Attestierungswert (624.N) in Übereinstimmung bringen kann, um eine zulässige Aktualisierung für gültig zu erklären. Die Bezugsziffern von 6 wurden zur Veranschaulichung und nur als Beispiel in den vorhergehenden Absatz mit aufgenommen.
Das Attestierungssystem prüft noch vorteilhafterweise direkt nach der Benachrichtigung die Herkunftsquelle der neuen Version der Komponente, die es in dem Hypervisor findet. Bei der bevorzugten Ausführungsform beinhaltet das Prüfen der Herkunftsquelle einer Komponente das Prüfen der Komponente, die die Aktualisierung installiert hat, in anderen Ausführungsformen können jedoch andere Prüfungen durchgeführt werden, beispielsweise woher die Aktualisierung kommt oder wie diese installiert wurde. Wenn der Messwert darüber hinaus nicht mit einem Attestierungswert übereinstimmt und das Attestierungssystem die Herkunftsquelle der entsprechenden Komponente geprüft hat, wird eines oder mehreres von Folgendem durchgeführt: Aktualisieren des Attestierungswerts mit dem Messwert der neuen Version der Komponente; und/oder Benachrichtigen einer Verwaltungsebene, dass ein Messwert nicht mit einem Attestierungswert übereinstimmt und ob das Attestierungssystem die Herkunftsquelle der Komponente erkennt.
Bei einem zweiten Aspekt der Erfindung wird ein Verfahren zum Aktualisieren und Attestieren einer Betriebssystemkomponente in einem Hypervisor bereitgestellt, wobei das Verfahren aufweist: Feststellen einer neuen Version einer Komponente eines Betriebssystems; Installieren der neuen Komponentenversion; Messen eines kennzeichnenden Merkmals der Komponente und Bereitstellen des Merkmals für ein Attestierungssystem; Benachrichtigen des Attestierungssystems, dass eine Komponente auf eine neue Version aktualisiert wurde; und wobei, wenn das Attestierungssystem feststellt, dass das kennzeichnende Merkmal der neuen Komponente nicht mit einem zuvor gespeicherten Attestierungswert übereinstimmt, das System weiß, dass eine zulässige Nichtübereinstimmung aufgetreten sein könnte.
Bei einem dritten Aspekt der Erfindung wird ein Verfahren zum Prüfen der Unversehrtheit eines Programms bereitgestellt, wobei das Verfahren aufweist:
Extrahieren eines von dem Programminstallationsprozess gespeicherten Komponentenmesswerts; Prüfen des Komponentenmesswerts anhand von Messwerten, die von dem Prüfsystem gespeichert werden, und Zurückweisen des Messwerts, wenn dieser nicht übereinstimmt; weiteres Prüfen des zurückgewiesenen Komponentenmesswerts und erneutes Zurückweisen, wenn dieser nicht von einer anderen Komponente kommt, die dem Prüfsystem bekannt ist; und Anzeigen einer Annahme, wenn der Komponentenmesswert eine Prüfung besteht, und einer Zurückweisung, wenn der Messwert keine der Prüfungen besteht.
Ein vierter Aspekt der Erfindung wird wie in Anspruch 11 beschrieben bereitgestellt.
Ein fünfter Aspekt der Erfindung wird wie in Anspruch 19 beschrieben bereitgestellt.
Ein sechster Aspekt der Erfindung wird wie in Anspruch 20 beschrieben bereitgestellt.
Im Hinblick auf einen weiteren Aspekt stellt die vorliegende Erfindung ein Computerprogrammprodukt zum Aktualisieren eines Codes in einer Ausführungsumgebung bereit, wobei das Computerprogrammprodukt aufweist: ein computerlesbares Speichermedium, das von einer Verarbeitungsschaltung gelesen werden kann und das Befehle zum Ausführen durch die Verarbeitungsschaltung speichert, um ein Verfahren zum Durchführen der Schritte der Erfindung durchzuführen.
Im Hinblick auf einen weiteren Aspekt stellt die vorliegende Erfindung ein Computerprogramm bereit, das auf einem computerlesbaren Medium gespeichert ist und in den internen Speicher eines digitalen Computers geladen werden kann, wobei das Computerprogramm Softwarecodeteile aufweist, wenn das Programm auf einem Computer ausgeführt wird, um die Schritte der Erfindung durchzuführen.
Diese Beschreibung stellt eine Lösung vor, die es einem System ermöglicht, die attestierende Partei darüber zu informieren, was bei dem nächsten vertrauenswürdigen Booten in einem virtualisierten System unter Verwendung eines virtuellen TMP zu erwartet ist.
Kurzbeschreibung der Zeichnungen
Die vorliegende Erfindung wird nunmehr lediglich beispielhaft mit Bezug auf bevorzugte Ausführungsformen beschrieben, wie sie in den folgenden Figuren veranschaulicht sind:
1 ist ein schematisches Implementierungsschaubild eines vertrauenswürdigen Datenverarbeitungssystems nach dem Stand der Technik und bei dem eine bevorzugte Ausführungsform der vorliegenden Erfindung ausgeführt werden kann;
2 ist ein schematisches Prozessschaubild eines vertrauenswürdigen Datenverarbeitungssystems nach dem Stand der Technik und bei dem eine bevorzugte Ausführungsform der vorliegenden Erfindung ausgeführt werden kann;
3 ist ein schematisches Prozessschaubild zum Attestieren des vertrauenswürdigen Datenverarbeitungssystems nach dem Stand der Technik und bei dem eine bevorzugte Ausführungsform der vorliegenden Erfindung ausgeführt werden kann;
4 ist ein schematisches Prozessschaubild zum Aktualisieren des vertrauenswürdigen Datenverarbeitungssystems nach dem Stand der Technik und bei dem eine bevorzugte Ausführungsform der vorliegenden Erfindung ausgeführt werden kann;
5 ist ein Vergleichsschaubild, das gleichwertige Schritte eines Aktualisierungsprozesses der Ausführungsform und des Aktualisierungsprozesses nach dem Stand der Technik zeigt und bei dem eine bevorzugte Ausführungsform der vorliegenden Erfindung ausgeführt werden kann;
6 ist ein schematisches Implementierungsschaubild eines Systems gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung;
7 ist ein schematisches Prozessschaubild des Aktualisierungsprozesses gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung;
8 ist ein Prozessschaubild eines Ladeprozesses einer neuen Komponente gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung;
9 ist ein Prozessschaubild eines Attestierungsprozesses gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung; und
10 ist ein schematisches Implementierungsschaubild eines Systems einer physischen Ausführungsform.
BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
1 ist ein vereinfachtes Implementierungsschaubild eines vertrauenswürdigen Systems nach dem Stand der Technik, das aufweist: eine Plattform 10; ein Trusted Platform Module 20 (TPM 20) und ein Attestierungssystem 30. Die Plattform 10 weist auf: einen Boot-Prozess 200 (nachstehend mit Bezug auf 2 beschrieben); einen Aktualisierungsprozess 12 und die Boot-Komponenten 15.1 bis 15N (an dieser und anderer Stelle in dieser Beschreibung wird der Buchstabe N verwendet, um eine Zahl darzustellen, jedoch keine spezifische Zahl). Die Boot-Komponenten 15 beinhalten: die Boot-Komponenten 15.1 bis 15N. Das TPM 20 weist die Plattformkonfigurationsregister 22.1 bis 22N auf. Das TPM 20 ist separat implementiert von der Plattform 10 dargestellt, es könnte jedoch auch Teil der Plattform 10 sein. Ein Plattformkonfigurationsregister PCR wird ebenfalls als Register bezeichnet. Das Attestierungssystem 30 weist einen Attestierungsprozess 300 und die Attestierungswerte 34.1 bis 34N auf. Das Attestierungssystem 30 ist separat implementiert von der Plattform dargestellt.
2 ist ein vereinfachtes Prozessschaubild eines Boot-Prozesses 200 nach dem Stand der Technik, das eine Folge von Schritten 202 bis 212 zum Ausführen einer Reihe von Boot-Komponenten in folgender Reihenfolge aufweist.
Schritt 202 dient zum Ausführen der ersten Boot-Komponente.
Schritt 204 dient zum Messen eines kennzeichnenden Merkmals der nächsten Boot-Komponente und Speichern des Messwerts in einem Register (zum Beispiel 22.1).
Schritt 206 dient zum Ausführen der nächsten Komponente.
Schritt 208 dient gegebenenfalls zum Messen eines kennzeichnenden Merkmals der nachfolgenden Boot-Komponente und Speichern des Messwerts in einem nachfolgenden Register (zum Beispiel 22.2).
Schritt 210 stellt einen Boot-Zyklus dar, der die Schritte 206 und 208 für mögliche nachfolgende Boot-Komponenten wiederholt.
Schritt 212 stellt das Ende des Prozesses dar, wenn keine Boot-Komponenten mehr übrig sind.
Bei der bevorzugten Ausführungsform führt ein Hypervisor Anfangsschritte durch (die entsprechenden Schritte 200, 202, 204 nach dem Stand der Technik), so dass das Messen und Ausführen in dem Hypervisor beginnen. Der Hypervisor stellt zum Beispiel einen Hypercall ”H-Messen” bereit, der Code wie beispielsweise eine nächste Boot-Komponente misst und ausführt. Bei einem anderen Beispiel könnte Plattform-Firmware die Anfangsschritte durchführen und eine nachfolgende Boot-Komponente in einem Hypervisor starten.
3 ist ein vereinfachtes Prozessschaubild eines Attestierungsprozesses 300 nach dem Stand der Technik, das eine Folge von nachfolgend beschriebenen Logikschritten 302 bis 308 aufweist. Der Attestierungsprozess wird ausgeführt, nachdem die vertrauenswürdige Plattform hochgefahren ist.
Schritt 302 dient zum Extrahieren von Messwerten, die in Registern gespeichert sind.
Schritt 304 dient zum Vergleichen der Messwerte mit den Attestierungswerten 34.1 bis 34N, die von dem Attestierungssystem 30 gespeichert werden.
Schritt 306 dient zum Anzeigen 1) einer Annahme, wenn die Werte mit den Messwerten übereinstimmen, oder 2) einer Zurückweisung, wenn zwischen den Werten und Messwerten keine Übereinstimmung besteht.
Schritt 308 stellt das Ende des Prozesses dar. Der Attestierungsprozess nach dem Stand der Technik vertraut darauf, dass die Attestierungswerte richtig sind, und nach dem Stand der Technik werden die Attestierungswerte von einem Administrator aktualisiert.
4 ist ein vereinfachtes Prozessschaubild eines Aktualisierungsprozesses 400 nach dem Stand der Technik, das eine Folge von Schritten 402 bis 406 aufweist.
Schritt 402 dient zum Feststellen, dass eine Komponente durch eine neuere Version der Komponente aktualisiert werden muss.
Schritt 404 dient zum Aktualisieren der Komponente, indem die alte Komponente entfernt und die neue Komponente geladen wird.
Schritt 406 stellt das Ende des Prozesses dar. Bei diesem Prozess wird die Komponente nicht als eine Boot-Komponente identifiziert und daher ist nicht bekannt, dass die Aktualisierung sich auf den von dem Attestierungssystem vorgehaltenen Attestierungswert auswirken wird.
5 zeigt einen Vergleich von Ergebnissen eines vertrauenswürdigen Systems nach dem Stand der Technik mit den Ergebnissen des vertrauenswürdigen Systems der bevorzugten Ausführungsform.
Eine vollständige Aktualisierung und Attestierung nach dem Stand der Technik weist die folgenden kombinierten Prozesse in Folge auf: 200, 300, 400 und erneut 300. Der Boot-Prozess 200 lädt die Boot-Komponenten, und jede Komponente wird der Reihe nach gemessen; die Messwerte werden in dem TPM20 gespeichert. Der Attestierungsprozess 300 ruft die Messwerte ab und prüft diese anhand der gespeicherten Attestierungswerte und zeigt eine Annahme an, da die Werte und Messwerte übereinstimmen. Der Aktualisierungsprozess 400 führt eine Aktualisierung bei einer oder mehreren Komponenten durch, darunter bei einer oder mehreren Boot-Komponenten, wobei der TPM-Messwert geändert wird. Eine weitere Ausführung des Attestierungsprozesses 300 zeigt eine Zurückweisung an, da der Attestierungswert nicht aktualisiert wurde und die Attestierungswerte und die TPM-Messwerte nicht übereinstimmen.
Der Aktualisierungs- und Attestierungsprozess der bevorzugten Ausführungsform weist folgende kombinierte Prozessschritte in Folge auf: 606, 622, 700 und erneut 622. Der Boot-Prozess 606 lädt die Boot-Komponenten; jede Boot-Komponente wird gemessen, und die Messwerte werden in einem TPM gespeichert. Ein Attestierungsprozess 622 der Ausführungsform ruft die Messwerte ab und prüft diese anhand der gespeicherten Attestierungswerte und zeigt eine Annahme an, da die Werte und Messwerte übereinstimmen. Der Aktualisierungsprozess 700 der Ausführungsform führt eine Aktualisierung bei einer oder mehreren Boot-Komponenten durch und ändert die Messwerte in dem TPM. Bei der bevorzugten Ausführungsform wird das Attestierungssystem benachrichtigt, dass die Aktualisierung durchgeführt wurde. Der Attestierungsprozess 622 zeigt eine Annahme an, da er die Herkunftsquelle der Aktualisierungskomponente prüft.
Bei einer anderen Ausführungsform werden die Attestierungswerte durch Messwerte aktualisiert, die während der Aktualisierung ermittelt wurden.
6 zeigt ein schematisches Komponentenschaubild des vertrauenswürdigen Datenverarbeitungssystems der bevorzugten Ausführungsform. Das vertrauenswürdige Datenverarbeitungssystem weist auf: eine Plattform 600; ein Attestierungssystem 620 und eine Aktualisierungsregistrierungsdatenbank 650.
Die Aktualisierungsregistrierungsdatenbank 650 ist eine Speicherressource und ein Index zum Vorhalten der aktuellen Versionen einzelner Komponenten von Betriebssystemen und Anwendungen, die zur Verwendung in Aktualisierungsinstanzen der Betriebssysteme oder Anwendungen dienen. In der Figur weist die Aktualisierungsregistrierungsdatenbank die Aktualisierungen 651.1 bis 650N auf. Das Abfragen der Versionsnummern oder Datumsangaben der Komponente in der Aktualisierungsregistrierungsdatenbank im Vergleich mit den Versionsnummern oder Datumsangaben einer Komponente einer Betriebssysteminstanz ergibt, welche Komponenten aktualisiert werden müssen.
Während des Betriebs ist die Plattform 600 eine Hardware-Plattform mit einem Hypervisor 604 zum Ausführen und Verwalten von virtuellen Betriebssystemen. Ein Beispiel einer Plattform ist ein IBM Power System. Während des Betriebs weist der Hypervisor 604 auf: einen Boot-Prozess 606; einen Aktualisierungsprozess 700; Aktualisierungseinrichtungen 612.1 bis 612N; und eine Hosting-Umgebung für eine virtuelle Maschine. Der Hypervisor des vorliegenden Beispiels erzeugt eine einzelne virtuelle Maschine 605 in der Hosting-Umgebung für ein einzelnes Betriebssystem 614, die bevorzugte Ausführungsform geht jedoch davon aus, dass mehr als ein Betriebssystem auf mehr als einer virtuellen Maschine aktualisiert werden könnte. Jede virtuelle Maschine verfügt über ein entsprechendes virtuelles TPM. Das Attestierungssystem vertraut jeder virtuellen Maschine, die auf einem Hypervisor ausgeführt wird. Das Vertrauen ergibt sich durch ein reales TPM oder durch aktuelle und vertrauenswürdige signierte Aktualisierungen und andere Sicherheitsmaßnahmen.
Das virtuelle Trusted Platform Module 610 weist eine Vielzahl von Registern (PCRs) PCR1, 2, 3 ... 17, 18 ... N auf. Jedes PCR kann einen Messwert oder einen Wert speichern.
Die Aktualisierungseinrichtungen 612.1 bis 612N weisen einen Beispielsatz von separaten Komponenten auf, von denen jede einer entsprechenden Boot-Komponente (616.1 bis 616N) zugeordnet ist und jede kann das Betriebssystem mit einer entsprechenden Aktualisierung (651.1 bis 651N) aktualisieren. Die Boot-Komponente 616.3 kann zum Beispiel von der Aktualisierungseinrichtung 612.3 unter Verwendung der Aktualisierung 651.3 aktualisiert werden und so weiter für die Boot-Komponente 616N, die Aktualisierungseinrichtung 612N und die Aktualisierung 651N. Jede Aktualisierungseinrichtung weist Verknüpfungen zu entsprechenden Aktualisierungen und Boot-Komponenten auf. Jede Aktualisierungseinrichtung soll gemessen und dann von dem Hypervisor ausgeführt werden. Der Messwert wird in einem ersten vereinbarten Register (zum Beispiel PCR17) gespeichert. Während der Ausführung misst eine Aktualisierungseinrichtung die neue Komponente, die sie installiert, und aktualisiert ein zweites vereinbartes Register (zum Beispiel PCR18). Es sei darauf hingewiesen, dass die Aktualisierungseinrichtung nur etwas kopieren oder während der Verarbeitung die Komponente erzeugen kann. Die Aktualisierungseinrichtung ”Bosboot” zum Beispiel erzeugt während der Verarbeitung ein Abbild einer neuen Betriebssystemkomponente von vielen Konfigurationsdateien und Systemdaten.
Bei einer bevorzugten Ausführungsform ist die Aktualisierungseinrichtung in der Lage, das Attestierungssystem direkt zu benachrichtigen, dass das Betriebssystem aktualisiert wurde. Dies kann bedeuten, dass die Aktualisierungseinrichtung direkten Kontakt zu dem Attestierungssystem herstellt oder einen gemeinsamen Prozess auf dem Hypervisor erhält, um Kontakt herzustellen. Das virtuelle Betriebssystem 614 (zum Beispiel IBM AIX*) weist, wenn es von dem Hypervisor geladen wird, die Boot-Komponenten 616.1 bis 616N auf, die als Teil des Boot-Prozesses geladen werden, um ein funktionierendes virtuelles Betriebssystem mit Anwendungen, Daten und Schnittstellen bereitzustellen. Andere Betriebssystemkomponenten, die nicht Teil des Boot-Prozesses sind, sind nicht dargestellt.
Der Boot-Prozess 606 weist einen Prozess wie der Boot-Prozess 200 nach dem Stand der Technik auf.
Das Attestierungssystem 620 weist auf: einen Attestierungsprozess 622 und die Attestierungswerte 624.1 bis 624N. Das Attestierungssystem 620 und der Hypervisor 604 haben vereinbart, welche Register (PCR1 ... N) verwendet werden, um den Messwert der Aktualisierungseinrichtung und die Signatur der geänderten Komponente (auch als das kennzeichnende Merkmal bezeichnet) aufzuzeichnen. Bei der bevorzugten Ausführungsform werden diese vereinbarten Register als erstes vereinbartes Register und zweites vereinbartes Register bezeichnet. In dem Beispiel handelt es sich bei dem ersten und zweiten vereinbarten Register beispielsweise um PCR17 und PCR18.
Das Attestierungssystem muss die Register in dem TPM attestieren. Alle Registerwerte werden unter Verwendung eines Attestierungsprotokolls weitergeleitet, bei dem digitale Signaturen und andere Sicherheitsmechanismen zur Gewährleistung des Vertrauens verwendet werden. Das Attestierungssystem kann erkennen, ob die vereinbarten Register (zum Beispiel das erste und zweite vereinbarte Register PCR17 und 18) gesetzt und in der Lage sind, das erneute Booten und die nachfolgende Änderung der aktuell vertrauenswürdigen Register (zum Beispiel PCR1, 2 und 3) vorzubereiten.
Das Attestierungssystem liest das erste vereinbarte Register (zum Beispiel PCR17) und stellt fest, dass es sich bei der Aktualisierungseinrichtung um eine vertrauenswürdige Aktualisierungseinrichtung handelt. Die Feststellung wird getroffen durch: Prüfen einer Hauptliste von Messwerten von bekannten und vertrauenswürdigen Aktualisierungseinrichtung; und Prüfen eines vertrauenswürdigen Boot-Ereignisprotokolls, das bei jeder Änderung an den Registern mit Metadaten aktualisiert wurde. Wenn das Attestierungssystem feststellt, dass das erste vereinbarte Register einen vertrauenswürdigen Wert enthält, geht es davon aus, dass das zweite vereinbarte Register ebenfalls einen vertrauenswürdigen Wert enthält, der beim nächsten Vergleich des Boot-Registers verwendet wird, das der in der Aktualisierung erkannten Aktualisierungseinrichtung zugeordnet ist.
Mit Bezug auf 7 weist der Hypervisor-Aktualisierungsprozess 700 die logischen Prozessschritte 702 bis 710 auf.
Schritt 702 dient zum Feststellen, dass eine Boot-Komponente eine verfügbare Aktualisierung aufweist, indem die Aktualisierungsregistrierungsdatenbank 650 nach neueren Komponenten abgesucht wird. Die Boot-Komponente 616.3 des virtuellen Betriebssystems 614 zum Beispiel weist Version 1 des AIX-Boot-Abbilds (AIX-Boot-Abbild1) auf, die Aktualisierung 651.3 in der Aktualisierungsregistrierungsdatenbank 650 wurde jedoch mit Version 2 des AIX-Boot-Abbilds (AIX-Boot-Abbild2) geladen. Dies wird bevorzugt, bei anderen Ausführungsformen kann jedoch ein anderer Mechanismus verwendet werden, um festzustellen, wann zu aktualisieren ist.
Schritt 704 dient zum Laden der neuen Boot-Komponente, indem die zugeordnete Aktualisierungseinrichtung (zum Beispiel die Aktualisierungseinrichtung 612.3) aktiviert wird und wobei die zugeordnete Aktualisierungseinrichtung in der Lage ist, die Boot-Komponente zu aktualisieren; die zugeordnete Aktualisierungseinrichtung greift auf die neue Boot-Komponente zu und installiert die neue Boot-Komponente über der alten Boot-Komponente oder installiert diese an deren Stelle. Die vorstehende Beschreibung ist die wesentliche Operation des Boot-Ladeschritts, und eine genauere Operation des Boot-Ladeschritts wird nachstehend mit Bezug auf 8 beschrieben.
Schritt 706 dient zum Messen einer neuen Boot-Komponente, nachdem diese in das virtuelle Betriebssystem geladen wurde, so dass der neue Messwert die neue Boot-Komponente an ihrem Platz in dem virtuellen Betriebssystem eindeutig identifiziert. Der neue Messwert wird zu einem spezifischen Register in dem Trusted Platform Module hinzugefügt. Bei der bevorzugten Ausführungsform sucht das Attestierungssystem 620 nach dem spezifischen Register und weiß, dass dieses einen neuen und keinen alten Messwert vorhält.
Schritt 708 dient zum Benachrichtigen des Attestierungssystems 620, dass eine Boot-Komponente aktualisiert wurde.
Schritt 710 zeigt das Ende des Aktualisierungsprozesses 700 an.
Während Schritt 704 zum Laden einer neuen Boot-Komponente vorstehend zwar als eine einfache Ausführungsform der Erfindung beschrieben wurde, verwendet die bevorzugte Ausführungsform der Erfindung eine weitere Verarbeitung, um das Niveau der Vertrauenswürdigkeit zu verbessern. Der wie nachstehend mit Bezug auf 8 beschriebene Prozess 704 zum Laden einer neuen Boot-Komponente ist eine bevorzugte Ausführungsform der Erfindung und weist die Prozessschritte 802 bis 812 auf.
Schritt 802 dient zum Identifizieren einer Aktualisierungskomponente, die der Boot-Komponente zugeordnet ist. In dem nachstehenden Beispiel wird ein Bosboot genanntes Programm aufgerufen, um das AIX-Boot-Abbild1 mit dem AIX-Boot-Abbild2 zu überschreiben.
Schritt 804 dient zum Laden der identifizierten Aktualisierungseinrichtung in das Betriebssystem.
Schritt 806 dient zum Messen der Aktualisierungseinrichtung und Hinzufügen des Messwerts zu dem ersten vereinbarten Register. In dem nachstehenden Beispiel misst ein Programm namens Hypercall Bosboot und vergrößert das erste vereinbarte Register (zum Beispiel PCR17) in dem TPM.
Schritt 808 dient zum Aufrufen der Aktualisierungseinrichtung, um die Aktualisierungskomponente zu installieren. In dem nachstehenden Beispiel schreibt Bosboot das neue Boot-Abbild.
Schritt 810 dient zum Messen der neuen Boot-Komponente und Hinzufügen des Messwerts zu dem zweiten vereinbarten Register.
Schritt 812 ist das Ende des Prozesses 704 zum Laden einer neuen Boot-Komponente.
Mit Bezug auf 9 werden die logischen Prozessschritte 902 bis 910 des Attestierungsprozesses 622 gemäß der bevorzugten Ausführungsform beschrieben. Der Attestierungsprozess wird nach dem Booten der vertrauenswürdigen Plattform ausgeführt, ist jedoch unabhängig von der vertrauenswürdigen Plattform.
Schritt 902 dient zum Extrahieren von Messwerten, die in Registern gespeichert sind.
Schritt 904 dient zum Vergleichen der Messwerte mit den Attestierungswerten 624.1 bis 624N, die von dem Attestierungssystem 620 gespeichert werden.
Schritt 906 dient zum Anzeigen einer Annahme, wenn die Werte mit den Messwerten übereinstimmen.
Schritt 908 dient zum Anzeigen einer Zurückweisung, wenn nichtübereinstimmende Boot-Messwerte von Schritt 906 mit einer bekannten Aktualisierungseinrichtung übereinstimmen.
Schritt 910 dient zum Anzeigen einer Zurückweisung, wenn nichtübereinstimmende Messwerte nach den Schritten 908 und 910 vorliegen.
Schritt 912 dient zum Anzeigen des Endes des Prozesses.
BEISPIEL
Ein Beispiel der Operation der bevorzugten Ausführungsform weist ein IBM Power* System auf, das einen IBM Power Hypervisor (PHYP) mit einem einzelnen virtuellen AIX-System beherbergt. Das AIX-System verwendet eine virtuelle TPM-Einheit und beinhaltet eine vertrauenswürdige Boot-Funktionalität. Das System wird von einem separaten Attestierungssystem überwacht und attestiert. Beim Attestieren werden die folgenden PCR-Messwerte zurückgesendet, wobei PCR1, PCR2, PCR3 Register in dem TPM sind.
PCR1 = Open-Firmware
PCR2 = AIX-Boot-Abbild
PCR3 = AIX Trusted Execution Database
Das Attestierungssystem betrachtet diese Messwerte als vertrauenswürdig und zeigt kein Sicherheitsproblem an, wenn diese über die Attestierung zurückgesendet werden. Damit das AIX-Boot-Abbild geändert und das Attestierungssystem über diese Aktualisierung informiert werden kann, gibt es noch folgende Funktionen.
PHYP wird geändert, so dass er ein neues Verfahren (als Hypercall und insbesondere als H_Messen bezeichnet) aufweist. H_Messen verwendet Parameter, die etwas beschreiben, das gemessen und ausgeführt werden soll, zum Beispiel Adresse und Länge. Der sich daraus ergebende Messwert wird in ein bestimmtes Register des TPM, beispielsweise PCR17, gesetzt. Das jeweilige Boot-Register ist nicht wichtig, wobei es sich um ein absolut adressiertes Register oder ein indirekt adressiertes Register handeln kann. Wichtig ist, dass das Attestierungssystem weiß, wo es nachschauen muss. PHYP gibt die Steuerung an der Adresse, an der vorbeigegangen wurde, an AIX zurück, der wichtige Unterschied besteht darin, dass der Hypercall zuerst verwendet wird, um eine Komponente zu messen, und dann, um diese Komponente auszuführen. Was gemessen wird, wird anschließend ausgeführt.
Um zu funktionieren, muss auch der Hypervisor vertrauenswürdig sein. Die Vertrauenswürdigkeit eines Hypervisor nach dem Stand der Technik wird durch das IBM Power System gewährleistet, das den PHYP-Code in sehr restriktiver Art und Weise aktualisiert, und nur durch das IBM Power System signierte Aktualisierungen können installiert werden. Bei der vorliegenden Ausführungsform weist das IBM Power System eine reale TPM-Einheit auf, und der PHYP wird in dem realen TPM gemessen. Eine als ”Deep-Attestation” (tiefe Attestierung) bekannte Technik kann verwendet werden, um die realen TPM-Messwerte über das virtuelle AIX-System abzurufen.
Ein definierter Satz von AIX-Programmen, die in der Beschreibung als Aktualisierungseinrichtung bezeichnet werden, dürfen Komponenten des vertrauenswürdigen Boot-Vorgangs ändern. In diesem Beispiel ist Bosboot das einzige Aktualisierungseinrichtungsprogramm, das das AIX-Boot-Abbild aktualisieren darf. Bei dieser Technik muss Bosboot vertrauenswürdig sein, und wenn Bosboot daher aufgebaut wird, wird eine digitale Signatur von Bosboot genommen und veröffentlicht. Damit H_Messen Bosboot erfolgreich messen kann, sollte Bosboot ein einzelner statischer Codeteil sein, der in einen zusammenhängenden Speicherteil geladen werden kann, damit die Messung durchgeführt werden kann. Es ist wichtig, dass Bosboot messbar ist. Bosboot muss nicht statisch sein, wenn andere Sicherheitsmaßnahmen vorhanden sind, um sicherzustellen, dass nichtstatische Programme nicht ohne Weiteres umgangen werden können.
In diesem Beispiel wird ein AIX-Boot-Abbild1 in ein AIX-Boot-Abbild2 geändert, womit dem Attestierungssystem mitgeteilt wird, dass eine unnötige Sicherheitsverletzung verhindert wurde. Die Operationen sind wie folgt:

1. Bosboot (eine Aktualisierungseinrichtung) wird aufgerufen (Schritt 702), um das Boot-Abbild neu zu schreiben.
2. Der AIX-Kern lädt (Schritt 704) Bosboot in den Speicher und ruft H_Messen auf.
3. PHYP misst (Schritt 706) Bosboot und vergrößert PCR17 in dem TPM.
4. Die Ausführung wird von dem Hypervisor an Bosboot weitergegeben, und Bosboot schreibt das neue Boot-Abbild und vergrößert PCR18 mit einem Messwert eines AIX-Boot-Abbilds2. Ähnlich wie bei PCR17 ist es auch hier nicht wichtig, welches Register verwendet wird, solange das Attestierungssystem weiß, dass PCR18 eine besondere Bedeutung hat.
5. Das Attestierungssystem wird informiert (Schritt 708), dass es erneut attestieren sollte, wobei keine Informationen mehr ausgetauscht werden müssen.

Wenn das Attestierungssystem das System nun attestiert, werden folgende Werte zurückgesendet (Schritt 902).
PCR1 = Open-Firmware
PCR2 = AIX-Boot-Abbild1
PCR3 = AIX Trusted-Execution Database1
PCR17 = bosboot
PCR18 = AIX-Boot-Abbild2
Das Attestierungssystem wird feststellen, dass PCR17 seit der letzten Attestierung geändert wurde, dies wird eine Maßnahme (Schritt 908) in dem Attestierungssystem auslösen. Zuerst wird der Wert von PCR17 geprüft, das System stellt fest, dass ein zulässiges von IBM veröffentlichtes Bosboot aufgerufen wurde, daher weiß das System, dass PCR18 ein neues AIX-Boot-Abbild sein wird. Wenn das Attestierungssystem nun einen neuen vertrauenswürdigen Boot-Vorgang abschließt, kann das Attestierungssystem feststellen, dass der neue über PCR1 gemeldete Wert von einem vertrauenswürdigen Bosboot gekommen ist, so dass keine Maßnahme erforderlich ist.
AUSFÜHRUNGSFORMEN
Vorstehend ist die bevorzugte Ausführungsform mit einem Hypervisor beschrieben, um eine Betriebsumgebung einer virtuellen Maschine zu verwalten, sowie andere Ausführungsformen, bei denen eine einzelne Funktion auf die eine oder andere Weise von der bevorzugten Ausführungsform abweichen kann.
Eine Ausführungsform, die sich wesentlich von der bevorzugten Ausführungsform unterscheidet, bezieht sich auf eine Ausführungsform ohne Virtualisierung, eine wie in 10 dargestellte nichtvirtuelle Umgebung. Diese Ausführungsform weist auf: eine Plattform 1000; ein Attestierungssystem 1020 und eine Aktualisierungsregistrierungsdatenbank 1050. Die Plattform 1000 ist auf der Basis von Silicium entworfen und hergestellt. Ähnlich wie die bevorzugte Ausführungsform ist das TPM 1010 kein wesentlicher Bestandteil, und eine andere sichere Einheit/ein anderer Speicher, die/der Messwerte und etwas Ähnliches wie eine Attestierung vorhält, könnte verwendet werden.
Die Aktualisierungsregistrierungsdatenbank 1050 ist eine Speicherressource und ein Index zum Vorhalten der aktuellen Versionen einzelner Komponenten von Betriebssystemen und Anwendungen, die zur Verwendung in Aktualisierungsinstanzen der Betriebssysteme oder Anwendungen dienen. In der Figur weist die Aktualisierungsregistrierungsdatenbank die Aktualisierungen 1051.1 bis 1050N auf. Das Abfragen der Versionsnummern oder Datumsangaben der Komponente in der Aktualisierungsregistrierungsdatenbank im Vergleich mit den Versionsnummern oder Datumsangaben einer Komponente einer Betriebssysteminstanz ergibt, welche Komponenten aktualisiert werden müssen.
Das Attestierungssystem 1020 weist einen Attestierungsprozess 1022 und die Attestierungswerte 1024.1 bis 1024N auf. Neben dem Unterschied, dass das Betriebssystem ein reales Betriebssystem ist, das auf einer physischen Maschine ausgeführt wird, sind der Attestierungsprozess 1022 und die Attestierungswerte 1024.1 bis 1024N gleich wie die in 6 dargestellten.
Während des Betriebs ist die Plattform 1000 eine Hardware-Plattform, die aufweist: einen Boot-Prozess 1006; einen Aktualisierungsprozess 1700; Aktualisierungseinrichtungen 1012.1 bis 1012N; ein TPM 1010; und ein Betriebssystem 1014. Ähnlich wie die bevorzugte Ausführungsform ist das TPM 1010 kein wesentlicher Bestandteil, und eine andere sichere Einheit/ein anderer Speicher, die/der Messwerte und etwas Ähnliches wie eine Attestierung vorhält, könnte verwendet werden.
In der nichtvirtuellen Umgebung weist ein TPM 1010 die Spezialregister (SR1 ... SRN) auf, die zum Vorhalten von Messwerten verwendet werden können. SRs verhalten sich insofern genau wie PCRs, als ein Schreibvorgang in ihnen tatsächlich ein Schreiben eines neuen Werts zusammen mit dem alten Wert sowie anschließend unter Verwendung eines starken Hash-Algorithmus ein Streuen beinhaltet. Der Prozessor weist Befehle auf, die eine Aktualisierung dieser Spezialregister (SRs) ermöglichen. Der Prozessor wird geändert, um einen Messbefehl aufzuweisen. Dieser Befehl verwendet eine Kennung für ein SR, eine Speicheradresse und eine Länge. Er misst die Daten an der Adresse (und alle Bytes bis zur Länge) und speichert dann den Messwert in dem spezifizierten SR. Der Prozessor überträgt die Ausführung an die Adresse.
In der nichtvirtuellen Umgebung muss die Plattform 1000 Code aktualisieren, wobei dem Code zugeordneter Aktualisierungscode vorhanden ist, um die Aktualisierung durchzuführen. Der zugeordnete Code wird in den Speicher geladen, anschließend wird der Messbefehl verwendet, um den zugeordneten Code zu messen und auszuführen. Der Messwert wird in einem ersten vereinbarten Register gespeichert. Der ausgeführte zugeordnete Code kann nun den Code installieren, dies beinhaltet vielleicht nur das Schreiben von Daten auf eine Platte. Vor dem Schreibvorgang oder vor jedem Schreibvorgang (sofern eine N-Byte-Schreibbegrenzung besteht) werden Messwerte ermittelt und in ein zweites vereinbartes Register geschrieben (ein SR, wobei dies mit der Aktualisierung des zweiten vereinbarten Registers PCR18 korreliert).
In der nichtvirtuellen Umgebung muss die Plattform 1000 ein Attestierungssystem 1020 darüber informieren, dass eine Aktualisierung stattgefunden hat. Wie bei der bevorzugten Ausführungsform attestiert das Attestierungssystem 1020, wodurch die Werte der SRs unter Verwendung kryptografischer Techniken übertragen werden, um die Vertrauenswürdigkeit aufrechtzuerhalten. Der Attestierungsprozess 1022 ähnelt der bevorzugten Ausführungsform.
Fachleuten ist ersichtlich, dass das Verfahren der beschriebenen Ausführungsformen der vorliegenden Erfindung ganz oder teilweise auf geeignete Weise in einer Logikvorrichtung oder einer Vielzahl von Logikvorrichtungen ausgeführt werden kann, die Logikelemente aufweist, die so angeordnet sind, dass sie die Verfahrensschritte durchführen, und dass diese Logikelemente Hardware-Komponenten, Firmware-Komponenten oder eine Kombination davon aufweisen können.
Fachleuten ist ferner ersichtlich, dass eine Logikanordnung gemäß den beschriebenen Ausführungsformen der vorliegenden Erfindung ganz oder teilweise auf geeignete Weise in einer Logikvorrichtung umgesetzt werden kann, die Logikelemente aufweist, um die Verfahrensschritte durchzuführen, und dass diese Logikelemente Komponenten wie Logikgatter in beispielsweise einem programmierbaren Logik-Array oder einer anwendungsspezifischen integrierten Schaltung aufweisen können. Eine solche Logikanordnung kann weiterhin in Basiselementen umgesetzt werden, um Logikstrukturen in einem solchen Array oder einer solchen Schaltung zum Beispiel unter Verwendung einer virtuellen Hardware-Deskriptorsprache vorübergehend oder dauerhaft einzurichten, die mit Hilfe fester oder übertragbarer Trägermedien gespeichert und übertragen werden kann.
Es ist ersichtlich, dass das oben beschriebene Verfahren und die oben beschriebene Anordnung auch ganz oder teilweise auf geeignete Weise in einer Software ausgeführt werden können, die auf einem oder mehreren Prozessoren (nicht in den Figuren dargestellt) läuft, und dass die Software in Form von einem oder mehreren Computerprogrammelementen bereitgestellt werden kann, die sich auf einem beliebigen geeigneten Datenträger (ebenfalls nicht in den Figuren dargestellt) wie beispielsweise einer Magnet- oder optischen Platte oder Ähnlichem befinden können. Kanäle für die Übertragung von Daten können ihrerseits Speichermedien aller Beschreibungen sowie signaltragende Medien wie drahtgebundene oder drahtlose signaltragende Medien aufweisen.
Die vorliegende Erfindung kann weiterhin auf geeignete Weise als ein Computerprogrammprodukt zur Verwendung mit einem Computersystem ausgeführt werden. Eine solche Ausführung kann eine Reihe von computerlesbaren Befehlen aufweisen, die entweder auf einem physischen Medium wie einem computerlesbaren Medium, beispielsweise einer Diskette, einer CD-ROM, ROM oder einer Festplatte, fest gespeichert sind oder zu einem Computersystem übertragen werden können und zwar unter Verwendung eines Modems oder einer anderen Schnittstelleneinheit über entweder ein physisches Medium, darunter optische oder analoge Datenübertragungsleitungen, ohne jedoch auf diese beschränkt zu sein, oder immateriell unter Verwendung drahtloser Techniken, darunter Mikrowellen-, Infrarot- oder andere Übertragungstechniken, ohne jedoch auf diese beschränkt zu sein. Die Reihe von computerlesbaren Befehlen setzt die oben beschriebene Funktionalität ganz oder teilweise um.
Fachleuten ist ersichtlich, dass diese computerlesbaren Befehle in einer Reihe von Programmiersprachen zur Verwendung mit vielen Computerarchitekturen oder Betriebssystemen geschrieben werden können. Solche Befehle können weiterhin unter Verwendung einer beliebigen aktuellen oder künftigen Speichertechnologie gespeichert werden, einschließlich Halbleiter-, magnetische oder optische Technologie, ohne jedoch auf diese beschränkt zu sein, oder unter Verwendung einer aktuellen oder künftigen Datenübertragungstechnologie übertragen werden, einschließlich optische, Infrarot- oder Mikrowellentechnologie, ohne jedoch auf diese beschränkt zu sein. Es ist denkbar, dass ein solches Computerprogrammprodukt als ein austauschbares Medium mit beigefügter gedruckter oder elektronischer Dokumentation verbreitet werden kann, zum Beispiel als in Folie eingeschweißte Software, vorinstalliert auf einem Computersystem, zum Beispiel auf einer System-ROM oder einer Festplatte, oder von einem Server oder einem elektronischen Schwarzen Brett über ein Netzwerk, zum Beispiel das Internet oder das World Wide Web, verbreitet werden kann.
Alternativ kann die bevorzugte Ausführungsform der vorliegenden Erfindung in Form eines auf einem Computer implementierten Verfahrens zum Implementieren eines Dienstes umgesetzt werden, das die Schritte zum Implementieren eines Computerprogrammcodes aufweist, der das Computersystem funktionsmäßig veranlassen kann, alle Verfahrensschritte durchzuführen, wenn der Code in einer Computerinfrastruktur implementiert und in dieser ausgeführt wird.
Alternativ können die beschriebenen Ausführungsformen der vorliegenden Erfindung in Form eines Datenträgers mit darauf enthaltenen Funktionsdaten umgesetzt werden, wobei die Funktionsdaten funktionale Computerdatenstrukturen aufweisen, um das Computersystem in die Lage zu versetzen, alle Verfahrensschritte durchzuführen, wenn die Daten in ein Computersystem geladen und auf diesem ausgeführt werden.
Dem Fachmann ist ersichtlich, dass viele Verbesserungen und Änderungen an der vorgenannten beispielhaften Ausführungsform vorgenommen werden können, ohne vom Schutzumfang der vorliegenden Erfindung abzuweichen.
ZUSAMMENFASSUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM
Zusammenfassend bezieht sich diese Erfindung auf ein Verfahren und eine Vorrichtung zum Aktualisieren eines Betriebssystems, das in einer vertrauenswürdigen Hypervisor-Datenverarbeitungsumgebung ausgeführt wird. Diese Erfindung bezieht sich insbesondere auf ein Verfahren, ein System und ein Computerprogrammprodukt zum Aktualisieren eines Betriebssystems, das in einer Hypervisor-Umgebung ausgeführt wird, aufweisend: Feststellen einer neuen Version einer Komponente eines Betriebssystems; Installieren der neuen Komponentenversion; Messen eines kennzeichnenden Merkmals der Komponente und Bereitstellen desselben für ein Attestierungssystem; Benachrichtigen des Attestierungssystems, dass eine Komponente auf eine neue Version aktualisiert wurde, wobei, wenn das Attestierungssystem feststellt, dass das kennzeichnende Merkmal der neuen Komponente nicht mit einem zuvor gespeicherten Attestierungswert übereinstimmt, das System weiß, dass eine zulässige Nichtübereinstimmung aufgetreten sein könnte. Das Installieren der neuen Version der Komponente weist auf: Identifizieren einer Aktualisierungsvorrichtung, die der neuen Version der Komponente zugeordnet ist; Messen eines kennzeichnenden Merkmals der identifizierten Aktualisierungseinrichtung; Laden und Installieren der neuen Version der Komponente; und Bereitstellen sowohl des kennzeichnenden Messwerts der Aktualisierungseinrichtung als auch der neuen Version der Komponente für das Attestierungssystem.
HINWEISE

*IBM, AIX, Express, ibm.com, Power, Power7 und Tivoli sind Warenzeichen oder eingetragene Warenzeichen der International Business Machines Corporation in den Vereinigten Staaten, anderen Ländern oder beides. Eine vollständige Liste der US-amerikanischen Warenzeichen von IBM kann unter folgender Adresse abgerufen werden: www.ibm.com/legal/copytrade.shtml.

ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

www.ibm.com/legal/copytrade.shtml [0109]

Claims

Verfahren zum Aktualisieren von Code in einer Ausführungsumgebung, aufweisend: Installieren von neuem Code; Messen eines kennzeichnenden Merkmals des neuen Codes und dessen Bereitstellen für ein Attestierungssystem; Benachrichtigen des Attestierungssystems, dass Code auf eine neue Version aktualisiert wurde, wobei, wenn das Attestierungssystem feststellt, dass das kennzeichnende Merkmal des neuen Codes nicht mit einem zuvor gespeicherten Attestierungswert übereinstimmt, das System weiß, dass eine zulässige Nichtübereinstimmung aufgetreten sein könnte.
Verfahren nach Anspruch 1, wobei das Installieren des neuen Codes aufweist: Identifizieren einer Aktualisierungseinrichtung, die dem neuen Code zugeordnet ist; Messen eines kennzeichnenden Merkmals der identifizierten Aktualisierungseinrichtung; Installieren des neuen Codes; und Bereitstellen des kennzeichnenden Messwerts der Aktualisierungseinrichtung für das Attestierungssystem, wobei das Attestierungssystem den kennzeichnenden Messwert der Aktualisierungseinrichtung mit einem zuvor gespeicherten Attestierungswert in Übereinstimmung bringen kann, um eine zulässige Aktualisierung für gültig zu erklären.
Verfahren nach einem der Ansprüche 1 oder 2, wobei die kennzeichnenden Merkmale in einem sicheren Speicher gespeichert werden, auf den nur das Speicherverfahren und das Attestierungssystem Zugriff haben.
Verfahren nach einem der Ansprüche 1 bis 3, wobei es sich bei der Ausführungsumgebung um einen Hypervisor und bei dem Code um ein virtuelles Betriebssystem zum Ausführen in einer virtuellen Maschine des Hypervisor handelt.
Verfahren nach einem der Ansprüche 1 bis 4, wobei Register sich in einem vertrauenswürdigen Plattformmodul befinden.
Verfahren nach einem der Ansprüche 1 bis 5, das weiterhin ein Feststellen beinhaltet, dass neuer Code zur Verfügung steht und dass eine Aktualisierung erforderlich ist, bevor die Schritte von Anspruch 1 durchgeführt werden.
Verfahren nach einem der Ansprüche 1 bis 6, wobei das Attestierungssystem direkt nach der Benachrichtigung die Herkunftsquelle des neuen Codes prüft.
Verfahren nach Anspruch 7, wobei, wenn der Messwert nicht mit einem Attestierungswert übereinstimmt und das Attestierungssystem die Herkunftsquelle des entsprechenden Codes geprüft hat, dann: Aktualisieren des Attestierungswerts mit dem Messwert der neuen Version der Komponente; und/oder Benachrichtigen einer Verwaltungsebene, dass ein Messwert nicht mit einem Attestierungswert übereinstimmt und ob das Attestierungssystem die Herkunftsquelle der Komponente erkennt.
Verfahren zum Aktualisieren und Attestieren von Code in einer Ausführungsumgebung, aufweisend: Installieren von neuem Code; Messen eines kennzeichnenden Merkmals des neuen Codes und dessen Bereitstellen für ein Attestierungssystem; Benachrichtigen des Attestierungssystems, dass Code auf eine neue Version aktualisiert wurde; und wobei, wenn das Attestierungssystem feststellt, dass das kennzeichnende Merkmal des neuen Codes nicht mit einem zuvor gespeicherten Attestierungswert übereinstimmt, das System weiß, dass eine zulässige Nichtübereinstimmung aufgetreten sein könnte.
Verfahren zum Prüfen der Unversehrtheit eines Programms, aufweisend: Extrahieren eines von dem Programminstallationsprozess gespeicherten Code-Messwerts; Prüfen des Code-Messwerts anhand von Referenzmesswerten, die von dem Prüfsystem gespeichert werden, und Zurückweisen des Messwerts, wenn dieser nicht übereinstimmt; weiteres Prüfen des zurückgewiesenen Code-Messwerts und erneutes Zurückweisen, wenn der Messwert nicht von einer dem Prüfsystem bekannten Komponente stammt; und Anzeigen einer Annahme, wenn der Code-Messwert eine Prüfung besteht, und einer Zurückweisung, wenn ein Code-Messwert keine der Prüfungen besteht.
System zum Aktualisieren von Code in einer Ausführungsumgebung, aufweisend: ein Installationsmittel zum Installieren von neuem Code; ein Messmittel zum Messen eines kennzeichnenden Merkmals des neuen Codes und dessen Bereitstellen für ein Attestierungssystem; ein Benachrichtigungsmittel zum Benachrichtigen des Attestierungssystems, dass Code auf eine neue Version aktualisiert wurde, wobei, wenn das Attestierungssystem feststellt, dass das kennzeichnende Merkmal des neuen Codes nicht mit einem zuvor gespeicherten Attestierungswert übereinstimmt, das System weiß, dass eine zulässige Nichtübereinstimmung aufgetreten sein könnte.
System nach Anspruch 11, wobei das Installieren des neuen Codes aufweist: ein Identifizierungsmittel zum Identifizieren einer Aktualisierungseinrichtung, die dem neuen Code zugeordnet ist; ein Messmittel zum Messen eines kennzeichnenden Merkmals der identifizierten Aktualisierungseinrichtung; ein Installationsmittel zum Installieren des neuen Codes; und ein Mittel zum Bereitstellen des kennzeichnenden Messwerts der Aktualisierungseinrichtung für das Attestierungssystem, wobei das Attestierungssystem den kennzeichnenden Messwert der Aktualisierungseinrichtung mit einem zuvor gespeicherten Attestierungswert in Übereinstimmung bringen kann, um eine zulässige Aktualisierung für gültig zu erklären.
System nach einem der Ansprüche 11 oder 12, wobei die kennzeichnenden Merkmale in einem sicheren Speicher gespeichert werden, auf den nur das Speicherverfahren und das Attestierungssystem Zugriff haben.
System nach einem der Ansprüche 11 bis 13, wobei es sich bei der Ausführungsumgebung um einen Hypervisor und bei dem Code um ein virtuelles Betriebssystem zum Ausführen in einer virtuellen Maschine des Hypervisor handelt.
System nach einem der Ansprüche 11 bis 14, wobei Register sich in einem vertrauenswürdigen Plattformmodul befinden.
System nach einem der Ansprüche 11 bis 15, das weiterhin ein Feststellen beinhaltet, dass neuer Code zur Verfügung steht und dass eine Aktualisierung erforderlich ist, bevor die Schritte von Anspruch 11 durchgeführt werden.
System nach einem der Ansprüche 11 bis 16, wobei das Attestierungssystem direkt nach der Benachrichtigung die Herkunftsquelle des neuen Codes prüft.
System nach Anspruch 17, wobei, wenn der Messwert nicht mit einem Attestierungswert übereinstimmt und das Attestierungssystem die Herkunftsquelle des entsprechenden Codes geprüft hat, dann: Aktualisieren des Attestierungswerts mit dem Messwert der neuen Version der Komponente; und/oder Benachrichtigen einer Verwaltungsebene, dass ein Messwert nicht mit einem Attestierungswert übereinstimmt und ob das Attestierungssystem die Herkunftsquelle der Komponente erkennt.
System zum Aktualisieren und Attestieren von Code in einer Ausführungsumgebung, wobei das System aufweist: Installationsmittel zum Installieren von neuem Code; ein Messmittel zum Messen eines kennzeichnenden Merkmals des neuen Codes und dessen Bereitstellen für ein Attestierungssystem; ein Benachrichtigungsmittel zum Benachrichtigen des Attestierungssystems, dass Code auf eine neue Version aktualisiert wurde; und wobei, wenn das Attestierungssystem feststellt, dass das kennzeichnende Merkmal des neuen Codes nicht mit einem zuvor gespeicherten Attestierungswert übereinstimmt, das System weiß, dass eine zulässige Nichtübereinstimmung aufgetreten sein könnte.
System zum Prüfen der Unversehrtheit eines Programms, aufweisend: Extrahieren eines von dem Programminstallationsprozess gespeicherten Code-Messwerts; ein Prüfmittel zum Prüfen des Code-Messwerts anhand von Referenzmesswerten, die von dem Prüfsystem gespeichert werden, und Zurückweisen des Messwerts, wenn dieser nicht übereinstimmt; ein weiteres Prüfmittel zum Prüfen des zurückgewiesenen Code-Messwerts und erneutes Zurückweisen, wenn der Messwert nicht von einer dem Prüfsystem bekannten Komponente stammt; und ein Anzeigemittel zum Anzeigen einer Annahme, wenn der Code-Messwert eine Prüfung besteht, und einer Zurückweisung, wenn ein Code-Messwert keine der Prüfungen besteht.
Computerprogrammprodukt zum Erzeugen einer ersten Computerressource in einem Client-Computer, wobei das Computerprogrammprodukt aufweist: ein computerlesbares Speichermedium, das von einer Verarbeitungsschaltung lesbar ist und Befehle zum Ausführen durch die Verarbeitungsschaltung speichert, um ein Verfahren gemäß einem der Ansprüche 1 bis 10 durchzuführen.
Computerprogramm, das in einem computerlesbaren Medium gespeichert ist und in den internen Speicher eines digitalen Computers ladbar ist und Teile eines Softwarecodes aufweist, wenn das Programm auf einem Computer ausgeführt wird, um das Verfahren eines der Ansprüche 1 bis 10 durchzuführen.