Secure Boot und Zertifizierung

Hier ist die Work-in-Pogress Zone für alles Nichtallgemeine sondern Konkrete an Vorarbeiten für die kommenden UEFI-Wiki-Artikel
Forumsregeln
Alles was konkrete Vorarbeiten zu den geplanten UEFI bezogenen Wiki-Artikeln angeht und keine allgemeine Infos sondern eben genauere Arbeitsschritte, detaliertere Anleitungen, aufgetauchte Probleme, Workarounds um eben diese etc. darstellt bitte hier reinsetzen.

Secure Boot und Zertifizierung

Beitragvon Robi » Do 12. Feb 2015, 23:05

Wohl eines der schwierigeren Themen. Wer sich dafür berufen fühlt und sich damit befassen will. Vom Vorteil ist wohl, wer beruflich hin und wieder mal mit openssl und x509 zu tun hat.

Vorschlag;
Folgendes mal durcharbeiten
Auf einer mit UEFI gebooteten Maschine das passende Repo von hier einbinden und efitools und sbsigntools installieren und mal etwas rumspielen.

Ziel:
    * Eine kleine vom normalem User verdauliche Beschreibung was der Secureboot genau ist und wie er vereinfacht ausgedrücklt funktioniert.
    * Eine ungefähre Erklärung oder Beschreibung was es mit den Microsoft-Zertifikaten und dem ganzem Theater damit, auf sich hat.
    * Ein Howto wie man unter Linux seine eigenen Zertifikate erstellt und verwaltet und damit zB seinen Bootloader oder andere EFI-Binaries zertifiziert um zu verhindern das irgendwas anderes starten kann. (zB als Sicherheit auf einem Linuxserver)

Beschreibung wie das genau geht, sollte bei den paketen beiliegen und auch im Netz zu finden sein.

Nebenaufgabe:
Heraufinden ob und was in den verschiedenen ovmf für Zertifikate drin sind.
Code: Alles auswählen
# ls -l /usr/share/qemu/ovmf-x86_64*.bin
-rw-r--r-- 1 root root 1966080 Dec 28 16:07 /usr/share/qemu/ovmf-x86_64-code.bin
-rw-r--r-- 1 root root 1966080 Dec 28 16:07 /usr/share/qemu/ovmf-x86_64-devel-code.bin
-rw-r--r-- 1 root root  131072 Dec 28 16:07 /usr/share/qemu/ovmf-x86_64-devel-vars.bin
-rw-r--r-- 1 root root 2097152 Dec 28 16:07 /usr/share/qemu/ovmf-x86_64-devel.bin
-rw-r--r-- 1 root root 1966080 Dec 28 16:07 /usr/share/qemu/ovmf-x86_64-ms-code.bin
-rw-r--r-- 1 root root  131072 Dec 28 16:07 /usr/share/qemu/ovmf-x86_64-ms-vars.bin
-rw-r--r-- 1 root root 2097152 Dec 28 16:07 /usr/share/qemu/ovmf-x86_64-ms.bin
-rw-r--r-- 1 root root 1966080 Dec 28 16:07 /usr/share/qemu/ovmf-x86_64-opensuse-4096-code.bin
-rw-r--r-- 1 root root  131072 Dec 28 16:07 /usr/share/qemu/ovmf-x86_64-opensuse-4096-vars.bin
-rw-r--r-- 1 root root 2097152 Dec 28 16:07 /usr/share/qemu/ovmf-x86_64-opensuse-4096.bin
-rw-r--r-- 1 root root 1966080 Dec 28 16:07 /usr/share/qemu/ovmf-x86_64-opensuse-code.bin
-rw-r--r-- 1 root root  131072 Dec 28 16:07 /usr/share/qemu/ovmf-x86_64-opensuse-vars.bin
-rw-r--r-- 1 root root 2097152 Dec 28 16:07 /usr/share/qemu/ovmf-x86_64-opensuse.bin
-rw-r--r-- 1 root root 1966080 Dec 28 16:07 /usr/share/qemu/ovmf-x86_64-suse-code.bin
-rw-r--r-- 1 root root  131072 Dec 28 16:07 /usr/share/qemu/ovmf-x86_64-suse-vars.bin
-rw-r--r-- 1 root root 2097152 Dec 28 16:07 /usr/share/qemu/ovmf-x86_64-suse.bin
-rw-r--r-- 1 root root  131072 Dec 28 16:07 /usr/share/qemu/ovmf-x86_64-vars.bin
-rw-r--r-- 1 root root 2097152 Dec 28 16:07 /usr/share/qemu/ovmf-x86_64.bin


