組込みシステムセキュリティの 考え方と対策

--- 研究サイドから実用化への取り組み

大岩 寛 （産総研 情報技術研究部門）

2015年8月6日

組込みソフトウェアの高信頼化 • 人の命を預かる 組込みソフトウェア – 航空機・鉄道車両 – 自動車 – 消費者機械 – インフラ（電力等） – 医療・ヘルスケア

• 数々の事故事例 • 2008: モノレール暴走 • 2008: エアバス乱降下 • 2000: 放射線誤照射 • Etc. etc…

2

信頼できないソフトによる障害事例

• 湘南モノレール線車両暴走事故 – 駅で車両が停止できず信号冒進 – 運輸安全委員会の調査で 加速制御装置の ソフトウェア不良が判明 (RA2009-6)

• 異常時処理に2つの誤り – 入力を受け付けなくなる

= 加速状態が解除できない – 故障検知装置 (WDT) も 入力を受け付けない状態を 正常動作と誤認識

• アクセルとブレーキを 両方働かせた状態で駅に進入

3

国土交通省運輸安全委員会 鉄道事故調査報告書RA2009-6 より

安全性とセキュリティ

• 組込みシステムに安全性とともに セキュリティが求められる時代の到来 – もはや「組込みの閉じた世界」は存在しない

•スマートフォン・携帯ネットワークの台頭 •家電・カーナビなどのインターネット接続

– 経由した間接的な侵入経路の確立

•センサーネットワーク・Internet of Things・ スマートグリッドなど

– 社会インフラのネットワーク協調動作

4

IoT による爆発的な機器数の増加

• 「もののインターネット」による 組込み機器の更なる増加 – “Trillion Sensors” :「一兆センサー」の時代

• Gartner 予測: 2020年に250億台 •総務省予測: 2020年に 530億台のIoT機器

– 今まで以上に膨大な機器が インターネットで情報を 相互にやり取りする世界が 身近になる

5

IoTとセキュリティ • センサーネットワークの社会基盤化

– 社会にくまなく張り巡らされたセンサー群 • カメラ・各種センサー・自動車・鉄道車輌・航空機 • 携帯電話（スマートフォン）・ウェアラブル機器

– センサーの生み出す膨大なデータ • 人の生み出す情報量を凌駕する自動取得情報量

• センサーの機能不全が社会機能の不全に繋がる

– 乗っ取りによる情報漏洩 – 乗っ取りによる機能の改変・虚偽情報の発信

• 監視カメラをハイジャックして監視を無効に • 虚偽の危機を発信することによる陽動・社会不安

IoTとセキュリティ

• 一方で、従来のセキュリティ対策は IoT には必ずしも向いていないことも

•消費電力の厳しい制限 – 太陽電池・蓄電池での長時間駆動

•間欠的な通信 •物理的に広域に分散した配置

– 監視や修正が今まで以上に困難に

– セキュリティの「作り込み」がますます重要に 7

インターネットに繋がなければ 大丈夫？

• FAQ: 例えば工場の生産システムの様に、 インターネットから切り離せば セキュリティ対策は大丈夫？

• Short answer: NO – 今時 Windows など汎用機器が無い環境は無い – USB 記録媒体などを経由してウィルスは侵入 – 実際、2010年に中東の核燃料工場に侵入

• Stuxnet: 隔離環境下の遠心分離機を実際に破壊 •それ以降、制御システムセキュリティは大問題に

8

高信頼ソフトウェアの目的

• 最終的な目的: 安心して使えるシステム (ユーザにとって)

• 正しいソフト（開発者にとって） – 作者の元々の目的・意図通りに動くソフト

• アプローチ

– 安全なソフトウェア（誤動作しない） – セキュアなソフトウェア（侵入されない）

9

大事なポイント

• 安全にソフトウェアを作る – システマチックに安全なソフトを構築する

• ソフトウェアが安全であることを調べる

• ソフトウェアが安全なことを説明する – 安全に作ったことの証跡を示す – 自分が調べたことを他人に示す – ソフトウェア安全性の「見える化」

10

組込みシステムとセキュリティ

• まだ確立したセキュリティ保護の 統一的プロセスは存在しない – 通常のソフトウェアのプロセスを応用

•組込みとセキュリティの双方に通じた技術者不足 •組込み特有の制約や前提の整理が進んでいない

– 場当たりな対策の組み合わせでは、 コスト増加と対策の不完全さを招く

プロセスとしてのセキュリティの確立が 今後の大きな課題と認識

11

組込みシステムとセキュリティ

• 技術的には、通常のシステムと 「やるべきこと」は変わらない

• でも、「できること」は異なる – 計算能力（速度・消費電力・メモリ）の制限 – かけられるコストの違い – 要求される安全性・安定性の違い

• 通常のシステムのセキュリティ技術を 理解した上で、取捨選択すべき

12

高信頼システムの実現手段

• 敵を知り、味方を知る – 考えるべき脅威は何か？

