技術的概要：暗号化レジストリ発生源

1. 問題定義

本論文は、現代のソフトウェア配布エコシステムにおける重大な構造的欠陥、「依存関係の混乱（Dependency Confusion）」を特定している。既存の防御策（例：.npmrc マッピング、GOPROXY 変数）は設定層で機能するが、設定ミス、CI/CD 変数による上書き、または欠落時に静かに失敗する。パッケージがインストールされた後、どのレジストリから配布されたかを示す暗号的な証拠は存在しない。

核心的な脆弱性は、パッケージ解決器が複数のレジストリ（パブリックおよびプライベート）を照会し、バージョン番号に基づいてアーティファクトを選択することにある。攻撃者は、被害組織がプライベートに使用する名前空間の下で、パブリックレジストリにより高いバージョン番号を持つ悪意のあるパッケージを公開できる。アーティファクト自体に配布経路の証拠が含まれていないため、解決器は正当なプライベートなアーティファクトよりも攻撃者のアーティファクトを静かに選択する可能性がある。現在のエコシステムには、配布経路を暗号的に検証する、またはアーティファクトレベルで名前空間の権限を強制するメカニズムが存在しない。

2. 手法とアーキテクチャ

著者は、防御を構成からアーティファクト自体へと移行させる「暗号化配布発生源システム」を提案する。このシステムは 3 つの中核コンポーネントに依存する。

A. 2 層アーカイブ形式

効率的な検証を可能にするため、システムは特定のアーカイブ構造を導入する。

• 外側エンベロープ（非圧縮 Tar）： 発生源マニフェスト、パブリッシャー署名、レジストリアテステーション、およびチェックサムを含む。これにより、ソースコードを解凍することなく検証が可能となる。
• 内側コンテンツ（Gzip 圧縮 Tar）： 実際のソースファイル、プロジェクトマニフェスト、および型定義を含む。
• 利点： 検証コストは、潜在的に大規模なソースアーカイブではなく、小さなエンベロープ（約 2〜5 KB）に比例する。

B. 暗号的レジストリ ID

すべてのレジストリインスタンス（パブリック、プライベート、スコープ付き）には、一意の Ed25519 鍵ペア が割り当てられる。

• レジストリは、その ID（URL、公開鍵、フィンガープリント、および主張する名前空間）を既知のエンドポイント（/.well-known/package-registry.json）で公開する。
• 鍵フィンガープリント（$F_R = \text{SHA-256}(\text{公開鍵})$）は、短く検証可能な識別子として機能する。
• レジストリは、自分が権限を持つ名前空間を宣言し、階層的な信頼（例：パブリック $\to$ 組織 $\to$ チーム）を可能にする。

C. 二重署名配布モデル

アーティファクトは、異なる時間的・論理的な主張を持つ 2 つの独立した署名を保持する。

1. パブリッシャー署名（$\sigma_P$）： パッケージ化時（$t_1$）に作成される。パブリッシャーは発生源マニフェストに署名し、著作者とコンテンツの完全性を主張する。
2. レジストリアテステーション（$\sigma_R$）： 公開時（$t_2 > t_1$）に作成される。レジストリはパブリッシャーの署名を検証し、コンテンツハッシュを確認し、アテステーション文書に署名する。これにより、レジストリがアーティファクトを受領・検証し、配布していることが主張される。

• カウンター署名のセマンティクス： このアプローチは、イベントを混同する共署名とは異なり、時間的順序と独立した主張を保持する。

D. 権限ある名前空間バインディング

消費者は、プロジェクトマニフェスト（例：mashin.toml）内で、特定の名前空間に対する権限あるレジストリを宣言する。

• ピン留め： 消費者はレジストリの鍵フィンガープリントをピン留めする（初回使用時の信頼 - TOFU）。
• 強制： 解決器は、権限のないレジストリからのアーティファクトを暗号的に拒否する。名前空間が特定のレジストリにバインドされている場合、解決器はそのレジストリのみを照会し、バージョン番号がより高くても他のレジストリからのアーティファクトを拒否する。

3. 主要な貢献

本論文は、7 つの具体的な貢献を提示する。

