Firma de código

Autenticación de software

La firma de código es el proceso de firmar digitalmente archivos ejecutables y scripts para confirmar el autor del software y garantizar que el código no haya sido alterado o dañado desde que fue firmado. El proceso emplea el uso de un hash criptográfico para validar la autenticidad e integridad. [1] La firma de código fue inventada en 1995 por Michael Doyle, como parte del complemento del navegador Eolas WebWish, que permitió el uso de criptografía de clave pública para firmar el código del programa de la aplicación web descargable utilizando una clave secreta, de modo que el intérprete de código del complemento pudiera usar la clave pública correspondiente para autenticar el código antes de permitirle el acceso 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 el sistema de compilación, y una suma de comprobación para verificar que el objeto no haya sido modificado. También se puede utilizar para proporcionar información de versiones sobre 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 aseguren sus claves privadas contra el acceso no autorizado. Las claves almacenadas en software en computadoras de uso general son susceptibles de ser comprometidas. Por lo tanto, es más seguro y la mejor práctica es 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]

Proporcionar seguridad

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 una 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 compila. Esta clave será única para 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 de certificación (CA) de confianza. [5]

La firma de código es particularmente valiosa en entornos distribuidos, donde la fuente de un fragmento de código determinado puede no ser evidente de inmediato; por ejemplo, applets de Java , controles ActiveX y otros códigos de scripts activos para navegadores y web. Otro uso importante es proporcionar actualizaciones y parches de forma segura al 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 de forma maliciosa 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 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, ya que el administrador de paquetes es el modo predominante de distribución 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 se desea. Las distribuciones de Linux basadas en Debian (entre otras) validan los paquetes descargados utilizando criptografía de clave pública. [8]

Identificación confiable mediante una autoridad de certificación (CA)

La clave pública utilizada para autenticar la firma del código debe poder rastrearse hasta una autoridad raíz de confianza (CA), 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 por proxy. Si un usuario confía en una CA, entonces el usuario presumiblemente puede confiar en la legitimidad del código que está firmado con una clave generada por esa CA o uno de sus proxies. 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 confiable dentro de la organización.

Firma de código con validación extendida (EV)

Los certificados de firma de código con 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 CA/B Forum. Además de los requisitos de validación específicos para 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]

Algunas aplicaciones, como la firma de controladores en modo kernel de Windows 10, requieren un certificado de firma de código EV. [11] Además, el IEBlog de Microsoft afirma que los programas de Windows "firmados por un certificado de firma de código EV pueden establecer inmediatamente una reputación con los servicios de reputación SmartScreen incluso si no existe una reputación previa para ese archivo o editor". [12]

Ejemplo de certificado de firma de código EV

Este es un ejemplo de un certificado de firma de código EV decodificado que SSL.com utiliza para firmar software. SSL.com EV Code Signing Intermediate CA RSA R3se muestra como el nombre común del emisor, lo que lo identifica como un certificado de firma de código EV. El Subjectcampo del certificado describe 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 Intermedio CA RSA R3 nombreOrganización = SSL Corp nombreDeLaLocalidad=Houston nombreDeEstadoOProvincia = Texas nombre_pais = US Validez No antes: 30 de agosto de 2019, 20:29:13 GMT No después del 12 de noviembre de 2022, 20:29:13 GMT Sujeto: 1.3.6.1.4.1.311.60.2.1.3 = EE. UU. 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 nombreOrganización = SSL Corp nombreDeLaLocalidad=Houston nombreDeEstadoOProvincia = Texas nombre_pais = US Información de clave pública del sujeto: Algoritmo de clave pública: rsaEncryption Clave pública: (2048 bit) 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 certificación 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 Página de inicio: https://www.ssl.com/repository  Uso extendido de la clave X509v3: Firma de código Puntos de distribución de CRL X509v3:  Nombre completo: Dirección URL: http://crls.ssl.com/SSLcom-SubCA-EV-CodeSigning-RSA-4096-R3.crl  Identificador de clave de sujeto X509v3: CE:6A:64:06:26:A7:7A:69:E8:CC:06:D5:6F:FA:E1:C2:9A:29:79:DE Uso de la clave X509v3: crítico Firma digital Algoritmo de firma: sha256WithRSAEncryption 17:d7:a1:26:58:31:14:2b:9f:3b ...

Alternativa a las CA

El otro modelo es el 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 al incluir las claves públicas con el instalador. La clave se puede utilizar luego para garantizar que todos los objetos posteriores que se necesiten ejecutar, como actualizaciones, complementos u otra aplicación, se verifiquen como provenientes del mismo desarrollador.

