Installation eigener Keys für Secureboot

[Robi]

Das wird hier ein kleiner Erfahrungsbericht in Form eines Fortsetzungsromans.

Problem:
Es wurde im Eigenbau ein neuer Rechner gebaut. Aufgabe ist es jetzt diesen Rechner im UEFI mit meinen eigenen Keys für Secureboot zu versehen und damit den Rechner speziell für seine Linux-Aufgabe und für seinen Verwendungszweck abzusichern, Die Hoheit über den Rechner im UEFI soll einzig bei mir liegen. Absicherung des UEFI gegen Booten von unautorisierten Betriebssystemen, Scriptkiddies, Bundestrojaner, Schad- und Spionagesoftware und sonstiges was eventuell die nächsten Jahre einen Default-Rechner im UEFI angreifen könnte, ohne mir dabei die Möglichkeit zu verbauen auch weiterhin im und mit dem UEFI herum experimentieren zu können.


Ausgangssituation
Rechner wurde aufgebaut mit Gigabyte GA-Z97N-WIFI, mit einer etwas moderaten CPU aber fetten und schnellen 2 x 8GB Hauptspeicher. Das Ganze mit 64GB SSD und einem CPU-Kühler in ein NAS-Gehäuse. Derzeit 2 x 2TB Western Digital Red SATA III in den Wechselrahmen runden das Ganze ab. Das alles aber nur so nebenbei für alle die, die etwas Anleitung benötigen wie man sich zB. seine eigenen Rechner zusammenstellen kann.

Geplante Aufgabe des Rechners, er soll später Headless als Home-NAS fungieren und nebenbei ein paar VMs für Tests und Experimente im virtualisiertem NAS-Umfeld zur Verfügung stellen, sowie als Plattform für die regelmäßigen und sehr umfangreichen Testläufe dienen, die bei meiner Entwicklerarbeit doch gelegentlich anfallen.
Installiert wurde ein OpenSuse 13.1 64bit mit UEFI + Secureboot, zusätzlich wurde noch efitools und sbsigntools von diesem Projekt installiert.

Die mitgelieferte Software sowie die Herstellerseite sind voll mit Windowstools, Treibern und ähnlichen, Erwähnt wird Linux nur einmal, auf gut deutsch: "man soll sich für Linux seine Treiber bei den Herstellern der Chips oder irgendwo anders zusammensuchen, wenn man denn welche braucht". (Habe keine Treiber benötigt, der Suse-Kernel hat alles problemlos im Griff) Handbuch und Doku reicht aus um die Hardware zusammen zu bauen und in Betrieb zu nehmen. Genaue Beschreibung der einzelnen BIOS/UEFI-Funktionen oder ähnliches sucht man vergeblich. Geschweige denn irgendwelche genauen Infos über UEFI oder gar den Secureboot. Eine EFI-Shell sucht man auch vergeblich auf den Hersteller Seiten. Es wird überhaupt keinerlei Anstalten gemacht Otto den Normalkäufer eines solchen Boards oder Rechners mit einem solchem Board vernünftig über die reichlich vorhanden normalen Funktionen und Setupeinstellungen aufzuklären. Dafür gibt es aber mehrere Möglichkeiten und Oberflächen für die Einstellung des UEFI und spezielle Tools für das Tuning und Overclocking. Der Kunde hat hier wunderschön anzuschauende Setuptools auch multilingual und mit Mausbedienung, Aber wer ein richtiges optimales UEFI-Bios Setup oder gar ein Tuning oder Overclocking manchen will, der muss entweder Ahnung haben von dem was er macht, oder sich die Infos dazu irgendwo anders im Netz suchen, oder ausprobieren, hoffen und beten das ihm der Prozessor der Speicher oder das ganze Board dabei nicht um die Ohren fliegt.

Im "Klassischem" Setupmenu ist so ziemlich alles zu finden was man sich an den System Einstellungen für die Hardware wünscht. Allerdings ist die Namensgebung und besonders die deutsche Übersetzung teilweise Hahnebüchend. Die Hilfe dazu ist durchweg ein Plazebo. Das man irgendwelchen "Itzelpritzl" hier ein- und ausschalteten kann, sieht man selbst, das braucht man nicht noch links als Hilfe dazu zu schreiben und was "Itzelpritzl" eigentlich ist, steht nirgends, weder in der Hilfe noch im Handbuch noch irgendwo auf der Herstellerseite. Ob man eventuell vom Support Hilfe dazu bekommen könnte, habe ich nicht probiert. Wer einigermaßen Ahnung hat oder sich wochenlang durchs Web gegooglet hat, findet was er sucht. Ansonsten sind die default Einstellungen ganz gut und für viele Einsatzgebiete auch optimal.


Mit dem Wahlschalter "Windows 8 feature" -> "Windows 8 WHQL " -> "Other OS" und zusätzlich dem Schalter für "CSM" kommt man an die Secureboot Einstellungen. Je nach dem wie diese beiden Schalter gesetzt werden, sieht man (oder eben sieht man nicht) unten den derzeit aktuellen "System Modus" und "Secureboot Modus" oder kann sogar "System Modus" von "Standard" auf "Custom" umschalten und "Secureboot" ein- und ausschalten. Also alles so wie es es in der Windowsspezifikation von Windows 8 "empfohlen wird. Windows 10 dürfte man mit der Schalterstellung "Windows 8 Feature" auch erfüllen, denn da lässt sich Secureboot nicht mehr abschalten, weil eben die Menüpunkte dazu nicht mehr angezeigt sind.

Aber alles Kokolores. Das Systemboard ist definitiv im SetupMode und es ist nicht ein Zertifikat installiert. Also egal was man einstellt, es gibt derzeit keinen Secureboot. Zu sehen auch unter Linux mit dem Befehl efi-readvar das alle Key Variablen ohne einen Eintrag sind.

Die Booteinstellungen im Setupmenu sind gewöhnungsbedürftig. Die Bezeichnung der automatisch vom UEFI-BIOS erzeugten Namen mag vielleicht für UEFI verständlich sein, Otto der Normaluser kann damit wenig anfangen. Je nach dem was man für Optionen eingestellt hat sieht man mehr oder weniger Bootmöglichkeiten, schnell unübersichtlich wird es wenn man den Networkboot eingestellt hat, da hier dann sofort beide NICs sowohl mit IPV4 und IPV6 Boot in der Bootauswahl vorkommen, dann noch UEFI + CSM ausgewählt und es blickt keiner mehr durch in der Liste mit 10 oder noch mehr Bootmöglichkeiten.
Einen speziellen Booteintrag im Setup selbst zu erstellen ist nicht möglich, und auch das Sortieren der selben muss man erst mittels ausprobieren erlernen.

Es gibt im Setupmenü leider keinen default Menupunkt um eine EFI-Shell zu laden. Im BIOS ist keine interne vorhanden und eine optionale wird auch vom Hersteller nicht auf den Downloadseiten angebooten und nach diesem Begriff zu suchen ist beim Hersteller auch vergebene Mühe. Das wird dem Normalo vorenthalten. Na ja der Nomalo will dort ja auch gar nicht hin, dieser geheime Ort soll den Scriptkiddies und Überbringern des Bundestrojaners vorenthalten bleiben.
UEFI-Version habe ich V2.3.1 ermittelt. Leider und überhaupt nicht erwartet funktioniert die UEFI-Shell v2 nicht und bei der Geschwindigkeit des Rechners ist auch keine Fehlermeldung unmittelbar vor dem clear des Bildschirms zu erkennen. Aber UEFI-Shell v1 tuts auch. Nur eben bcfg gibts bei der nicht, dafür haben wir aber den prima in Linux funktionierenden efibootmgr


Die Aufgabe für die nächsten Tage:

# Erstellung von eigenen PK KEK und db Zertifikaten
# Signierung der EFI-Shell und des Keytoos mit dem erstelltem db
# Ausprobieren der Schlüssel auf einer VM
# Testen ob und wie wir einzelne Schlüssel hinzufügen,austauschen und löschen können
# Wenn auf VM alles soweit passt, dann diese Zertifikate und zusätzlich das OpenSuse auf dem Systemboard installieren

