DE102021127624A1

DE102021127624A1 - Sichere bereitstellung der identität des basisboard-management-controllers einer plattform

Info

Publication number: DE102021127624A1
Application number: DE102021127624.1A
Authority: DE
Inventors: Nigel John Edwards; Luis E. Luciani; Ludovic Emmanuel Paul Noel JACQUIN
Original assignee: Hewlett Packard Enterprise Development LP
Current assignee: Hewlett Packard Enterprise Development LP
Priority date: 2021-03-01
Filing date: 2021-10-25
Publication date: 2022-09-01
Also published as: CN115001695B; CN115001695A; US20220278855A1; US11522723B2

Abstract

Beispielimplementierungen beziehen sich auf ein Verfahren und System zur Bereitstellung eines Identitätszertifikats für eine BMC einer Plattform. Auf der Grundlage der von der BMC empfangenen Zertifikatsignierungsanforderung (CSR) kann eine mit dem Plattformhersteller verbundene Zertifizierungsstelle (CA) die Identität des Sicherheitsprozessors und den privaten Schlüssel der BMC überprüfen. Ein kryptografisches Audit-Sitzungsprotokoll zwischen einem Bereitstellungsdienst der Plattform und dem Sicherheits-Coprozessor der Plattform wird zusammen mit der CSR bei der in einem Cloud-System implementierten CA empfangen. Die CA prüft die Signatur des empfangenen kryptografischen Audit-Sitzungsprotokolls. Nach der Überprüfung bestimmen die Validierungswerkzeuge im Cloud-System eine erste Zeit und eine zweite Zeit, die mit dem Sicherheits-Koprozessor verbunden sind. Wenn die Differenz zwischen der ersten Zeit und der zweiten Zeit unter einer erwarteten Zeit für die kryptografische Kommunikation liegt, wird die CSR als gültige Anforderung betrachtet und ein Identitätszertifikat für die BMC erstellt und an die Plattform übermittelt.

Description

HINTERGRUND
Da immer mehr Plattformen an nicht vertrauenswürdige Umgebungen ausgeliefert werden, werden mehrere Zero-Touch-Lösungen für die Bereitstellung verwendet. Zu den Plattformen können elektronische Geräte wie Server, Edge-Geräte, Switches, Speicher-Arrays usw. gehören. Zero-Touch-Lösungen ermöglichen es nicht vertrauenswürdigen Betreibern an entfernten Standorten, Plattformen einzurichten und diese nach sicherer Authentifizierung zu verwalten. Zur sicheren Authentifizierung können sichere Gerätekennungen verwendet werden, die mit den Plattformen verbunden sind. Bei der Bereitstellung der Plattform kann die Plattform authentifiziert werden, indem die sicheren Gerätekennungen überprüft werden und sichergestellt wird, dass die Plattform über die erforderlichen Identitätszertifikate verfügt. Die sicheren Gerätekennungen sind kryptografische Identitäten, die zur Authentifizierung der Identitätszertifikate auf der Plattform verwendet werden. Für die sichere Bereitstellung einer Plattform kann ein sicheres Authentifizierungsgerät auf der Plattform mit den kryptografischen Identitäten verwendet werden. Ein Trusted Platform Module (TPM) ist beispielsweise ein sicheres Authentifizierungsgerät, das kryptografische Schlüssel generiert und vor unbefugter Verwendung schützt. Das TPM wird von der Plattform bei kryptografischen Operationen verwendet. Eine Zertifizierungsstelle (CA) empfängt und bestätigt die sicheren Gerätekennungen/kryptografischen Identitäten der Plattform vom TPM, bevor sie das Identitätszertifikat für die Plattform übermittelt. Wenn eine Plattform eine Verbindung zu einem Datenzentrum herstellt, verwendet das Datenzentrum die Informationen im Identitätszertifikat, um festzustellen, ob die Plattform über die erforderlichen Gerätekennungen verfügt, um die Echtheit der Plattform festzustellen.
Figurenliste
Verschiedene Beispiele werden im Folgenden unter Bezugnahme auf die folgenden Abbildungen beschrieben.

1 ist ein Beispielsystem für die sichere Bereitstellung der Identität eines Baseband Management Controllers (BMC) in einer Plattform;
2 ist ein Blockdiagramm einer Plattform mit einem Prozessor, der betriebsfähig mit einem maschinenlesbaren Medium verbunden ist, das ausführbare Programmanweisungen speichert, in Übereinstimmung mit Ausführungsformen der vorliegenden Offenbarung;
3 zeigt ein Nachrichtenflussdiagramm eines Bereitstellungsprotokolls, das für die Erzeugung einer Zertifikatsignierungsanforderung (CSR) auf der Plattform verwendet wird, die ein Identitätszertifikat für die BMC anfordert, in Übereinstimmung mit Ausführungsformen der vorliegenden Offenlegung;
4 ist ein Blockdiagramm eines Cloud-Systems, das eine Zertifizierungsstelle (CA) implementiert, in Übereinstimmung mit Ausführungsformen der vorliegenden Offenbarung; und
5 ist ein Beispiel für ein BMC-Identitätszertifikat 502, das von der CA 104 für das BMC generiert wurde.
6 ist ein Flussdiagramm eines Verfahrens zur Validierung einer CSR-Anforderung im Cloud-System gemäß den hier offengelegten Ausführungsformen.