Sellado de tiempo

El sellado de tiempo fue diseñado para evitar la advertencia de confianza que aparecerá en el caso de un certificado vencido. En efecto, el sellado de tiempo extiende la confianza del código más allá del período de validez de un certificado. [13]

En caso de que un certificado deba ser revocado debido a una vulneración, la 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 determinar si el código se firmó antes o después de que el certificado se viera comprometido. [13]

Firma de código enCódigo X

Los desarrolladores deben firmar sus aplicaciones iOS y tvOS antes de ejecutarlas en cualquier dispositivo real y antes de subirlas a la App Store . Esto es necesario para demostrar que el desarrollador posee un ID de desarrollador de Apple válido. Una aplicación necesita un perfil o certificado válido para poder ejecutarse en los dispositivos. [14]

Problemas

Como cualquier medida de seguridad, la firma de código puede ser burlada. Se puede engañar a los usuarios para que ejecuten código no firmado, o incluso para que ejecuten código que se niega a validarse, y el sistema solo 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 intencionales por parte del autor del software; simplemente garantiza que el software no haya sido modificado por nadie más que el autor. A veces, los sistemas sandbox no aceptan certificados debido a una marca de tiempo falsa o debido a un uso excesivo de RAM .

Implementaciones

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 núcleo, pueden desestabilizar el sistema o abrirlo a agujeros de seguridad. Por esta razón, Microsoft prueba los controladores enviados a su programa WHQL . Una vez que el controlador ha pasado la prueba, 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 en un mensaje que advierte al usuario que el código no está firmado. Para el código .NET (administrado), existe un mecanismo adicional llamado Firma de nombre fuerte que utiliza claves públicas/privadas y hash SHA -1 en lugar de certificados. Sin embargo, Microsoft desaconseja la confianza en la Firma de nombre fuerte como reemplazo de Authenticode. [17]

El Grupo de Trabajo de Firma de Código del Foro CA/Navegador 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 la clave privada en un medio físico, como en un módulo criptográfico de hardware que cumpla al menos con FIPS 140-2 Nivel 2 o Common Criteria EAL 4+. [18] Posteriormente, las CA emitieron anuncios sobre el cumplimiento de la decisión. [19] [20] [21] [22] [23] [24] [25]

Código no firmado en juegos y dispositivos de consumo

En el contexto de los dispositivos de consumo, como las consolas de juegos , el término "código no firmado" se utiliza a menudo para referirse a una aplicación que no ha sido firmada con la clave criptográfica que normalmente se requiere para que el software sea aceptado y ejecutado. La mayoría de los juegos de consola tienen que estar firmados con una clave secreta diseñada por el fabricante de la consola o el juego no se cargará en la consola (tanto para imponer la dependencia del proveedor como para combatir la piratería de software). Hay varios métodos para lograr que se ejecute el código no firmado, que incluyen exploits de software , el uso de un modchip , una técnica conocida como el truco del intercambio o la ejecución de un softmod .

Puede que al principio no parezca obvio por qué el simple hecho de copiar una aplicación firmada en otro DVD no permite que arranque. En la Xbox , la razón 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 arrancar el XBE. En casi todo el software de Xbox, esto está configurado de tal manera que el ejecutable solo arrancará desde discos producidos de 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 del indicador ya que esto altera la firma del ejecutable y provoca que falle la validación cuando se verifica.

Véase también