Ich rechne damit, dass laut der Spezifikation die Windows an die Hardwarehersteller stellt, nachdem der PK das erste mal installiert ist, hinterher nach jedem clear CMOS, oder vergleichbaren Voll-Reset, oder sonstigen "Back 2 default" oder umstellen von Custom- auf Standard Mode genau diese ersten installieren Zertifikate wieder aktiv werden. Es sollte dort also nichts schief gehen, denn sonst ist das Mainboard für immer versaut.

also bis die Tage.

robi

[Robi]

Erzeugen eigener Key für UEFI Secureboot

Um das folgende einigermaßen zu verstehen sollte man mindestens dieses mal gelesen haben.

Im Moment sind gar keine im UEFI, wir brauchen also 3 Certifikate PK KEK und db . Diese können problemlos mit openssl angelegt werden.
Die Überlegung dazu:

* Da wir nur einen oder maximal eine Handvoll Rechner mit diesen Keys jemals am laufen haben werden, können wir getrost auf extrem zufälligen Zufall im Quatrat verzichten. die normale Random Funktion sollte durchaus zufällig genug sein. Auch sollten durchaus 2048 Bit ausreichend sein.
* Auf eine komplette Trustkette können wir für unseren privaten Verwendungszweck verzeichten. Es reichen also 3 Rootzertifikate. UEFI prüft nur beim Speichern/ändern/löschen der Keys ob die Authorisierung ok ist, und kann dazu auch nur die Zertifikate benutzten, die es selbst derzeit kennt.
* Da wir den Rechner doch einige Jahre benutzen wollen, sollten wir mit der Gültigkeit der Keys doch ehr großzügig umgehen. 10 Jahre Minimum.
* Wir dürfen die Zertifikate und insbesondere die privaten Keys über die gesamte Laufzeit des Rechners nicht verlieren und müssen sie hochgeheim verwahren. Das kann eventuell über die Laufzeit von 10-15 Jahren durchaus ein Problem werden.
* Da wir keine eigene Bank mit schwerem Tresor haben um die Key sicher zu lagern und unsere Keys dann eventuell doch auf dem einen oder anderem USB-Stick rumliegen könnte, sichern wir die privaten Key zusätzlich mit Passwörten, und diese werden dann nicht aufgeschrieben sondern so gewählt, dass wir sie auch 15 Jahre nicht vergessen werden.
* Ansonsten legen wir den kompletten Zertifikatsatz in einem geeigneten Key-Safe ab. Und einen Satz verstecken wir mal zur Sicherheit dort wo ihn niemand so auf die Schnelle suchen würde, und vor allem wo er auf keinen Fall irgendwie online hinkommen kann.
* Wir sollten die Zertifikate sowohl mit dem internen Namen und auch mit den Dateinamen doch eindeutig halten damit wir später genau erkennen was das für Dinger sind, und auch eine Seriennummer im Zertifikat und Dateinamen mitführen, falls wir doch aus irgend einem Grund mal den einen oder anderen austauschen müssten
* Dabei bleiben wir intern in den Zertifikaten nicht ganz anonym aber auch nicht allzu ausschweifend, wer weiß ob wir in 10 Jahren überhaupt noch in der Stadt leben und die Mailadressen ändern sich im privaten Bereich doch öfter mal. also auf solche sonst typischen Einträge verzichten wir mal

Soweit zur Vorüberlegung.
Beim Installieren des efitools Paketes wird automatisch gleich ein Satz Zertifikate auf dem eigenen Rechner erstellt, diese bitte nicht verwenden. Die sind erstens ohne Passwort, zweitens ziemlich anonym und dadurch keinesfalls eindeutig, und drittens ist nicht sicher was mit diesen beim nächsten Update des Paketes geschieht, werden diese wieder neue angelegt? oder gelöscht? das kann schnell tötlich enden. Zum Testen auf Virtuellen Maschienen oder so ist das ok, aber nicht damit auf richtige HW gehen. Wir legen sie aber analog an.

ein kleines Script dazu.

Code: Alles auswählen

#!/bin/bash
echo -e "\t\tErzeugen von eigenen UEFI Keys"
echo -e "\t\t------------------------------\n"
echo "Bitte gib einen Namen für die zu erstellenden Zertifikate ein "
echo -e "Beispiel : Franz Mustermann UEFI 2015\n"
read -p "Enter Zertifikatsnamen: " NAME

for ((i=1;i<60;i++));do echo -n "_"; done
echo -e "\nBitte gib eine Versionsnummer ein"
read -p "Enter Versionsnummer: " VERSION

for ((i=1;i<60;i++));do echo -n "_"; done
echo -e "\nBitte gib eine Gültigkeitsdauer in Jahren ein"
read -p "Enter Gültigkeitsdauer: " JAHRE

DAUER=$(($JAHRE * 365))
BASEN=$(echo $NAME | tr " " "_")
PFILEN=${BASEN}_PK_${VERSION}
for ((i=1;i<60;i++));do echo -n "_"; done
echo -e "\nErzeugen des PK-Schlüssels, du musst ein Passwort für den \"PK\" eingeben\n"
openssl req -new -x509 -newkey rsa:2048 -subj "/CN=$NAME PK/"\
        -keyout ${PFILEN}.key -out ${PFILEN}.crt -days $DAUER  -sha256 -set_serial "$VERSION"
for ((i=1;i<60;i++));do echo -n "-"; done
echo -e "\n\n\n"
KFILEN=${BASEN}_KEK_${VERSION}
echo -e "\n\Erzeugen des KEK-Schlüssels, du musste ein Passwort für den \"KEK\" eingeben\n"
openssl req -new -x509 -newkey rsa:2048  -subj "/CN=$NAME KEK/" \
        -keyout ${KFILEN}.key -out ${KFILEN}.crt -days $DAUER  -sha256 -set_serial "$VERSION"
for ((i=1;i<60;i++));do echo -n "_"; done
echo -e "\n\n\n"
DFILEN=${BASEN}_db_${VERSION}
echo -e "\n\Erzeugen des db-Schlüssels, du musste ein Passwort für den \"db\" eingeben\n"
openssl req -new -x509 -newkey rsa:2048 -subj "/CN=$NAME db/" -keyout ${DFILEN}.key \
        -out ${DFILEN}.crt -days $DAUER -sha256 -set_serial "$VERSION"
for ((i=1;i<60;i++));do echo -n "_"; done
echo -e "\n\n\n"

# erzeugen des DER-Formates für alle 3 Certifikate
openssl x509 -in ${PFILEN}.crt -out ${PFILEN}.cer -outform DER
openssl x509 -in ${KFILEN}.crt -out ${KFILEN}.cer -outform DER
openssl x509 -in ${DFILEN}.crt -out ${DFILEN}.cer -outform DER

chmod 0600 *.key
#GUID=`python -c 'import uuid; print str(uuid.uuid1())'`
GUID=$(uuidgen)
echo $GUID > myGUID.txt


Das Script legt im aktuellem Verzeichnis ensprechend die Keys ab. Die Privaten Key haben die Endung ".key" das ist das was wir absolut geheim halten sollten. Aber den Rest sollten wir auch nicht verlieren, wir brauchen immer beides. Die Zertifikate sind in 2 Formaten abgelegt. (es gibt verschiedene Tools die einmal das eine oder manchmal das andere Format wollen). einmal binär im DER-Format Endung *. cer" und einmal als PEM mit Endung "*,crt"
Zusätzlich wird eine myGUID.txt angelegt, darin wird eine zufällige GUID abgelegt, die können wir nutzen um unsere Keys eindeutig in den Variablen als von uns angelegt zu kennzeichnen. Ist aber optional und funktioniert auch nicht in jedem Fall. Gehört aber irgendwie dazu.

Es werden im Script abgefragt ein Zertifikatsnamen. Hier zB "Name Vorname UEFI 2015" eingeben. das sagt uns später wahrscheinlich genug. Die Dateinamen werden dann auch aus diesen Infos gebildet.
Als nächstes wird eine Versionsnummer gefragt, wir fangen bei 1 an. und sollten wird in die Verlegenheit kommen später neue anzulegen, dann hochzählen, das hilft später mal ungemein die Dinger auseinanderzuhalten.
Als nächstes wird eine Gültigkeitsdauer in Jahren gefragt, 10 - 15 Jahre sind zumindestens bei mir durchaus möglich bei privater Rechnernutzung. Das sollten wir bedenken. Ist die Zeit abgelaufen bootet nichts mehr im Secureboot und ob ich mit einem abgelaufenen Zertifikat ein anderes Zertifizieren könnte, was für das Einspielen von Neuen Zertifikaten notwendig wäre, ist fraglich. Außerdem können wir uns in 8 Jahren wahrscheinlich gar nicht mehr erinnern wie wir das genau gemacht haben. ------------ also lieber gleich großzügig.