Alles zum Thema Secureboot vorläufig mal in diesen Thread

robi
Robi
 
Beiträge: 68
Themen: 10
Registriert: So 15. Feb 2015, 16:02

Re: Secure Boot und Zertifizierung

Beitragvon Robi » Fr 6. Mär 2015, 23:13

Tests: Secure Boot mit OVMF.

Nach einer Woche Test und lesen von unzähligen Webseiten, Spezifikationen und Dokus hab ich jetzt endlich eine Idee wie das Ganze überhaupt funktioniert.

Spezifikation dafür >= UEFI 2.3,1
Das Ganze beruht auf folgender Struktur, die mit UEFI-Variablen ( wobei man sich unter UEFI-Variablen etwas viel komplexeres Vorstellen muss, als eine einfache Variable mit einem Wert) abgebildet wird und in einem vor Manipulation und Löschung geschützten Flash-speicher abgelegt wird. ( gegebenenfalls sogar auf speziellen HSM Chips ( Hardware Security Module) )

PK (Platform Key database)
KEK (Key Exchange Key Database)
DB (Allowed/Authorized Signature Database)
DBx (Forbidden Database)

und einem zusätzlichen für uns und Secure Boot unwichtigen "Secure Boot firmware update key", der dafür zuständig ist, dass nur vom Hersteller freigegebene FW upgedatet werden kann, und bei "wichtigen" Rechnertypen sogar bei jedem anschalten des Rechners überprüft wird.

In dieser Datenbank sind x590 Zertifikate ( in DB und DBx auch sha-1 hash möglich) hinterlegt. Die Funktion und das Zusammenspiel ist wie folgt.

PK (Vertrauens-Basis zwischen dem Plattform-Besitzer und Plattform-Firmware) hier befindet sich genau ein Zertifikat, Dieses ist vom "Plattform Owner", es kann immer nur eines dort geben und es ist das Wichtigste überhaupt. Wer den privat Key zu diesem Zertifikat hat, hat die volle Kontrolle über alle anderen in der Datenbank hinterlegten Einträge. Ohne ein solches Zertifikat befindet sich der UEFI im "Setup mode", In diesem Modus können problemlos in die anderen Datenbanken Einträge vorgenommen werden. Wird ein solches PK Zertifikat abgelegt, wechselt UEFI in den "User mode" und schaltet Secure Boot aktiv. Um in diesem Zustand dann einen Eintrag in PK oder KEK vorzunehmen oder zu ändern, oder zurück in den Setup mode zu kommen, würde man den privaten Key vom PK benötigen um das zu autorisieren . Ein solches PK Zertifikat wird schon bei der Herstellung dort installiert.

KEK (Vertrauens-Basis zwischen dem Betriebssystem und Plattform-Firmware) hier können 1 oder auch mehrere Zertifikate abgelegt werden. Mit diesen Zertifikaten ( und den passenden privat Keys dazu) ist es möglich Einträge in die DB und DBx vorzunehmen wenn sich der UEFI im "User mode" befindet und man mit dem Privaten Key die Änderung zertifiziert. Es muss aber schon im Herstellungsprozess folgendes Microsoft Zertifikat dort im KEK abgelegt werden.

