Certificados TLS de servidor
Tráfico web seguro a gran escala
Inventario de certificados
Descubrir y rastrear todos los certificados
Certificados DevOps
Automatizar para pipelines CI/CD
Cifrado de correo electrónico
S/MIME para correo electrónico empresarial
Cada vez que un usuario instala software, su sistema operativo debe decidir si confiar en él. Los certificados de firma de código son el mecanismo que cierra esa brecha de confianza, demostrando la identidad del publicador y garantizando que el código no ha sido manipulado desde que se firmó.
Los ataques a la cadena de suministro de software se han convertido en una de las categorías más dañinas de incidentes de ciberseguridad. Cuando los atacantes comprometen una canalización de compilación o inyectan código malicioso en una aplicación legítima, el impacto se propaga a cada usuario que descarga y ejecuta el software manipulado. Incidentes de alto perfil, desde la brecha de SolarWinds hasta paquetes npm comprometidos, han demostrado que confiar en el software por defecto ya no es viable.
La firma de código aborda este problema en su origen. Al adjuntar una firma criptográfica a un ejecutable, biblioteca, controlador o script, el desarrollador crea una prueba verificable de que el código proviene de una fuente conocida y no ha sido modificado desde su publicación. Los sistemas operativos, navegadores y herramientas de seguridad empresarial utilizan estas firmas para tomar decisiones de confianza: el código firmado de un editor reconocido se ejecuta sin problemas, mientras que el código no firmado o manipulado genera advertencias o se bloquea por completo.
Un certificado de firma de código es el certificado digital que hace esto posible. Emitido por una autoridad de confianza Autoridad de Certificación, vincula la identidad del publicador's a una clave pública y es usado por herramientas de firma para producir firmas que los sistemas operativos pueden verificar.
El proceso de firma de código sigue un modelo sencillo de tres pasos: hash, firma y verificación. Aquí está lo que ocurre en cada etapa:
La herramienta de firma calcula un criptográfico hash (normalmente SHA-256) del binario, script o paquete. Este hash es una huella digital única: incluso un cambio de un solo byte en el código producirá un valor de hash completamente diferente.
El hash se cifra con la clave privada del desarrollador's, produciendo la firma digital. La firma, junto con el certificado de firma de código (que contiene la clave pública y la identidad verificada del publicador's), se incrusta en el archivo o se adjunta junto a él.
Cuando el usuario descarga o ejecuta el software, el sistema operativo extrae la firma y utiliza la clave pública del editor para descifrar el hash. Luego genera de forma independiente el hash del archivo descargado. Si los dos hashes coinciden y el certificado se encadena a una CA de confianza, el software se verifica como auténtico y sin alteraciones.
Si alguien modifica el código después de firmarlo, ya sea un atacante que inyecta malware o un error de descarga que corrompe el archivo, la comparación de hash falla. El sistema operativo entonces advierte al usuario o bloquea la ejecución por completo, dependiendo de la política de seguridad de la plataforma.
Los certificados de firma de código se presentan en dos categorías principales, cada una con diferentes requisitos de validación y niveles de confianza:
La CA verifica la identidad de la organización o individuo que solicita el certificado. En Windows, el software firmado con un certificado estándar inicialmente generará advertencias de SmartScreen hasta que el editor adquiera suficiente reputación mediante el volumen de descargas. La clave privada puede almacenarse en software (un archivo PFX) o en un token de hardware, aunque desde junio de 2023, las reglas del foro CA/Browser exigen almacenamiento de claves basado en hardware para todos los certificados de firma de código.
Los certificados EV requieren un proceso de verificación más riguroso que incluye la comprobación de la existencia legal de la organización, su dirección física y su estado operativo. En Windows, el software firmado con EV recibe reputación inmediata de SmartScreen, lo que significa que los usuarios ven el nombre del editor en el cuadro de diálogo en lugar de una advertencia. La clave privada debe almacenarse en un FIPS 140-2 Nivel 2 (o superior) módulo de seguridad de hardware o token. Los certificados EV son necesarios para firmar controladores de modo kernel de Windows.
Para las organizaciones que distribuyen software comercial, la firma de código EV es típicamente la opción preferida porque elimina la fricción de SmartScreen y transmite un nivel más alto de confianza a los usuarios finales. Para herramientas y scripts internos, un certificado OV estándar, o uno emitido por una CA interna, suele ser suficiente.
Los certificados de firma de código tienen un período de validez finito, típicamente de uno a tres años. Sin medidas adicionales, todas las firmas producidas por un certificado quedarían inválidas en el momento en que el certificado expire. Esto obligaría a los publicadores a volver a firmar cada binario cada vez que renueven su certificado, lo que es poco práctico.
Una Autoridad de Marca de Tiempo (TSA) de confianza agrega una marca de tiempo firmada criptográficamente a la firma en el momento de la firma. Esto demuestra que el código se firmó mientras el certificado aún era válido, incluso si el certificado expira o es revocado más adelante.
Sin la marca de tiempo, un certificado expirado invalida retroactivamente todas sus firmas. Las firmas con marca de tiempo permanecen válidas indefinidamente, lo que es crítico para el software que permanece en producción durante años, como firmware, controladores y aplicaciones empresariales de larga duración.
Dos protocolos de sellado de tiempo se utilizan ampliamente. RFC 3161 es el protocolo estándar compatible en todas las plataformas. El sellado de tiempo Microsoft Authenticode es un protocolo más antiguo, específico de Windows. La mayoría de las herramientas de firma admiten ambos; la mejor práctica es usar RFC 3161 para una mayor compatibilidad.
Siempre añada una marca de tiempo a cada firma. No cuesta nada (los servicios TSA son gratuitos), no añade sobrecarga a la experiencia del usuario y evita una clase de problemas que es dolorosa de corregir después del hecho. Muchas organizaciones hacen que el sellado de tiempo sea un paso obligatorio en su canal CI/CD.
Cada plataforma principal tiene su propio ecosistema de firma de código con diferentes herramientas, formatos y almacenes de confianza. Comprender estas diferencias es esencial para las organizaciones que distribuyen software multiplataforma:
Microsoft's Authenticode es el marco de firma de código más utilizado. Cubre EXE, DLL, MSI, MSIX y scripts de PowerShell. El signtool.exe utilidad maneja la firma, y Windows SmartScreen usa la reputación del publicador para decidir si advierte a los usuarios. Los controladores de modo kernel requieren certificados EV y deben enviarse al Microsoft Hardware Developer Center para una firma de atestación adicional.
Apple's requiere que los desarrolladores firmen aplicaciones con un certificado emitido por el propio programa Developer ID de Apple's. Más allá de la firma, macOS Catalina y versiones posteriores requieren notarización, donde el desarrollador sube el binario firmado al servicio de notaría de Apple's, que lo escanea en busca de malware y emite un ticket. Gatekeeper luego verifica tanto la firma como el ticket de notarización antes de permitir la ejecución. Sin notarización, macOS bloqueará la aplicación.
Las aplicaciones y applets de Java se firman usando el jarsigner herramienta con un certificado estándar de firma de código almacenado en un Java KeyStore. El entorno de ejecución de Java verifica las firmas y puede aplicar políticas de seguridad basadas en la identidad del editor. Esto es particularmente importante para las aplicaciones Java empresariales desplegadas a través de repositorios internos.
Los gestores de paquetes de Linux (RPM, dpkg) admiten la firma basada en GPG con sus propios modelos de confianza. Para imágenes de contenedores, herramientas como Cosign (del proyecto Sigstore) y Docker Content Trust ofrecen capacidades de firma y verificación. A medida que el despliegue basado en contenedores crece, la firma de imágenes de contenedores se está convirtiendo en una parte estándar de las canalizaciones CI/CD seguras.
La firma de código es un mecanismo de confianza potente, pero solo es tan fuerte como las prácticas que la rodean. Las organizaciones enfrentan varios riesgos comunes:
Si un atacante roba la clave privada utilizada para la firma de código, puede firmar malware que parece provenir de un editor legítimo. Este es el riesgo de mayor impacto y es la razón por la que el Foro CA/Browser ahora exige el almacenamiento de claves en hardware. Las organizaciones deben almacenar las claves de firma en HSM, restringir el acceso al proceso de firma y mantener registros de auditoría de cada operación de firma.
Cuando un certificado de firma de código expira y las firmas no fueron marcadas con sello de tiempo, cada binario firmado se vuelve no confiable simultáneamente. Para el software ya desplegado en miles de puntos finales, esto puede generar advertencias de seguridad, bloquear el lanzamiento de aplicaciones y crear una crisis operativa urgente que es difícil de resolver rápidamente.
Cuando varios desarrolladores o canalizaciones CI/CD pueden firmar código sin supervisión centralizada, no hay garantía de que solo el código revisado y aprobado sea firmado. Un interno o una canalización comprometida podría firmar código malicioso o no probado. La firma debe tratarse como una operación privilegiada con flujos de trabajo de aprobación, acceso basado en roles y auditorías completas.
Las grandes organizaciones a menudo acumulan múltiples certificados de firma de código en diferentes equipos, geografías y sistemas CI/CD, algunos de autoridades certificadoras comerciales, otros de autoridades certificadoras internas. Sin una centralizada gestión del ciclo de vida enfoque, los certificados expiran sin aviso, las claves se almacenan de manera inconsistente y no hay una visión unificada de quién puede firmar qué.
Inventario centralizado de certificados: Evertrust CLM descubre y rastrea cada certificado de firma de código en toda su organización, sin importar qué CA lo emitió o dónde se almacena la clave, brindándole una vista única de toda su infraestructura de firma.
Aplicación de políticas: Defina y haga cumplir las reglas organizacionales sobre qué equipos pueden solicitar certificados de firma de código, qué algoritmos de clave y mecanismos de almacenamiento están permitidos, y qué flujos de aprobación deben seguirse antes de que se emita un certificado.
Ciclo de vida automatizado: Evertrust PKI automatiza la emisión y renovación de certificados de firma de código, integrándose con sus canalizaciones CI/CD para garantizar que los certificados de firma estén siempre actualizados y cumplan con los requisitos, eliminando el riesgo de firmas caducadas en producción.
Auditoría & cumplimiento: Registros de auditoría completos de cada solicitud de certificado, aprobación, emisión y operación de firma, ayudando a su organización a demostrar cumplimiento con las políticas de seguridad internas y los requisitos regulatorios externos.
