[09/03/2021] La Fundación Linux ha lanzado un servicio gratuito que los desarrolladores de software pueden utilizar para firmar digitalmente sus versiones y otros appliance de software. El proyecto pretende reforzar la seguridad y la capacidad de auditoría de la cadena de suministro de software de código abierto, que se ha enfrentado a un número de ataques sin precedentes en los últimos años.
El código del nuevo servicio, denominado sigstore, se ha desarrollado en colaboración con Google, Red Hat y la Universidad de Purdue, y será mantenido por la comunidad en el futuro. Todas las firmas y eventos de firma se almacenarán en un registro público a prueba de manipulaciones que podrá ser supervisado para descubrir posibles abusos.
¿Cómo funciona sigstore?
Sigstore utiliza el protocolo de autenticación OpenID para vincular los certificados a las identidades. Esto significa que un desarrollador puede utilizar su dirección de correo electrónico o su cuenta con un proveedor de identidad OpenID existente para firmar su software.
Esto es diferente de la firma de código tradicional, que requiere la obtención de un certificado de una autoridad de certificación (CA) en la que confían los mantenedores de un ecosistema de software concreto, por ejemplo, Microsoft o Apple. La obtención de un certificado de firma de código tradicional requiere pasar por procedimientos especiales que incluyen la verificación de la identidad o la adhesión a un programa de desarrolladores.
El cliente de firma de sigstore genera un par de claves efímeras de corta duración y se pone en contacto con la PKI (infraestructura de clave pública) de sigstore, que será gestionada por la Fundación Linux. El servicio PKI comprueba si la concesión de OpenID connect es correcta y emite un certificado basado en el par de claves que se utilizará para firmar el software. El evento de firma se registra en el registro público y luego las claves pueden descartarse.
Esta es otra diferencia con respecto a la firma de código existente, ya que cada evento de firma genera un nuevo par de claves y certificado. En última instancia, el objetivo es tener una prueba pública de que una identidad concreta firmó un archivo en un momento determinado. A continuación, la comunidad deberá crear herramientas que utilicen esta información para crear políticas y mecanismos de aplicación.
"Se basa en las autoridades de certificación X.509 normales, así que la gente puede añadir su propia CA raíz, puede deshacerse de la nuestra si no quiere confiar en ella, puede añadir sus propios intermediarios, y ese tipo de cosas", explica Dan Lorenc, miembro del equipo de seguridad de código abierto de Google y colaborador del proyecto.
Los desarrolladores pueden utilizar el servicio público de PKI y el registro de transparencia, o pueden desplegar y ejecutar su propio sistema de firma interno para su organización. El código del servicio de registro, llamado Rekor, y de la autoridad de certificación raíz, llamada Fulcio, son de código abierto y están disponibles en GitHub.
¿Por qué firmar las versiones de software?
La firma de código de software en general se utiliza para ofrecer garantías sobre la procedencia del software, proporcionando pruebas de que un fragmento de código se originó con un desarrollador o una organización concreta en la que el usuario confía. Las soluciones de listas blancas de aplicaciones, por ejemplo, utilizan esta información para aplicar las políticas del usuario sobre qué software y de quién se va a ejecutar en un sistema concreto.
Estas políticas pueden extenderse también a los gestores de paquetes. Cualquier software moderno se construye utilizando componentes de código abierto de terceros, que representan la mayor parte de su base de código. Por ello, se han producido ataques contra repositorios de paquetes de código abierto como npm, PyPi o Ruby Gems. Una técnica de ataque revelada recientemente se denomina confusión de dependencias, y se basa en engañar a los gestores de paquetes para que instalen una variante falsa de un determinado paquete local mediante la publicación de un paquete con el mismo nombre, pero con una versión superior en un repositorio público.
Las políticas de seguridad creadas en torno a las firmas digitales de software pueden ayudar a prevenir este tipo de ataques, así como los ataques en los que el servidor de descarga o actualización utilizado por un desarrollador de software se ve comprometido y sus paquetes legítimos se sustituyen por otros maliciosos, o los ataques de tipo man-in-the-middle contra los mecanismos de actualización de software.
Hay otros ataques, como el compromiso de la máquina de un desarrollador o de la infraestructura de construcción de software y la inyección de código malicioso durante las primeras etapas del desarrollo de software, como en el reciente ataque de SolarWinds que afectó a miles de organizaciones. La firma del código no habría evitado necesariamente ese ataque, ya que la firma de una versión de software es uno de los últimos pasos antes de la distribución y se produciría después de la inyección de código. Sin embargo, un registro de transparencia como el que forma parte de sigstore podría proporcionar información valiosa a los investigadores de un incidente, o incluso puede conducir a la detección temprana de un compromiso.
Según Luke Hinds, jefe de ingeniería de seguridad de Red Hat, el registro puede utilizarse para crear herramientas de monitorización similares a las del servicio de notificación de violaciones de datos HaveIBeenPwned.com, en el que un usuario puede introducir su dirección de correo electrónico y recibir una notificación si aparece en alguna de las violaciones públicas que se han indexado. Los desarrolladores podrían utilizar esta herramienta para recibir una notificación cada vez que su dirección de correo electrónico aparezca en el registro de sigstore. Si ese evento se produce cuando saben que no han estado activos, eso es inmediatamente una señal de alarma de que su cuenta o sistema podría haber sido comprometido y alguien está firmando software en su nombre.
"El objetivo del registro de transparencia no es bloquear los ataques, sino ofrecer una visión de los mismos que actualmente no se tiene", explico Hinds. "Proporciona transparencia en torno a la cadena de suministro de software".
Los investigadores de la Universidad de Purdue están trabajando en un prototipo de monitor que utilizará el registro, pero con el tiempo los responsables del proyecto esperan que la comunidad de código abierto y las empresas privadas del ámbito de la seguridad creen herramientas en torno al servicio sigstore. Por ejemplo, las organizaciones de desarrollo podrían desplegar el sistema y crear controles de seguridad granulares.
"No estamos construyendo un motor de políticas en sí mismo, sino que estamos construyendo las herramientas y primitivas que se pueden utilizar para construir uno de esos motores de políticas", anotó Lorenc. "Puede tener 12 desarrolladores y decir que siete de esos 12 tienen que firmar este artefacto para que sea bueno. Puede imaginar todo tipo de escenarios como ese".
Basado en el artículo de Lucian Constantin (CSO) y editado por CIO Perú