Cómo firmar controladores en Windows paso a paso

Última actualización: 17/12/2025
Autor: Isaac
  • Windows exige firmas digitales válidas para la mayoría de controladores en 64 bits, especialmente los de modo kernel, para garantizar integridad y seguridad.
  • La firma puede aplicarse tanto a binarios como a catálogos, usando herramientas como SignTool o Visual Studio y certificados emitidos por entidades confiables.
  • Los certificados autofirmados facilitan el desarrollo y pruebas de drivers sin firmar en Windows 7, 8.1 y 10 x64, pero no sustituyen a la firma comercial para distribución pública.
  • La compatibilidad entre versiones de Windows depende de usar algoritmos de hash adecuados (como SHA2) y seguir las directrices de Microsoft y WHQL.

firma de controladores en windows

Firmar un controlador en Windows puede parecer, a primera vista, un tema reservado a desarrolladores muy avanzados, pero si trabajas con dispositivos, drivers a medida o entornos de pruebas, tarde o temprano te vas a topar con este requisito. En los sistemas modernos, sobre todo en 64 bits, Windows ya no se fía de cualquier binario que intente colarse en el kernel: quiere firmas digitales válidas, algoritmos modernos como SHA2 y, en muchos casos, certificación a través de Microsoft.

En las siguientes líneas vamos a ver con calma qué significa exactamente firmar un controlador, qué diferencias hay entre modo kernel y modo usuario, cómo afecta a Windows 7, 8, 8.1 y 10 de 64 bits, qué papel juegan herramientas como SignTool o Visual Studio, y qué opciones tienes tanto para entornos de desarrollo (certificados de prueba o autofirmados) como para lanzamientos públicos con certificados emitidos por una entidad de confianza.

Qué es la firma de controladores en Windows y por qué es obligatoria

La firma de controladores en Windows consiste en asociar una firma digital a un paquete de driver (binarios, archivos INF, catálogo, etc.) con el fin de garantizar dos cosas: que nadie ha manipulado los archivos desde que se crearon y que proceden realmente del editor indicado (el proveedor del software o fabricante del hardware).

En la práctica, durante la instalación de un dispositivo Windows utiliza estas firmas digitales para verificar la integridad del paquete y la identidad del publicador. Si algo no cuadra (firma corrupta, certificado no confiable, hash incorrecto, etc.), el sistema mostrará advertencias, bloqueará la instalación o directamente se negará a cargar el controlador.

Desde Windows Vista de 64 bits en adelante, y especialmente en Windows 7, 8, 8.1 y 10 x64, la política de seguridad en modo kernel es clara: todo driver que vaya a ejecutarse en el kernel debe estar firmado correctamente. De lo contrario, el controlador no se carga, el dispositivo puede quedar inoperativo e incluso se pueden producir pantallazos azules si se forza la carga de binarios no válidos.

Cuando decides certificar tu controlador con Microsoft, puedes enviarlo al proceso de validación de Windows Hardware Quality Labs (WHQL). Si el paquete de drivers pasa las pruebas de certificación, Microsoft otorga su firma WHQL oficial. Esto no solo mejora la confianza y compatibilidad, sino que además te permite distribuir el controlador a través de Windows Update y otros canales de distribución soportados por Microsoft.

Es importante tener en mente que a partir de la versión 1507 de Windows 10, todos los controladores firmados a través del Centro de desarrollo de hardware de Microsoft se firman usando SHA2 como algoritmo de hash. SHA1 ha quedado obsoleto para estos escenarios, y mezclar certificados antiguos puede provocar problemas especialmente en sistemas recientes.

explicación firma de drivers en windows

Diferencias entre firma de controladores en modo kernel y modo usuario

En Windows conviven controladores que se ejecutan en modo kernel y en modo usuario. La política de firma no es exactamente la misma en ambos entornos, aunque tiende a endurecerse con cada nueva versión del sistema operativo.

  Usar el modo Dynamic Lock con Bluetooth en Windows: guía total

Los drivers de modo kernel son los más sensibles, porque se ejecutan en el núcleo del sistema y tienen acceso privilegiado a memoria y hardware. En versiones de 64 bits de Windows Vista y posteriores, estos controladores están obligados a ir firmados para poder cargarse. Esta restricción está directamente relacionada con la estabilidad del sistema y la protección frente a malware que intente inyectarse a bajo nivel.