Dann werden 3 Passwörter abgefragt und jeweils die Bestägung dazu. Je eines für PK, KEK und db . Die sollten wir unbedingt so wählen, dass wir sie uns leicht und lange merken können und auch auseinander halten können. Ohne dieses Passwörter sind die Privaten Keys nutzlos und somit kann man dann die Zertifikate im UEFI nicht mehr ändern. Der Hersteller kann uns auch nicht helfen, mit dem Einspielen unsere Keys haben wir mit den Rechner wirklich richtiges "self-customizing" veranstaltet. Mit allen Vorteilen und Konsequenzen.

Heraus kommen dann zB solche Dateien : Name war hier gewählt "robi UEFI 2015" und als Version die 1

Code: Alles auswählen

-rw-r--r-- 1 root root   37 May 10 02:25 myGUID.txt
-rw-r--r-- 1 root root  777 May 10 02:25 robi_UEFI_2015_KEK_1.cer
-rw-r--r-- 1 root root 1107 May 10 02:25 robi_UEFI_2015_KEK_1.crt
-rw------- 1 root root 1834 May 10 02:25 robi_UEFI_2015_KEK_1.key
-rw-r--r-- 1 root root  775 May 10 02:25 robi_UEFI_2015_PK_1.cer
-rw-r--r-- 1 root root 1107 May 10 02:25 robi_UEFI_2015_PK_1.crt
-rw------- 1 root root 1834 May 10 02:25 robi_UEFI_2015_PK_1.key
-rw-r--r-- 1 root root  775 May 10 02:25 robi_UEFI_2015_db_1.cer
-rw-r--r-- 1 root root 1107 May 10 02:25 robi_UEFI_2015_db_1.crt
-rw------- 1 root root 1834 May 10 02:25 robi_UEFI_2015_db_1.key

Bevor wir weitermachen sollten wir uns die Zertifikate von innen anschauen. Hier im Beispiel mal der Anfang vom KEK, Es reicht wenn wir das bei den PEM-Dateien machen. Befehl und der Anfang solch einer Ausgabe:

Code: Alles auswählen

# openssl x509 -noout -text -in robi_UEFI_2015_KEK_1.crt
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=robi UEFI 2015 KEK
        Validity
            Not Before: May 10 00:25:23 2015 GMT
            Not After : May  7 00:25:23 2027 GMT
        Subject: CN=robi UEFI 2015 KEK
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:e2:83:2f:19:a3:1f:06:8a:8b:e7:80:a2:ec:ad:
                    de:17:e1:..........

Zu Kontrollieren dort unbedingt: die Gültigkeitesdauer, das Subject:: und die "Serial Number:" (Version)
Alles Ok? dann haben wir jetzt schonmal unseren eigenen Keys.


robi

[Robi]

Wie erkenne ich den aktuellen Status:

Bevor wie weitermachen, müssen wir klären wie wir überhaupt den aktullen Status rund um Secureboot im System genau erkennen. also was sind für Keys derzeit aktiv und wie ist der Secureboot Status,

Mal als Zusammenfassung der Zusammenhänge, Das Securebootsystem funktioniert mittels der Variablen PK KEK db dbx und über die Variablen SecureBoot und SetupMode

db enthält Keys mit denen die Bootloader signiert werden, den Privaten Key davon benötigt man für das Signieren von Bootloader, Treibern uä. die in UEFI ausgeführt werden sollen.

dbx ist das Gegenteil von db, wenn hier ein Zertifikat oder Hash eingetragen ist, dann lässt sich das was damit signiert ist nicht ausführen

KEK ist das Zertifikat mit dem eine Änderung an db oder dbx authorisiert sein muss. Will man also an db oder dbx was ändern, dann muss man die Änderung mit dem privaten Key von KEK authorisieren.

PK ist das Zertifikat mit dem ich Änderungen an KEK autorisieren muss, und mit der ich auch Änderungen an PK authorisieren muss. Den Privaten Key benötige ich also immer für Änderungen an PK selbst oder an KEK

SecureBoot schaltet dann scharf das ab jetzt nur noch mit dem db signierte Dinge ausführbar sind.

SetupMode ist ein spezieller Status, der aussagt ich habe im Moment keinen PK installiert. Damit ist kein Secureboot möglich aber ich kann in diesem Zustand jetzt bequem Änderungen an KEK db dbx und PK vornehemen, denn UEFI wird in diesem Zustand nicht testen ob meine Änderungen ausreichend signiert und damit authorisiert sind. Sobald ich einen neuen PK installiert habe ist wieder der Nomale "Usermode" aktiv und SecureBoot wird auch beim nächsten Booten automatisch gesetzt. Der normale Modus ist hier UserMode es ist ein PK gesetzt und ich muss bei Änderungen an den Keys immer alles richtig signiert haben, sonst geht nichts.

Soweit ist das ganz einfach. Allerdings ist es jetzt so, ein normaler Rechner wird ausgeliefert und dort sind schon alle Keys vom Hersteller/Produzent drin, und ich komme nicht an die privaten Keys um irgendwelche Änderungen vorzunehmen. Muss also ich damit Leben, das mir eventuell nur die Möglichkeit eingeräumt ist, SecureBoot ein- und auszuschalten. ( aber nicht mal das könnte in Zukunft für mich möglich sein) den vorinstallierten Keys bin ich mehr oder weniger hilflos ausgliefert.
Die seltene Ausnahme die ich derzeit vor mir habe, Ich habe ein Systemboard gekauft, und auf diesem sind noch keine Keys drauf, ich kann mir also selbst welche drauf basteln wie es mir passt, muss mich danach dann aber trotzdem voll an die Reglen von UEFI halten, das heißt, auch ich muss anschließend wenn die Kiste im UserMode ist bei Änderungen alles sauber mit meinen privaten Keys signieren, sonst geht nichts. Habe aber den Vorteil, ich habe dann auch alle privaten Keys und kann dort Zertifikate ablegen oder löschen und auch mehrfach ändern oder anpassen, und kann die UEFI_Tools die ich haben will mit meinen eingen Keys selbst signieren.

Jetzt wird es etwas komplizierter, Intern im UEFI gibt es für die Variablen PK KEK db dbx noch einmal Default-Variablen. Diese sind nirgends von außen erreichbar und auch nicht durch zB einem FW-Update oder CMOS-clear überschreib- oder löschbar. Im Normalfall ist PK und PKDefault und auch alle anderen immer gleich mit ihren Default PartnerVariablen. Man spricht dabei vom StandardMode.
Die Windows Spezifikation für Intel-Platform sagt aus, es sollte einen Schalter geben um dieses temporär zu ändern und zwar im UEFI-BIOS-SETUP-Menu. Dieser Schalter wird in der Regel jedoch etwas versteckt, bei mir zB muss eine bestimmte Kombination von Einstellungen im Setup gesetzt sein und dann nach dem nächsten Speichern+Reset sehe ich es erst.
Mit diesem Schalter schaltet man das UEFI-BIOS vom StandardMode in den CustomMode um. Dabei wird die Trennung der Werte der Default Variablen mit den Normalen Variablen hergestellt, und mindestens der PK gelöscht, meist jedoch werden alle 4 Variabelen gelöscht. Damit ist das System dann mit PK KEK db dbx wieder im SetupMode. Die Default Variabelen behalten selbstverstänglich im Hintergrund die alten Werte, In diesem CustomMode kann man jetzt seine eigenen Key mehr oder weniger problemlos installieren wie es einem in den Kram passt, und wenn man einen PK geladen hat, dann wird auch SecureBoot aktiv und zwar dann nach den eigenen Keys die man sich geladen hat. Aber nur solange bis man im Setup Menu nicht wieder zurück auf StandardMode schalted oder sonst wie die Defaulteinstellungen des Systemboards wieder herstellt, Dann würden die eigenen Keys in den PK KEK db dbx gelöscht und wieder mit den default Werten überschrieben aus den Defaultvariablen . Aber wenigstens ein Trostpflaster für die Linuxgemeinde, denn wenn man im UEFI-Setup ein Adminpasswort setzt, würde man wohl nur über einen Jumper am Systemboard unbefugt den StandardMode wieder einschalten können. ansonsten kann man ganz normal mit seinem eingenen UEFI-Keys und seinen eigenen Secureboot und seinen eigenen signierten EFI-Tools und Bootloadern arbeiten.

