Compartir a través de

Guía de ROM de opción de validación de UEFI

Versión 1.3

Este documento ayuda a los OEM y a los OEM a validar que su firmware comprueba las firmas de su ROM de opción como parte de la cadena de confianza de arranque seguro.

Esta guía asume que conoce los aspectos básicos de la UEFI, que posee los conocimientos básicos del arranque seguro (capítulos 1, 2, 13, 20 y 27 de la especificación UEFI) y el modelo de seguridad de PKI.

Introducción

Las ROM de opción (o OpROMs) son el firmware ejecutado por el BIOS del PC durante la inicialización de la plataforma. Normalmente se almacenan en una tarjeta de complemento, aunque pueden residir en la placa del sistema.

Los dispositivos que normalmente requieren ROM de opción son tarjetas de vídeo, adaptadores de red y controladores de almacenamiento para módulos RAID. Estas ROM de opción también suelen proporcionar controladores de firmware al equipo.

Incluyen diversos tipos de controladores de firmware, como PC-AT heredado, Open Firmware y ROM de opción EFI. Algunos ejemplos de controladores de firmware son el BIOS de vídeo en tarjetas de vídeo, los controladores de arranque PXE para adaptadores Ethernet y los controladores de almacenamiento en controladoras RAID. Estos dispositivos suelen tener ROM de opción que proporcionan controladores de firmware.

Unified Extensible Firmware Interface (UEFI) admite ROM de opción en modo heredado.

Según la especificación UEFI más reciente (actualmente en 2.3.1 Errata C: sección 2.5.1.2), las ROM de opción ISA (heredada) no forman parte de la especificación UEFI. Para los fines de esta discusión, solo se considerarán las ROM de opción compatibles con UEFI basadas en PCI.

Las ROM de opción se pueden usar cuando no es posible insertar el firmware de un dispositivo en el firmware del equipo. Cuando la ROM de opción lleva el controlador, el IHV puede aprovechar ese controlador y mantener el controlador y el dispositivo en un solo lugar.

En este documento se explica por qué necesita validar las ROM de opción y muestra algunas técnicas para hacerlo.

Compatibilidad con BIOS UEFI y BIOS heredado

Muchos fabricantes crean dispositivos que incluyen ROM de opción y firmware para muchos tipos de PC. Entre los combos comunes se incluyen:

  • Solo ROM heredada
  • OpROM nativo de UEFI
  • ROM heredada + UEFI EBC OpROM
  • ROM heredada + UEFI x64 OpROM
  • ROM heredada + UEFI x64 + UEFI IA32
  • ROM heredada + UEFI x64 + UEFI IA32 + UEFI EBC OpROM

El BIOS UEFI puede cargar y ejecutar controladores de firmware heredados cuando está habilitado un módulo de soporte de compatibilidad (CSM). Tenga en cuenta que, cuando el arranque seguro está habilitado, se prohíbe la ejecución del módulo de soporte de compatibilidad y las ROM heredadas porque los controladores de firmware heredados no admiten la autenticación. Si el formato ROM de opción en la configuración del BIOS está establecido en ROM heredada, siempre usará la ROM heredada en el dispositivo.

Si el formato de la ROM de opción está establecido en Compatible con UEFI, usará la ROM de EFI más reciente si hay una y la ROM heredada si no la hay.

Los controladores UEFI son necesarios para muchas de las nuevas características de seguridad de nivel de firmware, así como para habilitar secuencias de arranque UEFI. Por ejemplo, la instalación de Windows desde un disco óptico que está conectado a un controlador de almacenamiento no compatible con UEFI no es posible cuando un sistema arranca en modo UEFI con el arranque seguro habilitado.

1. UEFI y ROM de opción

diagram of uefi driver considerations

Figura 2: Consideración de seguridad del controlador UEFI, fuente: UEFI 2.3.1 Errata C

El siguiente texto se originó en UEFI 2.3.1 Errata C, pero desde entonces se ha modificado con información de partners:

Dado que el perfil de usuario de UEFI detalla una serie de privilegios relacionados con la seguridad, es importante que el administrador de identidad de usuario y los proveedores de credenciales de usuario y el entorno en el que se ejecutan sean de confianza.

