JP2023101193A - 情報処理装置、車両、情報処理方法、及びプログラム - Google Patents

Abstract

【課題】検証情報の受信に失敗している場合に、検証が成功していないことを把握することができる。【解決手段】情報処理装置は、メッセージを認証するために用いられる鍵の設定を検証する鍵検証の開始を要求する信号を受信する第１受信部と、前記鍵検証を行うために用いられる検証情報を受信する第２受信部と、前記信号を受信してから予め定められた時間内に前記検証情報が受信されなかった場合に、前記鍵検証に失敗したことを示す情報を記録し、前記信号が受信されてから前記予め定められた時間内に前記検証情報が受信された場合であって、かつ、前記鍵検証に失敗した場合に、前記鍵検証に失敗したことを示す情報を記録する記録部と、を備えている。【選択図】図４

Description

本発明は、情報処理装置、車両、情報処理方法、及びプログラムに関する。

特許文献１には、第１ノードから、複数の第２ノードの各々に所定のデータが送信され、第２ノードに所定のデータが送信された場合に、当該第２ノードにより当該所定のデータが正常に受信されたか否かを検証するための検証用データが、当該第２ノードに送信され、複数の第２ノードの各々において、第１ノードから送信される前記検証用データが受信されると、受信した前記所定のデータと、受信した検証用データとに基づき、所定のデータが正常に受信されたか否かを検証し、検証結果が第１ノードに送信される車載ネットワークシステムが開示されている。

特開２０１８－１２１２２０号公報

特許文献１の車載ネットワークシステムにおいて、検証用データの受信に失敗した場合には、検証が行われず、検証結果も記録されない。従って、検証に成功したため失敗したことを示す検証結果が記録されなかったのか、そもそも検証が行われなかったため検証結果が記録されなかったのかが分かりにくいため、ユーザの利便性が低下するおそれがある。

そこで、本発明は、検証情報の受信に失敗している場合に、検証が成功していないことを把握することができる情報処理装置、車両、情報処理方法、及びプログラムを提供することを目的とする。

請求項１に記載の情報処理装置は、メッセージを認証するために用いられる鍵の設定を検証する鍵検証の開始を要求する信号を受信する第１受信部と、前記鍵検証を行うために用いられる検証情報を受信する第２受信部と、前記信号を受信してから予め定められた時間内に前記検証情報が受信されなかった場合に、前記鍵検証に失敗したことを示す情報を記録し、前記信号が受信されてから前記予め定められた時間内に前記検証情報が受信された場合であって、かつ、前記鍵検証に失敗した場合に、前記鍵検証に失敗したことを示す情報を記録する記録部と、を備えている。

請求項１に記載の情報処理装置は、第１受信部が、メッセージを認証するために用いられる鍵の設定を検証する鍵検証の開始を要求する信号を受信する。第２受信部が、前記鍵検証を行うために用いられる検証情報を受信する。そして、記録部が、前記信号を受信してから予め定められた時間内に前記検証情報が受信されなかった場合に、前記鍵検証に失敗したことを示す情報を記録する。また、記録部が、前記信号が受信されてから前記予め定められた時間内に前記検証情報が受信された場合であって、かつ、前記鍵検証に失敗した場合に、前記鍵検証に失敗したことを示す情報を記録する。

メッセージを認証するために用いられる鍵の設定を検証する鍵検証の開始を要求する信号を受信してから、予め定められた時間内に、検証情報が受信されなかった場合には、鍵検証が行われないため、検証に失敗したことを示す情報を記録する。そのため、当該情報処理装置によれば、検証情報の受信に失敗している場合に、検証が成功していないことを把握することができる。

請求項２に記載の情報処理装置は、請求項１に記載の情報処理装置において、前記記録部は、前記信号を受信せずに、前記検証情報が受信された場合に、前記鍵検証に失敗したことを示す情報を記録する。

請求項２に記載の情報処理装置では、鍵検証の開始を要求する信号を受信せずに、検証情報が受信された場合に、記録部が、前記鍵検証に失敗したことを示す情報を記録する。そのため、鍵検証の開始を要求する信号の受信に失敗している場合であっても、検証に失敗したことを示す情報を記録することができる。