Für den CustomMode gibt es derzeit keine offizielle Variable die man auslesen kann. ( bei unseren OVMF gibt es zwar eine die man herziehen könnte, aber verallgemeinern kann man das nicht, ebenfalls eine offizielle CustomMode Variable wird wohl erst irgendwann in der Zukunft in späteren Versionen bei uns auf den Systemboards ankommen) Alles andere kann man aber von Linux aus bequem auslesen. Voraussetzung man hat mit UEFI gebootet und man hat die beiden Pakete aus dem derzeit noch nicht Standard Repositorie "UEFI" installiert.

Welche Keys man aktuell im System hat, kann man mit efi-readvar ermitteln.

Code: Alles auswählen

# efi-readvar
Variable PK has no entries
Variable KEK has no entries
Variable db has no entries
Variable dbx has no entries
Variable MokList has no entries

Das ist der aktuelle Zustand meines Systemboards. also nichts drin. auf einem "Normalem" PC sind dort 4 Stück drin. Ein PK vom Hersteller, ein KEK von Microsoft und 2 db von Microsoft, einer für das booten von Microsoft selbst und einer der für das Signieren von Treibern und Bootloadern von Fremdanbietern durch Microsoft verwendet wird (mit dem auch Shim signiert ist)

Wie der aktuelle Status der anderen beiden Variablen SetupMode und Secureboot ist kann man mit folgendem Script ermitteln.

Code: Alles auswählen

#/bin/bash
#Script ermittelt den aktuellen Securebootmodus

mount | grep efivarfs 2>&1 /dev/null
if [ $? == 0 ]
    then echo "Error: kein efivarfs Verzeichnis gemountet"; exit 1
fi
EFIVAR=$(mount | grep efivarfs | awk '{print $3}')/../vars

SETUP=$(cat ${EFIVAR}/SetupMode-*/data 2>/dev/null | xxd -l1 -p)
SECUREB=$(cat ${EFIVAR}/SecureBoot-*/data 2>/dev/null | xxd -l1 -p)
VENDOR=$(cat ${EFIVAR}/VendorKeys-*/data 2>/dev/null | xxd -l1 -p)
COSTUM=$(cat ${EFIVAR}/CustomMode-*/data 2>/dev/null | xxd -l1 -p)

SETUP=${SETUP:="Parameter nicht verfügbar"}
SETUP=${SETUP/00/UserMode}
SETUP=${SETUP/01/SetupMode}
SECUREB=${SECUREB:="Parameter nicht verfügbar"}
SECUREB=${SECUREB/00/AUS}
SECUREB=${SECUREB/01/EIN}
VENDOR=${VENDOR:="Parameter nicht verfügbar"}
VENDOR=${VENDOR/00/CustomMode}
VENDOR=${VENDOR/01/StandardMode}
VENDOR=${COSTUM:="Parameter nicht verfügbar"}
VENDOR=${COSTUM/01/CustomMode}
VENDOR=${COSTUM/00/StandardMode}

echo "CostumMode (nicht Standard)      =   $COSTUM"       
echo "VendorKeys (nicht Standard)      =   $VENDOR"       
echo "SetupMode ist derzeit            =   $SETUP"
echo "Secureboot ist derzeit           =   $SECUREB"



(Ob das Script auch auf anderen Betriebssystemen außer OpenSuse funktioniert sollte mal jemand ausprobiern, ich hab derzeit nur Suse hier im Haus-)

Hier mal der Status auf einer Virtuellen Maschie.

Code: Alles auswählen

# sh status.sh
CostumMode (nicht Standard)      =   Parameter nicht verfügbar
VendorKeys (nicht Standard)      =   StandardMode
SetupMode ist derzeit            =   SetupMode
Secureboot ist derzeit           =   AUS

Ich habe mal die beiden anderen Variablen noch mit reingenommen, aber typischer Weise wird man hier nur "Paramter nicht verfügbar" sehen.

Damit dürften wir dann unseren Status bei den Aktivitäten die wir beim Einspielen der Keys erzeugen genau verfolgen können.

robi

[Robi]

Efi binary auf Zertifikate prüfen und selbst signieren

So jetzt wird langsam ernst. Bevor die Keys aufs Board kommen, muss erstmal genau überprüft werden, was ist alles überhaupt derzeit auf der EFI-Parition vorhanden, was brauche ich zum booten und mit was sind dort im Moment die Tools signiert.
Dann muss überlegt werden welche Tools und Bootloader will ich haben (auch für einen Plan B) und was muss ich mit meinen eigenen Keys jetzt alles signieren.

Zuerst mal auf die EFI-Partition, Dort habe ich Opensuse 13.1 installiert mit Shim derzeit.

Code: Alles auswählen

linux-ufqr:/boot/efi/efi/opensuse # ls -l
total 3565
-rwxrwxr-x 1 root root 1257800 May  6 21:14 MokManager.efi
-rwxrwxr-x 1 root root     125 May  6 21:14 grub.cfg
-rwxrwxr-x 1 root root  887416 May  6 21:14 grub.efi
-rwxrwxr-x 1 root root  121344 Mar 21 00:19 grubx64.efi
-rwxrwxr-x 1 root root 1380424 May  6 21:14 shim.efi


MokManager werde ich wohl nicht zwingend brauchen, eigentlich will ich später komplett auf Shim verzichten.
grub.cfg ist nur eine Konfig, braucht keine Signaturen
grub.efi ist der Grub2 der von Shim aufgerufen wird.
grubx64.efi ist der normale Grub2
shim.efi ist der Shim-Prebootloader.

Was wie signiert ist kann man mit "sbverify --list" ermitteln

Code: Alles auswählen

linux-ufqr:/boot/efi/efi/opensuse # sbverify --list MokManager.efi
warning: data remaining[1145464 vs 1257800]: gaps between PE/COFF sections?
signature 1
image signature issuers:
 - /CN=openSUSE Secure Boot CA/C=DE/L=Nuremberg/O=openSUSE Project/emailAddress=build@opensuse.org
image signature certificates:
 - 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


linux-ufqr:/boot/efi/efi/opensuse # sbverify --list grub.efi
signature 1
image signature issuers:
 - /CN=openSUSE Secure Boot CA/C=DE/L=Nuremberg/O=openSUSE Project/emailAddress=build@opensuse.org
image signature certificates:
 - 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


linux-ufqr:/boot/efi/efi/opensuse # sbverify --list grubx64.efi
No signature table present


linux-ufqr:/boot/efi/efi/opensuse # sbverify --list shim.efi
warning: data remaining[1254344 vs 1380424]: gaps between PE/COFF sections?
signature 1
image signature issuers:
 - /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=MOPR/CN=Microsoft Windows UEFI Driver Publisher
   issuer:  /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
 - 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
signature 2
image signature issuers:
 - /CN=openSUSE Secure Boot CA/C=DE/L=Nuremberg/O=openSUSE Project/emailAddress=build@opensuse.org
image signature certificates:
 - 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
linux-ufqr:/boot/efi/efi/opensuse #

Eventuell Fehlermeldungen wie:
warning: data remaining[1145464 vs 1257800]: gaps between PE/COFF sections?
kann man ignorieren, das scheint normal zu sein, oder irgendwo noch ein Bug i

Wie zu erkennen ist außer dem grubx64.efi alles mit dem OpenSuse Key signiert, und Shim noch zusätzlich mit dem Microsoft
Wenn ich also den OpenSuse Key in meine db ablege, dann kann ich zumindestens über Shim booten, Zu bedenken gibt es natürlich auch das beim Secureboot auch der Kernel überprüft wird, und der ist natürlich mit OpenSuse signiert, ich komme also gar nicht darum herum den OpenSuse Key mit aufzunehmen ohne das ich mir den gesamten Kernel vornehme.

Aber grubx64.efi ist derzeit überhaupt nicht signiert. Den sollten ich mit meinem eigenen Key signieren und dann unter einem anderem Namen dort ablegen, damit bei einem Update das nicht eventuell überschrieben wird.
Ansonsten ist das Verzeichnis dort soweit erstmal okey wenn ich den OpenSuse mit in die db aufnehme sollte ich keine Probleme mit Secureboot haben.

