- MOK (Machine Owner Key) permite al propietario de la máquina firmar y autorizar binarios y módulos para funcionar con Secure Boot activo.
- MOK Manager gestiona la inscripción de claves mediante una contraseña de un solo uso, sin afectar al arranque de Windows 11 en sistemas dual boot.
- La herramienta mokutil permite comprobar el estado de Secure Boot, importar claves MOK y ajustar políticas avanzadas como SBAT.
- Usar MOK ofrece un equilibrio entre seguridad y flexibilidad, facilitando kernels y controladores personalizados sin desactivar Secure Boot.
Si alguna vez has instalado una distro GNU/Linux junto a Windows 11 con Secure Boot activado, es muy probable que te hayas topado con una misteriosa pantalla azul llamada MOK Manager pidiéndote una contraseña. Para muchos usuarios, sobre todo quienes vienen de placas base antiguas sin UEFI ni TPM, esta pantalla puede parecer casi un mensaje de error fatal… pero no lo es.
Cuando estás montando un arranque dual (por ejemplo, Windows 11 en un SSD y Linux Mint, Debian o Fedora en otro disco) y aparece MOK Manager, no significa que hayas roto nada. Esa pantalla forma parte del propio mecanismo de seguridad de Secure Boot y está ahí precisamente para permitir que tu nuevo sistema Linux arranque sin desactivar dicha función. Entender qué es MOK, por qué te pide una contraseña y qué ocurre con Windows al aceptar esos cambios te va a ahorrar más de un susto.
Qué es MOK (Machine Owner Key) y por qué existe
La sigla MOK viene de Machine Owner Key, es decir, la clave del propietario de la máquina. Esta clave es una pieza más dentro de la cadena de arranque segura de los sistemas UEFI, diseñada para que solo se ejecute durante el boot el código que haya sido aprobado y firmado criptográficamente.
Con la llegada del firmware UEFI y el famoso Secure Boot, los fabricantes (y especialmente Microsoft) impulsaron un modelo en el que el firmware solo confía en binarios firmados por determinadas autoridades. En la práctica, esto implica que el firmware va a verificar la firma de componentes como shim, GRUB, el kernel y ciertos módulos antes de dejarlos arrancar.
El problema es evidente: si solo se admiten firmas “oficiales” (por ejemplo, de Microsoft o del propio fabricante del hardware), cualquier binario que prepares tú mismo, cualquier kernel personalizado o ciertos módulos de terceros (como los controladores de VirtualBox o NVIDIA en algunos casos) no se considerarían de confianza. Ahí es donde entra en juego MOK.
La idea es que el propietario de la máquina pueda tener su propia clave para firmar componentes sin depender de terceros. Esa Machine Owner Key se puede inscribir en la base de datos de claves de Secure Boot, de tal manera que todo lo que firmes con ella se considere igualmente legítimo y pueda ejecutarse durante el arranque sin violar las políticas de seguridad.
En resumidas cuentas, MOK actúa como una capa adicional que te permite integrar tus propios binarios y módulos en el sistema de arranque seguro sin tener que desactivar Secure Boot ni pasar por el aro de las firmas impuestas por otros, algo especialmente útil en entornos Linux donde es habitual compilar y cargar módulos fuera de los repositorios estándar.
Relación entre MOK, Secure Boot, UEFI y SHIM
Para entender mejor dónde encaja MOK dentro del puzzle, conviene repasar cómo se estructura el proceso de arranque UEFI con Secure Boot. En un sistema moderno, el firmware UEFI comprueba primero sus bases de datos de claves y revocaciones antes de lanzar cualquier binario EFI.
En el mundo Linux, casi siempre aparece una pieza intermedia llamada shim. Shim es un pequeño cargador firmado por una autoridad reconocida (habitualmente Microsoft), que sirve de intermediario entre el firmware y el gestor de arranque real: normalmente GRUB. De este modo, el firmware confía en shim porque está firmado “oficialmente”, y shim, a su vez, decide qué binarios posteriores considera válidos para seguir con el arranque.
Es precisamente shim el que integra el uso de la Machine Owner Key. A través de MOK, shim puede confiar en binarios que tú mismo has firmado, siempre que la clave pública correspondiente haya sido inscrita previamente mediante el MOK Manager. De esta manera, el flujo sería algo así: UEFI comprueba la firma de shim, shim valida GRUB y el kernel (y sus módulos) utilizando tanto las claves incluidas por la distribución como las MOK que tú hayas registrado.
Antes de que existiera esta vía, muchas distribuciones necesitaban depender casi por completo de la infraestructura de firma de Microsoft, lo que generaba bastante fricción. Ahora, con MOK, no es obligatorio que todo pase por esa firma centralizada: el dueño de la máquina tiene una vía para asumir parte del control de la cadena de confianza.
En la práctica, esto se traduce en que cuando instalas algunos controladores del kernel, herramientas de virtualización como VirtualBox (módulo vboxdrv) u otros componentes que se cargan muy temprano en el arranque, el sistema te puede pedir que generes un par de claves, firmes los módulos y los inscribas en MOK Manager para que Secure Boot no bloquee su ejecución.
Qué es exactamente MOK Manager y por qué te pide una contraseña
Cuando ves esa famosa pantalla azul tipo “BIOS” en la que se menciona MOK Manager, lo que estás ejecutando es un pequeño programa EFI (normalmente el fichero mmx64.efi) encargado de gestionar las Machine Owner Keys. Este programa se lanza justo después de que hayas solicitado algún cambio en la configuración de las claves de arranque.
Lo habitual es que el proceso comience desde tu sistema Linux, por ejemplo, con un comando como mokutil –import para inscribir una nueva clave pública. Ese comando te pedirá que establezcas una contraseña temporal de uso único, necesaria para que más tarde, durante el reinicio, MOK Manager pueda verificar que eres tú quien autoriza la operación y no un atacante.
En el siguiente arranque, antes de cargar el sistema, el firmware UEFI lanza shim y este, al detectar que hay una nueva clave pendiente de ser inscrita, da paso a MOK Manager. Ahí es donde aparece el menú de gestión, en el que se te invita a realizar alguna de las siguientes acciones: inscribir la nueva clave, borrar claves, ver las ya registradas o continuar sin cambios.
Uno de los errores más comunes es pensar que esa contraseña que pide MOK Manager es la de tu usuario de Linux, la de root o incluso la de Windows. No es así. Se trata de la contraseña de un solo uso que tú mismo escribiste al ejecutar mokutil. Si te equivocas o si el teclado no coincide con el layout esperado (por ejemplo, problema QWERTY/AZERTY), puedes creer que la clave no se inscribe correctamente cuando en realidad solo estás pulsando teclas distintas a las que crees.
Tras introducir correctamente esa contraseña, MOK Manager inscribe la nueva clave en la base de datos correspondiente. A partir de ese momento, todos los binarios y módulos firmados con dicha clave se considerarán de confianza por parte de shim y podrán ejecutarse con Secure Boot activado. Esto incluye kernels personalizados, módulos de terceros o cualquier otro componente que hayas decidido firmar.
Es importante subrayar que aceptar la inscripción de una MOK no rompe el arranque de Windows 11 ni invalida su firma. Windows seguirá arrancando como siempre porque lo que estás haciendo es añadir una clave de confianza adicional, no eliminar ni sustituir las que ya estaban presentes en el sistema.
MOK en escenarios reales: dual boot con Windows 11 y nuevas placas base
Uno de los casos más habituales donde aparece la duda sobre MOK Manager es cuando un usuario, con una placa base moderna que incluye UEFI, TPM y Secure Boot activo por defecto, decide instalar una distro como Linux Mint junto a Windows 11. Si vienes de una placa más antigua sin estas características, es normal que todo esto te suene a “magia negra”.
Imagina el escenario: mantienes la instalación de Windows 11 tal cual en su SSD, activas Secure Boot (porque lo exige el propio Windows para ciertas funciones) y, a la vez, instalas Linux Mint en otro disco. Durante la instalación de Mint, o al instalar después determinados controladores, el sistema puede pedirte una contraseña MOK. Ahí surgen las preguntas: ¿romperé Windows si acepto?, ¿qué pasa si no hago nada?, ¿debería desactivar Secure Boot?
La realidad es que, siempre que sigas el proceso habitual, no hay ningún riesgo para la partición de Windows 11. Secure Boot seguirá operativo, y Windows continuará arrancando sin problemas. Lo único que haces con MOK es decirle al firmware que también confíe en ciertos componentes de Linux que no venían firmados de fábrica, de modo que pueda arrancar en modo seguro sin que el firmware los bloquee.
Muchos instaladores modernos de distribuciones ya automatizan parte de este proceso. Pueden generar la clave, ejecutar los comandos necesarios (por ejemplo, herramientas de alto nivel que internamente llaman a mokutil –import) y programar la aparición de MOK Manager en el siguiente arranque para que solo tengas que aceptar la inscripción.
Si en tu caso estás configurando manualmente drivers más avanzados (por ejemplo, backports de controladores NVIDIA y versiones de kernel más modernas en distros como Debian Buster para que funcionen bien en portátiles gaming recientes), probablemente tengas que dar algunos pasos extra: crear tú mismo el par de claves (normalmente MOK.pem, MOK.der y MOK.priv), firmar los módulos y luego usar mokutil para importar la clave pública.
Esos ficheros no necesitan estar en ninguna ruta mágica del sistema para que MOK Manager funcione. Lo importante es que la clave pública que has importado se encuentre accesible en el momento de la inscripción y que guardes la clave privada (MOK.priv) en un lugar seguro, ya que la necesitarás cada vez que quieras firmar nuevos binarios o módulos con esa misma identidad de propietario.
Uso de mokutil, inscripción de claves y problemas habituales
La herramienta central para gestionar claves MOK desde Linux es mokutil. A través de esta utilidad puedes revisar el estado de Secure Boot, ver las claves ya inscritas, importar nuevas claves, comprobar cuáles están pendientes y modificar ciertas políticas avanzadas relacionadas con el arranque seguro.
Por ejemplo, para saber si Secure Boot está activo en tu máquina, puedes usar el comando mokutil –sb-state. Este comando te indicará si el sistema está arrancando con Secure Boot habilitado, deshabilitado o en algún estado intermedio controlado por UEFI.
Una vez tienes tu par de claves generado (a menudo MOK.pem y MOK.der, junto a la clave privada MOK.priv), el paso típico para preparar la inscripción es ejecutar algo como: mokutil –import MOK.der. Al hacerlo, mokutil te pedirá una contraseña de un solo uso, que deberás recordar porque MOK Manager te la solicitará al reiniciar para confirmar la operación.
Después de importar, puedes comprobar que la clave se ha marcado para inscripción con mokutil –list-new. Ahí deberías ver la clave recién importada en la lista de elementos pendientes. Si todo es correcto, tras el siguiente reboot debería aparecer MOK Manager solicitando que inscribas la nueva clave y que introduzcas la contraseña temporal.
Si tras reiniciar no aparece nada y el sistema arranca directamente a GRUB o al prompt de tu contraseña LUKS, es que algo se ha quedado a medias. En esos casos conviene revisar los mensajes del kernel, por ejemplo con dmesg | grep cert, para ver si aparecen referencias a certificados o claves recién añadidas. También es buena idea confirmar que el fichero mmx64.efi (el binario de MOK Manager) está presente en el directorio /boot/efi o ruta similar usada por tu distribución.
Otro problema muy frecuente tiene que ver con el layout del teclado. La interfaz de MOK Manager (igual que el prompt de contraseñas LUKS en muchas distros atómicas) no suele respetar el mapa de teclado configurado en tu sistema. Lo más habitual es que utilice un diseño US QWERTY por defecto, lo que puede descolocar a usuarios con teclados AZERTY o con disposiciones regionales diferentes.
En la práctica, esto significa que si tu contraseña incluye símbolos o letras cuya posición cambia en tu teclado, es probable que estés introduciendo una secuencia distinta de la que crees. Este desajuste hace que parezca que la contraseña “no funciona”, cuando realmente solo se están interpretando otras teclas. Por eso conviene, al definir la contraseña de un solo uso en mokutil, utilizar caracteres que no cambien de sitio entre tu teclado y el layout US estándar, o mentalizarte de qué teclas estás realmente pulsando en ese mapa.
Verificación, SBAT y gestión avanzada de Secure Boot
Además de gestionar la inscripción de claves MOK, mokutil también permite consultar y ajustar algunos parámetros avanzados vinculados con el mecanismo SBAT (Secure Boot Advanced Targeting). SBAT se emplea, entre otras cosas, para revocar versiones antiguas de componentes críticos del arranque como shim o GRUB2 mediante números de generación.
Las versiones más modernas de mokutil (a partir de la 0.6.0 aproximadamente) incorporan opciones para revisar y actualizar el estado de revocación SBAT. Con el comando mokutil –list-sbat-revocations puedes ver el nivel actual de SBAT en el que está funcionando tu sistema, es decir, qué generación mínima de esos binarios se admite todavía como válida.
En muchos sistemas con Secure Boot activo, la política SBAT por defecto está ajustada a previous. Esto quiere decir que se aplican las revocaciones anteriores, pero puede seguir permitiéndose el arranque de alguna versión relativamente reciente de shim y GRUB2. Si cambias la política con mokutil –set-sbat-policy latest, se aplicará la última capa de revocaciones y se impedirá que arranquen versiones más antiguas de esos componentes.
Por el contrario, existe la opción de retroceder de nuevo a la política previous en caso de necesidad. Ambas políticas (latest y previous) solo pueden establecer un nivel de revocación que no sea anterior al aplicado por el último paquete de shim instalado; es decir, no podrás volver a una situación menos segura que la determinada por las actualizaciones recientes.
Para tareas de diagnóstico extremo o si algo se ha roto tras una actualización compleja, puedes necesitar restablecer la política SBAT al nivel de revocación por defecto. En esos casos, la recomendación general es desactivar Secure Boot primero en el firmware y, solo entonces, usar un comando como mokutil –set-sbat-policy delete, que limpia esa política adicional de revocaciones para que el sistema vuelva al punto de partida marcado por el firmware y el shim actual.
Conviene tener presente que jugar con SBAT y con la revocación de binarios no es algo que debas hacer a la ligera: si revocas versiones que aún estás utilizando, puedes acabar con un sistema que no arranca ni siquiera en modo seguro hasta que reinstales componentes críticos o ajustes de nuevo el firmware UEFI.
¿Es realmente necesario usar MOK y Secure Boot en tu equipo?
Aunque desde el punto de vista teórico todo este mecanismo de MOK, Secure Boot, shim y SBAT aporta una capa de seguridad interesante, no todos los entornos tienen las mismas necesidades. En un entorno doméstico típico, donde el equipo rara vez sale de casa y nadie más tiene acceso físico, el riesgo de que un atacante manipule el arranque sin que te enteres es relativamente bajo.
Secure Boot está pensado sobre todo para escenarios en los que preocupa que alguien con acceso físico pueda inyectar malware en la cadena de arranque o sustituir componentes por versiones maliciosas. Estos casos son más habituales en empresas, centros educativos, laboratorios o equipos compartidos, donde hay muchos usuarios y resulta más difícil controlar quién toca qué.
En casa, si alguien ha forzado la puerta y se ha sentado delante de tu torre, probablemente el mayor problema ya no es si han puesto o no un bootkit en tu UEFI. Aun así, muchas personas prefieren mantener Secure Boot activado porque es un requisito de Windows 11 y porque les da cierta tranquilidad adicional saber que el firmware no va a ejecutar cualquier cosa sin comprobarla.
Ahí es donde MOK se convierte en una buena herramienta de compromiso: te permite seguir disfrutando de Secure Boot y cumplir los requisitos de Windows 11, pero sin renunciar a un Linux totalmente funcional, con controladores propietarios, módulos personalizados o kernels específicos que, en condiciones normales, Secure Boot bloquearía por no estar firmados por las entidades “oficiales”.
Si no quieres complicarte la vida, siempre queda la opción radical de desactivar Secure Boot en la configuración UEFI y olvidarte por completo de MOK, pero perderías esa capa de seguridad en el arranque y, en algunos casos, podrías tener advertencias o limitaciones por parte de Windows. Por eso, en muchos equipos modernos, lo más práctico es aprender a convivir con Secure Boot y usar MOK como herramienta para integrar sin fricciones tus sistemas Linux.
Al final, comprender qué es MOK Manager, para qué sirve mokutil y cómo se articulan estos elementos con UEFI, shim y SBAT te permitirá gestionar con mucha más confianza un entorno de arranque dual o multiboot. Las pantallas azules de MOK dejarán de parecer errores extraños y pasarán a ser simplemente una confirmación de que tienes el control de las claves que gobiernan tu máquina y de qué software puede ejecutarse durante los primeros segundos de vida de tu sistema.
Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.