solnik secure enclaveprocessor-pacsec-final-jp

詳説Secure Enclave プロセッサ

Tarjei Mandt (@kernelpool)

Mathew Solnik (@msolnik)

David Wang (@planetbeing)

自己紹介

• Tarjei Mandt

▫ Azimuth Securityシニアセキュリティリサーチャー

▫ [email protected]

• Mathew Solnik

▫ OffCell Researchディレクター


• David Wang

▫ Azimuth Securityシニアセキュリティリサーチャー


mailto:[email protected]



はじめに

• iPhone 5Sは技術上のマイルストーンであった▫ 初めての 64-bit 携帯電話

• いくつもの技術的な新規性を導入▫ Touch ID

▫ M7 モーションコプロセッサ

▫ セキュリティコプロセッサ (SEP)

• 機密情報の安全な記憶が有効になった▫ 指紋情報、暗号キー、その他

Secure Enclave プロセッサ

• SOCの他の部分に安全にサービスを動作させるよう設計されたセキュリティ回路

▫ メインプロセッサが機密データへ直接アクセスすることを防ぐ

• 他の多くのサービスをサポートするために使われる▫ 特にTouch IDなど

• それ専用の独自のOSが動作 (SEPOS)

▫ 専用のカーネル、ドライバ、サービスおよびアプリケーションを含む

Secure (?) Enclave プロセッサ

• SEPに関しては非常に少ない情報だけが公開▫ Appleによって提供された情報のみ

• SEPの特許は高レベルの概要のみ提示▫ 具体的な実装の詳細は記載されていない

• 複数の疑問が残る▫ SEPはどのようなサービスを提供しているのか?

▫ それらのサービスにどのようにアクセスするのか?

▫ どのような権限が必要なのか?

▫ SEPには攻撃に対してどのような効果があるのか?

トークの概要

• パート 1: Secure Enclaveプロセッサ▫ ハードウェアデザイン▫ ブートプロセス

• パート 2: 通信▫ メールボックスの仕組み▫ カーネルとSEP間のインタフェース

• パート 3: SEPOS▫ アーキテクチャ / 内部

• パート 4: セキュリティ分析▫ 攻撃面と堅牢性

詳説 Secure Enclave プロセッサ

SEPのARMコア: Kingfisher

• 専用のARMv7a 「Kingfisher」コア▫ APコアのEL3からではSEPにアクセスできない

• 300-400MHz以上で動作しているようである

• SOC内の複数のKingfisherコアのひとつ▫ 2-4個の他のKFコア - NAND/SmartIO/他に使用

▫ 他のコアから多数のアーキテクチャ情報が得られる

• プラットフォームに応じて変更(A7/A8/A9)

▫ 新しいチップ上での耐タンパーのようである

専用の周辺ハードウェア

• SEPはメモリマップドI/Oによってアクセス可能な独自の周辺回路のセットを持っている▫ APはアクセスできない組み込みのハードウェア

暗号化エンジンや乱数生成期セキュリティヒューズ GID/UIDキー

• 専用のIO信号線 -▫ 信号線はチップ外の周辺装置へと直接駆動する

GPIO

SPI

UART

I2C

共有の周辺ハードウェア

• SEPとAPはいくつかの周辺回路を共有する• 電源管理(PMGR)

▫ セキュリティヒューズの設定はPMGRに置かれている▫ それ以外にもいくつもの興味深いものがある

• メモリコントローラ▫ iOSカーネル経由でのぞき見ることが可能

• 位相同期(PLL)クロック生成器▫ 特に見どころなし…

• セキュアメールボックス▫ コア間でのデータ転送に使用

• 外部ランダムアクセスメモリ(RAM)

物理メモリ

• 専用のブートROM (といくらかの SRAM)

▫ BootROMの物理配置は 0x2_0da0_0000

• 外部RAMの暗号化にインラインAESを使用▫ SoCのRAMチップを取り外す物理メモリ攻撃に対してもっとも効果的 (iPad)

• APからSEPのメモリアクセスを防止するハードウェア「フィルタ」▫ SEPのKFコアだけがこのフィルタを保有

SEP KF フィルター構成図

From SoC To SoC

ブートROM

メールボックス

コア

SEPフィルタ

SEPの初期化 – 第1ステージ

• APのリセット完了後、APのブートROMがリセットからSEPを開放▫ この動作は不可逆である。APによってアクセス可能なハードウェアレジスタはSEPのリセットや停止はできない

• 初期状態では4096バイトのスタティックRAMがスタックおよび変数のために使用される