Esto incluye:

  • Proteger el área de almacenamiento donde se almacenan estos controladores.
  • Proteger los medios por los que se seleccionan estos controladores.
  • Proteger el entorno de ejecución de estos controladores frente a controladores no comprobados.
  • Las estructuras de datos usadas por estos controladores no deben estar dañadas por controladores no autorizados mientras todavía se usan.

Componentes como User Identity Manager, los controladores de credenciales de usuario y los controladores de placa tal vez se encuentran en una ubicación segura, como la unidad flash protegida contra escritura, que es de confianza para la directiva de plataforma.

Algunos otros controladores pueden residir en ubicaciones de almacenamiento desprotegidas, como una ROM de opción o una partición de disco duro, y pueden reemplazarse fácilmente. Estos controladores deben comprobarse.

Por ejemplo, la directiva de plataforma predeterminada debe poder comprobar correctamente los controladores enumerados en las opciones de carga de controlador#### o, de lo contrario, el usuario debe identificarse antes de procesar estos controladores. De lo contrario, se debe aplazar la ejecución del controlador. Si el perfil de usuario se cambia a través de una llamada posterior a Identificar () o a través de la autenticación dinámica, es posible que las opciones Driver#### no se vuelvan a procesar.

La base de datos de perfil de usuario se cierra mediante diferentes eventos de señal UEFI en función de si se puede proteger.

Los controladores UEFI y las ROM de opción UEFI solo se ejecutarán para dispositivos en la ruta de acceso de arranque.

La especificación PCI permite varias imágenes de ROM de opción en el mismo dispositivo. Estas ROM de opción podrían ser Legacy x86 y UEFI. El firmware UEFI establece la directiva de plataforma para seleccionar la ROM de opción. Esto puede hacer que la ROM del adaptador opcional se ejecute como su propio dispositivo de control.

El firmware comprueba las firmas durante las fases BDS y DXE. Todo ocurre en este orden:

  1. Inicializar PCI y buses derivados
  2. Sondeo de dispositivos PCI para ROM de opción
  3. Las ROM de opción encontradas se asignan en memoria
  4. La fase DXE carga cualquier controlador UEFI en la ROM

Las ROM de opción UEFI pueden estar en cualquier parte de la memoria. De forma predeterminada, la ROM de la tarjeta administra el dispositivo. UEFI permite a la plataforma controlar la directiva en torno a qué ROM de opción controla qué dispositivo utilizando EFI_PLATFORM_DRIVER_OVERRIDE. UEFI admite la ROM de opción para registrar una interfaz de configuración.

En un equipo con arranque seguro habilitado, los controladores de ROM opción suponen una amenaza de seguridad si no están firmados o no se validan. La validación de firmas para las ROM de opción es un requisito de WHCK. Lo mismo sucede al mantenimiento de las ROM de opción para asegurarse de que la actualización se valida antes de la instalación.

En las especificaciones y directivas del Programa de compatibilidad de hardware con Windows versión 1809:

  1. Comprobación de integridad del código de firmware firmado. El firmware que instala el OEM y es de solo lectura o está protegido por un proceso de actualización de firmware seguro, como se ha definido anteriormente, puede considerarse protegido. Los sistemas comprobarán que todos los componentes de firmware no protegidos, los controladores UEFI y las aplicaciones UEFI estén firmados mediante el uso mínimo de RSA-2048 con SHA-256 (MD5 y SHA-1 están prohibidos) y que las aplicaciones y controladores UEFI que no están firmados según estos requisitos no se ejecutarán (esta es la directiva predeterminada para algoritmos de firma aceptables). Si no se encuentra una firma de imágenes en la base de datos autorizada o se encuentra en la base de datos prohibida, la imagen no debe iniciarse y, en su lugar, la información sobre ella se colocará en la Tabla de información de ejecución de imágenes.

2. Declaración del problema

Algunas compilaciones del BIOS UEFI habilitado para arranque seguro, incluido Tiano Core, no autenticaron de manera predeterminada las ROM de opción UEFI porque las ROM de opción UEFI firmadas no estaban disponibles durante el desarrollo de arranque seguro. Esto expone una superficie de ataque o vulnerabilidad en el arranque seguro UEFI.

2.1. Punto vulnerable