DB (Vertrauensbasis zu UEFI-Treibern, Bootloadern, Bootimages, option ROMs und UEFI Applikationen) hier werden die Zertifikate hinterlegt gegen die sich mit denen im Secure Modus die Treiber, Bootloader und Applikationen verifizieren müssen. Sprich, alles was im Secure Modus gestartet werden darf, muss mit einem der Zertifikate signiert sein, (wozu man den priv Key dieses Zertifikates benötigen würde) Theoretisch ist es möglich hier auch einen sha1 Hash eines dieser Objekte abzulegen, was dann diesem speziellem Objekt auch ein starten ernöglichen würde. Hier muss im Herstellungsprozess schon folgende Zertifikate abgelegt werden.
Microsoft Windows Production PCA 2011 (mit diesem Zertifikat werden die Microsoft Bootloader signiert) und Microsoft Corporation UEFI CA 2011 (mit diesem Zertifikat werden Treiber, Applikationen und Bootloader von anderen Herstellern signiert. zB auch shim ) Weiterhin ist es möglich das sich dort weitere Zertifikate befinden, zB auch von Linuxdistributionen Ubuntu oder vom OEM. Änderungen und Erweiterungen im Usermodus müssen entweder mit dem PK oder KEK Zertifikat und dem dazugehörigen priv Key autorisiert werden.

DBx ist das Gegenteil von DB also eine Blacklist, dort könnten auch Zertifikate hinterlegt werden, (macht aber wohl weniger Sinn) aber die Objekte die einen sha Hash in der DBx haben, dürften nicht zum Starten von UEFI im Secure Boot akzeptiert werden, selbst wenn sie mit einem in der DB eingetragenen Zertifikat signiert sind. Hiermit ist es also möglich einzelne schon signierte Objekte wieder zu sperren.



Zusammengefasst in einem Satz: Die Signatur-DB wird schon zur Fertigungszeit im NVRAM abgelegt. Microsoft besitzt in KEK einen Schlüssel, und in der DB zwei Schlüssel, die es erlaubt DB Einträge zu verwalten und signierte Objekte hinzuzufügen und zu widerrufen. Die privaten Keys die man benötigen würde sind warscheinlich hinter 10 Meter dickem Stahl verschlossen, damit die ja niemand in die Hände bekommen kann. Microsoft hat also in punkto Secure Boot auf allen UEFI_BIOS basierenden Rechnern einen Generalschlüssel. Ein Blick in das "Windows Certification Program : Hardware Certification Taxonomy & Requirements" Abschnitt
"System.Fundamentals.Firmware.UEFISecureBoot" zeigt dann auch auf, was wir auf aktuellen Boards in Punkto Secure Boot zu erwarten haben, welche Voreinstellungen, welches Verhalten und den welche Einstellmöglichkeiten im UEFI-Setup die HW-Hersteller einbauen müssen, damit sie die HW von Microsoft für aktuelle Versionen zertifiziert bekommen..
Da sind unter andern in den Punkten 17, 18 und 19 auch Punkte enthalten, die die Allmacht von Secure Boot etwas entschärfen und es dem User zumindestens teilweise auch gestatten würden die Herrschafft über seinen Rechner selbst zu übernehmen und zu gestallten.

Linuxdistributionen haben mit Secure Boot ein kleines Problem, das mehr oder weniger darin besteht, dass die Oberherrschafft über die Zertifizierung derzeit einzig und allein bei Microsoft liegt und es nicht ausreicht, dass nur der Bootloader signiert ist, Auch der Kernel muss signiert sein und ebenfalls bestimmte Module des Kernels( was aber derzeit vom Kernel selbst kontrolliert wird). Verschiedene Distributionen gehen hier auch verschiedene Wege, und ob der Königsweg derzeit schon gefunden ist, sei dahingestellt. Einer dieser Wege heißt shim und erweitert in gewissen Sinne diese Secure Firmware-Datenbank, so dass dieses Methode hier in diesem Zusammenhang am besten gleich mit beschrieben werden sollte.

Shim ist ein einfacher Pre-Boot-Loader dessen Aufgabe es ist einen anderen Bootloader zu starten, typischer Weise grub2. Der Sinn dahinter, für einen Boot im Secureboot muss nur Shim zertifiziert sein. Die Zertifikate für den nachfolgenden Bootloader und den Kernel sind in Shim enthalten und damit ist es möglich auch einen Bootloader und Kernel zu booten der selbst nicht mit einem Zertifikat aus dem UEFI signiert ist. In shim wird das Zertifikat der Distribution hinterlegt und das efi-Shim-binary auch mit diesem Zertifikat signiert, Zusätzlich wird noch eine offizielle Signierung mit dem "Microsoft Corporation UEFI CA 2011" Zertifikat angestoßen. Damit kann Shim im Secureboot normal starten, und dann einen Bootloader und Kernel der mit dem Zertifikat dieser Distribution signiert ist im Secureboot starten. Beim Boot mittels Shim werden also sowohl der von Shim gestartete Bootloader als auch der zu startende Kernel nach den Richtilinien von UEFI überprüft, nur eben nicht zwangläufig nur gegen die Zertifikate die im UEFI hinterlegt sind. Die Vertrauensbasis auf der Secureboot aufgebaut ist, wird auf diese Weise gewährleistet.