In den Zeichnungen können identische Referenznummern ähnliche, aber nicht unbedingt identische Elemente bezeichnen. Die Abbildungen sind nicht unbedingt maßstabsgetreu, und die Größe einiger Teile kann übertrieben sein, um das gezeigte Beispiel deutlicher zu machen. Darüber hinaus enthalten die Zeichnungen Beispiele und/oder Ausführungsformen, die mit der Beschreibung übereinstimmen; die Beschreibung ist jedoch nicht auf die in den Zeichnungen dargestellten Beispiele und/oder Ausführungsformen beschränkt.
DETAILLIERTE BESCHREIBUNG
Die folgende detaillierte Beschreibung bezieht sich auf die beigefügten Zeichnungen. Wo immer möglich, werden in den Zeichnungen und in der folgenden Beschreibung dieselben Bezugsnummern verwendet, um auf gleiche oder ähnliche Teile hinzuweisen. Es wird jedoch ausdrücklich darauf hingewiesen, dass die Zeichnungen nur der Veranschaulichung und Beschreibung dienen. Obwohl in diesem Dokument mehrere Beispiele beschrieben werden, sind Änderungen, Anpassungen und andere Ausführungen möglich. Dementsprechend schränkt die folgende detaillierte Beschreibung die offengelegten Beispiele nicht ein. Stattdessen kann der richtige Umfang der offengelegten Beispiele durch die beigefügten Ansprüche definiert werden.
Die hier verwendete Terminologie dient nur der Beschreibung von Beispielen und ist nicht als einschränkend zu verstehen. Die hier verwendeten Singularformen „ein“, „ein“ und „die“ schließen auch die Pluralformen ein, sofern aus dem Kontext nicht eindeutig etwas anderes hervorgeht. Der hier verwendete Begriff „ein anderer“ ist definiert als mindestens ein zweiter oder mehr. Der hier verwendete Begriff „gekoppelt“ ist definiert als verbunden, sei es direkt, ohne dazwischenliegende Elemente, oder indirekt mit mindestens einem dazwischenliegenden Element, sofern nicht anders angegeben. Zwei Elemente können mechanisch, elektrisch oder kommunikativ über einen Kommunikationskanal, -weg, -netz oder -system miteinander verbunden sein. Der Begriff „und/oder“, wie er hier verwendet wird, bezieht sich auf alle möglichen Kombinationen von einem oder mehreren der aufgeführten Elemente und umfasst diese. Obwohl die Begriffe „erstes“, „zweites“, „drittes“ usw. hier verwendet werden, um verschiedene Elemente zu beschreiben, sollten diese Elemente nicht durch diese Begriffe eingeschränkt werden, da diese Begriffe nur verwendet werden, um ein Element von einem anderen zu unterscheiden, es sei denn, es wird etwas anderes angegeben oder der Kontext zeigt etwas anderes an. Wie hierin verwendet, bedeutet der Begriff „beinhaltet“, dass er beinhaltet, aber nicht darauf beschränkt ist, der Begriff „einschließlich“ bedeutet, dass er beinhaltet, aber nicht darauf beschränkt ist. Der Begriff „basierend auf“ bedeutet zumindest teilweise basierend auf.
Zur Erläuterung der vorliegenden Offenbarung werden bestimmte Beispiele unter Bezugnahme auf die in den 1-5 dargestellten Komponenten beschrieben. Die Funktionalität der dargestellten Komponenten kann sich jedoch überschneiden und in einer geringeren oder größeren Anzahl von Elementen und Komponenten vorhanden sein. Darüber hinaus kann die gesamte oder ein Teil der Funktionalität der dargestellten Elemente nebeneinander bestehen oder auf mehrere geografisch verteilte Standorte verteilt sein. Darüber hinaus können die beschriebenen Beispiele in verschiedenen Umgebungen implementiert werden und sind nicht auf die dargestellten Beispiele beschränkt. Ferner ist die in Verbindung mit den und beschriebene Abfolge von Vorgängen ein Beispiel und nicht als Einschränkung zu verstehen. Es können zusätzliche oder weniger Vorgänge oder Kombinationen von Vorgängen verwendet oder variiert werden, ohne dass dies den Rahmen der dargestellten Beispiele sprengen würde. Die vorliegende Offenbarung enthält daher lediglich Beispiele für Implementierungen, und es können viele Variationen und Änderungen an den beschriebenen Beispielen vorgenommen werden. Solche Modifikationen und Variationen sollen in den Anwendungsbereich dieser Offenbarung einbezogen werden und sind durch die folgenden Ansprüche geschützt.
Der in der nachstehenden Beschreibung verwendete Begriff „Plattform“ kann unter Verwendung eines Servers oder einer Gruppe von Servern, einer Workstation, eines Desktop-Computers, einer kundenspezifischen Industriemaschine oder eines beliebigen Computergeräts mit einem BMC und einer Bereitstellungsanwendung/einem Bereitstellungsdienst/einer Bereitstellungsengine implementiert werden. Plattformen werden an entfernte Standorte geliefert, und die Bereitstellung der Plattform wird über eine „Zero-Touch“-Lösung (unter Verwendung von Cloud-basierten Diensten) von entfernten Bedienern an einem Kundenstandort angefordert. Um die Integrität und Authentizität der Plattformen zu gewährleisten, können die Plattformen mit einem Sicherheits-Coprozessor (z. B. einem Trusted Platform Module (TPM)) ausgestattet sein. Die Identitätsinformationen (z. B. privater Schlüssel und öffentliches Schlüsselzertifikat) im Sicherheits-Coprozessor der Plattform werden überprüft, um die Integrität und Authentizität der Plattform zu gewährleisten, sobald das Betriebssystem läuft.
Ein Identitätszertifikat wird von einer Zertifizierungsstelle (CA) ausgestellt und unterzeichnet, die mit dem Hersteller der Plattform verbunden ist. Das Identitätszertifikat kann eine Identität der Plattform und einen privaten Schlüssel enthalten, der mit der Plattform verbunden ist, zusammen mit Details wie Ausstellerdetails, Ausstellersignatur und Zertifikatsrichtlinien.
Die Plattform wird auf der Grundlage eines Identitätszertifikats autorisiert. Traditionell verfügt der Baseband Management Controller (BMC) der Plattform jedoch nicht über ein Identitätszertifikat, und der BMC wird nicht überprüft. Die Überprüfung der Identität des BMC getrennt von der Identität der Plattform kann dabei helfen, zu bestätigen, dass BMC anderer Plattformen nicht verwendet werden. Die BMC 110 und die Plattform 102 arbeiten mit voneinander unabhängigen Betriebssystemen und können unabhängig voneinander Dienste von einem Cloud-System anfordern. Die BMC hat keinen Zugriff auf das Identitätszertifikat der Plattform. Wenn außerdem sowohl der öffentliche Schlüssel der BMC als auch der öffentliche Schlüssel des Sicherheitsprozessors der Plattform als von derselben Plattform stammend verifiziert werden, erhöht sich das allgemeine Vertrauen in die Plattform, die eine Bereitstellung bei einer entfernten Behörde wie dem Cloud-System anfordert. Daher ist es wichtig, dass der private Schlüssel der BMC der Plattform vom Cloud-System verifiziert werden kann, bevor der Zugang zu den Ressourcen bereitgestellt wird. Wenn die BMC über ein Identitätszertifikat verfügt, kann dieses vor der Bearbeitung der Bereitstellungsanforderung der Plattform überprüft werden.
Im Allgemeinen können sich die hier offengelegten Ausführungsformen auf ein Verfahren und ein System zur Bereitstellung eines Identitätszertifikats für eine BMC einer Plattform beziehen. Ein Hersteller kann sich dafür entscheiden, das Identitätszertifikat für die BMC der Plattform aus den oben genannten Sicherheitsgründen bereitzustellen. In einigen Beispielen kann die Bereitstellung gegen Ende eines Herstellungsprozesses erfolgen, zum Beispiel in einer Fabrik. Die Plattform kann in Betrieb genommen werden, und die BMC kann so konfiguriert werden, dass sie eine Zertifikatsignierungsanforderung (CSR) an die CA sendet. Auf der Grundlage der von der BMC empfangenen CSR kann die mit dem Plattformhersteller verbundene CA die Identität des Sicherheitsprozessors und den privaten Schlüssel der BMC überprüfen, bevor sie der BMC ein Identitätszertifikat zur Verfügung stellt.
Bei der Bereitstellung der BMC ist es wichtig, überprüfbare Nachweise dafür zu führen, dass die BMC einen bestimmten Identitätsschlüssel beherbergt und physisch mit einem vertrauenswürdigen Element der Plattform (z. B. einem Sicherheits-Coprozessor) zusammengelegt ist. In bestimmten Beispielen können Zeitstempel in einem oder mehreren Protokollen zur Bestimmung der Kolokation verwendet werden. Ein kryptografisches Audit-Sitzungsprotokoll zwischen einem Bereitstellungsdienst der Plattform und dem Sicherheits-Koprozessor der Plattform wird zusammen mit der CSR bei der CA empfangen, die an einem von der Plattform entfernten Ort implementiert ist, z. B. in einem Cloud-System. Die CA prüft die Signatur des empfangenen kryptografischen Sitzungsprotokolls. Nach der Verifizierung bestimmen die Validierungswerkzeuge im Cloud-System eine erste Zeit, die mit dem Sicherheits-Coprozessor verbunden ist, wenn ein Bereitstellungsprotokoll mit BMC eingeleitet wird. Ein zweiter Zeitpunkt, der dem Sicherheits-Koprozessor zugeordnet ist, wird bestimmt, wenn ein Protokoll zur Abfrage des privaten Schlüssels mit der BMC abgeschlossen ist. Der CSR wird anhand der Differenz zwischen dem ersten Zeitpunkt und dem zweiten Zeitpunkt validiert. Wenn die Differenz zwischen der ersten Zeit und der zweiten Zeit unter einer erwarteten Zeit für die kryptografische Kommunikation liegt, wird die CSR als gültige Anforderung betrachtet und ein Identitätszertifikat für die BMC erstellt und an die Plattform übermittelt. Darüber hinaus überprüft die Zertifizierungsstelle anhand des kryptografischen Audit-Sitzungsprotokolls, ob es sich bei der mit dem privaten Schlüssel der BMC signierten Nonce um die vom Sicherheits-Coprozessor generierte Nonce handelt.
Nachdem die BMC bereitgestellt wurde, kann die Plattform an einen Kundenstandort geliefert und in einer Produktionsumgebung verwendet werden. Wenn die BMC der Plattform mit dem Cloud-Verwaltungsdienst kommuniziert, kann das Cloud-System anhand des Identitätszertifikats überprüfen, ob es sich bei der kommunizierenden BMC um die BMC einer echten Plattform handelt, die die Bereitstellung beantragt.
Die Bereitstellung der Identität für die BMC hat mehrere Vorteile, da die BMC der Plattform die erste ist, die eine Verbindung zu dem (in einem Cloud-System gehosteten) Cloud-Management-Dienst herstellt, der mit der Plattform verbunden ist. Ohne ein Identitätszertifikat für die BMC könnten Angreifer die BMC einer geprüften Plattform verwenden, um Plattformen bereitzustellen, die von anderen Unternehmen hergestellt werden. Außerdem wäre es ohne das Identitätszertifikat schwierig zu erkennen, ob die BMC einer ersten Plattform für die Bereitstellung einer zweiten Plattform verwendet wird.
zeigt ein Beispielsystem 100 für die sichere Bereitstellung der Identität eines BMC in einer Plattform. Die Plattform 102 ist ein Computergerät mit einem Sicherheits-Coprozessor 108 und einem Bereitstellungsdienst 106, der auf dem Host-Betriebssystem (OS) der Plattform 102 läuft.
Die Plattform 102 umfasst außerdem einen Speicher 118, einen oder mehrere Prozessoren 120, Eingabe-/Ausgabeschnittstellen 122 und eine BMC 110, die einen privaten Schlüssel 112 und einen öffentlichen Schlüssel 114 enthält. Der Prozessor 120, der Sicherheits-Coprozessor 108 und der Speicher 118 können über einen Bus (nicht dargestellt) verbunden sein.
Bei dem Prozessor 120 der Plattform kann es sich um eine oder mehrere Zentraleinheiten (CPU), einen oder mehrere Mikroprozessoren auf Halbleiterbasis, eine oder mehrere Grafikverarbeitungseinheiten (GPU), andere Hardwarevorrichtungen, die zum Abrufen und Ausführen von in einem maschinenlesbaren Speichermedium 126 gespeicherten Anweisungen geeignet sind, oder um Kombinationen davon handeln. Der Prozessor 120 ist unabhängig von dem Prozessor (nicht dargestellt) des BMC 110 und des Sicherheits-Coprozessors 108. Eine Plattform-Firmware, z. B. eine Unified Extensible Firmware Interface (UEFI)-Firmware, die im Prozessor 120 der Plattform läuft, empfängt Anweisungen vom Cloud-System 128, 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, und die Ergebnisse der Authentifizierung werden im Sicherheits-Coprozessor 108 gespeichert.
Der Sicherheits-Coprozessor 108 kann ein eingebetteter Mikrocontroller sein, der eine sichere Ausführungs- und Speicherumgebung für die Bereitstellung, Lizenzierung und Verhinderung der unbefugten Nutzung von eingeschränkter Software bietet. Die Implementierung des Sicherheits-Coprozessors 108 kann den Kriterien des Trusted Platform Module (TPM) entsprechen, das von der Trusted Computing Group entwickelt wurde. In einer Ausführungsform kann der Sicherheits-Coprozessor 108 als Schaltkreis in einem separaten Chipsatz implementiert sein. Der Sicherheits-Coprozessor 108 besteht aus Firmware, die auf dem Mikrocontroller in einer sicheren Ausführungsumgebung läuft und einen sicheren Speicherbereich bereitstellt, der vor Manipulationen durch Programme auf Benutzerebene, das Betriebssystem (OS) oder das grundlegende Eingabe-/Ausgabesystem (BIOS), das auf dem Prozessor 120 innerhalb der Plattform 102 läuft, geschützt ist. Der sichere Speicher kann jede Art von Speicher umfassen. In einer Ausführungsform kann der sichere Speicher kryptografische Schlüssel und andere Daten speichern, die für Authentifizierungs- oder Lizenzierungszwecke verwendet werden können. Weitere Einzelheiten zu den Funktionen des Sicherheits-Coprozessors 108 in der vorliegenden Offenbarung werden in Verbindung mit den , und erörtert.
Bei der BMC 110 kann es sich um einen Dienstprozessor handeln, der in der Lage ist, einen aktuellen Zustand der Plattform 102 mit Hilfe eines oder mehrerer Sensoren zu überwachen. In einigen Beispielen kann der BMC 110 in eine Hauptplatine oder eine Hauptplatine (nicht dargestellt) der zu überwachenden Plattform 102 eingebettet sein. Die BMC 110 kann auch über eine Hilfsstromschiene (nicht dargestellt) mit Strom versorgt werden, selbst wenn die Plattform 102 ausgeschaltet ist. Das BMC 110 läuft unabhängig von einem Prozessor 120 der Plattform 102 und kann daher bei einem Ausfall des Prozessors, des Speichers oder einer anderen Hardware weiterhin die Dienste bereitstellen.
Außerdem kann die BMC 110 einen privaten Schlüssel 112 und einen öffentlichen Schlüssel 114 enthalten. In einem Beispiel werden der private Schlüssel 112 und der öffentliche Schlüssel 114 in einem sicheren Speicher der BMC 110 gespeichert. In einem anderen Beispiel können der private Schlüssel 112 und der öffentliche Schlüssel 114 während der Bereitstellung der Plattform 102 festgelegt werden, z. B. beim ersten Hochfahren an einem Produktionsstandort oder zu einem anderen Zeitpunkt. Die Werte können in ein einmalig beschreibbares Register auf derselben anwendungsspezifischen integrierten Schaltung (ASIC) wie die BMC 110 geschrieben werden. Das einmalig beschreibbare Register kann z. B. mit Fuses implementiert werden. In einem Beispiel wird der private Schlüssel 112 durch Ausführen eines Algorithmus unter Verwendung von Zufallsquellen erzeugt und programmiert.
Der öffentliche Schlüssel 114 und der private Schlüssel 112 werden zusammen als Paar erstellt und arbeiten während des SSL/TLS-Handshake-Prozesses (unter Verwendung asymmetrischer Kryptographie) zusammen, um eine sichere Sitzung aufzubauen. Der private Schlüssel 112 wird in einem gesicherten Speicher aufbewahrt und geheim gehalten und ist nur in der BMC 110 verfügbar. Der öffentliche Schlüssel wird weit verbreitet und ist Teil des TLS-Zertifikats. Zusammen mit dem privaten Schlüssel 112 stellt er sicher, dass die Daten verschlüsselt, überprüft und nicht verfälscht werden. Jeder, der Zugriff auf den öffentlichen Schlüssel 114 (d. h. das Zertifikat) hat, kann die Echtheit der digitalen Signatur überprüfen, ohne den geheimen privaten Schlüssel kennen zu müssen.
Um die Identität der BMC 110 bereitzustellen, signiert die BMC 100 eine X.509 CSR und übermittelt sie an den Bereitstellungsdienst 106. Die CSR wird mit dem privaten Schlüssel 112 der BMC 110 signiert. Die CSR wird von der CA 104 als Quelle für X.509-Attribute der BMC 110 der Plattform 102 verwendet. Der öffentliche Schlüssel der BMC 110 ist in der CSR enthalten, und der private Schlüssel wird verwendet, um die X.509-CSR digital zu signieren.
Gemäß den Ausführungsformen der vorliegenden Offenlegung wird zur Validierung der Identität der BMC 110 und zur Ausstellung des Identitätszertifikats der Sicherheits-Coprozessor 108 mit dem Identitätsschlüssel 116 der Plattform 102 verwendet, während die CSR von der BMC 110 erzeugt wird. Da der im Sicherheits-Coprozessor 108 gespeicherte Identitätsschlüssel 116 der Plattform 102 vertrauenswürdig ist, fungiert er als vertrauenswürdiger Proxy für die Bereitstellung der Identität des BMC 110 auf der Plattform 102. Der Identitätsschlüssel 116 im Sicherheitskoprozessor 108 umfasst beispielsweise einen privaten Schlüssel und einen öffentlichen Schlüssel. In einer Ausführungsform kann eine einzige CSR vom Bereitstellungsdienst 106 erzeugt werden, die die Anforderung der Identitätsbereitstellung für die BMC 110 enthält. Weitere Einzelheiten über die CSR-Generierung und die Übertragung der CSR an die CA 104 werden in Verbindung mit den und weiter unten erörtert.
Der Bereitstellungsdienst 106 kann für die Bereitstellung von Identitäten auf der Plattform 102 verwendet werden. In einem Beispiel kann der Bereitstellungsdienst 106 auf dem Prozessor 120 während der abschließenden Prüfung jeder Plattform vor dem Versand ausgeführt werden. Der Bereitstellungsdienst 106 kann eine Anwendung sein, die auf dem Prozessor 120 der Plattform 102 läuft. Der Bereitstellungsdienst 106 umfasst eine Sicherheits-/Provisionierungssoftware, die auf dem Betriebssystem der Plattform 102 läuft. In einer Implementierung kann der Bereitstellungsdienst 106 über das BMC 110 als Out-of-Band-Dienst aktiviert werden. In einer anderen Implementierung kann der Bereitstellungsdienst 106 auf dem Prozessor 120 ausgeführt werden, z. B. während des Hochfahrens des Systems. In einigen Fällen kann der Code für den Bereitstellungsdienst 106 in einem Flash-Speicher, in einem Nur-Lese-Speicher (ROM) usw. gespeichert werden.
Der Bereitstellungsdienst 106 kann für die Bereitstellung von Identitäten und Lizenzen auf der Plattform 102 verwendet werden. In einem Beispiel kann der Bereitstellungsdienst 106 für die Bereitstellung von Identitäten der Plattform 102 und des BMC 110 während der abschließenden Testphasen der Plattform 102 am Herstellungsort (z. B. einer Fabrik) verwendet werden. Der Bereitstellungsdienst 106 kommuniziert separat mit dem Sicherheits-Coprozessor 108 und dem BMC 110, um die erforderlichen Identitätsinformationen zu sammeln. In einem Beispiel empfängt der Bereitstellungsdienst 106 für die Bereitstellung des Identitätszertifikats der BMC 110 eine selbstsignierte CSR von der BMC 110. Außerdem sammelt der Bereitstellungsdienst 106 einen öffentlichen Schlüssel, der mit der Identität des Sicherheitskoprozessors 108 verknüpft ist, und überträgt die CSR des BMC 110. Der Bereitstellungsdienst 106 verwendet die Eingabe-/Ausgabeschnittstelle 122 zur Kommunikation mit der CA 104 im Cloud-System 128. Ein CSR von der BMC 110 wird an die CA 104 im Cloud-System 128 gesendet.
Die Zertifizierungsstelle 104 im Cloud-System 128 empfängt die CSR von der BMC 110. Die CA 104 kann Teil des Cloud-Systems 128 (wie in 1 dargestellt) des Hardware-Herstellers sein, der die Plattform 102 hergestellt hat. In einigen Ausführungsformen kann die CA 104 in einem Rechenzentrum des Herstellers implementiert sein.
In einigen Implementierungen kann die Plattform 102 eine einzige CSR zur Anforderung mehrerer Zertifikate für die Plattform übermitteln. Eine einzige CSR kann beispielsweise die Anforderung eines Identitätszertifikats der BMC 110 und eine Anforderung eines Plattformzertifikats enthalten.
Die Validierungswerkzeuge 134 im Cloud-System 128 sind für die Validierung der CSR und die Bestätigung verantwortlich, dass der Sicherheits-Coprozessor 108 von einem bekannten Lieferanten des Herstellers stammt. Die Validierungswerkzeuge 134 überprüfen die CSR, um festzustellen, ob die CSR mit einem privaten Schlüssel signiert ist, der dem öffentlichen Schlüssel in der CSR entspricht. Ein Prozessor 136 im Cloud-System 128 führt Anweisungen 130 und 132 aus, die auf dem maschinenlesbaren Medium 126 gespeichert sind, um die Identität der BMC 110 bereitzustellen. Die Anweisungen 130 veranlassen bei ihrer Ausführung den Prozessor 124 des Cloud-Systems 128, die CSR auf der Grundlage einer Differenz zwischen der ersten Zeit und der zweiten Zeit, die mit dem Sicherheits-Coprozessor 108 verbunden sind, zu validieren. Die erste Zeit und die zweite Zeit des Sicherheitskoprozessors 108 können aus dem kryptografischen Prüfsitzungsprotokoll extrahiert werden, das von der Plattform 102 bei der CA 104 empfangen wurde.
Die Anweisungen 132 werden ausgeführt, wenn der CSR gültig ist. Die CA 104 im Cloud-System 128 stellt ein digitales Identitätszertifikat für das BMC 110 aus. In einem Beispiel kann das Identitätszertifikat ein digitales Zertifikat sein, das von der CA 104 (die mit dem Hersteller der Plattform verbunden ist) unterzeichnet wurde.
Das von der CA 104 übermittelte Identitätszertifikat wird mit einem der CA 104 gehörenden öffentlichen Schlüssel signiert. Zusätzlich kann das Identitätszertifikat mit dem öffentlichen Schlüssel verschlüsselt werden, der dem Sicherheits-Koprozessor 108 zugeordnet ist, wenn es von der CA 104 übertragen wird. Dies bedeutet, dass nur die Plattform 102 mit dem richtigen Sicherheits-Koprozessor 108 das Identitätszertifikat entschlüsseln kann. Auf der Plattform 102 wird das entschlüsselte X.509-Zertifikat im Klartext gespeichert. Im Werk wird die Plattform getestet und mit Identitäten für das BMC 110 und die Plattform 102 versehen, bevor sie an die Kunden ausgeliefert wird.
Wenn die Plattform an einen Kundenstandort geliefert wird und der Kunde die Plattform 102 mit dem Cloud-System 128 verbindet, um Ressourcen anzufordern oder die Bereitstellung der Plattform 102 anzufordern, kann das Cloud-System 128 die Identitätsinformationen in den digitalen Zertifikaten authentifizieren, um zu bestätigen, dass die Plattform 102 vertrauenswürdig ist, und sie autorisieren, bevor sie den Zugriff auf die Unternehmensressourcen über das Cloud-System 128 erlaubt. In einigen Fällen, wenn die Plattform 102 zum ersten Mal mit dem Cloud-System 128 verbunden wird, läuft das Betriebssystem der Plattform 102 nicht und das BMC 110 kann mit einem Dienst im Cloud-System 128 kommunizieren, um die Plattform 108 bereitzustellen und zu verwalten. Wenn ein BMC 110 mit einem Identitätszertifikat eine Verbindung zum Cloud-System 128 herstellt, kann das Cloud-System 128 die Echtheit des BMC 110 und der Plattform 102 überprüfen, noch bevor auf der Plattform 102 ein Betriebssystem (OS) läuft.
2 ist ein Blockdiagramm 200 einer Plattform 102 mit einem Prozessor 120, der funktionsfähig mit einem maschinenlesbaren Medium 202 verbunden ist, das ausführbare Programmanweisungen speichert, in Übereinstimmung mit Ausführungsformen der vorliegenden Offenbarung. Der Bereitstellungsdienst 106 empfängt eine selbstsignierte CSR von der BMC 110.
Um sicherzustellen, dass sich die BMC 110 und der Sicherheits-Coprozessor 108 auf derselben physischen Plattform befinden und über die erforderlichen überprüfbaren Nachweise verfügen, interagiert der Bereitstellungsdienst 106 unabhängig mit der BMC 110 und dem Sicherheits-Coprozessor 108. Die überprüfbaren Nachweise sind in dem von der Plattform 102 an die CA 104 gesendeten CSR enthalten. Zu den überprüfbaren Nachweisen gehören der private Schlüssel des BMC und der Identitätsschlüssel 116 des Sicherheits-Coprozessors.
Der Prozessor 120 der Plattform 102 führt Anweisungen 204 und 206 aus, die auf dem maschinenlesbaren Medium 202 gespeichert sind, um die Identität der BMC bereitzustellen. Die Anweisungen 204 veranlassen den Prozessor 120 bei ihrer Ausführung, den Bereitstellungsdienst 106 zu initiieren. Der Bereitstellungsdienst 106 initiiert eine geprüfte Kommunikationssitzung mit dem Sicherheits-Coprozessor 108, um verifizierbare Nachweise in dem von der BMC 110 angeforderten CSR unter Verwendung des Sicherheits-Coprozessors 108 zu erstellen. Zu den überprüfbaren Nachweisen gehören die signierte Nonce (signiert mit dem privaten Schlüssel 112 des BMC) und das signierte kryptografische Audit-Sitzungsprotokoll (signiert mit dem Identitätsschlüssel 116 des Sicherheits-Coprozessors 108).
Die ausgeführten Anweisungen 206 veranlassen den Prozessor 120, mit der CA 104 zu kommunizieren, um die Identität des BMC 110 bereitzustellen. Der Bereitstellungsdienst 106 verwendet die Eingabe-/Ausgabeschnittstelle 122 zur Kommunikation mit der CA 104 im Cloud-System 128. Der Identitätsschlüssel 116 des Sicherheits-Coprozessors 108 und die Aktualität der Signatur des BMC 110 über die Nonce werden von den Validierungswerkzeugen 134 im Cloud-System 128 überprüft, um die CSR-Anforderung des BMC 110 zu validieren. Die Verwendung des Sicherheitskoprozessors 108 als vertrauenswürdiges Element der Plattform 102 ermöglicht es den Validierungswerkzeugen 134, zu überprüfen, ob die BMC 110 und der Sicherheitskoprozessor 108 physisch auf derselben Plattform 102 zusammengeführt werden.
ERZEUGUNG VON CSR MIT ÜBERPRÜFBAREM NACHWEIS FÜR DIE BMC-IDENTITÄTSBEREITSTELLUNG
3 zeigt ein Nachrichtenflussdiagramm 300 eines Bereitstellungsprotokolls, das für die Erstellung eines CSR verwendet wird, der ein Identitätszertifikat für das BMC 110 auf der Plattform 102 anfordert.
In Schritt 302 kann der Bereitstellungsdienst 106 die BMC 110 um eine X.509 CSR bitten. Die CSR enthält Informationen zur Identifizierung des Antragstellers und ist mit dem privaten Schlüssel der BMC 110 signiert. Eine selbstsignierte BMC-CSR wird von der BMC 110 an den Bereitstellungsdienst 106 gesendet (Schritt 304). Sobald die BMC-CSR eingegangen ist, leitet der Bereitstellungsdienst 106 eine kryptografische Prüfsitzung (Schritt 306) mit dem Sicherheits-Coprozessor 108 ein.
Wenn das Bereitstellungsprotokoll mit der BMC 110 eingeleitet und eine selbstsignierte BMC-CSR empfangen wird, besteht der erste Befehl in der kryptografischen Prüfsitzung darin, eine mit einer internen Zeit des Sicherheitskoprozessors 108 verbundene Zeit zu erhalten (Schritt 308). In Schritt 310 wird eine erste vom Sicherheitskoprozessor 108 bestätigte Zeit an den Bereitstellungsdienst 106 gesendet. In den Schritten 312 und 314 bittet der Bereitstellungsdienst 106 den Sicherheitskoprozessor 108 um ein Nonce (z. B. eine Zufallszahl) und erhält das Nonce vom Sicherheitskoprozessor 108. In Schritt 316 fordert der Bereitstellungsdienst 106 nach Erhalt der Nonce die BMC auf, die Nonce (oder Zahl) mit dem privaten Schlüssel 112 der BMC 110 zu signieren. In Schritt 318 sendet die BMC 110 die signierte Nonce an den Bereitstellungsdienst 106. In Schritt 320, nachdem das Protokoll zur Abfrage des privaten Schlüssels mit der BMC 110 in Schritt 318 abgeschlossen wurde, sendet der Bereitstellungsdienst 106 einen Befehl, um eine mit dem Sicherheits-Koprozessor 108 verbundene Zeit zu erhalten (Schritt 320).
In Schritt 322 wird eine zweite, vom Sicherheits-Koprozessor 108 bestätigte Zeit an den Bereitstellungsdienst 106 gesendet. Schließlich fordert der Bereitstellungsdienst 106 das vollständige kryptografische Audit-Sitzungsprotokoll an (Schritt 324) und erhält (Schritt 326) ein signiertes kryptografisches Audit-Sitzungsprotokoll zwischen dem Sicherheitskoprozessor 108 und dem Bereitstellungsdienst 106. Die gesamte geprüfte Sitzung (z. B. das kryptografische Prüfsitzungsprotokoll) wird vom Sicherheitskoprozessor 108 signiert. Wenn der CSR von der Plattform 102 an die CA übertragen wird, wird das signierte kryptografische Audit-Sitzungsprotokoll (einschließlich Protokollbefehle, Parameter und Antworten) an die CA 104 gesendet. Der CSR und die geprüfte Sitzung enthalten die überprüfbaren Nachweise in Form der signierten Nonce und des signierten kryptografischen Prüfsitzungsprotokolls.
4 ist ein Blockdiagramm 400 eines Cloud-Systems 128, das Plattformen 102 einen Cloud-Verwaltungsdienst zur Verfügung stellt. In einigen Fällen umfasst das Cloud-System 128 die CA 104, den Prozessor 124, eine Datenbank 404, die Validierungswerkzeuge 134 und das maschinenlesbare Medium 126. Das maschinenlesbare Medium 126 ist nicht flüchtig und wird alternativ als nicht flüchtiges maschinenlesbares Medium bezeichnet. In einigen Beispielen kann auf das maschinenlesbare Medium 126 durch den Prozessor 124 zugegriffen werden. Das maschinenlesbare Medium 126 kann mit Beispielanweisungen 406, 408 und 410 kodiert sein.
Die Anweisung 406 veranlasst bei Ausführung durch den Prozessor 124 die Validierungswerkzeuge 134 im Cloud-System 128, die CSR-Anforderung von der BMC 110 zu validieren. Anhand des von der CA 104 empfangenen kryptografischen Audit-Sitzungsprotokolls können die Validierungswerkzeuge 134 zunächst überprüfen, ob das kryptografische Audit-Sitzungsprotokoll vom Sicherheits-Coprozessor 108 signiert wurde. Auf der Grundlage des kryptografischen Audit-Sitzungsprotokolls können die Validierungswerkzeuge 134 prüfen, ob der Bereitstellungsdienst 106 sowohl mit dem Sicherheitskoprozessor 108 als auch mit der BMC 110 interagiert hat. Sobald die Signatur des Sicherheitskoprozessors 108 verifiziert ist, können die Validierungswerkzeuge eine erste Zeit und eine zweite Zeit bestimmen, die mit dem Sicherheitskoprozessor 108 verbunden sind. Die erste Zeit des Sicherheitskoprozessors 108 wird vom Bereitstellungsdienst 106 angefordert, wenn das Bereitstellungsprotokoll mit der BMC 110 eingeleitet wird. Die zweite Zeit des Sicherheits-Coprozessors 108 wird vom Bereitstellungsdienst 106 angefordert, wenn ein Protokoll zur Abfrage des privaten Schlüssels mit dem BMC 110 abgeschlossen ist.
Die Validierungswerkzeuge 134 bestimmen die Aktualität der Signatur 100 des BMC auf dem Nonce. Die für die Erzeugung der signierten Nonce 318 (in 3) benötigte Zeit wird von der CA 104 anhand der Differenz zwischen der ersten Zeit und der zweiten Zeit überprüft. Die Differenz zwischen der ersten Zeit und der zweiten Zeit des Sicherheitskoprozessors 108 gibt die Zeit an, die die Plattform 102 benötigt, um überprüfbare Nachweise der BMC 110 und des Sicherheitskoprozessors 108 zu erzeugen. Die Zeitdifferenz zwischen der ersten Zeit und der zweiten Zeit zeigt die Aktualität der Signatur der BMC auf dem Nonce an. Die Überprüfung der Aktualität der Unterschrift der BMC 110 auf dem Nonce zeigt die Aktualität einer Unterschrift an. Daher kann eine ältere Signatur der BMC 110 nicht zum Signieren des Nonce verwendet werden. Wenn die Differenz zwischen der ersten Zeit und der zweiten Zeit unter einer erwarteten Zeit für die kryptografische Kommunikation liegt, kann die CA 104 im Cloud-System 128 überprüfen, ob die BMC 110 und der Sicherheits-Coprozessor 108 Teil desselben Chassis sind. Darüber hinaus wird durch die Verwendung der Zeitmessung (Differenz zwischen erster und zweiter Zeit) für die Signierung des Nonce verhindert, dass ein Angreifer das Nonce zur Signierung an eine andere Plattform weiterleitet.
Die Anweisungen 408 werden ausgeführt, wenn bestätigt wird, dass der CSR ein gültiger CSR ist. Das Cloud-System 128 speichert die Geräteidentität des BMC 110 in der Datenbank 404. Sobald die Geräteidentität des BMC 110 in der Datenbank 404 im Cloud-System 128 gespeichert ist, erzeugt die CA 104 das Identitätszertifikat für das BMC 110.
Die Anweisungen 410 veranlassen die CA 104 bei Ausführung durch den Prozessor, das Identitätszertifikat des BMC 110 zu erzeugen und an die Plattform 102 zu übermitteln. Das Identitätszertifikat des BMC 110 wird mit dem öffentlichen Schlüssel des Sicherheits-Coprozessors 108 verschlüsselt. Der Sicherheits-Coprozessor 108 mit dem richtigen IAK kann dann das Identitätszertifikat des BMC 110 entschlüsseln. Somit können nur die Plattform 102 und der Sicherheits-Koprozessor 108, die für die Erstellung des CSR verwendet werden, das von der CA 104 erhaltene Identitätszertifikat entschlüsseln.
5 ist ein Beispiel für ein BMC-Identitätszertifikat 502, das von der CA 104 für das BMC 110 generiert wurde. Das Identitätszertifikat 502 enthält eine Produktidentität 510 des BMC 110 und einen öffentlichen Schlüssel 508 des BMC 110 zusammen mit Details wie Aussteller 504, Ausstellersignatur 506 und Zertifikatsrichtlinien 512
Das Identitätszertifikat 502 kann von der CA 104 (oder einer Registered Authority (RA)) ausgestellt werden. In einem Beispiel kann die CA 104 eine externe Einrichtung wie ein Systemintegrator sein, der die Vertrauenswürdigkeit der Plattform und des BMC gewährleistet. In einem anderen Beispiel kann die CA 104 in dem Cloud-System 128 des Herstellers der Plattform 102 vorhanden sein.
Das Identitätszertifikat 502 kann ein digitales X.509-Zertifikat sein, das verschiedene Attributfelder wie die Gültigkeitsdauer, die verwendeten Signaturalgorithmen, die Seriennummer des Produkts und die mit dem digitalen Zertifikat 502 verbundene Vertrauenskette enthält.
Das BMC 110 und die Plattform 102 führen voneinander unabhängige Betriebssysteme aus und können unabhängig voneinander mit verschiedenen Diensten des Cloud-Systems 128 kommunizieren. Wenn das BMC 110 von einem Kundenstandort aus mit dem Cloud-System 128 kommuniziert, kann das Cloud-System 128 anhand der Informationen im BMC-Identitätszertifikat 502 überprüfen, ob das BMC 110 der Plattform 102, das sich mit dem Cloud-System 128 verbindet, echt ist, bevor es Zugang zu den Unternehmensressourcen gewährt. Das Identitätszertifikat 502 des BMC 110 hilft dem Cloud-System bei der Authentifizierung der Echtheit der Plattform 102, noch bevor der Prozessor der Plattform 102 läuft.
6 ist ein Flussdiagramm eines Verfahrens 600 zur Validierung einer CSR-Anforderung im Cloud-System 128 gemäß den hier offengelegten Ausführungsformen. Es sei darauf hingewiesen, dass das Verfahren 600 in Verbindung mit den 1, 2 und 3 beschrieben wird. Das Verfahren 600 beginnt in Block 602 und setzt sich bis Block 604 fort. In Block 604 empfängt die im Datenzentrum 128 implementierte CA 104 die CSR der BMC 110 und das kryptografische Audit-Sitzungsprotokoll zwischen dem Bereitstellungsdienst 106 und dem Sicherheits-Coprozessor 108. In Block 606 prüft die CA 104 die Signatur des kryptografischen Sitzungsprotokolls. Wird die Signatur des Sicherheitskoprozessors 108 nicht verifiziert, wird die CSR-Anforderung abgelehnt (Block 608). Wenn die Signatur des Sicherheitskoprozessors 108 verifiziert ist, wird das Verfahren 600 mit Block 610 fortgesetzt.
In den Blöcken 610 und 612 können Validierungstools im Datenzentrum 128 unter Verwendung der Signaturen im kryptografischen Audit-Sitzungsprotokoll die internen Zeiten (erste Zeit -T0 und zweite Zeit -T1) des Sicherheits-Coprozessors 108 authentifizieren und bestimmen. Die erste Zeit ist mit einem ersten internen Zeitstempel des Sicherheitskoprozessors 108 verbunden. Der erste Zeitpunkt des Sicherheitskoprozessors 108 wird vom Bereitstellungsdienst 106 angefordert, wenn das Bereitstellungsprotokoll mit dem BMC 110 eingeleitet wird. In 3 fordert der Bereitstellungsdienst 106 beispielsweise die interne Zeit des Sicherheitskoprozessors 108 an, wenn eine selbstsignierte CSR von der BMC 110 empfangen und eine geprüfte kryptografische Sitzung mit dem Sicherheitskoprozessor 108 eingeleitet wird. Die zweite Zeit des Sicherheitskoprozessors 108 wird vom Bereitstellungsdienst 106 angefordert, wenn das Protokoll zur Abfrage des privaten Schlüssels mit der BMC 110 abgeschlossen ist. In 3 fordert der Bereitstellungsdienst 106 beispielsweise die interne Zeit des Sicherheitskoprozessors 108 nach dem Signieren der Nonce durch das BMC 110 an. Das BMC 110 wird vom Bereitstellungsdienst 106 aufgefordert, die Nonce mit seinem privaten Schlüssel 112 zu signieren.
In Block 614 können die Validierungswerkzeuge ein Protokoll zur Abstandsbegrenzung anwenden, das eine erwartete Zeit der Kommunikation und der zwischen den beiden Zeitstempeln ausgeführten Befehle berücksichtigt. Anhand der Differenz zwischen dem ersten Zeitpunkt und dem zweiten Zeitpunkt können die Validierungswerkzeuge überprüfen, ob die Nonce rechtzeitig mit dem privaten Schlüssel 112 der BMC 110 signiert wurde. Wenn die Differenz zwischen dem zweiten Zeitpunkt und dem ersten Zeitpunkt geringer ist als die erwartete Zeit der kryptografischen Kommunikation, deutet dies darauf hin, dass die BMC 110 und der Sicherheits-Koprozessor 108 Teil derselben Plattform sind und dass die Plattform 102 während des Bereitstellungsprozesses nicht neu gestartet wurde. Liegt die Differenz zwischen der ersten Zeit und der zweiten Zeit über der erwarteten Zeit für die kryptografische Kommunikation, wird der CSR abgelehnt (dargestellt in Block 608).
In Block 616, wenn die Differenz zwischen der ersten Zeit und der zweiten Zeit unter der erwarteten Zeit der kryptografischen Kommunikation liegt, erzeugt die CA 104 das Identitätszertifikat für die BMC 110. Die Identität des BMC 110 wird in der Datenbank 404 gespeichert, und dann übermittelt die CA 104 das Identitätszertifikat an die Plattform 102. Das Identitätszertifikat wird mit dem öffentlichen Identitätsschlüssel des Sicherheitskoprozessors verschlüsselt, um sicherzustellen, dass nur die an der Erstellung des CSR beteiligte Plattform 102 das Identitätszertifikat entschlüsseln kann. Durch diese Art der Validierung wird sichergestellt, dass das BMC einer ersten Plattform nicht den Sicherheits-Koprozessor 108 einer anderen Plattform verwendet. Das Verfahren endet in Block 618.
Das in Methode 600 beschriebene Bereitstellungsprotokoll ist ein Protokoll für die Bereitstellung von Zertifikaten in einem einzigen Durchgang. In einem einzigen Durchgang werden alle Schritte vom Empfang der CSR über die Validierung der CSR bis zur Rücksendung des Identitätszertifikats abgeschlossen. Darüber hinaus kann das Single-Round-Trip-Design für die sichere Vor-Ort-Bereitstellung von Identitäten für den Austausch von defekten Komponenten wie der Hauptplatine verwendet werden. Die Methode der Identitätsbereitstellung des BMC 110 mit einem einzigen Hin- und Rückweg verhindert Verzögerungen während der abschließenden Testphasen im Werk. Da die Aktualität der BMC-Signatur durch die signierte Nonce verifiziert wird, muss die CA 104 keine zusätzlichen Anforderungen an die BMC 110 stellen. Das Identitätszertifikat wird von der CA 104 auf der Grundlage der signierten Nonce und der Überprüfung der Zeitstempel des Sicherheits-Coprozessors 108 ausgestellt. Darüber hinaus kann ein einziger CSR neben dem CSR für die BMC auch Anforderungen für andere Identitätszertifikate enthalten. Ein einziger Hin- und Rückweg verkürzt die Zeit, die für die Bereitstellung und abschließende Prüfung der Plattform 102 im Werk erforderlich ist. In den Abbildungen und der Beschreibung wird ein einziges Round-Trip-Protokoll beschrieben, es können jedoch auch Multi-Round-Trip-Protokolle für die Bereitstellung der Identität der BMC 110 verwendet werden.
In der vorstehenden Beschreibung sind zahlreiche Details aufgeführt, um das Verständnis des hierin offengelegten Gegenstands zu erleichtern. Die Umsetzung kann jedoch auch ohne einige oder alle dieser Details erfolgen. Andere Implementierungen können Modifikationen, Kombinationen und Variationen der oben beschriebenen Details beinhalten. Es ist beabsichtigt, dass die folgenden Ansprüche solche Modifikationen und Variationen abdecken.

