Graduado en Ingeniería Informática

Universidad Politécnica de MadridEscuela Técnica Superior de

Ingenieros Informáticos

TRABAJO FIN DE GRADO

Arranque Seguro en Equipos de Seguridad

Autor: Sergio González de CastroDirector: Jorge Dávila Muro

MADRID, 9 DE ENERO DE 2017

Índice general

Índice general 1

Índice de figuras 2

Índice de cuadros 3

Agradecimientos 4

1. Resumen 5

2. Abstract 6

3. Introducción 7

4. Inicializado hardware de la arquitectura x86 84.1. Inicializado de la placa base . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.2. Inicializado del procesador . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5. UEFI BIOS 115.1. UEFI Platform Initialization (PI) . . . . . . . . . . . . . . . . . . . . . . . . 14

5.1.1. Security (SEC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155.1.2. Pre-EFI Initialization (PEI) . . . . . . . . . . . . . . . . . . . . . . . 165.1.3. Driver Execution Environment (DXE) . . . . . . . . . . . . . . . . . 165.1.4. Boot Device Select (BDS) . . . . . . . . . . . . . . . . . . . . . . . . 18

5.2. UEFI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.2.1. Variables UEFI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.2.2. GUID Partition Table (GPT) . . . . . . . . . . . . . . . . . . . . . . 195.2.3. UEFI System Partition (ESP) . . . . . . . . . . . . . . . . . . . . . . 205.2.4. Transient System Load (TSL) . . . . . . . . . . . . . . . . . . . . . . 205.2.5. UEFI Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205.2.6. Run Time (RT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.2.7. After Life (AL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.3. Secuencia completa de arranque UEFI y selección de lanzador . . . . . . . . 225.4. Formato de los ejecutables UEFI . . . . . . . . . . . . . . . . . . . . . . . . 225.5. Implementaciones UEFI BIOS . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6. Arranque seguro en UEFI 246.1. Secure Boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.1.1. Elementos en las bases de datos de firmas . . . . . . . . . . . . . . . 276.1.2. Validación de Ejecutables . . . . . . . . . . . . . . . . . . . . . . . . 276.1.3. Microsoft UEFI CA . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.2. UEFI TCG Measured Boot . . . . . . . . . . . . . . . . . . . . . . . . . . . 316.3. Consideraciones de seguridad en arranques seguros . . . . . . . . . . . . . . 33

7. Arranque seguro de sistemas operativos 347.1. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7.1.1. Shim Loader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357.1.2. Particiones cifradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7.2. Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377.2.1. Windows Trusted Boot . . . . . . . . . . . . . . . . . . . . . . . . . 397.2.2. Windows Measured Boot . . . . . . . . . . . . . . . . . . . . . . . . 40

7.3. Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407.3.1. Verified Boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

8. Secure Boot en FreeBSD 428.1. Carga de módulos firmados . . . . . . . . . . . . . . . . . . . . . . . . . . . 428.2. Firma de ejecutables UEFI . . . . . . . . . . . . . . . . . . . . . . . . . . . 448.3. Integrado con Shim (Fedora/Red Hat Linux) . . . . . . . . . . . . . . . . . 44

9. Conclusiones y Líneas Futuras 469.1. Fortificado de la kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469.2. Fortificado hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469.3. Hipervisores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469.4. Securizado de máquinas virtuales . . . . . . . . . . . . . . . . . . . . . . . . 47

Bibliografía 49

Índice de figuras4.1. Flujo simplificado firmware arranque x86, Intel Corp, 2009 [1] . . . . . . . . 8

5.1. Flujo de arranque UEFI, Intel Corp, 2011 [2] . . . . . . . . . . . . . . . . . 115.2. Volumenes de Firmware (FVs), Xeno Kovah et al, MITRE, [3] . . . . . . . . 135.3. Firmware File System (FFS), Xeno Kovah et al, MITRE, [3] . . . . . . . . . 135.4. Componentes descritos en UEFI PI, Basado en Intel Corp, 2011 [2] . . . . . 145.5. Operaciones PEI, UEFI Forum, 2016 [4, Vol. 1] . . . . . . . . . . . . . . . . 175.6. Componentes descritos en UEFI, Basado en Intel Corp, 2011 [2] . . . . . . . 195.7. UEFI Shell, © Stone Group 2017 . . . . . . . . . . . . . . . . . . . . . . . . 215.8. UEFI PI Compliant Firmware, Vincent Zimmer, Intel Corp, [5] . . . . . . . 22

6.1. Secure Boot Modes, Unified EFI, [6, Fig. 77] . . . . . . . . . . . . . . . . . 266.2. Loc. firmas embebidas en el formato PE/COFF, Unified EFI, [6, Fig. 76] . 286.3. Flujo de Secure Boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306.4. Mapa de los componentes medidos en los PCR’s, Unified EFI, [7, Fig. 76] . 326.5. Ejemplo del contenido de los PCRs, recuperado por por Measured Boot Tool 336.6. Bios Attack Surfaces, Vincent Zimmer, Intel Corp, [5, Pag. 31] . . . . . . . 33

7.1. Contenido de una variable WBM en la variable UEFI boot, interpretadapor UEFI Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

7.2. Ejemplo del contenido de BCD y WBM . . . . . . . . . . . . . . . . . . . . 387.3. Flujo de arranque Windows Trusted Boot / Measured Boot, [8] . . . . . . . 397.4. Flujo de comportamiento de Verified Boot, AOSP [9] . . . . . . . . . . . . . 417.5. Tabla de hash dm-verity, AOSP [10] . . . . . . . . . . . . . . . . . . . . . . 41

2

8.1. Flujo de Secure Boot para FreeBSD, haciendo uso de shim . . . . . . . . . . 45

Índice de cuadros6.1. Tabla de tipos de firma (SignatureType) de UEFI. Datos de [6, 3.4.1] . . . 276.2. Relación tipos de certificado PE/COFF con las posibles entradas en la base

de datos de firmas. Datos de [6, Table 204] . . . . . . . . . . . . . . . . . . 29

7.1. Variables UEFI usadas internamente por shim . . . . . . . . . . . . . . . . 367.2. Variables UEFI reconocidas por shim como mensajes, para solicitar opera-

ciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3

Agradecimientos

Extiendo mi agradecimiento a mi familia y amigos, los cuales me han acompañadodurante mi carrera académica. También quiero agradecer a Sergio Conde por ser unainspiración para mí renovando mi interés por el mundo de la seguridad informática, y aGuillermo Platas y Carlos Nuñez por su apoyo durante el desarrollo de este proyecto.

4

1 | RESUMEN

Este trabajo documenta el estado actual de las secuencias de arranque firmware dispo-nibles para el público general en la arquitectura IA-32, así como las diferentes especifica-ciones relacionadas con el proceso de carga segura de cargadores de arranque de sistemasoperativos, comúnmente conocido como Secure Boot. También se documenta la soluciónde seguridad propuesta por el consorcio Trusted Computing Group.

En este estudio, se documenta la secuencia de arranque seguro de los diferentes sis-temas operativos que disponen de implementaciones completas de secure boot. Una vezcomprendidas estas técnicas se revisará el estado de FreeBSD, determinando con ello cualesson las carencias de este para poder realizar un arranque seguro.

Como resultado en el presente trabajo se introduce al lector a los diferentes conceptosdel arranque de un equipo de forma segura, y al estudio de las modificaciones necesariaspara implementar una secuencia similar en el sistema operativo FreeBSD.

5

2 | ABSTRACT

This study documents the current state of firmware boot sequences available to thegeneral public in IA-32 system architecture, as well as the different specifications related tothe secure booting of operative system boot loaders, commonly referred to as Secure Boot.The solution proposed by the Trusted Computing Group consortium is also documented.

For this study, the secure boot procedure of the multiple operating systems that havea full secure boot implementation is documented. Once these techniques are understood,the state of the FreeBSD will be reviewed to determine which its deficiencies are in orderto realise a secure boot.

The result is a document that introduces the reader to the different concepts of thesecure boot of the computer and to the study of the modifications required to implementa similar sequence in the FreeBSD operative system.

6

3 | INTRODUCCIÓN

El arranque del sistema operativo en cualquier equipo es un momento crítico para elmismo. Una alteración maliciosa durante el arranque puede comprometer la integridad yseguridad de un sistema, pudiéndose implantar de forma subrepticia diferentes alteracionesal mismo.

El arranque seguro en ordenadores x861 es la solución que se ha establecido para mi-tigar estos ataques, haciendo uso de diferentes modelos criptográficos para garantizar queexclusivamente se carga software autorizado en la secuencia de arranque. Dicho arranqueseguro es parte de la especificación de UEFI2, bajo el nombre de Secure Boot.

En este documento, se quiere estudiar y documentar el proceso de arranque de unsistema con arquitectura x86, basado en UEFI, desde el encendido del mismo hasta laejecución del cargador de arranque del sistema operativo.

Adicionalmente, se revisará el estado del arte de Secure Boot, así como la secuencia dearranque de los diferentes módulos software que intervienen en el mismo (kernel, modulosde kernel, drivers UEFI, ...)

Finalmente, se estudiará el concepto de Measured Boot, un componente de TrustedComputing, desarrollado por el consorcio TCG3, e implementado mediante el uso de undispositivo TPM4.

Para ello, en los siguientes capítulos de este trabajo se van a desarrollar los siguientestemas:

Describir el inicio del arranque hardware de un equipo x86, previo a la ejecución delfirmware de la placa base, desarollada en el capítulo 4Describir de forma pormenorizada el proceso de arranque de un ordenador basadoen la arquitectura x86 con una BIOS UEFI, el cual se desarrolla en el capítulo 5Describir el funcionamiento y uso de Secure Boot, Measured Boot, así como el funcio-namiento y las capacidades de un dispositivo TPM, según su definición del estándardel consorcio TCG, expuesto en el capítulo 6Describir el proceso de arranque de los diversos sistemas operativos mayoritarios,prestando especial atención a Linux y su arranque de particiones cifradas LUKS,realizado en el capítulo 6Estudiar una solución que permita el arranque seguro en equipos FreeBSD, el sistemaoperativo sobre el cual está construida la distribución pfSense. Se estudia en elcapítulo 8Elaborar una serie de conclusiones, que el autor considera relevantes, sobre las téc-nicas de arranque seguro, así como exponer líneas futuras estableciendo posiblesmejoras a la protección de sistemas operativos, en el capítulo 9

1Arquitectura IA-32. Se referirá de forma indistinta como x86 tanto a la arquitectura x86 como a laextensión x86_64 (x64)

2Unified Extensible Firmware Interface3Trusted Computing Group4Trusted Platform Module

7

4 | INICIALIZADO HARDWARE DELA ARQUITECTURA X86

La secuencia de arranque en un equipo con arquitectura x86 consiste en una serie depasos dependientes del sistema concreto en el que se encuentre que culminan cuando laBIOS entrega el control del procesador al cargador del sistema operativo correspondiente.

El sistema de arranque de esta arquitectura ha evolucionado desde los procesadoresIntel 80286, introducidos por primera vez en 1982. Actualmente es extremadamente com-pleja, y involucra a múltiples implementadores Software/Hardware. [11]

Figura 4.1: Flujo simplificado firmware arranque x86, Intel Corp, 2009 [1]

Debido a múltiples problemas de interoperabilidad y retrocompatibilidad, se hace pa-tente que el sistema de arranque no se ha modificado mucho desde entonces y que, inclusoen sistemas con arranques UEFI, de índole mas moderna, se sigue haciendo uso de unainicialización con un diseño de hace más de 30 años. [12]

En este apartado, se prestará atención de forma genérica a los procesos hardwareinvolucrados en el arranque del procesador, necesarias independientemente de si se haceuso de una arquitectura BIOS IBM PC o las mas recientes BIOS UEFI.

8

4.1. Inicializado de la placa base

Una vez accionado el botón de encendido del ordenador, la fuente de alimentación entraen funcionamiento. En unos cientos de milisegundos, esta alcanza los valores nominalesde voltaje para cada uno de los raíles1, y emite la señal ATX “Power Good”[13, pag. 26,3.3.1], y se dispara el controlador de alimentación alojado en la placa base. [14]

Este se encarga entonces de alimentar diferentes relojes de cuarzo, que generarán lasseñales de clock necesarias para el correcto sincronismo de los diferentes componentes de laplaca base. Una vez que convergen los diversos relojes y cuando el controlador determinaque la inicialización es correcta, se libera el procesador del estado de reset. [14]

En los sistemas modernos no solo se dispone del procesador principal, sino que puedenexistir diversas tecnologías “fuera de banda” que no se encuentren gobernadas por elprocesador. Estas permiten realizar diversas tareas, como la administración remota. Unejemplo de ello es Intel Active Management Technology2. Estos subsistemas son tambiénalimentados por la placa base e incluso puede que realicen tareas previas al inicio delsistema, mientras este se encuentre alimentado, pero no encendido3. [14]

4.2. Inicializado del procesador

Cuando se elimina la señal RESET del procesador, este comienza su inicializado[15, Vol.3A, 8-18 , 8.4]. En este proceso se designa dinámicamente uno de los múltiples núcleos(incluyendo los núcleos lógicos de SMT4.) del procesador como procesador “de arranque”(bootstrap processor (BSP)). El resto son designados como procesadores “de aplicación”,(application processor (APs)).

Cuando se establece el BSP, este ejecuta el código de la BIOS, fijando para ello el valordel registro ip5 y cs6 en la posición del vector de reset.

La posición del vector de reset se encuentra en la posición de memoria física 0xFFFFFFF0[15,Vol. 3A, 9-5, 9.1.4]. Al encontrarnos en modo real, esta posición, no debería ser accesible,ya que se encuentra muy lejos del megabyte direccionable dentro de dicho modo. Esto es elresultado de un comportamiento especial del registro cs, observable en el arranque físicodel procesador.

1A saber, 1.5, 3.3, 5 y 12 voltios.2Mientras que este asunto será tratado más adelante en este documento, se puede adelantar que estos

sistemas pueden alterar la BIOS del sistema, así como operar con diferentes elementos de I/O (entrada/sa-lida) sin que el procesador sea consciente de ello.

3Un ejemplo simple de ello es el uso de Wake On Lan, el cual hace que la tarjeta de red escuche elpaquete mágico, aun con el equipo en un estado APCI S5/G2 (apagado, pero con alimentación).

4Simultaneous MultiThreading, conocido como HyperThreading en las plataformas Intel5Instruction Pointer, el registro con la posición de memoria de la siguiente instrucción a ejecutar,

conocido en otras arquitecturas como PC, Program Counter. Los 3 modos de direccionamiento de los quedispone[15, Vol. 1, 3-10, 3.3.7] son: ip(16 bits), eip(32 bits) y rip(64 bits).

6Code Segment, el segmento de memoria en el que se aloja el código ejecutable, referido por el registroip. Está compuesto por este registro y, junto con el registro ds Data Segment, fijan la base del segmentadode memoria[15, Vol. 1, 1-6, 1.3.4] usado en la arquitectura x86[15, Vol. 1, 2-1, 2.1.1].

9

El registro cs dispone de dos componentes: el selector de segmento, que es la partemodificable y visible del registro (cs propiamente dicho), y una dirección base, un registrooculto del procesador. La dirección base se forma normalmente copiando cs y desplazán-dolo 4 bits hacia la izquierda, obteniéndose así una dirección base de 20 bits (DirBase= cs * 16). Pero, al iniciarse el procesador, el contenido del registro de dirección basees 0xFFFF0000, por lo que, sumado al estado inicial del registro ip (0xFFF0), nos da ladeseada dirección base 0xFFFFFFF0. Esta dirección estará direccionada a la memoria novolatil de la BIOS, y comenzará su ejecución por el BSP.

Este comportamiento es siempre el mismo para el inicializado del sistema, indepen-dientemente del estado ACPI del que se retorne.

10

5 | UEFI BIOS

Unified Extensible Firmware Interface, tambien conocido como UEFI, es un conjuntode especificaciones1, que establecen un modelo universal de inicializado de un computador,independiente de su arquitectura2.

El estándar UEFI persigue abstraer los servicios de inicializado de hardware para fi-nalmente cargar un sistema operativo, independientemente del hardware sobre el cual seesté ejecutando. Con ello, se pretende conseguir una forma unificada por la cual los pe-riféricos y componentes se comuniquen con el firmware en la inicialización, para eliminarlos problemas de compatibilidad que se encontraban en las tradicionales BIOS. Adicional-mente, se quiere ampliar la funcionalidad provista sin un sistema operativo. Esto permitepor ejemplo la administración de equipos mediante la conexión a redes de comunicaciones,incluso de forma segura3, facilitando con ello labores de administración de grandes parquesde equipos.

La secuencia de arranque de UEFI está dividida en múltiples fases [16] [17] [2, BeyondBios, Vincent Zimmer et al] 5.1. Estas son las siguientes:

Figura 5.1: Flujo de arranque UEFI, Intel Corp, 2011 [2]

SEC Seguridad: Esta fase está encargada de cambiar el procesador a modo protegido, apli-car la actualización de microinstucciones (microcode) del procesador, preparaciones

1Regidas por el UEFI Forum, http://www.uefi.org2Mientras que en este documento se tratará x86, UEFI también se encuentra disponible para arquitec-

turas como ARM3Vía IPSec, soportando el uso de tarjetas inteligentes, y/o lectores biométricos

11

para entrar en la fase PEI. Se puede considerar que esta fase es parte del inicializadodel procesador.

PEI Inicializado Pre-EFI : Este es el código que inicializa diferentes elementos hardwaredel ordenador, y se encarga de que la memoria se encuentre inicializada para elarranque del DXE.

DXE Entorno de Ejecución de Drivers: Esta fase se encarga de cargar los diferentes driverspara proveer los servicios DXE/EFI. También se cargan drivers para protocolos, quepuedan ser usados por otros componentes.

BDS Selección de Dispositivo de Arranque: Cuando no es necesario cargar mas drivers,y todos los protocolos tienen un driver cargado, se carga el selector de arranque.Puede saltarse desde aquí a un programa de gestión del hardware, como la interfázgráfica de la BIOS, o realizar una carga local o remota de un cargador de arranquede sistema operativo.

TSL Carga Transeúnte de Sistema: Esta fase comprende tanto los posibles ejecutablesUEFI que se puedan lanzar que no abandonen el servicio de arranque, como el lan-zador de un sistema operativo, que si que termine abandonando la fase de arranqueUEFI, y comienze a ejecutar el sistema operativo.

RT Tiempo de Ejecución: Esta fase comprende todo el periodo de vida del sistemaoperativo, hasta que finalice su ejecución.

AL Póstumo: Esta fase comprende las acciones que se puedan tomar previas al apagadoesperado del sistema.

UEFI consta de múltiples especificaciones. Esta división responde a dos grandes seg-mentos en el flujo de arranque. Por un lado se tiene el software, que se programa siguiendouna interfaz común (UEFI). Por otra parte se encuentra el firmware de una plataforma enconcreto, que sirve un entorno para que opere la interfaz de dichos programas. [2, BeyondBios, Vincent Zimmer et al]

UEFI[6] La especificación de la interfáz software UEFI. Define el formato de los ejecutables, latabla de particiones GPT, los servicios, los diversos protocolos de periféricos (USB,SCSI, PCI...) y de comunicación (ethernet, wlan, bluetooth...) y la especificación deSecure Boot, autenticado, y verificaciones criptográficas. Los programas y driversUEFI que se desarrollan bajo esta especificación son compatibles4 entre diferentesarquitecturas.

UEFI PI[4] UEFI Platform Initialization Es un conjunto de especificaciones, que establecen comose realiza la carga de los distintos elementos hardware para proveer los mínimos parael funcionamiento de los programas y drivers UEFI. Esta es la inicialización tempranade los diversos elementos hardware en el arranque. En esencia, es el conjunto defirmware que permite que a continuación funcione el software UEFI.

4Es necesario recompilar para la arquitectura de destino, pero el código de alto nivel permanece elmismo.

12

Almacenamiento Firmware UEFI

El código UEFI reside en una memoria flash no volatil, normalmente accedida medianteel estándar SPI5. El estándar define la existencia de Volúmenes de Firmware (FVs6)[4, 2.9],y en particular el Volumen de Firmware de Arranque (BFV7).

El BFV contiene tanto el código de la fase SEC, como la base para la fase PEI. Estealmacén en la arquitectura IA-32 es la memoria ROM que se encuentra direccionadaen la posición más alta de memoria en modo real (0xFFFFFFF0). Existen también otrosFirmware Volumes, residentes en diferentes memorias no volátiles de diferentes periféricos(P.E, GPU).

Como se puede apreciar en la figura 5.2, no solo se almacena el contenido del firmwareUEFI en la memoria ROM, sino que se almacena también datos

Figura 5.2: Volumenes de Firmware (FVs), Xeno Kovah et al, MITRE, [3]

Un Firmware Volume tiene como formato el sistema de ficheros FFS8, en el cual sealmacenan ficheros los cuales se pueden dividir en secciones. 5.3

Figura 5.3: Firmware File System (FFS), Xeno Kovah et al, MITRE, [3]

5Serial Peripheral Interface, un protocolo de comunicación usualmente usado para memorias flash.6Firmware Volumes7Boot Firmware Volume8Firmware File System

13

5.1. UEFI Platform Initialization (PI)

Para poder disponer de los diferentes servicios provistos por UEFI, es necesario pri-mero inicializar el equipo (plataforma), configurando el procesador, iniciando la memoria,y cargando los drivers mínimos para ofrecer la funcionalidad UEFI. Una vez realizadasestas tareas, ya se dispone de la inicialización hardware básica. Todo este inicializado dehardware se realiza de acorde a la especificación UEFI Platform Initialization[4], el cualdescribe cuales son las distintas fases que componen este proceso de inicializado hardware.

Antes de finalizar la fase PI, y antes del inicio del cargador del sistema operativo resideel menú de configuración9 comúnmente conocido como "BIOS".

La inicialización es dependiente por cada sistema, ya que hay que ajustar el firmware alos componentes de un sistema concreto. Existe por ello las configuraciones “estáticas”, enlas cuales los componentes principales no son sustituibles (por ejemplo, que el procesador seencuentre soldado mediante BGA10 como puede ser en la mayoría de portátiles o sistemasembebidos), u opciones más flexibles que permitan sustituir por ejemplo el procesador yla RAM, como puedan ser placas bases en ordenadores de torre. Por esta razón es por loque por lo general son más configurables las BIOS de los ordenadores fijos, al tener quefuncionar en más configuraciones.

En la figura 5.4 se puede observar los elementos de la secuencia de arranque regidospor la especificación de UEFI PI.

Figura 5.4: Componentes descritos en UEFI PI, Basado en Intel Corp, 2011 [2]

9En los ordenadores personales, donde se puede personalizar opciones del hardware. En otros equiposeste menú es inexistente.

10Ball Grid Array, un tipo de soldado en superficie para componentes electrónicos como SoC’s

14

5.1.1. Security (SEC)

La fase Security (similar a la antiguamente conocida como POST) comienza cuando elprocesador comienza a leer el firmware desde la memoria flash del sistema (BFV), desde laposición 0xFFFFFFF0[4, Vol 1, 5.1.2.4]. Esta fase está íntimamente ligada con el inicializadodel procesador, y el código normalmente es provisto por el fabricante de la CPU.

Este proceso por lo general esta compuesto de los siguientes pasos: [15, Vol. 3A, 8-20,8.4.4.1][5, Pag. 20][17, Pag. 14-20][14]

1. Limpia los registros y caches del procesador.

2. Cambia el procesador a modo protegido

3. Localiza el BFV, y busca el “fichero” SecCore

4. Inicializa los registros MTRR 11.

5. Comienza a ejecutrar el fichero SecCore

6. Aplica el parche de microcode12 al procesador.

7. Se prepara el modo NEM13, en el cual la cache del procesador se usa como la RAMdel sistema (CAR14). Esto permite el uso de la pila ESP en el procesador.

8. Ejecuta el BIST15 y crea las tablas ACPI16, en el BSP y el resto de APs17.

9. Opcionalmente descubre e inicializa el TPM.

10. Comienza la fase PEI, pasándose a ejecutar el PEI Foundation.

Si alguno de los pasos falla, el procesador se detiene.

En algunos sistemas18 puede existir también la posibilidad de que el código de PEItenga que verificar alguna firma digital antes de comenzar a ejecutarse[21].

11Memory Type Range Registers, registros usados para acceder a memoria aplicando propiedades decache (writeback, writetrough, etc.)[15, Vol. 3A, 11-20, 11.11]

12Actualizaciones “de caja negra” provistas por el fabricante de la CPU para actualizar las microins-trucciones contenidas en el procesador. Estas actualizaciones se encuentran cifradas y firmadas[18][19].

13No-Eviction Mode14Cache-As-Ram15Built-In Self Test16Advanced Configuration and Power Interface. Se trata de un estándar[20] para la gestión de energía

de los diferentes componentes de un ordenador. Se encarga además de enumerar los diferentes disposi-tivos hardware, y de gestionar los sistemas multi-procesador, reemplazando a sus respectivos anticuadosestándares. El desarrollo de este estándar es actualmente regido por el UEFI Forum.

17Procesadores reales o lógicos no activos18Como Intel Boot Guard en modo de Verificación, o Verificación y Medición

15

5.1.2. Pre-EFI Initialization (PEI)

La fase Pre-EFI Initialization es la responsable de una mínima inicialización de loscontroladores y la memoria de la plataforma para con ello proveer los servicios mínimospara la fase DXE.[4, Vol 1, 2.3] Para ello, ha de hacer uso de la menor cantidad dememoria posible, ya que esta se encuentra alojada en la cache del procesador (CAR), y esmuy escasa, del orden de un centenar de kilobytes19. Esta fase consta de un código base(PEI Foundation | PEI Core) y una serie de módulos que inicializarán los componentes(PEIMs20).[4, Vol.1, 2.3] Los módulos se pueden comunicar entre si, mediante PPI21[4,Vol 1, 2.8]. Esta relación se define en la cabecera de los módulos, con lo que se describeque dependencias tienen entre si22[4, Vol. 1, 7.2.1]

SEC provee a PEI Core las posición donde comienza la CAR en la cache del procesador,la pila inicializada, y la localización de BFV.[4, Vol 1, 5.2.1] Con esto, se inicia un bucleque carga todos los módulos PEIM que se encuentren en todos los FVs. Este es conocidocomo PEI Dispatcher. Un módulo se lanza si todas sus dependencias ya se han lanzado.[4,Vol. 1, 5.5]

Entre estos PEIM se encuentran los que inicializan (recordemos que de forma básica)la CPU, diversos controladores de memoria y perifericos (MCH23, ICH24, SMBUS entreotros), y la memoria RAM del sistema.[4, Vol. 1, 7.1] Si algún modulo falla, el sistema sedetiene.

Cuando todos los PEIM se han cargado, si se está encendiendo el equipo desde unestado de suspensión (S3), se procede a cargar el sistema operativo residente en la RAM.En caso contrario, se carga el módulo DXE IPL25, el cual prepara unas estructuras dedatos para lanzar la fase DXE, denominados HOBs26. Estos describen, de forma análogaa como se ha hecho para cambiar de la fase SEC a PEI, los diferentes FVs y la memoriadel sistema. Se otorga entonces el control al EFI Driver Dispatcher, el cual ya dispone detoda la base de PEI que requiere para funcionar.5.5

Los módulos PEIM pueden validarse mediante firmas digitales, pero no hay un requisitode que estos se encuentren firmados.

5.1.3. Driver Execution Environment (DXE)

La fase Driver Execution Environment es donde se cargan los drivers UEFI y se terminade inicializar todo el hardware para finalmente proveer los servicios de UEFI, tanto detiempo de ejecución como de arranque. Esta fase consta de 3 componentes, el núcleo deDXE (DXE Foundation), un dispatcher (DXE Dispatcher), y un conjunto de drivers DXE.El núcleo se encarga de cargar, a través del dispatcher, todos los drivers DXE en el orden

19En el código de TianoCore, la implementación de referencia de UEFI, 128 Kbytes20Pre-EFI Initialization Modules21PEIM-to-PEIM Interface.22Dichas dependencias se nombran como DEPEX23Memory Controller Hub24I/O Controller Hub25DXE Initial Program Load26Hand-Off-Blocks

16

Figura 5.5: Operaciones PEI, UEFI Forum, 2016 [4, Vol. 1]

adecuado para proveer todos los servicios UEFI[4, Vol. 2, 2.1] y cargar también los driversUEFI necesarios que se encuentren en el resto de FVs en las diferentes memorias de otrosdispositivos.

En esta fase se producen varios eventos con mucha relevancia para la seguridad delsistema, como la carga de SMM27, la verificación de Secure Boot antes de cargar cualquierejecutable UEFI, o verificar y aplicar una actualización a la flash, provista como unacápsula UEFI Capsule.

Una vez los drivers son aceptados por Secure Boot, o si este está deshabilitado, secargan según sus dependencias, de forma análoga a la fase PEI, registrandose sus serviciosUEFI en una tabla que enumera todos los servicios UEFI del sistema. Estos servicios tienenun contexto de vida. Los servicios de arranque (boot) solo estarán disponibles durante elarranque, y los servicios de tiempo de ejecución (runtime) estarán también disponiblespara el sistema operativo.

Estos servicios UEFI pueden ser el controlador GOP28 de vídeo del sistema, protocolosde comunicación IP, drivers de la tarjeta de red, etc. Un listado exhaustivo de los protocolossoportados se encuentra en la especificación de UEFI[6].

Cuando ya se encuentran cargados todos los drivers, tiene que encontrarse ya com-pletamente inicializado el hardware, y existirán además las diferentes tablas de serviciosUEFI[4, 12.1]

Para terminar esta fase, comienza la ejecución del Boot Manager, que se encargará decargar el sistema operativo correspondiente.

27System Management Mode28Graphics Output Protocol[6, 11.9]

17

5.1.4. Boot Device Select (BDS)

En esta fase es cuando en equipos personales se muestra en el display del equipo elresultado del POST29, y se insta al usuario a pulsar algún botón para entrar en el menú deconfiguración de la BIOS, o seleccionar otro dispositivo de arranque. Estos menús puedenestar escondidos o deshabilitados en equipos especializados. También se puede lanzar unbinario transeúnte, el cual realice tareas con el equipo, pero que no finalice la fase dearranque.

Adicionalmente, puede existir en esta fase herramientas de gestión del firmware, pararealizar actualizaciones desde la interfaz de configuración de la BIOS. Es responsabilidaddel desarollador de la BIOS y del implementador el asegurar que las actualizaciones verifi-quen (si es que se han implementado) comprobaciones de seguridad, o si estas pueden serobviadas en caso de realizarse por un usuario presente en el equipo.

Una vez el Boot Loader determina (bien revisando la lista de ejecución de lanzadoreso por acción del usuario) cual es el programa que se ha de lanzar, este se valida conSecure Boot (si está habilitado) y tras superar este la validación se lanza. En caso de nosuperarla, se podrá seguir intentando lanzar programas alternativos. En cualquier caso, seha alcanzado la fase TSL.

5.2. UEFI

Esta especificación[6] es la que rige sobre los protocolos que estarán disponibles yproveerán los ejecutables (aplicaciones y drivers) UEFI, así como el formato de la tablade particiones GPT30, que sucede al viejo formato DOS de particiones, MBR31 y no sufrede sus limitaciones de número de particiones o tamaño de los discos. También se describeel funcionamiento de Secure Boot, y el formato para la firma de drivers y ejecutables.

Antes de continuar con la carga del sistema operativo es necesario conocer y detallaruna serie de conceptos sobre los sistemas UEFI, el almacenamiento de variables, el sistemade particiones GPT y la partición de sistema UEFI.

5.2.1. Variables UEFI

Una de las características más relevantes de UEFI, es la capacidad de almacenar enuna memoria no volátil (nvram, la flash BFV) variables que se conservan aunque el sistemano esté alimentado. Mientras que el concepto es similar al existente en las obsoletas BIOSIBM, las principales variables existen bien definidas en el estándar UEFI[6, Tabla 11 y3.3], con lo que no sufren los antiguos problemas de compatibilidad.

Estas variables tienen propiedades que permite determinar si se almacenan en la memo-ria flash (Non_Volatile), quien puede escribir en ellas (Time_Based_Authenticated_Write_Access),cuando son accesibles (Bootservice_Access y Runtime_Access).

29Power On Self Test30GUID Partition Table31Master Boot Record

18

Figura 5.6: Componentes descritos en UEFI, Basado en Intel Corp, 2011 [2]

Algunas de estas variables son las usadas para los almacenes de claves y hashes deSecure Boot (PK, KEK, DB, DBX...), y serán tratadas más adelante. Otras almacenan elorden de carga[6, 3.1] de drivers UEFI (DRIVER####), o el orden y localización de losprogramas que se ejecutarán en el arranque del sistema (BOOT####).

Las variables protegidas (Time_Based_Authenticated_Write_Access) definen unaclave pública que será la que a posteriori controle las modificaciones a la misma. Para modi-ficar variables protegidas, en el comando UEFI de modificación de variables SetVariable()se ha de agregar una firma digital creada con la variable que la protege, como se describeen el procedimientoEFI_VARIABLE_AUTHENTICATION_2 [6, 7.2.1, 7.2.2].

Las variables UEFI pueden ser modificadas por el sistema operativo, mediante el co-mando UEFI SetVariable(), sólo si están definidas como accesibles para el sistema ope-rativo (Runtime_Access).

5.2.2. GUID Partition Table (GPT)

GPT es el formato de tabla de particiones definido en la especificación de UEFI[6, 5].Este estándar permite un número ilimitado de particiones, y soporta almacenamientos dehasta Zettabytes. Mientras que no se entrará mucho en detalle, es importante conocer quelas particiones se identifican según un GUID32, de la formaC12A7328-F81F-11D2-BA4B-00A0C93EC93B (En concreto, este es el GUID reservado para

32Globally Unique Identifier, un identificador prácticamente garantizado que sea único si se escoge deforma aleatoria.

19

la partición ESP)

5.2.3. UEFI System Partition (ESP)

Los ejecutables que no residan dentro de alguna memoria flash, han de ser cargadosdesde un dispositivo de almacenamiento. Entre ellos se encuentran los cargadores de lossistemas operativos, así como otros programas transeúntes o incluso drivers.

Para ello, se reconocen particiones en cada soporte de almacenamiento conectado alequipo ya bien use GPT o MBR, con formato FAT[6, 12.3.1.1 - 12.3.4] y con un indicadoren las propiedades de la misma para reconocerlo.

En esta partición se almacenan en diferentes carpetas33 los lanzadores y otros ficherosque puedan usar, para lanzar su correspondiente aplicación.

5.2.4. Transient System Load (TSL)

Esta fase comprende el uso de ejecutables UEFI, hasta el momento de invocar la salidadel servicio de arranque UEFI, ExitBootServices(). Una vez que se invoca esa instruc-ción, se eliminan los diferentes servicios de arranque de UEFI, únicamente conservándoselas estructuras creadas por los drivers, así como los servicios UEFI de tiempo de ejecu-ción34. Es el final del ciclo de vida UEFI, y el código que debería de entrar en ejecución esel de la kernel del sistema operativo de destino, o un lanzador intermedio para el mismo.

Aunque la única diferencia entre los posibles ejecutables es que finalmente se invoqueExitBootServices(), en general se considera que los ejecutables que no finalizan losservicios de arranque son transeúntes, y los que si que los finalizan, son cargadores desistemas operativos.

Este es el punto donde se lanza el cargador del sistema operativo, Windows, Linux,FreeBSD, etc...

5.2.5. UEFI Shell

Un ejemplo de un ejecutable transeúnte, que no un lanzador de sistema operativo, seríala UEFI Shell, un programa para diagnóstico de sistemas UEFI, cuya especificación es re-gida por el UEFI Forum[22]. Existe también una implementación de referencia, distribuidapor TianoCore35.

Esta consola permite realizar diversas tareas como listar o modificar regiones de memo-ria asignadas, los drivers que están cargados (y cargar nuevos), ver y modificar variablesUEFI, e incluso lanzar otros ejecutables UEFI (los cuales han de también superar la veri-ficación de Secure Boot), que puedan ser a su vez cargadores de sistemas operativos.

33UEFI Forum insta a los implementadores que hagan uso del registro de subdirectorios para no coli-sionar entre diferentes posibles lanzadores UEFI, pero la participación es opcional.

34EFI Runtime Services35https://github.com/tianocore/tianocore.github.io/wiki/ShellPkg

20

Figura 5.7: UEFI Shell, © Stone Group 2017

5.2.6. Run Time (RT)

La fase de tiempo de ejecución únicamente dispone de los servicios de tiempo de eje-cución (runtime) de UEFI, así como las posibles regiones de memoria inicializadas por losdrivers.

A partir de este momento, es la kernel del sistema operativo la encargada de mantenerla seguridad del equipo, protegiendo al sistema frente a los accesos no autorizados a losdiferentes servicios del mismo.

5.2.7. After Life (AL)

Esta fase actualmente no es utilizada[3, Slide 53], pero podría usarse para cerrar deforma ordenada dispositivos.

21

5.3. Secuencia completa de arranque UEFI y selección delanzador

Una vez comprendida cada fase, y las tareas que tiene asociadas, se puede revisar laimagen completa de un arranque UEFI que se resume en el esquema de la figura 5.8. Enesta se observan los pasos que el sistema va realizando y las interacciones con los diversosservicios.

Figura 5.8: UEFI PI Compliant Firmware, Vincent Zimmer, Intel Corp, [5]

5.4. Formato de los ejecutables UEFI

Los ficheros ejecutables UEFI pueden ser de dos tipos, drivers o aplicaciones. Estosdifieren en que las aplicaciones no son dependencias de otras aplicaciones, mientras quelos drivers si que pueden tener otros drivers que dependan de ellos. Ambos hacen uso delformato PE/COFF 36, originalmente desarollado por Microsoft. Este formato es indepen-diente de arquitectura, ya que disponen de metadatos que anuncian la arquitectura con laque se ha compilado el mismo. También hacen uso de dicha formato los drivers DXE.

En la fase PEI, debido al reducido espacio disponible en la flash del sistema, los eje-cutables hacen uso del formato TE37, el cual está adecuado además a que sean ejecutadosdirectamente desde la flash, sin realojarlos en memoria (XIP, Execute In-Place)

36Portable Executable/Common Image Format37Terse Executable

22

5.5. Implementaciones UEFI BIOS

Existe una implementación software de referencia para UEFI y UEFI PI, que es ademásusada para compilar ejecutables UEFI y es la base de OVMF[23], una BIOS UEFI paramáquinas virtuales. Esta implementación es EDK II[24], desarollada por TianoCore, unproyecto de código libre (BSD), originalmente creado y coordinado por Intel[25].

Además de ello, existen las implementaciones de pago de los diferentes IBV38, normal-mente usadas en sistemas comerciales. [1, IBVs]

En cualquier caso todas ellas siguen el mismo esquema general de funcionamientodescrito por el estándar y sus variaciones corresponden a diferencias en la arquitectura delsistema y en la interfaz de acceso del usuario a los datos accesibles de la BIOS.

38Independent BIOS Vendors, empresas que disponen de su propia implementación de las BIOS, lascuales son contratadas por los fabricantes de hardware para usar en sus productos. Estas son, entre otras,Phoenix Technologies, Insyde Software, American Megatrends.

23

6 | ARRANQUE SEGURO EN UEFI

En UEFI, existen dos tecnologías relacionadas con la seguridad en el arranque de unsistema operativo:

Secure Boot es el nombre que recibe la especificación de UEFI relacionada con lacarga verificada de ejecutables UEFI.[6, 30] Estos ejecutables son tanto los driversUEFI/DXE como las aplicaciones como UEFI Shell, o un cargador de un sistemaoperativo. Con el uso de Secure Boot, se puede verificar que:

• El ejecutable no ha sido modificado• El ejecutable ha sido firmado por un emisor cuya clave pública está almacenada

en la base de datos de confianza

UEFI TCG Measured Boot1, es el procedimiento descrito[28] por el consorcio TCG2

mediante el cual en un sistema UEFI se registran los diferentes eventos del arranquedentro de un dispositivo TPM3. Para ello, se comunica con dicho TPM mediante unprotocolo definido[7][29]. Durante el arranque, se almacenan de forma irreversiblediferentes valores recuperados durante el inicio del sistema. Esto permite a posteriorihacer uso de funcionalidades donde se pueden almacenar secretos en el TPM loscuales no se puedan recuperar si no se hace uso de la misma secuencia de arranque.

Estas únicamente protegen hasta el momento en el cual se lanza el cargador sistemaoperativo. Desde ese momento, es responsabilidad del sistema operativo el proteger elsistema frente a ejecución privilegiada de código malicioso.[27]

Existen otras tecnologías que complementan a Secure Boot y Measured Boot

Intel Boot Guard (Verified Boot). Esta tecnología permite grabar en el procesadoruna clave pública, con lo que se verifica antes de ejecutar la fase Security (SEC) elcódigo disponible en la memoria flash. 4[30][31][5, Pag. 28]

Intel Boot Guard (Measured Boot). Esta tecnología permite al procesador inicializarel TPM antes de que se ejecute la fase Security (SEC), almacenando el hash del valorleido de la flash. Esto mientras que no detiene la ejecución de un firmware modificado,permite su detección.[30][31][5, Pag. 28]

AMD Hardware Validated Boot es una tecnología análoga a Intel Boot Guard (Veri-fied Boot), en la cual el procesador dispone de un co-procesador de seguridad (AMD

1Measured Boot es el nombre otorgado por Microsoft [26][27] al arranque con medición establecido porel TCG (UEFI TCG Measured Boot)

2Trusted Computing Group3Trusted Platform Module4El hecho de que sólo se pueda fijar una única clave, y que esta esté bajo control exclusivo del fabricante

de la placa base, plantea problemas sobre la libertad del usuario, ya que no permite que posteriormente secargue ningún bloque no identificado por dicha clave del fabricante.

24

Secure Processor)5 que puede verificar la fase Security (SEC) y posteriores [32, Pag.9] [34]

6.1. Secure Boot

Secure Boot es una parte de la especificación UEFI[6, 30]. Secure Boot establece queantes de ejecutar ninguna imagen UEFI, es necesario verificar que esta es confiable. Paraello, se establece un modelo de confianza con ayuda de las variables UEFI para almacenarla información correspondiente. Existen diversas variables UEFI6 que contienen los datosde Secure Boot:[3, Pag. 44][6, 30.5, 30.6][35]

PK Platform Key. Parte pública de la clave PK. Establece la relación de confianza entreel dueño de la plataforma y el firmware. Limita las modificaciones a PK y KEK

KEK Key Exchange Key. Parte pública de las claves KEK. Según la especificación, esta-blece la relación de confianza entre el sistema operativo y el firmware. Limita lasmodificaciones a las bases de datos de firmas.

DB Autorized Signature Database. La lista blanca. Contiene una lista de certificadosX.509, firmas de certificados y/o hashes de binarios de confianza.

DBX Forbidden Signature Database. La lista negra. Contiene un lista de certificados X.509y/o hashes revocados

DBT Authorized Timestamp Signature Database. Una lista con certificados X.509 en losque se confía como entidades TSA7 para firmas PKCS#7[37]. Con esto se permitela carga de ejecutables firmados cuyo emisor de la firma (X.509) está en DBX, perohan sido firmados antes que la fecha de revocado del firmante.8[6, Pag. 2289]

DBR Authorized Recovery Signature Database. Una lista blanca para cargadores de recu-peración, ya bien sean del sistema operativo o del fabricante hardware.9

La especificación requiere que se guarden estas variables en un almacenamiento novolátil y resistente a modificaciones, que además para PK sea resistente a borrado. [6,30.6.1, 30.3.6].

La forma mediante la cual la clave PK protege a KEK, y a su vez esta a DB*, es medianteel uso de variables Time_Based_Authenticated_Write_Access. La relación entre cualclave (variable) es necesaria para modificar cada lista es parte del estándar.

5Previamente conocido como PSP (Platform Security Processor)[32, Pag. 9]. Actualmente sólo estádisponible en algunas series de APU’s[33, Pie 1], citado: “AMD Secure Processor is currently only availableon select AMD A-Series and AMD E-Series APUs.”

6Bajo el GUID D719B2CB-3D3A-4596-A3BC-DAD00E67656F7Time Stamping Authority, según el RFC3161[36]8Con esto, se pueden bloquear firmas nuevas emitidas sin bloquear todos los ejecutables que se han

emitido en caso de que se comprometa la entidad de firma, ya que es necesario comprometer también alTSA. Si se compromete también al TSA, o si este no es de confianza y emite certificados “backdated”, estesistema no provee seguridad ninguna.

9Esta variable fue introducida en la Revisión 2.5 de UEFI, y actualmente no parece ser usada, Windows10 v1607 no la reconoce como una variable válida de SecureBoot y no está implementada en EDK II

25

Secure Boot se puede encontrar en 4 modos: 6.1[6, 30.3]

Figura 6.1: Secure Boot Modes, Unified EFI, [6, Fig. 77]

User Se encuentra registrada una PKpub. Esta puede ser sustituida por otra si se recibeun mensaje firmada con PKpriv. La variable KEK se puede modificar con un mensajefirmado por PKpriv. Si se fija la variable DeployedMode a 1, se pasa a modo Deployed.

Setup No se encuentra registrada una PKpub. No se ejecutan las verificaciones de SecureBoot, y las variables pueden ser modificadas sin autentificar. Si se registra una PKpub,se pasa a modo User.

Audit No se encuentra registrada una PKpub, y la variable AuditMode se ha fijado a 1.Se ejecutan las verificaciones de Secure Boot, pero nunca fallan, solo registran suresultado en una tabla de debug.[6, 30.4.2] Del modo Audit solo se puede pasar almodo Deployed, fijando una PKpub.

26

Deployed El modo más restringido. Para abandonar este modo, es necesario el uso de algúnmodo definido por el fabricante para regresar a User Mode, o eliminar PKpub, medianteun mensaje firmado por PKpriv, para volver al modo Setup.

6.1.1. Elementos en las bases de datos de firmas

En las bases de datos de firmas, se almacenan 0 o más elementos, denominados listas defirmas. Estas listas indican que “tipo” de firma contienen (SignatureType) 6.1, y contie-nen un array de dichas firmas (_EFI_SIGNATURE_DATA). Mientras que no es estrictamentenecesario, normalmente cada elemento se encuentra en su propia lista.

SignatureType GUID Típo (EFI_CERT_) Contenido826CA512-CF10-4AC9-B187-BE01496631BD SHA1_GUID Hash SHA1C1C41626-504C-4092-ACA9-41F936934328 SHA256_GUID Hash SHA2560B6E5233-A65C-44C9-9407-D9AB83BFC8BD SHA224_GUID Hash SHA224FF3E5307-9FD0-48C9-85F1-8AD56C701E01 SHA384_GUID Hash SHA384093E0FAE-A6C4-4F50-9F1B-D41E2B89C19A SHA512_GUID Hash SHA5123C5766E8-269C-4E34-AA14-ED776E85B3B6 RSA2048_GUID Clave RSA2048E2B36190-879B-4A3D-AD8D-F2E7BBA32784 RSA2048_SHA256_GUID Firma RSA2048 de hash SHA25667F8444F-8743-48F1-A328-1EAAB8736080 RSA2048_SHA1_GUID Firma RSA2048 de hash SHA1A5C059A1-94E4-4AA7-87B5-AB155C2BF072 X509_GUID Cert. X.509 (Codificado DER)3BD2A492-96C0-4079-B420-FCF98EF103ED X509_SHA256_GUID Hash SHA256 del cont. X.5097076876E-80C2-4EE6-AAD2-28B349A6865B X509_SHA384_GUID Hash SHA384 del cont. X.509446DBF63-2502-4CDA-BCFA-2465D2B0FE9D X509_SHA512_GUID Hash SHA512 del cont. X.509

Cuadro 6.1: Tabla de tipos de firma (SignatureType) de UEFI. Datos de [6, 3.4.1]

6.1.2. Validación de Ejecutables

El modo define si se está ejecutando o no la verificación de ejecutables de SecureBoot, siendo imperativa en Deployed, opcional en User, y deshabilitada en Setup y Audit(aunque en Audit si que se verifica, nunca se bloquea.)

La especificación no establece cuales ejecutables han de ser verificados, solo propone elmodelo sobre el cual desarrollar una verificación de integridad o origen del mismo.[6, 30.2]

Las política de seguridad que se aplica con Secure Boot es determinada por la imple-mentación de la BIOS. La implementación de referencia EDK II por defecto verifica lasimágenes PE/COFF cuyo origen no es un FV, sino que esta proviene de una option rom,un dispositivo de almacenamiento o una imagen descargada por ethernet (PXE)10 [38].EDK II usa como nombre genérico DXE para referirse a todas las imágenes PE/COFF.

Los bytes de la imagen que serán usados para calcular el resumen hash (digest) de estosficheros se calcula siguiendo lo especificado en el procedimento de Microsoft Authenticode.

10SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c, en el repositorio deEDK II

27

Con ello, se eliminan ciertas cabeceras y otros datos irrelevantes para una firma digital.[6, 30.2.3][39, Creating the PE Image Hash]

Para la validación del mismo por UEFI, los ficheros PE/COFF pueden contener unafirma digital opcional embebida en ellos, en la posición habilitada a tal efecto en dichoformato 6.2. Aunque no contengan una firma, siempre se podrá validar el propio resumenhash, resultado de aplicar una función hash a ese contenido. [6, 3.2.4]

Figura 6.2: Loc. firmas embebidas en el formato PE/COFF, Unified EFI, [6, Fig. 76]

Se contempla con ello que en el almacén de firmas digitales del fichero PE/COFF seencuentre uno de los siguientes tipos de certificados, identificados por el valor:[6, 3.2.4]

0x0002 Firma Authenticode (WIN_CERT_TYPE_PKCS_SIGNED_DATA), siguiendo el estándarPKCS#7 según lo establecido en la especificación Authenticode de Microsoft [39]

0x0EF0 Firma PKCS#1 v1.5[40] (WIN_CERT_TYPE_EFI_PKCS115)

0x0EF1 Firma UEFI encapsulada (WIN_CERT_TYPE_EFI_GUID). Actualmente existen dos ti-pos de firmas asociadas:

• EFI_CERT_TYPE_RSA_2048_SHA256_GUID, que incluye la clave pública RSA ysu firma en formato PKCS#1 v1.5[40].

• EFI_CERT_TYPE_PKCS7_GUID, que corresponde a una firma en formato PKCS#7según lo definido en su RFC[37].

Nada, el almacén no contiene firmas. Las validaciones de la imagen han de realizarseexclusivamente contra el resumen hash de la misma. (Típos EFI_CERT_SHA*_GUID).

28

Este procedimiento siempre está disponible, y siempre se verificarán los resultadosde la operación de hash contra las bases de datos

La especificación hace especial hincapié en que la validación de firmas PKCS#7 sehace contra cualquier nivel de la cadena de certificados X.509, y que se estos se validancontra cualquier firma de los mismos (EFI_CERT_X509_SHA* o EFI_CERT_RSA2048_GUID)[6, Nota Pag. 1812]

Cada tipo de certificado (WIN_CERT_TYPE_) se valida contra tipos de firma concretosen las bases de datos de firmas

Tipo de certificado WIN_CERT_TYPE_ Tipo de firma (EFI_CERT_)EFI_PKCS115 RSA2048_GUIDEFI_GUID + EFI_CERT_TYPE_RSA2048_SHA256_GUID RSA2048_GUIDEFI_GUID + EFI_CERT_TYPE_PKCS7_GUID RSA2048_GUIDPKCS_SIGNED_DATA X509_GUID

X509_SHA256_GUIDX509_SHA384_GUIDX509_SHA512_GUID

Ningún certificado (siempre se verifican) SHA1_GUIDSHA224_GUIDSHA256_GUIDSHA384_GUIDSHA512_GUID

Cuadro 6.2: Relación tipos de certificado PE/COFF con las posibles entradas en la basede datos de firmas. Datos de [6, Table 204]

Cuando se valida una imagen de un ejecutable, sea contra la lista que sea (blanca,negra, o de recuperación), se intenta validar primero al menos uno de certificados delejecutable. Si no se encuentra una forma de validar ninguno de dichos certificados, o notiene ningún certificado, se comprueba entonces los diferentes hashes de la lista. Si novalida ningún elemento, se afirma entonces que la lista no contiene al ejecutable.

El flujo para validar un ejecutable en Secure Boot comprende los pasos descritos en lafigura 6.3.

29

Sí¿Está SecureBootActivo o en Audit?

Se quiere cargar una imagen DXE

No

¿Tiene un origen considerado seguro?

Sí

Carga con éxito Se verifica contra DB

¿Está SecureBoot en

Audit?

No

Se agrega información de

debug a una variable UEFI

Sí

No

Se verifica contra DBX

Sí

No

Sí

¿Por un certificado con fecha de revocación no nula (0)?

Se verifica que la entidad TSA del certificado exista en DBT

¿Está presente en DB?

¿Está presente en DBX?

¿Está SecureBoot en

Audit?

No

No

Sí

¿Tiene fecha de emisión firmada el ejecutable? Sí

No

¿Es anterior la fecha de emisión del ejecutable que la fecha de revocado

del certificado DBX?

No

Sí

¿Existe el certificado de ese TSA en DBT? No

Sí

No

Sí

Falla la carga¿Existe alguna excepción en la política de seguridad para este

fichero?

Sí No

Figura 6.3: Flujo de Secure Boot

6.1.3. Microsoft UEFI CA

Las claves existentes en la variable DB son las que permiten la carga de ejecutablesUEFI. Dado que no existe una entidad central de certificación (CA)11 regida por el UEFIForum, son los vendedores de las placas bases los que determinan que certificados sonagregados a dichas bases de datos. Un cliente puede llegar a un acurdo con un vendedorde sistemas para que incluya, en producción, ciertos certificados, para acelerar grandesinstalaciones.

Mientras que los vendedores pueden optar por cargar las claves que así deseen (e inclusobloquear las modificaciones no permitiendo modificar o reiniciar PK o KEK), por motivoscomerciales la mayoría de vendedores siguen las certificaciones de Windows, necesariaspara vender productos Microsoft Windows Certified. En dichas certificaciones, exige quelos equipos tengan instalado en KEK la clave Microsoft Corporation KEK CA 2011, y enDB la clave Microsoft Windows Production PCA 2011. [41]

Opcionalmente, algunos vendedores incluyen también la clave Microsoft CorporationUEFI CA 2011, así como otras claves propias, o de otros sistemas operativos, como RedHat o Canonical. Esta clave es la clave conocida como el Microsoft UEFI CA. Microsoftfirma con esta clave programas destinados a ser usados como cargadores de arranque, trasauditar y dar un visto bueno a su seguridad.12 El programa tiene un coste ligado a laverificación de la entidad de certificación Verisign. [42]

6.2. UEFI TCG Measured Boot

El consorcio TCG13 publica una serie de estándares[28][7] por los cuales se pretendepoder atestiguar el estado de una máquina, estableciendo que la secuencia de arranque deesta no ha sido modificada. Para ello, se instala en la plataforma un dispositivo conocidocomo TPM14[43][44][45]. Este dispositivo es capaz de almacenar información de forma novolátil, y almacenar secretos. Estos dispositivos hardware tienen una versión de la especi-ficación asociada, y únicamente operan en dicho modo, son inmmutables desde el exterior.El consorcio TCG certifica que el hardware opera adecuadamente y cumple los estánda-res de seguridad Common Criteria[46] En este documento se desarrollará la especificaciónTPM 1.2.

Una de las características principales de Measured Boot es que no realiza ningunaacción activa, por lo que no previene la ejecución de ejecutables, ni realiza el mismo lasmediciones del sistema. La especificación establece que valores han de ser otorgados alTPM durante el arranque del sistema, para que este realice operaciones hash, irreversiblesy reproducibles. Mediante la carga en un registro de diferentes eventos de arranque, asícomo los valores acumulados de las diferentes mediciones realizadas, se puede determinarsi el equipo ha sufrido alguna modificación entre distintos arranques.

11Certificate Authority12Una característica importante del programa es que Microsoft no firma programas bajo la licencia

GPLv3, ya que requeriría que Microsoft ofreciese acceso libre a la clave privada.13Trusted Computing Group14Trusted Platform Module

31

El TPM dispone de unos “registros”, denominados PCRs, en los cuales la única formade almacenar información es agregándola al valor anterior. Cuando este se reinicia, se fijana valores concretos

Las diferentes variables y elementos que se cargan en el TPM, son introducidas por unsoftware residente en el firmware (parte de la BIOS UEFI). Esta pieza es el origen de todala confianza en este sistema, y se denomina Static Core Root-of-Trust Module (S-CRTMo SRTM).15. Si esta pieza de software es maliciosa, se destruye toda la confianza en elmismo, ya que podría realizar mediciones falsificadas, indiscernibles para el TPM, y porello indiscernibles para un sistema de atestiguado remoto.

El estándar especifica que valores han de ser almacenados, cómo se crea el registrode arranque, y las diferentes particularidades que se puedan dar en este proceso. [7] Larelación a alto nivel de que valores son registrados en que registro puede ser encontradaen la figura 6.4

Figura 6.4: Mapa de los componentes medidos en los PCR’s, Unified EFI, [7, Fig. 76]

El valor de los registros puede ser posteriormente leído por el sistema operativo, poderatestar el arranque, y sellar secretos agregando valores a los PCRs.

15Existe también un modo de arranque seguro para máquinas virtuales, conocido como Dynamic-CRTM

32

C:\tfg\Codigo\Measured Boot Tool\x64\Release>PCPTool.exe GetPCRs<PCRs><PCR Index="00">603e988f9bd980e079c916b95e1ed708e19d1246</PCR><PCR Index="01">24f9829d949f1c455e3a0557afea0bc4496baa3f</PCR><PCR Index="02">28e37571aa00c95a368d4101a008b3355920e79e</PCR><PCR Index="03">3a3f780f11a4b49969fcaa80cd6e3957c33b2275</PCR><PCR Index="04">e9988241fd7d6b2d4417edd7a5ae736c3b53e976</PCR><PCR Index="05">3a3f780f11a4b49969fcaa80cd6e3957c33b2275</PCR><PCR Index="06">3a3f780f11a4b49969fcaa80cd6e3957c33b2275</PCR><PCR Index="07">3a3f780f11a4b49969fcaa80cd6e3957c33b2275</PCR><PCR Index="08">0000000000000000000000000000000000000000</PCR>[...]<PCR Index="22">ffffffffffffffffffffffffffffffffffffffff</PCR><PCR Index="23">0000000000000000000000000000000000000000</PCR></PCRs>

Figura 6.5: Ejemplo del contenido de los PCRs, recuperado por por Measured Boot Tool

6.3. Consideraciones de seguridad en arranques seguros

Estos planteamientos de arranque seguro inician su confianza en el firmware, asumiendoque este no es malicioso. Esto constituye el S-CRTM en el esquema de seguridad del TCG.Para evitar modificaciones a esta fase temprana, existen tecnologías como Intel Boot Guard(Verified Boot) o AMD Hardware Validated Boot. [21]

Aunque este cargador temprano esté protegido contra modificaciones, pueden existirdiversos errores en la implementación, existentes en el propio código de la BIOS, o enservicios relacionados (SMM y similares). Existen diversos ataques derivados de problemasen la implementación. [47] [16] [48] [49] [50] [51] [52] [5] [3]

Figura 6.6: Bios Attack Surfaces, Vincent Zimmer, Intel Corp, [5, Pag. 31]

Es por ello que es necesario seguir buenas prácticas, y controlar la seguridad tantológica como física de los equipos.

33

7 | ARRANQUE SEGURO DE SISTE-MAS OPERATIVOS

Para que una solución de Secure Boot mantenga confianza en el equipo una vez este haabandonado la fase de BDS y comience a ejecutar un sistema operativo, es necesario quese impidan las operaciones dañinas para el sistema. Esto requiere de la cooperación de lakernel del sistema, la cual ha detectar de forma activa que efectivamente se ha lanzado enmodo Secure Boot (verificando la variable UEFI), y estableciendo limitaciones que puedencomprometer la integridad del equipo.

Las operaciones normalmente restringidas son:

Operaciones de acceso directo a memoria (DMA) desde programas corriendo en elsistema, las cuales pueden suponer modificar la kernel desde procesos no privilegia-dos.

Cargar drivers/modulos en la kernel que no se encuentren firmados, o que esténfirmados por una autoridad en la que no se confía.

Operaciones que permitan modificar el comportamiento de la kernel del sistema,incluso por el superusuario.

Un problema de seguridad1, que permita ejecutar código no autorizado en modo privi-legiado (como la kernel), destruye la confianza en el sistema. Es por esto que para que unsistema mantenga la seguridad otorgada en el arranque, ha de únicamente cargar códigoprivilegiado que haya sido auditado, compilado en un entorno controlado, verificable2 yseguro, y finalmente protegida su integridad mediante una firma digital.

Los diferentes sistemas operativos hacen uso de su propia entidad centralizada paraauditar y controlar dichos cambios, y son los que proveen los procedimientos para poderfirmar código que luego corra en esos sistemas.

Se describe a continuación el proceso de arranque de los diferentes sistemas operativosmayoritarios, y como modifican su comportamiento si disponen de un entorno de arranqueSecure Boot.

1Habitualmente asociado a un exploit de la kernel2Que el resultado de la compilación sea reproducible, para poder auditar desde un sistema externo,

sólo con el código final, que aplicando los pasos de compilado correspondiente se obtiene exactamentedichos ejecutables. Con esto, la confianza se transfiere al sistema de compilado, el cual puede a su vez serauditado.

34

7.1. Linux

La kernel de Linux normalmente se carga mediante un cargador de arranque, o bootloa-der3. Este programa se encarga de leer la imagen de la partición en la cual se encuentreinstalada, y en caso de ser “consciente” del estado Secure Boot, se encargará de verifi-car la validez de la firma digital de esta. La kernel validará los módulos (drivers) que seencuentren en el sistema de archivos cuando cargue, y los ejecutará únicamente si estánfirmados por alguna clave en la que se confía.

Actualmente, 3 distribuciones4 basadas en Linux que tienen una implementación com-pleta de Secure Boot, por lo que disponen de una cadena de confianza completa basada enla carga de drivers firmados, así como medidas para restringir el acceso desde los programasno privilegiados a la kernel.

1. Red Hat Linux 7

a) CentOS Linux 7b) Fedora Linux 18

2. SUSE Linux Enterprise 11

a) Open SUSE 12.3

3. Ubuntu Linux 16.04

Mientras que es una solución robusta, el usuario puede querer agregar módulos persona-lizados a la kernel, como los módulos DKMS5. Estos al no estar firmados por el fabricante,fallarían al cargar. Existen dos soluciones para ello, agregar entonces una clave adicionala DB, firmando entonces dichos módulos cuando sean compilados. Alternativamente sepuede usar “shim loader”, y permitir al sistema operativo gestionar sus claves.

7.1.1. Shim Loader

Dado que la mayoría de los equipos contienen la clave Microsoft UEFI CA en DB,las distribuciones antes mencionadas incluyen un cargador intermedio, conocido como“shim loader”. Este se encuentra firmado por Microsoft, y en su interior incluye la CAcorrespondiente al vendedor de su distribución. Con ello, se establece la confianza en unequipo con Secure Boot, sin tener que modificar entradas en DB.

shim almacena de forma similar a Secure Boot claves y firmas en variables UEFI, enuna lista denominada MOK6. Esta lista hace uso del formato de las listas de firmas descritas

3No es estrictamente necesario, ya que la kernel de Linux puede ser compilada para poder ser lanzadadirectamente como un ejecutable UEFI, sin necesidad de usar un bootloader. Estas imágenes son conocidascomo EFI Stub[53]. Como esta solución es poco flexible, normalmente las distribuciones hacen uso delanzadores de arranque como GRUB para cargar la kernel.

4Y otras derivadas de ellas5Dynamic Kernel Module Support6Machine Owner Key

35

en UEFI. A diferencia de Secure Boot, no se espera que se modifiquen dichas variablesa través del sistema operativo, sino que se gestione directamente mediante una interfazgráfica durante el arranque del sistema. Esta interfaz gráfica puede protegerse con unacontraseña.

Variable UsoMokSBState Deshabilitar Secure Boot para el siguiente ejecutableMokDBState Usar la lista DB para validar, o solo MOKMokPWStore Contraseña para el gestor MOK.MokList Lista blanca (Se copia en MokListRT para el SO)MokListX Lista negra (Se copia en MokListXRT para el SO)

Cuadro 7.1: Variables UEFI usadas internamente por shim

El sistema operativo puede solicitar cambios a shim, dejando para ello mensajes enforma de variables UEFI (Ver cuadro 7.2). La próxima vez que se lanza, shim compruebasi tiene mensajes pendientes, y pertinentemente solicita al usuario las contraseñas y/oconfirmaciones correspondientes.

Variable Variable de validado UsoMokNew MokAuth Agregar valores a la lista blancaMokDel MokDelAuth Eliminar valores de la lista blancaMokXNew MokXAuth Agregar valores a la lista negraMokXDel MokXDelAuth Eliminar valores de la lista negraMokDB (Des)habilitar el uso de la lista MOKMokSB (Des)habilitar Secure Boot en shimMokPW Crear o cambiar la contraseñaSHIM_VERBOSE Habilitar el modo prolijo en shim

Cuadro 7.2: Variables UEFI reconocidas por shim como mensajes, para solicitar operacio-nes

Si se está haciendo uso de Secure Boot, el cargador de arranque GRUB2 verifica quela imagen del sistema operativo es válida invocando a shim, un proceso que evita unaduplicidad de código innecesaria.

Cuando finalmente se otorga el control a la kernel de Linux, esta usará los certificadosdel vendedor con los que se ha compilado. Como este modelo de seguridad no permitela inclusión de módulos personalizados, Red Hat recientemente ha propuesto incluir enla kernel el modelo de seguridad usado en Red Hat Linux. Dicho modelo hace uso de lasvariables de Secure Boot DB y DBX, así como (si está activa) MOK. Con esto, la kernel no solotiene como clave principal la creada por el distribuidor de la distribución, sino que puedeusar claves las cuales a su vez pueden ser administradas, habilitándose así la posibilidadde continuar usando Secure Boot y hacer uso de módulos DKMS, si estos se firman trascompilarse con una clave en una de las listas blancas. [54]

36

7.1.2. Particiones cifradas

La kernel de Linux soporta cifrar de forma transparente para las aplicaciones disposi-tivos de bloques. Para ello, hace uso del sistema de virtualizado de dispositivos de bloque(LVM2), incluido en la kernel desde la versión 2.6 [55]. Con LVM2, se abstrae el almace-namiento físico de los volúmenes lógicos con los que opera el sistema. En las operacionesde lectura y escritura se aplica entonces operaciones criptográficas por las cuales se cifrao descifra el contenido del volumen virtual. El encargado de dichas operaciones es el mó-dulo dm-crypt. Este módulo es normalmente integrado dentro de la kernel en las grandesdistribuciones.

La inclusión de dm-crypt en la kernel, y el uso de Secure Boot permiten almacenar elcontenido cifrado en el volumen de almacenamiento, y provee una forma de validar quela kernel que se va a cargar no ha sido maliciosamente modificada, sin al menos habermodificado también el firmware del equipo.

Los metadatos así como la gestión de claves es comúnmente realizada mediante el usodel estándar LUKS7 [56]. Esto permite la interoperabilidad entre diferentes versiones dedm-crypt.

Esta solución permite realizar FDE8, únicamente residiendo en el perímetro exterior laimagen de la kernel y el cargador de arranque, habilitando el arranque seguro de equiposLinux, desde una partición cifrada.

7.2. Windows

Microsoft hace un uso activo de Secure Boot desde la versión 8 de su sistema operativoWindows, aunque soportaba el arranque UEFI desde Windows 7. En su secuencia dearranque, Windows incluye un bootloader, denominado Windows Boot Manager (bootmgr).Este se instala en la partición ESP, en la ruta\EFI\Microsoft\Boot\bootmgfw.efi. bootmgr busca almacenes BCD en las diferentesunidades ESP que estén disponibles en el sistema, localizando la suya mediante un valorGUID almacenado en la variable UEFI asociada, BOOT####. 7.1

Una vez localizado el almacén BCD, este se procesa. En el, se incluye tanto la confi-guración de bootmgr, como la localización y configuración de herramientas de diagnosticocomo Windows Memory Diagnostic, los diferentes lanzadores de Windows disponibles, asícomo la configuración de cada Windows Boot Loader, que contiene las preferencias conla que será lanzado Windows, como cual es la ruta de la carpeta de sistema Windows, ypropiedades adicionales. 7.2

Mientras que en el comportamiento habitual es obligatoria la firma de los drivers desistema, esta puede ser deshabilitada completamente modificando parámetros del arranquedel sistema, así como el uso de NX9. Si se encuentra activo Secure Boot, se habilita el modode arranque “Trusted Boot”

7Linux Unified Key Setup8Full Disk Encryption, que todo el sistema de archivos se encuentre cifrado9Execute Disable, también conocido como Data Execution Prevention

37

Option: 00. Variable: Boot0001Desc - Windows Boot ManagerDevPath - HD(1,GPT,C12A7328-F81F-11D2-BA4B-00A0C93EC93B,0x28,0x20000)/\EFI\Microsoft\Boot\bootmgfw.efiOptional- Y00000000: 57 49 4E 44 4F 57 53 00-01 00 00 00 88 00 00 00 *WINDOWS.........*00000010: 78 00 00 00 42 00 43 00-44 00 4F 00 42 00 4A 00 *x...B.C.D.O.B.J.*00000020: 45 00 43 00 54 00 3D 00-7B 00 39 00 64 00 65 00 *E.C.T.=...9.d.e.*00000030: 61 00 38 00 36 00 32 00-63 00 2D 00 35 00 63 00 *a.8.6.2.c.-.5.c.*00000040: 64 00 64 00 2D 00 34 00-65 00 37 00 30 00 2D 00 *d.d.-.4.e.7.0.-.*00000050: 61 00 63 00 63 00 31 00-2D 00 66 00 33 00 32 00 *a.c.c.1.-.f.3.2.*00000060: 62 00 33 00 34 00 34 00-64 00 34 00 37 00 39 00 *b.3.4.4.d.4.7.9.*00000070: 35 00 7D 00 00 00 00 00-01 00 00 00 10 00 00 00 *5...............*00000080: 04 00 00 00 7F FF 04 00- *........*

Figura 7.1: Contenido de una variable WBM en la variable UEFI boot, interpretada porUEFI Shell

Windows Boot Manager--------------------identifier {9dea862c-5cdd-4e70-acc1-f32b344d4795}device partition=\Device\HarddiskVolume5path \EFI\Microsoft\Boot\bootmgfw.efidescription Windows Boot Managerlocale en-usinherit {7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}default {8631f671-c337-11e6-b0e9-938facbc3f2e}resumeobject {8631f670-c337-11e6-b0e9-938facbc3f2e}displayorder {8631f671-c337-11e6-b0e9-938facbc3f2e}toolsdisplayorder {b2721d73-1db4-4c62-bf78-c548a880142d}timeout 30

Windows Boot Loader-------------------identifier {8631f671-c337-11e6-b0e9-938facbc3f2e}device partition=C:path \Windows\system32\winload.efidescription Windows 10locale en-usinherit {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}isolatedcontext Yesosdevice partition=C:systemroot \Windowsresumeobject {8631f670-c337-11e6-b0e9-938facbc3f2e}nx OptOutbootmenupolicy Standardhypervisorlaunchtype Off

Figura 7.2: Ejemplo del contenido de BCD y WBM

38

7.2.1. Windows Trusted Boot

Este modo de arranque se habilita si el cargador (Windows Boot Manager) es lanzadocon Secure Boot habilitado. En este modo de arranque, se ignoran donde se ignoran lasopciones de NX, de firmado de drivers y el debug del sistema, habilitándose las dos. Adi-cionalmente, se lanza el módulo Early Launch Anti-Malware (ELAM) que tenga registradoel sistema, el cual verifica que el resto de elementos en la secuencia de arranque no seandañinos. Este módulo no es un antivirus completo, sino que su comportamiento es másparecido al de una lista negra [57] 7.3. Los drivers han de estar firmados por una entidadcertificadora en la que el sistema operativo confíe, o bien directamente por Microsoft, me-diante el programa WHQL. Los drivers modificados, o sin firma, no se pueden ejecutar eneste modo. [58]

Figura 7.3: Flujo de arranque Windows Trusted Boot / Measured Boot, [8]

39

7.2.2. Windows Measured Boot

Si se encuentra disponible y habilitado un TPM, Windows permite el uso de funcio-nes de cifrado de disco con BitLocker (incluido FDE), y existe la posibilidad de realizaratestados remotos del proceso de arranque del equipo. Existen funciones avanzadas másrecientes, que se comentarán en 9

BitLocker funciona con un TPM almacenando una parte de la información secretanecesaria para el descifrado del mismo en el TPM. Esta únicamente se liberará en el casode que se conserve los mismos valores para la secuencia de Trusted Boot, y por ende losregistros PCR[0:8]. Opcionalmente se puede operar sin uno, almacenando entonces en unaunidad externa al equipo (un pendrive o similar) parte del secreto necesario para descifrarel disco, cifrada.

El atestado remoto permite a una entidad externa verificar la secuencia de arranquedel sistema operativo. Microsoft no hace un uso activo de esta funcionalidad, pero exis-ten herramientas no oficiales que constituyen una prueba de concepto funcional, comoMeasured Boot Tool. [57]

7.3. Android

La secuencia de arranque de Android es específica de cada dispositivo. En los sistemasARM (como teléfonos móviles, tablets y similares), es la empresa que lo comercializa laencargada de proveer un bootloader. En la mayoría de los dispositivos, este se encuentrafirmado, y se hace uso de un coprocesador de seguridad incluido en el procesador principal(ARM Trusted Zone) para validar la imagen previa a cargarla.

Existe una imagen de recuperación, para poder restaurar la partición principal encaso de que esta falle. Este modo de recuperación recibe el nombre de fastboot. Algunosfabricantes habilitan combinaciones especiales de botones para forzar este modo en unarranque normal.

Una vez que ha cargado el bootloader, este se encarga de lanzar la kernel, la cualse inicializará, a su vez cargando los diferentes drivers de una forma similar a un sistemaLinux. Una vez ha cargado, ejecutará el sistema de arranque init de Android, que arrancarálos diferentes servicios de espacio de usuario. [59]

7.3.1. Verified Boot

AOSP10 provee la especificación para el comportamiento en el arranque seguro deAndroid, Verified Boot, así como un procedimiento para establecer confianza en la imagende sistema, dm-verity. [10]

El proceso de verified boot establece como se ha de comportar el bootloader en casode que no se complete con éxito la validación, o que se haya modificado el cargador

10Android Open Source Project, la entidad bajo la cual Google publica código libre relacionado conAndroid

40

por el usuario (o un software malicioso) 7.4. Si el dispositivo es de tipo A, no admitemodificaciones al sistema de arranque. Si es de tipo B, si que existe la posibilidad dedesbloquear el bootloader, posiblemente eliminando los secretos del dispositivo HSM11.

Figura 7.4: Flujo de comportamiento de Verified Boot, AOSP [9]

Una vez iniciado el bootloader, la partición de sistema se verifica mediante el uso de unárbol de hashes criptográficamente seguros 7.5 Para verificar una posición en el árbol, sevalida el nivel inferior. Esto permite validar únicamente los bloques cuando se leen, peroasegurar que su valor es esperado. Se aplica a nivel de bloques, no a un nivel lógico.

Figura 7.5: Tabla de hash dm-verity, AOSP [10]

11Hardware Security Module

41

8 | SECURE BOOT EN FREEBSD

FreeBSD no hace un uso activo de Secure Boot. Mientras que el bootloader UEFI deFreeBSD puede ser agregado a las listas de claves para que este se inicie, validándose laintegridad del mismo, este no instruye a la kernel a hacer algún uso especial.

El proceso de arranque UEFI de FreeBSD 11.0 comienza cuando se ejecuta el lanzadorboot1.efi. Este cargador se encarga de leer en memoria un fichero de configuración paradespués transmitírselo a la segunda fase del proceso de carga. Una vez leído, el cargadorbusca particiones UFS o ZFS, comenzando desde el disco donde se encuentra ESP, yposteriormente leyendo el resto de unidades disponibles. Dentro de ellas, busca el fichero/boot/loader.efi, que corresponde a la segunda fase del proceso de arranque, LOADER[60]. En un entorno UEFI, FreeBSD no necesita hacer uso de un servidor BTX parainicializar las diferentes tablas del sistema (SMBIOS, ACPI, y otras) [61, 1.6]

loader.efi (LOADER) actúa como el cliente BTX. Este es el encargado de cargar lakernel, de una forma similar a lo que se podría esperar de un bootloader como GRUB2.De forma análoga a GRUB, también dispone de una consola con la que interactuar conel, y muestra gráficos con las opciones de arranque. [62]

Una vez la kernel de FreeBSD es lanzada, esta puede también estar compilada conGELI, un sistema de cifrado similar al de Linux (LVM2 + dm-crypt + LUKS), en el cualse almacenan mediante un sistema de almacén de claves y metadatos la información paramontar un sistema de archivos completamente cifrado. Es por esto que el soporte de FullDisk Encryption es posible. [63]

El modelo de Secure Boot que se propone está dividido en tres fases:

Carga de módulos de kernel firmados

Firma de ejecutables UEFI

Integrado con Shim(Fedora)

Este modelo es genérico para distribuciones FreeBSD y derivadas, por lo que puedeser integrado como parte de la solución de seguridad de distribuciones orientadas a actuarcomo equipos de seguridad (del tipo firewalls, IDS, etc), como por ejemplo OPNSense,pfSense, y otras.

8.1. Carga de módulos firmados

La kernel de FreeBSD permite la carga dinámica de módulos/drivers en la misma. Paraello, se hace uso de la llamada de sistema (syscall) KLDLOAD [64]. Esta es la encargada deverificar el fichero, así como verificar su extensión (.ko) y incluirla en el sistema. Si elproceso es llevado a cabo con éxito, esta estará cargada en el sistema. En caso contrario,se emitirá un error.

42

El código relacionado con el syscall KLDLOAD se encuentra en el código fuente dela Kernel, en /sys/kern/kern_linker.c. La función que se invoca con el syscall essys_kldload, la cual a su vez invoca diversos métodos intermedios. El momento en el cualse verifica el fichero para realizar la carga se encuentra en el método linker_load_file.8.1.

Listing 8.1: linker_load_file (/sys/kern/kern_linker.c)1 static int2 linker_load_file(const char *filename, linker_file_t *result)3 {4 linker_class_t lc;5 linker_file_t lf;6 int foundfile, error, modules;78 /* Refuse to load modules if securelevel raised */9 if (prison0.pr_securelevel > 0)

10 return (EPERM);1112 sx_assert(&kld_sx, SA_XLOCKED);13 lf = linker_find_file_by_name(filename);14 if (lf) {15 KLD_DPF(FILE, ("linker_load_file:␣file␣ %s␣is␣already␣loaded,"16 "␣incrementing␣refs\n", filename));17 *result = lf;18 lf->refs++;19 return (0);20 }21 foundfile = 0;22 error = 0;23 // Insertar aqui validacion OpenSSL (EVP_DigestVerifyInit /

EVP_DigestVerifyUpdate / EVP_DigestVerifyFinal)

En dicha localización se puede agregar una verificación que compruebe que en la rutadonde reside el fichero .ko del módulo, exista también un fichero con una firma digitalautorizada, con el hash del fichero firmado por una clave autorizada en el sistema, la cualpuede estar integrada en la propia kernel, o almacenada en una variable de entorno desolo lectura del sistema, accesible vía sysctl1. En caso de que el fichero de verificación noexista o falle al validar, y el sistema se encuentre en modo Secure Boot, esta ejecución sedetendría.

Una vez compilada la kernel, se encuentra en una carpeta tanto la kernel como todoslos módulos .ko que se han generado. Todos estos ficheros pueden entonces ser firmadoscon la clave privada. Una vez realizado esto, dicha kernel se podría distribuir mediante elsistema de distribución de paquetes de FreeBSD, PKG, el cual ha sido configurado con unrepositorio centralizado controlado por el emisor.

Tanto para la verificación como para la emisión de firmas digitales, se puede hacer1Un ejemplo podría ser security.secureboot.moklist

43

uso de OpenSSL, una librería ya disponible en el sistema para el realizado de operacionescriptográficas.

8.2. Firma de ejecutables UEFI

FreeBSD dispone nativamente de una herramienta para firmar ficheros PE/COFFsegún el estándar UEFI, denominada uefisign. Es necesario firmar los dos ficheros quecomponen el arranque, tanto boot1.efi (residente en ESP), como loader.efi (residenteen /boot/loader.efi en una partición de FreeBSD UFS/ZFS). Esto es necesario ya queboot1.efi es conforme al estándar y carga loader.efi haciendo uso de la función provistapara ello del estándar UEFI, LoadImage(), lo que supone que se verifique también estesegundo ejecutable.

Una vez firmados los ficheros, se agrega a DB la clave pública con la que se han firmadolos mismos, y se completa el arranque, tanto si se hace uso de shim(el cual también ha deestar adecuadamente firmado) como si se lanza directamente.

8.3. Integrado con Shim (Fedora/Red Hat Linux)

Un problema a la hora de personalizar la instalación sería cómo cargar en el sistemaclaves ajenas al mismo, sin vulnerar la cadena de confianza de Secure Boot. Para ello,se propone hacer uso de la arquitectura de seguridad de Fedora/Red Hat Linux. Estecontempla que se confíe también en las claves disponibles en la lista MOK, regida por shim.

Según este modelo, podría ser la propia fundación FreeBSD la que publicase una kernely módulos firmados, de forma análoga a como se realiza en Fedora/Red Hat. Para poderentonces personalizar el sistema, se puede agregar una clave específica controlada por eladministrador en la lista MOK.

Para implantar este modelo, es necesario modificar boot1.efi para que permita rea-lizar una carga de ejecutables sin confianza, como shim. Esto permitiría establecer unacadena de arranque por la cual shim verifique boot1.efi, el cual se comporta de forma si-milar a GRUB, pero en vez de usar a shim a continuación para verificar una kernel, usarlopara verificar loader.efi. En el momento que loader.efi se haya verificado correc-tamente, boot1.efi pasará a ejecutarlo, sin hacer uso de LoadImage(), comportándosecomo shim. loader.efi podrá entonces cargar la variable MokListRT, y realizar la cargade la kernel una vez esta haya sido verificada.

44

Cargador BDS

Afterlife

LoadImage() ShimRed Hat / Fedora carga Lista MOK usada boot1.efi

(firmado FreeBSD)ejecuta

(sin loadimage)

Verificación SHIM

(boot1.efi)

Localiza y carga

loader.efi

Verificación SHIM

(loader.efi)usaloader.efi

(firmado FreeBSD)ejecuta

(sin loadimage)Verificación

kernel

CertificadoOficial

FreeBSD

CertificadoPersonal(pfSense)

Firma Kernel(FreeBSD)

Firma KernelPersonal(pfSense)

Kernel Oficial

Kernel Personal CertificadoOficial

FreeBSD

embebido

Kernel(modo SecureBoot)

Carga de módulos

kernel

Agregar lista MOK a sysctl

Modulo Kernel Oficial

Firma Modulo

(FreeBSD)

Modulo Kernel Propio

Firma Modulo

(FreeBSD)

Modulo Kernel Propio

Carga no permitidakldload

Figura 8.1: Flujo de Secure Boot para FreeBSD, haciendo uso de shim

9 | CONCLUSIONES Y LÍNEAS FU-TURAS

Tras el análisis del estado del arte en la tecnología de arranque seguro disponible parael público general, se puede concluir que es razonable la construcción de sistemas cuyoarranque sea auditable, y cuyos ejecutables estén verificados en una cadena de confianza.También es importante tener en cuenta la seguridad física de dichos dispositivos, frente alos ataques evil maid.

En el desarrollo de este trabajo, el autor se ha centrado mayoritariamente en la pro-tección de la ejecución del sistema operativo, pero recordando que la kernel es responsablede la seguridad una vez iniciado el sistema operativo, se puede profundizar más en lossiguientes tópicos:

9.1. Fortificado de la kernel

Existen proyectos orientados a fortificar la kernel, auditándola y haciendo uso de buenasprácticas. Estos se encuentran disponibles tanto en sistemas con kernels Linux (Security-Enhanced Linux, grsecurity), como BSD (HardenedBSD, TrustedBSD). Incluir las mejorasde estos proyectos en la kernel de las distribuciones de seguridad es un proceso por el cualse podría mejorar la seguridad en equipos expuestos a ataques.

9.2. Fortificado hardware

La seguridad hardware es un aspecto muy importante en equipos móviles como portá-tiles. Existen proyectos dedicados a personalizar los sistemas de arranque de estos equipospara minimizar el posible impacto de errores en implementaciones no auditadas, comopueda ser Intel Management Engine (ME). [65]

9.3. Hipervisores

Algunos sistemas operativos como Qubes hacen uso de máquinas virtuales independien-tes para compartimentar el sistema operativo, permitiendo exclusivamente comunicacionescontroladas entre las mismas, a través de una intranet virtual. Con ello se persigue eliminarvulnerabilidades en las máquinas, orquestandolas mediante un hipervisor central.[66].

Mientras que dicha implementación es abierta y auditable, existe al menos una alter-nativa menos confiable.

Microsoft ha comenzado a popularizar Device Guard, que incluye la denominada Vir-tualization Based Security (VBS). Esta tecnología persigue colocar la ejecución de la kernel

46

y el gestor de los ejecutables permitidos (Code Integrity) en una máquina supervisada porel hipervisor Hyper-V[67]. Otro objetivo de ello es establecer una zona no accesible másque por la kernel donde se almacenen diferentes secretos, como puedan ser credencialesKerberos, o certificados digitales, con una tecnología denominada Credential Guard.

Mediante el uso de VBS, se pretende asegurar una separación W|X en todas las pá-ginas de la kernel, separación con la cual se pretende paliar vectores de ataque usadoscontra la kernel, como los desbordamientos de memoria. Si la kernel y el hipervisor fun-cionan adecuadamente, sistemas como Credential Guard se mantienen protegidos contralas aplicaciones de espacio de usuario. [68]

Como parte de Device Guard, se deben bloquear las opciones relacionadas con SecureBoot, virtualizado de CPU1 y IOMMU2.[69] Además, se requiere que no se pueda ignorarlas tablas de Secure Boot por parte del usuario, y que necesariamente se haga uso de algunatecnología de verificación de la integridad del firmware de arranque (SEC)[41]. Como yase ha criticado en [30] y [31], esta aproximación deja bastante que desear hacia la libertaddel usuario, y no necesariamente es más segura.

Adicionalmente, la versión 1607 de Windows 10 habilita Hyper-V automáticamente, loque ha causado problemas a usuarios del sistema de virtualizado VirtualBox, que no haceuso de Hyper-V.[70]3.

9.4. Securizado de máquinas virtuales

El uso de máquinas virtuales e hipervisores requiere de ciertas tecnologías hardwa-re para correctamente aislarlas del sistema anfitrión, y tener un rendimiento aceptable(IOMMU, las extensiones de virtualizado AMD-V/VT-x). Existen también tecnologíasdesarolladas para incrementar la confianza en un sistema potencialmente hostil

Intel TXT (Trusted Execution Technology) | AMD SVM (Secure Virtual Machine).Estas tecnologías permiten lanzar máquinas virtuales intentando desacoplarse delentorno anfitrión, y usando el TPM para medir su lanzamiento. [71] Ambas hacenuso del concepto de confianza D-CRTM (DTRM). Aunque existan algunos ataques[72][73], son un punto de partida. Aun así, es necesaria confianza total en otroscomponentes en el arranque [74].

AMD SEV (Secure Encrypted Virtualization) / SME (Secure Memory Encryption).SME es una tecnología que permite cifrar la memoria del sistema, controlado me-diante un coprocesador (AMD Secure Procesor (SP)) existente en la CPU, un bitpara indicar si la región está cifrada, y acelerado mediante motores AES hardware

1Intel VT-x, AMD-V2Intel VT-d, AMD IOMMU3El autor también sufrió dicho error, y a pesar de instar al sistema operativo a eliminar Hyper-V,

y aunque este lo reportaba como desinstalado, no consiguió eliminar Hyper-V. Esto sucedió tras ha-ber intentado habilitar (sin éxito) Secure Guard VBS, y tuvo que destruir (renombrando) el ficheroWindows/System32/hvax64.exe. Una vez destruido, Hyper-V finalmente dejó de iniciarse con el sistema.Mientras que el autor desconoce si están correlacionados los hechos, le preocupa el hecho de no poderdeshabilitar de una forma normal dicha funcionalidad de hipervisor

47

en la interfaz de memoria del procesador. SEV permite aislar máquinas virtualesentre sí, y protegerlas del hipervisor, mediante el uso de SVM. Cada VM disponede una clave propia, protegida en el SP. Las regiones de memoria que se quieranentonces compartir con el hipervisor, controladas por la VM, se cifrarán con la clavedel hipervisor, marcándose por la máquina virtual como públicas.[75]4

4Estas tecnologías aún no han llegado a mercado, se espera su salida con la microarquitectura ZEN deAMD.[76]

48

Bibliografía

[1] John MacInnis, Intel, “Implementing Firmware on Embedded Intel ArchitectureDesigns,” Enero 2009. [Online]. Available: https://www-ssl.intel.com/content/dam/www/public/us/en/documents/white-papers/ia-firmware-implementation-paper.pdf

[2] Intel Corporation, “Intel Technology Journal, Volume 15, Issue 1,” Octubre2011. [Online]. Available: http://www.intel.com/content/dam/www/public/us/en/documents/research/2011-vol15-iss-1-intel-technology-journal.pdf

[3] Xeno Kovah and Corey Kallenberg and John Butterworth and Sam Cornwell,MITRE, “Analyzing UEFI BIOS from Attacker & Defender Viewpoints,” Octubre2014. [Online]. Available: https://www.blackhat.com/docs/eu-14/materials/eu-14-Kovah-Analyzing-UEFI-BIOSes-From-Attacker-And-Defender-Viewpoints.pdf

[4] Unified EFI, Inc, “UEFI Platform Initialization Specification, Version 1.5,” Septiem-bre 2016. [Online]. Available: http://www.uefi.org/sites/default/files/resources/PI%201.5.zip

[5] Vincent Zimmer, “Developing Best-In-Class Security Principles with Open SourceFirmware,” Septiembre 2015. [Online]. Available: https://firmware.intel.com/sites/default/files/STTS003%20-%20SF15_STTS003_100f.pdf

[6] Unified EFI, Inc, “Unified Extensible Firmware Interface Specification, Version 2.6,”Enero 2016. [Online]. Available: http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf

[7] Trusted Computing Group, “TCG EFI Protocol Specification, Level 00 Revision00.13,” Marzo 2016. [Online]. Available: https://www.trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-rev13-160330final.pdf

[8] Microsoft Corporation, “Secure the Windows 8.1 boot process.” [Online]. Available:https://technet.microsoft.com/en-us/windows/dn168167.aspx

[9] Android Open Source Project, “Verifying Boot.” [Online]. Available: https://source.android.com/security/verifiedboot/verified-boot.html

[10] ——, “Verified Boot.” [Online]. Available: https://source.android.com/security/verifiedboot/index.html

[11] P. Dice, Quick Boot: A Guide for Embedded Firmware Developers. Intel Press,Mayo 2013. [Online]. Available: http://learning.acm.org/books/book_detail.cfm?id=2531443&type=24

[12] Jenny M. Pelner and James A. Pelner and Intel Corporation, “Minimal IntelArchitecture Boot Loader: Bare Bones Functionality Required for Booting an IntelArchitecture Platform,” Enero 2010. [Online]. Available: https://www.cs.cmu.edu/~410/doc/minimal_boot.pdf

49

[13] Intel Corporation, “ATX12V Power Supply Design Guide,” March 2005. [Online].Available: http://formfactors.org/developer/specs/ATX12V_PSDG_2_2_public_br2.pdf

[14] Pete Dice, “Booting an Intel Architecture System, Part I: Early Initialization,”Diciembre 2011. [Online]. Available: http://www.drdobbs.com/parallel/232300699

[15] Intel Corporation, “Intel 64 and IA-32 Architectures Software Developer’s Manual,”Septiembre 2016. [Online]. Available: https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf

[16] Nikolaj Schlej, “Fix it yourself: detecting and fixing UEFI firmware vul-nerabilities without access to it’s source code,” Noviembre 2015. [On-line]. Available: http://www.uefi.org/sites/default/files/resources/UEFI%20RoT%20white%20paper_Final%208%208%2016%20%28003%29.pdf

[17] Xeno Kovah and Corey Kallenberg, LegbaCore LLC, “Advan-ced x86: (BIOS and System Management Mode Internals) Uni-fied Extensible Firmware Interface (UEFI),” Octubre 2015. [Online].Available: http://opensecuritytraining.info/IntroBIOS_files/Day2_04_Advanced%20x86%20-%20BIOS%20and%20SMM%20Internals%20-%20UEFI.pdf

[18] Ben Hawkes, “Notes on Intel Microcode Updates,” Marzo 2013. [Online]. Available:http://inertiawar.com/microcode/hawkes_intel_microcode.pdf

[19] Daming D. Chen and Gail-Joon Ahn, “Security Analysis of x86 ProcessorMicrocode,” Diciembre 2014. [Online]. Available: http://inertiawar.com/microcode/hawkes_intel_microcode.pdf

[20] Unified EFI, Inc, “Advanced Configuration and Power Interface Specification,Version 6.1,” Enero 2016. [Online]. Available: http://www.uefi.org/sites/default/files/resources/ACPI_6_1.pdf

[21] Vincent Zimmer and Michael Krau, “Establishing the root of trust,” Agosto2016. [Online]. Available: http://www.uefi.org/sites/default/files/resources/UEFI%20RoT%20white%20paper_Final%208%208%2016%20%28003%29.pdf

[22] Unified EFI, Inc, “UEFI Shell Specification, Version 2.2,” Enero 2016. [Online].Available: http://www.uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pdf

[23] TianoCore, “OVMF.” [Online]. Available: http://www.tianocore.org/ovmf/

[24] ——, “EDK II.” [Online]. Available: http://www.tianocore.org/edk2/

[25] Tony Mangefeste, “Tianocore 2016 Updates,” Marzo 2016. [Online]. Availa-ble: http://www.uefi.org/sites/default/files/resources/UEFI_Plugfest_Tianocore_Update_March_2016%20rev20160324.pdf

[26] Microsoft Corporation, “Measured Boot.” [Online]. Available: https://msdn.microsoft.com/en-us/library/windows/desktop/hh848050.aspx

[27] ——, “Windows 8.1 boot security FAQ.” [Online]. Available: https://technet.microsoft.com/en-us/windows/dn168169.aspx

50

[28] Trusted Computing Group, “TCG EFI Platform Specification,” Marzo 2016.[Online]. Available: https://www.trustedcomputinggroup.org/wp-content/uploads/TCG-EFI-Protocol-Specification-.pdf

[29] ——, “TCG PC Client Specific TPM Interface Specification (TIS), Versión 1.3,” Mar-zo 2013. [Online]. Available: http://www.trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientTPMInterfaceSpecification_TIS__1-3_27_03212013.pdf

[30] Patrick Georgi, “Intel Boot Guard,” Febrero 2015. [Online]. Available: https://patrick.georgi.family/2015/02/17/intel-boot-guard/

[31] Matthew Garrett, “Intel Boot Guard, Coreboot and user freedom,” Febrero 2015.[Online]. Available: https://mjg59.dreamwidth.org/33981.html

[32] Roger Lai, AMD, “AMD Security and Server innovation,” Marzo 2013. [On-line]. Available: http://www.uefi.org/sites/default/files/resources/UEFI_PlugFest_AMD_Security_and_Server_innovation_AMD_March_2013.pdf

[33] AMD, “AMD Secure Technology.” [Online]. Available: https://www.amd.com/en-us/innovations/software-technologies/security

[34] W. Arthur and D. Challener, A Practical Guide to TPM 2.0: Using the TrustedPlatform Module in the New Age of Security, 1st ed. Berkely, CA, USA: Apress,2015.

[35] David Chen, Insyde Software, “Improving Platform Security with UEFISecure Boot and UEFI Variables,” Marzo 2016. [Online]. Available: http://www.uefi.org/sites/default/files/resources/Improving%20Platform%20Security%20with%20UEFI%20Secure%20Boot%20and%20UEFI%20Variables_20160318.pdf

[36] D. C. Adams and D. Pinkas, “Internet X.509 Public Key InfrastructureTime-Stamp Protocol (TSP),” RFC 3161, Aug. 2001. [Online]. Available:https://rfc-editor.org/rfc/rfc3161.txt

[37] B. S. Kaliski, “PKCS #7: Cryptographic Message Syntax Version 1.5,” RFC 2315(Informational), Internet Engineering Task Force, March 1998. [Online]. Available:http://www.ietf.org/rfc/rfc2315.txt

[38] Xeno Kovah and Corey Kallenberg, LegbaCore LLC, “Ad-vanced x86: (BIOS and System Management Mode Inter-nals) UEFI SecureBoot,” Octubre 2015. [Online]. Available:http://opensecuritytraining.info/IntroBIOS_files/Day2_06_Advanced%20x86%20-%20BIOS%20and%20SMM%20Internals%20-%20UEFI%20Secure%20Boot.pdf

[39] Microsoft Corporation, “Windows Authenticode Portable Executable SignatureFormat,” Marzo 2008. [Online]. Available: http://msdn.microsoft.com/en-us/windows/hardware/gg463180.aspx

[40] B. S. Kaliski and J. Staddon, “PKCS #1: RSA Cryptography Specifications Version2.0,” RFC 2437, Oct. 1998. [Online]. Available: https://rfc-editor.org/rfc/rfc2437.txt

51

[41] Microsoft Corporation, “Hardware Compatibility Specification for Systemsfor Windows 10, version 1607,” Diciembre 2016. [Online]. Available: https://msdn.microsoft.com/windows/hardware/commercialize/design/compatibility/systems#system_fundamentals_firmware_cs_uefisecureboot_connectedstandby

[42] Jeremiah Cox, Microsoft Corporation, “Microsoft UEFI Certification Autho-rity,” Septiembre 2013. [Online]. Available: http://www.uefi.org/sites/default/files/resources/UEFI_Plugfest_2013_-_New_Orleans_-_Microsoft_UEFI_CA.PDF

[43] Trusted Computing Group, “TPM Main Part 1 De-sign Principles, Specification 1.2, Revision 116,” Marzo 2011.[Online]. Available: http://trustedcomputinggroup.org/wp-content/uploads/TPM-Main-Part-1-Design-Principles_v1.2_rev116_01032011.pdf

[44] ——, “TPM Main Part 2 TPM Structures, Specification 1.2, Revision 116,” Marzo2011. [Online]. Available: http://trustedcomputinggroup.org/wp-content/uploads/TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf

[45] ——, “TPM Main Part 3 Commands, Specification 1.2, Revision 116,” Marzo2011. [Online]. Available: http://trustedcomputinggroup.org/wp-content/uploads/TPM-Main-Part-3-Commands_v1.2_rev116_01032011.pdf

[46] ——, “Trusted Computing Group Protection Profile PC Client Specific TrustedPlatform Module TPM Family 1.2; Level 2 Revision 116, Version 1.3,” Julio 2014.[Online]. Available: https://www.trustedcomputinggroup.org/wp-content/uploads/PC_Client_TPM_PP_1.3_for_TPM_1.2_Level_2_V116.pdf

[47] Alex Matrosov and Eugene Rodionov, “UEFI Firmware Rootkits: Mythsand Reality,” Noviembre 2016. [Online]. Available: https://2016.zeronights.ru/wp-content/uploads/2016/12/1_2_UEFI_Rootkits_ZN_2016.pdf

[48] Intel Security Advanced Threat Research, “Attacking and Defending BIOSin 2015,” Junio 2015. [Online]. Available: http://www.intelsecurity.com/advanced-threat-research/content/AttackingAndDefendingBIOS-RECon2015.pdf

[49] Joanna Rutkowska, “Intel x86 considered harmful,” Octubre 2015. [Online].Available: https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf

[50] Vincent Zimmer, “UEFI, Open Platforms and the Defender’s Dillema,” Mar-zo 2015. [Online]. Available: https://cansecwest.com/slides/2015/UEFI%20open%20platforms_Vincent.pptx

[51] Corey Callenberg and Xeno Kovah, “How Many Million BIOSes Would You LikeTo Infect,” Junio 2015. [Online]. Available: http://legbacore.com/Research_files/HowManyMillionBIOSesWouldYouLikeToInfect_Whitepaper_v1.pdf

[52] Intel Security Advanced Threat Research, “Attacking Hypervi-sors Using Firmware and Hardware,” Agosto 2015. [Onli-ne]. Available: http://www.intelsecurity.com/advanced-threat-research/content/AttackingHypervisorsViaFirmware_bhusa15_dc23.pdf

52

[53] Kernel.org, “The EFI Boot Stub.” [Online]. Available: https://www.kernel.org/doc/Documentation/efi-stub.txt

[54] David Howells, Red Hat, “KEYS: Blacklisting & UEFI database load,” Noviembre2016. [Online]. Available: https://lkml.org/lkml/2016/11/16/527

[55] SourceWare (Red Hat), “LVM2 Resource Page.” [Online]. Available: https://sourceware.org/lvm2/

[56] Clemens Fruhwirth, “LUKS On-Disk Format Specification Version 1.2.2,”Mayo 2016. [Online]. Available: https://gitlab.com/cryptsetup/cryptsetup/wikis/LUKS-standard/on-disk-format.pdf

[57] Microsoft Corporation, “Secured Boot and Measured Boot: Hardening EarlyBoot Components against Malware,” Septiembre 2012. [Online]. Available:https://msdn.microsoft.com/en-us/library/windows/hardware/dn653311.aspx

[58] ——, “Signature Categories and Driver Installation,” Julio 2016. [On-line]. Available: https://msdn.microsoft.com/en-us/windows/hardware/drivers/install/signature-categories-and-driver-installation

[59] Android Open Source Project, “Android Init Language.” [Online]. Available:https://android.googlesource.com/platform/system/core/+/master/init/readme.txt

[60] FreeBSD Foundation, “UEFI(8) - Unified Extensible Firmware Interface bootstrap-ping procedures,” Febrero 2016. [Online]. Available: https://www.freebsd.org/cgi/man.cgi?query=uefi&sektion=8&manpath=FreeBSD+11.0-stable

[61] The FreeBSD Documentation Project, “FreeBSD Architecture Handbook,” Octubre2016. [Online]. Available: https://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/index.html

[62] FreeBSD Foundation, “LOADER(8) - kernel bootstrapping final stage,” Noviem-bre 2015. [Online]. Available: https://www.freebsd.org/cgi/man.cgi?query=uefi&sektion=8&manpath=FreeBSD+11.0-stable

[63] ——, “GELI(8) - control utility for the cryptographic GEOM class,” Julio 2015.[Online]. Available: https://www.freebsd.org/cgi/man.cgi?query=geli&sektion=8&manpath=FreeBSD+11.0-stable

[64] ——, “KLDLOAD(2) - load KLD files into the kernel,” Marzo 1999. [Online]. Avai-lable: https://www.freebsd.org/cgi/man.cgi?query=kldload&sektion=2&manpath=FreeBSD+11.0-stable

[65] Trammell Hudson, “Bootstraping a slightly more secure laptop,” Diciem-bre 2016. [Online]. Available: https://media.ccc.de/v/33c3-8314-bootstraping_a_slightly_more_secure_laptop

[66] The Qubes OS Project, “An Introduction to Qubes OS.” [Online]. Available:https://www.qubes-os.org/intro/

53

[67] Brian Lich, Microsoft Corporation, “Introduction to Device Guard:virtualization-based security and code integrity policies,” Agosto 2016. [Onli-ne]. Available: https://technet.microsoft.com/en-us/itpro/windows/keep-secure/introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies

[68] ——, “Protect derived domain credentials with Credential Guard,” Enero 2017. [On-line]. Available: https://technet.microsoft.com/en-us/itpro/windows/keep-secure/credential-guard

[69] ——, “Requirements and deployment planning guidelines for Device Guard,” Octu-bre 2016. [Online]. Available: https://technet.microsoft.com/en-us/itpro/windows/keep-secure/requirements-and-deployment-planning-guidelines-for-device-guard

[70] Multiple authors, VirtualBox Forums, “Windows 10 Anniversary Update BrokeVirtualBox?” Agosto 2016. [Online]. Available: https://forums.virtualbox.org/viewtopic.php?f=6&t=79028

[71] AMD, “AMD Security Brochure,” 2012. [Online]. Available: https://www.amd.com/Documents/Security_021.pdf

[72] Rafal Wojtczuk and Joanna Rutkowska and Alexander Tereshkin, “Another Way toCircumvent Intel Trusted Execution Technology,” Diciembre 2009. [Online]. Available:http://invisiblethingslab.com/resources/misc09/Another%20TXT%20Attack.pdf

[73] Rafal Wojtczuk and Joanna Rutkowska, “Attacking Intel TXT via SINIT codeexecution hijacking,” Noviembre 2011. [Online]. Available: http://invisiblethingslab.com/resources/2011/Attacking_Intel_TXT_via_SINIT_hijacking.pdf

[74] Joseph Sharkey, “Breaking Hardware-Enforced Security with Hypervisors,”Agosto 2016. [Online]. Available: https://www.blackhat.com/docs/us-16/materials/us-16-Sharkey-Breaking-Hardware-Enforced-Security-With-Hypervisors.pdf

[75] David Kaplan and Jeremy Powell and Tom Woller, AMD,“AMD Memory Encryption,” Abril 2016. [Online]. Availa-ble: http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf

[76] RedGamingTech, “AMD Zen Processors Feature Impressi-ve Hardware Encryption Not Present In Intel CPU’s,” Oc-tubre 2016. [Online]. Available: http://www.redgamingtech.com/amd-zen-processors-feature-impressive-hardware-encryption-not-present-in-intel-cpus/

[77] Trusted Computing Group, “TPM Certified Products.” [Online]. Available: https://www.trustedcomputinggroup.org/membership/certification/tpm-certified-products/

[78] Richard Wilkins and Brian Richardson, “UEFI Secure Boot in mo-dern computer security solutions,” Septiembre 2013. [Online]. Avai-lable: http://members.uefi.org/learning_center/papers/UEFI_Secure_Boot_in_Modern_Computer_Security_Solutions_2013.pdf

54

[79] Xeno Kovah and Corey Kallenberg, LegbaCore LLC, “Advan-ced x86: (BIOS and System Management Mode Internals) Trus-ted Computing Technologies,” Octubre 2015. [Online]. Available:http://opensecuritytraining.info/IntroBIOS_files/Day2_07_Advanced%20x86%20-%20BIOS%20and%20SMM%20Internals%20-%20Trusted%20Computing.pdf

[80] Vincent Zimmer and Jiewen Yao, “A Tour beyond BIOS Memory Map Design in UEFIBIOS,” Febrero 2015. [Online]. Available: https://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Memory_Map_in%20UEFI_BIOS.pdf

[81] Vincent Zimmer and Jiewen Yao and Star Zeng, “ATour Beyond BIOS Implementing UEFI Authenticated Varia-bles in SMM with EDKII,” Septiembre 2015. [Online]. Available:https://www.researchgate.net/profile/Vincent_Zimmer/publication/282818992_A_Tour_Beyond_BIOS_Implementing_UEFI_Authenticated_Variables_in_SMM_with_EDKII_-_version_2/links/561d86d508aecade1acb3e52.pdf

[82] Rafal Sosnowski, Microsoft Corporation, “Diving into Secure Boot,” Marzo2016. [Online]. Available: https://blogs.technet.microsoft.com/dubaisec/2016/03/14/diving-into-secure-boot/

55

Este documento esta firmado porFirmante CN=tfgm.fi.upm.es, OU=CCFI, O=Facultad de Informatica - UPM,

C=ES

Fecha/Hora Tue Jan 10 12:00:38 CET 2017

Emisor delCertificado

EMAILADDRESS=camanager@fi.upm.es, CN=CA Facultad deInformatica, O=Facultad de Informatica - UPM, C=ES

Numero de Serie 630

Metodo urn:adobe.com:Adobe.PPKLite:adbe.pkcs7.sha1 (AdobeSignature)