IOGは記事は、DIDComm gets formal」を公開し分散型識別子通信(DIDComm)に関する最新の研究について紹介しています。
DIDCommは、自己主権型アイデンティティ（SSI）システムで使用される主要な通信フレームワークであり、W3Cの分散型識別子（DID）によって識別される送信者と受信者間で安全な通信を確立するためのものです。
最新のバージョンであるDIDComm v2は、送信者と受信者間の安全な通信経路を確立することを目的としています。
研究の主な目的は、DIDCommの暗号化と鍵導出スキームが主張されているセキュリティ特性を実際に達成しているかを形式的に分析することでした。その際、デジタル署名は分析から除外し、DIDCommのセキュリティ目標を形式的に定義することに重点を置きました。また、仕様や関連する標準を詳細に調査し、PythonとJavaでの主要な実装をレビューし、独自の改善策を提案しました。
主な貢献
- DIDCommの形式的モデルの構築：Constructive Cryptography（CC）という暗号学的モデリングフレームワークを用いて、DIDCommの理想的なモデルを定義し、実際の実装と比較しました。これにより、暗号化モード（anoncrypt、authcrypt、その組み合わせ）が期待されるセキュリティ要件を満たしていることを証明しました。ただし、一部のモードでは暗号化方式を特定のものに制限する必要があることも示しました。
- 効率的な暗号化手法の提案：現在のDIDCommの暗号化モードの組み合わせが非効率であることを発見し、計算コストとメッセージサイズを各ホップあたり約2倍改善する代替手法を提案しました。この方法は、既存のJSON標準とは直接互換性がありませんが、実装は容易であり、RFCドラフトへの有益な追加となり得ます。
- 完全なプライバシー保護モードの提案：DIDCommが受信者の識別子を第三者に漏洩する問題を解決するため、新しい暗号化モードを提案しました。このモードでは、受信者はメッセージが自分宛てかどうかを確認するために鍵導出と復号を試みます。これは匿名ネットワーク（例：Tor）上でのDIDCommの使用を可能にし、プライバシー保護が必要なユースケースに適しています。
今後の展望
この研究は、DIDCommの形式的な分析の第一歩を踏み出し、効率性とプライバシーの向上につながる改善策を提示しました。これらの提案がコミュニティによって採用され、DIDCommおよび関連するJSON暗号化技術全体の発展に寄与することが期待されます。また、提案されたモデルは合成可能であるため、DIDComm上に構築された高レベルのプロトコルのさらなるセキュリティ分析を容易にします。
以下は記事「DIDComm gets formal」を翻訳したものです。
DIDCommが形式化される
2024年10月16日 IO Research 読了時間
IInput | Outputは、堅実な作業基盤の構築を非常に重視しています。その最近の例が、分散型識別子通信（DIDComm）：Decentralized Identifier Communication (DIDComm)に関する研究です。この研究は「それで何が得られたのか？DIDCommメッセージングの分析と改善：What did come out of it? Analysis and improvements of DIDComm messaging.‘」という論文を通じて行われ、今週開催されるACMのコンピュータと通信のセキュリティに関する旗艦会議であるCCS’24で発表されます。この論文では、DIDCommを形式的に検討しています。
DIDCommとは何か？
この研究に深入りする前に、一歩下がって考えてみましょう。DIDCommは、現在の自己主権型アイデンティティ（SSI）：Self-Sovereign Identity (SSI)システムで使用されている主要な通信フレームワークです。DIDCommは当初、Hyperledgerコンソーシアムでのリクエスト・フォー・コメント（RFC）を通じて定義されましたが、最近では独自の仕様であるDIDComm v2を採用し、現在は分散型アイデンティティ財団：Decentralized Identity Foundationによってホストされています。この新バージョンは、送信者と受信者（複数可）の間に安全な通信経路を確立するための柔軟なフレームワークを提供することを目指しており、すべての参加者はW3Cの分散型識別子（DID）によって識別されます。DIDの哲学に従い、DIDCommフレームワークは、セキュリティを犠牲にすることなく、第三者への信頼を最小限に抑えることを目指しています。
DIDCommの主な使用例では、以下に模式的に示されていますが、送信者（ボブ）が受信者（アリス）にメッセージを送りたいとき、アリスが複数のデバイスを所有している可能性があります。このとき、ボブはアリスのDID文字列（例：did:example:alice）からアリスのDIDドキュメントを取得します。このDIDドキュメントには、アリスが所有する各デバイスの公開鍵と、これらのデバイスに送られるメッセージが従うべきルートが指定されています。ボブはこれに自分で選んだ追加のホップを連結することもできます。
このメッセージ交換を安全に行うために、DIDCommはよく知られたJSONベースの標準を活用し、公開鍵と対称鍵の暗号化および鍵導出アルゴリズムの組み合わせ、さらにデジタル署名を指定しています。DIDCommはSSI領域に限定されていますが、他の場所でもますます関連性が高まり、広く使用されています。したがって、手遅れになる前にDIDCommを形式的に検討し、潜在的な弱点を特定して修正することが重要です。
私たちの研究は何についてか？
私たちの研究では、DIDCommの暗号化と鍵導出スキームの組み合わせが、主張されているセキュリティ特性を達成しているかどうかを形式的に検討します。ただし、デジタル署名は分析から除外します。暗号化と鍵導出の部分を分析するだけでもかなりの作業です。これは簡略化のように見えるかもしれませんが、DIDCommは（私たちの研究までの話ですが）セキュリティ上達成しようとしていることの正式な声明を欠いていることを念頭に置いてください。したがって、DIDCommのセキュリティ目標を形式的に捉えることが私たちの研究の大きな部分を占めます。そのために、私たちはその仕様と関連する標準（specification）を研究し、PythonとJavaでの主要な実装を包括的にレビューし、次に述べるように独自の改良もコーディングしました。
DIDCommのメッセージングの形式的なモデルを持てば、DIDCommの暗号化モードが実際に主張されている（そして今や形式的に述べられた）セキュリティ要件を達成していることを証明します。その過程で、DIDCommを変更することなく簡単に解決できるいくつかの小さな弱点を特定します。また、提案されている暗号化モードの組み合わせの一つで、DIDCommがやや単純な（しかしコーディングしやすい）アプローチを取っていることに気づき、コードのシンプルさを維持しながら、DIDCommルートの各ホップあたり計算とメッセージサイズのコストを約2倍改善する代替方法を提案します。
私たちの形式的なモデルを通じて、DIDCommが常に受信者の識別子を漏らすことも簡潔に捉えます。これは仕様を読めば自明な観察ですが、私たちはすでにモデルを、その受信者の識別子（またはそれに関わる他のもの）が漏れるかどうかを調節できるように構築しています。この任意の漏洩をモデル化する能力を備え、私たちはDIDCommの追加の暗号化モードを提案できる立場にあります。これにより、DIDCommはあらゆる漏洩を防ぎ、完全なプライバシー保護を実現します。さらに、新しいモードを提案するだけでなく、それらが私たちのモデルに従って安全であることも証明します。
これらの貢献を一つ一つ見ていきましょう。
DIDCommの形式モデル
DIDCommが達成すると期待されることを捉えるために、Constructive Cryptography(CC)として知られる暗号化モデリングフレームワークを活用しています。これは、対象のプロトコル – この場合はDIDComm – の理想的なバージョンを定義し、実際の現実世界のDIDCommの定義と比較することを要求します。CCはまた、いくつかの前提となる構成要素を抽象化することを可能にします。私たちの場合、安全な公開鍵インフラストラクチャ（PKI）と安全でない通信ネットワークがすでに存在すると仮定しています。現実世界では、PKIは任意のDIDメソッドであり、ネットワーキング部分については、既存の任意のネットワークで十分です。なぜなら、私たちはそれに対するセキュリティ仮定を設けていないからです。さらに、私たちはネットワークの理想化を漏洩関数でパラメータ化しています。これにより、「すべてのメッセージ（msg）に対して、このネットワークはf(msg)を漏洩させますが、それ以上は漏洩しません」といったことが言えます。また、DIDCommの理想化も同様の漏洩関数でパラメータ化しています。直感的に言えば、与えられた漏洩関数に対して、現実世界のDIDCommと理想世界のDIDCommのどちらで操作しているかを区別できる敵対者がいないことを証明できれば、前者は選択された漏洩関数に対して後者と同じくらい安全であることを意味します。
では、DIDCommがネットワークの観察者に何を漏らすことを期待するのでしょうか？これは特定の暗号化モードによります。DIDCommの仕様で説明されている主要な2つのモード（anoncryptとauthcrypt）とその組み合わせを検討します。
anoncryptモードでは、送信者は受信者に自分の識別子を明かさず、送信者の認証も保証されませんが、メッセージの内容は第三者に対して機密です。このモードでは、DIDCommはメッセージの長さと受信者の識別子だけを第三者に漏らすことを期待します。
authcryptモードでは、送信者は関連データを持つ認証付き暗号化スキーム（例えばGCMモードのAES）を通じて受信者に対して認証され、メッセージの内容も第三者に対して機密です。このモードでは、メッセージの長さ、送信者の識別子、および受信者の識別子が第三者に漏洩します。
最後に、DIDCommはanoncryptとauthcryptの両方をどのように組み合わせるかを説明します。まず、送信するメッセージに対してauthcryptを実行し、その結果に対してanoncryptを実行します。これに期待されるセキュリティは、送信者が受信者に対して認証され、メッセージの内容が第三者に対して機密であることです。しかし、この場合、メッセージの長さと受信者の識別子だけが第三者の観察者に漏洩します。つまり、ある意味で、これは両方のモードの最良の部分を提供することが期待されます。
この理想化を得たら、DIDComm仕様での対称暗号化と鍵交換の具体的なアルゴリズムの選択によって与えられる現実世界の定義が、先に述べた理想化と区別できないかどうかを証明します。要するに、はい、現実世界のDIDCommは理想世界のDIDCommと同じセキュリティを達成します。ただし、組み合わせモードでは対称暗号化の選択をHMAC付きのCBCモードのAES（AES-CBC+HMAC）に制限する必要があるという注意点があります。その理由は少し微妙です。基本的に、AES-CBC+HMACは関連データを持つ認証付き暗号化スキーム（AEAD）であり、さらに鍵コミットメントの特性を持ちます。DIDCommがAEADのために提供するもう一つの代替手段はGCMモードのAESですが、これはコミットメントではありません。後者の結果として、敵対者は理論的には異なる受信者に異なる平文メッセージを受け取らせる暗号文を作り出すことができ、これは明らかに意図された動作ではありません。
anoncrypt(authcrypt())の組み合わせに対する効率的な代替案
anoncryptとauthcryptの以前の直接的な組み合わせがどのように機能するかを研究していると、このやや単純な組み合わせが実際には作業を重複させていることに気づきます。つまり、DIDCommは2つの大規模な暗号化プロセスを実行しています。さらに、基盤となる暗号とは無関係に、直接的な組み合わせの副作用として、DIDCommは受信者の識別子を2回含めて（暗号化して）います。これは無害に思えるかもしれませんが、いくつかのDIDメソッドでは1つの識別子が数百バイトを必要とする可能性があります。そしてこれは、送信者から受信者へのDIDCommルートの各ホップごとに行われます！
私たちの代替案では、両方のアルゴリズムを統合し、一度の大規模な暗号化だけが必要で、識別子は重複しません。注意点は、私たちの提案がDIDCommが構築されているJSONドラフト標準と直接的な互換性がないことです。しかし、それでも容易に実装可能で（GitHubでプロトタイプ：prototype in GitHubを提供しています）、RFCドラフト：RFC draftへの興味深い追加となる可能性があります。
完全なプライバシー保護の暗号化モード
私たちのDIDComm理想世界モデルの前述の概要で述べたように、DIDCommの3つの動作モードは受信者の識別子を第三者に漏洩します。これはほとんどの状況、つまり通常のTCP/IPネットワークなどのほとんどの通信ネットワークでは問題ないかもしれません。しかし、これは一般的に「プライバシー保護」とは言えません。特に、Torのような匿名化ネットワークではこれを漏洩しません。私たちのモデルでは、これは仮定されたネットワークに対して定義された漏洩関数で捉えられます。TCP/IPの場合、多くのものが漏洩します。Torの場合、メッセージサイズだけです。したがって、Torの上でDIDCommを使用すると、受信者の識別子が漏洩するため、現実世界が理想世界と同じくらい安全であることを証明できません。
私たちの提案は非常にシンプルです。各受信者のために以前と同様に鍵導出アルゴリズムを実行し、その結果の鍵で「1」ビットを暗号化します。欠点は、アリスがメッセージが自分宛であるかを判断するために、鍵導出アルゴリズムを実行し、暗号化された「1」を復号しなければならないことです。もし「1」を得たら、そのメッセージは確かに彼女宛です。そうでなければ、違います。これは過度に思えるかもしれませんが、これが実用的であるユースケースが存在することに注目します。つまり、一連のユーザーが一種の匿名の受信メールボックスを設定できます。受信するメッセージについては、ヘッダーだけをダウンロードし、前述のプロセスを実行し、一致した場合にのみメッセージを完全にダウンロードすればよいのです（プライバシーを高めるためにいくつかのダミーダウンロードを含めることもあります）。慎重にサイズ設定された受信ボックスであれば、効率性とプライバシーの間で良いトレードオフを提供できます。もちろん、より高度な方法も存在するかもしれませんが、これには非常に魅力的な特性があります。それは、DIDCommが構築されているJSON標準を介してすでに実装可能であるということです！
では、次は何でしょうか？
私たちはDIDCommを形式的に分析するための第一歩を踏み出し、すでにいくつかの改善を提案しました。これからは、コミュニティ（もちろん私たちもその一員です）がそれらを基に構築を続ける番です。
私たちの理論的な貢献を超えて、提案する改善がDIDCommにとって興味深いものだと信じています。効率の向上により、より広いJSON暗号化コミュニティにも利益をもたらすだけでなく、私たちのプライバシー保護モードが可能にするユースケースのためでもあります。例えば、完全に匿名の方法で匿名のクレデンシャルを受け取ることを考えてみてください！誰もあなたがある映画のチケットを購入しているかどうか、またはある組織のメンバーシップクレデンシャルを受け取っているかどうかを知る必要はありません！
最後に、今後の研究で注意すべき重要な点があります。私たちが合成可能なモデリングフレームワークを選択したという事実は、DIDCommの暗号化モードの上に構築された高レベルのプロトコルのその後の分析を容易にします。例えば、期待される具体的なネットワーク漏洩を定義し、この基礎的な研究で安全であることを証明した基本的な暗号化モードを活用することで、DIDCommのルーティングのセキュリティを分析することができます。
この記事のサポートに感謝します：Christian Badertscher、Fabio Banfi、そしてJesus Diaz。
