自動車サービス連携のセキュリティアーキテクチャの提案
2008MI011 朝倉 知也 2008MI079 岩井 大
指導教員 青山 幹雄

1. はじめに
現在，自動車の車載システムと通信技術の発達により，自動車はナビゲーションシステムなどの様々な外部サービスと車載システムを連携させることが可能となっている．
本稿では，外部サービス連携のセキュリティに着目し，ユーザから車載システムまでのセキュアな通信を保証するアーキテクチャを提案する．

2. 問題の背景
現在，車載システムと外部サービス間の連携はメーカごとにインタフェース/プロトコルなどの通信方式が異なる．そのためサードパーティサービスの利用が困難である．
こ の 問 題 を 解 決 す る た め SOA (Service-OrientedArchitecture)[7]を適用し，SOAP や REST (REpresentationalState Transfer)などの標準化されたプロトコルを用いるアーキテクチャが提案されている[3]．

3. 研究課題
SOA に基づく車載サービスブローカアーキテクチャでは，外部システムとユーザ間のプロトコルが定義されていない．
また，通信時のセキュリティを保証していない (図 1)．
外部システム
車載システム
ECU1
ECU2

Web

車載サービス
ブローカ

プロバイダA

ユーザ

サービスa
サービスb
プロバイダB
サービスc

セキュリティの保証がない

Web

サービスd

携帯端末
プロトコルの定義，セキュリティの保証がない

SOAに基づく車載サービスブローカのアーキテクチャの提案範囲

BundleをBasic Service Bundleと呼び，これらを利用することで共通的に使用される機能を開発者が実装する必要がな
い．それに対し，各事業者や機器に依存し標準化していな
い Bundle のことを Application Bundle と呼ぶ．
また，OSGi は組み込みシステムの利用が前提で開発されたため省メモリで動作可能であり，システムのリソース制約の影響を受けにくい．
4.2. SOA に基づく車載サービスブローカアーキテクチャ
本アーキテクチャは OSGi を用いた車載サービスブロー
カを自動車に搭載し，Basic Service Bundleとして提供されるプロトコル変換機能を持つ Bundle を利用することで，車載システムと外部サービス間の連携で SOAP/REST を容易に利用できる [3]．
車載サービスブローカの OSGi フレームワーク上では以下の 4 つの Bundle が実装され動作し，Bundle 間連携を行う
ことで車載ネットワークと外部サービスを連携する．
(1) HTTP 通信機能を持つ HTTP Server Bundle(2) SOAP/POX メッセージの生成と解析を行う
SOAP/POX Proxy Processor Bundle(3) テレマティクスサービス機能を持つ Application Bundle(4) 車載ネットワークと通信を行う Interface Gateway Bundle
4.3. 自動車ネットワークサービスにおけるセキュリティ
自動車ネットワークサービスのセキュリティを保証するた
めには，自動車に対する攻撃を明確にする必要がある[4]．
自動車に対する攻撃概要と具体例を表 1 に示す．
表 1 自動車に対する攻撃概要とその具体例
攻撃発生場所

概要

具体例

近接

整備員などになりすました第三者の車両への直接攻撃

ECUのプログラム改ざん，個人情報の吸い出し

中間(持ち込み機器)

車内の機器(ドライブレコーダなど)
からの攻撃

運転情報の改ざん，漏えい

広域ネットワーク経由

車外サービス連携の際に発生する
外部ネットワークからの攻撃

盗聴による個人情報流出，虚偽メッセージの表示

サービス実用化の際に考慮すべき範囲

図 1 参考アーキテクチャの提案範囲とその課題

4. 関連研究4.1. OSGi(Open Service Gateway initiative)
OSGi[9]は機器をネットワークに接続し，相互にサービスを提供するための仕様である．
OSGi は Java で実装され，JVM(Java Virtual Machine)上でミドルウェアである OSGi フレームワークが動作する．
OSGi フレームワーク上でソフトウェアコンポーネントであるBundle が複数個動作し，連携することが可能である．
OSGi 仕様では，利用価値の高いサービスを汎用化した