• ROM内のページテーブルが使われる▫ 大きな物理アドレス拡張が必要

• メッセージループが開始

SEPの初期化 – 第2ステージ

• メールボックス内のメッセージを受信

• SEPOSが使用するものと同じフォーマットの8バイトのメッセージ

• 全てのメッセージがエンドポイント255を使用(EP_BOOTSTRAP)

オペコード説明

1, 2 “ステータスチェック” (Ping)

3 nonceの生成

4 nonceワードの取得

5 “BootTZ0” (ブート継続)

メモリ保護

• SEPは4096バイトのSRAMより多くのメモリがいるため、外部のRAMを必要とする

• SEPの使用するRAMはAP改ざんから保護されなければならない

• APによって設定可能な2つの領域がセットアップされる:▫ TZ0はSEP向け▫ TZ1はAPの信頼ゾーン(カーネルパッチ保護)向け

• SEPはブート時のAPによるTZoのセットアップを待たなければならない

SEP 起動フロー

TZ0 と TZ1の設定

Ping送信

Send BootTZ0

Ping送信

AP

Acknowledge Ping

SEP

Map in TZ0

メモリ暗号化のセットアップ

Acknowledge BootTZ0

ステージ3の開始

iBoot

カーネル

ステージ3

ステージ2

SEP メモリ保護ブートストラップ

• SEPはTZ0がロック中にAPのワードを取得することはない

▫ ロックのためにハードウェアレジスタをチェック

▫ そののちに他のハードウェアレジスタからTZ0のサイズとアドレスを読み取る

• TZ0ロック後はこれらのハードウェアレジスタは変更不可

• 故障時にはプロセッサをスピン

TZ0 と TZ1 の設定

Ping送信

Send BootTZ0

Ping送信

Acknowledge Ping

Map in TZ0


Acknowledge BootTZ0


iBoot

Kernel

Stage 3

Stage 2

メモリ暗号化モード

• ECB、CBCおよびXEXをサポートしている模様• AES-128およびAES-256が使用可能• 2つのチャンネルをサポート

▫ ブートROMはチャンネル1を使用▫ SEPOSはチャンネル0を使用

• 物理アドレスの領域へのすべてのアクセスにおいて暗号化/復号は透過的に行われる▫ ブート後、SEPOSは暗号化領域の全ページのマッピングを保持する (ハードウェア領域およびAPとの共有メモリを除く)

キーの生成

• キーは“tangling”によって生成される:▫ 真の乱数生成出力▫ スタティックな“type”の値

• 保護された(読み取り不可の)レジスタを使用:▫ UID、GID、シードA、シードB

UIDに絡んだシードB == GenID_2B

• キーを生成するため、GenID_2Bを用いて以下のように暗号化:▫ [4 バイトマジック = 0xFF XK1][4バイト 0s][192ビットの乱数]


• メモリ暗号化のセットアップ後、SEPは暗号化メモリを使用するために再び初期化:

▫ ページテーブル

▫ スタック

▫ データ

• 初期の低能力のブートストラップとの間でコード共有なしの新しいメッセージループを開始

TZ0 と TZ1 の設定

Ping送信

Send BootTZ0

Ping送信

Acknowledge Ping

Map in TZ0


Acknowledge BootTZ0


iBoot

Kernel

Stage 3

Stage 2

SEP ブートフロー: ステージ3

ART送信

AP

Acknowledge Ping

SEP

Acknowledge ART

Copy in ART

共有メモリのアドレスを送信

SEPOS送信

Copy in SEPOS

Validate SEPOS and ART

Acknowledge SEPOS

SEPOSのブート

ブートローディング: Img4

• SEPはASN.1 DER エンコードに基づく“IMG4”ブートローダフォーマットを使用▫ 64bit iBoot/AP ブートROMと酷似▫ ”openssl -asn1parse”でパース可能

• SEPの使用する重要な3つのオブジェクト▫ ペイロード –

暗号化されたsepファームウェアを格納▫ リストア –

SEPをリストアする際の基本的な情報を格納▫ マニフェスト (またはAPチケット) -

ブートROM設定(およびセキュリティ)のアルファおよびオメガに影響

Img4 - マニフェスト

• マニフェスト(APTicket)には、SEP(OS)を認証し設定するために必要な重要情報のほとんどが含まれている

• 複数のハードウェア識別タグが含まれている▫ ECID▫ ChipID▫ その他

