Resumen Técnico: Proveniencia de Registro Criptográfico

1. Declaración del Problema

El artículo identifica una brecha estructural crítica en los ecosistemas modernos de distribución de software: la Confusión de Dependencias. Aunque las defensas existentes (por ejemplo, mapeos en .npmrc, variables GOPROXY) operan en la capa de configuración, fallan silenciosamente cuando están mal configuradas, son anuladas por variables de CI/CD o están ausentes. Una vez que un paquete se instala, no existe ninguna prueba criptográfica de qué registro lo distribuyó.

La vulnerabilidad central es que los resolvedores de paquetes consultan múltiples registros (públicos y privados) y seleccionan artefactos basándose en números de versión. Un atacante puede publicar un paquete malicioso con un número de versión más alto en un registro público bajo un namespace que la organización víctima utiliza de forma privada. Dado que el propio artefacto no lleva evidencia de su ruta de distribución, el resolvedor puede seleccionar silenciosamente el artefacto del atacante en lugar del privado legítimo. Los ecosistemas actuales carecen de un mecanismo para verificar criptográficamente la ruta de distribución o hacer cumplir la autoridad del namespace a nivel de artefacto.

2. Metodología y Arquitectura

Los autores proponen un Sistema de Proveniencia de Distribución Criptográfica que desplaza la defensa de la configuración al propio artefacto. El sistema se basa en tres componentes centrales:

A. Formato de Archivo de Dos Capas

Para habilitar una verificación eficiente, el sistema introduce una estructura de archivo específica:

• Sobre Externo (Tar sin comprimir): Contiene el manifiesto de proveniencia, la firma del publicador, la atestación del registro y sumas de verificación. Esto permite la verificación sin descomprimir el código fuente.
• Contenido Interno (Tar comprimido con Gzip): Contiene los archivos de código fuente reales, el manifiesto del proyecto y las definiciones de tipo.
• Beneficio: El costo de verificación es proporcional al pequeño sobre (~2–5 KB) en lugar del potencialmente gran archivo de origen.

B. Identidad Criptográfica del Registro

Cada instancia de registro (público, privado o con ámbito) se asigna un único par de claves Ed25519.

• Los registros publican su identidad (URL, clave pública, huella digital y namespaces reclamados) en un punto final conocido (/.well-known/package-registry.json).
• La Huella Digital de la Clave ($F_R = \text{SHA-256}(\text{clave pública})$) sirve como un identificador corto y verificable.
• Los registros declaran los namespaces para los cuales son autoritativos, habilitando una confianza jerárquica (por ejemplo, Público $\to$ Organización $\to$ Equipo).

C. Modelo de Distribución de Doble Firma

Los artefactos llevan dos firmas independientes con reclamaciones temporales y lógicas distintas:

1. Firma del Publicador ($\sigma_P$): Creada en el momento del empaquetado ($t_1$). El publicador firma el manifiesto de proveniencia, afirmando la autoría y la integridad del contenido.
2. Atestación del Registro ($\sigma_R$): Creada en el momento de la publicación ($t_2 > t_1$). El registro verifica la firma del publicador, comprueba la suma de verificación del contenido y firma un documento de atestación. Esto afirma que el registro recibió, verificó y está distribuyendo el artefacto.

• Semántica de Contrafirma: Este enfoque preserva el orden temporal y las reclamaciones independientes, a diferencia de la co-firma que confunde eventos.

D. Vinculación Autoritativa de Namespace

Los consumidores declaran qué registros son autoritativos para namespaces específicos en su manifiesto de proyecto (por ejemplo, mashin.toml).

• Fijación (Pinning): Los consumidores fijan la huella digital de la clave del registro (Confianza en el Primer Uso - TOFU).
• Aplicación: El resolvedor rechaza criptográficamente los artefactos de registros no autorizados. Si un namespace está vinculado a un registro específico, el resolvedor consulta solo a ese registro y rechaza los artefactos de otros, incluso si tienen números de versión más altos.

3. Contribuciones Clave

El artículo presenta siete contribuciones específicas:

