Teodor_Parvanov_Intel
所属: インテル
01-22-2025
共同執筆者: インテル® Tiber™ トラスト・サービス担当シニア・ソフトウェア・アーキテクト Teodor Parvanov、連合学習リサーチ部門エンジニア Karan Shah
https://community.intel.com/t5/user/viewprofilepage/user-id/386606
連合学習 (FL) は、異なるデータ所有者に分散されたデータセットを複数のモデル開発者が使用できるようにする、マシンラーニング (ML) の新たなパラダイムです。データ所有者がデータの完全コントロールを保持したまま、モデルの学習や評価にプライベート・データを自由に活用できるため、膨大な可能性が広がります。その結果、制限の厳しい機密データセットを活用しながら、完全性と秘匿性を損なうことなく、安定性と信頼性の高いモデルを構築できます。
図 1. データを中央サーバーに収集する従来の集中型学習から、プライベート・データがローカル環境の外に出ない連合学習へ
以前投稿した記事では、従来の集中型学習から始め、OpenFL による連合学習の設定手順を紹介しました。強固な PKI と、集約ノード (アグリゲーター) と参加ノード (コラボレーター) 間が相互認証された通信 (mTLS) の仕組みをベースとしているものの、このシステムの分散型という特性を突く攻撃や、アルゴリズムへの敵対的攻撃に対しては、依然として脆弱性を抱えています。
https://medium.com/openfl/from-centralized-machine-learning-to-federated-learning-with-openfl-b3e61da52432
https://github.com/securefederatedai/openfl/blob/develop/docs/releases.md
この記事では、OpenFL ベースの連合学習でプライバシー保護とセキュリティーを強化する、基本のビルディング・ブロックと手法を例に説明していきます。具体的には、信頼できる実行環境 (TEE) とリモート認証を活用した、セキュリティーと信頼性の高い連合学習システムの構築方法を探っていきます。
＜連合学習に対する攻撃ベクトル＞
連合学習を設定する過程で、データ所有者 (コラボレーター) は、各自のプライベート・データでパイプラインやアルゴリズムが実行されるのを確認し、合意することが求められます。学習スクリプトがデータを抽出して倫理に反したりバイアスのかかった方法で使用しようとしてはいないか、チェックする手順もその一部です。データ所有者は、連合学習プロセス中に自分のデータで実行されるコードは、あらかじめ承認したコードと同一であると想定しています。しかしながら、オンプレミスやクラウドといった標準的な実行環境では、このような保証は担保されず、そのため、データ所有者は連合学習の構築に関係するすべての人物や組織を暗黙的に信用せざるをえません。
一方、モデル開発者にも、学習プロセスの品質に関するリスクや、最終的なモデル自体の知的資産 (IP) を脅かされるといった脅威が存在します。実際、モデル所有者の意図した ML コードを悪意あるコラボレーターが改ざんし、学習の収束スピードが低下するリスクや、バイアスが埋め込まれるなど、モデル・ポイズニング攻撃を仕掛けてくる可能性も否定できません。不正なコラボレーターが、暗号化されていないメモリーやML アルゴリズムで生成されたファイルを解析して、モデルそのものを盗み出そうとするような別のシナリオも考えられます。この脅威によって、最終モデルが無断で複製 / 転用され、知的資産が侵害されてしまいます。
このような脆弱性から学習処理モデルを保護するソフトウェア・ベースの手法もありますが、セキュリティーを強化するには、参加エンティティー間の暗黙の信頼、またはコードの完全性と機密性を検証する明示的な仕組みが必要です。しかし、連合学習の件数と規模が拡大している今、人間同士の相互のやり取りや健全な判断力にのみ依存して信頼を確保するなど、現実的ではありません。
＜信頼できる実行環境 (TEE)＞
連合学習のコンテキストで「信頼性」を考えるとき、通常は、格納されている、ネットワークを転送中、処理を実行中の状態にある機密データの保護を指しています。格納されている状態と転送中の 2 つについては、OpenFL 連合学習ではデフォルトのセキュリティー通信となっている mTLS プロトコルなど、実績ある暗号テクノロジーを用いたソフトウェア・ベースのソリューションがあります。一方で処理中のデータは、OS、仮想ハイパーバイザー、クラウド・インフラストラクチャーの管理者権限を悪用したイントロスペクション (のぞき見) といった攻撃に対して脆弱です。準同型暗号などの高度なソフトウェア手法も存在しますが、非常に複雑で、演算オーバーヘッドが大きすぎるという課題があります。ここでは、こうした課題を補完し、パフォーマンスへの影響を最小限に抑えながらコンフィデンシャル・コンピューティングの幅広いユースケースに適応可能な、信頼できる実行環境 (TEE) と呼ばれるハードウェア・ベースのテクノロジーに焦点を当てて解説していきます。
TEE は、プロセッサー内部でも一層セキュリティーが強化された領域です。プロセッサー内部に取り込まれたコードやデータの機密性と完全性を保護するために設計されました。制御された実行環境が設けられ、機密性の高い演算処理をシステム内のほかのコンポーネントから分離して実行できるようにします。さらに、リモート認証プロトコルにも対応しているため、ワークロード (プログラム) のユーザーは事前に定義された信頼ポリシーに対するソフトウェアとハードウェア・スタックの完全性を独立して安全に検証できます。
連合学習に TEE を確保することで、参加エンティティーごとに実行するローカルの演算処理が改ざんや不正アクセスから防御されるため、プライバシーとセキュリティーが大幅に強化されます。この追加のセキュリティー層が、データの機密性と学習プロセスの完全性を維持し、参加エンティティー間の信頼性向上と、強固でセキュアな協調型 ML モデルの構築が可能になります。
以降のセクションでは、このハードウェア・ベースのセキュリティー手法について、インテル® ソフトウェア・ガード・エクステンションズ (インテル® SGX) によって OpenFL ベースの連合学習を保護する実際の手順を通じて説明します。
＜インテル® SGX によるデータと演算処理のセキュリティー確保＞
インテル® SGX は、CPU の拡張命令セットです。エンクレーブと呼ばれる隔離メモリー領域を設けて、機密データのセキュアな演算処理を可能にします。エンクレーブ内で実行するアプリケーションは、メモリーで暗号化され、システムのほかのコンポーネントから隔離された状態を維持します。エンクレーブ内で動いているコードのみがメモリーにアクセスすることができ、OS やハイパーバイザーのほか、ハードウェアへのアクセス権限があるユーザーであっても、このメモリーにアクセスすることはできません。
エンクレーブ内でアプリケーションを実行するには、インテル® SGX API に直接アクセスできるようにコードの修正と再コンパイルが必要です。この手間を省くために、Gramine では未修正のアプリケーションでもエンクレーブ内でそのまま実行できる、エンクレーブ内に最小限の依存関係を持つ「ホストされた環境」を用意しました。この環境がアプリケーションとホスト OS の間を仲介する役割を担い、アプリケーション用に「マイクロカーネル的な環境」を整えます。
https://gramine.readthedocs.io/en/stable/
エンクレーブ内でコードを実行するには、インテル® SGX 対応のインテル® CPU が必要です。また、参加エンティティーごとに BIOS 設定でインテル® SGX を有効化しておく必要があります。インテル® SGX を有効化する手順は、ベンダーのシステムマニュアルを参照してください。ただし、エンクレーブをビルドするだけなら、インテル® SGX 対応システムは必須要件ではありません。アプリケーションをエンクレーブ内で実行するには、インテル® SGX 対応の環境が必須要件となります。
https://www.intel.co.jp/content/www/jp/ja/support/articles/000028173/processors.html
OpenFL コードでインテル® SGX を有効化するには、集約ノード (アグリゲーター) か参加ノード (コラボレーター) かを問わず、すべての依存関係を含めた未修正のアプリケーション・コンテナをビルドする必要があります。
図 2. インテル® SGX の信頼できる実行環境 (TEE) で動く OpenFL ノード
OpenFL は、TaskRunner API 経由でアプリケーション・コンテナ内の TEE 実行をサポートしています。PKI 証明、連合学習のプラン、ソースコードが揃ったワークスペースを準備できたら、ワークスペースから以下のコマンドを呼び出します。
user@vm:~/example_workspace$ fx workspace dockerize --save
ここではデモ目的のためエンクレーブ署名キーを省略していますが、OpenFL はエンクレーブ署名キーを自動生成します。生成された鍵はワークスペースに格納され、コンテナイメージには含まれません。独自のエンクレーブ署名キーを --enclave-key フラグで指定することも可能です。
https://openfl.readthedocs.io/en/latest/about/features_index/taskrunner.html#running-the-task-runner
ワークスペース・イメージは .tar ファイルとして同じディレクトリーに格納されます。このイメージには、以前にチュートリアルで使用したものと同じ fx CLI アプリケーションが含まれていますが、インテル® SGX 内で動作し、各 PKI 証明と一緒に配布できる、実際の連合学習を参加エンティティー間で実行するアプリケーションとなっています。以下のとおり、TEE 環境と TEE 以外の環境での実行の違いはわずかです。
https://medium.com/openfl/from-centralized-machine-learning-to-federated-learning-with-openfl-b3e61da52432
これでコンフィデンシャル・コンピューティング導入の障壁が緩和されるものの、ハードウェアやソフトウェアのアクセス権限を悪用した攻撃対象をすべて塞ぐには、参加エンティティー間の信頼を確立することが重要です。ハードウェアとソフトウェアの正当性を証明することで信頼を確立する「リモート認証」と呼ばれるプロセスについては、次のセクションで詳しく解説します。
＜エンドツーエンドの信頼を確立する＞
リモート認証 (RA) は、例えば連合学習の参加ノードなどの当事者に対して、コンフィデンシャル・コンピューティング環境が信頼に値するかどうかを中立的な立場で証明するプロセスです。リモート認証では、対象のソフトウェアが最新の TEE 環境にある正当なハードウェア上で実際に動作していること、構成ファイルや入力データを含め、演算処理が期待どおりの初期状態から始まっていることを証明します。
もっと広く捉えると、TLS 証明だけでは実現できないレベルで信頼性を確認できるということです。なお、TLS 証明はあくまでも特定のサービス (連合学習の参加ノードなど) が信頼できる組織によってホストされていることを保証するだけで、その根底で動いているコードの真正性について言及するものではありません。
OpenFL では、すべての参加ノードにリモート認証が適用されるため、連合学習セットアップ全体での信頼性が向上します。
•データ所有者: リモート認証によって、意図した承認済みの ML ソフトウェアのみが自分のデータを処理していることを確認し、不正なデータ抽出や倫理に反する利用を防止。
•モデル開発者: モデルが期待される機密性プロパティーを持つ有効な TEE 環境で学習処理されているかを検証し、悪意あるデータ所有者によるモデルの盗用やポイズニング攻撃を防御。
インテルは、TEE から受け取った CPU、メモリー、マイクロコード、ファームウェア・バージョンなどコンピューティング資産の状態 (つまり測定値) に関するレポートをもとに、インテル® Tiber™ トラスト・オーソリティーを通じてリモート認証サービスを提供しています。これらの測定値は認証サービスへセキュアに送信され、インテルが定める信頼性構成ポリシーに基づき、既知の正当な値と一致しているか (完全性) が照合されます。測定値が一致すると、認証サービスは信頼できる環境であることを証明する検証可能なトークンを発行します。こうして、ほかのシステムがその証明書を信頼できるようになるという仕組みです。
＜リモート認証を適用した OpenFL＞
信頼できる実行環境 (TEE) 内で動作する OpenFL ノードの真正性を確立するために、参加ノード (アグリゲーター・エンクレーブまたはコラボレーター・エンクレーブ) が各自のインテル® SGX ローカル環境と、リモートのインテル® Tiber™ トラスト・オーソリティー API とのインタラクションを通じて、暗号署名付き認証証明を生成するプロセスを想定します。このプロセスは、連合学習における役割に関係なく、すべての参加ノードで同一です。
1.起動後、各 OpenFL 参加ノードはローカルのインテル® SGX 呼び出しエンクレーブにクエリーを送信。エンクレーブのソフトウェア / ハードウェア測定値が含まれた署名付き “quote” が生成されます。
2.次に、インテル® SGX の quote がインテル® Tiber™ トラスト・オーソリティー API に送信され、エンクレーブの測定値と (対応ハードウェア、ファームウェア・バージョン、信頼できる ML コードの測定値など) 連合学習で定義されているポリシーを照合。
3.インテル® SGX の quote が有効とみなされると、インテル® Tiber™ トラスト・オーソリティーは暗号署名付き JWT トークンを発行。TEE の真正性を証明します。
4.続けてエンクレーブ・プロセスが開始。生成された認証トークンが外部の検証用に公開されます(この仕組みについては、後ほど説明します)。