Resumo Técnico: Proveniência de Registro Criptográfico

1. Declaração do Problema

O artigo identifica uma lacuna estrutural crítica nos ecossistemas modernos de distribuição de software: Confusão de Dependências. Embora as defesas existentes (por exemplo, mapeamentos .npmrc, variáveis GOPROXY) operem na camada de configuração, elas falham silenciosamente quando mal configuradas, substituídas por variáveis de CI/CD ou ausentes. Uma vez que um pacote é instalado, não há prova criptográfica de qual registro o distribuiu.

A vulnerabilidade central é que os resolvedores de pacotes consultam múltiplos registros (públicos e privados) e selecionam artefatos com base nos números de versão. Um atacante pode publicar um pacote malicioso com um número de versão mais alto em um registro público, sob um namespace que a organização vítima utiliza privadamente. Como o próprio artefato não carrega evidência de seu caminho de distribuição, o resolvedor pode silenciosamente selecionar o artefato do atacante em vez do privado legítimo. Os ecossistemas atuais carecem de um mecanismo para verificar criptograficamente o caminho de distribuição ou impor autoridade de namespace no nível do artefato.

2. Metodologia e Arquitetura

Os autores propõem um Sistema de Proveniência de Distribuição Criptográfica que desloca a defesa da configuração para o próprio artefato. O sistema baseia-se em três componentes principais:

A. Formato de Arquivo de Duas Camadas

Para permitir verificação eficiente, o sistema introduz uma estrutura de arquivo específica:

• Envelope Externo (Tar não comprimido): Contém o manifesto de proveniência, assinatura do publicador, atestação do registro e checksums. Isso permite a verificação sem descomprimir o código-fonte.
• Conteúdo Interno (Tar Gzip): Contém os arquivos de código-fonte reais, o manifesto do projeto e definições de tipo.
• Benefício: O custo de verificação é proporcional ao pequeno envelope (~2–5 KB) em vez do potencialmente grande arquivo de código-fonte.

B. Identidade Criptográfica do Registro

Cada instância de registro (público, privado ou escopado) recebe um par de chaves Ed25519 único.

• Os registros publicam sua identidade (URL, chave pública, impressão digital e namespaces reivindicados) em um ponto de extremidade conhecido (/.well-known/package-registry.json).
• A Impressão Digital da Chave ($F_R = \text{SHA-256}(\text{chave pública})$) serve como um identificador curto e verificável.
• Os registros declaram os namespaces para os quais são autoritários, permitindo confiança hierárquica (por exemplo, Público $\to$ Organização $\to$ Equipe).

C. Modelo de Distribuição de Dupla Assinatura

Os artefatos carregam duas assinaturas independentes com reivindicações temporais e lógicas distintas:

1. Assinatura do Publicador ($\sigma_P$): Criada no momento do empacotamento ($t_1$). O publicador assina o manifesto de proveniência, afirmando autoria e integridade do conteúdo.
2. Atestação do Registro ($\sigma_R$): Criada no momento da publicação ($t_2 > t_1$). O registro verifica a assinatura do publicador, checa o hash do conteúdo e assina um documento de atestação. Isso afirma que o registro recebeu, verificou e está distribuindo o artefato.

• Semântica de Contra-assinatura: Esta abordagem preserva a ordem temporal e reivindicações independentes, ao contrário da co-assinatura que confunde eventos.

D. Vinculação Autoritária de Namespace

Os consumidores declaram quais registros são autoritários para namespaces específicos em seu manifesto de projeto (por exemplo, mashin.toml).

• Fixação (Pinning): Os consumidores fixam a impressão digital da chave do registro (Confiança no Primeiro Uso - TOFU).
• Aplicação: O resolvedor rejeita criptograficamente artefatos de registros não autorizados. Se um namespace estiver vinculado a um registro específico, o resolvedor consulta apenas esse registro e rejeita artefatos de outros, mesmo que tenham números de versão mais altos.

3. Contribuições Principais

O artigo apresenta sete contribuições específicas:

