DIDCommを形式化

Input | Outputは、堅実な作業基盤の設定に真剣に取り組んでいる。最近の例として、ACMのコンピュータおよび通信セキュリティのためのフラッグシップカンファレンス、CCS’24で発表された論文「What did come out of it? Analysis and improvements of DIDComm messaging（ここから何が得られたか：DidCommメッセージングの分析と改良）」に見られる、Decentralized Identifier Communication（DIDComm）の研究がある。この論文では、DIDCommの形式化を試みている。

DIDCommとは何か

この作業に没入する前に、前提を説明する。DIDCommは、今日自己主権ID（Self-Sovereign Identity：SSI）システムで使用されている主要な通信フレームワークである。DIDCommは最初、Hyperledgerコンソーシアム内のRFCで定義されたが、最近独自の仕様であるDIDComm v2を採択し、現在はDistentralized Identity Foundationによってホストされている。この新しいバージョンは、送信者と受信者の間の安全な通信ルートを確立するための柔軟なフレームワークを提供することを目的としており、すべての参加者はW3C分散型識別子（DID）で識別される。DIDの哲学に従って、DIDCommフレームワークはセキュリティを犠牲にすることなく第三者への信頼を最小化することを目指している。

DIDCommの主なユースケースでは、下図のとおり、複数のデバイスを所有している可能性のある受信者（Alice）にメッセージを送信したい送信者（Bob）が、AliceのDID文書をDID文字列（did:example: Aliceなど）から取得する。DID文書は、Aliceが所有する各デバイスの公開鍵と、各デバイスへのメッセージが辿るべきルートを指定している。またここに、Bobが自分で選んだホップを追加することもできる。

このメッセージ交換を安全に行うために、DIDCommはよく知られたJSONベースの標準を利用し、公開鍵暗号と対称鍵暗号と鍵導出アルゴリズムのいくつかの組み合わせとデジタル署名を規定している。DIDCommはSSI空間に限定されているが、だんだん需要が高まっており、さまざまな場所で広く使われるようになってきている。したがって、手遅れになる前にDIDCommが潜在的な弱点を特定し修正する一助となるために、今すぐ形式化して調査することが不可欠である。

研究内容

この研究では、DIDCommの暗号化と鍵導出スキームの組み合わせが、主張されているセキュリティ特性を達成しているかどうかを形式化によって検討する。ただし、この分析からはデジタル署名を除外している。暗号化と鍵導出の部分を分析するのはかなりの作業である。これは単純化したように見えるかもしれないが、DIDCommは、この研究の時点で、セキュリティ面で何を達成しようとしているかについて形式仕様記述を欠いていることを覚えておいてほしい。従って、 DIDCommのセキュリティ目標を形式化して捕捉することが、本作業の大部分を占めている。これを行うために、その仕様と関連する標準を研究し、PythonとJavaの主な実装を包括的にレビューし、次に説明するように、独自の改良をコーディングしている。

DIDCommメッセージングの形式的なモデルを得たら、DIDCommの暗号化モードが実際に主張されている（そして現在は形式的に記述されている）セキュリティ要件を満たしていることを証明する。その過程で、DIDCommに変更を加えなくとも簡単に解決できるようないくつかの軽微な弱点を特定する。提案された暗号化モードの組み合わせの1つでは、DIDCommは言わば単純な（ただしコーディングが容易な）アプローチに従うことを理解し、コードの単純さを維持しながら、DIDCommルートのホップあたりの計算コストとメッセージサイズコストを約2倍改善するような代替方法を提案する。

ここではまたこの形式的モデルを通じて、DIDCommが常に受信者の識別子を漏洩していることを簡潔に捕捉した。これは仕様書を読んだ後の些細な観察ではあるが、モデルはすでに受信者の識別子（または識別子以外の何か）を漏洩させるかどうかを調整できるようにキャストされている。このような任意の漏洩をモデル化する機能を備えた今、我々は、漏洩を防ぐことでDIDCommを完全にプライバシー保護とする追加のDIDComm暗号化モードを提案する立場にある。さらに、新しいモードを提案するだけでなく、本モデルによってそのモードが安全であることを証明する。

