Testing KeyManagement openSUSE 13.2

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.

Testing KeyManagement openSUSE 13.2

Beitragvon gehrke » So 29. Mär 2015, 14:52

So, ich spiele jetzt mal mit den Keys meiner openSUSE 13.2 rum, welche mit SecureBoot läuft. Mal schauen, wie weit ich komme...

Warnung: Dies ist work-in-progress. Der Autor arbeitet mit virtueller Hardware und geht bewusst das Risiko ein, dass das System unbrauchbar wird. Die folgenden Schritte sollten auf keinen Fall unbedacht auf realer Hardware nachvollzogen werden. Es besteht die Gefahr, dass die Hardware danach nicht mehr verwendbar ist!

Vorarbeiten: Backup
Ich rechne damit, mir alles innerhalb von kurzer Zeit zu zerschießen. Daher ziehe ich von der kompletten virtuellen Disk zuvor ein Backup im ausgeschalteten Zustand:
Code: Alles auswählen
host:/home/VM # cp -p test7-openSUSE.qcow2 backup-test7-openSUSE.qcow2

Aufnahme des Stands vor meinen Änderungen:
Code: Alles auswählen
host:/home/VM # grep '/usr/share/qemu/ovmf' /home/gehrke/vm/start_suse-13.2-secureboot.sh
UEFI=${UEFI:+"-bios /usr/share/qemu/ovmf-x86_64-ms.bin"}

In der VM sind die efitools schon installiert:
Code: Alles auswählen
opensuse-132-secureboot:~ # efi-readvar
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

Code: Alles auswählen
opensuse-132-secureboot:~ # ls -ltar /usr/share/efitools/keys
total 72
drwxr-xr-x 5 root root 4096 Mar 28 13:59 ..
-rw-r--r-- 1 root root 1704 Mar 28 13:59 PK.key
-rw-r--r-- 1 root root 1074 Mar 28 13:59 PK.crt
-rw-r--r-- 1 root root  753 Mar 28 13:59 PK.cer
-rw-r--r-- 1 root root  797 Mar 28 13:59 PK.esl
-rw-r--r-- 1 root root 1979 Mar 28 13:59 PK.auth
-rw-r--r-- 1 root root 1704 Mar 28 13:59 KEK.key
-rw-r--r-- 1 root root 1078 Mar 28 13:59 KEK.crt
-rw-r--r-- 1 root root  755 Mar 28 13:59 KEK.cer
-rw-r--r-- 1 root root  799 Mar 28 13:59 KEK.esl
-rw-r--r-- 1 root root 1981 Mar 28 13:59 KEK.auth
-rw-r--r-- 1 root root 1704 Mar 28 13:59 db.key
-rw-r--r-- 1 root root 1074 Mar 28 13:59 db.crt
-rw-r--r-- 1 root root  753 Mar 28 13:59 db.cer
-rw-r--r-- 1 root root  797 Mar 28 13:59 db.esl
-rw-r--r-- 1 root root 1979 Mar 28 13:59 db.auth
-rw------- 1 root root 1182 Mar 28 13:59 noPK.auth
drwxr-xr-x 2 root root 4096 Mar 28 13:59 .
Zuletzt geändert von gehrke am So 29. Mär 2015, 16:50, insgesamt 2-mal geändert.
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: Testing KeyManagement openSUSE 13.2

Beitragvon gehrke » So 29. Mär 2015, 15:06

Ich verwende diese Vorlage:
http://blog.hansenpartnership.com/ownin ... -platform/

Das vorige Sichern der Variablen via keytool spare ich mir jetzt mal, weil ich virtuelle Hardware habe und schnell die ganze VM restoren kann (hoffentlich). Das sollte man später auch noch durchexerzieren und bei realer Hardware natürlich sehr sorgfältig befolgen.

Eigenen PK erzeugen:
Code: Alles auswählen
opensuse-132-secureboot:~/pki # openssl req -new -x509 -newkey rsa:2048 -subj /CN='gehrke Plattform Key'/ -keyout PK.key -out PK.crt -days 3650 -nodes -sha256
Generating a 2048 bit RSA private key
........................+++
.....+++
writing new private key to 'PK.key'
-----

Verwendung eines UUID-Genereators: http://www.itu.int/en/ITU-T/asn1/Pages/UUID/uuids.aspx
Code: Alles auswählen
opensuse-132-secureboot:~/pki # cert-to-efi-sig-list -g dedfd9e0-d61f-11e4-a3ee-0002a5d5c51b PK.crt PK.esl

