## README_Secure_Boot
WARNING!!!! PLEASE MAKE SURE YOU KNOW EXACTLY WHAT YOU ARE DOING BEFORE PROCEEDING.
SlackBuilds.org 2023 accepts no liability for any issues caused by
using this software. The software is provided as is and requires
a working knowledge, of setting up secure booting and keys.
How to use these files
simply typing make will build you everything including sample certificates for
PK, KEK and db.
The prerequisites are the standard development environment,
gnu-efi version 3.0q or later, help2man and sbsigntools.
There will be one file called LockDown.efi. If run on your
efi platform in Setup Mode, this binary will *replace* all the
values in thePK, KEK and db
variables with the ones you just generated and place the platform
back into User Mode (booting securely). If you don't
want to replace allthe variables, take a dump of your current
variables,
see sig-list-to-cert(1), and add them
to the EFI signature list files before creating LockDown.efi
Say you want to concatenate an existing platform-db.esl file,
do this:
make DB.esl
cat platform.esl DB.esl > newDB.esl
mv newDB.esl DB.esl
and then make LockDown.efi in the usual way.
All of the EFI programs are also generated in signed form
(signed by both db and KEK).
Loader.efi
==========
This EFI binary is created to boot an unsigned EFI file on the
platform. Since this explicitly breaks the security of the
platform, it will first check to see if the boot binary is
naturally executable and execute it if it is
(either it's properly signed or the platform isn't in Secure
Boot mode).
If the binary gives an EFI_ACCESS_DENIED error meaning it
isn't properly signed,
Loader.efi will request present user authorisation before
proceeding to boot.
The idea is that Loader.efi may serve as a chain for elilo.efi
or another boot loader on distributed linux live and install
CDs and even as
the boot loader for the distribution on the hard disk
assuming the user does not wish to take control of the platform
and replace the keys.
To build a secure bootable CD, simply use Loader.efi as the usual
/efi/boot/bootX64.efi and place the usual loader in the same
directory as the file boot.efi.
In order to add further convenience, if the user places
the platform in setup mode and re-runs the loader,
it will ask permission to add the signature the unsigned
boot loader, boot.efi, to the authorised signatures
database, meaningLoader.efi will now no longer
ask for present user authorisation every time the system is
started.
Creating, using and installing your own keys
============================================
To create PEM files with the certificate and the key for PK for
example, do
openssl req -new -x509 -newkey rsa:2048 -subj "/CN=PK/" -keyout \
PK.key -out PK.crt -days 3650 -nodes -sha256
Which will create a self signed X509 certificate for PK in PK.crt
(using unprotected key PK.key with the subject common name PK
(that's what the CN=PK is doing).
You need to create at least three sets of certificates: one for PK,
one for KEK and one for db.
Now you need to take all the efi binaries in
/usr/share/efitools/efi and sign them with your own db key
using,
sbsign --key db.key --cert db.crt --output \
HelloWorld-signed.efi HelloWorld.efi
To install your new keys on the platform, first create your
authorised update bundles:
cert-to-sig-list PK.crt PK.esl
sign-efi-sig-list -k PK.key -c PK.crt PK PK.esl PK.auth
And repeat for KEK and db. In setup mode, it only matters that
the PK update PK.auth is signed by the new platform key.
None of the other variables will have their signatures checked.
Now on your platform update the variables, remembering to do PK
last because an update to PK usually puts the platform
into secure mode
UpdateVars db db.auth
UpdateVars KEK KEK.auth
UpdateVars PK PK.auth
And you should now be running in secure mode with your own keys.
|
