UEFI Secure Boot Impact on Linux

October 28, 2011.

Jeremy Kerr !ec"nica# $rc"itect %anonica# &att"e' (arrett Senior So)t'are En*ineer +e, -at Jame. Bottom#ey / Kerne# 0e1e#oper

1. Summary
Secure boot technology is now part of the new UEFI firmware specification. Given that Microsoft s in!ows " will re#uire secure boot to be enable! by !efault$ it is e%pecte! that the ma&ority of personal computer !evices will ship with it enable! in the first #uarter of '()'. *he UEFI specification for secure boot !oes not !efine who controls the boot restrictions on UEFI platforms$ leaving the platform implementer in control of the e%act security mo!el. Unfortunately$ Microsofts recommen!e! implementation of secure boot removes control of the system from the har!ware owner$ an! may prevent open source operating systems from functioning. *he in!ows " re#uirement for secure boot will pressure +EMs to implement secure boot in this fashion. e believe that restrictions that prevent users from e%ercising full control over their har!ware is not in the best interest of those users$ an! wor,s against the spirit of open source software in general. *herefore$ we present a set of recommen!ations that will allow users the free!om to choose their software$ while retaining the security features of UEFI Secure -oot$ an! complying with open source licenses use! in !istributions of .inu% .

2. !ec"no#o*y 0e.cription
UEFI secure boot is a technology integrate! into the latest version /v'.0.)1 of the UEFI specification$ implementing part of a 2verifie! software stac,3. 4 verifie! software stac, authenticates that the critical parts of software running on a particular !evice are authorise! an! have not been tampere! with in any way. *his is achieve! by implementing public ,ey cryptography to verify that various signatures are vali! when loa!ing each successive layer in the operating system boot process. Secure boot functionality is concerne! with several stages of this process5 vali!ation of system firmware$ !rivers$ an! of software loa!e! by the built6in firmware. *ypically$ this software is the 2bootloa!er3$ which is responsible for loa!ing the operating system image. ith secure boot enable!$ public ,eys in the UEFI firmware are use! to vali!ate the bootloa!er rea! from !is,. *his ensures that the bootloa!er image has been authorise! to run on this platform. In or!er to provi!e protection for the full software stac,$ the bootloa!er woul! typically be responsible for vali!ating the signature of the operating system7s ,ernel$ which in turn vali!ates the signatures of other software. If any of these components are replace! or altere! an! signature verification fails$ the system will be prevente! from booting. For e%ample$ if the bootloa!er signature !oes not match what the UEFI firmware is e%pecting$ the system will not boot.

2.1. Imp#ementation an, p#at)orm contro#

*he UEFI specification states that secure boot functionality is optional$ but it is e%pecte! that +EMs will be influence! by proprietary operating system ven!ors to implement it. Specifically$ the in!ows " logo program will re#uire secure boot to be enable!). In theory$ the wi!e !eployment of secure boot will be a goo! step towar!s increasing the security of general6purpose computing platforms. -ecause the UEFI specification !oes not !efine the e%act security mo!el to be implemente!$ there is some fle%ibility in how har!ware ven!ors /typically$ +EMs1 will configure secure boot on their systems. In particular$ the UEFI secure boot specification !oes not !efine who will be the custo!ians of the public ,eys that will be embe!!e! in the UEFI firmware. 8owever$ the in!ows " re#uirements attempt to !efine some of these implementation !etails$ in a way that restricts users free!oms. In particular$ that the 2root3 of the authentication system /calle! the 9latform :ey$ or 9: in the UEFI specification1 will be controlle! by the +EM '. Essentially$ the owner of the 9: has ultimate control of the security restrictions on secure6boot enable! har!ware. If the user !oes not control the 9:$ then the user may not be able to fully configure secure boot to their re#uirements.

2.2. &ar2et pre..ure

ith system security being a growing concern$ an authenticate! boot path may become a re#uirement of certain compliance stan!ar!s$ such as 9;I$ Sarbanes6+%ley$ FI9S$ or 8I994. Enterprise customers coul! ma,e secure boot capability a re#uirement of their purchasing process$ following recommen!ations from their software ven!ors.

