ATProto のアイデンティティ所有権と PDS キー管理のリスク

PDS オペレーターはユーザーのアイデンティティを完全に制御できる

現在の AT Protocol (ATProto) アーキテクチャでは、Personal Data Server (PDS) オペレーターは、ホストしているすべてのユーザーの署名キーとローテーションキーの両方を保持しています。PDS は、投稿、いいね、フォローなど、ユーザーのリポジトリへのすべてのコミットに署名するため、オペレーターは正当なアクティビティと暗号学的に区別がつかない方法でユーザーとして振る舞うことができます。

この制御は単一のアプリケーションにとどまりません。ATProto は複数のアプリ（Bluesky、Tangled、Grain、Leaflet など）の基盤として設計されているため、単一の PDS オペレーターが侵害されると、エコシステム内のすべてのアプリケーションでユーザーになりすますことができます。これにより、悪意のあるオペレーターや、令状を持つ国家主体が、正当な暗号署名を用いて、扇動的なコンテンツを投稿したり、リポジトリへの不正アクセスを許可したり、詐欺的なブログ記事を公開したりできるという、重大なセキュリティ脆弱性が生まれます。

アイデンティティの完全な消去のリスク

なりすましだけでなく、ローテーションキーを保持していることで、PDS オペレーターはユーザーを自身のアイデンティティから締め出すことができます。従来のプラットフォームのBANは単一のサービスにのみ影響します（例：X での BAN は GitHub アカウントには影響しません）。しかし、PDS オペレーターは、ATProto エコシステム全体でユーザーのアイデンティティを事実上「殺す」ことができます。ローテーションキーを変更するか、Decentralized Identifier (DID) を別の PDS に向けることで、オペレーターはユーザーが ATProto ベースのアプリケーションとやり取りする能力を永久に剥奪することができます。

データポータビリティ vs. キーの主権

データポータビリティとアイデンティティの主権には、決定的な違いがあります。ATProto は、ユーザーがリポジトリのホスティングプロバイダー (PDS) を別のサーバーに移動することを可能にしています（これは ActivityPub のような他のプロトコルで一般的なデータポータビリティの問題を解決しています）。しかし、デフォルトではキーの主権を提供していません。

ほとんどのユーザーは、キー管理が複雑であるため、主権を利便性のために放棄しています。しかし、現在のデフォルト状態では、システム全体のセキュリティは PDS オペレーターへの信頼に依存しています。もしオペレーターが侵害されると、その PDS でホストされているすべてのカウントは、統合されているすべてのアプリケーションで露出します。

緩和策と提案された変更点

ユーザーは、PDS のキーよりも優先度の高い、自己管理型のローテーションキーを実装することで、これらのリスクを緩和できます。これにより、ユーザーは、現在のオペレーターが攻撃的になった場合に、署名キーをローテーションし、DID を新しい PDS に移動させることができます。しかし、これはデフォルトの構成ではなく、標準的なクライアントのオンボーディングフローには組み込まれていません。

ATProto のセキュリティ体制を改善するために、以下の変更が推奨されます：

• Default Rotation Key Enrollment: バックアップ用のローテーションキーの登録は、アカウント作成プロセスの標準的な一部であるべきです。
• Client-Side Integration: キー管理ツールは、API レベルの関数として残るのではなく、クライアントに直接組み込まれるべきです。
• Auditability: ユーザーは、PDS が自身の代わりに何を署名したかを正確に監査できる、明確で透明な方法を持つべきです。
• Documentation: プロトコル文書は、PDS がユーザーのキーを保持していることの影響を明示的に述べるべきです。

コミュニティの視点と反論

これらのリスクに関する技術的な議論は、絶対的な主権を優先する層と、これらのリスクを可用性との許容可能なトレードオフとして捉える層との間で分断されています。

現在のモデルに対する主張

一部のコントリビューターは、この信頼モデルはウェブの他の部分の動作と一致していると主張しています。彼らは、ユーザーがすでに GitHub や Google のような中央集権的な実体に対してアイデンティティを信頼していることを指摘し、また、PDS オペレーターが攻撃的に振る舞うリスクは、第三者によるアカウント乗っ取りのリスクよりも低いと述べています。さらに、彼らは、ユーザーに独自の「uber-keys」を管理させることは、キーの紛失やバックアップがない場合に、永久的なアカウント損失につながる可能性があると主張しています。

セルフホスティングによる主張

いくつかのコミュニティメンバーは、リスクは重要度の高いユーザー（ジャーナリスト、政治家、オープンソースのメンテナーなど）にとって、セルフホスティングを通じて解決可能であると強調しています。PDS は、Raspberry Pi や Docker と SQLite を使用した小さな VM 上で低コストのハードウェア上で実行できるため、高いセキュリティを必要とする人々は、単に独自のキーを管理することができます。

代替的なアイデンティティ・モデル

一部の批評家は、 ATProto の DID spec に対するアプローチは洗練練れていないと示唆しており、マスター署名アイデンティティと、子 DID (限定的な CRUD 権限を持つ) の間の階層関係が、より安全なアーキテクチャであると提案しています。他の人々は、Farcaster の Ethereum ブロックチェーン上でのスマートコントラクトの使用を、 ATProto の現在のキーローテーションシステムと比較して、アイデンティティのリカバリーと管理のためのより堅ックな方法であると指摘しています。