Esta vulnerabilidad seguía presente en EDK II y UDK2010 en agosto de 2013. Los mantenedores de origen son conscientes del problema y se notifica un error. Cualquier firmware derivado de EDK II y UDK2010 debe comprobar cómo se administra la comprobación de la ROM de opción. El comportamiento de verificación de ROM de opción se controla mediante un valor PCD PcdOptionRomImageVerificationPolicy en el paquete EDK II SecurityPkg.

El código fuente de la vulnerabilidad de TianoCore es el archivo SecurityPkg\SecurityPkg.dec:

## Pcd for OptionRom.
  #  Image verification policy settings:
  #  ALWAYS_EXECUTE                         0x00000000
  #  NEVER_EXECUTE                          0x00000001
  #  ALLOW_EXECUTE_ON_SECURITY_VIOLATION    0x00000002
  #  DEFER_EXECUTE_ON_SECURITY_VIOLATION    0x00000003
  #  DENY_EXECUTE_ON_SECURITY_VIOLATION     0x00000004
  #  QUERY_USER_ON_SECURITY_VIOLATION       0x00000005
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x00|UINT32|0x00000001

El valor predeterminado (0x00) es ALWAYS_EXECUTE, que no realiza correctamente la comprobación de los controladores firmados en las ROM de opción para periféricos de complemento. Este no es un valor ideal para cualquier sistema que implemente la funcionalidad de arranque seguro UEFI.

Valor recomendado (mayor seguridad): DENY_EXECUTE_ON_SECURITY_VIOLATION (0x04)

Valor recomendado (mayor flexibilidad): QUERY_USER_ON_SECURITY_VIOLATION (0x05)

En EDK II y UDK2010, la práctica de codificación adecuada usa un mecanismo de invalidación para modificar los valores de PCD para el firmware de la plataforma. Por lo tanto, el valor de PcdOptionRomImageVerificationPolicy no debe modificarse en SecurityPkg\SecurityPkg.dec. El valor de invalidación debe establecerse en el archivo DSC de la plataforma. A continuación se muestra un ejemplo con Nt32Pkg\Nt32Pkg.dsc:

[PcdsFixedAtBuild]
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x04

La invalidación de PCD debe colocarse en la sección [PcdsFixedAtBuild] del archivo DSC. El mecanismo exacto para invalidar parámetros puede diferir en función de las herramientas del proveedor de BIOS.

Nota:

Esta vulnerabilidad puede existir en implementaciones tempranas del BIOS de arranque seguro UEFI de proveedores de BIOS independientes. Póngase en contacto con el proveedor del BIOS para determinar si la versión puede verse afectada.

3. ¿A quién afecta?

Un PC UEFI que implementa arranque seguro y tiene un controlador ROM de opción UEFI que no está firmado. Además, el firmware de compatibilidad para que las tarjetas existentes funcionen puede tener una vulnerabilidad de seguridad que no comprueba las ROM de opción.

Portátiles, netbooks, ultrabooks y tabletas: la mayoría no se ven afectados. Las ROM de opción suelen estar presentes en buses backplane, como PCI/e, ISA y sus derivados (ExpressCard, miniPCI, CardBus, PCCard, LPC, ThunderBolt, etc.). Si un portátil no tiene ninguno de estos expuestos, su superficie de ataque se reduce considerablemente. Además, es probable que los controladores UEFI para los componentes integrados en el portátil estén integrados en el volumen de firmware del BIOS principal y no se encuentren en una ROM de opción independiente. Por lo tanto, la mayoría de los portátiles no están en riesgo. Además, cuando se deshabilitan las ROM de opción heredadas, parece que UEFI solo admite la ROM de opción basada en PCI.

Sin embargo, si tiene un dispositivo de escritorio, una placa base o un servidor que tiene un BIOS UEFI e implementa el arranque seguro, es posible que se vea afectado. El controlador RAID dedicado de un servidor, o el controlador de almacenamiento de complementos para SATA, FC, etc. o tarjetas de red PCIe Ethernet pueden tener ROM de opción. Los controladores de complementos que admiten una amplia gama de funcionalidades en los servidores son comunes, por lo que esto se aplica especialmente al espacio del servidor.

Esto puede afectar potencialmente a equipos de 32 y 64 bits, tanto de clase 2 como de clase 3.