Code: Alles auswählen
opensuse-132-secureboot:~/pki # > noPK.esl

Code: Alles auswählen
opensuse-132-secureboot:~/pki # sign-efi-sig-list -k PK.key -c PK.crt PK PK.esl PK.auth
Timestamp is 2015-3-29 16:31:51
Authentication Payload size 873
Signature of size 1196
Signature at: 40
opensuse-132-secureboot:~/pki # sign-efi-sig-list -k PK.key -c PK.crt PK noPK.esl noPK.auth
Timestamp is 2015-3-29 16:32:07
Authentication Payload size 40
Signature of size 1196
Signature at: 40

Code: Alles auswählen
opensuse-132-secureboot:~/pki # ls -ltar
total 28
drwx------ 9 root root 4096 Mar 29 16:18 ..
-rw-r--r-- 1 root root 1704 Mar 29 16:21 PK.key
-rw-r--r-- 1 root root 1123 Mar 29 16:21 PK.crt
-rw-r--r-- 1 root root  833 Mar 29 16:28 PK.esl
-rw-r--r-- 1 root root    0 Mar 29 16:30 noPK.esl
-rw------- 1 root root 2069 Mar 29 16:31 PK.auth
-rw------- 1 root root 1236 Mar 29 16:32 noPK.auth
drwxr-xr-x 2 root root 4096 Mar 29 16:32 .
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: Testing KeyManagement openSUSE 13.2

Beitragvon gehrke » So 29. Mär 2015, 15:58

Jetzt fängt das Experimentieren an. Ich kopiere das Zeug einfach mal auf die EFI-Partition, in der Hoffnung, es von dort referenzieren zu können:
Code: Alles auswählen
opensuse-132-secureboot:~/pki # cp *.auth /boot/efi/
opensuse-132-secureboot:~ # cp  /usr/share/efitools/efi/KeyTool*.efi /boot/efi/

Code: Alles auswählen
opensuse-132-secureboot:~ # ls -ltar /boot/efi/
total 300
drwxrwxr-x 3 root root  16384 Jan  1  1970 .
drwxrwxr-x 4 root root   4096 Mar 26 19:31 EFI
drwxr-xr-x 6 root root   4096 Mar 26 21:03 ..
-rwxrwxr-x 1 root root   7324 Mar 29 16:33 NvVars
-rwxrwxr-x 1 root root   2069 Mar 29 16:53 PK.auth
-rwxrwxr-x 1 root root   1236 Mar 29 16:53 noPK.auth
-rwxrwxr-x 1 root root 131816 Mar 29 17:14 KeyTool-signed.efi
-rwxrwxr-x 1 root root 130318 Mar 29 17:14 KeyTool.efi
Zuletzt geändert von gehrke am So 29. Mär 2015, 16:37, insgesamt 1-mal geändert.
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: Testing KeyManagement openSUSE 13.2

Beitragvon Robi » So 29. Mär 2015, 16:31

KeyManagement geht ein bisschen zu weit, das braucht Otto der NomalLinuxer überhaupt nicht, Wir können das hier gerne mitbehandeln, aber es ist nicht vordergründig wichtig, Aber sehr interressant wenn man sich eh schon mal tiefer mit UEFI beschäftigt. ;)
Das einzige was wir ins Wiki bringen sollten ist die Mok-Liste und wie man damit arbeitet.

Grundlagen sollte man einigermaßen Verstanden haben http://wiki.mosnis.de/Secure_Boot#Aufba ... Verwaltung
Das hiersollte man mindestens mal gelesen und verstanden haben.

