====== Secure Boot ====== Im Zusammenhang mit diesen Artikel verwendete Hardware: https://www.heckpiet.net/dell-wyse-5070-thin-client-als-home-sever Im UEFI lässt sich SecureBoot aktivieren/deaktivieren. Oft ist parallel dazu auch die Konfiguration von TPM(TrustedPlattformModul) möglich. Auf Rechnern mit UEFI und ohne aktivierter rückwärts-Kompatibilität zum alten BIOS Standard können nur Datenträger mit Betriebssystemen gestartet werden, welche eine entsprechende Boot Partition haben. Hier ist die Boot Partition die 1. Partition auf dem Datenträger /dev/sda, also unter Linux mit ''/dev/sda1'' angesprochen. iglu:~ # parted -l Model: VMware Virtual disk (scsi) Disk /dev/sda: 53.7GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 538MB 537MB fat32 boot, esp 2 538MB 51.5GB 51.0GB btrfs 3 51.5GB 53.7GB 2149MB linux-swap(v1) swap Die Partitionstabelle muss **gpt** sein, das Dateisystem FAT und bei Flags muss ''boot'', ''esp'' stehen. Zu beachten ist, das auf einem PC mit mehreren Betriebssystemen es dazu kommen kann das ein System nicht mehr bootet mit der Meldung "Security Validation Failed". ==== Fehlermeldungen ==== Fehlermeldungen die auftreten können: ERROR verification failed 0x1A security violation Failed to load image: Security Policy Violation Failed to open \EFI\BOOT\mmx64.efi Not Found error:shim_lock protocol not found bad signature: (hd0, ecx4) /database2/boot/kernel_mapping) ===== mokutil ===== Eine **Abhilfe** bietet hier das ''mokutil''. Es ist evtl. nötig die default Keys im UEFI wieder herszustellen, der Secure BootStick verlangt evtl. den Standard Microsoft Key Folgende Kommandos zeigen zumindest: mokutil --kek * [key 1] = C=US, ST=Texas, L=Round Rock, O=Dell Inc., CN=Dell Inc. Platform Key * [key 2] = C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root mokutil --db * [key 1] = C=US, ST=Texas, L=Round Rock, O=Dell Inc., CN=Dell Inc. Key Exchange Key * [key 2] = C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root * [key 3] = C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Root Certificate Authority 2010 mokutil --dbx * [key 1] = C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Root Certificate Authority 2010 * [key 2] = [SHA-256] 80b4d96931b... ewig lang ...856967df8e Ansonsten gilt: Secure Boot deaktivieren und die folgenden Kommandos ausführen. Falls sich Secure Boot nicht deaktivieren lässt (Dell), dann ein System starten, welches mit den Standard Signaturen starten kann. In meinem Fall hatte OpenSuse neuere Keys bzw. seine eigenen Suse Key im NVRAM des UEFI Chips geladen und wohl auch die Secure Boot Advanced Targeting (SBAT) aktualisiert so das ältere Micosoft Keys nicht mehr funktionieren, sondern nur neuere Versionen davon - Hauptgrund warum der Boot-Stick nicht mehr startet. folgender Kommando zeigt nur einen **[key 1]** Issuer: CN=SUSE Linux Enterprise Secure Boot CA - so sieht es auch aus wenn es funktioniert. mokutil --list-enrolled Disabling/re-enabling Secure Boot: mokutil --disable-validation or mokutil --enable-validation mokutil --reset mokutil --set-sbat-policy previous / delete Choose a password between 8 and 16 characters long. Enter the same password to confirm it. Reboot. When prompted, press a key to perform MOK management. Select „Change Secure Boot state“. Enter each requested character of your chosen password to confirm the change. Note that you have to press Return/Enter after each character. - Select „Yes“. - Select „Reboot“. Im MOK Manager der direkt nach dem reboot aufgerufen wird alles löschen bzw. deaktiveren, MOK List delete und Validation deaktiveren. Wenn es funktioniert, dann sollte folgendes angezeigt werden: mokutil --list-sbat-revocations sbat,1,2022052400 grub,2 ==== Interessant aber ungetestet ==== Manipulate the MOK blacklist mokutil --mokx ===== shim Bootloader ===== Wird nach GRUB aufgerufen wenn festgstellt wird das Standard Bootloader nicht signiert ist Der shim Bootloader benötigt eine UEFI kompatible GPT Boot Partition sonst kommt die Meldung # shim-install No valid EFI partition The default boot loader used by openSUSE on UEFI systems is grub2. When in secure boot mode, an additional boot loader called 'shim' is used too. Instead of directly calling grub2 in that mode the firmware first loads 'shim'. 'shim' carries a signature by Microsoft in order to be recognized by the firmware. 'shim' in turn knows about the openSUSE certificate that was used to sign grub2. grub2 then is able to load linux kernels that are also signed by the openSUSE certificates. After loading the Linux kernel the scope of secure boot ends. The linux kernel used in openSUSE does not impose additional restrictions. In order to allow having custom boot loaders as well as custom kernels shim offers a way to import custom signatures. The program 'MokManager' is used for that purpose. When 'shim' is instructed to load a binary that is not signed by a well known entity it calls into MokManager which allows to import certificates into the database of well known signature issuers. Damit beim Suse Updates kein zu neuer restiktiver shim aktiv wird wurden nun sicherheitshalber Updates für shim blockiert: iglu:~ # zypper la shim Specified lock has been successfully added. iglu:~ # zypper ll # | Name | Type | Repository | Comment --+------+---------+------------+-------- 1 | shim | package | (any) | ===== efiboot ===== apt list "uefi" Auflistung… Fertig ... uefitool-cli/stable 0.28.0-1 arm64 uefitool-cli/stable 0.28.0-1 armhf uefitool/stable 0.28.0-1 arm64 uefitool/stable 0.28.0-1 armhf ~ # efiboot efibootdump efibootmgr ===== sbsigntools ===== Canonical EFI binary signing tools sbsigntools ===== Funktion Beobachtung ===== Boot funktioniert mit ECOS Stick ==== UEFI ==== UEFI Einstellung: TPM = deaktiviert Secure Boot = aktiviert aber auf alles erlauben gesetzt. Schlüssel stehen auf Custom Mode enabled, d.h. man kann Schlüssel setzen und die Einstellungen bleiben, evtl. hier sogar keinen Custom Mode damit immer der Ursprung fest eingestellt bleibt? Z.B. bei Suse Updates. ==== SUSE ==== === bootctl status === systemd-boot not installed in ESP. System: Firmware: n/a (n/a) Secure Boot: disabled Setup Mode: setup TPM2 Support: no Boot into FW: supported === mokutil === mokutil --list-sbat-revocations sbat,1,2022052400 grub,2 mokutil --sb-state SecureBoot disabled <-- sagt disabled im UEFI steht enabled Platform is in Setup Mode Erstaunlich, Kommandos liefern nichts zurück, kein Plattform Key? Im UEFI nur dbx gelöscht. mokutil --pk Dieser Kommando liefert nun 2 key zurück, in Suse keine Updates eingespielt, kann nur vom BootStick sein. mokutil --dbx Kommando mit ''--list-enrolled'' liefert wie zu erwarten den SUSE Key zurück mokutil --list-enrolled [key 1] ... Issuer: CN=SUSE Linux Enterprise Secure Boot CA, C=DE, L=Nuremberg, O=SUSE Linux Products GmbH, OU=Build Team/emailAddress=build@suse.de Validity Not Before: Apr 18 14:33:41 2013 GMT Not After : Mar 14 14:33:41 2035 GMT Subject: CN=SUSE Linux Enterprise Secure Boot CA, C=DE, L=Nuremberg, O=SUSE Linux Products GmbH, OU=Build Team/emailAddress=build@suse.de ===== efi-readvar ===== Kommando ''efi-readvar'' liefert: Variable PK has no entries Variable dbx has no entries Variable MokList has no entries bei KEK: wird was angezeigt List 0 und List1 bei db: wird was angezeigt List 0, List 1 und List 2 Auslesen von dbx und speichern in Datei dbx.esl ? efi-readvar -v dbx -o dbx.esl === efibootmgr === Kommando ''efibootmgr -v'' zeigt natürlich bei meiner angesteckten USB Festplatte und gestarteten SUSE meine Suse Start Partition ganz oben. Wenn meine Festplatte weg ist, würde der folgende Eintrag starten: Boot0004* RH2 PciRoot(0x0)/Pci(0x15,0x0)/USB(2,0)/HD(1,GPT,b90c1753-d520-47c9-a136-5a0ad43e2cd2,0x1000,0x5000)/File(\EFI\BOOT\BOOTx64.EFI) === fwupdmgr === fwupdmgr get-history No history Zeigt eine Liste der verbauten / angeschlossenen Geräte mit Update Informationen. Liste habe ich bereits gespeichert. fwupdmgr get-devices ===== keytool ===== tux@iglu:/Downloads # keytool -printcert -file microsoft-uefica-public.cer Owner: CN=Microsoft Corporation UEFI CA 2011, O=Microsoft Corporation, L=Redmond, ST=Washington, C=US Issuer: CN=Microsoft Corporation Third Party Marketplace Root, O=Microsoft Corporation, L=Redmond, ST=Washington, C=US Serial number: 6108d3c4000000000004 Valid from: Mon Jun 27 23:22:45 CEST 2011 until: Sat Jun 27 23:32:45 CEST 2026 Certificate fingerprints: SHA1: 46:DE:F6:3B:5C:E6:1C:F8:BA:0D:E2:E6:63:9C:10:19:D0:ED:14:F3 SHA256: 48:E9:9B:99:1F:57:FC:52:F7:61:49:59:9B:FF:0A:58:C4:71:54:22:9B:9F:8D:60:3A:C4:0D:35:00:24:85:07 Signature algorithm name: SHA256withRSA Subject Public Key Algorithm: 2048-bit RSA key Version: 3 Extensions: #1: ObjectId: 1.3.6.1.4.1.311.20.2 Criticality=false 0000: 1E 0A 00 53 00 75 00 62 00 43 00 41 ...S.u.b.C.A #2: ObjectId: 1.3.6.1.4.1.311.21.1 Criticality=false 0000: 02 03 01 00 01 ..... #3: ObjectId: 1.3.6.1.4.1.311.21.2 Criticality=false 0000: 04 14 F8 C1 6B B7 7F 77 53 4A F3 25 37 1D 4E A1 ....k..wSJ.%7.N. 0010: 26 7B 0F 20 70 80 &.. p. #4: ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false AuthorityInfoAccess [ [ accessMethod: caIssuers accessLocation: URIName: http://www.microsoft.com/pki/certs/MicCorThiParMarRoo_2010-10-05.crt ] ] #5: ObjectId: 2.5.29.35 Criticality=false AuthorityKeyIdentifier [ KeyIdentifier [ 0000: 45 66 52 43 E1 7E 58 11 BF D6 4E 9E 23 55 08 3B EfRC..X...N.#U.; 0010: 3A 22 6A A8 :"j. ] ] #6: ObjectId: 2.5.29.19 Criticality=true BasicConstraints:[ CA:true PathLen:2147483647 ] #7: ObjectId: 2.5.29.31 Criticality=false CRLDistributionPoints [ [DistributionPoint: [URIName: http://crl.microsoft.com/pki/crl/products/MicCorThiParMarRoo_2010-10-05.crl] ]] #8: ObjectId: 2.5.29.15 Criticality=false KeyUsage [ DigitalSignature Key_CertSign Crl_Sign ] #9: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: 13 AD BF 43 09 BD 82 70 9C 8C D5 4F 31 6E D5 22 ...C...p...O1n." 0010: 98 8A 1B D4 .... ] ]