公開鍵暗号の中核的課題に対処するa16zの3つの望ましいソリューション

出典：Noemi Glaeser, a16z crypto

公開鍵暗号では、暗号化鍵（公開鍵など）を特定のID（特定の個人や組織など）に正しく関連付けるという課題が常にありました。例えば特定の個人や組織)に正しく関連付けるという課題があった。この問題の鍵は、ID と公開鍵の関係を示す公開された一貫性のある方法を持つことで、誰もが自信を持ってこれらの公開鍵を使用して情報を暗号化できるようにすることです。

このような明確な関係がないと、誰かが特定の公開鍵が誰のものか判断できない可能性があり、暗号化された情報を間違った人に送ってしまい、情報漏えいやその他の深刻な結果につながる可能性があります。Web3では、この問題はまだ存在している。

上記の問題には、公開鍵ディレクトリ、IDベース暗号化（IBE）、登録ベース暗号化（RBE）という3つの解決策があります。これら3つのアプローチには、匿名性、双方向性、効率性の点でそれぞれ利点がある。例えば、IBEは強固な信頼基盤を必要とするが、匿名性と効率性の点ではIBEの方が優れているケースもある。本稿の目的は、ブロックチェーン上でこれら3つのアプローチを探求し、その長所と短所を比較することである。

3つのアプローチ

一般的に、暗号鍵とID情報を関連付ける一般的なアプローチは、公開鍵基盤（PKI）を使用することであり、その中核となるコンポーネントは公開鍵カタログである。このアプローチでは、メッセージを送信する人は、暗号化されたメッセージを送信するために、信頼できるサードパーティ（すなわち、このディレクトリを維持する機関、通常は認証局）と対話する必要がある。

しかし、Web2環境では、この公開鍵ディレクトリを維持するのはコストがかかり、面倒です。さらに、ユーザは認証局による潜在的な悪用のリスクにさらされます。

公開鍵基盤(PKI)の問題を解決するために、暗号学者によっていくつかの代替案が提案されてきました。1984年、Adi Shamir 氏は、当事者の識別子（電話番号、電子メール、ENSドメイン名など）を公開鍵として直接使用できるIdentity-Based Encryption（IBE）を提案した。このアプローチでは、公開鍵カタログを維持する必要はなくなりますが、秘密鍵を生成するために信頼できる第三者（鍵生成者）に頼らなければならないという新たな問題が生じました。

最初の実用的なIBE構成は、2001年にDan Boneh氏とMatthew Franklin氏によって提案されましたが、この技術は広く採用されることはなく、主に企業や政府の展開環境のような閉じたエコシステムで使用されてきました。IBEが広く使われていない理由のひとつは、IBEが強い信頼、つまりサードパーティが生成した鍵の信頼に依存していることだろう。

しかし、本稿で後述するように、この信頼の問題は、信頼された複数（すなわち、参加者グループの定足数）に依存することで解決でき、ブロックチェーン技術で容易に実現できる。

長所と短所

これらの暗号方式を比較する際には、考慮すべきさまざまな要素があり、私はこれについて2つの前提を置いています：

ユーザーは自分の鍵を更新したり失効したりしない：これはつまり、各ユーザーの鍵は固定されており、変更されないと議論では仮定していることを意味します。

スマートコントラクトは、オフチェーンデータアベイラビリティサービス（DAS）やブロブデータを使用しない：つまり、スマートコントラクトはオンチェーンデータのみに依存し、オフチェーンデータサービスや追加のデータストレージは存在しないと仮定される。

公開キーディレクトリ

誰でもスマートコントラクトを呼び出すことで、他の誰かに占有されていないID、別名 (id, pk) エントリをオンチェーンディレクトリに追加することができます。

非中央集権型PKI とは、誰にも占有されていないIDの使用によるPKIの使用を指します。スマートコントラクトを通じて、アイデンティティ（ID）とそれに対応する公開鍵のカタログを維持することである。このディレクトリは公開されており、中央集権的なサードパーティに依存しない。例えば、ドメイン名（つまりID）と、ドメイン名が解決するアドレス（およびそれらのアドレスのトランザクションから公開鍵を導き出すことができる）を含む関連するメタデータとのマッピングを維持するENSを考えてみよう。分散型PKIの機能は比較的単純で、スマートコントラクトは単に各IDに対応する公開鍵のリストを保持するだけである。

