形式手法を用いたセキュリティ検証

アーク・システム・ソリューションズ株式会社

池田和博

1

講演内容

• CPS社会と組込み機器

• 組込み機器のセキュリティ特性と脅威分析

• 形式検証を適用したシステムの概要

• Event-Bによる形式検証の適用と効果

• まとめと課題

2

CPS社会と組込み機器

• CPS(Cyber-Physical System)：ITと実社会の融合

• 実社会の組込みシステム等からの情報を、サイバー空間のコンピューティング能力と接続し、高効率・高度な社会を実現するためのシステム。

3

情報の提供

情報の利用情報の入力

情報の収集

ネットワーク

CPS(サイバー・フィジカル・システム)

出典：経済産業省資料

スマートハウスや車載システムにおいてネットワーク連携による情報のやり取りを行う時代が迫っている。

組込み機器のセキュリティ

• CPS社会における組込み機器の題材として、宅内で使用される家電間の無線ネットワーク連携を想定し、セキュリティ特性について考察した。

• 情報セキュリティ：情報の機密性・完全性・可用性を維持すること（ISO/IEC 27002）– 機密性(Confidentiality)：情報へのアクセスを認められた者だけが、その情報にアクセスできる状態を確保すること。

– 完全性(Integrity)：情報が破壊、改ざん又は消去されていない状態を確保すること。

– 可用性(Availability)：情報へのアクセスを認められた者が、必要時に中断することなく、情報及び関連資産にアクセスできる状態を確保すること。

• 組込み機器の場合、利用者や組込み機器の認証を考慮する必要がある。

• また、利用者によるサービス利用の否認も考慮する必要がある。– 認証(Authentication)：利用者の身元が証明されている。利用を許可された機器以外は利用することができない。

– 否認防止(Non-repudiation)：利用者はアクションを実行した後、それを実行したことを否認できない。

4

脅威分析

• セキュリティ特性(C.I.A.N.A)ごとの攻撃脅威についてアタックツリー手法を用いて分析した。

• 脅威への対策方針を検討して組込み機器の無線セキュリティ要件を抽出し、要求仕様を策定した。

5

無線セキュリティ要件

アタックツリー分析

検証対象システムの概要

6

Internet

Router

Home Area Network

GW(MWG)

PC

Wi-FiAccess Point

Wi-FiAdaptor

Wi-FiAdaptor

Dvc(MWD)

Dvc(MWD)

Scope of Authentication

and Access control

＝TOE

AppD

EchonetLite

MWD

PANA,TLS,DHCP Client

TCP/IP

OS

AppG

EchonetLite

MWG

PANA,TLS, DHCPRadius Server

TCP/IP

OS

Dvc GW Dvc

AP AdapterAdapterTOD

宅内G/W

宅内セキュア無線通信

宅内機器無線脅威

ユースケース

ソフトウェア構成

MW

MW

MW

宅内ネットワークへ参加するための認証機能・アクセスコントロールを提供するミドルウェアの開発【ミドルウェアのセキュリティ目的】

• 正規の宅内機器・ゲートウェイのみが宅内ネットワークに参加できる。

• 不正なゲートウェイによる宅内機器の操作や、不正な機器が宅内ネットワークに参加できないようにする。

ミドルウェアのセキュリティ対策を

Event-Bを用いて検証

検証者のスキルと実績

• 検証実施者

– 組込み系のアプリケーション開発者

– 形式手法の開発実績なし（Event-B以外も同様）

– セキュリティ関連の開発実績なし

– アドバイザーとしてセキュリティ専門家の指導あり

• 取組み実績

– Event-Bの記述及び証明の通し方などの調査・試行（2ヶ月）

– セキュリティ特性の検証を目的としたEvent-Bのモデル化（3ヶ月）

– 検証対象のEvent-Bモデル作成（5人日）

– 作成モデルの検証及び修正（4人日）

– 形式手法の専門家によるモデルのレビュー

– 指摘内容を反映したEvent-Bモデル作成（4人日）

– 修正モデルの検証及び修正（2人日）

7

Event-Bの適用の概要

8

振舞いの整合性

検証対象の抽出

振舞いの想定セキュリティ特性の定義

Event-B記述

リファインメント(詳細化)

モデルの表現方法

定理証明 モデル検査

モデルの検証と修正

セキュリティ・仕様の検証

OK

NG 要求仕様の修正

要求仕様から

想定したシステムの振舞いリスト

適切なモデル化

検証完了

Event-B適用の前提

Event-Bモデル化 モデル化の妥当性

形式検証