•意図的な攻撃 ← セキュリティ •偶然の異常 ← 安全性

– 外部環境の突発的な異常 – 機械自体の誤動作

– とるべき対策は何か？

•導入した対策は何を保証してくれるか – 逆に、何を保証してくれないか？ – 追加で必要な対策は何か

•技術の裏にある思いを理解する 13

高信頼システムの実現手段

• 自分がやったことを説明できるか？ – 見えないもの（ソフトウェア）の安全性を どう信用してもらうか？

•物をきちんと作る ← 出発点 •会社の信用？

– 過去の実績？

•証拠を示せるか？ •第3者のお墨付き？

– 誰のお墨付きなら信用できる？ – お墨付きを出す根拠は？ – 「お墨付きを出す人にどう信用してもらうか？」

14

脅威の把握

• 起こりうる脅威は何かを 「すべて」列挙するプロセス – 機械的にはやりにくい工程

• 後工程でのすべての 安全性作り込みの開始点

• 安全性説明の論拠の開始点 – 「超上流プロセス」の重要性

15

脅威の把握

• セキュリティ的の脅威 – どれだけの「悪意の振る舞い」を想定できるか

– 情報的な問題 •入力への不正データの混入

– 動作上の問題 •ユーザの不正操作 •タイミングの問題 などなど

• 安全の脅威 – どれだけの「不運の重なり」を想定できるか

•異常時動作の正しさ •タイミングの問題 などなど

16

脅威の把握

• 王道はない気もしますが…

• 想像力を働かせること • 他人の「いいやり方」を真似すること

– 考えるべきことのガイドラインが いろいろ世の中には転がっている

– 例: 我々の鉄道分野の共同研究での取り組み •別分野（宇宙産業）の脅威リストを眺めて どれくらい当てはまるか検討

17

脅威の把握

• 認証規格との関係 – 一般的な認証規格

•セキュリティ: ISO 15408 •安全性: ISO 61508

– 各産業ごとの認証規格 •自動車、鉄道、IT機器、航空、消費者機械 etc.

• とるべき「考え方」が書いてある – 「どうやるか」は自分で考えないとだめ

18

安全性・セキュリティの実現

• 把握した脅威をもとに、 対策をシステム上に実現する – 個別の話で言えば、「簡単」

•脅威がわかっていれば、対策はわかる •ここまでは、セキュリティも安全も共通

– 真の問題は「徹底すること」

•抜け漏れなく対策を実施すること •抜け漏れなく実施したことを確認すること •抜け漏れないことを他人に説明できること

19

セキュリティ対策

• 問題は単純なので、 対策はパターン化される – ある程度は自動化もできる

• 「ありとあらゆる悪意」に 「漏れなく対応」の悪夢 – 到底あとからは検査しきれない

• きっちり作り込むプロセスが大切

20

セキュリティ対策 • 安全な言語システムの利用

– 可能であれば、かなり有効 • あらゆるデータ処理に対し、最低限 「暴走しない」ことは保証できる

• ウィルスなどはほぼ完全に排除できる – 組込みではリソースが難しいか？

• セキュアプログラミング – 問題を起こさないプログラミングスタイル

• セキュリティ対策の「べからず集」「べき集」 – 対策を徹底するのは人の力にかかっている – 意味を理解するのが重要

• 闇雲にやっても高コスト、低ゲイン

21

セキュリティ対策

• セキュリティ検査 •ファジングテスト、攻撃テストなど

– プロセス全体からみたときにはすごく重要

– ただし、確実度はあまり期待しないこと •所詮「有限の攻撃」をしてみるテスト •到底「すべての悪意」には到達し得ない

– 「検査すれば大丈夫」は×

22

安全の作り込み

• 全自動化の難しい領域 – 「安全」はシステムごとに異なる

•鉄道・洗濯機：基本的に止めれば安全 •自動車：急ブレーキは追突・スピンの危険 •空調：止めると老人が凍死するかも •飛行機：エンジン止めたら墜落

• 扱うべき問題自体は比較的把握可能 – 分析工程で列挙した問題リスクに きちんと対応できるかを調べれば良い

•ただし、それでも膨大ではある

23

ソフトウェア・テスト

• いろいろ入力を試してみて、 結果が意図通りかどうかを調べる – 最も原始的ではある – テストは一番現実的に扱いやすい 信頼性確保手段

•テストは実装者にとってもわかりやすい •ソフト以前の工業製品から脈々と使われている

24

テストの限界

• そもそもすべての入力はテストできない – テストケースは有限

•それも、通常はかなり少ないケース数 – 数百とか数千とか数万とか

→ テスト結果が全て正しいことは、 プログラムが正しいことを意味しない

•正しそう だと言うことしかわからない •「正しそう具合」は測れない: 見積もるしかない

25

テスト結果の使われ方

• バグを見つけるのが目的の場合: – テスト失敗すれば、バグがあるのは確実

•テストが通らなければそれでOK

• 信頼性を裏付ける目的の場合: – テストケースが通った時の信頼性は？