ユーザーがIDを登録したい場合、まず鍵ペア（公開鍵と秘密鍵）を生成するか、すでに生成された鍵ペアを使用する必要がある。もし登録されていなければ、スマートコントラクトはこのIDと公開鍵をディレクトリに追加する。登録が完了すると、誰でもスマート・コントラクトに、あるIDに対応する公開鍵を要求して、そのユーザーに送信するメッセージを暗号化することができる。 送信者が以前にそのユーザー宛のメッセージを暗号化したことがあり、すでにそのユーザーの公開鍵を持っている場合は、スマート・コントラクトに再度公開鍵を要求する必要はない。公開鍵があれば、送信者はそれを使って通常通りメッセージを暗号化し、暗号化されたメッセージを受信者に送ることができる。受信者は対応する秘密鍵を使ってメッセージを復号化し、元のメッセージを復元する。

この方法の長所と短所を見てみましょう。

長所短所非対話的な復号化：復号化プロセスは他の当事者とのやり取りを必要とせず、復号化者は単独で復号化を完了できる。簡潔でない：システムが簡潔でない場合がある。透明性(Transparency)：システムはある意味で透明である。対話型暗号化(Interactive encryption) : 暗号化プロセスには、他の当事者との対話が必要な場合があり、複雑さが増す。任意のID：ユーザは、特定の形式や規則に制約されることなく、任意のIDを自由に選択・使用できる。送信者の非匿名性： 送信者の身元は、システム内で完全に匿名であるとは限りません。

IDベースの暗号化（IBE）

ユーザーのIDは公開鍵で表されます。これは、公開鍵が暗号化に使用されるだけでなく、ユーザーの一意の識別子としても機能することを意味します。しかし、このアプローチでは、鍵の生成と配布を担当する1つ以上の信頼できるサードパーティに依存する必要がある。さらに、これらのサードパーティはシステムの寿命を通じてマスターキーを保持する必要があり、これは場合によっては復号化やその他の重要な操作に使用される可能性がある。

IBEシステムでは、ユーザーは公開鍵と秘密鍵のペアを生成しません。従来の暗号システムのように、公開鍵と秘密鍵のペアを自分で生成することはない。その代わり、ユーザーは信頼できる鍵生成者に登録する必要がある。鍵生成者はマスター鍵のペア（マスター秘密鍵mskとマスター公開鍵mpkを含む）を持つ。ユーザがIDを提供すると、鍵生成者はマスター秘密鍵mskとユーザのIDを使用して、そのユーザに固有の秘密鍵を計算する。生成された秘密鍵は、通常鍵交換プロトコルを使って確立される安全なチャネルを通してユーザーに配信される必要がある。

送信者にとって、IBEシステムは暗号化プロセスを簡素化します。送信者は鍵ジェネレーターのマスター公開鍵（mpk）を一度ダウンロードするだけでよく、その後はそのIDを使ってメッセージを暗号化できる。受信者にとっても、復号化は簡単だ。登録ユーザーは、鍵ジェネレーターから送られた秘密鍵を使って、受信した暗号文を復号することができる。

鍵生成器のマスター秘密鍵(msk)は、システム運用中に継続的に新しいユーザー秘密鍵を生成する必要があるため、長期間保持する必要がある。これは、信頼されたセットアップ中に生成され、セットアップ完了後に破棄されるSNARKシステムとは異なる。一方IBEシステムでは、SNARKのように初期化後にマスター秘密鍵を削除することはできない。

マスター秘密鍵(msk)が適切に保存されていても、各登録ユーザーは鍵生成者が自分のメッセージを読まないことを信頼する必要がある。なぜなら、鍵生成者は常にユーザーの秘密鍵のコピーを保持したり、マスター秘密鍵を使ってユーザーの秘密鍵を再計算したりできるからである。

鍵生成者が、ほとんどのメッセージは復号できるが、 鍵生成者が設定した特定のメッセージは復号できないような、 欠陥のある、あるいは制限された秘密鍵をユーザーに与えることも 可能です。これは、鍵生成者がユーザの復号能力を操作する能力を持っていることを意味し、 その結果、ユーザの通信をある程度制御したり制限したりすることができます。