• ソフトウェアとハードウェアの両方で実行時の設定を変更するためにも使用される▫ DPRO –プロダクションの降格▫ DSEC –セキュリティの降格▫ その他…

SEPのImg4パーサのリバース: ステージ1

• 見れないものをどのようにリバースしよう?

▫ 再利用されていそうなコードを探そう!

• IMG4をパースしている別の箇所▫ AP ブートROM –取得には少しの痛み

▫ iBoot –物理メモリからダンプ - 0x8700xx000

シンボルは多くない…

しかし、時にはそれだけで取り出せる…

(iBoot from n51)

SEPのImg4パーサのリバース: ステージ2

• 別ファイルには “Img4Decode” シンボルが含まれている▫ /usr/libexec/seputil

• ユーザランドのIMG4パーサにはよりたくさんのシンボル▫ 正確ではないかも – しかしbindiffの表示は非常に近い

• seputilから推測可能なシンボルが見つかる:

▫ ASN’1 デコーダは libDERをベースにしている Appleが親切にもオープンソースとしてリリースしている

▫ RSA 部分は CoreCryptoによって処理されている

• LibDER + CoreCrypto = SEPのIMG4パースエンジン▫ 動作させるのに適したベースが手に入った

Img4パースのフロー

• SEP ブートROM はAPから sep-firmware.img4をコピー

• DER デコーダの初期化▫ ペイロードとマニフェスト、リストア情報のデコード

• ダイジェストと署名の証明書を検証▫ ルート証明書はブートROMのエンドポイントにハードコード

• マニフェスト内の全プロパティを検証▫ 現在のハードウェア構成に対してチェック

• 全項目パスすれば –ペイロードのロードおよび実行

Img4パースのフロー

AP

ペイロードとマニフェストのデコード

SEP

ダイジェストの検証

証明書の検証失敗

マニフェストの検証

証明書のプロパティに対する検証

ハードウェアのプロパティに対する検証

SEPOSのブート

構成の読み込み

SEP

SEP IMG4送信

セキュアメールボックス

• セキュアメールボックスによりAPはSEPと通信が可能になる▫ inbox(リクエスト)とoutbox(リプライ)の両方の機能

• SEPのデバイスI/Oレジスタを用いて実装▫ SEP構成空間として知られている

割り込みベースのメッセージパッシング

• メッセージ送信時は、APはメールボックスの inboxに書き込み

• このオペレーションはSEPに割り込みを発生させる▫ SEPにメッセージを受信したことを通知する

• リプライ準備が完了した時に、SEPが outboxにメッセージを書き込む▫ APにメッセージの受信を知らせるために、別の割り込みが発生される

メールボックスのメカニズム

StartWrite

operation?Read

operation?No

Yes

Address == Inbox

Data written to outbox?

Update inbox with write data

Generate interrupt for SEP processor

Yes

Ignore write operation

No

Address == Outbox

Yes

Respond to read with nonce data

No

Respond to read with outbox data

Yes

No

Yes

Done

Generate interrupt for AP processor

No

メールボックスのメッセージフォーマット

• 単一メッセージのサイズは8バイト

• フォーマットは受信側のエンドポイントに依存

• 最初のバイトはつねに宛先エンドポイントを指す

struct {

uint8_t endpoint; // destination endpoint number

uint8_t tag; // message tag

uint8_t opcode; // message type

uint8_t param; // optional parameter

uint32_t data; // message data

} sep_msg;

SEP マネージャ

• SEPと通信するための汎用的なフレームワークを提供▫ AppleSEPManager.kext内に実装

▫ IOPの提供する機能のうえに実装

• ドライバはSEPエンドポイントを登録することができる▫ 特定のSEPアプリやサービスと対話するために使用

▫ ユニークなインデックス値が割り当てられる

• またそれぞれ独自の複数のエンドポイントを実装▫ 例えば、SEPコントロールエンドポイント

SEP エンドポイント (1/2)

Index 名称ドライバ

0 AppleSEPControl AppleSEPManager.kext

1 AppleSEPLogger AppleSEPManager.kext

2 AppleSEPARTStorage AppleSEPManager.kext

3 AppleSEPARTRequests AppleSEPManager.kext

4 AppleSEPTracer AppleSEPManager.kext

5 AppleSEPDebug AppleSEPManager.kext

6 <not used>

7 AppleSEPKeyStore AppleSEPKeyStore.kext

SEP エンドポイント (2/2)

Index 名称ドライバ

8 AppleMesaSEPDriver AppleMesaSEPDriver.kext

9 AppleSPIBiometricSensor AppleBiometricSensor.kext