Wir haben es hier im UEFI Umfeld mit verschiedenen Formaten zu tun, Also DER-Format und BASE64-Format, (meist PEM), und die UEFI-Tools benötigen ein Spezielles Format. und uU muss dieses Spezielle Format auch noch durch einen anderen Key autorisiert werden. Bei den Extensionen der einzelnen Formate kann es auch noch durchaus Unterschiede geben, und einzelne Befehle müssen hin und wieder auf verschiedene Anforderungen angepasst werden, man muss also durchaus dabei etwas mitdenken
Das ist alles nicht ganz einfach zu verstehen, auf Virtuellen Maschinen damit rumzuspielen ist kein Problem, aber dem User da draußen auf echter HW sollten da dringend die Finger von lassen, desshalb bin ich nicht sicher ob wir das überhaupt öffentlich abhandeln sollten. (hier sind wir auch nur halb im verborgenen und mindestens google ließt ständig mit)

    Eine kleine Sammlung von öffentlichen Zertifikaten die eventuell benötigt werden ist im eFINnd Paket enthalten.
    Zertifikate müssen von einem in das andere Format transferiert werden, das geht mit openssl prima.
    Zertifikate anschauen geht mit openssl
    Rootzertifikate erstellen auch mit openssl, dazu sollte man aber auch wissen was man da tut,
    Zertifikate signieren auch mit openssl
    von einem Binary auslesen können mit was für einem Zertifikat es signiert ist
    ein Binary signieren.
    und Windows hat dann auch seine eigenen
    usw.

dazu kommen dann noch die speziellen Tools und Methoden speziell für UEFI weil es dort zumindestens im Usermod dann auch nocht richtig kompliziert wird, wenn dann zum Key auch noch einen GUID hinzugefügt wird und wenn dann eine Änderung autorisiert sein muss, und auch noch die Seriennummer größer sein muss als die die von dem was dort im Moment gespeichert ist.

Wollt ihr das wirklich hier auch noch abhandeln? Wir verzetteln uns nur. Ich denke, wer das wirklich braucht soll sich selbst die Mühe machen und sich das selbst zusammensuchen und erarbeiten, das er genau weiß was er da tut. Die Informationen sind im Netz, die Tools dazu sind zT auch derzeit noch nicht ganz fertig.

Die meisten im Moment im Web befindlichen Anleitungen schlampen da schon mächtig und zB die Vertrauensrichtlinien die dazu eigentlich eingehalten werden müssten, wird oftmals nach diesen Howtos aufs gröbste verletzten. Es ist nun mal so, das nicht jeder für alles einfach Rootzertifikate erstellen soll und einsetzen sollte, nur weil an der Stelle wo man ein Zertifikat benötigt auch ein Rootzertifikat gehen würde. Das macht das ganze Vertrauens-Konzept zum Unsinn und gipfelt dann dort wo wir heute schon bei den https Servern sind, das selbst Webserver von Banken zB auf verschiedenen Domainnamen keine für die Adresse gültigen Zertifikate haben, und dennoch jeder User das schon aus Prinzip übergeht, weil er es ja gewohnt ist, beim surfen täglich zig Zertifikaten blind zu vertrauen, egal wer sie ausgestellt hat und das weil jeder Depp mit einem Webserver der Meinung ist, er müsste https anbieten für seinen Müll den er dort anbietet und der User der dort mal hinschauen will sich ein Account eröffen muss, dessen Passwörter dann doch nur in Klarschrift in der Datenbank abgelegt sind und eventuell sogar noch vollkommen unbemerkt das ganze Dateisystem mit der Datenbank als Share im Web freigegeben ist. Hauptsache HTTPS, aber keine 3 Pfennige übrig sich ein vernünftiges Zertifikat für seinen Server signieren zu lassen. Und das auch nur weil in jedem Handbuch steht, wie man sich einen solches Zertifikat zum testen schnell mal selbst erstellen kann.

Es muss auch Dinge geben, die es einfach nur gibt und die obwohl es sie gibt nicht immer auch gutverständlich erklärt sind.

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

Re: Testing KeyManagement openSUSE 13.2

Beitragvon gehrke » So 29. Mär 2015, 16:35

Tja, der erste naive Versuch war schon mal ein Reinfall. Ich bin bis hierhin gut durchgekommen:
you should now be able to use KeyTool to insert them into where the platform key is. Go to ‘Edit Keys’, select the ‘The Platform Key (PK)’ and then ‘Replace Keys(s)’. Navigate the file Chooser to your PK.auth file and you now are the platform Owner.

Leider kam es zu einem Fehler:
Code: Alles auswählen
ERROR: Failed to update variable: (26) Security Violation

Zuvor hatte ich SecureBoot abgeschaltet.
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: Testing KeyManagement openSUSE 13.2

Beitragvon gehrke » So 29. Mär 2015, 16:58

Robi hat geschrieben:KeyManagement geht ein bisschen zu weit,
[...]
Wollt ihr das wirklich hier auch noch abhandeln? Wir verzetteln uns nur.
Das weiß ich derzeit tatsächlich noch nicht so genau. Diese Tests dienen erst mal der Erkenntnisfindung. Was schlägst Du vor, wie es weiter gehen soll?