Claims

Verfahren zur Bereitstellung der Identität eines Baseboard Management Controllers (BMC), wobei das Verfahren umfasst: Empfangen einer Zertifikatssignierungsanforderung (CSR) von der BMC einer Plattform bei einer Zertifizierungsstelle (CA), wobei ein kryptographisches Prüfsitzungsprotokoll zwischen einem Bereitstellungsdienst der Plattform und einem Sicherheits-Coprozessor der Plattform zusammen mit der CSR empfangen wird; Bestimmen einer ersten Zeit, die mit dem Sicherheits-Coprozessor assoziiert ist, wenn ein Bereitstellungsprotokoll mit dem BMC initiiert wird, aus dem kryptographischen Audit-Sitzungsprotokoll; Bestimmen, aus dem kryptographischen Audit-Sitzungsprotokoll, einer zweiten Zeit, die mit dem Sicherheits-Coprozessor assoziiert ist, wenn ein Privatschlüssel-Herausforderungsprotokoll mit der BMC abgeschlossen ist; und Validierung des CSR von der BMC auf der Grundlage einer Differenz zwischen dem ersten und dem zweiten Mal.
Verfahren nach Anspruch 1, wobei die Validierung Folgendes umfasst: Bestimmen, ob die Differenz zwischen der ersten Zeit und der zweiten Zeit unter einer erwarteten Zeit der kryptografischen Kommunikation liegt; Bestätigung, dass die BMC und der Sicherheits-Coprozessor Teil derselben Plattform sind, wenn die Differenz zwischen der ersten Zeit und der zweiten Zeit unter einer erwarteten Zeit der kryptographischen Kommunikation liegt; und Erstellung eines Identitätszertifikats für die BMC, wenn bestätigt wird, dass die BMC und der Sicherheits-Coprozessor Teil derselben Plattform sind.
Verfahren nach Anspruch 1, wobei der Bereitstellungsdienst aus einer Bereitstellungssoftware besteht, die auf einem Betriebssystem (OS) der Plattform läuft.
Verfahren nach Anspruch 1, wobei die Validierung Folgendes umfasst: Ablehnung des CSR, wenn die Differenz zwischen der ersten und der zweiten Zeit über einer erwarteten Zeit für die kryptografische Kommunikation liegt.
Verfahren nach Anspruch 1, wobei die Validierung Folgendes umfasst: Bestimmen, aus dem kryptographischen Audit-Sitzungsprotokoll, ob eine vom Sicherheits-Coprozessor erzeugte Nonce dieselbe ist wie die von der BMC während der kryptographischen Audit-Sitzung signierte Nonce.
Verfahren nach Anspruch 5, wobei der Unterschied zwischen der ersten Zeit und der zweiten Zeit die Aktualität der Signatur einer BMC auf dem Nonce anzeigt, wobei das Nonce durch den Sicherheits-Coprozessor erzeugt und durch die BMC signiert wird.
Verfahren nach Anspruch 1, wobei der Bereitstellungsdienst unabhängig mit dem Sicherheits-Coprozessor und dem BMC der Plattform kommuniziert.
Verfahren nach Anspruch 1, wobei das kryptografische Prüfsitzungsprotokoll zwischen dem Sicherheits-Coprozessor und dem Bereitstellungsdienst von dem Sicherheits-Coprozessor signiert wird.
Verfahren nach Anspruch 1, wobei das Bereitstellungsprotokoll einen einzigen Hin- und Rückweg für die Bereitstellung der Identität der BMC verwendet.
Ein nicht-transitorisches, maschinenlesbares Speichermedium, das Anweisungen speichert, die von einem Prozessor eines Cloud-Systems ausgeführt werden können, wobei das maschinenlesbare Speichermedium Anweisungen umfasst, um: eine Zertifikatsignierungsanforderung (CSR) von einem BMC einer Plattform empfangen, wobei ein kryptographisches Prüfsitzungsprotokoll zwischen einem Bereitstellungsdienst der Plattform und einem Sicherheits-Coprozessor der Plattform zusammen mit der CSR empfangen wird; aus dem kryptographischen Audit-Sitzungsprotokoll einen ersten Zeitpunkt zu bestimmen, der mit dem Sicherheits-Coprozessor verbunden ist, wenn ein Bereitstellungsprotokoll mit der BMC eingeleitet wird; aus dem kryptographischen Audit-Sitzungsprotokoll einen zweiten Zeitpunkt zu bestimmen, der mit dem Sicherheits-Coprozessor verbunden ist, wenn ein Protokoll zur Abfrage des privaten Schlüssels mit der BMC abgeschlossen ist; und Erzeugen eines Identitätszertifikats für die BMC, wenn eine Differenz zwischen der ersten Zeit und der zweiten Zeit unter einer erwarteten Zeit der kryptografischen Kommunikation liegt; und das Identitätszertifikat mit einem öffentlichen Schlüssel der Zertifizierungsstelle an die Plattform übermitteln.
Das nicht-transitorische maschinenlesbare Speichermedium nach Anspruch 10, das außerdem Anweisungen zum: den CSR ablehnen, wenn die Differenz zwischen der ersten und der zweiten Zeit über der erwarteten Zeit für die kryptografische Kommunikation liegt.
Nicht-übertragbares maschinenlesbares Speichermedium nach Anspruch 10, wobei das Bereitstellungsprotokoll einen einzigen Hin- und Rückweg für die Bereitstellung der Identität der BMC verwendet.
Das nicht-transitorische maschinenlesbare Speichermedium nach Anspruch 10, das außerdem Anweisungen für folgende Zwecke enthält: feststellen, ob die Differenz zwischen der ersten Zeit und der zweiten Zeit unter einer erwarteten Zeit für die kryptografische Kommunikation liegt; bestätigen, dass die BMC und der Sicherheits-Coprozessor Teil derselben Plattform sind, wenn die Differenz zwischen der ersten Zeit und der zweiten Zeit unter einer erwarteten Zeit der kryptografischen Kommunikation liegt; und ein Identitätszertifikat für die BMC zu erzeugen, wenn bestätigt wird, dass die BMC und der Sicherheits-Coprozessor Teil derselben Plattform sind.
Nicht-transitorisches maschinenlesbares Speichermedium nach Anspruch 10, das ferner Anweisungen umfasst, um festzustellen, ob der Bereitstellungsdienst auf der Plattform unabhängig mit dem BMC und dem Sicherheits-Coprozessor der Plattform kommuniziert.
Ein Verfahren, das Folgendes umfasst: Empfangen einer Zertifikatsignierungsanforderung (CSR) von einem BMC einer Plattform bei einer Zertifizierungsstelle (CA), wobei ein kryptographisches Prüfsitzungsprotokoll zwischen einem Bereitstellungsdienst der Plattform und einem Sicherheits-Coprozessor der Plattform zusammen mit der CSR empfangen wird; Bestimmen einer ersten Zeit, die mit dem Sicherheits-Coprozessor assoziiert ist, wenn ein Bereitstellungsprotokoll mit dem BMC initiiert wird, aus dem kryptographischen Audit-Sitzungsprotokoll; Bestimmen einer zweiten, dem Sicherheits-Coprozessor zugeordneten Zeit aus dem kryptographischen Prüfsitzungsprotokoll, wenn ein Protokoll zur Abfrage des privaten Schlüssels mit der BMC abgeschlossen ist; Überprüfen, dass sich die BMC und der Sicherheits-Coprozessor auf demselben Chassis befinden, wenn eine Differenz zwischen der ersten Zeit und der zweiten Zeit unter einer erwarteten Zeit der kryptografischen Kommunikation liegt; und Erstellung und Übermittlung eines Identitätszertifikats für die BMC, wenn sich die BMC und der Sicherheits-Coprozessor in einem einzigen Chassis befinden.
Verfahren nach Anspruch 15, wobei der Bereitstellungsdienst aus einer Bereitstellungssoftware besteht, die auf einem Betriebssystem (OS) der Plattform läuft.
Verfahren nach Anspruch 15, wobei die CA den CSR zurückweist, wenn die Differenz zwischen der ersten Zeit und der zweiten Zeit über einer erwarteten Zeit der kryptographischen Kommunikation liegt.
Verfahren nach Anspruch 15, wobei das kryptografische Prüfsitzungsprotokoll zwischen dem Sicherheits-Coprozessor und dem Bereitstellungsdienst von dem Sicherheits-Coprozessor signiert wird.
Verfahren nach Anspruch 15, wobei das Überprüfen ferner umfasst: Bestimmen, aus dem kryptographischen Audit-Sitzungsprotokoll, ob eine vom Sicherheits-Coprozessor erzeugte Nonce dieselbe ist wie die von der BMC während der kryptographischen Audit-Sitzung signierte Nonce.
Verfahren nach Anspruch 15, wobei der Bereitstellungsdienst unabhängig mit dem Sicherheits-Coprozessor und der BMC der Plattform kommuniziert und das Bereitstellungsprotokoll einen einzigen Hin- und Rückweg für die Bereitstellung einer Identität der BMC verwendet.