Si una plataforma de arranque seguro admite ROM de opción de dispositivos no conectados permanentemente a la plataforma y admite la capacidad de autenticar esas ROM de opción, debe admitir los métodos de validación de ROM de opción descritos en Protocolos de red: UDP y MTFTP y las variables EFI autenticadas descritas en la especificación UEFI 2.3.1 Errata C, sección 7.2.

4. ¿Cómo comprobarlo?

Si está desarrollando el firmware y se basa en Tiano Core, compruebe si hay vulnerabilidades mencionadas en la sección 2.1. Si usa el firmware de otro IBV, consúltelo con ellos. O puede hacer la prueba usted mismo como se indica a continuación.

Necesitará lo siguiente:

  • PC sometido a prueba con firmware UEFI
  • Dispositivo PCI con ROM de opción en el equipo sometido a prueba (como una tarjeta de vídeo)
  • Asegúrese de que el arranque seguro está habilitado

Pasos para la prueba:

  1. Inserte un complemento UEFI en la tarjeta PCI con la ROM de opción UEFI en el equipo en prueba.

    Si usa una tarjeta de vídeo PCI para la prueba, conecte un monitor externo.

  2. Habilite el arranque seguro con la configuración siguiente:

    • PK: PK o PK de prueba autofirmado
    • KEK: MS KEK, KEK de prueba de Fabrikam firmado PK u otro KEK
    • DB: NULL. (Debe ser NULL).
    • DBX: NULL.
    • SecureBoot: la variable UEFI debe establecerse en true.

  3. Reinicie el equipo

  4. Espere el siguiente resultado:

    • Si el firmware UEFI se implementa correctamente, el controlador ROM de opción UEFI no se cargaría, ya que la presencia de un ROM de opción hará que el firmware compruebe la "base de datos" para un certificado. Dado que "Db" es NULL, el controlador UEFI no se cargará. Por ejemplo, si usa la tarjeta de vídeo para probarlo, verá que no aparece nada en pantalla.
    • Si el firmware no se implementa correctamente, el controlador UEFI se cargará desde la ROM de opción, ya que el firmware no comprueba si hay firmas en "Db". Por ejemplo, si usa la tarjeta de vídeo para la prueba, verá que se mostrará el monitor enlazado a la tarjeta de ROM de opción.

    ![nota] No importa si el controlador ROM de opción UEFI está firmado o no, la ROM de opción no se cargará cuando DB sea null y SB esté habilitado (PK y KEK están inscritos).

Consulte los scripts de ejemplo disponibles en WHCK para generar la PK y la KEK. El Apéndice B tiene scripts de ejemplo y más detalles.

También puede consultar en el Apéndice A otro enfoque para realizar la prueba anterior. Este enfoque no requiere establecer la DB en Null, pero necesita un controlador ROM de opción UEFI sin firmar del IHV.

5. Cómo solucionarlo

Si se produce un error en la prueba anterior, trabaje con el IBV para adquirir las versiones necesarias y configurarlas para validar las ROM de opción. Asegúrese de que el firmware supera la prueba. En el caso de los equipos que se han enviado, deberá realizar una actualización de firmware segura. Consulte la publicación de NIST 800-147 o consulte Guía de creación y administración de claves de arranque seguro de Windows 8.1..

Puede probar el equipo y aprovechar el HCK de Windows como herramienta de prueba (no de certificación) para probar la actualización de firmware segura.

5.1. Firmar el controlador

En caso de que encuentre que puede tener controladores sin firmar en las ROM de opción UEFI, lea a continuación sobre cómo corregirlo.

Firme cada controlador ROM de opción individualmente. Esto interrumpirá el formato de la ROM de opción de PCI. Solo tiene que firmar el controlador UEFI antes de crear la ROM de opción combinada.

Antes de insertar el controlador UEFI en OpROM, firme la imagen UEFI y pruébela con arranque seguro ON & OFF en el shell UEFI (cargue o descargue el archivo del controlador). A continuación, coloque el controlador firmado en la ROM de opción combinada.

Puede dirigir su IHV al Centro sysDev de Microsoft para obtener sus ROM de opción UEFI firmadas a través de un servicio disponible a través del centro sysDev.

5.2. Validación de la actualización

Ejecute la prueba mencionada anteriormente para comprobar que la vulnerabilidad no existe. Use las pruebas de HCK para asegurarse de que no haya regresiones funcionales.

6. Recursos

