-
Notifications
You must be signed in to change notification settings - Fork 1
old fork, use upstream
License
marineam/efitools
Folders and files
Name | Name | Last commit message | Last commit date | |
---|---|---|---|---|
Repository files navigation
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 the PK, 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 all the 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, meaning Loader.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.
About
old fork, use upstream
Resources
License
Stars
Watchers
Forks
Packages 0
No packages published