Shim kann aber mehr, es ist möglich ihn interaktiv zu erweitern weitere Zertifikate und auch Hash von Bootloadern hinzuzufügen. Dieses wird in eine eigene MOK-List (Machine Owner Key Liste) abgelegt. Diese wird nicht wie die normalen Signatur-DB-Variablen abgelegt, sondern in Variablen die zwar permanent sind, aber jeweils nur bis zum Ende des Bootstart vorhanden sind. Damit lassen sich diese Variablen dann auch nicht vom Betriebssystem aus erzeugen oder manipulieren, sondern nur vor dem eigentlichem Bootvorgang im UEFI und zwar lokal am Rechner selbst. Es ist also zB. für Malware oder andere ungebetene Gäste auf Betriebssystemebene nicht möglich, hier an diesen MOKs irgendwas zu manipulieren. Das Aufnehmen von weiteren und auch von eigenen Zertifikaten in die MOK Liste ist wesentlich einfacher als in die DB-Liste, und es werden dabei auch nicht die privaten Keys benötigt. Dieses kann aber nur interaktiv im UEFI erfolgen und nicht vom gestarteten Betriebssytem aus. Derzeit benutzen per default mehrere Distributionen shim im Zusammenspiel mit grub2 für UEFI-Boot im Secure Mode.


Die letzten Tage habe ich viel mit OVMF getestet. Zertifikate erstellt und in die verschiedensten Standards konvertiert und autorisiert, EFI-Treiber, Kernel und Bootloader signiert und überprüft wer mit welchen Zertifikaten signiert, die Signatur-Datenbank modifiziert sowohl aus dem Setup-Menü, aus der EFI-Shell und aus Linux heraus sowie das Verhalten der einzelnen Bootloader im Secure Mode getestet, sowie eine Menge diverser Tools sowohl für die UEFI-Umgebung als auch für Linux ausprobiert.
Viele der Programme und Tools die ich hierzu verwendet habe, hatten derzeit nur schlechte bzw gar keine Doku und längst ist auch noch nicht alles fertig und stabil, ehr vieles noch im Experimentierstatus. Aber zumindestens mit OVMF funktioniert sogut wie alles. Ich freue mich schon auf das neue Systemboard das ich hier demnächst mit einer aktuellen UEFI-Version einbauen werde. Bis dort hin muss ich aber noch ein wenig mit OVMF testen, denn so einfach ist das alles nicht.

Auf Befehle, Scripte, Text-Ausgaben und Links dazu verzichte ich vorerst mal großzügig, das ist alles ohne sich vorher tiefgründig mit der Materie zu beschäftig, sowieso nicht nachvollziehbar und bei der derzeitigen regen Beteiligung habe ich dazu auch wenig Motivation.

robi
Zuletzt geändert von Robi am Di 5. Mai 2015, 20:35, insgesamt 1-mal geändert.
Robi
 
Beiträge: 68
Themen: 10
Registriert: So 15. Feb 2015, 16:02

Re: Secure Boot und Zertifizierung

Beitragvon Robi » So 8. Mär 2015, 04:08

Zu den Zertifikaten in den OVMF Images aus dem Virtualization Repo das ich im Setup vorgeschlagen habe, falls irgend jemand da mal mit spielen will, damit er nicht gleich ganz verzweifelt. ;)