Apéndice A: Enfoque alternativo para probar mediante controladores ROM de opción sin firmar

Este enfoque se basa en la obtención de herramientas de IHV para asegurarse de que el controlador ROM de opción UEFI está firmado.

Necesitará lo siguiente:

  • PC sometido a prueba con firmware UEFI
  • Dispositivo PCI con un controlador ROM de opción sin firmar conectado al equipo sometido a prueba (como una tarjeta de vídeo)
  • Asegúrese de que el arranque seguro está habilitado
  • Herramientas de IHV de opción para detectar la firma en el controlador ROM de opción si no es evidente que el controlador ROM de opción está firmado o no

Si el firmware se implementa correctamente y la opción ROM no está firmada, la tarjeta debe producir un error en la comprobación por firmware y no cargar el controlador en la tarjeta. El equipo debe notificar un código de error como EFI_IMAGE_EXECUTION_AUTH_SIG_FOUND. En caso de que use una tarjeta de vídeo, es posible que vea que el PC muestra solo una pantalla negra, ya que el controlador ROM de opción no se cargó.

Si el firmware se implementa incorrectamente, esta prueba funcionaría.

Apéndice B: Scripts para habilitar el arranque seguro con NULL db

Puede usar el conjunto actual de variables de arranque seguro (PK y KEK) o generar unas de prueba para probar esto

A continuación se muestran los pasos que se usan para generar la PK de prueba, KEK y para establecer Db en NULL. Asegúrese de que el arranque seguro no está habilitado; de lo contrario, estos pasos requerirían archivos bin de UEFI firmados.

Nota:

Establecemos la variable de arranque seguro: Db, KEK y PK en orden inverso, por lo que no tenemos que firmar los archivos bin de UEFI.

Antes de este paso, el PC debe estar en modo de configuración.

  1. Crear certificados KEK y PK

    Este paso requiere la herramienta makecert.exe disponible en Windows SDK.

    MakeCert.exe -cy authority -len 2048 -m 60 -a sha256  -pe -ss my -n "CN=DO NOT SHIP - Fabrikam Test KEK CA" Fabrikam_Test_KEK_CA.cer
MakeCert.exe -cy authority -len 2048 -m 60 -a sha256  -pe -ss my -n "CN=DO NOT SHIP - Fabrikam Test PK" TestPK.cer

  2. Script para generar PK de prueba

    Se proporciona una muestra a continuación.

    this scripts demonstrates how to format the Platform key
NOTE The PK is actually set in the Enable_OEM_SecureBoot.ps1 script
Import-Module secureboot
$d = (pwd).Path

###############################################################################
Complete the following parameters
###############################################################################

$certname = "TestPK"
TODO change this path to where you have the PK.cer file
This is where you plugin the certificate generated by the HSM
$certpath = $d + "\" + $certname + ".cer"

Each signature has an owner SignatureOwner, which is a GUID identifying the agent which inserted the signature in the database.
Agents might include the operating PC or an OEM-supplied driver or application.
Agents may examine this field to understand whether they should manage the signature or not.
TODO replace with OEM SignatureOwner GUID.
You can use tools like Guidgen.exe tool in SDK or a similar tool to generate a GUID
$sigowner = "55555555-5555-5555-5555-555555555555"

$var = "PK"
$efi_guid = "{8BE4DF61-93CA-11d2-AA0D-00E098032B8C}"
$append = $false

###############################################################################
Everything else is calculated
###############################################################################

Workaround relative path bug
TODO substitute OEM with your OEM name
$siglist =  $certname + "_SigList.bin"
$serialization = $certname + "_SigList_Serialization_for_" + $var + ".bin"
$signature = $serialization + ".p7"

$appendstring = "set_"
$attribute = "0x27"
$example = "Example_SetVariable_Data-" + $certname + "_" + $appendstring + $var + ".bin"

Format-SecureBootUEFI -Name $var -SignatureOwner $sigowner -ContentFilePath $siglist -FormatWithCert -Certificate $certpath -SignableFilePath $serialization -Time 2011-05-21T13:30:00Z  -AppendWrite:$append

OutputFilePath - Specifies the name of the file created that contains the contents of what is set.
If this parameter is specified, then the content are not actually set, just stored into this file.
Please note if -OutputFilePath is provided the PK is not set like in this case. The master script sets it at the end.