4.4. 情報セキュリティ
情報セキュリティとは，企業や団体内の情報システム，情報システムを利用して得た情報を正確に運用することである[5]．情報セキュリティの目的は，機密性，完全性，可用性があり，内容や範囲，対象によって達成すべき目的は区分されている．
Web サービスなどを対象とするネットワークセキュリティの対策方法として，不正アクセス防止や秘密鍵を用いた暗号化がある．例として，デジタル証明書を用いる SSL，署名や 証明書を 用い て SOAP メ ッ セ ー ジ を 暗号化す る
WS-Security[10]が挙げられる．

5. アプローチ
本稿では，SOA に基づく車載サービスブローカアーキ
テ ク チ ャ を 拡張し ， ユ ー ザ か ら 車載シ ス テ ム ま で のEnd-to-End でセキュアな通信を保証する新たな連携方法を提案する．
前提条件として，外部システムはユーザがブラウザを用いて実行する，もしくは Web アプリケーションとし，外部システム自体のセキュリティは保証されているものとする．
ユーザと外部システム間の通信は HTTPS で行い，セキュリティとして SSL を用いる．また，外部システムと車載システム間の通信は SOAP/REST で行い，セキュリティとしてそれぞれ WS-Security/SSL を用いる．異なるセキュリティレベ
ルに応じ，SOAP(WS-Security)と REST(SSL)を選択可能とする(図 2)．
サービスの要求するセキュリティレベルに応じて選択

外部システム

車載サービス
ブローカECU

プロバイダASOAP(HTTP)

車載
ネットワーク

サービスa
WSDL

WS-S

車載システム

ユーザ
SSL
HTTPS
携帯端末

プロバイダB

SSL

メッセージプロトコル変換

サービスb
WSDL

REST(HTTP)

ECU

ブラウザを用いて利用

セキュリティ保証

WS-S(WS-Security)

図 2 提案する連携方法

は外部システムとの通信時に登録されたユーザ情報を用いて認証を行い，対応する Application Bundle と連携する．
外部システムでも同様に，データベースに格納したユーザ情報を用いて認証を行う．これにより，第三者からの不正アクセスを防ぐことができる．また，ユーザと外部システム間，外部システムと車載システム間の通信は WS-Security/SSLを用いて暗号化され，個人情報の流出，盗聴を防ぐことができる(図 4)．
WS-S/SSLを用いたメッセージ暗号化

車載システム車載
ネットワーク
ECU

SSL

Web
アプリケーション

HTTPS
携帯端末

HTTP Server

SOAP/POX
Proxy Processor

Security

Application

InterfaceGatewayOSGiフレームワークIDとパスワードをJVM
保持OS

userName

userPass

userCarID

パスワード

車両情報

Webアプリケーションの要求するセキュリティを選択
車載システム外部システム

車載ネットワーク
同一のIDとパスワードを設定

図 3 自動車サービス連携のセキュリティアーキテクチャ
6.2. 実現するセキュリティ機能
提案アーキテクチャでは，OSGi フレームワーク上に認証機能を持つ Security Bundle を追加する．Security Bundle

受信したID，PWと比較し認証

図 5 Security Bundle
6.4. セキュリティの選択
外部システムと車載システム間の通信には，SOAP(WS-Security)と REST(SSL)を選択することが可能である．外部システムの要求するセキュリティレベルに応じ，SOAP(WS-Security)と REST(SSL)から適切なセキュリティを選択する(図 6)．

ユーザ管理
DB

ID

ID,PW
OSGiフレームワーク
JVM
OS

OSGiフレームワーク上に複数存在

ブラウザを用いて利用

Bundle間連携

認証

HTTP Server

SSL
REST(HTTP)

ユーザ

プロバイダ

SecuritySOAP/POX
Proxy Processor

OSGi
フレームワーク

ユーザ管理
DB

Application αService αTCP

外部システムApplication βService β

TCP

ECU

CAN
Gateway

ECU

携帯端末

