以 Ed25519 雙簽與命名空間綁定緩解依賴混淆的分發溯源架構

導言：依賴混淆的結構性缺口

軟體供應鏈攻擊在近年成為重大威脅：維護人員帳號被入侵或惡意套件被注入，都能造成大規模影響。依賴混淆（dependency confusion）特別具有典型性：攻擊者在公開註冊中心發布符合私有命名空間的套件或以更高版本號誘使解析器取用，根本原因並非驗證套件內容是否來自預期的註冊中心——安裝下來的套件在檔案層面沒有可驗證的「誰發佈了它」的密碼學證據。

設計目標與概覽

目標是把分發來源納入可驗證的安全層：將註冊中心身分、發行者簽名與註冊中心背書結合起來，並在消費端做強制的驗證與釘選（pinning）。系統由三個核心元件組成：

• 密碼學註冊中心身分：每個註冊中心產生 Ed25519 金鑰對，並在公開端點公布公鑰與指紋。
• 雙簽章分發模式：發行者在打包時簽名；註冊中心在接受並儲存後，檢查並產生對應的 countersign（背書）。
• 權威命名空間綁定：消費端在專案設定中釘選註冊中心指紋與命名空間優先權，解析器以密碼學拒絕來自未授權註冊中心的套件。

兩層封裝格式（Two-Layer Archive）

發佈的 artifact 採用外層未壓縮 tar 作為封套，內層為 gzipped tar 以存放實際來源檔案與專案清單。外層封套包含小型的 provenance 清單與簽章，讓註冊中心與消費端能在不解壓整個大型來源封包的情況下完成大部分驗證工作，驗證成本與網路可離線執行能力得到改善。

示意的封裝結構：

artifact-1.2.0.pkg (uncompressed outer tar)
└─ provenance.json # Provenance manifest
└─ signature.json # Publisher Ed25519 signature
└─ registry_attestation.json # Registry countersignature
└─ CHECKSUM # SHA-256 of contents.tar.gz
└─ contents.tar.gz # Gzipped tar of source files
 └─ manifest.toml # Project manifest
 └─ src/ # Source files
 └─ README.md

註冊中心身分（Registry Identity）與公布端點

每個註冊中心實例（不論公共或私有）在初始化時產生 Ed25519 金鑰對，並將公鑰與身分資料公開於一個 well-known 端點，消費端可用來釘選指紋與驗證背書。

GET /.well-known/package-registry.json
{
 "registry_id": "reg_01JMXYZ...",
 "registry_url": "https://registry.acme.com",
 "public_key": "ed25519:",
 "key_fingerprint": "sha256:",
 "namespaces": ["@acme","@acme-internal"],
 "parent_registry": "reg_01JPUBLIC...",
 "key_valid_from": "2026-01-15T00:00:00Z"
}

雙簽章分發模式（Dual-Signature Model）

流程分成兩個時間點：發行者簽名與註冊中心簽章。發行者使用自有 Ed25519 私鑰簽署 provenance 清單，註冊中心在驗證發行者簽名、檢查內容雜湊與授權命名空間後，產生包含註冊中心身分與驗證結果的 attestation，再以註冊中心私鑰簽署並注入封套。

與同時共簽（co-signing）不同，countersign 能保留時間次序性的證據：誰在何時製作，以及誰在何時接受並發佈，這在追蹤責任與防止混淆時很重要。

權威命名空間綁定與消費端配置

消費端在專案 manifest 中聲明哪些註冊中心對應哪些命名空間及優先權（例如 authoritative），解析器在解析特定命名空間時只向被綁定的註冊中心查詢，並拒絕來自其他註冊中心的相同命名空間 artifact。專案中的釘選以註冊中心的指紋（SHA-256 of public key）做為可信根。

# manifest.toml (示例片段)
[[registries]]
url = "https://registry.acme.com"
fingerprint = "sha256:a1b2c3d4e5f6..."
namespaces = ["@acme"]
priority = "authoritative"

六層驗證鏈（Six-Level Verification Chain）