10 AppleSEPCredentialManager AppleSEPCredentialManager.kext

11 AppleSEPPairing AppleSEPManager.kext

12 AppleSSE AppleSSE.kext

254 L4Info

255 Bootrom SEP Bootrom

エンドポイントのコントロール (EP0)

• SEP宛てに発行されたコントロールリクエストを処理

• out-of-lineバッファをリクエストとリプライを設定するために使用

• nonceを生成、読み取り、無効化するためのインタフェースを提供

• SEPマネージャのユーザクライアントは、コントロールエンドポイントと対話するためのサポートを提供▫ SEPユーティリティによって利用 (/usr/libexec/seputil)

コントロールエンドポイントのオペコード

オペコード名称説明

0 NOP SEPの起動に使われる

2 SET_OOL_IN_ADDR out-of-lineバッファのアドレス要求

3 SET_OOL_OUT_ADDR out-of-line bufferアドレスの応答

4 SET_OOL_IN_SIZE リクエストバッファのサイズ

5 SET_OOL_OUT_SIZE リプライバッファのサイズ

10 TTYIN SEP コンソールへの書き込み

12 SLEEP SEPのスリープ

Out-of-line バッファ

• 割り込みベースのメールボックスを使用しての大量のデータ転送は低速▫ Out-of-line バッファは巨大データの転送に使われる

• SEPマネージャはSEPから見えるメモリを割り当てる方法を提供する▫ AppleSEPManager::allocateVisibleMemory(…)▫ 実際に物理メモリの一部を割り当てる

• コントロールエンドポイントはターゲットエンドポイントへのリクエスト/リプライバッファを割り当てるために使われる

エンドポイントの登録 (AP)

Allocate SEP visible memory

Create AppleSEPEndpoint

object

Insert endpoint in endpoint table

OOL buffers required?

Yes

Assign send buffer to endpoint

Allocate SEP visible memory

Register OOL buffer with SEP via EP0

Register OOL buffer with SEP via EP0

Assign receive buffer to endpoint

DoneNo

Start

Physically contiguious memory region

AppleSEPManager::endpointForHandle()

Inserts endpoint at the specified table index

SEP を使用するドライバ

• 現在、いくつかのドライバはその動作のためにSEPに依存している

• 以前はカーネル内に置かれていたドライバのいくつかのパーツはSEP内に移動された▫ Apple(SEP)KeyStore

▫ Apple(SEP)CredentialManager

• ほとんどのドライバはSEP内に対応するドライバを持っている

L4

• マイクロカーネルの一系統

• 1993年にJochen Liedtkeによって発表▫ L3からの発展 (1980年代半ば)

• それ以前のマイクロカーネルの低パフォーマンスに対応するために開発された▫ L3よりもIPCパフォーマンスを10-20倍高速に改善

• 多数の亜種および実装▫ 例：組み込みシステム向けに最適化された L4-

embedded

SEPOS

• Darbat/L4-embedded ベース (ARMv7)

▫ Appleによるカスタマイズ

• 独自のドライバ、サービス、アプリケーションを実装▫ macho バイナリとしてコンパイルされている

• カーネルは最小限のインタフェースセットのみ提供

▫ オペレーティングシステムの多くの部分がユーザランド上に実装

SEPOS アーキテクチャ

SEP Drivers SEP ServicesSEPOS

(Bootstrap Server)

Secure Key StoreSecure Credential

ManagerSecure Biometric

Engine

Hardware

SSEART Manager /

ART Mate

Embedded Runtime (ERT)

libSEPOS

Kernel (L4)

Core SEPOS Components

SEP Applications

カーネル (L4)

• 利用可能な状態にマシンを初期化▫ カーネルページテーブルの初期化

▫ カーネルインタフェースページ(KIP)のセットアップ

▫ ハードウェア上での割り込みの設定

▫ タイマーのスタート

▫ カーネルスケジューラの初期化および開始

▫ ルートタスクの開始

• 小さいシステムコールのセット(~20) を提供

システムコール (1/2)

Num Name Description

0x00 L4_Ipc 2スレッド間でのIPCをセットアップ

0x00 L4_Notify スレッド通知

0x04 L4_ThreadSwitch スレッド実行の切り替え

0x08 L4_ThreadControl スレッドの生成または削除

0x0C L4_ExchangeRegisters 他のスレッドとのレジスタの交換

0x10 L4_Schedule スレッドスケジュール情報の設定

0x14 L4_MapControl 仮想メモリのマッピングまたは解放

