自動車サービス連携のセキュリティアーキテクチャの提案

自動車サービス連携のセキュリティアーキテクチャの提案
2008MI011 朝倉知也 2008MI079 岩井大
指導教員青山幹雄
1. はじめに
現在，自動車の車載システムと通信技術の発達により，
自動車はナビゲーションシステムなどの様々な外部サービ
スと車載システムを連携させることが可能となっている．
本稿では，外部サービス連携のセキュリティに着目し，
ユーザから車載システムまでのセキュアな通信を保証する
アーキテクチャを提案する．
2. 問題の背景
現在，車載システムと外部サービス間の連携はメーカご
とにインタフェース/プロトコルなどの通信方式が異なる．そ
のためサードパーティサービスの利用が困難である．
この問題を解決するため SOA (Service-Oriented
Architecture)[7]を適用し，SOAP や REST (REpresentational
State 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
プロバイダA
SOAP
(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
Web
アプリケーション
HTTPS
携帯端末
HTTP Server
SOAP/POX
Proxy Processor
Security
Application
Interface
Gateway
OSGiフレームワーク
IDとパスワードを
JVM
保持
OS
userName
userPass
パスワード
userCarID
Webアプリケーションの
要求するセキュリティを選択
車載システム
外部システム
WS-S
車両情報
車載
ネットワーク
同一の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)
Security
SOAP/POX
Proxy Processor
OSGi
フレーム
ワーク
ユーザ管理
DB
Application α
Service α
TCP
ユーザ
SSL
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
SOAP
(HTTP)
車載サービス
ブローカ
プロバイダA
Web
アプリケーションA
WS-Sでセキュリティ
を保証可能
ID,PW,ServiceName
プロバイダB
REST
(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)外部システム
(5)ユーザ
プロバイダ
REST
(HTTP)
SSL
HTTPS
ドアロック確認
アプリケーション
携帯端末
ブラウザを用いて利用
MySQL
Bundle間連携
HTTP Server
Security
SOAP/POX
Proxy Processor
Application
ドアロック確認
Interface
Gateway
Knopflerfish
JVM
OS
userName
ID
userPass
userCarID
パスワード
車両情報
同一のIDとパスワードを設定
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
CPU
Intel (R)
Pentium (R)4
2.80GHz
Intel (R)
Pentium (R)4
2.00GHz
Intel (R)
core (TM)2 Duo
2.00GHz
Intel (R)
Pentium (R) Dual
1.60GHz
Intel (R)
Pentium (R)4
2.00GHz
メモリ
760MB
1.00GB
2.00GB
2.5GB
1.00GB
JDK
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
―
―
ブラウザ
―
―
(5)PC5
(ユーザ)
―
Knopflerfish 3.1.0
―
―
Tomcat 6.0
―
MySQL 5.5.17
―
―
―
―
Internet Explorer 8
1000BASE-T
ネットワーク
図 7 プロトタイプの開発/実行環境
7.3. プロトタイプの振る舞い
セキュリティ機能が有る通信では SSL 通信と認証を行い，
ドアロック状態を取得する．セキュリティ機能が無い通信で
は，SSL 通信と認証を行わない．以下にセキュリティ機能が
有る通信とセキュリティ機能が無い通信の振る舞いと測定
範囲を示す(図 8，図 9，表 2)．
車載システム
DoorECU
CAN
Gateway
Interface
Gateway
Bundle
OSGiフレームワーク
ドアロック確認
Application
Bundle
Security
Bundle
外部システム
ユーザ管理DB
(MySQL)
ドアロック確認
アプリケーション
ID，PW，車両情報
取得
ユーザ
(携帯端末)
取得命令(ID，PW)
T1
認証
取得命令
取得命令
ドアロック状態
取得命令
サービス実行
SSL通信
T3
SSL通信
T2
ドアロック状態
ドアロック状態
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
ドアロック状態
ドアロック状態
外部システム
ドアロック確認
アプリケーション
)
ドアロック
状態確認
CAN
Gateway
(
認証
取得命令(ID，PW,ServiceName)
OSGiフレームワーク
Interface
ドアロック確認
Application
Gateway
Bundle
Bundle
車載システム
DoorECU
ドアロック状態
通知
T3：車載システム処理時間
図 8 セキュリティ機能が有る通信のシーケンス図
実行回数(回)
図 10 セキュリティ機能が有る通信の応答時間
300
250
(
応
答 200
時
間 150
ミ
リ 100
秒
)
50
0
実行回数(回)
図 11 セキュリティ機能の無い通信の応答時間
図 10，図 11 の測定結果では定期的に大幅な遅延が発
生しているが，JVM のガベージコレクションによると推定で
きる．そこで，測定結果の上位約 5%を特異値とし，特異値
を除いた応答時間を補修値とする．それぞれの 100 回ごと
の補修値平均と補修値全体の平均，標準偏差を以下に示
す(図 12)．
セキュリティ機能が有る通信
250
229
232
233
セキュリティ機能が無い通信
229
230
232
230
229
230
補修値平均(T1+T2) 標準偏差
230.7
(
補 200
修
値 150
233
1.55
補修値平均(T4)
標準偏差
17.5
18
16
18
18
19
15
18
17
0
実行回数(回)
図 12 補修値平均と標準偏差
8.3. セキュリティ機能の処理時間
図 12 より，応答時間は実行回数に依存せず，ほぼ一定
であった．また，セキュリティ機能が有る通信とセキュリティ
機能が無い通信の応答時間の差が，セキュリティ機能の処
理時間となる．外部システムで行うユーザ認証(T1)の平均
応答時間は 30.4 ミリ秒，外部システムと車載システム間の
SSL 通信(T2-T3)の平均応答時間は 175.2 ミリ秒であった(表
3)．この結果から，セキュリティ機能が有る通信の応答時間
の内，セキュリティ機能の処理時間が 9割以上を占め，特に
SSL 通信処理に時間がかかることを確認した．
表 3 セキュリティ機能の処理時間
補修値平均
(ミリ秒)
セキュリティ機能の有る通信(T1+T2)
セキュリティ機能の無い通信(T4)
セキュリティ機能の処理時間
230.7
17.5
213.2
平均応答時間
(ミリ秒)
認証処理時間(T1)
外部システムと車載システム間
のSSL通信処理時間(T2-T3)
10. 今後の課題
今後の課題として，以下の 4 点が挙げられる．
(1) SSL 通信処理のパフォーマンス改善
(2) セキュリティポリシに基づくセキュリティ選択のコード化
(3) WS-Security を用いたプロトタイプの実装
(4) 正式な ECU と CAN Gateway の利用
11. まとめ
1.11
18
)
ミ 100
リ
秒 50 18
部システムと車載システム間の通信に WS-Security と SSL
を適用することで，車載システムからユーザまでのセキュア
な通信を実現した．
9.2. プロトタイプの応答時間
プロトタイプとしてドアロック確認システムを開発し，セキ
ュリティ機能の処理時間を測定した．その結果，応答時間
の 9 割以上がセキュリティ機能の処理時間であった．また，
セキュリティ機能の処理時間の 8 割以上が SSL 通信の処理
時間であることを確認した．これは，JavaではSSL通信の暗
号処理に時間がかかるためだと考えられる．この問題の解
決方法として，JNI(Java Native Interface)を用いて C 言語で
実装されたネイティブコードと連携し，SSL 通信処理のパフ
ォーマンスを改善する方法がある．
30.4
175.2
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.

Download Report