Time - you can change the time below as long as it isn't in the future. Nothing wrong with keeping it as is.

Set-SecureBootUEFI -Name $var -Time 2011-05-21T13:30:00Z -ContentFilePath $siglist  -OutputFilePath $example -AppendWrite:$append

  3. Generar KEK de prueba o usar su propia KEK de OEM

    Puede aprovechar su propia KEK de OEM o scripts de WHCK para esto.

    Se proporciona una muestra a continuación.

    script to add option OEM KEK
Import-Module secureboot
$d = (pwd).Path

###############################################################################
Complete the following parameters
###############################################################################

$certname = "Fabrikam_Test_KEK_CA"
TODO change this path to where you have the PK.cer file
This is where you plugin the certificate generated by the HSM
$certpath = $d + "\" + $certname + ".cer"

TODO change this path to where you have the OEM_KEK.cer file
Each signature has an owner SignatureOwner, which is a GUID identifying the agent which inserted the signature in the database.
Agents might include the operating system or an OEM-supplied driver or application.
Agents may examine this field to understand whether they should manage the signature or not.
TODO replace with OEM SignatureOwner GUID.
You can use tools like Guidgen.exe tool in SDK or a similar tool to generate a GUID

$sigowner = "00000000-0000-0000-0000-000000000000"

$var = "KEK"
$efi_guid = "{8BE4DF61-93CA-11d2-AA0D-00E098032B8C}"
$append = $false

###############################################################################
Everything else is calculated
###############################################################################

$siglist = $certname + "_SigList.bin"
$serialization = $certname + "_SigList_Serialization_for_" + $var + ".bin"
$signature = $serialization + ".p7"
if ($append -eq $false)
{
$appendstring = "set_"
$attribute = "0x27"
} else
{
$appendstring = "append_"
$attribute = "0x67"
}
$example = "Example_SetVariable_Data-" + $certname + "_" + $appendstring + $var + ".bin"

Format-SecureBootUEFI -Name $var -SignatureOwner $sigowner -ContentFilePath $siglist -FormatWithCert -CertificateFilePath $certpath -SignableFilePath $serialization -Time 2011-05-21T13:30:00Z -AppendWrite:$append

-Time You can change the time below as long as it isn't in the future. Nothing wrong with keeping it as is.

Set-SecureBootUEFI -Name $var -Time 2011-05-21T13:30:00Z -ContentFilePath $siglist -OutputFilePath $example -AppendWrite:$append

  4. Establecer Db en Null y establecer KEK y PK

    Lo primero que hace este script es establecer la Db en Null.

    Nota:

    Tenga en cuenta que si la CA de KEK de prueba de Fabrikam es la única entidad de certificación KEK presente (lo que significa que no hay ninguna CA de KeK de Windows), el equipo puede arrancar en Windows RE.

    Antes de la ejecución del script, ejecute "Set-ExecutionPolicy Bypass -Force"

    Import-Module secureboot
try
{
Write-Host "Deleting db..."
Set-SecureBootUEFI -Name db -Time "2011-06-06T13:30:00Z" -Content $null
}
catch
{
}
Write-Host "Setting Fabrikam KEK..."
Set-SecureBootUEFI -Time 2011-05-21T13:30:00Z  -ContentFilePath Fabrikam_Test_KEK_CA_SigList.bin  -Name KEK

Write-Host "Setting self-signed Test PK..."
Set-SecureBootUEFI -Time 2011-05-21T13:30:00Z -ContentFilePath TestPK_SigList.bin  -Name PK

Write-Host "`n... operation complete.  `nSetupMode should now be 0 and SecureBoot should also be 0. Reboot and verify that Windows is correctly authenticated, and that SecureBoot changes to 1."

  5. Conectar la tarjeta ROM de opción y probar

    La prueba debe superarse o producir un error en función de la corrección del firmware. Por ejemplo:

    Si la ROM de opción en el firmware se implementa correctamente y usa una tarjeta de vídeo para realizar pruebas, no debería haber ninguna pantalla en el monitor conectado.

    Sin embargo, si usa un firmware incorrecto, la tarjeta de vídeo debería tener salida en la pantalla.

Guía de creación y administración de claves de arranque seguro de Windows

Introducción al Arranque seguro

Validar la funcionalidad de la plataforma de actualización de firmware UEFI de Windows