DE112018002031T5

DE112018002031T5 - Sichern einer betriebssystemkonfiguration unter verwendung von hardware

Info

Publication number: DE112018002031T5
Application number: DE112018002031.2T
Authority: DE
Inventors: Patrick Joseph Callaghan
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2017-06-16
Filing date: 2018-06-12
Publication date: 2020-01-16
Anticipated expiration: 2038-06-13
Also published as: WO2018229640A1; GB2576469B; GB201918518D0; JP7169042B2; CN110663027A; US20200019709A1; US20180365427A1; GB2576469A; CN110663027B; US11113404B2; US20180365426A1; US10482259B2; JP2020523685A; US11080405B2; DE112018002031B4; US20200019710A1; US10467416B2

Abstract

Ein Verfahren, System und Computerprogrammprodukt beinhaltet das Empfangen, in einem gebooteten Zustand eines Datenverarbeitungssystems, einer Anforderung für das Laden einer Betriebssystemkonfiguration. Das Verfahren beinhaltet des Weiteren das Speichern, automatisch als Reaktion auf das Empfangen der Anforderung, eines digitalen Schlüssels, um die Betriebssystemkonfiguration zu authentifizieren. Das Verfahren beinhaltet des Weiteren das Neustarten des Datenverarbeitungssystems. Als Reaktion auf das Neustarten des Datenverarbeitungssystems und während sich das Datenverarbeitungssystem in einem Preboot-Zustand befindet, beinhaltet das Verfahren: Validieren, dass der gespeicherte digitale Schlüssel ein Schlüssel für eine gültige Betriebssystemkonfiguration ist; Empfangen, von einer mit dem Datenverarbeitungssystem physisch verbundenen Benutzerschnittstelle, eines Signals, das die empfangene Anforderung bestätigt; Authentifizieren, als Reaktion auf das Empfangen des Signals, der Betriebssystemkonfiguration unter Verwendung des digitalen Schlüssels; und Booten, als Reaktion auf das Authentifizieren, der Betriebssystem konfiguration.

Description

HINTERGRUND
Die vorliegende Offenbarung betrifft Datenverarbeitungssysteme, bei denen ein sicheres Booten von Betriebssystemen zur Anwendung kommt. Genauer gesagt, die vorliegende Offenbarung betrifft das Sichern einer Betriebssystemkonfiguration von Datenverarbeitungssystemen unter Verwendung von Hardware.
Datenverarbeitungssysteme verfügen über Zugriffssteuerungsrichtlinien, die den Zugriff beschränken können, den Benutzer auf Dateisystem-Objekte haben. Eine Zugriffssteuerungsrichtlinie kann zum Beispiel die Dateien beschränken, die ein Benutzer modifizieren kann, oder sie kann einen Benutzer daran hindern, ein bestimmtes Betriebssystemmodul zu laden. Zugriffssteuerungsrichtlinien können von der Konfiguration eines Betriebssystems, das auf einem Datenverarbeitungssystem ausgeführt wird, durchgesetzt werden. Eine Betriebssystemkonfiguration wiederum kann festgelegt werden, indem Kernel-Parameter gesetzt werden, die mit einer bestimmten Konfiguration eines Betriebssystemkernels übereinstimmen, bevor der Kernel verwendet wird, um ein Datenverarbeitungssystem in einen Zustand zu booten, der für die Ausführung von Benutzeranwendungen geeignet ist. Sobald ein Datenverarbeitungssystem unter Verwendung einer bestimmten Betriebssystemkonfiguration gebootet wird, kann die von der Konfiguration durchgesetzte Zugriffssteuerungsrichtlinie wirksam bleiben, bis das Datenverarbeitungssystem unter einer anderen Betriebssystemkonfiguration gebootet wird, sofern dies durch das Datenverarbeitungssystem gestattet wird.
Einige Datenverarbeitungssysteme ermöglichen es Benutzern, unter einem Satz von verschiedenen Betriebssystemkonfigurationen zu wählen. Ein Benutzer mit einem gültigen Konto auf diesen Datenverarbeitungssystemen kann eine Zugriffssteuerungsrichtlinie (oder die Durchsetzung einer Zugriffssteuerungsrichtlinie) eines Datenverarbeitungssystems ändern, indem er eine Betriebssystemkonfiguration auswählt und bootet, die eine andere Zugriffssteuerungsrichtlinie als die Konfiguration hat, die gerade gebootet wird.
Es ist für Benutzer üblich, unter Verwendung eines Kontoberechtigungsnachweises (z.B. eines Benutzernamens und Kennworts) einen Fernzugriff auf Datenverarbeitungssysteme durchzuführen. Benutzer, die einen Fernzugriff auf ein Datenverarbeitungssystem durchführen, unterliegen gewöhnlich denselben Zugriffssteuerungsrichtlinien wie Benutzer, die von einem lokalen Terminal auf das Datenverarbeitungssystem zugreifen. Berechtigte Benutzer eines Datenverarbeitungssystems können die Zugriffssteuerungsrichtlinie des Datenverarbeitungssystems unter Verwendung des zuvor beschriebenen Prozesses folglich über einen Fernzugriff ändern. Ein Nebeneffekt dieses Regimes ist jedoch, dass nicht berechtigte Benutzer, die in der Lage sind, den Zugriffsberechtigungsnachweis eines berechtigten Benutzers auf ein Datenverarbeitungssystem zu erlangen, auch die Zugriffssteuerungsrichtlinie des Datenverarbeitungssystems über einen Fernzugriff ändern können, wobei sie möglicherweise ihre Zugriffsberechtigungen auf dem Datenverarbeitungssystem erweitern.
In Anbetracht des Vorstehenden gibt es einen Bedarf an Techniken, um es einem Benutzer eines Datenverarbeitungssystems zu ermöglichen, unter einem Satz von verschiedenen Betriebssystemkonfigurationen zu wählen und die Gewissheit zu haben, dass die gewählte Konfiguration nicht modifiziert, verändert oder in anderer Weise manipuliert wurde, bevor die gewählte Konfiguration auf dem Datenverarbeitungssystem gebootet wird.
KU RZDARSTELLU NG
Zu Ausführungsformen dieser Offenbarung gehören Verfahren, Systeme und Computerprogrammprodukte, die es einem Benutzer eines Datenverarbeitungssystems ermöglichen, unter einem Satz von verschiedenen Betriebssystemkonfigurationen zu wählen und die Gewissheit zu haben, dass die gewählte Konfiguration nicht modifiziert, verändert oder in anderer Weise manipuliert wurde, bevor die gewählte Konfiguration auf dem Datenverarbeitungssystem gebootet wird. Die hierin offenbarten Ausführungsformen bieten Vorteile bei der Sicherheit, Zugriffsflexibilität und Verwaltung von Datenverarbeitungssystemen.
Gemäß Ausführungsformen der vorliegenden Offenbarung beinhaltet ein Verfahren das Empfangen, in einem gebooteten Zustand eines Datenverarbeitungssystems, einer Anforderung für das Laden einer Betriebssystemkonfiguration. Das Verfahren beinhaltet des Weiteren das Speichern, automatisch als Reaktion auf das Empfangen der Anforderung, eines digitalen Schlüssels, um die Betriebssystemkonfiguration zu authentifizieren. Das Verfahren beinhaltet des Weiteren das Neustarten des Datenverarbeitungssystems. Als Reaktion auf das Neustarten des Datenverarbeitungssystems und während sich das Datenverarbeitungssystem in einem Zustand vor dem Starten (Preboot-Zustand) befindet, beinhaltet das Verfahren: Validieren, dass der gespeicherte digitale Schlüssel ein Schlüssel für eine gültige Betriebssystemkonfiguration ist; Empfangen, von einer mit dem Datenverarbeitungssystem physisch verbundenen Benutzerschnittstelle, eines Signals, das die empfangene Anforderung bestätigt; Authentifizieren, als Reaktion auf das Empfangen des Signals, der Betriebssystemkonfiguration unter Verwendung des digitalen Schlüssels; und Booten, als Reaktion auf das Authentifizieren, der Betriebssystemkonfiguration.
Gemäß verschiedenen Ausführungsformen der vorliegenden Offenbarung enthält ein System ein Benutzerschnittstellenterminal, ein Datenverarbeitungssystem, das mit dem Benutzerschnittstellenterminal physisch verbunden ist und einen Hauptspeicher, einen Prozessor und ein durch einen Computer lesbares Speichermedium hat, das über damit realisierte Programminstruktionen verfügt. Die Programminstruktionen sind durch den Prozessor ausführbar, um das System zu veranlassen, in einem gebooteten Zustand des Datenverarbeitungssystems eine Anforderung für das Laden einer Betriebssystemkonfiguration zu empfangen. Die Programminstruktionen sind des Weiteren durch den Prozessor ausführbar, um das System zu veranlassen, automatisch als Reaktion auf das Empfangen der Anforderung einen digitalen Schlüssel zu speichern, um die Betriebssystemkonfiguration zu authentifizieren. Das Datenverarbeitungssystem wird dann neu gestartet.
Als Reaktion auf das Neustarten des Datenverarbeitungssystems und während sich das Datenverarbeitungssystem in einem Preboot-Zustand befindet, sind die Programminstruktionen des Weiteren durch den Prozessor ausführbar, um das System zu veranlassen: zu prüfen, ob der gespeicherte digitale Schlüssel ein Schlüssel für eine gültige Betriebssystemkonfiguration ist; von einer mit dem Datenverarbeitungssystem physisch verbundenen Benutzerschnittstelle ein Signal zu empfangen, das die empfangene Anforderung bestätigt; als Reaktion auf das Empfangen des Signals die Betriebssystemkonfiguration unter Verwendung des digitalen Schlüssels zu authentifizieren; und als Reaktion auf das Authentifizieren die Betriebssystemkonfiguration zu booten.
Verschiedene Ausführungsformen sind auf ein Computerprogrammprodukt zum sicheren Booten eines Datenverarbeitungssystems ausgerichtet. Das Computerprogrammprodukt enthält ein durch einen Computer lesbares Speichermedium, das über damit realisierte Programminstruktionen verfügt, wobei das durch einen Computer lesbare Speichermedium kein flüchtiges Signal ist und die Programminstruktionen durch einen Prozessor ausführbar sind, um das Datenverarbeitungssystem zum Durchführen eines Verfahrens zu veranlassen, welches das Empfangen, in einem gebooteten Zustand des Datenverarbeitungssystems, einer Anforderung zum Laden einer Betriebssystemkonfiguration beinhaltet. Das Verfahren beinhaltet des Weiteren das Speichern, automatisch als Reaktion auf das Empfangen der Anforderung, eines digitalen Schlüssels, um die Betriebssystemkonfiguration zu authentifizieren. Das Verfahren beinhaltet dann das Neustarten des Datenve ra rbe itu ngssystems.
Als Reaktion auf das Neustarten des Datenverarbeitungssystems und während sich das Datenverarbeitungssystem in einem Preboot-Zustand befindet, beinhaltet das Verfahren ferner: Validieren, dass der gespeicherte digitale Schlüssel ein Schlüssel für eine gültige Betriebssystemkonfiguration ist; Empfangen, von einer mit dem Datenverarbeitungssystem physisch verbundenen Benutzerschnittstelle, eines Signals, das die empfangene Anforderung bestätigt; Authentifizieren, als Reaktion auf das Empfangen des Signals, der Betriebssystemkonfiguration unter Verwendung des digitalen Schlüssels; und Booten, als Reaktion auf das Authentifizieren, der Betriebssystemkonfiguration.
Gemäß alternativen Ausführungsform der vorliegenden Offenbarung beinhaltet ein Verfahren das Empfangen, von einer Benutzeranwendung, die unter einer ersten Betriebssystemkonfiguration auf einer Datenverarbeitungseinheit ausgeführt wird, einer Anforderung für das Ausführen einer zweiten Betriebssystemkonfiguration eines Satzes von Betriebssystemkonfigurationen. Die zweite Betriebssystemkonfiguration wird mit einem privaten Schlüssel eines Public-Private-Key-Paares signiert und weist mindestens einen Betriebssystemkernel auf, der mit einem Satz von Parametern kompiliert wird, die zu einer Zugriffssteuerungsrichtlinie der zweiten Betriebssystemkonfiguration gehören. Das Verfahren beinhaltet ferner das Speichern, als Reaktion auf das Empfangen der Anforderung, eines öffentlichen Schlüssels, der dem privaten Schlüssel entspricht, in einem nicht flüchtigen Hauptspeicher der Datenverarbeitungseinheit. Das Verfahren beinhaltet des Weiteren das Ausführen einer vertrauenswürdigen Anwendung während eines Preboot-Zustands der Datenverarbeitungseinheit, um: zu validieren, dass der in einem nicht flüchtigen Hauptspeicher gespeicherte öffentliche Schlüssel ein Schlüssel für eine gültige Betriebssystemkonfiguration ist; von einer lokalen Schnittstelle zu der Datenverarbeitungseinheit ein Signal zu empfangen, das die empfangene Anforderung bestätigt; den öffentlichen Schlüssel in einen geschützten Hauptspeicher zu verschieben, wenn das Signal die Anforderung bestätigt; und ein Bootladeprogramm auszuführen, das Zugriff auf den geschützten Hauptspeicher hat, um das zweite Betriebssystem unter Verwendung eines in dem geschützten Hauptspeicher gespeicherten öffentlichen Schlüssels zu authentifizieren und die zweite Betriebssystemkonfiguration als Reaktion auf das Authentifizieren zu booten.
Gemäß alternativen Ausführungsformen der vorliegenden Offenbarung enthält ein System ein Benutzerschnittstellenterminal, ein Datenverarbeitungssystem, das mit dem Benutzerschnittstellenterminal physisch verbunden ist und einen Hauptspeicher, einen Prozessor und ein durch einen Computer lesbares Speichermedium hat, das über damit realisierte Programminstruktionen verfügt. Die Programminstruktionen sind durch den Prozessor ausführbar, um das System zu veranlassen, von einer Benutzeranwendung, die unter einer ersten Betriebssystemkonfiguration auf einer Datenverarbeitungseinheit ausgeführt wird, eine Anforderung für die Ausführung einer zweiten Betriebssystemkonfiguration eines Satzes von Betriebssystemkonfigurationen zu empfangen. Die zweite Betriebssystemkonfiguration wird mit einem privaten Schlüssel eines Public-Private-Key-Paares signiert und weist mindestens einen Betriebssystemkernel auf, der mit einem Satz von Parametern kompiliert wird, die zu einer Zugriffssteuerungsrichtlinie der zweiten Betriebssystemkonfiguration gehören.
Die Programminstruktionen sind des Weiteren durch den Prozessor ausführbar, um das System zu veranlassen, als Reaktion auf das Empfangen der Anforderung, einen öffentlichen Schlüssel, der dem privaten Schlüssel entspricht, in einem nicht flüchtigen Hauptspeicher der Datenverarbeitungseinheit zu speichern. Die Programminstruktionen sind ferner durch den Prozessor ausführbar, um das System zu veranlassen, eine vertrauenswürdige Anwendung während eines Preboot-Zustands der Datenverarbeitungseinheit auszuführen, um: zu validieren, dass der in einem nicht flüchtigen Hauptspeicher gespeicherte öffentliche Schlüssel ein Schlüssel für eine gültige Betriebssystemkonfiguration ist; von dem Benutzerschnittstellenterminal ein Signal zu empfangen, das die empfangene Anforderung bestätigt; den öffentlichen Schlüssel in einen geschützten Hauptspeicher zu verschieben, wenn das Signal die Anforderung bestätigt; und ein Bootladeprogramm auszuführen, das Zugriff auf den geschützten Hauptspeicher hat, um das zweite Betriebssystem unter Verwendung eines in dem geschützten Hauptspeicher gespeicherten öffentlichen Schlüssels zu authentifizieren und die zweite Betriebssystemkonfiguration als Reaktion auf das Authentifizieren zu booten.
Die vorstehende Kurzdarstellung zielt nicht darauf ab, jede veranschaulichte Ausführungsform oder jede Ausführung der vorliegenden Offenbarung zu beschreiben.
Figurenliste
Die zu der vorliegenden Anmeldung gehörenden Zeichnungen sind in die Spezifikation aufgenommen und bilden Teil der Spezifikation. Sie veranschaulichen Ausführungsform der vorliegenden Offenbarung und dienen zusammen mit der Beschreibung dazu, die Grundgedanken der Offenbarung zu erklären. Die Zeichnungen veranschaulichen lediglich bestimmte Ausführungsformen und stellen keine Beschränkung der Offenbarung dar.

