Habilitación del arranque seguro, BitLocker y Device Guard en Windows 10 IoT Core

  • Artículo

Windows 10 IoT Core incluye ofertas de características de seguridad como el arranque seguro UEFI, el cifrado de dispositivos BitLocker y Device Guard. Esto ayudará a los creadores de dispositivos a crear dispositivos Windows IoT totalmente bloqueados que son resistentes a muchos tipos diferentes de ataques. Juntas, estas características proporcionan la protección óptima que garantiza que una plataforma se inicie de forma definida, al tiempo que bloquea los archivos binarios desconocidos y protege los datos de usuario mediante el uso del cifrado de dispositivos.

Orden de arranque

Se necesita una comprensión del orden de arranque en un dispositivo Windows 10 IoT Core para poder profundizar en los componentes individuales que proporcionan una plataforma segura para el dispositivo IoT.

Hay tres áreas principales que se producen desde el momento en que un dispositivo IoT está encendido, hasta la carga y ejecución del kernel del sistema operativo de la aplicación instalada.

  • Arranque seguro de la plataforma
  • Arranque seguro de unified Extensible Firmware Interface (UEFI)
  • Integridad de código de Windows

Boot Order

Puede encontrar información adicional sobre el proceso de arranque de Windows 10 aquí.

Bloqueo de dispositivos IoT

Para bloquear un dispositivo Windows IoT, se deben tener en cuenta las siguientes consideraciones.

Arranque seguro de la plataforma

Cuando el dispositivo se enciende por primera vez, el primer paso del proceso de arranque general es cargar y ejecutar cargadores de arranque de firmware, que inicializan el hardware en los devies y proporcionan funcionalidad de parpadeo de emergencia. A continuación, se carga el entorno UEFI y se entrega el control.

Estos cargadores de arranque de firmware son específicos de SoC, por lo que deberá trabajar con el fabricante del dispositivo adecuado para que estos cargadores de arranque se creen en el dispositivo.

Arranque seguro UEFI

El arranque seguro UEFI es el primer punto de cumplimiento de directivas y se encuentra en UEFI. Restringe el sistema para permitir solo la ejecución de archivos binarios firmados por una entidad especificada, como controladores de firmware, ROMs de opción, controladores UEFI o aplicaciones, y cargadores de arranque UEFI. Esta característica evita que se ejecute código desconocido en la plataforma y pueda debilitar su seguridad. El arranque seguro reduce el riesgo de ataques de malware previos al arranque en el dispositivo, como rootkits.

Como OEM, debe almacenar las bases de datos de arranque seguro UEFI en el dispositivo IoT en tiempo de fabricación. Estas bases de datos incluyen la base de datos signature (db), la base de datos de firma revocada (dbx) y la base de datos clave de inscripción de claves (KEK). Estas bases de datos se almacenan en la RAM no volátil del firmware (NV-RAM) del dispositivo.

  • Base de datos de firmas (db): enumera los firmantes o hashes de imágenes de cargadores de sistema operativo, aplicaciones UEFI y controladores UEFI que se pueden cargar en el dispositivo.

  • Base de datos de firmas revocada (dbx): enumera los firmantes o hash de imágenes de cargadores de sistema operativo, aplicaciones UEFI y controladores UEFI que ya no son de confianza y no se pueden cargar en el dispositivo.

  • Base de datos de claves de inscripción de claves (KEK): contiene una lista de claves de firma que se pueden usar para actualizar las bases de datos de firma y revocadas.

Una vez creadas y agregadas estas bases de datos al dispositivo, el OEM bloquea el firmware de la edición y genera una clave de firma de plataforma (PK). Esta clave se puede usar para firmar actualizaciones en la KEK o para deshabilitar el arranque seguro UEFI.

Estos son los pasos que lleva a cabo el arranque seguro uefi:

  1. Una vez encendido el dispositivo, las bases de datos de firma se comprueban con la clave de firma de la plataforma (PK).
  2. Si el firmware no es de confianza, el firmware UEFI inicia la recuperación específica del OEM para restaurar el firmware de confianza.
  3. Si no se puede cargar el Administrador de arranque de Windows, el firmware intentará arrancar una copia de seguridad del Administrador de arranque de Windows. Si esto también produce un error, el firmware UEFI inicia la corrección específica del OEM.
  4. El Administrador de arranque de Windows se ejecuta y comprueba la firma digital del kernel de Windows. Si es de confianza, el Administrador de arranque de Windows pasa el control al kernel de Windows.

