SecureBootModel en OpenCore 0.7.2

por

Apple Secure Boot es la tecnología utilizada por Apple en los Mac para verificar la integridad del sistema operativo en el arranque: bootloader > Kernel > instantánea del volumen de sistema. Si esta comprobación falla, MacOS no arrancará. Apple Secure Boot sólo funciona durante el proceso de arranque, una vez que MacOS se está ejecutando ya no realiza ninguna función. Nota: es muy recomendable leer las guías de Dortania: applesecureboot.md, uefisecureboot.md y vault.md.

1. SecureBootModel en OpenCore

Apple define 3 modos de Secure Boot:

  • Seguridad completa (Full Security): sólo permite arrancar el sistema operativo instalado u otra versión firmada de macOS en la que Apple confía actualmente. También verifica la integridad de la versión instalada. Si la verificación falla, el sistema ofrece reinstalar macOS o arrancar desde un disco diferente.
  • Seguridad media (Medium Security): verifica que la versión instalada de MacOS es legítima pero no comprueba la integridad del sistema. Permite arrancar cualquier versión firmada de MacOS en la que Apple haya confiado en algún momento.
  • Sin seguridad (No Security): se permiten otros sistemas o versiones diferentes de las mencionadas en las opciones seguras. No hay requisitos respecto al sistema operativo de arranque.

El estado actual de Apple Secure Boot en los Mac con procesador Intel puede obtenerse desde NVRAM:

nvram 94b73556-2197-4702-82a8-3e1337dafbfb:AppleSecureBootPolicy

Si la variable existe, puede ser:

  • %02 – Full Security
  • %01 – Medium Security
  • %00 – No Security.

Si la variable no existe, Apple Secure Boot no es soportado.

Opencore tiene una clave SecureBootModel que ajusta el modo de Apple Secure Boot para que funcione como en los Mac. Esta clave ha cambiado en Opencore versión 0.7.2:

  • En Opencore 0.7.1, el valor Failsafe para SecureBootModel es Default, este valor establece el modelo de hardware de arranque seguro como j137 (iMacPro1,1,1 de diciembre de 2017, macOS mínimo 10.13.2). Esto significa que las versiones de macOS anteriores a 10.13.2 no se pueden instalar con este valor de SecureBootModel.
  • A partir de Opencore 0.7.2, el valor Failsafe para SecureBootModel sigue siendo Default pero ahora establece un modelo de hardware de arranque seguro como x86legacy, nuevo valor que corresponde a macOS 11 Big Sur y 12 Monterey en hardware sin chip T2 (como nuestro hackintosh) y VM (máquinas virtuales).

Observa que a partir de OpenCore 0.7.2:

  • x86legacy está diseñado para máquinas sin chip T2 con Big Sur y Monterey
  • j137 no funciona en Monterey
  • j137 es el valor recomendado para macOS desde 10.13.2 hasta 10.15.x
  • sistemas anteriores a macOS 10.13.2 han de poner SecureBootModel=Disabled
  • quienes no desean tener Apple Secure Boot por la razón que sea pueden poner SecureBootModel=Disabled, incluso en Monterey
  • SecureBootModel puede adoptar el valor, de la lista de valores válidos, que se corresponda con la versión de macOS que deseas arrancar (por ejemplo j160 para macOS Catalina 10.15.1).

