JP2016113122A - 車載ネットワークの試験装置 - Google Patents

Abstract

【課題】車載ネットワークに流れるデータを介して車載制御装置に発生するセキュリティ上の脆弱性を早期に検出する車載ネットワークの試験装置を提供する。【解決手段】受信メッセージ識別子とデータペイロードの組み合わせを設計所定値からプロトコル上限まで逐次掃引して印加し、なおかつ網羅的にその組み合わせを試行しつつ車載制御装置１１０のリセットもしくは例外処理を監視することによって、車載制御装置１１０の脆弱性を検出するように車載ネットワークの試験装置１００を構成する。【選択図】図１

Description

本発明は、車載電子装置において、車載ネットワークに流れるデータを介して発露するセキュリティ上の脆弱性を検証する装置に関する。

２０１３年８月に開催された情報セキュリティの国際会議ＤＥＦＣＯＮ ２１（毎年、米国ネバダ州ラスベガスで開かれる世界最大のセキュリティ・カンファレンス）において、車載ネットワークであるＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）に流れる情報を解析し、その通信になりすますことで攻撃する実証実験の動画が公開された。これ以降、車載ネットワークおよびそれに繋がる車載電子装置のセキュリティに関する議論が注目を浴びている。

車載ネットワークの規格は公開された国際規格であることと、車内のクローズした環境で使用されることが前提であった。したがって、全体がすべて善意の設計者によりハンドリングされることしか想定されてこなかった。しかしながら、悪意の第三者が外部より接続し車両の制御に影響を与える可能性が明らかにされ、それが今まで誰も考えもしないこと（考え付いていても経済的合理性が不明で先送り）であったので、以後この脅威に対する議論が大いに盛り上がった。

特に将来技術として各社が取り組もうとしている自動運転などは、特定の局面では運転者の意志よりも車両制御ソフトの判断が優先される仕組みであり、これをテロ目的などで悪意の第三者に制御されると重大な人的および財産的危機を引き起こす恐れがある。

この脅威に対抗するものとして、現行インターネットの技術領域で使用されている暗号化や電子署名などの技術が、車載ネットワーク領域にも降りてくるものと推測される。しかしながら、これらの対策を順当に実施したとしても、問題となるのはバッファオーバーフローなど制御ソフトウェア（特に車載ネットワークをハンドリングするドライバソフトウェア群およびそれらのデータを使用したアプリケーションソフトウェア）の処理例外に起因する脆弱性である。バッファオーバーフローについては、統一的な方法論や根本的な解決方法がなく、個別かつ虱潰し的に該当ソフトウェアの問題点を見つけて対策していくしか方法がない。

バッファオーバーフローは、車載ネットワークを通じて送り込んだデータにより車載ＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）に処理中断をおこさせるか、最悪の場合、ネットワーク送信データを制御コード（マシン語）に見立ててそこに制御を移すことにより車載ＥＣＵを乗っ取ることが可能である。いずれにせよ、車載ＥＣＵにとっては良くて走行中のリセット（車両走行状態によっては大きな運転ショックが出る）、最悪のケースで悪意の第三者による制御ハイジャックに見舞われることになる。これは車両の運転者のみならず、交通社会にとって大いなる脅威である。

前述したようにバッファオーバーフローを防ぐためには、制御ソフトウェアのセキュアな作り込みや、検証を地道に行うことが肝要であり技術的な特効薬はない。また、ソフトウェアの改造や流用に当たって、新たな脆弱性が容易に作りこまれることもその特徴である。

ここで「セキュア」という表現は、「技術的に安全が保障された」という意味である。

パソコンのＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）であるＷｉｎｄｏｗｓ ＸＰ（登録商標）がライフサイクルの１２年が経過してその寿命（ライフサイクル）を終えてもセキュリティの脆弱性の観点では枯れなかったことがその証左である。

近年、制御ソフトウェアが巨大化していることによって、ホワイトボックステストでプログラムの網羅的な試験を実施することが困難になってきている。したがって、ファジング（非特許文献１参照）などの技術の応用によって脆弱性試験を実施することが現実的な対応策となってきている。

