Symptom

Diese Anweisungen gelten nur für das System x240 M5. Unterstützung für Remote Physical Presence wurde in UEFI C4E132H Revision 2.50 hinzugefügt.

Um „Secure Boot“ auf einem Server zu aktivieren, ist es nicht notwendig, das System physisch zu öffnen oder interne DIP-Schaltereinstellungen zu ändern. Das UEFI-Setup bietet die Möglichkeit, die physische Präsenz remote zu bestätigen. Benutzer können den DIP-Schalter 6 Bit 2 auch manuell einstellen, um die physische Präsenz per Hardware zu bestätigen. Aus Sicherheitsgründen wird jedoch nicht empfohlen, die physische Präsenz bestätigt zu lassen, nachdem das System in ein Betriebssystem gebootet wurde.

Schritt 1:
Starten Sie den Server im UEFI-Setup-Bildschirm. Navigieren Sie zu Systemeinstellungen --> Sicherheit --> Konfiguration der physischen Präsenzrichtlinie.

Im Standardmodus sollten Benutzer damit rechnen, dass die Richtlinie für physische Anwesenheit aktiviert und ausgegraut ist. Benutzer sehen den Status der physischen Anwesenheit = Deaktiviert.
Hinweis: Wenn die Richtlinie für physische Präsenz aus irgendeinem Grund deaktiviert ist, wird die Registerkarte „Remote Physical Presence Assert umschalten“ ausgegraut. Um mit der Richtlinie fortzufahren, muss sie zuerst aktiviert werden. Dazu müssen Sie die physische Präsenz der Hardware über den DIP-Schalter 6, Bit 2, einstellen und das Setup neu starten. Anschließend können Sie die Richtlinie für physische Präsenz aktivieren.
Diese Funktion bietet Administratoren die zusätzliche Sicherheitsfunktion, die physische Anwesenheitsrichtlinie zu deaktivieren, um die Remote-Behauptung der physischen Anwesenheit zu verhindern. Aus Sicherheitsgründen sollte die physische Hardwarepräsenz entfernt werden, indem der DIP-Schalter 6, Bit 2 ausgeschaltet wird, sobald die Richtlinie deaktiviert ist.

Schritt 2:
Scrollen Sie nach unten zu „Remote Physical Presence Assert umschalten“, wählen Sie es aus und drücken Sie die Eingabetaste.
Benutzer werden sehen, dass sich der „physische Anwesenheitsstatus“ in „behauptet“ ändert. Das Behaupten und Aufheben der Behauptung erfordert keinen Neustart, damit es wirksam wird.

Schritt 3:
Drücken Sie nun die Taste „Esc“, um eine Ebene zurückzugehen, und gehen Sie zu: Sicherheit > Registerkarte „Secure Boot-Konfiguration“.

Möglicherweise müssen Sie auf die Schaltfläche „Physische Anwesenheit aktualisieren“ klicken, um den aktuellen Wert der physischen Anwesenheit anzuzeigen.

Stellen Sie nun die Sicherheitsstartkonfiguration ein --> Sicherer Start ist --> von Deaktiviert auf Aktiviert ändern.

Benutzern wird die Eingabeaufforderung „Möchten Sie Secure Boot wirklich aktivieren? Möchten Sie fortfahren? J/N << Geben Sie J ein.“ angezeigt.

Schritt 4:
Kehren Sie nun zur Registerkarte „Physical Presence Policy Configuration“ zurück und wählen Sie erneut --> „Remote Physical Presence Assert umschalten“, um den Physical Presence State zu deaktivieren.

Schritt 5:
Drücken Sie die Taste „Esc“, um zur obersten Ebene des UEFI-Setups zu gelangen, speichern Sie dann die Einstellungen und führen Sie einen Neustart durch.

Mit den gleichen Schritten können Sie auch den sicheren Start deaktivieren.

Betroffene Konfigurationen

Das System kann einer der folgenden Lenovo Server sein:

• Lenovo Flex System x240 M5 Compute Node, Typ 9532, jedes Modell

Dieser Tipp ist nicht softwarespezifisch.