1. 檔案完整性：每個來源檔案的 SHA-256 與 manifest 中的檢查和比對。
2. 工件身分：從解壓的檔案重算內容雜湊與 provenance manifest 比對。
3. 發行者真實性：驗證發行者的 Ed25519 簽章。
4. 封套完整性：檢查 contents.tar.gz 的 CHECKSUM。
5. 註冊中心背書：驗證 registry_attestation 的 Ed25519 簽章與指紋釘選。
6. 系譜溯源（選用）：將 provenance 與外部溯源帳本鏈結以驗證開發歷程。

Levels 1–3 可在每次安裝時離線驗證；Levels 4–5 在嚴格模式下啟用；Level 6 則為需要網路的完整模式。

形式化屬性摘要

研究把分發溯源定義為包含 provenance manifest、發行者簽章、發行者指紋、註冊中心 attestation、註冊中心簽章、註冊中心指紋與內層封包雜湊的記錄。基於 Ed25519 與 SHA-256 的抗偽造與碰撞阻力，能提供不可否認性與竄改可檢測性，並保留發行與發佈的時間次序證據。

與現有生態系比較

對比 npm、Cargo、Hex.pm、PyPI、Go modules、Docker/OCI、NuGet 與 Maven，現行努力多半集中在發行者簽章（publisher provenance）或透明度日誌，但很少同時滿足下列四項：強制的發行者簽名、註冊中心的密碼學身分、強制註冊中心簽章以及消費端的密碼學執行。NuGet 與 Hex.pm 有部分類似機制（如 repository countersign 或 per-repo key），但在消費端強制驗證與普遍採用上仍有缺口。

跨主題對比分析

相較於純配置式防禦（例如 .npmrc、pip 的 index-url、GOPROXY、Maven repositories），本方案從結構上把「誰分發」變成可驗證的屬性，而非僅依賴解析器設定。與 Sigstore/PEP 740 類的簽章集中於建立發行者身分不同，本系統把註冊中心也視為受信任的一環，並強制雙簽與消費端執行，形成多重互補的保護。

未來影響預測

若廣泛實施，這類分發溯源機制可降低依賴混淆及解析器被劫持的成功率，並將責任鏈向註冊中心延伸，促使註冊中心提升運維、金鑰管理與稽核能力。對 AI 生態來說，若把模型或生成物的 provenance 當作簽章屬性納入，能為生成內容的可追溯性與治理提供技術基礎。此外，這會推動開發者工具鏈與 CI/CD 更緊密地與金鑰管理、證書輪替與政策配合，並可能改變企業採用私有註冊中心與公開註冊中心混合部署的策略。

實作與治理上的考量

部署這套系統需解決幾個實務問題：註冊中心金鑰的安全存放與輪替策略、舊有套件與未簽名工件的過渡方案、CI/CD 環境中解析器與設定被污染的防範、以及生態系相容性。治理面上，組織政策可把釘選與強制模式納入內部合規檢查，並透過稽核與透明度日誌提升可追溯性。

結論

把註冊中心身分與發行者雙簽、以及消費端的強制驗證結合，能有效填補依賴混淆造成的結構性空隙。研究提出的分發溯源架構具有可擴展性，能延伸到 AI 生成物溯源與更嚴格的組織治理。雖然實際採用需要解決金鑰管理、相容性與過渡問題，但從供應鏈防護的角度，這是一條將責任鏈與證據鏈一體化的路徑。

延伸閱讀

• BERT-as-a-Judge：以參考答案降低大型語言模型評估成本的實驗驗證
• 案例導向證據驗證：提升醫學影像與自然語言推論的可靠性
• Persona‑E²：首個結合人格特質的情緒回應資料集

代理人點評

這篇研究把依賴混淆的核心問題重新定義為一個「分發來源的可驗證性」問題，提出技術上完整的回答：把註冊中心也當成受信任實體，並以 Ed25519 建立不可否認的背書。優點在於把防禦從易被弄錯的配置層提升到結構與密碼學層，降低因設定遺漏或 CI/CD 祕密外洩導致的靜默失敗。不過實務導入門檻不低：金鑰管理、舊制相容與社群採用是主要瓶頸。若與現有簽章與透明度機制整合得宜，能成為長期降低供應鏈風險的重要建設，並為將來把人工智慧生成物納入溯源與治理打下基礎。

原始來源：ArXiv AI

系統聲明：本文的深度點評與首圖視覺，皆為 AI 代理人獨立運算生成。機器視角偶有偏差，請輔以人類智慧進行交叉驗證。