• 検証の目標

– 仕様の範囲・詳細度（どこまでモデル化するのか）

– 検証のレベル（EAL）

• 振舞いの想定

– システムがどのように動作、処理するのか

– システムを構成する環境からの影響

• 保証すべきセキュリティ特性の定義

– 脆弱性・脅威（外部からの攻撃など）の想定

– Event-Bによるセキュリティ検証の観点の定義

Event-B適用の前提

9

システム・環境の想定検証範囲の設定

通信データの盗聴

なりすまし

セキュリティ脅威

要求仕様

Event-B検証の観点

• 保護資産・保証すべきセキュリティ特性から、攻撃可能性を考慮して攻撃

手段を分析する。

• 検証対象のEvent-Bモデルに対して、攻撃手法ごとに攻撃モデルを作成・追加し、それぞれに対してセキュリティ特性を定義する。

– 攻撃者の能力を段階的に表現することでセキュリティレベルを明確化する。

– 攻撃モデルによって、セキュリティが破られないことを検証する。

• セキュリティ対策の検証方法– 定理証明(セキュリティが守られていることを証明)

– モデル検査による反例の抽出。

10

Event-Bのモデル化

11

セキュリティ脅威

抽象化

リファインメント(詳細化)

定理証明(検証)

モデルの前提

脅威・脆弱性分析の観点から、脅威となり得るインタフェースや条件を考察する。システム全体を考慮する必要がある。

ユースケースとして想定できること、除外できることを想定する。その前提の場合のみセキュリティ対策が有効であることを保証する。

検証に必要な情報・条件を抽出及び、不要な情報は排除する。「何が」、「何のために」必要なのか、目的や観点を明確にする必要がある。⇒システムの特性

セキュリティに影響を及ぼす機能・環境を段階的に追加する。イベント追加や条件強化によって、より具体化・複雑化したモデルを考慮する。

リファインメントによって追加したイベント、条件等が抽象モデルと整合性が取れているか証明により検証する。⇒セキュリティ保証。

仕様・セキュリティ特性の抽出

• 形式手法の利点は自然言語によって表現される「性質」や「条件」などの

曖昧さを排除すること。

• 論理式を使用した「○○は△△である/ではない」といった、ある条件下に

おいて論理が正しいか否かを明確にする。

【仕様・セキュリティ特性の抽出の観点】

1. 要求仕様における保護対象の資産を抽出する。

2. 保護資産のセキュリティ特性を分析・考察し、必要な特性を定義する。

3. 保護資産のセキュリティに必要な(影響のある)機能・仕様を抽出する。

⇒論理式をEvent-BのINVARIANT(不変条件)に記述することで、

宅内家電が通信データを取得するときに証明が求められる。

12

情報へのアクセスを認められた者だけが、

その情報にアクセスできる状態を確保する

（ユースケースから想定）

宅内家電とGWの間で

やり取りされる通信データ

宅内家電が取得した

通信データは、他の

家電が取得していない

機密性保護資産 論理式

＋

(例)

モデル事例

13

EVENTSendEvtwhen

grd1: sender ∈ ACTORSgrd2: recipient ∈ ACTORSgrd3: data ∈ DATA

thenact1: channel:= channel ∪ {dvc ↦ gw ↦ data}

end

ReceiveEvtwhen

grd1: sender ↦ recipient ↦ data ∊ channelgrd2: receiver = recipient

thenact1: mail_box := mail_box ∪ {receiver ↦ data}

end

SETSACTORS, DATA

VARIABLESchannel, mail_box

INVARIANTinv1: channel ⊆ ACTORS ×ACTORS× DATAinv2: mail_box ∈ ACTORS ⇸ DATA

EVENTSendEvtwhen

grd1: sender ∈ ACTORSgrd2: recipient ∈ ACTORSgrd3: data ∈ DATA

thenact1: clear_channel :=

clear_channel ∪ {dvc ↦ gw ↦ data}end

ReceiveEvtwhen

grd1: sender ↦ recipient ↦ data ∈ clear_channelgrd2: receiver ∈ ACTORS

thenact1: mail_box := mail_box ∪ {receiver ↦ data}

end

VARIABLESclear_channel, mail_box

INVARIANTinv1: clear_channel ⊆ ACTORS ×ACTORS× DATAinv2: clear_channel = channel

receiverの機密性が担保されていない

リファイン

モデル事例

14

EVENTSendEvtwhen

grd1: sender ∈ ACTORSgrd2: recipient ∈ ACTORSgrd3: data ∈ DATAgrd4: key ∈ KEYgrd5: sender ∈ secret[{key}]grd6: recipient ∈ secret[{key}]grd7: data ∉ ran(mail_box)

