kenmaro です。
秘密計算、特に準同型暗号のことについて記事を書いています。
秘密計算エンジニアとして得た全ての知見をまとめた記事はこちら。
https://qiita.com/kenmaro/items/74c3147ccb8c7ce7c60c
これから準同型暗号について勉強したいリサーチャー、エンジニアの方へのロードマップはこちら。
https://qiita.com/kenmaro/items/f2d4fb84833c308a4d29
今話題のゼロ知識証明について解説した記事はこちら。
https://qiita.com/kenmaro/items/d968375793fe754575fe
概要
今回は、準同型暗号の研究開発で有名なフランスのスタートアップ、
ZamaAI https://www.zama.ai/
のトップリサーチャーである Nigel Smartさんの書かれたブログ
について、自分なりに解釈や勉強をしながらまとめたいと思います。
内容は、FHEを実際の（複雑な）システムにどう「インフラとして」応用するか、ということです。
FHEを構成する（例えば）格子暗号において、単なる公開鍵暗号としての用途ではなく、
システム全体のセキュリティーを守るためのインフラとして使うという観点で、どういうことを考えればいいかということがまとめられています。
この「インフラとして」使う、というところは、最初はピンとこないかもしれないですが、例えばherumi さんの
のこの記事などをしっかりと読むことをお勧めします。
忙しい人のためのまとめ
- システムで考えられる登場人物や、彼らが実行可能な攻撃について考えてみるよ
- 登場人物はアリス（暗号を作って送信する人）、ボブ（暗号を受け取って復号する人）、イブ（悪意を持ったハッカー）だよ
- FHEを搭載したシステムを考えると、さらに登場人物が増えて複雑になるよ（チャーリー：暗号状態で計算を実行する人）
- 各主人公は悪意を持つ（つまりイブと結託する）可能性があるよ
- アリスが悪意を持った時の考えられる攻撃と対策を考えるよ
- ボブが悪意を持った時の考えられる攻撃と対策を考えるよ
- チャーリーが悪意を持った時の考えられる攻撃と対策を考えるよ
背景
データの安全を守る様々なプロトコル
現在私たちが何気なく使っているウェブブラウザにおいてみても、
裏ではTLSによって通信のデータは暗号化されています。
悪意を持った第三者に様々なデータ（たとえばクレジットカードの番号とか、パスワードとか）が盗まれないよう、
いろいろな暗号スイートを使ってプロトコルが組まれています。
例えば、
- AEAD（認証付き暗号） がTLSでは使用され、暗号が途中で改竄されていないか検証され、
- 共通鍵のコンセンサス(鍵をお互いに共有する行為のこと）はRSAなどのDH（鍵共有プロトコル）で行われ、
- その公開鍵はさらにRSAの署名で作られた証明書に含まれている
ように、いろいろな要素が絡まって既存のセキュリティは達成されています。
システムの登場人物
基本的な登場人物は
- アリス（暗号を作って送信する人）
- ボブ（暗号を受け取って復号する人）
であり、彼らのデータを盗もうとする人として
- イブ（悪意を持ったハッカー）
を説明することが多いですが、実際のシステムでは
アリス、ボブ、イブ（間の攻撃者）というように単純化したシナリオだけではなく、
たくさんのアリス、たくさんのボブを考える必要があります。
さらにもしかするとアリスかボブはイブによってコントロールされているかもしれないというシナリオも当然考えられます。
したがって、実際のシステムではこれらの可能性を考慮したプロトコルを実装し、
本当にデータをやりとりしたい本物のアリスとボブに対して、安全に、また認証付きでデータを送ることが求められています。
FHEを含んだシステム
さて、上の例ではアリスがボブに対して暗号を送信したいというシステムでの話でしたが、
FHE（もしくはHE）を含んだシステムの場合、登場人物が増えることになります。
具体的には一人増えて登場人物は４人になります。
- アリス
- ボブ
- チャーリー（計算を実行する人）
- イブ
FHEを含んだシステムでは、暗号に対する計算を行うサーバが登場し、そのサーバがチャーリーという名前で登場されています。
複雑になったシナリオ
いろいろと考えてみます。
まずチャーリーに悪意はないのか、きちんと計算を実行しているかということ。
また、ボブは秘密鍵を持っているので、チャーリーと結託すればチャーリーが入力である暗号xを復号できるということ。
さらに、たくさんアリスがいた場合、アリスの中に悪意のあるアリスがいないか。
さらに、アリスとチャーリーに悪意がないとしても、ボブに悪意があればボブがxの暗号文を取得してxを復号できる可能性があるということ。
たくさん考慮することがあることがわかると思います。
しかし大事なのは、一貫してやりたいことは、
アリスのインプットに対して関数Fを施したいことと、登場人物の中に悪意のある人が混ざっているかどうかを検証すること
です。
これから各登場人物について可能な攻撃と、対処方法について書いてみます。
悪意を持ったアリス
悪意を持ったアリスを考えてみます、というより、アリスの正当性がわからないという仮定を置きます。
アリスからの暗号文の正当性問題
アリスの正当性がわからない（つまりアリスに悪意があるかわからないということ）ので、
アリスからの暗号文が、正しい暗号化をされている有効な暗号化どうか検証しなくてはわからなくなります。
アリスに悪意があれば、暗号文に見せかけたフェイクデータをシステムに投入してシステムを妨害してくることが考えられるわけです。
対策
対処法として、ゼロ知識証明を使うことで実証します。
アリスが正しい暗号化プロトコルに準拠したことと、
アリスが何を暗号化したかをきちんと知っているかということ（たとえば他の暗号をコピーしたものを使っていないかなど）
はゼロ知識証明を使うことで実証できます。これにより、
アリスが正しい暗号化プロトコルに準拠したかどうか、つまり暗号文が正当に作られたものか
を検証してシステムを守ることができます。
アリスが意図的に暗号文のノイズを選ぶ問題
さらに気をつけることがあります、これは格子暗号などに特有の話です。
FHEでは暗号文を作る時に、ノイズを足す必要があり、そのノイズは暗号スキームに則った分布から選ばれる必要があります。
このノイズがどう選ばれる必要があるのか、そもそもなぜ足されなければならないかなどは、格子暗号の理論部分になりますので、別記事をお読みいただければと思います。
ここで問題になるのは、ノイズがアリスによって意図的にノイズ分布の特定の場所から選ばれていないか、ということです。
対策
暗号に欠かせないセキュリティ分析において、
通常であればノイズ付きの暗号はアベレージケースの（確率的に扱われる部分は期待値を使って）セキュリティ分析を行いますが、
この意図的なノイズ付与を加味することにより、ワーストケースのセキュリティ分析（確率分布から考えられる一番最悪なケースの分析）が必要になります。これは結局のところシステムを考える時には実用的にはワーストケースのセキュリティ分析が十分になされていることが必要になってくるということです。
防げないと考えられる攻撃
この際、一つだけ防ぎようのない攻撃があります。
それはアリスが自分の入力について嘘をつくことです。アリスが自分のデータを虚偽入力して、きちんとした手順で暗号化した場合、中身の平文が虚偽の無い入力を直接確かめる術はないのです。（当たり前ですが、第三者は暗号の中身を除くことができません。）
例えば複数のアリスの給与の合計を計算するプロトコルにおいて、一人のアリスが嘘の給料情報を入力することについては防ぐことができません。
一つ改善が可能なのは、アリスの入力データが第三者のデータとリンクされていている場合です。
例えばアリスの給与インプットが、会社側（給与明細を発行した側）の数字と一致しているかの検証は、ゼロ知識証明を用いることで検証することが可能になります。
悪意を持ったボブ
ボブは暗号の復号者として秘密鍵を持っているので、悪意を持つと厄介なことになります。（当たり前な気もしますが、大事なポイントです。）
ボブのSingle Point of Failure 問題
ボブは秘密鍵を持っているただ一人の登場人物なので、Single Point of Failure と呼ばれます。
この一点を狙えばシステムを破れる、というような意味です。
対策
最も一般的なアプローチは閾値型のプロトコルを用いることになります。FHEを構成する暗号に対しても閾値型の構成を組むことができます。
例えば、ボブを５人に増やし、全員の部分復号されたデータを集めることで初めて本当の復号ができる、というような構成です。
複数人のボブに復号処理を分散することで、
- 鍵の漏洩のリスクを下げる
- ボブが悪意を持ってみてはいけない暗号文を勝手に復号することを防ぐ
効果が期待できます。
ボブがきちんと復号しているか問題
２つ目は、ボブが本物の暗号を本物の平文にきちんと復号したか、ということです。
例えばボブは悪意を持って、暗号とは全く関係のない平文をあたかも復号した結果のように見せかける可能性があります。
対策
これについてもゼロ知識証明を用いることで対策が可能です。
秘匿したい秘密鍵に対して、暗号文と平文がきちんと対応していることを証明する時にゼロ知識証明を使用できます。
悪意を持ったチャーリー
さて、計算を暗号状態で実行するチャーリーについて考察してみます。
チャーリーがきちんと計算したか問題
実は計算を行うチャーリーが本物のチャーリーであるかどうか、
つまりきちんとするべき計算をしているかということを証明すること、が一番難しく、一番研究されていることです。
対策するための仮説
まず前提として簡単な仮説を２つ持つ必要があります。
仮説① 暗号に対して実行する計算アルゴリズムは公開されている
１つ目は、F(x)のFは公開情報であるということです。
ニューラルネットワークのモデルを用いた推論を例に挙げると、これはモデルが公開情報ということを意味するわけではありません。
F(x,y）として、xを入力、yをモデルの重み情報だとすると、公開しているのはモデルのアーキテクチャ（トポロジー）の部分であり、 重み情報そのものは秘匿されているというシナリオです。
ここで、チャーリーへの入力と出力つまりEnc(x)とEnc(y）は公開情報だとします。（y = F(x))
このときに検証したいのは、チャーリーが「既知」のオペレーションFをEnc(x)に施してEnc(y)を得たかどうかということです。
仮説② 暗号に対して実行する計算は決定的である
また、２つ目の仮説は、暗号への演算Fは決定的であるということです。
決定的という意味は、同じ入力を入れれば常に同じ出力が出てくる、ということです。
つまり、Fは確率に基づいた演算などではなく、例えば掛け算や足し算など、答えが一意に決まる関数である必要があります。
これらの仮説を仮定すれば、以下の対策が可能となります。
対策① Verifiable Computation
これはVerifiable Computation によって実証することができます。
VCはゼロ知識証明に近いですが、それよりも簡易的です。なぜなら、VCでは秘密にする情報は何もないからです。
ただしVCは実用的に高速に動くものではなく、実際はFHEを用いた手法が他のVC手法より効率的です（FHEを使うと本末転倒になるので使えない）。
可能性のある技術としてはブロックチェーンに用いられている START/SNARK/Bullet-Proof ですが、まだ研究されなければならない項目は多数（準備万端とは言えない）ようです。
対策② チャーリーも複数人にする
現在一番手っ取り早くこの検証を行うには、チャーリーについてもコピーして結果について多数決を行うのが良いでしょう。
Fは決定的である（PBSであっても出てくる結果は決定的）という仮定の元から、多数決をとって一番多く得られた結果を採用すればよいことになります。
まとめ
サマリとして、FHEを単なるシンプルな構成のシステムで使われる暗号プロトコルだと見るのは狭い視野である。
RSAがシンプルでない（実用的な）システムで様々なプロトコルを使ってセキュリティを実現しているということと同様に、
FHEも他の暗号プリミティブと協力して全体セキュリティを考慮したシステム作りの、一つのプリミティブだという見方をするべき。
ということでしょうか。
今回は、ZamaAIのトップリサーチャーのブログから学ぶ、
FHE込みのシステム構成で考えられるセキュリティ対策とその指針についてまとめてみました。
ゼロ知識証明や、閾値法による分散化、Verifiable Computation など、
いろいろと理解が難しそうな言葉が対策のところに並びましたが、大事なデータを守るためのセキュリティですから、丁寧に理解していきたいと思います。
いろいろな技術の組み合わせで現在のTLSなどのプロトコルがシステムとして成り立っているのと同様に、
FHE込みのシステムについても実運用に耐えうるシステムをもっと工夫して考えていきたいですね。
このブログには登場しませんでしたが、例えばブロックチェーン技術や、TEE、KMSなどもキーワードとして入ってくるかと思います。
これからもキャッチアップしていきたいですね。
今回はこの辺で。