図 4 実現するセキュリティ機能
6.3. Security Bundle
Security Bundle のサービスは Axis2 Bundle によってデプロイされ，外部から利用可能となる[1]．外部システムは車載システムと通信する際に，ID，パスワード，ServiceNameを送信する．Security Bundle は外部システムから送信された ID と パ ス ワ ー ド を 用い て 認証を 行う ． 認証後，ServiceName で指定されたサービスを持つ Application
Bundle と連携する(図 5)．

Application γ
Service γ

WS-S
SOAP(HTTP)

車載サービスブローカ

Web
アプリケーション

ServiceNameで指定されたサービスを持つBundleと連携

6.1. 自動車サービス連携のセキュリティアーキテクチャ
ユーザから車載システムまでの End-to-End で必要とされるセキュリティレベルを満たし，セキュアな通信を保証するアーキテクチャを提案する(図 3)．
SOAに基づくアーキテクチャと同様に車載サービスブロ
ーカに OSGi を用いることで，SOAP/REST を用いた連携が可能になる．セキュアな通信を実現するため WS-Security とSSL を用い，Web アプリケーションの要求するセキュリティレベルに応じて選択する．
車載
ネットワークユーザ

プロバイダ

IDとパスワードを用いたユーザ認証

6. 提案アーキテクチャ

車載システム外部システム
車載サービス
ブローカ

ECU
ECU
ECU

車載サービス
ブローカ

WS-S

プロバイダASOAP(HTTP)

Web
アプリケーションA

WS-Sでセキュリティを保証可能

ID,PW,ServiceName
プロバイダBREST(HTTP)SSL

Web
アプリケーションB

図 6 セキュリティの選択

SSLでセキュリティを保証可能

7. 提案アーキテクチャのプロトタイプ
7.1. 利用シナリオ
プロトタイプの利用シナリオとして，遠隔からドアのロック状態を確認する「ドアロック確認システム」を選択する．前提
条件として，ドアロック確認アプリケーションの要求するセキュリティレベルは SSL で満たせるものとする．また，比較対象として，セキュリティ機能が無いドアロック確認システムを実装する．
7.2. 実装環境
車載サービスブローカの OSGi フレームワークには，オープンソースの Knopflerfish[6]を用いる．また，外部システ
ムには Apache Tomcat[2]，データベースに MySQL[8]を用いる．車載システム内の通信は TCP 接続で行い，外部システムと車載システム間の通信は REST(SSL)で行う(図 7)．プ
ロトタイプは Java で実装し，規模は外部システムが 108 行，車載システムが 216 行となった．
車載システムCAN
Gateway

TCP(1)Door
ECU

SSL

車載サービスブローカ(2)(3)OSGi
TCP
フレームワーク

車載ネットワーク(4)外部システム

REST(HTTP)(5)ユーザ

プロバイダ

SSL

ドアロック確認アプリケーション

HTTPS
携帯端末
ブラウザを用いて利用

MySQL

Bundle間連携

HTTP Server

Security

SOAP/POX
Proxy Processor

Application

ドアロック確認InterfaceGateway

userName

userPass

userCarID

ID

パスワード

車両情報

Knopflerfish
JVM
OS

IDとパスワードを保持(1)PC1(DoorECU)(2)PC2(CAN Gateway)(3)PC3(4)PC4(OSGiフレームワーク) (外部システム)

Windows XP
SP3

Windows XP
SP3

Windows Vista SP2

Windows Vista

Windows XP SP2

CPUIntel (R)Pentium (R)42.80GHz

Intel (R)Pentium (R)42.00GHzIntel (R)core (TM)2 Duo
2.00GHzIntel (R)Pentium (R) Dual
1.60GHzIntel (R)Pentium (R)42.00GHz

メモリ

760MB

1.00GB

2.00GB

2.5GB

1.00GBJDK

JDK 1.6.0_29

JDK 1.6.0_29

JDK 1.6.0_29

JDK 1.6.0_29―Eclipse SDK

Eclipse3.5.0

Eclipse3.5.0

Eclipse3.5.0

Eclipse3.5.0

―

OS

OSGi
Framework――

Tomcat

―

―

MySQL

―

―

ブラウザ

―

―

同一のIDとパスワードを設定(5)PC5
(ユーザ)

―

―

―