請求項３に記載の情報処理装置は、請求項１又は２に記載の情報処理装置において、メモリに記憶された鍵と、前記メッセージに付与された認証情報とに基づいて、前記メッセージを認証する認証部と、前記検証情報に基づいて、前記鍵の設定を検証する鍵検証部とを更に含み、前記記録部は、前記信号が受信されてから前記予め定められた時間内に前記検証情報が受信された場合であって、かつ、前記鍵検証部による検証に失敗した場合に、前記鍵検証に失敗したことを示す情報を記録する。

請求項３に記載の情報処理装置では、鍵検証の開始を要求する信号が受信されてから前記予め定められた時間内に前記検証情報が受信された場合であって、かつ、前記鍵検証部による検証に失敗した場合に、記録部が、前記鍵検証に失敗したことを示す情報を記録する。

従って、鍵検証の開始を要求する信号の受信と検証情報の受信が正常に行われた場合には、鍵の検証に失敗したことを条件として、鍵検証に失敗したことを示す情報を記録する。

請求項４に記載の車両は、請求項１～請求項３の何れか１項記載の情報処理装置と、前記情報処理装置へ前記検証情報を送信する他の情報処理装置と、を備え、前記第１受信部は、外部装置から前記信号を受信し、前記第２受信部は、前記他の情報処理装置から前記検証情報を受信する。

請求項４に記載の車両では、第１受信部は、外部装置から前記信号を受信し、前記第２受信部は、前記他の情報処理装置から前記検証情報を受信する。そのため、当該情報処理装置によれば、他の情報処理装置からの検証情報の受信に失敗している場合に、検証が成功していないことを把握することができる

請求項５に記載の情報処理方法は、第１受信部が、メッセージを認証するために用いられる鍵の設定を検証する鍵検証の開始を要求する信号を受信し、第２受信部が、前記鍵検証を行うために用いられる検証情報を受信し、記録部が、前記信号を受信してから予め定められた時間内に前記検証情報が受信されなかった場合に、前記鍵検証に失敗したことを示す情報を記録し、前記信号が受信されてから前記予め定められた時間内に前記検証情報が受信された場合であって、かつ、前記鍵検証に失敗した場合に、前記鍵検証に失敗したことを示す情報を記録する。

請求項５に記載の情報処理方法は、第１受信部が、メッセージを認証するために用いられる鍵の設定を検証する鍵検証の開始を要求する信号を受信する。第２受信部が、前記鍵検証を行うために用いられる検証情報を受信する。そして、記録部が、前記信号を受信してから予め定められた時間内に前記検証情報が受信されなかった場合に、前記鍵検証に失敗したことを示す情報を記録する。また、記録部が、前記信号が受信されてから前記予め定められた時間内に前記検証情報が受信された場合であって、かつ、前記鍵検証に失敗した場合に、前記鍵検証に失敗したことを示す情報を記録する。

上述のように、当該情報処理方法によれば、検証情報の受信に失敗している場合に、検証が成功していないことを把握することができる。

請求項６に記載のプログラムは、メッセージを認証するために用いられる鍵の設定を検証する鍵検証の開始を要求する信号を受信し、前記鍵検証を行うために用いられる検証情報を受信し、前記信号を受信してから予め定められた時間内に前記検証情報が受信されなかった場合に、前記鍵検証に失敗したことを示す情報を記録し、前記信号が受信されてから前記予め定められた時間内に前記検証情報が受信された場合であって、かつ、前記鍵検証に失敗した場合に、前記鍵検証に失敗したことを示す情報を記録する処理をコンピュータに実行させるためのプログラムである。

請求項６に記載のプログラムでは、コンピュータが、メッセージを認証するために用いられる鍵の設定を検証する鍵検証の開始を要求する信号を受信する。コンピュータが、前記鍵検証を行うために用いられる検証情報を受信する。

そして、コンピュータが、前記信号を受信してから予め定められた時間内に前記検証情報が受信されなかった場合に、前記鍵検証に失敗したことを示す情報を記録する。また、コンピュータが、前記信号が受信されてから前記予め定められた時間内に前記検証情報が受信された場合であって、かつ、前記鍵検証に失敗した場合に、前記鍵検証に失敗したことを示す情報を記録する。

