スマホ端末、制御システムの堅牢化 ·...

Ⓒ2014 KDDI R&D Laboratories Inc. 1

ネットに繋がるスマホのリスク分析と課題解決を進めてきた。この過程で、制御（組込み）システムの堅牢化が見えてきた。

1章スマホ端末への攻撃 2章スマホ端末の堅牢化 3章制御（組込み）システムへの攻撃 4章制御（組込み）システムの堅牢化

スマホ端末、制御システムの堅牢化～2020年に向けた繋がる組込みシステム～

KDDI研究所　　竹森敬祐（Ph.D)


スマホを取り巻く脅威 ■ 使い方　◆ 様々なアプリをインストールし　　　て機能アップさせる携帯端末。 ■ スマホのセキュリティ　　　Market(アプリ)のセキュリティ　◆ 安全なMarket／サービス利用　　　で、安心して楽しめます。 ■ 残る脅威は　◆ リスクを伴うソフトウェア　　　（リスクウェア）　◆ 利用者モラル　◆ 紛失

紛失

デバイス（GPS、カメラ、NFC、SDカード、SIM/UIM）

OS(カーネル、ライブラリ、サンドボックス）

アプリデータ

（メール、写真、アドレス帳）

３G/LTE（電話/SMS、パケット）

WiFi、Bluetooth(パケット)

アプリ、コンテンツ

アプリ・マーケット

SNS、Webサービス

広告、アプリ管理

サービス提供

悪用

不正改造管理者権限奪取

感染

盗聴不正課金

ネットワーク

端末

利用者モラル悪性Webサイト（詐欺）

プライバシー侵害

情報漏洩

リスクウェア(悪用、悪意、プライバシー侵害、偽物）

Ⓒ2014 KDDI R&D Laboratories Inc.

公開されている一般の脆弱性DB

3

JVN : Japan Vulnerability Notes (JPCERT/CC , IPA ) Android ：　103

CVE : Common Vulnerability and Exposures (米国政府 , MITRE社)

Android　：　187


◆　zergRush exploit oneclick tool （runme.bat）の実行プロセス Ø  android 端末とPC をusb 接続し、コマンドラインより

“runme.bat” を実行、下記プロセスが実行される。

①android 端末　作業用ディレクトリ作成 ②zergRush exploit code 送信、実行権付与、実行 ③root 権限の取得 ④system 領域のremount 　 ⑤su　/ busybox ツールのsystem領域への挿入 ⑦SuperUsr.apk アプリのインストール ⑥system 設定変更 ⑦端末reboot ⑧adb 接続しsu command による id変更要求 ⑨superuser.apkが起動　⇒　get root !!

Ø  上記①～⑦までを自動実行（runme.bat）

・①～③まではzergrush を利用したroot権限取得・④～⑦は恒久的はroot 権限を使用するための作業

一時的 Root 奪取

恒久的 Root 奪取

runme.bat (root oneclick tool ) +files /adb.exe/busybox/su /superuser.apk/zergRush

脆弱性を突くJailbreak（root権限奪取とシステム改造）


スマホ・タブレットのリスク

■ スマホにウイルス*なし　◆ PCのような自動的／伝播的なウイルス感染はない。** 　◆ PCのように、クリックするだけで感染することもない。　　　⇒ Marketから駆除されることで、絶滅する。

　　*ウイルスとは、ファイルやネットワークを媒介して自動感染（伝播）するもの。　　**手動感染した後は、自動感染はありうる。 ■ アンインストールで元通りに　◆ 殆どの悪意のアプリ（マルウェア）は一般権限で、/data領域にイ　　　ンストールされる。　　　⇒ /system領域の改竄に至らずアンインストールで元通りになる。　　　⇒ 但し、抜き取られた情報は元には戻らない。

　◆ 希少なJailbreakアプリは管理者権限を持ち、端末改造に至る。


分析：Jailbreak（root権限奪取とシステム改造）の流れ ■ 攻撃のシナリオ　Step1: root権限奪取アプリをユーザ領域にインストールする（感染）。　Step2: 実行され、OS等の脆弱性を突いてメモリ上でroot権限を奪う（攻撃）。　Step3: システム領域に恒久的にroot権限を利用できるようsuを置く（改造）。

展開されたシステム領域

メモリ：RAM

フラッシュ・ストレージ

システム

領域

ユーザ領域

MalwareStep1

実行（ロード）

一時的なroot権限奪取

脆弱性攻撃

Step2

改造

Step3

恒久的なroot権限奪取

su

感染


端末・OSの堅牢化　～不正改造対策～

8

アプリ制御・ライブラリ

デバイス（WiFi, GPS, カメラ等）

サンドボックスDalvik（制限機構）

一般アプリ

root化アプリ

SELinuxの制限機構

サンドボックス連携の制限機構

Linuxカーネル

Linuxのｒ/w/x制御

カーネル層から堅牢にしておいたことで、完全乗っ取り型の遠隔制御の被害確認なし

■ 端末の堅牢化（Security Spiced Android）　◆ 端末メーカ、通信キャリアの領域である/systemを保護する（例　　　/system/binにsuを置かせない）ことで攻撃の影響を最小化する。


SEAndroidの導入

9

■ Security Enhanced Android 　◆ アメリカ国家安念保障局（NSA）がSELinuxをAndroidに適用。　　　⇒ root権限奪取の糸口を減らす。　　　⇒ root権限を奪取されても、できることを減らし、被害を抑え込む。 ■ アクセス制御　◆ 通常Linuxの任意アクセス制御（DAC: Discretionary Access Control）

リソースに対する所有者権限による制御 rwx r-x r-x 755 /data/aaa.txt owner group other 　　　⇒ rootは全てにアクセス可能 = rootが取られるとおしまい。

　◆ SELinuxの強制アクセス制御（MAC: Mandatory Access Control) 　⇒ 「誰が」「何に対して」「何をできる」のホワイトなルールセット。　⇒ 明示的な許可の無い組み合わせは、root権限であっても禁止


SEAndroidのモード

10

■ Disable （ver4.2）　◆ SELinuxが無効なモード。　◆ Android4.3からSEAndroidを無効にするオプションがない。 ■ Permissive Mode （ver4.3）　◆ ポリシー違反をログ出力し、制御は行わない。　　　⇒ dmesg or /data/misc/audit/audit.log

■ Enforcing Mode （ver4.4）　◆ ポリシーに基づきアクセス制御を行う。　　　⇒ 現在、AOSP*のmaster branchは、Enforcing Modeを採用。

＊Android Open Source Project


KDDI研） Android（ARM）＋TPMのセキュアブート ■ 世界初のAndroid端末のセキュアブート（2012年）　◆ Android搭載のARMボードにTPMを接続して、完全性検証を試作。　◆ 端末起動時に、ブートローダ、Android OS、アプリの状態を測定。　◆ 測定結果を、遠隔の状態管理局に送付し、完全性をリモート検証する。

デモ構成

遠隔の状態管理局

Android(ARM), TPM

起動時の測定ログ

Boot Loader 1

TPM

Boot Loader 2

Linuxカーネル

外部の状態管理サーバ

Root of Trust端末（メモリ＋CPU処理）

署名(秘密鍵）

Boot Loader 2の期待値

認証（秘密鍵）

測定

認証（公開鍵）

Step1

測定

検証

測定値(Android, ｱﾌﾟﾘ）

Androidシステム/system, etc

測定

Init(+測定機能)起動用ﾌｧｲﾙｼｽﾃﾑ

署名

署名

起動

起動

起動

署名

アプリ/data/app, /data/app-private, /sd_card

測定起動

期待値（Android, ｱﾌﾟﾘ）

Step2

Step3

Step3'

Step4


実装） SIMを活用したセキュアブート

SIM/UIM、3Gモデム（SIM/UIMドライバ）


Step 2) Linuxカーネル、Intramfsを測定、測定値をSIM/UIMへ保存。Linuxを起動。

13

2014年 ARM＋SIM/UIMのセキュアブート

Step 3) Androidシステムを測定、SIM/UIMへ測定値を保存。Androidシステムを起動。

Step 1) SIM/UIMドライバを測定、SIM/UIM起動、測定値をSIM/UIMへ保存。