1. 暗号的レジストリ ID： すべてのレジストリが Ed25519 鍵ペアを保持し、すべてのアーティファクトに署名することで、配布経路のアーティファクトレベルの証明を確立する。
2. 二重署名モデル： パッケージ化時にパブリッシャーが署名し、公開時にレジストリがカウンター署名する配布モデルであり、時間的順序を保持する。
3. 権限ある名前空間バインディング： 消費者がレジストリフィンガープリントをピン留めし、権限のないレジストリからのアーティファクトを暗号的に拒否するメカニズム。
4. 2 層アーカイブ形式： 発生源エンベロープとソースコンテンツを分離し、高速かつ部分的な検証を可能にする構造。
5. 6 レベル検証チェーン： ファイル完全性（レベル 1）から系譜発生源（レベル 6）までの漸進的検証プロセス。レベル 1〜5 が中核的な貢献である。
6. 体系的なエコシステム比較： npm、Cargo、Hex.pm、PyPI、Go、Docker/OCI、NuGet、Maven の 8 つの主要エコシステムの分析により、既存のどのエコシステムも、必須のパブリッシャー署名、暗号的レジストリ ID、必須のレジストリカウンター署名、および消費者側の暗号化強制を組み合わせないことを実証する。
7. ランタイムガバナンス統合： 配布発生源が 3 層構造ガバナンスアーキテクチャと統合され、4 フェーズのライフサイクルチェーン（定義、配布、機能、実行）を形成する方法を示すケーススタディ。

4. 結果と評価

セキュリティ分析

定義された脅威モデル（攻撃者は CI/CD 設定を侵害したりパブリックレジストリに公開したりできるが、レジストリの秘密鍵を侵害することはできない）の下で、システムは3 層防御を提供する。

• レイヤー 1（レジストリ）： 名前空間強制により、権限のない公開を防止する。
• レイヤー 2（消費者）： 権限バインディングにより、権限のないレジストリからの解決を防止する。
• レイヤー 3（アーティファクト）： レジストリアテステーション（署名検証）により、レイヤー 1 と 2 が回避された場合でも、権限のないレジストリからのアーティファクトのインストールを防止する。

本論文は、依存関係の混乱攻撃が成功するためには、消費者の解決器設定とターゲットレジストリの秘密署名鍵の両方が同時に侵害される必要があることを証明する。厳格な脅威モデル（鍵侵害が除外されている場合）において、攻撃が成功する確率はゼロである。

パフォーマンス評価

Apple M シリーズプロセッサで測定。

• 検証レイテンシ： 4 マシンプロジェクトのエンドツーエンド検証は、デフォルトモード（レベル 1〜3）で1.18 ms（中央値）、厳格モード（レベル 1〜5）で1.61 msで完了する。
• オーバーヘッド： 暗号化操作（Ed25519 署名/検証、SHA-256）は無視できる（マイクロ秒）。支配的なコストは、外側エンベロープの tar 展開（約 259 µs）である。
• 比較： この性能は、既存のエコシステム検証（例：npm の監査署名は透明性ログへのネットワーク往復により 100〜500 ms かかることが多い）と同等かそれ以上である。提案されたシステムはレベル 1〜5 でのネットワーク呼び出しを回避するためである。
• ストレージオーバーヘッド： 発生源エンベロープは数 KB の固定サイズを追加する。小規模プロジェクトでは、これは高い割合のオーバーヘッドとなる（例：203 バイトのソースに対して 2,659%）が、大規模プロジェクト（12 マシン）では約 300% に低下し、ソースサイズに対して無視できるレベルになる。

5. 意義と主張

本論文は、依存関係の混乱は設定の問題ではなく、発生源の問題であると主張する。

• 構造的防御： 静かに失敗する設定ベースの防御とは異なり、このシステムはアーティファクトに埋め込まれた暗号的証明を提供する。検証は、解決器の設定状態に関係なく可能である。
• 独自性： このシステムは、必須のパブリッシャー署名、暗号的レジストリ ID、必須のレジストリカウンター署名、および消費者側の暗号化強制を組み合わせる最初のシステムである。
• 拡張性： このアーキテクチャは、AI 生成発生源（モデルの使用と構成レベルを署名付き属性として追跡）およびガバナンス強制依存関係解決（インストール後の事後処理ではなく、インストール中に信頼ティアと効果権限を強制する）に拡張可能である。
• 完全性： ビルド発生源およびランタイムガバナンスと統合されると、このシステムはソースコード作成から実行までの連続的で改ざん検知可能なチェーンを生成し、ソフトウェアサプライチェーンにおける暗号学的なギャップを埋める。

著者は、このシステムがタイプスクワッティング（名前層の攻撃）やレジストリサーバーアクセスに関与する内部犯行（鍵侵害）には対処しないことを指摘している。これらには HSM や行動分析などの直交する防御策が必要である。