If it is interesting to you how to generate the obstvenny keys for SecureBoot how to set them instead of standard (or together with them), how to sign your favourite EFI loader how to prohibit loading unsigned or signed with others conversion keys as the interface for the SecureBoot setup at AMI, Insyde and Phoenix looks and why it, by and large, is not important at all — welcome under kat, but be afraid of a large number of pictures and long console instructions.
How it is arranged and SecureBoot works, I already told at the beginning of the fifth part of the above-mentioned opus, to repeat I do not see sense. If you it is not aware about what all this UEFI SecureBoot in general who such PK, KEK, db and dbx and why from the point of view of SecureBoot by default an owner of your system is the vendor of UEFI, and the only authorized user is Microsoft — safely proceed there, we here so far will wait for you.
With an educational program finished, to business now. In spite of the fact that about creation of the keys and the SecureBoot setup about ten excellent articles (references to part from which are given in the section Literature), things are right where they started are written in three last years. The main problem with information on the SecureBoot setup even in English-speaking network segment (not to mention a RuNet) — the most part of articles, texts and posts breaks on "here we have keys in the EFI Signature List format now, add their dependent on your vendor a firmware by method and it is ready". At the same time vendors do not hurry to describe the menu of the SecureBoot setup in documentation on the platforms for Oyem'ov, in manuals on final systems, as a result the user is lost on the unfamiliar district and or disconnects SecureBoot preventing to load his darling of OpenBSD (or that there at it), or leaves it on default settings (and what, Windows is loaded). I will also try to describe this last step in more detail, but not to the detriment of other necessary steps.
Especially for this article I got from granaries pair not of the newest notebooks with firmwares on the Phoenix SCT and Insyde H2O platforms, and also absolutely new payment of congatec (for which I am busy with development of a firmware at present) on the AMI AptioV platform. Meet, our test stands:
1. AMI, they are "triangular": congatec conga-TR3 @ conga-TEVAL, AMD RX-216GD (Merlin Falcon), AMI AptioV (UEFI 2.4)
2. Insyde, they are "square": Acer Aspire R14 R3-471T (Quanta ZQX), Intel Core i3-4030U (Ivy Bridge), Insyde H2O (UEFI 2.3.1C)
3. Phoenix, they are "semicircular": Dell Vostro 3360 (Quanta V07), Intel Core i7-3537U (Ivy Bridge), Phoenix SCT (UEFI 2.3.1C)
About interfaces for the SecureBoot setup
On all above-mentioned systems the vendor declares support of the UEFI SecureBoot technology, but the interface for its setup strongly differs between systems. Fortunately, it is not really big problem as for the SecureBoot setup on compatible to the UEFI 2.3.1C specification (and newer) firmwares no interface in Setup, except a possibility of removal of the current PK (i.e. transfer of SecureBoot in so-called Setup Mode) is required, and after that it is possible to use any EFI-application capable to cause the UEFI service gRS-> SetVariable with user-provided data, including the utility of KeyTool.efi from a packet of efitools which especially for key management and is intended it was necessary only to learn it to use.
Nevertheless, if the convenient interface for setup is present (at AMI it, in my opinion, even more conveniently KeyTool'a) — can use it so it is necessary to tell about these interfaces all the same.
We prepare the base
Let's begin with lyrical digression about existence of the necessary software for different OS. In spite of the fact that Microsoft is one of developers of technology, in open access still there are no normal means for work with it from Windows (keys can be generated the utility of MakeCert from the Windows SDK, and for all the rest it is offered to use HSM of the third parties for big money). I thought at first to take and write the necessary utility on Qt, but therefore I decided that keys and signatures do not need to be generated every day, and on few times there will be enough also existing solutions. You can try to overpersuade me in comments if you want.
Generally, for all following you need Linux (which can be started with LiveUSB if it at you is not set). For it exists the whole two sets of utilities for work with SecureBoot: efitools/sbsigntool and EFIKeyGen/pesign. I have a positive experience with the first set therefore it will be a question of it.
As a result, except Linux, several things will be necessary for us:
1. A packet of openssl and the utility of the same name from it for generation of key couples and conversion of certificates from DER in PEM.
2. efitools packet, to be exact utilities of cert-to-efi-sig-list, sign-efi-sig-list for conversion of certificates to the ESL format and signatures of files in this format, and KeyTool.efi for key management of the system which is in SetupMode.
3. sbsigntool packet, to be exact the utility of sbsign for the signature of the performed UEFI files (i.e. loaders, DXE drivers, Optionrom'ov and applications for UEFI Shell) your key.
Load Linux, set the above-stated packets, open the terminal in a house directory and you pass to the following step.
We generate own keys for SecureBoot
As usual, there are several methods to make something, and the used tool is more powerful, the it is more such methods. OpenSSL as the tool is developed so that it seems that he is able to do in general everything and if to read to it man — that and all rest. Therefore in this article I will be limited to direct generation of key files, and I will leave dances around creation of own CA on independent studying.
We generate key couplesKeys it is required to generate three pieces: PK, KEK and ISK.
Let's begin with PK for which generation it is necessary to execute the following
then to enter and confirm the password which then will ask in attempt of the signature something the turned-out private key.
openssl req -new -x509 -newkey rsa:2048 -sha256 -days 365 -subj "/CN=Platform Key" -keyout PK.key -out PK.pem
Command above we ask to generate OpenSSL to us key couple of RSA2048/SHA256 with validity period for one year, under the name Platform Key, with an output of the private key in the PK.key file and opened — in the PK.pem file. If to add - nodes, then for the signature in this key couple the password will not be necessary, but here we will not begin to do it — with the password though not much more, but it is safer.
In the same way we generate key couples for KEK and ISK, at the same time I advise passwords to enter different:
openssl req -new -x509 -newkey rsa:2048 -sha256 -days 365 -subj "/CN=Key Exchange Key" -keyout KEK.key -out KEK.pem
openssl req -new -x509 -newkey rsa:2048 -sha256 -days 365 -subj "/CN=Image Signing Key" -keyout ISK.key -out ISK.pem
We convert public keys into the ESL formatNow it is necessary to convert public keys from the PEM format in clear UEFI SecureBoot the ESL format. This binary format is described in the UEFI specification (section 30.4.1 in the current version 2.5) and is interesting that files in it can be connected with each other concatenation, and this fact still is useful to us.
cert-to-efi-sig-list -g "$(uuidgen)" PK.pem PK.esl
cert-to-efi-sig-list -g "$(uuidgen)" KEK.pem KEK.esl
The key - g adds to the generated GUID ESL file, in our case — accidental, half-scientific start of the utility of uuidgen and use of its output. If you do not have this utility — think out GUIDY or leave value by default.
cert-to-efi-sig-list -g "$(uuidgen)" ISK.pem ISK.esl
We sign ESL filesIt is necessary for correctly work of SecureBoot that PK was signed by itself, KEK is signed with PK, and db and dbx storages — sotvetstvenno KEK. At this PK cannot be a little, and here the situation from several KEK though meets in the wild nature, but I nevertheless strongly recommend to delete the preset key of Microsoft from KEK for the simple reason — db and dbx can be signed with any key from KEK storage i.e. if from there not to delete MS key, then MS will have an opportunity to manage contents of db and dbx, i.e. to add any new keys or hashes to the list of a trusted boot and to delete from it existing. In my opinion, it is a little too and if we take key management in hand, then it is necessary to do it up to the end.
then to convert the received PEM in ESL command
openssl x509 -in MicCorKEKCA2011_2011-06-24.crt -inform DER -out MsKEK.pem -outform PEM
then to add the turned-out file to our KEK.esl file command
cert-to-efi-sig-list -g "$(uuidgen)" MsKEK.pem MsKEK.esl
Now Microsoft the same authorized user of your platform, as well as you what I also congratulate you on.
cat KEK.esl MsKEK.esl > KEK.esl
The same sequence, as under a spoiler above. We convert from DER into PEM, then from PEM into ESL, then we add to db.esl which eventually should be signed with any key from KEK:
openssl x509 -in MicWinProPCA2011_2011-10-19.crt -inform DER -out MsWin.pem -outform PEM
openssl x509 -in MicCorUEFCA2011_2011-06-27.crt -inform DER -out UEFI.pem -outform PEM
cert-to-efi-sig-list -g "$(uuidgen)" MsWin.pem MsWin.esl
cert-to-efi-sig-list -g "$(uuidgen)" UEFI.pem UEFI.esl
cat ISK.esl MsWin.esl UEFI.esl > db.esl
Now we sign PK by itself:
We sign KEK.esl with PK key:
sign-efi-sig-list -k PK.key -c PK.pem PK PK.esl PK.auth
We sign db.esl with KEK key:
sign-efi-sig-list -k PK.key -c PK.pem KEK KEK.esl KEK.auth
sign-efi-sig-list -k KEK.key -c KEK.pem db db.esl db.auth
If did not bother yet, it is possible to add something else to db or to form dbx storage, the necessary teams you know now, all further — on your discretion.
We sign the loaderIt was necessary to sign some performed file with ISK key to check work of SecureBoot after adding of your keys. For tests I advise to sign the utility of RU.efi, it graphic and bright, and even from far away it is visible, it was started or not. Actually, the utility this extremely powerful and it it is possible to do kind and not really many cases therefore after tests it will be best of all to delete it, and further to sign only loaders.
Anyway, the performed files here are signed by such command:
Here I renamed the performed file at the same time into bootx64.efi which needs to be put in directory/EFI/BOOT of the test USB carrier with FS FAT32. For 32-bit UEFI (relieve you rand of work with them) use bootia32.efi and RU32.efi.
sbsign --key ISK.key --cert ISK.pem --output bootx64.efi RU.efi
As a result of this everything at you three .auth files which will need to be written "turned out as is" in NVRAM variables db, KEK and PK, and in such order. Copy all three files in a root of other USB carrier from FS FAT32 on which in quality/EFI/BOOT/bootx64.efi use/share/efitools/efi/KeyTool.efi will act / (copy it also in a root, just in case) and your "set of the tamer of SecureBoot" is ready.
Taming of obstinate
Everything begins equally: we insert our USB stick with keys and Keytool'om into the free USB port, vklyuchiy the machine, we come into BIOS Setup.
Here, before being engaged in the SecureBoot setup, it is necessary to disconnect CSM, and with it — and legasi-loading to which our technology is not compatible. Also surely put on an input in BIOS Setup the password more long, otherwise it will be possible to bypass SecureBoot just having disconnected it for what on some systems with IPMI and/or AMT even physical presence will not be required.
AMI AptioVAt the majority of the firmwares based on the AMI code, management of the SecureBoot technology is on the Security tab, at me this management looks so:
We come into the Key Management menu (earlier it was on the same tab, now it was selected in separate) and we see the following there:
We select a variable necessary to us then at first suggest to select between installation of a new key and adding to already available, we select the first:
Now value by default is offered or to set, or to load own of the file, we select the last:
Further the device and the file on it is necessary, and then to select a format of this file, in our case it is Authenticated Variable:
Then it is necessary to confirm file updating and if everything went well before, as a result we will receive the laconic message:
We repeat the same for KEK and PK, and to polucha on an output here such status:
Everything is right, we have only PK, only one key in KEK and three keys in db, return to the previous menu the Esc button and we include SecureBoot:
It is ready, we save settings and we leave with reset then we try to be loaded from our USB stick and we see here such picture:
Perfectly, unsigned loaders go the wood, it was necessary to check signed. We insert other USB stick, we reboot and we see something like that:
Now it is possible to tell that SecureBoot works as it is necessary.
If your AMI UEFI of such interface for adding has no keys, then you will suit other method about which further.
Insyde H2OHere everything is slightly worse, than in the previous case. There is no interface for adding of own keys, and opportunities of the SecureBoot setup it is offered only three: or to delete all variables time, having transferred SecureBoot to Setup Mode, or to select the performed file which hash will be added to db, and it can be started even if it is not signed in general, or to return to standard keys as which by this machine PK from Acer, on a key from Acer and MS in KEK and a lot of everyone from Acer and MS in db act.
However, there is no interface — the hell with him, at us for this KeyTool is, the main thing that it is possible to pass into Setup Mode. It is interesting that BIOS Setup does not allow to include SecureBoot if the password of Supervisor Password is not set therefore we set at first it, then we execute erasing of keys:
Then on the next Boot tab we select the mode of loading of UEFI and we include SecureBoot:
Since photos at me in the middle of night turn out insufferably disgusting, I will make KeyTool'a screenshots on the previous system, and it is necessary to believe you that on this everything looks in the same way (mother I swear!).
We are loaded from our carrier into KeyTool, and we see approximately following:
We select Edit Keys, we are included in the menu of the choice of storage:
There at first we select db, then Replace Keys, then our USB device, and then and the file:
We click Enter and without any messages on success show us the menu of the choice of storage again. We repeat the same at first for KEK, and then and for PK, later we leave in the main menu double clicking Esc. We switch off the machine, we include again, we try to load KeyTool again and we see such picture (which I dragged off from a dump of a firmware, its photo on the glossy screen still koshmarny, than previous):
There now, one part of SecureBoot'a works, another is checked by start of RU.efi signed by us and too works. At me on this Windows 8 system it is installed in the UEFI mode, and so — also it works, Microsoft with the certificate was not brought.
Phoenix SCTHere it is even less opportunities, and in all Secure Boot Configuration menu on the Security tab only two points: return to standard keys and removal of all keys with transfer of system in SetupMode, is just necessary for us the second:
Then on the Boot tab it is necessary to select type of loading of UEFI, to include SecureBoot and to create the boot record for KeyTool'a, otherwise on this platform to start it it will not turn out:
We click Yes, we leave with saving of changes, we reboot, we click when loading F12 to be included in the boot menu, we select from there KeyTool, work with which is described above. After adding of keys and reset attempt of restart of KeyTool'a comes to an end here so:
At the same time set by the same machine Linux RU.efi signed by us so SecureBoot can recognize operable continues to be loaded regularly, as well as.
As a result, thanks to utilities with the open code, it was succeeded to get SecureBoot on systems with UEFI of three different vendors, to generate own keys and to sign with them the performed files necessary to us. Now loading of a platform entirely in our hands, but only if the password on BIOS resistant is also not stored by clear text as some, and in implementation of SecureBoot have any known (or yet unknown) no holes. SecureBoot in itself — not panacea from butkit, but with it a situation with safe loading is all the same much better, than without it.
I hope that material will help you, and thanks that read this footcloth.
Managing EFI Bootloaders for Linux: Controlling SecureBoot.
AltLinux UEFI SecureBoot mini-HOWTO.
Booting a self-signed Linux kernel.
Sakaki's EFI Install Guide: Configuring SecureBoot.
Ubuntu Security Team: SecureBoot.
Owning your Windows 8 UEFI Platform.
MinnowBoard Max: Quickstart UEFI Secure Boot.
Windows 8.1 Secure Boot Key Creation and Management Guidance.
This article is a translation of the original post at habrahabr.ru/post/273497/
If you have any questions regarding the material covered in the article above, please, contact the original author of the post.
If you have any complaints about this article or you want this article to be deleted, please, drop an email here: email@example.com.
We believe that the knowledge, which is available at the most popular Russian IT blog habrahabr.ru, should be accessed by everyone, even though it is poorly translated.
Shared knowledge makes the world better.