Debunking the top two myths about UEFI

Back in June, I distilled the nuances of the Unified Extensible Firmware Interface (UEFI) into small, bite sized portions.  I delineated the advantages the framework offers the community and made a cogent case for why we shouldn’t ignore it.

Since then, I’ve noticed that people have a few misconceptions about UEFI and these false notions often stymie their adoption of the framework.  You don’t have to look far to see users ranting in forums about how a feature called Secure Boot prevents PC owners from installing operating systems other than Windows 8.  Another myth people believe is that Secure Boot requires a TPM chip to work.

In this article I want to tackle these myths face on.  I think a lot of people are unwittingly exposing their systems to gratuitous harm because of ignorance – I can’t remain aloof while malware creators exploit our ignorance. That isn’t fair to you.

First, let me explain exactly what Secure Boot is then I’ll talk I expose two errant beliefs about the framework and I’ll wrap up with my closing opinion on the matter.

What exactly is this Secure Boot thing?

In order to understand Secure Boot you need to understand the idea of your computer’s pre-boot environment.

When you power-on a new PC a few things happen behind the scenes.  The electricity surges through insulated wires and shocks your CPU to life.  As the fan spins up, the machine goes through what’s known as a power-on self-test (POST) which comprises the system running through a checklist of hardware peripherals to initialize.  This process usually last a few seconds and completes a fraction of a second before the infamous Windows icon graces the screen.

In the past, consumers never had to worry about malicious hackers or hacking groups seeking to compromise the vulnerable gap where the firmware hands over control to the operating system. But now as Microsoft and other OS vendors have beefed up OS security the shell is harder and crunchy so script kiddies motivated by fame and money are seeking to compromise the soft gooey center of the computer known as the BIOS.  Also know as rootkits, these attacks surreptitiously compromises systems and since it attacks the firmware, they are often present even after reinstalling the OS or replacing the hard drive.

This is no joke.

The Basic Input Output System (BIOS) is the first software program run by a PC when it’s powered on.  It lives in firmware at the boundaries of your hardware and software.  It’s basically an embedded system and contains low level machine instructions for “kicking off the show”.  The BIOS get’s things started but has one major liability: it’s based off antiquated technology from the mid 70’s.

As you could imagine, old technology is not without its security risks and the BIOS is certainly no exception.  In fact, in July of 2009, the Invisible Things Lab demonstrated how to irrevocably re-flash Intel BIOSes with new code.  These attacks are especially sinister because they happen below the radar of antivirus programs.

Rafal Wojtczuk and Alexander Tereshkin of ITL published a slide deck for Blackhat that provided background on how BIOS reflashing worked and how these attacks are executed.  Ultimately, the best way to preclude these attacks is to write better code because Secure Boot doesn’t mitigate BIOS reflashing.

That being said, At the UEFI Winter Plugfest last year, Zachary Bobroff demonstrated Secure Flash Update is a viable solution to protecting the BIOS.  It uses digital signatures to authenticate the BIOS image and silicon features to stop unauthorized flash updates.

Both Secure Boot and Secure Flash Updating are similar but are actually two distinct things.  The first was designed to harden the handoff from firmware to software.  It protects the boot gap as hardware kicks of the operating system load, but it doesn’t stop any direct assaults on the firmware itself.  Secure boot ensures that operating system images are authenticated but it doesn’t provide any mechanisms for firmware protection.

The fact that the malicious hackers even see the BIOS as “the new frontier” for attack is, ipso facto, a major concern now.  The white papers by Bobroff, Wojtczuk, and Tereshkin serve as cogent evidence for a robost solution to pre-boot security.

Let’s talk a little more about Secure Boot:

Secure Boot throws a wrench in the maniacal machinations of basement dwelling geeks who have nothing better to do than concoct new ways to cripple computers.

Secure Boot wedges itself between firmware initiation and operating system load time to makes it harder for hackers to subvert your system.  You can get a detailed break down of Secure Boot starting on page 6 of 57 in the Intel Technology Journal whitepaper, but the bottom line is that Secure Boot only boots an OS that contains a digital signature known to the motherboard.

If that sounds like mumbo jumbo then you need to know a little about cryptography.