Estos son los valores válidos de SecureBootModel en OpenCore 0.7.2:

  • Default – Modelo reciente, actualmente establecido en x86legacy
  • Disabled – Sin modelo, Secure Boot está deshabilitado
  • j137 – iMacPro1,1 (diciembre de 2017) macOS 10.13.2 o posterior
  • j680 – MacBookPro15,1 (julio de 2018) macOS 10.13.6 o posterior
  • j132 – MacBookPro15,2 (julio de 2018) macOS 10.13.6 o posterior
  • j174 – MacMini8,1 (octubre de 2018) macOS 10.14 o posterior
  • j140k – MacBookAir8,1 (octubre de 2018) macOS 10.14.1 o posterior
  • j780 – MacBookPro15,3 (mayo de 2019) macOS 10.14.5 o posterior
  • j213 – MacBookPro15,4 (julio de 2019) macOS 10.14.5 o posterior
  • j140a – MacBookAir8,2 (julio de 2019) macOS 10.14.5 o posterior
  • j152f – MacBookPro16,1 (noviembre de 2019) macOS 10.15.1 o posterior
  • j160 – MacPro7,1 (diciembre de 2019) macOS 10.15.1 o posterior
  • j230k – MacBookAir9,1 (2020 de marzo) macOS 10.15.3 o posterior
  • j214k – MacBookPro16,2 (mayo de 2020) macOS 10.15.4 o posterior
  • j223 – MacBookPro16,3 (mayo de 2020) macOS 10.15.4 o posterior
  • j215 – MacBookPro16,4 (junio de 2020) macOS 10.15.5 o posterior
  • j185 – iMac20,1 (2020 de agosto). macOS 10.15.6 o posterior
  • j185f – iMac20,2 (2020 de agosto). macOS 10.15.6 o posterior
  • x86legacy – Mac sin chip t2 y VM (máquinas virtuales). macOS 11.0.1 o posterior.

Estos ordenadores Mac tienen chip de seguridad T2 de Apple (coinciden con la lista de valores de SecureBootModel):

  • iMac (2020)
  • Mac Pro (2019)
  • Mac Pro (Rack, 2019)
  • Mac mini (2018)
  • MacBook Air (2020)
  • MacBook Air (2019)
  • MacBook Air (2018)
  • MacBook Pro (2020)
  • MacBook Pro (2019)
  • MacBook Pro (2018)
  • iMac Pro (2017).

iMac19,1 (marzo de 2019 – macOS 10.14.4 o posterior) no está en la lista porque carece de chip T2.
Si no te sientes seguro con los sistemas operativos antiguos, siempre puedes poner el modelo que sólo admita las versiones de macOS que necesitas, y no las anteriores. Por ejemplo, j140K filtrará 10.13 y anteriores, j152F filtrará 10.14 y anteriores, x86legacy filtrará 10.15 y anteriores.

2. Apple Secure Boot en el hackintosh

macOS tiene su propia implementación de arranque seguro llamada Apple Secure Boot, esta función se puede utilizar con UEFI Secure Boot deshabilitado en BIOS. ¿Cómo conseguir Apple Secure Boot en Hackintosh? OpenCore puede proporcionar un arranque seguro mediante 3 claves de config.plist:

  • Misc >> Security >> DmgLoading: para establecer la política de carga de DMG en OpenCore; puede ser Any (el arranque falla si Secure Boot está habilitado), Signed y Disabled (ambas admiten arranque seguro)
  • Misc >> Security >> SecureBootModel: para configurar el modelo de hardware de Apple Secure Boot; SecureBootModel distinto de Disabled equivale a Medium Security, para Full Security debes utilizar también ApECID
  • Misc >> Security >> ApECID: permite usar identificadores personalizados de arranque seguro de Apple y tener Full Security cuando se combina con SecureBootModel.

Para el valor ApECID, hay que obtener un entero de 64 bits generado aleatoriamente de forma criptográfica. Puedes usar el comando de Bash urandom en Terminal. Esta herramienta genera un entero aleatorio de 32 bits, si ejecutamos la herramienta dos veces y combinamos los 2 enteros de 32 bits obtenemos un valor de 64 bits. Copia este texto en un archivo, guárdalo con extension sh y ejecútalo con doble clic:

#!/bin/sh
# primer entero de 32 bit
low32=$(od -An -N4 -tu4 < /dev/urandom)
# segundo entero de 32 bit
high32=$(od -An -N4 -tu4 < /dev/urandom)
# uniendo los 2 enteros
long=$(($low32 + ($high32 << 32)))
# quitando el signo - inicial si existe
echo $long | sed 's/-//'

Ahora puedes introducir el resultado en Misc -> ApECID en el archivo config.plist.