1. Identidade Criptográfica do Registro: Estabelecer que cada registro possui um par de chaves Ed25519 e assina cada artefato, criando prova de nível de artefato do caminho de distribuição.
2. Modelo de Dupla Assinatura: Um modelo de distribuição onde o publicador assina no empacotamento e o registro contra-assina na publicação, preservando a ordem temporal.
3. Vinculação Autoritária de Namespace: Um mecanismo para consumidores fixarem impressões digitais de registros e rejeitarem criptograficamente artefatos de registros não autorizados.
4. Formato de Arquivo de Duas Camadas: Uma estrutura que separa o envelope de proveniência do conteúdo de origem para permitir verificação rápida e parcial.
5. Cadeia de Verificação de Seis Níveis: Um processo de verificação progressiva que varia da integridade de arquivo (Nível 1) à proveniência de linhagem (Nível 6), sendo os Níveis 1–5 a contribuição central.
6. Comparação Sistemática de Ecossistemas: Uma análise de oito ecossistemas principais (npm, Cargo, Hex.pm, PyPI, Go, Docker/OCI, NuGet, Maven) demonstrando que nenhum ecossistema existente combina assinatura obrigatória do publicador, identidade criptográfica do registro, contra-assinatura obrigatória do registro e aplicação criptográfica no lado do consumidor.
7. Integração com Governança em Tempo de Execução: Um estudo de caso mostrando como a proveniência de distribuição se integra a uma arquitetura de governança estrutural de três camadas para formar uma cadeia de ciclo de vida de quatro fases (Definição, Distribuição, Capacidade, Execução).

4. Resultados e Avaliação

Análise de Segurança

Sob o modelo de ameaça definido (o adversário pode comprometer configurações de CI/CD ou publicar em registros públicos, mas não pode comprometer chaves privadas de registro), o sistema fornece uma defesa de três camadas:

• Camada 1 (Registro): A aplicação de namespace impede a publicação não autorizada.
• Camada 2 (Consumidor): A vinculação autoritária impede a resolução a partir de registros não autorizados.
• Camada 3 (Artefato): A atestação do registro (verificação de assinatura) impede a instalação de artefatos de registros não autorizados, mesmo que as Camadas 1 e 2 sejam contornadas.

O artigo prova que um ataque bem-sucedido de confusão de dependências requer o comprometimento simultâneo da configuração do resolvedor do consumidor e da chave de assinatura privada do registro alvo. Sob o modelo de ameaça estrito (onde o comprometimento de chave é excluído), a probabilidade de um ataque bem-sucedido é zero.

Avaliação de Desempenho

Medido em um processador Apple série M:

• Latência de Verificação: A verificação ponta a ponta para um projeto de 4 máquinas completa em 1,18 ms (mediana) para o modo padrão (Níveis 1–3) e 1,61 ms para o modo estrito (Níveis 1–5).
• Sobrecarga: As operações criptográficas (assinatura/verificação Ed25519, SHA-256) são negligenciáveis (microssegundos). O custo dominante é a extração tar do envelope externo (~259 µs).
• Comparação: Isso é comparável ou mais rápido que a verificação de ecossistemas existentes (por exemplo, assinaturas de auditoria npm frequentemente levam 100–500 ms devido a idas e vindas de rede para logs de transparência) porque o sistema proposto evita chamadas de rede para os Níveis 1–5.
• Sobrecarga de Armazenamento: O envelope de proveniência adiciona um tamanho fixo de vários kilobytes. Para projetos pequenos, isso representa uma sobrecarga percentual alta (por exemplo, 2.659% para uma origem de 203 bytes), mas cai para ~300% para projetos maiores (12 máquinas), tornando-se negligenciável em relação ao tamanho da origem.

5. Significado e Reivindicações

O artigo afirma que a confusão de dependências é um problema de proveniência, não um problema de configuração.

• Defesa Estrutural: Ao contrário de defesas baseadas em configuração que falham silenciosamente, este sistema fornece prova criptográfica embutida no artefato. A verificação é possível independentemente do estado de configuração do resolvedor.
• Unicidade: O sistema é o primeiro a combinar assinatura obrigatória do publicador, identidade criptográfica do registro, contra-assinatura obrigatória do registro e aplicação criptográfica no lado do consumidor.
• Extensibilidade: A arquitetura estende-se para proveniência de geração por IA (rastreamento do uso de modelos e níveis de composição como atributos assinados) e resolução de dependências imposta por governança (imposição de níveis de confiança e permissões de efeito durante a instalação, em vez de post-hoc).
• Completude: Quando integrada com proveniência de construção e governança em tempo de execução, o sistema cria uma cadeia contínua e evidenciada de adulteração desde a criação do código-fonte até a execução, fechando lacunas criptográficas na cadeia de suprimentos de software.

Os autores observam que o sistema não aborda typosquatting (um ataque na camada de nomenclatura) ou ameaças internas envolvendo acesso ao servidor de registro (comprometimento de chave), que requerem defesas ortogonais como HSMs e análise comportamental.