それでは、これらの内容を一つずつ検討していく。

DIDCommの形式的モデル

DIDCommが達成しようとしているものを捉えるために、CC（Constructive Cryptography）として知られる暗号モデリングフレームワークを利用する。このフレームワークでは、手元にあるプロトコル、この場合はDIDCommの理想バージョンを定義し、実際のDIDCommの定義と比較する必要がある。CCはまた、仮定した構成要素を抽象化することを可能にする。本研究では、安全な公開鍵基盤（PKI）と安全でない通信ネットワークが既に存在すると仮定する。現実の世界では、PKIは任意のDID方式であるが、ネットワーキング部分に関してはセキュリティ上の仮定をしないので、既存のどのようなネットワークでも十分である。さらに、ネットワークの理想化を漏洩関数でパラメーター化し、「すべてのメッセージ（msg）に対して、このネットワークはf（msg）を漏洩するが、それ以上は何も漏洩しない」などと言えるようにする。また、DIDCommの理想化を同様の漏洩関数でパラメーター化する。直感的には、もしある漏洩関数について、それが現実世界のDIDCommで動作しているのか理想世界のDIDCommで動作しているのかを敵対者が判断できないことを証明できるなら、これは選択された漏洩関数に対して前者が後者と同じくらい安全であることを意味する。

では、DIDCommがネットワークオブザーバーに何を漏洩すると想定しているか。これは特定の暗号化モードに依存する。主な2つのモード（anoncryptとauthcrypt）とそれらの組み合わせについては、DIDCommの仕様に記述されている。

anoncryptモードでは、送信者は受信者にその識別子を開示せず、送信者認証も保証されないが、メッセージの内容は第三者にとって機密である。このモードでは、DIDCommはメッセージ長と受信者識別子だけを第三者に漏洩することが想定される。

authcryptモードでは、送信者は関連するデータスキーム（GCMモードのAESなど）による認証済み暗号化を通じて受信者に対して認証され、メッセージの内容も第三者にとって機密となる。このモードでは、メッセージ長、送信者識別子、受信者識別子が第三者に漏洩される。

最後に、DIDCommはanoncryptとauthcryptの両方を組み合わせる方法を説明している。まず、送信するメッセージに対してauthcryptを実行し、結果に対してanoncryptを実行する。これで想定されるセキュリティは、受信者は送信者の認証を得られ、メッセージの内容は第三者に機密となるというものである。そしてこの場合、第三者オブザーバーに漏洩されるのはメッセージ長と受信者識別子のみとなる。したがって、ある意味では、これは両方のモードの最良の部分を提供していると考えられる。

一旦この理想化が実現すれば、DIDComm仕様における対称暗号と鍵交換のための具体的なアルゴリズムの選択によって決まる現実世界の定義が、今述べた理想化と区別がつかないことを証明する。つまり、現実世界のDIDCommは理想世界のDIDCommと同じセキュリティを達成していることになる。ただしここで、複合モードでは対称暗号の選択をHMAC（AES-CBC+HMAC）を使用してCBCモードでAESに制限する必要があるという点には注意が必要だ。その理由は少し微妙である。基本的に、AES-CBC+HMACはAEAD（Authenticated Encryption Scheme with Associated Data）であり、さらに鍵コミットという性質を持つ。DIDCommがAEADに提供するもう1つの代替手段はGCMモードのAESであり、これはコミットしていない。後者の結果として、敵対者は理論上さまざまな受信者をだまして異なる平文のメッセージを受け取ることを可能にする暗号文を考え出すことができることになるが、これは明らかに意図された振る舞いではない。

anoncrypt(authcrypt())の構成の効率的な代替手段

