DE102022108380A1

DE102022108380A1 - Verwaltung der speicherung von geheimnissen in speichern von baseboard-management-controller

Info

Publication number: DE102022108380A1
Application number: DE102022108380.2A
Authority: DE
Inventors: Theodore F. Emerson; Shiva R. Dasari; Luis E. Luciani, Jr.; Kevin E. Boyum; Naysen J. Robertson; Robert L. Noonan; Christopher M. Wesneski; David F. Heinrich
Original assignee: Hewlett Packard Enterprise Development LP
Current assignee: Hewlett Packard Enterprise Development LP
Priority date: 2021-10-28
Filing date: 2022-04-07
Publication date: 2023-05-04
Also published as: CN116049825A; US20230134324A1

Abstract

Eine Vorrichtung enthält einen Host und einen Basisplatinen-Verwaltungscontroller. Der Basisplatinen-Verwaltungscontroller enthält ein Halbleiterpaket; und das Halbleiterpaket enthält einen Speicher, einen Sicherheits-Hardwareprozessor und einen Haupt-Hardwareprozessor. Der Haupthardwareprozessor veranlasst den Basisboard-Verwaltungscontroller, als Agent zu dienen, der unabhängig vom Host auf Kommunikationen mit einer entfernten Verwaltungseinheit reagiert, um den Host zu verwalten. Der Sicherheits-Hardwareprozessor verwaltet die Speicherung eines Geheimnisses des Hosts in dem Speicher.

Description

HINTERGRUND
Eine Computerplattform (z. B. ein Server) kann einen speziellen Dienstprozessor enthalten, der als „Baseboard Management Controller“ oder „BMC“ bezeichnet wird und den physischen Zustand der Computerplattform überwacht. Der BMC kann über ein Verwaltungsnetzwerk mit einem Fernverwaltungsserver kommunizieren, um dem Fernverwaltungsserver Informationen über die Computerplattform zu übermitteln und dem Fernverwaltungsserver die Steuerung von Aktionen zu ermöglichen, die vom BMC durchgeführt werden. Als Beispiele für seine Aufgaben kann der BMC Sensoren überwachen (z. B. Temperatursensoren, Lüfterdrehzahlsensoren), einen Betriebssystemstatus überwachen, Stromversorgungszustände überwachen, Computersystemereignisse protokollieren, ferngesteuerte Funktionen der Computerplattform ausführen (z. B. das Ein- und Ausschalten der Computerplattform) usw.
Figurenliste

1 ist eine schematische Darstellung einer Computerplattform mit einem Baseboard Management Controller (BMC), der einen sicheren Speicher zum Speichern von Geheimnissen gemäß einer Beispielimplementierung enthält.
2 ist eine schematische Darstellung einer sicheren Enklave eines BMC, die einen sicheren Speicher zur Speicherung von Geheimnissen gemäß einer Beispielimplementierung enthält.
Die und zeigen die Verpackung der Komponenten des BMC in verschiedenen Ausführungsbeispielen.
5 ist ein Flussdiagramm, das einen Prozess darstellt, der von einer sicheren Enklave eines BMC verwendet wird, um eine API-Anforderung (Application Programming Interface) für einen Verschlüsselungsschlüssel zu verarbeiten, der in einem sicheren Speicher der sicheren Enklave gemäß einer Beispielimplementierung gespeichert ist.
6 ist ein Flussdiagramm, das einen Prozess darstellt, der von einer sicheren Enklave eines BMC verwendet wird, um eine API-Anforderung zum Aktualisieren oder Löschen eines Zertifikats zu verarbeiten, das in einem sicheren Speicher der sicheren Enklave gemäß einer Beispielimplementierung gespeichert ist.
7 ist ein schematisches Diagramm eines Geräts, das einen BMC enthält, der die Speicherung eines Geheimnisses eines Hosts des Geräts gemäß einer Beispielimplementierung verwaltet.
8 ist ein Flussdiagramm, das einen Prozess zur Verwaltung eines in einem sicheren Speicher einer BMC gespeicherten Geheimnisses gemäß einer Beispielimplementierung darstellt.
9 ist eine Illustration von maschinenlesbaren Anweisungen, die auf einem nicht-transitorischen maschinenlesbaren Speichermedium gespeichert sind, um eine Maschine zu veranlassen, die Speicherung eines Geheimnisses in einem sicheren Speicher eines Verwaltungscontrollers gemäß einer Beispielimplementierung zu verwalten.