Tomcat 6.0――

MySQL 5.5.17

Knopflerfish 3.1.0―――
Internet Explorer 81000BASE-T

ネットワーク

図 7 プロトタイプの開発/実行環境
7.3. プロトタイプの振る舞い
セキュリティ機能が有る通信では SSL 通信と認証を行い，ドアロック状態を取得する．セキュリティ機能が無い通信では，SSL 通信と認証を行わない．以下にセキュリティ機能が有る通信とセキュリティ機能が無い通信の振る舞いと測定範囲を示す(図 8，図 9，表 2)．
車載システム
DoorECU

CAN
GatewayInterfaceGateway
BundleOSGiフレームワーク
ドアロック確認
Application
BundleSecurity
Bundle外部システム
ユーザ管理DB(MySQL)

ドアロック確認アプリケーション

ID，PW，車両情報取得

ユーザ(携帯端末)

取得命令(ID，PW)

ドアロック
状態確認

取得命令

取得命令
ドアロック状態

取得命令

SSL通信

T2

サービス実行

SSL通信

T3
ドアロック状態

ドアロック状態

T1：認証処理時間

T2：ドアロック状態取得命令応答時間

ユーザ(携帯端末)

取得命令(ID，PW)
サービス実行
ドアロック
状態確認

取得命令
ドアロック状態

取得命令

取得命令

T4
ドアロック状態
ドアロック状態

ドアロック状態

ドアロック状態
通知

T4：システム応答時間

図 9 セキュリティ機能が無い通信のシーケンス図
表 2 測定範囲
セキュリティ機能 セキュリティ機能
が有る通信
が無い通信
T1+T2

システム応答時間

セキュリティ処理時間

T4
T3

車載システム応答時間
T1

認証処理時間外部システムと車載システム間のSSL通信処理時間

T2-T3

―

8. プロトタイプに基づく評価
8.1. プロトタイプの性能評価実装したプロトタイプを実行し，ドアロック確認アプリケーションの起動から終了までの応答時間を測定することで，性能評価を行う．DoorECU と CAN Gateway は Java で実装したスタブであるため，正式な車載システムの応答時間を測定することはできない．そのため，セキュリティ機能の有無に着目し，セキュリティ機能が有る通信とセキュリティ機能が無い通信を比較し，セキュリティ機能の処理時間を計測する．
応答時間の測定範囲はドアロック確認アプリケーションの起動から終了までであり，また，車載サービスブローカ内のユーザ認証は簡易的な実装である．よって，セキュリティ機能の処理時間は表2 で示したように，外部システムで行うユーザ認証の処理時間(T1)と，外部システムと車載システム間の SSL 通信の処理時間(T2-T3)の合計である．
8.2. 応答時間の測定と平均値の算出
セキュリティ機能が有る通信とセキュリティ機能が無い通信をそれぞれ 1000 回実行し，応答時間を測定した(図 10,
図 11)．セキュリティ機能が有る通信の測定範囲は図 8 のT1+T2，セキュリティ機能が無い通信の測定範囲は図 9 のT4 である．
500
応 450
答400
時
間 350
ミリ 300
秒 250
200

ドアロック状態ドアロック状態

外部システムドアロック確認アプリケーション)

T1

認証