Puede encontrar más detalles sobre el arranque seguro, junto con la guía de creación y administración de claves, aquí.

Integridad de código de Windows

La integridad de código de Windows (WCI) mejora la seguridad del sistema operativo validando la integridad de un controlador o aplicación cada vez que se carga en la memoria. CI contiene dos componentes principales: integridad de código en modo kernel (KMCI) y integridad de código en modo de usuario (UMCI).

La integridad de código configurable (CCI) es una característica de Windows 10 que permite a los generadores de dispositivos bloquear un dispositivo y solo permitir que se ejecute y ejecute código firmado y de confianza. Para ello, los generadores de dispositivos pueden crear una directiva de integridad de código en un dispositivo "golden" (versión final de versión de hardware y software) y, a continuación, proteger y aplicar esta directiva en todos los dispositivos de la planta de fábrica.

Para más información sobre la implementación de directivas de integridad de código, auditoría y cumplimiento, consulte la documentación más reciente de technet aquí.

Estos son los pasos que realiza la integridad de código de Windows:

  1. El kernel de Windows comprobará todos los demás componentes de la base de datos de firma antes de cargarlo. Esto incluye controladores, archivos de inicio y ELAM (Antimalware de inicio temprano).
  2. El kernel de Windows cargará los componentes de confianza en el proceso de inicio y prohibirá la carga de los componentes que no son de confianza.
  3. El sistema operativo Windows 10 IoT Core se carga, junto con las aplicaciones instaladas.

Cifrado de dispositivos BitLocker

Windows 10 IoT Core también implementa una versión ligera de Cifrado de dispositivos BitLocker, que protege los dispositivos IoT frente a ataques sin conexión. Esta funcionalidad tiene una fuerte dependencia de la presencia de un TPM en la plataforma, incluido el protocolo previo al sistema operativo necesario en UEFI que lleva a cabo las medidas necesarias. Estas medidas previas al sistema operativo garantizan que el sistema operativo tenga un registro definitivo de cómo se inició el sistema operativo; sin embargo, no aplica ninguna restricción de ejecución.

Sugerencia

La funcionalidad de BitLocker en Windows 10 IoT Core permite el cifrado automático del volumen del sistema operativo basado en NTFS al enlazar todos los volúmenes de datos NTFS disponibles a él. Para ello, es necesario asegurarse de que el GUID de volumen de EFIESP esté establecido en C12A7328-F81F-11D2-BA4B-00A0C93EC93B.

Device Guard en Windows IoT Core

La mayoría de los dispositivos IoT se crean como dispositivos de función fija. Esto implica que los generadores de dispositivos saben exactamente qué firmware, sistema operativo, controladores y aplicaciones deben ejecutarse en un dispositivo determinado. A su vez, esta información se puede usar para bloquear completamente un dispositivo IoT si solo permite la ejecución de código conocido y de confianza. Device Guard en Windows 10 IoT Core puede ayudar a proteger los dispositivos IoT asegurándose de que el código ejecutable desconocido o que no es de confianza no se puede ejecutar en dispositivos bloqueados.

Seguridad llave en mano en IoT Core

Para facilitar la habilitación sencilla de las características de seguridad clave en dispositivos IoT Core, Microsoft proporciona un paquete de seguridad llave en mano que permite a los creadores de dispositivos compilar dispositivos IoT totalmente bloqueados. Este paquete le ayudará a:

  • Aprovisionamiento de claves de arranque seguro y habilitación de la característica en plataformas de IoT compatibles
  • Configuración y configuración del cifrado de dispositivos mediante BitLocker
  • Iniciar el bloqueo del dispositivo para permitir solo la ejecución de aplicaciones y controladores firmados

Los pasos siguientes llevarán a través del proceso para crear una imagen de bloqueo mediante el paquete de seguridad llave en mano

Create lockdown image

