現代のiOSセキュリティ機能 – SPTM、TXM、そしてExclavesの詳細分析
(arxiv.org)- Appleのオペレーティングシステムの XNUカーネル は、基本的に単一の信頼領域を提供してきた
- 最近は カーネルアーキテクチャの分離とマイクロカーネル化 により、セキュリティ脆弱性の影響を減らすための変化が進められている
- 2023年に導入された Secure Page Table Monitor (SPTM) により、中核機能の分離と新たな信頼ドメイン構造が形成された
- Exclaves や Trusted Execution Monitor (TXM) などの最新セキュリティメカニズムは、SPTMを基盤として実装されている
- こうした 構造改善 により、カーネル侵害が発生してもシステム全体の信頼性が直ちに低下するわけではない
概要
Appleのオペレーティングシステムの中核である XNUカーネル はハイブリッドカーネルと呼ばれるものの、実際にはすべてのシステム機能が単一の特権信頼領域に集約された、一種のモノリシック構造として運用されている。このため、カーネルが侵害されるとシステム全体が即座に深刻な脅威にさらされるという問題がある。近年 Apple は、カーネルをより細かく分割し、マイクロカーネル的な設計に近づける改善を進めており、たとえばページテーブル操作や暗号関連の主要機能をカーネル領域の外へ移している。
主な変化の動機と研究の方向性
- セキュリティ強化のためにカーネル構造の改善が必要であることが明確になった
- カーネル脆弱性が悪用された際にシステム全体へ及ぶ悪影響を最小化することが目標
- SPTM などの新しいメカニズムが実際にどのように設計・動作しているかを科学的に分析した先行研究が不足している
- 本論文では、これらの未公開の新機能を体系的に調査し、現行のすべてのセキュリティ装置の相互作用と効果を整理する
SPTM (Secure Page Table Monitor) の中核メカニズム
- SPTM は Guarded Level 2（最上位特権レベル）で Guarded Execution Feature (GXF) とともに動作する、システム内で最高権限を持つコンポーネントである
- GXF は既存のAArch64の例外レベル構造に水平的な保護レベルを追加し、システムの機微な活動をXNUからの直接アクセスから隔離する
- SPTMはフレームのリタイピングとメモリマッピング規則に基づいて信頼ドメイン（domain of trust）を提供し、機能ごとに領域を分離する
- この信頼ドメインの代表例として TXM（コード署名・権限検証を担当）と Exclaves（最新の領域分離セキュリティ機能）などがある
Exclaves と通信メカニズム
- Exclaves は独立した信頼領域で動作する実行環境であり、SPTMベースのメモリ保護・制御体系に依存する
- Exclavesとシステム間の通信は xnuproxy（セキュア要求ハンドラ）や Tightbeam IPC フレームワークなど、さまざまな方式で実装されている
- Tightbeamはエンドポイント生成、メッセージバッファ、クライアント・サーバー接続など、複雑なIPC構造を持つ
- 実際のExclaves活用例として、プライバシーインジケータ（録画・オーディオ使用表示など）の操作も分析対象に含まれる
セキュリティ強化と今後の展望
- 中核的なシステム機能がXNUの直接アクセスから分離されたことで、カーネルが侵害されてもシステム全体の信頼水準を保つための追加の安全装置が整備された
- SPTM・Exclaves・TXM間の相互作用を精密に分析した結果、従来よりもはるかに強力な段階的保護体系が形成されている
- 論文の結論では、SPTM導入後の現状と今後のセキュリティ強化の可能性、残る限界、後続研究の方向性が簡潔に示されている
構成と詳細内容の案内
第1章: 動機–目標–構成
- Appleのカーネル分割の動きに関する歴史的文脈と研究の必要性
- 本研究の貢献点を強調
第2章: 背景と基礎
- AArch64アーキテクチャ の例外レベル、メモリアクセス方式、Appleチップの特殊保護技法（Fast Permission Restrictions, Page Protection Layer, Guarded Execution Feature, Shadow Permission Remap Register）を紹介
- 既存のセキュリティ研究とその限界を整理
第3章: 分析環境
- 対象ハードウェア・ファームウェア・ツール・シンボルおよびApple専用レジスタの説明
第4章: 全体アーキテクチャ設計の概要
- EL（例外レベル）とGL（水平保護レベル）をまたぐシステム全体構造の可視化
第5章: SPTMの詳細構造
- SPTMの基本構成と初期化、呼び出し方式（カーネル・TXM・Secure Kernel）およびヘッダー／ディスパッチテーブルの詳細解説
- SPTM内部のイベント処理、GENTER、SVC/HVC（ハイパーバイザコール）処理フロー
- フレームのリタイピングロジック: 呼び出しと検証、タイプ／ドメイン別の妥当性確認、SPRR（Permission Remapping）の更新、呼び出し完了などを段階的に説明
- ページマッピングプロセスとセキュリティ機構
第6章: Secure Kernelの役割
- Secure KernelとSPTM呼び出し、SVC処理など、セキュア運用の基礎
第7章: Exclavesシステム
- ExclavesおよびExclavecore、ExclaveKitなどの主要コンポーネント
- Exclaveのメモリ・リソース管理、ドメイン別グループ化、コンクレーブ（副領域）状態マシン、ユーザー空間とのインタラクション
- エンドポイント生成・スケジューリング、Machポート、seL4スタイルIPC、xnuproxy、Tightbeamなどの通信方式と実際の使用例（例: プライバシーインジケータ）
第8章: TXM (Trusted Execution Monitor)
- TXMのSPTM連携方式、ディスパッチ・リタイピングおよび保護領域の運用構造
- TXMのセキュリティ上の責務と呼び出し処理方式を説明
第9〜10章: 全体的な議論と結論
- SPTMとExclavesの導入に伴うセキュリティ上の意義、現在の限界、将来の方向性
- 研究の締めくくりとして、参考資料・用語解説の付録を提供
主要用語の解説
- XNU: Appleオペレーティングシステムの中核カーネルで、‘X is Not Unix’ の略
- SPTM: メモリ保護と分割を通じて信頼ドメインを付与する中核モジュール
- TXM: コード署名検証などの機微な作業を担うセキュリティ監督者
- Exclaves: 別個の物理的・論理的領域で隔離実行される信頼セキュリティ環境
- Tightbeam IPC: Exclavesとシステム間の安全な通信を支援するフレームワーク
- GXF/GL: AArch64における保護例外レベルと、それに加わるGuarded Levelベースの水平信頼領域制御機能
結論
現代のiOSセキュリティ構造は、SPTM・TXM・Exclavesを中心として 信頼性の分離と役割分担 を最大化する方向へ進化している。こうした階層的保護体系は、カーネル下位層の侵害リスクを大幅に低減し、将来のセキュリティ脅威にも堅牢に対応できる技術的基盤を提供する。
1件のコメント
Hacker Newsの意見
SEARとAppleのチームは、iOSのセキュリティで本当に素晴らしい仕事をしていると思う。この点は大いに称賛したい。
ハードウェアレベルからスタック全体にわたってセキュリティ機能を組み込む努力も見事だし、実際にITW（実環境での攻撃）エクスプロイトを調べ、それを防ぐ方法も継続して研究している。
たとえばPPLのような機能を導入してみて、それが完全ではないと分かれば、思い切って捨てて新しい手法を探しにいく。
Appleは垂直統合された構造なので、こうしたことがAndroidよりはるかにやりやすい。Androidではハードウェアベンダー（QC、Mediatek）に協力を求め、linuxカーネル、AOSP、LLVM upstreamなど複数の段階を経る必要がある。
Pointer Authentication Codes（PAC）も良い例だ。Appleは「自分たちでやろう」という姿勢で独自のLLVMブランチを維持しながら導入し、実際にITWベースの攻撃を緩和して問題を解決した。
私がApple製品を買う理由は、単にセキュリティやプライバシーが優れているからだけではなく、Appleがこうした機能を収益のために必ずしもやらなければならないわけではないのに、情熱を持って本気で推進しているからだ。
実際、マーケティングや宣伝を超えて、脱獄コミュニティのトップハッカーをセキュリティチームに採用し、Private Relay、プライベートメール、trusted compute、multi-party inference などの革新をもたらしている。
もちろん、Appleの偽善的な態度には明らかに問題もある。たとえばVPNを許可していてもAppleサーバー向けのトラフィックは例外だったり、プライバシー保護のデフォルト設定にも（Wi‑Fi Callingや「journaling suggestions」は除外されるなど）物足りなさがある。
実質的にはAppleや一部の通信パートナーからは守られないという条件付きではあるが、それでもGoogleは「GoogleまたはGoogleの広告購入者以外の全員に対して安全です」という感じなので、Appleのほうがはるかに先を行っていると思う。
莫大なエンジニアリング effort を費やしたあとでも、iMessageには怪しいコードがカーネルで実行される経路がまだ残っており、そのため0-clickエクスプロイトが依然として存在している。
こうした取り組みのもう1つの利点は、Appleがセキュリティを強化した新しいプロセッサでコードパスが一度でも実行されれば、すべてのプラットフォームのセキュリティが自然と高まることだ。
理論上、静的解析だけでは捉えにくい問題もより見つけやすくなり、単なるクラッシュ以外の、より深いインサイトも得られる。
Googleも実は数年前からMTEを追加できたが、Android認証の一環としてOEMへの強制適用を望まなかった。
OSアップデートと同じように、似た歴史が繰り返されているわけだ。
現在Appleがセキュリティを重視している理由は、ユーザーを守ることだけではない。
本質的には、ユーザーが承認されていないソフトウェアを自分で実行したり、脱獄のような行為をしたりすることを難しくして、App Storeの独占を維持するためだ。
結局のところ、ユーザーの利益ではなく会社の利益を優先していると思う。
iOSのセキュリティについて読むたびに、その複雑さにはいつも驚かされる。
ハードウェア段階、カーネル段階、さまざまなサンドボックス手法など、かなり多くのレイヤーが積み重なっている。
こうした構造が「過去の信頼を前提にした設計へ後付けした継ぎはぎ」なのか気になる。
もし最初から設計し直すなら、もっと単純にできるのか、実際にそのように設計されたOSが存在するのかも気になる。
脆弱性は、プラットフォームが多様なユースケースをサポートするほど避けられない。
それに対処する方法が、まさに多層防御（Defence-in-depth）だ。
iOSはMacOSをベースにしており、MacOSはNeXT、そのルーツはUnixにある。
もともと低いユーザー信頼を念頭に設計されていた。
時代によってユーザーをどこまで信頼するかも変わってきたし、近年は常時接続のネットワーク機能やSpectre以降の新たな脅威などで、さらに複雑になっている。
歴史的な設計判断への継ぎはぎなのか、という問いに答えるなら、そうだと思う。
Unixのセキュリティモデルと、C言語ベースのシステムプログラミングの限界を補う努力の結果だ。
もし最初から新しく設計するなら、capability architecture などを適用して複雑さを減らせるかもしれないが、POSIX互換性の問題のため、実際にはほとんどが学術用途や趣味の範囲にとどまっている。
完全に新しいモデルへ進むなら、既存のUnixプログラムの大半をそのまま捨てることになるため、実際の導入は非常に難しい。
seL4は高速で高い安全性を持ち、形式的に検証されたマイクロカーネル構造だ。
高度なアクセス制御、仮想マシン対応など、非常に優れている。
seL4マイクロカーネルアーキテクチャの解説記事
ただし「残りの部分」が欠けているので、実用的なOSというより研究用途に近いと思う。
両方試してみることはできるのではないかと思う。
「ハードウェアセキュリティ」にも固有の信頼前提はあるが、結局はハードコードされたソフトウェアにすぎず、複雑さが増すほどバグが生じる可能性も一緒に高くなる。
今回のHexacon Ivan Krstić Keynoteで、Appleはバグバウンティプログラムを強化すると発表した。
関連する公式ブログ
定期アップデートやアプリ実行時の平文（暗号化されていない）接続の問題が、まだ解決されているのか気になる。
関連資料