ROM化されたBoot Loaderから測定

Step4) 所望のアプリを測定、測定値をSIM/UIMへ保存。

Linuxカーネルのinitから測定

ROM化されたBoot Loaderから測定

Linuxカーネルのinitから測定

Step5) 署名付測定値を検証サーバへ送付。

Boot Loader

SIM/UIM

Linuxカーネル

外部の検証サーバ

Root of TrustARM端末

測定値（ﾊｯｼｭ値）管理Javaアプリ

測定

署名検証（公開鍵）

Step 1保存

測定値

Androidシステム/system, etc

測定

init(+測定機能)Initramfs

署名

保存

起動

起動

アプリ/data/app, /data/app-private, /sd_card

測定起動

期待値（3G/LTEﾓﾃﾞﾑ, Linux, Android）

Step 3

Step 4

Step 5

ﾊｯｼｭ積算値+ + +

署名(秘密鍵）

SIM/UIMドライバ(3G/LTEモデム)

Step 2

+

Linuxｶｰﾈﾙ,init

Androidｼｽﾃﾑ

アプリ

SIM/UIMﾄﾞﾗｲﾊﾞ

ﾊｯｼｭ（測定値）

+

+

+

+

署名


SIM/UIMドライバ、Linuxカーネル、initramfs測定

Step 1

Step 2

Step 2


本研究におけるポイント

■ Root of Trustの構築　◆ eMMCフラッシュメモリ搭載のARM端末は、ブートローダをROM 　　　焼きすることができ、Root of Trustとして利用できる。 ■ 測定結果をSIM/UIMで担保　◆ SIM/UIMをセキュアブート機構を持つ端末にのみバインドさせる。　◆ 起動の初期段階（＝ブートローダ）からSIM/UIMを起動させ、早々　　　に測定結果を保存する。　◆ SIM/UIM内のTPMモドキのPCR（レジスタ）を設ける。 ■ ハッシュ測定にARM上のCPUをフル活用　◆ SIM/UIM側でのハッシュ測定は、大きな時間を要する。


SIM/UIMの端末バインド ■ SIM/UIMの端末バインド　◆ 悪意のARM端末が、正常起動した端末のように見せかける攻撃が想定される。　　　⇒ 正規のセキュアブート機構を持つARM端末に当該SIM/UIMが挿入されたと　　　　　きのみハッシュ測定値を管理するようにしなければならない。

マスタ鍵：Km

SIM/UIMARM Secure World(揮発性メモリ(DRAM))＝ブートローダ

ﾌﾟﾛｸﾞﾗﾏﾌﾞﾙROM（一度限りの書込）

ARMNormal World(揮発性メモリ(DRAM))

フラッシュメモリ（不揮発性メモリ）

暗号化された秘密鍵:Km（Ks）

署名：Ks(nonce）

秘密鍵の復号と管理 Ks=Km(Km(Ks))

スマホOS

スマホOS

端末認証

乱数生成:nonce

端末[メーカ,機種]の公開鍵Kpリスト

署名の復号: nonce=Kp(Ks(nonce))

各種アプリ

nonce

Ks(nonce)






用語）本稿では、制御系システムを広く捉えることを念頭に、Electric Control Unit（ECU）を Micro Computing Unit（MCU）に置き換えて説明する。略語）Controller Area Network（CAN）


■ 制御システムを信じれますか？　◆ 組込みシステムのH/Wや制御コードのセキュリティ対策が足りない?! 　　　⇒ Micro Control Unit(MCU)の制御コード、取替えは容易。　　　⇒ 通信相手からのパケットを全て信じて動作する性善説のモデル。

社会インフラ（制御システム）が危ない?!

■ 2020年に向けた脅威　◆ 様々な物がNWを介して繋がる。　⇒ 社会インフラを狙ったテロ ■ ターゲット例　◆ スマートメータ ⇒ 停電　◆ 監視カメラ ⇒ 証拠性なし　◆ 車載制御システム ⇒ 交通事故　◆ 航空機・管制システム ⇒ 大事故　◆ カーナビ ⇒ 渋滞誘発　◆ プラント ⇒ 製品不具合

Internet

スマートメータ

監視カメラ車／飛行機

スマホ／カーナビ

プラント


電力網、プラントへの攻撃

■ ブラックアウト（角川文庫）　　マルク・エルスべルグ (著) 　猪股和夫 (翻訳), 竹之内悦子 (翻訳)

　◆ スマートメータに感染し、一斉に電力消　　　費量を増加させることで、発電所・送電　　　網を停止させる。　◆ 発電所システムの計器に感染し、周波　　　数の同期外れを誘発させ、停電させる。 ■ スタックスネット（2011年09月28日(水) 読売新聞・39頁）　　　http://www.takara-sign.com/r_blog_2011/s_images/2011-10-01-virus-001s.jpg

　◆ イランの核施設システムに感染し、遠心　　　分離機の回転数を狂わせ、兵器に利用　　　できうる濃縮ウランを作らせない。


車載システムへの攻撃

偽チップ（複製）または、ソフトウェアの改竄

MCUの改竄

⇒純正と偽った商品の流通　　　（ＥＶ/ＰＨＶ用バッテリー、電源ケーブル等）保証されていないバッテリーの使用最悪は燃えるケースも

⇒自動車の盗難（イモビライザーへのアタック等）イモビライザーを攻撃　⇒鍵が無くても車を盗難可能

偽造チップ Renaissance


偽造バッテリー

個人情報


クレジットカード情報、個人住所などの悪用被害金額が膨大になる。

⇒バックドアを使った個人情報の流出

リミッターカット、燃料費調整など　⇒重大事故への発展。車の寿命も短くなる。

⇒MCU内部の設定変更（リミッターカット等）

タコメーターの初期化　⇒中古車市場における不正な金額での取引　　　最悪はカーメーカーの信用を落とすことも

⇒走行距離の偽造


攻撃者、ターゲット、攻撃術、被害

インフォテイメント系 AV、ナビ、ETC等

駆動系エンジン、ミッション等

安全制御系ブレーキ、ステアリング等

車体系メータ、エアコン等

制御用車載ネットワーク CAN、LIN、RlexRay等

外部端末スマホ、AVプレーヤ等

診断ポート書換えツール等

車メーカ

悪性サイト

マルウェア

レンタル

利用者

窃盗団

車検

廃棄

内外GW

外部サイト一般Web、管理サーバ等

不正制御[交通事故] WiFiパケット盗聴[プライバシ侵害]

イモビ・カッター[盗難] 距離メータ改竄[中古車不正販売]

廃棄品等の再利用[ニコイチ車の販売、メーカ(OEM)の信頼低下]

なりすましリプレイ

改竄

取替

不正制御


欧州自動車市場でのセキュリティ要求

欧州を中心とした、自動車へのｾｷｭﾘﾃｨ実装のニーズ高まり。 �　　　⇒　MCUの不正改竄防止、ﾘﾌﾟﾛｸﾞﾗﾐﾝｸの保護　 �　　　⇒　MCUの認証/ﾃﾞｰﾀの暗号化が必須�

世界規模で広範囲の�

車載用途に対して、 �

ｾｷｭﾘﾃｨ機能搭載が �

展開されていく方向�

アイデア/コンセプトのステージ �

計画の具体化要求�

2008年4月： “SHE” (H/Wによる暗号処理）のAudiによる議論開始�

2009年4月： “SHE” の仕様がHIS �（独のｶｰﾒｰｶｰ団体）を通じて公表される�

2008年7月：BMWをﾘｰﾀﾞｰ、Boschをﾊﾟｰﾄﾅｰに、　欧州ﾌﾟﾛｼﾞｪｸﾄ “EVITA”ｽﾀｰﾄ �

　2009年7月：　“HSM” (HW Security Module)搭載要求�

　　2010年6月：車両ﾌﾟﾗｯﾄﾌｫｰﾑに“SHE” 対応要求�

2010年7月： EVITAが3種類の “HSM”を � secure on-board architectureに規定�

２０１１年１２月に耐タンパを含めた議論（ＰＲＥＳＥＲＶＥ）が欧州でスタート






用語）本稿では、制御系システムを広く捉えることを念頭に、Electric Control Unit（ECU）を Micro Computing Unit（MCU）に置き換えて説明する。略語）Controller Area Network（CAN）


提案）脅威と対策

■ MCUとCANを狙う攻撃　◆ MCUコードの改竄・感染、 MCUの取替えによるシステムの不正制御。　◆ CANを流れるパケットのなりすまし、改竄、リプレイ攻撃。 ■ 対策（目標）　★ 「MCUのセキュアブート」と「制御パケット単位での認証」が必要　◆ MCUが完全な状態で起動したことを保証する（セキュアブート）。　　　⇒ ROM（Root of Trust）とセキュアエレメント（Secure RAM、Secure ROM）で実現。　◆ CANを流れるパケットが、本物のMCUから発信され、改竄やコピーされていな　　　いことを保証する。　　　⇒ 送信元MCUの認証　　　⇒ 送信パケットの完全性の検証　　　⇒ リプレイ阻止のワンタイム性　　　　　⇒ Media Authentication Code（MAC）　　　　　　＝hash（制御データ、認証のための秘密の情報、パケットカウンタ）


セキュアMCUを活用した対策

インフォテイメント系 AV、ナビ、ETC等

駆動系エンジン、ミッション等

安全制御系ブレーキ、ステアリング等

車体系メータ、エアコン等

制御用車載ネットワーク CAN、LIN、RlexRay等

外部端末スマホ、AVプレーヤ等

診断ポート書換えツール等

内外GW

外部サイト一般Web、管理サーバ等

なりすましリプレイ

改竄

取替

不正制御

(1)  MCUのｾｷｭｱﾌﾞｰﾄ（完全性検証） (2)  MCUの認証 (3)  CANパケットの認証、リプレイ阻止

MCU認証ｾｷｭｱﾌﾞｰﾄ

パケット認証


■ 制御システムの保護　◆ Root of Trustとセキュアエレメントを持つMCUで制御システムを構築　　　(1) Root of TrustからマスタMUC・エンドMCUの系全体のセキュアブート　(2) 起動後に、マスタMCUからエンドMCUをチャレンジレスポンス認証。　(3) エンドMCUをパケット単位で認証することでなりすまし／リプレイ検知

Secure RAM/ROM＋Root of Trustを持つMCU

エンドMCU

Root of TrustBoot LoaderのROM化

ｾｷｭｱｴﾚﾒﾝﾄ：専用

マスタMCU


ｾｷｭｱｴﾚﾒﾝﾄ：eSIMSecRAM（暗号処理）SecROM（鍵管理）

ハンダ付け

Flashコード+署名

RAM実行領域


RAM実行領域

偽エンドMCU


RAM実行領域

制御バス

SeｃRAM（暗号処理）

SecROM(鍵管理）

エンドMCU




RAM実行領域


SecROM(鍵管理）

■ 攻撃 - 偽制御パケット送信 - リプレイパケット送信

■ 構成 - 鍵なし


（１） MCUのセキュアブート～改竄対策～ ■ MCUの構成要件　◆ セキュアブートの基点となるRoot of Trustに、Boot Loaderを組み込む。　◆ 安全な情報管理領域（Secure ROM）と、安全な情報処理領域（Secure RAM）　　　から成るセキュアエレメントで、署名検証を行う。

■ 署名検証方式のセキュアブートの流れ Step 0) ROM化（Root of Trust）されたBoot Loaderを起動する。 Step 1) Boot Loaderは、Flashメモリから署名付き制御コードを読み込　　　　　み、制御コードのハッシュ値を算出する。 Step 2) ハッシュ値と署名をセキュアエレメントに送付し、Secure ROMで　　　　　管理されている署名検証鍵を用いて、ハッシュ値と、署名から取　　　　　り出したハッシュ値が一致するか、確認する。 Step 3) 一致した場合には、検証OKとして、Boot Loaderに通知する。 Step 4) Boot Loaderは、読み込んでいた制御コードをRAMに展開する。