従来技術としては、インターネットにおけるコンテンツビューアの技術領域であり、必ずしも車載機器応用では無いが、例えば特許文献１に示すようにネットワーク入力を広範に可変として、例外処理が発生したモジュールを特定しコンテンツビューアの脆弱性の検出を行う検出装置およびバグ検出方法の技術が知られている。

特許第５３８６０１５号公報

"Ｆｕｚｚ Ｔｅｓｔｉｎｇ ｏｆ Ａｐｐｌｉｃａｔｉｏｎ Ｒｅｌｉａｂｉｌｉｔｙ"， Ｂａｒｔｏｎ Ｍｉｌｌｅｒ ＜ＵＲＬ：http://pages.cs.wisc.edu/~bart/fuzz/＞

しかしながら、上記特許文献１では、これをそのまま車載ネットワークの脆弱性検査に適用することはできない。一般のインターネットと車載ネットワークとではプロトコルが異なり、ネットワークを流れるデータの用途や意味も異なるからである。

また、非特許文献１で例示したファジングなどを応用した試験に際しても、車載制御ソフトウェアが脆弱性を抱え込む機序を理解して、テストケースをルール付しないと網羅的かつ効率的な検証はできない。

車載制御ソフトウェアで注目すべき脆弱性は、ネットワーク関連ドライバやアプリケーションのバッファオーバーエラーである。

一般的にはバッファオーバーエラーには主に２種類があって、スタックオーバーフローエラーとヒープオーバーフローエラーが挙げられる。しかしながら、車載制御機器関係の技術領域に限定すると、バッファオーバーエラーの中でも特に問題にすべきはスタックオーバーフローエラーであり、ヒープオーバーフローエラーではない。

車載制御ソフトウェアではヒープを使用することはない。ヒープのような動的なメモリ管理は、最悪実行時間の把握を難しくして再現性のない遅延を生むので、車載目的の制御ソフトウェアに関しては不向きであり、通常使用されない。（ヒープはソフトリアルタイム制御向きであり、自動車のようなハードリアルタイム制御には向いていない。）
車載制御装置では、Ｃ言語やＣ＋＋言語で制御ソフトウェアを記述している関係で言語の機構上スタックオーバーフローエラーの発生は避けられず、これを効率的に検証できる装置および手法が求められている。

車載ネットワークは、ＣＡＮからＣＡＮ ＦＤ（ＣＡＮ ｗｉｔｈ Ｆｌｅｘｉｂｌｅ Ｄａｔａ Ｒａｔｅ）およびＥｔｈｅｒｎｅｔ（登録商標）と１通信フレーム当たりのデータ量（ペイロード）が制御の高度化により年々巨大になってくると予想されている。

その際、低容量（小ペイロード）の通信プロトコルに適合した通信ソフトウェアをベースとして用い、これを流用し修正かつ改良して新プロトコルに対応すると想定されるが、スタック上のデータバッファを新プロトコルに合わせて適切に拡張するか、少なくともデータ格納溢れを意識した異常処理を作り込んでいないとスタックオーバーフローが容易に発生し、結果として脆弱性を作り込むことになる。

そこで本発明は、上記車載制御ソフトウェア特有の作り込み機序に起因する脆弱性を自動的に発見する車載ネットワークの試験装置を提供することを目的とする。

上記課題を解決するために、例えば特許請求の範囲に記載の構成を採用する。

本発明は上記課題を解決する手段を複数含んでいるが、その一例を挙げるならば、車載ネットワークから制御情報を取得して動作に反映させる車載電子装置に関して、この動作を検証するための車載ネットワークの試験装置であって、前記車載電子装置のＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）のリセット割り込み、アドレスエラー、もしくは不正命令割り込みの少なくともひとつを検出する異常検出器と、車載ネットワークに供給する送信メッセージを動的に変更するテストデータ生成器とで構成され、前記テストデータ生成器は該車載電子装置の受信可能なメッセージ識別子を蓄積した辞書と、単位メッセージ当たりのペイロード量を動的に変更して発生させるデータ発生器とで構成され、前記テストデータ生成器から発生させたメッセージ識別子とペイロードとの組み合わせデータを、車載ネットワーク経由で該車載電子装置に供給するとともに、前記異常検出器により前記車載電子装置のリセット割り込み、アドレスエラー、もしくは不正命令割り込みの少なくともひとつの発生を監視することを特徴とする。

