kenmaro です。
秘密計算、特に準同型暗号のことについて記事を書いています。
秘密計算エンジニアとして得た全ての知見をまとめた記事はこちら。
https://qiita.com/kenmaro/items/74c3147ccb8c7ce7c60c
これから準同型暗号について勉強したいリサーチャー、エンジニアの方へのロードマップはこちら。
https://qiita.com/kenmaro/items/f2d4fb84833c308a4d29
今話題のゼロ知識証明について解説した記事はこちら。
https://qiita.com/kenmaro/items/d968375793fe754575fe
概要
前回
の記事の中で、
Ownership Preserving DB という言葉を定義している、
こちらのOperonというデータベースについて言及しました。
このときに登場する３つのエンティティについて
- データオーナー（ユーザ）
- データ操作者（ソフトウェアサービサー）
- 基盤を提供するインフラサービサー
が登場して、それらの登場人物の中で以下にしてデータのオーナーシップを保存したデータベースを構築するか、
ということが論文にまとめられていました。
これを参考にして、秘密計算のシステムを構成するときに最初に考えたい、
セキュリティ要件のメトリクスについて考えていく記事にしたいと思っています。
登場人物（エンティティ）について
OPDBの概念で登場する３つの役割
OPDB(Ownership Preserved DataBase) において、Operonの論文では
３つの役割を持った登場人物（エンティティ）について定義し、セキュリティ要件を定義していました。
人物１. データオーナー（ユーザ）
データの保有者であり、このデータを安全に活用することでビジネスに役立てることを目的としている。
データへのアクセス権限、操作に対する権限を管理できる人物
人物２. データ操作者（ソフトウェアサービサー）
データーオーナーと共同で、もしくは単体で、データ活用のサービスをソフトウェアとして提供し、データ活用のためのデータ操作について設計する人物
人物３. 基盤を提供するインフラサービサー
データをデータ操作者に代わって実際に操作する人。インフラのプロバイダーと考えて良い。
この場合、OPDBのシステムを構成している人物。
この３人に、
第三者（データを盗もうとする攻撃者）
を加えて４つのエンティティについて考えると、セキュリティ要件はとても考えやすくなります。
登場するデータの種類について
Operonの論文では、
- データオーナーがサービスに入力するデータ
- データに対するオペレーション
- データの分析結果に相当するmeasure
といったように、サービスに登場するデータを分類していましたが、少しわかりにくいところもありました。
というより、この論文ではかなり一般的に物事を書こうとしていたので、measureが具体的にどのようなデータに相当するのか、
など少し理解が難しくなっていました。
これを私なりに分割分類すると以下のようになります。
データ1. ユーザのデータ
Operonにあったように、データオーナーであるユーザがサービスへと入力するデータであり、
いかなる場合においてもデータは暗号化されて保存され、復号権限はデータオーナーのみが保持しています。
もちろん、データオーナーの許可があればサービス内でも復号することは可能です。
データ2. サービスが出力する結果データ
結果については、例えばAIモデルを提供するAIaaSを考えれば推論結果がこの結果データに該当します。
サービサーがユーザのデータを操作し、ビジネスロジックに従って何かしらの計算を実行、
その実行結果をユーザに戻すようなシチュエーションであれば、その戻す計算結果がこの結果データです。
データオーナーはこの結果を復号する権限をもちろん持っています。
データ3. サービスが途中出力するデータ
サービスはデータオーナーからのデータを暗号状態で受け取り、それを操作することになります。
目的は２の結果データの計算ですが、その計算過程で計算途中についてもデータが発生します。
AIの例だと例えば中間層からの出力などがこれに該当するでしょう。
DBを用いた例だと、結果を計算するためにいくつかのクエリを用いて検索可能暗号を使ってデータの統計値を計算し、
それをもとに結果データを導出するのであれば、この統計値はサービスが途中で出力するデータにカテゴライズされます。
データ4. サービサーの計算ロジック
サービサーは先述の通り、データオーナーからのデータを操作しなにかしらのビジネスロジックを利用してデータを暗号状態で分析するわけですが、そのときの計算ロジックももちろんデータに該当します。
AIaaSの例であれば、どのようなモデルを使っているか、モデルは何層あって、といったトポロジーがこのロジックに該当します。
また、統計値を用いた分析であれば、このカラムに対して統計値を計算している、そのデータとユーザのこのデータを参照することで結果を計算している、（つまりDBを使っていればどのようなクエリをどのカラムに対して実行しているかという情報）
というようなロジックそのものに該当します。
AIの例であればkeras を使って構築したモデルの定義であり、統計値の例だとAVGを計算している、MAXを計算している、というようなロジックです。
もちろんサービサーはこのロジックを知っているから計算できるのですが、計算はインフラサービサーが提供している基盤上で計算されているため、そのロジックをインフラサービサーに公開できるか、というところが議論のポイントになります。
データ5. サービサーの計算ロジックに使用する値
サービサーがサービスで計算を行う時のロジックそのものではなく、そのロジックで扱われる数値データがこれに該当します。
AIaaSの例で言うと、モデルの構造そのものではなく、学習済みモデルの重みデータです。
統計値を用いた例であれば、どのカラムに対してどのようなクエリを打っているかという情報ではなく、そこでどのような数値に対してWhereをとっているか、と考えた時の具体的な値に相当します。
AIaaSの例だと、サービサーにとってモデルの重み情報はサービサーが学習したモデルの学習結果に該当するため、外に公開し難いデータである可能性があります。
秘密計算セキュリティ要件のメトリクス
以上の、
- エンティティ
- データタイプ
について理解が深まると、秘密計算システム構築時のセキュリティ要件のメトリクスを構成することができます。
| データタイプ \ エンティティ | データオーナー | サービサー | インフラサービサー |
|---|---|---|---|
| 入力データ | 秘匿が必要か | 秘匿が必要か | 秘匿が必要か |
| 結果データ | 秘匿が必要か | 秘匿が必要か | 秘匿が必要か |
| 途中出力データ | 秘匿が必要か | 秘匿が必要か | 秘匿が必要か |
| サービサーロジック | 秘匿が必要か | 秘匿が必要か | 秘匿が必要か |
| サービサーロジック中の値 | 秘匿が必要か | 秘匿が必要か | 秘匿が必要か |
この、各データに対する、エンティティ毎への秘匿の必要の有無
を埋めていくと、自ずとセキュリティ要件は決まってきます。
また、前提として攻撃者（第三者）をここでは省略していますが、
攻撃者に対しては全てのデータタイプが秘匿されるべきであることがほとんどなため、
今回は攻撃者のカラムを省略しています。
途中出力データについて
途中出力データはここでは一つの行で書いていますが、
実際の計算において途中出力のデータは複数になることがほとんどです。
似たような出力であれば一つのカテゴリにまとめて評価することも可能です。
しかしながら、別の出力であれば、そこから漏洩する可能性のある情報も基本的には異なることが多いです。
したがって、この「途中出力データ」については何が出力となりうるのか
ということをもれなく吟味し、それぞれのデータに対して秘匿必要の有無を議論することが必要になります。
まとめ
今回は、Operonの論文からの派生として、
実際にデータを秘匿したままデータを活用する秘密計算のシステム構築時に考えるべきセキュリティ要件のメトリクス
について考察してみました。
多くの場合、このメトリクスで考えると物事がスッキリすることが多いです。
秘密計算システム構築時の参考にしてみてはいかがでしょうか。
今回はこの辺で。