Ihr könnt im Setup das Secure Boot an und ausschalten wenn ein PK drin ist. und ihr könnt vom default in den modified Modus wechsel mit dem Ergebnis wie es in der HW-Spezifikation oben angegeben ist. Jedes mal wenn ihr die VM im QEMU neu startet ist das default aber wieder eingestellt, Egal was ihr vorher dort an den Zertifikaten geändert habt. Damit habt ihr immer einen Notausstieg wenn ihr irgendwo in der Konfiguration einen Denkfehler drin habt.
Es ist also eine komplette Palette von Möglichkeiten vorhanden, um zu testen wie man Secure Boot einstellen kann, um mit seine eigenen Zertifikaten die Kiste abzusichern und gegebenefalls auch noch andere Zertifizierungen zuzulassen um zB. trotzdem von den Zertifizierten CD/DVDs zu booten. Wenn ihr mehrere Zertifikate ladet, bei mit hat er nach 6 gesagt er hat keinen Platz mehr, also der Speicherplatz dafür in den OVMF ist etwas begrenzt.

/usr/share/qemu/ovmf-x86_64.bin
keine Zertifikate enthalten. Secure Boot desshalb default auch ausgeschalten


/usr/share/qemu/ovmf-x86_64-suse.bin
alles SLES Zerttifikate und Secure Boot ist per default aktiviert
Code: Alles auswählen
Variable PK, length 1301                                                                                                                                     
PK: List 0, type X509                                                                                                                                       
    Signature 0, size 1273, owner 00000000-0000-0000-0000-000000000000                                                                                       
        Subject:                                                                                                                                             
            CN=SUSE Linux Enterprise Secure Boot CA, C=DE, L=Nuremberg, O=SUSE Linux Products GmbH, OU=Build Team, emailAddress=build@suse.de               
        Issuer:                                                                                                                                             
            CN=SUSE Linux Enterprise Secure Boot CA, C=DE, L=Nuremberg, O=SUSE Linux Products GmbH, OU=Build Team, emailAddress=build@suse.de               
Variable KEK, length 1301                                                                                                                                   
KEK: List 0, type X509                                                                                                                                       
    Signature 0, size 1273, owner 00000000-0000-0000-0000-000000000000                                                                                       
        Subject:                                                                                                                                             
            CN=SUSE Linux Enterprise Secure Boot CA, C=DE, L=Nuremberg, O=SUSE Linux Products GmbH, OU=Build Team, emailAddress=build@suse.de               
        Issuer:                                                                                                                                             
            CN=SUSE Linux Enterprise Secure Boot CA, C=DE, L=Nuremberg, O=SUSE Linux Products GmbH, OU=Build Team, emailAddress=build@suse.de               
Variable db, length 1324                                                                                                                                     
db: List 0, type X509                                                                                                                                       
    Signature 0, size 1296, owner 00000000-0000-0000-0000-000000000000                                                                                       
        Subject:                                                                                                                                             
            CN=SUSE Linux Enterprise Secure Boot Signkey, C=DE, L=Nuremberg, O=SUSE Linux Products GmbH, OU=Build Team, emailAddress=build@suse.de           
        Issuer:                                                                                                                                             
            CN=SUSE Linux Enterprise Secure Boot CA, C=DE, L=Nuremberg, O=SUSE Linux Products GmbH, OU=Build Team, emailAddress=build@suse.de               
Variable dbx has no entries                                                                                                                                 
Variable MokList has no entries 



/usr/share/qemu/ovmf-x86_64-opensuse.bin
Opensuse Zertifikate und Secure Boot per default aktiviert
Code: Alles auswählen
Variable PK, length 1188                                                                                                                                     
PK: List 0, type X509                                                                                                                                       
    Signature 0, size 1160, owner 00000000-0000-0000-0000-000000000000                                                                                       
        Subject:                                                                                                                                             
            CN=openSUSE Secure Boot CA, C=DE, L=Nuremberg, O=openSUSE Project, emailAddress=build@opensuse.org                                               
        Issuer:                                                                                                                                             
            CN=openSUSE Secure Boot CA, C=DE, L=Nuremberg, O=openSUSE Project, emailAddress=build@opensuse.org                                               
Variable KEK, length 1188                                                                                                                                   
KEK: List 0, type X509                                                                                                                                       
    Signature 0, size 1160, owner 00000000-0000-0000-0000-000000000000                                                                                       
        Subject:                                                                                                                                             
            CN=openSUSE Secure Boot CA, C=DE, L=Nuremberg, O=openSUSE Project, emailAddress=build@opensuse.org                                               
        Issuer:                                                                                                                                             
            CN=openSUSE Secure Boot CA, C=DE, L=Nuremberg, O=openSUSE Project, emailAddress=build@opensuse.org                                               