本発明によれば、車載ネットワークに流れるデータを介して発生するスタックオーバーフローエラーを早期に網羅的に検証することによって、車両の脆弱性を摘出可能な試験装置および試験方法を提供することができる。

上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

本実施形態に係る車載ネットワーク試験装置の全体構成図である。 本発明が検出対象とするスタックオーバーフローエラーの機序をしめすメモリ配置図である。 本発明が検出対象とするスタックオーバーフローエラーが制御ソフトウェアに作り込まれる要因を示した解説図である。 本実施形態に係る車載ネットワーク試験装置の時系列動作を示したタイムチャートである。 本実施形態に係る車載ネットワーク試験装置の内部動作手順を示すフローチャートである。

以下、図面を用いて本発明の実施形態を説明する。

＜本実施形態の概要＞
本実施形態の試験装置では、試験対象の車載ＥＣＵが受信可能なメッセージ識別子をデータベースとしてテスト辞書を保持している。

同じくペイロード発生器は、上記各メッセージ識別子に対応する想定されたペイロード量（設計的に与えられソフトウェアに作り込まれたペイロード量）より大きなデータフレームを発生し、前記メッセージ識別子と合成して車載ネットワークに送出することができる。

一方、試験対象の車載ＥＣＵのＣＰＵ周辺にはデバッグポートもしくは類似の信号端子が用意されており、ＣＰＵのリセットあるいは例外処理の発生を捉えて本発明の試験装置に伝える結線が施されている。

本実施形態の試験装置では、上記メッセージ識別子とペイロードの組み合わせを自動的かつ網羅的に車載ネットワークに流し、試験対象の車載ＥＣＵの挙動、とくに例外処理が実行されたか、もしくはリセットが発生したか否かを自動的に調べることができる。

上述のスタックオーバーフローエラー作り込み機序を想定した脆弱性検出試験であるので、ペイロード量を通信で想定された量（設計値）よりプロトコルの上限一杯までスイープ（掃引）してテストすることが重要となる。

また、ペイロードのデータ自体は、車載制御装置ＥＣＵのＣＰＵに例外処理を引き起こしやすい値を設定することも重要となる。たとえば、値の候補としてアドレスに換算して例外ベクタに相当する値などが挙げられる。

＜実施の形態における構成＞
図１は、本発明の実施形態の一つを図示したものである。

車載ＥＣＵ・１１０は、車載ネットワーク１２０から情報を取り入れ制御に反映する。車載ＥＣＵ・１１０は本発明における被試験対象である。

本発明の試験装置１００は、接続１０９にて車載ネットワーク１２０に接続し、接続１１６にて車載ＥＣＵ・１１０の動作をモニタしている。

試験装置１００は、主にテストデータ生成器１０７と異常検出器１０１により構成されており、全体の動作はシーケンサー１０３により制御されて試験動作を実行する。

テストデータ生成器１０７の内部は、受信メッセージ識別子の辞書１０５、ペイロードのデータ発生器１０６、種となるデータ１０８、およびそれらを合成して送信フレームを生成するメッセージ合成器１０２より構成されている。

試験装置１００より車載ネットワーク１２０に送出された試験用送信メッセージは、車載ＥＣＵ・１１０内部のネットワークデバイス１１３に捕捉されてＣＰＵ１１１の作用よりＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１１２に転送されるが、そこで場合によっては後述の脆弱性が発生する局面を迎える。

ＲＡＭ１１２とＣＰＵ１１１は内部バス１１４で接続されており、関数の戻りアドレス（及びそれを格納したスタックフレーム）もＲＡＭ１１２内に格納されるが、これがネットワークから受信したデータにより破壊され、脆弱性を引き起こすのがその要因である。

ＣＰＵ１１１が脆弱性に見舞われると、リセットが発生するか、例外処理が行われるので、その状況をデバッグポート１１５より外部出力し、接続１１６を通じて試験機１００の異常検出器１０１が捕捉しシーケンサー１０３に報告する。

