Week 5 Frontier

PreviousWeek 2 さらなる暗号技術とSNARKsとSTARKs NextSpartan

Last updated 7 months ago

Week 5 Frontier

Week5では”frontier”ということで以下のマテリアルをベースにMPC、FHE、TLSNotary、ZKEmailについて学習

MPC

(Secure) Multi Party Computationのことで、複数の参加者が各々が持つ秘密情報を開示せずに、協働して計算を可能にする方法です。期末テストの答案が返ってきた際に自分の点数は開示しないけれど、友人と比較してどうか、、、ということはよくあることかと思います。現実的にはこっそり教えあうのですが、MPCがあることでどちらが上であるか、や仲良しグループの平均点を知ることができることになります。

MPCの起源は1980年代からシャミアの秘密分散やGarbled circuitsなどからスタートしており、今日に至るまで研究が進んでいます。

最近のユースケースとしては以下のようなものが例として挙げられます。

機械学習のモデル作成時にデータ提供者が自らの原データを開示せず、学習（計算）を実行する
暗号資産管理で秘密鍵の生成を分散して管理する

実際の例としてGarbled Circuitsを見ていきます。Garbled circuitsでは 1 out of 2 と呼ばれるMPCの先駆けで、

Obvlious Transfer (紛失通信、OT)を用いる；OTはSenderとReciever間の情報のやりとりで、⓵SenderはRecieverにメッセージ $m_0$ , $m_1$ を暗号化したうえで送信するが、②Receiverは予め決めていた $b \in \{0,1\}$ について $m_b$ のみ内容を確認でき(つまり $m_{1-b}$ をReceiverはわからない）、③Senderは $b$ について知ることはない、というものになる

FHE

完全準同型暗号とは、一定の計算処理と暗号化・復号化の順序を交換可能になる手法です。例えば、原データで足し算する場合に、一度暗号化して、足し算に相当する処理を行ってから復号化すると元の足し算と結果が同一になる

（homo-morphism = 構造を保つ）

暗号化に当たっては格子暗号が用いられており、格子暗号の計算困難性を背景にしています。確率分布を用いたサンプリングと丸目誤差を伴う計算を行う点が過去のweekで取り扱った暗号手法と大きく異なる点です。この誤差が積もってくると意図した複合が困難になるため演算が可能な回数に応じてsome what, 完全、など分類されます。完全準同型暗号は誤差が発生しないのではなく、蓄積された誤差についてはブートストラップを行いクリアにします。

格子の一番単純な例はベクトル空間の基底で、二次元なら碁盤の目として表現ができます。一般的にはその碁盤の目を線形独立な基底Bを用いて以下のようなLとして格子を表現します。

${B}={b_1,b_2, \dots, b_n } \subset \mathbb{Z}^n,$

$L= {x_1 b_1 +x_2 b_b + \dots + x_n b_b | x_1,x_2,\dots x_n \in \mathbb{Z} }$

Lattice Probremsと呼ばれる以下の問題は指数時間の計算時間が必要と呼ばれる問題であり、この計算時間が格子暗号の安全性の背景となる。

最少ベクトル問題：Lの元で原点0に最も近い点を求めること
最近ベクトル問題：与えられた点に最も近い格子上の点を求めること

TLS Notary

現代のデジタル社会では、オンラインデータの真正性証明とプライバシー保護の両立が大きな課題となっています。TLS NotaryはWebサイトから受け取ったデータの一部を第三者に証明するためのオープンソースのプロトコルです。この分野はzkTLSまたはWeb Proofとも呼ばれています。TLS Notaryは従来のTLS（Transport Layer Security）プロトコルを拡張し、MPC（Multi-Party Computation）を組み合わせることで、プライバシーを保護しながらデータの真正性を保証します。

TLS Notaryの主な参加者と役割は下記になります。

Server: TLS接続を通じてクライアント（Prover）にデータを提供する役割
Prover（証明者）: Serverと通信するクライアントであり、データの真正性を証明したい人
Verifier（検証者）: データの真正性を確認したい人
Notary （公証人）: 中立的な第三者として、プロセスを支援する役割

TLS Notaryの技術的特徴

MPCの活用

TLS NotaryはMPCを用いて、クライアントであるProverとNotaryが協力してServerとのTLS接続を確立します。この過程で以下の特徴があります。

セッションキーの分散管理: ProverとNotaryはTLSセッションキーを分割して保持します。これにより、どちらも単独でデータを復号化できません。
ブラインド署名: NotaryはProverのデータを見ることなく、その真正性に署名できます。
透過性: Serverからはクライアント（Prover）との通常のTLS接続に見えるため、Server側を変更することなくTLS Notaryを導入することが可能です。

選択的開示

Proverは、Serverから受け取ったデータのうち、証明したい部分のみを選択的に開示でき、必要最小限の情報のみを公開することを可能にします。

コミットメントスキーム

TLS Notaryは軽量なコミットメントスキームを採用しています。これにより、大量のデータを効率的に処理し、後で選択的に開示することが可能になります。

TLS Notaryプロトコルの流れ

MPC-TLS接続: ProverとNotaryがMPCを使ってServerとのTLS接続を確立します。
データ取得: ProverがServerからデータを取得します。この際、ServerはProverとの通常のTLS通信と区別がつきません。
コミットメント生成: Proverがデータのコミットメントを作成し、Notaryに送信します。
署名: Notaryがコミットメントにブラインド署名を行います。
選択的開示: Proverが証明したい部分を選択し、Verifierに提示します。
検証: VerifierがNotaryの署名を確認し、提示されたデータの真正性を検証します。

TLS Notaryのユースケース

TLS Notaryで証明できることとしては下記のような例があります。

Web上の特定のアカウントにアクセスできる
Webサイトが特定の日付に特定のコンテンツを表示した
自分自身の個人情報（住所、生年月日、健康状態など）を保有している
ログイン認証情報や機密の財務情報を明かすことなく、オンラインバンキングを使用して送金を受け取った
誰かからプライベートメッセージを受け取った
オンラインで商品を購入した
アプリの使用がブロックされた
専門資格を取得した

ZKEmail

ZKEmailは、ゼロ知識証明（Zero-Knowledge Proofs, ZKPs）を利用し、電子メールのやり取りを通じて暗号資産の送受信やWebサイトへのログイン等を可能にするためのツールやアプリケーション群を開発しているプロジェクトです。ゼロ知識証明の技術を利用することにより、特定のデータを秘匿しながらメールの検証を行うことが可能になります。具体的なリポジトリをいくつか紹介します。

特定のデータをマスキングしながら電子メールの署名を匿名で検証できます。特定のドメインやメール本文の特定のテキストに基づく検証が可能です。

そもそもRegexとは何かから説明します。Regexは正規表現（せいきひょうげん、英: Regular Expression、略してregexまたはregexp）と訳します。文字列のパターンを表現するための特別な記法やルールのことです。主にプログラミングやテキスト処理、データ検証などで用いられ、特定の文字列を検索、置換、抽出する際に非常に便利です。

ZK Regexは、Circomというコンパイラを用いた正規表現の検証ライブラリです。このライブラリはメール検証に用いられるだけでなく、データの一部を秘匿しつつ条件に一致するかどうかを判断できます。

このサービスに登録していないメールアドレスへも、トークンやNFTを送信できます。このため、このサービスはエアドロップを行う際に有用です。

送信するメールは、通常、DKIM プロトコルに従ってメールドメインサーバーによって管理される秘密キーを使用して署名されます。この署名は、メールのヘッダーセクションに含まれます。 Email Walletは、メールの DKIM 署名を検証して、メールがユーザーによって送信され、内容が偽造されていないことを確認します。チェーン上で直接署名を検証する代わりに、署名の zk 証明が作成され、チェーン上で検証される仕組みです。