Variable db, length 1213                                                                                                                                     
db: List 0, type X509                                                                                                                                       
    Signature 0, size 1185, owner 00000000-0000-0000-0000-000000000000                                                                                       
        Subject:                                                                                                                                             
            CN=openSUSE Secure Boot Signkey, C=DE, L=Nuremberg, O=openSUSE Project, emailAddress=build@opensuse.org                                         
        Issuer:                                                                                                                                             
            CN=openSUSE Secure Boot CA, C=DE, L=Nuremberg, O=openSUSE Project, emailAddress=build@opensuse.org                                               
Variable dbx has no entries                                                                                                                                 
Variable MokList has no entries




/usr/share/qemu/ovmf-x86_64-ms.bin
Microsoft Zertifikate und Secure Boot per default aktiviert
Code: Alles auswählen
Variable PK, length 1560
PK: List 0, type X509
    Signature 0, size 1532, owner 00000000-0000-0000-0000-000000000000
        Subject:
            C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation KEK CA 2011
        Issuer:
            C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root
Variable KEK, length 1560                                                                                                                                   
KEK: List 0, type X509                                                                                                                                       
    Signature 0, size 1532, owner 00000000-0000-0000-0000-000000000000                                                                                       
        Subject:                                                                                                                                             
            C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation KEK CA 2011                                                   
        Issuer:                                                                                                                                             
            C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root                                   
Variable db, length 1600                                                                                                                                     
db: List 0, type X509                                                                                                                                       
    Signature 0, size 1572, owner 00000000-0000-0000-0000-000000000000                                                                                       
        Subject:                                                                                                                                             
            C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011                                                   
        Issuer:                                                                                                                                             
            C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root                                   
Variable dbx has no entries                                                                                                                                 
Variable MokList has no entries




qemu/ovmf-x86_64-devel.bin
sind Zertifikate von Virtualization drin, Secure Boot ist per default disabled
Code: Alles auswählen
Variable PK, length 982
PK: List 0, type X509
    Signature 0, size 954, owner 00000000-0000-0000-0000-000000000000
        Subject:
            CN=Virtualization OBS Project, emailAddress=Virtualization@build.opensuse.org
        Issuer:
            CN=Virtualization OBS Project, emailAddress=Virtualization@build.opensuse.org
Variable KEK, length 982
KEK: List 0, type X509
    Signature 0, size 954, owner 00000000-0000-0000-0000-000000000000
        Subject:
            CN=Virtualization OBS Project, emailAddress=Virtualization@build.opensuse.org
        Issuer:
            CN=Virtualization OBS Project, emailAddress=Virtualization@build.opensuse.org
Variable db, length 982
db: List 0, type X509
    Signature 0, size 954, owner 00000000-0000-0000-0000-000000000000
        Subject:
            CN=Virtualization OBS Project, emailAddress=Virtualization@build.opensuse.org
        Issuer:
            CN=Virtualization OBS Project, emailAddress=Virtualization@build.opensuse.org
Variable dbx has no entries
Variable MokList has no entries


robi
Robi
 
Beiträge: 68
Themen: 10
Registriert: So 15. Feb 2015, 16:02

Re: Secure Boot und Zertifizierung

Beitragvon gehrke » Mo 23. Mär 2015, 15:14

Aktueller heise.de-Artikel zu Windows10:
Bei Desktop-PCs und Notebooks mit Windows 8 schreibt Microsoft in den Logo Requirements vor, dass sich Secure Boot per BIOS-Setup abschalten lassen muss. Künftig ist der Abschalter optional. Bei Smartphones und Tablets mit Window 10 Mobile darf sich Secure Boot nicht abschalten lassen.

Quelle: http://www.heise.de/newsticker/meldung/ ... 82371.html
http://www.youtube.com/watch?v=PpUrMk3g_og (Angriff auf die Freiheit von Ilija Trojanow / Juli Zeh) - let’s encrypt
Benutzeravatar
gehrke
 