1 stellt einen Ablaufplan eines Satzes von durch einen Computer ausgeführten Operationen dar, um gemäß verschiedenen Ausführungsformen unter Verwendung von Hardware und Software eine aus einem Satz von Betriebssystemkonfigurationen ausgewählte Betriebssystemkonfiguration sicher zu booten.
2 stellt einen Ablaufplan eines beispielhaften Satzes von durch einen Computer ausgeführten Operationen dar, um gemäß verschiedenen Ausführungsformen unter Verwendung von Hardware und Software eine aus einem Satz von Betriebssystemkonfigurationen ausgewählte Betriebssystemkonfiguration sicher zu booten.
3 stellt ein Blockschaubild eines beispielhaften Systems dar, um gemäß verschiedenen Ausführungsformen unter Verwendung von Hardware und Software eine aus einem Satz von Betriebssystemkonfigurationen ausgewählte Betriebssystemkonfiguration sicher zu booten.
4 stellt einen Ablaufplan eines Satzes von durch einen Computer ausgeführten Operationen dar, um gemäß verschiedenen Ausführungsformen unter Verwendung von Hardware und Software eine Auswahl eines Benutzers einer Betriebssystemkonfiguration aus einem Satz von Betriebssystemkonfigurationen sicher zu booten.
5 stellt ein Interaktionsdiagramm von Interaktionen zwischen einem Benutzer und einem Datenverarbeitungssystem dar, das einen Satz von durch einen Computer ausgeführten Operationen ausführt, um gemäß verschiedenen Ausführungsformen unter Verwendung von Hardware und Software eine aus einem Satz von Betriebssystemkonfigurationen ausgewählte Betriebssystemkonfiguration sicher zu booten.
6 stellt ein Blockschaubild eines Computersystems dar, das über Hardware- und Softwarekomponenten verfügt, um gemäß verschiedenen Ausführungsformen unter Verwendung von Hardware und Software eine aus einem Satz von Betriebssystemkonfigurationen ausgewählte Betriebssystemkonfiguration sicher zu booten.

