(57)【要約】【課題】機器の保護機能の異常を検知できる異常検知装置を提供する。【解決手段】機器（車両１００）の異常を検知する異常検知装置（サーバ１）は、車両１００の車載ネットワークにおける異常を判定する異常判定部１３１の判定結果と、車両１００のデータログとを、車両１００から受信する通信部７０と、通信部７０が受信したデータログに基づいて車載ネットワークにおける異常を判定する第１判定部１０と、通信部７０が受信した異常判定部１３１の判定結果と第１判定部１０の判定結果とが一致するか否かを判定する第２判定部２０と、異常判定部１３１の判定結果と第１判定部１０の判定結果とが一致しないと第２判定部２０が判定した場合に、異常判定部１３１の異常に対応するための情報を車両１００、および、車両１００を使用または管理するユーザの少なくとも一方に通知する通知部５０と、を備える。【選択図】図３
2019174426.tif 000002
【特許請求の範囲】
【請求項１】
機器の異常を検知する異常検知装置であって、
前記機器が有する異常判定部であって、前記機器の機器内ネットワークにおける異常を判定する異常判定部の判定結果と、前記機器のデータログとを、前記機器から受信する通信部と、
前記通信部が受信した前記データログに基づいて前記機器内ネットワークにおける異常を判定する第１判定部と、
前記通信部が受信した前記異常判定部の判定結果と前記第１判定部の判定結果とが一致するか否かを判定する第２判定部と、
前記異常判定部の判定結果と前記第１判定部の判定結果とが一致しないと前記第２判定部が判定した場合に、前記異常判定部の異常に対応するための情報を前記機器、および、前記機器を使用または管理するユーザの少なくとも一方に通知する通知部と、を備える、
異常検知装置。
【請求項２】
前記第２判定部は、前記異常判定部の判定結果と、前記第１判定部の判定結果とが一致しないと判定した場合に、前記異常判定部の判定結果が正常を示し、かつ、前記第１判定部の判定結果が異常を示すときには、前記異常判定部の判定結果が異常を示し、かつ、前記第１判定部の判定結果が正常を示すときよりも異常度が高いと判定し、前記通知部は、前記異常に対応するための情報として、当該高い異常度の異常に対応するための情報を通知する、
請求項１に記載の異常検知装置。
【請求項３】
前記高い異常度の異常に対応するための情報には、前記機器の機能を制限することを示す情報が含まれる、
請求項２に記載の異常検知装置。
【請求項４】
前記第１判定部は、
前記通信部が受信した前記データログから前記機器内ネットワークにおける位置または異常の種類ごとに異常を検知する複数の検知部を有し、
前記複数の検知部の検知結果に応じて前記機器内ネットワークにおける異常を判定する、
請求項１〜３のいずれか１項に記載の異常検知装置。
【請求項５】
前記通知部は、前記異常に対応するための情報として、前記複数の検知部のうち異常を検知した検知部を示す情報を通知する、
請求項４に記載の異常検知装置。
【請求項６】
前記異常判定装置は、さらに、前記複数の検知部のうち異常を検知した検知部の組み合わせに応じて、前記機器を異常とした攻撃の攻撃経路を推定する推定部を備える、
請求項４または５に記載の異常検知装置。
【請求項７】
前記異常判定装置は、さらに、前記機器内ネットワークにおける前記推定部が推定した前記攻撃経路を流れるパケットを止めることで、前記攻撃経路が実際に攻撃を受けた経路であるか否かを診断する診断部を備える、
請求項６に記載の異常検知装置。
【請求項８】
前記通知部は、前記異常に対応するための情報として、前記攻撃経路を表示するための情報を通知する、
請求項６または７に記載の異常検知装置。
【請求項９】
前記第１判定部は、前記データログが示す前記機器内ネットワークで送信されるパケットの送信周期が所定の周期となっているか否かに応じて前記機器内ネットワークにおける異常を判定する、
請求項１〜８のいずれか１項に記載の異常検知装置。
【請求項１０】
前記第１判定部は、前記データログが示す前記機器内ネットワークで送信されるパケットの内容の変化量が所定の変化量となっているか否かに応じて前記機器内ネットワークにおける異常を判定する、
請求項１〜９のいずれか１項に記載の異常検知装置。
【請求項１１】
前記通知部は、前記異常判定部の判定結果と、前記第１判定部の判定結果とが一致しないと前記第２判定部が判定した場合に、前記異常判定部の異常に対応するための情報を、さらに、前記機器と同じ種類の機器、および、当該機器を使用または管理するユーザの少なくとも一方に通知する、
請求項１〜１０のいずれか１項に記載の異常検知装置。
【請求項１２】
機器の異常を検知する異常検知方法であって、
前記機器が有する異常判定部であって、前記機器の機器内ネットワークにおける異常を判定する異常判定部の判定結果と、前記機器のデータログとを、前記機器から受信するステップと、
受信した前記データログに基づいて前記機器内ネットワークにおける異常を判定する第１判定ステップと、
受信した前記異常判定部の判定結果と前記第１判定ステップでの判定結果とが一致するか否かを判定する第２判定ステップと、
前記異常判定部の判定結果と、前記第１判定ステップでの判定結果とが一致しないと前記第２判定ステップで判定した場合に、前記異常判定部の異常に対応するための情報を前記機器、および、前記機器を使用または管理するユーザの少なくとも一方に通知するステップと、を含む、
異常検知方法。
【請求項１３】
請求項１２に記載の異常検知方法をコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、異常検知装置、異常検知方法およびそのプログラムに関する。
【背景技術】
【０００２】
近年、自動車等の車両の中のシステムには、電子制御ユニット（ＥＣＵ：Ｅｌｅｃｔｒｏｎｉｃ  Ｃｏｎｔｒｏｌ  Ｕｎｉｔ）と呼ばれる装置が多数配置されている。これらのＥＣＵをつなぐネットワークは車載ネットワークと呼ばれる。車載ネットワークには、多数の規格が存在する。その中でも最も主流な車載ネットワークの一つに、ＩＳＯ１１８９８−１で規定されているＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）という規格が存在する。
【０００３】
ＣＡＮでは、通信路は２本のワイヤで構成されたバス（ＣＡＮバス）であり、バスに接続されているＥＣＵはノードと呼ばれる。ＣＡＮバスに接続されている各ノードは、フレーム（メッセージ）を送受信する。またＣＡＮでは、送信先や送信元を指す識別子は存在せず、送信ノードはフレーム毎に、メッセージＩＤと呼ばれるＩＤを付けて送信し、各受信ノードは予め定められたメッセージＩＤのみを受信する。車両の中のシステムにおいては、多数のＥＣＵそれぞれは、様々なフレームの授受を行う。
【０００４】
近年、コネクテッドカーの普及により、ＥＣＵが搭載された車両はインターネット等を介して外部ネットワークと接続される機会が増えている。例えば、ＣＡＮバスに不正なノードを接続すること、或いは、携帯情報端末、車外の通信装置等と通信する機能を有するＥＣＵ等を攻撃して不正なノードに変化させること等により、攻撃者が、攻撃フレームをＣＡＮバスに送信して、車両を不正にコントロールする可能性がある。攻撃フレームは、不正な攻撃者によってＣＡＮバスに送信されたフレームであり、車載ネットワークの正常状態において本来は送信されないフレームである。
【０００５】
車両等は、長期間（例えば１０年等）使用されることもあり、長期間にわたって車両の解析が可能であり、攻撃者からの攻撃を受けているおそれがある。このため、車両に対するサイバーセキュリティ対策は急務となっている。このようなサイバーセキュリティ対策に関する技術として、危殆化を識別する技術や車両を遠隔診断する技術が知られている（例えば、特許文献１、特許文献２参照）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特許第６１２２５５５号公報
【特許文献２】特許第４２４４１５３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上記車両（コネクテッドカー）等のＩｏＴ（Ｉｎｔｅｒｎｅｔ  ｏｆ  Ｔｈｉｎｇｓ）機器は、インターネット等を介して外部ネットワークに接続されるため、上述したように、攻撃者からの攻撃を受けることがある。このため、これらの機器について、攻撃者からの攻撃による機器の異常を判定する異常判定部（保護機能）の導入が進められている。しかし、例えば車両等は、長期間使用されることもあり、保護機能ですら攻撃者に狙われる危険性がある。したがって、保護機能の異常を検知することが必要となっている。しかし、特許文献１は、ＩＴ（Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｅｃｈｎｏｌｏｇｙ）分野において単に危殆化を識別することを開示しているだけであり、また、特許文献２は、車両の分野において車両を遠隔診断する技術を開示しているだけであり、いずれも保護機能の異常の検知については開示されていない。
【０００８】
そこで、本開示は、保護機能の異常を検知できる異常検知装置等を提供する。
【課題を解決するための手段】
【０００９】
本開示における異常検知装置は、機器の異常を検知する異常検知装置であって、前記機器が有する異常判定部であって、前記機器の機器内ネットワークにおける異常を判定する異常判定部の判定結果と、前記機器のデータログとを、前記機器から受信する通信部と、前記通信部が受信した前記データログに基づいて前記機器内ネットワークにおける異常を判定する第１判定部と、前記通信部が受信した前記異常判定部の判定結果と前記第１判定部の判定結果とが一致するか否かを判定する第２判定部と、前記異常判定部の判定結果と前記第１判定部の判定結果とが一致しないと前記第２判定部が判定した場合に、前記異常判定部の異常に対応するための情報を前記機器、および、前記機器を使用または管理するユーザの少なくとも一方に通知する通知部と、を備える。
【００１０】
本開示における異常検知方法は、機器の異常を検知する異常検知方法であって、前記機器が有する異常判定部であって、前記機器の機器内ネットワークにおける異常を判定する異常判定部の判定結果と、前記機器のデータログとを、前記機器から受信するステップと、受信した前記データログに基づいて前記機器内ネットワークにおける異常を判定する第１判定ステップと、受信した前記異常判定部の判定結果と前記第１判定ステップでの判定結果とが一致するか否かを判定する第２判定ステップと、前記異常判定部の判定結果と、前記第１判定ステップでの判定結果とが一致しないと前記第２判定ステップで判定した場合に、前記異常判定部の異常に対応するための情報を前記機器、および、前記機器を使用または管理するユーザの少なくとも一方に通知するステップと、を含む。
【００１１】
本開示におけるプログラムは、上記の異常検知方法をコンピュータに実行させるためのプログラム。
【発明の効果】
【００１２】
本開示における異常検知装置等は、保護機能の異常を検知できる。具体的には、保護機能として異常判定部の異常を検知し、車両等の機器を保護できる。
【図面の簡単な説明】
【００１３】
【図１】機器のセキュリティ機能を説明するための図である。
【図２】実施の形態における異常検知装置に接続される機器の一例を示す構成図である。
【図３】実施の形態における異常検知装置の一例を示す構成図である。
【図４】実施の形態における異常検知装置および機器の全体処理の一例を示すシーケンス図である。
【図５】実施の形態における機器の異常判定部の動作の一例を示すフローチャートである。
【図６】実施の形態における機器の外部通信ＥＣＵの動作の一例を示すフローチャートである。
【図７】実施の形態における第１判定部および第２判定部の動作の一例を示すフローチャートである。
【図８】攻撃経路の画像の一例を示す図である。
【図９】攻撃経路の画像の他の一例を示す図である。
【発明を実施するための形態】
【００１４】
以下、適宜図面を参照しながら、実施の形態を詳細に説明する。但し、必要以上に詳細な説明は省略する場合がある。例えば、既によく知られた事項の詳細説明や実質的に同一の構成に対する重複説明を省略する場合がある。これは、以下の説明が不必要に冗長になるのを避け、当業者の理解を容易にするためである。
【００１５】
なお、発明者らは、当業者が本開示を十分に理解するために添付図面及び以下の説明を提供するのであって、これらによって特許請求の範囲に記載の主題を限定することを意図するものではない。
【００１６】
（実施の形態）
以下、図１から図９を用いて、実施の形態を説明する。以下では、本開示の異常検知装置として、サーバを例に説明する。また、サーバ（異常検知装置）に接続され、サーバによって異常が検知される機器として、車両を例に説明する。このため、機器の機器内ネットワークを車載ネットワークとも呼び、機器内ネットワークで送信されるパケットをフレーム（ＣＡＮのフレーム）とも呼ぶ。
【００１７】
［１．セキュリティ機能］
図１は、機器（車両）のセキュリティ機能を説明するための図である。
【００１８】
車両１００は、近年のＩｏＴ化によって、外部ネットワーク（例えば、携帯端末、ＰＣ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）、カーナビゲーションシステム等）に接続される機会が増加し、不正な攻撃者による攻撃の対策が必要となっている。このため、車両１００には、異常検知ＥＣＵが搭載されている。異常検知ＥＣＵは、既知の攻撃から車両１００を保護する機能を有する。例えば、異常検知ＥＣＵは、保護機能として、車両１００の車載ネットワークにおける異常を判定する異常判定部を有する。また、未知の攻撃に対応するために、上記保護機能を更新する機能を有する。
【００１９】
車両１００は、サーバと相互に通信可能となっており、異常検知ＥＣＵを更新するために、異常判定部の判定結果と、車両１００のデータログがサーバに送信される。データログは、車種と、車種毎に車両を識別するための車両ＩＤ、車両に搭載される各ＥＣＵについてのＩＤ、その各ＥＣＵが送信するフレームについての情報等が関連付けられた情報である。各ＥＣＵが送信するフレームについての情報は、例えばＣＡＮのフレームの識別情報（メッセージＩＤ）、フレームの送信周期（受信周期）、フレームの内容等の情報である。フレームの内容としては、例えば、ステアリングやブレーキ等の制御量（指示値）等がある。
【００２０】
サーバは、判定結果が異常を示す場合にはデータログを解析し、その異常を引き起こした攻撃に対応するための更新プログラムを生成して、車両１００と同種の車両に送信し、それらの車両が有する異常検知ＥＣＵを更新させる。
【００２１】
このように、近年の車両は、例えば、未知の攻撃に対応するため、車両の異常についての判定結果およびデータログ等をサーバに送信している。
【００２２】
しかし、攻撃者は、車両の異常が発見されないように、車両の異常判定部を攻撃することが考えられる。具体的には、攻撃者は、異常判定部を攻撃してその判定ルールを不正に改ざんし、不正な制御を正常と判定させることが考えられる。この場合、サーバには、正常を示す判定結果が送信されるため、問題がないと判断されて異常検知ＥＣＵの更新が行われず、このような新たな攻撃の対策がされないことになってしまう。
【００２３】
そこで、本開示では、異常判定部の判定ルールの改ざんを検知できる異常検知装置（サーバ１）について説明する。
【００２４】
［２．車両の構成］
まず、車両１００の構成について説明する。
【００２５】
図２は、実施の形態における異常検知装置（サーバ１）に接続される機器（車両１００）の一例を示す構成図である。なお、図２には、車両１００がネットワーク２００を介して接続されるサーバ１も示している。ネットワーク２００における通信には、無線通信、或いは、有線通信のいかなる通信プロトコルを適用しても良い。
【００２６】
車両１００における車載ネットワークシステムは、ＣＡＮプロトコルに従って通信するネットワーク通信システムの一例であり、制御装置、センサ、アクチュエータ、ユーザインタフェース装置等の各種機器が搭載された車両におけるネットワーク通信システムである。この車載ネットワークシステムは、例えば、ゲートウェイ１１０、外部通信ＥＣＵ１２０、異常検知ＥＣＵ１３０、ＥＣＵ１４０ａ（操舵自動制御ＥＣＵ）、ＥＣＵ１４０ｂ（ステアリングＥＣＵ）、ＥＣＵ１４０ｃ（ブレーキＥＣＵ）およびＥＣＵ１４０ｄ（ブレーキ自動制御ＥＣＵ）、ならびに、バス１６０ａ〜１６０ｃを含んで構成される。なお、車載ネットワークシステムには、これら以外にもいくつものＥＣＵが含まれ得るが、ここでは省略している。ＥＣＵは、例えば、プロセッサ（マイクロプロセッサ）、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置である。メモリは、ＲＯＭ、ＲＡＭ等であり、プロセッサにより実行される制御プログラム（ソフトウェアとしてのコンピュータプログラム）を記憶することができる。例えばプロセッサが、制御プログラム（コンピュータプログラム）に従って動作することにより、ＥＣＵは各種機能を実現することになる。なお、コンピュータプログラムは、所定の機能を達成するために、プロセッサに対する指令を示す命令コードが複数個組み合わされて構成されたものである。ＥＣＵは、ＣＡＮプロトコルに従って車両１００内のバス１６０ａ〜１６０ｄを介してフレームの授受を行い得る。
【００２７】
各ＥＣＵは、バスに対して、ＣＡＮのプロトコルに従ったフレームを送受信する。例えば、バスから他のＥＣＵが送信したフレームを受信し、また、他のＥＣＵに送信したい内容を含むフレームを生成してバスに送信する。具体的には、各ＥＣＵは、受信したフレームの内容に応じた処理を行い、また、ＥＣＵに接続されている機器、センサ等の状態を示すデータまたは他のＥＣＵへの指示値（制御値）等のデータを含むフレームを生成して送信する。生成されたフレームには、メッセージＩＤが含まれており、各ＥＣＵは、各ＥＣＵに対して予め定められたメッセージＩＤを含むフレームのみを受信することができるため、目的のＥＣＵへとフレームを送信することができる。
【００２８】
ＥＣＵ１４０ｂは、ステアリング１５０ａに接続されており、ステアリング１５０ａの状態を取得し、周期的にステアリング１５０ａの状態を表すフレームを、バス１６０ａを介してＥＣＵ１４０ａに送信している。ＥＣＵ１４０ａは、ステアリング１５０ａの操舵を自動で制御するためのＥＣＵであり、ＥＣＵ１４０ｂから送信されるステアリング１５０ａの状態を所望の状態にするために、周期的に制御信号（指示値）を含むフレームを、バス１６０ａを介してＥＣＵ１４０ｂに送信している。ＥＣＵ１４０ｂは、ＥＣＵ１４０ａから送信されるフレームに応じてステアリング１５０ａを制御する。
【００２９】
ＥＣＵ１４０ｃは、ブレーキ１５０ｂに接続されており、ブレーキ１５０ｂの状態を取得し、周期的にブレーキ１５０ｂの状態を表すフレームを、バス１６０ｂを介してＥＣＵ１４０ｄに送信している。ＥＣＵ１４０ｄは、ブレーキ１５０ｂを自動で制御するためのＥＣＵであり、ＥＣＵ１４０ｃから送信されるブレーキ１５０ｂの状態を所望の状態にするために、周期的に制御信号（指示値）を含むフレームを、バス１６０ｂを介してＥＣＵ１４０ｃに送信している。ＥＣＵ１４０ｃは、ＥＣＵ１４０ｄから送信されるフレームに応じてブレーキ１５０ｂを制御する。
【００３０】
外部通信ＥＣＵ１２０は、車両１００のデータログおよび後述する異常判定部１３１の判定結果（これらを送信データとも呼ぶ）を、ネットワーク２００を介してサーバ１へ送信する。また、外部通信ＥＣＵ１２０は、サーバ１から送信された情報を受信し、当該情報を各ＥＣＵへと送信する。外部通信ＥＣＵ１２０は、送信データをサーバ１へ送信するタイミングを判断する判断部１２１を有する。例えば、判断部１２１は、予め定められた定期的なタイミングで送信するというルールに基づいて、送信データをサーバ１へ定期的に送信する。また、判断部１２１は、後述するサーバ１が備える送信指示部６０からの指示に応じて送信データをサーバ１へ送信する。外部通信ＥＣＵ１２０は、例えば、電波の送受信を行うアンテナ、及び、信号の送受信回路などを含む。なお、外部通信ＥＣＵ１２０は、ゲートウェイ１１０に備えられていてもよい。
【００３１】
異常検知ＥＣＵ１３０は、車載ネットワークにおける異常を検知する機能として、例えば、異常判定部１３１を有する。例えば、異常検知ＥＣＵ１３０は、車載ネットワークにおける各バスに接続されており（バスとの接続関係の図示は省略している）、異常判定部１３１は、バスから受信したフレームに基づいて異常か否かを判定する。例えば、異常検知ＥＣＵ１３０は、異常を判定するための判定ルールを保持しており、バスから受信するフレームを判定ルールに照らし合わせることで、異常か否かを判定する。判定ルールの詳細については、後述する図５で説明する。例えば、異常判定部１３１は、車載ネットワークにおける位置または異常の種類ごとに異常を検知する複数の検知部を有する。具体的には、位置毎に異常を検知する複数の検知部には、車載ネットワークにおけるバス１６０ａを監視する検知部やバス１６０ｂを監視する検知部が含まれる。また、異常の種類毎に異常を検知する複数の検知部には、バス１６０ａを監視する検知部のように互いに同じ場所を監視する検知部が複数あっても、バス１６０ａを流れるフレームの内容（指示値）から異常を検知する指示値異常検知部やバス１６０ａを流れるフレームの送信周期（受信周期）から異常を検知する周期異常検知部が含まれる。異常判定部１３１が車載ネットワークにおける位置または異常の種類ごとに異常を検知する複数の検知部を有することによって、車載ネットワークにおいて異常があるバスまたはＥＣＵを特定しやすくなる。
【００３２】
なお、異常検知ＥＣＵ１３０が備えられる場所は、車載ネットワークにおけるバスに接続される場所であれば特に限定されず、例えば、外部通信ＥＣＵ１２０に備えられていてもよいし、ゲートウェイ１１０に備えられていてもよい。異常検知ＥＣＵ１３０は、異常の判定を行う毎に判定結果を異常検知ＥＣＵ１３０が有する記憶部に蓄積し外部通信ＥＣＵ１２０からの求めに応じて蓄積した判定結果を外部通信ＥＣＵ１２０に送信してもよいし、異常の判定を行う毎にその判定結果を外部通信ＥＣＵ１２０に送信し、外部通信ＥＣＵ１２０は、外部通信ＥＣＵ１２０が有する記憶部に判定結果を蓄積してもよい。もしくは、判定結果は車両１００が有する他の記憶部に蓄積されてもよい。
【００３３】
ゲートウェイ１１０は、ＥＣＵ１４０ａおよび１４０ｂが接続されたバス１６０ａと、ＥＣＵ１４０ｃおよび１４０ｄが接続されたバス１６０ｂと、外部通信ＥＣＵ１２０が接続された１６０ｃとに接続され、一のバスから受信したフレームを他のバスに転送する機能を有する一種のＥＣＵである。なお、ゲートウェイ１１０は、異常検知ＥＣＵ１３０に接続されたバスやその他のＥＣＵに接続されたバスも接続されている。例えば、ゲートウェイ１１０は、自車両の車種、車両ＩＤ、自車両に搭載される各ＥＣＵについてのＩＤ、および、各バスから収集した各ＥＣＵが送信するフレームについての情報等を関連付けてデータログとして保持する。例えば、データログに含まれるフレームの送信周期（受信周期）は、フレームの識別情報毎に各フレームの送信時間（受信時間）等を取得することで算出することができる。なお、データログは、ゲートウェイ１１０に保持されていなくてもよく、車両１００が有する他の記憶部に保持されてもよい。
【００３４】
このような構成により、車両１００は、異常判定部１３１の判定結果および車両１００のデータログをサーバ１に送信することができる。なお、判定ルールが、不正な攻撃者によって改ざんされた場合、異常判定部１３１の判定結果は、本当は異常を示すにもかかわらず、正常を示すものとなってしまうことがある。つまり、異常判定部１３１の判定結果として、実際には誤った判定結果がサーバ１に送信されることがある。
【００３５】
［３．サーバの構成］
次に、サーバ１の構成について説明する。
【００３６】
図３は、実施の形態における異常検知装置（サーバ１）の一例を示す構成図である。なお、図３には、ネットワーク２００を介してサーバ１に接続される車両１００も示している。
【００３７】
サーバ１は、車両１００外部のコンピュータであり、ネットワーク２００を介して、車両１００における外部通信ＥＣＵ１２０と通信する。サーバ１は、上述したような異常検知ＥＣＵ１３０の更新を行う機能を有するが、本開示では、当該機能についての説明は省略し、異常判定部１３１の判定ルールが不正に改ざんされても、車両１００（異常判定部１３１）の異常を検知できる機能を中心に説明する。サーバ１は、当該機能を実現するための機能構成要素として、第１判定部１０、第２判定部２０、推定部３０、診断部４０、通知部５０、送信指示部６０および通信部７０を備える。これらの各構成要素は、サーバ１における通信回路、メモリに格納された制御プログラムを実行するプロセッサ等により実現される。
【００３８】
通信部７０は、車両１００が有する異常判定部１３１であって、車両１００の車載ネットワークにおける異常を判定する異常判定部１３１の判定結果と、車両１００のデータログとを、車両１００から受信する。また、通信部７０は、車両１００への通知、指示等の情報を車両１００へ送信する。例えば、通信部７０は、ネットワークケーブルに接続されるコネクタ、または、電波の送受信を行うアンテナ、及び、信号の送受信回路などを含む。
【００３９】
第１判定部１０は、通信部７０が受信したデータログに基づいて車載ネットワークにおける異常を判定する。本開示では、サーバ１は、攻撃者から攻撃されないように保護されていることを前提としており、第１判定部１０は、改ざんされていない判定ルールによって、車載ネットワークにおける異常を判定することができる。第１判定部１０は、当該判定を行うために、再現部１１を有する。サーバ１は、車両１００の車種、車両１００に搭載されているＥＣＵ、各ＥＣＵからなる車載ネットワークの構成、各ＥＣＵのソフトウェアバージョン等を予め把握しており、再現部１１は、車両１００の車載ネットワークを仮想的に再現するものである。つまり、再現部１１では、車両１００における異常判定部１３１も再現されており、異常判定部１３１が有する複数の検知部の機能も複数の検知部１２として再現されている。このため、第１判定部１０は、通信部７０が受信したデータログから車載ネットワークにおける位置または異常の種類ごとに異常を検知する複数の検知部１２を有し、複数の検知部１２の検知結果に応じて車載ネットワークにおける異常を判定する。再現部１１は、データログに基づいて、車両１００の車載ネットワーク上で行われた処理を仮想的に再現できるため、第１判定部１０は、改ざんされていない判定ルールによって、車両１００の異常判定部１３１が行った判定の対象と同じ対象について判定できる。したがって、第１判定部１０の判定結果は、車両１００の異常判定部１３１における判定ルールが改ざんされていなければ異常判定部１３１と同じ判定結果となり、車両１００の異常判定部１３１における判定ルールが改ざんされていれば異常判定部１３１と異なる判定結果となる。
【００４０】
第２判定部２０は、通信部７０が受信した異常判定部１３１の判定結果と、第１判定部１０の判定結果とが一致するか否かを判定する。例えば、第２判定部２０は、各判定結果が一致する場合には、一致することを示す信号を出力し、各判定結果が一致しない場合には、一致しないことを示す情報を、推定部３０、診断部４０、通知部５０等に出力する。
【００４１】
推定部３０は、複数の検知部１２のうち異常を検知した検知部１２の組み合わせに応じて、車両１００を異常とした攻撃の攻撃経路を推定する。上述したように、再現部１１では、異常判定部１３１が有する複数の検知部の機能も複数の検知部１２として再現されているため、再現部１１における複数の検知部１２のうち、異常を検知した検知部１２がわかることで、当該検知部１２に対応する異常判定部１３１における検知部、つまり具体的には当該検知部に関連するバスまたはＥＣＵに異常がある可能性があると予想できる。すなわち、車両１００における異常がある可能性のあるバスまたはＥＣＵを手掛かりに、推定部３０は、攻撃者による攻撃の攻撃経路を推定できる。推定部３０の動作の詳細については、後述する図８で説明する。
【００４２】
当該攻撃経路は、異常がある可能性のあるバスまたはＥＣＵを手掛かりに推定されたものであるため、当該攻撃経路が実際に攻撃を受けた経路であるかは確定していない。そこで、診断部４０は、車載ネットワークにおける推定部３０が推定した攻撃経路を流れるパケットを止めることで、攻撃経路が実際に攻撃を受けた経路であるか否かを診断する。診断部４０の動作の詳細については、後述する図９で説明する。
【００４３】
送信指示部６０は、車両１００に異常判定部１３１の判定結果および車両１００のデータログをサーバ１へ送信させるための情報を生成する。例えば、当該情報は、所定の期間を指定して異常判定部１３１の判定結果および車両１００のデータログを送信させるための情報である。具体的には、「２０秒後から１０分間切れ目なく送る」といったことを示す情報である。
【００４４】
例えば、攻撃者は、攻撃の発覚を阻止するために、異常判定部１３１の判定結果および車両１００のデータログ（送信データ）がサーバ１に送信されないように外部通信ＥＣＵ１２０を攻撃することが考えられる。データログが送信されなければ、第１判定部１０は、データログから異常判定部１３１の異常を判定できなくなり、異常判定部１３１の判定結果が送信されなければ、第２判定部２０は、第１判定部１０の判定結果と異常判定部１３１の判定結果とが一致するか否か判定できなくなる。また、例えば、予め定められた定期的なタイミングで送信するというルールを知る攻撃者が、送信データを偽装して、あたかも定期的に送信しているように欺くことが考えられる。これに対して、送信指示部６０は、不規則なタイミングで、車両１００（外部通信ＥＣＵ１２０）に送信データを送信させる指示をすることで、指示したタイミングで返信がなければ、外部通信ＥＣＵ１２０が攻撃を受けていることがわかる。また、通信部７０が受信したデータログに不審なコマンド（例えば、通常時には車載ネットワークにおいて流れない診断コマンド等）が含まれている場合に、攻撃の予兆があるとして、送信指示部６０は、送信データを送信させる指示をしてもよい。これにより、第１判定部１０が、データログから異常判定部１３１の異常を判定できなくなることや、第２判定部２０が、第１判定部１０の判定結果と異常判定部１３１の判定結果とが一致するか否か判定できなくなることを抑制できる。
【００４５】
通知部５０は、異常判定部１３１の判定結果と、第１判定部１０の判定結果とが一致しないと第２判定部２０が判定した場合に、異常判定部１３１の異常に対応するための情報を車両１００、および、車両１００を使用または管理するユーザの少なくとも一方に通知する。車両１００を使用または管理するユーザとは、例えば、車両１００の運転手またはサーバ１を介して車両１００を管理するサーバ１の管理人等である。異常判定部１３１の異常に対応するための情報は、例えば、車両１００に異常があること、異常の種類、異常の発生した場所もしくは攻撃経路等を認識させるための情報（例えば文字、音声、画像、映像等）、または、異常に対する制御を車両１００にさせるための制御情報を含む。これらの情報に基づいて、ユーザまたは車両１００は、異常判定部１３１の異常に対応することができる。
【００４６】
このように、第１判定部１０は、改ざんされていない判定ルールによって、車両１００のデータログを用いて車載ネットワーク（車両１００の実際の車載ネットワークの状態を再現したもの）における異常を判定する。したがって、車両１００の異常判定部１３１の判定ルールが不正に改ざんされていても、第１判定部１０の判定結果と異常判定部１３１の判定結果とが一致していなければ、車両１００に異常があることがわかり、車両１００の異常判定部１３１の異常を検知できる。
【００４７】
［４．全体処理シーケンスおよび各構成要素の動作の詳細］
次に、サーバ１および車両１００の全体処理および各構成要素の動作の詳細について、図４から図９を用いて説明する。
【００４８】
図４は、実施の形態における異常検知装置（サーバ１）および機器（車両１００）の全体処理の一例を示すシーケンス図である。なお、以下では、異常検知ＥＣＵ１３０が改ざんされているとして説明するが、図４には、正常時（異常検知ＥＣＵ１３０が改ざんされていないとき）の処理（ステップＳ１１およびステップＳ１２）も示している。また、攻撃者は、車両１００のステアリング１５０ａを不正にコントロールしようとしているとする。
【００４９】
正常時には、ＥＣＵ１４０ａ（操舵自動制御ＥＣＵ）は、ステアリング１５０ａの操舵を自動制御するために、操舵指示を含むフレームを所定の周期でＥＣＵ１４０ｂ（ステアリングＥＣＵ）に送信し（ステップＳ１１）、ＥＣＵ１４０ｂは、操舵指示に従ってステアリング１５０ａを制御する（ステップＳ１２）。
【００５０】
しかし、攻撃者は、ステアリング１５０ａを不正にコントロールするために（例えば異常な挙動の操舵をするために）、ＥＣＵ１４０ａとＥＣＵ１４０ｂとを接続するバス１６０ａに攻撃フレームを送る（ステップＳ１３）。
【００５１】
異常検知ＥＣＵ１３０（異常判定部１３１）は、バス１６０ａを監視することで、車載ネットワークにおける異常を検知する（ステップＳ１４）。例えば、異常検知ＥＣＵ１３０が改ざんされていなければ、ＥＣＵ１４０ａが所定の周期でフレームを送信しているところに攻撃者から送信された攻撃フレームが割り込むため、異常検知ＥＣＵ１３０は、予め定められた送信周期に関するルールに反して周期異常を起こす原因となっている攻撃フレームを特定して、攻撃フレームの送信を阻止する処理を行う（ステップＳ１５）。しかし、当該ルールが改ざんされており、異常検知ＥＣＵ１３０が異常なしと判定してしまうため、攻撃フレームの送信を阻止する処理が行われず、ＥＣＵ１４０ｂは、攻撃フレームに含まれる操舵指示に従ってステアリング１５０ａを制御してしまう（ステップＳ１６）。
【００５２】
ここで、ステップＳ１４での処理の詳細について図５を用いて説明する。
【００５３】
図５は、実施の形態における機器（車両１００）の異常判定部１３１の動作の一例を示すフローチャートである。ここでは、異常判定のための判定ルールとして、車載ネットワークで送信されるフレームの送信周期が所定の周期となっているかを判定するための周期異常判定ルール、および、車載ネットワークで送信されるフレームの内容（指示値）の変化量が所定の変化量となっているか否かを判定するための指示値異常判定ルールを示している。
【００５４】
まず、異常判定部１３１は、周期異常判定ルールに基づいて、フレームの送信周期が所定の周期となっているかを判定する（ステップＳ３１）。なお、送信周期は、所定の周期と完全一致しておらず、所定の周期からある程度ずれていても所定の周期となっていると判定される。所定の周期および所定の周期からのずれの許容量は、車載ネットワークの設計に応じて適宜決定される。
【００５５】
異常判定部１３１は、フレームの送信周期が所定の周期となっていないと判定した場合（ステップＳ３１でＮｏ）、送信周期に異常があると判定する（ステップＳ３２）。本実施の形態では、攻撃者は、バス１６０ａに攻撃フレームを送っているため、周期異常判定ルールが改ざんされていなければ、異常判定部１３１は、本来は、送信周期に異常があると判定し、異常検知ＥＣＵ１３０は、異常検知処理を行う。しかし、周期異常判定ルールが改ざんされることで、改ざんされた周期異常判定ルールでは、異常判定部１３１は、フレームの送信周期が所定の周期となっていると判定する。
【００５６】
異常判定部１３１は、フレームの送信周期が所定の周期となっていると判定した場合（ステップＳ３１でＹｅｓ）、指示値異常判定ルールに基づいて、車載ネットワークで送信されるフレームの内容（指示値）の変化量が所定の変化量となっているか否かを判定する（ステップＳ３３）。なお、車載ネットワークで送信されるフレームの指示値の変化量は、所定の変化量と完全一致しておらず、所定の変化量からある程度ずれていても所定の変化量となっていると判定される。所定の変化量および所定の変化量からのずれの許容量は、指示対象に応じて適宜決定される。例えば、指示対象がステアリングの場合、車両１００が危険な状態にならない程度の回転量となるように決定される。
【００５７】
ステップＳ１４での処理で、まず、送信周期の判定を行った後に、送信周期が正常の場合に指示値の変化量の判定を行っているのは、送信周期が異常となっていれば、自ずと指示値の「変化量」も異常となり、指示値の変化量の判定を行う必要がないためである。具体的には、「変化量」とは、周期的に送信されるフレームのうちの２つの連続するフレームのそれぞれの指示値から計算される単位時間あたりの変化量であるため、送信周期が異常、つまり、フレームの間隔が異常となってしまうと、単位時間当たりの変化量も異常となるためである。
【００５８】
異常判定部１３１は、車載ネットワークで送信されるフレームの指示値の変化量が所定の変化量となっていないと判定した場合（ステップＳ３３でＮｏ）、指示値の変化量に異常があると判定する（ステップＳ３４）。本実施の形態では、攻撃者は、バス１６０ａに攻撃フレームを送っているため、指示値異常判定ルールが改ざんされていなければ、異常判定部１３１は、本来は、指示値の変化量に異常があると判定し、異常検知ＥＣＵ１３０は、攻撃フレームの送信を阻止する処理を行う。しかし、指示値異常判定ルールが改ざんされることで、改ざんされた指示値異常判定ルールでは、異常判定部１３１は、フレームの指示値の変化量が所定の変化量となっていると判定する。
【００５９】
異常判定部１３１は、フレームの指示値の変化量が所定の変化量となっていると判定した場合（ステップＳ３３でＹｅｓ）、車載ネットワークに異常がないと判定する（ステップＳ３５）。本実施の形態では、攻撃者は、バス１６０ａに攻撃フレームを送っているが、異常判定部１３１の判定ルールが不正に改ざんされているため、異常判定部１３１の判定結果は正常を示すことになる。
【００６０】
なお、異常判定のための判定ルールは、周期異常判定ルールおよび指示値異常判定ルールに限らず、その他のルールであってもよい。例えば、判定ルールが、バス上の電圧または電流が所定値となっているか否かを判定するための電圧／電流異常判定ルールであってもよい。バス上を流れるフレームの内容等と、バス上の電圧または電流には相関があるため、バス上の電圧または電流が異常であれば、車載ネットワークに異常が発生していると判断することができるためである。また、例えば、判定ルールが、複数の要素間の相関関係が所定の関係となっているか否かを判定するための相関関係異常判定ルールであってもよい。一例をあげると、エンジンの回転数（速度）が大きいほど、ステアリングの変化量は小さくなるという相関関係があるため、エンジンの回転数とステアリングの変化量の相関関係をあらかじめ定義し、上記相関関係が崩れたことをもって、車載ネットワークに異常が発生していると判断することができるためである。
【００６１】
次に、外部通信ＥＣＵ１２０（判断部１２１）は、例えば、予め定められた定期的なタイミング、または、サーバ１からの送信指示に応じて、車両１００のデータログおよび異常判定部１３１の判定結果を送信するかを判断する（ステップＳ１７）。ステップＳ１７での処理の詳細について図６を用いて説明する。
【００６２】
図６は、実施の形態における機器（車両１００）の外部通信ＥＣＵ１２０の動作の一例を示すフローチャートである。
【００６３】
外部通信ＥＣＵ１２０（判断部１２１）は、現在が車両１００のデータログおよび異常判定部１３１の判定結果を定期的に送信するタイミングであるか否かを判定する（ステップＳ４１）。データログおよび判定結果を予め定められた定期的なタイミングで送信するというルールに基づいて、当該判定は行われる。
【００６４】
判断部１２１は、現在がデータログおよび判定結果を定期的に送信するタイミングであると判定した場合（ステップＳ４１でＹｅｓ）、外部通信ＥＣＵ１２０は、データログおよび判定結果をサーバ１へ送信する（ステップＳ４２）。
【００６５】
判断部１２１は、現在がデータログおよび判定結果を定期的に送信するタイミングでないと判定した場合（ステップＳ４１でＮｏ）、サーバ１からデータログおよび判定結果をサーバ１へ送信するよう指示があったか否かを判定する（ステップＳ４３）。上述したように、データログおよび判定結果がサーバ１に送信されないように攻撃者が外部通信ＥＣＵ１２０を攻撃しているか否かを判定するために、上記指示がされ、ステップＳ４３での判定が行われる。
【００６６】
判断部１２１は、上記指示があったと判定した場合（ステップＳ４３でＹｅｓ）、外部通信ＥＣＵ１２０は、データログおよび判定結果をサーバ１へ送信し、判断部１２１は、上記指示がなかったと判定した場合（ステップＳ４３でＮｏ）、外部通信ＥＣＵ１２０は、データログおよび判定結果をサーバ１へ送信しない。
【００６７】
これにより、データログおよび判定結果がサーバ１へ、定期的に送信されなかったり、指示に応じて送信されなかったりすれば、外部通信ＥＣＵ１２０が何かしらの攻撃を受けていると判断することができる。
【００６８】
外部通信ＥＣＵ１２０からサーバ１へ車両１００のデータログおよび異常判定部１３１の判定結果が送信されて、サーバ１（通信部７０）は、異常判定部１３１の判定結果と車両１００のデータログとを受信する（ステップＳ１８）。通信部７０は、異常判定部１３１の判定結果を第２判定部２０へ送り、車両１００のデータログを第１判定部１０に送る。
【００６９】
次に、第１判定部１０は、通信部７０が受信したデータログに基づいて車載ネットワークにおける異常を判定し、第２判定部２０は、異常判定部１３１の判定結果と、第１判定部１０の判定結果とを比較する（ステップＳ１９）。ステップＳ１９での処理の詳細について図７を用いて説明する。
【００７０】
図７は、実施の形態における第１判定部１０および第２判定部２０の動作の一例を示すフローチャートである。
【００７１】
まず、第１判定部１０は、車両１００と同様の環境で異常を判定する（ステップＳ５１）。第１判定部１０は、上述したように、車両１００の車載ネットワークを再現した再現部１１を有するため、第１判定部１０での判定は、図５で説明した異常判定部１３１での判定と同じように行われる。つまり、ステップＳ３１での処理と同じように、第１判定部１０は、データログが示す車載ネットワークで送信されるフレームの送信周期が所定の周期となっているか否かに応じて車載ネットワークにおける異常を判定する。また、ステップＳ３３での処理と同じように、第１判定部１０は、データログが示す車載ネットワークで送信されるパケットの内容の変化量が所定の変化量となっているか否かに応じて車載ネットワークにおける異常を判定する。
【００７２】
次に、第２判定部２０は、異常判定部１３１の判定結果と、第１判定部１０の判定結果とが一致するか否かを判定する（ステップＳ５２）。
【００７３】
第２判定部２０は、異常判定部１３１の判定結果と、第１判定部１０の判定結果とが一致すると判定した場合（ステップＳ５２でＹｅｓ）、異常検知ＥＣＵ１３０の改ざんという観点では異常なしと判定する（ステップＳ５３）。例えば、異常判定部１３１の判定結果が正常を示し、第１判定部１０の判定結果も正常を示す場合、正常であることに対して特に処理が行われなかったり、正常であることが記録されたり、正常であることがユーザに通知されたりする。例えば、異常判定部１３１の判定結果が異常を示し、第１判定部１０の判定結果も異常を示す場合、異常検知ＥＣＵ１３０を更新するための処理が行われる。
【００７４】
なお、異常判定部１３１の判定結果と、第１判定部１０の判定結果とがそれぞれ正常を示して一致するにもかかわらず、異常検知ＥＣＵ１３０が改ざんされているということも考えられる。しかし、このような偽装をするためには、車両１００における各種判定ルール、判定結果および車両１００のデータログを全て偽装する必要があり、サーバからの不規則な送信指示に対応しながらこれらを全て偽装することは困難であるため、異常判定部１３１の判定結果と、第１判定部１０の判定結果とがそれぞれ正常を示して一致するにもかかわらず、異常検知ＥＣＵ１３０が改ざんされているということは発生しにくいと考えられる。
【００７５】
第２判定部２０は、異常判定部１３１の判定結果と、第１判定部１０の判定結果とが一致しないと判定した場合（ステップＳ５２でＮｏ）、サーバ１（第１判定部１０）の判定結果が正常を示すか否かを判定する（ステップＳ５３）。
【００７６】
第２判定部２０は、第１判定部１０の判定結果が正常を示すと判定した場合（ステップＳ５４でＹｅｓ）、異常度が低いと判定する（ステップＳ５５）。異常判定部１３１は異常と判定しているが、第１判定部１０の判定結果が正常を示し、実際には車両１００に異常はないためである。例えば、このような現象が発生する原因としては、車両１００において、判定ルールのアップデートに失敗して、判定ルールが旧バージョンであったり、アップデート自体がされていなかったりすることが考えられる。
【００７７】
第２判定部２０は、第１判定部１０の判定結果が異常を示すと判定した場合（ステップＳ５４でＮｏ）、異常度が高いと判定する（ステップＳ５６）。つまり、第２判定部２０は、異常判定部１３１の判定結果と、第１判定部１０の判定結果とが一致しないと判定した場合に、異常判定部１３１の判定結果が正常を示し、かつ、第１判定部１０の判定結果が異常を示すときには、異常判定部１３１の判定結果が異常を示し、かつ、第１判定部１０の判定結果が正常を示すとき（つまりステップＳ５４でＹｅｓのとき）よりも異常度が高いと判定する。異常判定部１３１は正常と判定しているが、第１判定部１０の判定結果が異常を示し、実際には車両１００が気づいていない異常が車両１００にあるためである。例えば、この場合、車両１００の車載ネットワークへの攻撃を通すために判定ルールが改ざんされており、車両１００が不正にコントロールされ得る危険な状態となっている。したがって、第２判定部２０は、異常度が高いと判定する。
【００７８】
なお、判定結果の表現方法については、特に限定されず、例えば、正常が０、異常が１として、判定結果が２値で表されてもよいし、判定結果における異常の度合いが少数で表されてもよいし、判定結果が異常の種類やその疑わしさで表されてもよい。
【００７９】
次に、推定部３０は、車両１００を異常とした攻撃の攻撃経路を推定し、診断部４０は、攻撃経路が実際に攻撃を受けた経路であるか否かを診断する（ステップＳ２０）。ステップＳ２０での処理の詳細については、後述する。
【００８０】
そして、通知部５０は、異常判定部１３１の異常に対応するための情報を車両１００、および、車両１００を使用または管理するユーザの少なくとも一方に通知する（ステップＳ２１）。例えば、通知部５０は、異常判定部１３１の異常に対応するための情報として、攻撃が発生したことをユーザに通知する。また、例えば、第２判定部２０が、異常度が高いと推定している場合、通知部５０は、異常判定部１３１の異常に対応するための情報として、当該高い異常度の異常に対応するための情報を車両１００に通知する。具体的には、当該高い異常度の異常に対応するための情報には、車両１００の機能を制限することを示す情報が含まれる。つまり、車両１００の機能が制限されることで、攻撃者によって車両１００が不正にコントロール（例えば、急加速、急旋回等のコントロール）されないようにすることができ、危険な状態になることを防ぐことができる。また、例えば、通知部５０は、異常に対応するための情報として、攻撃経路を表示するための情報をユーザに（ユーザが有する表示部に）通知する。
【００８１】
なお、通知部５０は、異常判定部１３１の判定結果と、第１判定部１０の判定結果とが一致しないと第２判定部２０が判定した場合に、異常判定部１３１の異常に対応するための情報を、さらに、車両１００と同じ種類（車種）の車両、および、当該車両を使用または管理するユーザの少なくとも一方に通知してもよい。これにより、当該同じ車種の車両に対しても、車両１００と同じように攻撃の対策が可能となる。
【００８２】
ここで、ユーザに通知されて表示される攻撃経路を示す画像について、図８および図９を用いて説明する。
【００８３】
図８は、攻撃経路の画像の一例を示す図である。図９は、攻撃経路の画像の他の一例を示す図である。図８および図９には車両１００を表す画像１０００、車両１００に搭載されたＥＣＵを表す画像１４００ａ〜１４００ｒ、各ＥＣＵを接続するバスを表す画像１６００ａ、１６００ｂおよびゲートウェイを表す画像１１００が示されている。また、図８および図９において、実線のハッチングを付している画像（ＥＣＵ）および太線の画像（バス）は確定された攻撃経路を示し、破線のハッチングを付しているＥＣＵは攻撃経路の候補を示している。
【００８４】
詳細は後述するが、推定部３０が攻撃経路を推定することで、図８に示されるように、画像１４００ｃ、１６００ａおよび１１００に対応するＥＣＵ、バスおよびゲートウェイが攻撃経路となっていること、および、画像１４００ａ、１４００ｂ、１４００ｅ〜１４００ｇ、１４００ｑ、１４００ｒに対応するＥＣＵが攻撃経路の候補であることを示す画像を表示することができ、ユーザは、車載ネットワークがどのようにして攻撃されたのかを解析することができる。また、詳細は後述するが、診断部４０は、攻撃経路が実際に攻撃を受けた経路であるか否かを診断することで、図９に示されるように、画像１４００ｃ、１４００ｅ、１４００ｑ、１６００ａおよび１１００に対応するＥＣＵ、バスおよびゲートウェイが攻撃経路となっていることを示す画像を表示することができ、確定された攻撃経路が表示されるため、ユーザは、車載ネットワークがどのようにして攻撃されたのかをより解析しやすくなる。
【００８５】
ここで、推定部３０の動作の詳細について説明する。
【００８６】
上述したように、第１判定部１０は、通信部７０が受信したデータログから車載ネットワークにおける位置または異常の種類ごとに異常を検知する複数の検知部１２を有し、複数の検知部１２の検知結果に応じて車載ネットワークにおける異常を判定する。再現部１１には、車載ネットワークにおける各バスおよび各ＥＣＵに対応する検知部１２が存在し、また、異常の種類ごとにも検知部１２は存在しているため、推定部３０は、複数の検知部１２のうちの異常を検知した検知部１２の組み合わせに応じて車両１００を異常とした攻撃の攻撃経路を推定できる。
【００８７】
例えば、図２におけるバス１６０ａにおいて流れるフレームの周期異常を検知する検知部１２が異常を検知した場合について説明する。例えば、ＥＣＵ１４０ａへの攻撃が成功している場合には、攻撃者は、ＥＣＵ１４０ａが送信するフレームの周期に異常が発生しないようにＥＣＵ１４０ａを改ざんすると考えられ、周期異常が発生しないと考えられる。このため、バス１６０ａにおいて流れるフレームの周期異常を検知する検知部１２が異常を検知した場合、ＥＣＵ１４０ａへの攻撃が成功しておらず、攻撃者は、フレームの周期異常の発生を阻止できていないと考えられる。したがって、この場合、推定部３０は、ＥＣＵ１４０ａは攻撃されておらず、バス１６０ａに接続されたＥＣＵ１４０ａを除くＥＣＵ、および、外部に接続されたゲートウェイ等が攻撃経路であると推定できる。
【００８８】
また、例えば、図２におけるバス１６０ａにおいて流れるフレームの内容（指示値）の変化量を検知する検知部１２が異常を検知した場合について説明する。例えば、ＥＣＵ１４０ａへの攻撃が成功している場合、攻撃者は、ＥＣＵ１４０ａが送信するフレームの内容を改ざんし、もしくは、ＥＣＵ１４０ａからのフレームの送信を停止して、改ざんした内容のフレームを別途送信すると考えられる。したがって、この場合、推定部３０は、ＥＣＵ１４０ａが攻撃されており、ＥＣＵ１４０ａが攻撃経路であると推定できる。
【００８９】
なお、バス１６０ａにおいて他のＥＣＵに指示をする内容を含むフレームを送信するＥＣＵが複数ある場合がある。この場合、推定部３０は、当該複数のＥＣＵを候補として攻撃経路を推定するが、診断部４０は、攻撃経路の候補が実際に攻撃を受けた経路であるか否かを診断することができる。ここで、診断部４０の動作の詳細について説明する。
【００９０】
診断部４０は、車載ネットワークにおける推定部３０が推定した攻撃経路を流れるフレームを止めることで、攻撃経路が実際に攻撃を受けた経路であるか否かを診断する。推定部３０が推定した攻撃経路に含まれるバス１６０ａを流れるフレームとして、ＥＣＵ１４０ａが送信するフレームを止めるように、診断部４０は、遠隔診断機能により送信を止めるコマンドをＥＣＵ１４０ａに向けて送信する。これによって、バス１６０ａにおいて流れるフレームの指示値の変化量の異常が検知されなくなれば、ＥＣＵ１４０ａが改ざんされていると診断することができる。一方で、バス１６０ａにおいて流れるフレームの指示値の変化量の異常が検知されたままであれば、他のＥＣＵが改ざんされていると診断することができる。
【００９１】
このようにして、同一のバスに接続された指示値を含むフレームを送信する複数のＥＣＵに対して、１つずつフレームの送信を止めることを繰り返していくことで、攻撃経路が実際に攻撃を受けた経路であるか否かを診断することができる。
【００９２】
したがって、通知部５０は、例えば、図９に示されるように、診断部４０による診断によって、確定した攻撃経路のみが示された画像を表示するための情報を通知できる。なお、通知部５０が通知する攻撃経路を表示するための情報は、診断部４０による診断後の図９に示されるような画像を表示するための情報に限らず、診断部４０による診断前の図８に示されるような画像を表示するための情報であってもよい。また、診断部４０によってＥＣＵが１つずつ改ざんされているか否かが確定するたびに攻撃経路を表示するための情報が更新されていき、図８に示されるような画像から図９に示されるような画像へと徐々に表示内容が変わっていってもよい。
【００９３】
［５．効果等］
以上説明したように、サーバ１（異常検知装置）は、車両１００（機器）の異常を検知する異常検知装置である。サーバ１は、車両１００が有する異常判定部１３１であって、車両１００の車載ネットワーク（機器内ネットワーク）における異常を判定する異常判定部１３１の判定結果と、車両１００のデータログとを、車両１００から受信する通信部７０を備える。サーバ１は、通信部７０が受信したデータログに基づいて車載ネットワークにおける異常を判定する第１判定部１０と、通信部７０が受信した異常判定部１３１の判定結果と第１判定部１０の判定結果とが一致するか否かを判定する第２判定部２０と、を備える。サーバ１は、異常判定部１３１の判定結果と第１判定部１０の判定結果とが一致しないと第２判定部２０が判定した場合に、異常判定部１３１の異常に対応するための情報を車両１００、および、車両１００を使用または管理するユーザの少なくとも一方に通知する通知部５０と、を備える。
【００９４】
これによれば、車両１００が有する、車載ネットワークにおける異常を判定する異常判定部１３１自体が異常となっていても、異常となっている異常判定部１３１の判定結果と、正しい判定を行う第１判定部１０の判定結果とが比較されるため、異常判定部１３１（保護機能）の異常を検知できる。そして、各判定結果が一致しない、つまり、異常判定部１３１自体が異常となっている場合には、異常判定部１３１の異常に対応するための情報が通知されることによって、異常に対応することができる。例えば、異常が見つかった車両１００と同じ車種の車両に対して、当該異常を引き起こした攻撃の対策をすることができる。
【００９５】
また、例えば、第２判定部２０は、異常判定部１３１の判定結果と、第１判定部１０の判定結果とが一致しないと判定した場合に、異常判定部１３１の判定結果が正常を示し、かつ、第１判定部１０の判定結果が異常を示すときには、異常判定部１３１の判定結果が異常を示し、かつ、第１判定部１０の判定結果が正常を示すときよりも異常度が高いと判定し、通知部５０は、異常に対応するための情報として、当該高い異常度の異常に対応するための情報を通知してもよい。
【００９６】
異常判定部１３１の判定結果が正常を示し、かつ、第１判定部１０の判定結果が異常を示すときとは、実際には車両１００に異常があるにもかかわらず、車両１００では異常があると認識できていない状態であるため、危険な状態である可能性が高い。このため、当該高い異常度の異常に対応するための情報を通知することで、車両１００が危険な状態であることをユーザに知らせたり、危険な状態を回避するための制御を車両１００にさせたりすることができる。
【００９７】
また、例えば、当該高い異常度の異常に対応するための情報には、車両１００の機能を制限することを示す情報が含まれていてもよい。
【００９８】
これによれば、例えば、車両１００のスピードを制限するなどして、危険な状態を回避することができる。
【００９９】
また、例えば、第１判定部１０は、通信部７０が受信したデータログから車載ネットワークにおける位置または異常の種類ごとに異常を検知する複数の検知部１２を有し、複数の検知部１２の検知結果に応じて車載ネットワークにおける異常を判定してもよい。例えば、通知部５０は、異常に対応するための情報として、複数の検知部１２のうち異常を検知した検知部１２を示す情報を通知してもよい。
【０１００】
これによれば、車載ネットワークにおいて異常があるバスまたはＥＣＵを特定しやすくなる。
【０１０１】
また、例えば、サーバ１は、さらに、複数の検知部１２のうち異常を検知した検知部１２の組み合わせに応じて、車両１００を異常とした攻撃の攻撃経路を推定する推定部３０を備えていてもよい。
【０１０２】
これによれば、攻撃経路をより正確に推定することができる。
【０１０３】
また、例えば、サーバ１は、さらに、車載ネットワークにおける推定部３０が推定した攻撃経路を流れるパケットを止めることで、攻撃経路が実際に攻撃を受けた経路であるか否かを診断する診断部４０を備えていてもよい。
【０１０４】
これによれば、攻撃経路を確定することができ、より確実な情報を通知することができる。
【０１０５】
また、例えば、通知部５０は、異常に対応するための情報として、攻撃経路を表示するための情報を通知してもよい。
【０１０６】
これによれば、ユーザは、攻撃経路を視覚的に確認することができる。例えば、サーバ１を介して車両１００を管理する管理者が攻撃経路を確認することで、効果的に、異常を引き起こした攻撃の対策をすることができる。
【０１０７】
また、例えば、第１判定部１０は、データログが示す車載ネットワークで送信されるフレーム（パケット）の送信周期が所定の周期となっているか否かに応じて車載ネットワークにおける異常を判定してもよい。
【０１０８】
これによれば、フレームの送信周期を検知するだけで容易に車載ネットワークにおける異常を検知できる。
【０１０９】
また、例えば、第１判定部１０は、データログが示す車載ネットワークで送信されるフレームの内容（指示値）の変化量が所定の変化量となっているか否かに応じて車載ネットワークにおける異常を判定してもよい。
【０１１０】
これによれば、フレームの指示値の変化量を検知するだけで容易に車載ネットワークにおける異常を検知できる。
【０１１１】
また、例えば、通知部５０は、異常判定部１３１の判定結果と、第１判定部１０の判定結果とが一致しないと第２判定部２０が判定した場合に、異常判定部１３１の異常に対応するための情報を、さらに、車両１００と同じ車種（種類）の車両、および、当該車両を使用または管理するユーザの少なくとも一方に通知してもよい。
【０１１２】
これによれば、当該同じ車種の車両に対しても、車両１００と同じように攻撃の対策が可能となる。
【０１１３】
（他の実施の形態）
以上のように、本出願において開示する技術の例示として、実施の形態を説明した。しかしながら、本開示における技術は、これに限定されず、適宜、変更、置き換え、付加、省略等を行った実施の形態にも適応可能である。また、上記実施の形態で説明した各構成要素を組み合わせて、新たな実施の形態とすることも可能である。
【０１１４】
例えば、上記実施の形態では、異常検知装置として、サーバ１を例に説明したが、これに限らない。例えば、異常検知装置は、車両１００等のＩｏＴ機器に接続されるコンピュータ等であってもよい。
【０１１５】
また、サーバ１を構成する構成要素は、複数のサーバ（コンピュータ）に分散して配置されていてもよい。
【０１１６】
また、例えば、上記実施の形態では、サーバ１（異常検知装置）に接続され異常が検知される機器として、車両１００を例に説明したが、これに限らない。例えば、機器は、他の移動体であってもよく、また、移動体に限らず他のＩｏＴ機器（例えば医療機器等）であってもよい。
【０１１７】
また、例えば、上記実施の形態では、フレームの周期異常の検知について、送信周期の異常が検知されたが、受信周期の異常が検知されてもよい。
【０１１８】
また、本開示は、異常検知装置として実現できるだけでなく、異常検知装置を構成する各構成要素が行うステップ（処理）を含む異常検知方法として実現できる。
【０１１９】
具体的には、図４および図７に示されるように、異常検知方法は、機器の異常を検知する異常検知方法であって、機器が有する異常判定部１３１であって、機器の機器内ネットワークにおける異常を判定する異常判定部１３１の判定結果と、機器のデータログとを、機器から受信するステップ（ステップＳ１８）と、受信したデータログに基づいて機器内ネットワークにおける異常を判定する第１判定ステップ（ステップＳ５１）と、受信した異常判定部１３１の判定結果と第１判定ステップでの判定結果とが一致するか否かを判定する第２判定ステップ（ステップＳ５２）と、異常判定部１３１の判定結果と第１判定ステップでの判定結果とが一致しないと第２判定ステップで判定した場合に（ステップＳ５２でＮｏ）、異常判定部１３１の異常に対応するための情報を機器、および、機器を使用または管理するユーザの少なくとも一方に通知するステップ（ステップＳ２１）と、を含む。
【０１２０】
例えば、それらのステップは、コンピュータ（コンピュータシステム）によって実行されてもよい。そして、本開示は、それらの方法に含まれるステップを、コンピュータに実行させるためのプログラムとして実現できる。さらに、本開示は、そのプログラムを記録したＣＤ−ＲＯＭ等である非一時的なコンピュータ読み取り可能な記録媒体として実現できる。
【０１２１】
例えば、本開示が、プログラム（ソフトウェア）で実現される場合には、コンピュータのＣＰＵ、メモリおよび入出力回路等のハードウェア資源を利用してプログラムが実行されることによって、各ステップが実行される。つまり、ＣＰＵがデータをメモリまたは入出力回路等から取得して演算したり、演算結果をメモリまたは入出力回路等に出力したりすることによって、各ステップが実行される。
【０１２２】
また、上記実施の形態の異常検知装置に含まれる各構成要素は、専用または汎用の回路として実現されてもよい。
【０１２３】
また、上記実施の形態の異常検知装置に含まれる各構成要素は、集積回路（ＩＣ：Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）であるＬＳＩ（Ｌａｒｇｅ  Ｓｃａｌｅ  Ｉｎｔｅｇｒａｔｉｏｎ）として実現されてもよい。
【０１２４】
また、集積回路はＬＳＩに限られず、専用回路または汎用プロセッサで実現されてもよい。プログラム可能なＦＰＧＡ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）、または、ＬＳＩ内部の回路セルの接続および設定が再構成可能なリコンフィギュラブル・プロセッサが、利用されてもよい。
【０１２５】
さらに、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて、異常検知装置に含まれる各構成要素の集積回路化が行われてもよい。
【０１２６】
以上のように、本開示における技術の例示として、実施の形態を説明した。そのために、添付図面及び詳細な説明を提供した。
【０１２７】
したがって、添付図面及び詳細な説明に記載された構成要素の中には、課題解決のために必須な構成要素だけでなく、課題解決のためには必須でない構成要素も含まれ得る。そのため、それらの必須ではない構成要素が添付図面や詳細な説明に記載されていることをもって、直ちに、それらの必須ではない構成要素が必須であるとの認定をするべきではない。
【０１２８】
また、上述の実施の形態は、本開示における技術を例示するためのものであるから、特許請求の範囲又はその均等の範囲において種々の変更、置き換え、付加、省略などを行うことができる。
【産業上の利用可能性】
【０１２９】
本開示は、外部からの攻撃の対策が必要なコネクテッドカー等のＩｏＴ機器に適用可能である。
【符号の説明】
【０１３０】
１    サーバ（異常検知装置）
１０    第１判定部
１１    再現部
１２    検知部
２０    第２判定部
３０    推定部
４０    診断部
５０    通知部
６０    送信指示部
７０    通信部
１００    車両（機器）
１１０    ゲートウェイ
１２０    外部通信ＥＣＵ
１２１    判断部
１３０    異常検知ＥＣＵ
１３１    異常判定部
１４０ａ、１４０ｂ、１４０ｃ、１４０ｄ    ＥＣＵ
１５０ａ    ステアリング
１５０ｂ    ブレーキ
１６０ａ、１６０ｂ、１６０ｃ    バス
２００    ネットワーク
１０００、１１００、１４００ａ〜１４００ｒ、１６００ａ、１６００ｂ    画像
【図１】
2019174426.tif 000003
【図２】
2019174426.tif 000004
【図３】
2019174426.tif 000005
【図４】
2019174426.tif 000006
【図５】
2019174426.tif 000007
【図６】
2019174426.tif 000008
【図７】
2019174426.tif 000009
【図８】
2019174426.tif 000010
【図９】
2019174426.tif 000011