2.3. Key re1ocation

9art of the UEFI specification$ an! a man!atory part of any public ,ey cryptography system$ is a ,ey revocation process. *his allows ,nown compromise! ,eys to be a!!e! to a blac,list of ,eys that can no longer be use! to verify boot images. If a ,ey is a!!e! to this blac,list$ images that rely on that ,ey will no longer wor,. *his is ,nown in the UEFI specification as the 2forbi!!en signatures !atabase3$ an! is mo!ifiable !uring e%ecution by authenticate! software.

2.4. Fu## .tac2 .upport

For the secure boot concept to be effective$ it shoul! be a part of a 2full6stac,3 security system$ where each layer of software<from the system firmware to /at least1 all components of the operating system ,ernel<is verifie! before e%ecution. =epen!ing on the technical implementation$ a signe! bootloa!er may also have to verify signatures on .inu% ,ernel images that it loa!s. Failure to !o so woul! permit the signe! bootloa!er to e%ecute
From http5>>vi!eo.ch?.ms>buil!>'())>sli!es>8 6@AB*CvanC!erC8oeven.ppt%$ sli!es )) an! )B. 2*he platform is secure! through a platform ,ey that the +EM installs in firmware !uring manufacturing3 6 http5>>blogs.ms!n.com>b>b">archive>'())>(?>''>protecting6the6pre6os6environment6with6uefi.asp%
) '

arbitrary unsigne! co!e$ possibly circumventing secure boot technology. If such a non6verifying bootloa!er were signe! an! !istribute!$ malware coul! simply replace the verifying bootloa!er with the non6verifying one$ an! use it to loa! a compromise! operating system. In effect$ this non6 verifying bootloa!er becomes the tool to compromise secure boot$ an! the ,ey use! to sign it woul! li,ely be a!!e! to systems forbi!!en signatures !atabase$ either before shipping or at runtime by system software. *he way to ma,e the .inu% bootloa!er a part of the secure boot process is to alter it to vali!ate the signature of the software that it loa!s /typically the .inu% ,ernel1$ an! refuse to e%ecute software that !oes not pass this vali!ation.

3. Bene)it.
Secure boot technology presents some beneficial features to both free software an! proprietary operating systems. hen use! in appropriate situations$ it coul! be useful for .inu% users.

3.1. &a#'are pre1ention

+ne of the main benefits of secure boot technology is that it can greatly re!uce the number of malware 2root,its3. In the case that malware mo!ifies critical operating system components$ on system restart the boot process is interrupte! with signature verification errors an! the en! user is imme!iately aware that the system has been compromise!. System recovery software coul! then simply replace any unsigne! components.

3.2. Loca# .ecurity po#icy

Un!er certain circumstances local security policy may !ictate that only authorise! operating systems be boote!. Secure boot allows I* !epartments to limit the set of authorise! ,eys in or!er to ai! enforcement of such a policy.

3.3. 5ercei1e, bene)it. )or proprietary .o)t'are

4lthough there are some en!6user benefits of secure boot$ there are some conse#uences that may benefit proprietary software ven!ors$ rather than the user. hile we cannot specifically !etermine these benefits$ we perceive that the following items may be attractive to proprietary software ven!ors.

3.3.1. -ar,'are6.o)t'are inte*ration

;ontrolling the boot environment may ma,e it possible for software to be reliably tie! to a specific piece of har!ware. *his creates the opportunity for a 2force! obsolescence3 scenario$ where har!ware upgra!es are necessary to install future versions of system software$ or vice versa.

3.3.2. +ecurrin* re1enue a..urance

If secure boot is use! to verify all parts of the operating system$ inclu!ing application binaries$ the ,ey owner is in a position to enforce that applications can only be installe! from an approve! 24pp

Store3$ thus ensuring recurring revenue from all en! user purchases. In this situation$ it woul! be technically infeasible to install applications procure! via an alternate source.

4. 0i.a,1anta*e.
4lthough secure boot is mar,ete! as being beneficial to en! users$ it has many !isa!vantages that are not being communicate! clearly$ if at all. In particular$ the currently6recommen!e! implementation of secure boot$ where the machine owner !oes not control the 9:$ may present the following issues.

4.1. %"oice o) "ar,'are

Secure boot re#uires all components that run in the conte%t of the system firmware to be signe!. *his inclu!es not only the bootloa!er$ but also any firmware6level har!ware !rivers. For all6in6one systems such as laptops this coul! be achieve! by all !rivers being signe! with the +EMs ,ey. 8owever$ for systems where components may be replace! after purchase$ the problem is less tractable. If the component ven!ors signs their own !rivers$ then they must ensure that their ,ey is installe! on all har!ware they wish to support. *his approach woul! prevent new har!ware ven!ors from entering the mar,et until they ha! !istribute! their ,ey to a range of +EMs$ an! has a large per6platform overhea!. Even then$ if no mechanism is provi!e! to install their ,ey into ol!er systems$ only new har!ware will support their components. 4n alternative is for ven!ors to have their !rivers signe! with a ,ey that is inclu!e! in the ma&ority /if not all1 of shippe! platforms. *his approach avoi!s the per6platform overhea! issues$ but means that the har!ware ven!or is now behol!en to the owner of sai! ,ey to provi!e a signature. *his woul! be li,ely to a!! a!!itional cost an! !elays to the process of releasing new har!ware or !rivers. *he most scalable approach woul! be for ven!ors to obtain a ,ey with a chain of trust bac, to a ,ey present in all shippe! platforms. *his a!!s relatively little overhea!$ but re#uires that the ven!or7s ,ey be present in or!er for secure boot vali!ation to operate. If the ,ey use! for the root of trust is also use! to sign operating systems$ this ma,es it impractical for en! users or organisations to remove that ,ey if they !o not wish their har!ware to run those operating systems.

4.2. %"oice o) operatin* .y.tem

4 system shippe! with secure boot enable! by !efault will only boot signe! operating systems. Since there is no centralise! UEFI signing authority$ it is therefore necessary for each +S ven!or to either ensure that the public half of their signing ,ey is inclu!e! in the system firmware$ or for the +EM to provi!e a mechanism for the en!6user to install new signing ,eys. Microsoft have assure! the community that +EMs will be able to !eci!e the level of restrictions on boot images$ within the constraints of the in!ows " re#uirements. hile +EMs may !eci!e to allow secure boot to be !isable!$ this still presents a significant barrier to installing .inu% on machines that have shippe! with in!ows "$ as it is only possible by manually switching an option

in the system firmware. De#uiring users to reconfigure their system firmware in or!er to use an alternative to in!ows will un!oubte!ly re!uce the feasibility of these alternatives. 9rovi!ing a mechanism for en!6user installe! ,eys is problematic. In or!er to prevent pre6operating6 system malware$ it must be impossible for the malware to install new signing ,eys. 4ny solution for en!6user installation of ,eys must guar! against programmatic installation by malware. If no mechanism is provi!e! for the en!6user to install ,eys$ every operating system ven!or faces the same pre!icament as !escribe! in section @.). 9rovi!ing one ,ey per operating system results in scalability issues$ with each platform re#uiring the ,ey to be preinstalle!. Signing all operating systems with a single thir!6party ,ey a!!s significant cost an! !elays to entering the mar,et.

4.3. U.abi#ity o) a#ternate operatin* .y.tem.

If secure boot must be !isable! before an alternate operating system can be boote!$ then those alternatives will become restricte! to technically6min!e! users who are able to reconfigure their firmware to !isable secure boot. .i,ewise$ !ual6boot configurations will become !ifficult to manage$ as users must enable an! !isable secure boot when switching between signe! an! unsigne! boot images.

4.4. Operatin* .y.tem up,ate.

Each component of the operating system involve! in the firmware boot process must be signe!. *his ma,es it impossible for these components to be !ynamically generate! on the en!6user har!ware. Instea!$ static images must be generate! an! signe! before being provi!e! to the en!6user. *his is incompatible with the current GDU- ' !esign$ which generates a system6specific boot loa!er image at install time.

4.7. %on.e8uence. o) 2ey compromi.e

In the event of the private half of a truste! signing ,ey being !isclose!$ it may be use! to sign malware which will then successfully vali!ate$ !espite secure boot restrictions. 4voi!ing this re#uires that the signing ,ey be revo,e! an! blac,liste!$ which will also cause any other co!e signe! with the ,ey to cease vali!ation. If the ,ey belongs to an operating system ven!or then this will prevent the operating system from booting$ while if it belongs to a har!ware ven!or then that ven!or7s firmware6level !rivers will no longer vali!ate an! the component will no longer function in the firmware environment. In the worst case scenario$ ,ey revocation may ren!er some machines unbootable.

4.9. In)ra.tructure re8uirement.

Implementing a secure boot system re#uires a non6trivial amount of supporting infrastructure an! maintenance effort. *his inclu!es overhea!s for maintaining a secret ,ey$ authorising the ,ey$ an! signing boot images.

Decent compromises to well6,nown browser certificate authorities) show that there are significant conse#uences if this effort is not con!ucte! in a secure /an! therefore potentially costly1 manner. For smaller .inu% !istributions$ supporting secure boot may not be feasible !ue to these overhea!s.

4.:. Security 1u#nerabi#ity ,i.c#o.ure

Usually$ a proportion of security6conscious users will wor, alongsi!e software ven!ors to assist in the reporting an! responsible !isclosure of security vulnerabilities of a software pro!uct. 8owever$ the enforcement of e%ternally6controlle! secure boot restrictions may !ecrease the li,elihoo! of these vulnerabilities being reporte! to software ven!ors. If the only metho! of running unauthorise! or customise! software on a har!ware !evice is to e%ploit a vulnerability$ then these vulnerabilities become valuable to allow users to run mo!ifie! software on their systems. Instea! of reporting security issues$ researchers wor,ing on restricte! systems may choose not to !isclose flaws$ but instea! use them to circumvent secure boot restrictions. In this case$ the software ven!or may only be in!irectly notifie! by these vulnerabilities$ one at a time. E%amples inclu!e attac,s on 4pples i+S har!ware$ an! Sonys 9laystationE 0.

7. Imp#ementation )actor.
4s secure boot has not yet been implemente! 2in the wil!3$ there are a number of factors that will change the impact of secure boot on .inu%.

7.1. Factory ,e)au#t con)i*uration

*he !efault secure boot configuration of systems will !etermine whether or not they can be use! 2out of the bo%3 for booting .inu%$ or other non6signe! operating system images. e !o not currently have an estimate of the proportion of systems that will ship with secure boot restrictions enforce! by !efault.

7.2. $bi#ity to ,i.ab#e .ecure boot

*he ability to !isable secure boot restrictions is vital to ensure .inu%s continue! ability to run on a wi!e range of platforms. If users cannot !isable secure boot$ then fewer platforms will be able to run open source operating systems. 4!!itionally$ open source software !evelopers will no longer be able to buil! an! test mo!ifie! /an! therefore not signe!1 software on these restricte! platforms. If the process re#uire! to !isable secure boot is !ifficult for non6technical users$ then we ris, restricting use of unsigne! software to a small portion of the mar,et. ;urrently it is up to each +EM as to whether or not to create a user interface to enable or !isable secure boot.

=igiFotar$ a well6,nown ;4$ ha! its ,eys compromise! an! use! to sign forge! SS. certificates5 http5>>www.theregister.co.u,>'())>(?>(G>!iginotarCau!itC!amningCfail>
)

7.3. $bi#ity to recon)i*ure 2ey.

Some .inu% users may wish to use secure boot functionality with custom images. In this case$ they will never be using the +EM6!efine! ,eys. *he UEFI specification !efines a 2setup mo!e3 where ,eys can be configure!. For this use case$ users will nee! to be able to reconfigure the platforms firmware to inclu!e their own ,eys$ which will re#uire an interface to !o so. 8owever$ since this will be a relatively infre#uently6use! feature$ it !oes not seem li,ely that -I+S ven!ors will implement it for general6 purpose usage.

7.4. Key re1ocation po#icy

*he UEFI specification !oes not !efine criteria for a!!ing a ,ey to the forbi!!en signatures !atabase$ so it is left to the platform manufacturer to !eci!e which ,eys are initially inclu!e!$ an! the operating system ven!or to !eci!e which ,eys may be a!!e! after purchase. Generally$ it ma,es sense when managing the forbi!!en signature !atabase to a!! ,nown6 compromise! ,eys to it$ but !ifferent organisations may have !ifferent stan!ar!s for a 2compromise! ,ey3. It is also possible$ although unli,ely$ that some organisations may a!! competitors ,eys to the systems forbi!!en signatures !atabase$ even though the ,eys have not been compromise!. *his woul! prevent competitors software from running on some systems.

7.7. $utomate, ,ep#oyment

9erforming automate! installations of operating systems to a large number of machines may be !ifficult in the event of customers wishing to use their own signing ,ey. *he !ifficulty of automatically installing new signing ,eys without provi!ing the opportunity for malware to use the same mechanism leaves this an open #uestion. It is un!esirable for I* !epartments to have to perform manual ,ey installation.

9. +ecommen,ation.
Secure boot technology can be beneficial for increasing the security of .inu% installations. .inu% !istributions shoul! gain secure boot compatibility in or!er to increase protection against malware an! !is, encryption circumvention$ provi!e! that users free!oms are protecte!. Unfortunately$ the current implementation recommen!e! for secure boot ma,es installation of .inu% more !ifficult an! may prevent users from mo!ifying their own systems. So$ we recommen! that secure boot implementations are !esigne! aroun! the hardware owner having full control of the security restrictions. ;e recommen, t"at a## OE&. a##o' .ecure boot to be ea.i#y ,i.ab#e, an, enab#e, t"rou*" a )irm'are con)i*uration inter)ace

It is essential that users are able to remove secure boot restrictions$ an! boot the software of their choice on the !evices that they own. Furthermore$ the interface to configure this option shoul! be easily accessible by non6technical users. +f course$ this option shoul! only be available to users with physical access to the har!ware$ an! not be accessible via programmatic means. ;e recommen, t"at OE&. <'it" a..i.tance )rom BIOS 1en,or.= pro1i,e a .tan,ar,i.e, mec"ani.m )or con)i*urin* 2ey. in .y.tem )irm'are For secure boot to be useful in a user6controlle! environment$ it must be possible for users to a!! custom ,eys /:E:$ !b an! !b% entries1 to the system firmware. :eys may then be shippe! with an operating system or generate! by the user. *his allows the user to maintain control of the co!e run on their systems without giving up the benefits of secure boot. For support purposes$ the mechanism provi!e! for ,ey management must be consistent across platforms$ an! provi!e a simple metho! of booting custom software$ inclu!ing from removable me!ia. 4 suggeste! implementation may be to scan removable me!ia for signing ,eys an! prompt the user for their installation$ or using the specification6!efine! setup mo!e to allow ,ey reconfiguration. ;e recommen, t"at "ar,'are ."ip in .etup mo,e, 'it" t"e operatin* .y.tem ta2in* re.pon.ibi#ity )or initia# 2ey in.ta##ation Shipping har!ware in setup mo!e allows ,ey policy to be !etermine! by the operating system ven!or or en! user. 9re6installe! operating systems coul! then install their own signing ,eys on first boot. *his permits the user to avoi! the situation where pre6installe! signing ,eys !o not match the user7s !esire! security policy. For further information on secure boot an! .inu%$ contact the authors5 Heremy :err I &eremy.,errJcanonical.com Matthew Garrett I m&gJre!hat.com Hames -ottomley I &ames.bottomleyJhansenpartnership.com

Le*a# >otice.
;anonical an! its associate! logo is a registere! tra!emar, of ;anonical .t!. De! 8at an! its associate! logo is a registere! tra!emar, of De! 8at$ Inc. .inu% is a registere! tra!emar, of .inus *orval!s. 4ll other tra!emar,s are the properties of their respective owners. 4ny information referre! to in this !ocument may change without notice.