Während die Erfindung offen für verschiedene Modifikationen und alternative Formen ist, wurden Einzelheiten der Erfindung beispielhalber in den Zeichnungen gezeigt und werden ausführlich beschrieben. Es sollte jedoch klar sein, dass nicht beabsichtigt ist, die Erfindung auf die jeweiligen beschriebenen Ausführungsformen zu beschränken. Im Gegenteil ist beabsichtigt, alle Modifikationen, Äquivalente und Alternativen, die unter die Wesensart und den Umfang der Erfindung fallen, abzudecken.
AUSFÜHRLICHE BESCHREIBUNG
Aspekte der vorliegenden Offenbarung betreffen Datenverarbeitungssysteme, bei denen ein sicheres Booten von Betriebssystemen zur Anwendung kommt, spezifischere Aspekte betreffen das Sichern einer Betriebssystemkonfiguration von Datenverarbeitungssystemen unter Verwendung von Hardware vor dem Booten. Während die vorliegende Offenbarung nicht unbedingt auf solche Anwendungen beschränkt ist, lassen sich verschiedene Aspekte der Offenbarung durch eine Erörterung von verschiedenen Beispielen unter Verwendung dieses Kontexts als vorteilhaft erkennen.
Zu Ausführungsformen der vorliegenden Offenbarung gehören Verfahren, Systeme und Computerprogrammprodukte, die es einem Benutzer eines Datenverarbeitungssystems ermöglichen können, unter einem Satz von verschiedenen Betriebssystemkonfigurationen zu wählen und die Gewissheit zu haben, dass die gewählte Konfiguration nicht modifiziert, verändert oder in anderer Weise manipuliert wurde, bevor sie auf dem Datenverarbeitungssystem gebootet wird. Die hierin offenbarten Ausführungsformen bieten Vorteile bei der Sicherheit, Zugriffsflexibilität und Verwaltung von Datenverarbeitungssystemen.
Ausführungsformen der vorliegenden Offenbarung beruhen auf der Erkenntnis, dass sichere Boottechniken unter Verwendung der hierin beschriebenen Techniken erweitert oder in anderer Weise verbessert werden können, um unter anderem die Authentizität einer Betriebssystemkonfiguration, die aus einem Satz von auf einem Datenverarbeitungssystem gespeicherten Betriebssystemkonfigurationen ausgewählt wird, in einer Preboot-Umgebung sicherzustellen. Sichere Boottechniken wie beispielsweise Unified Extensible Firmware Interface Secure Boot (nachstehend „UEFI Secure Boot“) erhöhen die Sicherheit von Datenverarbeitungssystemen in der Preboot-Umgebung, indem sie die Ausführung von ungeschütztem, durch einen Computer ausführbaren Code (nachstehend „Code“) vor dem Booten eines Betriebssystems verhindern. In einem Beispiel speichert eine sichere Boottechnik einen Satz (z.B. einen oder mehrere) von öffentlichen Schlüsseln eines Satzes von asymmetrischen Schlüsselpaaren (z.B. eines Public-Private-Key-Paares) in einem Satz von Variablen in einem geschützten, nicht flüchtigen Hauptspeicher eines Datenverarbeitungssystems während der Herstellung des Datenverarbeitungssystems. Jede Anwendung (z.B. Computerprogramm), deren Ausführung auf dem Datenverarbeitungssystem genehmigt (bzw. autorisiert) ist, wird unter Verwendung eines privaten Schlüssels signiert, der einen entsprechenden öffentlichen Schlüssel in dem gespeicherten Satz von öffentlichen Schlüsseln hat. Bevor eine Anwendung ausgeführt wird, während sich ein Datenverarbeitungssystem in einem Preboot-Zustand befindet, überprüft eine vertrauenswürdige Anwendung die Integrität des ausführbaren Codes der auszuführenden Anwendung, indem sie überprüft, ob die Anwendung mit einem privaten Schlüssel digital signiert ist, der einem der öffentlichen Schlüssel in dem gespeicherten Satz von öffentlichen Schlüsseln entspricht. Ein Problem bei dieser sicheren Boottechnik besteht darin, dass der Satz der autorisierten Unterzeichner (oder der Satz der privaten Schlüssel) vor oder gleichzeitig mit der Herstellung des Datenverarbeitungssystems festgelegt wird. Einem neuen Betriebssystem zum Beispiel zu ermöglichen, das Datenverarbeitungssystem sicher zu booten, kann voraussetzen, dass ein Unterzeichner eines Satzes von vorher festgelegten autorisierten Unterzeichnern veranlasst wird, das Betriebssystem digital zu signieren, bevor es in dem Datenverarbeitungssystem eingesetzt wird.
Die sicheren Boottechniken können einen Satz von vertrauenswürdigen Anwendungen bereitstellen, um es Endbenutzern zu ermöglichen, zusätzliche öffentliche Schlüssel hinzuzufügen, um Anwendungen zu authentifizieren, die auf einem Datenverarbeitungssystem gebootet werden können. UEFI Secure Boot zum Beispiel stellt die „mokutil“-, „shim“- und „grub“-Anwendungen bereit, um es Benutzern zu ermöglichen, öffentliche Schlüssel zu dem während der Herstellung bereitgestellten Satz von öffentlichen Schlüsseln hinzuzufügen. Ein Benutzer, der in einem Betriebssystem angemeldet ist, das auf einem Datenverarbeitungssystem gebootet wurde, zu dem ein neuer öffentlicher Schlüssel (der z.B. einem neuen Betriebssystemkernel-Abbild entspricht, das zu dem Datenverarbeitungssystem hinzugefügt werden soll) hinzugefügt wird, führt mokutil aus, um den neuen öffentlichen Schlüssel bereitzustellen. Die mokutil-Anwendung schreibt den neuen öffentlichen Schlüssel in einen nicht flüchtigen Hauptspeicher, auf den beim nächstmaligen Booten des Datenverarbeitungssystems nur die shim-Anwendung zugreifen kann. Die shim-Anwendung kann eine vertrauenswürdige Anwendung sein, die zum Beispiel in einem geschützten Hauptspeicher des Datenverarbeitungssystems eingebettet ist. Ferner kann das Datenverarbeitungssystem so konfiguriert werden, dass es sicherstellt, dass shim die erste Anwendung ist, die nach dem Neustart des Datenverarbeitungssystems ausgeführt wird. Beim nächstmaligen Neustart des Datenverarbeitungssystems im Anschluss an eine Aktualisierung durch mokutil überprüft das UEFI Secure Boot-System die shim-Anwendung und führt sie aus. Die shim-Anwendung liest dann einen durch mokutil beschriebenen Bereich des nicht flüchtigen Hauptspeichers, um festzustellen, ob ein neuer öffentlicher Schlüssel gespeichert wurde. Shim, als Reaktion auf das Erkennen des neuen öffentlichen Schlüssels, kann den Benutzer an einer lokalen Konsole auffordern, zu bestätigen, ob der neue Schlüssel in einem Satz oder einer Datenbank von gespeicherten öffentlichen Schlüsseln festgeschrieben werden soll. Shim entfernt (oder löscht) den neuen öffentlichen Schlüssel, falls der Benutzer keine positive Bestätigung bereitstellt. Alternativ verschiebt shim über Aufrufe der shim-Anwendung den neuen öffentlichen Schlüssel in einen anderen Bereich des nicht flüchtigen Hauptspeichers (z.B. eine Datenbank, die alle akzeptierten öffentlichen Schlüssel speichert), der ausschließlich von grub verwendet wird, wenn der Benutzer eine positive Bestätigung bereitstellt. Der neue öffentliche Schlüssel steht danach für die Authentifizierung des neuen Kernelabbilds zur Verfügung.
Um einen Betriebssystemkernel sicher zu booten, authentifiziert shim die grub-Anwendung und führt sie aus, nachdem sie beliebige neue Schlüssel in einem Datenverarbeitungssystem festgeschrieben hat. Grub verwendet ihre Konfigurationsdateien, um festzustellen, welches Kernelabbild gebootet werden soll. Nachdem sie einen zu bootenden Betriebssystemkernel ermittelt hat, authentifiziert grub das Kernelabbild und bootet es, indem sie die shim-Anwendung aufruft, um zu überprüfen, ob das Kernelabbild mit einem privaten Schlüssel signiert ist, der einem der öffentlichen Schlüssel entspricht, die in einer Datenbank mit öffentlichen Schlüsseln (Public-Key-Datenbank) des Datenverarbeitungssystems gespeichert sind. Nachdem er gebootet wurde, kann der Betriebssystemkernel ebenfalls Kernelmodule authentifizieren, wenn sie durch Anforderung in das Datenverarbeitungssystem geladen werden sollen.
Diese sicheren Boottechniken können es einem Benutzer ermöglichen, ein neues Betriebssystem in ein Datenverarbeitungssystem zu laden, vorausgesetzt, der Benutzer hat Zugriff auf eine ordnungsgemäß signierte Version des Betriebssystems und verwaltet einen öffentlichen Schlüssel, der einem privaten Schlüssel entspricht, welcher zur Signierung des Betriebssystems verwendet wird. Bekannte sichere Boottechniken ermöglichen es Benutzern jedoch nicht, aus einem Satz von in dem Datenverarbeitungssystem gespeicherten Betriebssystemkonfigurationen eine Betriebssystemkonfiguration zum Booten auf einem Datenverarbeitungssystem auszuwählen. Darüber hinaus ermöglichen es bekannte sichere Boottechniken dem Datenverarbeitungssystem nicht, sicherzustellen, dass die ausgewählte Betriebssystemkonfiguration gebootet wird, ohne dass diese modifiziert oder in anderer Weise manipuliert ist.
Ausführungsform der vorliegenden Offenbarung stellen Verfahren, Systeme und Computerprogrammprodukte bereit, die bekannte sichere Boottechniken verbessern, indem sie eine Anforderung für das Booten einer Betriebssystemkonfiguration aus einem Satz von Betriebssystemkonfigurationen, die mit einem privaten Schlüssel eines asymmetrischen Schlüsselpaares digital signiert und auf einem System gespeichert werden, empfangen, einer vertrauenswürdigen Anwendung, die so konfiguriert ist, dass sie eine geschützte, öffentliche Schlüssel enthaltende Datenbank aktualisiert, automatisch einen öffentlichen Schlüssel des asymmetrischen Schlüsselpaares bereitstellen, die Anforderung für das Laden der Betriebssystemkonfiguration unter Nutzung der physischen Präsenz des Benutzers an dem Datenverarbeitungssystem überprüfen und die Betriebssystemkonfiguration authentifizieren und booten.
In der Verwendung hierin ist eine vertrauenswürdige Anwendung eine Anwendung, deren ausführbarer Code authentifiziert oder bei dem in anderer Weise gewährleistet ist, dass er nicht von einer Partei geändert wurde, die keine Befugnis zum Ändern des Codes hat. Ausführbarer Code kann unter Verwendung von bekannten digitalen Signier-und Überprüfungstechniken authentifiziert werden. Ausführbarer Code kann zum Beispiel signiert werden, indem der Code unter Verwendung eines privaten Schlüssels eines asymmetrischen Schlüsselpaares verschlüsselt wird. Die Integrität des Codes kann dann authentifiziert werden, indem ein öffentlicher Schlüssel eines asymmetrischen Schlüsselpaares verwendet wird, um eine Signatur des signierten Codes zu überprüfen. Die Authentifizierung schlägt fehl, wenn die Signatur des signierten Codes zum Beispiel aufgrund einer Änderung des signierten Codes nach der Signierung nicht überprüft werden kann.
In der Verwendung hierin kann eine Schlüsseldatenbank ein Bereich des geschützten Hauptspeichers sein, der so konfiguriert ist, dass er einen Satz von digitalen Schlüsseln (z.B. öffentliche Schlüssel eines asymmetrischen Schlüsselpaares) speichert. Bei dem geschützten Hauptspeicher kann es sich um einen Hauptspeicher handeln, der nur für vertrauenswürdige Anwendungen oder eine ausgewählte Gruppe von Anwendungen zugänglich (z.B. lesbar oder beschreibbar) ist.
In der Verwendung hierin kann ein Preboot-Zustand eines Datenverarbeitungssystems ein Zustand des Datenverarbeitungssystems sein, nachdem das Datenverarbeitungssystem neu startet und bevor das Datenverarbeitungssystem ein Betriebssystem bootet. Ein gebooteter Zustand eines Betriebssystems ist ein Zustand eines Datenverarbeitungssystems, nachdem ein Betriebssystem auf dem Datenverarbeitungssystem gebootet wurde.
In der Verwendung hierin kann eine Betriebssystemkonfiguration ein Datenobjekt sein, das über ein bootfähiges Betriebssystemkernel-Abbild (nachstehend „Betriebssystemkernel“ oder „Kernel“) und einen zugehörigen Satz von einem oder mehreren Kernel-Parameterwerten (z.B. Parameterwerten) verfügt. In einigen Ausführungsformen können die Kernel-Parameterwerte fest codierte (z.B. in den ausführbaren Code des Betriebssystemkernels kompilierte), feste Befehlszeilen-Parameterwerte sein. Die feste Codierung der Kernel-Parameterwerte kann das Bereitstellen der Parameterwerte für einen Compiler beinhalten, wobei eine oder mehrere Compiler-Optionen verwendet werden, wenn der Betriebssystemkernel kompiliert wird. Die feste Codierung der Kernel-Parameterwerte kann ferner das Kompilieren des Betriebssystemkernels beinhalten, wobei Kompilieroptionen verwendet werden, um zu verhindern, dass ein Bootladeprogramm oder eine andere Anwendung die fest codierten Kernel-Parameterwerte überschreibt. In bestimmten Ausführungsformen können die Kernel-Parameterwerte in einem von dem Betriebssystemkernel getrennten Datenobjekt bereitgestellt werden.
Ein Datenobjekt kann, in der Verwendung hierin, ein einzelnes Kernelabbild sein. Ein Datenobjekt kann auch eine Datenstruktur sein, die über einen Betriebssystemkernel und einen Satz von zusätzlichen Datenobjekten verfügt. Das Signieren des Betriebssystems kann das Signieren des Datenobjekts und/oder einer jeden Komponente des Datenobjekts beinhalten.
Das Booten einer Betriebssystemkonfiguration auf einem Datenverarbeitungssystem, bei dem Kernel-Parameter fest codiert sind, kann das Übergeben des Betriebssystemkernels an ein Bootladeprogramm und das Veranlassen des Bootladeprogramms, den Betriebssystemkernel zu laden und auf dem Datenverarbeitungssystem auszuführen, beinhalten. Ebenso kann das Booten einer Betriebssystemkonfiguration, bei der ein oder mehrere Kernel-Parameterwerte in einem von dem Betriebssystemkernel getrennten Datenobjekt gespeichert werden, das Übergeben sowohl des Betriebssystemkernels als auch des einen oder der mehreren Kernel-Parameterwerte an ein Bootladeprogramm und das Veranlassen des Bootladeprogramms, den Betriebssystemkernel mit dem einen oder den mehreren Kernel-Parameterwerten zu laden und auszuführen, beinhalten.
Bei einem bestimmten Betriebssystemkernel kann eine Betriebssystemkonfiguration durch ihre Durchsetzung der Zugriffssteuerungsrichtlinien gekennzeichnet sein. Dies kann als die Sicherheitsstufe einer Konfiguration bezeichnet werden. Ein Datenverarbeitungssystem zum Beispiel kann eine Verteilung eines Linux^®-Kernels haben, der unter anderem zusammen mit einem Security Enhanced Linux (SELinux-)-Modul zur Durchsetzung von Zugriffssteuerungsrichtlinien installiert ist. Mit dem Beispiel fortfahrend, kann das Datenverarbeitungssystem auch so konfiguriert sein, dass es drei Arten von Betriebssystemkonfigurationen (z.B. Sicherheitsstufen) unterstützt: niedrig, mittel und hoch. Ein Linux-Kernel, der unter Verwendung der Konfiguration ‚niedrig‘ gebootet wird, kann SELinux deaktivieren und eine Durchsetzung einer Zugriffssteuerungsrichtlinie verhindern, während ein Linux-Kernel, der unter Verwendung der Konfiguration ‚mittel‘ gebootet wird, SELinux in einem toleranten oder Debugmodus aktivieren kann, um eine Zugriffssteuerungsrichtlinie zu überwachen, aber nicht durchzusetzen. Ferner kann ein Linux-Kernel, der unter Verwendung der Konfiguration ‚hoch‘ gebootet wird, SELinux in einem Durchsetzungsmodus aktivieren, um während des Bootens des Datenverarbeitungssystems eine verbindliche Zugriffssteuerungsrichtlinie durchzusetzen. Dieses beispielhafte Datenverarbeitungssystem kann somit drei verschiedene Betriebssystemkonfigurationen unterstützen, wobei jede Konfiguration über einen Linux-Kernel und ein zugehöriges SELinux-Modul verfügt, das zum Beispiel mit Kernel-Parameterwerten kompiliert wird, die so gesetzt sind, dass sie eine bestimmte Zugriffsrichtliniendurchsetzungs- oder Sicherheits-Stufe ermöglichen.
Unter Bezugnahme auf die Figuren, stellt 1 einen Ablaufplan 100 eines Satzes von durch einen Computer ausgeführten Operationen dar, um gemäß verschiedenen Ausführungsformen unter Verwendung von Hardware und Software eine aus einem Satz von Betriebssystemkonfigurationen ausgewählte Betriebssystemkonfiguration sicher zu booten. Die Operationen des Ablaufplans 100 können durch ein Datenverarbeitungssystem ausgeführt werden, das so konfiguriert ist, dass es Anwendungen sicher bootet, wie hierin beschrieben ist. In einigen Ausführungsformen kann es sich bei dem Datenverarbeitungssystem um den Computer 305 (3) oder die Datenverarbeitungseinheit 600 (6) handeln. In bestimmten Ausführungsformen kann das Datenverarbeitungssystem einen oder mehrere Datenverarbeitungsknoten oder Datenverarbeitungseinheiten enthalten. Verschiedene in dem Ablaufplan 100 dargestellte Operationen können unter Verwendung von Software-, Firmware- und Hardwarekomponenten des Datenverarbeitungssystems ausgeführt werden. Diese Komponenten, darunter das Datenverarbeitungssystem als Ganzes, werden hierin gemeinsam als das Datenverarbeitungssystem bezeichnet. Jede in dem Ablaufplan 100 gezeigte Operation kann durch das Datenverarbeitungssystem automatisch oder als Reaktion auf ein oder mehrere Ereignisse (z.B. eine Benutzeraktion oder -anforderung) ausgeführt werden.
Das Datenverarbeitungssystem kann die Operation 105 ausführen, um eine Anforderung für das Booten einer Betriebssystemkonfiguration zu empfangen. Die Anforderung kann von einem fernen Benutzerschnittstellenterminal (z.B. einem Benutzerschnittstellenterminal, das mit dem Datenverarbeitungssystem zum Beispiel über ein Datenübertragungsnetzwerk verbunden ist) empfangen werden. Die Anforderung kann auch von einem lokalen Benutzerschnittstellenterminal (z.B. einem Benutzerschnittstellenterminal, das mit dem Datenverarbeitungssystem physisch verbunden ist) empfangen werden. Ein Benutzer, der eine Anforderung übergibt oder in anderer Weise unter Verwendung eines lokalen Benutzerschnittstellenterminals mit dem Datenverarbeitungssystem interagiert, muss entweder physisch präsent an dem Datenverarbeitungssystem sein oder sich in solch unmittelbarer Nähe zu dem Datenverarbeitungssystem befinden, dass davon ausgegangen werden kann, dass er das Datenverarbeitungssystem physisch besitzt.
Das Datenverarbeitungssystem kann die Operation 110 ausführen, um einen digitalen Schlüssel zur Authentifizierung der angeforderten Betriebssystemkonfiguration zu speichern, wie hierin beschrieben ist. Der digitale Schlüssel kann ein öffentlicher Schlüssel eines asymmetrischen Schlüsselpaares sein, bei dem der jeweilige private Schlüssel verwendet wurde, um die angeforderte Betriebssystemkonfiguration zu signieren. In Ausführungsformen kann der digitale Schlüssel in einem nicht flüchtigen Hauptspeicher gespeichert werden. Zu dem nicht flüchtigen Hauptspeicher kann, ohne darauf beschränkt zu sein, ein persistenter Direktzugriffsspeicher (RAM, Random Access Memory), ein FLASH-Speicher, Systemspeicher gehören. In einigen Ausführungsformen kann das Datenverarbeitungssystem so konfiguriert sein, dass es den nicht flüchtigen Hauptspeicher nach dem Neustart automatisch auf digitale Schlüssel prüft.
Das Datenverarbeitungssystem kann die Operation 115 ausführen, um das Datenverarbeitungssystem neu zu starten. In einigen Ausführungsformen kann das Datenverarbeitungssystem als Reaktion auf das Ausführen der Operation 110 automatisch neu starten. In verschiedenen Ausführungsformen kann das Datenverarbeitungssystem als Reaktion auf das Empfangen einer Anforderung von einem Benutzerschnittstellenterminal für einen Neustart neu starten.
Während sich das Datenverarbeitungssystem in einem Preboot-Zustand befindet, kann das Datenverarbeitungssystem eine Anforderung an einen Benutzer an einem lokalen Benutzerschnittstellenterminal senden, um die Anforderung für das Booten der angeforderten Betriebssystemkonfiguration zu bestätigen. Das Datenverarbeitungssystem kann dann die Operation 120 ausführen, um von dem lokalen Benutzerschnittstellenterminal ein Signal zu empfangen, das die Anforderung für das Booten der angeforderten Betriebssystemkonfiguration bestätigt. Das Ausführen der Operation 120 kann sicherstellen, dass ein Benutzer, der eine Änderung der auf dem Datenverarbeitungssystem gebooteten Betriebssystemkonfiguration anfordert (z.B. eine mögliche Änderung der Zugriffssteuerungsrichtlinien-Durchsetzungs- oder Sicherheitsstufe), physischen Zugriff auf das Datenverarbeitungssystem hat. Diese Operation kann die Wahrscheinlichkeit einschränken, dass ein nicht berechtigter Benutzer die Zugriffssteuerungsrichtlinien-Durchsetzungs- oder Sicherheitsstufe des Datenverarbeitungssystems über einen Fernzugriff ändert.
Während sich das Datenverarbeitungssystem immer noch in dem Preboot-Zustand befindet, kann es die Operation 125 ausführen, um die angeforderte Betriebssystemkonfiguration unter Verwendung des digitalen Schlüssels zu authentifizieren. Das Datenverarbeitungssystem kann dann die Operation 130 ausführen, um die angeforderte Betriebssystemkonfiguration zu booten.
In einigen Ausführungsformen kann das Datenverarbeitungssystem als Reaktion auf das Neustarten überprüfen (z.B. validieren) oder feststellen, ob der in der Operation 115 gespeicherte digitale Schlüssel einer Betriebssystemkonfiguration entspricht, die zum Booten auf dem Datenverarbeitungssystem berechtigt ist. Die Überprüfung kann die Feststellung beinhalten, ob eine Betriebssystemkonfiguration, die auf dem Datenverarbeitungssystem gespeichert und zur Ausführung berechtigt ist, mit einem privaten Schlüssel signiert wurde, der dem digitalen Schlüssel entspricht. Die Überprüfungsoperation trägt dazu bei, die Integrität der Preboot-Umgebung und des gebooteten Systems sicherzustellen, indem sie sicherstellt, dass nur bekannte oder genehmigte Konfigurationen für ein Booten in Frage kommen.
In einigen Ausführungsformen kann das Datenverarbeitungssystem als Reaktion auf das Empfangen der Bestätigung in der Operation 120 den digitalen Schlüssel in einen geschützten Hauptspeicher verschieben. Das Speichersystem kann den digitalen Schlüssel zum Beispiel in eine Schlüsseldatenbank oder Schlüsselrepository verschieben, die nur durch bestimmte vertrauenswürdige (z.B. sichere oder authentifizierte) Anwendungen beschreibbar ist. Diese Ausführungsformen können den Vorteil bieten, die vorhandene Architektur von sicheren Boottechniken zu nutzen, um es vertrauenswürdigen Anwendungen zu ermöglichen, die Gültigkeit und Authentizität der angeforderten Betriebssystemkonfiguration zu überprüfen. Dies ermöglicht dem Datenverarbeitungssystem auch, die angeforderte Betriebssystemkonfiguration nach einem Neustart zu booten, ohne dass ein Benutzer Zugriff auf ein lokales Benutzerschnittstellenterminal haben muss.
In einigen Ausführungsformen ist der geschützte Hauptspeicher (z.B. die Schlüsseldatenbank) nur durch eine Software-Anwendung beschreibbar, bei der die Integrität ihres ausführbaren Codes durch eine Hardwarekomponente des Datenverarbeitungssystems authentifiziert wird (z.B. unter Verwendung von digitalen Schlüsseln, die in dem geschützten Hauptspeicher gespeichert sind). Diese Ausführungsformen können den Vorteil bieten, die Authentizität der angeforderten Betriebssystemkonfiguration durchzusetzen, indem sie die Anzahl der Parteien beschränken, die neue, und möglicherweise nicht autorisierte, Schlüssel zu dem Datenverarbeitungssystem hinzufügen können.
In einigen Ausführungsformen beinhaltet die Authentifizierung der angeforderten Betriebssystemkonfiguration das Abrufen des digitalen Schlüssels aus dem geschützten Hauptspeicher und das Verwenden des abgerufenen Schlüssels, um eine Signatur der angeforderten Betriebssystemkonfiguration zu überprüfen. Diese Ausführungsformen können den Vorteil bieten, die vorhandene Architektur von sicheren Boottechniken zu nutzen, um sicherzustellen, dass eine Betriebssystemkonfiguration nicht modifiziert ist, bevor die Konfiguration gebootet wird.
Gemäß verschiedenen Ausführungsformen kann die in der Operation 105 angeforderte Betriebssystemkonfiguration einen Betriebssystemkernel und einen Satz von Kernel-Parameterwerten beinhalten, um eine Zugriffssteuerungsrichtlinien-Durchsetzungs- oder Sicherheitsstufe des Betriebssystemkernels (z.B. eine Zugriffssteuerungsrichtlinie) durchzusetzen. In bestimmten Ausführungsformen wird der Satz von Kernel-Parameterwerten in den ausführbaren Code des Betriebssystemkernels kompiliert, wie hierin beschrieben ist.
2 stellt einen Ablaufplan 200 eines beispielhaften Satzes von durch einen Computer ausgeführten Operationen dar, um gemäß verschiedenen Ausführungsformen unter Verwendung von Hardware und Software eine aus einem Satz von Betriebssystemkonfigurationen ausgewählte Betriebssystemkonfiguration sicher zu booten. Die Operationen des Ablaufplans 200 können durch ein Datenverarbeitungssystem ausgeführt werden, das so konfiguriert ist, dass es Anwendungen sicher bootet, wie hierin beschrieben ist. Jede in dem Ablaufplan 200 gezeigte Operation kann durch das Datenverarbeitungssystem automatisch oder als Reaktion auf ein oder mehrere Ereignisse (z.B. eine Benutzeraktion oder -anforderung) ausgeführt werden.
Das Datenverarbeitungssystem kann die Operation 205 ausführen, indem es zum Beispiel einen Satz von Betriebssystemkonfigurationen erzeugt, die in der Lage sind, auf dem Datenverarbeitungssystem zu booten. Die Betriebssystemkonfigurationen können Betriebssystemkernels zusammen mit einem Satz von Kernel-Parameterwerten enthalten. Die Kernel-Parameterwerte können die Zugriffssteuerungsrichtlinien-Durchsetzungsstufe (oder die Sicherheitsstufe) eines zugehörigen Betriebssystemkernels konfigurieren. Jede Konfiguration kann ferner zum Beispiel mit einem anderen privaten Schlüssel eines asymmetrischen Public-Private-Key-Paares digital signiert werden, um die Integrität des ausführbaren Codes der Betriebssystemkonfiguration sicherzustellen. Einem jeden privaten Schlüssel entsprechende öffentliche Schlüssel können ebenfalls in dem Datenverarbeitungssystem gespeichert werden.
Das Datenverarbeitungssystem kann die Operation 210 ausführen, um eine Anforderung für das Booten einer ausgewählten Betriebssystemkonfiguration (z.B. eine Boot-Anforderung) zu empfangen. Die Anforderung kann von einem fernen Benutzerschnittstellenterminal oder einem lokalen Benutzerschnittstellenterminal empfangen werden, wie hierin beschrieben ist.
Bei der Operation 215 kann das Datenverarbeitungssystem einen digitalen Schlüssel (z.B. einen öffentlichen Schlüssel) speichern, der zu einem privaten Schlüssel gehört, welcher verwendet wurde, um die angeforderte Betriebssystemkonfiguration zu signieren. Der digitale Schlüssel kann in einem nicht flüchtigen Hauptspeicher des Datenverarbeitungssystems gespeichert werden, wie hierin beschrieben ist. In einigen Ausführungsformen kann das Datenverarbeitungssystem ferner eine Konfiguration (z.B. eine Konfigurationsdatei) eines Bootladeprogramms aktualisieren, um das Bootladeprogramm zu veranlassen, die angeforderte Betriebssystemkonfiguration beim nächsten Neustart des Datenverarbeitungssystems zu booten.
Bei der Operation 220 kann das Datenverarbeitungssystem neu starten (z.B. neu booten). Das Datenverarbeitungssystem kann dann die folgenden Operationen ausführen, während sich das Datenverarbeitungssystem in einem Preboot-Zustand befindet, wie hierin beschrieben ist.
Bei der Operation 225 kann das Datenverarbeitungssystem den digitalen Schlüssel überprüfen, um festzustellen, ob der digitale Schlüssel einer bekannten (z.B. gespeicherten) Betriebssystemkonfiguration entspricht, die zum Booten auf dem Datenverarbeitungssystem berechtigt ist, wie hierin beschrieben ist. Das Datenverarbeitungssystem kann zur Operation 230 schalten, wenn der öffentliche Schlüssel überprüft ist, oder alternativ kann das Datenverarbeitungssystem als Reaktion auf die Feststellung, dass die angeforderte Betriebssystemkonfiguration nicht überprüft werden kann, zur Operation 250 schalten.
Bei der Operation 230 kann das Datenverarbeitungssystem die Anforderung für das Booten der angeforderten Betriebssystemkonfiguration bestätigen. Das Ausführen der Operation 230 kann das Auffordern des anfordernden Benutzers an einem lokalen Benutzerschnittstellenterminal, die Anforderung für das Booten der angeforderten Betriebssystemkonfiguration zu bestätigen, beinhalten. Das Datenverarbeitungssystem kann dann ein Bestätigungssignal oder eine Bestätigungsnachricht von dem lokalen Benutzerschnittstellenterminal empfangen. Das empfangene Bestätigungssignal kann ein beliebiges elektronisches Signal, darunter eine elektrische Spannung oder einen Satz digitaler Zeichen, beinhalten. Das empfangene Bestätigungssignal kann eine positive Bestätigung oder eine negative Bestätigung sein. Das Datenverarbeitungssystem kann zur Operation 235 schalten, wenn das empfangene Bestätigungssignal eine positive Bestätigung ist, während das Datenverarbeitungssystem zur Operation 250 schalten kann, wenn das empfangene Bestätigungssignal eine negative Bestätigung ist. Ferner kann das Datenverarbeitungssystem als Reaktion auf das Empfangen einer positiven Bestätigung den digitalen Schlüssel in einen geschützten Hauptspeicher verschieben (z.B. als eine Alternative zum Ausführen der Operation 235), wie hierin beschrieben ist.
Bei der Operation 235 kann das Datenverarbeitungssystem den digitalen Schlüssel in einen geschützten Hauptspeicher des Datenverarbeitungssystems verschieben, wie hierin beschrieben ist. In einigen Ausführungsformen kann das Datenverarbeitungssystem die Operation 235 ausführen, bevor es die Operation 230 ausführt.
Bei der Operation 240 kann das Datenverarbeitungssystem den digitalen Schlüssel aus dem geschützten Hauptspeicher abrufen oder lesen und ihn verwenden, um die angeforderte Betriebssystemkonfiguration zu authentifizieren, wie hierin beschrieben ist. Das Authentifizieren der angeforderten Betriebssystemkonfiguration kann die Feststellung beinhalten, dass die angeforderte Betriebssystemkonfiguration nicht modifiziert wurde, nachdem sie unter Verwendung eines privaten Schlüssels signiert worden ist. Das Datenverarbeitungssystem kann mit der Operation 245 fortfahren, wenn die angeforderte Betriebssystemkonfiguration authentisch ist, während das Datenverarbeitungssystem mit der Operation 250 fortfahren kann, wenn die angeforderte Betriebssystemkonfiguration nicht authentisch ist.
Bei der Operation 245 kann das Datenverarbeitungssystem die angeforderte Betriebssystemkonfiguration booten, wie hierin beschrieben ist. Das Datenverarbeitungssystem kann die Operationen des Ablaufplans 200 bei der Operation 255 beenden.
Bei der Operation 250 kann das Datenverarbeitungssystem den digitalen Schlüssel aus dem nicht flüchtigen Hauptspeicher und/oder dem geschützten Hauptspeicher löschen oder entfernen. Das Datenverarbeitungssystem kann dann einen Hinweis bereitstellen, dass die angeforderte Betriebssystemkonfiguration nicht gebootet werden kann. In einigen Ausführungsformen und als Reaktion auf das Ankommen an der Operation 250 von anderen Operationen (z.B. der Operation 225, 235 und 240) darf das Datenverarbeitungssystem den privaten Schlüssel nicht löschen. In diesen Ausführungsformen kann das Datenverarbeitungssystem denn Bootvorgang abbrechen, indem es einen Hinweis bereitstellt, dass die angeforderte Betriebssystemkonfiguration nicht gebootet werden kann.
3 stellt ein Blockschaubild eines beispielhaften Systems 300 zum sicheren Booten einer Betriebssystemkonfiguration dar, die gemäß verschiedenen Ausführungsformen unter Verwendung von Hardware und Software aus einem Satz von Betriebssystemkonfigurationen ausgewählt wurde. Bei dem System 300 kann es sich um ein Datenverarbeitungssystem handeln, das so konfiguriert ist, dass es die Operationen der vorliegenden Offenbarung ausführt, wie hierin beschrieben ist. Das System 300 enthält die Datenverarbeitungseinheit 305 und die lokale Benutzerschnittstelle 380 (z.B. ein lokales Benutzerschnittstellenterminal). In einigen Ausführungsformen kann das System 300 eine ferne Benutzerschnittstelle 370 (z.B. ein fernes Benutzerschnittstellenterminal) und ein Datenübertragungsnetzwerk 375 enthalten.
Die Datenverarbeitungseinheit 305 kann einen Prozessor 310, einen Hauptspeicher 315, einen Massenspeicher 320 und eine Sicherheitskomponente 325 enthalten. Bei der Datenverarbeitungseinheit 305 kann es sich um eine Datenverarbeitungseinheit handeln, die so konfiguriert ist, dass sie eine ausgewählte Betriebssystemkonfiguration sicher lädt, wie hierin beschrieben ist. Der Prozessor 310 kann in den Hauptspeicher 315 geladene Anwendungen ausführen, darunter eine Benutzeranwendung 330 und eine vertrauenswürdige Anwendung 360.
Der Massenspeicher 320 kann eine Speichereinheit wie beispielsweise die Speichereinheit 628 (6) sein. Der Massenspeicher 320 kann Anwendungen, darunter Betriebssystemkonfigurationen, zur Ausführung auf der Datenverarbeitungseinheit 305 speichern. Die Speichereinheit kann zum Beispiel die Benutzeranwendung 330, das Bootladeprogramm 335, die Betriebssystemkonfiguration A 340 und die Betriebssystemkonfiguration B 345 speichern.
Die Benutzeranwendung 330 kann eine Software-Anwendung sein, die durch einen in der Datenverarbeitungseinheit 305 angemeldeten Benutzer ausführbar ist. In einigen Ausführungsformen kann die Benutzeranwendung 330 im Wesentlichen gleich der in 4 erörterten Benutzeranwendung sein und die gleichen Operationen ausführen. Die Benutzeranwendung 330 kann zum Beispiel ausgeführt werden, um es einem Benutzer zu ermöglichen, eine Anforderung für das Ändern einer Betriebssystemkonfiguration auf der Datenverarbeitungseinheit 305 zu senden. In einer bestimmten Ausführungsform kann die Benutzeranwendung 330 ausgeführt werden, um die Konfiguration des Bootladeprogramms 335 zu aktualisieren, wie hierin beschrieben ist.
Das Bootladeprogramm 335 kann eine Software-Anwendung sein, die zur Ausführung auf der Datenverarbeitungseinheit 305 berechtigt ist, um eine Betriebssystemkonfiguration wie beispielsweise die Betriebssystemkonfiguration A 340 und die Betriebssystemkonfiguration B 345 zu booten. In einigen Ausführungsformen kann das Bootladeprogramm 335 mit einem privaten Schlüssel eines Public-Private-Key-Paares signiert werden, um die Integrität seines ausführbaren Codes sicherzustellen. Nach einem Neustart der Datenverarbeitungseinheit 305 kann das Bootladeprogramm 335 von einer vertrauenswürdigen Anwendung (z.B. der vertrauenswürdigen Anwendung 360) ausgeführt werden, um, beruhend auf einer Konfiguration des Bootladeprogramms, eine vorausgewählte Betriebssystemkonfiguration zu authentifizieren und zu booten.
Bei der Betriebssystemkonfiguration A 340 und der Betriebssystemkonfiguration B 345 kann es sich um zwei verschiedene bootfähige Betriebssystemkonfigurationen handeln, die auf der Datenverarbeitungseinheit 305 gespeichert sind. Jede Betriebssystemkonfiguration kann signiert sein und einen Betriebssystemkernel sowie einen Satz von zugehörigen Kernel-Parameterwerten enthalten, wie hier beschrieben ist. In einigen Ausführungsformen können sowohl die Betriebssystemkonfiguration A 340 als auch die Betriebssystemkonfiguration B 345 den gleichen Betriebssystemkernel und verschiedene Sätze von Kernel-Parameterwerten haben. In bestimmten Ausführungsformen können die Betriebssystemkonfiguration A 340 und die Betriebssystemkonfiguration B 345 verschiedene Betriebssystemkernels und ähnliche Kernel-Parameterwerte haben (z.B. können die Kernel-Parameterwerte sicherstellen, dass jede Konfiguration so gebootet wird, dass sie dieselbe Zugriffsrichtliniendurchsetzungsstufe hat).
Die Sicherheitskomponente 325 kann Hardware- und Softwarekomponenten enthalten, um die Integrität des ausführbaren Codes oder die Authentizität von Anwendungen sicherzustellen, die auf der Datenverarbeitungseinheit 305 booten. In einigen Ausführungsformen kann die Sicherheitskomponente 325 einen nicht flüchtigen Hauptspeicher 350, auf den Benutzer zugreifen können, einen geschützten nicht flüchtigen Hauptspeicher 355, eine vertrauenswürdige Anwendung 360 und eine Datenbank 365 enthalten. Während sie als eine getrennte Komponente gezeigt ist, kann die gesamte oder ein Teil der Sicherheitskomponente 325 in einer oder mehreren anderen Komponenten der Datenverarbeitungseinheit 305 enthalten sein.
Bei dem nicht flüchtigen Hauptspeicher 350, auf den Benutzer zugreifen können, kann es sich um einen beliebigen nicht flüchtigen Hauptspeicher handeln, auf den eine Anwendung, die durch einen Benutzer der Datenverarbeitungseinheit 305 ausführbar ist, mindestens zum Schreiben zugreifen kann, wie hierin beschrieben ist. Der nicht flüchtige Hauptspeicher 355, auf den Benutzer zugreifen können, kann zum Beispiel ein batteriegepufferter Direktzugriffsspeicher, ein Flashspeicher oder ein Bereich auf dem Massenspeicher 320 sein. In bestimmten Ausführungsformen kann der nicht flüchtige Hauptspeicher, auf den Benutzer zugreifen können, als ein Zwischenspeicherungsbereich dienen, um einen öffentlichen Schlüssel vorübergehend zu speichern, der einer Betriebssystemkonfiguration entspricht, die zum Booten auf der Datenverarbeitungseinheit 305 ausgewählt wurde, wie hierin beschrieben ist.
Der geschützte nicht flüchtige Hauptspeicher 355 kann ein Bereich des nicht flüchtigen Hauptspeichers sein, auf den nur von einem ausgewählten Satz von Anwendungen (z.B. der vertrauenswürdigen Anwendung 360 und dem Bootladeprogramm 335) zugegriffen werden kann. In einigen Ausführungsformen kann in den Hauptspeicher 355 nur von der vertrauenswürdigen Anwendung 360 und nur während eines Preboot-Zustands der Datenverarbeitungseinheit 305 geschrieben werden. In bestimmten Ausführungsformen speichert der geschützte nicht flüchtige Hauptspeicher 355 einen Satz von oder eine Datenbank mit überprüften öffentlichen Schlüsseln, um Anwendungen zu authentifizieren, die auf der Datenverarbeitungseinheit 305 booten können.
Die vertrauenswürdige Anwendung 360 kann eine Anwendung sein, die über durch die Datenverarbeitungseinheit 305 authentifizierten, ausführbaren Code verfügt und so konfiguriert ist, dass sie bei einem Neustart der Datenverarbeitungseinheit 305 automatisch ausgeführt wird. In einigen Ausführungsformen kann die vertrauenswürdige Anwendung 360 so konfiguriert sein, dass sie automatisch eine Prüfung auf neue digitale Schlüssel vornimmt, die an einem vorher festgelegten Speicherort des nicht flüchtigen Hauptspeichers 350, auf den Benutzer zugreifen können, gespeichert sind, und deren Gültigkeit überprüft. Die vertrauenswürdige Anwendung 360 kann auch so konfiguriert sein, dass sie die Operationen der hierin erörterten vertrauenswürdigen Anwendung ausführt.
Die Datenbank 365 kann eine Repository mit öffentlichen Schlüsseln sein, um Anwendungen zu authentifizieren, die auf der Datenverarbeitungseinheit 305 booten können. In einigen Ausführungsformen kann die Datenbank 365 ein Teil des geschützten nicht flüchtigen Hauptspeichers 355 sein. In bestimmten Ausführungsformen können ein oder mehrere in der Datenbank 365 gespeicherte öffentliche Schlüssel während der Herstellung der Datenverarbeitungseinheit 305 geschrieben und digital signiert werden.
Die lokale Benutzerschnittstelle 380 kann ein Benutzerschnittstellenterminal sein, das so konfiguriert ist, dass es einem Benutzer ermöglicht, Eingabe- und Ausgabeoperationen in Bezug auf die Datenverarbeitungseinheit 305 auszuführen. Die lokale Benutzerschnittstelle 380 kann mit der Datenverarbeitungseinheit 305 mittels einer Verbindungseinheit (z.B. eines Datenkabels, eines Videokabels oder eines anderen Eingabe-Ausgabe-Kabels oder -Busses) physisch verbunden sein. Gemäß verschiedenen Ausführungsformen kann die lokale Benutzerschnittstelle 380 eine Interaktion zwischen der vertrauenswürdigen Anwendung 360 und einem Benutzer ermöglichen, der im physischen Besitz der Datenverarbeitungseinheit 305 ist oder sich physisch an der Datenverarbeitungseinheit 305 befindet.
4 stellt einen Ablaufplan 400 eines Satzes von durch einen Computer ausgeführten Operationen dar, um gemäß verschiedenen Ausführungsformen unter Verwendung von Hardware und Software eine Auswahl eines Benutzers einer Betriebssystemkonfiguration aus einem Satz von Betriebssystemkonfigurationen sicher zu booten. Die Operationen des Ablaufplans 400 können durch eine Datenverarbeitungseinheit ausgeführt werden, die so konfiguriert ist, dass sie Anwendungen sicher bootet, wie hierin beschrieben ist. Jede in dem Ablaufplan 400 gezeigte Operation kann durch die Datenverarbeitungseinheit automatisch oder als Reaktion auf ein oder mehrere Ereignisse (z.B. eine Benutzeraktion oder - anforderung) ausgeführt werden.
Bei der Operation 405 kann die Datenverarbeitungseinheit eine Anforderung von einer Benutzeranwendung empfangen, die unter einer ersten Betriebssystemkonfiguration (O/S-Konfiguration A) ausgeführt wird, um eine zweite Betriebssystemkonfiguration (O/S-Konfiguration B) zu booten. Die Anforderung kann von einem beliebigen Terminal oder einer beliebigen Einheit empfangen werden, die es einem Benutzer ermöglicht, auf die Datenverarbeitungseinheit zuzugreifen und die Benutzeranwendung auszuführen. In einigen Ausführungsformen kann der Benutzer auf die Datenverarbeitungseinheit zugreifen und die Benutzeranwendung unter Verwendung eines Satzes von Identifikationsdaten (z.B. Benutzername und ein Kennwort, das zu einem berechtigten Benutzerkonto gehört) ausführen.
Die Betriebssystemkonfiguration B kann einen Betriebssystemkernel enthalten, der einen Satz von Kernel-Parameterwerten hat, wie hierin beschrieben ist. Die Betriebssystemkonfiguration B kann mit einem privaten Schlüssel eines Public-Private-Key-Paares (z.B. eines asymmetrischen Schlüsselpaares) signiert werden. In einigen Ausführungsformen kann die O/S-Konfiguration B den gleichen Betriebssystemkernel wie den in der O/S-Konfiguration A enthaltenen Betriebssystemkernel enthalten. Die O/S-Konfiguration B kann jedoch einen anderen Satz von Kernel-Parameterwerten als den in der O/S-Konfiguration A enthaltenen Satz von Kernel-Parameterwerten haben. Ruft man sich das zuvor erörterte Beispiel der Betriebssystemkonfiguration ins Gedächtnis, können sowohl die O/S-Konfiguration A als auch die O/S-Konfiguration B einen Linux-Kernel mit einem SELinux-Modul enthalten. Die O/S-Konfiguration A kann jedoch Kernel-Parameterwerte enthalten, um den Linux-Kernel mit einer hohen Zugriffssteuerungsdurchsetzungs-Sicherheitsstufe zu booten, während die O/S-Konfiguration B Kernel-Parameterwerte enthalten kann, um den Linux-Kernel mit einer mittleren Zugriffssteuerungsdurchsetzungs-Sicherheitsstufe zu booten.
Bei der Operation 410 kann die Datenverarbeitungseinheit den öffentlichen Schlüssel, der einem privaten Schlüssel entspricht, welcher verwendet wird, um die O/S-Konfiguration B zu signieren, in einem nicht flüchtigen Hauptspeicher speichern, wie hierin beschrieben ist. In einigen Ausführungsformen kann die Benutzeranwendung oder eine weitere Anwendung die Datenverarbeitungseinheit veranlassen, die Operation 410 auszuführen.
Bei der Operation 415 kann die Datenverarbeitungseinheit neu starten. Nach dem Neustart kann die Datenverarbeitungseinheit die Operationen 425 und 430 ausführen, während sie sich in einem Preboot-Zustand befindet, der mit der Operation 420 konsistent ist.
Bei der Operation 425 kann die Datenverarbeitungseinheit eine vertrauenswürdige (z.B. sichere oder garantiert nicht modifizierte) Anwendung ausführen, um ein Signal zu empfangen, das die Anforderung für das Booten der O/S-Konfiguration B bestätigt. In einigen Ausführungsformen kann die vertrauenswürdige Anwendung im Wesentlichen gleich dem UEFI-shim-Programm sein. Das Datenverarbeitungssystem kann so konfiguriert sein, dass es die vertrauenswürdige Anwendung nach dem Neustart des Datenverarbeitungssystems automatisch lädt, authentifiziert und ausführt. Die vertrauenswürdige Anwendung kann so konfiguriert sein, dass sie einen bestimmten Bereich des nicht flüchtigen Hauptspeichers (z.B. den Bereich des nicht flüchtigen Hauptspeichers, der in der Operation 410 beschrieben wurde) liest, um festzustellen, ob neue öffentliche Schlüssel zu dem Datenverarbeitungssystem hinzugefügt wurden. Die vertrauenswürdige Anwendung kann des Weiteren so konfiguriert sein, dass sie als Reaktion auf das Erkennen des neuen öffentlichen Schlüssels überprüft, ob der öffentliche Schlüssel einer bekannten Betriebssystemkonfiguration (z.B. einer Betriebssystemkonfiguration, die zum Booten auf dem Datenverarbeitungssystem berechtigt ist) entspricht. Als Reaktion auf das Überprüfen des öffentlichen Schlüssels kann die vertrauenswürdige Anwendung den öffentlichen Schlüssel in einen geschützten Hauptspeicher der Datenverarbeitungseinheit kopieren, übertragen oder verschieben, wie hierin beschrieben ist. In einigen Ausführungsformen ist der geschützte Hauptspeicher nur durch die vertrauenswürdige Anwendung beschreibbar. Darüber hinaus kann in den geschützten Hauptspeicher nur geschrieben werden, solange sich die Datenverarbeitungseinheit in einem Preboot-Zustand befindet.
Bei der Operation 430 kann die Datenverarbeitungseinheit ein Bootladeprogramm ausführen, um die O/S-Konfiguration B zu authentifizieren und zu booten. In einigen Ausführungsformen kann die vertrauenswürdige Anwendung das Bootladeprogramm für das Datenverarbeitungssystem laden, authentifizieren und dann ausführen. Das authentifizierte Bootladeprogramm kann den öffentlichen Schlüssel aus dem geschützten Hauptspeicher lesen und ihn verwenden, um die O/S-Konfiguration B vor dem Booten zu authentifizieren. Das Bootladeprogramm kann die O/S-Konfiguration B booten, wenn die Authentifizierung erfolgreich ist, während das Bootladeprogramm den Bootvorgang abbrechen kann, wenn die Authentifizierung nicht erfolgreich ist (z.B., wenn das Bootladeprogramm erkennt, dass die O/S-Konfiguration B geändert wurde, nachdem sie signiert worden ist).
Die Operationen des Ablaufplans 400 können an der Operation 435 enden.
In einigen Ausführungsformen bestimmt der Satz der Kernel-Parameterwerte in der O/S-Konfiguration B Software-Module, die ladbar sind, während die O/S-Konfiguration B auf dem Datenverarbeitungssystem gebootet wird. Ferner kann der Satz von Parameterwerten in verschiedenen Ausführungsformen die Durchsetzung von Zugriffssteuerungsrechten (z.B. die Zugriffssteuerungsrichtlinien-Durchsetzungsstufe) unter der O/S-Konfiguration B bestimmen. Diese Ausführungsformen bieten den Vorteil, dass sichergestellt ist, dass die Konfiguration und die Zugriffssteuerungsrichtlinien des Datenverarbeitungssystems nicht durch einen Benutzer, der das Datenverarbeitungssystem verwendet, geändert werden können, außer wenn der Benutzer physischen Zugriff auf das Datenverarbeitungssystem hat und die Integrität einer Betriebssystemkonfiguration, die ausgewählt wurde, um das Datenverarbeitungssystem zu ändern, authentifiziert wird, wie hierin beschrieben ist.
Gemäß verschiedenen Ausführungsformen ist der geschützte nicht flüchtige Hauptspeicher nur durch einen Satz von Anwendungen, darunter der vertrauenswürdigen Anwendung, beschreibbar, bei denen die Integrität des ausführbaren Codes durch eine Hardwarekomponente des Datenverarbeitungssystems authentifiziert wird, wie hierin beschrieben ist. Diese Ausführungsformen bieten den Vorteil, dass sichergestellt ist, dass nicht autorisierte öffentliche Schlüssel nicht zu dem Datenverarbeitungssystem hinzugefügt werden können. Dies wiederum verringert die Wahrscheinlichkeit, dass nicht autorisierte Betriebssystemkonfigurationen auf dem Datenverarbeitungssystem gebootet werden können.
5 stellt ein Interaktionsdiagramm 500 von Interaktionen zwischen einem Benutzer und einem Datenverarbeitungssystem dar, das einen Satz von durch einen Computer ausgeführten Operationen ausführt, um gemäß verschiedenen Ausführungsformen unter Verwendung von Hardware und Software eine aus einem Satz von Betriebssystemkonfigurationen ausgewählte Betriebssystemkonfiguration sicher zu booten. Das Interaktionsdiagramm 500 veranschaulicht Interaktionen zwischen einem Benutzer 505 und Elementen eines Datenverarbeitungssystems, das so konfiguriert ist, dass es eine Betriebssystemkonfiguration sicher bootet, wie hierin beschrieben ist. Zu Komponenten des Interaktionsdiagramms gehören der Benutzer 505, eine Ausführungsumgebung 510 des Datenverarbeitungssystems und der Systemzustand 515 des Datenverarbeitungssystems. Die Ausführungsumgebung 510 kann die Betriebssystemkonfiguration A 525 sein, die die Benutzeranwendung 530, die vertrauenswürdige Anwendung 550, das Bootladeprogramm 560 und die Betriebssystemkonfiguration B 570 ausführt. Der Systemzustand 515, wie er im Kontext von 5 verwendet wird, gibt das Ziel von Operationen an, die in der Datenverarbeitungseinheit gespeicherte, nicht flüchtige Daten entweder lesen oder modifizieren. Der Benutzer 505 kann mit der Ausführungsumgebung 510 über eine Benutzerschnittstelle 520 (z.B. einem lokalen oder fernen Benutzerschnittstellenterminal) oder über eine lokale Benutzerschnittstelle 545 (z.B. während der Benutzer physischen Zugriff auf das Datenverarbeitungssystem hat) interagieren.
Der erste Satz von Interaktionen kann ausgeführt werden, während die Betriebssystemkonfiguration A (O/S-Konfiguration A) auf dem Datenverarbeitungssystem gebootet wird, wie durch das Referenzelement 535 gezeigt ist.
Gemäß verschiedenen Ausführungsformen kann die Benutzeranwendung 530 eine Anforderung 531 für das Laden der Betriebssystemkonfiguration B (O/S-Konfiguration B) empfangen. Die Anforderung 531 kann von dem Benutzer 505 über die Benutzerschnittstelle 520 empfangen werden. Die Benutzeranwendung 530 kann dann einen Satz von Operationen 532 ausführen, um einen öffentlichen Schlüssel zu speichern, der zu einem privaten Schlüssel gehört, welcher verwendet wird, um die O/S-Konfiguration B zu signieren. Der öffentliche Schlüssel kann in einem nicht flüchtigen Hauptspeicher des Datenverarbeitungssystems gespeichert werden. Die Benutzeranwendung 530 kann des Weiteren die Operationen 533 ausführen, um eine Konfiguration des Bootladeprogramms des Datenverarbeitungssystems zu aktualisieren, um die O/S-Konfiguration B nach dem nächsten Neustart des Datenverarbeitungssystems zu booten. Die O/S-Konfiguration A kann dann eine Anforderung 534 für einen Neustart des Datenverarbeitungssystems empfangen.
Das Datenverarbeitungssystem kann dann neu starten, wie durch das Referenzelement 540 gezeigt ist.
Die folgenden Interaktionen werden ausgeführt, während sich das Datenverarbeitungssystem in einem Preboot-Zustand befindet, wie durch das Referenzelement 565 gezeigt ist.
Gemäß verschiedenen Ausführungsformen führt eine vertrauenswürdige Anwendung 550 Operationen 551 aus, um den gespeicherten öffentlichen Schlüssel aus dem nicht flüchtigen Hauptspeicher abzurufen und zu überprüfen (z.B. validieren), dass der abgerufene öffentliche Schlüssel einer bekannten (z.B. gültigen) signierten Betriebssystemkonfiguration entspricht. Die vertrauenswürdige Anwendung 550 kann ferner Operationen 552 ausführen, um den Benutzer 505 über das lokale Benutzerschnittstellenterminal 545 aufzufordern, die Anforderung für das Booten der O/S-Konfiguration B zu bestätigen. Die vertrauenswürdige Anwendung 550 kann dann Operationen 553 ausführen, um eine Bestätigung von dem Benutzer 505 zu empfangen. Die vertrauenswürdige Anwendung kann des Weiteren Operationen 554 und 555 ausführen, um den öffentlichen Schlüssel in einen geschützten Hauptspeicher zu verschieben und das Bootladeprogramm 560 zu authentifizieren und auszuführen. Das Bootladeprogramm 560 kann die Operationen 561 und 562 ausführen, um den öffentlichen Schlüssel aus dem geschützten Hauptspeicher abzurufen und die O/S-Konfiguration B zu authentifizieren und zu booten. In einigen Ausführungsformen kann das Bootladeprogramm 560 die vertrauenswürdige Anwendung 550 veranlassen, die Operationen 561 und 562 auszuführen und nach einer erfolgreichen Authentifizierung (oder Überprüfung) die O/S-Konfiguration B 570 zu booten.
Das Datenverarbeitungssystem kann dann in einen gebooteten Zustand unter der O/S-Konfiguration B eintreten, wie durch das Referenzelement 575 gezeigt ist.
6 stellt ein Blockschaubild einer Datenverarbeitungseinheit 600 dar, die über Hardware- und Softwarekomponenten verfügt, um gemäß verschiedenen Ausführungsformen unter Verwendung von Hardware und Software eine aus einem Satz von Betriebssystemkonfigurationen ausgewählte Betriebssystemkonfiguration sicher zu booten.
Zu den Komponenten der Datenverarbeitungseinheit 600 können ein oder mehrere Prozessoren 606, ein Hauptspeicher 612, eine Terminalschnittstelle 618, eine Speicherschnittstelle 620, eine Eingabe-/Ausgabe-(„E/A“)-Einheitenschnittstelle 622 und eine Netzwerkschnittstelle 624 gehören, die alle für eine komponentenübergreifende Übertragung über einen Hauptspeicherbus 610, einen E/A-Bus 616, eine Busschnittstelleneinheit („IF“) 608 und eine E/A-Busschnittstelleneinheit 614 direkt oder indirekt per Datenaustausch verbunden sind.
Die Datenverarbeitungseinheit 600 kann eine oder mehrere vielseitig einsetzbare, programmierbare zentrale Verarbeitungseinheiten (CPUs) 606A und 606B enthalten, die hierin generisch als der Prozessor 606 bezeichnet werden. In einer Ausführungsform kann die Datenverarbeitungseinheit 600 mehrere Prozessoren enthalten; in einer weiteren Ausführungsform kann die Datenverarbeitungseinheit 600 alternativ jedoch eine einzelne CPU-Einheit sein. Jeder Prozessor 606 führt in dem Hauptspeicher 612 gespeicherte Instruktionen aus.
Die Datenverarbeitungseinheit 600 kann eine Busschnittstelleneinheit 608 enthalten, um Übertragungen zwischen dem Prozessor 606, dem Hauptspeicher 612, dem Bildschirmsystem 604 und der E/A-Busschnittstelleneinheit 614 abzuwickeln. Die E/A-Busschnittstelleneinheit 614 kann mit dem E/A-Bus 616 verbunden sein, um Daten an die und von den verschiedenen E/A-Einheiten zu übertragen. Die E/A-Busschnittstelleneinheit 614 kann über den E/A-Bus 616 mit mehreren E/A-Schnittstelleneinheiten 618, 620, 622 und 624, die auch als E/A-Prozessoren (IOPs) oder E/A-Adapter (IOAs) bezeichnet werden, Daten austauschen. Das Bildschirmsystem 604 kann einen Bildschirmcontroller, einen Bildschirmspeicher oder beides enthalten. Der Bildschirmcontroller kann einer Bildschirmeinheit 602 Video-, Audio- oder beide Arten von Daten bereitstellen. Der Bildschirmspeicher kann ein dedizierter Hauptspeicher zur Pufferung von Videodaten sein. Das Bildschirmsystem 604 kann mit einer Bildschirmeinheit 602 wie beispielsweise einem eigenständigen Bildschirm, einem Computer-Monitor, einem Bildschirm eines Fernsehgeräts, eines Tablett-Computers oder eines Handheld-Computers oder einer weiteren anderen Einheit mit Anzeigemöglichkeit verbunden sein. In einer Ausführungsform kann die Bildschirmeinheit 602 einen oder mehrere Lautsprecher zur Tonwiedergabe enthalten. Alternativ können ein oder mehrere Lautsprecher zur Tonwiedergabe mit einer E/A-Schnittstelleneinheit verbunden sein. In alternativen Ausführungsformen können eine oder mehrere von dem Bildschirmsystem 604 bereitgestellte Funktionen eine interne integrierte Schaltung sein, die auch den Prozessor 606 enthält. Ferner können eine oder mehrere der von der Busschnittstelleneinheit 608 bereitgestellten Funktionen eine interne integrierte Schaltung sein, die auch den Prozessor 606 enthält.
Die E/A-Schnittstelleneinheiten unterstützen den Datenaustausch mit einer Vielzahl von Speicher- und E/A-Einheiten. Die Terminalschnittstelleneinheit 618 unterstützt zum Beispiel den Anschluss von einer oder mehreren Benutzer-E/A-Einheiten, zu denen Benutzer-Ausgabeeinheiten (wie beispielsweise eine Video-Bildschirmeinheit, ein Lautsprecher und/oder ein Fernsehgerät) und Benutzer-Eingabeeinheiten (wie beispielsweise eine Tastatur, eine Maus, ein Ziffernblock, ein Touchpad, eine Rollkugel, Schaltflächen, ein Lichtstift oder andere Zeigereinheiten) gehören können. Ein Benutzer kann die Benutzer-Eingabeeinheiten unter Verwendung einer Benutzerschnittstelle betätigen, um der Benutzer-E/A-Einheit 626 Eingabedaten und Befehle bereitzustellen, und die Datenverarbeitungseinheit 600 kann über die Benutzer-Ausgabeeinheiten Ausgabedaten empfangen. Eine Benutzerschnittstelle kann zum Beispiel durch die Benutzer-E/A-Einheit 626 dargestellt werden, wie sie beispielsweise auf einer Bildschirmeinheit angezeigt, über einen Lautsprecher wiedergegeben oder über einen Drucker gedruckt wird.
Die Speicherschnittstelle 620 unterstützt den Anschluss von einem oder mehreren Plattenlaufwerken oder Direktzugriffspeichereinheiten 628 (bei denen es sich üblicherweise um rotierende Magnetplattenlaufwerk-Speichereinheiten handelt, obgleich es alternativ andere Speichereinheiten, darunter Anordnungen von Festplattenlaufwerken, die so konfiguriert sind, dass sie einem Host-Computer als eine einzige große Speichereinheit erscheinen, oder Solid-State-Laufwerke, wie beispielsweise ein Flashspeicher, sein könnten.) In einer weiteren Ausführungsform kann die Speichereinheit 628 mittels einer beliebigen Art einer sekundären Speichereinheit ausgeführt sein. Der Inhalt des Hauptspeichers 612 oder eines beliebigen Teils davon kann nach Bedarf in der Speichereinheit 628 gespeichert oder daraus abgerufen werden. Die E/A-Einheitenschnittstelle 622 stellt beliebigen von verschiedenen anderen E/A-Einheiten oder Einheiten anderer Art, wie beispielsweise Druckern oder Telefaxgeräten, eine Schnittstelle bereit. Die Netzwerkschnittstelle 626 stellt einen oder mehrere Übertragungspfade von der Datenverarbeitungseinheit 600 zu anderen digitalen Einheiten und Datenverarbeitungssystemen bereit.
Die Sicherheitskomponente 631 kann im Wesentlichen gleich der Sicherheitskomponente 325 (3) sein und die gleichen Funktionen enthalten. Die Sicherheitskomponente 631 kann Hardware- und Softwarekomponenten enthalten, um die Integrität des ausführbaren Codes oder die Authentizität von Anwendungen sicherzustellen, die auf der Datenverarbeitungseinheit 600 booten.
Obgleich die in 6 gezeigte Datenverarbeitungseinheit 600 eine bestimmte Busstruktur veranschaulicht, die einen direkten Übertragungspfad zwischen den Prozessoren 606, dem Hauptspeicher 612, der Busschnittstelle 608, dem Bildschirmsystem 604 und der E/A-Busschnittstelleneinheit 614 bereitstellt, kann die Datenverarbeitungseinheit 600 in alternativen Ausführungsformen verschiedene Busse oder Übertragungspfade enthalten, die in beliebigen von verschiedenen Formen angeordnet sein können, wie beispielsweise als Punkt-zu-Punkt-Verbindungen in hierarchischen, Stern- oder Netzkonfigurationen, als mehrere hierarchische Busse, parallele und redundante Pfade oder in einer beliebigen anderen geeigneten Art der Konfiguration. Während die E/A-Busschnittstelleneinheit 614 und der E/A-Bus 608 als einzelne jeweilige Einheiten gezeigt sind, kann die Datenverarbeitungseinheit 600 darüber hinaus mehrere E/A-Busschnittstelleneinheiten 614 und/oder mehrere E/A-Busse 616 enthalten. Zwar sind mehrere E/A-Schnittstelleneinheiten gezeigt, die den E/A-Bus 616 von verschiedenen Übertragungspfaden trennen, die zu den verschiedenen E/A-Einheiten führen, doch sind einige oder alle der E/A-Einheiten in weiteren Ausführungsformen direkt mit einem oder mehreren System-E/A-Bussen verbunden.
In verschiedenen Ausführungsformen ist die Datenverarbeitungseinheit 600 ein Mehrbenutzer-Mainframe-Computersystem, ein Einzelbenutzersystem oder ein Servercomputer bzw. eine ähnliche Einheit, die nur eine kleine oder gar keine direkte Benutzerschnittstelle hat, aber Anforderungen von anderen Computersystemen (Clients) empfängt. In weiteren Ausführungsformen kann die Datenverarbeitungseinheit 600 als ein Desktop-Computer, ein tragbarer Computer, ein Laptop- oder Notebook-Computer, ein Tablet-Computer, ein Taschenrechner, ein Telefon, ein Smartphone oder als eine beliebige andere geeignete Art eines elektronischen Geräts ausgeführt sein.
In einer Ausführungsform kann der Hauptspeicher 612 einen Direktzugriffs-Halbleiterspeicher, eine Speichereinheit oder ein Speichermedium (entweder flüchtig oder nicht flüchtig) enthalten, um Daten und Programme zu speichern oder zu codieren. In einer weiteren Ausführungsform stellt der Hauptspeicher 612 den gesamten virtuellen Speicher der Datenverarbeitungseinheit 600 dar und kann auch den virtuellen Speicher von anderen Computersystemen enthalten, die mit der Datenverarbeitungseinheit 600 verbunden oder über ein Netzwerk 630 angeschlossen sind. Der Hauptspeicher 612 kann eine einzelne monolithische Einheit sein, in weiteren Ausführungsformen kann der Hauptspeicher 612 jedoch eine Hierarchie von Cachespeichern und anderen Hauptspeichereinheiten enthalten. Zum Beispiel kann der Hauptspeicher in mehreren Cachespeicher-Stufen vorhanden sein und diese Cachespeicher können weiter nach ihrer Funktion unterteilt sein, so dass ein Cachespeicher Instruktionen enthält, während ein anderer Daten, die keine Instruktionen sind, enthält, welche von dem Prozessor verwendet werden. Der Hauptspeicher 612 kann noch weiter verteilt und verschiedenen CPUs oder Gruppen von CPUs zugeordnet sein, wie dies bei beliebigen verschiedenen Computerarchitekturen mit so genanntem nichteinheitlichem Speicherzugriff (non-uniform memory access (NUMA)) bekannt ist.
Der Hauptspeicher 612 kann alle oder einen Teil der in den 1 bis 5 gezeigten Komponenten und Daten speichern. Im Einzelnen können ein(e) oder mehrere einer/eines Benutzeranwendung, vertrauenswürdigen Anwendung, Bootladeprogramms und Betriebssystemkonfiguration aus der Speichereinheit 628 oder der Sicherheitskomponente 631 in den Hauptspeicher 612 geladen werden, um authentifiziert und ausgeführt zu werden, um die hierin beschriebenen Operationen durchzuführen. Der durch einen Computer ausführbare Code kann durch den Prozessor 606 ausgeführt werden. Einige oder alle der in den 1 bis 5 gezeigten Komponenten und Daten können sich auf verschiedenen Computersystemen befinden und auf sie kann über einen Fernzugriff, z.B. über ein Netzwerk 630, zugegriffen werden. Die Datenverarbeitungseinheit 600 kann Mechanismen der virtuellen Adressierung verwenden, die es den Programmen der Datenverarbeitungseinheit 600 ermöglichen, sich so zu verhalten, als hätten sie anstelle des Zugriffs auf mehrere kleinere Speicherentitäten nur Zugriff auf eine einzige große Speicherentität. Während die in den 1 bis 5 gezeigten Komponenten und Daten als in dem Hauptspeicher 612 enthalten veranschaulicht sind, sind diese Komponenten und Daten somit nicht unbedingt alle komplett gleichzeitig in derselben Speichereinheit enthalten. Obgleich die in den 1 bis 5 gezeigten Komponenten und Daten als getrennte Entitäten veranschaulicht sind, können in weiteren Ausführungsformen einige von ihnen, Teile von einigen von ihnen oder alle von ihnen zusammengepackt sein.
In einer Ausführungsform können die in den 1 bis 5 gezeigten Komponenten und Daten Instruktionen oder Anweisungen enthalten, die auf dem Prozessor 606 ausgeführt werden, oder Instruktionen oder Anweisungen, die von Instruktionen oder Anweisungen interpretiert werden, welche auf dem Prozessor 606 ausgeführt werden, um die Funktionen auszuführen, die nachstehend weiter beschrieben sind. In einer weiteren Ausführungsform können die in den 1 bis 5 gezeigten Komponenten mittels Halbleitereinheiten, Chips, Logikgattern, Schaltungen, Schaltungskarten und/oder anderen physischen Hardware-Einheiten anstelle von oder zusätzlich zu einem auf einem Prozessor beruhenden System in Hardware ausgeführt sein. In einer Ausführungsform können die in den 1 bis 5 gezeigten Komponenten zusätzlich zu Instruktionen oder Anweisungen Daten enthalten.
6 soll repräsentative Komponenten der Datenverarbeitungseinheit 600 darstellen. Einzelne Komponenten können jedoch eine größere Komplexität aufweisen als sie in 6 dargestellt ist. In 6 können andere als die gezeigten oder zusätzliche Komponenten vorhanden sein und die Anzahl, die Art und die Konfiguration solcher Komponenten kann variieren. Mehrere bestimmte Beispiele für zusätzliche Komplexität oder zusätzliche Varianten sind hierin offenbart; diese haben jedoch lediglich Beispielcharakter und sind nicht unbedingt die einzigen solchen Varianten. Die verschiedenen Programmkomponenten, die als in 6 enthalten beschrieben sind, können in verschiedenen Ausführungsformen auf mehrere unterschiedliche Arten, darunter mittels verschiedener Computeranwendungen, Routinen, Komponenten, Programme, Objekte, Module, Datenstrukturen usw., ausgeführt sein, die hierin als „Software“, „Computerprogramme“ oder einfach „Programme“ bezeichnet sein können.
Bei der vorliegenden Erfindung kann es sich um ein System, ein Verfahren und/oder ein Computerprogrammprodukt handeln. Das Computerprogrammprodukt kann (ein) durch einen Computer lesbare(s) Speichermedium (oder -medien) beinhalten, auf dem/denen durch einen Computer lesbare Programminstruktionen gespeichert sind, um einen Prozessor dazu zu veranlassen, Aspekte der vorliegenden Erfindung auszuführen.
Bei dem durch einen Computer lesbaren Speichermedium kann es sich um eine physische Einheit handeln, die Instruktionen zur Verwendung durch ein System zur Ausführung von Instruktionen behalten und speichern kann. Bei dem durch einen Computer lesbaren Speichermedium kann es sich zum Beispiel um eine elektronische Speichereinheit, eine magnetische Speichereinheit, eine optische Speichereinheit, eine elektromagnetische Speichereinheit, eine Halbleiterspeichereinheit oder jede geeignete Kombination daraus handeln, ohne auf diese beschränkt zu sein. Zu einer nicht erschöpfenden Liste spezifischerer Beispiele des durch einen Computer lesbaren Speichermediums gehören die folgenden: eine tragbare Computerdiskette, eine Festplatte, ein Direktzugriffsspeicher (RAM), ein Nur-Lese-Speicher (ROM), ein löschbarer programmierbarer Nur-Lese-Speicher (EPROM bzw. Flash-Speicher), ein statischer Direktzugriffsspeicher (SRAM), ein tragbarer Kompaktspeicherplatte-Nur-Lese-Speicher (CD-ROM), eine DVD (digital versatile disc), ein Speicher-Stick, eine Diskette, eine mechanisch kodierte Einheit wie zum Beispiel Lochkarten oder gehobene Strukturen in einer Rille, auf denen Instruktionen gespeichert sind, und jede geeignete Kombination daraus. Ein durch einen Computer lesbares Speichermedium soll in der Verwendung hierin nicht als flüchtige Signale an sich aufgefasst werden, wie zum Beispiel Funkwellen oder andere sich frei ausbreitende elektromagnetische Wellen, elektromagnetische Wellen, die sich durch einen Wellenleiter oder ein anderes Übertragungsmedium ausbreiten (z.B. durch ein Glasfaserkabel geleitete Lichtimpulse) oder durch einen Draht übertragene elektrische Signale.
Hierin beschriebene, durch einen Computer lesbare Programminstruktionen können von einem durch einen Computer lesbaren Speichermedium auf jeweilige Datenverarbeitungs-/Verarbeitungseinheiten oder über ein Netzwerk wie zum Beispiel das Internet, ein lokales Netzwerk, ein Weitverkehrsnetz und/oder ein drahtloses Netzwerk auf einen externen Computer oder eine externe Speichereinheit heruntergeladen werden. Das Netzwerk kann Kupferübertragungskabel, Lichtwellenübertragungsleiter, drahtlose Übertragung, Leitwegrechner, Firewalls, Vermittlungseinheiten, Gateway-Computer und/oder Edge-Server aufweisen. Eine Netzwerkadapterkarte oder Netzwerkschnittstelle in jeder Datenverarbeitungs-/Verarbeitungseinheit empfängt durch einen Computer lesbare Programminstruktionen aus dem Netzwerk und leitet die durch einen Computer lesbaren Programminstruktionen zur Speicherung in einem durch einen Computer lesbaren Speichermedium innerhalb der entsprechenden Datenverarbeitungs-/Verarbeitungseinheit weiter.
Bei durch einen Computer lesbaren Programminstruktionen zum Ausführen von Arbeitsschritten der vorliegenden Erfindung kann es sich um Assembler-Instruktionen, ISA-Instruktionen (Instruction-Set-Architecture), Maschineninstruktionen, maschinenabhängige Instruktionen, Mikrocode, Firmware-Instruktionen, zustandssetzende Daten oder entweder Quellcode oder Objektcode handeln, die in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen geschrieben werden, darunter objektorientierte Programmiersprachen wie Smalltalk, C++ o.ä. sowie herkömmliche prozedurale Programmiersprachen wie die Programmiersprache „C“ oder ähnliche Programmiersprachen. Die durch einen Computer lesbaren Programminstruktionen können vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Software-Paket, teilweise auf dem Computer des Benutzers und teilweise auf einem fernen Computer oder vollständig auf dem fernen Computer oder Server ausgeführt werden. In letzterem Fall kann der entfernt angeordnete Computer mit dem Computer des Benutzers durch eine beliebige Art Netzwerk verbunden sein, darunter ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetz (WAN), oder die Verbindung kann mit einem externen Computer hergestellt werden (zum Beispiel über das Internet unter Verwendung eines Internet-Dienstanbieters). In einigen Ausführungsformen können elektronische Schaltungen, darunter zum Beispiel programmierbare Logikschaltungen, im Feld programmierbare Gatter-Anordnungen (FPGA, field programmable gate arrays) oder programmierbare Logikanordnungen (PLA, programmable logic arrays) die durch einen Computer lesbaren Programminstruktionen ausführen, indem sie Zustandsinformationen der durch einen Computer lesbaren Programminstruktionen nutzen, um die elektronischen Schaltungen zu personalisieren, um Aspekte der vorliegenden Erfindung durchzuführen.
Aspekte der vorliegenden Erfindung sind hierin unter Bezugnahme auf Ablaufpläne und/oder Blockschaltbilder bzw. Schaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es wird darauf hingewiesen, dass jeder Block der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder sowie Kombinationen von Blöcken in den Ablaufplänen und/oder den Blockschaltbildern bzw. Schaubildern mittels durch einen Computer lesbare Programminstruktionen ausgeführt werden können.
Diese durch einen Computer lesbaren Programminstruktionen können einem Prozessor eines Universalcomputers, eines Spezialcomputers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, so dass die über den Prozessor des Computers bzw. der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführten Instruktionen ein Mittel zur Umsetzung der in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder festgelegten Funktionen/Schritte erzeugen. Diese durch einen Computer lesbaren Programminstruktionen können auch auf einem durch einen Computer lesbaren Speichermedium gespeichert sein, das einen Computer, eine programmierbare Datenverarbeitungsvorrichtung und/oder andere Einheiten so steuern kann, dass sie auf eine bestimmte Art funktionieren, so dass das durch einen Computer lesbare Speichermedium, auf dem Instruktionen gespeichert sind, ein Herstellungsprodukt aufweist, darunter Instruktionen, welche Aspekte der/des in dem Block bzw. den Blöcken des Ablaufplans und/oder der Blockschaltbilder bzw. Schaubilder angegebenen Funktion/Schritts umsetzen.
Die durch einen Computer lesbaren Programminstruktionen können auch auf einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder eine andere Einheit geladen werden, um das Ausführen einer Reihe von Prozessschritten auf dem Computer bzw. der anderen programmierbaren Vorrichtung oder anderen Einheit zu verursachen, um einen auf einem Computer ausgeführten Prozess zu erzeugen, so dass die auf dem Computer, einer anderen programmierbaren Vorrichtung oder einer anderen Einheit ausgeführten Instruktionen die in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder festgelegten Funktionen/Schritte umsetzen.
Die Ablaufpläne und die Blockschaltbilder bzw. Schaubilder in den Figuren veranschaulichen die Architektur, die Funktionalität und die Arbeitsweise möglicher Ausführungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. In diesem Zusammenhang kann jeder Block in den Ablaufplänen oder Blockschaltbildern bzw. Schaubildern ein Modul, ein Segment oder einen Teil von Instruktionen darstellen, die eine oder mehrere ausführbare Instruktionen zur Ausführung der bestimmten logischen Funktion(en) aufweisen. In einigen alternativen Ausführungen können die in den Blöcken angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren gezeigt stattfinden. Zwei nacheinander gezeigte Blöcke können zum Beispiel in Wirklichkeit im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können manchmal je nach entsprechender Funktionalität in umgekehrter Reihenfolge ausgeführt werden. Es ist ferner anzumerken, dass jeder Block der Blockschaltbilder bzw. Schaubilder und/oder der Ablaufpläne sowie Kombinationen aus Blöcken in den Blockschaltbildern bzw. Schaubildern und/oder den Ablaufplänen durch spezielle auf Hardware beruhende Systeme umgesetzt werden können, welche die festgelegten Funktionen oder Schritte durchführen, oder Kombinationen aus Spezial-Hardware und Computerinstruktionen ausführen.
Die Beschreibungen der verschiedenen Ausführungsformen der vorliegenden Offenbarung erfolgten zum Zweck der Veranschaulichung, sollen jedoch nicht erschöpfend oder auf die offenbarten Ausführungsformen beschränkt sein. Viele Modifikationen und Varianten sind für den Fachmann erkennbar, ohne vom Umfang und Wesen der beschriebenen Ausführungsformen abzuweichen. Die hierin verwendete Terminologie wurde gewählt, um die Grundgedanken der Ausführungsformen, die praktische Anwendung oder technische Verbesserung gegenüber auf dem Markt befindlicher Technologien zu erklären bzw. um anderen Fachleuten das Verständnis der hierin offenbarten Ausführungsformen zu ermöglichen.