上述のように、当該プログラムによれば、検証情報の受信に失敗している場合に、検証が成功していないことを把握することができる。

本発明によれば、検証情報の受信に失敗している場合に、検証が成功していないことを把握することができる。

実施形態に係る車両通信システムの概略構成を示す図である。 実施形態のＥＣＵのハードウェア構成を示すブロック図である。 実施形態のストレージの構成の例を示すブロック図である。 実施形態のＣＰＵの機能構成の例を示すブロック図である。 実施形態に係る車両通信システムにおけるデータの流れを説明する図である。 ＥＣＵにおける検証処理の流れを示すフローチャートである。 ＥＣＵにおける検証処理に関する時間を説明するための図である。

（通信システム）
図１は、実施形態に係る車両通信システム１２の概略構成を示すブロック図である。図１に示されるように、本実施形態に係る車両通信システム１２は、情報処理装置である複数のＥＣＵ（Electronic Control Unit）１０と、複数のＥＣＵ１０同士を接続する通信路であるバス１４と、を含んで構成されている。本実施形態の車両通信システム１２は、例えば、車両１１に設けられた各ＥＣＵ１０を接続するネットワークとして形成されている。また、例えば車両工場において、診断装置３２０が、車両１１の診断用インタフェース部３１０を介して車両通信システム１２に接続される。

図１には、ＥＣＵ１０Ａ、ＥＣＵ１０Ｂ、及びＥＣＵ１０Ｃの３つのＥＣＵ１０が図示されている。ＥＣＵ１０Ａは、マスタＥＣＵに相当し、ＥＣＵ１０Ｂ及びＥＣＵ１０Ｃは、スレーブＥＣＵに相当する。なお、バス１４には、ＥＣＵ１０Ａ、１０Ｂ及び１０Ｃに限らず、さらに多くのＥＣＵ１０が接続されていてもよい。また、本実施形態の車両通信システム１２は、バス型のバス構造を採用しているが、これに限らず、スター型、リング型、ライン型（ディジーチェーン接続）のバス構造を採用してもよい。

本実施形態の車両通信システム１２では、ＥＣＵ１０同士の通信を行うための通信方式にＣＡＮ（Controller Area Network）プロトコル、又はＣＡＮプロトコルよりも通信速度が高速であるＣＡＮ－ＦＤ（CAN With Flexible Data Rate）プロトコルを採用している。なお、通信方式はこれに限らず、イーサネット（登録商標）等のＬＡＮ規格を採用してもよい。

（ＥＣＵ）
図２に示されるように、本実施形態のＥＣＵ１０は、マイクロコントローラ２０と、ＣＡＮトランシーバ３０と、を含んで構成されている。マイクロコントローラ２０は、ＣＰＵ（Central Processing Unit）２２、ＲＯＭ（Read Only Memory）２４、ＲＡＭ（Random Access Memory）２６、及びＣＡＮコントローラ２８を含んで構成されている。

ＣＰＵ２２は、中央演算処理ユニットであり、各種プログラムを実行したり、各部を制御したりする。すなわち、ＣＰＵ２２は、ＲＯＭ２４からプログラムを読み出し、ＲＡＭ２６を作業領域としてプログラムを実行する。本実施形態では、ストレージ２７に実行プログラム１００が記憶されている（図３参照）。

ＲＯＭ２４は、各種プログラム及び各種データを記憶している。

ＲＡＭ２６は、作業領域として一時的にプログラム又はデータを記憶する。

ストレージ２７は、各種プログラム及び各種データを記憶している。図３に示されるように、ストレージ２７には、実行プログラム１００と、鍵データ１１０と、メッセージデータ１２０とが記憶されている。鍵データ１１０には、ＭＡＣ（Message Authentication Code：メッセージ認証コード）を生成するための暗号鍵のデータが記憶されている。メッセージデータ１２０には、ＥＣＵ１０が送信する又は受信したメッセージが記憶されている。