Referencias

  1. ^ "Introducción a la firma de código (Windows)". learn.microsoft.com . 15 de agosto de 2017. Archivado desde el original el 6 de febrero de 2024 . Consultado el 13 de marzo de 2024 .
  2. ^ "WebWish: Nuestros deseos son tus órdenes".
  3. ^ Hendric, William (2015). "Una descripción completa de los certificados de confianza - CABForum" (PDF) . Archivado (PDF) desde el original el 22 de abril de 2019. Consultado el 26 de febrero de 2015 .
  4. ^ "Cómo proteger sus claves privadas como práctica recomendada para los certificados de firma de código" (PDF) .
  5. ^ Hendric, William (17 de junio de 2011). «¿Qué es la firma de código?». Archivado desde el original el 20 de junio de 2018. Consultado el 26 de febrero de 2015 .
  6. ^ "Firmas digitales y Windows Installer: aplicaciones Win32". learn.microsoft.com . 7 de enero de 2021. Archivado desde el original el 30 de enero de 2024 . Consultado el 13 de marzo de 2024 .
  7. ^ windows-driver-content (18 de mayo de 2022). "Guía de creación y administración de claves de arranque seguro de Windows". learn.microsoft.com . Archivado desde el original el 30 de octubre de 2023 . Consultado el 22 de septiembre de 2023 .
  8. ^ "SecureApt - Wiki de Debian". wiki.debian.org . Archivado desde el original el 7 de mayo de 2019 . Consultado el 7 de mayo de 2019 .
  9. ^ "Firma de código" (PDF) . 2014-02-26. Archivado (PDF) desde el original el 2014-02-26 . Consultado el 2014-02-21 .
  10. ^ "Directrices para la emisión y gestión de certificados de firma de código de validación extendida" (PDF) . Foro CA/Browser. Archivado (PDF) del original el 27 de noviembre de 2019 . Consultado el 4 de diciembre de 2019 .
  11. ^ "Política de firma de controladores". Microsoft. Archivado desde el original el 9 de diciembre de 2019. Consultado el 9 de diciembre de 2019 .
  12. ^ "Certificados de firma de código Microsoft SmartScreen y Extended Validation (EV)". Microsoft. 14 de agosto de 2012. Archivado desde el original el 9 de diciembre de 2019. Consultado el 9 de diciembre de 2019 .
  13. ^ ab Morton, Bruce. "Firma de código" (PDF) . CASC. Archivado (PDF) del original el 26 de febrero de 2014. Consultado el 21 de febrero de 2014 .
  14. ^ "Distribuir tu aplicación a dispositivos registrados". Documentación para desarrolladores de Apple . Archivado desde el original el 13 de marzo de 2024. Consultado el 15 de enero de 2024 .
  15. ^ "Cada vez más, las soluciones antivirus falsas han robado certificados de firma de código". 9 de enero de 2014. Archivado desde el original el 16 de abril de 2014 . Consultado el 14 de abril de 2014 .
  16. ^ http://www.eweek.com/c/a/Security/Theres-A-Racket-Brewing-In-the-Code-Signing-Cert-Business/ [ enlace roto ]
  17. ^ "Blog de seguridad de .NET". learn.microsoft.com . 6 de agosto de 2021. Archivado desde el original el 19 de enero de 2024 . Consultado el 13 de marzo de 2024 .
  18. ^ "Requisitos básicos para la emisión y gestión de certificados de firma de código de confianza pública" (PDF) . CA/Browser Forum. 2024. p. 10. Archivado (PDF) del original el 13 de marzo de 2024 . Consultado el 22 de marzo de 2024 . (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.
  19. ^ "Firma de código: almacenamiento de claves privadas | SignPath". SignPath: firma de código sencilla y segura . Archivado desde el original el 8 de marzo de 2024. Consultado el 13 de marzo de 2024 .
  20. ^ "Cambios en la firma de código en 2021". knowledge.digicert.com . Archivado desde el original el 2023-12-10 . Consultado el 2024-03-13 .
  21. ^ "Cronología de DigiCert: nuevo requisito de almacenamiento de claves privadas para la firma de código". knowledge.digicert.com . Archivado desde el original el 2023-12-08 . Consultado el 2024-03-13 .
  22. ^ "Nuevo requisito de almacenamiento de clave privada para certificados de firma de código". knowledge.digicert.com . Archivado desde el original el 2024-02-19 . Consultado el 2024-03-13 .
  23. ^ "[CSCWG-public] Resultados de la votación de la votación CSCWG-17: extensión de clave privada del suscriptor". 26 de septiembre de 2022. Archivado desde el original el 5 de diciembre de 2022. Consultado el 13 de marzo de 2024 .
  24. ^ "Los requisitos de almacenamiento de claves de firma de código cambiarán el 1 de junio de 2023". Archivado desde el original el 2 de octubre de 2023 . Consultado el 13 de marzo de 2024 .
  25. ^ "🥇 Nuevo requisito de almacenamiento de clave privada para todos los certificados de firma de código: junio de 2023 (actualización)". SSLPOINT . 23 de septiembre de 2022. Archivado desde el original el 22 de septiembre de 2023 . Consultado el 13 de marzo de 2024 .
  • Guía de firma de código de Apple
  • Introducción a la firma de código de Microsoft
  • Infraestructura de seguridad de Debian
  • Cómo hacer una distribución fuerte
Retrieved from "https://en.wikipedia.org/w/index.php?title=Code_signing&oldid=1238139055"