💻 computer science

Cryptographic Registry Provenance: Structural Defense Against Dependency Confusion in AI Package Ecosystems

Dit artikel stelt een cryptografisch register-provenance-systeem voor dat zich verdedigt tegen aanvalsen op afhankelijkheidsverwarring in AI-pakketecosystemen door het implementeren van verplichte dubbele handtekeningen van uitgever en register, gecombineerd met cryptografische afdwinging aan de kant van de consument, om structurele gaten in softwareverdeling te elimineren.

Oorspronkelijke auteurs: Alan L. McCann

Gepubliceerd 2026-05-06

📖 5 min leestijd🧠 Diepgaand

CC0 1.0

Oorspronkelijke auteurs: Alan L. McCann

Oorspronkelijk artikel vrijgegeven aan het publieke domein onder CC0 1.0 (http://creativecommons.org/publicdomain/zero/1.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een taart op maat bestelt bij een bakkerij. Je hebt een privé, vertrouwde bakkerij in je buurt (het interne register van je bedrijf) en een enorm, openbaar marktplein waar iedereen taarten kan verkopen (het openbare internetregister).

Het Probleem: De "Valse Bakker"-Truc
Op dit moment kan het zijn dat, als je om een "Chocoladetaart" vraagt, je bezorger per ongeluk een taart oppakt van een vreemdeling op het openbare marktplein die toevallig zijn taart "Chocoladetaart" heeft genoemd en er een hogere prijskaart aan heeft gehangen. De bezorger maakt het onderscheid niet, omdat de taartdoos er hetzelfde uitziet, en de bezorger alleen een lijst met instructies (configuratie) controleert die eenvoudig kan worden gewijzigd of genegeerd.

Dit wordt een Dependency Confusion-aanval genoemd. Hackers misleiden bedrijven om kwaadaardige software te downloaden door zich voor te doen als de eigen private software van het bedrijf, maar dan vanuit een openbare, onbetrouwbare bron. Zodra de slechte software is geïnstalleerd, is er geen manier om te bewijzen waar het vandaan kwam.

De Oplossing: Een "Verstevigd Paspoort"-Systeem
Het paper stelt een nieuw systeem voor waarbij elk softwarepakket wordt geleverd met een cryptografisch "paspoort" dat exact bewijst welke bakkerij (register) het heeft geleverd. Het werkt als een drie-laags beveiligingscontrole:

Laag 1: Het ID-kaartje van de Bakker (Identiteit van het Register)

Elke bakkerij (register) krijgt een unieke, niet-nabootsbare ID-kaart (een cryptografische sleutel).

Hoe het werkt: Voordat je zelfs maar bestelt, zegt je bedrijf: "We vertrouwen alleen de bakkerij in de buurt." Het systeem controleert het ID-kaartje van de bakkerij die de taart levert. Als het niet de bakkerij in de buurt is, wordt de levering direct geweigerd.
De Analogie: Het is als een bouncer bij een club die een specifieke VIP-lijst controleert. Als je naam niet op de lijst staat voor deze specifieke club, kom je niet binnen.

Laag 2: De Dubbele Handtekening (Model met Dubbele Handtekening)

Elke taartdoos krijgt twee handtekeningen, alsof een notaris en de bakker een document samen ondertekenen.

De Handtekening van de Bakker: De persoon die de taart heeft gebakken, tekent eerst en zegt: "Ik heb dit gemaakt."
De Handtekening van de Bezorgdienst: Het register (de bezorgdienst) tekent het na ontvangst en zegt: "Ik heb deze taart gecontroleerd, de bakker geverifieerd, en ik ben degene die het aan jou levert."

Waarom twee? Dit bewijst twee dingen: wie het heeft gemaakt, en exact welke bezorgdienst het bij je deur heeft gebracht. Als een hacker de doos probeert te verwisselen, komt de tweede handtekening niet overeen met de bezorgdienst die je vertrouwt.

Laag 3: De Vergrendelde Doos (Autoritair Namespace-binding)

Je vertrouwt niet alleen de bezorgdienst; je sluit de deur van je keuken af zodat deze alleen opent voor die specifieke dienst.

Hoe het werkt: Je computer is geprogrammeerd om te zeggen: "Als het pakket zegt dat het van de 'Bedrijf'-namespace komt, moet het noodzakelijkerwijs komen van het ID-kaartje van het 'Bedrijf'-register." Als een pakket aankomt met de juiste naam maar het verkeerde ID-kaartje (zelfs als het er perfect uitziet), slaat je computer de deur dicht en weigert het.
De Analogie: Het is als een brievenbus die alleen brieven accepteert van je specifieke postbode. Zelfs als een vreemdeling een brief achterlaat die er precies uitziet als je post, zal de brievenbus niet voor hen openen.

De "Drie-Laags"-Verdediging

Het paper betoogt dat een crimineel, om dit systeem succesvol te hacken, op exact hetzelfde moment drie verschillende sloten moet openbreken:

Het register bedriegen om hen toe te staan onder jouw naam te publiceren (Laag 1).
Je computer bedriegen om het verkeerde register te vertrouwen (Laag 2).
De geheime digitale sleutels van het register stelen om de handtekening te vervalsen (Laag 3).

Het paper beweert dat, omdat de derde laag (de digitale handtekening) wiskundig onbreekbaar is zonder de privésleutel, de aanvalskans terugvalt tot nul, zelfs als de eerste twee lagen verward zijn.

Wat zit er in de "Taart" zelf?
Het paper introduceert ook een speciale manier om de software te verpakken (het "Twee-Lagen Archief").

Stel je voor dat de software een kwetsbare taart is in een doos.
Binnenste Doos: De taart zelf (gecomprimeerd).
Buitenste Doos: Een transparante, onbreekbare envelop die het "paspoort" bevat (handtekeningen en ID).
Het Voordeel: De bezorger (de computer) kan het paspoort in de buitenste doos controleren zonder de binnenste doos zelfs maar te openen. Dit maakt de beveiligingscontrole ongelooflijk snel (milliseconden) en zorgt ervoor dat het paspoort nooit verloren kan raken of gescheiden kan worden van de taart.

De Conclusie
Het paper concludeert dat huidige beveiligingsmethoden zijn als het geven van een stuk papier met instructies aan bezorgers dat gemakkelijk verloren kan gaan of kan worden gewijzigd. Dit nieuwe systeem plaatst het bewijs van herkomst in het pakket zelf. Het verandert een "vertrouw me"-situatie in een "bewijs het"-situatie, waardoor het wiskundig onmogelijk wordt om een privé-pakket te verwarren met een openbaar pakket zonder de wetten van de cryptografie te verbreken.

Wat het niet doet:
Het paper geeft toe dat dit systeem niet voorkomt dat iemand een valse naam op een pakket schrijft (typosquatting) of een mens bedriegt om hun sleutels af te staan (sociale manipulatie). Het lost strikt het probleem op van "Welk register heeft dit bestand daadwerkelijk geleverd?"

Technische Samenvatting: Cryptografische Herkomst van Registers

1. Probleemstelling

Het paper identificeert een kritieke structurele kloof in moderne software-distributie-ecosystemen: Dependency Confusion. Hoewel bestaande verdedigingsmechanismen (bijv. .npmrc-toewijzingen, GOPROXY-variabelen) werken op het configuratielaag, falen ze stilzwijgend bij verkeerde configuratie, overschrijving door CI/CD-variabelen of afwezigheid. Zodra een pakket is geïnstalleerd, bestaat er geen cryptografisch bewijs van welke registry het heeft gedistribueerd.

De kernkwetsbaarheid is dat pakketoplossers meerdere registers (publiek en privaat) bevragen en artefacten selecteren op basis van versienummers. Een aanvaller kan een kwaadaardig pakket met een hoger versienummer publiceren naar een publieke registry onder een namespace die het slachtofferorganisatie privaat gebruikt. Omdat het artefact zelf geen bewijs draagt van zijn distributieweg, kan de oplossingstool stilzwijgend het artefact van de aanvaller selecteren boven het legitieme private exemplaar. Huidige ecosystemen missen een mechanisme om de distributieweg cryptografisch te verifiëren of namespace-autoriteit op artefactniveau af te dwingen.

2. Methodologie en Architectuur

De auteurs stellen een Cryptografisch Distributieherkomst-systeem voor dat de verdediging verschuift van configuratie naar het artefact zelf. Het systeem rust op drie kerncomponenten:

A. Tweelaags Archiefformaat

Om efficiënte verificatie mogelijk te maken, introduceert het systeem een specifieke archiefstructuur:

Buitenste Omhulsel (Ongecomprimeerde Tar): Bevat het herkomstmanifest, de handtekening van de uitgever, de registry-attestatie en checksums. Dit maakt verificatie mogelijk zonder de broncode te decomprimeren.
Binnenste Inhoud (Gecomprimeerde Tar): Bevat de daadwerkelijke bronbestanden, het projectmanifest en type-definities.
Voordeel: De verificatiekosten zijn evenredig met het kleine omhulsel (~2–5 KB) in plaats van het potentieel grote bronarchief.

B. Cryptografische Registry-Identiteit

Elke registry-instantie (publiek, privaat of gescope) krijgt een unieke Ed25519-sleutelpaar toegewezen.

Registers publiceren hun identiteit (URL, publieke sleutel, vingerafdruk en beweerde namespaces) op een bekende eindpunt (/.well-known/package-registry.json).
De Sleutelvingerafdruk ( $F_R = \text{SHA-256}(\text{publieke sleutel})$ ) dient als een korte, verifieerbare identifier.
Registers verklaren voor welke namespaces ze autoriteit hebben, wat hiërarchisch vertrouwen mogelijk maakt (bijv. Publiek $\to$ Organisatie $\to$ Team).

C. Dubbel-Handtekening Distributiemodel

Artefacten dragen twee onafhankelijke handtekeningen met onderscheiden temporale en logische claims:

Uitgever-Handtekening ( $\sigma_P$ ): Aangemaakt op het moment van verpakking ( $t_1$ ). De uitgever ondertekent het herkomstmanifest en bevestigt auteurschap en inhoudsintegriteit.
Registry-Attestatie ( $\sigma_R$ ): Aangemaakt op het moment van publicatie ( $t_2 > t_1$ ). De registry verifieert de handtekening van de uitgever, controleert de inhoud-hash en ondertekent een attestatiedocument. Dit bevestigt dat de registry het artefact heeft ontvangen, geverifieerd en distribueert.

Tegenhandtekenings-Semantiek: Deze benadering behoudt de temporale volgorde en onafhankelijke claims, in tegenstelling tot co-handtekenen dat gebeurtenissen door elkaar haalt.

D. Autoritair Namespace-binding

Consumenten verklaren in hun projectmanifest (bijv. mashin.toml) welke registers autoriteit hebben voor specifieke namespaces.

Vastpinnen: Consumenten pinnen de vingerafdruk van de registry-sleutel (Trust On First Use - TOFU).
Handhaving: De oplossingstool verwerpt cryptografisch artefacten van niet-geautoriseerde registers. Als een namespace is gebonden aan een specifieke registry, vraagt de oplossingstool alleen die registry en verwerpt hij artefacten van anderen, zelfs als deze hogere versienummers hebben.

3. Belangrijkste Bijdragen

Het paper presenteert zeven specifieke bijdragen:

Cryptografische Registry-Identiteit: Het vaststellen dat elke registry een Ed25519-sleutelpaar bezit en elk artefact ondertekent, waardoor bewijs van de distributieweg op artefactniveau ontstaat.
Dubbel-Handtekening Model: Een distributiemodel waarbij de uitgever ondertekent bij verpakking en de registry tegenhandtekent bij publicatie, waardoor de temporale volgorde wordt behouden.
Autoritair Namespace-binding: Een mechanisme waarmee consumenten registry-vingerafdrukken kunnen vastpinnen en cryptografisch artefacten van niet-geautoriseerde registers kunnen verwerpen.
Tweelaags Archiefformaat: Een structuur die het herkomstomhulsel scheidt van de broninhoud om snelle, gedeeltelijke verificatie mogelijk te maken.
Zes-niveau Verificatieketen: Een progressief verificatieproces variërend van file-integriteit (Niveau 1) tot afstammingsherkomst (Niveau 6), waarbij Niveau 1–5 de kernbijdrage vormen.
Systematische Ecosysteemvergelijking: Een analyse van acht grote ecosystemen (npm, Cargo, Hex.pm, PyPI, Go, Docker/OCI, NuGet, Maven) die aantoont dat geen enkel bestaand ecosysteem verplichte uitgever-ondertekening, cryptografische registry-identiteit, verplichte registry-tegenhandtekening en consument-zijde cryptografische handhaving combineert.
Integratie met Runtime Governance: Een case study die laat zien hoe distributieherkomst integreert met een drie-laags structureel governance-architectuur om een vier-fasen levenscyclusketen te vormen (Definitie, Distributie, Capabiliteit, Executie).

4. Resultaten en Evaluatie

Veiligheidsanalyse

Onder het gedefinieerde bedreigingsmodel (een aanvaller kan CI/CD-configuraties compromitteren of naar publieke registers publiceren, maar kan de private sleutels van de registry niet compromitteren), biedt het systeem een drie-laags verdediging:

Laag 1 (Registry): Namespace-handhaving voorkomt ongeautoriseerde publicatie.
Laag 2 (Consument): Autoritair binding voorkomt oplossing vanuit niet-geautoriseerde registers.
Laag 3 (Artefact): Registry-attestatie (handtekeningverificatie) voorkomt installatie van artefacten van niet-geautoriseerde registers, zelfs als Laag 1 en 2 worden omzeild.

Het paper bewijst dat een succesvolle dependency confusion-aanval vereist dat tegelijkertijd de oplossingstool-configuratie van de consument en de private ondertekeningssleutel van de doel-registry worden gecompromitteerd. Onder het strikte bedreigingsmodel (waarbij sleutelcompromittering is uitgesloten) is de kans op een succesvolle aanval nul.

Prestatie-evaluatie

Gemeten op een Apple M-serie processor:

Verificatietijd: End-to-end verificatie voor een project van 4 machines voltooit in 1,18 ms (mediaan) voor de standaardmodus (Niveau 1–3) en 1,61 ms voor de strenge modus (Niveau 1–5).
Overhead: De cryptografische bewerkingen (Ed25519 ondertekenen/verifiëren, SHA-256) zijn verwaarloosbaar (microseconden). De dominante kosten zijn tar-uitpakking van het buitenste omhulsel (~259 µs).
Vergelijking: Dit is vergelijkbaar met of sneller dan bestaande ecosysteemverificatie (bijv. npm audit-handtekeningen duren vaak 100–500 ms door netwerk-roundtrips naar transparantielogboeken) omdat het voorgestelde systeem netwerkoproepen voor Niveau 1–5 vermijdt.
Opslagoverhead: Het herkomstomhulsel voegt een vaste grootte van enkele kilobytes toe. Voor kleine projecten is dit een hoog percentage overhead (bijv. 2.659% voor een bron van 203 bytes), maar daalt dit tot ~300% voor grotere projecten (12 machines), waardoor het relatief verwaarloosbaar wordt ten opzichte van de brongrootte.

5. Betekenis en Claims

Het paper beweert dat dependency confusion een herkomstprobleem is, geen configuratieprobleem.

Structurele Verdediging: In tegenstelling tot op configuratie gebaseerde verdedigingen die stilzwijgend falen, biedt dit systeem cryptografisch bewijs ingebed in het artefact. Verificatie is mogelijk ongeacht de configuratiestatus van de oplossingstool.
Uniekheid: Het systeem is het eerste dat verplichte uitgever-ondertekening, cryptografische registry-identiteit, verplichte registry-tegenhandtekening en consument-zijde cryptografische handhaving combineert.
Uitbreidbaarheid: De architectuur is uitbreidbaar naar AI-generatie herkomst (het bijhouden van modelgebruik en samenstellingsniveaus als ondertekende attributen) en governance-afgedwongen afhankelijkheidsoplossing (het afdwingen van vertrouwensniveaus en effectrechten tijdens installatie in plaats van achteraf).
Volledigheid: Wanneer geïntegreerd met bouwherkomst en runtime governance, creëert het systeem een continue, vervalsing-bewijsketen van broncodecreatie tot uitvoering, waardoor cryptografische gaten in de softwareleveringsketen worden gesloten.

De auteurs merken op dat het systeem geen oplossing biedt voor typosquatting (een aanval op de naamgevingslaag) of interne bedreigingen die toegang tot de registry-server omvatten (sleutelcompromittering); hiervoor zijn orthogonale verdedigingen nodig zoals HSM's en gedragsanalyse.