AUSFÜHRLICHE BESCHREIBUNG
Ein BMC kann eine Reihe von Firmware-Befehlen ausführen, die als „Firmware-Management-Stack“ bezeichnet werden, um eine Vielzahl von verwaltungsbezogenen Funktionen für eine Computerplattform auszuführen. So kann der BMC beispielsweise verwaltungsbezogene Funktionen wie Betriebssystem-Laufzeitdienste, Ressourcenerkennung und -initialisierung sowie Pre-Operating-Systemdienste bereitstellen. Die verwaltungsbezogenen Funktionen können auch Fernverwaltungsfunktionen für die Computerplattform umfassen. Zu den Fernverwaltungsfunktionen können beispielsweise Tastatur-Video-Maus-Funktionen (KVM), virtuelle Stromversorgungsfunktionen (z. B. fernaktivierte Funktionen zur Ferneinstellung eines Stromversorgungszustands, wie z. B. eines Energiesparzustands, eines Einschaltzustands, eines Rücksetzzustands oder eines Ausschaltzustands), virtuelle Medienverwaltungsfunktionen usw. gehören.
Neben der Bereitstellung von Verwaltungsfunktionen für die Computerplattform kann die BMC sicherheitsrelevante Funktionen bereitstellen, die die Computerplattform vor Sicherheitsverletzungen schützen. So kann die BMC beispielsweise eine Hardware- (oder „Silizium-“) Root of Trust (RoT)-Engine oder „SRoT-Engine“ für die Computerplattform enthalten. Die SRoT-Engine kann die Firmware der Computerplattform auf verschiedene Weise validieren. Beispielsweise kann die Firmware der Computerplattform als eine Kette von validierten Firmware-Abschnitten validiert werden. Beispielsweise kann eine Hardware-SRoT-Engine einen Teil der Firmware in Hardware validieren, indem sie ihn in eine sichere Enklave der BMC lädt. Die sichere Enklave kann dann den validierten Teil der Firmware ausführen, um einen zweiten Teil der Firmware weiter zu validieren usw., wodurch eine Kette des Vertrauens entsteht. Die Validierung der Firmware kann von einer einzigen Instanz (z. B. ausschließlich als Funktion einer sicheren Enklave) oder von verschiedenen Instanzen durchgeführt werden, wobei davon ausgegangen wird, dass jede Instanz nur zuvor validierte Teile der Firmware ausführt. Der zweite Teil der Firmware im vorherigen Beispiel kann beispielsweise zusätzliche Firmware sein, die von einer sicheren Enklave benötigt wird. Dieser zweite Teil wird zur Validierung eines dritten Teils verwendet, der maschinenlesbaren Anweisungen für eine BMC entsprechen kann. Dieser dritte Teil kann einen vierten Teil validieren, der maschinenlesbaren Anweisungen für Hostsystem-Firmware, wie z. B. Unified Extensible Firmware Interface (UEFI)-Firmware, entsprechen kann.
Der BMC ist ein relativ komplexes Teilsystem, das möglicherweise Millionen von Anweisungen des Firmware-Management-Stacks ausführt, noch bevor der Rest der Computerplattform eingeschaltet wird. Obwohl die BMC die Integrität des Firmware-Verwaltungsstapels überprüfen kann, bevor die BMC den Stapel lädt und ausführt, setzt die relativ große Anzahl von Anweisungen des Stapels die Computerplattform potenziell latenten oder unentdeckten Sicherheitslücken aus. Aufgrund der mangelnden Transparenz proprietärer Management-Stacks, die potenziell unentdeckte Sicherheitslücken aufweisen können, möchten die Kunden von Computerplattformen diese möglicherweise mit Open-Source-Firmware-Management-Stacks verwalten. Darüber hinaus möchte ein bestimmter Kunde möglicherweise denselben Open-Source-Firmware-Management-Stack für die Verwaltung aller Computerplattformen des Kunden verwenden, unabhängig von dem/den jeweiligen Anbieter(n) für diese Plattformen. Bei dem Open-Source-Firmware-Management-Stack kann es sich beispielsweise um Firmware handeln, die im Rahmen der OpenBMC-Community entwickelt wurde, z. B. Version 2.7 oder spätere Versionen.
Wenn ein Kunde den Firmware-Management-Stack der BMC bereitstellen darf, kann die BMC vor der Herausforderung stehen, Sicherheitsmerkmale für die Computerplattform bereitzustellen. Ein potenzielles Sicherheitsmerkmal für die BMC kann beispielsweise ein Speicher zum Speichern von Geheimnissen der Computerplattform sein. Ein „Geheimnis“ kann beispielsweise ein kryptografischer Schlüssel, ein Zertifikat, ein Passwort, ein Token, ein Seed, eine kryptografische Identität für die Plattform usw. sein. Ohne geeignete Maßnahmen können die Geheimnisse dem Firmware-Verwaltungsstapel ausgesetzt sein und daher für Sicherheitslücken des Firmware-Verwaltungsstapels anfällig sein.
Gemäß den hier beschriebenen Beispielimplementierungen stellt ein Management-Controller für eine Computerplattform, wie z. B. ein BMC, Sicherheitsmerkmale für die Computerplattform bereit, führt einen Firmware-Management-Stack aus und isoliert die Sicherheitsmerkmale vom Firmware-Management-Stack. Abhängig von der jeweiligen Implementierung kann der Firmware-Management-Stack ein nicht-proprietärer Open-Source-Firmware-Stack sein, ein Firmware-Stack, der anderweitig von einem Kunden der Computerplattform bereitgestellt wird, ein proprietärer Firmware-Stack und so weiter. In Übereinstimmung mit Beispielimplementierungen bietet der BMC als Teil seiner Sicherheitsmerkmale einen Speicher (hier als „sicherer Speicher“ bezeichnet), um Geheimnisse für die Computerplattform sicher zu speichern. Bei dem sicheren Speicher kann es sich beispielsweise um einen nichtflüchtigen Direktzugriffsspeicher (NVRAM) handeln, in dem Geheimnisse gespeichert, gelesen, gelöscht und geändert werden können. Gemäß den Beispielimplementierungen regelt der BMC den Zugriff auf die sicheren Geheimnisse streng.
Gemäß einigen Implementierungen bietet der BMC eine Verwaltungsebene und eine Sicherheitsebene, die von der Verwaltungsebene isoliert ist. Der Firmware-Management-Stack wird in der Verwaltungsebene ausgeführt. Die Komponenten in der Sicherheitsebene des BMC sind gemäß Beispielimplementierungen durch eine Firewall von anderen Komponenten der Computerplattform isoliert. In diesem Zusammenhang bezieht sich eine „Firewall“ auf eine Kommunikationsbarriere, durch die die Kommunikation streng kontrolliert wird. Bei einigen Implementierungen kann die Kommunikation durch die Firewall beispielsweise durch die Verwendung einer Anwendungsprogrammierschnittstelle (API) für Sicherheitsdienste geregelt werden.
Insbesondere umfasst die Sicherheitsebene der BMC gemäß Beispielimplementierungen eine sichere Enklave, und die sichere Enklave umfasst einen sicheren Speicher, der ein oder mehrere Geheimnisse für die Computerplattform speichern kann. Die Geheimnisse können Geheimnisse des Hosts und die Geheimnisse können Geheimnisse der BMC enthalten. In diesem Zusammenhang bezieht sich eine „sichere Enklave“ auf ein Teilsystem des BMC, bei dem der Zugriff in das und aus dem Teilsystem streng kontrolliert wird. Gemäß Beispielimplementierungen führt die sichere Enklave kryptografische Funktionen für die Computerplattform aus und ist vollständig innerhalb einer kryptografischen Grenze angeordnet. Eine „kryptografische Grenze“ bezieht sich in diesem Zusammenhang auf eine kontinuierliche Grenze oder einen Perimeter, der die logischen und physischen Komponenten eines kryptografischen Teilsystems enthält, wie z. B. BMC-Komponenten, die die sichere Enklave bilden. Ein „Host“ bezieht sich auf Komponenten (z. B. einen oder mehrere CPU-Kerne und ein System) der Computerplattform, die mindestens eines der folgenden Elemente bereitstellen: ein Betriebssystem (z. B. ein Linux-Betriebssystem), um eine Betriebssystemumgebung für die Computerplattform zu schaffen, oder eine Pre-Boot-Umgebung (z. B. ein Basis-Eingabe-/Ausgabesystem (BIOS) und/oder ein Unified Extensible Firmware Interface (UEFI)), um die Computerplattform auf die Betriebssystemumgebung vorzubereiten.
Da die sichere Enklave durch eine kryptografische Grenze geschützt ist, kann der Zugriff auf Geheimnisse, die im sicheren Speicher gespeichert sind, streng kontrolliert werden. In Übereinstimmung mit Beispielimplementierungen kann die sichere Enklave eine oder mehrere APIs (hier als „Geheimverwaltungs-APIs“ bezeichnet) für die Verwaltung der im sicheren Speicher gespeicherten Geheimnisse bereitstellen. Auf diese Weise können die APIs zur Verwaltung der Geheimnisse gemäß einigen Implementierungen Zugriffsfunktionen für die Verwaltung der Geheimnisse bereitstellen, z. B. APIs zum Lesen von Geheimnissen, zum Schreiben von Geheimnissen, zum Löschen oder Freigeben von Geheimnissen, zum Binden oder Versiegeln von Geheimnissen an bestimmte Plattformkonfigurationsregister-Zustände (PCR), zum Aufheben der Bindung oder Entsiegeln von Geheimnissen auf der Grundlage bestimmter PCR-Zustände, zum Erstellen von Geheimnissen, zum Speichern von Geheimnissen und so weiter.
Die Verwaltungsebene der BMC (und insbesondere ein oder mehrere Hauptverarbeitungskern(e) der Verwaltungsebene) kann als Stellvertreter für die sichere Enklave für den geheimen verwaltungsbezogenen Austausch oder für Sitzungen zwischen dem Host und der sicheren Enklave dienen. Der Begriff „Stellvertreter“ für eine bestimmte Komponente (z. B. die sichere Enklave) bezieht sich auf eine Relais- oder Vermittlungskomponente, die im Namen der betreffenden Komponente handelt. Als Proxy für die sichere Enklave kann die Verwaltungsebene des BMC Aufrufe oder Anfragen von Anforderern (z. B. einem UEFI oder einem Betriebssystem) an die geheimen Verwaltungs-APIs empfangen und die Anfragen zur Verarbeitung an die sichere Enklave weiterleiten. Darüber hinaus kann die BMC-Verwaltungsebene in ihrer Funktion als Proxy die Antworten auf diese Anfragen von der sicheren Enklave an die Anforderer weiterleiten.
Gemäß Beispielimplementierungen kann die sichere Enklave neben dem sicheren Speicher eine Reihe anderer Komponenten enthalten. Beispielsweise kann die sichere Enklave gemäß einigen Implementierungen einen Sicherheitsprozessor (z. B. einen oder mehrere Hardware-Verarbeitungskerne zur Ausführung von Firmware-Befehlen zur Verarbeitung der geheimen Verwaltungs-API-Anforderungen, zur Validierung von Firmware und zur Durchführung anderer sicherheitsbezogener Aufgaben), einen flüchtigen Speicher (z. B, einen flüchtigen Speicher (z. B. einen Speicher zum Speichern von Firmware, die in den flüchtigen Speicher geladen und vom Sicherheitsprozessor ausgeführt wird); eine sichere Brücke zur Steuerung des Zugriffs auf die sichere Enklave und zur Steuerung der von der sicheren Enklave ausgehenden Kommunikation; kryptografische Verarbeitungsperipheriegeräte (z. B. kryptografische Beschleuniger, ein Zufallszahlengenerator, eine Schaltung zur Erkennung von Manipulationen usw.); und eine Silizium-Root-of-Trust-Engine (SRoT).
Gemäß Beispielimplementierungen können der/die Hauptverarbeitungskern(e) des BMC (der den Firmware-Management-Stack ausführt) und die sichere Enklave in einem Halbleitergehäuse (oder „Chip“) angeordnet sein. Bei dem Halbleitergehäuse kann es sich um eine beliebige Art von Gehäuse handeln, wie z. B. ein oberflächenmontiertes Gehäuse, ein Durchgangslochgehäuse, ein Ball-Grid-Array-Gehäuse, ein Small-Outline-Gehäuse, ein Chip-Scale-Gehäuse und so weiter. Außerdem können die Komponenten der sicheren Enklave je nach Ausführung in einem oder mehreren Chips des Halbleitergehäuses hergestellt werden.
Als spezifischeres Beispiel können gemäß einigen Implementierungen alle Komponenten der sicheren Enklave in zwei Halbleiterchips des Halbleitergehäuses hergestellt werden. Der sichere Speicher kann in einem ersten Halbleiterchip hergestellt werden, und die übrigen Komponenten der sicheren Enklave können in einem anderen, zweiten Halbleiterchip hergestellt werden. Darüber hinaus können gemäß Beispielimplementierungen Komponenten (z. B. Hauptverarbeitungskerne, ein Speicher usw.) der Verwaltungsebene des BMC auch auf dem zweiten Halbleiterchip hergestellt werden.
Gemäß einem weiteren Implementierungsbeispiel können alle Komponenten der sicheren Enklave auf einem einzigen Halbleiterchip hergestellt werden. Darüber hinaus können auch die Komponenten der Verwaltungsebene des BMC auf diesem einzigen Halbleiterchip hergestellt werden.
Unabhängig von der jeweiligen Implementierung können die Anschlüsse (z. B. Adress-, Daten- und Steueranschlüsse) des sicheren Speichers vollständig in das Halbleitergehäuse eingebettet sein, so dass keiner der Anschlüsse außerhalb des Halbleitergehäuses freiliegen kann. Daher kann der sichere Speicher sehr widerstandsfähig gegen physische Manipulationen (z. B. Manipulationen unter Verwendung von physischen Sonden und eines Logikanalysators) sowie gegen andere Arten von Manipulationen (z. B. Manipulationen unter Verwendung von Schwachstellen des Firmware-Management-Stacks) sein.
Bezug nehmend auf 1, als spezifischeres Beispiel, enthält eine Computerplattform 100 in Übereinstimmung mit einigen Implementierungen einen Management-Controller (oder „Service-Prozessor“), wie z. B. einen BMC 129. Der BMC 129 umfasst einen sicheren Speicher 144, der sich in einer sicheren Enklave 140 des BMC 129 befindet. Der sichere Speicher 144 kann ein oder mehrere Geheimnisse 145 für die Computerplattform 100 speichern.
Ein Host 101 der Computerplattform 100 kann die Geheimnisse 145 unter Verwendung einer oder mehrerer APIs zur Verwaltung von Geheimnissen 147 verwalten, die von der sicheren Enklave 140 bereitgestellt werden. Beispielsweise können die Geheimnisse 145 einen oder mehrere Verschlüsselungsschlüssel enthalten, und die APIs zur Verwaltung der Geheimnisse 147 können eine oder mehrere APIs 147 zum Abrufen von Verschlüsselungsschlüsseln und zum Speichern von Verschlüsselungsschlüsseln enthalten.
Im Allgemeinen kann ein Verschlüsselungsschlüssel (oder „KEK“) von einem selbstverschlüsselnden Speichergerät 122 (z. B. einem NVMe-Speichergerät (Non-Volatile Memory Express)) der Computerplattform 100 verwendet werden. Genauer gesagt, kann das Speichergerät 122 intern einen Medienzugriffsschlüssel speichern und verwenden, um die auf dem Speichergerät 122 gespeicherten Daten zu verschlüsseln und zu entschlüsseln, und der Medienzugriffsschlüssel kann mit einem Wrapping Key (KEK) verschlüsselt werden. Der KEK kann als ein Passwort angesehen werden, das der Host 101 dem selbstverschlüsselnden Speichergerät 122 zur Verfügung stellt, um den Zugriff auf das Gerät 122 freizugeben, da das Gerät 122 den Medienzugriffsschlüssel (und damit den Medienzugriffsschlüssel zum Ver- und Entschlüsseln von Daten) ohne den KEK nicht entschlüsseln kann. Das selbstverschlüsselnde Speichergerät 122 verwendet den KEK zur Entschlüsselung des Medienverschlüsselungsschlüssels, und das selbstverschlüsselnde Speichergerät 122 speichert den KEK nicht.
In Fortsetzung des Beispiels kann ein UEFI 111 des Hosts 101 (z. B. ein CPU-Kern 102, der UEFI-Befehle ausführt) beim Booten der Computerplattform 100 das Vorhandensein des selbstverschlüsselnden Speichergeräts 122 erkennen und eine Berechtigungsverwaltung für das Gerät 122 durchführen. Diese Verwaltung der Berechtigungsnachweise kann beinhalten, dass das UEFI 111 Maßnahmen wie die Feststellung, ob ein KEK für das selbstverschlüsselnde Speichergerät 122 eingerichtet wurde, durchführt. Wenn der KEK eingerichtet wurde, ruft das UEFI 111 eine Geheimverwaltungs-API 147 auf, um den KEK aus dem sicheren Speicher 144 abzurufen, so dass das UEFI 111 den abgerufenen KEK an das Laufwerk 122 weitergeben kann.
Wie hier weiter beschrieben, kann ein Geheimnis 145 in Übereinstimmung mit weiteren Implementierungen ein anderes Geheimnis als ein KEK sein. Im Allgemeinen bezieht sich ein „Geheimnis“, wie es hier verwendet wird, auf Daten, die eine sicherheitsgeschützte Entität oder ein Artefakt darstellen, wie z. B. einen kryptografischen Schlüssel, einen Berechtigungsnachweis, ein Zertifikat, einen Messungshash, eine kryptografische Plattformidentität, einen Seed, ein Passwort und so weiter. Das „Verwalten“ eines Geheimnisses 145 bezieht sich im Allgemeinen auf die Steuerung oder Regelung von Aspekten, die mit der Speicherung und dem Zugriff auf das Geheimnis 145 zusammenhängen, wie z. B. das Lesen oder Abrufen des Geheimnisses 145 aus dem sicheren Speicher 144; das Schreiben des Geheimnisses 145 in den sicheren Speicher 144; das Erzeugen eines Geheimnisses 145, das in dem sicheren Speicher 144 gespeichert werden soll (z. B., Erzeugen eines kryptographischen Schlüssels); Löschen des Geheimnisses 145 aus dem sicheren Speicher 144; Versiegeln eines Geheimnisses 145 mit einem oder mehreren Mess-Hashes oder einem oder mehreren Mess-Digest-Werten (z. B. PCR-Werten); Entsiegeln des Geheimnisses 145; und so weiter.
Ein Blade-Server ist ein Beispiel für eine Computerplattform 100 gemäß einer Beispielimplementierung. Bei der Computerplattform 100 kann es sich jedoch gemäß weiteren Implementierungen auch um eine andere Plattform als einen Blade-Server handeln, beispielsweise um einen Rack-Server, ein Speicher-Array, einen modularen Switch, einen tragbaren Computer, ein Smartphone, einen Client, einen Desktop und so weiter.
Unabhängig von ihrer besonderen Form umfasst die Computerplattform 100 Hardware, die in der Lage ist, maschinenausführbare Befehle zu verarbeiten, sowie einen Rahmen oder ein Gehäuse, an dem die Hardware befestigt ist. So kann die Computerplattform 100 beispielsweise eine oder mehrere Hauptplatinen umfassen, die an einem Gehäuse befestigt werden können, und jede Hauptplatine kann ein oder mehrere Multicore-CPU-Halbleiterpakete (oder „Sockel“ oder „Chips“) enthalten. Bei Implementierungen, in denen die Computerplattform 100 ein Blade-Server ist, kann der Blade-Server beispielsweise einen Formfaktor, eine oder mehrere mechanische Verriegelungen und entsprechende elektrische Anschlüsse aufweisen, damit der Blade-Server in eine entsprechende Server-Blade-Öffnung oder einen Steckplatz in einem rackmontierten Blade-Gehäuse eingebaut und daraus entfernt werden kann.
Ein „BMC“ oder „Baseboard Management Controller“ ist ein spezialisierter Dienstprozessor, der den physischen Zustand eines Servers oder anderer Hardware mithilfe von Sensoren überwacht und über ein Verwaltungsnetzwerk mit einem Verwaltungssystem kommuniziert. Der Baseboard-Management-Controller kann auch mit Anwendungen kommunizieren, die auf Betriebssystemebene ausgeführt werden, und zwar über einen IOCTL-Schnittstellentreiber (Input/Output Controller), eine REST-Anwendungsprogrammschnittstelle (API) oder einen anderen Systemsoftware-Proxy, der die Kommunikation zwischen dem Baseboard-Management-Controller und Anwendungen erleichtert. Der Baseboard-Management-Controller kann auf Hardware-Ebene auf Hardware-Geräte zugreifen, die sich in einem Servergehäuse befinden, einschließlich des Systemspeichers. Der Baseboard-Management-Controller kann in der Lage sein, die Hardware-Geräte direkt zu verändern. Der Baseboard-Management-Controller kann unabhängig vom Betriebssystem des Systems arbeiten, in dem der Baseboard-Management-Controller angeordnet ist. Der Baseboard-Management-Controller kann sich auf der Hauptplatine oder der Hauptplatine des Servers oder eines anderen zu überwachenden Geräts befinden. Die Tatsache, dass ein Baseboard-Management-Controller auf der Hauptplatine des zu überwachenden Servers/der zu überwachenden Hardware montiert oder anderweitig mit dem zu überwachenden Server/der zu überwachenden Hardware verbunden oder daran angebracht ist, verhindert nicht, dass der Baseboard-Management-Controller als vom Server/der zu überwachenden Hardware „getrennt“ betrachtet wird. Wie hierin verwendet, hat ein Baseboard-Management-Controller Verwaltungsfunktionen für Teilsysteme eines Computergeräts und ist von einer Verarbeitungsressource getrennt, die ein Betriebssystem eines Computergeräts ausführt. Der Baseboard-Management-Controller ist getrennt von einem Prozessor, z. B. einer Zentraleinheit, die ein High-Level-Betriebssystem oder einen Hypervisor auf einem System ausführt.
In Übereinstimmung mit Beispielimplementierungen kann der Host 101 einen oder mehrere CPU-Kerne 102 (z. B. CPU-Verarbeitungskerne, Halbleiter, die CPU-Prozessorkerne enthalten, usw.) und Speichervorrichtungen enthalten, die mit der/den CPU(s) 102 verbunden sind, um einen Systemspeicher 104 zu bilden. Die CPU-Kerne 102 können mit einer oder mehreren I/O-Brücken 106 gekoppelt sein, die die Kommunikation zwischen den CPU-Kernen 102 und dem BMC 129 sowie die Kommunikation mit verschiedenen I/O-Geräten ermöglichen, z. B. mit Speicherlaufwerken 122, einem oder mehreren Netzwerkschnittstellen-Controllern (NICs) 124, einem oder mehreren USB-Geräten (Universal Serial Bus) 126, I/O-Geräten, einem Videocontroller und so weiter. Darüber hinaus kann die Computerplattform 100, wie ebenfalls in 1 dargestellt, ein oder mehrere Peripheral Component Interconnect Express (PCIe)-Geräte 110 (z. B. PCIe-Erweiterungskarten) enthalten, die über entsprechende individuelle PCIe-Busse 108 mit den CPU-Kernen 102 verbunden sein können. Gemäß einer weiteren Beispielimplementierung können die PCIe-Geräte 110 mit der/den E/A-Brücke(n) 106 gekoppelt werden, anstatt mit den CPU-Kernen 102 gekoppelt zu sein. In weiteren Implementierungen können die E/A-Brücke(n) 106 und die PCIe-Schnittstellen Teil des CPU-Kerns 102 sein.
In Übereinstimmung mit Beispielimplementierungen kann eines von mehreren Speichermodulen der Computerplattform 100 einen nichtflüchtigen Speicher 168 bilden, der Firmware 170 speichert. Wie in 1 dargestellt, kann der nichtflüchtige Speicher 168 in Übereinstimmung mit einigen Implementierungen über einen Bus 167 (z. B. einen SPI-Bus (Serial Peripheral Interconnect)) mit Komponenten des BMC 129 verbunden sein. Gemäß Beispielimplementierungen enthält die Firmware 170 Anweisungen, die von einem Hardwaresicherheitsprozessor 142 der sicheren Enklave 140 des BMC 129 (als Teil der Sicherheitsebene des BMC) ausgeführt werden; Anweisungen, die von dem/den allgemeinen Verarbeitungskern(en) 154 des BMC 129 (d. h. dem Firmware-Stack, der der Verwaltungsebene des BMC 129 entspricht) ausgeführt werden, und Anweisungen, die von der/den CPU(s) 102 ausgeführt werden, um das Computersystem 100 zu starten und Laufzeitdienste bereitzustellen.
Im Allgemeinen können die Speichervorrichtungen, die den Systemspeicher 104, den Firmware-Speicher 168 sowie andere hier beschriebene Speicher und Speichermedien bilden, aus nicht transitorischen Speichervorrichtungen wie Halbleiterspeichervorrichtungen, Flash-Speichervorrichtungen, Memristoren, Phasenwechsel-Speichervorrichtungen, einer Kombination aus einer oder mehreren der vorgenannten Speichertechnologien usw. gebildet werden. Darüber hinaus können die Speichervorrichtungen flüchtige Speichervorrichtungen (z. B. dynamische Direktzugriffsspeicher (DRAM), statische Direktzugriffsspeicher (SRAM) usw.) oder nichtflüchtige Speichervorrichtungen (z. B. Flash-Speicher, Festwertspeicher (ROM) usw.) sein, sofern hier nicht anders angegeben.
In Übereinstimmung mit einigen Implementierungen können eine oder mehrere NICs 124 intelligente Eingabe-/Ausgabe-Peripheriegeräte oder „intelligente E/A-Peripheriegeräte“ sein, die Backend-E/A-Dienste für eine oder mehrere Anwendungen 115 (oder Anwendungsinstanzen) bereitstellen, die auf der Computerplattform 100 ausgeführt werden. In Übereinstimmung mit einigen Implementierungen können eines oder mehrere der PCIe-Geräte 110 intelligente E/A-Peripheriegeräte sein.
Der BMC 129 kann eine Verwaltungsebene und eine Sicherheitsebene umfassen, die von der Verwaltungsebene isoliert ist. Genauer gesagt umfasst der BMC 129 gemäß Beispielimplementierungen einen oder mehrere Hauptverarbeitungskerne 154, die maschinenausführbare Anweisungen ausführen, um Verwaltungsfunktionen für die Computerplattform 100 durchzuführen. Diese Anweisungen können dem Firmware-Management-Stack des BMC 129 entsprechen. Indem die Hauptprozessorkerne 154 den Firmware-Verwaltungsstapel ausführen, kann die BMC 129 beispielsweise eine Vielzahl von Verwaltungsfunktionen für den Host 101 ausführen, wie z. B. die Überwachung von Sensoren, die Überwachung des Betriebssystemstatus, die Überwachung des Energiestatus, die Protokollierung von Computersystemereignissen, die Bereitstellung einer Fernkonsole, die Bereitstellung von ferngesteuerten Funktionen und anderen Technologien für die virtuelle Präsenz und so weiter.
Die Ausführung des Firmware-Verwaltungsstapels durch die Hauptverarbeitungskerne 154 kann dazu führen, dass der BMC 129 als Agent für den Host 101 dient, um einer Verwaltungseinheit, wie dem Fernverwaltungsserver 190, die Fernverwaltung des Host 101 zu ermöglichen. Der Fernverwaltungsserver 190 kann sich je nach Implementierung physisch in einem anderen Rack, Blade-Server, Rechenzentrum und/oder an einem anderen geografischen Standort als die Computerplattform 100 befinden. Als Beispiel für die BMC 129, die als Agent für den Host 101 dient, um die Fernverwaltung des Hosts 101 zu ermöglichen, kann die BMC 129 eine Fernkonsole für den Host 101 für eine Vielzahl von Zwecken bereitstellen, wie z. B. KVM-Funktionen, virtuelle Stromversorgungsfunktionen, virtuelle Medienverwaltungsfunktionen usw. Der Remote-Management-Server 190 kann mit dem BMC 129 über die Netzwerkstruktur 161 kommunizieren, selbst wenn der Host 101 ausgeschaltet ist und selbst wenn noch keine Software auf dem Host 101 installiert wurde. Als weitere Beispiele dafür, dass die BMC 129 als Agent für den Host 101 dient, kann der Fernverwaltungsserver 190 mit der BMC 129 über die Netzwerkstruktur 161 kommunizieren, um Zustandsinformationen zu erhalten (z. B., Temperatursensormesswerte, Manipulationssensormesswerte, Boot-Status, Fehleranzeigen, Sicherheitsprüfungsfehler usw.) über den Host 101 zu erhalten; virtuelle Medien für den Host 101 einzurichten; den Host 101 einzuschalten; den Host 101 auszuschalten; eine Wiederherstellungsaktion für den Host 101 einzuleiten (z. B. eine Betriebssystemwiederherstellung einzuleiten); einen Boot-Pfad für den Host 101 festzulegen usw. In Übereinstimmung mit Beispielimplementierungen kann die sichere Enklave 140 des BMC 129 Plattformmanifeste (z. B. Manifeste, die Integritätsmessungen von Softwarekomponenten und Hardwarekomponentenidentitäten darstellen) an den Fernverwaltungsserver 190 liefern, so dass der Server 190 die Plattformmanifeste validieren kann.
Darüber hinaus kann der Fernverwaltungsserver 190 in Übereinstimmung mit einigen Implementierungen mit dem BMC 129 kommunizieren, um zu steuern, ob die Computerplattform 100 in der Lage ist, „der Flotte beizutreten“ oder in einem Netzwerk anderer Plattformen (z. B. einem Netzwerk von Servern) aktiv zu werden. Beispielsweise kann das UEFI 11 oder das Betriebssystem 113 in Reaktion auf das Hochfahren der Computerplattform 100 als Teil einer Anforderung, der Flotte beizutreten, die sichere Enklave 140 auffordern (z. B. eine Sicherheitsdienst-API-Anforderung), dem Fernverwaltungsserver 190 einen Schlüssel bereitzustellen, der es der Computerplattform 100 ermöglicht, der Flotte beizutreten. Bei dem Schlüssel kann es sich beispielsweise um ein signiertes Manifest des BMC 129 und andere Hashes, ein Hardware-Identitätszertifikat (z. B. ein IDevID-Zertifikat) und ein Nonce (zur Verhinderung von Wiederholungen) handeln. Als Reaktion auf den API-Aufruf, der der Anforderung des Schlüssels entspricht, kann die sichere Enklave 140 die erforderlichen Hashes extrahieren, das Hardware-Identitätszertifikat extrahieren, den Schlüssel generieren und den Schlüssel an den Remote-Management-Server 190 übermitteln.
Im Allgemeinen kann die Netzwerkstruktur 161 mit einem oder mehreren Typen von Kommunikationsnetzwerken verbunden sein, wie (als Beispiele) Fibre-Channel-Netzwerke, Gen-Z-Fabrics, dedizierte Managementnetzwerke, lokale Netzwerke (LANs), Weitverkehrsnetzwerke (WANs), globale Netzwerke (z. B. das Internet), drahtlose Netzwerke oder eine beliebige Kombination davon.
In Übereinstimmung mit Beispielimplementierungen führen die CPU-Kerne 102 maschinenausführbare Befehle (d. h. „Software“) aus, um eine oder mehrere Komponenten zu bilden, die die Geheimhaltungsmanagement-APls 147 aufrufen können, um Geheimnisse 145 zu verwalten, die in dem sicheren Speicher 144 gespeichert sind. Zu diesen Komponenten können beispielsweise das UEFI 111, ein BIOS (Basic Input/Output System), ein Betriebssystem 113 und Anwendungen 115 gehören. In diesem Zusammenhang ist eine „API“ eine Softwareschnittstelle, die mit einer Reihe von Regeln verbunden ist, die festlegen, wie eine Einheit eine oder mehrere Funktionen, die von der Softwareschnittstelle bereitgestellt werden, anfordern oder aufrufen kann. Ein Anforderer kann einen API-Aufruf oder eine Anforderung an eine API 147 zur Verwaltung eines Geheimnisses 144 übermitteln.
DerAPI-Aufruf kann Daten enthalten, die einen Befehl (z. B. einen Schreib- oder Lesebefehl) zur Verwaltung eines Geheimnisses 144 darstellen, einen oder mehrere Parameter des Befehls, eine Kennung des Geheimnisses 144, Anmeldedaten des Anfragenden, der den API-Aufruf tätigt, usw. In Übereinstimmung mit Beispielimplementierungen können die APIs zur Verwaltung von Geheimnissen 147 sichere Speicherdienste für die Zwecke der Verwaltung der Speicherung der sicheren Geheimnisse 145 im sicheren Speicher 144 bereitstellen.
Als Beispiele für die von den APIs zur Verwaltung von Geheimnissen 147 bereitgestellten Speicherdienste können die APIs zur Verwaltung von Geheimnissen 147 Dienste zum Speichern von Messungshashes, zum Laden von Referenzmessungshashes, zum Aufbau mindestens eines Teils einer Root-of-Trust-Messkette, zum Speichern kryptografischer Schlüssel, zum Abrufen kryptografischer Schlüssel, zum Erzeugen kryptografischer Schlüssel, zum Validieren eines Firmware-Images, zum Abrufen einer kryptografischen Plattformidentität, zum Erstellen von Zertifikaten, zum Speichern von Zertifikaten, zum Hinzufügen von Zertifikaten, zum Löschen von Zertifikaten, zum Versiegeln kryptografischer Schlüssel, zum Entsiegeln kryptografischer Schlüssel usw. bereitstellen. Bei den API-Anforderungen kann es sich gemäß den Beispielimplementierungen um Redfish-API-Anforderungen, IPMI-API-Anforderungen (Intelligent Platform Management Interface) oder andere API-Anforderungen handeln.
Eine API-Anforderung und eine entsprechende API-Antwort sind mit einer Sitzung oder einem Austausch zwischen dem Anforderer (z. B. einer Entität des Hosts 101, wie dem Betriebssystem 113 oder dem UEFI 111) und dem „Antwortenden“ oder der sicheren Enklave 140 verbunden. Gemäß Beispielimplementierungen können der/die Verarbeitungskern(e) 154 des BMC 129 (als Teil der BMC-Verwaltungsebene) als Proxy für die sichere Enklave 140 (und für den Sicherheitsprozessor 142) dienen, um API-Anforderungen von Anforderern an die sichere Enklave 140 zu übermitteln und die entsprechenden Antworten von der sicheren Enklave 140 an die Anforderer zu übermitteln. So kann ein Anforderer beispielsweise Daten, die eine einer bestimmten geheimen Verwaltungs-API 147 entsprechende Anforderung darstellen, in einen Speicherbereich schreiben, der mit der Verwaltungsebene des BMC verbunden ist. Der/die Verarbeitungskern(e) 154 kann/können dann mit der sicheren Enklave 140 kommunizieren, um die Anforderung zur Verarbeitung an die sichere Enklave 140 weiterzuleiten. Darüber hinaus kann (können) der (die) Verarbeitungskern(e) 154 mit der sicheren Enklave 140 kommunizieren, um die Antwort auf die Anfrage zu empfangen und die Antwort dann an den Anfragenden zu übermitteln.
Um dem Anfragenden die Sicherheit zu geben, dass der Datenaustausch nicht manipuliert wurde, kann mindestens eine der beiden Komponenten, Anfrage oder Antwort, „verpackt“ werden. "In diesem Zusammenhang bezieht sich das „Wrapping“ einer Anfrage oder einer Antwort auf die Anwendung eines kryptographischen Sicherheitsschutzes auf die Anfrage oder die Antwort.
Als spezifischeres Beispiel für das Wrapping kann ein Anforderer eine asymmetrische Verschlüsselung unter Verwendung eines öffentlichen Schlüssels anwenden, um Inhalte zu verschlüsseln, die einem oder mehreren vordefinierten Feldern oder Parametern (z. B. einem Anforderer-Identifikator, einem Befehl usw.) eines API-Aufrufs entsprechen, um einen entsprechenden Chiffretext zu bilden. Der öffentliche Schlüssel kann Teil eines Paares (öffentlicher Schlüssel, privater Schlüssel) sein, das mit einer asymmetrischen Chiffre verwendet wird, und die sichere Enklave 140 kann Eigentümer des privaten Schlüssels sein. Der Antragsteller fügt den Chiffretext in den Antrag ein, und die sichere Enklave 140 entschlüsselt den Chiffretext mit dem privaten Schlüssel. Auf diese Weise kann eine andere Einheit als die sichere Enklave 140 (die den privaten Schlüssel besitzt) den verschlüsselten Inhalt der Anfrage nicht entschlüsseln. In Übereinstimmung mit weiteren Implementierungen kann der Anfragende einen Sitzungsschlüssel generieren und eine symmetrische Chiffre (anstelle der oben beschriebenen asymmetrischen Chiffre) verwenden, um das/die vordefinierte(n) Feld(er) oder Parameter des API-Aufrufs zu verschlüsseln, um den entsprechenden Chiffretext zu bilden. Bei diesen Implementierungen kann der Anforderer den Sitzungsschlüssel mit dem öffentlichen Schlüssel (des Paares (öffentlicher Schlüssel, privater Schlüssel)) unter Verwendung der asymmetrischen Chiffre verschlüsseln und den mit dem Sitzungsschlüssel verschlüsselten Chiffretext und den verschlüsselten Sitzungsschlüssel in die Anforderung aufnehmen. Als Reaktion auf den Empfang der Anforderung kann die sichere Enklave 140 den verschlüsselten Sitzungsschlüssel unter Verwendung des privaten Schlüssels (des Paares (öffentlicher Schlüssel, privater Schlüssel)) entschlüsseln, und die sichere Enklave 140 kann den mit dem Sitzungsschlüssel verschlüsselten Chiffretext unter Verwendung des Sitzungsschlüssels entschlüsseln.
Im weiteren Verlauf des Beispiels kann die sichere Enklave 140 nach der Entschlüsselung der Anfrage mit der Verarbeitung der Anfrage und der Erzeugung einer entsprechenden Antwort fortfahren. Die sichere Enklave 140 kann gemäß Beispielimplementierungen einen Inhalt (der einem oder mehreren vordefinierten Feldern oder Parametern der API-Antwort entspricht) mit dem privaten Schlüssel (des Paares (öffentlicher Schlüssel, privater Schlüssel)) signieren, um eine Signatur zu erzeugen, die die sichere Enklave 140 in die Antwort aufnimmt. Auf diese Weise kann der Anfragende auf der Grundlage seiner Berechnung der Signatur unter Verwendung des öffentlichen Schlüssels und des Vergleichs der berechneten Signatur mit der in der Antwort enthaltenen Signatur die Antwort authentifizieren, um zu überprüfen, ob die Antwort von der sicheren Enklave 140 stammt. In Übereinstimmung mit weiteren Implementierungen kann die sichere Enklave 140 den Inhalt der Antwort mit dem Sitzungsschlüssel verschlüsseln.
Ein oder mehrere Geheimnisse 145 können in Übereinstimmung mit Beispielimplementierungen Geheimnisse des BMC 129 sein, und eine Anforderung zur Verwaltung eines Geheimnisses 145 kann von der Verwaltungsebene des BMC ausgehen. Beispielsweise kann in Übereinstimmung mit einigen Implementierungen ein Hauptverarbeitungskern 154 als Reaktion auf die Ausführung des Verwaltungsstapels ein Anforderer sein und eine Anforderung zum Zugriff auf ein Geheimnis 145 bereitstellen. Der Prozessorkern 154 kann Daten, die die Anforderung darstellen, an die sichere Enklave 140 übermitteln und Daten von der sicheren Enklave 140 empfangen, die eine Antwort auf die Anforderung darstellen. Daher kann der sichere Speicher 144 in Übereinstimmung mit einigen Implementierungen Geheimnisse 145 des Hosts 101 und Geheimnisse 145 des BMC 129 speichern.
Die sichere Enklave 140 der BMC 129 ist gemäß Beispielimplementierungen von der Verwaltungsebene (und anderen nicht sicheren Komponenten der BMC 129, die sich außerhalb der sicheren Enklave 140 befinden) isoliert. In Übereinstimmung mit Beispielimplementierungen umfasst die sichere Enklave 140 eine Hardware- oder Silizium-RoT (als „SRoT“ bezeichnet), die Sicherheitsmerkmale für die BMC 129 bereitstellt.
Insbesondere speichert die sichere Enklave 140 in Übereinstimmung mit Beispielimplementierungen einen unveränderlichen Fingerabdruck, der von der SRoT-Engine 143 verwendet wird, um Teile der Firmware 170 zu validieren. Der BMC 129 hält die Hauptverarbeitungskerne 154 und den Sicherheitsprozessor 142 fest, wenn der BMC 129 eingeschaltet oder zurückgesetzt wird. Als Reaktion auf das Einschalten oder Zurücksetzen validiert die SRoT-Engine 143 einen anfänglichen Teil der Firmware 170 und lädt ihn dann in einen Speicher 151 der sicheren Enklave 140, so dass diesem Firmware-Teil nun vertraut wird. Das BMC 129 hebt dann den Zugriff auf den Sicherheitsprozessor 142 auf, damit dieser booten und die geladenen Firmware-Anweisungen ausführen kann. Durch die Ausführung der Firmware-Anweisungen kann der Sicherheitsprozessor 142 dann einen anderen Teil der Firmware 170 validieren, der einem Teil des Management-Firmware-Stacks des BMC entspricht, und nach der Validierung diesen Teil des Firmware-Stacks in einen Speicher 155 des BMC 129 laden. Der Teil des Management-Firmware-Stacks kann dann von dem/den Hauptverarbeitungskern(en) 154 ausgeführt werden (wenn er aus dem Reset freigegeben wird), was den/die Hauptverarbeitungskern(e) 154 veranlasst, zusätzliche Teile der Firmware 170 zu laden und die geladenen Teile in einem Speicher 164 abzulegen. Der Zugriff auf den Speicher 164 kann zusätzliche Trainings- und Initialisierungsschritte beinhalten (z. B. Trainings- und Initialisierungsschritte, die in der DDR4-Spezifikation festgelegt sind). Diese Anweisungen können von dem validierten Teil des Firmware-Management-Stacks des BMC im Speicher 155 ausgeführt werden. In Übereinstimmung mit Beispielimplementierungen kann die sichere Enklave 140 den Speicher 155 sperren, um eine Änderung oder Manipulation des validierten Teils bzw. der validierten Teile, die in dem Speicher 155 gespeichert sind, zu verhindern.
Daher kann die Vertrauenskette in Übereinstimmung mit Beispielimplementierungen von der SRoT der BMC auf den Firmware-Management-Stack ausgedehnt werden, der von den Hauptverarbeitungskernen 154 der BMC ausgeführt wird.
In Übereinstimmung mit Beispielimplementierungen ist die BMC 129 so konstruiert, dass sie eine bestimmte Domäne oder Entität der BMC 129 daran hindert, sich einzuschalten oder aus dem Reset zu kommen, bis die sichere Enklave 140 die Domäne/Entität validiert. Darüber hinaus kann die BMC 129 in Übereinstimmung mit Beispielimplementierungen Komponenten der BMC 129 daran hindern, auf Ressourcen der BMC 129 und Ressourcen der Computerplattform 100 zuzugreifen, bis die sichere Enklave 140 die Ressourcen genehmigt/validiert hat. Das BMC 129 kann Busfilterung und -überwachung durchführen (z. B. Busfilterung und -überwachung für einen SPI-Bus, einen Systemmanagement-Bus (SMB), einen Inter-Intergrade Component (I² C)-Bus, einen Improved I² C (I³ C)-Bus usw.), um unerwünschten Zugriff auf Busgeräte zu verhindern. Beispielsweise kann die BMC 129 die Busfilterung und -überwachung für den Bus 167 übernehmen.
In Übereinstimmung mit Beispielimplementierungen kann der BMC 129 einen Netzwerkschnittstellen-Controller (NIC) 158 (z. B. ein Halbleiterpaket oder „Chip“) enthalten, der es dem BMC 129 ermöglicht, (über die Netzwerkstruktur 161) mit Einheiten zu kommunizieren, die sich außerhalb der Computerplattform 100 befinden, wie z. B. dem Fernverwaltungsserver 190. Der BMC 129 kann darüber hinaus eine oder mehrere zusätzliche Kommunikationsschnittstellen 156 enthalten, wie z. B. eine USB-Schnittstelle, eine PCI-Schnittstelle, eine SPI-Schnittstelle, eine I³ C-Busschnittstelle und so weiter. Darüber hinaus kann das BMC 129 gemäß Beispielimplementierungen Komponenten enthalten, die in 1 nicht speziell dargestellt sind, wie z. B. eine physische Speicherschnittstelle, eine Speichercontroller-Schnittstelle, einen Videocontroller usw.
Gemäß Ausführungsbeispielen umfasst die BMC 129 ein Halbleiterpaket 153 (oder „Chip“), das zumindest einige der Komponenten der BMC 129, wie die Hauptverarbeitungskerne 154 und die sichere Enklave 140, enthält. Das Halbleiterpaket 153 kann einen oder mehrere Halbleiterchips enthalten. In Übereinstimmung mit einigen Implementierungen kann der sichere Speicher 144 in einem Halbleiterchip hergestellt werden, und die übrigen Komponenten der BMC 129 können in einem oder mehreren zusätzlichen Halbleiterchips hergestellt werden. Gemäß Ausführungsbeispielen sind die Anschlüsse (z. B. Leitungen, Stifte, Kugeln usw.) des sicheren Speichers 144, wie z. B. die Anschlüsse, die für die Kommunikation von Daten-, Steuer- und Adresssignalen mit dem sicheren Speicher 144 verwendet werden, nicht außerhalb des Halbleitergehäuses 153 exponiert. Mit anderen Worten, in Übereinstimmung mit Beispielimplementierungen sind die Anschlüsse des sicheren Speichers 144 physisch von dem Bereich außerhalb des Halbleitergehäuses 153 isoliert, was verhindert, dass physische Sondenmanipulationen verwendet werden, um die Integrität oder Sicherheit der Daten, die in dem sicheren Speicher 144 gespeichert sind, zu beeinträchtigen.
Wie in 2 gezeigt, kann die sichere Enklave 140 ein komplettes System-on-Chip (SOC) sein und sich innerhalb einer streng kontrollierten kryptografischen Grenze 204 befinden. Im Allgemeinen können die Komponenten der sicheren Enklave 140 über eine Businfrastruktur 205 kommunizieren. In Übereinstimmung mit Beispielimplementierungen kann die Businfrastruktur 205 Merkmale wie einen Datenbus, einen Steuerbus, einen Adressbus, einen Systembus, einen oder mehrere Busse, eine oder mehrere Brücken usw. umfassen. Der Sicherheitsprozessor 142 kann einen oder mehrere Prozessorkerne 208 (z. B. CPU-Kerne), einen Befehlscache 209 und einen Datencache 211 enthalten. Der flüchtige Speicher 151 kann z. B. ein statischer Direktzugriffsspeicher (SRAM) sein und Daten speichern, die Messungen der vertrauenswürdigen Datenverarbeitungsbasis (TCB) darstellen, wie z. B. eine oder mehrere PCR-Banken. Der sichere Speicher 144 kann zum Beispiel ein nichtflüchtiger RAM (NVRAM) sein. Die sichere Enklave 140 kann Register 240 enthalten. Bei den Registern 240 kann es sich um Softwareregister, Hardwareregister oder eine Kombination aus Hardware- und Softwareregistern handeln, abhängig von der jeweiligen Implementierung. In einigen Implementierungen umfassen die Register 240 beispielsweise kryptografisch sichere Register, wie Software-PCRs. Darüber hinaus können die Register 240 gemäß Beispielimplementierungen Betriebsregister umfassen, wie z. B. Hardware-Register, die Steuer-, Status- und Konfigurationsfunktionen für die sichere Enklave 140 bereitstellen.
Die sichere Enklave 140 umfasst gemäß Beispielimplementierungen eine sichere Brücke 214, die den Zugriff auf die sichere Enklave 140 kontrolliert (d. h. eine Firewall für die sichere Enklave 140 einrichtet), und zwar über eine Sicherheitsdienst-API (z. B. eine Geheimverwaltungs-API 147). Bezug nehmend auf 2 in Verbindung mit 1 kann ein Hauptverarbeitungskern 154 der BMC 129, wenn er als Proxy dient, Daten, die der Anfrage entsprechen und mit einer Sicherheitsdienst-API übereinstimmen, über eine Verbindung 218 in einen Anfragepuffer 270 der sicheren Brücke 214 schreiben. Bei der Verbindung 218 kann es sich beispielsweise um einen Bus 218 (z. B. einen SPI-Bus) oder eine interne Verbindungsstruktur handeln, wie die Advanced Microcontroller Bus Architecture (AMBA)-Struktur oder die Advanced eXtensible Interface (AXI)-Struktur. Gemäß Beispielimplementierungen können ein oder mehrere Sicherheitsverarbeitungskern(e) 208 die Geheimhaltungsanforderung verarbeiten und Daten in einem Antwortpuffer 272 speichern. Die Daten stellen eine Antwort (z. B. eine Ablehnung, eine Bestätigung, Daten, die angeforderte Daten darstellen, usw.) auf die Geheimverwaltungsanforderung dar, und ein Hauptverarbeitungskern 154 kann die Daten aus dem Antwortpuffer 272 lesen und die Antwort an den Anforderer weiterleiten. In Übereinstimmung mit einigen Implementierungen kann die sichere Brücke 214 überprüfen, ob der Anfragende Zugriffsrechte für eine gegebene Anfrage hat (d.h. überprüfen, ob die sichere Brücke 214 die Anfrage akzeptieren und verarbeiten oder ablehnen kann), basierend auf einem oder mehreren Parametern der Anfrage, wie z.B. Parameter, die die Anmeldeinformationen des Anfragenden darstellen (z.B. eine Anforderungskennung und ein Passwort, einen Schlüssel oder ein Zertifikat), einen Befehl, Befehlsoperanden und so weiter. In Übereinstimmung mit einigen Implementierungen kann die Sicherheitsdienst-API von den APIs zur Verwaltung von Geheimnissen 147 getrennt sein; und in Übereinstimmung mit weiteren Beispielimplementierungen kann die Sicherheitsdienst-API Teil jeder API zur Verwaltung von Geheimnissen 147 sein.
Die sichere Brücke 214 kann eine zusätzliche vorgelagerte Schnittstelle bereitstellen, damit die sichere Enklave 140 die Verbindung 218 „erreichen“ kann. Die sichere Enklave 140 kann die vorgelagerte Schnittstelle nutzen, um ihre Firmware zu erhalten und im Allgemeinen die Firmware 170 zu validieren (1). Die sichere Brücke 214 kann Filterung und Überwachung auf der Verbindungsleitung 218 einsetzen, um den unbefugten Zugriff auf den Speicher 151 zu verhindern.
Wie ebenfalls in 2 dargestellt, kann die sichere Enklave 140 gemäß Beispielimplementierungen eine Manipulationserkennungsschaltung 234 enthalten, die verschiedene Umgebungssensorsignale 236 (z. B. Sensorsignale, die eine Temperatur, eine Taktrate, eine Spannung usw. darstellen) empfängt, um eine böswillige Manipulation der Betriebsumgebung der sicheren Enklave zu erkennen, so dass geeignete Maßnahmen ergriffen werden können, wenn dies geschieht. Auf diese Weise kann die Manipulationserkennungsschaltung 234 in Übereinstimmung mit Beispielimplementierungen, wenn eine Manipulation durch die Manipulationserkennungsschaltung 234 erkannt wird, eine oder mehrere Korrekturmaßnahmen durch die sichere Enklave 140 einleiten, um die erkannte Sicherheitsbeeinträchtigung zu beheben. Wenn die Manipulationserkennungsschaltung 234 eine erkannte Manipulation anzeigt, kann die sichere Enklave 140 beispielsweise sensible Informationen entfernen (z. B. bestimmte Geheimnisse löschen, wie die Geheimnisse 145, die im sicheren Speicher 144 gespeichert sind); ein Signal oder eine Nachricht ausgeben, um eine externe Komponente (z. B. einen Hauptverarbeitungskern 154, das Betriebssystem 113 (1), den Fernverwaltungsserver 190 (1) usw.) auf die Manipulation aufmerksam zu machen; den/die Hauptverarbeitungskern(e) 154 anhalten oder extern zurücksetzen; usw. In Übereinstimmung mit einigen Implementierungen, wie in 2 dargestellt, kann die sichere Enklave 140 eine kryptografische Engine 270 enthalten, die in den sicheren Speicher 144 geschriebene Daten verschlüsselt und aus dem sicheren Speicher 144 gelesene Daten entschlüsselt. Abhängig von der jeweiligen Implementierung kann die Ver- und Entschlüsselung eine Advanced Encryption Standard-XOR-Encrypt-XOR-Based Tweaked-Codebook Mode with Ciphertext Stealing (oder „AES-XTS“) Blockchiffre oder eine andere Blockchiffre verwenden.
Die sichere Enklave 140 kann gemäß Beispielimplementierungen kryptografische Beschleuniger 244 enthalten, wie z. B. symmetrische und asymmetrische kryptografische Beschleuniger, die den Sicherheitsprozessor 142 bei Operationen wie Schlüsselerzeugung, Signaturvalidierung, Verschlüsselung, Entschlüsselung usw. unterstützen. Darüber hinaus können die kryptografischen Beschleuniger 244 einen echten Zufallszahlengenerator enthalten, um eine vertrauenswürdige Entropiequelle für kryptografische Operationen bereitzustellen.
Neben anderen Komponenten kann die sichere Enklave 140 gemäß Beispielimplementierungen einmalig programmierbare (OTP-)Sicherungen 258 enthalten, die Daten speichern, die wirklich unveränderliche Attribute darstellen, wie z. B. eine Silizium-Root-of-Trust-Signatur nach Secure Hash Algorithm 2 (SHA-2) (z. B. den unveränderlichen Fingerabdruck, der von der SRoT-Engine 143 verwendet wird), einen eindeutigen Bezeichner (z. B. einen Bezeichner, der zum Einsetzen eines Plattform-Identitätszertifikats verwendet wird), einen Fingerabdruck für die Sicherheitsfreigabe und so weiter. Die sichere Enklave 140 kann auch andere Komponenten enthalten, die, wie ein Fachmann wissen kann, in einer prozessorbasierten Architektur vorhanden sein können, wie z. B. Zeitgeber 254, ein Unterbrechungscontroller 250 (der Unterbrechungsauslösungsimpulse von den Zeitgebern 254 und anderen Quellen empfängt) und so weiter.
Darüber hinaus kann die sichere Enklave 140 Schnittstellen zur Unterstützung der anfänglichen Entwicklung und Fehlersuche der sicheren Enklave 140 (im Vorproduktionsmodus der sicheren Enklave 140) enthalten, die jedoch vollständig deaktiviert werden können oder geänderte Funktionen (für den Produktionsmodus der sicheren Enklave 140) aufweisen können, wenn bestimmte Sicherungen (z. B. bestimmte OTP-Sicherungen 258) durchgebrannt sind. Zu diesen Schnittstellen kann beispielsweise ein Universal Asynchronous Receiver/Transmitter (UART) 262 gehören, der für die Fehlersuche und Entwicklung der sicheren Enklave 140 verwendet werden kann und dann für den Produktionsmodus der sicheren Enklave 140 auf eine reine Sendekonfiguration gesichert wird. Gemäß einigen Implementierungen kann der UART 262 beispielsweise von den OTP-Sicherungen 258 so konfiguriert werden, dass er im Produktionsmodus der sicheren Enklave 140 einseitig Statusinformationen von der sicheren Enklave 140 liefert. Als weiteres Beispiel können die OTP-Fuses 258 in Übereinstimmung mit weiteren Implementierungen den UART 262 für den Produktionsmodus deaktivieren, so dass die gesamte Kommunikation mit dem UART 262 deaktiviert wird, um jegliche Kommunikation über die kryptografische Grenze 204 zu verhindern. Als weiteres Beispiel für eine Schnittstelle, die bei der anfänglichen Entwicklung und Fehlersuche der sicheren Enklave 140 hilfreich sein kann, aber für den Produktionsmodus geändert/deaktiviert werden kann, kann die sichere Enklave 140 eine Joint Test Action Group (JTAG)-Schnittstelle (nicht dargestellt) für den Sicherheitsprozessor 142 enthalten; und diese JTAG-Schnittstelle kann für den Produktionsmodus der sicheren Enklave 140 deaktiviert werden.
Wie aus 3 in Verbindung mit 2 hervorgeht, kann das Halbleitergehäuse 153 in Übereinstimmung mit Ausführungsbeispielen einen Chip 157-2 enthalten, in dem der sichere Speicher 144 hergestellt ist. Auf diese Weise können die Speicherzellen des sicheren Speichers 144 und zusätzliche Komponenten des sicheren Speichers 144, die zum Speichern von Daten in den Speicherzellen und zum Abrufen von Daten aus den Speicherzellen verwendet werden (z. B. Dekodierlogik, Kodierlogik, Steuersignalerzeugungslogik usw.), in dem Halbleiterchip 157-2 hergestellt werden. In Übereinstimmung mit Beispielimplementierungen kann das Halbleitergehäuse 153 ein oder mehrere zusätzliche Chips 157-1 enthalten, die die anderen Komponenten des BMC 129 enthalten. Bei der in 3 dargestellten Beispielimplementierung enthält ein Halbleiterchip 157-1 andere Komponenten 312 der sicheren Enklave 140 und Komponenten 314 der nicht sicheren Verwaltungsebene (z. B. den/die Hauptverarbeitungskern(e) 154 und den Speicher 155) der BMC 129.
Wie in 3 dargestellt, kann der sichere Speicher 144 mit dem Rest der sicheren Enklave 140 über eine Zwischenverbindung 320 zwischen den Chips 157-1 und 157-2 verbunden sein. In Übereinstimmung mit einigen Implementierungen kann die Verbindung 320 der physischen Kommunikationsschnittstelle zwischen der kryptografischen Verarbeitungsmaschine 270 (siehe 2) und dem sicheren Speicher 144 entsprechen. Die Verbindungsleitung 320 ist mit dem Halbleiterchip 153 verbunden und kann außerhalb des Halbleitergehäuses 153 nicht direkt erreicht werden. Aufgrund dieser Anordnung ist keiner der Adress-, Daten- oder Steueranschlüsse des sicheren Speichers 144 außerhalb des Halbleitergehäuses 153 zugänglich. Mit anderen Worten, das Halbleitergehäuse 153 kann externe Anschlüsse 316 haben, aber keiner dieser Anschlüsse 316 kann abgefragt werden, um die Kommunikation mit dem sicheren Speicher 144 auszuspähen. Daher kann die in 3 dargestellte Anordnung einen zusätzlichen Schutz für die im sicheren Speicher 144 gespeicherten Daten bieten.
Unter Bezugnahme auf 4 in Verbindung mit 2 können gemäß einer weiteren Beispielimplementierung, die mit der Referenznummer 408 dargestellt ist, alle Komponenten der sicheren Enklave 140, einschließlich des sicheren Speichers 144, in einem einzigen Chip 157 eines Halbleitergehäuses 400 (das das Halbleitergehäuse 153 ersetzt) hergestellt werden. Die Hauptverarbeitungskerne 154 (2) können beispielsweise in einem anderen Chip des Halbleitergehäuses 400 hergestellt werden. Gemäß weiteren Ausführungsbeispielen kann das Halbleiterpaket 400 mehrere Halbleiterchips enthalten, und bei diesen Ausführungsbeispielen kann der sichere Speicher 144 nicht in einem separaten Chip von den anderen Komponenten der sicheren Enklave 140 untergebracht sein. Gemäß weiteren Beispielimplementierungen werden die Hauptverarbeitungskerne 154 und alle Komponenten der sicheren Enklave 140 auf einem einzigen Halbleiterchip eines Halbleitergehäuses hergestellt. Als solche sind viele Implementierungen denkbar, die in den Anwendungsbereich der beigefügten Ansprüche fallen.
Zurück zu 1: In Übereinstimmung mit Beispielimplementierungen kann ein Speichergerät 122 ein NVMe-Speichergerät sein, und der sichere Speicher 144 kann Daten speichern, die einen Verschlüsselungsschlüssel (d. h. ein sicheres Geheimnis 145) für das NVMe-Speichergerät 122 darstellen. In Übereinstimmung mit einigen Implementierungen kann ein CPU-Kern 102, der eine Boot-Service-Firmware (z. B. UEFI 111 Boot-Service-Firmware) ausführt, als Reaktion auf das Booten der Computerplattform 100 das NVMe-Speichergerät 122 erkennen und ein Credential-Management für das Speichergerät 122 durchführen. Unter Bezugnahme auf 2 in Verbindung mit 1 kann der CPU-Kern 102 als Teil dieser Berechtigungsverwaltung einen API-Aufruf oder eine Anforderung an die sichere Enklave 140 übermitteln, um den Verschlüsselungsschlüssel für das NVMe-Speichergerät 122 anzufordern. Auf diese Weise kann der CPU-Kern 102 eine Anforderung übermitteln, die mit einer bestimmten Geheimverwaltungs-API 147 verknüpft ist und einen Befehl enthält, der den Schlüsselverschlüsselungsschlüssel, eine Kennung für das NVMe-Laufwerk 122, Sicherheitsberechtigungsnachweise usw. anfordert. Die sichere Brücke 214 und ein Sicherheitsverarbeitungskern 208 der sicheren Enklave 140 können die Anforderung verarbeiten und eine entsprechende Antwort liefern.
Genauer gesagt, unter Bezugnahme auf 5 in Verbindung mit 1 und 2, kann die sichere Enklave 140 in Übereinstimmung mit Beispielimplementierungen einen Prozess 500 durchführen, um eine Anfrage zum Zugriff auf ein Geheimnis 145 zu verarbeiten, wobei das Geheimnis 145 ein Schlüsselverschlüsselungsschlüssel (oder „KEK“) ist. Gemäß Block 504 umfasst der Prozess 500 den Empfang einer API-Anforderung durch die sichere Enklave 140, die einen Befehl zur Anforderung eines KEK enthält. Die sichere Enklave 140 kann eine oder mehrere Sicherheitsüberprüfungen für die API-Anforderung durchführen (Block 508). Beispielsweise kann die sichere Brücke 214 überprüfen, ob der Anfragende über die entsprechenden Berechtigungsnachweise für die Übermittlung einer API-Anforderung an die sichere Enklave 140 verfügt; ein Sicherheitsverarbeitungskern 208 kann Anweisungen ausführen, um zu überprüfen, ob der Anfragende über eine Zugriffsberechtigung für die Anforderung eines KEK verfügt, und so weiter. Als Reaktion auf die Feststellung (Entscheidungsblock 512) der sicheren Enklave 140, dass die Sicherheitsüberprüfung(en) bestanden wurde(n), kann der Sicherheitsverarbeitungskern 208 dann gemäß Block 516 Anweisungen ausführen, um den Verarbeitungskern 208 zu veranlassen, den in der API-Anforderung enthaltenen Befehl auszuführen, um auf den KEK zuzugreifen. Die Ausführung des Befehls kann beinhalten, dass der Verarbeitungskern 208 Daten aus dem sicheren Speicher 144 liest, der den KEK darstellt. Gemäß Block 520 kann die Sicherheitsenklave 140 dann eine Antwort auf die API-Anforderung geben, z. B. den KEK bereitstellen, die API-Anforderung verweigern, eine Antwort geben, dass ein KEK nicht gefunden wurde, und so weiter.
Ein weiteres Beispiel: Ein sicheres Geheimnis 145 kann ein Zertifikat sein, und die sichere Enklave 140 kann einen Prozess 600 durchführen, der in 6 dargestellt ist, um das Zertifikat zu aktualisieren oder zu löschen. Eine bestimmte API-Anfrage kann beispielsweise darauf gerichtet sein, ein mit dem Fernverwaltungsserver 190 verbundenes Zertifikat zu aktualisieren, ein mit der Computerplattform 100 verbundenes Zertifikat zu aktualisieren, ein Stammzertifikat zu aktualisieren, ein Zwischenzertifikat zu aktualisieren, ein Zertifikat zu löschen und so weiter.
Unter Bezugnahme auf 6 in Verbindung mit den 1 und 2 umfasst der Prozess 600 in Übereinstimmung mit einigen Implementierungen, dass die sichere Enklave 140 eine API-Anforderung empfängt (Block 604), die einen Befehl zur Anforderung einer Aktualisierung oder Löschung eines Zertifikats enthält. Die sichere Enklave 140 kann gemäß Block 608 eine oder mehrere Sicherheitsüberprüfungen für die API-Anforderung durchführen. Diese Sicherheitsüberprüfungen können von der sicheren Brücke 214 und/oder einem Sicherheitsverarbeitungskern 208 durchgeführt werden. Beispielsweise kann die sichere Brücke 214 als Gatekeeper der sicheren Enklave dienen, um zu überprüfen, ob der Anfragende über die entsprechenden Anmeldeinformationen verfügt, um eine API-Anforderung an die sichere Enklave 140 zu übermitteln; ein Sicherheitsverarbeitungskern 208 kann Anweisungen ausführen, um zu überprüfen, ob der Anfragende über eine Zugriffsberechtigung verfügt, um die Aktualisierung oder Löschung des Zertifikats anzufordern, und so weiter. Als Reaktion auf die Feststellung der sicheren Enklave 140 (Entscheidungsblock 612), dass die Sicherheitsprüfung(en) bestanden wurde(n), kann der Sicherheitsverarbeitungskern 208 dann gemäß Block 616 Anweisungen ausführen, um den Verarbeitungskern 208 zu veranlassen, den in der API-Anforderung enthaltenen Befehl zur Aktualisierung oder Löschung des Zertifikats auszuführen. Gemäß Block 620 kann die Sicherheitsenklave 140 dann eine Antwort auf die API-Anforderung geben, wie z. B. die Bestätigung der Löschung des Zertifikats, die Bestätigung einer Aktualisierung des Zertifikats, die Ablehnung der API-Anforderung, die Antwort, dass das Zertifikat nicht gefunden wurde, usw.
Bezug nehmend auf 2 als weiteres Beispiel für sichere Geheimnisse 145 und die APIs zur Verwaltung von Geheimnissen 147 kann sich eine bestimmte API zur Verwaltung von Geheimnissen 147 in Übereinstimmung mit weiteren Implementierungen auf das Versiegeln oder Entsiegeln eines kryptografischen Schlüssels (d. h. des Geheimnisses 145) beziehen. Beispielsweise kann der flüchtige Speicher 151 der sicheren Enklave 140 in Übereinstimmung mit einigen Implementierungen Daten speichern, die TCB-Messungen darstellen, wie z. B. PCR-Messungen. Außerdem kann das Betriebssystem 113 (1) der Computerplattform 100 Operationen durchführen, die an die TCB-Messungen gebunden sind. Beispielsweise kann das Betriebssystem 113 die TCB-Messungen verwenden, um KEK an einen bestimmten Zustand der Computerplattform 100 zu binden, wie z. B. die Bindung eines Festplattenverschlüsselungsschlüssels an einen bestimmten Satz von PCR-Werten. Das „Versiegeln“ bezieht sich darauf, dass die sichere Enklave 140 den KEK mit den PCR-Werten verschlüsselt, so dass die sichere Enklave 140 den KEK nicht entsiegelt oder entschlüsselt und den Festplattenverschlüsselungsschlüssel an das Betriebssystem 113 weitergibt, wenn die aktuellen PCR-Werte nicht mit den PCR-Werten übereinstimmen, mit denen der KEK versiegelt ist.
Als weiteres Beispiel für sichere Geheimnisse 145 und die APIs zur Verwaltung von Geheimnissen 147 kann sich eine bestimmte API zur Verwaltung von Geheimnissen 147 in Übereinstimmung mit weiteren Implementierungen auf das Versiegeln oder Entsiegeln eines Passworts (d. h. des Geheimnisses 145) mit einem bestimmten Satz von PCR-Werten beziehen. Zum Beispiel kann das Betriebssystem 113 (1) ein Kennwort mit einem bestimmten Satz von PCR-Werten versiegeln, damit das versiegelte Kennwort nach einem Neustart der Computerplattform 100 in das UEFI 111 (1) übertragen werden kann. Daher können in diesem Beispiel die APIs zur Verwaltung der Geheimnisse 147 eine API zum Versiegeln eines Kennworts mit einem Satz von PCR-Messwerten und eine API 147 zum Entsiegeln eines Kennworts auf der Grundlage eines bereitgestellten Satzes von PCR-Messwerten umfassen.
In ähnlicher Weise kann gemäß einigen Implementierungen das sichere Geheimnis 145 ein Schlüssel für ein virtuelles privates Netzwerk (VPN) sein, und die APIs zur Verwaltung des Geheimnisses 147 können eine API 147 zum Versiegeln eines VPN-Schlüssels mit einer Reihe von PCR-Messungen und eine API 147 zum Entsiegeln eines VPN-Schlüssels auf der Grundlage eines bereitgestellten Satzes von PCR-Messungen umfassen. Unabhängig von seiner besonderen Form kann das sichere Geheimnis 145 von einem Anforderer über eine oder mehrere APIs zur Verwaltung von Geheimnissen 147 sicher abgerufen werden.
Gemäß 7 enthält eine Vorrichtung 700 in Übereinstimmung mit Beispielimplementierungen einen Host 704 und einen Baseboard-Management-Controller 708. Der Baseboard-Management-Controller 708 umfasst ein Halbleiterpaket 712, und das Halbleiterpaket 712 umfasst einen Speicher 716, einen Sicherheits-Hardware-Prozessor 720 und einen Haupt-Hardware-Prozessor 724. Der Haupthardwareprozessor 724 veranlasst den Baseboard-Management-Controller 708, als Agent zu dienen, der unabhängig vom Host 704 auf die Kommunikation mit einer entfernten Verwaltungseinheit reagiert, um den Host 704 zu verwalten. Der Sicherheits-Hardwareprozessor 720 verwaltet die Speicherung eines Geheimnisses 717 des Hosts 704 im Speicher 716.
Wie in 8 gezeigt, umfasst ein Prozess 800 gemäß Beispielimplementierungen einen Baseboard-Management-Controller einer Computerplattform, der mit einer Verwaltungseinheit kommuniziert (Block 804), um einen Host der Computerplattform zu verwalten. Der Prozess 800 umfasst das Speichern (Block 808) eines sicheren Geheimnisses für die Computerplattform in einem sicheren Speicher des Basisplatinen-Verwaltungscontrollers. Der Sicherheits-Hardwareprozessor des Baseboard-Management-Controllers verwaltet (Block 812) die Speicherung des Geheimnisses.
Gemäß 9 enthält ein Halbleiterpaket 902 in Übereinstimmung mit Beispielimplementierungen einen Haupt-Hardwareprozessor 924 und eine sichere Enklave 904. Die sichere Enklave 904 umfasst einen sicheren Speicher 908 und einen Hardware-Sicherheitsprozessor 916. Der Verwaltungscontroller 900 enthält außerdem eine Kommunikationsschnittstelle 920. Der Haupt-Hardwareprozessor 924 führt Anweisungen aus, um mit einem entfernten Verwaltungsserver über die Kommunikationsschnittstelle 920 zu kommunizieren und als Reaktion auf die Kommunikation einen Host einer Computerplattform zu verwalten. Der Hardware-Sicherheitsprozessor 916 stellt eine Anwendungsprogrammierschnittstelle (API) 906 für den Host bereit, um ein Geheimnis 912 zu verwalten, das in dem sicheren Speicher 908 gespeichert ist.
Gemäß Beispielimplementierungen dient der Haupt-Hardwareprozessor als Proxy zwischen dem Sicherheits-Hardwareprozessor und dem Host. Der Proxy empfängt eine Anforderung zur Verwaltung der Speicherung des Geheimnisses von einem Anforderer des Hosts. Der Proxy leitet die Anfrage an den Sicherheits-Hardware-Prozessor weiter. Der Sicherheitshardwareprozessor liefert dem Proxy eine Antwort auf die Anfrage. Der Proxy leitet die Antwort an den Anfragenden weiter. Ein besonderer Vorteil ist, dass der Proxy den Zugriff auf den Sicherheits-Hardware-Prozessor einschränkt.
In Übereinstimmung mit Beispielimplementierungen kann der Haupt-Hardwareverarbeitungskern eine Anforderung zur Verwaltung eines Geheimnisses des Basisplatinen-Verwaltungscontrollers bereitstellen, das im sicheren Speicher gespeichert ist. Der Sicherheits-Hardwareprozessor verwaltet die Speicherung des Geheimnisses als Reaktion auf die Anforderung. Ein besonderer Vorteil besteht darin, dass der Baseboard-Management-Controller sowohl Geheimnisse des Hosts als auch Geheimnisse des Baseboard-Management-Controllers speichern kann.
Gemäß den Ausführungsbeispielen enthält der Speicher Anschlüsse zur Übertragung von Daten, Adressen und Steuersignalen mit dem Speicher, wobei keiner der Anschlüsse außerhalb des Halbleitergehäuses freiliegt. Ein besonderer Vorteil ist, dass physische Manipulationen verhindert werden können.
In Übereinstimmung mit Beispielimplementierungen kann das Halbleiterpaket außerdem einen ersten Chip, der den Speicher enthält, und einen zweiten Chip, der den Sicherheits-Hardwareprozessor enthält, umfassen. Darüber hinaus kann das Halbleiterpaket eine Verbindung zwischen dem ersten Chip und dem zweiten Chip enthalten. Ein besonderer Vorteil ist, dass physische Manipulationen verhindert werden können.
Gemäß Ausführungsbeispielen kann der zweite Chip außerdem den Haupt-Hardwareprozessor enthalten. Ein besonderer Vorteil ist, dass physische Manipulationen verhindert werden können.
Gemäß Implementierungsbeispielen führt der Sicherheits-Hardwareprozessor Anweisungen aus, um eine Anwendungsprogrammierschnittstelle zur Verwaltung der Speicherung des Geheimnisses bereitzustellen. Ein besonderer Vorteil ist, dass der Zugriff auf den Sicherheits-Hardware-Prozessor beschränkt ist.
In Übereinstimmung mit Beispielimplementierungen enthält der Basisplatinen-Verwaltungscontroller außerdem eine sichere Enklave, die eine zugehörige kryptografische Grenze aufweist. Der Sicherheitsprozessor und der Speicher befinden sich innerhalb der kryptografischen Grenze, und der Haupt-Hardwareprozessor befindet sich außerhalb der kryptografischen Grenze. Ein besonderer Vorteil ist, dass der Zugriff auf den Sicherheits-Hardwareprozessor eingeschränkt ist.
Gemäß Beispielimplementierungen umfasst die Verwaltung des Hosts durch den Basisplatinen-Verwaltungscontroller mindestens eines der folgenden Elemente: Steuern eines Systemleistungszustands des Hosts, Steuern eines Bootpfads des Hosts, Durchführen einer Wärmeverwaltung des Hosts, Verwalten der Verwendung virtueller Medien durch den Host, Steuern eines Bootvorgangs des Hosts, Durchführen von Sicherheitsprüfungen mit dem Host, Durchführen von Fehlerprüfungen mit dem Host, Validieren von Firmware, die vom zweiten Hardwareprozessor ausgeführt wird, Validieren von Firmware, die vom Sicherheitsprozessor ausgeführt wird, Durchführen einer Fehlerbehebung des Hosts oder Bereitstellen einer Fernkonsole für eine Fernverwaltungseinheit. Ein besonderer Vorteil ist, dass die Grundplatinenverwaltung sowohl verwaltungsbezogene Rollen als auch sicherheitsbezogene Rollen für den Host bereitstellen kann.
Obwohl die vorliegende Offenbarung in Bezug auf eine begrenzte Anzahl von Implementierungen beschrieben wurde, werden Fachleute, die über die Vorteile dieser Offenbarung verfügen, zahlreiche Modifikationen und Variationen davon schätzen. Es ist beabsichtigt, dass die beigefügten Ansprüche alle derartigen Modifikationen und Variationen abdecken.

Claims

Eine Vorrichtung, die Folgendes umfasst: einen Host; und eine Basisplatinen-Verwaltungssteuerung, die ein Halbleiterpaket umfasst, wobei das Halbleiterpaket einen Speicher, einen Sicherheits-Hardwareprozessor und einen Haupt-Hardwareprozessor umfasst, wobei: den Haupt-Hardwareprozessor, um zu bewirken, dass der Basisplatinen-Verwaltungscontroller als Agent dient, der unabhängig vom Host auf Kommunikationen mit einer entfernten Verwaltungseinheit antwortet, um den Host zu verwalten; und den Sicherheits-Hardwareprozessor zur Verwaltung der Speicherung eines Geheimnisses des Hosts im Speicher.
Die Vorrichtung nach Anspruch 1, wobei: den Haupt-Hardwareprozessor, der als Proxy zwischen dem Sicherheits-Hardwareprozessor und dem Host dient; den Proxy, um eine Anfrage zur Verwaltung der Speicherung des Geheimnisses von einem Anfrager des Hosts zu erhalten; den Proxy, um die Anfrage an den Sicherheits-Hardware-Prozessor weiterzuleiten; den Sicherheits-Hardwareprozessor, um dem Proxy eine Antwort auf die Anfrage zu geben; und der Proxy soll die Antwort an den Antragsteller weiterleiten.
Die Vorrichtung nach Anspruch 1, wobei: den Haupt-Hardwareprozessor, um eine Anforderung zur Verwaltung der Speicherung eines Geheimnisses der Basisplatinen-Verwaltungssteuerung im Speicher bereitzustellen; und den Sicherheits-Hardwareprozessor, um das Geheimnis als Reaktion auf die Anfrage zu verwalten.
Die Vorrichtung nach Anspruch 1, wobei: der Speicher umfasst Anschlüsse zur Kommunikation von Daten, Adressen und Steuersignalen mit dem Speicher; und keine der Klemmen außerhalb des Halbleitergehäuses freiliegt.
Die Vorrichtung nach Anspruch 1, wobei das Halbleiterpaket weiterhin umfasst: einen ersten Chip, der den Speicher enthält; einen zweiten Chip, der den Sicherheits-Hardware-Prozessor enthält; und eine Verbindung, um den ersten Stempel und den zweiten Stempel zu koppeln.
Die Vorrichtung nach Anspruch 5, wobei der zweite Chip außerdem den Haupt-Hardwareprozessor umfasst.
Die Vorrichtung nach Anspruch 1, wobei der Sicherheitshardwareprozessor Befehle ausführt, um eine Anwendungsprogrammierschnittstelle zur Verwaltung der Speicherung des Geheimnisses bereitzustellen.
Die Vorrichtung nach Anspruch 1, wobei das Halbleiterpaket ferner einen Chip umfasst, der den Speicher, den Sicherheits-Hardwareprozessor und den Haupt-Hardwareprozessor enthält.
Die Vorrichtung nach Anspruch 1, wobei das Geheimnis einen kryptographischen Schlüssel, ein Zertifikat oder ein Passwort umfasst.
Die Vorrichtung nach Anspruch 1, wobei die Basisplatten-Verwaltungssteuerung ferner Folgendes umfasst: eine sichere Enklave mit einer zugehörigen kryptographischen Grenze, wobei: der Sicherheitshardwareprozessor und der Speicher sich innerhalb der kryptographischen Grenze befinden; und der Haupt-Hardwareprozessor liegt außerhalb der kryptografischen Grenze.
Vorrichtung nach Anspruch 1, wobei die Verwaltung des Hosts durch den Basisplatinen-Verwaltungscontroller mindestens eines der folgenden Elemente umfasst: Steuern eines Systemleistungszustands des Hosts, Steuern eines Bootpfads des Hosts, Durchführen einer thermischen Verwaltung des Hosts, Verwalten der Verwendung virtueller Medien durch den Host, Steuern eines Bootvorgangs des Hosts, Durchführen von Sicherheitsprüfungen für den Host, Durchführen von Fehlerprüfungen für den Host, Validieren von durch den zweiten Hardwareprozessor ausgeführter Firmware, Validieren von durch den Sicherheitsprozessor ausgeführter Firmware, Durchführen einer Fehlerbehebung des Hosts oder Bereitstellen einer Fernkonsole für einen Fernverwaltungsserver.
Ein Verfahren, das Folgendes umfasst: Kommunikation durch einen Basisplatinen-Verwaltungscontroller einer Computerplattform mit einer Verwaltungseinheit, um einen Host der Computerplattform zu verwalten; Speichern eines Sicherheitsgeheimnisses für die Computerplattform in einem Sicherheitsspeicher der Basisplatinen-Verwaltungssteuerung; und Verwaltung der Speicherung des Geheimnisses durch einen Sicherheits-Hardwareprozessor des Baseboard-Management-Controllers.
Das Verfahren nach Anspruch 12, wobei der Basisplatinen-Verwaltungscontroller eine Verwaltungsebene umfasst, die Verwaltungsebene einen Proxy umfasst und der Sicherheits-Hardwareprozessor mit einer Sicherheitsebene verbunden ist, wobei das Verfahren ferner Folgendes umfasst: Empfang einer Anfrage des Hosts durch den Proxy zur Verwaltung der Speicherung des Geheimnisses; Weiterleitung der Anfrage durch den Proxy an den Sicherheits-Hardware-Prozessor; Bereitstellung einer Antwort auf die Anfrage an den Proxy durch den Sicherheits-Hardware-Prozessor; und Weiterleitung der Antwort an den Antragsteller durch den Proxy.
Das Verfahren nach Anspruch 12, wobei die Kommunikation mindestens eines der folgenden Elemente umfasst: Steuern eines Systemleistungszustands des Hosts, Steuern eines Boot-Pfads des Hosts, Durchführen von Wärmemanagement des Hosts, Verwalten der Verwendung virtueller Medien durch den Host, Steuern eines Bootvorgangs des Hosts, Durchführen von Sicherheitsprüfungen für den Host, Durchführen von Fehlerprüfungen für den Host, Validieren von durch den zweiten Hardware-Prozessor ausgeführter Firmware, Validieren von durch den Sicherheitsprozessor ausgeführter Firmware, Durchführen von Fehlerbehebung des Hosts oder Bereitstellen einer Fernkonsole für die Verwaltungseinheit.
Das Verfahren nach Anspruch 12, wobei: das Verwalten der Speicherung des Geheimnisses das Ausführen von Anweisungen durch den Sicherheits-Hardwareprozessor umfasst, die mit einer Anwendungsprogrammierschnittstelle (API) verbunden sind; und das Ausführen der Anweisungen umfasst, dass der Sicherheits-Hardwareprozessor mindestens einen der folgenden Schritte durchführt: Verwalten des Zugriffs auf einen kryptografischen Schlüssel, Verwalten des Zugriffs auf einen Schlüsselverschlüsselungsschlüssel, Erzeugen eines Schlüssels, Speichern eines Zertifikats, Erzeugen eines Zertifikats, Löschen eines Zertifikats oder Aktualisieren eines Zertifikats.
Das Verfahren nach Anspruch 12, wobei das Verwalten der Speicherung des Geheimnisses das Verwalten der Speicherung des Geheimnisses innerhalb einer kryptographischen Grenze umfasst, die den Sicherheits-Hardwareprozessor und den sicheren Speicher enthält.
Ein Management-Controller, der Folgendes umfasst: ein Halbleiterpaket mit einem Haupt-Hardwareprozessor und einer sicheren Enklave, wobei die sichere Enklave einen sicheren Speicher und einen Hardware-Sicherheitsprozessor umfasst; eine Kommunikationsschnittstelle; wobei der Haupthardwareprozessor Befehle ausführt, um mit einem Fernverwaltungsserver über die Kommunikationsschnittstelle zu kommunizieren und als Reaktion auf die Kommunikation einen Host einer Computerplattform zu verwalten; und wobei der Hardware-Sicherheitsprozessor eine Anwendungsprogrammierschnittstelle (API) bereitstellt, um ein in dem sicheren Speicher gespeichertes Geheimnis zu verwalten.
Der Management-Controller nach Anspruch 17, wobei: Das Geheimnis umfasst ein erstes Geheimnis des Hosts; der Haupthardwareprozessor als Stellvertreter für den Hardwaresicherheitsprozessor für eine erste Anforderung vom Host dient, die auf die Verwaltung des ersten Geheimnisses gerichtet ist; und den Haupt-Hardwareprozessor, um eine zweite Anfrage an den Hardware-Sicherheitsprozessor zu senden, die auf die Verwaltung eines zweiten Geheimnisses gerichtet ist, das mit dem Management-Controller verbunden ist.
Der Management-Controller nach Anspruch 17, wobei das Halbleiterpaket ferner Folgendes umfasst: einen ersten Chip, der den sicheren Speicher enthält; einen zweiten Chip, der den Hardware-Sicherheitsprozessor und den Haupt-Hardware-Sicherheitsprozessor umfasst; und eine Verbindung, um den ersten Stempel und den zweiten Stempel zu koppeln.
Der Management-Controller nach Anspruch 17, wobei: die sichere Enklave hat eine zugehörige kryptografische Grenze; der Hardware-Sicherheitsprozessor und der sichere Speicher sich innerhalb der kryptographischen Grenze befinden; und der Haupt-Hardwareprozessor liegt außerhalb der kryptografischen Grenze.