Por otro lado, los controladores que operan en modo usuario (por ejemplo, muchos drivers de impresora y componentes adicionales) no estaban originalmente sujetos a una obligación tan estricta. De hecho, en versiones antiguas de Windows no era un requisito absoluto que estos drivers fueran firmados. Sin embargo, Microsoft siempre ha recomendado firmarlos por motivos de seguridad, y desde Windows 8 existen escenarios en los que sí se exige firma para determinados tipos de drivers de usuario.

Un ejemplo típico: un controlador de impresora que se instala en un equipo x64 suele mostrar un cuadro de diálogo durante el proceso de instalación para pedir confirmación al usuario. En la práctica, ese paquete tiene que estar correctamente firmado para que la instalación pueda continuar sin bloqueos o alertas críticas de seguridad.

La idea general es que, aunque en modo usuario el requisito no sea universal, Microsoft empuja cada vez más a que todo el software relacionado con drivers esté firmado. Firmarlos permite comprobar de forma fiable quién los ha creado, detectar manipulaciones y reducir el riesgo de que se cuelen componentes maliciosos simulando ser controladores legítimos.

Requisitos de firma y algoritmos SHA en distintas versiones de Windows

Uno de los aspectos que más dolores de cabeza da es la compatibilidad entre versiones de Windows y algoritmos de hash como SHA1 y SHA2. Muchos desarrolladores se encuentran con controladores que funcionan en un sistema pero no en otro, y gran parte de la culpa la tienen los cambios en las políticas de firma.

En sistemas más antiguos, como Windows 7 u 8 de 64 bits, era frecuente trabajar con certificados y firmas basadas en SHA1, aunque Microsoft ya avisaba de que SHA1 se quedaba corto en seguridad. A medida que se ha avanzado hacia Windows 8.1 y 10, se ha ido imponiendo SHA2 como estándar para las firmas de código y de drivers.

En la práctica, algunos fabricantes optaron por firmar los binarios de modo kernel incrustando certificados duales (SHA1 y SHA2) emitidos por entidades que no eran Microsoft. Esos binarios con firmas duales, en determinados casos, no llegan a cargarse en versiones anteriores a Windows 10, y en algunos sistemas Windows 10 pueden incluso provocar bloqueos graves o pantallazos azules.

Para mitigar estos problemas, Microsoft publicó parches específicos, como la actualización KB 3081436. Al instalar esta actualización en sistemas afectados, se corrigen incompatibilidades con ciertos controladores firmados en SHA2, y se proporciona una lista de valores hash SHA de referencia en la sección “Más información – Información del hash del archivo” de dicho artículo de soporte.

Si vas a distribuir controladores que deban funcionar en varias versiones de Windows, es fundamental revisar los requisitos de firma por versión detallados por Microsoft. Ahí se especifica qué algoritmos son válidos, cómo se trata la compatibilidad hacia atrás y qué combinaciones de firma (catálogo, binario incrustado, certificados cruzados, etc.) son aceptadas oficialmente.

  Cómo solucionar problemas comunes de impresión en Windows

Firma de controladores en modo usuario: recomendaciones y recursos

Aunque muchas veces el foco se lo lleva el kernel, la firma de controladores en modo usuario también merece atención. Microsoft no la impuso de manera tan estricta desde el principio, pero sí la recomienda encarecidamente para preservar la seguridad del sistema y ofrecer confianza al usuario final.

La firma de un driver de modo usuario cumple básicamente las mismas funciones que en modo kernel: identifica al proveedor del controlador (fabricante, ISV, etc.) y confirma que el paquete no ha sido modificado desde que se firmó. Cuando un usuario instala, por ejemplo, una impresora con drivers de modo usuario en un equipo x64, el asistente de instalación puede mostrar un cuadro de diálogo que pregunta si se confía en el editor. Si la firma es válida y el certificado pertenece a una entidad reconocida, la instalación es más fluida y con muchas menos advertencias.

Microsoft proporciona una serie de documentos y tutoriales que profundizan en el proceso de firma, muchos de ellos originalmente pensados para modo kernel pero aplicables también al modo usuario. El artículo principal de firma de controladores y el subtema “Cómo firmar como versión un módulo de kernel” dentro del tutorial de firma de código en modo kernel son buenos puntos de partida para entender la lógica general de la firma de código en Windows.

Además, dentro de la instalación del Windows Driver Kit (WDK) se incluye un archivo de ayuda llamado selfsign_readme.htm, ubicado en el directorio selfsign. Este documento explica cómo generar certificados de prueba y cómo utilizarlos durante el desarrollo, algo especialmente útil cuando aún no dispones de un certificado emitido por una entidad raíz de confianza.