ＣＡＮコントローラ２８は、ＣＡＮプロトコル及びＣＡＮ－ＦＤプロトコルに係る機能、例えば、通信調停やエラーチェック等の機能を実現する。

ＣＡＮトランシーバ３０は、マイクロコントローラ２０、及びバス１４と接続され、マイクロコントローラ２０から入力される通信フレームをバス１４に送信し、バス１４によって転送される通信フレームをマイクロコントローラ２０に入力する機能を有している。

図４は、ＥＣＵ１０Ｂ、１０Ｃの機能構成の例を示すブロック図である。図４に示されるように、ＥＣＵ１０Ｂ、１０Ｃは、第１受信部２００、第２受信部２１０、判定部２２０、鍵検証部２３０、記録部２４０、第３受信部２５０、認証部２６０、及び情報処理部２７０を有している。各機能構成は、ＣＰＵ２２がストレージ２７に記憶された実行プログラム１００を読み出し、これを実行することによって実現される。

第１受信部２００は、診断装置３２０から、診断用インタフェース部３１０を介して、メッセージを認証するために用いられる鍵が正しく設定されているか否かを検証する鍵検証の開始を要求する信号を受信する機能を有している。本実施形態の第１受信部２００、第２受信部２１０、及び第３受信部２５０は、ＣＡＮプロトコル又はＣＡＮ－ＦＤプロトコルの通信方式に基づいて制御される。

第２受信部２１０は、ＥＣＵ１０Ａから、鍵検証を行うために用いられる検証情報を受信する機能を有している。例えば、検証情報として、任意に生成される乱数と、ＥＣＵ１０Ｂ、１０Ｃに登録された暗号鍵により復号可能な態様で暗号化された乱数を含むデータを用いてもよい。また、検証情報は、複数のメッセージで構成され、冗長に複数回送信される。ここで、上記の鍵検証の開始を要求する信号は、診断装置３２０から一回だけ送信されるため、第１受信部２００で受信を失敗する可能性がある。一方、検証情報は、ＥＣＵ１０Ａから複数回送信されるため、第２受信部２００で受信を失敗する可能性は低い。

判定部２２０は、第１受信部２００によって鍵検証の開始を要求する信号を受信してから予め定められた時間内に第２受信部２１０によって検証情報が受信されたか否かを判定する。

例えば、鍵検証の仕組みとして、鍵検証の開始を要求する信号を受信してからのタイムアウト時間が設定されており、タイムアウト時間から、鍵検証にかかる時間を減算した時間を、「予め定められた時間」として用いればよい。

また、判定部２２０は、第１受信部２００によって鍵検証の開始を要求する信号を受信せずに、第２受信部２１０によって検証情報が受信されたか否かを判定する。例えば、第１受信部２００で上記の鍵検証の開始を要求する信号の受信を失敗し、かつ、第２受信部２１０によって検証情報が受信されたか否かを判定する。

鍵検証部２３０は、第２受信部２１０によって受信した検証情報と、鍵データ１１０の暗号鍵のデータとに基づいて、暗号鍵が正しく設定されているか否かを検証する。例えば、鍵検証部２３０は、検証情報に含まれる暗号化された乱数を暗号鍵で復号したものと、検証情報に含まれる暗号化されていない乱数とを比較し、一致する場合、暗号鍵が正しく設定されている（検証成功）と判断し、一致しない場合、暗号鍵が正しく設定されていない（検証失敗）と判断する。

記録部２４０は、判定部２２０によって、第１受信部２００によって鍵検証の開始を要求する信号を受信してから予め定められた時間内に第２受信部２１０によって検証情報が受信されなかったと判定された場合に、鍵検証に失敗したことを示すダイアグをストレージ２７に記録する。

また、記録部２４０は、判定部２２０によって、第１受信部２００によって鍵検証の開始を要求する信号を受信してから予め定められた時間内に第２受信部２１０によって検証情報が受信されたと判定された場合に、鍵検証部２３０によって暗号鍵が正しく設定されていないと判断されたことを条件に、鍵検証に失敗したことを示すダイアグをストレージ２７に記録する。

