この論文は、CC BY 4.0 DEED ライセンスに基づいてarxiv で入手できます。
著者:
(1) Ehsan Toreini、サリー大学、英国。
(2) マリアム・メエルネジハド、ロンドン・ロイヤル・ホロウェイ大学。
(3) アード・ヴァン・モールセル、バーミンガム大学。
このセクションでは、システムのアーキテクチャ (図 1) を示し、その機能について説明します。 FaaS アーキテクチャには、3 つの役割の利害関係者が含まれています。A) ML システム: データと ML アルゴリズムを所有するシステム、B) 公平性監査サービス: ML システムの公正なパフォーマンスを計算するサービス、C) ユニバーサル検証者: 誰でも技術的な専門知識と監査プロセスを検証する意欲を持っている人。
それぞれのプロトコルの役割 (ML システム、Fairness Auditor Service、Universal Verifier) を実装する当事者のセキュリティの設計と実装 (図 1) は、互いに独立しています。役割間で行われる相互コミュニケーションは、当事者間に信頼がないことを前提としています。したがって、すべての主張には検証証明 (ZKP を使用します) が添付されている必要があります。監査システムはさまざまな攻撃に対して脆弱であり、信頼できないと想定しています。したがって、Fairness Auditor System に保存されるデータは暗号化され、改ざんが防止され、すべての段階で検証可能でなければなりません。さらに、ML システムと公平性監査者の間の通信チャネルは保護されていないと仮定します。したがって、機密データは送信を開始する前に暗号化する必要があります。ただし、プロトコル シーケンスの事前設定段階で暗号化プリミティブについて合意が得られます。
FaaS では、ML システムがデータセット サンプルの元のラベルの暗号文を誠実に送信すると仮定します。このような仮定に反対し、ML システムがデータセットの実際のラベルを変更することで監査サービス、ひいては検証者を欺こうとしているのではないかと議論する人もいるかもしれません。たとえば、ML システムは、監査人がアルゴリズムが公平であると結論付けるように、実際のラベルと予測ラベルの暗号文を可能な限り類似したものに提供します。これはさらなる研究が必要な興味深い分野です。たとえば、実際のラベルの暗号文を独立して監査サービスに提供することで対処できます。たとえば、検証者は、ML システムに提供するデータセットを所有することができます。次に、検証者は実際のラベルに必要な値を個別に決定し、これらを監査サービスにフィードします。このように、ラベルの一部は他の場所から取得されるため、ML システムにとって監査人に送信するデータをどのように操作するかはあまり明確ではありません。
ロールの内部セキュリティは FaaS を超えています。 ML システム自体は、データとアルゴリズムを保護するために追加の対策を検討する必要があります。 ML システムはデータと予測を正直に表示すると仮定します。倫理的に行動するインセンティブは、公平性監査プロセスに参加する際の不誠実さとは対照的であるため、これは合理的な仮定です。これについては、「ディスカッション」セクションで詳しく説明します。
表 2: 元のデータ内のエントリの 3 ビット表現の可能な置換。
主なセキュリティ プロトコル シーケンスは、ML システムと公平性監査サービスまたは短縮形の監査人の間で行われます。私たちのアーキテクチャでは 3 つの役割を提案していますが、通信は主に上記の 2 つの役割の間で行われ、ユニバーサル検証者は、計算に異議を唱えたい場合は監査サービス (公平性委員会を表す) に頼ることができることに注意してください。
ML システムは、ML アルゴリズムの実装と実行を担当します。データを入力として持ち、(ユースケースと目的に応じて) 何らかの予測を実行して出力を形成します (図 1)。公平性監査サービスは、ML システムから情報を受け取り、公平性メトリックを計算することによってその公平性パフォーマンスを評価します。次に、メトリクスの結果を ML システムに返します。また、公的検証のために公平性委員会で計算を公開します。パブリック公平性委員会は、公的にアクセス可能な読み取り専用の公平性委員会 (Web サイトなど) です。監査人は、公平性委員会にデータ(および十分な証拠)を追加する権利のみを有します。また、監査人はデータを公開する前に、データの信頼性、正確性、完全性を検証します。
このプロトコルには、セットアップ、暗号文の生成、公平性メトリックの計算という 3 つの段階があります。
このフェーズでは、ML システムと監査人が初期設定について合意します。プロトコルは乗算巡回グループ設定 (デジタル署名アルゴリズム (DSA) のようなグループ [18]) で機能すると仮定しますが、加法巡回グループ (楕円曲線デジタル署名アルゴリズム (ECDSA) のようなグループ [18]) でも機能することもあります。 ])。監査人および ML システムは、プロトコルの開始前に (p、q、g) について公的に合意します。 p と q を 2 つの大きな素数とし、q|(p − 1) とします。乗法巡回群 (Z ∗ p ) では、Gq は素数次数 q の部分群であり、g はその生成子です。簡単にするために、Decision Diffie–Hellman (DDH) 問題は範囲外であると仮定します [31]。
次に、ML システムは DSA または ECDSA を使用して公開/秘密ペア キーを生成し、その公開キーをフェアネス ボードで公開します。秘密キーのペアの保護は ML システムのセキュリティ アーキテクチャに依存し、秘密キーは業界標準の慣行 (たとえば、ボード上のセキュア メモリ モジュールの使用) で安全に保存されると想定しています。
暗号文テーブル:最初の合意の後、ML システムはテスト データセット内のサンプル数に対応する n 行からなる暗号文テーブルを生成します。この文書の残りの部分では、このテーブルを暗号テーブルと呼びます。 ML システムがテスト セット内のサンプル数を明らかにしたくない場合、監査人と ML システムは n について公的に合意できます。この場合、n は、普遍的な検証者が結果に満足するのに十分な大きさでなければなりません。
暗号文テーブルの各行は、(1) 保護されたグループのメンバーシップ ステータス、(2) 実際のラベル、および (3) ML モデルによる予測ラベルの 3 つのパラメータを要約します。各行には、3 つのパラメータの暗号化された形式とその正しさの証明が含まれています。セットアップ段階の暗号文テーブルを表 3 に示します。最も単純なケースでは、各パラメータはバイナリです。したがって、パラメータを組み合わせると、合計 8 つの順列が生成されます。セットアップ段階では、データ サンプルごとに 8 つの可能な順列すべてとその証明を含むテーブルが生成されます。順列の全体構造を表 2 に示します。各行は 4 つの特性を満たします: (a) 単一の暗号文が 8 つの可能な順列のうちの 1 つの暗号化バージョンであるかどうかを簡単に検証できます。(b) 検証可能であれば、検証可能です。単一の暗号文が選択されると、現在の暗号文がどの順列を表すかを検証することはできません。(c) 単一の行から選択された 2 つの暗号文ごとに、誰もがそれぞれを区別できます。(d) 与えられた一連の暗号文が任意に選択されます。各行をセットとして見ると、セット内に各「順列」のケースがいくつあるかを簡単に確認できます。
暗号テーブル関数の生成は、次のシーケンスに基づいています。
ステップ (1): n 個のサンプルのそれぞれについて、システムはランダムな公開鍵 g xi を生成します。ここで、xi は秘密鍵、xi ∈ [1, q − 1] です。
ステップ (3): バイナリエンコーディングの 10 進数値に等しい対応する列番号が暗号テーブルから選択され、公平性監査テーブルが完成します (表 2 を参照)。
最後に、生成された公平性監査テーブルは ML システムによってデジタル署名され、公平性監査サービスを通じて送信されます。
まず、公平性監査サービスは公平性監査テーブルを受け取り、デジタル署名と ZKP を検証し、その内容を公平性ボードに公開します。
この時点で、これらの方程式の各要素を展開して比較します。
このプロセスは、特に公平性監査テーブル内のデータ サンプルの数が多い場合に計算量が多くなります。この場合、公平性監査人は順列番号の宣言を ML システムに委任できます。監査人は依然として公平性監査テーブルと関連する ZKP を受け取ります。公平性監査テーブルを公平性ボードに保存し、公平性を計算し、宣言された順列番号の正確性を検証できます。ユニバーサル検証者は、同じ手順に従って、公平性ボードを介して公的にアクセスできる公平性監査テーブルを通じて公平性メトリックの計算を検証できます。
この段階の最後に、監査人は取得した数値を使用して公平性の指標を計算し、情報を公開します。各順列の数は、保護された属性を持つ各グループの ML アルゴリズムの全体的なパフォーマンスを示します。表 4 は、順列と、それが ML システムの公平性メトリックにどのように関連するかを示しています。暗号文テーブルとその結果は公平性委員会で公開されます(図1)