what we expect to do -------------------- The current idea is to use the latest shim signed by Microsoft that will enable us to bootstrap into a later boot loader that can be signed by Debian. grub itself will need to be signed by a FTP master, so we will need to sort out key signing. Same for the kernel. Roughly matches existing deployment in Ubuntu, although hopefully with some further improvements on top. What is the shim ---------------- EFI executable that is in a format that is acceptable for signing by microsoft. UEFI has a database of keys that can be used for signing, the shim is to be used by a 3rd party. Supports its own user-modifiable key database (MokManager) so an end user can install their own key (requires the user to be physically present). Grub will call into the shim to verify the kernel, so you get a fully signed root of trust. Could theoretically verify initramfs and root filesystem. You can also disable sig validation so shim will launch anything you give it (again requiring physical presence)... from then on it will boot any copy of grub /kernel, without disabling secure boot entirely... allows for kernel and grub development without having to jump through a lot of hoops. The aim is the least worst that still respects user's freedoms. Local key management was implemented by SUSE, the rest by redhat. Future: support for ARM has just been added; fall-back bootloader so if a system loses all boot entries, the shim will re-enroll and register them and boot normally. MS requirements for key management ---------------------------------- See MSFT recently modified their signing policies. You need an EV cert to sign into their service, this costs more money because someone actually has to verify your ID. This isn't bad for debian, but for an end-user this is expensive. There is also a model where the vendor cert is embedded in a new place in the executable. Even if you receive a binary from debian, you can still verify the executables are identical. This will allow MSFT to verify the binary is the same, with only the certificate changed. Private half of keys must be stored in FIPS compliant hardware token. Ubuntu does a key sharding process, required some kind of approval from Microsoft State of debian's code ---------------------- grub has many patches from redhat/mjg causing it to operate in a secure boot way. When grub core is signed it refuses to load any modules that are unsigned. Secure boot core images are larger as a result. That code is in debian, some of it is configured off by default, but that is trivial to change. There is code to build custom uploads. todo: enable the grub code for secureboot Discussion after last year's discussion: http://thread.gmane.org/gmane.linux.debian.devel.boot/143954 Updated to-do list from that thread: TODO: setup a meeting with FSF about hardware UEFI secure boot in debian is being done in the right way and merging grub changes upstream 0. Need a debian key to get into MokManager Need an RSA 2048 key The process: we generate the key and the self-signed certificate of the correct form, which is embedded in the shim package that is then submitted to Microsoft. The signing request requires obtaining an EV code-signing cert, and then this has to be uploaded via Windows to Microsoft. 0. colin will provide the procedure to do this in ubuntu 1. tollef: DSA generates key and obtains EV cert for submission to MS 2. tollef: DSA generates key and self-signed cert for shim 3. vorlon includes the public key and cert from step 2 in the shim package, uploads this to debian and gets through binary NEW. 4. tollef: Whoever controls the EV cert extracts the shim binary, puts it into a cab, signs that with the EV cert 5. Some poor soul sacrifices their remaining dignity and runs windows to upload this tollef says we need a HSM for this... it would be on a different host than ftp-master itself, so we'd need to make this work. TODO: tollef will see if we have a HSM, or get one - maybe YubiHSM, or a smartcard TODO: tollef will talk with DSA about how best to set this up so it can be detached from ftp-master GOAL date for this: 28th of september 1. Colin Watson will prepare dak changes to support upload and subsequent signing of EFI executables. (This is an embedded, not detached, signature.) Colin has dak changes to support this, but could use assistance to test this in some environment. TODO: lfaraone will work with colin to work with him to test this. Prefer that this run unattended or mostly so, so all grub uploads don't have to go through NEW. Maybe make some basic whitelisting or depend on a key or something so that it isn't uploadable by any debian developer. In Ubuntu it requires a button push sign-off, and it is manually checked that it was signed by the right key. TODO: lfaraone will speak with the FTP team and look at getting the above to work 2. Steve Langasek will prepare and upload a package of the 'shim' EFI boot loader. This will embed our own set of public keys (corresponding to those used by dak) and can load any other EFI executable signed by one of them. Later, there will be a shim-signed package containing the same executable with a Microsoft signature. (This costs money and takes several days, but shim should require only very infrequent changes.) Need MokManager support in the shim (in order to allow user to enable/disable kernel signature verification). Ubuntu has packaging that has mokmanager, though it has not yet passed through Microsoft review and is therefore not currently live in any Ubuntu release. TODO: vorlon will maintain this in debian, but is going to wait on this until we have a key 3. Colin Watson will update the GRUB package to build a to-be-signed monolithic EFI executable separate from the package. Then he will add a grub-signed package that includes the Debian-signed executable from the archive. This executable would be suitable for use on both removable media and the installed system. 4. The kernel team will need to upload kernel images for signing and add linux-image-signed packages with the Debian-signed kernel images. Locking down things in the kernel: you need to be able to distinguish between root and the kernel in a secure boot environment. In the past root could modify kernel... secure boot prevents that, so there is an incentive to lock down the kernel so root cannot do that in various ways. There would be an external patch set that would do this that debian would have to carry until upstream Linux will do their reimplementation. Are we going to turn on this patchset by default when secureboot is enabled? This detail is not blocking us moving forwards and can be worked out.