また、記録部２４０は、判定部２２０によって、第１受信部２００によって鍵検証の開始を要求する信号を受信せずに、第２受信部２１０によって検証情報が受信されたと判定された場合に、鍵検証に失敗したことを示すダイアグをストレージ２７に記録する。

第３受信部２５０は、他のＥＣＵ１０から通信フレームを受信する機能を有している。通信フレームは、通信データを含んでいる。通信データはメッセージと、当該メッセージから生成された認証情報としてのＭＡＣと、を含んでいる。

認証部２６０は、第３受信部２５０が受信したメッセージの各々について、当該メッセージを認証する機能を有している。認証部２６０は、受信した通信データに含まれるＭＡＣと、受信したメッセージから生成された検証用ＭＡＣとを比較して一致した場合にメッセージを認証する。

情報処理部２７０は、他のＥＣＵ１０や各部のセンサから取得したメッセージを処理する機能を有している。例えば、ＥＣＵ１０が車両１１の情報を表示させるメータＥＣＵである場合、情報処理部２７０は、受信したメッセージに基づいてメータパネルに情報を表示させることができる。

（作用）
次に本実施形態の車両通信システム１２における処理の流れについて図５のシーケンス図、及び図６のフローチャートを用いて説明する。例えば、車両工場において、作業員が、上記図１に示すように、診断装置３２０を、車両１１の診断用インタフェース部３１０を介して車両通信システム１２に接続する。そして、作業員が、診断装置３２０に対して鍵更新を指示する操作を行うと、図５に示す処理が行われる。

まず、ステップＳ１００において、診断装置３２０が、鍵更新の開始を要求する信号を、ＥＣＵ１０Ｂ及びＥＣＵ１０Ｃに送信する。

ステップＳ１０２において、診断装置３２０が、鍵更新情報の送信を要求する信号を、ＥＣＵ１０Ａに送信する。

ステップＳ１０４において、ＥＣＵ１０Ａが、暗号鍵を生成し、ＥＣＵ１０Ａの鍵データ１１０の暗号鍵を更新する。

ステップＳ１０６において、ＥＣＵ１０Ａが、生成した暗号鍵に更新するための鍵更新情報をＥＣＵ１０Ｂ及びＥＣＵ１０Ｃに送信する。

ステップＳ１０８において、ＥＣＵ１０Ｂ、１０Ｃが、ＥＣＵ１０Ａから受信した鍵更新情報に基づいて、ＥＣＵ１０Ｂ、１０Ｃの鍵データ１１０の暗号鍵を更新する。

そして、作業員が、診断装置３２０に対して鍵検証を指示する操作を行うと、ステップＳ１１０において、診断装置３２０が、鍵検証の開始を要求する信号を、ＥＣＵ１０Ｂ及びＥＣＵ１０Ｃに送信する。

ステップＳ１１２において、診断装置３２０が、検証情報の送信を要求する信号を、ＥＣＵ１０Ａに送信する。

ステップＳ１１４において、ＥＣＵ１０Ａが、登録されている暗号鍵を検証するための検証情報を、ＥＣＵ１０Ｂ及びＥＣＵ１０Ｃに送信する。

ステップＳ１１６において、ＥＣＵ１０Ｂ、１０Ｃが、暗号鍵が正しく設定されているか否かを検証する。

そして、作業員が、診断装置３２０に対して鍵の検証結果を取得する操作を行うと、ステップＳ１１８において、診断装置３２０が、鍵の検証結果の取得を要求する信号を、ＥＣＵ１０Ｂに送信し、上記ステップＳ１１６での検証結果を取得する。

ステップＳ１２０において、診断装置３２０が、鍵の検証結果の取得を要求する信号を、ＥＣＵ１０Ｃに送信し、上記ステップＳ１１６での検証結果を取得する。

上記ステップＳ１１６の検証処理は、図６に示すフローチャートによって実現される。以下では、ＥＣＵ１０Ｂが検証処理を実行する場合を例に説明するが、ＥＣＵ１０Ｃも同様に検証処理を実行する。この検証処理は、鍵検証の開始を要求する信号、又は検証情報を受信したことをトリガとしてＣＰＵ２２により実行される。

