Please add notes and discussion here Sunday, 2019-07-21, 13:30 Secure boot: way of ensuring that running OS (and other binaries) were not tampered with Chain of signatures: BIOS, kernel, modules, programs Based on public key crypto Way of preventing boot time malware; otherwise they start before OS Included in most modern x86 Can be disabled Linux Shim - simple (really simple, tiny) first-stage boot loader Is audited, well understood, etc. Collaborative, across many distributions Signed by Microsoft Microsoft is CA (and because of obvious reasons their key is present on all hardware) It then verifies and starts GRUB So shim is signed by Microsoft, and then contains many keys - from distributions Microsoft does not want to sign GRUB Too complex, and GPLv3 - Microsoft does not like it But as long as Microsoft signes shim, we're OK Distributions sign GRUB, kernel, firmware, modules, etc. Restrictions No unsigned kernels Ubuntu was allowing to run unsigned kernels, but resigned from it No non-free modules You need to sign them, and then add machine-only (your!) key to chain of trust No hibernation (why?) All state of system is put into hibernation file But how to ensure that this was not tampered while off Might be solved in the future, not yet IT IS SUPPORTED IN DEBIAN! Everything is deployed (sincethis year) so everything works amd64, arm64, i386 Packages using Recommends so be carefull during installation of packages when --no-install-recommends arm64 - no one CA, Microsoft is starging it. Not all hardware has those keys Should work invisibly debian-installer. Live media Installed systems Cloud images Packages with variants -signed and -unsigned Not always in the name, e.g. kernel is just signed -signed-template source packages 2 buildd phases: source => build binary => sign => *-signed binary Need for reproducibility Signing service Locked down, keys in HSM, managed by FTP team (not sure here) see for more details: https://wiki.debian.org/SecureBoot/Discussion It took long time Required cross-team collaboration Kernel, EFI, FTP, DSA, buildd. We (Debian) work great when people can work independently. But here people (and teams) were waiting at each other And there were conflicting proposals, required many rounds of dicsussions Big progress during sprint, Spring 2018 in DE Tooling is still rough Security-related software, not many people use it and understand it well We have (and use) more firmware features so we discover more bugs Now it's enabled in Debian, so more people use it and discover more bugs Now, with secure boot, it's much easier (and safer) to install Debian We don't need to disable secure boot in BIOS User freedom! ============= Ability to disable default keys, and put own Hard work of team (and other Debian teams) Patches are welcomed, especially for different architectures It's hard to test booting without access to hardware Current setup allows for more algorithms, signing variants, etc. Need for more people and feedback from people who have troubles or new ideas Some proposals from audience, but posing some risks Need more discussions We're free software, we can allow for changing - but users need to be aware of security trade-offs More lockdown of kernel and modules - but might pose some problems Many different BIOS: UEFI, uBoot, CoreBoot ATF - arm trusted firmware Small devices don't have full bios We want to still ensure security there Vendors can build own boot systems, embedd own keys Who can modify what? Also hardware limitations: which part of software, at which boot step, can modify which part of system (restricting memory, etc.) Discussion how to compile own kernel Build own kernel, add your own keys But how to add own key to shim? Might require separate chain of keys Debian has signing service: needed to avoid need for manual signing (and giving access for to many people for signing) When on own machine, manual signing might be OK