シーケンサー１０３は、脆弱性を捉えた旨、表示装置１０４を通じて外部の操作者に分かるように表示を行う。しかしながら、表示装置（もしくはマン・マシン・インターフェース）は図１の１０４で図示するように試験機１００の内部に包括されていてもよいし、例えば異常検知信号のみ外部に出力して、表示と記録は試験機１００と分離された別装置（図示せず）により行ってもよい。

上述のＣＰＵ１１１にリセットが発生する状況は、直接リセットベクタに制御が飛ぶ場合と、ソフトウェア暴走により外部ウォッチドックタイマからリセット信号が入る場合とがある。また、ＣＰＵ１１１に例外処理が発生する状況は、通常許可されていないアドレス空間を参照しようとしたアドレスエラーによるものと、異常なアドレスに遷移しそのビット列を命令として実行した結果、有り得ない（解読不能な）命令をフェッチしたことによる不当命令割り込みにより発生する場合がある。

いずれの場合も、デバッグポート１１５を経由して異常検出器１０１がこの状況を検出することが可能である。

上記の各構成、機能、処理部などは、それらの全部または一部を、例えば集積回路で設計することによりハードウェアとして実現することもできるし、プロセッサがそれぞれの機能を実現するプログラムを実行することによりソフトウェアとして実現することもできる。各機能を実現するプログラム、テーブルなどの情報は、メモリやハードディスクなどの記憶装置、ＩＣカード、ＵＳＢメモリ、ＳＤカード、ＣＤ−ＲＯＭ、ＤＶＤなどの記憶媒体に格納することができる。

＜脆弱性の原理と作り込み要因＞
図２は、スタックオーバーフローエラーがなぜ脆弱性たり得るのかを解説した図である。

バッファオーバーフローを利用して、制御ソフトウェアに想定外の動作をさせることができる。バッファオーバーフローには２種類があって、スタックオーバーフローとヒープオーバフローがあるが、車載制御ソフトウェアで問題になるのは前者のスタックオーバーフローであることは前述した通りである。

原理を解説すると、制御ソフトウェアはネットワークデータに限らず、外部から受け取ったデータを格納するために、バッファ２０３と呼ぶメモリ領域を確保する。あらかじめ決められた固定サイズのバッファを用意して、そこに受け取ったデータを書き込むのがソフトウェア処理の定石である。

一般に、受け取るデータの長さは可変である。そのため、制御ソフトウェアは受け取ったデータがバッファのサイズを超えないように、データの長さをチェックすべきである。ところが、アプリケーションの中には、データの長さのチェックを省略している場合がある。

例えば、通信データの１フレームを格納するバッファであって、１フレームの最大バイト数（ペイロードの上限値）が通信プロトコルの規格として決まっている場合、最大バイト数（ペイロードの上限値）分のバッファを一旦確保してしまえば、アプリケーションはことさら受け取ったデータ長さとバッファ全体長との比較チェックを行わないで済ましてしまうかもしれない。

このような制御ソフトウェアに対して、バッファのサイズを超えるデータを、例えば車載ネットワークから送り込むと、当然のようにバッファからデータが溢れる。溢れたデータは、プログラムが使っているほかのメモリ領域中のデータを上書きしてしまう。この結果、プログラムは正常に動作しなくなったり、ハングアップしてしまったりすることになる。

このように制御ソフトウェアの不具合を利用することで、制御ソフトウェアの正常な稼働を停止もしくは中断をさせることが可能になる。これをサービス妨害（ＤｏＳ：Ｄｅｎｉａｌ ｏｆ Ｓｅｒｖｉｃｅ）攻撃と呼ぶ。

ＤｏＳ攻撃による動作の停止や中断だけでなく、バッファオーバーフローを利用して意図したアクションを実行させるという攻撃も登場してきている。

