Mon-3-Mar, 11:15am, Ard Biesheuvel
LCA14-105: UEFI Secure Boot
• NOT: a way to lock down your TiVo
UEFI Secure Boot does not prevent the user
from manipulating the boot environment:
• ‘...
The primary purpose of UEFI Secure Boot is
to prevent exploits from gaining persistence
by corrupting the boot environment...
• Covered by UEFI Secure Boot authentication:
• the next boot stage (kernel, GRUB, etc)
• authenticated variable store (e....
Current status:
• proof of concept implementation available for
QEMU/Vexpress
• requires EFI stub patches that are not yet...
• device tree images (FDT)
• direct control over internal plumbing of the kernel => security hole
• trusted by the kernel,...
• Linaro will not act as a root CA for UEFI Secure Boot on
ARM systems
• single root CA == single point of failure!
• hard...
• Crypto routines for image verification are used in two
ways
• Verification of signed EFI applications (GRUB, kernel)
• V...
Proceed with prototype
• image authentication using runtime services, either
from GRUB or from the kernel (kexec)
• invest...
More about Linaro Connect: http://connect.linaro.org
More about Linaro: http://www.linaro.org/about/
More about Linaro eng...
Upcoming SlideShare
Loading in …5
×

LCA14: LCA14-105: UEFI secure boot

898 views

Published on

Resource: LCA14
Name: LCA14-105: UEFI secure boot
Date: 03-03-2014
Speaker: Ard Biesheuvel
Video: https://www.youtube.com/watch?v=09nb3Fiobw0

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
898
On SlideShare
0
From Embeds
0
Number of Embeds
97
Actions
Shares
0
Downloads
27
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

LCA14: LCA14-105: UEFI secure boot

  1. 1. Mon-3-Mar, 11:15am, Ard Biesheuvel LCA14-105: UEFI Secure Boot
  2. 2. • NOT: a way to lock down your TiVo UEFI Secure Boot does not prevent the user from manipulating the boot environment: • ‘BIOS’ menu or EFI shell may still be available • kernel command line can be persistently modified (by root) • NOT: a way to keep secrets on the target • if your kernel binary contains special sauce that you prefer to keep secret, you need something else UEFI Secure Boot, what it is not
  3. 3. The primary purpose of UEFI Secure Boot is to prevent exploits from gaining persistence by corrupting the boot environment This is accomplished by allowing only signed EFI applications to be executed: • EFI-stub kernel images • (n+1) stage bootloaders (GRUB) • option ROMs So what is UEFI Secure Boot?
  4. 4. • Covered by UEFI Secure Boot authentication: • the next boot stage (kernel, GRUB, etc) • authenticated variable store (e.g., updating the root certificate using UEFI runtime services) • NOT (currently) covered by UEFI Secure Boot • authentication of UEFI/Tianocore itself • (n+2) stage bootloader (i.e., GRUB verifying the kernel) • command line passed to next stage • FDT blob • initrd image • Kexec Scope of UEFI Secure Boot
  5. 5. Current status: • proof of concept implementation available for QEMU/Vexpress • requires EFI stub patches that are not yet upstream • requires an updated sbsigntool that allows signing of ARM and arm64 PE/COFF images (available in Linaro Overlay repository) • instructions can be found here: https://wiki.linaro. org/ardbiesheuvel/UefiSecureBootPrototype • Tianocore Authenticated Variable Store needs porting to TrustZone/Secure World • if the Secure World ‘owns’ the WRITE_ENABLE pin of the NOR flash, it should also perform the authentication of the signed variable updates itself UEFI Secure Boot on ARM
  6. 6. • device tree images (FDT) • direct control over internal plumbing of the kernel => security hole • trusted by the kernel, so it needs to be authenticated by the boot loader • implicit => e.g., part of UEFI binary itself • signed updates through TrustZone • reuse authenticated variable store? • allows standardised update mechanism through runtime services • kernel command line • updatable by root through efibootmgr (unauthenticated) • powerful controls over kernel internals • may need to be sanitized in the EFI stub or next stage bootloader • authentication through runtime services • GRUB and Kexec calling into UEFI Secure Boot protocol handler • what about initrd images?? UEFI Secure Boot on ARM
  7. 7. • Linaro will not act as a root CA for UEFI Secure Boot on ARM systems • single root CA == single point of failure! • hardware A running distro X and hardware B running distro Y have no purpose for a shared cert authority between them • No need for a shim on ARM systems • it is up to the vendors to decide whether to ship systems in Setup Mode or with some Platform Key pre-installed • no bully in our playground who imposes incompatible rules for everyone Certificate management
  8. 8. • Crypto routines for image verification are used in two ways • Verification of signed EFI applications (GRUB, kernel) • Verification of signed variable updates • Secure design calls for handling of the latter to reside completely in the secure world • Needs secure world interface to pass unchecked variable updates • Needs secure world interface to reuse secure world routines to authenticate EFI application • is needed to avoid duplication of authentication routines and variable access routines in both worlds TrustZone Secure World integration
  9. 9. Proceed with prototype • image authentication using runtime services, either from GRUB or from the kernel (kexec) • investigate how to handle initrd and command line • anything else? Next steps
  10. 10. More about Linaro Connect: http://connect.linaro.org More about Linaro: http://www.linaro.org/about/ More about Linaro engineering: http://www.linaro.org/engineering/ Linaro members: www.linaro.org/members

×