Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# UEFI Secure Boot für Amazon-EC2-Instances
UEFI Secure Boot baut auf dem langjährigen sicheren Startprozess von Amazon EC2 auf und bietet zusätzliche Funktionen, mit defense-in-depth denen Kunden Software vor Bedrohungen schützen können, die auch nach Neustarts bestehen. Es stellt sicher, dass die Instance nur Software startet, die mit kryptografischen Schlüsseln signiert ist. Die Schlüssel werden in der Schlüsseldatenbank des [UEFI nicht flüchtige Variablenspeicher](uefi-variables.md) gespeichert. UEFI Secure Boot verhindert die unbefugte Änderung des Bootflows der Instance.
**Topics**
+ [Wie UEFI Secure Boot mit Amazon-EC2-Instances funktioniert](how-uefi-secure-boot-works.md)
+ [Anforderungen für UEFI Secure Boot in Amazon EC2](launch-instance-with-uefi-sb.md)
+ [Überprüfen, ob eine Amazon-EC2-Instance für UEFI Secure Boot aktiviert ist](verify-uefi-secure-boot.md)
+ [Ein Linux-AMI mit benutzerdefinierten UEFI-Secure-Boot-Schlüsseln erstellen](create-ami-with-uefi-secure-boot.md)
+ [Erstellen Sie den AWS binären Blob für UEFI Secure Boot](aws-binary-blob-creation.md)
# Wie UEFI Secure Boot mit Amazon-EC2-Instances funktioniert
UEFI Secure Boot ist ein in UEFI spezifiziertes Feature, das eine Überprüfung des Status der Bootchain ermöglicht. Sie soll sicherstellen, dass nach der Selbstinitialisierung der Firmware nur kryptographisch verifizierte UEFI-Binärdateien ausgeführt werden. Zu diesen Binärdateien gehören UEFI-Treiber und der Haupt-Bootloader sowie kettengeladene Komponenten.
UEFI Secure Boot spezifiziert vier wichtige Datenbanken, die in einer Vertrauenskette verwendet werden. Die Datenbanken werden im UEFI-Variablenspeicher gespeichert.
Die Vertrauenskette lautet wie folgt:
**Plattformschlüssel (PK)-Datenbank**
Die PK-Datenbank ist der Vertrauensanker. Sie enthält einen einzigen öffentlichen PK-Schlüssel, der in der Vertrauenskette zum Aktualisieren der Schlüsselaustausch-Schlüssel (KEK)-Datenbank verwendet wird.
Um die PK-Datenbank zu ändern, benötigen Sie den privaten PK-Schlüssel, um eine Aktualisierungsanforderung zu signieren. Dies beinhaltet das Löschen der PK-Datenbank durch Schreiben eines leeren PK-Schlüssels.
**Schlüsselaustausch-Schlüssel (KEK)-Datenbank**
Die KEK-Datenbank ist eine Liste öffentlicher KEK-Schlüssel, die in der Vertrauenskette zum Aktualisieren der Signatur (db)- und Deny-Liste (dbx)-Datenbanken verwendet werden.
Um die um die öffentliche KEK-Datenbank zu ändern, benötigen Sie den privaten PK-Schlüssel, um eine Aktualisierungsanforderung zu signieren.
**Signatur (db)-Datenbank**
Die db-Datenbank ist eine Liste von öffentlichen Schlüsseln und Hashes, die in der Vertrauenskette verwendet werden, um alle UEFI-Boot-Binärdateien zu validieren.
Um die db-Datenbank zu ändern, benötigen Sie den privaten PK-Schlüssel einen der privaten KEK-Schlüssel, um eine Aktualisierungsanforderung zu signieren.
**Signatur-Deny-Liste (dbx)-Datenbank**
Die dbx-Datenbank ist eine Liste von öffentlichen Schlüsseln und binären Hashes, die nicht vertrauenswürdig sind und in der Vertrauenskette als Widerrufsdatei verwendet werden.
Die dbx-Datenbank hat immer Vorrang vor allen anderen wichtigen Datenbanken.
Um die dbx-Datenbank zu ändern, benötigen Sie den privaten PK-Schlüssel oder einen der privaten KEK-Schlüssel, um eine Aktualisierungsanforderung zu signieren.
Das UEFI-Forum unterhält eine öffentlich zugängliche dbx für viele bekanntermaßen fehlerhafte Binärdateien und Zertifikate unter [https://uefi.org/revocationlistfile](https://uefi.org/revocationlistfile).
**Wichtig**
UEFI Secure Boot erzwingt die Signaturvalidierung für alle UEFI-Binärdateien. Um die Ausführung einer UEFI-Binärdatei in UEFI Secure Boot zu erlauben, signieren Sie sie mit einem der oben beschriebenen privaten db-Schlüssel.
Standardmäßig ist UEFI Secure Boot deaktiviert und das System befindet sich im `SetupMode`. Wenn sich das System im `SetupMode` befindet, können alle Schlüsselvariablen ohne kryptografische Signatur aktualisiert werden. Wenn der PK gesetzt ist, ist UEFI Secure Boot aktiviert und der wird beendet. SetupMode
# Anforderungen für UEFI Secure Boot in Amazon EC2
Wenn Sie eine [Amazon-EC2-Instance](LaunchingAndUsingInstances.md) mit einem unterstützten AMI und einem unterstützten Instance-Typ starten, validiert diese Instance automatisch UEFI-Boot-Binärdateien anhand ihrer UEFI-Secure-Boot-Datenbank. Es ist keine zusätzliche Konfiguration erforderlich. Sie können UEFI Secure Boot auch nach dem Start für eine Instance konfigurieren.
**Anmerkung**
UEFI Secure Boot schützt Ihre Instance und ihr Betriebssystem vor Änderungen im Bootflow. Wenn Sie ein neues AMI aus einem Quell-AMI erstellen, bei dem UEFI Secure Boot aktiviert ist, und bestimmte Parameter während des Kopiervorgangs ändern, wie beispielsweise die `UefiData` innerhalb des AMI, können Sie UEFI Secure Boot deaktivieren.
**Topics**
+ [Unterstützt AMIs](#uefi-amis)
+ [Unterstützte Instance-Typen](#uefi-instance)
## Unterstützt AMIs
**Linux AMIs**
Um eine Linux-Instance zu starten, muss für das Linux-AMI UEFI Secure Boot aktiviert sein.
Amazon Linux unterstützt UEFI Secure Boot ab AL2023 Version 2023.1. UEFI Secure Boot ist jedoch standardmäßig nicht aktiviert. AMIs Weitere Informationen finden Sie unter [UEFI Secure Boot](https://docs.aws.amazon.com/linux/al2023/ug/uefi-secure-boot.html) im *AL2023 Benutzerhandbuch*. Ältere Versionen von Amazon Linux AMIs sind nicht für UEFI Secure Boot aktiviert. Um ein unterstütztes AMI zu verwenden, müssen Sie eine Reihe von Konfigurationsschritten für Ihr eigenes Linux-AMI ausführen. Weitere Informationen finden Sie unter [Ein Linux-AMI mit benutzerdefinierten UEFI-Secure-Boot-Schlüsseln erstellen](create-ami-with-uefi-secure-boot.md).
**Windows AMIs**
Um eine Windows-Instance zu starten, muss für das Windows-AMI UEFI Secure Boot aktiviert sein. *Informationen zu einem AWS Windows-AMI, das für UEFI Secure Boot mit Microsoft-Schlüsseln vorkonfiguriert ist, [finden Sie unter Suchen Sie nach einem mit NitroTPM und UEFI Secure Boot AMIs konfigurierten Windows Server](https://docs.aws.amazon.com/ec2/latest/windows-ami-reference/ami-windows-tpm.html#ami-windows-tpm-find) in der Windows-Referenz.AWS AMIs *
Derzeit wird das Importieren von Windows mit UEFI Secure Boot über den Befehl [import-image](https://docs.aws.amazon.com/cli/latest/reference/ec2/import-image.html) nicht unterstützt.
## Unterstützte Instance-Typen
Alle virtualisierten Instance-Typen, die UEFI unterstützen, unterstützen auch UEFI Secure Boot. Informationen zu den Instance-Typen, die UEFI Secure Boot unterstützen, finden Sie unter [Anforderungen für den UEFI-Bootmodus](launch-instance-boot-mode.md).
**Anmerkung**
Bare-Metal-Instance-Typen unterstützen UEFI Secure Boot nicht.
# Überprüfen, ob eine Amazon-EC2-Instance für UEFI Secure Boot aktiviert ist
Sie können die folgenden Verfahren verwenden, um festzustellen, ob ein Amazon EC2 für UEFI Secure Boot aktiviert ist.
## Linux-Instances
Sie können das `mokutil`-Serviceprogramm verwenden, um zu überprüfen, ob eine Linux Instance für UEFI Secure Boot freigegeben ist. Wenn `mokutil` nicht auf Ihrer Instance installiert ist, müssen Sie es installieren. Die Installationsanweisungen für Amazon Linux 2 finden Sie unter [Suchen und Installieren von Softwarepaketen auf einer Amazon-Linux-2-Instance](https://docs.aws.amazon.com/linux/al2/ug/find-install-software.html). Für andere Linux-Verteilungen schauen Sie in der spezifischen Dokumentation.
**So überprüfen Sie, ob eine Linux-Instance für UEFI Secure Boot aktiviert ist**
Verbinden Sie sich mit Ihrer Instance und führen Sie den folgenden Befehl als `root` in einem Terminal-Fenster aus.
```
mokutil --sb-state
```
Es folgt eine Beispielausgabe.
+ Wenn UEFI Secure Boot aktiviert ist, enthält die Ausgabe `SecureBoot enabled`.
+ Wenn UEFI Secure Boot nicht aktiviert ist, enthält die Ausgabe `SecureBoot disabled` oder `Failed to read SecureBoot`.
## Windows-Instances
**So überprüfen Sie, ob eine Windows-Instance für UEFI Secure Boot aktiviert ist**
1. Verbinden Sie sich mit der Instance.
1. Öffnen Sie das msinfo32-Tool.
1. Überprüfen Sie das Feld **Secure Boot State** (Sicherer Boot-Status). Wenn UEFI Secure Boot aktiviert ist, lautet der Wert **Unterstützt**, wie in der folgenden Abbildung dargestellt.
![\[Sicherer Startstatus innerhalb der Systeminformationen.\]](http://docs.aws.amazon.com/de_de/AWSEC2/latest/UserGuide/images/secure-boot-state-win.png)
Sie können auch das PowerShell Windows-Cmdlet verwenden, um den Secure `Confirm-SecureBootUEFI` Boot-Status zu überprüfen. Weitere Informationen zum Cmdlet finden Sie unter [Confirm- SecureBoot UEFI](https://learn.microsoft.com/en-us/powershell/module/secureboot/confirm-securebootuefi) in der Microsoft-Dokumentation.
# Ein Linux-AMI mit benutzerdefinierten UEFI-Secure-Boot-Schlüsseln erstellen
Diese Anleitung zeigt Ihnen, wie Sie ein Linux-AMI mit UEFI Secure Boot und benutzerdefinierten privaten Schlüsseln erstellen. Amazon Linux unterstützt UEFI Secure Boot ab AL2023 Version 2023.1. Weitere Informationen finden Sie unter [UEFI Secure Boot on AL2023](https://docs.aws.amazon.com/linux/al2023/ug/uefi-secure-boot.html) im *Amazon Linux 2023-Benutzerhandbuch*.
**Wichtig**
Das folgende Verfahren ist nur für **fortgeschrittene Benutzer** vorgesehen. Sie müssen über ausreichende Kenntnisse im Bootflow der SSL- und Linux-Distribution verfügen, um diese Verfahren verwenden zu können.
**Voraussetzungen**
+ Die folgenden Tools werden verwendet:
+ OpenSSL – [https://www.openssl.org/](https://www.openssl.org/)
+ [efivar — efivar https://github.com/rhboot/](https://github.com/rhboot/efivar)
+ [efitools — https://git.kernel. org/pub/scm/linux/kernel/git/jejb/efitools.git/](https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git/)
+ [get-instance-uefi-data](https://docs.aws.amazon.com/cli/latest/reference/ec2/get-instance-uefi-data.html) command
+ Ihre Linux-Instance muss mit einem Linux-AMI gestartet worden sein, das den UEFI-Startmodus unterstützt und es müssen nichtflüchtige Daten vorhanden sein.
Neu erstellte Instances ohne UEFI Secure Boot-Schlüssel werden in `SetupMode` erstellt, wodurch Sie Ihre eigenen Schlüssel registrieren können. Einige AMIs sind mit UEFI Secure Boot vorkonfiguriert und Sie können die vorhandenen Schlüssel nicht ändern. Wenn Sie die Schlüssel ändern möchten, müssen Sie ein neues AMI basierend auf dem ursprünglichen AMI erstellen.
Sie haben zwei Möglichkeiten, die Schlüssel im Variablenspeicher zu propagieren, die in den folgenden Optionen A und B beschrieben sind. Option A beschreibt, wie dies innerhalb der Instance geschieht und den Fluss echter Hardware nachahmt. Option B beschreibt, wie ein binäres Blob erstellt wird, das dann als base64-kodierte Datei übergeben wird, wenn Sie das AMI erstellen. Für beide Optionen müssen Sie zuerst die drei Schlüsselpaare erstellen, die für die Vertrauenskette verwendet werden.
**Topics**
+ [Aufgabe 1: Schlüsselpaare erstellen](#uefi-secure-boot-create-three-key-pairs)
+ [Aufgabe 2 – Option A: Fügen Sie innerhalb der Instance Schlüssel zum Variablenspeicher hinzu](#uefi-secure-boot-optionA)
+ [Aufgabe 2 – Option B: Erstellen Sie ein binäres Blob mit einem vorgefüllten Variablenspeicher](#uefi-secure-boot-optionB)
## Aufgabe 1: Schlüsselpaare erstellen
UEFI Secure Boot basiert auf den folgenden drei Schlüsseldatenbanken, die in einer Vertrauenskette verwendet werden: dem Plattformschlüssel (PK), dem Schlüsselaustauschschlüssel (KEK) und der Signaturdatenbank (db).¹
Sie erstellen jeden Schlüssel auf der Instance. Um die öffentlichen Schlüssel in einem Format vorzubereiten, das für den UEFI Secure Boot-Standard gültig ist, erstellen Sie für jeden Schlüssel ein Zertifikat. `DER` definiert das SSL-Format (Binärkodierung eines Formats). Anschließend konvertieren Sie jedes Zertifikat in eine UEFI-Signaturliste, bei der es sich um das Binärformat handelt, das von UEFI Secure Boot verstanden wird. Und schließlich signieren Sie jedes Zertifikat mit dem entsprechenden Schlüssel.
**Topics**
+ [Bereiten Sie die Erstellung der Schlüsselpaare vor](#uefisb-prepare-to-create-key-pairs)
+ [Schlüsselpaar 1: Erstellen Sie den Plattformschlüssel (PK)](#uefisb-create-key-pair-1)
+ [Schlüsselpaar 2: Erstellen Sie den Schlüsselaustauschschlüssel (KEK)](#uefisb-create-key-pair-2)
+ [Schlüsselpaar 3: Erstellen Sie die Signaturdatenbank (db)](#uefisb-create-key-pair-3)
+ [Signieren Sie das Boot-Image (Kernel) mit dem privaten Schlüssel.](#uefi-secure-boot-sign-kernel)
### Bereiten Sie die Erstellung der Schlüsselpaare vor
Erstellen Sie vor dem Erstellen der Schlüsselpaare einen global eindeutigen Bezeichner (GUID), der bei der Schlüsselgenerierung verwendet werden soll.
1. [Stellen Sie eine Verbindung zur Instance her.](connect.md)
1. Führen Sie in der Eingabeaufforderung einen Shell-Befehl aus.
```
uuidgen --random > GUID.txt
```
### Schlüsselpaar 1: Erstellen Sie den Plattformschlüssel (PK)
Der PK ist der Vertrauensanker für UEFI Secure Boot-Instances. Die private PK wird verwendet, um den KEK zu aktualisieren, der wiederum dazu verwendet werden kann, autorisierte Schlüssel zur Signaturdatenbank (db) hinzuzufügen.
Der X.509-Standard wird zum Erstellen des Schlüsselpaars verwendet. Informationen zum Standard finden Sie unter [X.509](https://en.wikipedia.org/wiki/X.509) auf *Wikipedia*.
**So erstellen Sie den PK**
1. Erstellen Sie den Schlüssel. Sie müssen die Variable `PK` benennen.
```
openssl req -newkey rsa:4096 -nodes -keyout PK.key -new -x509 -sha256 -days 3650 -subj "/CN=Platform key/" -out PK.crt
```
Die folgenden Parameter werden angegeben:
+ `-keyout PK.key` – Die private Schlüsseldatei.
+ `-days 3650` – Die Anzahl der Tage, an denen das Zertifikat gültig ist.
+ `-out PK.crt` – Das Zertifikat, das zum Erstellen der UEFI-Variablen verwendet wird.
+ `CN=Platform key` – Der gemeinsame Name (common name, CN) für den Schlüssel. Sie können stattdessen den Namen Ihrer eigenen Organisation eingeben. *Platform key*
1. Erstellen Sie das Zertifikat.
```
openssl x509 -outform DER -in PK.crt -out PK.cer
```
1. Wandeln Sie das Zertifikat in eine UEFI-Signaturliste um.
```
cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl
```
1. Signieren Sie die UEFI-Signaturliste mit dem privaten PK (selbstsigniert).
```
sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth
```
### Schlüsselpaar 2: Erstellen Sie den Schlüsselaustauschschlüssel (KEK)
Der private KEK wird verwendet, um Schlüssel zur Datenbank hinzuzufügen, was die Liste der autorisierten Signaturen darstellt, die im System gestartet werden sollen.
**So erstellen Sie den KEK**
1. Erstellen Sie den Schlüssel.
```
openssl req -newkey rsa:4096 -nodes -keyout KEK.key -new -x509 -sha256 -days 3650 -subj "/CN=Key Exchange Key/" -out KEK.crt
```
1. Erstellen Sie das Zertifikat.
```
openssl x509 -outform DER -in KEK.crt -out KEK.cer
```
1. Wandeln Sie das Zertifikat in eine UEFI-Signaturliste um.
```
cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl
```
1. Signieren Sie die Signaturliste mit dem privaten PK.
```
sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth
```
### Schlüsselpaar 3: Erstellen Sie die Signaturdatenbank (db)
Die db-Liste enthält autorisierte Schlüssel, die zum Booten auf dem System autorisiert sind. Um die Liste zu ändern, ist der private KEK erforderlich. Boot-Images werden mit dem privaten Schlüssel signiert, der in diesem Schritt erstellt wird.
**So erstellen Sie den db**
1. Erstellen Sie den Schlüssel.
```
openssl req -newkey rsa:4096 -nodes -keyout db.key -new -x509 -sha256 -days 3650 -subj "/CN=Signature Database key/" -out db.crt
```
1. Erstellen Sie das Zertifikat.
```
openssl x509 -outform DER -in db.crt -out db.cer
```
1. Wandeln Sie das Zertifikat in eine UEFI-Signaturliste um.
```
cert-to-efi-sig-list -g "$(< GUID.txt)" db.crt db.esl
```
1. Signieren Sie die Signaturliste mit dem privaten KEK.
```
sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db db.esl db.auth
```
### Signieren Sie das Boot-Image (Kernel) mit dem privaten Schlüssel.
Für Ubuntu 22.04 erfordern die folgenden Images Signaturen.
```
/boot/efi/EFI/ubuntu/shimx64.efi
/boot/efi/EFI/ubuntu/mmx64.efi
/boot/efi/EFI/ubuntu/grubx64.efi
/boot/vmlinuz
```
**So signieren Sie ein Image**
Verwenden Sie die folgende Syntax, um ein Image zu signieren.
```
sbsign --key db.key --cert db.crt --output /boot/vmlinuz /boot/vmlinuz
```
**Anmerkung**
Sie müssen alle neuen Kernel signieren. *`/boot/vmlinuz`* wird normalerweise einen Link zum zuletzt installierten Kernel führen.
In der Dokumentation Ihrer Distribution erfahren Sie mehr über Ihre Bootchain und die erforderlichen Images.
¹ Vielen Dank an die ArchWiki Community für all die Arbeit, die sie geleistet hat. Die Befehle zum Erstellen des PK, zum Erstellen des KEK, zum Erstellen der Datenbank und zum Signieren des Images stammen aus [Creating keys](https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Creating_keys), das vom ArchWiki Wartungsteam and/or und den Mitwirkenden verfasst wurde. ArchWiki
## Aufgabe 2 – Option A: Fügen Sie innerhalb der Instance Schlüssel zum Variablenspeicher hinzu
Nachdem Sie die [drei Schlüsselpaare](#uefi-secure-boot-create-three-key-pairs) erstellt haben, können Sie eine Verbindung zu Ihrer Instance herstellen und die Schlüssel innerhalb der Instance zum Variablenspeicher hinzufügen, indem Sie die folgenden Schritte ausführen. Führen Sie alternativ die Schritte unter [Aufgabe 2 – Option B: Erstellen Sie ein binäres Blob mit einem vorgefüllten Variablenspeicher](#uefi-secure-boot-optionB) aus.
**Topics**
+ [Schritt 1: Starten Sie eine Instance mit UEFI Secure Boot-Unterstützung](#step1-launch-uefi-sb)
+ [Schritt 2: Konfigurieren Sie eine Instance zur Unterstützung von UEFI Secure Boot](#step2-launch-uefi-sb)
+ [Schritt 3: Erstellen eines AMI Ihrer Instance](#step3-launch-uefi-sb)
### Schritt 1: Starten Sie eine Instance mit UEFI Secure Boot-Unterstützung
Wenn Sie mit den folgenden Voraussetzungen [eine Instance starten](LaunchingAndUsingInstances.md), kann die Instance dann für die Unterstützung von UEFI Secure Boot konfiguriert werden. Sie können die Unterstützung für UEFI Secure Boot nur für eine Instance beim Start aktivieren; Sie können sie später nicht aktivieren.
**Voraussetzungen**
+ **AMI** – Das Linux-AMI muss den UEFI-Startmodus unterstützen. Um zu überprüfen, ob das AMI den UEFI-Startmodus unterstützt, muss der AMI-Startmodus-Parameter **uefi** sein. Weitere Informationen finden Sie unter [Den Bootmodus-Parameter für ein Amazon-EC2-AMI bestimmen](ami-boot-mode.md).
Beachten Sie, dass AWS nur Linux AMIs so konfiguriert ist, dass es UEFI für Graviton-basierte Instance-Typen unterstützt. AWS stellt derzeit kein x86\$164-Linux AMIs bereit, das den UEFI-Boot-Modus unterstützt. Sie können Ihr eigenes AMI so konfigurieren, dass es den UEFI-Boot-Modus für alle Architekturen unterstützt. Um ein Ihren eigenes AMI für die Unterstützung des UEFI-Startmodus zu konfigurieren, müssen Sie eine Reihe von Konfigurationsschritten auf Ihrem eigenen AMI durchführen. Weitere Informationen finden Sie unter [Den Bootmodus eines Amazon-EC2-AMIs festlegen](set-ami-boot-mode.md).
+ **Instance-Typ** – Alle virtualisierten Instance-Typen, die UEFI unterstützen, unterstützen auch UEFI Secure Boot. Bare-Metal-Instance-Typen unterstützen UEFI Secure Boot nicht. Informationen zu den Instance-Typen, die UEFI Secure Boot unterstützen, finden Sie unter [Anforderungen für den UEFI-Bootmodus](launch-instance-boot-mode.md).
+ Starten Sie Ihre Instance nach dem Veröffentlichen von UEFI Secure Boot. Nur Instances, die nach dem 10. Mai 2022 (als UEFI Secure Boot veröffentlicht wurde) gestartet wurden, können UEFI Secure Boot unterstützen.
Nachdem Sie Ihre Instance gestartet haben, können Sie überprüfen, ob sie für die Unterstützung von UEFI Secure Boot konfiguriert werden kann (mit anderen Worten, Sie können mit [Schritt 2](#step2-launch-uefi-sb) fortfahren), indem Sie prüfen, ob UEFI-Daten vorhanden sind. Das Vorhandensein von UEFI-Daten weist darauf hin, dass nichtflüchtige Daten beibehalten werden.
**So überprüfen Sie, ob die Instance für Schritt 2 bereit ist**
Verwenden Sie den Befehl [https://docs.aws.amazon.com/cli/latest/reference/ec2/get-instance-uefi-data.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/get-instance-uefi-data.html) und geben Sie die Instance-ID an.
```
aws ec2 get-instance-uefi-data --instance-id i-1234567890abcdef0
```
Die Instance ist bereit für Schritt 2, wenn UEFI-Daten in der Ausgabe vorhanden sind. Wenn die Ausgabe leer ist, kann die Instance nicht für die Unterstützung von UEFI Secure Boot konfiguriert werden. Dies kann passieren, wenn Ihre Instance gestartet wurde, bevor die UEFI Secure Boot-Unterstützung verfügbar wurde. Starten Sie eine neue Instance und versuchen Sie es erneut.
### Schritt 2: Konfigurieren Sie eine Instance zur Unterstützung von UEFI Secure Boot
#### Registrieren Sie die Schlüsselpaare in Ihrem UEFI-Variablenspeicher in der Instance
**Warnung**
Sie müssen Ihre Boot-Images signieren, *nachdem* Sie die Schlüssel registriert haben, sonst können Sie Ihre Instance nicht starten.
Nachdem Sie die signierten UEFI-Signaturlisten (`PK`, `KEK` und `db`) erstellt haben, müssen sie bei der UEFI-Firmware registriert sein.
Schreiben in der `PK`-Variablen ist nur möglich, wenn:
+ Es ist noch keine PK angemeldet, was angegeben wird, wenn die `SetupMode`Variable `1` ist. Prüfen Sie dies mit dem folgenden Befehl: Die Ausgabe ist entweder `1` oder `0`.
```
efivar -d -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-SetupMode
```
+ Die neue PK ist durch den privaten Schlüssel der bestehenden PK signiert.
**So melden Sie die Schlüssel in Ihrem UEFI-Variablenspeicher an**
Die folgenden Befehle müssen in der Instance ausgeführt werden.
Wenn aktiviert SetupMode ist (der Wert ist`1`), können die Schlüssel registriert werden, indem die folgenden Befehle auf der Instanz ausgeführt werden:
```
[ec2-user ~]$ efi-updatevar -f db.auth db
```
```
[ec2-user ~]$ efi-updatevar -f KEK.auth KEK
```
```
[ec2-user ~]$ efi-updatevar -f PK.auth PK
```
**So überprüfen Sie, ob UEFI Secure Boot aktiviert ist**
Führen Sie die Schritte unter [Überprüfen, ob eine Amazon-EC2-Instance für UEFI Secure Boot aktiviert ist](verify-uefi-secure-boot.md) aus, um zu überprüfen, ob UEFI Secure Boot aktiviert ist.
Sie können Ihren UEFI-Variablenspeicher jetzt mit dem CLI-Befehl [https://docs.aws.amazon.com/cli/latest/reference/ec2/get-instance-uefi-data.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/get-instance-uefi-data.html) exportieren oder mit dem nächsten Schritt fortfahren und Ihre Boot-Images signieren, um sie in einer UEFI Secure Boot-fähigen Instance neu zu starten.
### Schritt 3: Erstellen eines AMI Ihrer Instance
Um ein AMI aus der Instance zu erstellen, können Sie die Konsole oder die `CreateImage` API, CLI oder verwenden SDKs. Informationen zur Verwendung der Konsole finden Sie unter [Ein Amazon-EBS-gestütztes AMI erstellen](creating-an-ami-ebs.md). Die API-Anweisungen finden Sie unter [CreateImage](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateImage.html).
**Anmerkung**
Die `CreateImage`-API kopiert den UEFI-Variablenspeicher der Instance automatisch in das AMI. Die Konsole verwendet die `CreateImage`-API. Nachdem Sie Instances mit diesem AMI gestartet haben, haben die Instances denselben UEFI-Variablenspeicher.
## Aufgabe 2 – Option B: Erstellen Sie ein binäres Blob mit einem vorgefüllten Variablenspeicher
Nachdem Sie die [drei Schlüsselpaare](#uefi-secure-boot-create-three-key-pairs) erstellt haben, können Sie ein binäres Blob erstellen, das einen vorgefüllten Variablenspeicher enthält, der die UEFI Secure Boot-Schlüssel enthält. Führen Sie alternativ die Schritte unter [Aufgabe 2 – Option A: Fügen Sie innerhalb der Instance Schlüssel zum Variablenspeicher hinzu](#uefi-secure-boot-optionA) aus.
**Warnung**
Sie müssen Ihre Boot-Images signieren, *bevor* Sie die Schlüssel registrieren, sonst können Sie Ihre Instance nicht starten.
**Topics**
+ [Schritt 1: Erstellen Sie einen neuen Variablenspeicher oder aktualisieren Sie einen vorhandenen](#uefi-secure-boot-create-or-update-variable)
+ [Schritt 2: Hochladen des binären Blobs bei der AMI-Erstellung](#uefi-secure-boot-upload-binary-blob-on-ami-creation)
### Schritt 1: Erstellen Sie einen neuen Variablenspeicher oder aktualisieren Sie einen vorhandenen
Sie können den Variablenspeicher *offline* ohne eine laufende Instance erstellen, indem Sie das Python-Uefivars-Tool verwenden. Das Tool kann aus Ihren Schlüsseln einen neuen Variablenspeicher erstellen. Das Skript unterstützt derzeit das EDK2 Format, das AWS Format und eine JSON-Darstellung, die mit Tools auf höherer Ebene einfacher zu bearbeiten ist.
**So erstellen Sie den Variablenspeicher offline ohne laufende Instance**
1. Laden Sie das Tool unter folgendem Link herunter.
```
https://github.com/awslabs/python-uefivars
```
1. Erstellen Sie einen neuen Variablenspeicher von Ihren Schlüsseln, indem Sie den folgenden Befehl ausführen. Dadurch wird ein Base64-kodierter Binär-Blob in .bin erstellt. *your\$1binary\$1blob* Das Tool unterstützt auch das Aktualisieren eines binären Blobs über die `-I`-Parameter.
```
./uefivars.py -i none -o aws -O your_binary_blob.bin -P PK.esl -K KEK.esl --db db.esl --dbx dbx.esl
```
### Schritt 2: Hochladen des binären Blobs bei der AMI-Erstellung
Verwenden Sie [https://docs.aws.amazon.com/cli/latest/reference/ec2/register-image.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/register-image.html) um Ihre UEFI-Variablenspeicherdaten zu übergeben. Geben Sie für den Parameter `--uefi-data` geben Sie Ihr binäres Blob an, und geben Sie für den Parameter `--boot-mode` `uefi` an.
```
aws ec2 register-image \
--name uefi_sb_tpm_register_image_test \
--uefi-data $(cat your_binary_blob.bin) \
--block-device-mappings "DeviceName=/dev/sda1,Ebs= {SnapshotId=snap-0123456789example,DeleteOnTermination=true}" \
--architecture x86_64 \
--root-device-name /dev/sda1 \
--virtualization-type hvm \
--ena-support \
--boot-mode uefi
```
# Erstellen Sie den AWS binären Blob für UEFI Secure Boot
Sie können die folgenden Schritte ausführen, um die UEFI Secure Boot-Variablen während der AMI-Erstellung anzupassen. Der KEK, der in diesen Schritten verwendet wird, ist auf dem Stand von September 2021. Wenn Microsoft den KEK aktualisiert, müssen Sie den neuesten KEK verwenden.
**Um den AWS binären Blob zu erstellen**
1. Erstellen Sie eine leere PK-Signaturliste.
```
touch empty_key.crt
cert-to-efi-sig-list empty_key.crt PK.esl
```
1. Laden Sie die KEK-Zertifikate herunter.
```
https://go.microsoft.com/fwlink/?LinkId=321185
```
1. Verpacken Sie die KEK-Zertifikate in einer UEFI-Signaturliste (`siglist`).
```
sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK.esl MicCorKEKCA2011_2011-06-24.crt
```
1. Laden Sie Microsofts DB-Zertifikate herunter.
```
https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt
https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt
```
1. Generieren Sie die DB-Signaturliste.
```
sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db.esl MicWinProPCA2011_2011-10-19.crt
sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db.esl MicCorUEFCA2011_2011-06-27.crt
cat MS_Win_db.esl MS_UEFI_db.esl > MS_db.esl
```
1. Das Unified Extensible Firmware Interface Forum stellt die DBX-Dateien nicht mehr zur Verfügung. Sie werden jetzt von Microsoft am bereitgestellt GitHub. Laden Sie das neueste DBX-Update aus dem Microsoft Secure Boot-Updates-Repository unter [https://github.com/microsoft/secureboot\$1objects](https://github.com/microsoft/secureboot_objects) herunter.
1. Entpacken Sie die signierte Update-Binärdatei.
Erstellen Sie `SplitDbxContent.ps1` mit dem folgenden Skriptinhalt. [Alternativ können Sie das Skript aus der Galerie mit installieren. PowerShell ](https://www.powershellgallery.com/packages/SplitDbxContent/1.0) `Install-Script -Name SplitDbxContent`
```
<#PSScriptInfo
.VERSION 1.0
.GUID ec45a3fc-5e87-4d90-b55e-bdea083f732d
.AUTHOR Microsoft Secure Boot Team
.COMPANYNAME Microsoft
.COPYRIGHT Microsoft
.TAGS Windows Security
.LICENSEURI
.PROJECTURI
.ICONURI
.EXTERNALMODULEDEPENDENCIES
.REQUIREDSCRIPTS
.EXTERNALSCRIPTDEPENDENCIES
.RELEASENOTES
Version 1.0: Original published version.
#>
<#
.DESCRIPTION
Splits a DBX update package into the new DBX variable contents and the signature authorizing the change.
To apply an update using the output files of this script, try:
Set-SecureBootUefi -Name dbx -ContentFilePath .\content.bin -SignedFilePath .\signature.p7 -Time 2010-03-06T19:17:21Z -AppendWrite'
.EXAMPLE
.\SplitDbxAuthInfo.ps1 DbxUpdate_x64.bin
#>
# Get file from script input
$file = Get-Content -Encoding Byte $args[0]
# Identify file signature
$chop = $file[40..($file.Length - 1)]
if (($chop[0] -ne 0x30) -or ($chop[1] -ne 0x82 )) {
Write-Error "Cannot find signature"
exit 1
}
# Signature is known to be ASN size plus header of 4 bytes
$sig_length = ($chop[2] * 256) + $chop[3] + 4
$sig = $chop[0..($sig_length - 1)]
if ($sig_length -gt ($file.Length + 40)) {
Write-Error "Signature longer than file size!"
exit 1
}
# Content is everything else
$content = $file[0..39] + $chop[$sig_length..($chop.Length - 1)]
# Write signature and content to files
Set-Content -Encoding Byte signature.p7 $sig
Set-Content -Encoding Byte content.bin $content
```
Verwenden Sie das Skript, um die signierten DBX-Dateien zu entpacken.
```
PS C:\Windows\system32> SplitDbxContent.ps1 .\dbx.bin
```
Dadurch werden zwei Dateien erzeugt – `signature.p7` und `content.bin`. Verwenden Sie `content.bin` im nächsten Schritt.
1. Erstellen Sie einen UEFI-Variablenspeicher mit dem `uefivars.py`-Skript.
```
./uefivars.py -i none -o aws -O uefiblob-microsoft-keys-empty-pk.bin -P ~/PK.esl -K ~/MS_Win_KEK.esl --db ~/MS_db.esl --dbx ~/content.bin
```
1. Prüfen Sie das binäre Blob und den UEFI-Variablenspeicher.
```
./uefivars.py -i aws -I uefiblob-microsoft-keys-empty-pk.bin -o json | less
```
1. Sie können das Blob aktualisieren, indem Sie es erneut an dasselbe Tool übergeben.
```
./uefivars.py -i aws -I uefiblob-microsoft-keys-empty-pk.bin -o aws -O uefiblob-microsoft-keys-empty-pk.bin -P ~/PK.esl -K ~/MS_Win_KEK.esl --db ~/MS_db.esl --dbx ~/content.bin
```
Erwartete Ausgabe
```
Replacing PK
Replacing KEK
Replacing db
Replacing dbx
```