Riepilogo Tecnico: Provenienza del Registro Crittografico

1. Enunciato del Problema

Il documento identifica una lacuna strutturale critica negli ecosistemi moderni di distribuzione del software: la Confusione delle Dipendenze. Sebbene le difese esistenti (ad esempio, mappature .npmrc, variabili GOPROXY) operino a livello di configurazione, falliscono in modo silenzioso quando sono configurate erroneamente, sovrascritte da variabili CI/CD o assenti. Una volta installato un pacchetto, non esiste alcuna prova crittografica di quale registro lo abbia distribuito.

La vulnerabilità fondamentale risiede nel fatto che i risolutori di pacchetti interrogano più registri (pubblici e privati) e selezionano gli artefatti in base ai numeri di versione. Un attaccante può pubblicare un pacchetto malevolo con un numero di versione più alto su un registro pubblico sotto un namespace che l'organizzazione vittima utilizza privatamente. Poiché l'artefatto stesso non trasporta prove del suo percorso di distribuzione, il risolutore potrebbe selezionare silenziosamente l'artefatto dell'attaccante rispetto a quello privato legittimo. Gli ecosistemi attuali mancano di un meccanismo per verificare crittograficamente il percorso di distribuzione o per imporre l'autorità del namespace a livello di artefatto.

2. Metodologia e Architettura

Gli autori propongono un Sistema di Provenienza della Distribuzione Crittografica che sposta la difesa dalla configurazione all'artefatto stesso. Il sistema si basa su tre componenti fondamentali:

A. Formato dell'Archivio a Due Livelli

Per abilitare una verifica efficiente, il sistema introduce una specifica struttura di archivio:

• Involtino Esterno (Tar non compresso): Contiene il manifesto di provenienza, la firma del pubblicatore, l'attestazione del registro e i checksum. Ciò consente la verifica senza decomprimere il codice sorgente.
• Contenuti Interni (Tar compresso con Gzip): Contiene i file sorgente effettivi, il manifesto del progetto e le definizioni dei tipi.
• Vantaggio: Il costo della verifica è proporzionale al piccolo involtino (~2–5 KB) piuttosto che al potenziale grande archivio sorgente.

B. Identità Crittografica del Registro

Ogni istanza di registro (pubblico, privato o scoped) riceve una coppia di chiavi Ed25519 unica.

• I registri pubblicano la propria identità (URL, chiave pubblica, impronta digitale e namespace rivendicati) su un endpoint ben noto (/.well-known/package-registry.json).
• L'Impronta Digitale della Chiave ($F_R = \text{SHA-256}(\text{chiave pubblica})$) funge da identificatore breve e verificabile.
• I registri dichiarano i namespace per i quali sono autorizzati, abilitando una fiducia gerarchica (ad esempio, Pubblico $\to$ Organizzazione $\to$ Team).

C. Modello di Distribuzione a Doppia Firma

Gli artefatti portano due firme indipendenti con rivendicazioni temporali e logiche distinte:

1. Firma del Pubblicatore ($\sigma_P$): Creata al momento dell'impacchettamento ($t_1$). Il pubblicatore firma il manifesto di provenienza, affermando la paternità e l'integrità del contenuto.
2. Attestazione del Registro ($\sigma_R$): Creata al momento della pubblicazione ($t_2 > t_1$). Il registro verifica la firma del pubblicatore, controlla l'hash del contenuto e firma un documento di attestazione. Ciò afferma che il registro ha ricevuto, verificato e sta distribuendo l'artefatto.

• Semantica della Controfirma: Questo approccio preserva l'ordine temporale e le rivendicazioni indipendenti, a differenza della co-firma che confonde gli eventi.

D. Vincolo di Namespace Autoritario

I consumatori dichiarano quali registri sono autoritari per specifici namespace nel loro manifesto di progetto (ad esempio, mashin.toml).

• Fissaggio (Pinning): I consumatori fissano l'impronta digitale della chiave del registro (Trust On First Use - TOFU).
• Applicazione: Il risolutore rifiuta crittograficamente gli artefatti provenienti da registri non autorizzati. Se un namespace è vincolato a un registro specifico, il risolutore interroga solo quel registro e rifiuta gli artefatti da altri, anche se questi hanno numeri di versione più alti.

3. Contributi Chiave

Il documento presenta sette contributi specifici:

1. Identità Crittografica del Registro: Stabilire che ogni registro possiede una coppia di chiavi Ed25519 e firma ogni artefatto, creando una prova a livello di artefatto del percorso di distribuzione.
2. Modello a Doppia Firma: Un modello di distribuzione in cui il pubblicatore firma al momento dell'impacchettamento e il registro controfirma al momento della pubblicazione, preservando l'ordine temporale.
3. Vincolo di Namespace Autoritario: Un meccanismo per consentire ai consumatori di fissare le impronte digitali dei registri e rifiutare crittograficamente gli artefatti provenienti da registri non autorizzati.
4. Formato dell'Archivio a Due Livelli: Una struttura che separa l'involtino di provenienza dai contenuti sorgente per abilitare una verifica rapida e parziale.
5. Catena di Verifica a Sei Livelli: Un processo di verifica progressivo che va dall'integrità del file (Livello 1) alla provenienza della genealogia (Livello 6), con i Livelli 1–5 che costituiscono il contributo fondamentale.
6. Confronto Sistematico degli Ecosistemi: Un'analisi di otto ecosistemi principali (npm, Cargo, Hex.pm, PyPI, Go, Docker/OCI, NuGet, Maven) che dimostra che nessun ecosistema esistente combina la firma obbligatoria del pubblicatore, l'identità crittografica del registro, la controfirma obbligatoria del registro e l'applicazione crittografica lato consumatore.
7. Integrazione con la Governance Runtime: Uno studio di caso che mostra come la provenienza della distribuzione si integri con un'architettura di governance strutturale a tre livelli per formare una catena di ciclo di vita a quattro fasi (Definizione, Distribuzione, Capacità, Esecuzione).

4. Risultati e Valutazione

Analisi di Sicurezza

Secondo il modello di minaccia definito (l'avversario può compromettere le configurazioni CI/CD o pubblicare su registri pubblici, ma non può compromettere le chiavi private del registro), il sistema fornisce una difesa a tre livelli:

• Livello 1 (Registro): L'applicazione del namespace impedisce pubblicazioni non autorizzate.
• Livello 2 (Consumatore): Il vincolo autoritario impedisce la risoluzione da registri non autorizzati.
• Livello 3 (Artefatto): L'attestazione del registro (verifica della firma) impedisce l'installazione di artefatti provenienti da registri non autorizzati anche se i Livelli 1 e 2 vengono aggirati.

Il documento dimostra che un attacco riuscito di confusione delle dipendenze richiede la compromissione simultanea della configurazione del risolutore del consumatore e della chiave di firma privata del registro target. Secondo il modello di minaccia rigoroso (dove la compromissione della chiave è esclusa), la probabilità di un attacco riuscito è zero.

Valutazione delle Prestazioni

Misurato su un processore Apple serie M:

• Latenza di Verifica: La verifica end-to-end per un progetto di 4 macchine si completa in 1,18 ms (mediana) per la modalità predefinita (Livelli 1–3) e 1,61 ms per la modalità rigorosa (Livelli 1–5).
• Sovraccarico: Le operazioni crittografiche (firma/verifica Ed25519, SHA-256) sono trascurabili (microsecondi). Il costo dominante è l'estrazione tar dell'involtino esterno (~259 µs).
• Confronto: Questo è comparabile o più veloce delle verifiche esistenti negli ecosistemi (ad esempio, le firme npm audit spesso richiedono 100–500 ms a causa dei round-trip di rete verso i log di trasparenza) perché il sistema proposto evita le chiamate di rete per i Livelli 1–5.
• Sovraccarico di Archiviazione: L'involtino di provenienza aggiunge una dimensione fissa di diversi kilobyte. Per progetti piccoli, questo rappresenta un sovraccarico percentuale elevato (ad esempio, 2.659% per una sorgente di 203 byte), ma scende a ~300% per progetti più grandi (12 macchine), diventando trascurabile rispetto alla dimensione della sorgente.

5. Significato e Affermazioni

Il documento afferma che la confusione delle dipendenze è un problema di provenienza, non un problema di configurazione.

• Difesa Strutturale: A differenza delle difese basate sulla configurazione che falliscono in modo silenzioso, questo sistema fornisce una prova crittografica incorporata nell'artefatto. La verifica è possibile indipendentemente dallo stato di configurazione del risolutore.
• Unicità: Il sistema è il primo a combinare la firma obbligatoria del pubblicatore, l'identità crittografica del registro, la controfirma obbligatoria del registro e l'applicazione crittografica lato consumatore.
• Estendibilità: L'architettura si estende alla provenienza della generazione AI (tracciamento dell'uso del modello e dei livelli di composizione come attributi firmati) e alla risoluzione delle dipendenze imposta dalla governance (imposizione di livelli di fiducia e permessi di effetto durante l'installazione anziché a posteriori).
• Completezza: Quando integrata con la provenienza di build e la governance runtime, il sistema crea una catena continua e a prova di manomissione dalla creazione del codice sorgente all'esecuzione, colmando le lacune crittografiche nella catena di fornitura del software.

Gli autori notano che il sistema non affronta il typosquatting (un attacco a livello di naming) o le minacce interne che coinvolgono l'accesso al server del registro (compromissione della chiave), che richiedono difese ortogonali come HSM e analisi comportamentale.