ステップＳ１３０において、ＣＰＵ２２は、ＥＣＵ１０Ａから検証情報を受信したか否かを判定する。検証情報を受信していない場合には、検証情報を受信するまで待機し、検証情報を受信している場合には、ステップＳ１３２へ移行する。

ステップＳ１３２において、ＣＰＵ２２は、検証情報を受信したタイミングからｘ秒前までの間に、診断装置３２０から送信された、鍵検証の開始を要求する信号を受信しているか否かを判定する。ここで、ｘ秒は、鍵検証の開始を要求する信号を受信してからのタイムアウト時間である（図７参照）。検証情報を受信したタイミングからｘ秒前までの間に、診断装置３２０から送信された、鍵検証の開始を要求する信号を受信している場合には、ステップＳ１３４へ移行する。一方、検証情報を受信したタイミングからｘ秒前までの間に、診断装置３２０から送信された、鍵検証の開始を要求する信号を受信していない場合には、鍵検証の開始を要求する信号を受信せずに、第２受信部２１０によって検証情報が受信されたと判定し、ステップＳ１４０へ移行する。なお、ステップＳ１４０へ移行する場合であっても、並行して、後述するステップＳ１３４以降の処理を実行し、鍵検証を続行するようにしてもよい。

ステップＳ１３４では、ＣＰＵ２２は、鍵検証の開始を要求する信号を受信したタイミングから、（ｘ－ａ）秒経過するまでに検証情報を十分に受信したか否かを判定する。ここで、ａ秒は、鍵検証にかかる時間であり、（ｘ－ａ）秒は、タイムアウト時間から、鍵検証にかかる時間を減算した時間である（図７参照）。鍵検証の開始を要求する信号を受信したタイミングから、（ｘ－ａ）秒経過するまでに検証情報を十分に受信していない場合には、ステップＳ１４０へ移行する。一方、鍵検証の開始を要求する信号を受信したタイミングから、（ｘ－ａ）秒経過するまでに検証情報を十分に受信した場合には、ステップＳ１３６へ移行する。

ステップＳ１３６では、ＣＰＵ２２は、受信した検証情報と、鍵データ１１０の暗号鍵のデータとに基づいて、暗号鍵が正しく設定されているか否かを検証する。

ステップＳ１３８では、ＣＰＵ２２は、鍵検証の開始を要求する信号を受信したタイミングから、ｘ秒経過するまでに、上記ステップＳ１３６での鍵検証が成功したか否かを判定する。鍵検証が失敗した場合、又は鍵検証の開始を要求する信号を受信したタイミングから、ｘ秒経過するまでに鍵検証が終了しなかった場合には、ステップＳ１４０へ移行する。

一方、鍵検証の開始を要求する信号を受信したタイミングから、ｘ秒経過するまでに、鍵検証が成功した場合には、検証処理を終了する。

ステップＳ１４０では、ＣＰＵ２２は、鍵検証が失敗したことを示すダイアグをストレージ２７に記録して、検証処理を終了する。

（まとめ）

本実施形態の車両通信システム１２のＥＣＵ１０Ｂ、１０Ｃは、メッセージを認証するために用いられる鍵の設定を検証する鍵検証の開始を要求する信号を受信してから、予め定められた時間内に、検証情報が受信されなかった場合には、鍵検証が行われないため、検証に失敗したことを示すダイアグを記録する。そのため、当該車両通信システム１２によれば、検証情報の受信に失敗している場合に、検証が成功していないことを把握することができる。また、鍵検証が行われなかった場合にも適切にダイアグが記録されるので、ユーザである検査員の利便性を向上させることができる。

従来より、メッセージ認証が車両に導入され、車両工場では同一コマンドでＭＡＣ鍵の登録、検証を行う。検証では、スレーブＥＣＵが鍵検証開始要求を受け取り、更にマスタＥＣＵから送られる情報に従って判定し、問題があればダイアグを記録する。車両工場では、ダイアグ読み出しで検証成功、失敗を判定する。しかし、検証をした結果、検証成功なのか、検証開始の要求を受けとらず、検証成功の状態に見えるのか判別がつかない。すわなち、鍵の検証成功、失敗を確認する際には、検証成功を示すダイアグだけを確認しているため、検証処理が正しく行われない場合も、検証成功に見える。また、車両においては、既存のダイアグ読み出しという機能に即して検証を実施するため、検証処理が正しく行われたことを確認するのは効率的ではない。