Nota: no uses random en lugar de urandom, no es criptográficamente seguro.

Cuando se usa ApECID, SecureBootModel debe tener un valor definido en lugar de Default. Yo me he encontrado con el problema de que x86legacy proporciona Medium Security y sólo valores que se corresponden con modelos de Mac que tienen chip T2 (ejemplo: j185, j137) permiten personalizar el volumen de arranque y conseguir Full Security. Recuerda que SecureBootModel y SMBIOS son cosas diferentes, no es obligatorio tener en ambas claves el mismo modelo de Mac y realmente no hay mejoras ni desventajas si son iguales.

La primera vez que arrancas con ApECID hay que personalizar el volumen de arranque. Para ello:

  • Arranca en modo Recovery
  • Asegúrate de tener conexión a internet
  • Abre Terminal
  • bless –folder /Volumes/HD/System/Library/CoreServices –bootefi –personalize
    (reemplaza HD con el nombre de tu volumen de sistema)
  • Reinicia a macOS.

SecureBootModel y ApECID:

  • con SecureBootModel=Disable >> No Security (%00)
  • con SecureBootModel=x86legacy o cualquiera de los valores válidos >> Medium Security (%01)
  • con SecureBootModel=cualquiera de los valores con chip T2 más ApECID >> Full Security (%02).

3. Vault

Es una forma de aumentar la seguridad en OpenCore firmando digitalmente OpenCore.efi de manera que nadie excepto tú puede modificar el boot loader.

Como tarea inicial hay que modificar config.plist:

  • Misc >> Security >> Vault:
    – Basic: requiere solamente el archivo vault.plist, se usa para verificar la integridad del sistema de archivos
    – Secure: requiere ambos archivos vault.plist y vault.sig, mejora la seguridad ya que cualquier cambio en vault.plist requiere una nueva firma digital
  • Booter >> ProtectSecureBoot=Yes >> suelen necesitarlo los firmwares UEFI hechos por Insyde para evitar problemas con las claves seguras.

Después hay que copiar la carpeta OpenCore/Utilities/CreateVault para colocarla junto a la carpeta EFI dentro de la partición EFI. La ruta resultante ha de quedar así: partición EFI/carpeta Utilities/carpeta CreateVault.

.
├── EFI
│   ├── BOOT
│   └── OC
├── Utilities
│   └── CreateVault
│       ├── RsaTool
│       ├── create_vault.sh
│       └── sign.command
└──

Dentro de CreateVault hay 3 archivos: create_vault.sh, RsaTool y sign.command.
Ejecuta sign.command para generar un hash para cada archivo de la carpeta EFI, escribirlos en el archivo vault.plist y crear una firma de 256 bytes de vault.plist que será introducida dentro del archivo OpenCore.efi.

¿Cómo desactivar Vault?

  • Consigue una copia nueva de OpenCore.efi
  • Misc >> Security >> Vault >> Optional
  • Elimina los archivos vault.plist y vault.sig.

4. Secure Boot habilitado en BIOS

Windows 10 arranca bien con Secure Boot habilitado o deshabilitado en BIOS. Pero Opencore sólo arranca con Secure Boot deshabilitado en BIOS. Esto no es importante para los usuarios que solamente utilizan macOS. Pero como Windows 11, cerca de su lanzamiento final, parece requerir Secure Boot habilitado en BIOS, es importante para los usuarios que usan macOS y Windows juntos y planean actualizar a Windows 11.

Este tema tiene su propio artículo: OpenCore y UEFI Secure Boot con WSL.

Nota importante: en el momento actual no es posible tener a la vez UEFI Secure Boot + Vault. Dado que ambos sistemas firman o modifican el archivo OpenCore.efi, cuando el segundo sistema en ser aplicado modifica este archivo rompe la integridad guardada por el sistema aplicado en primer lugar. Es indiferente cuál de los 2 se aplica antes, después de hacer firma digital + vault (o en orden inverso) OpenCore no arranca con un aviso de corrupción de OpenCore.efi.

Deja un comentario