Dieser Tipp ist nicht optionsspezifisch.

Das System weist das oben beschriebene Symptom auf.

Problemumgehung

Nicht zutreffend.

Weitere Informationen

Der sichere Start soll sicherstellen, dass der gesamte ausgeführte Code vertrauenswürdig und signiert ist. Im Standardmodus überprüft Lenovo Firmware alle im UEFI-Modus geladenen Codes anhand ihrer Signatur.

Wenn Secure Boot aktiviert ist, prüft es jede Software, einschließlich der UEFI-Treiber (Option ROMs) und des Betriebssystems, anhand von Datenbanken mit bekannten Signaturen. Wenn jede Software gültig ist, führt die Firmware die Software und das Betriebssystem aus. Die Secure Boot-Funktion verhindert somit das Booten von Adapterkarten, die ROMs enthalten, die nicht der erwarteten Signatur entsprechen.

Der sichere Start wird nur für den UEFI-Startmodus und nicht für den Legacy-Startmodus unterstützt.

OEMs stellen Lenovo ihre Treiber zur Verfügung, die dann in die UEFI-Firmware aufgenommen werden. Dazu gehören die Signaturdatenbank (db), die Datenbank für widerrufene Signaturen (dbx) und die Key Enrollment Key-Datenbank (KEK). Diese Datenbanken werden zum Herstellungszeitpunkt auf dem Flash-Speicher gespeichert.

In der Signaturdatenbank und der Datenbank für widerrufene Signaturen sind die Signierer oder Image-Hashes von UEFI-Anwendungen, Betriebssystem-Loadern (wie etwa dem Microsoft Operating System Loader oder Boot Manager) und UEFI-Treibern aufgeführt, die auf den Server geladen werden können, sowie die widerrufenen Images für Elemente, die nicht mehr vertrauenswürdig sind und nicht geladen werden dürfen.

Die Key Enrollment Key-Datenbank ist eine separate Datenbank mit Signaturschlüsseln, die zum Aktualisieren der Signaturdatenbank und der Datenbank für widerrufene Signaturen verwendet werden kann. Microsoft erfordert, dass ein bestimmter Schlüssel in die KEK-Datenbank aufgenommen wird, damit Microsoft in Zukunft neue Betriebssysteme zur Signaturdatenbank hinzufügen oder bekannte fehlerhafte Images zur Datenbank für widerrufene Signaturen hinzufügen kann. Nachdem diese Datenbanken hinzugefügt wurden und die Firmware abschließend validiert und getestet wurde, sperrt Lenovo die Firmware vor Änderungen, mit Ausnahme von Updates, die mit dem richtigen Schlüssel signiert sind, oder Updates von einem physisch anwesenden Benutzer, der Firmware-Menüs verwendet, und generiert dann einen PK. Der PK kann verwendet werden, um Updates für den KEK zu signieren oder Secure Boot zu deaktivieren.

Im Allgemeinen gibt es eine Rangfolge (von höchstwertig bis niedrigstwertig) von PK, KEK, db, dbx. Das heißt:

– Um einen KEK zu aktualisieren, müssen Sie über eine Signatur mit dem richtigen PK verfügen.

- Um eine Datenbank oder eine Datenbankx zu aktualisieren, benötigen Sie eine Signatur mit dem richtigen PK oder KEK.

– Zum Aktivieren von Secure Boot ist ein PK erforderlich.

Die Schlüsselbeschreibung ist wichtig, um die von uns unterstützten Modi zu verstehen. Secure Boot hat zwei (2) Modi: Standard und Benutzerdefiniert.

Im Standardmodus kann ein Benutzer von Microsoft signierte Zertifikate nutzen. Mit diesen Zertifikaten kann UEFI überprüfen, ob alle Options-ROMs und Betriebssysteme signiert und gültig sind. Sie umfassen sowohl Windows als auch Drittanbieterzertifikate für Linux. Im Wesentlichen erlauben wir die Verwendung dieser Standardwerte in Secure Boot-Zertifikaten in unserem Standardmodus. Dies umfasst einen PK, mehrere KEKs, db und dbx.

