Strona 1 z 1

Własne klucze w UEFI/Secure Boot

: 13 stycznia 2017, 14:51
autor: Radson
Jako że jest mój pierwszy post na forum, chciałbym się przywitać, a jednocześnie podziękować za to że wcześniej wielokrotnie znajdowałem tu rozwiązanie swoich wcześniejszych problemów, bo "biernym" użytkownikiem tego forum jestem już od paru lat.

Przechodząc jednak do rzeczy, postanowiłem ujarzmić Secure Boot i zmusić go do współpracy z Debianem. Stworzyłem więc własne klucze PK, KEK oraz db i zaktualizowałem w ustawieniach BIOSu (PK oczywiście jako ostatni). Podpisałem również binarkę bootloadera (w moim przypadku rEFIND jednak ze standardowym Grubem był ten sam problem), jednak przy włączonym Secure Boot występuje ten sam błąd co z każdym niepodpisanym bootloaderem. Mam więc pytanie, czy jest to możliwe, że mój BIOS mimo że pozwala na manipuk akceptuje tylko klucze od Microsoftu, albo czy moje klucze wogóle się nie dodały pomimo tego że efi-readvar je pokazuje?

Kod: Zaznacz cały

Variable PK, length 838
PK: List 0, type X509
    Signature 0, size 810, owner 26dc4851-195f-4ae1-9a19-fbf883bbb35e
        Subject:
            CN=radson's platform key
        Issuer:
            CN=radson's platform key
Variable KEK, length 4410
KEK: List 0, type X509
    Signature 0, size 852, owner 3b053091-6c9f-04cc-b1ac-e2a51e3be5f5
        Subject:
            CN=ASUSTeK Notebook KEK Certificate
        Issuer:
            CN=ASUSTeK Notebook KEK Certificate
KEK: List 1, type X509
    Signature 0, size 1532, owner 77fa9abd-0359-4d32-bd60-28f4e78f784b
        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
KEK: List 2, type X509
    Signature 0, size 1096, owner 6dc40ae4-2ee8-9c4c-a314-0fc7b2008710
        Subject:
            C=GB, ST=Isle of Man, L=Douglas, O=Canonical Ltd., CN=Canonical Ltd. Master Certificate Authority
        Issuer:
            C=GB, ST=Isle of Man, L=Douglas, O=Canonical Ltd., CN=Canonical Ltd. Master Certificate Authority
KEK: List 3, type X509
    Signature 0, size 818, owner 26dc4851-195f-4ae1-9a19-fbf883bbb35e
        Subject:
            CN=radson's key-exchange key
        Issuer:
            CN=radson's key-exchange key
Variable db, length 6904
db: List 0, type X509
    Signature 0, size 861, owner 3b053091-6c9f-04cc-b1ac-e2a51e3be5f5
        Subject:
            CN=ASUSTeK Notebook SW Key Certificate
        Issuer:
            CN=ASUSTeK Notebook SW Key Certificate
db: List 1, type X509
    Signature 0, size 870, owner 3b053091-6c9f-04cc-b1ac-e2a51e3be5f5
        Subject:
            CN=ASUSTeK MotherBoard SW Key Certificate
        Issuer:
            CN=ASUSTeK MotherBoard SW Key Certificate
db: List 2, type X509
    Signature 0, size 1572, owner 77fa9abd-0359-4d32-bd60-28f4e78f784b
        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
db: List 3, type X509
    Signature 0, size 1515, owner 77fa9abd-0359-4d32-bd60-28f4e78f784b
        Subject:
            C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Windows Production PCA 2011
        Issuer:
            C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Root Certificate Authority 2010
db: List 4, type X509
    Signature 0, size 1096, owner 6dc40ae4-2ee8-9c4c-a314-0fc7b2008710
        Subject:
            C=GB, ST=Isle of Man, L=Douglas, O=Canonical Ltd., CN=Canonical Ltd. Master Certificate Authority
        Issuer:
            C=GB, ST=Isle of Man, L=Douglas, O=Canonical Ltd., CN=Canonical Ltd. Master Certificate Authority
db: List 5, type X509
    Signature 0, size 822, owner 26dc4851-195f-4ae1-9a19-fbf883bbb35e
        Subject:
            CN=radson's kernel-signing key
        Issuer:
            CN=radson's kernel-signing key
Variable dbx, length 877
dbx: List 0, type X509
    Signature 0, size 849, owner 00000000-0000-0000-0000-000000000000
        Subject:
            CN=DO NOT TRUST - Lost Certificate
        Issuer:
            CN=DO NOT TRUST - Lost Certificate
Variable MokList has no entries
Do podpisania pliku bootloadera użyłem narzędzia sbsigntool.
Klucz PK oraz ostatnie pozycje w KEK i db zostały wygenerowane przeze mnie.

Re: Własne klucze w UEFI/Secure Boot

: 13 stycznia 2017, 21:21
autor: dedito
Po co w ogóle chcesz zmusić Debiana do pracy z Secure Boot?

Re: Własne klucze w UEFI/Secure Boot

: 13 stycznia 2017, 23:31
autor: Radson
dedito pisze:Po co w ogóle chcesz zmusić Debiana do pracy z Secure Boot?
Pewnie dlatego, że lubię bawić się/eksperymentować nowymi technologiami, a tym razem padło na Secure Boot. No cóż, powodem założenia tego tematu była poniekąd ciekawość, chciałem sprawdzić czy któryś z forumowiczów również eksperymentował z Secure Boot.

Re: Własne klucze w UEFI/Secure Boot

: 14 stycznia 2017, 10:31
autor: dedito
To może trochę literatury, pewnie to studiowałeś, ale dla porządku należałoby przytoczyć dla ewentualnych zainteresowanych:
http://www.rodsbooks.com/efi-bootloader ... eboot.html
https://wiki.archlinux.org/index.php/Se ... r_own_keys
https://wiki.ubuntu.com/SecurityTeam/Se ... h_user_key

Re: Własne klucze w UEFI/Secure Boot

: 14 stycznia 2017, 12:57
autor: Radson
dedito pisze:To może trochę literatury, pewnie to studiowałeś, ale dla porządku należałoby przytoczyć dla ewentualnych zainteresowanych:
http://www.rodsbooks.com/efi-bootloader ... eboot.html
https://wiki.archlinux.org/index.php/Se ... r_own_keys
https://wiki.ubuntu.com/SecurityTeam/Se ... h_user_key
Tak, zapoznałem się z tym co podlinkowałeś. Ogólnie wzorowałem się tym poradnikiem z wiki Gentoo, jednak problem jest niezależny od dystrybucji, więc podlinkowany przez Ciebie poradnik pod Archa jest jak najbardziej ok. No cóż, spróbuję podpisać bootloader najnowszym sbsigntools (0.8) i dam znać czy są jakieś efekty. No i oczywiście dzięki za zainteresowanie.

Re: Własne klucze w UEFI/Secure Boot

: 14 stycznia 2017, 13:00
autor: dedito

Re: Własne klucze w UEFI/Secure Boot

: 19 marca 2020, 19:44
autor: Morfik
Ja ostatnio się wziąłem za ten temat i w zasadzie nie stwierdziłem większych problemów. Debiana też nie trzeba zmuszać do niczego by ten Secure Boot działał. :D

Jak coś to tutaj naskrobałem kawałek tutka na temat podmiany kluczy dla Secure Boot w firmware EFI/UEFI.