Ｃ言語もしくはＣ＋＋言語の場合、プログラムは通常、あるプログラムが別の小さなプログラム（関数サブルーチン）に処理を依頼するように作られている。この関数サブルーチンは、ＲＡＭ（図１の１１２に相当）のメモリ上に一時的に利用するためのスタック領域２００を確保する。このスタック領域２００には、実際にサブルーチンが利用すべきローカル変数や呼び出し元プログラムのレジスタ内容等退避データのほか、前述したバッファ２０３やリターンアドレス２０４が書き込まれている。リターンアドレス２０４とは、サブルーチンによる処理が完了したら、元のプログラムへ戻るために利用するメモリのアドレスのことである。（図２の「正常な状態２０１」のリターンアドレス２０４参照）
このような状態で、前述のように送り込まれたデータ２０５がバッファ２０３よりも大きいと、データが溢れてしまい、リターンアドレス２０４が記述されたスタック領域２００を上書きしてしまうことも可能になる。そこで、図２の「不正なデータが送られた後の状態２０２」のように、送り込んだデータの溢れる部分２０６に、リターンアドレスとして別の値２０８を書き込んでおき、書き込まれたリターンアドレスが指定しているメモリ領域には攻撃者が望むようなコマンドを実行する不正な命令コード２０７を記述しておく。

この結果、該関数サブルーチンがリターンするタイミングで、呼出し元のプログラムが動作しているのと同じ権限で、任意のコマンド（不正な命令コード２０７）を実行できることになる。プログラムがスーパバイザモードのような強い権限で動いていると、こういった攻撃を受けると直ちに致命的な結果を招き、制御が攻撃者によりネットワーク越しに乗っ取られることになる。

図３は、このような脆弱性が作り込まれる要因を解説した図である。

図３では、スタック領域２００の内容が図２と比較して詳細に記述されており、リターンアドレス２０４の上（アドレスの若い方）に向かって順番に、ベースレジスタ等の退避レジスタの値が格納され、その上に呼び出された関数が使用する自動変数（ローカル変数）が乗る。自動変数（ローカル変数）の中には、呼び出された関数が使用するローカル変数とここで議論されている処理バッファ（３０２および３０４）が格納されるものとする。

通常のセキュアなコーディングでは、転送方式（ａ）のように、処理バッファ［ｎ］３０２とネットワークデバイス１１３の受信レジスタ３０１に格納されているデータの大きさを比較してチェック付き転送３０３のように処理バッファ［ｎ］３０２が溢れない範囲で、受信レジスタ３０１→処理バッファ［ｎ］３０２の転送が行われる。

しかしながら、転送方式（ｂ）のように、通信プロトコルの１フレーム当たりの最大バイト数（ペイロードの上限値）分の処理バッファ［ｐｒｏｔｏｃｏｌ＿ｍａｘ］３０４を確保してチェック無し転送３０５を行う場合も多い。

ここで問題になるのは、このようなチェック無し転送が行われるプログラムを最大バイト数（ペイロードの上限値）が異なる別のプロトコルの通信ソフトウェアとして流用した場合である。

流用先で処理バッファ［ｐｒｏｔｏｃｏｌ＿ｍａｘ］３０４の数を調整しなければ、流用先プロトコルの最大バイト数（ペイロードの上限値）が流用元に比べて大きい場合、容易にスタックオーバーフロー３０６を引き起こすことになる。

現状、ＣＡＮ→ＣＡＮ ＦＤ→Ｅｔｈｅｒｎｅｔと新しい通信規格ほど最大バイト数（ペイロードの上限値）が拡大される方向であるので、このような脆弱性がネットワーク対応した種々の車載ＥＣＵに内在化することが懸念される。

＜実施の形態における動作＞
図４は、試験装置１００の動作を示したタイムチャートである。

図４の横軸は、受信メッセージの識別子（ＩＤ）ごとに一群として纏められたテストケース４０２であり、すべての受信識別子のテストが網羅的に車載ＥＣＵ・１１０に供与され、応答が調べられる。

すべての受信識別子を網羅的に試行する理由は、受信識別子によって処理関数が異なり脆弱性発生個所も異なる状況を考慮したものである。

図４の縦軸は１フレーム当たりのペイロード数４０１であり、ペイロード想定値（設計値）より１バイトずつ増加させて連続的にテストケースが設定される。ペイロードの最大値は、言うまでもなくプロトコルで規定されたプロトコル上限値４０７である。

個別の受信ＩＤごとに挙動を見ていくと、受信ＩＤｎ−１・４０３では、ペイロード想定値Ｐｎ−１・４０４より１バイトずつペイロードを増加させてテストケースが組まれる。