Beiträge: 118
Themen: 1
Registriert: Mo 23. Dez 2013, 21:53

Re: Secure Boot und Zertifizierung

Beitragvon linuxfreund » Mo 23. Mär 2015, 21:56

Hab ich auch gerade eben hier gepostet bevor ich Deinen Post gelesen habe!
Umso wichtiger als vor dieser Nachricht schon ist es jetzt das wir diese Arbeitsgruppe haben und Möglichkeiten finden dieser neuen Gefahr zu begegnen!!!

HP Pavilion: Intel Quad-Core i5-4440 3.10 GHz, NVIDIA Geforce 640 GT, 12 GB RAM, 1TB HDD
Sony Vaio SVF-15N2L2ES: Intel Core i5 1.60 GHz, 508 GB HDD, 4 GB DDR3-RAM, Intel HD Graphics 4400
Beide openSUSE13.1(Desktop), openSUSE13.2(Laptop) + Windows8.1

Benutzeravatar
linuxfreund
 
Beiträge: 62
Registriert: Mo 9. Mär 2015, 21:25

Re: Secure Boot und Zertifizierung

Beitragvon gehrke » Di 24. Mär 2015, 23:00

Robi hat geschrieben:Tests: Secure Boot mit OVMF.
[...]
Bis dort hin muss ich aber noch ein wenig mit OVMF testen, denn so einfach ist das alles nicht.
Ach Quatsch, das ist doch alles Kinderkram.

Trotzdem noch mal zum Verständnis:
Ich habe bei einer Beispiel-Installation openSUSE 13.1 das Startscript angepasst, um SecureBoot zu aktivieren.
Code: Alles auswählen
#UEFI=${UEFI:+"-bios /usr/share/qemu/ovmf-x86_64.bin"}
UEFI=${UEFI:+"-bios /usr/share/qemu/ovmf-x86_64-suse.bin"}

Enabled wird SecureBoot damit auch - so weit, so gut.

Diese installierte Version (zuvor installiert mit SecureBoot disabled) weigert sich nun zu starten:
Code: Alles auswählen
Boot Failed. opensuse
Boot Failed. EFI DVD/CDROM
Boot Failed. EFI DVD/CDROM 1
Boot Failed. EFI Floppy
Danach lande ich in der EFI-Shell.

Ist das das erwartete Verhalten? Was müsste hier nun passieren, um die Installation zu retten? Ist das ein valides Anwendungs-Szenario?
http://www.youtube.com/watch?v=PpUrMk3g_og (Angriff auf die Freiheit von Ilija Trojanow / Juli Zeh) - let’s encrypt
Benutzeravatar
gehrke
 
Beiträge: 118
Themen: 1
Registriert: Mo 23. Dez 2013, 21:53

Re: Secure Boot und Zertifizierung

Beitragvon gehrke » Di 24. Mär 2015, 23:55

Eine Neu-Installation von OpenSUSE 13.1 mit dieser Konfiguration:
Code: Alles auswählen
UEFI=${UEFI:+"-bios /usr/share/qemu/ovmf-x86_64-suse.bin"}
scheitert ebenfalls gleich zu Anfang mit obiger Fehlermeldung und landet in der EFI-Shell.
http://www.youtube.com/watch?v=PpUrMk3g_og (Angriff auf die Freiheit von Ilija Trojanow / Juli Zeh) - let’s encrypt
Benutzeravatar
gehrke
 
Beiträge: 118
Themen: 1
Registriert: Mo 23. Dez 2013, 21:53

Re: Secure Boot und Zertifizierung

Beitragvon gehrke » Mi 25. Mär 2015, 07:53

Robi hat geschrieben:Auf Befehle, Scripte, Text-Ausgaben und Links dazu verzichte ich vorerst mal großzügig, das ist alles ohne sich vorher tiefgründig mit der Materie zu beschäftig, sowieso nicht nachvollziehbar und [...]

Hhmm, aber es wäre jetzt schon sehr interessant zu wissen, woher Du weißt, welche Zertifikate in welchen ovmf*.bin-Files stecken.