1. Identidad Criptográfica del Registro: Establecer que cada registro posee un par de claves Ed25519 y firma cada artefacto, creando prueba a nivel de artefacto de la ruta de distribución.
2. Modelo de Doble Firma: Un modelo de distribución donde el publicador firma al empaquetar y el registro contrafirma al publicar, preservando el orden temporal.
3. Vinculación Autoritativa de Namespace: Un mecanismo para que los consumidores fijen huellas digitales de registros y rechacen criptográficamente los artefactos de registros no autorizados.
4. Formato de Archivo de Dos Capas: Una estructura que separa el sobre de proveniencia del contenido de origen para habilitar una verificación rápida y parcial.
5. Cadena de Verificación de Seis Niveles: Un proceso de verificación progresivo que va desde la integridad del archivo (Nivel 1) hasta la proveniencia de linaje (Nivel 6), siendo los Niveles 1–5 la contribución central.
6. Comparación Sistemática de Ecosistemas: Un análisis de ocho ecosistemas principales (npm, Cargo, Hex.pm, PyPI, Go, Docker/OCI, NuGet, Maven) que demuestra que ningún ecosistema existente combina la firma obligatoria del publicador, la identidad criptográfica del registro, la contrafirma obligatoria del registro y la aplicación criptográfica del lado del consumidor.
7. Integración de Gobernanza en Tiempo de Ejecución: Un estudio de caso que muestra cómo la proveniencia de distribución se integra con una arquitectura de gobernanza estructural de tres capas para formar una cadena de ciclo de vida de cuatro fases (Definición, Distribución, Capacidad, Ejecución).

4. Resultados y Evaluación

Análisis de Seguridad

Bajo el modelo de amenazas definido (el adversario puede comprometer configuraciones de CI/CD o publicar en registros públicos, pero no puede comprometer las claves privadas del registro), el sistema proporciona una defensa de tres capas:

• Capa 1 (Registro): La aplicación del namespace previene la publicación no autorizada.
• Capa 2 (Consumidor): La vinculación autoritativa previene la resolución desde registros no autorizados.
• Capa 3 (Artefacto): La atestación del registro (verificación de firma) previene la instalación de artefactos de registros no autorizados incluso si se eluden las Capas 1 y 2.

El artículo demuestra que un ataque exitoso de confusión de dependencias requiere el compromiso simultáneo de la configuración del resolvedor del consumidor y la clave privada de firma del registro objetivo. Bajo el modelo de amenazas estricto (donde se excluye el compromiso de claves), la probabilidad de un ataque exitoso es cero.

Evaluación de Rendimiento

Medido en un procesador Apple de la serie M:

• Latencia de Verificación: La verificación de extremo a extremo para un proyecto de 4 máquinas se completa en 1.18 ms (mediana) para el modo predeterminado (Niveles 1–3) y 1.61 ms para el modo estricto (Niveles 1–5).
• Sobrecarga: Las operaciones criptográficas (firma/verificación Ed25519, SHA-256) son insignificantes (microsegundos). El costo dominante es la extracción tar del sobre externo (~259 µs).
• Comparación: Esto es comparable o más rápido que la verificación existente en ecosistemas (por ejemplo, las firmas de npm audit a menudo tardan 100–500 ms debido a las vueltas de red a registros de transparencia) porque el sistema propuesto evita llamadas de red para los Niveles 1–5.
• Sobrecarga de Almacenamiento: El sobre de proveniencia añade un tamaño fijo de varios kilobytes. Para proyectos pequeños, esto representa un porcentaje alto de sobrecarga (por ejemplo, 2,659% para un origen de 203 bytes), pero cae a ~300% para proyectos más grandes (12 máquinas), volviéndose insignificante en relación con el tamaño del origen.

5. Significado y Reclamaciones

El artículo afirma que la confusión de dependencias es un problema de proveniencia, no un problema de configuración.

• Defensa Estructural: A diferencia de las defensas basadas en configuración que fallan silenciosamente, este sistema proporciona una prueba criptográfica incrustada en el artefacto. La verificación es posible independientemente del estado de configuración del resolvedor.
• Unicidad: El sistema es el primero en combinar la firma obligatoria del publicador, la identidad criptográfica del registro, la contrafirma obligatoria del registro y la aplicación criptográfica del lado del consumidor.
• Extensibilidad: La arquitectura se extiende a la proveniencia de generación de IA (rastrear el uso de modelos y niveles de composición como atributos firmados) y a la resolución de dependencias aplicada por gobernanza (hacer cumplir niveles de confianza y permisos de efecto durante la instalación en lugar de post-hoc).
• Completitud: Cuando se integra con la proveniencia de compilación y la gobernanza en tiempo de ejecución, el sistema crea una cadena continua y evidente de manipulación desde la creación del código fuente hasta la ejecución, cerrando brechas criptográficas en la cadena de suministro de software.

Los autores señalan que el sistema no aborda el typosquatting (un ataque en la capa de nombres) ni las amenazas internas que implican acceso al servidor del registro (compromiso de claves), las cuales requieren defensas ortogonales como HSMs y análisis de comportamiento.