長所 短所 一定/最小限のオンチェーンストレージ：ブロックチェーン上のシステムが必要とするストレージの量は小さいか一定であり、時間の経過とともに増加することはない。強い信頼の前提：システムは1つ以上の信頼できるサードパーティに依存しているため、これらのサードパーティに対する強い信頼が必要である。これらのサードパーティが危険にさらされたり信頼できなかったりすると、システムの安全性が損なわれる。非対話型暗号化：暗号化プロセスは他の当事者とのやり取りを必要とせず、送信者は単独で暗号化を完了できる。送信者の匿名性：プライバシー保護のため、送信者の身元を匿名にすることができる。任意のID：特定の形式やルールに縛られることなく、ユーザーが自由にIDを選択・使用することができます。

登録ベースの暗号化（RBE）

IBEと同様、このシステムでは、ユーザーのID（電子メールアドレスや電話番号など）がそのまま公開鍵として機能します。しかし、IBEとは異なり、このシステムはもはや、鍵を管理するために信頼できるサードパーティやクォーラムの集合に依存していない。その代わり、この信頼できるサードパーティは、キー・キュレーターに取って代わられる。

このセクションでは、RBEを構築する効率的な方法について説明する。私が知る限り、これは他の実用的なRBE構築と比較して大きな利点があり、格子ベースではなくペアリングベースであるため、ブロックチェーン上に展開することができるからだ。

RBEシステムでは、各ユーザーが自分自身の鍵（ペア）を生成します。RBEシステムでは、各ユーザーが自分自身の鍵ペア（公開鍵と秘密鍵の両方）を生成する。ユーザーはまた、秘密鍵と共通参照文字列（CRS）に基づいて、いくつかの更新値（図ではaというラベル）を計算する必要があります。これらの更新値は、システム内でのさらなる操作に使用される。共通参照文字列(CRS)の存在は、システムが完全に信頼されないように設定されていないことを意味する。ただし、CRS生成プロセスでは、べき乗（powers of  tau）と呼ばれる構成法を使用する。この構成法は、チェーンの複数の参加者が共同で計算することができる。少なくとも一人の参加者が正直である限り、CRSは安全である。

スマートコントラクトは、バケットにグループ化され、システムに登録する際にID、公開鍵、更新値をスマートコントラクトに送信する必要がある、予想されるユーザー数Nに対して設定される。スマートコントラクトは、前述のパブリック参照文字列（CRS）とは異なるパブリックパラメータppのセットを保持する。ppは、システムに登録されている全ユーザーの公開鍵を簡潔にまとめたものと理解できる。スマート・コントラクトは、ユーザーから登録要求を受け取ると、更新された値をチェックし、その値が正しいことを検証する。検証されると、スマート・コントラクトはユーザーの公開鍵をppの適切なバケットに掛け合わせる。このステップは、その後の操作のために、新しいユーザーの公開鍵をシステムの公開パラメータセットに含めることと同じです。

登録ベースの暗号化(RBE)システムでは、ユーザはメッセージの復号に役立つ情報をローカルに保持する必要があります。この情報は、新しいユーザーが自分と同じグループに登録したときに更新する必要がある。ユーザーは自分でブロックチェーンを監視してこの情報を手動で更新するか、スマートコントラクトが最近登録されたユーザーに関する情報を提供し、ユーザーは定期的にこれらの更新を取得して、復号化されたメッセージを最新の状態に保つことができる。

このシステムでは、送信者は2つのことだけを行う必要があります：

共通参照文字列（CRS）をダウンロードする：これは一度だけダウンロードする必要があり、その後再び更新する必要はありません。

パブリックパラメータのダウンロード：送信者は時折、最新のパブリックパラメータをダウンロードする必要があります。送信者にとっては、受信者の公開鍵が見つかる限り、毎回最新版をダウンロードしなくても、これらの公開パラメータに受信者の公開鍵が含まれていることが重要です。

その後、送信者はダウンロードしたCRS、公開パラメータ、受信者のID IDを使ってメッセージを暗号化し、受信者に送信する。つまり、送信者はデータを頻繁に更新する必要はなく、受信者の公開鍵が公開パラメータにあることを確認するだけでよい。