Was brauche ich noch zusätzlich an Tools. Ich will definitiv eine EFI-Shell dort haben und das KeyTool. Die EFI-Shell soll Plan B sein, von dort aus kann ich dann notfalls per Hand Booten oder dort Dateien hin und herschieben damit ich das System zum booten bekomme und mit dem KeyTool kann ich notfalls auch Keys in den UEFI dazufügen oder ändern. ( Sichern und nachschauen was drin genau drin ist damit auch möglich) Diese beiden Tools sollte ich also erstmal besorgen und ausprobieren ob sie mit meinem System laufen. Wenn ja dann werden sie mit meinem Key signiert.
EFI-Shell geht bei mir nur die v1, hatte ich schon ausprobiert und das KeyTool findet man unter /usr/share/efitools/efi/KeyTool.efi
Vorsicht, dort sind noch mehrere andere Tools und es gibt für jedes Tool auch eine signierte Version. Allerdings ist die Signatur dort einer bei der Installation von efitools erstellten Signatur gemacht worden, diese nicht verwenden, wir haben ja unsere eigenen Keys erstellt.

Wenn noch jemand mehr braucht, dann zusammensuchen, schauen was diese Efi-binaries derzeit für eine Signatur haben und dann mit dem eigenem db-Key signieren. Dazu legt man sich am besten irgendwo ein Verzeichnis an und kopiert alle Efi-binaries rein die man selbst signieren will.

Das Signieren selbst funktioniert mit sbsign
sbsign --key <keyfile> --cert <certfile> <efi-boot-image>
oder besser noch mit
sbsign --key <keyfile> --cert <certfile> --output <file> <efi-boot-image>

Wobei <keyfile>der db-private-Key ist; <certfile> ist das db-Zertifikat
Da die weiter oben erstellten eigenen Zertifikate alle ein Passwort haben, wird hierbei dann jeweils das db-Passwort benötigt.

ich habe mal ein Script geschrieben, dort nur eintragen wo das Zertifikat und der Key dazu zu finden ist und schon kann man damit gleich mehrere in einer Schleife signieren. (passwort wird jedes mal abgefragt)

Code: Alles auswählen