In cryptography you have a something called a public key and a private key.  The private key is known only to the author but the public key is freely available to everyone in the world.

The main thing to keep in mind here is that the private key must stay private.  If anyone discovers the private key then the whole cryptosystem breaks down.

So the creator of a digital document or program can sign his or her work with the private key.  Since, in the abstract, only the author has the private key, everyone can trust that the file did in fact come from the author.  The private key gives you confidence that the program is who it claims to be and not Mr. Evil Hacker.  The public key is used to authorize access to the digitally signed file — keep that in mind as we walk through the UEFI myths.

Myth 1:

UEFI is bad because it prevents me from installing other operating systems like Linux on my computer.

Okay first of all there is a ubiquitous message floating around the web that Linux lovers can’t install Linux on new Windows 8 machines because of Secure Boot.  This is false for two reasons:

  1. Secure Boot is optional so you can always disable it
  2. Linux users can selection distros that have bootloaders signed by Microsoft’s Certificate Authority (CA)

Users may take the liberty to disable Secure Boot at any time.  For example, on ASRock Motherboards in Windows 8, people can boot to the UEFI Firmware Settings and disable Secure Boot by clicking the Security menu and choosing disable.  And on most newer Acer computers, you can boot to BIOS, arrow over to the Authentication tab and disable Secure Boot from there.

Secondly, both Ubuntu, Fedora and even SUSE ship with signed Secure Boot support.  In addition, Linux developers can easily include the Secure boot bootloader in their OSs by renaming a signed shim, called shim.efi, to bootx64.efi and dropping it in the /EFI/BOOT/ folder of their install media.  There are a few other things Linux developers need to make this work but the bottom line is that Linux isn’t relegated to the sidelines with the arrival of Secure Boot.

Myth 2:

I need a Trusted Platform Module (TPM) to make Secure Boot work

TPM is really only tangentially related to UEFI’s Secure Boot.  Secure Boot is one strata of a robust pre-boot security plan and the TPM chip is just another layer that you can employ to safely store your credentials.

That being said, TPM is actually already implemented by several major computer vendors including the Lenovo, Dell and HP so you may already have the chip in your computer.

The point is that TPM can offer additional  security but it isn’t a prerequisite for Secure Boot to work.

The Bottom Line

UEFI is poised to supplant the legacy BIOS.  This easily becomes good news when you understand how Secure Boot works and what it was designed to do.

What do you think about Secure Boot?  Let me know in the comments.


Connect with Vonnie on Twitter

Posted in Desktops, Hardware, Laptops, Smartphones, Tablets
  • Eoin Ryan

    I’m not an expert on this at all; but if “Linux developers can easily include the Secure boot bootloader in their OSs by renaming a signed shim”, what’s to stop malware writers doing the same thing to bypass Secure Boot?

    • Tadd Seiff

      Nothing is stopping them, but using the shim isn’t bypassing the secure boot. After the shim is done, the boot is over. And since the shim is signed, we know there is no malicious code in the boot process (the shim code). What is launched by the shim, though, could be anything, but it’s no longer in the boot process, so secure boot has done its job. At least, this is how I understand it.

  • Neel Gupta

    You can’t disable “Secure Boot” in Windows RT devices.

    • Tadd Seiff

      Correct. To sell WINDOWS 10 with a sticker from Microsoft, the PC manufacture MUST LOCK OUT THE USER from disabling secure boot.

  • Jeremy Wilkins

    It still causes trouble for Linux software raid 1 on the boot disks. I am having a seriously rough time getting this configuration to work anymore and I can’t easily put those drives in a new computer without a EFI boot disk if that motherboard fails. Bad design IMHO.

  • Writer forgot to mention that only *certain* flavors of Linux distros will work on the steaming pile known as UEFI. i.e. only those distros with sufficiently deep pockets to pay the extortion fees to MS for the magical, wonderful UEFI to permit an OS other than Windoze to load.

    The writer of this piece can dress up the propaganda in whatever manner he imagines will be palatable up to and including wrapping UEFI in “security” clothing but in the final analysis, all it amounts to is the consumer having to ask permission and then pay the vig to install on his property what he should have been able to by default.

    UEFI is just another layer of Microsoft propaganda marketed as security and swallowed by little brains who do what MS tells them to.