そこで、本実施形態では、マスタＥＣＵから送信される検証情報を受け取った際に、それ以前の予め定められた時間内で検証開始を要求する信号を受け取ったか否かを確認してダイアグを記録する機能を、スレーブＥＣＵに導入する。これにより、鍵検証が行われなかった場合にも適切にダイアグが記録される。

（備考）
なお、上記実施形態では、メッセージの認証に用いられる鍵の検証に失敗したことを示すダイアグを記録する場合を例に説明したが、これに限定されるものではない。例えば、メッセージの認証に用いられる鍵以外のセキュリティに関する検証に失敗したことを示すダイアグを記録するようにしてもよい。具体的には、ＥＣＵは、セキュリティに関する検証の開始を要求する信号を受信し、当該検証を行うために用いられる検証情報を受信し、信号を受信してから予め定められた時間内に検証情報が受信されなかった場合に、当該検証に失敗したことを示す情報を記録し、信号が受信されてから予め定められた時間内に検証情報が受信された場合であって、かつ、当該検証に失敗した場合に、当該検証に失敗したことを示す情報を記録する。

また、診断装置を車両に接続して、診断装置から鍵検証開始要求をＥＣＵに送信する場合を例に説明したが、これに限定されるものではない。診断装置であるサーバから無線通信により鍵検証開始要求をＥＣＵに送信するようにしてもよい。この場合には、「予め定められた時間」として、サーバとの通信時間を考慮した時間を用いればよい。

また、鍵検証の開始を要求する信号の受信タイミング（時刻、カウンタ値等）と、検証情報の受信タイミングとを入力値とし、ダイアグが記録されるべきかを出力値とした教師データを用いて、ニューラルネットワークモデルの学習を行い、鍵検証の開始を要求する信号の受信タイミングと、検証情報の受信タイミングとを入力値としてダイアグを記録するか否かを、ニューラルネットワークモデルである学習済みモデルを用いて判定するようにしてもよい。この場合、鍵検証の開始を要求する信号や検証情報が受信されていない場合には、入力値なしとすればよい。

具体的には、ＥＣＵは、メッセージを認証するために用いられる鍵の設定を検証する鍵検証の開始を要求する信号を受信し、信号を受信したタイミングを示す情報を取得し、鍵検証を行うために用いられる検証情報を受信し、検証情報を受信したタイミングを示す情報を取得し、信号を受信したタイミングを示す情報、及び検証情報を受信したタイミングを示す情報を入力値とし、ダイアグを記録するか否かを出力値とする、ニューラルネットワークモデルである学習済みモデルを用いて、出力値に応じて、鍵検証に失敗したことを示すダイアグを記録する。

また、上記実施形態でＣＰＵ２２がソフトウェア（プログラム）を読み込んで実行した各種処理を、ＣＰＵ以外の各種のプロセッサが実行してもよい。この場合のプロセッサとしては、ＦＰＧＡ（Field-Programmable Gate Array）等の製造後に回路構成を変更可能なＰＬＤ（Programmable Logic Device）、及びＡＳＩＣ（Application Specific Integrated Circuit）等の特定の処理を実行させるために専用に設計された回路構成を有するプロセッサである専用電気回路等が例示される。また、上述した検証処理を、これらの各種のプロセッサのうちの１つで実行してもよいし、同種又は異種の２つ以上のプロセッサの組み合わせ（例えば、複数のＦＰＧＡ、及びＣＰＵとＦＰＧＡとの組み合わせ等）で実行してもよい。また、これらの各種のプロセッサのハードウェア的な構造は、より具体的には、半導体素子等の回路素子を組み合わせた電気回路である。