#!/bin/bash
echo "Script signiert efi-binary mit deinem db-certifikat"
if [ $# -lt 1 ]; then echo "usage: $0 file.efi ........";exit 1;fi

#gib hier die genauen Position und Namen des Certifikates und Key an
CERT="/root/bin/keys/robi_UEFI_2015_db_1.crt"
KEY="/root/bin/keys/robi_UEFI_2015_db_1.key"

while [ $# -gt 0 ]
do
   echo -e "signiere $1 mit $KEY \neventuell müssen sie ein Passwort eingeben\n"
   BASEN=$(basename $1 .efi)
   sbsign --key "$KEY"  --cert "$CERT" --output "$BASEN"_sig.efi  "$BASEN".efi
   sbverify --cert "$CERT" "$BASEN"_sig.efi
   echo -e "----------\n\n\n"
   shift
done
exit


Einfach in das Verzeichnis wechseln und dort "script *.efi" und schon werden die alle signiert. Danach wird noch einmal manuell überprüft ob die Signatur auch wirklich ok ist, (hat das Script zwar schon gemacht, aber hätte nicht abgebrochen wenn was nicht gestimmt hätte)
sbverify --cert <certfile> <sig-file>
<certfile> sollte das von uns erstellte db-Zertifkat sein.

Danach werden die so signierten und überprüften Dateien jetzt wieder zurück auf die Efi-Partition kopiert und bekommen dabei ihren alten Namen zurück oder einen anderen. Je nach dem.

Jetzt müssen nur noch ein paar Booteinträge angelegt werden. Die signierte EFI-Shell sollte definitiv einen bekommen, und wenn wir einen Bootloader bei der obrigen Aktion umbenannt haben, dann auch für diesen einen neuen Booteintrag einrichten. KeyTool braucht keinen, das können wir aus der Shell starten wenn wir es jemals brauchen sollten.

Code: Alles auswählen

efibootmgr -c -d /dev/sda -p 1 -L Shell -l "\\Shellx64.efi"

legt zB einen neuen Booteintrag für die Datei "Shellx64.efi" mit dem Namen "Shell" auf "/dev/sda1"
die Datei sollte derzeit von Linux aus als "/boot/efi/Shell64.efi" vorhanden sein. Wichtig dabei sollten wir auf der Efipartition den PATH angeben müssen ist immer dort wo wir unter Linux / eingeben würden \\ anzugeben.

Wenn dann alles soweit fertig ist, dann geht es erstmal wieder ans Ausprobieren. Es müssen jetzt die neu angelegten Booteinträge ausprobiert werden und auch die Booteinträge bei denen wir das Binary signiert haben.


robi

[Robi]

Also nur mal so zur Info.

Bin jetzt mit meiner neuen Kiste im UserMode und mit aktiviertem Secureboot. und es gibt sogar einen Booteintrag mit dem ich die Kiste booten kann.
Aber Alles in Allem nichts für schwache Nerven, der Bildschirm war zwischenzeitlich auch mal längere Zeit schwarz, die physikalische Kiste verhält sich doch ganz anders als die VM mit dem OVMF. Ich glaube nicht das man dieses Verfahren allgemein jedem unerfahrenen Linux Nutzer empfehlen sollte, das kann nen Haufen Probleme mit sich bringen, und selbst wenn ich hier bei mir alle Problemstellen finden sollte, ist das noch längst nicht gesagt das das auf der HW eines andern Herstellers nicht auch ganz anders aussehen und vielleicht auch enden kann.

Aber alles der Reihe nach, als nächstes kommt hier erstmal der Abschnitt wie es auf der VM in 3 Arten funktioniert hat, dann kommen meine Erfahrungen das auf der physikalischen Maschine zu machen.

robi

[Robi]

Ablegen der Keys im UEFI:

Nachdem jetzt die Signierung der UEFI-Binaries überprüft wurde und auch die Booteinträge überprüft wurde, nach dem klar ist wir haben notfalls eine UEFI-Shell und auch einen Booteintrag dazu, kann es losgehen unsere Zertifikate in den UEFI zu bringen.

Dazu gibt es verschiedene Möglichkeiten.

* Es könnte eine Möglichkeit im Setup Menu geben die Zertifikate direkt von dort aus abzuspeichern. Dieses würde nur im SetupMode gehen, entweder es sind derzeit noch gar keine Zertifikate installiert, dann im UserMode oder es sind schon die "Default" installiert und man hat vorher in den CustomMode gewechselt. Ob dazu jetzt die DER oder PEM Formate genommen werden können und welche Prefixe die Dateien haben müssen, muss man ausprobieren

* Es gibt mindestens eine Möglichkeit das mit einem UEFI-Tool zu machen, Hier haben wird dazu das KeyTool signiert und auf der UEFI-Partition abgelegt. Damit ist es möglich, Zertifikate im Uefi abzulegen, zu ändern, nachzuschauen welche sind installiert und man kann auch von den installierten Zertifikaten eine Sicherung anfertigen. Änderungen geht im Setupmode bei den KEK db und dbx im DER-Format bei Zertifikatsdateien mt dem Prefix ".cer". Darüber hinaus auch im UserMode mit "AUTH" Dateien,(dazu später)

* Es gibt im Linux mit den efitools die Möglichkeit die Zertifikate in den UEFI zu bringen. Dieses ist mit den PEM- und "AUTH" Format möglich.

Zusätzlich gibt es auch andere Tools und Pakete die das unter Linux zu erledigen, die ich aber nicht getestet habe. Allgmein werde ich hier nur auf die Möglichkeiten unter Linux aus dem efitools eingehen.

Noch ein paar Hintergrundinfos:
Mit der ehr seltenen Ausnahme, dass sich das System im SetupMode befindet, müssen für Änderungen an den diesen Sicherheitsvariablen des UEFI mit den privaten Keys von derzeit im KEK oder PK vorhanden Zertifikates autorisiert sein. Dafür wird neben den Zertifkaten die wir in den UEFI bringen wollen immer das Zertifikat und der private Key von KEK oder PK benötigt, in unserem Fall ist der private Key noch zusätzlich mit einem Passwort verschlüsselt, das brauchen wir dann ebenfalls.
Die Interne Struktur dieser Variablen im UEFI hat neben den Zertifikaten noch weitere Eintragungen, unter anderem eine GUID und eine Seriennummer. Die GUID ist unkritisch, wenn wir diese nicht angeben, dann wird eine aus NULLEN bestehende genommen. Die Seriennummeer ist dagegen von Bedeutung.
Sie stellt eine Art zusätzliche Sicherheit dar. Eine Änderung wird vom UEFI an diesen Sicherheitsvariablen nur akzeptiert und ausgeführt, wenn die Seriennummer der Änderung größer als die Seriennummer des gegenwärtigen Wertes der Variable ist. Reine Zahlenwerte als Seriennummer sind eventuell möglich, normalerweise wird aber die Seriennummer aus der aktuellen Zeit erstellt.Dieses kann in der Praxis beim mehrfachen Ändern der Variablen innerhalb kurzer Abstände eventuell zu kleinen Problemen führen.

Damit die efitools die Sicherheitsvariablen ändern können müssen sie die Zertifikate erst einmal in die intern im UEFI verwendete Struktur umwandeln. Diese Struktur nennt sich EFI-Sign-List und die Dateien haben typisch das Prefix ".esl". Diese Umwandlung kann in einem eigenem Schritt mittels des Kommandos cert-to-efi-sig-list

Code: Alles auswählen

cert-to-efi-sig-list [-g <guid>] <crt file> <efi sig list file>

die Option -g mit der GUID ist optional, benötigt wird das Zertifikat im PEM Format und der Zieldateiname muss mit angegeben werden.
Würden wir mehr als ein Zertifikat zB in db ablegen wollen, dann können die Efi-Sign-List von mehren Zertifikaten einfach mit cat zu einer einzigen Datei zusammengesetzt werden

Code: Alles auswählen

 cat Zertifikat1.esl Zertifkat2.esl > beideZertifikate.esl

Diese Sign-List muss dann noch zertifiziert werden mit dem KEK oder PK privat Key. Diese kann auch in einem seperatem Prozess auf Konsolebene erfolgen. mittels sign-efi-sig-list

Code: Alles auswählen

sign-efi-sig-list [-a] [-g <guid>] [-t <timestamp>] -c <crt file> -k <key file> <var> <efi sig list file> <output file>

-a ist optional und würde Bedeuten die Änderung wird beim Speichern im UEFI an einen eventuell schon vorhanden Wert angehängt. Ohne die Option würde ein schon vorhandener Wert überschrieben.
-g GUID ist optional, wenn nicht angegeben dann würde dort einer aus NULL gebildet.
-t <timestamp> ist auch optional, dieses würde die Seriennummer gezielt auf einen Zeitwert setzen
-c <crt file> ist das KEK bzw PK Zertifikat im PEM Format
-k <key file> ist der dazugehörige private Key
<var> ist die Sicherheitsvariabel die im UEFI beschrieben werden soll, also entweder PK KEK db oder dbx
<efi sig list file> ist die erstellte efi-sign-list die eingetragen werden soll
<output file> ist die Ausgabe Datei. die AUTH-Datei typischerweise sollte sie den prefix .auth bekommen.

Am Ende des Prozesses bekommen wir auf diesem Weg eine Autorisierte Datei in der eine oder mehere Zertifikate enthalten sind, mit der relativ einfach sowohl mit dem KeyTool als auch mit dem Befehl efi-updatevar die Sicherheitsvariabeln PK KEK db oder dbx änderbar sind.

Code: Alles auswählen

efi-updatevar -f <Auth file> <var>

<Auth-file> ist die so erstellte Autorisierte File die ein oder mehrer Zertifkate enthält und mit einem passendem Zertifkat und dessen Privaten Key autorisiert sind.
<var> ist die Sicherheitsvariable die beschrieben werden soll, also PK KEK db oder dbx


Das geniale an dieser hier ausführlich beschriebenen Methode, die AUTH-file kann auf irgend einen Rechner erstellt werden und der private Key und gegenenfalls das Passwort dazu wird auf dem Rechner auf dem die UEFI Änderung durchgeführt werden soll gar nicht benötigt. Ich kann also zentral die Auth-file erstellen und diese dann den Admins in die Hand geben damit sie die UEFI-Secureboot-Zertifikate auf die Rechner bringen oder dort ändern. Die Admins benötigen dabei den privaten Key nicht der bleibt bei mir und damit geheim.

Diese Änderung lässt sich auch nur ein mal auf einem Rechner ausführen, selbst wenn sich der Admin eine solche Datei mal aufgehoben hat, und mit dieser dann später mal Änderungen wieder rückgängig machen möchte, geht dieses nicht. In der Auth-file ist die Seriennummer der Änderung und eine weitere Änderung würde eine höhere Seriennummer benötigen. für die nächste oder eine erneute Änderung müsste also die Auth-datei neu erstellt werden, und den Key und das Passwort habe ich.

Es ist anzunehmen, dass genau dieses allerdings mit Windowstools zB bei Windowsupdates vom Microsoft gemacht werden könnte, um die db und dbx Einträge zu ändern. Denn den privat Key für den KEK hat auf einem Normalen PC Microsoft. Ich glaube irgenwo gelesen zu haben, in der Zwischenzeit hat Microsoft auch schon mittels einen Hash-Eintrages in die dbx Variabel eine Bootloaderversion zurückgerufen.

Neben dieser Variante geht es von Linux aus auch ohne Umweg über eine Efi-Sign-List. Auch das geht mittels efi-updatevar

Code: Alles auswählen

efi-updatevar [-a] -k <key> [-g <guid>] -c <cert file> <var>

-a ist optional, mit wird Eintrag zusätzlich eingetragen, ohne wird überschrieben
-k <key> ist der private Key mit dem Signiert werden muss
-g GUID ist optional
-c ist das Zertifikat das in die Sicherheitsvariable gepeichert werden soll
<var> ist wieder der Name der Sicherheitsvariable also PK KEK db oder dbx

In der Praxis hat sich gezeigt, das diese Methode nicht immer funktioniert, zum Teil konnte ich das auf die Seriennummer zurückzuführen, die dabei scheinbar etwas anderes (eventuell nicht nach der Zeit des BS sondern nach der (UTC) Zeit des BIOS gerechnet wurde????). Möglich hier aber auch das hier noch BUGs in den EFI-Tools sind. Die Hardwarehersteller werden mit Sicherheit hier auch nicht wirklich alles testen und hier eventuell auch Unschäfen in der UEFI-Spezifikation implementiert haben, da sie wenn überhaupt sowieso nur mit Micosoft testen.

mit das ganze nicht so kompliziert ist habe ich für das erstellen der Auth-Dateien aus unseren selbst erstellten Zertifikaten und Keys ein Script geschreiben. Es geht davon aus das die Zertifikate mit den hier im Beitrag oben erstellten Script erstellt wurde. Es wird nur der Path zu dem Direktory und der Name der Zertifikatsreihe benötigt. Zusätzlich wird ein Distributionszertifikat mit in den db geladen.
Die Distributionszertifikate sollten bei jeder Distribution downloadbar sein. Bzw man kann auch das Binary Zip File von rEFInd downloaden, dort sind einige dieser Zertifkate enthalten.

Code: Alles auswählen

keys/openSUSE-UEFI-CA-Certificate.cer
keys/openSUSE-UEFI-CA-Certificate.crt
keys/fedora-ca.cer
keys/microsoft-kekca-public.der
keys/microsoft-uefica-public.der
keys/refind.cer
keys/microsoft-pca-public.der
keys/altlinux.cer
keys/microsoft-uefica-public.crt
keys/SLES-UEFI-CA-Certificate.crt
keys/SLES-UEFI-CA-Certificate.cer
keys/canonical-uefi-ca.crt
keys/fedora-ca.crt
keys/refind.crt
keys/README.txt
keys/canonical-uefi-ca.der


Das Script zu erstellen der Auth-Dateien

Code: Alles auswählen

#!/bin/bash
echo -e "Script signiert deine Keys damit sie in den UEFI geladen werden können\n\n"

# gib hier die genaue Position an der sich die Certifikate befinden"
DIR="/root/UEFI/mykeys"

# gib hier den Namen der Certifikate an
NAME="robi_UEFI_2015"

# gib hier die Version der Certifikate an
VERSION=1

# gib hier eventuell noch den Dateinamen des Certifikates deiner Distribution an
OS_CERT="/root/UEFI/keys/openSUSE-UEFI-CA-Certificate.crt"

#------------------ Ende Konfiguration --------------------------------
# Ab hier nur ändern wenn du genau weißt was du da machst

PK_KEY=${DIR}/${NAME}_PK_${VERSION}.key
PK_CERT=${DIR}/${NAME}_PK_${VERSION}.crt
KEK_KEY=${DIR}/${NAME}_KEK_${VERSION}.key
KEK_CERT=${DIR}/${NAME}_KEK_${VERSION}.crt
db_CERT=${DIR}/${NAME}_db_${VERSION}.crt
GUIDF=${DIR}/myGUID.txt

for i in "$PK_KEY" "$KEK_KEY" "$PK_CERT" "$KEK_CERT" "$db_CERT" "$GUIDF"
do
    if [ -r $i ] ; then echo "Datei \"$i\" gefunden"
    else     echo "ERROR : Datei \"$i\" nicht gefunden"
             echo "Bitte überprüfen"
             exit 1
    fi
done
GUID=$(cat "$GUIDF")

# Erzeugen der Certifikatsliste für db und signieren mit dem KEK-Key
echo -e "\n\n\nErzeugen der Certifikatsliste für db und signieren mit dem KEK-Key"
echo -e "eventuell müssen sie das Passwort für den KEK-Key eingeben"
cert-to-efi-sig-list "$db_CERT" "$DIR"/DB_CERT.esl
if [ ${OS_CERT:-0}!=0 -a -r "$OS_CERT" ]
then
    cert-to-efi-sig-list "$OS_CERT" "$DIR"/OS_CERT.esl
    cat "$DIR"/OS_CERT.esl >> "$DIR"/DB_CERT.esl
    rm "$DIR"/OS_CERT.esl
fi
sign-efi-sig-list -g $GUID -k "$KEK_KEY" -c "$KEK_CERT" db "$DIR"/DB_CERT.esl "$DIR"/db.auth
rm "$DIR"/DB_CERT.esl


# Erzeugen der Certifikatsliste für KEK und signieren mit dem PK-Key
echo -e "\n\n\nErzeugen der Certifikatsliste für KEK und signieren mit dem PK-Key"
echo -e "eventuell müssen sie das Passwort für den PK-Key eingeben"
cert-to-efi-sig-list "$KEK_CERT" "$DIR"/KEK_CERT.esl
sign-efi-sig-list -g $GUID -k "$PK_KEY" -c "$PK_CERT" KEK "$DIR"/KEK_CERT.esl "$DIR"/KEK.auth
rm "$DIR"/KEK_CERT.esl


# Erzeugen der Certifikatsliste für PK und signieren mit dem PK-Key
echo -e "\n\n\nErzeugen der Certifikatsliste für PK und signieren mit dem PK-Key"
echo -e "eventuell müssen sie das Passwort für den PK-Key eingeben"
cert-to-efi-sig-list "$PK_CERT" "$DIR"/PK_CERT.esl
sign-efi-sig-list -g GUID -k "$PK_KEY" -c "$PK_CERT" PK "$DIR"/PK_CERT.esl "$DIR"/PK.auth
rm "$DIR"/PK_CERT.esl

echo -e "\n\n\nfolgende Autorisierte Certifikats Pakte wurden für UEFI erstellt"
ls -l "$DIR"/*.auth
echo
exit


Das Script endet zB mit folgender Ausgabe

Code: Alles auswählen

folgende Autorisierte Certifikats Pakte wurden für UEFI erstellt
-rw------- 1 root root 2032 May 10 23:17 /root/UEFI/mykeys/KEK.auth
-rw------- 1 root root 2030 May 10 23:18 /root/UEFI/mykeys/PK.auth
-rw------- 1 root root 3733 May 10 23:17 /root/UEFI/mykeys/db.auth


Dann nur noch folgende 3 Befehle in dieser Reihenfolge ausführen

Code: Alles auswählen

efi-updatevar -f /root/UEFI/mykeys/db.auth  db
efi-updatevar -f /root/UEFI/mykeys/KEK.auth  KEK
efi-updatevar -f /root/UEFI/mykeys/PK.auth  PK


Das Ergebnis sollte dann unsere selbst erstellen Zertifikate sowohl in PK KEK und db enthalten und das Zertifikat der Distribution ebenfalls unter db

Code: Alles auswählen

# efi-readvar
Variable PK, length 819
PK: List 0, type X509
    Signature 0, size 791, owner 00000000-0000-0000-0000-000000000000
        Subject:
            CN=robi UEFI 2015 PK
        Issuer:
            CN=robi UEFI 2015 PK
Variable KEK, length 821
KEK: List 0, type X509
    Signature 0, size 793, owner a983ecb0-1792-4374-becd-7e6e8f5a1494
        Subject:
            CN=robi UEFI 2015 KEK
        Issuer:
            CN=robi UEFI 2015 KEK
Variable db, length 2519
db: List 0, type X509
    Signature 0, size 791, owner a983ecb0-1792-4374-becd-7e6e8f5a1494
        Subject:
            CN=robi UEFI 2015 db
        Issuer:
            CN=robi UEFI 2015 db
db: List 1, type X509
    Signature 0, size 1672, owner a983ecb0-1792-4374-becd-7e6e8f5a1494
        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 dbx has no entries
Variable MokList has no entries


Beim nächsten Boot sollte dann auch automatisch Secureboot aktiv werden und wir hoffentlich alles richtig gemacht haben und mit unseren konfigurierten Bootloadern im Secureboot Linux booten können.


robi

[Robi]

Die Erfahrungen auf der Hardware:

Erforscht, entwickelt und getestet wurde zuerst nur auf der virtuellen Firmware. Mittlerweile sind aber eigene Zertifikate bei mir auch auf der richtigen HW installiert. Es gibt dabei wie erwartet durchaus ein paar kleine Unterschiede im Verhalten, die sich wahrscheinlich auf weitere Boards des selben Herstellers verallgemeinern lassen.

Zunächst, es wurden nur die Befehle und Scripte verwendet wie sie hier im Beitrag auch aufgeführt sind. Das Installieren der Zertifikate mit Hilfe der auth-Dateien ging problemlos, Beim Versuch dieses in einem Schritt mit efi-updatevar ohne die Umgehung mit den efi-sign-listen zu erledigen, wurde dieses mit einer wenig hilfreichen Fehlermeldung abgewießen. Ähnliches habe ich allerdings auch auf der Virtuellen Umgebung erlebt und dort als wahrscheiliches Problem mit der Seriennummer (also Zeitstempel) indentifiziert. Die Methode über die Auth-Dateien halte ich persönlich sowieso für die bessere und sichere Methode, insbesondere wenn man die Dateien mit einem Script erstellt, diese ist einfach bedingt durch die doch vielen ähnlichen Optionen die richtig angegeben werden müssen.

Den erste wirkliche Unterschied habe ich unmittelbar nach dem Installieren der Key gesehen. Der Virtuelle UEFI hat sofort angezeigt das unmittelbar nach dem Installieren des PK der Status von SetupMode auf UserMode gewechselt hat. Die HW hat dagen nach wie vor angezeit das der SetupMode nach wie vor noch besteht.
Der erster Reboot nach dem Installieren der Keys endete dann auf der HW in einen schwarzen Bildschirm. Nach einigen Untersuchungen war dann die Ursache aber klar. Der Booteintrag der als erster ausprobiert wurde war unter Secureboot derzeit so nicht funktionsfähig, und die Maschien beim Setup so schnell das es gar nicht erst zum Anzeigen des Logos gekommen ist.

Das System hatte aber beim ersten Reset danach von sich aus automatisch auf UserMode und Secureboot umgestellt.

Erkenntnisse zu den vorbereiteten Booteinträgen und den selbst signieren EFI-Tools
Die Signierung der Shell und des KeyTools funktionioniert. Auch die Signierung von grubx64.efi funktioniert eigentlich, der Bootloader startet zumindestens, allerdings bleibt er dann sofort im Rescue-Modus von Grub2 hängen und es lässt sich auch damit so nichts booten. Dieses ist sowohl auf der Virtuellen Firmware wie auch auf der HW das gleiche. Auf meinem Board habe ich bei den Einstellungen jedoch einen Schalter gefunden, "Sicherer Start" (in der Hilfe irgendwas mit Secureboot Flusskontrolle) wird dieser disabled kann man auch das selbst signierte grubx64.efi im Secureboot booten. Diese Einstellmöglichkeite scheint nicht Standard zu sein, bzw in UEFI V2.4 wegzufallen, denn im OVMF gibt es diesen Schalter nicht. Er scheint zu bewirken, das nicht geprüft wird ob nachfolgende Teile des Bootloader oder der Kernel auch richtig signiert sind. Von diesem Schalter wenn möglich die Finger lassen.

Der Booteintrag grub.efi und auch der MokManager die beide nur von OpenSuse signiert sind, funktionieren problemlos. shim.efi das sowohl von Microsoft als auch von Opensuse signiert ist funktioniert nicht auf der Hardware und wird von Secureboot abgewiesen. Auf OVMF funktioniert es. Grund scheint zu sein, bei OVMF werden beide Signaturen zur Secureboot Überprüfung herangezogen, auf der Hardware wird nur der erste Signatureintrag getestet, und das ist der von Microsoft. Wer unbedingt Shim braucht, kann sich bei OpenSuse zB behelfen, in dem er aus dem Shim Paket die Datei /usr/lib64/efi/shim-opensuse.efi anstatt dem installiertem shim.efi nimmt. Dieser ist nur von OpenSuse signiert. weitere Möglichkeit mit "sbattach --remove shim.efi" ließe sich auch die MicosoftSignatur entfernen.

Tests mit der HW:
In der Zwischenzeit sind auch schon eine Menge Tests gelaufen. Die Keys sitzen fest und überleben auch ein Rücksetzen auf Default. Ich kann im Setup SecureBoot ein und Ausschalten und auch vom DefaultMode in den CustomMode schalten und dort alle Keys löschen. (Das Board und damit wahrscheinlich der Großteil der derzeitigen Boards dieses Herstellers sind also geeignet, um sich für Linux eignen Keys zu installieren auch wenn schon beim Kauf die default Keys vorinstalliert sind.) Leider sind meine Keys nach dem Löschen im CustomMode und wieder zurückschalten in den DefaultMode nicht wie eigentlich erwartet noch vorhanden. Allerdings lassen sie sich mit Hilfe der auth-Dateien problemos und schnell wieder installieren.

Im striktem Securboot lassen sich keine CD/DVDs booten. Grund ist klar, es gehen wegen der Keys eh nur welche von OpenSuse und die gehen nicht weil deren Shim nicht geht, Allerdings lassen sich OpenSuse Medien von der EFI-Shell und grub.efi manuell booten. USB-Sticks ließen sich auch nur booten wenn vorher entsprechend konfiguriert ist dass ein Bootloader und der Kernel entweder mit Opensuse oder meine db-Key signiert ist , Wenn das jemand ohne mein Wissen machen wollte, bräuchte der schon ziemlich genauere Kenntnisse was auf diesem Rechner im Secureboot überhaupt geht oder nicht. 0-8-15 geht auf jeden Fall nicht.


Fazit:
Die Aktion ist für mich soweit ein voller Erfolg. Jetzt nur noch die richtigen Einstellungen im UEFI-Setup und dann ein AdminPasswort auf den UEFI. Damit dürfte der Rechner die nächsten Jahre hoffentlich vor so ziemlich allen Gefahren die im UEFI-Umfeld zu erwarten sein könnten gut geschützt sein. Voraussetzung natürlich, der Hersteller hat nicht schon von Hause aus dicke Sicherheits-Löcher in der Firmware drin. Vom Betriebssystem aus kann man den Rechner wahrscheinlich kaputt machen, aber nichts installieren was ohne meine Zustimmung im UEFI oder im UEFI-Hintergrund laufen könnte. Um dieses zu ändern müsste man den Rechner schon physikalisch vor sich haben und würde dann immer noch auf eine Reihe von unerwarteter Problemen stoßen, da das gesammte Setup doch weit-weit weg von jeglicher Standardkonfiguration ist. Dieses Alles ist vielleicht für die Sicherheitanforderungen in einem Hochsicherheits Rechnezentrum noch nicht ganz ausreichend, für den Hausgebrauch reicht mir das aber so in Summe schon aus.


Wie geht es weiter
Dieser Rechner wird definitiv noch einen anderen Bootloader bekommen und Grub2 und Shim fliegen runter. Die derzeit auf den Rechner befindlichen privaten Keys werden mittels shred gelöscht. Die Zertifikate und Keys kommen in einen Passwortsafe auf einem anderem Rechner. Zusätzlich wird noch ein Plan C erstellt, ein USB-Stick der mit meine db Key im Secureboot bootbar ist, und auf dem sich auch die Schlüssel und privaten Keys sowie die verwendeten Scripte und ein Howto in Form eines verschlüsselten Archives befinden. Dieser wird dann an einem sicherem Ort aufbewahrt.

robi

[gehrke]

@robi: Chapeau! Was Du hier gezeigt hast, ist ziemlich cooler Scheiss. Ich bin noch weit davon entfernt, das wirklich nachvollziehen zu können. Aber das ist eine erstklassige Arbeit.

Soweit ist das ganz einfach. Allerdings ist es jetzt so, ein normaler Rechner wird ausgeliefert und dort sind schon alle Keys vom Hersteller/Produzent drin, und ich komme nicht an die privaten Keys um irgendwelche Änderungen vorzunehmen.
[...]
Die seltene Ausnahme die ich derzeit vor mir habe, Ich habe ein Systemboard gekauft, und auf diesem sind noch keine Keys drauf, ich kann mir also selbst welche drauf basteln wie es mir passt,

Also klar ist, dass der ALDI-PC mit Windows ausgeliefert mit allen möglichen Keys kommt, die man auch nie mehr weg bekommt. Richtig?
Wer also Wert legt auf möglichst hohe Autonomie, sollte so vorgehen wie hier gezeigt. Aber woran erkenne ich ein jungfräuliches, unverseuchtes Board?

[Robi]

Also klar ist, dass der ALDI-PC mit Windows ausgeliefert mit allen möglichen Keys kommt, die man auch nie mehr weg bekommt. Richtig?

Sobald irgend eine Marken-Firma ihr Label auf den Rechner klebt, sind die Keys drin und Windwos drauf. Ganz ohne vorinstallierte Securebootkeys gehts wohl nur beim Kauf eines Boards, bzw. eventuell auch wenn man sich den Rechner von einer kleinen Firma oder beim Händler individuell zusammenstellen lässt. Eventuell noch mit Glück bei einer Kleinserie, wenn kein Windows vorinstalliert wird.

Wer also Wert legt auf möglichst hohe Autonomie, sollte so vorgehen wie hier gezeigt. Aber woran erkenne ich ein jungfräuliches, unverseuchtes Board?

Zu erkennen ist das erstmal nur mit geschärften Augen und dem Wissen nach was man suchen muss im Setup. Um es wirklich genau wissen will muss man die Variablen dazu auslesen, entweder wenn es geht vom BIOS-Setup aus, oder aus einem mit UEFI installiertem Linux oder von der EFI-Shell mit oder ohne Zuhilfenahme von Tools.
Wie die Hardwarespezifikation die Microsoft den Herstellern vorgibt, ist ein Schalter im UEFI-Setupmenu für die Intel-PC-Plattform vorgesehen, zum Umschalten von "DefaultMode" in "CustomMode". Beim Umschalten in den CustomMode würden temporär die vorinstallierten Keys entweder gleich gelöscht, oder danach manuell zu löschen und eventuell auch gleich dort eigenen Keys zu installieren sein. Wie ich an meinem Systemboard gesehen habe (Bild), der Schalter ist da, ist aber versteckt und man muss etwas rumprobieren bis man dort hin kommt. Wenn man den Rechner anschließend im CustomMode lässt und nicht wieder umschaltet auf DefaultMode und auch keinen "Reset to Factory" macht, kann man den Rechner dann trotzdem mit seinen eigenen Keys betreiben. Die vorinstallierten Keys sind zwar noch Rechner, aber sind inaktiv und kommen erst wenn jemand diese Einstellung wieder zurücksetzen würde. Von daher gehts auf einem vorinstallierten auch.

robi