anoncryptとauthcryptの直接的な組み合わせがどのように機能するかを研究する中で、私たちはこの些かナイーブな構成に一部作業の重複があることに気づいた。すなわち、DIDCommは2つのバルク暗号化プロセスを実行している。さらに、直接構成の副作用として、基礎となる暗号とは別に、DIDCommが受信者の識別子を2回含む（暗号化する）ことがある。これは無害に見えるかもしれないが、DIDメソッドの中には1つの識別子が数百バイトを必要とする場合もあることを考えてみて欲しい。そしてこれが送信者から受信者へ至るDIDCommルートのホップごとに行われる。

代替案として、両アルゴリズムの組み合わせを提示する。ここで必要となるのはバルク暗号化1つのみで、識別子の重複はなくなる。ただし、この案は、DIDCommがビルドするJSONドラフト標準と直接互換性を持たない。しかし、これはそれでも簡単に実装可能であり（GitHubにプロトタイプを提示する）、RFCドラフトへの興味深い追加となる可能性がある。

プライバシーを完全に保護する暗号化モード

DIDCommの理想世界モデルの概要で前述したように、DIDCommの3つの操作モードは受信者の識別子を第三者に漏洩する。これはほとんどの状況、すなわち、普通のTCP/IPネットワークのようなほとんどの通信ネットワークでは問題にならないかもしれない。しかし、これは一般に「プライバシー保護」ではない。具体的に言えば、Torのような匿名化ネットワークはこれを漏洩しない。我々のモデルでは、これは想定されたネットワークに対して定義された漏洩関数によって捕捉される。TCP/IPでは多くのものが漏洩されている。Torの場合、漏洩されるのはメッセージサイズのみだ。Torの上でDIDCommを使用した場合、受信者の識別子が漏洩されるため、現実世界が理想世界と同程度に安全であると証明することはできない。

我々の提案は非常に単純である。以前のように各受信者に対して鍵導出アルゴリズムを実行するが、その結果得られた鍵で「1」ビットを暗号化するのである。欠点は、メッセージが自分宛てのものかどうかをAliceが判断するためには、鍵導出アルゴリズムを実行し、暗号化された「1」の復号を試みる必要があるということだ。もし彼女が「1」を得たならば、メッセージは事実彼女宛てである。何か別のものだった場合は、そうではないことになる。これでは手間がかかりすぎるように感じられるかもしれないが、それでも実用に足る可能性があるユースケースは存在する。例えば、ユーザーが集団で一種の匿名受信メールボックスを設定できる。受信メッセージについては、ヘッダーをダウンロードし、前述のプロセスを実行し、一致する場合にのみメッセージ全体をダウンロードする（プライバシーを高めるためにおとりのダウンロードを含めてもいいだろう）。受信箱のサイズを慎重に設定すれば、効率性とプライバシーのバランスの取れたトレードオフを提供できるかもしれない。もちろん、より高度なメソッドが存在するかもしれないが、これには非常に魅力的な点がある。DIDCommがビルドするJSON標準を介してすでに実装可能なのだ。

今後の予定

DIDCommを形式的に分析するための第一歩は踏み出され、すでにいくつかの改善策を提案している。今、それを構築し続けることはコミュニティ（もちろん私たちもその一部である）に委ねられている。

理論的貢献を超えて我々が提案する改善は、DIDCommにとって興味深いものであると信じている。効率性の向上は、より広いJSON暗号化コミュニティにも利益をもたらすだけでなく、プライバシー保護モードが有効になるユースケースもあるためだ。たとえば、匿名の資格情報を完全に匿名の方法で受信すると考えてみよう。あなたが映画のチケットを買っているだとか、とある組織のための会員資格情報を受け取っていることだとか、誰も知る必要がない。

最後に、今後の作業のために気に留めておきたい重要な点として。構成可能なモデリングフレームワークを選択したという事実は、DIDCommの暗号化モードに基づいて構築された高レベルプロトコルのその後の分析を促進させる。例えば、想定される具体的なネットワーク漏洩を定義し、この基礎作業で安全性を証明した基本的な暗号化モードを活用することで、DIDCommルーティングのセキュリティを分析することができる。

本記事の執筆に協力いただいたChristian Badertscher、Fabio Banfi、Jesus Diaz各氏に感謝する。