Im benutzerdefinierten Modus kann ein Benutzer seinen eigenen Schlüsselsatz installieren. Die Spezifikationen für den Secure Boot-Status ermöglichen einen Start im benutzerdefinierten Modus ohne PK. Dadurch kann ein Betriebssystem einen neuen PK registrieren, der dann zum Validieren seines eigenen KEK, db und dbx verwendet wird.

Die Standardeinstellung im Secure Boot-Modus ist der Standardmodus und die Standardeinstellung für den Secure Boot ist Deaktiviert.

Physische Präsenz:
Physische Präsenz ist eine Form der Autorisierung zum Ausführen bestimmter TPM-Funktionen. Diese Autorisierung kommt normalerweise vom Plattformbetreiber. Bei TPM 1.2-Geräten sind die Funktionen, die physische Präsenz erfordern, solche, die Bereitstellungs- und Neubereitstellungsvorgänge ausführen, z. B. das Zulassen und Löschen von Besitz, wenn der aktuelle Autorisierungswert des Besitzers unbekannt ist. Bei TPM 2.0-Geräten ist physische Präsenz mit Vorgängen verknüpft, die eine Plattformautorisierung erfordern, aber vom Betriebssystem initiiert werden. Normalerweise kann die Plattformautorisierung nur durch Firmware erteilt werden, nicht durch das Betriebssystem. Es gibt zwei Methoden, um eine Autorisierung für physische Präsenz bereitzustellen: die Befehlsmethode und die Hardwaremethode. Diese beiden Methoden sind für TPM 1.2-Geräte in der TPM 1.2-Hauptspezifikation und für TPM 2.0-Geräte in der TPM-Profilspezifikation der PC-Client-Plattform definiert.

Hardwaremethode zur Bestätigung der physischen Präsenz:
Ein Beispiel für die Implementierung der Hardwaremethode ist ein DIP-Schalter auf der Systemplatine, der mit einem Pin am TPM verbunden ist. Durch Einstellen des Schalters ändert der Pin die Polarität und das TPM setzt sein internes Flag für physische Präsenz. Mit dieser Hardwaremethode können Befehle, die die Anzeige der physischen Präsenz erfordern, jederzeit ausgeführt werden (in der Umgebung vor dem Betriebssystem oder aus der Betriebssystemumgebung), solange der Schalter eingestellt ist und für TPM 2.0 eine Plattformautorisierung verfügbar ist. Dies stellt ein Sicherheitsrisiko dar, wenn der Schalter in der aktivierten Position belassen wird.

Befehlsmethode zum Behaupten der physischen Präsenz:
In manchen Fällen ist es aufgrund von Kosten, Formfaktor, Nutzung oder Zugänglichkeit nicht möglich, einen Knopf oder Schalter an der Außenseite der Plattform anzubringen. Aus diesem Grund wird eine zweite Methode zur Bestätigung der physischen Anwesenheit definiert, die sogenannte Befehlsmethode. Bei der Befehlsmethode stellt die Firmware eine Benutzeroberfläche (UI) bereit, um den angeforderten Vorgang zu erklären. Ein physisch anwesender Benutzer bestätigt oder lehnt den Vorgang ab, indem er eine Taste auf der Tastatur drückt. Die Befehlsmethode autorisiert dann das Senden des TPM-Befehls an das TPM. Im TPM wird keine weitere Überprüfung der physischen Anwesenheit durchgeführt. Das TPM führt den TPM-Vorgang aus, wenn der Benutzer ihn über die UI bestätigt hat. Eine der erforderlichen Eigenschaften für die Anzeige der physischen Anwesenheit ist, dass sie vom Plattformbetreiber, normalerweise dem Benutzer, durchgeführt werden muss, wenn dieser physisch auf der Plattform anwesend ist. Dies erfordert, dass die Befehlsmethode so eingeschränkt wird, dass sie nur verfügbar ist, während der Plattformstatus diese Zusicherung bieten kann. Dieser Status besteht normalerweise während des Bootens in das UEFI-Setup, bevor ein Netzwerkstapel verfügbar ist und potenziell nicht vertrauenswürdiger Software ausgesetzt wird.