[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: UEFI Secure Boot - the plan for stretch



This should all be tracked in the BTS, so I started work on that (as
you've probably seen).

There is a tracking bug, #820036, which depends on all the others.

On Fri, 2016-04-01 at 14:35 +0100, Steve McIntyre wrote:
[...]
> 1. Generate a key and an EV code-signing cert, submit to Microsoft
> ==================================================================
> 
> This needs 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.
> 
> Tollef was organising an HSM (Yubikey $thing) to make this more
> secure. Exact details on key management are yet TBD - we had
> discussions about an N-of-M keyholder scheme similar-ish to what
> Ubuntu do.

Does this require a bug report?

> Steve Langasek to include the public key and cert in a shim package
> for Debian, upload it and get it in the archive.
>
> Whoever controls the EV cert extracts the shim binary, puts it into a
> cab, signs that with the EV cert and uploads the result.
>
> 2. dak changes to support upload and signing of EFI executables
> ===============================================================
> 
> Colin pointed at the code in launchpad as inspiration:
> 
>   https://git.launchpad.net/launchpad/tree/lib/lp/archivepublisher/uefi.py
>   https://git.launchpad.net/launchpad/tree/lib/lp/archivepublisher/tests/test_uefi.py
> 
> and gave us a WIP dak patch. Luke (was?) volunteered to investigate
> the dak work.

Needs a bug report against dak and/or ftp.debian.org.

> 3. 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 additional 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.)
> 
> Steve Langasek said he was happy to do this once we've got the rest of
> the process started and we have a certificate ready to embed.

Opened #820052.

> 4. Updates for other core packages to add signed versions
> =========================================================
> 
> Once we have our key ready and dak support added, we'll be able to
> upload things and get them signed automatically to create $foo-signed
> packages. Expected packages here:
> 
>  * grub2

Opened #820050.

>  * linux

Opened #820006 (ITP) and #820008 (changes to linux).

>  * fwupdate

Someone who understands this should open an ITP or RFP.

>  * ???

It seems we will have to distribute detached module signatures to
maintain reproducibility and avoid duplication, so kmod, initramfs-
tools and dracut all need to handle those.  I've written the patches
for kmod (#820010) and initramfs-tools (#820037), and it should be easy
to support them in dracut (#820041).

> 5. Minor tweaks to other places to make use of the signed packages
> ==================================================================
> 
>  * d-i

Opened #820038 against kernel-wedge, but more changes are needed in the
debian-installer build scripts.

>  * debian-cd
>  * debian-live
[...]

Please open bug reports against these.

Ben.

-- 
Ben Hutchings
No political challenge can be met by shopping. - George Monbiot

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: