Assignment Title: Paper #1
Forensic Analysis of UEFI

by
Pui Yee (Pearl) Pang
Pearl.pang.py@gmail.com

By submitting this assignment I acknowledge that I have read and agree to abide by the Champlain College Academic Honesty Policy. I declare that all work within this assignment is my own or appropriately attributed. I accept that failure to follow the academic honesty policy may result in a failure grade, or expulsion from Champlain College.

Date Due: _11/4/2015___
Date Submitted:_11/4/2015__
Abstract
The Unified Extensible Firmware Interface (UEFI) Specification is an interface between the operating system (OS) and the platform firmware and is managed through the UEFI forum, a collection of chipset, hardware, system, firmware, and operating system vendors. One of many benefits of using UEFI is that it provides a more secure environment during the boot process by adding several security mechanisms such as secure boot, and update. With the added secure boot feature, the correct bootloader certification is needed and database key authentication is also required before the booting process. As a result, rootkit or other malware program have a hard time hijacking the boot process and concealing itself from the operating system. This paper will focus on the analysis of UEFI's secure boot feature and its implications and challenges for digital investigators conducting computer forensic investigation. Keywords: UEFI secure boot, boot firmware, malware, rootkit.

Introduction To meet the demands of and preference for faster and more powerful computer most users want, hard disk drive manufacturers produce disks in excess of 2 TB. Moreover, most personal computers using the legacy Basic Input / Output System (BIOS) with master boot record (MBR) only allows a maximum disk size of approximately 2.2 TB and a maximum of four primary partitions to be run (UEFI Forum, 2010). The introduction of Unified Extensible Firmware Interface (UEFI), solves the existing booting and partitioning limitations in the legacy BIOS. The 64-bit UEFI firmware allows applications in the pre-boot execution environment to use 64-bit addressing to obtain direct access to all of the machine’s memory (Simpson, 2014). UEFI also works with a new partitioning scheme called Globally Unique Identification (GUID) Partition Tables (GPT), a more flexible partitioning scheme allowing more and larger partitions instead of just four primary partitions per disk up to 2 TB in BIOS (UEFI Forum, 2010; Smith, 2012). UEFI's main role in the boot process includes 1) Execute small core block of firmware that executes first and is capable of verifying the integrity of other firmware components. 2) Initialize and test low-level hardware. 3) Load and execute additional firmware modules. 4) Select boot device, call bootloader and pass control to OS kernel. 5) Develop extensions drivers and applications (Bashun, Sergeev, Minchenkov & Yakovlev, 2013). The interface defined by the EFI specification includes data tables that contain platform information, and boot and runtime services that are available to the OS loader and the Operating System (OS). UEFI firmware provides several technical advantages over a traditional BIOS, such as flexible pre-OS environment, boot and runtime services, CPU-independent architecture, and CPU-independent drivers which include powerful security mechanisms, such as secure boot, and update, etc. (Microsoft, 2009).
Secure boot service feature analysis The secure boot defines how platform firmware manages security certificates, validation of firmware, and a definition of the interface/protocol between firmware and the operating system (Microsoft). This protocol is intended to provide access for generic authentication information associated with specific device paths by preventing the loading of drivers or OS loaders that are not signed with an acceptable digital signature. The authentication information is configurable using the defined interfaces. Successive configuration of the authentication information will overwrite the previously configured information. Once overwritten, the previous authentication information will not be retrievable (UEFI Forum, 2015).
Recent modification The first version of UEFI 2.0 was released on January 31, 2006. Version 2.1 of the UEFI specification was released on January 23, 2007. It added cryptography, network authentication and the User Interface Architecture (Human Interface Infrastructure in UEFI). The secure boot feature was not added until the UEFI version 2.2 was released on November 2, 2010. The UEFI technology is keep updating and the most current UEFI version 2.5 was released on April 2015.

Application to OS
The traditional BIOS will boot any software. Normally, BIOS boots from the boot loader. The BIOS does not know the difference between malware and a trusted bootloader, so BIOS will allow either the malware or bootloader to boot. As a result, it is easy and convenient for malware, such as a rootkit, to replace the bootloader. The rootkit could load the normal operating system with no indication that anything was wrong, staying completely invisible and undetectable to the OS. Rootkit detection is difficult because a rootkit may be able to subvert the software that is intended to find it. Detection methods include using an alternative and trusted operating system, behavioral-based methods, signature scanning, difference scanning, and memory dump analysis. Removal can be complicated or practically impossible, especially in cases where the rootkit resides in the kernel (UEFI Forum, 2015). Secure boot is a feature of UEFI 2.2 requiring the operating system that is attempting to load to have a valid certificate (UEFI Forum, 2010). The secure boot feature is to sign executables using a public key cryptography scheme, called Trusted Platform Module (TPM). The public part of a Platform Key (PK) can be stored in the firmware for use as a root key. Additional Key Exchange Keys (KEK) can also have their public portion stored in the firmware called the signature database (db). That database contains public keys that can be used to verify different components that might be used by UEFI as well as bootloaders, and operating systems that get loaded from external sources, such as a USB drive or network. The signature database is meant to contain the current list of authorized and forbidden keys as determined by the UEFI organization (Edge, 2011). When secure boot is enabled, it is initially placed in "setup" mode, which allows a PK to be written to the firmware. Once the key is written, secure boot enters "User" mode, where only drivers and loaders signed with the PK can be loaded by the firmware. Additional KEK can be added to a database stored in memory to allow other certificates to be used, but they must still have a connection to the private portion of the PK secure boot. Ultimately, the PK is required to authenticate the ownership during the booting stage, while KEK are required to authenticate other components, such as OS (Edge, 2011). Unlike BIOS, UEFI will check the bootloader certificates before launching it and to ensure it is signed properly. If a rootkit or another malware program does replace the bootloader, UEFI won’t allow it to boot. UEFI prevents malware from hijacking the boot process and concealing itself from the operating system (UEFI Forum, 2015).
Relevant forensic implications Computer forensic examiners are told to image a subject's computer by pulling the plug, and removing the hard drive, or conducting a live imaging at the crime scene. Currently, one option for acquiring an image of a computer drive includes booting the subject machine into a controlled boot environment using software such as Raptor, or Windows FE (SWGDE). However, UEFI implementation creates one or more challenges to the forensic imaging and analysis process for digital examiners because of the following reasons (SWGDE):
1) UEFI restrict booting from media not native to the subject machine, thereby preventing the use of forensic boot environments.
2) Full disk encryption in conjunction with a TPM, which binds the hard drive to the computer in which it is installed. If UEFI boot restrictions limit the digital forensic examiner to conducting live acquisition, the following methods should be used:
Physical acquisition. Remove the hard drive and image it externally.
Logical acquisition. Image the media while the OS is running.
Compatible environment acquisition. Boot to a UEFI compatible boot environment and extract data from there.
Conclusion
The added secure boot functionality created by UEFI provides a more secure environment than the traditional BIOS to computer by avoiding a rootkit or other malwares to be easily installed by attackers, who ultimately want to gain unauthorized administrator access to the system. However, it also creates complications for digital examiners because added authorization and certification are needed, and UEFI restricts booting from media not native to the subject machine.

Reference
Bashun, V., Sergeev, A., Minchenkov, V. & Yakovlev, A. (November, 2013). 2013 14th Conference of Open Innovations Association Finnish-Ruissian University Cooperation in Telecommunications (FRUCT). pp.16-24. doi:10.1109/FRUCT.2013.6737940.
How to Geek (HTG). How Window 8's Secure Boot Feature Works & What It Means for Linux. Retrieved from http://www.howtogeek.com/116569/htg-explains-how-windows-8s-secure-boot-feature-works-what-it-means-for-linux/
Microsoft. (2009). UEFI and Windows. Retrieved from https://technet.microsoft.com/en-us/library/hh824898.aspx
Microsoft. (2015). Protecting the pre-OS environment with UEFI. Retrieved from http://blogs.msdn.com/b/b8/archive/2011/09/22/protecting-the-pre-os-environment-with-uefi.aspx
Scientific Working Group on Digital Evidence (SWGDE). (February, 2014). SWGDE UEFI and its Effect on Digital Forensics Imaging. Retrieved from https://www.swgde.org/documents/Current%20Documents/2014-02-06%20SWGDE%20UEFI%20Effect%20on%20Digital%20Imaging%20V1
Simpson, G. (January, 2014). UEFI Momentum – The AMD perspective. AMD.
Smith, R. (July, 2012). Make the most of large drives with GPT and Linux. IBM. Retrieved from http://www.ibm.com/developerworks/library/l-gpt/l-gpt-pdf.pdf
UEFI Forum (2010). FAQ: Drive Partition Limits. Retrieved from http://www.uefi.org/sites/default/files/resources/UEFI_Drive_Partition_Limits_Fact_Sheet.pdf
UEFI Forum. (November, 2010). Unified Extensible Firmware Interface Specification. Version 2.2.D Retrieved from http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_2_D.pdf
UEFI Forum. (April, 2015). Unified Extensible Firmware Interface Specification. Version 2.5. Retrieved from http://www.uefi.org/sites/default/files/resources/UEFI%202_5.pdf