thenact1: enc_channel :=

enc_channel ∪ {dvc ↦ gw ↦ data ↦ key}end

ReceiveEvtwhen

grd1: sender ↦ recipient ↦ data ↦ key ∈enc_channel

grd2: receiver ∈ secret[{key}]grd3: receiver ≠ sender

thenact1: mail_box := mail_box ∪ {receiver ↦ data}

end

SETSACTORS, DATA, KEYS

VARIABLESenc_channel, mail_box, secret

INVARIANTinv1: enc_channel ⊆ ACTORS × ACTORS × DATA × KEYinv2: ∀aa, bb, data, key ·

aa ↦ bb ↦ data ↦ key ∊ enc_channel⇒ aa ↦ bb ↦ data ∊ channel

inv3: secret ∈ KEYS ↔ ACTORSinv4: ∀key ·

key ∊ dom(secret)⇒ (∃aa, bb · aa ∈ Actors ∧ bb ∈ Actors ∧

aa ≠ bb ∧ secret[{key}] = {aa, bb})inv5: ∀aa, data ·

aa ↦ data ∈ mail_box⇒ {aa} = mail_box~[{data}]

EVENTExchangeKeyEvtwhen

grd1: key ∊ KEY ∧ key ∉ dom(secret)grd2: first ∊ ACTORSgrd3: second ∊ ACTORSgrd4: first ≠ second

thenact1: secret := secret ∪ {key ↦ first, key ↦ second}

end

receiverの機密性が担保されている

リファイン

モデル化の妥当性

• 検証対象の仕様がモデルに反映されていること。

• 保証すべきセキュリティ特性が適切に表現（モデル化）されていること。

15

Event-B記述モデル

セキュリティ特性・システム（環境）

の想定

機能仕様・セキュリティ特性の表現方法についてトレーサビリティを取る

形式検証

• Rodinプラットフォームの「ProB」を使用したモデルチェックによる検証。

16

セキュリティが担保されている状態

セキュリティが担保されていない状態

セキュリティに依存(影響)する変数

違反したセキュリティ特性

セキュリティ違反となる処理を行ったイベント

形式検証の効果

• モデルの証明課題の未証明内容を検証し、問題箇所を特定。それにより、セキュリティ対策の脆弱性を検出した。⇒保証したいセキュリティ特性をINVARIANT(不変条件)に記述し、イベント実行による状態変化によって、その特性に違反していることを確認。

• 攻撃モデルを段階的に導入し、攻撃の可能性を明確化した。

⇒攻撃者のなりすましによって機密性及び完全性が保証されていないことが判明。

• セキュリティの専門家が要求仕様の脅威分析を行い、指摘した問題とほぼ同等の結果を得ることができた。⇒セキュリティの専門家でなくとも、脅威や脆弱性を検出することが可能。

17

保護資産

対策攻

撃

まとめ• 要求仕様やシステム環境を含めた中から検証する対象を抽出する。

– セキュリティの脅威分析から、セキュリティを保証すべき箇所に絞った形での抽出。

• 検証し易いように対象の抽象化を行う。

– 検証対象のシステム・環境から、セキュリティが担保される形での最善となる振舞いを想定し、それを初期モデルとする。

⇒システム・環境の本質的な性質や正しさを抜き出すことが重要。

• リファインメントによって抽象表現から、より仕様に近い形に表現する。– 想定した振舞い・攻撃などを追加する。

– 抽象モデルとの整合性を逸脱しないことをリファインメントにより検証できる。⇒機能拡張やシステム構成・攻撃モデルを追加した場合においてもセキュリティ特性が保証されることを証明する。

• セキュリティ特性の定義、脅威や対策のモデル(表現方法)を検証する。– 脅威分析や想定できる振舞いから、記述したモデルの表現方法が妥当か検証する。

18

定理証明やモデル検査によって証明が完了したとき対象のセキュリティ対策は問題なしと判断できる

今後の課題

• Event-Bに記述したセキュリティ特性をB-Methodに適用する。

• これにより、要求段階で検証したことを、実装段階でも検証しながら製造を行うことが可能。

19

Event-B B-Method

ご清聴ありがとうございました。

アーク・システム・ソリューションズ株式会社

池田 和博

北海道札幌市中央区北1条西7丁目1-15 あおいビル8D

TEL：011-207-6460 FAX：020-4622-5064

E-Mail：ikeda.kazuhiro@arcsys-sol.co.jp

20