エンドMCU



RAM実行領域



SecROM(鍵）

1.読込

2.ハッシュ値＋署名

3.検証結果

4.ロード

■ 実装　◆ ボード：HSBV850E2FG4-Lボート（CPU 60MHz）　◆ CPU:TOPPERS/ATK2-SC1 1.3.0 　⇒ ハッシュ測定時間： 110msec／60KB


（１） MCUのセキュアブート～改竄対策～ ■ 評価ボード　◆ テセラ　FL-850/F1L-176-S 　http://www.tessera.co.jp/fl/f1l-176.html ■ MCU 　◆ ルネサスエレクトロニクス　RH850F1L 　http://japan.renesas.com/products/ 　mpumcu/rh850/rh850f1x/rh850f1l/index.jsp ■ 統合開発環境　◆ ルネサスエレクトロニクス　CubeSuite+ for V850 　http://www.digikey.jp/product-search/ja?vendor 　=0&keywords=CUBESUITE+for+V850 ■ OS 　◆ TOPPERS　ATK2-SC1のRH850向け最新コード　　　をチューニング。　https://www.toppers.jp/atk2-download.html


（２）セキュアエレメントを用いたMCU認証～取替対策～ ■ チャレンジレスポンスによるMCU認証　◆ システム起動時に、マスタMCUからエンドMCUをチャレンジレスポンスで認証。　　　⇒ 認証用の公開鍵・秘密鍵は、セキュアエレメントで管理。　◆ マスタMCUのセキュアエレメント内で秘密の情報を生成し、エンドMCUのセキュ　　　アエレメントに秘密の情報を、暗号化して渡す。

エンドMCU


マスタMCU

ｾｷｭｱｴﾚﾒﾝﾄ：eSIM

FlashRAM初期乱数

Flash RAM


SecROM(鍵管理）

秘密鍵Ks

Step a)チャレンジ（初期乱数）

起動時認証(署名)


SecROM(鍵管理）

秘密の情報（乱数）

公開鍵Kp

起動時認証

Step b)レスポンスKs（初期乱数）

Step c)Kp(乱数)