0x18 L4_SpaceControl 新しいアドレス空間の生成

0x1C L4_ProcessorControl プロセッサ属性の設定

システムコール (2/2)

Num Name Description

0x20 L4_CacheControl キャッシュのフラッシュ

0x24 L4_IpcControl IPCアクセスの制限

0x28 L4_InterruptControl 割り込みの有効・無効化

0x2C L4_GetTimebase システム時刻の取得

0x30 L4_SetTimeout IPCセッションのタイムアウトの設定

0x34 L4_SharedMappingControl 共有メモリのセットアップmapping

0x38 L4_SleepKernel ?

0x3C L4_PowerControl ?

0x40 L4_KernelInterface カーネル情報の取得

特権システムコール

• いくつかのシステムコールは特権が必要と思われる▫ 例：メモリやスレッド管理の呼び出し

• ルートタスク (SEPOS) のみが特権システムコールを呼び出すことができる▫ 呼び出し側空間のアドレスによって決定される

• 必要時にそれぞれのシステムコールによって行われる検査▫ is_privileged_space()

特権システムコール

SYS_SPACE_CONTROL (threadid_t space_tid, word_t control, fpage_t kip_area,

fpage_t utcb_area)

{

TRACEPOINT (SYSCALL_SPACE_CONTROL,

printf("SYS_SPACE_CONTROL: space=%t, control=%p, kip_area=%p, "

"utcb_area=%p¥n", TID (space_tid),

control, kip_area.raw, utcb_area.raw));

// Check privilege

if (EXPECT_FALSE (! is_privileged_space(get_current_space())))

{

get_current_tcb ()->set_error_code (ENO_PRIVILEGE);

return_space_control(0, 0);

}

...

} INLINE bool is_privileged_space(space_t *

space)

