¡Esta es una revisión vieja del documento!
Tabla de Contenidos
Habilitando el arranque seguro en Slackware
En el hardware basado en la Interfaz de firmware extensible unificada (UEFI), un sistema puede operar en modo de arranque seguro. En el modo de arranque seguro, solo los binarios EFI (es decir, los gestores de arranque, los cargadores de arranque) en los que el propietario de la plataforma confía, ya sea explícitamente o mediante una cadena de confianza, pueden ejecutarse en el momento del arranque. Esto evita que los binarios y sistemas operativos no autorizados de EFI se ejecuten en su sistema, lo que puede mejorar la seguridad.
Este artículo te enseñará:
- Acerca de las claves de arranque seguro y las bases de datos de firmas
- Cómo registrar claves de arranque seguro mientras se inicia en Slackware
- Cómo firmar archivos binarios de EFI para su uso en el modo de arranque seguro.
Claves de arranque seguro y bases de datos de firmas
Se utilizan dos tipos de claves de arranque seguro para crear relaciones de confianza:
- Clave de la plataforma: esto establece la relación de confianza entre el propietario de la plataforma y el firmware de la plataforma. El firmware UEFI solo puede almacenar una clave de plataforma. La clave pública se almacena en la variable de arranque seguro
PK
. Esta clave permite al propietario de la plataforma manipular todas las claves de arranque seguro y las bases de datos de firmas. - Key Exchange Key: establece la relación de confianza entre el sistema operativo y el firmware de la plataforma. El firmware UEFI puede almacenar múltiples claves de intercambio de claves. Las claves públicas se almacenan en la variable de arranque seguro “KEK”. Key Exchange Keys solo permite que el sistema operativo manipule las bases de datos de firmas.
Hay dos bases de datos de firmas para autorizar binarios de EFI:
- Base de datos de firmas prohibidas: almacena hashes y claves de firma públicas de binarios EFI prohibidos. Esto utiliza la variable de arranque seguro
dbx
. Los binarios EFI con hashes presentes en esta base de datos o firmas que pueden autenticarse con una clave de firma almacenada en la base de datos tienen prohibido cargarse. - Base de datos de firmas autorizada: almacena hashes y claves de firma públicas de binarios de EFI de confianza. Esto utiliza la variable de arranque seguro
db
. Los binarios EFI con hashes presentes en esta base de datos o firmas que pueden autenticarse usando una clave de firma almacenada en la base de datos pueden ejecutarse si no hay coincidencias con ninguna entrada en la base de datos de firmas prohibidas.
Requisitos
Necesitarás el paquete efitools and sbsigntools antes de que empieces. En Slackbuilds están disponibled http://slackbuilds.org.
Si aún no tiene su propia clave de plataforma inscrita en el firmware UEFI, el howto asume que tiene desactivado el arranque seguro y que ha borrado la variable PK
en el firmware UEFI.
Inscripción de claves de inicio seguro y entradas de base de datos de firmas
Si no tiene un par de claves de plataforma existentes y un par de claves de firma binaria EFI, el método más sencillo para crear los pares de claves sería crear claves autofirmadas. Se recomienda crear pares de claves RSA de 2048 bits que usen el algoritmo de firma sha256RSA. Para generar claves autofirmadas con las propiedades recomendadas, ejecute:
openssl req -new -x509 -newkey rsa:2048 -subj "/CN=Platform Key Common Name/" \ -keyout PK.priv -out PK.pub -days 3650 -nodes -sha256 openssl req -new -x509 -newkey rsa:2048 -subj "/CN=EFI Binary Signing Key Common Name/" \ -keyout db.priv -out db.pub -days 3650 -nodes -sha256
que crea claves privadas con la extensión .priv
y certificados de clave pública con la extensión .pub
. Es posible que desee ajustar el período de validez de la clave y elegir un Nombre común (CN) diferente para ayudar a distinguir sus claves.
To prepare a new Platform Key for writing to the PK
variable:
- Insert the public Platform Key into an EFI signature list:
cert-to-efi-sig-list -g owner_guid PK.pub PK.esl
replacing
owner_guid
with a hexadecimal GUID in the format12345678-1234-1234-123456789abc
. The owner GUID should be the same for all keys that you own. If an operating system cannot add a signature to a signature database due to a lack of resources, it may remove a signature with an owner GUID associated with the operating system. - Sign the EFI signature list. In Setup mode (Secure Boot off) the private half of the inserted key should sign the signature list. In User mode (Secure Boot on) the private key of the current Platform key should sign the signature list:
sign-efi-sig-list -k PK.priv -c PK.pub PK PK.esl PK.signed
A similar procedure applies for preparing a Key Exchange Key or a signature database entry for writing to the KEK
, db
, or dbx
variables. Key Exchange Keys must be signed by the private half of the Platform Key:
cert-to-efi-sig-list -g owner_guid KEK.pub KEK.esl sign-efi-sig-list -a -k PK.priv -c PK.pub KEK KEK.esl KEK.signed
And signature database entries must be signed by the private half of the Platform Key or any of the Key Exchange Keys:
cert-to-efi-sig-list -g owner_guid db.pub db.esl sign-efi-sig-list -a -k PK.priv -c PK.pub db db.esl db.signed
Note that the -a
option was used to prepare for an append write.
To update the Secure Boot variables you must have root privileges. You will need to load the efivarfs kernel module and mount the efivarfs filesystem beforehand if it has not been taken care of already:
modprobe efivarfs mount -t efivarfs efivarfs /sys/firmware/efi/efivars
To enroll the Platform Key, run:
efi-updatevar -f PK.esl.signed PK
If the system was in Setup mode it will now be in User mode.
To add keys to the KEK
, db
or dbx
variables, run (as appropriate):
efi-updatevar -a -f KEK.signed KEK
efi-updatevar -a -f db.signed db
efi-updatevar -a -f dbx.signed dbx
You can check that your keys have been properly enrolled using efi-readvar
.
Signing EFI Binaries
My recommendation (at the time of writing) is that you either use a boot manager with an EFI stub kernel, or directly boot an EFI stub kernel. ELILO, efilinux and syslinux (and possibly GRUB but I do not know for sure) will allow unsigned kernels to run (or at least it does on my hardware and VM), which defeats the purpose of Secure Boot. If you do follow my recommendation, make sure you sign your kernel every time you change it.
You will need to sign all EFI binaries, up to, and including your bootloader and/or EFI stub kernel. To sign an binary, run:
sbsign --key db.priv --cert db.pub --output signed_binary.efi binary.efi
An example of how to add an EFI stub kernel entry using efibootmgr is:
efibootmgr -c -L SlackSecureBoot -l '\EFI\Slackware\vmlinuz-signed.efi' -u 'root=/dev/sda3'
warning: gap in section table
when signing an EFI binary (see below), the binary will probably not work in Secure Boot mode. This warning appears for EFI binaries built against earlier gnu-efi library versions. If you plan to use ELILO you will need to recompile it yourself, the version shipped with Slackware will not work.
warning: gap in section table: .text : 0x00000400 - 0x00017c00, .reloc : 0x00017ca1 - 0x000180a1, warning: gap in section table: .reloc : 0x00017ca1 - 0x000180a1, .data : 0x00018000 - 0x00033000, gaps in the section table may result in different checksums warning: data remaining[225792 vs 242346]: gaps between PE/COFF sections?
Disabling Secure Boot
If you want to remove all Secure Boot keys and revert to Setup mode, the easiest way to do so is to sign an empty file with your Platform Key and write the signed file to all the Secure Boot variables:
touch empty sign-efi-sig-list -k PK.priv -c PK.pub PK empty empty.signed efi-updatevar -f empty.signed PK efi-updatevar -f empty.signed KEK efi-updatevar -f empty.signed db efi-updatevar -f empty.signed dbx
Dual/Multi-booting with Windows
If Windows is one of your boot options, you will need the Microsoft KEK and db certificates. The certificates can be found at https://technet.microsoft.com/en-us/library/dn747883.aspx and will need to be converted from DER format to PEM format:
openssl x509 -in certificate.der -inform DER -out certificate.pem
The instructions that were provided above can then be used to enroll the certificates. The owner GUID you should use for Microsoft keys is 77fa9abd-0359-4d32-bd60-28f4e78f784b.