Requisitos previos

  • Un equipo que ejecuta Windows 10 Enterprise (otras versiones de Windows no son compatibles con los scripts proporcionados)
  • SDK de Windows 10: necesario para la generación de certificados
  • Windows 10 ADK : necesario para la generación CAB
  • Plataforma de referencia: el hardware de lanzamiento con firmware de envío, sistema operativo, controladores y aplicaciones será necesario para el bloqueo final.

Desarrollo de dispositivos IoT

Windows 10 IoT Core funciona con varios silicios que se usan en cientos de dispositivos. De los dispositivos de desarrollo de IoT sugeridos, los siguientes proporcionan funcionalidad de TPM de firmware de fábrica, junto con las funcionalidades de Arranque seguro, Arranque medido, BitLocker y Device Guard:

  • Qualcomm DragonBoard 410c

    Para habilitar el arranque seguro, puede ser necesario aprovisionar RPMB. Una vez que se ha parpadeado eMMC con Windows 10 IoT Core (según las instrucciones aquí, presione [Power] + [Vol+] + [Vol-] simultáneamente en el dispositivo al encender y seleccione "Aprovisionar RPMB" en el menú BDS. Tenga en cuenta que se trata de un paso irreversible.

  • Intel MinnowBoardMax

    Para MinnowBoard Max de Intel, la versión de firmware debe ser 0.82 o posterior (obtenga el firmware más reciente). Para habilitar las funcionalidades de TPM, enciende la placa con un teclado y pantalla conectado y presiona F2 para entrar en la configuración de UEFI. Vaya a Administrador de dispositivos -> Configuración del sistema -> Configuración de seguridad -> PTT y establézcalo en <Habilitar>. Presione F10 para guardar los cambios y continuar con un reinicio de la plataforma.

Nota:

Raspberry Pi 2 ni 3 no admite TPM y, por tanto, no podemos configurar escenarios de bloqueo.

Generación de paquetes de bloqueo

Siga las instrucciones de los dos vínculos siguientes:

Probar paquetes de bloqueo

Puede probar los paquetes de seguridad generados aquí <YOUR_IOT_ADD_ON_WORKSPACE>\Build<ARCH><OEM_NAME>. Security.* .cab> mediante la instalación manual de ellos en un dispositivo desbloqueado mediante los pasos siguientes

  1. Flashe el dispositivo con la imagen desbloqueada (imagen usada para el examen en paso anterior).

  2. Conectar al dispositivo (mediante SSH o mediante PowerShell)

  3. Copie los siguientes archivos .cab en el dispositivo en un directorio, por ejemplo, c:\OemInstall

    • OEM. Custom.Cmd.cab
    • OEM. Security.BitLocker.cab
    • OEM. Security.SecureBoot.cab
    • OEM. Security.DeviceGuard.cab

  4. Iniciar el almacenamiento provisional de los paquetes generados mediante la emisión de los siguientes comandos

    applyupdate -stage c:\OemInstall\OEM.Custom.Cmd.cab

    Si usa una imagen personalizada, tendrá que omitir este archivo y editar manualmente con c:\windows\system32\oemcustomization.cmd el contenido disponible en Output\OEMCustomization\OEMCustomization.cmd el archivo.

    applyupdate -stage c:\OemInstall\OEM.Security.BitLocker.cab
applyupdate -stage c:\OemInstall\OEM.Security.SecureBoot.cab
applyupdate -stage c:\OemInstall\OEM.Security.DeviceGuard.cab

  5. Por último, confirme los paquetes mediante

    applyupdate -commit

  6. El dispositivo se reiniciará en el sistema operativo de actualización (mostrando engranajes) para instalar los paquetes y se reiniciará de nuevo en el sistema operativo principal. Una vez que el dispositivo se reinicie en MainOS, se habilitará el arranque seguro y se debe activar SIPolicy.

  7. Reinicie el dispositivo de nuevo para activar el cifrado de BitLocker.

  8. Prueba de las características de seguridad

    • SecureBoot: pruebe bcdedit /debug on , recibirá un error que indica que el valor está protegido por la directiva de arranque seguro.
    • BitLocker: ejecute start /wait sectask.exe -waitencryptcomplete:1, si ERRORLEVEL es -2147023436 (ERROR_TIMEOUT), el cifrado no se ha completado. Al ejecutar sectask.exe desde un archivo de .cmd omita .start /wait
    • DeviceGuard: ejecute cualquier binario sin firmar o un binario firmado con el certificado no en la lista SIPolicy y confirme que no se puede ejecutar.

Generar imagen de bloqueo

Después de validar que los paquetes de bloqueo funcionan según la configuración definida anteriormente, puede incluir estos paquetes en la imagen siguiendo los pasos indicados a continuación. Lea la guía de fabricación de IoT para obtener instrucciones de creación de imágenes personalizadas.

  1. En el directorio del área de trabajo, actualice los siguientes archivos desde el directorio de salida generado anterior.

    • SecureBoot : Copy ..\Output\SecureBoot\*.bin ..\Workspace\Common\Packages\Security.SecureBoot
      • SetVariable_db.bin
      • SetVariable_kek.bin
      • SetVariable_pk.bin
    • Bitlocker: Copy ..\Output\Bitlocker\*.* ..\Workspace\Common\Packages\Security.Bitlocker
      • DETask.xml
      • Security.Bitlocker.wm.xml
      • setup.bitlocker.cmd
    • DeviceGuard : Copy ..\Output\DeviceGuard\*.* ..\Workspace\Common\Packages\Security.DeviceGuard
      • SIPolicyOn.p7b
      • SIPolicyOff.p7b

  2. Agregue RetailOEMInput.xml y TestOEMInput.xml en el directorio ProductName con el identificador de característica del paquete de bloqueo

    • <Feature>SEC_BITLOCKER</Feature>
    • <Feature>SEC_SECUREBOOT</Feature>
    • <Feature>SEC_DEVICEGUARD</Feature>

  3. Volver a generar la imagen

    • buildpkg all (esto genera nuevos paquetes de bloqueo en función de los archivos de directiva anteriores)
    • buildimage ProductName test(or)retail (esto genera un nuevo flash.ffu)

  4. Flashe el dispositivo con este nuevo Flash.ffu y valide las características de seguridad.

Consulte SecureSample como ejemplo de una configuración de la placa dragon de bloqueo.

Desarrollo con el cumplimiento de CodeSigning habilitado

Una vez que se generan los paquetes y se activa el bloqueo, los archivos binarios introducidos en la imagen durante el desarrollo deberán firmarse correctamente. Asegúrese de que los archivos binarios en modo de usuario estén firmados con la clave *.\Keys\ **-UMCI.pfx. Para la firma en modo kernel, como para controladores, deberá especificar sus propias claves de firma y asegurarse de que también se incluyen en siPolicy anterior.

Desbloqueo de unidades cifradas

Durante el desarrollo y las pruebas, al intentar leer contenido de un dispositivo cifrado sin conexión (por ejemplo, tarjeta SD para MinnowBoardMax o eMMC de DragonBoard a través del modo de almacenamiento masivo USB), se puede usar "diskpart" para asignar una letra de unidad al volumen MainOS y Data (supongamos que v: para MainOS y w: para Datos). Los volúmenes aparecerán bloqueados y deberán desbloquearse manualmente. Esto se puede hacer en cualquier máquina que tenga instalado el certificado OEM-DRA.pfx (incluido en el ejemplo DeviceLockDown). Instale PFX y, a continuación, ejecute los siguientes comandos desde un símbolo del sistema de CMD administrativo:

  • manage-bde -unlock v: -cert -cf OEM-DRA.cer
  • manage-bde -unlock w: -cert -cf OEM-DRA.cer

Si es necesario tener acceso frecuente al contenido sin conexión, se puede configurar el bloqueo automático de BitLocker para los volúmenes después del desbloqueo inicial mediante los comandos siguientes:

  • manage-bde -autounlock v: -enable
  • manage-bde -autounlock w: -enable

Deshabilitación de BitLocker

Si surge la necesidad de deshabilitar temporalmente BitLocker, inítete una sesión remota de PowerShell con el dispositivo IoT y ejecute el siguiente comando: sectask.exe -disable.

Nota:

El cifrado del dispositivo se volverá a habilitar en el arranque del dispositivo posterior, a menos que la tarea de cifrado programada esté deshabilitada.