(57)【要約】  検証装置に設けられる検証装置カウンタに同期される実装ユニットカウンタと、  前記実装ユニットカウンタのカウンタ値がある値である間、２回以上の異なるタイミングで、前記実装ユニットカウンタの前記カウンタ値に基づいて暗号化した実装ユニットＩＤを表す暗号化信号を、前記検証装置に送信する処理部とを備える、実装ユニットが開示される。
2017060979.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して複数のノードが接続されるシステムにおいて、複数の前記ノードの少なくとも１つを形成する実装ユニットであって、
前記ネットワーク上の検証装置に設けられる検証装置カウンタに同期される実装ユニットカウンタと、
前記実装ユニットカウンタのカウンタ値がある値である間、２回以上の異なるタイミングで、前記実装ユニットカウンタの前記カウンタ値に基づいて暗号化した実装ユニットＩＤを表す暗号化信号を、前記検証装置に送信する処理部とを備える、実装ユニット。
【請求項２】
第１時間毎にタイムアウトし、前記実装ユニットカウンタのカウンタ値を変化させる第１タイマと、
前記実装ユニットに設けられ、前記第１時間よりも短い第２時間毎にタイムアウトする第２タイマとを更に備え、
前記タイミングは、前記第２タイマがタイムアウトするときを含む、請求項１に記載の実装ユニット。
【請求項３】
前記タイミングは、更に、前記実装ユニットカウンタの前記カウンタ値が変化するときを含む、請求項２に記載の実装ユニット。
【請求項４】
前記第２タイマは、前記実装ユニットカウンタの前記カウンタ値が変化したときにセットされる、請求項２又は３に記載の実装ユニット。
【請求項５】
前記暗号化信号は、前記カウンタ値と、予め付与される共通鍵とに基づいて生成される、請求項１〜４のうちのいずれか１項に記載の実装ユニット。
【請求項６】
前記検証装置にＣＡＮ（Controller Area Network）に準拠した車両ネットワークを介して接続される、請求項１〜５のうちのいずれか１項に記載の実装ユニット。
【請求項７】
ネットワークを介して複数の実装ユニットが接続されるシステムの健全性を検証する検証装置であって、
複数の前記実装ユニットのそれぞれに設けられる実装ユニットカウンタと同期する検証装置カウンタと、
複数の前記実装ユニットのそれぞれが暗号化時点の前記実装ユニットカウンタのカウンタ値に基づいて暗号化した実装ユニットＩＤを表す暗号化信号であって、前記実装ユニットカウンタの前記カウンタ値がある値である間における２回以上の異なるタイミングで、複数の前記実装ユニットのそれぞれが送信する暗号化信号を、受信する第１の処理部と、
前記第１の処理部が前記暗号化信号を受信したときの前記検証装置カウンタのカウンタ値と、前記暗号化信号とに基づいて、前記システムの健全性を判断する第２の処理部とを備える、検証装置。
【請求項８】
前記第２の処理部は、前記検証装置カウンタの前記カウンタ値がある値である間に受信した全ての前記暗号化信号を復号して得た全ての異なる前記実装ユニットＩＤに基づいて、１つのハッシュ値を算出し、算出したハッシュ値に基づいて、前記システムの健全性を判定する、請求項７に記載の検証装置。
【請求項９】
前記第２の処理部は、算出した前記ハッシュ値と、複数の前記実装ユニットのそれぞれに係る正当な全ての前記実装ユニットＩＤに基づく１つの参照ハッシュ値との比較結果に基づいて、前記システムの健全性を判定する、請求項８に記載の検証装置。
【請求項１０】
ネットワークを介して複数のノードが接続されるシステムの健全性を検証する実装ユニット検証プログラムであって、複数の前記ノードの少なくとも１つを形成する実装ユニットのコンピューターに、
前記ネットワーク上の検証装置に設けられる検証装置カウンタに実装ユニットカウンタを同期させ、
前記実装ユニットカウンタのカウンタ値がある値である間、２回以上の異なるタイミングで、前記実装ユニットカウンタのカウンタ値に基づいて暗号化した実装ユニットＩＤを表す暗号化信号を、前記検証装置に送信する、
処理を、実行させる、実装ユニット検証プログラム。
【請求項１１】
ネットワークを介して複数の実装ユニットが接続されるシステムの健全性を検証する実装ユニット検証プログラムであって、前記ネットワーク上の検証装置のコンピューターに、
複数の前記実装ユニットのそれぞれに設けられる実装ユニットカウンタに、検証装置カウンタを同期させ、
複数の前記実装ユニットのそれぞれが暗号化時点の前記実装ユニットカウンタのカウンタ値に基づいて暗号化した実装ユニットＩＤを表す暗号化信号であって、前記実装ユニットカウンタの前記カウンタ値がある値である間における２回以上の異なるタイミングで複数の前記実装ユニットのそれぞれが送信する暗号化信号を、受信し、
前記暗号化信号を受信したときの前記検証装置カウンタのカウンタ値と、前記暗号化信号とに基づいて、前記システムの健全性を判断する、
処理を、実行させる、実装ユニット検証プログラム。
【請求項１２】
ネットワークを介して複数の実装ユニットが接続されるシステムの健全性を検証する実装ユニット検証方法であって、
複数の前記実装ユニットのそれぞれが、前記ネットワーク上の検証装置に設けられる検証装置カウンタに実装ユニットカウンタを同期させ、
複数の前記実装ユニットのそれぞれが、前記実装ユニットカウンタのカウンタ値がある値である間、２回以上の異なるタイミングで、前記実装ユニットカウンタの前記カウンタ値に基づいて暗号化した実装ユニットＩＤを表す暗号化信号を、前記検証装置に送信することを含む、実装ユニット検証方法。
【請求項１３】
ネットワークを介して複数の実装ユニットが接続されるシステムの健全性を検証する実装ユニット検証方法であって、
前記ネットワーク上の検証装置が、複数の前記実装ユニットのそれぞれに設けられる実装ユニットカウンタに検証装置カウンタを同期させ、
前記検証装置が、複数の前記実装ユニットのそれぞれが暗号化時点の前記実装ユニットカウンタのカウンタ値に基づいて暗号化した実装ユニットＩＤを表す暗号化信号であって、前記実装ユニットカウンタの前記カウンタ値がある値である間における２回以上の異なるタイミングで複数の前記実装ユニットのそれぞれが送信する暗号化信号を、受信し、
前記検証装置が、前記暗号化信号を受信したときの前記検証装置カウンタのカウンタ値と、前記暗号化信号とに基づいて、前記システムの健全性を判断することを含む、実装ユニット検証方法。
【請求項１４】
ネットワークを介して複数の実装ユニットが接続されるシステムの健全性を検証する実装ユニット検証システムであって、
複数の前記実装ユニットのそれぞれに設けられ、第１時間毎にカウンタ値が変化する実装ユニットカウンタと、
複数の前記実装ユニットのそれぞれに設けられ、前記実装ユニットカウンタの前記カウンタ値がある値である間、２回以上の異なるタイミングで、前記実装ユニットカウンタのカウンタ値に基づいて暗号化した実装ユニットＩＤを表す暗号化信号を、前記ネットワーク上の検証装置に送信する実装ユニット処理部と、
前記検証装置に設けられ、前記実装ユニットカウンタと同期し、前記第１時間毎にカウンタ値が変化する検証装置カウンタと、
前記検証装置に設けられ、前記暗号化信号を受信したときの検証装置カウンタのカウンタ値と、前記暗号化信号とに基づいて、前記システムの健全性を判断する検証装置処理部とを含む、実装ユニット検証システム。
【請求項１５】
ネットワークを介して複数の実装ユニットが接続されるシステムの健全性を検証する実装ユニット検証方法であって、
前記ネットワーク上の検証装置が、第１時間毎に検証装置カウンタのカウンタ値を変化させ、
複数の前記実装ユニットのそれぞれが、実装ユニットカウンタのカウンタ値を検証装置カウンタのカウンタ値に同期させ、
複数の前記実装ユニットのそれぞれが、前記実装ユニットカウンタの前記カウンタ値がある値である間、２回以上の異なるタイミングで、前記実装ユニットカウンタのカウンタ値に基づいて暗号化した実装ユニットＩＤを表す暗号化信号を、検証装置に送信し、
前記検証装置が、前記実装ユニットから暗号化された前記実装ユニットＩＤを受信したときの検証装置カウンタのカウンタ値と、前記暗号化信号とに基づいて、前記システムの健全性を判断することを含む、実装ユニット検証方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、実装ユニット、実装ユニット検証方法及び実装ユニット検証プログラムに関する。
【背景技術】
【０００２】
従来から、２つのノード間でそれぞれのカウンタのカウンタ値を同期させ、それぞれのノードにおいてそれぞれのカウンタ値を用いて暗号化や復号を行う検証方法が知られている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開2004-40660号公報
【特許文献２】特開2013-98719号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、複数の実装ユニットを含むシステムにおいては、システムの健全性を検証できる検証機構、即ち各実装ユニットが正当なユニットであること（不正に取り付けられたユニット等でないこと）を検証できる検証機構を持つことが有用である。これは、例えば、システム内に成りすましのユニットが設けられると、同成りすましのユニットが同システムの動作に悪影響を与えうるためである。【０００５】
この点、複数の実装ユニットのそれぞれが検証装置に向けて検証用の信号を送信し、該検証装置において受信した検証用の信号に基づいて、システムの健全性を判断する検証機構においては、以下の問題がある。即ち、かかる検証機構においては、ある実装ユニットは、他の優先度の高い信号の優先的な送信に起因して、検証用の信号を正常なタイミングで検証装置に送信できない場合があり得る。かかる場合には、システムの健全性を精度良く判定することが難しい。【０００６】
本開示は、実装ユニットを含むシステムにおいて該システムの健全性を精度良く検証できるようにすることを目的とする。
【課題を解決するための手段】
【０００７】
本開示の一局面によれば、ネットワークを介して複数のノードが接続されるシステムにおいて、複数の前記ノードの少なくとも１つを形成する実装ユニットであって、
前記ネットワーク上の検証装置に設けられる検証装置カウンタに同期される実装ユニットカウンタと、
前記実装ユニットカウンタのカウンタ値がある値である間、２回以上の異なるタイミングで、前記実装ユニットカウンタの前記カウンタ値に基づいて暗号化した実装ユニットＩＤを表す暗号化信号を、前記検証装置に送信する処理部とを備える、実装ユニットが提供される。
【発明の効果】
【０００８】
本開示によれば、実装ユニットを含むシステムにおいて該システムの健全性を精度良く検証できる。
【図面の簡単な説明】
【０００９】
【図１】車両システムの一例を概略的に示す図である。
【図２】検証装置のハードウェア構成の一例を示す図である。
【図３】実装ユニットのハードウェア構成の一例を示す図である。
【図４】検証装置の機能部の一例を示す図である。
【図５】実装ユニットの機能部の一例を示す図である。
【図６】検証装置により実行される初期化処理の一例を示すフローチャートである。
【図７】実装ユニットにより実行される初期化処理の一例を示すフローチャートである。
【図８】実装ユニットにより実行される報告処理の一例を示すフローチャートである。
【図９】実装ユニットにより実行される暗号化処理の一例を示すフローチャートである。
【図１０】検証装置により実行されるデバイスＩＤテーブル生成処理の一例を示すフローチャートである。
【図１１】デバイスＩＤテーブルの一例を示す図である。
【図１２】検証装置により実行されるハッシュテーブル生成処理の一例を示すフローチャートである。
【図１３】ハッシュテーブルの一例を示す図である。
【図１４】検証装置により実行される検証処理の一例を示すフローチャートである。
【図１５】報告処理及び検証処理の一部のタイミングチャートである。
【図１６】変形例を示すタイミングチャートである。
【発明を実施するための形態】
【００１０】
以下、添付図面を参照しながら各実施例について詳細に説明する。
【００１１】
図１は、車両システムの一例を概略的に示す図である。
【００１２】
車両システム１は、車両に実装される。車両システム１は、検証装置１０と、複数の実装ユニット２０−１〜２０−Ｎとを含む。検証装置１０及び複数の実装ユニット２０−１〜２０−Ｎは、有線及び／又は無線回線などで接続された車両ネットワーク２を介して、通信可能に接続される。車両ネットワーク２は、例えば、ＣＡＮ（Controller Area Network）やＬＩＮ（Local Interconnect Network）などの通信プロトコルに準拠する。以下では、一例として、車両ネットワーク２は、ＣＡＮに準拠することとする。
【００１３】
検証装置１０は、例えばＥＣＵ（Electronic Control Unit）により形成される。検証装置１０は、検証専用のＥＣＵにより形成されてもよいし、他の機能を持つＥＣＵにより実現されてもよい。
【００１４】
複数の実装ユニット２０−１〜２０−Ｎのそれぞれは、例えばＥＣＵにより形成される。例えば、実装ユニット２０−１〜２０−Ｎには、エンジンのような駆動装置を制御するＥＣＵ、制動装置を制御するＥＣＵ、ドアロック等のような各種装備品を制御するＥＣＵ等が含まれる。ただし、複数の実装ユニット２０−１〜２０−Ｎには、コンピューターを内蔵するセンサや、コンピューターを内蔵するアクチュエータ、コンピューターを内蔵するバッテリ等が含まれてもよい。複数の実装ユニット２０−１〜２０−Ｎのそれぞれには、それぞれ固有の実装ユニットＩＤが付与される。
【００１５】
複数の実装ユニット２０−１〜２０−Ｎの構成は、以下で説明する検証方法に関する限り、実装ユニットＩＤが異なる点を除いて同じである。従って、以下では、特に言及しない限り、複数の実装ユニット２０−１〜２０−Ｎのうちの、任意の代表の１つの実装ユニットについて説明する。以下では、複数の実装ユニット２０−１〜２０−Ｎのうちの、任意の代表の１つの実装ユニットを、「実装ユニット２０」と表す。
【００１６】
尚、車両ネットワーク２には、図１に点線にて概略的に示すように、外部ツール３０が接続可能とされる。外部ツール３０は、例えば車両のメーカーやディーラーのような信頼できる場所で使用されるツールである。外部ツール３０は、車両システム１の初期化時や、車両システム１内のデータを外部へ取り出す時に使用できる。
【００１７】
図２は、検証装置１０のハードウェア構成の一例を示す図である。
【００１８】
図２に示す例では、検証装置１０は、制御部１１、主記憶部１２、補助記憶部１３、ネットワークＩ／Ｆ部１６、カウンタ１７、及びタイマ１８を含む。尚、検証装置１０の検証機能に係る部位は、耐タンパ技術（内部回路の隠蔽処理）が施されてよい。
【００１９】
制御部１１は、主記憶部１２や補助記憶部１３に記憶されたプログラムを実行する演算装置である。
【００２０】
主記憶部１２は、ＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）などである。主記憶部１２は、制御部１１が実行する基本ソフトウェアであるＯＳ（Operating System）やアプリケーションソフトウェアなどのプログラムやデータを記憶又は一時保存する記憶装置である。
【００２１】
補助記憶部１３は、ＥＥＰＲＯＭ（Electrically Erasable Programmable Read-Only Memory）やＨＤＤ（Hard Disk Drive）などであり、アプリケーションソフトウェアなどに関連するデータを記憶する記憶装置である。補助記憶部１３には、予め用意されたプログラムのほか、車両出荷後に外部サーバーからダウンロードしたプログラム等が記憶（更新）されてもよい。
【００２２】
ネットワークＩ／Ｆ部１６は、車両ネットワーク２を介して接続された複数の実装ユニット２０との間のインターフェースである。
【００２３】
カウンタ１７は、専用のハードウェアとしてのカウンタ（例えばＣＰＵ：Central Processing Unitに内蔵されるカウンタ）により実現される。但し、カウンタ１７は、記憶装置（例えば主記憶部１２）における特定の記憶領域における値（カウンタ値）を、制御部１１がカウントアップする（書き換える）ことで、実現されてもよい。カウンタ１７、及びタイマ１８の機能は後述する。以下では、カウンタ１７、及びタイマ１８は、区別のために、それぞれ、「検証装置カウンタ１７」、及び「検証装置タイマ１８」と称する。
【００２４】
図３は、実装ユニット２０のハードウェア構成の一例を示す図である。
【００２５】
図３に示す例では、実装ユニット２０は、制御部２１、主記憶部２２、補助記憶部２３、ネットワークＩ／Ｆ部２６、カウンタ２７、第１タイマ２８、及び第２タイマ２９を含む。同様に、実装ユニット２０の検証機能に係る部位は、耐タンパ性を有するように耐タンパ技術が施されてよい。
【００２６】
制御部２１は、主記憶部２２や補助記憶部２３に記憶されたプログラムを実行する演算装置である。
【００２７】
制御部２１、主記憶部２２、及び補助記憶部２３は、検証装置１０のハードウェア構成における対応する部の説明と同様である。
【００２８】
ネットワークＩ／Ｆ部２６は、車両ネットワーク２を介して接続された検証装置１０との間のインターフェースである。
【００２９】
カウンタ２７は、カウンタ１７と同様、専用のハードウェアとしてのカウンタにより実現されてもよいし、特定の記憶領域における値（カウンタ値）を制御部２１がカウントアップする（書き換える）ことで実現されてもよい。カウンタ２７、第１タイマ２８、及び第２タイマ２９の機能は後述する。以下では、カウンタ２７、第１タイマ２８、及び第２タイマ２９は、区別のために、それぞれ、「実装ユニットカウンタ２７」、「第１タイマ２８」及び「第２タイマ２９」と称する。
【００３０】
図４は、検証装置１０の機能部の一例を示す図である。
【００３１】
検証装置１０は、初期化処理部１０１と、カウンタ管理部１０２と、デバイスＩＤテーブル生成部１０３（第１の処理部の一例）と、ハッシュテーブル生成部１０４と、検証処理部１０６と、検証装置記憶部１０９と、を含む。ハッシュテーブル生成部１０４及び検証処理部１０６は、第２の処理部の一例である。
【００３２】
初期化処理部１０１、カウンタ管理部１０２、デバイスＩＤテーブル生成部１０３、ハッシュテーブル生成部１０４、及び検証処理部１０６は、図２に示した制御部１１が１つ以上のプログラムを実行することでそれぞれ実現される。また、検証装置記憶部１０９は、図２に示した補助記憶部１３により実現される。
【００３３】
初期化処理部１０１は、例えば車両の工場出荷前に、外部ツール３０からシステム鍵の書込み要求と共にシステム鍵を受信し、受信したシステム鍵を検証装置記憶部１０９に記憶する。また、初期化処理部１０１は、システム鍵の書込み要求と共に、取得したシステム鍵を、複数の実装ユニット２０−１〜２０−Ｎに配布する。
【００３４】
カウンタ管理部１０２は、例えば車両の工場出荷前に、外部ツール３０からリセット指令を受信したときに、検証装置カウンタ１７及び検証装置タイマ１８をリセットする。また、カウンタ管理部１０２は、カウンタリセットコマンドを車両ネットワーク２を介して複数の実装ユニット２０−１〜２０−Ｎに送信する。
【００３５】
カウンタ管理部１０２は、例えばイグニッションスイッチのオン時に、検証装置カウンタ１７及び検証装置タイマ１８をリセットすると共に、カウンタリセットコマンドを車両ネットワーク２を介して複数の実装ユニット２０−１〜２０−Ｎに送信する。
【００３６】
カウンタ管理部１０２は、検証装置カウンタ１７及び検証装置タイマ１８のリセット後、検証装置タイマ１８が所定時間Ｔ１を計時する毎に、検証装置カウンタ１７のカウントアップを行う。
【００３７】
デバイスＩＤテーブル生成部１０３は、実装ユニット２０−１〜２０−Ｎから車両ネットワーク２を介して受信する情報に基づいて、デバイスＩＤテーブルを生成する。この動作例については後述する。デバイスＩＤテーブル生成部１０３は、生成したデバイスＩＤテーブルを検証装置記憶部１０９に記憶する。
【００３８】
ハッシュテーブル生成部１０４は、検証装置記憶部１０９内のデバイスＩＤテーブルに基づいて、ハッシュテーブルを生成する。ハッシュテーブル生成部１０４の動作例については後述する。
【００３９】
検証処理部１０６は、検証装置記憶部１０９内のハッシュテーブルに基づいて、実装ユニット２０−１〜２０−Ｎが正当な（不正でない）実装ユニットであるか否か、即ち車両システム１の健全性を判断（検証）する。この動作例については後述する。
【００４０】
検証装置記憶部１０９には、複数の実装ユニット２０−１〜２０−ＮのそれぞれのデバイスＩＤが予め記憶される。複数の実装ユニット２０−１〜２０−ＮのそれぞれのデバイスＩＤは、後述の検証処理部１０６による検証処理で用いられる。検証装置記憶部１０９には、複数の実装ユニット２０−１〜２０−ＮのそれぞれのデバイスＩＤに代えて、これらに基づき生成できる他の固有情報（例えば、後述の積算ハッシュ値）が記憶されてもよい。
【００４１】
図５は、実装ユニット２０の機能部の一例を示す図である。
【００４２】
実装ユニット２０は、初期化処理部２０１と、カウンタ管理部２０２と、報告処理部２０４（処理部の一例）と、ユニット記憶部２０９と、を含む。報告処理部２０４は、暗号化部２０３を含む。
【００４３】
初期化処理部２０１、カウンタ管理部２０２、及び報告処理部２０４は、図３に示した制御部２１が１つ以上のプログラムを実行することでそれぞれ実現される。また、ユニット記憶部２０９は、図３に示した補助記憶部２３により実現される。
【００４４】
初期化処理部２０１は、車両ネットワーク２を介して受信するシステム鍵の書込み要求に応答して、システム鍵をユニット記憶部２０９に記憶する。
【００４５】
カウンタ管理部２０２は、車両ネットワーク２を介して受信するカウンタリセットコマンドに応答して、実装ユニットカウンタ２７、第１タイマ２８及び第２タイマ２９をリセットする。
【００４６】
カウンタ管理部２０２は、実装ユニットカウンタ２７及び第１タイマ２８のリセット後、第１タイマ２８が所定時間Ｔ１を計時する毎に、実装ユニットカウンタ２７のカウントアップを行う。
【００４７】
報告処理部２０４は、暗号化部２０３が生成した暗号化ＩＤ信号（後述）を車両ネットワーク２を介して検証装置１０に送信する。報告処理部２０４は、実装ユニットカウンタ２７のカウンタ値が各値である間、２回以上の異なるタイミングで、暗号化部２０３に対して暗号化要求を出力する。従って、報告処理部２０４は、実装ユニットカウンタ２７のカウンタ値が各値である間、２回以上の異なるタイミングで、暗号化部２０３が生成した暗号化ＩＤ信号を車両ネットワーク２を介して検証装置１０に送信する。
【００４８】
暗号化部２０３は、報告処理部２０４からの暗号化要求を受信したときに、そのときの実装ユニットカウンタ２７のカウンタ値と、ユニット記憶部２０９に記憶されたシステム鍵とに基づいて、実装ユニットＩＤを暗号化する。実装ユニットＩＤは、実装ユニット２０に固有のＩＤであり、ユニット記憶部２０９に予め記憶される。暗号化部２０３は、暗号化した実装ユニットＩＤを表す信号（以下、「暗号化ＩＤ信号」とも称する）を生成する。
【００４９】
ユニット記憶部２０９には、対応する実装ユニット２０に係る実装ユニットＩＤが予め記憶される。
【００５０】
次に、車両システム１の実働時の動作例について説明する。
【００５１】
図６は、検証装置１０により実行される初期化処理の一例を示すフローチャートである。
【００５２】
ステップＳ６０２では、初期化処理部１０１は、初期化条件の成立イベントを検知したか否かを判定する。初期化条件の成立イベントは、任意である。以下では、一例として、初期化条件の成立イベントは、外部ツール３０からのシステム鍵の書込み要求の受信イベント、外部ツール３０からのリセット指令の受信イベント、及び、イグニッションスイッチがオンするオンイベントを含む。判定結果が"ＹＥＳ"の場合は、ステップＳ６０４に進み、判定結果が"ＮＯ"の場合は、そのまま終了する。
【００５３】
ステップＳ６０４では、初期化処理部１０１は、初期化条件の成立イベントが外部ツール３０からのシステム鍵の書込み要求の受信イベントであるか否かを判定する。判定結果が"ＹＥＳ"の場合は、ステップＳ６０６に進み、判定結果が"ＮＯ"の場合は、ステップＳ６１０に進む。
【００５４】
ステップＳ６０６では、初期化処理部１０１は、システム鍵の書込み条件が成立するか否かを判定する。システム鍵の書込み条件は、例えば、イグニッションスイッチがオフ状態であり、且つ、アクセサリースイッチがオン状態であるときに成立する。判定結果が"ＹＥＳ"の場合は、ステップＳ６０８に進み、判定結果が"ＮＯ"の場合は、そのまま終了する。
【００５５】
ステップＳ６０８では、初期化処理部１０１は、外部ツール３０からのシステム鍵の書込み要求と共に受信したシステム鍵を、検証装置記憶部１０９に記憶する。また、初期化処理部１０１は、システム鍵の書込み要求と共に受信したシステム鍵を、車両ネットワーク２を介して複数の実装ユニット２０−１〜２０−Ｎに送信する。
【００５６】
ステップＳ６１０では、初期化処理部１０１は、初期化条件の成立イベントが外部ツール３０からのリセット指令の受信イベント又はイグニッションスイッチのオンイベントであるか否かを判定する。判定結果が"ＹＥＳ"の場合は、ステップＳ６１２に進み、判定結果が"ＮＯ"の場合は、そのまま終了する。
【００５７】
ステップＳ６１２では、初期化処理部１０１は、カウンタ管理部１０２に対して初期化要求を出力する。この初期化要求に応答して、カウンタ管理部１０２は、検証装置カウンタ１７及び検証装置タイマ１８をリセットする。また、カウンタ管理部１０２は、初期化要求に応答して、カウンタリセットコマンドを車両ネットワーク２を介して複数の実装ユニット２０−１〜２０−Ｎに送信する。
【００５８】
図７は、実装ユニット２０により実行される初期化処理の一例を示すフローチャートである。
【００５９】
ステップＳ７０２では、初期化処理部２０１は、初期化条件の成立イベントを検知したか否かを判定する。初期化条件の成立イベントは、任意である。以下では、一例として、初期化条件の成立イベントは、検証装置１０からのシステム鍵の書込み要求の受信イベント、及び、検証装置１０からのカウンタリセットコマンドの受信イベントを含む。判定結果が"ＹＥＳ"の場合は、ステップＳ７０４に進み、判定結果が"ＮＯ"の場合は、そのまま終了する。
【００６０】
ステップＳ７０４では、初期化処理部２０１は、初期化条件の成立イベントが検証装置１０からのシステム鍵の書込み要求の受信イベントであるか否かを判定する。判定結果が"ＹＥＳ"の場合は、ステップＳ７０６に進み、判定結果が"ＮＯ"の場合は、ステップＳ７１０に進む。
【００６１】
ステップＳ７０６では、初期化処理部２０１は、システム鍵の書込み条件が成立するか否かを判定する。システム鍵の書込み条件は、同様に、例えば、イグニッションスイッチがオフ状態であり、且つ、アクセサリースイッチがオン状態であるときに成立する。判定結果が"ＹＥＳ"の場合は、ステップＳ７０８に進み、判定結果が"ＮＯ"の場合は、そのまま終了する。
【００６２】
ステップＳ７０８では、初期化処理部２０１は、検証装置１０からのシステム鍵の書込み要求と共に受信したシステム鍵を、ユニット記憶部２０９に記憶する。
【００６３】
ステップＳ７１０では、初期化処理部２０１は、初期化条件の成立イベントが検証装置１０からのカウンタリセットコマンドの受信イベントであるか否かを判定する。判定結果が"ＹＥＳ"の場合は、ステップＳ７１２に進み、判定結果が"ＮＯ"の場合は、そのまま終了する。
【００６４】
ステップＳ７１２では、初期化処理部２０１は、カウンタ管理部２０２に対して初期化要求を出力する。この初期化要求に応答して、カウンタ管理部２０２は、実装ユニットカウンタ２７、第１タイマ２８及び第２タイマ２９をリセットする。
【００６５】
図８は、実装ユニット２０により実行される報告処理の一例を示すフローチャートである。
【００６６】
ステップＳ８０２では、報告処理部２０４は、タイムアウトイベントを検知したか否かを判定する。タイムアウトイベントは、第１タイマ２８が所定時間Ｔ１を計時する毎に発生する第１タイムアウトイベントと、第２タイマ２９が所定時間Ｔ２を計時する毎に発生する第２タイムアウトイベントとを含む。ここで、所定時間Ｔ１は、所定時間Ｔ２よりも長く、例えば所定時間Ｔ２の２倍以上の長さを有する。判定結果が"ＹＥＳ"の場合は、ステップＳ８０４に進み、判定結果が"ＮＯ"の場合は、そのまま終了する。
【００６７】
ステップＳ８０４では、報告処理部２０４は、タイムアウトイベントが第１タイムアウトイベントであるか否かを判定する。判定結果が"ＹＥＳ"の場合は、ステップＳ８０６に進み、判定結果が"ＮＯ"の場合は、ステップＳ８０８に進む。
【００６８】
ステップＳ８０６では、報告処理部２０４は、実装ユニットカウンタ２７のカウンタ値を"１"だけインクリメントする。また、報告処理部２０４は、第２タイマ２９をセットする。これにより、第２タイマ２９は、この時点から計時を０から再開し、所定時間Ｔ２の経過後に、第２タイムアウトイベントを発生させる。
【００６９】
ステップＳ８０８では、報告処理部２０４は、暗号化部２０３に対して暗号化要求を出力する。
【００７０】
ステップＳ８１０では、報告処理部２０４は、ステップＳ８０８で出力した暗号化要求に応じて暗号化部２０３が生成した暗号化ＩＤ信号を、車両ネットワーク２を介して検証装置１０に送信（報告）する。
【００７１】
図８に示す処理によれば、報告処理部２０４は、所定時間Ｔ１が経過する毎に、又は、所定時間Ｔ２が経過する毎に、暗号化部２０３に対して暗号化要求を出力し、暗号化要求に応じて得られた暗号化ＩＤ信号を検証装置１０に送信する。ここで、所定時間Ｔ２は、上述のように、所定時間Ｔ１よりも短い。従って、第２タイマ２９は、実装ユニットカウンタ２７のカウンタ値が各値である間、少なくとも１回以上、第２タイムアウトイベントを発生させる。即ち、第２タイマ２９は、実装ユニットカウンタ２７のカウンタ値がある値に変化してから次の値に変化するまでの間、少なくとも１回以上、第２タイムアウトイベントを発生させる。第２タイムアウトイベントの発生タイミングは、第１タイムアウトイベントの発生タイミングとは異なる。従って、報告処理部２０４は、実装ユニットカウンタ２７のカウンタ値が各値である間、２回以上の異なるタイミング（第１タイムアウトイベント及び第２タイムアウトイベントの各発生タイミング）で、暗号化ＩＤ信号を検証装置１０に送信できる。
【００７２】
図９は、実装ユニット２０により実行される暗号化処理の一例を示すフローチャートである。
【００７３】
ステップＳ９０２では、暗号化部２０３は、報告処理部２０４から暗号化要求を受信したか否かを判定する。判定結果が"ＹＥＳ"の場合は、ステップＳ９０４に進み、判定結果が"ＮＯ"の場合は、そのまま終了する。
【００７４】
ステップＳ９０４では、暗号化部２０３は、現時点の実装ユニットカウンタ２７のカウンタ値を取得する。
【００７５】
ステップＳ９０５では、暗号化部２０３は、取得したカウンタ値が有効な値を持つか否かを判定する。尚、上述の初期化処理が正常に実行され且つ実装ユニットカウンタ２７が正常である場合は、基本的には、取得したカウンタ値は有効な値を持つことになる。判定結果が"ＹＥＳ"の場合は、ステップＳ９０６に進み、判定結果が"ＮＯ"の場合は、そのまま終了する。
【００７６】
ステップＳ９０６では、暗号化部２０３は、システム鍵をユニット記憶部２０９から読み出す。
【００７７】
ステップＳ９０７では、暗号化部２０３は、読み出したシステム鍵が有効な値を持つか否かを判定する。尚、上述の初期化処理が正常に実行された場合は、基本的には、読み出したシステム鍵は有効な値を持つことになる。判定結果が"ＹＥＳ"の場合は、ステップＳ９０８に進み、判定結果が"ＮＯ"の場合は、そのまま終了する。
【００７８】
ステップＳ９０８では、暗号化部２０３は、ステップＳ９０４で得たカウンタ値と、ステップＳ９０６で得たシステム鍵とに基づいて、暗号鍵を生成する。暗号鍵の生成方法は任意であるが、暗号鍵の生成方法は、一例として、以下の方法が用いられる。
Enc-Key= Sys-Key EXOR Cntr(d)        式（１）
ここで、Enc-Keyは、暗号鍵を表し、Sys-Keyは、システム鍵を表し、Cntr(d)は、現時点の実装ユニットカウンタ２７のカウンタ値を表す。式（１）による暗号化によれば、暗号鍵は、現時点の実装ユニットカウンタ２７のカウンタ値とシステム鍵との排他的論理和を取ることで導出される。
【００７９】
ステップＳ９１０では、暗号化部２０３は、ステップ９０８で生成した暗号鍵に基づいて、ユニット記憶部２０９に記憶された実装ユニットＩＤを暗号化して、暗号化ＩＤ信号を生成する。即ち、以下のとおりである。
Rep=Enc(Enc-Key, Dev-ID)        式（２）
ここで、Repは、暗号化された実装ユニットＩＤであり、暗号化ＩＤ信号に含まれる。Dev-IDは、実装ユニットＩＤを表し、Enc(Enc-Key, Dev-ID)は、暗号鍵Enc-KeyによるDev-IDの暗号化を表す。このようにして生成された暗号化ＩＤ信号は、上述した報告処理のステップＳ８１０にて検証装置１０に向けて送信されることになる。
【００８０】
図９に示す処理によれば、暗号化部２０３は、実装ユニットカウンタ２７等のリセット後（ステップＳ７１２参照）、所定時間Ｔ１が経過する毎に、又は、所定時間Ｔ２が経過する毎に、報告処理部２０４からの暗号化要求に応答して、暗号化ＩＤ信号を生成する。所定時間Ｔ２は、上述のように、所定時間Ｔ１よりも短い。従って、第２タイマ２９は、実装ユニットカウンタ２７のカウンタ値が各値である間、少なくとも１回以上、第２タイムアウトイベントを発生させる。暗号化ＩＤ信号は、上述のように、現時点の実装ユニットカウンタ２７のカウンタ値に基づいて、実装ユニットＩＤを暗号化することで生成される。従って、実装ユニット２０が正当な実装ユニットである場合は、実装ユニットカウンタ２７のカウンタ値がある値である間の２回以上の第２タイムアウトイベントに対しては、同一の暗号化ＩＤ信号が生成される。この結果、実装ユニット２０が正当な実装ユニットである場合は、報告処理部２０４は、実装ユニットカウンタ２７のカウンタ値が各値である間、２回以上の異なるタイミングで、同一の暗号化ＩＤ信号を検証装置１０に送信できる。
【００８１】
図１０は、検証装置１０により実行されるデバイスＩＤテーブル生成処理（記録処理）の一例を示すフローチャートである。
【００８２】
ステップＳ１００２では、デバイスＩＤテーブル生成部１０３は、車両ネットワーク２を介して暗号化ＩＤ信号を受信したか否かを判定する。判定結果が"ＹＥＳ"の場合は、ステップＳ１００４に進み、判定結果が"ＮＯ"の場合は、そのまま終了する。
【００８３】
ステップＳ１００４では、デバイスＩＤテーブル生成部１０３は、システム鍵を検証装置記憶部１０９から読み出すと共に、現時点の検証装置カウンタ１７のカウンタ値を取得する。
【００８４】
ステップＳ１００６では、デバイスＩＤテーブル生成部１０３は、読み出したシステム鍵が有効な値を持ち、且つ、取得したカウンタ値が有効な値を持つか否かを判定する。尚、上述の初期化処理が正常に実行された場合は、基本的には、読み出したシステム鍵は有効な値を持つことになる。また、上述の初期化処理が正常に実行され且つ検証装置カウンタ１７が正常である場合は、基本的には、取得したカウンタ値は有効な値を持つことになる。判定結果が"ＹＥＳ"の場合は、ステップＳ１００８に進み、判定結果が"ＮＯ"の場合は、そのまま終了する。
【００８５】
ステップＳ１００８では、デバイスＩＤテーブル生成部１０３は、ステップＳ１００４で得たカウンタ値と、ステップＳ１００４で得たシステム鍵とに基づいて、暗号鍵を生成する。暗号鍵の生成方法は、実装ユニット２０における同方法と同じである（ステップＳ９０８参照）。具体的には、暗号鍵の生成方法は、一例として、以下の方法が用いられる。
Enc-Key= Sys-Key EXOR Cntr(m)        式（３）
ここで、Enc-Keyは、暗号鍵を表し、Sys-Keyは、システム鍵を表し、Cntr(m)は、現時点の検証装置カウンタ１７のカウンタ値を表す。
【００８６】
ステップＳ１０１０では、デバイスＩＤテーブル生成部１０３は、ステップＳ１００８で生成した暗号鍵に基づいて、ステップＳ１００２で受信した暗号化ＩＤ信号を復号（デクリプト）する。復号方法は、実装ユニット２０において行われる暗号化（ステップＳ９１０）の方法に依存する。一例として、以下の方法が用いられる。
Dev-ID＝decrypt(Rep, Enc-Key)        式（４）
ここで、decrypt(Rep, Enc-Key)は、暗号鍵Enc-KeyによるRepの復号を表す。以下では、このようにして取り出されたデバイスＩＤを図中に符号で表すとき、区別のため、"decrypted Dev-ID"で表す。
【００８７】
ステップＳ１０１２では、デバイスＩＤテーブル生成部１０３は、ステップＳ１００４で得たカウンタ値に対応するデバイスＩＤテーブルに、ステップＳ１０１０で得たデバイスＩＤを記録する。ここでは、一例として、デバイスＩＤテーブル生成部１０３は、ステップＳ１０１０で得たデバイスＩＤを、デバイスＩＤテーブルに昇順に記録することで、ステップＳ１００４で得たカウンタ値に対応するデバイスＩＤテーブルを生成（更新）する。尚、ステップＳ１０１０で得たデバイスＩＤが、ステップＳ１００４で得たカウンタ値に対応するデバイスＩＤテーブルに、既に記録されている場合（例えば、同じ実装ユニット２０からの２回目以降の受信の場合）は、デバイスＩＤテーブル生成部１０３は、同デバイスＩＤテーブルを更新しない。
【００８８】
デバイスＩＤテーブルは、図１１に示すように、検証装置カウンタ１７のカウンタ値毎に用意され、各検証装置カウンタ１７のカウンタ値のときに復号された１つ以上のデバイスＩＤを表す。例えば、デバイスＩＤテーブルは、例えば検証装置カウンタ１７のＭ個のカウンタ値に対応できるように、Ｍ個設定される。この場合、検証装置カウンタ１７のカウンタ値が更新される毎に、最も古いカウンタ値に係るデバイスＩＤテーブルが解放され、該デバイスＩＤテーブルに、新たなカウンタ値に係るデバイスＩＤが記憶される。図１１に示す例では、検証装置カウンタ１７のカウンタ値＝０のときと、検証装置カウンタ１７のカウンタ値＝１のときのそれぞれのデバイスＩＤテーブルが示されている。図１１に示す例では、検証装置カウンタ１７のカウンタ値＝０と１のときは、共に、"XXXXX1"〜"XXXX10"のデバイスＩＤが復号されたことを表す。"XXXXX1"〜"XXXX10"のデバイスＩＤの数は、検証装置カウンタ１７のカウンタ値＝０のときに、車両ネットワーク２を介して検証装置１０が正常に受信できた暗号化ＩＤ信号に基づく実装ユニットの数に対応する。図１１に示す例では、検証装置カウンタ１７のカウンタ値が０と１のときでは、暗号化ＩＤ信号が検証装置１０で正常に受信された実装ユニットの数が同一であるが、必ずしも同一とならない場合がある。尚、車両システム１の健全性が確保されている状態では、基本的には、"XXXXX1"〜"XXXX10"のデバイスＩＤの数は、複数の実装ユニット２０−１〜２０−Ｎの全数に対応する。
【００８９】
図１０に示す処理よれば、検証装置１０は、車両ネットワーク２を介して暗号化ＩＤ信号を受信する毎に、その時点（複合時点）の検証装置カウンタ１７のカウンタ値と、システム鍵とに基づいて、暗号化ＩＤ信号を復号する。検証装置１０は、復号の結果として得られるデバイスＩＤに基づいて、デバイスＩＤテーブルを生成する。このようにして、検証装置１０は、車両ネットワーク２を介して暗号化ＩＤ信号を受信する毎に、暗号化ＩＤ信号から得たデバイスＩＤに基づいて、デバイスＩＤテーブルを生成（更新）する。尚、検証装置カウンタ１７のカウンタ値が変化すると、その直前のカウンタ値に係るデバイスＩＤテーブルは更新できなくなる（確定される）。以下、このようにして確定されるデバイスＩＤテーブルを、「確定されたデバイスＩＤテーブル」とも称する。
【００９０】
図１２は、検証装置１０により実行されるハッシュテーブル生成処理（積算ハッシュ値算出処理）の一例を示すフローチャートである。
【００９１】
ステップＳ１２０２では、ハッシュテーブル生成部１０４は、検証装置タイマ１８のタイムアウトイベントを検知したか否かを判定する。検証装置タイマ１８は、所定時間Ｔ１を計時する毎にタイムアウトイベントを発生させる。
【００９２】
ステップＳ１２０４では、ハッシュテーブル生成部１０４は、現時点の検証装置カウンタ１７のカウンタ値を取得する。尚、この時点で取得する検証装置カウンタ１７のカウンタ値は、ステップＳ１２０２で検知したタイムアウトイベントに応じてカウンタ管理部１０２により"１"だけインクリメントされた後のカウンタ値である。
【００９３】
ステップＳ１２０６では、ハッシュテーブル生成部１０４は、ステップＳ１２０４で取得したカウンタ値が有効な値を持つか否かを判定する。判定結果が"ＹＥＳ"の場合は、ステップＳ１２０８に進み、判定結果が"ＮＯ"の場合は、そのまま終了する。
【００９４】
ステップＳ１２０８では、ハッシュテーブル生成部１０４は、ステップＳ１２０４で得たカウンタ値から"１"を引いたカウンタ値に係るデバイスＩＤテーブル（確定されたデバイスＩＤテーブル）に基づいて、積算ハッシュ値を算出する。即ち、ハッシュテーブル生成部１０４は、ステップＳ１２０２で検知したタイムアウトイベントに起因して確定されたデバイスＩＤテーブルに基づいて、積算ハッシュ値を生成する。
【００９５】
検証装置カウンタ１７のカウンタ値がｉのときの積算ハッシュ値Accumulated Hash(i)は、例えば、以下のように算出される。ハッシュテーブル生成部１０４は、カウンタ値＝ｉに対応するデバイスＩＤテーブルに記録された全てのデバイスＩＤのハッシュ値を算出する。次いで、ハッシュテーブル生成部１０４は、式（５）に示すように、算出した各ハッシュ値について、デバイスＩＤの昇順に排他的論理和を繰り返して取ることで、積算ハッシュ値Accumulated Hash(i)を算出する。
Hash Value(0) ＝Hash Value(0) EXOR Hash Value(Dev-ID x)        式（５）
ここで、右辺のHash Value(0)の初期値は、例えば、検証装置カウンタ１７のカウンタ値＝ｉに対応するデバイスＩＤテーブルの1番目のデバイスＩＤのハッシュ値である。この場合、図１１に示す例では、右辺のHash Value(0)の初期値は、デバイスＩＤ"XXXXX1"のハッシュ値である。Hash Value(Dev-ID x)は、検証装置カウンタ１７のカウンタ値＝ｉに対応するデバイスＩＤテーブルにｘ番目（ｘ＝２，３，...，ｊ）に記録された各デバイスＩＤのハッシュ値である。尚、ハッシュ値Hash Value(Dev-ID x)の算出には、SHA（Secure Hash Algorithm）‐256などのハッシュ関数を用いることができる。ｊは、検証装置カウンタ１７のカウンタ値＝ｉに対応するデバイスＩＤテーブルに記録されたデバイスＩＤの全数である。左辺のHash Value(0)は、右辺のHash Value(0)とHash Value(Dev-ID x)との排他的論理和を取ることで得られる値である。左辺のHash Value(0)は、繰り返しの次の計算では、右辺のHash Value(0)として用いられる。
【００９６】
具体的には、まず、ハッシュテーブル生成部１０４は、ｘ＝２として式（５−１）の計算を行う。
Hash Value(0) ＝Hash Value(Dev-ID 1) EXOR Hash Value(Dev-ID 2)      式（５−１）
次に、ハッシュテーブル生成部１０４は、ｘ＝３として式（５−２）の計算を行い、Hash Value(0)を更新する。
Hash Value(0) ＝Hash Value(0) EXOR Hash Value(Dev-ID 3)        式（５−２）
尚、式（５−２）における右辺のHash Value(0) は、式（５−１）で得られた左辺のHash Value(0)に対応する。
次に、ハッシュテーブル生成部１０４は、ｘ＝４として式（５−３）の計算を行い、Hash Value(0)を更新する。
Hash Value(0) ＝Hash Value(0) EXOR Hash Value(Dev-ID 4)        式（５−３）
尚、式（５−３）における右辺のHash Value(0) は、式（５−２）で得られた左辺のHash Value(0)に対応する。
以下、ハッシュテーブル生成部１０４は、ｘ＝５，６，...といった具合にｘを増加させ、ｘ＝ｊとなるまで式（５）の計算を繰り返し、ｘ＝ｊのときに得られた左辺のHash Value(0)を、積算ハッシュ値Accumulated Hash(i)とする。
Accumulated Hash(i) ＝Hash Value(0) EXOR Hash Value(Dev-ID j)    式（５−４）
ステップＳ１２１０では、ハッシュテーブル生成部１０４は、ハッシュテーブルにおいて、ステップＳ１２０４で得たカウンタ値から"１"を引いたカウンタ値に、ステップＳ１２０８で算出した積算ハッシュ値を対応付けて記録する。即ち、ハッシュテーブル生成部１０４は、積算ハッシュ値を得るために用いたデバイスＩＤテーブルに係るカウンタ値に、同積算ハッシュ値を紐付けて記録することで、ハッシュテーブルを生成する。
【００９７】
図１３は、ハッシュテーブルの一例を示す。図１３には、検証装置カウンタ１７のカウンタ値が０〜Ｎのそれぞれのときの積算ハッシュ値Accumulated Hash（0）〜Accumulated Hash（N）が示されている。尚、図１２に示す処理によれば、検証装置カウンタ１７のカウンタ値＝０のときの積算ハッシュ値Accumulated Hash（0）は、上述のように、検証装置カウンタ１７のカウンタ値＝１になったときに（ステップＳ１２０２の"ＹＥＳ"）に、演算される。但し、検証装置カウンタ１７のカウンタ値＝０のときの積算ハッシュ値Accumulated Hash（0）は、検証装置カウンタ１７のカウンタ値＝１になった後の任意のタイミングで演算されてもよい。
【００９８】
図１２に示す処理によれば、検証装置カウンタ１７のカウンタ値毎に、同カウンタ値であるときに得られた１つ以上のデバイスＩＤに基づいて、１つのハッシュ値（積算ハッシュ値）が算出される。尚、積算ハッシュ値は、１つ以上のデバイスＩＤのそれぞれのハッシュ値に基づいて算出されるので、車両システム１の健全性を表す指標値となる。１つ以上のデバイスＩＤのそれぞれの集合も、車両システム１の健全性を表す指標値であるが、必要とされる記憶領域（データ量）の低減の観点及び後述の比較処理の負荷低減の観点からは、積算ハッシュ値の方が有利となる。
【００９９】
図１４は、検証装置１０により実行される検証処理の一例を示すフローチャートである。
【０１００】
ステップＳ１４０２では、検証処理部１０６は、検証装置タイマ１８のタイムアウトイベントを検知したか否かを判定する。検証装置タイマ１８は、上述のように、所定時間Ｔ１を計時する毎にタイムアウトイベントを発生させる。
【０１０１】
ステップＳ１４０４では、検証処理部１０６は、現時点の検証装置カウンタ１７のカウンタ値を取得する。尚、この時点で取得する検証装置カウンタ１７のカウンタ値は、ステップＳ１４０２で検知したタイムアウトイベントに応じてカウンタ管理部１０２により"１"だけインクリメントされた後のカウンタ値である。
【０１０２】
ステップＳ１４０６では、検証処理部１０６は、ステップＳ１４０４で取得したカウンタ値が有効な値を持つか否かを判定する。判定結果が"ＹＥＳ"の場合は、ステップＳ１４０８に進み、判定結果が"ＮＯ"の場合は、そのまま終了する。
【０１０３】
ステップＳ１４０８では、検証処理部１０６は、ハッシュテーブルに基づいて、ステップＳ１４０４で得たカウンタ値から"１"を引いたカウンタ値に係る積算ハッシュ値を取得する。即ち、検証処理部１０６は、直近に算出された積算ハッシュ値を取得する。例えば、ステップＳ１４０４で得たカウンタ値から"１"を引いたカウンタ値が"ｉ"であるとき、検証処理部１０６は、ハッシュテーブルに基づいて、積算ハッシュ値accumulated Hash(i)を取得する。
【０１０４】
ステップＳ１４１０では、検証処理部１０６は、検証装置記憶部１０９に記憶された正当な複数の実装ユニット２０−１〜２０−ＮのそれぞれのデバイスＩＤに基づいて、正当な積算ハッシュ値を算出する。以下、正当な複数の実装ユニット２０−１〜２０−ＮのそれぞれのデバイスＩＤに基づいて算出される正当な積算ハッシュ値を、区別のために、「マスタ積算ハッシュ値」と称する。マスタ積算ハッシュ値の算出方法自体は、上述した積算ハッシュ値accumulated Hashの算出方法と同じである（図１２のステップＳ１２０８の説明参照）。マスタ積算ハッシュ値の算出方法は、同算出に用いるデバイスＩＤが、正当な複数の実装ユニット２０−１〜２０−Ｎの各デバイスＩＤ（予め記憶されたデバイスＩＤ）である点が、上述した積算ハッシュ値の算出方法に対して、異なるだけである。
【０１０５】
尚、マスタ積算ハッシュ値は、正当な複数の実装ユニット２０−１〜２０−Ｎの組み合わせが事後的に変わらない限り、固定値である。従って、マスタ積算ハッシュ値は、正当な複数の実装ユニット２０−１〜２０−ＮのそれぞれのデバイスＩＤに代えて又は加えて、予め検証装置記憶部１０９に記憶されてもよい。この場合、ステップＳ１４１０では、検証処理部１０６は、検証装置記憶部１０９に記憶されたマスタ積算ハッシュ値を取り出せばよい。或いは、正当な複数の実装ユニット２０−１〜２０−ＮのそれぞれのデバイスＩＤの各ハッシュ値が、同デバイスＩＤに代えて又は加えて、予め検証装置記憶部１０９に記憶されてもよい。この場合、ステップＳ１４１０では、検証処理部１０６は、検証装置記憶部１０９に記憶された各ハッシュ値に基づいて、マスタ積算ハッシュ値を算出する。
【０１０６】
ステップＳ１４１２では、検証処理部１０６は、ステップＳ１４０８で得た積算ハッシュ値と、ステップＳ１４１０で得たマスタ積算ハッシュ値とが同一であるか否かを判定する。判定結果が"ＹＥＳ"の場合は、そのまま終了し、判定結果が"ＮＯ"の場合は、ステップＳ１４１４に進む。
【０１０７】
ステップＳ１４１４では、検証処理部１０６は、車両システム１の健全性が損なわれている可能性があることを示す情報（以下、単に「異常情報」と称する）を出力する。異常情報は、任意の態様で出力されてもよい。例えば、異常情報は、メータなどの表示装置に出力されてもよいし、音声出力装置を介して音声により出力されてもよい。また、異常情報は、ダイアグ情報として所定の記憶装置に記憶されてもよい。
【０１０８】
図１４に示す処理によれば、ハッシュテーブルに記録された積算ハッシュ値がマスタ積算ハッシュ値と比較され、比較の結果、ハッシュテーブルに記録された積算ハッシュ値がマスタ積算ハッシュ値と異なる場合は、異常情報が出力される。これにより、車両システム１の健全性が損なわれている可能性がある場合に、その旨の異常情報を出力できる。
【０１０９】
尚、図１４に示す処理では、検証装置タイマ１８のタイムアウトイベントが検知される毎に、新たな積算ハッシュ値が記録されたハッシュテーブルに基づいて、同積算ハッシュ値とマスタ積算ハッシュ値とが比較されることで、車両システム１の健全性が判断される。しかしながら、かかる検証処理は、必ずしも、検証装置タイマ１８のタイムアウトイベントが検知される毎に、実行される必要はない。例えば、かかる検証処理は、検証装置タイマ１８の複数回のタイムアウトイベントが検知される毎に、新たな複数の積算ハッシュ値が記録されたハッシュテーブルに基づいて、同複数の積算ハッシュ値に対して一括的に実行されてもよい。
【０１１０】
図１５は、上述した報告処理及び検証処理の一部のタイミングチャートである。図１５では、ラインＬ１よりも上側に、実装ユニット２０におけるタイミングチャートが示され、ラインＬ１よりも下側に、検証装置１０におけるタイミングチャートが示されている。図１５において、横軸は時間であり、横線に付された下向きの矢印は、時間軸上のタイミングを表す。ラインＬ１よりも上側には、上から順に、第１タイムアウトイベントの発生タイミング、実装ユニットカウンタ２７のカウンタ値、第２タイムアウトイベントの発生タイミング、及び報告処理の実行タイミングに係る各タイミングチャートが示されている。ラインＬ１よりも下側には、上から順に、検証装置タイマ１８のタイムアウトイベントの発生タイミング、検証装置カウンタ１７のカウンタ値、及び記録処理の実行タイミング（デバイスＩＤテーブルの更新タイミング）に係る各タイミングチャートが示されている。また、記録処理に係るタイミングチャートの下側には、上から順に、ハッシュテーブルの更新タイミング（積算ハッシュ値の算出タイミング）、及び検証処理の実行タイミングに係る各タイミングチャートが示されている。図１５において、点線の各矢印Ｔｒ１乃至Ｔｒ９は、報告処理とそれに応じた記録処理との対応関係を示す。
【０１１１】
図１５に示すように、実装ユニット２０からの報告処理は、第１タイムアウトイベント及び第２タイムアウトイベントの各発生タイミングでそれぞれ実行される。この報告処理を受けて、検証装置１０による上述のデバイスＩＤテーブル生成処理が実行される。また、検証装置カウンタ１７のカウントアップ毎に、検証装置１０による上述のハッシュテーブル生成処理が実行されると共に、検証処理が実行される。
【０１１２】
ところで、車両ネットワーク２においては、複数の実装ユニット２０−１〜２０−Ｎを含む多数の電子機器（ノード）からの各種信号ないしデータ（以下、単に「メッセージ」と称する）が流される。このため、車両ネットワーク２では、複数のノードから同時に車両ネットワーク２にメッセージが送信される場合に優先順位が高いメッセージを他のメッセージに衝突させずに送信できるような仕組みを有する。一般的に、優先順位が高いメッセージとは、車両走行に関連するメッセージであり、例えば制動力制御や駆動力制御に関わるメッセージである。制動力制御や駆動力制御に関わるメッセージは、制動力制御や駆動力制御を行う制御装置（図１の複数の実装ユニット２０−１〜２０−Ｎのうちの１つ以上の実装ユニット）から車両ネットワーク２に定期的又は不定期的に送信される。
【０１１３】
このため、実装ユニット２０からの報告処理に係るメッセージ、具体的には報告処理部２０４から車両ネットワーク２に流される暗号化ＩＤ信号には、相対的に低い優先順位が付与される傾向となる。この結果、実装ユニット２０からの報告処理に係るメッセージは、優先順位が高いメッセージによる車両ネットワーク２における輻輳時には、所期のタイミングで車両ネットワーク２に送信されず、検証装置１０により正常に受信されない可能性がある。以下では、優先順位が高いメッセージに起因して報告処理に係るメッセージが検証装置１０により正常に受信されないイベントを、「通信エラーイベント」とも称する。
【０１１４】
この点、実装ユニット２０からの報告処理が第１タイムアウトイベントの発生タイミングのみで実行される比較構成においては、通信エラーイベントが発生した場合に次のような問題が生じる。ここでは、実装ユニットカウンタ２７のカウンタ値を"２"にする第１タイムアウトイベントの発生タイミングで通信エラーイベントが発生した場合を想定する。尚、この通信エラーイベントは、図１５に矢印Ｔｒ３に対して模式的に×マークＰで示されている。かかる通信エラーイベントが発生した場合、検証装置１０は、検証装置カウンタ１７のカウンタ値が"２"であるときに、実装ユニット２０からの報告処理に係るメッセージを受信できないことになる。この結果、検証装置カウンタ１７のカウンタ値が"２"であるときに、デバイスＩＤテーブルには、実装ユニット２０に係るデバイスＩＤが記録されない。これに伴い、かかるデバイスＩＤテーブルに基づきハッシュテーブル生成部１０４により算出される積算ハッシュ値（検証装置カウンタ１７のカウンタ値＝２のときの積算ハッシュ値）は、実装ユニット２０に係るデバイスＩＤを含まずに算出された値となる。これは、ハッシュテーブル生成部１０４により算出される積算ハッシュ値が、マスタ積算ハッシュ値と一致しないことを意味する。このため、検証処理部１０６は、車両システム１の健全性が損なわれている可能性があることを示す情報（異常情報）を出力することになる。このように、比較構成においては、車両システム１の健全性が損なわれていないにも拘らず、通信エラーイベントに起因して異常情報が出力される可能性がある。
【０１１５】
これに対して、上述した本実施例によれば、比較構成において生じる上述した問題を低減できる。具体的には、同様に、実装ユニットカウンタ２７のカウンタ値を"２"にする第１タイムアウトイベントの発生タイミングで通信エラーイベントが発生した場合を想定する。本実施例においても、比較構成と同様、実装ユニットカウンタ２７のカウンタ値を"２"にする第１タイムアウトイベントの発生タイミングでは、検証装置１０は、実装ユニット２０からの報告処理に係るメッセージを受信できない。しかしながら、本実施例においては、実装ユニットカウンタ２７のカウンタ値を"２"であるときの第２タイムアウトイベントの発生タイミングで、検証装置１０は、実装ユニット２０からの報告処理に係るメッセージを受信できる。即ち、図１５にて矢印Ｔｒ４に示すように、本実施例においては、検証装置１０は、検証装置カウンタ１７のカウンタ値が"２"であるときに、実装ユニット２０からの報告処理に係るメッセージを受信できる。この結果、検証装置カウンタ１７のカウンタ値が"２"であるときに、デバイスＩＤテーブルには、実装ユニット２０に係るデバイスＩＤが記録される。これに伴い、かかるデバイスＩＤテーブルに基づきハッシュテーブル生成部１０４により算出される積算ハッシュ値（検証装置カウンタ１７のカウンタ値＝２のときの積算ハッシュ値）は、実装ユニット２０に係るデバイスＩＤを含めて算出された値となる。これは、ハッシュテーブル生成部１０４により算出される積算ハッシュ値が、１回の通信エラーイベントに起因してマスタ積算ハッシュ値と一致しなくなってしまうという問題が解消されていることを意味する。このため、本実施例では、検証装置カウンタ１７のカウンタ値＝２のときの積算ハッシュ値に基づいて異常情報が出力される可能性は、低減される。このように、本実施例によれば、車両システム１の健全性が損なわれていないにも拘らず通信エラーイベントに起因して異常情報が出力されてしまう可能性を、低減できる。
【０１１６】
尚、図１５に示す例では、実装ユニットカウンタ２７のカウンタ値が各値である間に２回だけ報告処理部２０４による報告処理が実行されているが、これに限られない。実装ユニットカウンタ２７のカウンタ値が各値である間に３回以上報告処理部２０４による報告処理が実行されるようにしてもよい。この報告処理部２０４による報告処理の回数（カウンタ値毎の報告処理回数）が多いほど、通信エラーイベントに対するロバスト性は高くなる。尚、カウンタ値毎の報告回数は、所定時間Ｔ１に対する所定時間Ｔ２の長さを調整することで、調整できる。例えば、所定時間Ｔ２を所定時間Ｔ１の１／３よりも短いが１／４よりも長く設定する場合、実装ユニットカウンタ２７のカウンタ値毎の報告処理回数は、"４"となる。
【０１１７】
以上、上述した本実施例によれば、例えば、以下のような効果が奏される。
【０１１８】
まず、本実施例においては、実装ユニット２０においては、暗号鍵は、実装ユニットカウンタ２７のカウンタ値及びシステム鍵に基づいて生成され、検証装置１０においては、暗号鍵は、検証装置カウンタ１７のカウンタ値及びシステム鍵に基づいて生成される。そして、実装ユニット２０においてデバイスＩＤを暗号鍵により暗号化した暗号化ＩＤ信号は、検証装置１０に送信され、検証装置１０において暗号鍵により復号される。従って、実装ユニット２０における暗号鍵が、検証装置１０において暗号鍵と異なるときは、検証装置１０においてデバイスＩＤが正常に復号されないことになる。即ち、検証装置１０において暗号化ＩＤ信号を復号して得られるデバイスＩＤが、実装ユニット２０のデバイスＩＤと異なることになる。この場合、検証装置１０において算出される積算ハッシュ値が、マスタ積算ハッシュ値と一致しなくなり、異常情報（車両システム１の健全性が損なわれている可能性があることを示す情報）が出力される。
【０１１９】
本実施例において、異常情報が出力される主なる要因としては、実装ユニット２０が保持するデバイスＩＤが正当なデバイスＩＤであると仮定すると、実装ユニット２０における暗号鍵が、実装ユニット２０における暗号鍵と異なることがある。実装ユニット２０におけるカウンタ値及びシステム鍵の少なくともいずれか一方が、検証装置１０におけるカウンタ値及びシステム鍵と異なるときは、実装ユニット２０で生成される暗号鍵は、検証装置１０で生成される暗号鍵とは異なることになる。
【０１２０】
この点、本実施例によれば、実装ユニット２０は、検証装置カウンタ１７のカウンタ値とカウンタ値が同期される実装ユニットカウンタ２７を備える。即ち、本実施例では、検証装置カウンタ１７のカウンタ値と実装ユニットカウンタ２７のカウンタ値が同期される。従って、本実施例では、実装ユニット２０が保持するシステム鍵が正当なシステム鍵であると仮定すると、実装ユニット２０で生成される暗号鍵が検証装置１０で生成される暗号鍵と異なってしまう事態は基本的に生じない。
【０１２１】
ここで、実装ユニット２０に成りすます不正なユニット（成りすましのユニット）が、該実装ユニット２０のデバイスＩＤを使って不正な暗号化ＩＤ信号を、検証装置１０に送信する場合を想定する。検証装置１０が、かかる成りすましのユニットを検出できない場合は、例えば、成りすましのユニットが不正な制御信号を車両ネットワーク２に送信することで、望ましくない車両制御が実行されてしまうなど、車両システム１の健全性が損なわれうる。尚、望ましくない車両制御には、例えば改竄された目標駆動力に基づく駆動力制御などがあり得る。
【０１２２】
かかる場合、成りすましのユニットは、実装ユニット２０のデバイスＩＤやシステム鍵を不正に入手できたとしても、検証装置１０におけるカウンタ値（検証装置カウンタ１７のカウンタ値）と同期するカウンタを持つことは困難である。これは、検証装置１０におけるカウンタ値は、一定値でなく、検証装置タイマ１８のタイムアウトイベント毎にカウントアップされるためである。即ち、成りすましのユニットは、検証装置１０におけるカウンタ値に、自身のカウンタ値を同期させる術がないためである。
【０１２３】
従って、本実施例によれば、実装ユニット２０に成りすます不正なユニット（成りすましのユニット）に起因して車両システム１の健全性が損なわれることを効果的に抑制できる。
【０１２４】
ところで、実装ユニット２０における暗号鍵が実装ユニット２０における暗号鍵とが同じであるにも拘らず、異常情報が出力される要因として、上述のような通信エラーイベントがある。かかる場合は、車両システム１の健全性が損なわれていない可能性が高いため、異常情報が出力されない方が望ましい。この点、本実施例によれば、実装ユニットカウンタ２７のカウンタ値が各値である間、２回以上、報告処理部２０４による報告処理が実行される。従って、本実施例によれば、図１５を参照して上述したように、車両システム１の健全性が損なわれていないにも拘らず通信エラーイベントに起因して異常情報が出力されてしまう可能性を、低減できる。
【０１２５】
以上、特定の実施例について詳述したが、特定の実施例に限定されるものではなく、特許請求の範囲に記載された範囲内において、種々の変形及び変更が可能である。また、上述した実施例の構成要素を全部又は複数を組み合わせることも可能である。
【０１２６】
例えば、上述した実施例では、報告処理部２０４による報告処理は、第１タイムアウトイベント及び第２タイムアウトイベントのいずれが発生したときも実行されるが、これに限られない。例えば、所定時間Ｔ２を所定時間Ｔ１の１／２未満に設定する場合には、報告処理部２０４による報告処理は、第２タイムアウトイベントが発生したときだけ実行されてもよい。即ち、所定時間Ｔ２を所定時間Ｔ１の１／２未満に設定する場合には、第２タイマ２９は、実装ユニットカウンタ２７のカウンタ値が各値である間、２回以上の異なるタイミングで、第２タイムアウトイベントを発生させることができる。これは、ある第１タイムアウトイベントが発生してから次の第１タイムアウトイベントが発生するまでの間に、必ず２回以上報告処理部２０４による報告処理が実行されることを意味する。これにより、上述した実施例と同様、通信エラーイベントに起因して異常情報が出力される可能性を低減できる。例えば、図１６には、所定時間Ｔ２が所定時間Ｔ１の１／２未満であり且つ１／３より長いときの例が示される。図１６から、ある第１タイムアウトイベントが発生してから次の第１タイムアウトイベントが発生するまでの間に、必ず２回以上報告処理部２０４による報告処理が実行されることが分かる。
【０１２７】
また、上述した実施例では、第２タイマ２９は、第１タイムアウトイベント毎にセットされるが、これに限られない。即ち、第２タイマ２９は、第１タイムアウトイベントに必ずしも同期してセットされる必要はない。例えば、所定時間Ｔ２を所定時間Ｔ１よりも短くすれば、ある第１タイムアウトイベントが発生してから次の第１タイムアウトイベントが発生するまでの間に、第２タイムアウトイベントが必ず発生する。これは、ある第１タイムアウトイベントの発生時点と、その次の第１タイムアウトイベントの発生までに必ず発生する第２タイムアウトイベントの発生時点とで、報告処理部２０４による報告処理が実行されることを意味する。これにより、上述した実施例と同様、通信エラーイベントに起因して異常情報が出力される可能性を低減できる。
【０１２８】
また、図１４に示す処理では、検証装置カウンタ１７のカウンタ値毎の積算ハッシュ値が１つでもマスタ積算ハッシュ値と異なる場合に、異常情報が出力されるが、これに限られない。例えば、検証装置カウンタ１７のカウンタ値毎の積算ハッシュ値がマスタ積算ハッシュ値と異なる状態が、検証装置カウンタ１７のカウンタ値が所定回数以上変化しても継続する場合に、異常情報が出力されることとしてもよい。
【符号の説明】
【０１２９】
１  車両システム
２  車両ネットワーク
１０  検証装置
１７  検証装置カウンタ
１８  検証装置タイマ
２０  実装ユニット
２７  実装ユニットカウンタ
２８  第１タイマ
２９  第２タイマ
１０１  初期化処理部
１０２  カウンタ管理部
１０３  デバイスＩＤテーブル生成部
１０４  ハッシュテーブル生成部
１０６  検証処理部
１０９  検証装置記憶部
２０１  初期化処理部
２０２  カウンタ管理部
２０３  暗号化部
２０４  報告処理部
２０９  ユニット記憶部
【図１】
2017060979.tif 000003
【図２】
2017060979.tif 000004
【図３】
2017060979.tif 000005
【図４】
2017060979.tif 000006
【図５】
2017060979.tif 000007
【図６】
2017060979.tif 000008
【図７】
2017060979.tif 000009
【図８】
2017060979.tif 000010
【図９】
2017060979.tif 000011
【図１０】
2017060979.tif 000012
【図１１】
2017060979.tif 000013
【図１２】
2017060979.tif 000014
【図１３】
2017060979.tif 000015
【図１４】
2017060979.tif 000016
【図１５】
2017060979.tif 000017
【図１６】
2017060979.tif 000018
【手続補正書】
【提出日】平成30年4月12日(2018.4.12)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ネットワークを介して複数のノードが接続されるシステムにおいて、複数の前記ノードの少なくとも１つを形成する実装ユニットであって、
前記ネットワーク上の検証装置に設けられる検証装置カウンタに同期される実装ユニットカウンタと、
前記実装ユニットカウンタのカウンタ値がある値である間、２回以上の異なるタイミングで、前記実装ユニットカウンタの前記カウンタ値に基づいて暗号化した実装ユニットＩＤを表す暗号化信号を、前記検証装置に送信する処理部とを備える、実装ユニット。
【請求項２】
第１時間毎にタイムアウトし、前記実装ユニットカウンタのカウンタ値を変化させる第１タイマと、
前記実装ユニットに設けられ、前記第１時間よりも短い第２時間毎にタイムアウトする第２タイマとを更に備え、
前記タイミングは、前記第２タイマがタイムアウトするときを含む、請求項１に記載の実装ユニット。
【請求項３】
前記タイミングは、更に、前記実装ユニットカウンタの前記カウンタ値が変化するときを含む、請求項２に記載の実装ユニット。
【請求項４】
前記第２タイマは、前記実装ユニットカウンタの前記カウンタ値が変化したときにセットされる、請求項２又は３に記載の実装ユニット。
【請求項５】
ネットワークを介して複数の実装ユニットが接続されるシステムの健全性を検証する検証装置であって、
複数の前記実装ユニットのそれぞれに設けられる実装ユニットカウンタと同期する検証装置カウンタと、
複数の前記実装ユニットのそれぞれが暗号化時点の前記実装ユニットカウンタのカウンタ値に基づいて暗号化した実装ユニットＩＤを表す暗号化信号であって、前記実装ユニットカウンタの前記カウンタ値がある値である間における２回以上の異なるタイミングで、複数の前記実装ユニットのそれぞれが送信する暗号化信号を、受信する第１の処理部と、
前記第１の処理部が前記暗号化信号を受信したときの前記検証装置カウンタのカウンタ値と、前記暗号化信号とに基づいて、前記システムの健全性を判断する第２の処理部とを備える、検証装置。
【請求項６】
前記第２の処理部は、前記検証装置カウンタの前記カウンタ値がある値である間に受信した全ての前記暗号化信号を復号して得た全ての異なる前記実装ユニットＩＤに基づいて、１つのハッシュ値を算出し、算出したハッシュ値に基づいて、前記システムの健全性を判定する、請求項５に記載の検証装置。
【請求項７】
前記第２の処理部は、算出した前記ハッシュ値と、複数の前記実装ユニットのそれぞれに係る正当な全ての前記実装ユニットＩＤに基づく１つの参照ハッシュ値との比較結果に基づいて、前記システムの健全性を判定する、請求項６に記載の検証装置。
【請求項８】
ネットワークを介して複数のノードが接続されるシステムの健全性を検証する実装ユニット検証プログラムであって、複数の前記ノードの少なくとも１つを形成する実装ユニットのコンピューターに、
前記ネットワーク上の検証装置に設けられる検証装置カウンタに実装ユニットカウンタを同期させ、
前記実装ユニットカウンタのカウンタ値がある値である間、２回以上の異なるタイミングで、前記実装ユニットカウンタのカウンタ値に基づいて暗号化した実装ユニットＩＤを表す暗号化信号を、前記検証装置に送信する、
処理を、実行させる、実装ユニット検証プログラム。
【請求項９】
ネットワークを介して複数の実装ユニットが接続されるシステムの健全性を検証する実装ユニット検証プログラムであって、前記ネットワーク上の検証装置のコンピューターに、
複数の前記実装ユニットのそれぞれに設けられる実装ユニットカウンタに、検証装置カウンタを同期させ、
複数の前記実装ユニットのそれぞれが暗号化時点の前記実装ユニットカウンタのカウンタ値に基づいて暗号化した実装ユニットＩＤを表す暗号化信号であって、前記実装ユニットカウンタの前記カウンタ値がある値である間における２回以上の異なるタイミングで複数の前記実装ユニットのそれぞれが送信する暗号化信号を、受信し、
前記暗号化信号を受信したときの前記検証装置カウンタのカウンタ値と、前記暗号化信号とに基づいて、前記システムの健全性を判断する、
処理を、実行させる、実装ユニット検証プログラム。
【請求項１０】
ネットワークを介して複数の実装ユニットが接続されるシステムの健全性を検証する実装ユニット検証方法であって、
複数の前記実装ユニットのそれぞれが、前記ネットワーク上の検証装置に設けられる検証装置カウンタに実装ユニットカウンタを同期させ、
複数の前記実装ユニットのそれぞれが、前記実装ユニットカウンタのカウンタ値がある値である間、２回以上の異なるタイミングで、前記実装ユニットカウンタの前記カウンタ値に基づいて暗号化した実装ユニットＩＤを表す暗号化信号を、前記検証装置に送信することを含む、実装ユニット検証方法。
【請求項１１】
ネットワークを介して複数の実装ユニットが接続されるシステムの健全性を検証する実装ユニット検証方法であって、
前記ネットワーク上の検証装置が、複数の前記実装ユニットのそれぞれに設けられる実装ユニットカウンタに検証装置カウンタを同期させ、
前記検証装置が、複数の前記実装ユニットのそれぞれが暗号化時点の前記実装ユニットカウンタのカウンタ値に基づいて暗号化した実装ユニットＩＤを表す暗号化信号であって、前記実装ユニットカウンタの前記カウンタ値がある値である間における２回以上の異なるタイミングで複数の前記実装ユニットのそれぞれが送信する暗号化信号を、受信し、
前記検証装置が、前記暗号化信号を受信したときの前記検証装置カウンタのカウンタ値と、前記暗号化信号とに基づいて、前記システムの健全性を判断することを含む、実装ユニット検証方法。
【国際調査報告】
2017060979.tif 000019
2017060979.tif 000020
2017060979.tif 000021
2017060979.tif 000022
2017060979.tif 000023
2017060979.tif 000024