BTW: Hier mal die vollständige Liste:
Code: Alles auswählen
linux-h2ek:~ # ls /usr/share/qemu/ovmf*.bin
/usr/share/qemu/ovmf-x86_64-code.bin        /usr/share/qemu/ovmf-x86_64-ms.bin                  /usr/share/qemu/ovmf-x86_64-opensuse.bin
/usr/share/qemu/ovmf-x86_64-devel-code.bin  /usr/share/qemu/ovmf-x86_64-opensuse-4096-code.bin  /usr/share/qemu/ovmf-x86_64-suse-code.bin
/usr/share/qemu/ovmf-x86_64-devel-vars.bin  /usr/share/qemu/ovmf-x86_64-opensuse-4096-vars.bin  /usr/share/qemu/ovmf-x86_64-suse-vars.bin
/usr/share/qemu/ovmf-x86_64-devel.bin       /usr/share/qemu/ovmf-x86_64-opensuse-4096.bin       /usr/share/qemu/ovmf-x86_64-suse.bin
/usr/share/qemu/ovmf-x86_64-ms-code.bin     /usr/share/qemu/ovmf-x86_64-opensuse-code.bin       /usr/share/qemu/ovmf-x86_64-vars.bin
/usr/share/qemu/ovmf-x86_64-ms-vars.bin     /usr/share/qemu/ovmf-x86_64-opensuse-vars.bin       /usr/share/qemu/ovmf-x86_64.bin
http://www.youtube.com/watch?v=PpUrMk3g_og (Angriff auf die Freiheit von Ilija Trojanow / Juli Zeh) - let’s encrypt
Benutzeravatar
gehrke
 
Beiträge: 118
Themen: 1
Registriert: Mo 23. Dez 2013, 21:53

Re: Secure Boot und Zertifizierung

Beitragvon Robi » Mi 25. Mär 2015, 22:38

gehrke hat geschrieben:
Robi hat geschrieben:Tests: Secure Boot mit OVMF.
[...]
Bis dort hin muss ich aber noch ein wenig mit OVMF testen, denn so einfach ist das alles nicht.
Ach Quatsch, das ist doch alles Kinderkram.

Kinderkram nicht, den Zusammenhang verstehen in dem ich das geschrieben haben. Ich will meine eigenen Keys im UEFI und nicht das was mir Microsoft und der Hersteller vorschreibt.

gehrke hat geschrieben:Trotzdem noch mal zum Verständnis:
Ich habe bei einer Beispiel-Installation openSUSE 13.1 das Startscript angepasst, um SecureBoot zu aktivieren.
Code: Alles auswählen
#UEFI=${UEFI:+"-bios /usr/share/qemu/ovmf-x86_64.bin"}
UEFI=${UEFI:+"-bios /usr/share/qemu/ovmf-x86_64-suse.bin"}

Enabled wird SecureBoot damit auch - so weit, so gut.

Diese installierte Version (zuvor installiert mit SecureBoot disabled) weigert sich nun zu starten:

Vollkommen richtig, den shim den du installiert hast ist mit dem Microsoft Key signiert. du musst das
/usr/share/qemu/ovmf-x86_64-ms.bin nehmen, damit startet das defaultmäßig installierte Shim. Aber nicht Microsoft, das hat für den Bootloader einen anderen Key der ist nicht in diesem OVMF. siehe auch meine PN

robi

robi
Robi
 
Beiträge: 68
Themen: 10
Registriert: So 15. Feb 2015, 16:02

Re: Secure Boot und Zertifizierung

Beitragvon Robi » Mi 25. Mär 2015, 23:02

gehrke hat geschrieben:Hhmm, aber es wäre jetzt schon sehr interessant zu wissen, woher Du weißt, welche Zertifikate in welchen ovmf*.bin-Files stecken.

robi hat geschrieben:Auf einer mit UEFI gebooteten Maschine das passende Repo von hier einbinden und efitools und sbsigntools installieren und mal etwas rumspielen.

dann mal mit "rpm -ql paket" nachschauen was in diesen beiden Paketen für Befehle und EFI-Toosl din sind.

ein bischen Doku kann ich frühenstes am Wochenende dazu schreiben.

robi
Robi
 
Beiträge: 68
Themen: 10
Registriert: So 15. Feb 2015, 16:02

Nächste

Zurück zu Workspace

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast

cron