Eclypsiumの調査で、侵害されたハードウェアが実行時にAIモデルを改変できる仕組みが明らかに

Eclypsiumは、元のファイルをそのまま保ちながら、侵害されたコンピューティング基盤によって推論中のAIモデルの挙動が変えられることを実証した。10月29日に信頼できるAIには信頼できるインフラが必要で公開されたこの研究は、モデルの署名やファイルハッシュを確認するだけでは、メモリー上で実行されているモデルの完全性を保証できない理由を示している。

NVIDIAの支援を受けた制御環境での実証実験で、研究者らは侵害されたデータ処理ユニット（DPU）と、制限の緩いメモリー分離を組み合わせ、実行時のモデルの重みを改変した。保存されたモデルや推論サービスを変更することなく、モデルの回答が変化した。この発見は、ハードウェア、ファームウェア、デバイス構成もAIのセキュリティ境界に含まれることを示している。

AIモデルを改変する別の手段

AIのセキュリティをめぐる議論では、悪意あるプロンプト、汚染された学習データ、安全でないツールの使用に焦点が当たりがちだ。この研究が検証するのは、より下層にある、モデルの実行中にそのパラメーターを保持し、移動させるインフラである。

重みとは、モデルの回答を形作る数値パラメーターだ。ディスク上の正規のファイルをメモリーに読み込んだ後、十分な権限を持つコンポーネントがその内容を変更することがある。その後、元のファイルを確認すれば、回答の生成に変更後の実行時状態が使われていたとしても、期待どおりのバイト列が確認される。

Eclypsiumの実証実験では、地政学に関する質問への分析結果が目に見えて変化した。より広い懸念として、実行時の操作が、生成コードや自動化された意思決定など、ほかの機微な用途にも影響を及ぼす可能性がある。ただし、こうした可能性と、実験室で実際に示された具体的な挙動は区別する必要がある。

検知されずに改変できるという主張にも、明確な適用範囲がある。実証実験で用いられた保存モデルの完全性チェックでは、メモリー上の変更は検出されなかった。だからといって、あらゆる監視やフォレンジック調査でも検知できないことが証明されたわけではない。

攻撃が成立する条件が重要

このテストでは、NVIDIA Grace Hopper環境が使われた。直接メモリーアクセスの経路は、侵害された特権コンポーネントと、機微なメモリーへのアクセスを許す構成設定に依存していた。研究者らは、IOMMUパススルーと制限の緩いPCIe分離を重要な条件として挙げ、これらがLinuxのデフォルト設定ではないことを明確に指摘している。

IOMMUは、周辺機器がアクセスできるメモリーを制御するのに役立つ。研究者らがテストした、より強固な分離構成では、同じ直接アクセス経路は利用できなかった。したがって、この結果は、セキュリティ機能が導入されているだけで境界を実際に強制していると考えるのではなく、実際の導入環境の設定を確認することの重要性を示している。

DPUは、ネットワーク、ストレージ、セキュリティサービスに使われるプログラム可能なインフラプロセッサだ。データを効率よく移動できることは有用だが、正当なインフラ機能を支える権限も、攻撃者がコンポーネントを掌握すれば危険になり得る。

NVIDIAの対応：信頼境界を検証する

共同研究についての説明で、NVIDIAはBlueFieldの認証付き起動、ハードウェアを基盤とする信頼性、分離、ファームウェア更新の保護、アテステーションについて説明している。また、クラウド事業者は、それぞれ異なる信頼モデルに応じてセキュリティ構成を選択すると強調している。

両社が伝えているのは、事業者はそうした選択を裏付ける証拠を必要としているということだ。メモリーアクセス制御、デバイス分離、管理インターフェースは、導入環境の脅威モデルに照らして評価しなければならない。機能が利用可能であるというだけでは、正しく設定されていることの証明にはならない。

NVIDIAとEclypsiumは、この問題は単一ベンダーにとどまらないとも説明している。AIシステムは、特権を持つホストソフトウェア、アクセラレーターのファームウェア、管理コントローラー、データ転送の仕組みに依存している。具体的な経路はアーキテクチャごとに異なるが、こうしたコンポーネントを考慮する必要があることに変わりはない。

エージェントのセキュリティがインフラのセキュリティにも左右される理由

モデルがツールを呼び出したり、企業データにアクセスしたり、アクションを実行したりできる場合、リスクはさらに高まる。インフラへの改ざんは、実際にどのモデルが動作しているかについて、アプリケーションレベルの安全対策が前提とする信頼を損なうおそれがある。

NVIDIAのOpen Agent Safety Platformは、多層的な対応の一例だ。OpenShellが実行時のガバナンスを担い、BlueField上のNVIDIA Sentryは、ホストとエージェントの外側にあるハードウェア分離型のセキュリティドメインで動作する。このアーキテクチャは、独立した制御点から挙動を監視し、ポリシーを適用することを目指している。

こうした独立した立場には、別のセキュリティ上の責任も伴う。制御を担うハードウェアとソフトウェアスタック自体が、信頼できる状態を保たなければならない。制御機能をアプリケーションの外に移せば依存関係を一つ減らせる一方、その機能を任されたコンポーネントの検証がいっそう重要になる。

ハードウェアの棚卸しから継続的な保証へ

Eclypsiumは、モデルに焦点を当てた保証とインフラストラクチャの完全性との間にある隔たりを「AIインフラストラクチャ保証ギャップ」と呼んでいます。同社のインフラストラクチャ保証プラットフォームは、コンポーネントを台帳化し、ファームウェアと構成を評価し、デバイスの状態を承認済みのベースラインと照合して、変更を監視します。同社は、こうした機能を既存のアプリケーションやモデルの保護策を補完するものと位置づけています。

運用担当者が実務としてまず取り組むべきなのは、DPU、GPU、管理コントローラーとそれらのファームウェアを、それぞれ個別に管理する資産として扱うことです。それぞれについて、管理責任者の明確化、バージョンの追跡、脆弱性評価、そして明確なアップデート手順が必要です。管理プレーンへのアクセスや、インフラストラクチャ用プロセッサ上のサードパーティー製ソフトウェアも、この評価の対象に含める必要があります。

ハードウェアの確認は、導入、アップデート、インシデントからの復旧、再割り当ての各段階でも行う必要があります。OSイメージがクリーンであるだけでは、すべての低レベルコンポーネントが承認済みの状態にあるとは確認できません。共有インフラストラクチャでは、ハードウェアが複数の顧客に順次提供される可能性があるため、このライフサイクル管理がとりわけ重要になります。

成果物だけでなく、稼働中のシステムを確認する

モデルの署名は引き続き有用です。読み込まれる成果物について、重要な問いに答えてくれるからです。セキュアブート、アテステーション、ランタイム分離、継続的な監視は、そのモデルを実行するシステムについて、それぞれ異なる問いに答えます。いずれか一つを、ほかすべての代わりとして扱うべきではありません。

Eclypsiumの研究が示す重要な点は、ある完全性チェックに合格したモデルでも、実行チェーンの別の部分が変更されている可能性があるということです。重要な業務プロセスにAIを導入する組織では、運用期間を通じて、モデルの評価と並行してインフラストラクチャの検証を行う必要があります。