Claims

Verfahren, das aufweist: Empfangen, in einem gebooteten Zustand eines Datenverarbeitungssystems, einer Anforderung für das Laden einer Betriebssystemkonfiguration; Speichern, automatisch als Reaktion auf das Empfangen der Anforderung, eines digitalen Schlüssels, um die Betriebssystemkonfiguration zu authentifizieren; Neustarten des Datenverarbeitungssystems; als Reaktion auf das Neustarten des Datenverarbeitungssystems und während sich das Datenverarbeitungssystem in einem Preboot-Zustand befindet: Validieren, dass der gespeicherte digitale Schlüssel ein Schlüssel für eine gültige Betriebssystemkonfiguration ist; Empfangen, von einer mit dem Datenverarbeitungssystem physisch verbundenen Benutzerschnittstelle, eines Signals, das die empfangene Anforderung bestätigt; Authentifizieren, als Reaktion auf das Empfangen des Signals, der Betriebssystemkonfiguration unter Verwendung des digitalen Schlüssels; und Booten, als Reaktion auf das Authentifizieren, der Betriebssystemkonfiguration.
Verfahren nach Anspruch 1, das des Weiteren aufweist: Feststellen, vor dem Empfangen, dass der öffentliche Schlüssel einer Betriebssystemkonfiguration entspricht, die zum Booten auf dem Datenverarbeitungssystem berechtigt ist.
Verfahren nach Anspruch 1, das des Weiteren aufweist: Verschieben, als Reaktion auf das Empfangen des Bestätigungssignals, des digitalen Schlüssels in einen geschützten Hauptspeicher des Datenverarbeitungssystems, wobei der geschützte Hauptspeicher nur beschreibbar ist, solange sich das Datenverarbeitungssystem in einem Preboot-Zustand befindet.
Verfahren nach Anspruch 3, wobei der geschützte Hauptspeicher nur durch eine Software-Anwendung beschreibbar ist, bei der die Integrität des Ausführungscodes durch eine Hardwarekomponente des Datenverarbeitungssystems authentifiziert wird.
Verfahren nach Anspruch 3, wobei das Authentifizieren das Abrufen des digitalen Schlüssels aus dem geschützten Hauptspeicher und das Verwenden des abgerufenen digitalen Schlüssels beinhaltet, um eine Signatur der Betriebssystemkonfiguration zu überprüfen.
Verfahren nach Anspruch 1, wobei die Betriebssystemkonfiguration aufweist: einen Betriebssystemkernel; und einen Satz von Parametern, um eine Zugriffssteuerungsrichtlinie des Betriebssystemkernels durchzusetzen.
Verfahren nach Anspruch 6, wobei der Satz von Parametern in einen ausführbaren Code des Betriebssystemkernels kompiliert wird.
Verfahren nach Anspruch 1, wobei: die Betriebssystemkonfiguration mit einem privaten Schlüssel eines Public-Private-Key-Paares digital signiert wird, und der digitale Schlüssel ein öffentlicher Schlüssel des Public-Private-Key-Paares ist.
System, das aufweist: ein Benutzerschnittstellenterminal; ein Datenverarbeitungssystem, das mit dem Benutzerschnittstellenterminal physisch verbunden ist und einen Hauptspeicher und einen Prozessor hat; und ein durch einen Computer lesbares Speichermedium des Datenverarbeitungssystems, das über damit realisierte Programminstruktionen verfügt, wobei die Programminstruktionen durch den Prozessor ausführbar sind, um das System zu veranlassen: in einem gebooteten Zustand des Datenverarbeitungssystems eine Anforderung für das Laden einer Betriebssystemkonfiguration zu empfangen; automatisch als Reaktion auf das Empfangen der Anforderung einen digitalen Schlüssel zu speichern, um die Betriebssystemkonfiguration zu authentifizieren; das Datenverarbeitungssystem neu zu starten; als Reaktion auf das Neustarten des Datenverarbeitungssystems und während sich das Datenverarbeitungssystem in einem Preboot-Zustand befindet: zu validieren, dass der gespeicherte digitale Schlüssel ein Schlüssel für eine gültige Betriebssystemkonfiguration ist; von einer mit dem Datenverarbeitungssystem physisch verbundenen Benutzerschnittstelle ein Signal zu empfangen, das die empfangene Anforderung bestätigt; als Reaktion auf das Empfangen des Signals die Betriebssystemkonfiguration unter Verwendung des digitalen Schlüssels zu authentifizieren; und als Reaktion auf das Authentifizieren die Betriebssystemkonfiguration zu booten.
System nach Anspruch 9, wobei die Programminstruktionen des Weiteren durch den Prozessor ausführbar sind, um das System zu veranlassen: festzustellen, vor dem Empfangen, dass der öffentliche Schlüssel einer Betriebssystemkonfiguration entspricht, die zum Booten auf dem Datenverarbeitungssystem berechtigt ist.
System nach Anspruch 9, wobei die Programminstruktionen des Weiteren durch den Prozessor ausführbar sind, um das System zu veranlassen: den digitalen Schlüssel, als Reaktion auf das Empfangen des Bestätigungssignals, in einen geschützten Hauptspeicher des Datenverarbeitungssystems zu verschieben, wobei der geschützte Hauptspeicher nur beschreibbar ist, solange sich das Datenverarbeitungssystem in einem Preboot-Zustand befindet.
System nach Anspruch 11, wobei der geschützte Hauptspeicher nur durch eine Software-Anwendung beschreibbar ist, bei der die Integrität des Ausführungscodes durch eine Hardwarekomponente des Datenverarbeitungssystems authentifiziert wird.
System nach Anspruch 11, wobei die Programminstruktionen des Weiteren durch den Prozessor ausführbar sind, um das System zu veranlassen, den digitalen Schlüssel aus dem geschützten Hauptspeicher abzurufen und den abgerufenen digitalen Schlüssel zum Überprüfen einer digitalen Signatur der Betriebssystemkonfiguration zu verwenden.
System nach Anspruch 9, wobei die Betriebssystemkonfiguration aufweist: einen Betriebssystemkernel; und einen Satz von Parametern, um eine Zugriffssteuerungsrichtlinie des Betriebssystemkernels durchzusetzen.
System nach Anspruch 14, wobei der Satz von Parametern in einen ausführbaren Code des Betriebssystemkernels kompiliert wird.
System nach Anspruch 9, wobei: die Betriebssystemkonfiguration mit einem privaten Schlüssel eines Public-Private-Key-Paares digital signiert wird, und der digitale Schlüssel ein öffentlicher Schlüssel des Public-Private-Key-Paares ist.
Computerprogrammprodukt zum sicheren Booten eines Datenverarbeitungssystems, wobei das Computerprogrammprodukt ein durch einen Computer lesbares Speichermedium enthält, das über damit realisierte Programminstruktionen verfügt, wobei das durch einen Computer lesbare Speichermedium kein flüchtiges Signal an sich ist, wobei die Programminstruktionen durch einen Prozessor ausführbar sind, um das Datenverarbeitungssystem zu veranlassen, ein Verfahren auszuführen, das aufweist: Empfangen, in einem gebooteten Zustand des Datenverarbeitungssystems, einer Anforderung für das Laden einer Betriebssystemkonfiguration; Speichern, automatisch als Reaktion auf das Empfangen der Anforderung, eines digitalen Schlüssels, um die Betriebssystemkonfiguration zu authentifizieren; Neustarten des Datenverarbeitungssystems; als Reaktion auf das Neustarten des Datenverarbeitungssystems und während sich das Datenverarbeitungssystem in einem Preboot-Zustand befindet: Validieren, dass der gespeicherte digitale Schlüssel ein Schlüssel für eine gültige Betriebssystemkonfiguration ist; Empfangen, von einer mit dem Datenverarbeitungssystem physisch verbundenen Benutzerschnittstelle, eines Signals, das die empfangene Anforderung bestätigt; Authentifizieren, als Reaktion auf das Empfangen des Signals, der Betriebssystemkonfiguration unter Verwendung des digitalen Schlüssels; und Booten, als Reaktion auf das Authentifizieren, der Betriebssystemkonfiguration.
Computerprogramm nach Anspruch 17, wobei das Verfahren des Weiteren aufweist: Feststellen, vor dem Empfangen, dass der öffentliche Schlüssel einer Betriebssystemkonfiguration entspricht, die zum Booten auf dem Datenverarbeitungssystem berechtigt ist.
Computerprogramm nach Anspruch 17, wobei das Verfahren des Weiteren aufweist: Verschieben, als Reaktion auf das Empfangen des Bestätigungssignals, des digitalen Schlüssels in einen geschützten Hauptspeicher des Datenverarbeitungssystems, wobei der geschützte Hauptspeicher nur beschreibbar ist, solange sich das Datenverarbeitungssystem in einem Preboot-Zustand befindet.
Computerprogrammprodukt nach Anspruch 17, wobei die Betriebssystemkonfiguration aufweist: einen Betriebssystemkernel; und einen Satz von Parametern, um eine Zugriffssteuerungsrichtlinie des Betriebssystemkernels durchzusetzen.
Verfahren, das aufweist: Empfangen, von einer Benutzeranwendung, die unter einer ersten Betriebssystemkonfiguration auf einer Datenverarbeitungseinheit ausgeführt wird, einer Anforderung für das Ausführen einer zweiten Betriebssystemkonfiguration eines Satzes von Betriebssystemkonfigurationen, wobei die zweite Betriebssystemkonfiguration: mit einem privaten Schlüssel eines Public-Private-Key-Paares signiert wird, und mindestens einen Betriebssystemkernel aufweist, der mit einem Satz von Parametern kompiliert wird, wobei der Satz von Parametern zu einer Zugriffssteuerungsrichtlinie der zweiten Betriebssystemkonfiguration gehört; Speichern, als Reaktion auf das Empfangen der Anforderung, eines öffentlichen Schlüssels, der dem privaten Schlüssel entspricht, in einem nicht flüchtigen Hauptspeicher der Datenverarbeitungseinheit; und Ausführen einer vertrauenswürdigen Anwendung während eines Preboot-Zustands der Datenverarbeitungseinheit, um: zu validieren, dass der gespeicherte digitale Schlüssel ein Schlüssel für eine gültige Betriebssystemkonfiguration ist; von einer lokalen Schnittstelle zu der Datenverarbeitungseinheit ein Signal zu empfangen, das die empfangene Anforderung bestätigt; den öffentlichen Schlüssel in einen geschützten Hauptspeicher zu verschieben, wenn das Signal die Anforderung bestätigt, und ein Bootladeprogramm auszuführen, das Zugriff auf den geschützten Hauptspeicher hat, um das zweite Betriebssystem unter Verwendung des in dem geschützten Hauptspeicher gespeicherten öffentlichen Schlüssels zu authentifizieren und die zweite Betriebssystemkonfiguration als Reaktion auf das Authentifizieren zu booten.
Verfahren nach Anspruch 21, wobei der Satz von Parametern Software-Module bestimmt, die unter der zweiten Betriebssystemkonfiguration ladbar sind.
Verfahren nach Anspruch 21, wobei der Satz von Parametern die Durchsetzung der Zugriffssteuerungsrichtlinie bestimmt.
Verfahren nach Anspruch 21, wobei der geschützte Hauptspeicher nur durch einen Satz von Anwendungen beschreibbar ist, darunter die vertrauenswürdige Anwendung, bei denen die Integrität des ausführbaren Codes durch eine Hardwarekomponente des Datenverarbeitungssystems authentifiziert wird.
System, das aufweist: ein Benutzerschnittstellenterminal; ein Datenverarbeitungssystem, das mit dem Benutzerschnittstellenterminal physisch verbunden ist und einen Hauptspeicher und einen Prozessor hat; und ein durch einen Computer lesbares Speichermedium des einen oder der mehreren Datenverarbeitungsknoten, das über damit realisierte Programminstruktionen verfügt, wobei die Programminstruktionen durch den Prozessor ausführbar sind, um das System zu veranlassen: von einer Benutzeranwendung, die unter einer ersten Betriebssystemkonfiguration auf einer Datenverarbeitungseinheit ausgeführt wird, eine Anforderung für das Ausführen einer zweiten Betriebssystemkonfiguration eines Satzes von Betriebssystemkonfigurationen zu empfangen, wobei die zweite Betriebssystemkonfiguration: mit einem privaten Schlüssel eines Public-Private-Key-Paares signiert wird, und mindestens einen Betriebssystemkernel aufweist, der mit einem Satz von Parametern kompiliert wird, wobei der Satz von Parametern zu einer Zugriffssteuerungsrichtlinie der zweiten Betriebssystemkonfiguration gehört; als Reaktion auf das Empfangen der Anforderung einen öffentlichen Schlüssel, der dem privaten Schlüssel entspricht, in einem nicht flüchtigen Hauptspeicher der Datenverarbeitungseinheit speichert; und eine vertrauenswürdige Anwendung während eines Preboot-Zustands der Datenverarbeitungseinheit ausführt, um: zu validieren, dass der gespeicherte digitale Schlüssel ein Schlüssel für eine gültige Betriebssystemkonfiguration ist; von dem Benutzerschnittstellenterminal ein Signal zu empfangen, das die empfangene Anforderung bestätigt; den öffentlichen Schlüssel in einen geschützten Hauptspeicher zu verschieben, wenn das Signal die Anforderung bestätigt, und ein Bootladeprogramm auszuführen, das Zugriff auf den geschützten Hauptspeicher hat, um das zweite Betriebssystem unter Verwendung des in dem geschützten Hauptspeicher gespeicherten öffentlichen Schlüssels zu authentifizieren und die zweite Betriebssystemkonfiguration als Reaktion auf das Authentifizieren zu booten.