ユーザーが暗号化されたメッセージを受信すると、まずローカルに保存されている補助情報をチェックして、条件に合致する値（例えば、ある検証チェックをパスした値）があるかどうかを確認します。条件に合致する値がローカルに見つからない場合は、スマートコントラクトから最新の更新情報を取得する必要があることを意味します。ユーザーがセカンダリーメッセージに適した値を見つけたら、この値と秘密鍵を使って受信した暗号文を復号化し、元のメッセージを復元することができる。

明らかに、このソリューションは他の2つよりも複雑です。

しかし、公開鍵カタログよりも少ないオンチェーンストレージで済み、IBEの強い信頼の仮定を避けることができます。

パラメータの単純性：

• オンチェーンに保存されるパラメータのサイズは、ユーザー数に対して準線形であり、公開鍵ディレクトリが必要とするストレージ量（線形）よりもはるかに小さい。ディレクトリが必要とするストレージ量ははるかに少ない（線形成長）が、それでも定数ではないため、この点でIBE（Identity Based Encryption）システムに劣る。

双方向性を持つ暗号化:

• メッセージを送信するとき、送信者はターゲットが含まれる公開パラメーターのコピーを必要とします。ターゲットとなる受信者を含む公開パラメータのコピーが必要です。つまり、送信者は、受信者が登録された後のある時点でこれらのパラメータを更新する必要がありますが、1回の更新で複数の受信者のキーが含まれる可能性があるため、受信者ごとに個別に更新する必要はありません。全体として、メッセージ送信はIBEよりもインタラクティブだが、公開鍵カタログを使うよりはそうではない。

双方向性のある復号化:

• 暗号化と同様に、受信者は、暗号化に使用されたものと同様の公開パラメータバージョンのコピーが必要です。補助情報と一致させるために、暗号化に使用される公開パラメータのバージョンに類似した公開パラメータのコピーを受信者は必要とします。新しいユーザがグループに登録されると、公開パラメータと補助情報は、暗号化に使用された公開パラメータのバージョンに対応する値で暗号文を復号できるように更新される。ユーザは、復号化に失敗しない限り、毎回すぐに補助情報を更新するのではなく、定期的に補助情報を更新してもらうことを選択できる。公開パラメータの更新とは異なり、補助情報の更新をより頻繁に取得しても、プライベート情報が損なわれることはありません。

送信者の匿名性:

• 公開鍵カタログの場合と同様に、送信者は（復号に失敗しない限りは）独立して受信者に関連する特定の情報を調べる必要なく、（最新のパラメータを持っている限り）メッセージを独自に暗号化することができます。送信者がチェーンから情報を読み取る必要がある場合、その情報は意図された受信者には無関係です（送信者がパラメータの特定のグループだけを要求している場合は別ですが、その場合は情報の一部がわかってしまうかもしれません）。

透明性:

• システムを設定するには、信頼設定（分散または外部で管理されるかもしれません）を通じて設定する必要があります。外部で管理されるかもしれません）を通じてシステムをセットアップし、修正されたCRS（共通参照文字列）を出力する必要がありますが、セットアップが完了すれば、もはや信頼できる第三者や仲裁グループには依存しません。調整役の第三者（スマート・コントラクト）に依存しているが、このシステムは完全に透過的であり、誰でも調整役として行動したり、状態遷移を検証することで正当に実行されているかどうかをチェックできる（これがスマート・コントラクトとして実装できる理由である）。さらに、ユーザーは、自分自身や他の人がシステムに登録されているかどうかを確認するために、（非）メンバーシップの簡潔な証明を求めることができる。これはIBEシステムとは対照的で、信頼できる第三者が復号鍵を秘密裏に漏洩していないこと（例えば、秘密のコピーを保存したり、誰かに漏らしたりしていないこと）を証明してもらうのは難しい。対照的に、公開鍵カタログは完全に透明です。

IDの制限されたセット:

• ここにRBEの基本的な構成が描かれています。.IDが属するグループ分けを透過的に決定するためには、IDは共通の決定論的な順序を持たなければならない。電話番号は単純に並べることができるが、任意の文字列を並べるのは非常に複雑で、不可能な場合もある。これは、そのようなマッピングを計算する別のコントラクトを提供するか、後続の研究で提案されているカッコーハッシングアプローチを使用することで軽減できます。

受信者の匿名性：

• このアプローチでは、受信者の身元を明らかにしない暗号文を許可します。の身元を明かすことはありません。