DE102021101891A1

DE102021101891A1 - Bestimmen , ob eine aktion zur berechnung ausgeführt werden soll gerät basierend auf der analyse von endorsement-informationen eines sicherheits-coprozessors

Info

Publication number: DE102021101891A1
Application number: DE102021101891.9A
Authority: DE
Inventors: Luis Luciani; Darrell R. Haskell
Original assignee: Hewlett Packard Enterprise Development LP
Current assignee: Hewlett Packard Enterprise Development LP
Priority date: 2020-01-29
Filing date: 2021-01-28
Publication date: 2021-07-29
Also published as: US20210232688A1; CN113190880A; US11580225B2; CN113190880B

Abstract

Die hier offengelegten Beispiele beziehen sich auf ein Computergerät, das eine zentrale Verarbeitungseinheit, einen von der zentralen Verarbeitungseinheit getrennten Verwaltungscontroller und einen Sicherheits-Coprozessor enthält. Der Management-Controller wird über eine Hilfsstromschiene mit Strom versorgt, die den Management-Controller mit Strom versorgt, während sich das Computergerät in einem Hilfsstromzustand befindet. Der Sicherheits-Coprozessor enthält eindeutige Gerätedaten. Der Management-Controller empfängt die eindeutigen Gerätedaten und speichert eine Darstellung an einem sicheren Ort. Zu einem späteren Zeitpunkt empfängt der Management-Controller Befürwortungsinformationen von einem erwarteten Standort des Sicherheits-Coprozessors. Der Management-Controller bestimmt auf der Grundlage einer Analyse der Vermerkinformationen und der gespeicherten Darstellung der eindeutigen Gerätedaten, ob eine Aktion auf dem Computergerät durchgeführt werden soll.

Description

HINTERGRUND
Service-Provider und Hersteller stehen vor der Herausforderung, den Verbrauchern Qualität und Wert zu liefern, z. B. durch die Bereitstellung eines sicheren Rechensystems. Ein Rechenzentrum ist eine Einrichtung, in der Computernetzwerke, Computersysteme und zugehörige Komponenten, wie Telekommunikations- und Speichersysteme, untergebracht sind. Die Ausrüstung in einem Rechenzentrum kann in Form von Servern vorliegen, die in Rack-Schränken montiert sind.
Figurenliste
Die folgende detaillierte Beschreibung bezieht sich auf die Zeichnungen, wobei:

1 und 2 sind Blockdiagramme von Rechengeräten, gemäß verschiedener Beispiele;
3 ist ein Flussdiagramm eines Verfahrens zur Durchführung einer Aktion auf der Grundlage einer Analyse von Vermerksinformationen und einer gespeicherten Darstellung von geräteeigenen Daten, die für einen Sicherheits-Coprozessor einzigartig sind, gemäß einem Beispiel;
4 ist ein Blockdiagramm eines Management-Controllers, der in der Lage ist, eine Aktion auf der Grundlage einer Analyse von Befürwortungsinformationen und einer gespeicherten Darstellung von eindeutigen Gerätedaten durchzuführen, die für einen Sicherheits-Coprozessor eindeutig sind, gemäß einem Beispiel;
5 ist ein Blockdiagramm eines Computergeräts, das in der Lage ist, eine Aktion basierend auf einer Analyse von Befürwortungsinformationen und einer gespeicherten Darstellung von eindeutigen Gerätedaten, die für einen Sicherheits-Coprozessor eindeutig sind, gemäß einem Beispiel durchzuführen.

In den Zeichnungen können identische Referenznummern ähnliche, aber nicht notwendigerweise identische Elemente bezeichnen. Eine Indexzahl „N“, die an einige der Bezugszahlen angehängt ist, ist lediglich als Hinweis auf eine Vielzahl zu verstehen und muss nicht unbedingt für jede Bezugszahl mit einer solchen Indexzahl „N“ dieselbe Menge darstellen. Darüber hinaus kann die Verwendung einer Bezugszahl ohne Indexnummer, auf die an anderer Stelle mit einer Indexnummer Bezug genommen wird, hier eine allgemeine Bezugnahme auf die entsprechenden Pluralelemente, kollektiv oder einzeln, darstellen. In einem anderen Beispiel kann anstelle der Indexnummer N eine Indexnummer von „I“, „M“ usw. verwendet werden.
In den Zeichnungen bezeichnen identische Referenznummern ähnliche, aber nicht notwendigerweise identische, Elemente. Die Abbildungen sind nicht notwendigerweise maßstabsgetreu, und die Größe einiger Teile kann zur besseren Veranschaulichung des gezeigten Beispiels übertrieben sein. Darüber hinaus bieten die Zeichnungen Beispiele und/oder Implementierungen, die mit der Beschreibung übereinstimmen; die Beschreibung ist jedoch nicht auf die in den Zeichnungen dargestellten Beispiele und/oder Implementierungen beschränkt.
DETAILLIERTE BESCHREIBUNG
In der vorliegenden Offenlegung schließt die Verwendung des Begriffs „ein“, „ein“ oder „die“ auch die Pluralformen ein, sofern aus dem Kontext nicht eindeutig etwas anderes hervorgeht. Auch der Begriff „beinhaltet“, „einschließlich“, „umfasst“, „mit“, „haben“ oder „mit“, wenn er in dieser Offenbarung verwendet wird, spezifiziert das Vorhandensein der angegebenen Elemente, schließt aber das Vorhandensein oder die Zugabe anderer Elemente nicht aus.
Um einen zuverlässigen Betrieb einer Plattform für einen Endbenutzer zu gewährleisten, muss ein Plattformhersteller dem Endbenutzer ermöglichen, die Authentizität der Plattform zu überprüfen. Ein Authentifizierungsmodul oder ein Sicherheits-Coprozessor, der den von der Trusted Computing Group konzipierten Kriterien des Trusted Platform Module (TPM) entspricht, ist eine beispielhafte Sicherheitslösung zur Erkennung der Authentizität einer Plattform. Das TPM kann verwendet werden, um zu erkennen, ob ein Gerät der Plattform gefälscht ist, z. B. von einer nicht autorisierten Partei oder auf eine nicht autorisierte Weise hergestellt wurde. Das TPM kann verwendet werden, um jedes Gerät der Plattform zu authentifizieren, z. B. um zu prüfen, ob das Gerät von einer autorisierten Partei in einer autorisierten Weise hergestellt wurde. Während der Herstellung eines Geräts kann der Gerätehersteller eine signierte Herstelleridentität im Gerät instanziieren. Die signierten Informationen werden im TPM gespeichert. Später können die signierten Informationen aus dem TPM abgerufen werden, um die Authentizität des Geräts durch Überprüfung der Gültigkeit der Herstelleridentität zu verifizieren. Das TPM kann als Sicherheits-Coprozessor-Chip implementiert sein, der den Spezifikationen der Trusted Computing Group entspricht.
In einigen Beispielen kann der Sicherheits-Coprozessor (z. B. ein TPM) geräteeigene Daten wie einen privaten Bestätigungsschlüssel enthalten. In einigen Beispielen ist ein privater Endorsement-Schlüssel ein kryptografischer Schlüssel, der außerhalb des Sicherheits-Coprozessors nicht sichtbar ist. Der Sicherheits-Coprozessor kann den Endorsement-Schlüssel für Verschlüsselungszwecke verwenden. Der Besitz eines privaten Endorsement-Schlüssels kann indirekt nachgewiesen werden, indem er zur Entschlüsselung eines Wertes verwendet wird, der mit einem öffentlichen Endorsement-Schlüssel verschlüsselt wurde. In einigen Beispielen kann ein öffentlicher Endorsement-Schlüssel vom Sicherheits-Coprozessor als öffentliches Zertifikat bereitgestellt werden. In einigen Beispielen kann der öffentliche Bestätigungsschlüssel und/oder das öffentliche Zertifikat als geräteeigene Daten betrachtet werden, die nur für den Sicherheits-Coprozessor gelten. Ferner kann das öffentliche Zertifikat in einigen Beispielen ein Plattformzertifikat sein, das bescheinigt, dass eine bestimmte Plattform einen eindeutigen Sicherheits-Koprozessor und bestimmte Plattformkonfigurationselemente enthält.
Ein möglicher Angriffsvektor auf den Sicherheits-Coprozessor, derzum Schutz eines Computergeräts verwendet wird, besteht jedoch darin, den Sicherheits-Coprozessor durch einen zu ersetzen, der mit einem Angreifer bekannten Informationen bestückt ist. Zum Schutz vor einem solchen Angriffsvektor beziehen sich die hierin offengelegten Beispiele auf eine Verwaltungssteuerung, die zu einem ersten Zeitpunkt (z. B. während der Herstellung oder Bereitstellung) eindeutige Gerätedaten (z. B. ein öffentliches Zertifikat) von dem Sicherheits-Coprozessor anfordert und empfängt und zu einem späteren Zeitpunkt als Reaktion auf die Verwendung der eindeutigen Gerätedaten eine Aktion durchführt. In einem Beispiel kann der Management-Controller zu einem späteren Zeitpunkt als Reaktion auf eine Analyse eines installierten Sicherheits-Coprozessors unter Verwendung der eindeutigen Daten bestimmen, ob das Computergerät hochgefahren werden soll. Dementsprechend kann der Verwaltungscontroller in einigen Beispielen bei jedem Hochfahren auf der Grundlage der vom Sicherheits-Coprozessor empfangenen eindeutigen Gerätedaten bestimmen, ob das Gerät hochgefahren werden soll.
In einigen Beispielen ist ein TPM ein Sicherheits-Coprozessor, mit dem man nur über einen Input/Output (1/0)-Puffer interagieren kann, der eine wohldefinierte Formatierung verwendet. Das Verhalten des TPMs basiert ausschließlich auf der (Reihe von) Befehl(en), die es erhält. Somit basiert jede Garantie, die man vom TPM erhalten kann, auf den erteilten Befehlen. Prototypische Beispiele sind die Mechanismen „Measured Boot“ und „Remote Attestation“, die auf der Verwendung der TPM Platform Configuration Registers aufbauen, um den Zustand einer Plattform aus der Ferne zu verifizieren. PCRs werden durch Hashing ihres vorherigen Wertes mit den zu speichernden Informationen aktualisiert. Im gemessenen Boot-Fall werden PCRs verwendet, um Firmware- und Software-Integritätswerte zu speichern. Die Verwendung von PCRs verhindert das Entfernen von Firmware- oder Software-Ausführungsereignissen. In den hier beschriebenen Beispielen kann eine Firmware- oder Softwarekomponente ihr Messereignis nicht aus den PCRs löschen. Außerdem kann ein Hersteller den erwarteten PCR-Wert für ein Gerät oder eine Plattform vorhersagen, da der Hersteller weiß, welche Firmware oder Software ausgeführt werden sollte. Wie hier verwendet, kann Firmware mehrere Komponenten umfassen, die programmiert werden können, z. B. einen Field Programmable Gate Array-Bitstream, ein Serial Peripheral Interface (SPI)-Flash, einen elektronisch löschbaren programmierbaren Festwertspeicher (EEPROM) usw. in der Plattform. Nicht verwendete programmierbare Logik kann ebenfalls gemessen werden (und kann ein bekannter Wert sein, z. B. 0 oder ein sich wiederholendes Muster).
1 und 2 sind Blockdiagramme von Rechengeräten gemäß verschiedener Beispiele. Bezug nehmend auf die Zeichnungen, sind 1 und 2 sind Blockdiagramme von Rechenvorrichtungen, die in der Lage sind, eine Aktion basierend auf einer Analyse von Vermerksinformationen eines Sicherheits-Coprozessors durchzuführen. Die Systeme 100, 200 können eine Vorrichtung umfassen, die Komponenten enthält, die verwendet werden können, um sicherzustellen, dass ein Sicherheits-Coprozessor, der bei der Herstellung installiert wird, der Sicherheits-Coprozessor ist, der beim Booten der Rechenvorrichtung verwendet wird.
1 enthält einen Management-Controller 110, der über einen Multiplexer 120 mit einem Sicherheits-Coprozessor 130 verbunden ist. Der Sicherheits-Coprozessor 130 kann auch über den Multiplexer 120 mit einem Controller-Hub 140 verbunden sein.
2 enthält ferner einen weiteren Multiplexer 222, um dem Management-Controller 110 die Kommunikation mit einer Mehrfachkomponente 270, einem Firmware-Speicher 250, einem programmierbaren Logikbaustein (PLD) 260, einer Verarbeitungseinheit 280, einem Speicher 282 und einer Leistungssteuerung 290 zu ermöglichen.
In einigen Beispielen kann der Management-Controller 110 verwendet werden, um Dienste für das Computersystem 100, 200 zu implementieren. Der Management-Controller 110 kann mit einem von der Verarbeitungseinheit 280 getrennten Prozessor implementiert werden, der zur Ausführung eines High-Level-Betriebssystems verwendet wird. Management-Controller, wie z. B. Baseboard-Management-Controller (BMCs), können sogenannte „Lights-Out“-Funktionalität für Computergeräte bereitstellen. Die „Lights-Out“-Funktionalität kann es einem Benutzer, wie z. B. einem Systemadministrator, ermöglichen, Verwaltungsoperationen auf dem Computersystem 100, 200 durchzuführen, selbst wenn ein Betriebssystem nicht installiert oder nicht funktionsfähig auf dem Computergerät ist. Darüber hinaus kann in einem Beispiel der Management-Controller 110 mit Hilfsenergie betrieben werden, so dass das Computersystem 100, 200 nicht in einen Einschaltzustand gebracht werden muss, in dem die Kontrolle über das Computersystem 100, 200 nach dem Hochfahren an ein Betriebssystem übergeben wird. Als Beispiele kann der Management-Controller 110 sogenannte „Out-of-Band“-Dienste bereitstellen, wie z. B. Remote-Konsolenzugriff, Remote-Neustart- und Energieverwaltungsfunktionen, Überwachung des Systemzustands, Zugriff auf Systemprotokolle und ähnliches. Wie hierin verwendet, verfügt ein Management-Controller 110 über Verwaltungsfunktionen für Teilsysteme eines Management-Controllers 110 und ist getrennt von einem Prozessor oder Verarbeitungselement, das ein Hauptbetriebssystem eines Computergeräts (z. B. eines Servers oder einer Reihe von Servern) ausführt.
Wie bereits erwähnt, kann der Verwaltungscontroller 110 in einigen Fällen eine Lights-Out-Verwaltung des Computersystems 100, 200 ermöglichen, die einen Fernverwaltungszugriff (z. B. Zugriff auf die Systemkonsole) unabhängig davon ermöglicht, ob das Computersystem 100, 200 eingeschaltet ist, ob die Hardware eines primären Netzwerksubsystems funktioniert oder ob ein Betriebssystem in Betrieb oder sogar installiert ist. Der Management-Controller 110 kann eine Schnittstelle, wie z. B. eine Netzwerkschnittstelle, und/oder eine serielle Schnittstelle umfassen, die ein Administrator verwenden kann, um aus der Ferne mit dem Management-Controller 110 zu kommunizieren. Wie hierin verwendet, ist ein „Out-of-Band“-Dienst ein Dienst, der von der Verwaltungssteuerung 110 über einen dedizierten Verwaltungskanal (z. B. die Netzwerkschnittstelle oder die serielle Schnittstelle) bereitgestellt wird und unabhängig davon verfügbar ist, ob sich das Computersystem 100, 200 im eingeschalteten Zustand befindet.
In einigen Beispielen kann ein Management-Controller 110 als Teil eines Gehäuses enthalten sein. In anderen Beispielen kann ein Management-Controller 110 in einem oder mehreren der Server enthalten sein (z. B. als Teil des Management-Subsystems des Servers) oder über eine Schnittstelle angeschlossen sein (z. B. eine periphere Schnittstelle). In einigen Beispielen können Sensoren, die mit dem Management-Controller 110 verbunden sind, interne physikalische Variablen wie Luftfeuchtigkeit, Temperatur, Stromversorgungsspannung, Kommunikationsparameter, Lüftergeschwindigkeiten, Betriebssystemfunktionen oder ähnliches messen. Der Management-Controller 110 kann auch in der Lage sein, das Gerät neu zu starten oder den Stromkreislauf zu unterbrechen. Wie bereits erwähnt, ermöglicht der Management-Controller 110 die Fernverwaltung des Geräts. So können über den Management-Controller 110 Benachrichtigungen an eine zentrale Station erfolgen, und Passwörter oder andere Benutzereingaben können über den Management-Controller 110 implementiert werden.
Eine Firmware-Engine kann mithilfe von Befehlen implementiert werden, die von einem Prozessor und/oder einer Logik ausgeführt werden können. In einigen Beispielen kann die Firmware-Engine als Plattform-Firmware implementiert sein. Die Plattform-Firmware kann eine Schnittstelle, wie z. B. ein Basic Input/Output System (BIOS) oder Unified Extensible Firmware Interface (UEFI), enthalten, damit sie mit ihr verbunden werden kann. Die Plattform-Firmware kann sich in einem Adressraum befinden, in dem die Verarbeitungseinheit 280 (z. B. die CPU) für das Computersystem 100, 200 bootet. In einigen Beispielen kann die Plattform-Firmware für einen Einschalt-Selbsttest für das Computersystem 100, 200 verantwortlich sein. In anderen Beispielen kann die Plattform-Firmware für den Boot-Prozess verantwortlich sein und dafür, welches Betriebssystem, wenn überhaupt, auf das Computersystem 100, 200 zu laden ist. Des Weiteren kann die Plattform-Firmware in der Lage sein, verschiedene Komponenten des Computersystems 100, 200 zu initialisieren, wie z. B. Peripheriegeräte, Speichergeräte 282, Speicher-Controller-Einstellungen, Speicher-Controller-Einstellungen, Busgeschwindigkeiten, Grafikkarteninformationen usw. In einigen Beispielen kann die Plattform-Firmware auch in der Lage sein, verschiedene Low-Level-Funktionen durchzuführen, während das Computersystem 100, 200 ausgeführt wird. Darüber hinaus kann die Plattform-Firmware in einigen Beispielen in der Lage sein, mit einem Betriebssystem auf höherer Ebene zu kommunizieren, das auf einer CPU ausgeführt wird, z. B. über eine erweiterte Konfigurations- und Energieschnittstelle (ACPI). Die Firmware kann in einem Firmware-Speicher 250 gespeichert sein. In einigen Beispielen kann der Management-Controller 110 eine Validierung für sich selbst, den Sicherheits-Coprozessor, die Komponente, den Firmware-Speicher usw. durchführen.
Eine oder mehrere der Komponenten, Motoren, Speicher und Steuerungen können mit einer anwendungsspezifischen integrierten Schaltung (ASIC) implementiert werden. Beispiele für ASICs sind Steuerungen, programmierbare Logikbausteine 260 wie Field Programmable Gate Arrays (FPGAs), komplexe programmierbare Logikbausteine (CPLD) usw.
Wie hierin verwendet, kann ein „Root-of-Trust-Gerät“ oder RoT-Gerät ein Gerät sein, das sich in einer erwarteten Weise verhält, da ein Fehlverhalten des RoT-Geräts möglicherweise nicht erkannt werden kann. Mit anderen Worten, das RoT-Gerät kann inhärent vertrauenswürdige Software, Hardware oder eine Kombination davon sein. Ein RoT-Gerät kann Compute Engines enthalten. Bei der Compute Engine kann es sich um Software handeln, die mit Hardware im RoT-Gerät arbeitet, um Hardware des RoT-Geräts oder um eine Kombination davon. Zum Beispiel kann ein RoT-Gerät eine Root of Trust for Storage (RTS) enthalten. Der RTS kann eine Rechenmaschine sein, die in der Lage ist, eine genaue Zusammenfassung von Werten zu erhalten. Zum Beispiel kann das RoT ein TPM sein. In solchen Beispielen kann das TPM eine PCR (oder eine Vielzahl von PCRs) enthalten. Ferner kann das RTS ein PCR (oder eine Vielzahl von PCRs) sein. In einem anderen Beispiel kann das RoT eine Root of Trust for Reporting (RTR) enthalten. Der RTR kann eine Compute Engine sein, die in der Lage ist, angeforderte Informationen an ein anforderndes Gerät zu senden. Die Informationen können die Inhalte in einem Register des RoT (oder die Inhalte des RTS) und vom Anforderer spezifizierte Informationen enthalten. Der RoT kann weitere, hier nicht beschriebene Compute-Engines enthalten, z. B. eine Compute-Engine zur Messung bestimmter Werte oder eine Compute-Engine zur Authentifizierung.
Wie hierin verwendet, kann ein „vertrauenswürdiges Plattformmodul“ oder „TPM“ ein integrierter Schaltkreis sein, der in eine Hauptplatine eines Computersystems eingebaut oder anderweitig mit ihr verbunden ist. Das TPM kann fälschungssicher oder manipulationssicher sein. Das TPM kann für Dienste auf dem Rechnersystem verwendet werden. Die Dienste können Geräteidentifikation, Authentifizierung, Verschlüsselung, Messung, Bestimmung der Geräteintegrität, sichere Erzeugung von kryptografischen Schlüsseln, Fernbescheinigung und versiegelte Speicherung umfassen. Das TPM kann Plattformkonfigurationsregister (PCRs) enthalten. Die PCRs können sicherheitsrelevante Metriken speichern.
In einem Beispiel kann der Management-Controller 110 mit einem sicheren Speicher, einem Hardware-Root of Trust oder anderen Sicherheitsmerkmalen verbunden sein. In einem Beispiel werden beim ersten Booten des Computersystems 100, 200 in ein Service-Betriebssystem (OS) oder eine Provisioning-Engine in einer Fabrik ein eindeutiger privater und öffentlicher Schlüssel generiert und auf das System „geklebt“, indem sie im Speicher des Management-Controllers gespeichert werden. Dieser Speicher kann persistent und nicht austauschbar sein. Der Management-Controller 110 kann einen indirekten Zugriff auf einen Schlüssel über eine Anwendungsprogrammierschnittstelle ermöglichen. Die Werte können in ein Write-Only-Register auf demselben Application Specific Integrated Circuit (ASIC) wie der Management-Controller 110 geschrieben werden. Das Write-Only-Register kann z. B. mit Fuses implementiert werden. In einem Beispiel wird der private Schlüssel durch Ausführen eines Algorithmus unter Verwendung von Zufallsquellen erzeugt und programmiert. In einem anderen Beispiel ist der öffentliche Schlüssel ein kryptografischer Hash des privaten Schlüssels. In einigen Beispielen ist nach der Programmierung die Möglichkeit, die Register zu ändern, deaktiviert (z. B. durch Trennen einer schmelzbaren Verbindung, z. B. auf einer Schreibleitung). In einigen Beispielen kann der Verwaltungscontroller 110 verwendet werden, um sicherzustellen, dass die Firmware des Computersystems 100, 200 sicher ist (z. B. indem sichergestellt wird, dass die Firmware nicht aktualisiert wird, es sei denn, sie wird mit einem öffentlichen Schlüssel signiert oder verschlüsselt, den der private Schlüssel des Verwaltungscontrollers 110 verifizieren oder entschlüsseln kann. In einigen Beispielen kann der Verwaltungscontroller 110 außerdem verhindern, dass das Computersystem 100, 200 mit kompromittierter Firmware startet.
Darüber hinaus kann der Verwaltungscontroller 110 in einigen Beispielen auch ein Schlüsselverzeichnis enthalten. Wie hierin verwendet, ist ein Schlüsselspeicher ein Speicher, der mindestens einen privaten Schlüssel enthält, der verwendet werden kann, um zu verifizieren, dass Informationen durch einen öffentlichen Schlüssel signiert wurden. In einigen Beispielen kann der öffentliche Schlüssel auch in der Schlüsselablage enthalten sein. In einigen Beispielen kann ein privater Schlüssel, der Teil einer Vertrauensbasis ist, als Teil eines Schlüssel-Repositorys betrachtet werden. Ferner können in einigen Beispielen die geräteeigenen Daten im Schlüssel-Repository gespeichert werden.
Eine Systemplatine ist die Hauptleiterplatte, die für das System 100, 200 verwendet wird, und ermöglicht die Kommunikation zwischen vielen der Komponenten des Geräts, z. B. der Verarbeitungseinheit 280, dem Speicher 282, Peripheriegeräten, Busgeräten usw. In einigen Beispielen kann ein Controller-Hub 140 ein I/O-Controller-Hub sein, z. B. eine Southbridge. Der Controller-Hub 140 kann verwendet werden, um die Datenkommunikation zwischen einer CPU und anderen Komponenten der Systemplatine zu verwalten. In einigen Beispielen kann ein Controller-Hub eine direkte Medienschnittstelle zu einem Northbridge-Gerät oder der CPU haben. Des Weiteren kann der Controller-Hub 140 Peripherieunterstützung für das Gerät bereitstellen, z. B. Busverbindungen wie Universal Serial Bus (USB), Peripheral Component Interconnect (PCI), PCI express, PCI extended, serielles AT-Attachment, Audioschaltungen, integriertes Ethernet, erweiterte Host-Controller-Schnittstellen, Kombinationen davon usw.
Ein Prozessor, wie z. B. eine Zentraleinheit (CPU) 280 oder ein Mikroprozessor, der zum Abrufen und Ausführen von Befehlen und/oder elektronischen Schaltungen geeignet ist, kann zur Ausführung von Befehlen konfiguriert werden. In bestimmten Szenarien können Anweisungen und/oder andere Informationen, wie z. B. Betriebssystemanweisungen und Daten, im Speicher 282 oder einem anderen Speicher enthalten sein. Eingabe-/Ausgabeschnittstellen können zusätzlich durch das Rechensystem 100, 200 bereitgestellt werden. Beispielsweise können Eingabegeräte, wie eine Tastatur, ein Sensor, eine Berührungsschnittstelle, eine Maus, ein Mikrofon usw. verwendet werden, um Eingaben aus der Umgebung des Computersystems zu empfangen. Außerdem kann ein Ausgabegerät, wie z. B. ein Display, verwendet werden, um dem Benutzer Informationen zu präsentieren. Beispiele für Ausgabegeräte sind Lautsprecher, Anzeigegeräte, Verstärker usw. Darüber hinaus können in bestimmten Beispielen einige Komponenten verwendet werden, um die Funktionalität anderer hier beschriebener Komponenten zu implementieren. Eingabe-/Ausgabegeräte wie Kommunikationsgeräte, z. B. Netzwerkkommunikationsgeräte oder drahtlose Geräte, können ebenfalls als Geräte betrachtet werden, die die Eingabe-/Ausgabeschnittstellen verwenden können.
Wie oben erwähnt, kann der Management-Controller 110 von der Verarbeitungseinheit 280 getrennt sein. Außerdem kann der Management-Controller 110 eine Vertrauensbasis (Root of Trust) enthalten, wie oben beschrieben. In einem Beispiel wird der Management-Controller 110 über eine Hilfsstromschiene mit Strom versorgt. Die Hilfsspannungsschiene kann auch für die Versorgung anderer Komponenten verwendet werden, z. B. für ein PLD 260, Multiplexer 120, 222, usw. Der Sicherheits-Coprozessor 130 kann geräteeigene Daten wie oben beschrieben enthalten.
In einem Beispiel kann der Verwaltungscontroller 110 zu einem ersten Zeitpunkt, z. B. bei der Herstellung des Computersystems 100, 200, einer Bereitstellungsphase usw., die eindeutigen Gerätedaten empfangen und eine Darstellung der eindeutigen Gerätedaten an einem sicheren Ort speichern. Der Empfang der eindeutigen Gerätedaten kann als Reaktion auf eine Anfrage des Management-Controllers erfolgen. Der sichere Speicher kann ein vertrauenswürdiger Bereich des Management-Controllers 110 sein. In einigen Beispielen kann der sichere Speicher nicht überschrieben werden. In einem Beispiel kann der sichere Speicher einmalig beschreibbare Register enthalten.
In einem Beispiel enthalten die geräteeigenen Daten einen öffentlichen Befürwortungsschlüssel oder ein öffentliches Zertifikat für den Sicherheits-Coprozessor. Jedes hergestellte Gerät kann einen anderen privaten Schlüssel und öffentlichen Schlüssel haben. Der öffentliche Schlüssel oder ein öffentliches Zertifikat kann somit als geräteeigene Daten für den Sicherheits-Koprozessor betrachtet werden. Wie oben erwähnt, sollten die Daten für den Sicherheits-Koprozessor eindeutig sein. Eine Darstellung der eindeutigen Gerätedaten kann in einem Speicher gespeichert werden, z. B. in einem sicheren Speicher, der mit der Verwaltungssteuerung 110 verbunden ist. In einem Beispiel besteht die Darstellung aus den eindeutigen Gerätedaten, die vom Sicherheits-Coprozessor empfangen werden. In einem anderen Beispiel ist die Darstellung ein Hash (z. B. MD5, SHA usw.) der eindeutigen Gerätedaten, ein partieller Hash eines Teils der eindeutigen Gerätedaten, eine Kopie eines Teils der eindeutigen Gerätedaten, eine andere Darstellung der eindeutigen Gerätedaten oder eine Kombination davon.
In ähnlicher Weise kann der Management-Controller 110 Code, Einstellungen usw. von anderen Komponenten messen, wie z. B. Code von ihm selbst, einem PLD, anderen Komponenten, Firmware usw. Die Messung kann später verwendet werden, um zu validieren, dass die erwarteten Werte an den gemessenen Stellen vorhanden sind.
Zu einem späteren Zeitpunkt (z. B. wenn sich das Computersystem an einem Kundenstandort befindet) kann der Verwaltungscontroller 110 eine Validierungssequenz beginnen. Der Management-Controller 110 kann durch eine Vertrauensbasis geschützt werden. Die Validierungssequenz kann damit beginnen, dass der Management Controller 110 validiert, dass sein Startup-Code gültig ist (z. B. durch Messen des Startup-Codes und Vergleichen der Messung mit einem zuvor gemessenen Wert). Der Startup-Code kann dann zusätzliche Teile des Codes messen, die auf dem Management-Controller 110 laufen sollen. In einem Beispiel kann der Management-Controller 110, sobald er seinen Code validiert hat, eine Kette zur Validierung anderer Firmware bilden. Beispielsweise kann der Management-Controller 110 Firmware über eine oder mehrere Messungen des Firmware-Speichers 250, eines PLD 260, des Sicherheits-Coprozessors 130, einer anderen Komponente 270 (z. B. einer Innovation Engine oder Management Engine) usw. validieren.
Wie in 2 dargestellt, kann der Sicherheits-Coprozessor 130 über einen Bus mit dem Controller-Hub 140 oder dem über den Multiplexer 120 gesteuerten Management-Controller 110 gekoppelt werden. Der Bus kann ein serieller Bus sein, z. B. ein SPI-Bus (Serial Peripheral Interface), ein 12C-Bus, ein CAN-Bus (Controller Area Network) usw. Mit dieser Konfiguration kann der Sicherheits-Coprozessor 130 aktiv mit dem Controller-Hub 140 des Systems zusammenarbeiten, aber dennoch vom Management-Controller validiert werden.
In einem Beispiel beinhaltet die Validierungssequenz, dass der Management-Controller 110 den Multiplexer 120 mit einem Steuersignal 224 steuert, um auszuwählen, dass der Sicherheits-Coprozessor 130 mit dem Management-Controller 110 kommuniziert. Die Verwaltungssteuerung 110 kann dann mit dem Sicherheits-Coprozessor 130 kommunizieren. In einem Beispiel kann der Sicherheits-Coprozessor 130 hochfahren, sobald er von der Hilfsenergie versorgt wird. Außerdem kann der Sicherheits-Coprozessor 130 in einigen Beispielen eine kürzere Boot-Zeit haben als der Management-Controller 110.
In einem Beispiel kann die Verwaltungssteuerung 110 einen Startbefehl an den Sicherheits-Coprozessor 130 ausgeben. In einigen Beispielen überträgt der Startbefehl das Eigentum an dem Sicherheits-Coprozessor 130 nicht an die Verwaltungssteuerung 110.
Die Verwaltungssteuerung 110 kann dann Vermerkinformationen anfordern und empfangen. Die Vermerksinformationen können von einem erwarteten Standort des Sicherheits-Coprozessors 130 stammen. Zum Beispiel kann die Anforderung über einen Bus gesendet werden, an dem der Sicherheits-Koprozessor 130 erwartet wird. Wenn sich ein anderer Sicherheits-Koprozessor an dem Ort befindet als der erwartete oder ursprüngliche Sicherheits-Koprozessor, kann eine Aktion durchgeführt werden.
Der bestückte Sicherheits-Coprozessor kann die Vermerksinformationen an den Management-Controller 110 weitergeben. Der Management-Controller 110 kann eine Aktion auf dem Computersystem 100, 200 basierend auf einer Analyse der Vermerksinformationen und der gespeicherten Darstellung der eindeutigen Gerätedaten durchführen.
In einem Beispiel sind die Befürwortungsinformationen ein Schlüssel oder ein Zertifikat und die eindeutigen Gerätedaten ein entsprechender Schlüssel oder ein Zertifikat. Es kann ein Vergleich durchgeführt werden, um zu überprüfen, ob die beiden übereinstimmen.
In einem anderen Beispiel sind die Vermerksinformationen ein Schlüssel oder ein Zertifikat, das die eindeutigen Gerätedaten enthält, und die Darstellung ist ein Hash der eindeutigen Gerätedaten. Die Anerkennungsinformationen können gehasht und verglichen werden, um zu überprüfen, dass der Sicherheits-Coprozessor nicht manipuliert oder ersetzt wurde.
In einem weiteren Beispiel können die Bestätigungsinformationen in Form einer Antwort auf eine Abfrageanforderung des Management-Controllers 110 vorliegen. Zum Beispiel kann die Verwaltungssteuerung 110 Daten bereitstellen, die der Sicherheits-Coprozessor 130 mit einem privaten Schlüssel verschlüsseln oder signieren soll. Die geräteeigenen Daten können Informationen enthalten, die es der Verwaltungssteuerung 110 ermöglichen, die Daten zu entschlüsseln oder die Signatur zu validieren. Bei diesem Austausch kann ein Nonce verwendet werden. Dementsprechend können die Bestätigungsinformationen eine Antwort enthalten, die eine erwartete Antwort auf die Abfrage ist. Die Validierung kann auf der erwarteten Antwort basieren.
In einem Beispiel kann der Verwaltungscontroller 110 basierend auf der Analyse der Vermerkinformationen bestimmen, ob eine Aktion durchgeführt werden soll. In dem Beispiel, in dem die Vermerksinformationen unter Verwendung der eindeutigen Gerätedaten validiert werden, kann die Verwaltungssteuerung 110 die Validierungssequenz fortsetzen. In einigen Beispielen ist die Validierungssequenz Teil eines Boot-Ereignisses. So kann in einem Beispiel die Aktion das Aktivieren des Einschaltens des Computersystems 100, 200 umfassen (z. B. durch direktes oder indirektes Aktivieren eines Stromversorgungs-Steuersignals 290 (z. B. unter Verwendung von PLD 260)). Wie bereits erwähnt, können weitere Validierungen stattfinden, bevor das Stromversorgungs-Steuersignal aktiviert wird. Andere Aktionen, die durchgeführt werden können, umfassen das Protokollieren des Ereignisses und das Senden einer Nachricht über das Ereignis.
In einem anderen Beispiel können die Vermerkinformationen von einem zweiten Sicherheits-Koprozessor empfangen werden, der das Original ersetzt hat. In diesem Szenario werden die Vermerksinformationen nicht validiert und es kann eine Aktion ausgeführt werden. In einem Beispiel kann das Ereignis protokolliert werden. In einem anderen Beispiel kann eine Nachricht an einen Administrator gesendet werden. In einem weiteren Beispiel kann der Management-Controller 110 das Booten des Computersystems 100, 200 verhindern. Dies kann direkt durch die Steuerung eines Stromsignals 290 oder über Zwischenglieder (z. B. unter Verwendung des PLD 260) realisiert werden.
In einem Beispiel, in dem der Management-Controller 110 die Vermerksinformationen validiert, kann der Management-Controller 110 den Multiplexer 120 auswählen, um den Controller-Hub 140 für die Kommunikation mit dem Sicherheits-Coprozessor 130 auszuwählen. Dies kann nach dem Teil der Validierungssequenz erfolgen, der sich auf den Sicherheits-Coprozessor bezieht. In einigen Beispielen kann der Sicherheits-Coprozessor 130 während eines Boot-Prozesses von einem Host-Gerät unter Verwendung des Controller-Hubs 140 in Besitz genommen werden.
In einigen Beispielen kann die Validierungssequenz auch die Validierung anderer Komponenten umfassen, z. B. Komponente 270, Firmware-Speicher 250 und/oder PLD 260. In einem Beispiel kann der Multiplexer 222 verwendet werden, um einen Bus von der Kommunikation mit dem Management-Controller 110 oder dem Controller-Hub 140 zu trennen. Dies kann durch ein Signal vom Management-Controller 110 gesteuert werden, zum Beispiel durch das Signal 224 oder ein separates Signal. Der Management-Controller 110 kann ein Firmware-Image der anderen Komponente als weiteren Teil der Validierungssequenz validieren. Für die Validierung der Komponente können verschiedene Ansätze verwendet werden, z. B. das Behalten eines Hashes eines erwarteten Firmware-Images, Teil-Images und/oder Einstellungen und das Erfassen eines neuen Hashes des aktuellen Firmware-Images, Teil-Images und/oder Einstellungen der Komponente 270. Die Hashes können verglichen werden. In einem Beispiel ist die Validierung des Firmware-Images der Komponente 270 Teil der Validierungssequenz und eine Aktion (z. B. Booten freigeben/verhindern) kann als Reaktion auf das Ergebnis der Validierung durchgeführt werden. In Beispielen, in denen ein Multiplexer verwendet wird, kann das Steuersignal den Pfad in einen Produktionsmoduspfad ändern, in dem die Komponente mit einer anderen Komponente (z. B. dem Controller-Hub 140) während des normalen Betriebs des Computersystems 100, 200 kommunizieren soll.
Mit den hier beschriebenen Ansätzen kann der Management-Controller 110 das Computersystem 100, 200 sicher starten. Der Management-Controller kann seinen anfänglichen Startcode mit einem Root-of-Trust-Ansatz validieren, wie oben beschrieben. Dann kann ein Firmware-Image eines verbleibenden Teils des Management-Controllers 110 unter Verwendung eines Root-of-Trust-Ansatzes validiert werden. Weiterhin können Komponenten, wie das PLD 260 und die Komponente 270, validiert werden. Des Weiteren kann eine Boot-Firmware im Firmware-Speicher 250 gespeichert werden. Die Boot-Firmware kann z. B. ein Plattform-Firmware-Image wie ein Basis-Eingabe-Ausgabe-System oder ein einheitliches erweiterbares Firmware-Schnittstellen-Image enthalten. Die Boot-Firmware kann als Teil einer Startup-Sequenz validiert werden. In einigen Beispielen wird jede Komponente validiert, bevor die Stromversorgung des Computersystems 100, 200 aktiviert wird.
Eine oder mehrere Komponenten eines Rechnersystems können mit einer Engine implementiert werden. Eine Engine kann Hardware und/oder Kombinationen von Hardware und Programmierung enthalten, um die hier beschriebenen Funktionen auszuführen. Darüber hinaus kann eine Funktionalität, die einer bestimmten Engine zugeordnet ist, auch mit einer anderen Engine oder einer Kombination von Engines implementiert werden.
In einigen Beispielen kann ein Verarbeitungselement, z. B. die Verarbeitungseinheit 280, eine oder mehrere Verarbeitungseinheiten (z. B. eine Zentraleinheit (CPU)), ein oder mehrere Mikroprozessoren auf Halbleiterbasis, eine oder mehrere Grafikverarbeitungseinheiten (GPU), andere Hardwaregeräte, die zum Abrufen und Ausführen von in einem maschinenlesbaren Speichermedium gespeicherten Anweisungen geeignet sind, oder Kombinationen davon sein. Das Verarbeitungselement kann ein physisches Gerät sein. Darüber hinaus kann das Verarbeitungselement in einem Beispiel mehrere Kerne auf einem Chip, mehrere Kerne über mehrere Chips, mehrere Kerne über mehrere Geräte oder Kombinationen davon umfassen. Ein Verarbeitungselement kann Anweisungen abrufen, dekodieren und ausführen, um Aufgaben zu implementieren, z. B. die Ausführung eines Betriebssystems, die Bereitstellung von Serverfunktionen, die Ausführung von Containern oder virtuellen Maschinen usw. Alternativ oder zusätzlich zum Abrufen und Ausführen von Befehlen kann das Verarbeitungselement mindestens einen integrierten Schaltkreis (IC), andere Steuerlogik, andere elektronische Schaltkreise oder Kombinationen davon umfassen, die eine Reihe von elektronischen Komponenten zur Ausführung der Funktionalität verschiedener Befehle enthalten.
Ein maschinenlesbares Speichermedium kann ein beliebiges elektronisches, magnetisches, optisches oder anderes physikalisches Speichergerät sein, das ausführbare Anweisungen enthält oder speichert. So kann ein maschinenlesbares Speichermedium z. B. ein Random Access Memory (RAM), ein Electrically Erasable Programmable Read-Only Memory (EEPROM), ein Speicherlaufwerk, ein Compact Disc Read Only Memory (CD-ROM) und ähnliches sein. Als solches kann das maschinenlesbare Speichermedium nicht-transitory sein. Wie hier im Detail beschrieben, kann ein maschinenlesbares Speichermedium mit einer Reihe von ausführbaren Anweisungen zum Ausführen eines Computersystems kodiert sein.
Im Rechensystem kann der Management-Controller 110 Teil eines Management-Subsystems sein, während die Verarbeitungseinheit 280 Teil eines Produktions- oder Host-Subsystems ist. Teile des Host-Subsystems können in Reaktion auf die vom Management-Controller 110 durchgeführte Validierung eingeschaltet werden.
3 ist ein Flussdiagramm eines Verfahrens zur Durchführung einer Aktion auf der Grundlage einer Analyse von Vermerkinformationen und einer gespeicherten Darstellung von eindeutigen Gerätedaten, die für einen Sicherheits-Coprozessor eindeutig sind, gemäß einem Beispiel. ist ein Blockdiagramm eines Management-Controllers, der in der Lage ist, eine Aktion auf der Grundlage einer Analyse von Vermerkinformationen und einer gespeicherten Darstellung von eindeutigen Gerätedaten eines Sicherheits-Coprozessors durchzuführen, gemäß einem Beispiel.
Bei dem Verarbeitungselement 410 kann es sich um eine oder mehrere Verarbeitungseinheiten, einen oder mehrere Mikroprozessoren auf Halbleiterbasis, eine oder mehrere Grafikverarbeitungseinheiten (GPU), andere Hardwarevorrichtungen, die zum Abrufen und Ausführen von im maschinenlesbaren Speichermedium 420 gespeicherten Anweisungen geeignet sind, oder Kombinationen davon handeln. Das Verarbeitungselement 410 kann ein physisches Gerät sein. Das Verarbeitungselement 410 kann Anweisungen 422, 424, 426 abrufen, dekodieren und ausführen, um die Bestimmung zu implementieren, ob die Stromversorgung einer Rechenvorrichtung basierend auf einer Analyse von Befürwortungsinformationen aktiviert werden soll. Alternativ oder zusätzlich zum Abrufen und Ausführen von Anweisungen kann das Verarbeitungselement 410 mindestens einen integrierten Schaltkreis (IC), andere Steuerlogik, andere elektronische Schaltkreise oder Kombinationen davon enthalten, die eine Anzahl elektronischer Komponenten zur Durchführung der Funktionalität der Anweisungen 422, 424, 426 umfassen.
Das maschinenlesbare Speichermedium 420 kann ein beliebiges elektronisches, magnetisches, optisches oder anderes physikalisches Speichergerät sein, das ausführbare Anweisungen enthält oder speichert. So kann das maschinenlesbare Speichermedium z. B. ein Random Access Memory (RAM), ein Electrically Erasable Programmable Read-Only Memory (EEPROM), ein Speicherlaufwerk, ein Compact Disc Read Only Memory (CD-ROM) und ähnliches sein. Als solches kann das maschinenlesbare Speichermedium nicht-transitory sein. Wie hier im Detail beschrieben, kann das maschinenlesbare Speichermedium 420 mit einer Reihe von ausführbaren Anweisungen zum Ausführen einer Aktion als Reaktion auf eine Analyse von Befürwortungsinformationen und einer gespeicherten Darstellung von geräteeigenen Daten, die für einen Sicherheits-Coprozessor einzigartig sind, kodiert sein.
Der Management-Controller 400 kann als Teil eines Computergeräts oder Computersystems implementiert werden, z. B. in den Systemen 100, 200. Das Computergerät kann den Management-Controller 400, einen Sicherheits-Coprozessor und mindestens eine vom Management-Controller 400 getrennte Zentraleinheit enthalten. In einigen Beispielen wird der Management-Controller über eine Hilfsstromschiene mit Strom versorgt, die den Management-Controller 400 mit Strom versorgt, während sich die Rechenvorrichtung in einem Hilfsstromzustand befindet. Wie hierin verwendet, ist „ein Hilfsspannungszustand“ ein Zustand, in dem die CPU nicht mit Strom versorgt wird, aber eine Reihe von Komponenten (z. B. der Management-Controller 400) mit Strom versorgt wird. In einigen Beispielen kann der Hilfsspannungszustand der S5-Zustand des Advanced Configuration and Power Interface (ACPI) sein. Der Hilfsenergiezustand ermöglicht die Vermeidung von Konflikten zwischen dem Verwaltungsprozessor und einer anderen Software, wie z. B. einer Plattform-Firmware (z. B. UEFI), die auf dem System ausgeführt wird.
Obwohl die Ausführung der Methode 300 im Folgenden mit Bezug auf den Management-Controller 400 beschrieben wird, können auch andere geeignete Komponenten zur Ausführung der Methode 300 verwendet werden (z. B. Management-Controller 110). Außerdem können die Komponenten zur Ausführung der Methode 300 auf mehrere Geräte verteilt sein. Das Verfahren 300 kann in Form von ausführbaren Anweisungen, die auf einem maschinenlesbaren Speichermedium, z. B. dem Speichermedium 420, gespeichert sind, und/oder in Form von elektronischen Schaltungen implementiert werden.
Bei 302 des Verfahrens 300 kann der Verwaltungscontroller 400 Kommunikationsanweisungen 422 ausführen, um eindeutige Daten von einem Sicherheits-Coprozessor zu empfangen. Wie bereits erwähnt, kann dies während eines Herstellungs- oder Bereitstellungszustands des Computergeräts oder eines ähnlichen Sicherheits-Snapshot-Zustands erfolgen. Der Management-Controller 400 kann die eindeutigen Gerätedaten empfangen und eine Darstellung der eindeutigen Gerätedaten an einem sicheren Ort speichern, indem er Speicheranweisungen 426 (304) ausführt. Der Empfang der eindeutigen Gerätedaten kann als Reaktion auf eine Anfrage des Management-Controllers 400 erfolgen. Der sichere Speicher kann ein vertrauenswürdiger Bereich des Management-Controllers 400 sein. In einigen Beispielen kann der sichere Speicher nicht überschrieben werden. In einem Beispiel kann der sichere Speicher einmalig beschreibbare Register enthalten.
Wie oben erwähnt, enthalten die geräteeigenen Daten einen öffentlichen Bestätigungsschlüssel oder ein öffentliches Zertifikat für den Sicherheits-Coprozessor. Wie bereits erwähnt, kann in einigen Beispielen jede Einheit, die hergestellt wird, einen anderen privaten Schlüssel und öffentlichen Schlüssel haben. Der öffentliche Schlüssel oder ein öffentliches Zertifikat kann daher als geräteeigene Daten für den Sicherheits-Koprozessor betrachtet werden. Die Daten sollten also eindeutig für den Sicherheits-Koprozessor sein. Eine Repräsentation der geräteeindeutigen Daten kann in einem Speicher gespeichert werden, z. B. in einem sicheren Speicher, der mit der Verwaltungssteuerung 400 verbunden ist. In einem Beispiel besteht die Darstellung aus den eindeutigen Gerätedaten, die vom Sicherheits-Coprozessor empfangen werden. In einem anderen Beispiel ist die Darstellung ein Hash (z. B. MD5, SHA usw.) der eindeutigen Gerätedaten, ein partieller Hash eines Teils der eindeutigen Gerätedaten, eine Kopie eines Teils der eindeutigen Gerätedaten, eine andere Darstellung der eindeutigen Gerätedaten oder eine Kombination davon.
In ähnlicher Weise kann der Management-Controller 400 Code, Einstellungen usw. von anderen Komponenten messen, wie z. B. Code von ihm selbst, einem PLD, anderen Komponenten, Firmware usw. Die Messung kann später verwendet werden, um zu validieren, dass die erwarteten Werte an den gemessenen Stellen vorhanden sind.
Zu einem späteren Zeitpunkt (z. B. wenn sich das Computergerät an einem Kundenstandort befindet) kann der Management Controller 400 eine Validierungssequenz beginnen. Die Verwaltungssteuerung 400 kann durch eine Vertrauensbasis geschützt werden. Die Validierungssequenz kann damit beginnen, dass der Management Controller 400 validiert, dass sein Startup-Code gültig ist (z. B. durch Messen des Startup-Codes und Vergleichen der Messung mit einem zuvor gemessenen Wert). Der Startup-Code kann dann weitere Teile des Codes messen, die auf dem Management-Controller 400 laufen sollen. In einem Beispiel kann der Management-Controller 400, sobald er seinen Code validiert hat, eine Kette zur Validierung anderer Firmware bilden. Beispielsweise kann der Management-Controller 400 Firmware über eine oder mehrere Messungen des Firmware-Speichers, eines PLDs, des Sicherheits-Coprozessors, einer anderen Komponente (z. B. einer Innovation Engine oder Management Engine) usw. validieren.
In einem Beispiel umfasst die Validierungssequenz die Steuerung eines Multiplexers durch den Management-Controller 400 unter Verwendung eines Steuersignals, um auszuwählen, dass der Sicherheits-Coprozessor mit dem Management-Controller 400 kommuniziert. Der Management-Controller 400 kann dann mit dem Sicherheits-Coprozessor kommunizieren.
In einem Beispiel kann die Verwaltungssteuerung 400 einen Startbefehl an den Sicherheits-Coprozessor ausgeben. In einigen Beispielen überträgt der Startbefehl das Eigentum an dem Sicherheits-Coprozessor nicht an die Verwaltungssteuerung 400.
Die Verwaltungssteuerung 400 kann dann bei 306 Vermerksinformationen anfordern und empfangen. Die Vermerksinformationen können von einem erwarteten Standort des Sicherheits-Koprozessors stammen. Beispielsweise kann die Anforderung über einen Bus gesendet werden, an dem sich der Sicherheits-Koprozessor voraussichtlich befindet. Wenn sich ein anderer Sicherheits-Koprozessor an dem Ort befindet als der erwartete oder ursprüngliche Sicherheits-Koprozessor, kann eine Aktion durchgeführt werden.
Der Sicherheits-Coprozessor, der bestückt wird, kann die Vermerkinformationen an den Management-Controller 400 liefern. Die Verwaltungssteuerung 400 kann mithilfe des Verarbeitungselements 410 Validierungsanweisungen 424 ausführen, um zu bestimmen, ob eine Aktion auf dem Computergerät basierend auf einer Analyse der Vermerkinformationen und der gespeicherten Darstellung der eindeutigen Gerätedaten durchgeführt werden soll. Beispielsweise kann der Verwaltungscontroller auf der Grundlage der Analyse (308) bestimmen, ob die Stromversorgung des Computergeräts aktiviert werden soll. Das Verarbeitungselement 410 kann Aktionsanweisungen 428 ausführen, um die Aktion durchzuführen.
Wie oben erwähnt, ist in einem Beispiel die Bestätigungsinformation ein Schlüssel oder ein Zertifikat und die eindeutigen Gerätedaten sind ein entsprechender Schlüssel oder ein Zertifikat. Es kann ein Vergleich durchgeführt werden, um zu überprüfen, ob die beiden übereinstimmen.
In einem anderen Beispiel sind die Vermerksinformationen ein Schlüssel oder ein Zertifikat, das die eindeutigen Gerätedaten enthält, und die Darstellung ist ein Hash der eindeutigen Gerätedaten. Die Anerkennungsinformationen können gehasht und verglichen werden, um zu überprüfen, dass der Sicherheits-Coprozessor nicht manipuliert oder ersetzt wurde.
In einem weiteren Beispiel können die Bestätigungsinformationen in Form einer Antwort auf eine Abfrageanforderung des Management-Controllers 400 vorliegen. Zum Beispiel kann die Verwaltungssteuerung 400 Daten bereitstellen, die der Sicherheits-Coprozessor mit einem privaten Schlüssel verschlüsseln oder signieren soll. Die geräteeigenen Daten können Informationen enthalten, die es der Verwaltungssteuerung 400 ermöglichen, die Daten zu entschlüsseln oder die Signatur zu validieren. Bei diesem Austausch kann ein Nonce verwendet werden. Dementsprechend können die Bestätigungsinformationen eine Antwort enthalten, die eine erwartete Antwort auf die Abfrage ist. Die Validierung kann auf der erwarteten Antwort basieren.
In einem Beispiel kann die Verwaltungssteuerung 400 auf der Grundlage der Analyse der Vermerkinformationen bestimmen, ob eine Aktion durchgeführt werden soll. In dem Beispiel, in dem die Vermerksinformationen unter Verwendung der eindeutigen Gerätedaten validiert werden, kann die Verwaltungssteuerung 400 die Validierungssequenz fortsetzen. In einigen Beispielen ist die Validierungssequenz Teil eines Boot-Ereignisses. So kann die Aktion in einem Beispiel das Aktivieren des Einschaltens des Computergeräts umfassen (z. B. durch direktes oder indirektes Aktivieren eines Stromversorgungs-Steuersignals (z. B. unter Verwendung eines PLD)). Wie bereits erwähnt, können weitere Validierungen erfolgen, bevor das Stromversorgungs-Steuersignal aktiviert wird. Andere Aktionen, die durchgeführt werden können, umfassen das Protokollieren des Ereignisses und das Senden einer Nachricht über das Ereignis.
In einem anderen Beispiel können die Vermerkinformationen von einem zweiten Sicherheits-Koprozessor empfangen werden, der das Original ersetzt hat. In diesem Szenario werden die Vermerksinformationen nicht validiert und es kann eine Aktion ausgeführt werden. In einem Beispiel kann das Ereignis protokolliert werden. In einem anderen Beispiel kann eine Nachricht an einen Administrator gesendet werden. In einem weiteren Beispiel kann der Management Controller 400 das Booten des Computergeräts verhindern.
5 ist ein Blockdiagramm eines Computergeräts, das in der Lage ist, eine Aktion basierend auf einer Analyse von Befürwortungsinformationen und einer gespeicherten Darstellung von eindeutigen Gerätedaten durchzuführen, die für einen Sicherheits-Coprozessor eindeutig sind, gemäß einem Beispiel. Die Rechenvorrichtung 500 kann einen Sicherheits-Coprozessor 510, eine Plattform-Firmware 512, eine Root-of-Trust-Vorrichtung 514, einen Prozessor 530 und einen Speicher 532 umfassen.
In diesem Beispiel kann der Sicherheits-Coprozessor 510 mithilfe der Plattform-Firmware 512 ausgewertet werden, die auf einem Prozessor 530 des Computergeräts 500 ausgeführt wird. Dies kann in ähnlicher Weise wie bei den Ansätzen mit den Management-Controllern 110, 400 durchgeführt werden.
Zu einem ersten Zeitpunkt kann der Sicherheits-Coprozessor 510 nach eindeutigen Gerätedaten abgefragt werden. Die Abfrage kann über ein Root-of-Trust-Gerät 514, wie z. B. einen Management-Controller 110, oder über eine andere Engine, wie z. B. die Plattform-Firmware 512, die auf dem Prozessor 530 ausgeführt wird, erfolgen. Die Plattform-Firmware 512 kann in einen Speicher 532, wie z. B. einen Hauptspeicher des Computergeräts 500, geladen werden. Sie kann in einem sicheren Speicher (z. B. in einem anderen Sicherheits-Coprozessor, einem sicheren Speichergerät usw.) gespeichert werden.
Zu einem späteren Zeitpunkt, wenn das Computergerät 500 in einer Produktionsumgebung gebootet werden soll, kann das Root-of-Trust-Gerät 514 (z. B. ein Management-Controller mit Root-of-Trust) seinen Code sowie den Code anderer Komponenten in einer Weise messen, die mit der oben beschriebenen Weise übereinstimmt. Die anderen Komponenten können einen Speicher (z. B. einen Festwertspeicher) umfassen, der die Plattform-Firmware 512, anderen Code, Einstellungen, PLD-Logik usw. enthält. Dies kann geschehen, bevor die Stromversorgung zum Booten des Computergeräts 500 freigegeben wird.
Sobald die Stromversorgung eingeschaltet ist, kann die Plattform-Firmware 512 mit der Ausführung auf dem Prozessor 530 beginnen. Als Teil einer Initialisierung des Computergeräts 500 kann die Plattform-Firmware 512 eine Validierungssequenz für den Sicherheits-Coprozessor 530 enthalten.
In einem Beispiel beinhaltet die Validierungssequenz, dass der Prozessor 530 mit dem Sicherheits-Coprozessor 130 kommuniziert. In verschiedenen Beispielen kann der Sicherheits-Coprozessor 130 hochfahren, sobald er über die Hilfsenergie oder über eine mit dem Prozessor 530 gemeinsam genutzte Stromschiene versorgt wird.
In einem Beispiel wird die Plattform-Firmware 512 ausgeführt, um einen Startbefehl an den Sicherheits-Coprozessor 510 zu geben. In einigen Beispielen überträgt der Startbefehl nicht das Eigentum an dem Sicherheits-Coprozessor 510.
Der Prozessor 530 kann dann Endorsement-Informationen anfordern und empfangen. Die Vermerksinformationen können von einem erwarteten Standort des Sicherheits-Coprozessors 510 stammen. Beispielsweise kann die Anforderung über einen Bus gesendet werden, an dem sich der Sicherheits-Koprozessor 510 voraussichtlich befinden wird. Wenn sich ein anderer Sicherheits-Koprozessor an dem Ort befindet als der erwartete oder ursprüngliche Sicherheits-Koprozessor, kann eine Aktion durchgeführt werden.
Der bestückte Sicherheits-Coprozessor kann die Vermerksinformationen an die Plattform-Firmware 512 liefern, die auf dem Prozessor 530 ausgeführt wird. Die Plattform-Firmware 512 kann ausgeführt werden, um eine Analyse der Vermerksinformationen und der gespeicherten Darstellung der eindeutigen Gerätedaten durchzuführen, wie oben in Bezug auf den Management-Controller beschrieben.
Wenn der Sicherheits-Coprozessor 510 validiert wird, kann das Computergerät 500 seine Boot-Sequenz fortsetzen und die Ausführung des Computergeräts 500 kann an ein High-Level-Betriebssystem übergeben werden. Wenn der Sicherheits-Coprozessor 510 nicht validiert wird, kann eine andere Maßnahme ergriffen werden, z. B. Protokollierung, Senden einer Sicherheitswarnung oder -nachricht, Anhalten des Startvorgangs des Computergeräts 500 usw. Das Stoppen des Hochfahrens des Computergeräts 500 kann beinhalten, die Stromversorgung des Computergeräts 500 zu unterbrechen, ein Flag in einem PLD zu setzen, um das System zu veranlassen, nicht hochzufahren, bis es gelöscht ist, die Kontrolle über das Computergerät 500 nicht an das Betriebssystem zu übergeben, usw. Femer kann in einigen Beispielen die Plattform-Firmware 512 verwendet werden, um einige der Aktivitäten des Management-Controllers 400 zu implementieren, die mit der Validierung des Sicherheits-Coprozessors zusammenhängen.
Während bestimmte Implementierungen oben gezeigt und beschrieben wurden, können verschiedene Änderungen in Form und Details vorgenommen werden. Zum Beispiel können einige Merkmale, die in Bezug auf eine Implementierung und/oder einen Prozess beschrieben wurden, auf andere Implementierungen bezogen werden. Mit anderen Worten: Prozesse, Merkmale, Komponenten und/oder Eigenschaften, die in Bezug auf eine Implementierung beschrieben wurden, können auch in anderen Implementierungen nützlich sein. Darüber hinaus ist zu beachten, dass die hier beschriebenen Systeme und Verfahren verschiedene Kombinationen und/oder Unterkombinationen der Komponenten und/oder Merkmale der verschiedenen beschriebenen Implementierungen umfassen können. So können Merkmale, die unter Bezugnahme auf eine oder mehrere Implementierungen beschrieben werden, mit anderen hier beschriebenen Implementierungen kombiniert werden.

Claims

Ein Computergerät, das Folgendes umfasst: mindestens eine zentrale Recheneinheit: einen Verwaltungscontroller, der von der mindestens einen zentralen Verarbeitungseinheit getrennt ist, wobei der Verwaltungscontroller unter Verwendung einer Hilfsenergieschiene mit Strom versorgt wird, die den Verwaltungscontroller mit Strom versorgt, während sich die Rechenvorrichtung in einem Hilfsenergiezustand befindet; und einen Sicherheits-Coprozessor mit eindeutigen Gerätedaten, die nur für den Sicherheits-Coprozessor gelten, wobei der Verwaltungscontroller zu einem ersten Zeitpunkt die eindeutigen Gerätedaten empfängt und eine Darstellung der eindeutigen Gerätedaten an einem sicheren Ort speichert, wobei zu einem späteren Zeitpunkt, als Teil einer Validierungssequenz, der Management-Controller Endorsement-Informationen von einem erwarteten Ort des Sicherheits-Coprozessors empfängt, und wobei der Verwaltungscontroller auf der Grundlage einer Analyse der Vermerksinformationen und der gespeicherten Darstellung der eindeutigen Gerätedaten bestimmt, ob eine Aktion auf dem Computergerät durchgeführt werden soll.
Computergerät nach Anspruch 1, wobei die Aktion darin besteht, die Stromversorgung der Computervorrichtung zu aktivieren, wobei die Computervorrichtung ferner umfasst: einem Multiplexer, der den Sicherheits-Coprozessor selektiv mit einem Controller-Hub oder einer Busschnittstelle zum Management-Controller verbindet.
Computergerät nach Anspruch 1 oder 2, wobei der Management-Controller den Multiplexer über ein Steuersignal steuern soll, um den Sicherheits-Coprozessor für die Kommunikation mit dem Management-Controller während des Teils der Validierungssequenz auszuwählen.
Computergerät nach einem der vorhergehenden Ansprüche, wobei der Management-Controller den Multiplexer so steuern soll, dass er den Controller-Hub nach dem Teil der Validierungssequenz auswählt.
Computergerät nach einem der vorhergehenden Ansprüche, wobei der Management-Controller einen anderen Multiplexer über das gleiche Steuersignal steuern soll, um eine andere Komponente zu veranlassen, sich mit einem anderen Bus zu verbinden, der mit dem Management-Controller verbunden ist.
Computergerät nach einem der vorhergehenden Ansprüche, wobei der Management-Controller ein Firmware-Image der anderen Komponente als zweiten Teil der Validierungssequenz validieren soll.
Computergerät nach einem der vorhergehenden Ansprüche, wobei der Management-Controller den anfänglichen Startcode des Management-Controllers, ein Firmware-Image eines verbleibenden Teils des Management-Controllers unter Verwendung einer Vertrauenswurzel, einer Boot-Firmware und der Komponente validieren soll, bevor die Stromversorgung des Computergeräts freigegeben wird.
Computergerät nach einem der vorhergehenden Ansprüche, wobei die gespeicherte Darstellung ein Hash der eindeutigen Gerätedaten ist.
Computergerät nach einem der vorhergehenden Ansprüche, wobei die Bestätigungsinformationen zweite geräteeigene Daten sind und die Analyse den Vergleich der Darstellung der geräteeigenen Daten umfasst.
Computergerät nach einem der vorhergehenden Ansprüche, wobei die Bestätigungsinformation eine Antwort auf eine Abfrage ist, die die Darstellung der geräteeindeutigen Daten verwendet, um die Abfrage zu verschlüsseln, und die Analyse eine Antwort mit einer erwarteten Antwort enthält.
Ein nicht-transitorisches, maschinenlesbares Speichermedium, das Befehle speichert, die, wenn sie von einem physikalischen Verarbeitungselement eines Management-Controllers ausgeführt werden, den Management-Controller dazu veranlassen,: zu einem ersten Zeitpunkt geräteeigene Daten von einem Sicherheits-Coprozessor empfangen, die für den Sicherheits-Coprozessor eines Computergeräts einzigartig sind; eine Darstellung der eindeutigen Gerätedaten an einem sicheren Ort speichern, wobei das Rechengerät den Management-Controller, den Sicherheits-Coprozessor und mindestens eine vom Management-Controller getrennte zentrale Verarbeitungseinheit enthält, wobei der Management-Controller über eine Hilfsspannungsschiene mit Strom versorgt wird, die den Management-Controller mit Strom versorgt, während sich das Rechengerät in einem Hilfsspannungszustand befindet, zu einem späteren Zeitpunkt als Teil einer Validierungssequenz Endorsement-Informationen von einem erwarteten Ort des Sicherheits-Coprozessors empfangen; Bestimmen, ob die Leistung des Computergeräts basierend auf einer Analyse der Bestätigungsinformationen und der gespeicherten Darstellung der eindeutigen Gerätedaten aktiviert werden soll.
Nicht-transitorisches, maschinenlesbares Speichermedium nach Anspruch 11, das ferner Anweisungen umfasst, die, wenn sie von dem physischen Verarbeitungselement ausgeführt werden, die Verwaltungssteuerung veranlassen,: einen Multiplexer steuern, der den Sicherheits-Coprozessor über ein Steuersignal selektiv mit einem Controller-Hub oder einer Busschnittstelle mit dem Management-Controller verbindet, um den Sicherheits-Coprozessor auszuwählen, mit dem Management-Controller während des Teils der Validierungssequenz zu kommunizieren; und den Multiplexer steuern, um den Controller-Hub auszuwählen, der nach dem Teil der Validierungssequenz mit dem Sicherheits-Coprozessor kommuniziert.
Nicht-transitorisches, maschinenlesbares Speichermedium nach Anspruch 11 oder 12, das ferner Anweisungen umfasst, die, wenn sie von dem physischen Verarbeitungselement ausgeführt werden, die Verwaltungssteuerung veranlassen,: einen zweiten Multiplexer über dasselbe Steuersignal zu steuern, um eine andere Komponente zu veranlassen, sich mit einem anderen Bus zu verbinden, der mit dem Management-Controller verbunden ist; und ein Firmware-Abbild der anderen Komponente als zweiten Teil der Validierungssequenz validieren.
Nicht-transitorisches, maschinenlesbares Speichermedium nach einem der Ansprüche 11 bis 13, das ferner Anweisungen umfasst, die, wenn sie von dem physischen Verarbeitungselement ausgeführt werden, die Verwaltungssteuerung veranlassen,: den anfänglichen Startcode des Management-Controllers, ein Firmware-Image eines verbleibenden Teils des Management-Controllers unter Verwendung einer Vertrauenswurzel, einer Boot-Firmware und der Komponente zu validieren, bevor die Stromversorgung des Computergeräts aktiviert wird.
Nicht-transitorisches maschinenlesbares Speichermedium nach einem der Ansprüche 11 bis 14, wobei die Bestätigungsinformationen zweite geräteeigene Daten sind und die Analyse den Vergleich der Darstellung der geräteeigenen Daten mit den zweiten geräteeigenen Daten umfasst.
Ein Verfahren, das Folgendes umfasst: Empfangen von geräteeindeutigen Daten von einem Sicherheits-Coprozessor, die für den Sicherheits-Coprozessor eines Rechengeräts eindeutig sind, durch einen Management-Controller zu einem ersten Zeitpunkt; Speichern einer Darstellung der eindeutigen Gerätedaten an einem sicheren Ort durch den Management-Controller, wobei das Rechengerät den Management-Controller, den Sicherheits-Coprozessor und mindestens eine vom Management-Controller getrennte zentrale Verarbeitungseinheit enthält, wobei der Management-Controller über eine Hilfsspannungsschiene mit Strom versorgt wird, die den Management-Controller mit Strom versorgt, während sich das Rechengerät in einem Hilfsspannungszustand befindet, Steuern eines Multiplexers, der den Sicherheits-Coprozessor selektiv mit einem Controller-Hub oder einem Bus, der mit dem Management-Controller verbunden ist, über ein Steuersignal verbindet, um den Sicherheits-Coprozessor für die Kommunikation mit dem Management-Controller während eines Teils einer Validierungssequenz zu einem späteren Zeitpunkt auszuwählen; Empfangen von Bestätigungsinformationen von einem erwarteten Standort des Sicherheits-Coprozessors zu einem späteren Zeitpunkt als Teil der Validierungssequenz durch den Management-Controller; Bestimmen, durch den Management-Controller, ob die Stromversorgung des Computergeräts basierend auf einer Analyse der Vermerksinformationen und der gespeicherten Darstellung der eindeutigen Gerätedaten aktiviert werden soll.
Verfahren nach Anspruch 16, das weiterhin umfasst: Steuerung des Multiplexers durch den Management-Controller, um den Controller-Hub für die Kommunikation mit dem Sicherheits-Coprozessor nach dem Teil der Validierungssequenz auszuwählen.
Verfahren nach Anspruch 16 oder 17, das weiterhin umfasst: Steuern eines zweiten Multiplexers durch den Management-Controller über das gleiche Steuersignal, um eine andere Komponente zu veranlassen, sich mit einem anderen Bus zu verbinden, der mit dem Management-Controller verbunden ist; Validierung eines Firmware-Images der anderen Komponente durch den Management-Controller als zweiten Teil der Validierungssequenz; Validieren des anfänglichen Startcodes des Management-Controllers, eines Firmware-Images eines verbleibenden Teils des Management-Controllers unter Verwendung einer Vertrauenswurzel, einer Boot-Firmware und der Komponente durch den Management-Controller, bevor die Stromversorgung des Computergeräts freigegeben wird.
Verfahren nach einem der Ansprüche 16 bis 18, wobei die Bestätigungsinformationen zweite geräteeigene Daten sind und die Analyse einen Vergleich der Darstellung der geräteeigenen Daten umfasst.
Verfahren nach einem der Ansprüche 16 bis 19, wobei die Bestätigungsinformation eine Antwort auf eine Abfrage ist, die die Darstellung der eindeutigen Gerätedaten verwendet, um die Abfrage zu verschlüsseln, und die Analyse eine Antwort mit einer erwarteten Antwort enthält.