このペイロード想定値というのは設計的に個別受信ＩＤに対して紐付けして決まっているもので、通常のネットワーク動作ではこのペイロード量で固定してネットワークメッセージがやりとりされる。この基本値は、受信ＩＤ値に対応づけて受信メッセージ識別子の辞書１０５に記憶されている。

受信ＩＤｎ−１・４０３のテスト群では、ペイロードをペイロード想定値４０４からプロトコル上限値４０７まで掃引して印加した結果、車載ＥＣＵ１１０に異常動作を引き起こすことはなかった。

続く受信ＩＤｎ・４０５ではペイロード想定値Ｐｎ・４０６から順次ペイロードを増やしてテストをしたところ、車載ＥＣＵ・１１０にリセットが発生（４０８）し、その時のペイロード値はＰｖｕｌｕｎｅ．４０９であった。

つまり、このペイロード値で図３の３０６の如くリターンアドレス２０４の書き換えが発生したことになる。

上記のような脆弱性を発見すれば、試験装置１００はその旨を図１で示す表示装置１０４で表示して動作を停止し、操作者の指示を仰ぐことになる。

図５は、試験装置１００の動作をフローチャートにて示したものである。図５の流れに従い順次動作を解説する。

ステップＳ５０１では、試験対象の車載ＥＣＵ・１１０が受信可能なメッセージＩＤを識別子辞書１０５より検索する。続く、ステップＳ５０２では該メッセージＩＤに紐づけされたペイロード想定値（図４のＰｎ−１・４０４およびＰｎ・４０６に相当）を検索し、変数Ｐに保持しておく。（図１ではＰ １２１の矢印として図示。）
ステップＳ５０３では、この変数Ｐがインクリメントされ、判定ステップＳ５０４でプロトコル上限値との比較が実行される。プロトコル上限を超えていればステップＳ５０５に遷移し、そうでなければステップＳ５０６により送信フレームを合成し車載ネットワーク１２０に送出する。

プロトコル上限値を超えていればステップＳ５０５に進んで受信可能メッセージＩＤのすべてに渡って網羅的にテストパターンを試行したかが確認される。受信可能メッセージＩＤの網羅が終了していなければＳ５０１に戻って、受信メッセージＩＤを変化させて一連の試験をやり直す。

判定ステップＳ５０４から引き続くステップＳ５０６では、Ｓ５０１で検索済みの受信メッセージＩＤと、Ｓ５０３で設定したプロトコル量をもとに算出したメッセージの長さ情報（ＣＡＮプロトコルで言えばＤＬＣ：Ｄａｔａ Ｌｅｎｇｔｈ Ｃｏｄｅ）、およびペイロード本体のビット列とが合成され、送信フレームの本体が形成される。

ペイロード本体のビット列としては、図３の現象３０６で言及したように、リターンアドレス２０４と置き換わった場合に、その現象が外部から観察されやすい値の繰り返しで構成されていた方が好都合である。

すなわち、該車載ＥＣＵ・１１０のＣＰＵがアドレス値として解釈した場合に、リセットベクタに合致してリセット割り込みを発生させるか、アドレス境界を逸脱してアドレスエラーを引き起こすか、もしくは不正または未定義命令の格納場所を指示して不正命令割り込みを発生させるかして、異常検出器１０１が検知可能な動作を引き起こす要因となるデータを予見的に生成して送信メッセージのペイロードとすることが好ましい。

したがって、この値は検査対象の車載ＥＣＵ・１１０に搭載されるＣＰＵアーキテクチャに依存して異なるが、上記の趣旨で値が決定されることは重要である。（試験装置の全体構成図である図１ではペイロードの種データ１０８として図示している。）
続くステップＳ５０７では、Ｓ５０６でテスト送信フレームをネットワークに送出した応答として車載ＥＣＵ・１１０の挙動が調べられる。車載ＥＣＵ・１１０にリセットや例外処理などの異常状態が発生していない場合はＳ５０３に戻り、発生している場合はステップＳ５０８で脆弱性を発見した旨の表示を行って動作を終了する。

Ｓ５０３に戻った場合は、ペイロード量をひとつ増加させて上記の一連の動作を繰り返すことになる。