CAN
Gateway(認証取得命令(ID，PW,ServiceName)

OSGiフレームワーク
Interface
ドアロック確認
Application
Gateway
BundleBundle車載システム
DoorECU

ドアロック状態
通知

T3：車載システム処理時間

図 8 セキュリティ機能が有る通信のシーケンス図

実行回数(回)図 10 セキュリティ機能が有る通信の応答時間

300250(

応答 200時
間 150
ミリ 100秒)

50
0
実行回数(回)図 11 セキュリティ機能の無い通信の応答時間
図 10，図 11 の測定結果では定期的に大幅な遅延が発生しているが，JVM のガベージコレクションによると推定できる．そこで，測定結果の上位約 5%を特異値とし，特異値を除いた応答時間を補修値とする．それぞれの 100 回ごとの補修値平均と補修値全体の平均，標準偏差を以下に示す(図 12)．
セキュリティ機能が有る通信

セキュリティ機能が無い通信

233

230

250

232233229232230229230

補修値平均(T1+T2) 標準偏差230.7

(補 200修値 150

2291.55

補修値平均(T4)

標準偏差

17.5
18161818191518170

実行回数(回)

図 12 補修値平均と標準偏差8.3. セキュリティ機能の処理時間
図 12 より，応答時間は実行回数に依存せず，ほぼ一定であった．また，セキュリティ機能が有る通信とセキュリティ機能が無い通信の応答時間の差が，セキュリティ機能の処理時間となる．外部システムで行うユーザ認証(T1)の平均応答時間は 30.4 ミリ秒，外部システムと車載システム間のSSL 通信(T2-T3)の平均応答時間は 175.2 ミリ秒であった(表3)．この結果から，セキュリティ機能が有る通信の応答時間の内，セキュリティ機能の処理時間が 9割以上を占め，特にSSL 通信処理に時間がかかることを確認した．
表 3 セキュリティ機能の処理時間
補修値平均(ミリ秒)

平均応答時間(ミリ秒)

230.7

認証処理時間(T1)30.4

セキュリティ機能の無い通信(T4)

17.5
213.2

外部システムと車載システム間のSSL通信処理時間(T2-T3)

175.2

セキュリティ機能の処理時間

セキュリティ機能の有る通信(T1+T2)

10. 今後の課題
今後の課題として，以下の 4 点が挙げられる．
(1) SSL 通信処理のパフォーマンス改善(2) セキュリティポリシに基づくセキュリティ選択のコード化(3) WS-Security を用いたプロトタイプの実装(4) 正式な ECU と CAN Gateway の利用

11. まとめ

1.1118)ミ 100
リ秒 50 18

部システムと車載システム間の通信に WS-Security と SSLを適用することで，車載システムからユーザまでのセキュアな通信を実現した．
9.2. プロトタイプの応答時間
プロトタイプとしてドアロック確認システムを開発し，セキュリティ機能の処理時間を測定した．その結果，応答時間の 9 割以上がセキュリティ機能の処理時間であった．また，セキュリティ機能の処理時間の 8 割以上が SSL 通信の処理時間であることを確認した．これは，JavaではSSL通信の暗号処理に時間がかかるためだと考えられる．この問題の解決方法として，JNI(Java Native Interface)を用いて C 言語で実装されたネイティブコードと連携し，SSL 通信処理のパフォーマンスを改善する方法がある．

9. 考察
9.1. 車載システムからユーザまでのセキュアな通信
SOA に基づく車載サービスブローカアーキテクチャでは，通信時のセキュリティ保証はされていない．提案アーキ
テクチャでは，ユーザと外部システム間の通信に SSL，外

本稿では，SOA に基づく車載サービスブローカアーキ
テクチャを拡張し，End-to-End でセキュアな通信を保証する新たなアーキテクチャを提案した．異なるセキュリティレベルの要求に応じ，セキュリティとして WS-Security と SSLを選択可能とした．さらに，プロトタイプを開発し，応答時間とセキュリティ処理時間を測定した．

参考文献[1] Apache Axis2, http://axis.apache.org/axis2/java/core/.
[2] Apache Tomcat, http://tomcat.apache.org/.
[3] 濱千代 正弥, 片桐 雅仁, 自動車ネットワークサービ
スの連携アーキテクチャ 南山大学2010年度卒業論文,2011.
[4] 情報処理推進機構, http://www.ipa.go.jp/.
[5] 情報セキュリティ標準テキスト編集委員会, 情報セキュ
リティ, オーム社, 2006.
[6] Knopflerfish OSGi-Open Source OSGi Service Platform,
http://www.knopflerfish.org/index/html/.
[7] D. Krafzig, et al., Enterprize SOA, Prentice Hall, 2005.
[8] MySQL, http://www-jp.mysql.com/.
[9] OSGi(Open Service Gateway initiative) Alliance,
http://www.osgi.org/Main/HomePage.
[10] C. Wells, Ajax アプリケーション&Web セキュリティ, オーム社, 2008.