La firma de código es el proceso de firmar digitalmente ejecutables y scripts para confirmar el autor del software y garantizar que el código no haya sido alterado ni dañado desde que se firmó. El proceso emplea el uso de un hash criptográfico para validar la autenticidad y la integridad. [1] La firma de código fue inventada en 1995 por Michael Doyle, como parte del complemento del navegador Eolas WebWish, que permitía el uso de criptografía de clave pública para firmar el código de un programa de aplicación web descargable utilizando una clave secreta, por lo que el complemento El intérprete de código podría luego usar la clave pública correspondiente para autenticar el código antes de permitirle acceder a las API del intérprete de código. [2]
La firma de código puede proporcionar varias funciones valiosas. El uso más común de la firma de código es brindar seguridad durante la implementación; En algunos lenguajes de programación, también se puede utilizar para ayudar a prevenir conflictos de espacios de nombres. Casi todas las implementaciones de firma de código proporcionarán algún tipo de mecanismo de firma digital para verificar la identidad del autor o del sistema de compilación, y una suma de verificación para verificar que el objeto no haya sido modificado. También se puede utilizar para proporcionar información de versiones de un objeto o para almacenar otros metadatos sobre un objeto. [3]
La eficacia de la firma de código como mecanismo de autenticación para software depende de la seguridad de las claves de firma subyacentes. Al igual que con otras tecnologías de infraestructura de clave pública (PKI) , la integridad del sistema depende de que los editores protejan sus claves privadas contra el acceso no autorizado. Las claves almacenadas en software en computadoras de uso general son susceptibles de verse comprometidas. Por lo tanto, es más seguro y una buena práctica almacenar las claves en dispositivos de hardware criptográficos seguros y a prueba de manipulaciones conocidos como módulos de seguridad de hardware o HSM . [4]
Muchas implementaciones de firma de código proporcionarán una forma de firmar el código utilizando un sistema que involucra un par de claves, una pública y otra privada, similar al proceso empleado por TLS o SSH . Por ejemplo, en el caso de .NET, el desarrollador utiliza una clave privada para firmar sus bibliotecas o ejecutables cada vez que construyen. Esta clave será exclusiva de un desarrollador o grupo o, a veces, por aplicación u objeto. El desarrollador puede generar esta clave por su cuenta u obtener una de una autoridad certificadora (CA) confiable. [5]
La firma de código es particularmente valiosa en entornos distribuidos, donde el origen de un determinado fragmento de código puede no ser inmediatamente evidente (por ejemplo, subprogramas de Java , controles ActiveX y otros códigos activos de secuencias de comandos web y de navegador). Otro uso importante es proporcionar actualizaciones y parches de forma segura para el software existente. [6] Windows , Mac OS X y la mayoría de las distribuciones de Linux proporcionan actualizaciones mediante la firma de código para garantizar que no sea posible que otros distribuyan código maliciosamente a través del sistema de parches. Permite que el sistema operativo receptor verifique que la actualización es legítima, incluso si la actualización fue entregada por terceros o por medios físicos (discos). [7]
La firma de código se utiliza en Windows y Mac OS X para autenticar el software en la primera ejecución, lo que garantiza que el software no haya sido manipulado maliciosamente por un distribuidor externo o un sitio de descarga. Esta forma de firma de código no se utiliza en Linux debido a la naturaleza descentralizada de esa plataforma, siendo el administrador de paquetes el modo de distribución predominante para todas las formas de software (no solo actualizaciones y parches), así como el modelo de código abierto que permite la inspección directa. del código fuente si lo desea. Las distribuciones de Linux basadas en Debian (entre otras) validan los paquetes descargados utilizando criptografía de clave pública. [8]
La clave pública utilizada para autenticar la firma del código debe poder rastrearse hasta una CA de autoridad raíz confiable, preferiblemente utilizando una infraestructura de clave pública (PKI) segura. Esto no garantiza que se pueda confiar en el código en sí, solo que proviene de la fuente indicada (o más explícitamente, de una clave privada particular ). [9] Una CA proporciona un nivel de confianza raíz y puede asignar confianza a otros mediante proxy. Si un usuario confía en una CA, entonces presumiblemente puede confiar en la legitimidad del código firmado con una clave generada por esa CA o uno de sus representantes. Muchos sistemas operativos y marcos contienen confianza incorporada para una o más autoridades de certificación. También es común que las grandes organizaciones implementen una CA privada, interna a la organización, que proporciona las mismas características que las CA públicas, pero solo es de confianza dentro de la organización.
Los certificados de firma de código de validación extendida (EV) están sujetos a requisitos técnicos y de validación adicionales. Estas pautas se basan en los requisitos básicos y las pautas de validación extendida del Foro CA/B. Además de los requisitos de validación específicos de EV, las pautas de firma de código EV estipulan que "la clave privada del suscriptor se genera, almacena y utiliza en un módulo criptográfico que cumple o supera los requisitos de FIPS 140-2 nivel 2". [10]
Ciertas aplicaciones, como la firma de controladores en modo kernel de Windows 10, requieren un certificado de firma de código EV. [11] Además, IEBlog de Microsoft afirma que los programas de Windows "firmados mediante un certificado de firma de código EV pueden establecer inmediatamente una reputación con los servicios de reputación de SmartScreen incluso si no existe una reputación previa para ese archivo o editor". [12]
Este es un ejemplo de un certificado de firma de código EV decodificado utilizado por SSL.com para firmar software. SSL.com EV Code Signing Intermediate CA RSA R3se muestra como el nombre común del Emisor, identificándolo como un certificado de firma de código EV. El campo del certificado Subjectdescribe a SSL Corp como una organización. Code Signingse muestra como el único uso de clave extendida X509v3.
Certificado: Datos: Versión: 3 (0x2) Número de serie: 59:4e:2d:88:5a:2c:b0:1a:5e:d6:4c:7b:df:35:59:7d Algoritmo de firma: sha256WithRSAEncryption Editor: commonName = SSL.com Firma de código EV CA RSA R3 intermedia nombre de la organización = SSL Corp nombrelocalidad = Houston estadoOProvinciaNombre = Texas nombre del país = EE. UU. Validez No antes: 30 de agosto a las 20:29:13 2019 GMT No después: 12 de noviembre a las 20:29:13 2022 GMT Sujeto: 1.3.6.1.4.1.311.60.2.1.3 = Estados Unidos 1.3.6.1.4.1.311.60.2.1.2 = Nevada dirección de la calle = 3100 Richmond Ave Ste 503 businessCategory = Organización privada código postal = 77098 nombrecomún = SSL Corp número de serie = NV20081614243 nombre de la organización = SSL Corp nombrelocalidad = Houston estadoOProvinciaNombre = Texas nombre del país = EE. UU. Información de clave pública del sujeto: Algoritmo de clave pública: rsaEncryption Clave pública: (2048 bits) Módulo: 00:c3:e9:ae:be:d7:a2:6f:2f:24 ... Exponente: 65537 (0x10001) Extensiones X509v3: Identificador de clave de autoridad X509v3: ID de clave:36:BD:49:FF:31:2C:EB:AF:6A:40:FE:99:C0:16:ED:BA:FC:48:DD:5F Acceso a la información de la autoridad: Emisores de CA - URI: http://www.ssl.com/repository/SSLcom-SubCA-EV-CodeSigning-RSA-4096-R3.crt OCSP-URI: http://ocsps.ssl.com Políticas de certificado X509v3: Política: 2.23.140.1.3 Política: 1.2.616.1.113527.2.5.1.7 Política: 1.3.6.1.4.1.38064.1.3.3.2 CPS: https://www.ssl.com/repository Uso de clave extendida X509v3: Firma de código Puntos de distribución de CRL X509v3: Nombre completo: URI: http://crls.ssl.com/SSLcom-SubCA-EV-CodeSigning-RSA-4096-R3.crl Identificador de clave de asunto X509v3: CE:6A:64:06:26:A7:7A:69:E8:CC:06:D5:6F:FA:E1:C2:9A:29:79:DE Uso de clave X509v3: crítico Firma digital Algoritmo de firma: sha256WithRSAEncryption 17:d7:a1:26:58:31:14:2b:9f:3b ...
El otro modelo es el modelo de confianza en el primer uso , en el que los desarrolladores pueden optar por proporcionar su propia clave autogenerada. En este escenario, el usuario normalmente tendría que obtener la clave pública de alguna manera directamente del desarrollador para verificar que el objeto proviene de él por primera vez. Muchos sistemas de firma de código almacenarán la clave pública dentro de la firma. Algunos marcos de software y sistemas operativos que verifican la firma del código antes de ejecutarlo le permitirán elegir confiar en ese desarrollador a partir de ese momento después de la primera ejecución. Un desarrollador de aplicaciones puede proporcionar un sistema similar incluyendo las claves públicas con el instalador. Luego, la clave se puede utilizar para garantizar que se verifique que todos los objetos posteriores que deban ejecutarse, como actualizaciones, complementos u otra aplicación, provienen del mismo desarrollador.
El sellado de tiempo fue diseñado para eludir la advertencia de confianza que aparecerá en el caso de un certificado vencido. De hecho, el sellado de tiempo extiende la confianza del código más allá del período de validez de un certificado. [13]
En el caso de que un certificado deba ser revocado debido a un compromiso, una fecha y hora específicas del evento comprometedor pasarán a formar parte del registro de revocación. En este caso, el sellado de tiempo ayuda a establecer si el código se firmó antes o después de que el certificado se viera comprometido. [13]
Los desarrolladores deben firmar sus aplicaciones de iOS y tvOS antes de ejecutarlas en cualquier dispositivo real y antes de cargarlas en la App Store . Esto es necesario para demostrar que el desarrollador posee una ID de desarrollador de Apple válida. Una aplicación necesita un perfil o certificado válido para poder ejecutarse en los dispositivos. [14]
Como cualquier medida de seguridad, la firma de código puede anularse. Se puede engañar a los usuarios para que ejecuten código sin firmar, o incluso para que ejecuten código que se niega a validarse, y el sistema sólo permanece seguro mientras la clave privada siga siendo privada. [15] [16]
También es importante tener en cuenta que la firma de código no protege al usuario final de ninguna actividad maliciosa o errores de software no intencionados por parte del autor del software; simplemente garantiza que el software no haya sido modificado por nadie que no sea el autor. En ocasiones, los sistemas sandbox no aceptan certificados, debido a una marca de tiempo falsa o por un uso excesivo de RAM .
Microsoft implementa una forma de firma de código (basada en Authenticode) proporcionada para los controladores probados por Microsoft. Dado que los controladores se ejecutan en el kernel, pueden desestabilizar el sistema o abrirlo a agujeros de seguridad. Por este motivo, Microsoft prueba los controladores sometidos a su programa WHQL . Una vez que el controlador ha pasado, Microsoft firma esa versión del controlador como segura. Solo en sistemas de 32 bits, es posible instalar controladores que no estén validados con Microsoft después de aceptar permitir la instalación cuando se le indique al usuario que el código no está firmado. Para el código .NET (administrado), existe un mecanismo adicional llamado Firma de nombre seguro que utiliza claves públicas/privadas y hash SHA -1 en lugar de certificados. Sin embargo, Microsoft desaconseja confiar en la firma de nombre segura como reemplazo de Authenticode. [17]
El Grupo de Trabajo de Firma de Código del CA/Browser Forum decidió que a partir del 1 de junio de 2023, todos los certificados de firma de código (no solo los de EA) deberían exigir el almacenamiento de claves privadas en un medio físico, como en un módulo criptográfico de hardware que cumpla con al menos al menos FIPS 140-2 Nivel 2 o Criterios Comunes EAL 4+. [18] Posteriormente, las autoridades competentes emitieron anuncios sobre el cumplimiento de la decisión. [19] [20] [21] [22] [23] [24] [25]
En el contexto de dispositivos de consumo como consolas de juegos , el término "código sin firmar" se utiliza a menudo para referirse a una aplicación que no ha sido firmada con la clave criptográfica normalmente necesaria para que el software sea aceptado y ejecutado. La mayoría de los juegos de consola deben firmarse con una clave secreta diseñada por el fabricante de la consola o el juego no se cargará en la consola (tanto para imponer el bloqueo del proveedor como para combatir la piratería de software). Hay varios métodos para ejecutar código sin firmar, que incluyen exploits de software , el uso de un modchip , una técnica conocida como truco de intercambio o ejecutar un softmod .
Puede que inicialmente no parezca obvio por qué simplemente copiar una aplicación firmada en otro DVD no permite que se inicie. En Xbox , la razón de esto es que el archivo ejecutable de Xbox (XBE) contiene un indicador de tipo de medio, que especifica el tipo de medio desde el que se puede iniciar XBE. En casi todo el software de Xbox, esto está configurado de manera que el ejecutable solo se iniciará desde discos producidos en fábrica, por lo que simplemente copiar el ejecutable en un medio grabable es suficiente para detener la ejecución del software.
Sin embargo, dado que el ejecutable está firmado, no es posible simplemente cambiar el valor de la bandera, ya que esto altera la firma del ejecutable, lo que hace que falle la validación cuando se verifica.
(Sección 1.2.2) [...] A partir del 1 de junio de 2023, para los certificados de firma de código, las CA DEBEN garantizar que la clave privada del suscriptor se genere, almacene y utilice en un módulo criptográfico de hardware adecuado que cumpla o supere los requisitos especificados. en la sección 6.2.7.4.1 utilizando uno de los métodos de 6.2.7.4.2.