図５のフローチャートでは、チャート簡略化の観点から各受信可能メッセージＩＤに対して（ペイロード想定値＋１）のペイロード量より試験が開始されるアルゴリズムで表現されているが、図４で示したようにペイロード想定値そのもののペイロード量より試験を開始してもよく、この違いは本発明の趣旨に影響を与えるような本質的な問題ではない。

以上、本発明の実施形態によれば、車載ネットワークに流れるデータを介して引き起こされる車載ＥＣＵの脆弱性を省人力で網羅的かつ自動的に検出することができる。

また本発明による試験装置は、ＣＡＮ、ＣＡＮ ＦＤ、Ｅｔｈｅｒｎｅｔ等、広範な通信プロトコルをベースとする車載ネットワークの試験に適用可能である。

１００：試験装置
１０１：異常検出器
１０２：メッセージ合成器
１０３：シーケンサー
１０４：表示装置
１０５：受信メッセージ識別子の辞書
１０６：ペイロードのデータ発生器
１０７：テストデータ生成器
１０８：ペイロードの種データ
１０９：［試験装置→車載ネットワーク］接続
１１０：車載ＥＣＵ
１１１：ＣＰＵ
１１２：ＲＡＭ
１１３：ネットワークデバイス
１１４：内部バス
１１５：デバッグポート
１１６：［車載ＥＣＵ→試験装置］接続
１２０：車載ネットワーク

Claims (5)

1. 車載ネットワークから制御情報を取得して動作に反映させる車載電子装置に関して、この動作を検証するための車載ネットワークの試験装置であって、
   前記車載電子装置のＣＰＵのリセット割り込み、アドレスエラー、もしくは不正命令割り込みの少なくともひとつを検出する異常検出器と、
   車載ネットワークに供給する送信メッセージを動的に変更するテストデータ生成器とで構成され、
   前記テストデータ生成器は該車載電子装置の受信可能なメッセージ識別子を蓄積した辞書と、単位メッセージ当たりのペイロード量を動的に変更して発生させるデータ発生器とで構成され、
   前記テストデータ生成器から発生させたメッセージ識別子とペイロードとの組み合わせデータを、車載ネットワーク経由で該車載電子装置に供給するとともに、前記異常検出器により前記車載電子装置のリセット割り込み、アドレスエラー、もしくは不正命令割り込みの少なくともひとつの発生を監視する
   ことを特徴とする車載ネットワークの試験装置。
2. 請求項１に記載の車載ネットワークの試験装置であって、
   前記テストデータ生成器を構成するデータ発生器が、メッセージ識別子に対して設計的に決められたペイロード量よりも大きなペイロードを発生させて車載ネットワークに供給し試験を行う
   ことを特徴とする車載ネットワークの試験装置。
3. 請求項２に記載の車載ネットワークの試験装置であって、
   前記テストデータ生成器を構成するデータ発生器が、メッセージ識別子に対して設計的に決められたペイロード量よりも大きなペイロードを発生させ、かつ車載ネットワークのプロトコルで決められた最大ペイロード量まで逐次掃引してテスト送信を実施して試験を行う
   ことを特徴とする車載ネットワークの試験装置。
4. 請求項１に記載の車載ネットワークの試験装置であって、
   前記テストデータ生成器が、前記車載電子装置の受信可能なメッセージ識別子を蓄積した辞書と単位メッセージ当たりのペイロード量を動的に変更して発生させるデータ発生器とで構成され、
   前記メッセージ識別子とペイロードデータとの組み合わせを網羅的に車載ネットワークに供給し試験を行う
   ことを特徴とする車載ネットワークの試験装置。
5. 請求項１に記載の車載ネットワークの試験装置であって、
   前記テストデータ生成器を構成するデータ発生器が、前記車載電子装置のＣＰＵがアドレス値として解釈した場合に、リセットベクタに合致してリセット割り込みを発生させるか、アドレス境界を逸脱してアドレスエラーを引き起こすか、もしくは不正または未定義命令の格納場所を指示して不正命令割り込みを発生させるかして、前記異常検出器が検知可能な通常とは異なる動作を引き起こす少なくともひとつの要因となるデータを生成して送信メッセージのペイロード内容とする
   ことを特徴とする車載ネットワークの試験装置。