💻 computer science

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

This paper proposes a cryptographic registry provenance system that defends against dependency confusion attacks in AI package ecosystems by implementing mandatory publisher and registry dual-signatures alongside consumer-side cryptographic enforcement to eliminate structural gaps in software distribution.

Original authors: Alan L. McCann

Published 2026-05-06

📖 5 min read🧠 Deep dive

CC0 1.0

Original authors: Alan L. McCann

Original paper dedicated to the public domain under CC0 1.0 (http://creativecommons.org/publicdomain/zero/1.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are ordering a custom cake from a bakery. You have a private, trusted bakery in your neighborhood (your company's internal registry) and a massive, public marketplace where anyone can sell cakes (the public internet registry).

The Problem: The "Fake Baker" Trick
Currently, if you ask for "Chocolate Cake," your delivery driver might accidentally pick up a cake from a stranger in the public marketplace who just happened to name their cake "Chocolate Cake" and put a higher price tag on it. The driver doesn't know the difference because the cake box looks the same, and the driver only checks a list of instructions (configuration) that can be easily changed or ignored.

This is called a Dependency Confusion attack. Hackers trick companies into downloading malicious software by pretending to be the company's own private software, but from a public, untrusted source. Once the bad software is installed, there is no way to prove where it actually came from.

The Solution: A "Tamper-Proof Passport" System
The paper proposes a new system where every software package comes with a cryptographic "passport" that proves exactly which bakery (registry) delivered it. It works like a three-layer security check:

Layer 1: The Baker's ID Card (Registry Identity)

Every bakery (registry) gets a unique, unforgeable ID card (a cryptographic key).

How it works: Before you even order, your company says, "We only trust the neighborhood bakery." The system checks the ID card of the bakery delivering the cake. If it's not the neighborhood bakery, the delivery is rejected immediately.
The Analogy: It's like a bouncer at a club checking a specific VIP list. If your name isn't on the list for this specific club, you don't get in.

Layer 2: The Double Signature (Dual-Signature Model)

Every cake box gets two signatures, like a notary public and the baker both signing a document.

The Baker's Signature: The person who baked the cake signs it first, saying, "I made this."
The Delivery Service's Signature: The registry (the delivery service) signs it after receiving it, saying, "I checked this cake, verified the baker, and I am the one delivering it to you."

Why two? This proves two things: who made it, and exactly which delivery service brought it to your door. If a hacker tries to swap the box, the second signature won't match the delivery service you trust.

Layer 3: The Locked Box (Authoritative Namespace Binding)

You don't just trust the delivery service; you lock the door to your kitchen to only open for that specific service.

How it works: Your computer is programmed to say, "If the package says it's from the 'Company' namespace, it must come from the 'Company' registry's ID card." If a package arrives with the right name but the wrong ID card (even if it looks perfect), your computer slams the door and rejects it.
The Analogy: It's like having a mailbox that only accepts letters from your specific postman. Even if a stranger leaves a letter that looks exactly like your mail, the mailbox won't open for them.

The "Three-Layer" Defense

The paper argues that to successfully hack this system, a criminal would have to break three different locks at the exact same time:

Trick the registry into letting them publish under your name (Layer 1).
Trick your computer into trusting the wrong registry (Layer 2).
Steal the secret digital keys of the registry to forge the signature (Layer 3).

The paper claims that because the third layer (the digital signature) is mathematically unbreakable without the private key, the attack probability drops to zero, even if the first two layers are confused.

What About the "Cake" Itself?

The paper also introduces a special way of packaging the software (the "Two-Layer Archive").

Imagine the software is a fragile cake inside a box.
Inner Box: The cake itself (compressed).
Outer Box: A clear, uncrushable envelope containing the "passport" (signatures and ID).
The Benefit: The delivery driver (the computer) can check the passport in the outer box without even opening the inner box. This makes the security check incredibly fast (milliseconds) and ensures the passport can never get lost or separated from the cake.

The Bottom Line

The paper concludes that current security methods are like giving drivers a piece of paper with instructions that can be easily lost or changed. This new system puts the proof of origin inside the package itself. It turns a "trust me" situation into a "prove it" situation, making it mathematically impossible to confuse a private package with a public one without breaking the laws of cryptography.

What it doesn't do:
The paper admits this system doesn't stop someone from writing a fake name on a package (typosquatting) or tricking a human into giving up their keys (social engineering). It strictly solves the problem of "Which registry actually delivered this file?"

Technical Summary: Cryptographic Registry Provenance

1. Problem Statement

The paper identifies a critical structural gap in modern software distribution ecosystems: Dependency Confusion. While existing defenses (e.g., .npmrc mappings, GOPROXY variables) operate at the configuration layer, they fail silently when misconfigured, overridden by CI/CD variables, or absent. Once a package is installed, there is no cryptographic proof of which registry distributed it.

The core vulnerability is that package resolvers query multiple registries (public and private) and select artifacts based on version numbers. An attacker can publish a malicious package with a higher version number to a public registry under a namespace the victim organization uses privately. Because the artifact itself carries no evidence of its distribution path, the resolver may silently select the attacker's artifact over the legitimate private one. Current ecosystems lack a mechanism to cryptographically verify the distribution path or enforce namespace authority at the artifact level.

2. Methodology and Architecture

The authors propose a Cryptographic Distribution Provenance System that shifts defense from configuration to the artifact itself. The system relies on three core components:

A. Two-Layer Archive Format

To enable efficient verification, the system introduces a specific archive structure:

Outer Envelope (Uncompressed Tar): Contains the provenance manifest, publisher signature, registry attestation, and checksums. This allows verification without decompressing the source code.
Inner Contents (Gzipped Tar): Contains the actual source files, project manifest, and type definitions.
Benefit: Verification cost is proportional to the small envelope (~2–5 KB) rather than the potentially large source archive.

B. Cryptographic Registry Identity

Every registry instance (public, private, or scoped) is assigned a unique Ed25519 keypair.

Registries publish their identity (URL, public key, fingerprint, and claimed namespaces) at a well-known endpoint (/.well-known/package-registry.json).
The Key Fingerprint ( $F_R = \text{SHA-256}(\text{public key})$ ) serves as a short, verifiable identifier.
Registries declare the namespaces they are authoritative for, enabling hierarchical trust (e.g., Public $\to$ Organization $\to$ Team).

C. Dual-Signature Distribution Model

Artifacts carry two independent signatures with distinct temporal and logical claims:

Publisher Signature ( $\sigma_P$ ): Created at packaging time ( $t_1$ ). The publisher signs the provenance manifest, asserting authorship and content integrity.
Registry Attestation ( $\sigma_R$ ): Created at publication time ( $t_2 > t_1$ ). The registry verifies the publisher's signature, checks the content hash, and signs an attestation document. This asserts that the registry received, verified, and is distributing the artifact.

Countersigning Semantics: This approach preserves temporal ordering and independent claims, unlike co-signing which conflates events.

D. Authoritative Namespace Binding

Consumers declare which registries are authoritative for specific namespaces in their project manifest (e.g., mashin.toml).

Pinning: Consumers pin the registry's key fingerprint (Trust On First Use - TOFU).
Enforcement: The resolver cryptographically rejects artifacts from unauthorized registries. If a namespace is bound to a specific registry, the resolver queries only that registry and rejects artifacts from others, even if they have higher version numbers.

3. Key Contributions

The paper presents seven specific contributions:

Cryptographic Registry Identity: Establishing that every registry holds an Ed25519 keypair and signs every artifact, creating artifact-level proof of the distribution path.
Dual-Signature Model: A distribution model where the publisher signs at packaging and the registry countersigns at publication, preserving temporal ordering.
Authoritative Namespace Binding: A mechanism for consumers to pin registry fingerprints and cryptographically reject artifacts from unauthorized registries.
Two-Layer Archive Format: A structure separating the provenance envelope from source contents to enable fast, partial verification.
Six-Level Verification Chain: A progressive verification process ranging from file integrity (Level 1) to lineage provenance (Level 6), with Levels 1–5 being the core contribution.
Systematic Ecosystem Comparison: An analysis of eight major ecosystems (npm, Cargo, Hex.pm, PyPI, Go, Docker/OCI, NuGet, Maven) demonstrating that no existing ecosystem combines mandatory publisher signing, cryptographic registry identity, mandatory registry countersigning, and consumer-side cryptographic enforcement.
Runtime Governance Integration: A case study showing how distribution provenance integrates with a three-layer structural governance architecture to form a four-phase lifecycle chain (Definition, Distribution, Capability, Execution).

4. Results and Evaluation

Security Analysis

Under the defined threat model (adversary can compromise CI/CD configs or publish to public registries, but cannot compromise registry private keys), the system provides a three-layer defense:

Layer 1 (Registry): Namespace enforcement prevents unauthorized publishing.
Layer 2 (Consumer): Authoritative binding prevents resolution from unauthorized registries.
Layer 3 (Artifact): Registry attestation (signature verification) prevents installation of artifacts from unauthorized registries even if Layers 1 and 2 are bypassed.

The paper proves that a successful dependency confusion attack requires the simultaneous compromise of the consumer's resolver configuration and the target registry's private signing key. Under the strict threat model (where key compromise is excluded), the probability of a successful attack is zero.

Performance Evaluation

Measured on an Apple M-series processor:

Verification Latency: End-to-end verification for a 4-machine project completes in 1.18 ms (median) for default mode (Levels 1–3) and 1.61 ms for strict mode (Levels 1–5).
Overhead: The cryptographic operations (Ed25519 sign/verify, SHA-256) are negligible (microseconds). The dominant cost is tar extraction of the outer envelope (~259 µs).
Comparison: This is comparable to or faster than existing ecosystem verification (e.g., npm audit signatures often take 100–500 ms due to network round-trips to transparency logs) because the proposed system avoids network calls for Levels 1–5.
Storage Overhead: The provenance envelope adds a fixed size of several kilobytes. For small projects, this is a high percentage overhead (e.g., 2,659% for a 203-byte source), but drops to ~300% for larger projects (12 machines), becoming negligible relative to the source size.

5. Significance and Claims

The paper claims that dependency confusion is a provenance problem, not a configuration problem.

Structural Defense: Unlike configuration-based defenses that fail silently, this system provides cryptographic proof embedded in the artifact. Verification is possible regardless of the resolver's configuration state.
Uniqueness: The system is the first to combine mandatory publisher signing, cryptographic registry identity, mandatory registry countersigning, and consumer-side cryptographic enforcement.
Extensibility: The architecture extends to AI-generation provenance (tracking model usage and composition levels as signed attributes) and governance-enforced dependency resolution (enforcing trust tiers and effect permissions during installation rather than post-hoc).
Completeness: When integrated with build provenance and runtime governance, the system creates a continuous, tamper-evident chain from source code creation to execution, closing cryptographic gaps in the software supply chain.

The authors note that the system does not address typosquatting (a naming-layer attack) or insider threats involving registry server access (key compromise), which require orthogonal defenses like HSMs and behavioral analysis.