また、上記実施形態において、プログラムはコンピュータが読み取り可能な非一時的記録媒体に予め記憶（インストール）されている態様で説明した。例えば、実行プログラム１００は、ＲＯＭ２４に予め記憶されている。しかしこれに限らず、実行プログラム１００は、ＣＤ－ＲＯＭ（Compact Disc Read Only Memory）、ＤＶＤ－ＲＯＭ（Digital Versatile Disc Read Only Memory）、及びＵＳＢ（Universal Serial Bus）メモリ等の非一時的記録媒体に記録された形態で提供されてもよい。また、実行プログラム１００は、ネットワークを介して外部装置からダウンロードされる形態としてもよい。

上記実施形態で説明した処理の流れは、一例であり、主旨を逸脱しない範囲内において不要なステップを削除したり、新たなステップを追加したり、処理順序を入れ替えたりしてもよい。

１０、１０Ａ、１０Ｂ、１０Ｃ ＥＣＵ（情報処理装置、他の情報処理装置）
１１ 車両
１２ 車両通信システム
２０ マイクロコントローラ
２２ ＣＰＵ
２７ ストレージ
１００ 実行プログラム（プログラム）
１１０ 鍵データ
２００ 第１受信部
２１０ 第２受信部
２２０ 判定部
２３０ 鍵検証部
２４０ 記録部
２５０ 第３受信部
２６０ 認証部
２７０ 情報処理部

Claims (6)

1. メッセージを認証するために用いられる鍵の設定を検証する鍵検証の開始を要求する信号を受信する第１受信部と、
   前記鍵検証を行うために用いられる検証情報を受信する第２受信部と、
   前記信号を受信してから予め定められた時間内に前記検証情報が受信されなかった場合に、前記鍵検証に失敗したことを示す情報を記録し、
   前記信号が受信されてから前記予め定められた時間内に前記検証情報が受信された場合であって、かつ、前記鍵検証に失敗した場合に、前記鍵検証に失敗したことを示す情報を記録する記録部と、
   を含む情報処理装置。
2. 前記記録部は、前記信号を受信せずに、前記検証情報が受信された場合に、前記鍵検証に失敗したことを示す情報を記録する請求項１記載の情報処理装置。
3. メモリに記憶された鍵と、前記メッセージに付与された認証情報とに基づいて、前記メッセージを認証する認証部と、
   前記検証情報に基づいて、前記鍵の設定を検証する鍵検証部とを更に含み、
   前記記録部は、前記信号が受信されてから前記予め定められた時間内に前記検証情報が受信された場合であって、かつ、前記鍵検証部による検証に失敗した場合に、前記鍵検証に失敗したことを示す情報を記録する請求項１又は２記載の情報処理装置。
4. 請求項１～請求項３の何れか１項記載の情報処理装置と、
   前記情報処理装置へ前記検証情報を送信する他の情報処理装置と、
   を備え、
   前記第１受信部は、外部装置から前記信号を受信し、
   前記第２受信部は、前記他の情報処理装置から前記検証情報を受信する
   車両。
5. 第１受信部が、メッセージを認証するために用いられる鍵の設定を検証する鍵検証の開始を要求する信号を受信し、
   第２受信部が、前記鍵検証を行うために用いられる検証情報を受信し、
   記録部が、前記信号を受信してから予め定められた時間内に前記検証情報が受信されなかった場合に、前記鍵検証に失敗したことを示す情報を記録し、
   前記信号が受信されてから前記予め定められた時間内に前記検証情報が受信された場合であって、かつ、前記鍵検証に失敗した場合に、前記鍵検証に失敗したことを示す情報を記録する
   情報処理方法。
6. メッセージを認証するために用いられる鍵の設定を検証する鍵検証の開始を要求する信号を受信し、
   前記鍵検証を行うために用いられる検証情報を受信し、
   前記信号を受信してから予め定められた時間内に前記検証情報が受信されなかった場合に、前記鍵検証に失敗したことを示す情報を記録し、
   前記信号が受信されてから前記予め定められた時間内に前記検証情報が受信された場合であって、かつ、前記鍵検証に失敗した場合に、前記鍵検証に失敗したことを示す情報を記録する
   処理をコンピュータに実行させるためのプログラム。