Robi hat geschrieben:Das ist alles nicht ganz einfach zu verstehen, auf Virtuellen Maschinen damit rumzuspielen ist kein Problem, aber dem User da draußen auf echter HW sollten da dringend die Finger von lassen, desshalb bin ich nicht sicher ob wir das überhaupt öffentlich abhandeln sollten. (hier sind wir auch nur halb im verborgenen und mindestens google ließt ständig mit)
Ich habe mal eine fette Warnung voran gestellt.
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: Testing KeyManagement openSUSE 13.2

Beitragvon Robi » So 29. Mär 2015, 18:45

gehrke hat geschrieben:Tja, der erste naive Versuch war schon mal ein Reinfall. Ich bin bis hierhin gut durchgekommen:
you should now be able to use KeyTool to insert them into where the platform key is. Go to ‘Edit Keys’, select the ‘The Platform Key (PK)’ and then ‘Replace Keys(s)’. Navigate the file Chooser to your PK.auth file and you now are the platform Owner.

Leider kam es zu einem Fehler:
Code: Alles auswählen
ERROR: Failed to update variable: (26) Security Violation

Zuvor hatte ich SecureBoot abgeschaltet.


Den Pk (Zertifikat des Plattformowners) kannst du nur überschreiben wenn der neue mit dem alten signiert ist, geht in der Praxis nie, da du für den PK des Herstellers den privaten Key niemals in die Hand bekommst. Aber es sollte eine manuelle Möglichkeit im UEFI-BIOS eingeräumt sein, wenn du dort den Modus auf "Custom Mode" änderst , dann kannst du dann entweder den PK löschen (ovmf), oder bei den HW-Herstellern ist damit der PK schon automatisch gelöscht und die Kiste damit im "SetupMode"

Am besten mit dem ganz einfachen ovmf UEFI-BIOS anfangen. dort sind gar keine Keys drin. Dort kannst du der Reihe nach dann deine oder die orginalen Microsoft/Opensuse/Suse/.... Keys reinlegen die du haben willst. den PK zu Schluss. und du solltest am besten einen KEK nehmen, zu dem du den private Key hast. Sobald du den PK eingelesen hast ist die Kistes "scharf" und SecureBoot ist an.

Dann kannst du versuchen (am Besten am Anfang von aus Linux heraus) einen zusätzlichen db dort reinzuladen. SecureBoot an oder Aus ist egla, Dieser muss mit dem KEK signiert sein, in der Doku steht drin wie das geht, aufpassen die db dabei nicht überschreiben sondern Key anhängen. dann versuche deinen Eintrag in der db wieder zu löschen, in dem du den alten db key wieder reinschreibst, und zwar diesmal überschreiben. dann ist der neue wieder raus.

Das Ganze ist etwas schwierig ( und fast unmöglich umfassend und idiotensicher zu erklären) und man braucht den 100% Überblick welcher Key ist jetzt welcher und hat welche Aufgabe und mit was sind meine EFI-Tools/Bootloader usw singniert, und welchen Key muss ich mit was signieren und wohin laden damit ich mein signierten EFI-Tool im Secureboot starten kann.
Auch geht hier mal nur das eine Format und hier mal braucht man das andere Format. und dann gibt es noch den GUID (zwar nicht unbedingt wichtig, aber gehört dazu) und es gibt eine Seriennummer in den auth-Dateien die du anlegst, (in der Doku meist zeitgesteuert). Diese soll verhindern das du mit einer auth-Datei x-belieb mal dort in die Datenbank reinschreiben kannst. Die nächste Änderung benötigt dann eine höhere Seriennumer, also muss du eine neue auth Datei dafür erstellen. Ich habe damit auch fast 14 Tage rumexperimentiert bis ich es einigermaßen begriffen hatte und die Feinheiten verstanden habe.
Das Schöne, du brauchst die VM nur neu KALT-Starten und schon ist alles wieder beim Altem. Du kannst also gar nichts kaputt machen. Bei richtiger HW ist das etwas komplizierter, und auf jedem Systemboard oder UEFI eventuell auch anders, um das alles wieder zurück zusetzen. desshalb sollten User da unbedingt und dringend die Finger vom Key-Management des UEFI lassen wenn dieser auf der HW ist und sie das noch nicht wirklich beherrschen.

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


Zurück zu Workspace

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste

cron