{

return (is_roottask_space(space);

}

L4_SpaceControl

システムコールにてルートタスクのチェック

from darbat 0.2 source

SEPOS (初期化)

• ブート時の初期プロセス (ルートタスク)

▫ 任意の特権L4システムコールを呼び出し可能

• 残りの全てのタスクの初期化および開始▫ SEPファームウェアによって組み込まれたアプリケーションリストを処理

• 各タスクのコンテキスト構造の維持

▫ 仮想アドレス空間、特権レベル、スレッド等に関する情報を含む

• ブートストラップサーバの立ち上げ

SEPOS アプリの初期化

Initialize Apps

proc_create( ) No Last app in list?

Done

Yes

macho2vm( ) thread_create( )

ertp_map_page( )

Read application list from sep-firmware

Compute CRC of loaded images

CRC valid?

Panic

Yes

No

Create and start new thread at app entry point (L4_ThreadControl)

Reads Mach-O header and maps segments

(L4_MapControl)

Creates new process and address space (L4_SpaceControl)

Maps the Mach-O header from physical

memory

Compares CRC with value stored in sep-firmware

アプリケーションリスト

• SEPファームウェアによって組み込まれている全てのアプリケーションの情報が含まれている▫ 物理アドレス (オフセット)

▫ 仮想ベースアドレス

▫ モジュール名とサイズ

▫ エントリポイント

• SEPファームウェアイメージ内のSEPOSバイナリより前にある0xEC8バイトを見つける

アプリケーションリスト

サイズエントリーポイント

仮想アドレス

物理アドレス(オフセット)

ブートストラップサーバ

• SEPOSのコア機能を実装▫ システム、スレッド、オブジェクト(メモリ)マネージメントのためのメソッドをエクスポート

• 組込みランタイム経由でRPCによってSEPアプリケーションに実現可能となる▫ ert_rpc_bootstrap_server()

• Enable applications to perform otherwise privileged operationsアプリケーションに特権操作を実行することを可能にする▫ 例: 新しいスレッドの生成

特権メソッド

• アプリケーションはブートストラップサーバの特定のメソッドを呼び出すために特権が必要▫ オブジェクト/プロセス/acl/マッピング情報の問合せ

• 特権レベルはプロセス生成時に決定される▫ プロセス名は‘A ’から‘ZZZZ’の範囲

▫ 例: “SEPD” (SEPDrivers)

• チェックは各メソッドによって行われる▫ proc_has_privilege( int pid );

sepos_object_acl_info( )

int sepos_object_acl_info(int *args)

{

int result;

int prot;

int pid;

args[18] = 1;

*((_BYTE *)args + 104) = 1;

result = proc_has_privilege( args[1] );

if ( result == 1 )

{

result = acl_get( args[5], args[6], &pid, &prot);

if ( !result )

{

args[18] = 0;

args[19] = prot;

args[20] = pid;

result = 1;

*((_BYTE *)args + 104) = 1;

}

}

return result;

}

送信側のPIDが特権付きかのチェックを呼出し

資格

• いくつかのメソッドは特別の資格を必要とする▫ sepos_object_create_phys()

▫ sepos_object_remap()

• 任意の物理メモリマッピングからの非特権アプリケーションを防止しようとする

• 起動時にプロセスに割り当て▫ 資格決定のために使われる別のテーブル

資格の割り当て

int proc_create( int name )

{

int privileged = 0;

...

if ( ( name >= 'A ' ) && ( name <= 'ZZZZ' ) )

privileged = 1;

proctab[ pid ].privileged = privileged;

proctab[ pid ].entitlements = 0;

while ( privileged_tasks[ 2 * i ] != name )

if ( ++i == 3 )

return pid;

proctab[ pid ].entitlements = privileged_tasks[ 2 * i + 1 ];

return pid;

}

資格の割り当て

タスク名資格

SEPDrivers MAP_PHYS

ARTManager/ARTMate MAP_PHYS | MAP_SEP

Debug MAP_PHYS | MAP_SEP

• MAP_PHYS (2)

▫ アクセス(マップ)するために必要な物理領域

• MAP_SEP (4)

▫ 同上、ただし物理領域がSEPメモリをターゲットとしている場合に必要

SEP ドライバー

• 全てのSEPドライバーのホスト▫ AKF, TRNG, Expert, GPIO, PMGR, 他

▫ 完全にユーザモードで実装

• 各ドライバのデバイスI/Oレジスタをマップ▫ ローレベルなドライバの操作を有効にする

• 専用のドライバAPIを用いてSEPアプリケーションに公開される

▫ ルックアップ、コントロール、読み込み、書き込みのための関数を含む

ドライバの相互作用

SEPOS

SEPDrivers

Lookup handle to SEPD service

Driver

Driver lookupLookup handle to

driver

Driver control / read / write

Perform driver operation

DriverDriver

Registers SEPD service

on startup

Retrieves SEPD thread handle from list

AKF ドライバー

• SEPOS内のAP/SEPエンドポイントの管理

• コントロール (EP0) リクエストの処理▫ 例: リプライおよびレスポンスのためのOOLバッファオブジェクトのセットアップ

• SEPアプリケーションは特定のAPリクエストを処理するために新しいエンドポイントを登録することができる▫ AKF_ENDPOINT_REGISTER (0x412C) コントロールリクエスト

SEP サービス

• さまざまなSEP関連のサービスをホスト▫ セキュアなキー生成サービス

▫ テストサービス

▫ アンチリプライサービス

▫ 資格情報サービス

• 通常、ドライバ上に実装

• サービスAPIのSEPアプリケーションへの提供▫ service_lookup(…)

▫ service_call(…)

サービスの相互作用

SEPOS

sepServices

Lookup handle to sepS service

Service

Service lookupLookup handle to

service

Service callIssue a service

request

ServiceService

Registers sepS service

on startup

Retrieves sepS thread handle from list

SEP アプリケーション

• APで動作する様々なドライバをサポートするように設計▫ AppleSEPKeyStore sks

▫ AppleSEPCredentialManager scrd

• いくつかのアプリは特定のデバイスのみで見られる▫ 例: SSEはiPhone 6以降のみに提供

• 開発ビルドに対して排他的であってもよい▫ 例: デバッグアプリケーション

攻撃界面: SEPOS

• 多くのデータにおいてAPとSEP間での通信する方法が含まれている▫ メールボックス (エンドポイント)

▫ 共有リクエスト/リプライバッファ

• 攻撃者はすでにAPカーネルレベルでの特権を手に入れているという前提▫ EL1での任意コード実行が可能

攻撃界面: AKF エンドポイント

• AKFとともに登録されたすべてのエンドポイントは潜在的なターゲットである▫ SEPドライバとアプリケーションの両方を含む

• エンドポイントを必要としないSEPマネージャ(AP)での登録▫ メールボックスに直接書き込むことができる

▫ 代わりに、我々は独自のエンドポイントをSEPマネージャに登録できる

攻撃界面: AKF エンドポイント

エンドポイント所有者 OOL In OOL Out 注記

0 SEPD/ep0

1 SEPD/ep1 ✓

2 ARTM ✓ ✓ iPhone 6 and prior

3 ARTM ✓ ✓ iPhone 6 and prior

7 sks ✓ ✓

8 sbio/sbio ✓ ✓

10 scrd/scrd ✓ ✓

12 sse/sse ✓ ✓ iPhone 6 and later

List of AKF registered endpoints (iOS 9) and their use of out-of-line request and reply buffers

攻撃界面: エンドポイントハンドラ

SEP バイオメトリクスメッセージハンドラ

耐攻撃性

• SEPの脆弱性を攻略するためにはどれくらいの労力が必要か?

▫ 例: スタック/ヒープの改変

• 複数の要因によって決定される▫ アドレス空間のレイアウト

▫ アロケータ(ヒープ)の堅牢化

▫ エクスプロイットの緩和策

▫ その他

アドレス空間のレイアウト

• SEPアプリケーションは適切なベースアドレスにロードされる▫ イメージベースのランダム化なし

▫ 典型的には 0x1000 または 0x8000 に配置(ページゼロセグメントの存在に依存)

• 適切なメモリ保護マスク(!=0)のないセグメントは無視される▫ 例: __PAGEZERO は決して「マップ済み」とならない

Stack

TEXTMain Thread

Thread 2

Stack

DATA

MappingThread 3

Stack

Virtual Memory

System stack (0x1000 bytes)

Application Image

スタックの改変

• SEPアプリケーションのメインスレッドはイメージ埋め込みのスタックを使用▫ 破壊により隣接するDATAセグメントのデータを上書きする可能性

• SEPOSによって起動された追加スレッドのスタックはオブジェクトを使用してマッピングされる▫ ギャップとともに配置 “保護ページ”

スタックの改変

• SEPアプリケーションはスタックcookie保護付きでコンパイルされる▫ Cookieの値は ‘GARD’の固定値

▫ 偽造/バイパスは簡単

• スタックはほとんどの場合既知のアドレス▫ メインスレッドのスタックは既知のアドレス上にある

▫ 後続スレッドのスタックのアドレスは予測可能

ヒープの改変: malloc()

• SEPアプリの使っているランタイムアロケータ▫ K&R 実装

• ポインタとブロックサイズを含むヘッダを持つ単一のリンクフリーリスト(サイズ順に並んでいる)

▫ struct Header { void * ptr, size_t size };

▫ free()時に隣接する要素を結合

• ヒープサイズは初期化時に決定される▫ malloc_init( malloc_base, malloc_top );

▫ 拡張しない


Next

Size

Data (Free) Data (In Use)

Next

Size

Data (Free)

Free List Next

Size

Image DATA segment


• ヒープのメタデータに対する保護はなし▫ フリーリストポインタの上書きが可能

▫ ブロックサイズの改変の可能性がある

• 割り当てアドレスが予測可能▫ アプリケーションイメージ内の__DATAセグメントによって埋め込まれたMallocエリア

▫ 連続の順序でアロケートされる

非実行保護

• SEPOS は非実行の保護機構を実装している

• ページが実行可能とマークされていない限りは常にセットされる▫ space_t::map_fpage()

▫ ページテーブルエントリの XN と PXN ビットがセット

• ノンセキュア (NS) ビットもSEPメモリの領域外すべてのページにセットされる

SEPOS 緩和機構まとめ

緩和機構提供注

スタックcookie保護 Yes (…) ‘GARD’ –たいていは効果なし

メモリレイアウトのランダム化

ユーザー No

カーネル No イメージベース: 0xF0001000

スタックガードページ Yes/No メインスレッドにはなし

ヒープメタデータ保護 No

Nullページ保護 No ルートタスクのページマップ必須

非実行保護 Yes XN と PXN両方

攻撃界面: ブートROM

• 効果的であるのは2つの大きな攻撃界面のみ▫ IMG4 パーサ

メモリ破壊

ロジックの不備

▫ ハードウェアベース

• マイナーなアンチexploitの緩和策のみ提供▫ ASLRなし

▫ 基本的なスタックガード

▫ ひとつでも適当なバグがあればゲームオーバー

IMG4の攻撃

• ASN.1はうまく動作させるために非常にトリッキーである▫ OpenSSL, NSS, ASN1C, その他に多くの脆弱性

• LibDER自体は比較的信頼できる▫ “他のDERパッケージと違い、LibDERではエンコードやデコードの際にmallocやコピーを行いません”

– LibDERの readme.txt

▫ KISS の設計思想

• しかし、それを呼び出すラッピングコードはそうではない▫ seputil やそれに類するもの

▫ コードが libDER自身より非常に複雑

攻撃界面: ハードウェア

• データ受信のための周辺信号ライン上でのメモリ破壊攻撃▫ SPI ▫ I2C▫ UART

• サイドチャネル/差動電力解析▫ A7特有 (新しいものほど耐性がある)

• グリッチ▫ 標準クロック/電圧方法▫ 他

外部RAM

• 暗号化メモリは検証されない▫ SEPメモリのビット破壊が可能

• 暗号キーを生成する際に、“ランダム要素”が暗号なしの外部RAMに一時的に保存される

▫ これにより攻撃者は最終的なメモリ暗号キーの生成に対して影響を与えることができる

ヒューズアレイへの攻撃

• 潜在的にもっとも侵略的な攻撃ベクタのひとつ▫ 多くの忍耐が必要

▫ 高い可能性

• レーザーが使用可能▫ 高価な手法 -我々向けではない

• 主なターゲット▫ プロダクションモード

▫ セキュリティモード

終盤: JTAG

▫ 2000以上のピンのソケットが必要

▫ CRCとヒューズ封印のバイパスが必要

▫ “FSRC” ピン - ヒューズアレイへのライン?

• ヒューズ検知ルーチンの誤動作

• IMG4 パーサの攻撃▫ DSECとDPROはそもそも本当に何を行う?

A8 SoC Pins

まとめ

• SEP(OS) はセキュリティを考慮して設計されている▫ メールボックスインタフェース

▫ 権限の分離

• しかし、SEP(OS)からは基本的な攻撃対策が欠けている▫ 例えば、メモリレイアウトのランダム化など

• いくつかのSEPアプリケーションは重大な攻撃界面を露出させている▫ 例： SEP バイオメトリクスアプリケーション

まとめ (続き)

• 全体的なハードウェアのデザインは競合よりもはるかに先▫ ハードウェアフィルタ

▫ インラインでの暗号化されたRAM

▫ 一般的には小さい攻撃界面

• しかし、弱点もある▫ 共有 PMGR と PLL は攻撃に対してオープン

▫ ヒューズソースピンが含まれていることは再考に値する

▫ 降格機能はむしろ危険であるように見える Lightning経由のJTAGがなぜ存在している?

Thanks!

• Ryan Mallon

• Daniel Borca

• Anonymous reviewers

SEPOS: システムメソッドクラス Id メソッド説明特権

0 0 sepos_proc_getpid() プロセスのpidを取得

0 1 sepos_proc_find_service() 登録済みのサービスを名前から検索

0 1001 sepos_proc_limits() プロセスの制限情報を問い合わせる x

0 1002 sepos_proc_info() プロセス情報を問い合わせる

0 1003 sepos_thread_info() スレッドの情報を問い合わせる

0 1004 sepos_thread_info_by_tid() スレッドIDの情報を問い合わせる

0 1100 sepos_grant_capability() - x

0 2000 sepos_panic() OSをパニックにする

SEPOS: オブジェクトメソッド (1/2)

クラス Id メソッド説明特権

1 0 sepos_object_create() 匿名オブジェクトを生成

1 1 sepos_object_create_phys() 物理領域からオブジェクトを生成 x (*)

1 2 sepos_object_map() タスクのアドレスにオブジェクトをマッピング

1 3 sepos_object_unmap() オブジェクトのマップ解除(未実装)

1 4 sepos_object_share() オブジェクトをタスクと共有

1 5 sepos_object_access() オブジェクトのアクセス制御リストを問合わせ

1 6 sepos_object_remap() オブジェクトの物理領域を再マッピング x (*)

1 7 sepos_object_share2() マニフェストをタスクと共有

SEPOS: オブジェクトメソッド (2/2)

クラス Id メソッド説明特権

1 1001 sepos_object_object_info() オブジェクトの情報を問い合わせる x

1 1002 sepos_object_mapping_info() マッピング情報を問い合わせる x

1 1003 sepos_object_proc_info() プロセス情報を問い合わせる x

1 1004 sepos_object_acl_info() アクセス制御リスト情報を問い合わせる x

SEPOS: スレッドメソッドクラス Id メソッド説明特権

2 0 sepos_thread_create() 新しいスレッドを生成

2 1 sepos_thread_kill() スレッドをKillする (実装されていない)

2 2 sepos_thread_set_name() スレッドのサービス名を設定

2 3 sepos_thread_get_info() スレッドの情報を取得

solnik secure enclaveprocessor-pacsec-final-jp

Internet