En resumen, aunque un controlador en modo usuario pueda funcionar técnicamente sin firma en algunos escenarios, conviene tratarlo como si fuera obligatorio. A nivel de seguridad, imagen de marca y compatibilidad con los asistentes de instalación de Windows, firmar el driver es lo más sensato.

Firma de drivers de modo kernel en Windows 7 y 8 usando SignTool

Cuando trabajas con Windows 7 y 8 de 64 bits, uno de los enfoques más habituales para firmar controladores de modo kernel es usar la herramienta de línea de comandos SignTool, incluida en el SDK de Windows. Esta utilidad permite tanto firmar archivos como verificar las firmas existentes, y acepta bastantes opciones para adaptarse a distintos escenarios.

Algunas de las opciones más importantes de SignTool son las siguientes:

  • /ac: especifica un certificado adicional, por ejemplo, un certificado cruzado que enlaza tu certificado con una entidad raíz de confianza.
  • /f: indica el archivo que contiene el certificado de firma (habitualmente un .pfx).
  • /p: proporciona la contraseña asociada al certificado de firma almacenado en el archivo .pfx.
  • /fd: define el algoritmo de hash utilizado al crear la firma del archivo, por ejemplo, /fd sha256 para generar una firma basada en SHA256 (si no se indica nada, SHA1 suele ser el valor por defecto en versiones más antiguas).
  • /n «Nombre común del certificado»: permite seleccionar un certificado concreto del almacén de certificados de Windows a partir de su nombre común (CN).
  • /t: especifica un servidor de sellado de tiempo compatible con el esquema Authenticode de Microsoft.
  • /tr: indica un servidor de marca de tiempo compatible con RFC 3161, más moderno y recomendable para nuevas implementaciones.
  SYSTEM_SERVICE_EXCEPTION (0x0000003B): causas, diagnóstico y soluciones

A la hora de trabajar con tu proyecto de controlador, es importante tener claro qué archivos se deben firmar. Para que un driver se instale correctamente en Windows 7 u 8, hay que firmar todos los binarios relevantes del proyecto (por ejemplo, archivos .sys) y también el archivo de catálogo (.cat) que agrupa el conjunto de archivos del paquete.

Tienes dos opciones principales: puedes copiar esos archivos a un directorio de trabajo donde tengas SignTool disponible, o directamente moverlos a la carpeta bin del Windows SDK y ejecutar la herramienta desde ahí. Lo importante es que tengas a mano tanto los binarios como los certificados que vas a usar para la firma.

Un escenario típico consiste en adquirir el certificado de firma de código adecuado, por ejemplo, un certificado “Microsoft Cross Certificate” emitido por GlobalSign u otra entidad de confianza. Colocas ese certificado cruzado (CrossCert.crt) en tu directorio de trabajo junto con tu certificado principal de firma de código (por ejemplo, CodeSign.pfx) y ejecutas un comando similar a este:

signtool sign /ac CrossCert.crt /f CodeSign.pfx /p password1234 /tr http://timestamp.globalsign.com/tsa/r6advanced1 filter.sys

Con este comando generas una firma que incluye el certificado cruzado y obtiene un sello de tiempo desde el servidor RFC 3161 de GlobalSign. El sello de tiempo es clave, porque permite demostrar que el archivo se firmó en una fecha en la que el certificado era válido, incluso si más adelante caduca.

Después de firmar el archivo, toca comprobar que todo ha quedado correctamente. Para ello se suele utilizar un comando de verificación como:

signtool verify -v -kp nombre_del_archivo.sys

La opción -v fuerza una salida detallada, mostrando información pormenorizada de la cadena de certificados, y la opción -kp verifica la firma según los criterios de firma de código específicos de drivers de modo kernel. Si todo va bien, verás un resultado indicando que la firma y la cadena de certificados son correctas.

Por último, es recomendable repetir el mismo proceso de firma y verificación con el archivo .cat del paquete. Una vez que tanto los binarios como el catálogo están correctamente firmados, el driver se puede instalar en Windows 7 y 8 x64 sin problemas de seguridad, y durante el asistente de instalación debería aparecer la información del editor de confianza y las ventanas estándar del sistema.

Para profundizar en todas las variantes de la herramienta, Microsoft mantiene una referencia completa de comandos de SignTool, así como un tutorial específico para firma de código en modo kernel y documentación dedicada a las firmas digitales de módulos del kernel en Windows. Esos recursos explican casos especiales, parámetros avanzados y particularidades de cada versión del sistema.