•直接的に示すものは何もない •テスト設計にきちんと論理的根拠がなければ、 安全性の根拠になり得ない

26

テストの信頼性向上へ向けて

• きちんと論理的に説明できる テストの設計（計画）が重要 – どういう意図で設計したか – どういう根拠でOKと判断したか

– 問題が万が一起こったときにも、 そこに至ったプロセスを検証し説明できる 材料をそろえておくことが肝要

27

テストで見つからない問題

• 毎回起こる問題は比較的見つけやすい – ロジックの間違い – 想定漏れ、対策漏れ

•ただし、脅威の分析がきちんとできている場合

• 見つけにくい問題もある – 微妙なタイミングで発現する問題

•「○○と△△がほぼ同時に起こった場合」 – 何万回試しても再現できなかったりする – でも現場ではけっこう起こる

– きちんと限界を見極めておくことが必要

28

我々の取り組み例: Calot (Combinatorial-Analytical Logic-Oriented Test)

• テスト設計を効率化・精密化するツール – 機能分析の論理化・明確化

• 論理木を用いた機能分析 • 分析結果の説明力向上

– テストセットの自動生成 • 抜け漏れのないテスト生成 • 工学的な基準による 効率的なテストセット生成

テストの信頼性強化 テストの説明力強化

29

テスト設計 自動生成された テストケース

モデル検査・形式検証

• プログラムの動作を数学的に解析し、 一定の性質を満たすことを保証する技術 – 起こりうる可能性が複数あるときに、 すべてのケースを論理的に調べる技術

• 最近は産業応用もだいぶ進んできた – 形式検証技術の発展 – 解析に使うコンピュータの高速化

30

モデル検査 • ソフトウェアの設計や実装からモデルを作成 – 重要な部分の振る舞いを抽出

• 網羅的に振る舞いを 全検査 – 不要な状態が 発生ないことを しらみつぶしに探索

– 見つかれば、反例として設計変更にフィードバック

31

EM SQ UM

ソースコード

モデル化

仕様

自動・網羅検査

• 既に実績のある技術 • 開発現場への展開と 現場からの要望に基づく 技術改良

モデル検査の利点と欠点 • テストでは押さえきれない タイミングなどの網羅検査が可能 – 実際にソフトを実行するのではなく、 仮想的に全可能性を網羅してくれる

• こういう力業は計算機の得意とするところ – 検査器はどんどん改良が進む

• メモリが許せば数億状態くらいまで探索できる • 単純な使い方は普通のエンジニアでも理解できる

• 現実的な規模の応用にはまだコツが必要

– モデルのサイズには限界（数億状態程度） – うまい抽象化や状態数削減に、経験が必要

• この段階でのミスは間違った結果に繋がる – 仕様を書くのも結構大変

32

その他の取り組み

• セキュリティ系 – 既存プログラム向けの 安全性を向上させる言語処理系

– ソフトウェア安全性検査器の自動生成 • 安全系

– 動的な振る舞いのテスト技術 – 開発プロセス全体での安全性管理 （開発トレーサビリティ技術）

• 「説明」系 – 認証工学： 認証プロセス自体の工学的解析

33

まとめ：ソフトウェアの高信頼化へ

• 銀の弾丸はないですが…

• 闇雲に対策するのはお勧めしません

• 敵を知り、対策を考えることで – 有意義で省コストな対策につながります – 後から振り返ってやり直しがききます – やったことを他人に説明できます

•「安心」を提供することにつながります 34

まとめ：ソフトウェアの高信頼化へ

• 我々サイドのこれからの仕事： 社会的側面からの研究課題 – 安全性・信頼性のためのコストの見える化

•無駄にお金を掛けていないこと、 ちゃんとメリットが得られていることの 説明力の向上

– 開発者間・世代間・関係企業間で きちんと連携・一貫できる 安全な開発プロセスの体系化

– IoT による非連続的変化を踏まえた インターネット全体のセキュリティ構造の検討

35

The Internet

IoTネットワークの近未来像 インフラとして

インターネット上に 広くばらまかれた

センサー群

必要な センサー情報を 取得し利用

一般サービス 利用者へ

情報として提供

街←→サイバー空間 サービス連携

交通流動最適化 異常検知・スマート警備 移動支援・スマートモビリティ 狭域気象予測・把握

センサー 提供者 （官・民）

センサー 提供者 （官・民）

センサー 利用者 （官・民）

センサー 利用者 （官・民）

動的割り当て 資源管理

セキュリティ管理

IoT 時代のセキュリティへ向けて （我々の取り組みの方向性）

• IoT（もののインターネット）、 M2M （機器間通信）を前提とした セキュリティの再検討 – そもそも、今のWeb向けのモデルを そのまま延長して良いのか？

– 一兆センサーの基盤をセキュアに 維持し続けるには何が新たに必要か？

– ソフトウェアの安全性の作り込みの上に、 IoT社会全体の安全性を考えてゆきます

37