通信バス

秘密の情報（乱数）


（３）MACによるCANパケット認証～不正制御対策～ ■ カウンタ⇒セキュアエレメント　◆ RAMでカウンタ値を管理しておき、セキュアエレメントに渡す。　◆ セキュアエレメントで、MAC（データ、秘密の情報、パケットカウンタ）を算出する。

送信側MCU

ｾｷｭｱｴﾚﾒﾝﾄ

受信側MCU

ｾｷｭｱｴﾚﾒﾝﾄ

Flash RAMカウンタ

FlashRAMデータ、カウンタ


SecROM(鍵管理）

Hash（データ,秘密の情報,カウンタ）に置き換えたMACパケット送信

パケット単位の認証情報(MAC)の生成


SecROM(鍵管理）

パケット単位の認証情報（MAC)の検証

通信バス

秘密の情報（乱数）秘密の情報（乱数）

Step Ⅰ)

Step Ⅱ)

Step Ⅲ)


Recessive

Dominant idle S

O

F 1

ID

11

RTR

1 6

Control Field

Data Field 0-8 Bytes

0 … 64

idle

CRC ↓

MAC

CRC Delimiter ACK Slot

ACK Delimiter

E O

F ITM

15 1 1 1 7 3

Data Frame Inter Frame

Space Inter Frame Space

IDE r d3 d2 d1 d0

0 0 Data Length Code / DLC

Reserved

CAN-L2SEC type1 Standard Format (ID 11 bit)

IV 64

HMAC Data

■ CANパケットのセキュリティ対策　◆ 送信元MCU認証、データ改竄検知、リプレイ攻撃の阻止を行う。　　　⇒ MAC hash（データ、秘密の情報、パケットカウンタ）　◆ MACは、CANのデータ領域（Layer3）、もしくはCRC部（Layer2）に、MACの一　　　部を埋め込む。

（３）MACによるCANパケット認証～不正制御対策～


まとめ　～セキュアブート＋MCU認証＋パケット認証～マスタMCU（通信GW）

エンドMCU／セキュアCAN

タミヤTT-01

(1)  MCUのｾｷｭｱﾌﾞｰﾄ（完全性検証） (2)  MCUの認証 (3)  CANパケットの認証、リプレイ阻止

エンドMCU



RAM実行領域



SecROM(鍵）

1.読込

2.ハッシュ値＋署名

3.検証結果

4.ロード

スマホ端末、制御システムの堅牢化 ·...

Documents