JP2023068037A - 車両異常検知サーバ、車両異常検知システム及び車両異常検知方法 - Google Patents

Abstract

【課題】監視対象の車両の多少にかかわらず、異常の検知から対処まで迅速かつ適切に実行可能な車両異常検知装置等を提供する。【解決手段】車両と通信して当該車両が備える車載ネットワークのログを受信する通信部８１０と、通信の相手である複数台の車両の一である第一車両における異常の発生を示す情報を取得すると、当該異常に応じた異常関連車両を複数台の車両から選出するログ収集対象車両選出部８５５と、異常関連車両に、搭載する車載ネットワークのログの送信を要求する第一リクエストを通信部８１０を介して送信するログ収集部８３０と、第一リクエストに応じて異常関連車両から送信され、通信部８１０が受信したログが示す情報に基づいて異常関連車両における異常の発生有無の判定を行うログ分析部８４０とを備える。【選択図】図５

Description

本発明は車両に搭載される電子制御ユニットが通信を行う車載ネットワークにおいて送信され得る攻撃フレームの検知、対処等のためのセキュリティ技術に関する。

近年、自動車には、電子制御ユニット（ＥＣＵ：Electronic Control Unit）と呼ばれる装置が多数配置されている。これらのＥＣＵをつなぐ通信ネットワークは車載ネットワークと呼ばれる。車載ネットワークに用いられる主な通信規格としては、ＩＳＯ１１８９８－１で規定されているController Area Network（ＣＡＮ（登録商標））やＥｔｈｅｒｎｅｔ（登録商標）が挙げられる。自動車が高性能化するのに伴い、このような車載ネットワークを介してＥＣＵ間で送受信されるデータに基づいて各ＥＣＵによる制御の内容が決定されて提供される機能が増えてきている。このような制御システムにおいては、不正に取り付けられたＥＣＵ、又はサイバー攻撃によって乗っ取られたＥＣＵが、データの内容が改竄されたフレーム等の偽のフレームを送信することにより他のＥＣＵに不正な制御を実行させるという攻撃が行われる恐れがある。

このような攻撃を検知して防御する技術として、車載ネットワークにおいて同一メッセージＩＤを持ったフレームについて、想定される送信周期を予め登録し、実際の送信周期とこの想定の送信周期との比較に基づいて不正か否かの判別を行う技術が知られている（特許文献１参照）。

また、各車両の車載ネットワークで送受信されたフレームがサーバに送信され、サーバでは、このフレームの異常度を算定し、この異常度に基づいて、多様な攻撃フレームに適切に対処する技術が知られている（特許文献２参照）。

特開２０１４－１４６８６８号公報 特開２０１７－１１１７９６号公報

しかしながら、上記の構成では、サーバにデータを送信する車両が多くなれば、このデータの処理に基づく異常への対処までにボトルネックが生じた場合に適切な対処を迅速に執ることができず、例えば攻撃の対象になり得る車両が増える等、攻撃の被害が深刻化する可能性が高まるという課題がある。

そこで本発明は、監視対象の車両の多少にかかわらず、異常の検知から対処まで迅速かつ適切に実行可能な車両異常検知装置等を提供する。

本発明の一態様による車両異常検知サーバは、車両と通信して当該車両が備える車載ネットワークのログを受信する通信部と、前記通信の相手である複数台の車両の一である第一車両における異常の発生を示す情報を取得すると、前記第一車両の異常に応じた異常関連車両を前記複数台の車両から選出する車両選出部と、前記異常関連車両に、前記異常関連車両が備える車載ネットワークのログの送信を要求する第一リクエストを前記通信部を介して送信するログ収集部と、前記第一リクエストに応じて前記異常関連車両から送信され、前記通信部が受信したログが示す情報に基づいて前記異常関連車両における異常の発生有無の判定を行うログ分析部とを備える。

また、本発明の一態様による車両異常検知システムは、上記の車両異常検知サーバと、前記車両異常検知サーバと通信する複数台の車両であって、前記車両異常検知サーバからのリクエストに応じて前記ログを前記車両異常検知サーバに送信する車両とを含む。

また、本発明の一態様による車両異常検知方法は、上記の車両異常検知システムで実行される車両異常検知方法であって、前記車両異常検知システムにおいて、前記複数台の車両の一である第一車両における異常の発生を示す情報を取得すると、前記複数台の車両から前記第一車両の異常に応じた異常関連車両を選出し、前記車両異常検知システムから前記異常関連車両に、前記異常関連車両が備える車載ネットワークのログの送信を要求する第一リクエストを送信し、前記車両異常検知システムが、前記第一リクエストに応じて前記異常関連車両から送信されたログが示す情報に基づいて、前記異常関連車両における異常の発生有無の判定を行う。

なお、これらの全般的または具体的な態様は、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能な記録媒体で実現されてもよく、装置、システム、方法、コンピュータプログラム及び記録媒体の任意の組合せで実現されてもよい。

本開示における車両異常検知装置等は、監視対象の車両の多少にかかわらず、異常の検知から対処まで迅速かつ適切に実行することができる。

なお、本開示の更なる効果及び利点は、本明細書及び図面の開示内容から明らかとなるであろう。上記更なる効果及び利点は、本明細書及び図面に開示されている実施の形態及び特徴によって個別に提供されてもよく、必ずしもすべての効果及び利点が提供される必要はない。

図１は、実施の形態における車両異常検知システムのサービス体制の例を示すブロック図である。 図２は、上記の車両異常検知システムに含まれるクラウドサーバの運営体制の例を示すブロック図である。 図３は、実施の形態における車両異常検知システムの全体構成の例を示す概念図である。 図４は、上記の車両異常検知システムに含まれる車両が備える車載ネットワークの構成の例を示すブロック図である。 図５は、上記の車両異常検知システムに含まれる車両異常検知サーバの機能構成例を示すブロック図である。 図６は、実施の形態における車両ログ格納データベースに格納される車両ログ情報のデータ構成の例を示すブロック図である。 図７は、実施の形態における車両情報データベースに格納される車両情報のデータ構成例を示す図である。 図８は、実施の形態における車両情報データベースに格納される車種別情報のデータ構成例を示す図である。 図９は、実施の形態におけるセキュリティ情報データベースに格納される攻撃フェーズ情報のデータ構成例を示す図である。 図１０は、実施の形態におけるＥＣＵ情報データベースに格納されるＥＣＵ ＩＤ変換テーブルの一例を示す図である。 図１１は、実施の形態におけるＥＣＵ情報データベースに格納されるメッセージＩＤ変換テーブルの一例を示す図である。 図１２は、実施の形態におけるＥＣＵ情報データベースに格納される車種別メッセージＩＤ－ＥＣＵ関連付けテーブルの一例を示す図である。 図１３は、実施の形態におけるＥＣＵ情報データベースに格納される車種別ＥＣＵ関連付けテーブルの一例を示す図である。 図１４は、上記の車両異常検知システムに含まれる車両の備えるゲートウェイの機能構成例を示すブロック図である。 図１５は、上記の車両異常検知システムにおける異常検知までの処理手順例を示すシーケンス図である。 図１６は、上記の車両異常検知システムに含まれる車両異常検知サーバでの、平常時に異常検知処理の対象である標本車両を選出する手順例を示すフロー図である。 図１７は、上記の車両異常検知システムに含まれる車両異常検知サーバでの、異常検知の手順例を示すフロー図である。 図１８は、上記の車両異常検知システムに含まれる車両異常検知サーバでの、追加調査対象車両を選出する処理の手順例を示すフロー図である。 図１９は、上記の車両異常検知システムにおける通信の概要を示すシーケンス図である。

（本開示の基になった知見）
本発明者らは、「背景技術」の欄において記載した技術に関し、以下の問題が生じることを見出した。

車載ネットワークで送受信されるフレームが多数の車両からサーバに送信されると、車両とサーバとをつなぐ通信ネットワークでの通信データ量、又はサーバでの処理対象のデータ量がそれぞれの処理能力に対して過剰になり、異常の検知、又は検知された異常への適時の対処ができなくなる状況が想定される。このような状況を回避するためには、サーバによる異常検知処理の対象となる車両は、車両の母集団からサンプリングして選択し、選択された車両が各車両の車載ネットワークで送受信されたデータ、又はそのログをサーバへ送信することが考えられる。これにより、通信データ量の増加及びサーバでの処理負荷の増加が抑えられる。しかしながら、対象として選択されていない車両については、監視対象として選択されない限り、サーバでの異常検知処理が行われない。つまり、選択されていない車両で発生している異常は対処されないか、されるまでに時間がかかる。この異常がサイバー攻撃によるものであれば、異常への対処がなされない間にこの攻撃の影響による大きなトラブルが当該車両で発生したり、攻撃が他の車両に拡大したりする等、被害が深刻化するおそれもある。

このような問題を解決するために、本発明の一態様に係る車両異常検知サーバは、車両と通信して当該車両が備える車載ネットワークのログを受信する通信部と、前記通信の相手である複数台の車両の一である第一車両における異常の発生を示す情報を取得すると、前記第一車両の異常に応じた異常関連車両を前記複数台の車両から選出する車両選出部と、前記異常関連車両に、前記異常関連車両が備える車載ネットワークのログの送信を要求する第一リクエストを前記通信部を介して送信するログ収集部と、前記第一リクエストに応じて前記異常関連車両から送信され、前記通信部が受信したログが示す情報に基づいて前記異常関連車両における異常の発生有無の判定を行うログ分析部とを備える。

これにより、ある車両で検出された異常に応じて、同様の異常が発生している可能性が高いと考えられる他の車両について従来に比べて優先的な異常判定の実施が可能となる。そして、異常の発生の早期検知ができることで、対応も迅速に行われ、攻撃の当該車両への影響の深刻化、又はさらに他の車両への拡大を抑えることができる。

例えば、前記車両選出部は、前記複数台の車両から第一標本車両を選出し、前記ログ収集部は、選出された前記第一標本車両に、前記第一標本車両が備える車載ネットワークのログの送信を要求する第二リクエストを前記通信部を介して送信し、前記ログ分析部は、前記第二リクエストに応じて前記第一標本車両から送信され、前記通信部が受信したログが示す情報に基づいて前記第一標本車両における異常の発生有無の判定を行い、前記第一標本車両における異常の発生がないと前記ログ分析部によって判定された場合、前記車両選出部は、前記複数台の車両から前記第一標本車両とは別の第二標本車両を選出し、前記ログ収集部は、選出された前記第二標本車両に、前記第二標本車両が備える車載ネットワークのログの送信を要求する第三リクエストを前記通信部を介して送信してもよい。

これにより、異常の発生有無の判定の対象となる車両は、監視対象の全車両の一部であり、かつ監視対象が入れ替わる。したがって、通信データ量の増加及び異常検知のためにサーバで分析されるデータの量の増加を抑えながら、多様性な監視対象の車両を広く監視する効率の良い監視が実現される。

例えば、前記ログは、前記車載ネットワークで送受信されるフレームが含む情報の少なくとも一部の時系列データ又は前記フレームに関する情報の時系列データであってもよい。

これにより、異常発生の有無の判定は、フレームが含むデータの内容又は送信される周期性等に基づいて良好な精度で実行可能である。

例えば、前記車両選出部は、前記異常関連車両は、前記異常が発生している車両と車種が共通である車両を前記異常関連車両として選出してもよい。

車種が同一の車両は同種の情報処理装置（ＥＣＵ）を備えることが多く、生じやすい故障、未発見のバグ、又はサイバー攻撃に対する脆弱性等の共通の問題を抱えている可能性が高い。つまり、車種が同一の車両では、一台の車両で検知された異常と同様の異常が他の車両にも発生している可能性は、他の車種よりも高い。このような車両を異常関連車両として扱って、分析のためのデータの収集の対象とすることで、効率よく異常の発生を検知し、迅速な対処が可能になる。

例えば、前記車載ネットワークにおいて送受信されるフレームの種類と前記フレームを送信する情報処理装置との対応を示す第一の車両情報を保持する記憶部をさらに備え、前記車両選出部は、前記第一車両において発生した異常に関連したフレームと種類が同じフレームを送信する情報処理装置を備える車両を、前記第一の車両情報を参照して前記複数台の車両から特定し、特定した前記車両を前記異常関連車両として選出してもよい。

上述のように、同種のＥＣＵは共通の問題を抱えている可能性が高い。つまり、ある一台の車両が備えるＥＣＵから不正なフレームが送信されている（異常が発生している）場合、同種のＥＣＵを備える他の車両の車載ネットワークでも同様の不正なフレームが送信されている可能性は、同種のＥＣＵを備えない車両よりも高い。このような車両を異常関連車両として扱って、分析のためのデータを送信させることで、効率よく異常の発生を検知し、迅速な対処が可能になる。

例えば、前記記憶部は、前記車載ネットワークにおいて送受信されるフレームの種類を示すメッセージＩＤの車種間の対応を示す第二の車両情報をさらに保持し、前記車両選出部は、前記第二の車両情報を参照して、前記第一車両とは異なる車種が備える車載ネットワークで送受信されるフレームのメッセージＩＤであって、前記第一車両において発生した異常に関連したフレームのメッセージＩＤに対応するメッセージＩＤを特定し、特定した前記メッセージＩＤが示す種類のフレームを送信する情報処理装置を備える車両を、前記第一の車両情報を参照して前記複数台の車両から特定し、特定した前記車両を前記異常関連車両として選出してもよい。

サイバー攻撃には、例えば車両の加速の制御に関するデータを含むフレームなど、特定の種類のフレームを標的として行われるものが想定され得る。しかしながら、フレームの種類を示すＩＤは、一部を除いて各車両のシステム設計者が任意に設定可能であり、車種間で共通とは限らない。上記の構成により、異常が検出されたフレームと同種のフレームについて、車種間でのＩＤの差異を越えて、効率よく異常の発生を検知し、迅速な対処が可能になる。

例えば、前記第一リクエストの送信先の候補である車両を識別する車両ＩＤの車種別のリストである車両ＩＤリストを保持する記憶部をさらに備え、前記車両選出部は、前記車両ＩＤリストを用いて前記異常関連車両を選出してもよい。また例えば、前記車両ＩＤリストは、前記第一リクエストの送信先の候補である前記車両に関連する地域に応じた前記車両ＩＤの区分を示し、前記車両選出部は、前記車両ＩＤリストが示す地域に基づいて前記異常関連車両を選出してもよい。

これにより、検知された異常と同様の異常が発生している可能性がより高い車両から分析のためのデータを送信させることで、効率よく異常の発生を検知し、迅速な対処が可能になる。車種の目安になる型番が共通でも製造地（又は製造工場）又は仕向地によって搭載するＥＣＵの仕様が異なったり、複数の車種に仕様が共通のＥＣＵが採用されることもある。または、ある時間に特定の地域を走行する車両がサイバー攻撃の標的となる場合もある。したがって、これらのような地理的条件に基づく異常関連車両の選定も異常判定の効率向上に有効である。

例えば、前記車両ＩＤリストは、前記第一リクエストの送信先の候補である前記車両に関連する地域に応じた前記車両ＩＤの区分を示し、前記車両選出部は、前記車両ＩＤリストが示す地域に基づいて前記異常関連車両を選出してもよい。

異常が検出されたフレームを送信するＥＣＵと同種のＥＣＵではなくても、その異常の悪影響を受けやすい状況が想定される。例えば、異常が検出されたフレームを送信するＥＣＵと同一の機能ドメインに属するＥＣＵ、又は異常が検出されたフレームを受信して処理するＥＣＵは、その他のＥＣＵよりもこの異常の悪影響を受けやすい。このようなＥＣＵを搭載する車両を異常関連車両として扱って、分析のためのデータを送信させることで、効率よく異常の発生を検知し、迅速な対処が可能になる。

また、本発明の一態様に係る車両異常検知システムは、上記のいずれかの車両異常検知サーバと、前記車両異常検知サーバと通信する複数台の車両であって、前記車両異常検知サーバからのリクエストに応じて前記ログを前記車両異常検知サーバに送信する車両とを含む。

これにより、ある車両で検出された異常に応じて、同様の異常が発生している可能性が高いと考えられる他の車両について従来に比べて優先的な異常判定の実施が可能となる。そして、異常の発生の早期検知ができることで、対応も迅速に行われ、攻撃の当該車両への影響の深刻化、又はさらに他の車両への拡大を抑えることができる。

また、本発明の一態様に係る車両異常検知方法は、上記の車両異常検知システムで実行される車両異常検知方法であって、前記車両異常検知システムにおいて、前記複数台の車両の一である第一車両における異常の発生を示す情報を取得すると、前記複数台の車両から前記第一車両の異常に応じた異常関連車両を選出し、前記車両異常検知システムから前記異常関連車両に、前記異常関連車両が備える車載ネットワークのログの送信を要求する第一リクエストを送信し、前記車両異常検知システムが、前記第一リクエストに応じて前記異常関連車両から送信されたログが示す情報に基づいて、前記異常関連車両における異常の発生有無の判定を行う。

これにより、ある車両で検出された異常に応じて、同様の異常が発生している可能性が高いと考えられる他の車両について従来に比べて優先的な異常判定の実施が可能となる。そして、異常の発生の早期検知ができることで、対応も迅速に行われ、攻撃の当該車両への影響の深刻化、又はさらに他の車両への拡大を抑えることができる。

なお、これらの包括的又は具体的な各態様は、集積回路、コンピュータプログラム若しくはコンピュータ読み取り可能なＣＤ－ＲＯＭ等の記録媒体で実現されてもよく、又は、装置、システム、方法、集積回路、コンピュータプログラム若しくは記録媒体の任意の組み合わせで実現されてもよい。

以下、図面を参照しながら実施の形態について具体的に説明する。なお、以下で説明する実施の形態は、包括的又は具体的な例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは一例であり、本発明を限定する趣旨ではない。また、以下の実施の形態における構成要素のうち、独立請求項に記載されていない構成要素は、任意の構成要素として説明される。また、各図は模式図であり、必ずしも厳密に図示されたものではない。

（実施の形態）
［１ 車両異常検知システムの概要］
まず、実施の形態における車両異常検知システムの概要について例を用いて説明する。図１は、この車両異常検知システムのサービス体制の例を示すブロック図である。

この例における車両異常検知システムには、情報セキュリティサービスの提供を受けるユーザ（サービスユーザ）１０００の元にある複数の車両１０１０、データセンタ運営会社１１００の管理下にあるクラウドサーバ１１１０、及び上記の情報セキュリティサービスの提供を事業とするサービスプロバイダ１２００の管理下にあるサーバ１２１０が含まれる。

第一の車両及び第二の車両は車両１０１０の例であり、それぞれが車載ネットワークを備える自動車である。各車載ネットワークにはゲートウェイ１０２０が含まれる。車両１０１０を実際に運転するのは運転者Ｄ１０である。車載ネットワークで送受信されるデータは、そのログが複数の車両１０１０からクラウドサーバ１１１０に送信される（矢印１３１０）。また、クラウドサーバ１１１０から車両１０１０には、そのようなログの送信リクエストが送信される（矢印１３６０）。このように、車両１０１０の車載ネットワークは外部との通信が可能である。車載ネットワークの構成の詳細は後述する。

クラウドサーバ１１１０は、ＣＰＵ（Central Processing Unit）等のプロセッサ、ＨＤＤ（Hard Disk Drive）、ＲＡＭ（Random Access Memory）及びＲＯＭ（Read-only Memory）等の記憶装置、及びＮＩＣ（Network Interface Controller）等の通信インタフェースを各々備える複数台のコンピュータで実現される。クラウドサーバ１１１０は、複数台の車両１０１０からインターネットなどの通信ネットワークを介してログを受信し（矢印１３１０）、また、受信したログをサーバ１２１０に提供（矢印１３２０）が可能なよう保持する。

サーバ１２１０は、ＣＰＵ等のプロセッサ、ＨＤＤ、ＲＡＭ及びＲＯＭ等の記憶装置、及びＮＩＣ等の通信インタフェースを備える一台又は複数台のコンピュータで実現される。サーバ１２１０は、クラウドサーバ１１１０から取得したログを分析して異常の発生の有無を判定する。この判定の結果は、例えばサーバ１２１０を介して管理ユーザＵ１０に提示される（矢印１３４０）。また例えば、クラウドサーバ１１１０に送信されて（矢印１３５０）保管され、また、クラウドサーバ１１１０から車両１０１０に提供される（矢印１３６０）。管理ユーザＵ１０は、例えばサービスプロバイダ１２００に所属し、この車両異常検知システムの運用、車両異常検知システムによるサービスの提供状況の監視等を担当する。なお、判定の結果はサーバ１２１０から車両１０１０に直接提供されてもよい（矢印１３３０）。車両１０１０では、この結果は例えば記録媒体に記録されたり、ユーザインタフェースを通じて運転者Ｄ１０に提示されたりする。なお、異常を示す結果の場合には、この異常に応じた制御、例えば異常が発生した系統の無効化、異常の影響を受ける機能の縮退、車両１０１０の退避のための運転等のための制御が、運転者Ｄ１０の操作によって、又は車両１０１０が備えていれば自動制御システムによって実行されることもある。

ここで、データセンタ運営会社について、例を用いてさらに説明しておく。図２は、本実施の形態における車両異常検知システムの運営体制の例を示すブロック図である。データセンタ運営会社は、例えば車両１０１０を製造しているカーメーカーと、車両１０１０からの持続的なデータの収集及び保存を可能にする設備の提供及び管理をする管理会社とによって設けられ、クラウドサーバ１１１０を車両異常検知システムに提供する。

上述のようなサービス体制及び運営体制は一例であり、以下に説明する実施の形態又はその変形の実現が可能な限りは各種の変形が可能である。例えば車両１０１０に対するクラウドサーバ１１１０へのログの送信リクエストは、クラウドサーバ１１１０がサーバ１２１０から送信される指示に基づいて発せられてもよいし（矢印１３５０、１３６０）、サーバ１２１０から車両１０１０の各々に直接送信されてもよい（矢印１３３０）。また、ログを分析しての異常の発生の有無の判定もクラウドサーバ１１１０で実行されてもよく、この場合、サーバ１２１０はその判定の結果の取得及び監視要員又は車両１０１０への提示の機能のみを提供してもよい。また、この例ではクラウドサーバ１１１０とサーバ１２１０とは別主体によって提供されているが、同一主体によって提供され、共通の一台のコンピュータ、又は複数台のコンピュータで構成されるクラウドコンピューティングによって実現されてもよい。また例えば、図２に示す管理会社がサービスプロバイダ１２００と同一主体であってもよい。

以下でより具体的に説明する、本実施の形態における車両異常検知システムに含まれる車両異常検知サーバは、上記の説明においてクラウドサーバ１１１０、又はさらにサーバ１２１０が担う各機能を提供するものである。

［２ 車両異常検知システムの構成］
［２．１ 車両異常検知システムの全体構成］
図３は、本実施の形態における車両異常検知システムの全体構成の例を示す図である。車両異常検知システムは、車両異常検知サーバ８０と、車両１０１０ａ、１０１０ｂ、１０１０ｃ、１０１０ｄ、１０１０ｅ、１０１０ｆとが、通信路として機能するネットワーク８１で接続されて構成される。

ネットワーク８１は例えば３Ｇ、４Ｇ、５Ｇといったテレマティクスの実現に利用可能な通信網であり、インターネット及び携帯電話網等を含み得る。

車両異常検知サーバ８０は、機能的には図１に示すクラウドサーバ１１１０、又はさらにサーバ１２１０に相当する。

車両１０１０ａ、１０１０ｂ、１０１０ｃ、１０１０ｄ、１０１０ｅ、及び１０１０ｆは、図１に示す複数の車両１０１０に相当する。なお、以下では、これらの車両をまとめて、又は特定しない一台以上のいずれかを指して車両１０１０と呼称することがある。

車両１０１０には複数の車種が含まれる。この例では、車両１０１０ａ、１０１０ｂ、１０１０ｃ及び１０１０ｄは車種Ａ、車両１０１０ｅは車種Ｂ、１０１０ｆは車種Ｃである。車種が同一の車両は、例えば型式（車両型式）が同一であり、車両の識別情報としての車両ＩＤの一部が同一の車両である。具体例を挙げると、車種が同一の車両は、車台番号における型式の値、又は車両識別番号（ＶＩＮ：Vehicle Identification Number）における先頭からシリアル番号の前までの桁の値が同一である。

車両１０１０はそれぞれ、制御装置、センサ、アクチュエータ、ユーザインタフェース装置等の各種機器、及びこれらの各機器に接続される情報処理装置であって、車内のバス（ＣＡＮバス）を介してフレームに係る通信を行う複数のＥＣＵを含む車載ネットワークを備える。車載ネットワーク上の各ＥＣＵは、ＣＡＮのプロトコルに従って相互に通信を行う。ＣＡＮプロトコルにおけるフレームには、データフレーム、リモートフレーム、オーバーロードフレーム及びエラーフレームがある。以下では主としてデータフレームに注目して説明する。なお、ＣＡＮのプロトコルでは、データフレームは、格納するデータが表す情報に応じた種類を示すＩＤ（以下ではメッセージＩＤともいう）を格納するＩＤフィールド、データ長を示すＤＬＣ（Data Length Code）、データを格納するデータフィールド等を含むよう規定されている。

［２．２ 車載ネットワークの構成］
図４は、車両１０１０が備える車載ネットワークの構成の一例を示す図である。

車両１０１０等における車載ネットワークは、バス（ＣＡＮバス）１０～７０により接続された、複数のＥＣＵ（ＥＣＵ１００、１０１、２００、２０１、３００、３０１、３０２、４００、４０１、５００、６００、７００）及びゲートウェイ９０といった複数のノードを含む。なお、車載ネットワークには、更に多くのＥＣＵが含まれ得るが、図示は省略している。

ＥＣＵは、プロセッサ（マイクロプロセッサ）、メモリ等のデジタル回路、アナログ回路、通信回路等を含む、本実施の形態における情報処理装置の例である。メモリは、ＲＯＭ、ＲＡＭ等であり、プロセッサにより実行される制御プログラム（コンピュータプログラム）、又はさらに、この制御プログラムの実行時に参照されるデータを記憶することができる。メモリの書き込み可能な部分には、この制御プログラムの実行の中間又は最終段階で生成されるデータが保持されてもよい。ＥＣＵは、プロセッサがこの制御プログラムに従って動作することにより各種の所定の機能を提供する。なお、コンピュータプログラムは、プロセッサに対する指令を示す命令コードが、この所定の機能が達成されるよう複数個組み合わされて構成されたものである。

バス１０には、それぞれエンジン１１０、トランスミッション１１１に接続されたＥＣＵ（エンジンＥＣＵ）１００及びＥＣＵ（トランスミッションＥＣＵ）１０１を含む、モータ、燃料、電池の制御といった車両の「走る」（走行又は加速）の制御に関連する駆動系のＥＣＵが接続されている。

バス２０には、それぞれブレーキ２１０、ステアリング２１１に接続されたＥＣＵ（ブレーキＥＣＵ）２００及びＥＣＵ（ステアリングＥＣＵ）２０１を含む、車両の「曲がる」（操舵）及び「止まる」（制動）の制御に関連するシャーシ系のＥＣＵが接続されている。

バス３０には、それぞれ自動ブレーキシステム３１０、車線維持システム３１１、車車間通信システム３１２に接続されたＥＣＵ３００、ＥＣＵ３０１及びＥＣＵ３０２を含む、車間距離維持機能、衝突防止機能、エアバッグ作動等に関連する安全機能系のＥＣＵと車車間通信システム用のＥＣＵとが接続されている。

バス４０には、それぞれドア４１０、ライト４１１に接続されたＥＣＵ４００及びＥＣＵ４０１を含む、エアコン、ウインドウ、ドアミラー、方向指示器等といった装備の制御に関連するボディ系のＥＣＵが接続されている。

バス５０には、ヘッドユニット５１０に接続されたＥＣＵ５００を含む、インストルメントパネル、カーナビゲーションシステム、オーディオシステム等に関連したインフォテインメント系のＥＣＵが接続されている。なお、インストルメントパネルとヘッドユニットとの機能分担はいかなるものであってもよい。

バス６０には、ＩＴＳ（Intelligent Transport Systems）装置６１０に接続されたＥＣＵ６００を含む、ＥＴＣ（Electronic Toll Collection System）等の高度道路交通システムに対応するＥＣＵが接続されている。

バス７０には、例えばＯＢＤ２（On-Board Diagnostics 2）等といった、外部の故障診断ツール等と通信するためのインタフェースである診断ポート７１０に接続されたＥＣＵ７００が接続されている。なお、ＥＣＵ７００を除き診断ポート７１０をバス７０に接続していてもよい。

なお、上記各バスに接続されたＥＣＵに接続されている機器及びシステムは、車載ネットワークシステムの概念を説明するための例に過ぎない。これらの機器及びシステムのそれぞれは、一台又は複数台の他の機器に置き換えられ得るし、必須でないものもある。

ＥＣＵ（ＥＣＵ１００、２００等）のそれぞれは、接続されている機器（エンジン１１０、ブレーキ２１０等）又はシステムの状態若しくは動作内容を示す情報又はセンシング情報等の情報を取得し、取得した情報のデータを含むフレーム（データフレーム）を車載ネットワーク、つまりＣＡＮバスに周期的に送出している。

ゲートウェイ９０は、複数の通信路（ＣＡＮバス）を中継して通信路間でデータを転送する情報処理装置である。ゲートウェイ９０は、バス１０、バス２０、バス３０、バス４０、バス５０、バス６０及びバス７０と接続している。つまり、ゲートウェイ９０は、一のバスから受信したフレームを、所定の条件下で他のバス（つまり条件に応じて選択した転送先バス）に転送する機能を有する一種のＥＣＵである。また、ゲートウェイ９０は、車両１０１０の外部の車両異常検知サーバ８０とネットワーク８１を介して通信するための通信装置（通信回路等）を備え、例えば、各バスから受信したフレームについての情報を車両異常検知サーバ８０に送信（アップロード）する機能を有する。ゲートウェイ９０の構成については、後に詳細に説明する。

ここで、以下では特に断らない場合、車種が同一の車両は、車載ネットワークの構成が同一であるとの想定に基づいて説明する。つまり車種Ａ、Ｂ、及びＣには、図４に示す構成と同様の構成の車種もあれば、一部異なる構成の車種も含まれる。ただし、各種の機器又はシステムと接続される複数のＥＣＵがＣＡＮバスに接続されている点、ＣＡＮバス間に跨がる通信がゲートウェイによって中継される点、車載ネットワークで送受信されるフレームについての情報が車外の車両異常検知サーバに送信される点は共通である。車両異常検知サーバとの通信の機能は、例えばゲートウェイとは別のＥＣＵで実現されるＴＣＵ（Telematics Control Unit）によって提供されてもよい。また、ＥＣＵ間の通信路には、Ｅｔｈｅｒｎｅｔ、ＦｌｅｘＲａｙ（登録商標）等のＣＡＮとは異なるプロトコルに従って構築されるものが含まれてもよい。ただし、以下ではＣＡＮプロトコルに従って構築されている車載ネットワークである場合を例に説明する。

一方、以下では特に断らない場合、同一車種の複数の車両において、車載ネットワークのＣＡＮバスに流れるデータフレーム（メッセージ）の利用に関する仕様、例えばデータフレームの種類を示すメッセージＩＤ毎のデータフィールドの内容の規定等は同一であるとの想定に基づいて説明する。

なお、車種が相違する車両が同種のＥＣＵを備えることもある。同種のＥＣＵとは、構成が同一のＥＣＵであり、例えば、同じ製造事業者（ＥＣＵベンダ）による同型式のＥＣＵであり、また、主たる機能を実現するための構成が同一のＥＣＵである。ただし、異なる車種の車両に搭載される同種のＥＣＵ間では、送信するフレームのＩＤ（メッセージＩＤ）は互いに異なり得る。

［２．３ 車両異常検知サーバの構成］
図５は、車両異常検知サーバ８０の機能構成例を示すブロック図である。

車両１０１０の車載ネットワークで送受信されるフレームの異常の発生に対処するための車両異常検知サーバ８０は、上述のクラウドサーバ１１１０、又はさらにサーバ１２１０で実現され、つまり、プロセッサ、記憶装置、通信インタフェース等を備える一台又は複数台のコンピュータである。

車両異常検知サーバ８０は、通信部８１０と、認証処理部８２０と、ログ収集部８３０と、ログ分析部８４０と、セキュリティ情報生成部８５０と、ログ収集対象車両選出部８５５と、車両情報データベース（以下、ＤＢと表記）８６０と、ＥＣＵ情報ＤＢ８６５と、車両ログ格納ＤＢ８７０と、分析結果格納ＤＢ８８０と、セキュリティ情報ＤＢ８９０とを含んで構成される。認証処理部８２０、ログ収集部８３０、ログ分析部８４０、セキュリティ情報生成部８５０及びログ収集対象車両選出部８５５は、例えば、記憶装置に格納されている制御プログラムをプロセッサが実行して情報を処理することにより実現され得る機能的な構成要素である。また、車両情報ＤＢ８６０、ＥＣＵ情報ＤＢ８６５、車両ログ格納ＤＢ８７０、分析結果格納ＤＢ８８０及びセキュリティ情報ＤＢ８９０は、例えば、記憶装置に格納されている制御プログラムをプロセッサが実行して記憶装置上でデータを管理（生成、編集、保存）することで実現され得る機能的な構成要素である。これらのデータベースが実現される記憶装置は、本実施の形態における記憶部の例である。

通信部８１０は、通信インタフェース、メモリに格納された制御プログラムを実行するプロセッサ等により実現される。通信部８１０は、車両１０１０のそれぞれとネットワーク８１を介して通信することで、各車両１０１０の車載ネットワークのＣＡＮバス上に流れたフレーム（メッセージ）が含む情報、又はフレームに関する情報等を示す時系列データを含むログを受信する。フレームが含む情報とは、例えば、車載ネットワークでＣＡＮバスから受信されたフレームのＩＤ（メッセージＩＤ）、ＤＬＣが示すデータフィールドの長さ、フレーム（メッセージ）のデータフィールドに格納されているデータの内容である。また、フレームに関する情報とは、例えば同一メッセージＩＤのフレームの受信タイミング（間隔、頻度等）に関する情報である。以下、これらのような、フレームが含む情報及びフレームに関する情報であってログに表され得るものを、まとめてフレーム情報ともいう。

通信部８１０は、各車両からログを受信することで、各車両の車載ネットワークにおいて送受信されたフレームについてのこのようなフレーム情報を取得する取得部として機能する。また、通信部８１０は、セキュリティ情報生成部８５０が生成したセキュリティに関する送信用情報を送信する。送信用情報は、例えば、車両の乗員等を対象としたアラート（警告）通知のための提示用情報、車両の走行等の制御指示を示す制御情報、車両において暗号処理の適用に際して用いられる鍵の更新を指示するための制御情報、車両側でフレームに係る不正を検知するための不正検知用情報等である。また、通信部８１０は、ログ収集対象車両選出部８５５（後述）が選出したログ収集の対象車両にログの送信リクエストを送信する。このリクエストは、フレームのＩＤ、又は送信対象であるフレームに関連するＥＣＵを示すＥＣＵ ＩＤなど、対象車両に提供を求めるログに含められる情報に関する指示を含んでもよい。

認証処理部８２０は暗号処理機能を備え、車両１０１０と通信する際に、車両１０１０と車両異常検知サーバ８０との間で行う相互認証の処理を担い、暗号処理により安全な通信路を確立する。例えば認証処理部８２０は、暗号処理機能により、相互認証に基づいて、通信部８１０が受信した車両からの暗号化されたログを復号し、車両に送信するための送信用情報を暗号化し得る。また、車両異常検知サーバ８０で保持される各種ＤＢは関係者（例えば図２のカーメーカー及び管理会社）にとっての秘匿情報である場合もある。このような場合に車両異常検知サーバ８０では、各種ＤＢに情報を暗号化して保存するために、認証処理部８２０の暗号処理機能が利用される。

ログ収集部８３０は、各車両１０１０から収集したログの内容である各種情報（車載ネットワークで送受信されたフレームについてのフレーム情報等）を、車両ログ格納ＤＢ８７０に格納する。ログ収集部８３０は、各種データを車両ログ格納ＤＢ８７０へ格納する際に、各種データに所定の正規化等の処理を施してもよい。車両ログ格納ＤＢ８７０に格納されるデータ（車両ログ情報）については別図を用いて後に説明する。

ログ分析部８４０は、各車両１０１０から収集されて車両ログ格納ＤＢ８７０に格納（集積）されたログを分析することにより、車両１０１０の車載ネットワークで受信されたフレームが異常であるか否か（攻撃者によりその車載ネットワークに攻撃フレームが流されたか否か）に関連する指標である異常度を算定する。ログ分析部８４０は、集積されたログが表す、各車両から収集された複数のフレームについてのフレーム情報に対して、例えば、統計処理等を行い得る。ログ分析部８４０は、通信部８１０が取得した複数のフレームについてのフレーム情報と、通信部８１０がその複数のフレームについてのフレーム情報より後に取得した、一の車両１０１０（例えば車両１０１０ａ）の車載ネットワークにおいて受信されたフレームについてのフレーム情報とに基づいて、その一の車両１０１０の車載ネットワークにおいて受信されたそのフレームの異常度（異常の度合い）を算定する算定部として機能する。

ログ分析部８４０は、例えば、正常な車載ネットワークで送受信される各フレームについての所定モデルであって異常な車載ネットワークで送受信される各フレームとの比較に用いることのできる所定モデルを構築し、その後に取得されるログに基づいて機械学習を用いて所定モデルをより適切なものへと調整（更新）してもよい。また、ログが逐次取得される場合には、所定モデルの更新が逐次行われてもよい。これにより、未知の攻撃パターンに対してより迅速に適切な対処可能となり得る。

これらの場合に、ログ分析部８４０は、集積したログが示す複数のフレームについてのフレーム情報に加工処理（例えば多変量解析等）を適宜施して、所定モデルの学習のために供給し得る。所定モデルの学習には、教師あり学習、教師なし学習のいずれの方式を用いてもよい。例えば、各車両１０１０の車載ネットワークシステムにおいて、所定ルールに基づいてそのルールに適合しないフレーム（不正フレーム）がＣＡＮバスに流れたことを検知する不正検知機能がある場合には、不正フレームか不正でないフレームかの区別を示す情報がログに含まれてもよく、ログ分析部８４０では、その区別を示す情報に基づいて所定モデルの教師あり学習を行ってもよい。

また例えば、ログ分析部８４０では、各車両１０１０から不正フレームでないフレームについてのログを収集して、又は不正フレームか否かについて区別せずにログを収集し、収集したログに基づいて所定モデルの教師なし学習を行ってもよい。この所定モデルは、ある車両１０１０の車載ネットワークで受信されたフレームについての異常度の算定に利用される。所定モデルの内容は、フレームの異常度の算定に用いることのできるものであればよい。異常度は、例えば、フレーム情報と所定モデルとの比較、算術演算、論理演算、又は条件判断等、つまりフレーム情報と所定モデルとを用いた演算処理により算定される。ログ分析部８４０は、異常度の算定のための所定モデルとして、例えば、同一車種の各車両におけるログ情報に基づいて、正常状態において車載ネットワークで受信されるフレームについての特徴量（フレームが含むデータの内容、同一ＩＤのフレームの受信間隔又は受信頻度等の各成分を含む特徴ベクトル等）の分布を表わすように所定モデルを構築し得る。なお、所定モデルは、例えば、異常度を目的変数とし、ログが示す情報を説明変数とする場合の目的変数と説明変数との間の関係を表すモデルであってもよい。異常度は、例えば、異常なし（正常）を０（ゼロ）とし、異常ありの場合に異常の度合いに応じた正の数値をとるように定め得る。異常度は、０（例えば異常なし）と１（例えば異常あり）との２値をとるものであってもよいし、異常ありを複数段階に区別して３値以上をとるものであってもよい。または、異常度が所定閾値を超える場合に異常ありと判別するような活用も可能である。一例としては、ある車両１０１０の車載ネットワークで受信されたフレームの異常度は、そのフレームの特徴量が、既に集積されたログに基づいて定められた所定モデルが示す特徴量の分布（例えば平均値と分散で特定される正規分布）に対する標準偏差に所定係数（例えば３）を乗じて定まる閾値を境界とする範囲の内に位置するか否かで算定でき、また、所定係数を複数用いることで異常度を複数段階に算定できる。異常度を算定するための所定モデルの構築に用いられる手法としては、外れ値検出、時系列上の急激な変化を検出する変化点検出等がある。

このようにログ分析部８４０は、集積されたログ（車両ログ）が表す各車両１０１０の車載ネットワークで受信された複数のフレームについてのフレーム情報に基づいて、その複数のフレームについてのフレーム情報の受信より後に、ある車両１０１０の車載ネットワークにおいて受信されたフレームについてのフレーム情報の異常度を算定する。ある車両１０１０の車載ネットワークにおいて受信されたフレームについてのフレーム情報もその車両１０１０のログから得ることができる。そしてログ分析部８４０で算定された異常度は、セキュリティ情報生成部８５０で生成する送信用情報の内容の決定、送信用情報の送信先の車両１０１０の範囲の決定、送信用情報の送信タイミング（時期）の決定等のために用いられる。ある車両１０１０の車載ネットワークで受信されたフレームについて算定した異常度により異常ありと判定した場合（つまり攻撃フレームを検知した場合）に、ログ分析部８４０は、セキュリティ情報生成部８５０に、その車両及び一定条件下で他の車両１０１０へと送信用情報の送信（警告の通知等）を行わせる。また、ログ分析部８４０は、集積したログ情報に基づく統計処理、所定モデルの更新（学習）、ある車両１０１０の車載ネットワークで受信されたフレームの異常度の算定等の各種分析処理を行う。そしてログ分析部８４０は、その分析処理の結果（例えば更新後の所定モデルを表わす情報、算定した異常度に関する情報等）を、分析結果格納ＤＢ８８０に格納して保存し、次回の分析処理（フレームの異常度の算定等）に利用する。

セキュリティ情報生成部８５０は、車両情報ＤＢ８６０が保持する車両情報（図７参照）と、セキュリティ情報ＤＢ８９０に格納された攻撃フェーズ情報（図９参照）及びアラートレベル情報とを参照して、ログ分析部８４０で算定された、ある車両１０１０の車載ネットワークで受信されたフレームについての異常度に応じて、セキュリティに関する送信用情報の内容を決定し、送信用情報の送信先の車両の範囲（例えば、同一車種の車両に所定の送信用情報を送信するか否か）を決定し、送信用情報の送信時期を決定する。これらの決定については図７及び図８を用いて後述する。これらの決定に従ってセキュリティ情報生成部８５０は、送信用情報の送信の制御を行う、つまり通信部８１０に送信先の車両１０１０へと送信用情報を送信させる。

上述のような統計処理、多変量解析、又は機械学習等を適用する手法では、予め定めたルールに照らす手法では異常と判定されない現象、例えば攻撃予兆、未知の攻撃パターンに係る攻撃フレームの発生等が多段階の異常度によって表され、この多段階の異常度に応じたより柔軟で適切な対処が可能となる。

［２．４ 車両ログ情報］
図６は、車両異常検知サーバ８０が備える車両ログ格納ＤＢ８７０に格納される車両ログ情報のデータ構成の一例を示す図である。図６に示すように車両ログ情報は、各カーメーカーが製造する車両について、車種と、車種毎に車両を識別するための車両ＩＤと、車両に搭載される各ＥＣＵを識別するためのＩＤと、その各ＥＣＵが送信するフレームについてのフレーム情報であるログ（図ではＣＡＮログと表記）との関連付けを表わす。この車両ログ情報は、車両異常検知サーバ８０が各車両１０１０から取得したログを集積することで生成されている。ここでＣＡＮログは、例えばＣＡＮのフレームの識別情報（ＩＤ（メッセージＩＤ））、フレームのＤＬＣが示すデータ長、フレームのデータフィールドの内容等のフレームに含まれる情報、及びフレームの送信周期（受信周期）等のフレームに関する情報を示すデータであり、各車両１０１０から受信したログに基づく。なお、ＣＡＮログが示す情報は、ログが示す上記の情報に基づく、ＣＡＮのフレームについての特徴量（例えば特徴ベクトル等）を正規化したものであってもよい。

ログ分析部８４０は、この車両ログ情報の分析によって、各車両１０１０の車載ネットワークで受信されたフレームについての異常度の算定等を行うことで各車両１０１０における異常の発生の有無の判定を行う。

［２．５ 車両情報ＤＢ］
図７は、車両異常検知サーバ８０が備える車両情報ＤＢ８６０のデータ構成の一例を示す図である。図７に示すように車両情報は、車種毎に、その車種の車両が搭載しているＥＣＵを識別するためのＩＤ（例えばＥＣＵの種別を識別するための型式等）と、そのＥＣＵが送信するフレームの種類を識別するためのＩＤ（ＣＡＮのメッセージＩＤ）との対応を示す。車両情報は、車種毎にその車種の車両に搭載される全てのＥＣＵのＩＤと、その各ＥＣＵが送信するフレームに係るＣＡＮのメッセージＩＤとを含むが、説明の便宜上、図７では一部のＥＣＵのＩＤ及びそのＥＣＵが送信する一部のフレームのＩＤしか示していない。

図７の例における車両情報テーブル８６１は、車種Ａの各車両について、ＩＤ「００１」のＥＣＵ及びＩＤ「００２」のＥＣＵを備えること、並びにＩＤ「００１」のＥＣＵはメッセージＩＤ「１００」のフレームとメッセージＩＤ「１０１」のフレームとを送信すること及びＩＤ「００２」のＥＣＵはＣＡＮのメッセージＩＤ「２００」のフレームを送信することを示す。また、車両情報テーブル８６１はさらに、車種Ｂの各車両について、ＩＤ「００１」のＥＣＵ及びＩＤ「００３」のＥＣＵを備えること、並びにＩＤ「００１」のＥＣＵはメッセージＩＤ「１１０」のフレームとメッセージＩＤ「１１１」のフレームとを送信すること及びＩＤ「００３」のＥＣＵはＣＡＮのメッセージＩＤ「３０１」のフレームを送信することを示す。なお、ＥＣＵのＩＤが共通であっても、異なる車種の車両に搭載されているものは同種のＥＣＵであるとは限らない。この場合、異なる車種間のＥＣＵ ＩＤの関連は、ＥＣＵ情報ＤＢ８６５を参照することにより取得される。また、例えば事前にＥＣＵ情報ＤＢ８６５を参照して、各車種で用いられるＥＣＵ ＩＤを車両異常検知サーバ８０で用いる統一ＥＣＵ ＩＤに変換してから処理することにより、図７に示す車両情報ＤＢでは同じＥＣＵ ＩＤのＥＣＵは車種が異なっても同種（同一種別）のＥＣＵとして扱えるようにしてもよい。

車両情報テーブル８６１及びＥＣＵ情報ＤＢ８６５を参照することで、ログ収集対象車両選出部８５５は、特定のＥＣＵを搭載する車種を選出することができる。また、車両情報テーブル８６１を参照することで、セキュリティ情報生成部８５０は、異常度に応じた一定条件下で、ある車両で異常なフレームを送信したＥＣＵと同種のＥＣＵを搭載する車種の車両を、セキュリティに関する送信用情報の送信先に含ませることができる。

図８は、車両異常検知サーバ８０の車両情報ＤＢにさらに含まれる、車種別情報のデータ構成の一例を示す図である。図８に示すように、車種別情報は各カーメーカーの各車種についての、異常検知の対象となり得る車両の車両ＩＤを地域別に示す情報である。なお、地域とは、例えば対象車両の登録地域、通信の結果最後に車両の所在が確認された地域、製造場所（製造工場）、仕向地である。車種別情報は本実施の形態における車両ＩＤリストの例である。

［２．６ 攻撃フェーズ情報］
図９は、セキュリティ情報ＤＢ８９０が保持する攻撃フェーズ情報の一例を示す。攻撃フェーズ情報は、攻撃フレームの送信による車両への攻撃を複数段階（ここでは４つの攻撃フェーズ）に区別し、各攻撃フェーズについてアラートレベルを対応付けた情報である。図９の例では、攻撃フェーズ情報は、攻撃フェーズ及びその攻撃フェーズの攻撃が検知された数（検知数）Ｎの組み合わせと、５段階の各アラートレベルとを対応付けている。この検知数は、累積的な検知数であってもよいし、一定の単位期間における検知数であってもよい。アラートレベルは、セキュリティ上の重要度を示し、ログ収集対象車両選出部８５５がログ収集対象車両を選出する際に用いられる。また、車両異常検知サーバ８０が車両に送信する、セキュリティに関する送信用情報に係る送信態様を区別するために用いられる指標でもある。

この例では、攻撃フェーズは攻撃予兆と攻撃とに大別されている。４つの攻撃フェーズのうち、深刻度の低い方から３つのフェーズ１～３が攻撃予兆の攻撃フェーズである。また、最も深刻度の高いフェーズ４が攻撃の攻撃フェーズである。なお、攻撃は深刻度が最も低いフェーズ１から順に実行されることが多いと予想されるが、必ずしもこの順に実行されるとは限らない。

以下、攻撃フェーズ毎に、想定される攻撃予兆又は攻撃の手法、攻撃フェーズの判別手法の例、及びアラートレベルについて説明する。

［２．６．１ フェーズ１］
一般に車載ネットワークで用いられるＣＡＮのフレーム（メッセージ）に係る仕様（例えばメッセージＩＤ毎のフレームの内容、用途等）は非公開である。このため、攻撃者は、まず攻撃の準備として、１台の車両に対して、診断ポート（例えば図４の診断ポート７１０）を介して、様々なＣＡＮのフレーム（メッセージ）を車載ネットワークに不正に注入し、車両の挙動を確認しながらＣＡＮのフレームに係る仕様を解析する。この解析行為は、所望の攻撃メッセージのＣＡＮのフレームに係る仕様のうち、少なくとも攻撃に利用する部分が解明するまで、トライアルアンドエラーを繰り返すことで行われる。また、ＣＡＮのフレームに係る仕様の解析とは別にＣＡＮバスに攻撃フレームを送り込むための、車載ネットワークの脆弱性を探す。攻撃フェーズ情報では、この攻撃の準備の段階を、攻撃予兆のフェーズ１と定めている。

セキュリティ情報生成部８５０は、例えば、異常の発生を示す異常度が算定されたフレームのメッセージＩＤが、車載ネットワークの正常状態において車載ネットワークに接続された各ＥＣＵが送信すると規定されているメッセージＩＤ以外のメッセージＩＤであった場合、又は、そのフレームの受信間隔（送信間隔）が正規のフレームのものと異なる場合等において、攻撃予兆のフェーズ１であると判別し得る。また、セキュリティ情報生成部８５０は、例えば、異常の発生を示す異常度が算定されたフレームのメッセージＩＤが、診断コマンドであることを示すメッセージＩＤであって、フェーズ１より（深刻度が）高いフェーズに該当しないＩＤである場合に、攻撃予兆のフェーズ１であると判別し得る。診断コマンドとは、例えば、予め診断ポートに接続される正規の診断ツールが利用するものとして規定された特定のメッセージＩＤ（診断用メッセージＩＤ）を含むフレームである。なお、攻撃予兆のフェーズ１の判別手法として、他のいかなる方法を用いてもよい。

図９に例示される攻撃フェーズ情報では、フェーズ１は、検知数と関係なくアラートレベルの「１」と対応付けられている。このため、セキュリティ情報生成部８５０は、フェーズ１と判別した場合に、アラートレベルの「１」に対応する送信態様で、送信用情報の車両への送信の制御を行う。

［２．６．２ フェーズ２］
ある車種の車両の車載ネットワークに係る機器又はＥＣＵに脆弱性が見つかれば、攻撃者は、その脆弱性を突いて例えばその機器又はＥＣＵを制御下に置くことを試みる。例えば、ヘッドユニットはアプリケーションプログラム等のソフトウェアを外部ネットワークからダウンロード可能であり、ヘッドユニットには、手当てされていない脆弱性があるとする。この場合、攻撃者は例えば、ヘッドユニット向けのマルウェア（不正動作を行う悪意のあるソフトウェア等）を偽装して公開し、ユーザに意図せずマルウェアをダウンロードさせて脆弱性を突こうとする。また、攻撃者はヘッドユニットに接続する外部機器を介して、その脆弱性を突くかもしれない。例えば、ヘッドユニットがスマートフォンと接続できるのであれば、攻撃者は、インターネット上のサイト等ににマルウェアを偽装して公開し、ユーザに意図せずスマートフォン上にダウンロードさせる。そしてユーザがスマートフォンとヘッドユニットを接続した際に、スマートフォン上のマルウェアからヘッドユニットの脆弱性を突くかもしれない。そして攻撃者は、ヘッドユニットの脆弱性を突いて、ＣＡＮバスに不正アクセスするための攻撃基盤を構築するために、マルウェアにより、ヘッドユニットにおけるソフトウェア（ファームウェア等）を不正に書き換えてヘッドユニットを制御下に置くと考えられる。攻撃フェーズ情報では、この攻撃の準備の段階を、攻撃予兆のフェーズ２と定めている。また、Ｖ２Ｘ（車車間通信（Ｖ２Ｖ：Vehicle to Vehicle）及び路車間通信（Ｖ２Ｉ：Vehicle to Infrastructure））用のＥＣＵ（図４の例ではＥＣＵ３０２）のような外部ネットワークと直接接続するＥＣＵに脆弱性があれば、攻撃者は、ヘッドユニット等を介さずに、そのＥＣＵを乗っ取って不正にそのＥＣＵのソフトウェアを書き換えるかもしれない。これらのＣＡＮバスに不正にアクセスできる状態にする行為の段階も、攻撃予兆のフェーズ２に該当する。即ち、ＥＣＵのソフトウェア（ファームウェア等）を不正に書き換える処理を行う段階を、攻撃予兆のフェーズ２としている。

セキュリティ情報生成部８５０は、例えば、異常発生を示す異常度が算定されたフレームのメッセージＩＤが、ＥＣＵのファームウェア更新用のフレームのＩＤとして規定されているメッセージＩＤであった場合等において、攻撃予兆のフェーズ２であると判別し得る。なお、攻撃予兆のフェーズ２の判別手法として、他のいかなる方法を用いてもよい。例えば、ファームウェア更新用のフレームが適切な更新時期でないのにＣＡＮバスに流れたことを確認する方法を用いてもよい。

図９に例示される攻撃フェーズ情報では、フェーズ２は、検知数が１の場合にアラートレベルの「２」と、検知数が１を超える場合にアラートレベルの「３」と対応付けられている。このため、セキュリティ情報生成部８５０は、フェーズ２と判別した場合においてそのフェーズ２が検知された数が１であればアラートレベルの「２」に対応する送信態様で、フェーズ２が検知された数が複数であればアラートレベルの「３」に対応する送信態様で、送信用情報の車両への送信の制御を行う。

［２．６．３ フェーズ３］
攻撃予兆のフェーズ２でマルウェアがＥＣＵのソフトウェアを不正に書き換える等により、ある特定車種の車両の車載ネットワークに攻撃基盤が構築された後において、マルウェアは、マルウェア自身が現在アクセスしている車両の車種等の情報を確認するために、診断コマンド等をＣＡＮバスに送信することで、車両ＩＤ、ＥＣＵ情報（ＥＣＵ ＩＤ、ＥＣＵの名称等）等を取得しようとする。攻撃フェーズ情報では、この段階を、攻撃予兆のフェーズ３と定めている。

セキュリティ情報生成部８５０は、例えば、異常の発生を示す異常度が算定されたフレームのメッセージＩＤが、車両ＩＤ、ＥＣＵ情報等の取得のための診断コマンドのメッセージＩＤである場合に、攻撃予兆のフェーズ３であると判別し得る。なお、攻撃予兆のフェーズ３の判別手法として、他のいかなる方法を用いてもよい。

図９に例示される攻撃フェーズ情報では、フェーズ３は、検知数が１の場合にアラートレベルの「３」と、検知数が１を超える場合にアラートレベルの「４」と対応付けられている。このため、セキュリティ情報生成部８５０は、フェーズ３と判別した場合においてそのフェーズ３が検知された数が１であればアラートレベルの「３」に対応する送信態様で、フェーズ３が検知された数が複数であればアラートレベルの「４」に対応する送信態様で、送信用情報の車両への送信の制御を行う。

［２．６．４ フェーズ４］
攻撃予兆のフェーズ３でマルウェアが車種等の情報を取得した後において、マルウェアが攻撃者の不正サーバにアクセスし、不正サーバから、該当車種に対応するＣＡＮの攻撃用のフレームの送信手順等を示すＣＡＮ攻撃セットを受信する。ＣＡＮ攻撃セットは、例えば、車種毎の車両の車載ネットワークに対して車両の走行等を不正に制御するためのフレーム群の内容及び送信順序等を示すように攻撃者が準備したものである。マルウェアは、ＣＡＮ攻撃セットに基づいて、ＣＡＮバスに攻撃フレームを送信することで、攻撃を遂行し、車両を不正制御する。攻撃フェーズ情報では、この段階を、攻撃のフェーズ４と定めている。

セキュリティ情報生成部８５０は、例えば、異常の発生を示す異常度が算定されたフレームのメッセージＩＤが、そのフレームが受信された車両において重要な制御用のフレームのＩＤとして規定されている複数のメッセージＩＤのいずれかに該当する場合に、攻撃のフェーズ４であると判別し得る。重要な制御用のフレームは、重要性に鑑みて任意に規定可能であるが、例えば走行に関連するフレームである。ここでいう走行に関連するフレームとは、例えば、「走る」、「曲がる」、「止まる」等の車両の走行及び挙動の制御に関連する駆動系及びシャーシ系のＥＣＵ（例えばエンジンＥＣＵ、トランスミッションＥＣＵ、ブレーキＥＣＵ、ステアリングＥＣＵ等）により送信されることが規定されているフレームである。なお、攻撃のフェーズ４の判別手法として、他のいかなる方法を用いてもよい。例えば、車両内のアクチュエータの制御指示を示すフレームの内容と、アクチュエータの作用を反映した車両の状態を示すフレームの内容とを比較することで、攻撃がなされているか否かを判別する方法を用いてもよい。

図９に例示される攻撃フェーズ情報では、フェーズ４は、検知数が１の場合にアラートレベルの「４」と、検知数が１を超える場合にアラートレベルの「５」と対応付けられている。このため、セキュリティ情報生成部８５０は、フェーズ４と判別した場合においてそのフェーズ４が検知された数が１であればアラートレベルの「４」に対応する送信態様で、フェーズ４が検知された数が複数であればアラートレベルの「５」に対応する送信態様で、送信用情報の車両への送信の制御を行う。

［２．７ ＥＣＵ情報ＤＢ］
図１０は、車両異常検知サーバ８０備えるＥＣＵ情報ＤＢ８６５に含まれるＥＣＵ ＩＤ変換テーブルのデータ構成の一例を示す図である。同一種類のＥＣＵであっても、カーメーカーや車種によってＥＣＵを識別するためのＥＣＵ ＩＤが異なっていることがある。図１０に示すＥＣＵ ＩＤ変換テーブルは、ある車種のＥＣＵ ＩＤを他の車種のＥＣＵ ＩＤに変換するためのテーブルである。図１０のＥＣＵ ＩＤ変換テーブルでは、各行が同じ種類のＥＣＵであることを示す。例えば、図１０のＥＣＵ ＩＤ変換テーブルによると、車種ＡにおいてＥＣＵ ＩＤ「００１」で識別されるＥＣＵは、車種ＢにおいてもＥＣＵ ＩＤ「００１」で識別され、車種Ｃ、車種Ｄにおいては種類が同一のＥＣＵが搭載されていないことが分かる。また、車種ＡにおいてＥＣＵ ＩＤ「００２」で識別されるＥＣＵは、車種ＢにおいてはＥＣＵ ＩＤ「１０４」で識別されるＥＣＵであり、車種ＣではＥＣＵ ＩＤ「０１２」で識別されるＥＣＵであり、車種Ｄには非搭載であることが分かる。ログ収集対象車両選出部８５５は、ある種類のＥＣＵを搭載する車種を選出する際にこのＥＣＵ ＩＤ変換テーブルを参照することで、車種間で異なるＩＤで識別される同種のＥＣＵを搭載する車種を漏れなく選出することができる。同種のＥＣＵは、複数の車種の車両に搭載され得る。相違する車種の各車両に搭載された、同種のＥＣＵそれぞれが送信するフレームは、フレームのメッセージＩＤが相違し得るだけで、フレームのその他の内容（ＤＬＣが示すデータ長、データフィールドのデータ等）、フレームの送信周期等は共通である。

また、ＥＣＵ情報ＤＢ８６５には、図１１にデータ構成の一例を示すメッセージＩＤ変換テーブルが含まれてもよい。データフィールドのデータが示す情報に応じたフレームの種類が共通であっても、カーメーカーや車種によってこのフレームの種類を識別するためのメッセージＩＤが異なっていることがある。図１１に示すメッセージＩＤ変換テーブルは、ある車種のメッセージＩＤを他の車種のメッセージＩＤに変換するためのテーブルである。図１１のメッセージＩＤ変換テーブルでは、各行が同じ種類のフレームであることを示す。例えば、図１１のメッセージＩＤ変換テーブルによると、車種ＡにおいてメッセージＩＤ「０００」で識別されるフレームは、車種Ｂ、車種Ｃ、車種ＤのいずれにおいてもメッセージＩＤ「０００」で識別されることが分かる。また、車種ＡにおいてメッセージＩＤ「００１」で識別されるＥＣＵは、車種ＢにおいてはメッセージＩＤ「０１０」で識別されるフレームであり、車種ＣではメッセージＩＤ「００２」で識別されるフレームであり、車種ＤではメッセージＩＤ「００５」で識別されるフレームであることが分かる。ログ収集対象車両選出部８５５は、ある種類のフレームを送信するＥＣＵを搭載する車種を選出する際にこのメッセージＩＤ変換テーブルを参照することで、車種間で異なるＩＤで識別される同種のフレームを送信するＥＣＵを搭載する車種を漏れなく選出することができる。図１１は、本実施の形態における第二の車両情報の例である。

また、ＥＣＵ情報ＤＢ８６５は、図１２に例示する車種別メッセージＩＤ－ＥＣＵ関連付けテーブルを含んでもよい。ある車種のあるフレーム情報から算出された異常度が一定のレベルを超えるため、異常が発生していると判定された場合、この車種別メッセージＩＤ－ＥＣＵ関連付けテーブルを用いることにより当該フレームのメッセージＩＤから関連するＥＣＵのＥＣＵ ＩＤを取得することができる。例えば図１２に示す種別メッセージＩＤ－ＥＣＵ関連付けテーブルによれば、車種Ａのあるフレームのフレーム情報の異常度が高い場合に、当該フレームのメッセージＩＤ（図中で見出し「Ｍｓｇ．ＩＤ」の右欄）が「００１」であったときは、当該フレームに関連している、すなわち異常に関連していると推定されるＥＣＵはＥＣＵ ＩＤ「００２」のＥＣＵとＥＣＵ ＩＤ「００４」のＥＣＵである。ここで関連するＥＣＵとは、例えば当該メッセージＩＤのフレームを送信又は受信するＥＣＵであってもよい。車種別メッセージＩＤ－ＥＣＵ関連付けテーブルは、本実施の形態における、第一の車両情報の例である。

また、ＥＣＵ情報ＤＢ８６５は、図１３に例示する車種別ＥＣＵ関連付けテーブルを含んでもよい。ある車種のあるフレームに関する情報から算出された異常度が一定のレベルを超えるため、異常が発生していると判定された場合、この車種別ＥＣＵ関連付けテーブルを用いることにより当該フレームを送信したＥＣＵに関連するＥＣＵのＥＣＵ ＩＤを取得することができる。例えば図１３に示す車種別ＥＣＵ関連付けテーブルによれば、車種ＡのＥＣＵ ＩＤ「００１」に関連するＥＣＵのＥＣＵ ＩＤは、ＥＣＵ ＩＤ「００２」及び「００４」である。ここで関連するＥＣＵとは、当該フレームの送信先であったり、当該ＥＣＵとフレームの送受信を行うＥＣＵであったり、共通の機能を実現するためのＥＣＵであってもよい。車種別ＥＣＵ関連付けテーブルは、本実施の形態における関連情報処理装置情報の例である。

［２．８ ゲートウェイの構成］
図１４は、車両１０１０の車載ネットワークにおけるゲートウェイ９０の機能構成例を示すブロック図である。同図に示すように、ゲートウェイ９０は、フレーム送受信部９０１と、フレーム解釈部９０２と、不正フレーム検知部９０３と、ルール保持部９０４と、フレーム生成部９０５と、転送制御部９０６と、転送ルール保持部９０７と、鍵処理部９２０と、鍵保持部９２１と、フレームアップロード部９５０と、不正検知通知部９３０と、更新処理部９４０とを機能的構成要素として含む。これらの各構成要素は、例えばゲートウェイ９０における通信回路、メモリに格納された制御プログラムを実行するプロセッサ又はデジタル回路等により実現される。例えば、フレームアップロード部９５０及び更新処理部９４０は、車両異常検知サーバ８０と通信するための通信回路等により実現される。

フレーム送受信部９０１は、バス１０、バス２０、バス３０、バス４０、バス５０、バス６０、及びバス７０のそれぞれに対して、ＣＡＮプロトコルに従ったフレームを送受信する。フレーム送受信部９０１は、バスからフレームを１ｂｉｔずつ受信し、フレーム解釈部９０２に通知する。また、フレーム生成部９０５より通知を受けた転送先のバスを示すバス情報及び送信用のフレームに基づいて、そのフレームの内容を、バス１０、バス２０、バス３０、バス４０、バス５０、バス６０、及びバス７０のうち転送先のバスに、１ｂｉｔずつ送信する。

フレーム解釈部９０２は、フレーム送受信部９０１よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。フレーム解釈部９０２は、受信されたフレームの各フィールドの情報を不正フレーム検知部９０３へ通知する。なお、フレーム解釈部９０２は、受け取ったフレームがＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部９０５へ通知する。また、フレーム解釈部９０２は、他のＥＣＵが送信したエラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームであると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。

不正フレーム検知部９０３は、ルール保持部９０４が保持する、不正フレームか否かの判定用（不正フレームの検知用）のルール又はアルゴリズム（例えば不正検知用プログラム等）を示す情報（不正検知用情報）を参照し、受信されたフレームが不正フレームか否かを判定する。不正フレームの検知用のルール又はアルゴリズムを示す情報の一例としては、受信が許可されるＣＡＮのフレーム（メッセージ）の条件（特定のための情報）を列挙したホワイトリスト、受信が許可されない条件を列挙したブラックリスト等が挙げられる。不正フレームは、不正フレームの検知用のルールに適合しないフレームである。不正フレームと判定した場合には、不正フレーム検知部９０３は、不正フレームが送信されている途中において、不正フレームが送信されているバスに、エラーフレームを送信することで不正フレームを無効化するよう制御する。つまり不正フレームが検知された場合に、不正フレーム検知部９０３は、フレーム送受信部９０１にエラーフレームを送信させることで、不正フレームを無効化する。また、不正フレーム検知部９０３は、不正フレームか否かの判定結果を、フレーム解釈部９０２へ通知する。不正フレーム検知部９０３で不正フレームと判定されなかった場合にフレーム解釈部９０２は、そのフレームの各フィールドの情報を転送制御部９０６に通知する。また、不正フレーム検知部９０３は、不正フレームと判定した場合（不正フレームを検知した場合）にその不正フレームについての情報（例えば、不正検知の旨を示す情報、又は、不正検知の旨及び不正フレームの内容を示す情報）を不正検知通知部９３０に通知する。なお、不正フレーム検知部９０３は、不正フレームと判定した場合に不正フレームの内容を示す情報を十分に取得するために、不正フレームを無効化するエラーフレームの送信を、不正フレームの特定部分（例えばデータフィールド）が受信されるまで待ってから速やかに行うこととしてもよい。

転送制御部９０６は、転送ルール保持部９０７が保持する転送ルール情報に従って、受信したフレームのＩＤ（メッセージＩＤ）、及び転送元バス（つまりそのフレームを受信したバス）に応じて転送先のバスを選択し、転送先のバスを示すバス情報と、転送されるべきフレームの内容（例えばフレーム解釈部９０２より通知されたメッセージＩＤ、ＤＬＣ（データ長）、データ（データフィールドの内容）等）をフレーム生成部９０５へ通知して、送信を要求する。

転送ルール保持部９０７は、バス毎のフレームの転送についてのルールを示す転送ルール情報を保持する。転送ルール情報は、転送元となり得る各バスについて、そのバスで受信された転送すべきフレームのメッセージＩＤと転送先のバスとを示す。また転送ルール情報は、各バスが、フレーム内容を暗号化すると規定されたバスか否か、及び、フレームにＭＡＣが付与されると規定されたバス（ＭＡＣ対応ＥＣＵが接続されたバス）か否かを示す情報を含む。この情報を参照することで転送制御部９０６は、フレームの転送に際して、暗号化及びＭＡＣの付与のそれぞれに関する処理を行う。例えば、転送制御部９０６は、転送先がＭＡＣに対応している場合は、鍵保持部９２１が保持しているＭＡＣ鍵を用いて鍵処理部９２０にＭＡＣを生成させ、フレームにＭＡＣを付与して転送するように制御する。また、転送制御部９０６は、転送元が暗号化に対応している場合は、鍵保持部９２１が保持している、転送元のバスに接続された各ＥＣＵと共有している暗号鍵を用いて、鍵処理部９２０にフレームの内容を復号させる。そして、転送先が暗号化に対応している場合は、転送制御部９０６は、鍵保持部９２１が保持している、転送先のバスに接続された各ＥＣＵと共有している暗号鍵を用いて、鍵処理部９２０にフレームの内容を暗号化させて転送するよう制御する。鍵処理部９２０では、フレームの内容の暗号化、及びフレームの内容等に基づくＭＡＣの生成のそれぞれについて、いかなる方式を用いてもよい。ＭＡＣは、例えばフレームのデータフィールド内の一部の値に基づいて生成されてもよいし、その値と、他のフィールドの値又はその他の情報（例えばフレームの受信回数をカウントするカウンタ値等）を結合したものに基づいて生成されてもよい。ＭＡＣの計算方法としては、例えばＨＭＡＣ（Hash-based Message Authentication Code）、ＣＢＣ－ＭＡＣ（Cipher Block Chaining Message Authentication Code）等を用いることができる。

フレーム生成部９０５は、転送制御部９０６からの送信の要求に従い、転送制御部９０６より通知されたフレームの内容を用いて送信用のフレームを構成し、その送信用のフレーム及びバス情報（例えば転送先のバスの識別子等）をフレーム送受信部９０１へ通知する。

不正検知通知部９３０は、不正フレーム検知部９０３が不正フレームを検知した場合に不正検知の旨を運転者等に通知するために、不正フレームについての情報（例えば、不正検知の旨を示す情報、又は、不正検知の旨及び不正フレームの内容を示す情報）をヘッドユニットに通知する制御（フレーム送受信部９０１の制御等）を行う。また、不正検知通知部９３０は、不正フレーム検知部９０３が不正フレームを検知した場合に、例えば、不正検知の旨を示す情報と、その不正フレームについての情報とを含ませたログ情報等を、車両異常検知サーバ８０に通知する制御を行ってもよい。この不正検知の旨により不正フレームを不正でないフレームと区別するログ情報は、例えば、車両異常検知サーバ８０において教師あり学習に用いられ得る。また、不正検知の旨を示す情報は、車両異常検知サーバ８０によって例えば各種通知（例えばカーメーカー、ＥＣＵベンダ等といった各種の送信先への送信等）のためにも利用され得る。

更新処理部９４０は、ルール保持部９０４が保持している不正フレームの検知用のルール又はアルゴリズムを示す情報（ホワイトリスト、ブラックリスト等）を、車両異常検知サーバ８０から取得される情報に基づいて更新する。

フレームアップロード部９５０は、フレーム送受信部９０１によりいずれかのバスから受信されたフレームを逐次取得し、受信されたフレームについてのフレーム情報（例えばフレームの内容、受信間隔、受信頻度等）を示すログをログ送信判定部９６０による判定に基づき車両異常検知サーバ８０に送信（アップロード）する。フレームアップロード部９５０は、ログに、ゲートウェイ９０を搭載している車両の識別情報（車両ＩＤ）を含める。また、フレームアップロード部９５０は、ログに、その他の各種情報（例えば車両状態情報、車両の位置の情報等）を含めてもよい。フレームアップロード部９５０は、受信されたフレームについての情報として、車両異常検知サーバ８０で統計処理、機械学習等を行う場合に取り扱い易いように、フレームの内容、受信間隔、受信頻度等を加工する加工処理を施してもよい。ここで、フレームの受信間隔は、例えば、そのフレームの受信時刻と、そのフレームと同一ＩＤのフレームが前回受信された時刻との差である。また、フレームの受信頻度は、例えば、一定の単位時間において、そのフレームと同一ＩＤのフレームが受信された数である。この加工処理は、例えば、フレームに関するデータの整形、データの分析（主成分分析等を含む多変量解析等）に係る処理である。加工処理は、例えば、フレームの内容、受信間隔、受信頻度等の特徴から特徴量を抽出し、正規化等を行い、特徴量の情報量の縮約を行うこと等である。特徴量の情報量の縮約は、例えば特徴量を各成分としての特徴ベクトルで表し、車両異常検知サーバ８０と連携して得た情報に基づいて、特徴ベクトルの次元数を主成分分析で削減すること等により実現される。また、フレームアップロード部９５０は、例えば車両異常検知サーバ８０とのトラフィック量を削減すべく、無条件で又は通信状況に応じて、ログを圧縮してから送信してもよいし、一部のＩＤのフレーム、例えばログ送信判定部９６０により指示されるＩＤのフレームだけについてのフレーム情報をログに含めてもよい。

ログ送信判定部９６０は、車両異常検知サーバ８０からの送信リクエストに基づき、車両異常検知サーバ８０にログを送信するかどうかを決定する。車両異常検知サーバ８０からの送信リクエストを受けた場合、一定の期間、フレーム送受信部９０１がバスからフレームを受信する毎に、そのフレームについてのフレーム情報を含むログを車両異常検知サーバ８０に送信することとしてもよいし、複数のフレームが受信された段階でその各フレームについての情報を含むログ情報を車両異常検知サーバ８０に送信することとしてもよい。但し、バスから受信されたフレームについてのフレーム情報を、迅速に車両異常検知サーバ８０へと伝えると、そのフレームが異常であるか否かを車両異常検知サーバ８０に迅速に検知させて迅速な対処を可能にし得る。また、ログ送信判定部９６０は、フレーム送受信部９０１がバスから受信したフレームのうち全てのフレームについてのフレーム情報ではなく、車両異常検知サーバ８０からの送信リクエストで指示された１つ又は複数のＩＤのフレームだけについてのフレーム情報をログに含めるようフレームアップロード部９５０に指示してもよい。なお、送信リクエストで特定されるのは、フレームのＩＤではなく当該フレームの送受信に関連するＥＣＵ ＩＤであってもよい。この場合、ログ送信判定部９６０は、車両異常検知サーバ８０からの送信リクエストで特定されているＥＣＵ ＩＤのＥＣＵが送受信するフレームのメッセージＩＤを、ログ情報送信対象のフレームＩＤとしてフレームアップロード部９５０に通知する。

なお、車両異常検知サーバ８０から送信用情報（アラート、制御情報等）の送信がなされた場合に対応して、ゲートウェイ９０は、その送信用情報を受信し、送信用情報に従って、必要な情報をバスを介して予め定められたＥＣＵに送信する等によって、運転者又は周辺車両に対する警告の提示、車両１０１０の走行の制御、機能の縮退の制御等を実現させる。

［２．９ 車両との連携による車両異常検知サーバでの異常検知］
次に、本実施の形態における車両異常検知システムにおいて、上述のように構成される車両異常検知サーバ８０と車両１０１０との連携による異常検知までの処理について説明する。

図１５は、車両１０１０との連携による車両異常検知サーバ８０での異常検知までの処理手順の一例を示すシーケンス図である。図１５に示す例では、主として、車両１０１０の一台が、搭載する車載ネットワークで送受信されたフレームについてのフレーム情報（この例では、フレームについての情報を加工処理して得られた特徴ベクトル）を含むログを車両異常検知サーバ８０に送信し、車両異常検知サーバ８０で、フレームの異常度の算定等の処理（異常検知処理）が行われる。具体的には、車両１０１０のゲートウェイ９０が、他のＥＣＵが送信する一つのフレームを車載ネットワークのバス経由で受信する際の動作で行われる処理である。この例は車両１０１０の一台（例えば車両１０１０ａ）がログを車両異常検知サーバ８０に送信する場合を用いて説明するが、車両異常検知サーバ８０に対しては、その他の車両１０１０（車両１０１０ｂ、１０１０ｃ、１０１０ｄ、１０１０ｅ、１０１０ｆ等）も同様にログを送信する。以下、図１５に沿って説明する。

車両１０１０の車載ネットワークにおけるバス１０に接続された１つのＥＣＵ（例えばエンジンＥＣＵ１００、トランスミッションＥＣＵ１０１等）がバス１０にＣＡＮのフレームを送信し始める（ステップＳ１０１）。

車両１０１０のゲートウェイ９０では、ステップＳ１０１で送信されているフレームをバス１０から受信する（ステップＳ１０２）。

ゲートウェイ９０は、ステップＳ１０１でフレームが送信されている間において、不正フレーム検知部９０３により、ステップＳ１０２で受信したフレームが不正か否かについて、不正フレームの検知用のルール又はアルゴリズムを示す情報を参照することで、判定される（ステップＳ１０３）。ステップＳ１０３で、不正と判定した場合（ステップＳ１０３でＹＥＳ）には、ゲートウェイ９０では、ステップＳ１０１で送信され始めたフレームの送信が完了する前に、フレーム生成部９０５で生成されたエラーフレームを送信して不正フレームを無効化する（ステップＳ１０４）。なお、フレームを送信していたＥＣＵは、バス１０を介してこのエラーフレームを受信すると（ステップＳ１０５でＹＥＳ）、当該フレームの送信を中断する（ステップＳ１０６）。また、バス１０に接続された他のＥＣＵも、このエラーフレームを受信すると、ステップＳ１０１で送信され始めていたフレームの受信を中止する。

ゲートウェイ９０は、ステップＳ１０３で不正と判定しなかった場合（ステップＳ１０３でＮＯ）に、ステップＳ１０４でのエラーフレームの送信後に、車両異常検知サーバ８０から送信リクエストを受信しているかを確認する（ステップＳ１１６）。送信リクエストを受信していなかった場合（ステップＳ１１６でＮＯ）、当該車両１０１０は車両異常検知サーバ８０によりその時点での監視の対象として選択されていない。したがってゲートウェイ９０は、フレーム情報の車両異常検知サーバ８０への送信は行わずにフレーム転送処理（ステップＳ１１０）に進む。また、送信リクエストを受信していた場合（ステップＳ１１６でＹＥＳ）、ステップＳ１０２で受信したフレームの内容、受信間隔、受信頻度等に基づいて特徴量を特定（算出）する（ステップＳ１０７）。

続いてゲートウェイ９０では、フレームアップロード部９５０により、ステップＳ１０７で算出されたフレームについての特徴量に基づいて加工処理が行われる（ステップＳ１０８）。フレームアップロード部９５０は、加工処理の結果として得た、当該フレームについての特徴ベクトル（フレーム情報）を含むログを、車両異常検知サーバ８０に送信する（ステップＳ１０９）。

また、ゲートウェイ９０は、受信したフレームがステップＳ１０３で不正と判定された場合を除いて、転送制御部９０６によって、フレームの転送（転送ルール情報に基づいてフレームの転送を行う処理）が行われる（ステップＳ１１０）。図１５の例では、ステップＳ１０２で受信されたフレームが、このフレーム転送処理によりバス２０に転送され、バス２０に接続されたブレーキＥＣＵ２００又はステアリングＥＣＵ２０１が転送されたこのフレームを受信する（ステップＳ１１１）。

車両異常検知サーバ８０では、異常検知のための監視の対象となる車両を選出し（ステップＳ１１４）、選出された対象車両に対してログの送信リクエストを送信する（ステップＳ１１５）。車両の選出については図１６を用いて後述する。また、ゲートウェイ９０から、車両１０１０の車載ネットワークで送受信されたフレームについての特徴ベクトル（フレーム情報）を含むログを受信する（ステップＳ１１２）。そして、車両異常検知サーバ８０は、受信した特徴ベクトルを含むログを利用して、異常検知処理を行う（ステップＳ１１３）。異常検知処理については、図１７を用いて後述する。

［２．１０ 監視対象車両の選出処理］
図１６は、車両異常検知サーバ８０における異常検知のための監視の対象となる車両の、平常時の選出処理（図１５のステップＳ１１４）の一例を示すフローチャートである。以下、図１６に沿って車両の選出処理について説明する。

車両異常検知サーバ８０では、ログ収集対象車両選出部８５５が、車種毎に監視対象、つまり異常判定に用いるフレーム情報の送信リクエストの対象となる車両（以下、対象車両という）の選出に用いるインデックスを持ち（ステップＳ１６０１）、このインデックスを用いて車両情報ＤＢが保持する車種別情報（図８）を参照して対象車両の車両ＩＤを決定する（ステップＳ１６０２）。また、一定の時間が経過してインデックスの更新のタイミングになった場合（ステップＳ１６０３）、ログ収集対象車両選出部８５５は、インデックスを更新し（ステップＳ１６０４）、再度車種別情報を参照して対象車両の車両ＩＤを決定する（ステップＳ１６０２）。

このようにフレーム情報を送信させる車両を選出することで、監視対象の車両を標本抽出していることになり、全車両がフレーム情報を送信するよりも、ネットワーク８１の混雑、及び車両異常検知サーバ８０の過負荷の発生が抑えられる。

なお、対象車両の選出に用いられるインデックスの個数、つまりは同時期にフレーム情報を車両異常検知サーバ８０に送信させる車両１０１０の台数は、車種毎に複数存在してもよく、例えば各車種の総台数に応じた個数のインデックスが存在してもよい。また、通信トラフィックが混雑している場合には対象車を限定し、混雑していない場合には対象車を拡大するなど、混雑具合により変更されてもよい。これにより、車両異常検知システムによるネットワーク８１のトラフィックの増加が抑えられる。また、車両異常検知サーバ８０が有する計算リソースの余裕に応じて変更されてもよい。

また、インデックスの更新は上記の例のような等値の加算又は減算によって行われてもよいし、乱数等に基づいた無作為の選択によるものであってもよい。

また、車両に関連する地域を加味して、ある地域から集中的、又は複数の地域から分散的に選択してもよい。

［２．１１ 異常検知処理］
図１７は、車両異常検知サーバ８０における異常検知処理（図１５のステップＳ１１３）の一例を示すフローチャートである。以下、図１７に沿って、異常検知処理について説明する。

車両異常検知サーバ８０では、ログ分析部８４０が、各車両１０１０から送信されたログ（各車両の車載ネットワークで送受信されたフレームについてのフレーム情報の時系列データ）に基づいて、統計的異常検知処理を実行する（ステップＳ２０１）。統計的異常検知処理は、各車両１０１０から取得したログ（つまりログ収集部８３０が収集して車両ログとして車両ログ格納ＤＢ８７０に格納されたログ）を参照して、車載ネットワークで送受信されたフレームについてのフレーム情報の統計処理、多変量解析等を行うことで、異常状態との比較に用いることのできる所定モデルの構築又は機械学習による所定モデルの更新を行う処理を含む。また、統計的異常検知処理は、過去に各車両１０１０の車載ネットワークで送受信されたフレームに基づくその所定モデルと、ある車両（ここでは車両１０１０ａと想定する）から最後に取得したログが含むその車両の車載ネットワークで受信されたフレームについてのフレーム情報（特徴ベクトル等）とを用いた演算処理（比較等）により、その車両１０１０ａで受信されたフレームの異常度について算定する処理を含む。この演算処理は、例えば、外れ値検出、時系列上の急激な変化を検出する変化点検出等のための処理を含み得る。ログ分析部８４０は、これらの処理を実行してフレームの異常度を算定する。なお、車両異常検知サーバ８０で、異常度の算定の対象となるフレームは、車両１０１０ａの車載ネットワークで送受信されたフレームに限定されるものではなく、他の車両１０１０の車載ネットワークで受信されたフレームでもよい。

次に車両異常検知サーバ８０では、ログ分析部８４０によって、ステップＳ２０１の統計的異常検知処理でフレームについて算定された異常度が、予め定められた閾値より高いか否かにより、フレームが異常であるか否かの判定（異常検知）が行われる（ステップＳ２０２）。

ステップＳ２０２でフレームが異常であると判定した場合（ステップＳ２０２でＹＥＳ）には、ログ分析部８４０はさらに、異常と判定したフレームの識別情報（メッセージＩＤ）等に応じて、例えば攻撃予兆、攻撃等のどの段階の攻撃フェーズであるかを判別することにより、攻撃フェーズ情報（図９参照）を用いてアラートレベルの判定（つまり送信用情報の内容、送信時期、送信先の車両の範囲等といった送信態様の決定）を行い、決定されたアラートレベルに従った送信態様でセキュリティ情報生成部８５０から送信用情報（アラート、制御情報等）の送信を行わせる（ステップＳ２０３）。

次に車両異常検知サーバ８０では、ステップＳ２０２での判定結果又はステップＳ２０１での統計的異常検知処理での更新後の所定モデルを表す情報が分析結果格納ＤＢ８８０に格納され、車両１０１０から最後に受信したログが車両ログ格納ＤＢに格納される（ステップＳ２０４）。

また、ステップＳ２０２でフレームが異常であると判定した場合（ステップＳ２０２でＹＥＳ）には、車両異常検知サーバ８０では、ログ収集対象車両選出部８５５によって、異常と判定されたフレームの識別情報（メッセージＩＤ）等を用いて、異常検知の送信リクエストを送る追加調査対象車両が選定される（ステップＳ２０５）。追加調査対象車両の選定の処理については後述する。そして、選定された追加対象車両に対して、車両異常検知サーバ８０からログの送信リクエストが送信される（ステップＳ２０６）。追加対象車両は１ないし複数台の車両１０１０であり、各対象車両について順次ログの送信リクエストが送られる。送信リクエストに応じて各車両からフレーム情報（特徴ベクトル情報）を含むログを受信すると（ステップＳ２０７）、これらのログに対してステップＳ２０１の統計的異常検知処理が実行される。

また、ステップＳ２０２でフレームが異常でないと判定した（ステップＳ２０２でＮＯ）場合にも、車両異常検知サーバ８０では、ステップＳ２０４と同様に、ステップＳ２０２での判定結果又はステップＳ２０１での統計的異常検知処理での更新後の所定モデルを表す情報が分析結果格納ＤＢ８８０に格納され、車両１０１０から最後に受信したログが車両ログ格納ＤＢに格納される（ステップＳ２０８）。

なお、車両異常検知サーバ８０における機械学習による所定モデルの更新は、例えば、ステップＳ２０１の統計的異常検知処理内ではなく、ステップＳ２０４又はステップＳ２０８において実行されてもよい。

［２．１２ 追加調査対象車両選定処理］
図１８は、追加調査対象車両の選定の処理の手順例を示すフロー図である。

車両異常検知サーバ８０での追加調査対象の車両の選定は、ログ収集対象車両選出部８５５が車両情報ＤＢ８６０及びＥＣＵ情報ＤＢ８６５を参照して行う。この例に示す追加調査対象車両の選出には、異常が検知されたフレームのメッセージＩＤ、異常が検知されたフレームの送信元であるＥＣＵのＥＣＵ ＩＤ、異常が検知されたフレームに対応するフレームのメッセージＩＤの、３種類の情報が用いられる。

図１８のフロー図を参照すると、ログ収集対象車両選出部８５５は、メッセージＩＤによる追加調査対象の車両の探索が実施済みであるか否か判定する（ステップＳ１８０１）。メッセージＩＤによる探索が未実施である場合（ステップＳ１８０１でＮＯ）、ログ収集対象車両選出部８５５は、車種別メッセージＩＤ－ＥＣＵ関連付けテーブル（図１２参照）を用いて、異常判定されたフレームのメッセージＩＤに関連するＥＣＵ ＩＤを取得する（ステップＳ１８０４）。

メッセージＩＤによる探索が実施済みである場合（ステップＳ１８０１でＹＥＳ）又はステップＳ１８０４に続いて、ログ収集対象車両選出部８５５は、ＥＣＵとの関連による追加調査対象の車両の探索が実施済みであるか否か判定する（ステップＳ１８０２）。ＥＣＵとの関連による探索が未実施である場合（ステップＳ１８０２でＮＯ）、ログ収集対象車両選出部８５５は、車種別ＥＣＵ関連付けテーブル（図１３参照）及び車両情報テーブル８６１（図７参照）を用いて、異常と判定されたフレームを送信したＥＣＵに関連するＥＣＵ ＩＤを取得する（ステップＳ１８０４）。

ＥＣＵとの関連による探索が実施済みである場合（ステップＳ１８０２でＹＥＳ）又はステップＳ１８０５に続いて、ログ収集対象車両選出部８５５は、対応するメッセージＩＤによる追加調査対象の車両の探索が実施済みであるか否か判定する（ステップＳ１８０３）。対応するメッセージＩＤによる探索が未実施である場合（ステップＳ１８０３でＮＯ）、ログ収集対象車両選出部８５５は、対応メッセージＩＤ変換テーブル（図１１参照）及び車両情報テーブル８６１（図７参照）を用いて、異常判定されたフレームに対応するフレームを送信したＥＣＵのＥＣＵ ＩＤを取得する（ステップＳ１８０６）。

次にログ収集対象車両選出部８５５は、ＥＣＵ ＩＤ変換テーブル（図１０参照）を用いて、既に取得したＥＣＵ ＩＤのＥＣＵを備える車種の情報、及び当該ＥＣＵと対応するＥＣＵを備えるその他の車種の情報を取得する（ステップＳ１８０７）。

次にログ収集対象車両選出部８５５は、車種別情報（図８参照）を用いて、ステップＳ１８０７で取得した情報が示す各車種の地域別の車両リストを取得（ステップＳ１８０８）し、この車両リストに掲載されている車両を追加調査の対象車両として選出する（ステップＳ１８０９）。

上述のように、ログ収集対象車両選出部８５５は、検知された異常に関連するフレームに関する情報を用いて追加調査の対象車両を選出する。このようにして選出される車両１０１０は、異常が発生した車両と同様の脆弱性等を有する可能性が高い、つまり、異常と同じ異常が車載ネットワークで発生する可能性が高い。したがって、これらの車両１０１０を異常発生有無の追加調査の対象とすることで、早期で効率よく以上に対する対処を執ることが可能である。このように、ログ収集対象車両選出部８５５によって、検知された異常に関連するフレームに関する情報を用いて選出される車両１０１０は、本実施の形態における異常関連車両の例である。

なお、上記の説明では、ステップＳ１８０９で車種別情報を用いて各車種の地域別の車両リストが取得されているが、地域別に分けず全地域で一つの車種別の車両リストとして取得されてもよい。また、追加調査の対象車両は、車両リストに掲載されている全車両ではなくてもよい。対象車両は、例えば異常度の判定結果に応じて車両リストからさらに絞り込んで選出されてもよい。ここでの異常度の判定結果とは、例えばアラートレベルの判定（ステップＳ２０３）である。または、車両リストに掲載される車両の数、ネットワーク８１の混雑状況、又は車両異常検知サーバ８０の負荷の大きさに応じて変更されてもよい。

また、図１８に示すフロー図では、３種類の情報を用いられているが、これに限定されない。例えばこれらの３種類の情報の一部のみが用いられてもよいし、さらに他の情報が用いられてもよい。

［２．１３ 車両異常検知サーバによる各車両の異常監視］
次に、本実施の形態における車両異常検知システムにおける、車両異常検知サーバ８０による複数の車両の異常監視の流れを例を用いて説明する。図１９は、車両異常検知サーバ８０による車種Ａの複数の車両（車両１０１０ａ、車両１０１０ｂ、車両１０１０ｃ）の異常監視のために行われる通信の概要を示すシーケンス図である。

このシーケンス図が示す時間軸の当初においては、車両異常検知システムは平常時である、すなわち、車両異常検知サーバ８０において検知されている車両の異常はないと想定する。そして車両異常検知サーバ８０では、異常検知のための監視の対象とする対象車両が選出される（ステップＳ１９０１）。この対象車両の選出は、例えば図１６に示す車両選出処理の手順に沿って行われる。この例では、車両１０１０ａが選出され、車両異常検知サーバ８０から車両１０１０ａにログの送信リクエストが送信される（ステップＳ１９０２）。ここまでの手順は、図１５に示すステップＳ１１４及びＳ１１５に相当する。

リクエストを受信した車両１０１０ａでは、ログ送信判定のタイミングにおいてログ送信判定を行い、車両１０１０ａの車載ネットワークで送受信されていたフレームのフレーム情報、この例では特徴ベクトルをログとして車両異常検知サーバ８０に送信する（ステップＳ１９５０）。この手順は、図１５に示すステップＳ１１６及びＳ１０７からＳ１０９に相当する。

リクエストに応じて車両１０１０ａから送信されたログ（特徴ベクトル）を受信した車両異常検知サーバ８０では、特徴ベクトルが示す情報と、これまでに受信している情報に基づくモデルとから異常度を算出し、当該異常度が所定閾値を超えるか否かに基づいて異常の発生の有無を判定する異常検知処理が行われる（ステップＳ１９０３）。ここまでの手順は、図１５に示すステップＳ１１２及びＳ１１３に相当する。

この異常検知処理で異常と判定されなかった場合、対象車の更新タイミングが来るまでステップＳ１９０１、Ｓ１９０２、Ｓ１９５０、Ｓ１９０３の手順が繰り返される。この例では、上記の一連の手順の繰り返しの間、車両１０１０ａについて終始異常なしと判定されたものと想定して説明を進める。

一定の時間が経過して対象車両の更新タイミングになると、車両異常検知サーバ８０では対象車の選出が再度行われる（ステップＳ１９１１）。この例では、この回の車両選出処理の結果、車両１０１０ｂが対象車両に選ばれ、車両異常検知サーバ８０では、ステップＳ１９０１からステップ１９０３までと同様のステップＳ１９１１、Ｓ１９１２及びＳ１９１３が、車両１０１０ｂでは、車両１０１０ａで行われたステップＳ１９５０と同様のステップＳ１９６０が行われる。これにより、リクエストに応じて車両１０１０ｂから送信されたログ（特徴ベクトル）を受信した車両異常検知サーバ８０が、異常検知処理を行う。この例では、上記の一連の手順の繰り返しの間、車両１０１０ｂについて終始異常なしと判定されたものと想定して説明を進める。

さらに一定の時間が経過して対象車両の更新タイミングが再度来ると、車両異常検知サーバ８０では対象車両の選出が再度行われる（ステップＳ１９１３）。この例では、この回の車両選出処理の結果、車両１０１０ｃが対象車両に選ばれ、車両異常検知サーバ８０では、ステップＳ１９０１からステップ１９０３までと同様のステップＳ１９２１、Ｓ１９２２及びＳ１９２３が、車両１０１０ｃでは、車両１０１０ａで行われたステップＳ１９５０と同様のステップＳ１９７０が行われる。この例では、リクエストに応じて車両１０１０ｃから送信されたログを用いて車両異常検知サーバ８０が行った異常検知処理の結果、異常が発生していると判定されたと想定する。この場合、車両異常検知サーバ８０では、ステップＳ１９２１からの一連の手順が繰り返されるのではなく、追加調査対象車両選出処理が行われる（ステップＳ１９３１）。追加調査対象車両の選出は、例えば図１８に示す追加調査対象車両選出処理の手順に沿って行われる。ここでは、異常が検知されたのと同じ車種の車両、すなわち、車両１０１０ａと車両１０１０ｂとが選出されたと想定して説明を進める。

次いで車両異常検知サーバ８０から車両１０１０ａ及び車両１０１０ｂにログ送信のリクエストが送信され（ステップＳ１９３２）、車両１０１０ａ及び車両１０１０ｂからは、このリクエストに応じて特徴ベクトルがログとして車両異常検知サーバ８０に送信される（ステップＳ１９５５、Ｓ１９６５）。

車両１０１０ａ及び車両１０１０ｂから送信された特徴ベクトルを受信した車両異常検知サーバ８０は、それぞれに対して異常検知処理を行う（ステップＳ１９３３）。

以上説明した一連の処理手順において、ステップＳ１９３１で追加調査対象車選出処理を実行するログ収集対象車両選出部８５５は、本実施の形態における車両選出部の例であり、選出された車両が異常関連車両の例である。また、ステップＳ１９３２で送信されるログの送信リクエストが第一リクエストの例である。

また、例えばステップＳ１９１１までの手順において、ステップＳ１９０１で選出された車両１０１０ａは、本実施の形態における第一標本車両の例であり、車両１０１０ａに送信されたリクエストは、第二リクエストの例である。さらに、ステップＳ１９１１で選出された車両１０１０ｂは、本実施の形態における第二標本車両の例であり、車両１０１０ｂに送信されたリクエストは、第三リクエストの例である。

なお、図１９に示す手順では、車両異常検知サーバ８０は、車両１０１０ａ及び車両１０１０ｂそれぞれから特徴ベクトルを受信してから異常検知処理（ステップＳ１９３３）行われているが、車両１０１０から特徴ベクトルを受信する度に異常検知処理（ステップＳ１９１６）が行われてもよい。

また、この例では、各車両１０１０の車載ネットワークで送受信されるフレームの異常の有無の判定は、車両異常検知サーバ８０のログ分析部８４０によるログの分析によって行われている（ステップＳ１９０３、Ｓ１９１３、Ｓ１９２３）がこれに限定されない。例えば、各車両１０１０の不正フレーム検知部９０３又はその他のデータセキュリティ機能又は自己診断機能を提供する機器によって、当該車両の異常の発生の有無の判定がなされ、その結果を示すデータが車両異常検知サーバ８０に提供されてもよい。この場合、ログ分析部８４０では、ログの分析に代えて当該結果を示すデータの取得をもって、送信元である車両１０１０における異常の発生の有無を示す情報を取得し、その発生の有無に応じた次の手順を実行してもよい。このとき、車両１０１０で異常の発生が検知された場合には、当該車両から不正なフレームに関するフレーム情報が車両異常検知サーバ８０に提供される。車両異常検知サーバ８０は、このフレーム情報を用いてアラートレベルの判定、追加調査対象車両の選出等を行う。

また、この例では平常時の対象車両の１台が選出されているが、複数台であってもよい。また、対象車両の更新タイミングを一定時間の経過としたが、他のタイミングで更新が行われてもよい。また、追加調査対象車両の選出方法は、先に挙げた他の選出方法を用いてもよく、カーメーカー又は車種を横断して対象車両が選出してもよい。構わない。また、図１９では、アラートの通知が省略されているが、異常の検知に伴いアラート通知も行われてもよい。

［２．１４ 補足事項］
ここまでは説明が繁雑になることを避ける意図で触れていないものの、想定されるバリエーション等について以下に述べる。

上記では車種が同一であることについて、型式及び車両ＩＤの共通性の点で説明したがこれに限定されない。例えば、サイバー攻撃に対する共通の脆弱性をはらむという理由で、搭載されているＥＣＵの構成、又はさらに車載ネットワーク上の配置が同じである車両群をもって車種が同一であると考えてもよい。したがって、例えば、型式が同じであっても、搭載されているＥＣＵのサプライヤが異なる車両は、同一車種ではなく別車種として扱ってもよい。また、逆にＥＣＵのサプライヤが異なっていても制御仕様が同一であればＥＣＵの構成は同一として扱ってもよい。また、同じサプライヤ、さらには同じ型番のＥＣＵであっても、ＥＣＵの搭載するソフトウェア（ファームウェアを含む）のバージョンが異なる場合には、別種のＥＣＵとして扱ってもよい。

また、対象車の再選出（図１９のステップＳ１９１１、Ｓ１９２１）のタイミングは、前回選出からの一定時間の経過時に限定されない。サーバによる設定やＯＥＭ（Original Equipment Manufacturer）、ＳＯＣ（Security Operation Center）からの指示によって変更されたり、随時実行されたりしてもよい。

また、上述のようにログを送信する個々の車両の選出が車両異常検知サーバ８０で行われるのではなくてもよい。例えば、車両異常検知サーバ８０では、時刻及び地域等の条件を設定して全車両にこの条件を通知し、各車両において自車固有の情報や時刻情報、位置情報などから対象車両に該当するか否かを判定し、該当する場合にログを車両異常検知サーバ８０に送信してもよい。

また、上記では、車両異常検知サーバ８０において所定閾値を越える異常度が算出されないときを平常時とし、平常時の処理が行われているがこれに限定されない。例えば、ＯＥＭやＳＯＣからの指示、ＩＴＳ等の他システムからの通知に応じて平常時の処理か異常発生時の処理かを切り替えられるものとしてもよい。

また、車両異常検知サーバ８０から送信されるログ送信のリクエストは、平常時（図１９のステップＳ１９０２、Ｓ１９１２、Ｓ１９２２）と異常検知時（ステップＳ１９３２）とで内容が異なるものであってもよい。例えば、ログ送信のリクエストには緊急フラグ領域が含まれ、異常検知時には緊急フラグが立てられてもよい。これに対して車両１０１０では、例えばログ送信処理の優先度を高めたり、又は平常時と内容の異なるログ、例えばより詳細、又は簡易な内容のログを用意して車両異常検知サーバ８０に送信してもよい。また、平常時以外では、攻撃フェーズ又はアラートレベルによってリクエスト及びログそれぞれの内容が異なってもよい。

（その他変形例）
以上のように、本発明に係る技術の例示として実施の形態を説明した。しかしながら、本発明に係る技術はこの実施の形態の内容に限定されず、適宜、変更、置き換え、付加、省略等を行った実施態様にも適用可能である。例えば、以下のような変形例も本発明の一実施態様に含まれる。

（１）上記実施の形態では、車両がＣＡＮのプロトコルに従った通信を行う車載ネットワーク（車載ネットワークシステム）を有する例を用いて説明したが、本発明に係る技術が適用可能なネットワーク種別（通信プロトコル）はこれに限定されない。例えば、車載ネットワークは、ＣＡＮ－ＦＤ、Ｅｔｈｅｒｎｅｔ、ＬＩＮ（Local Interconnect Network）、若しくはＦｌｅｘＲａｙ等のプロトコルに従うネットワーク、又はこれら及びＣＡＮから選択される複数のプロトコルに従うネットワークの組み合わせであってもよい。

（２）上記実施の形態では、特徴ベクトルの作成の処理等を含む送信前の加工処理を、車両１０１０が備えるゲートウェイ９０のフレームアップロード部９５０で行われる例を示した。この加工処理は、車両１０１０内の構成要素と車両異常検知サーバ８０とのどちらかで行われることとしてもよいし、車両１０１０内の構成要素及び車両異常検知サーバ８０の双方が分担することとしてもよい。分担の配分は設計事項として適宜決定し得る。

（３）上記実施の形態では、車両１０１０のゲートウェイ９０が車両異常検知サーバ８０に送信するログに含まれるのは、車上での不正検知の結果に拘わらないフレーム情報である。これに代えて、ゲートウェイ９０が、不正フレームを検知したことに応じて車載ネットワークにエラーフレームを送信する対処を実行する場合、その不正フレームについての情報（特徴ベクトル等）を車両異常検知サーバ８０に送信しない、つまり、車両異常検知サーバ８０に車載ネットワークでの異常の発生を通知しなくてもよい。

（４）上記実施の形態では、平常時には、ログを車両異常検知サーバ８０に送信する車両１０１０を車両異常検知サーバ８０が選出して送信リクエストを送る、又は条件を送るとしていたが、ログを車両異常検知サーバ８０に送信するか否かを決定するシステムが各車両１０１０にあってもよい。例えば、平常時には、各車両１０１０では、車両ＩＤの末尾の数字と現在時刻の末尾の数字が一致するか否かの判定が繰り返され、一致した場合にログが送信されてもよい。この例の場合も、車両異常検知サーバ８０での異常検知時のリクエスト送信は、車両異常検知サーバ８０から各車両に送られる。また、対象車両の選定を、車両異常検知サーバ８０とは別のサーバが行ってもよい。

（５）上記実施の形態では、車両異常検知サーバ８０にて統計的異常検知処理を行うことで、あるフレームの異常度を算定し、異常度に基づいて異常ありと判定した場合において、アラートレベルを決定する例を挙げている。その他、車両異常検知サーバ８０は、統計的異常検知処理に依らずに、例えば予め定められたアルゴリズム等によって、そのフレームの異常度を算定し、異常度に応じて（例えば異常ありか否かに応じて）アラートレベルを決定する機能を有してもよい。例えば、そのフレームが、ファームウェア更新用のフレームについて予め規定されたメッセージＩＤを有するフレームであって、そのフレームがファームウェアの適切な更新時期以外にＣＡＮバスに流れたことを確認された場合に、異常ありを示す異常度を算定してアラートレベルを決定してアラート通知等を行ってもよい。または、この場合は攻撃予兆のフェーズ２に該当すると見做して攻撃フェーズ情報（図９参照）を用いてアラートレベルを決定してもよい。また、例えばより単純に、ブラックリスト又はホワイトリスト等に示される不正フレームの検知用のルールに基づく判定手法が用いられてもよい。そして車両異常検知サーバ８０では、統計的異常検知処理と、不正フレームの検知用の予め定められたルール又はアルゴリズムを用いて不正フレームを検知する処理とを併用することで、異常度が算定されてもよい。この場合には、不正フレームと検知されたフレームについては、異常ありを示すように異常度の算定を行う。

（６）上記実施の形態で示した各種処理の手順（例えば図１５、図１６、図１７、図１８、図１９に示した手順等）の実行順序は、必ずしも、図示に沿って上述した通りの順序に限定されるものではない。これらの実行順序は、発明の要旨を逸脱しない範囲で入れ替えたり、複数の手順を並列に行ったり、その手順の一部を省略したりすることができる。

（７）上記実施の形態におけるゲートウェイその他のＥＣＵは、例えば、プロセッサ、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置と説明したが、情報処理装置であればよく、その例である。この情報処理装置は、ハードディスク装置等の記憶装置、及びディスプレイ、キーボード、マウス等の入出力装置であるハードウェア構成要素を含んでいてもよい。また、車両異常検知サーバ８０は、例えばプロセッサ、記憶装置、通信インタフェース等を備えるコンピュータであることとしたが、ディスプレイ、キーボード、マウス等の入出力装置であるハードウェア構成要素を含んでいてもよい。また、上記実施の形態で示した各装置（ＥＣＵ、車両異常検知サーバ８０等）は、メモリに記憶された制御プログラムがプロセッサにより実行されてソフトウェア的に機能を実現する代わりに、専用のハードウェア（デジタル回路等）によりその機能の少なくとも一部を実現することとしてもよい。

（８）上記実施の形態における各装置を構成する構成要素の一部又は全部は、１個のシステムＬＳＩ（Large Scale Integration：大規模集積回路）から構成されてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ等を含んで構成されるコンピュータシステムである。このＲＯＭには、コンピュータプログラムが記録されている。そして、このマイクロプロセッサが、ＲＯＭに記録されているコンピュータプログラムに従って動作することにより、システムＬＳＩは、その機能を達成する。また、上記各装置を構成する構成要素の各部は、個別に１チップ化されていてもよいし、一部又は全部を含むように１チップ化されてもよい。また、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。更には、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてあり得る。

（９）上記各装置を構成する構成要素の一部又は全部は、各装置に脱着可能なＩＣカード又は単体のモジュールから構成されているとしてもよい。前記ＩＣカード又は前記モジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭ等から構成されるコンピュータシステムである。前記ＩＣカード又は前記モジュールは、上記の超多機能ＬＳＩを含むとしてもよい。マイクロプロセッサが、コンピュータプログラムに従って動作することにより、前記ＩＣカード又は前記モジュールは、その機能を達成する。このＩＣカード又はこのモジュールは、耐タンパ性を有するとしてもよい。

（１０）上記実施の形態及び上記変形例で示した各構成要素及び機能を任意に組み合わせることで実現される形態も本発明の範囲に含まれる。

なお、各実施の形態において車載システムへの適用を示したが、本発明は車載システムに限らず、産業用途、スマートファクトリーなどの工場制御用途において、遠隔制御を行う際にも有効である。

本開示は、複数の車両の異常検知を行う車両異常検知システムにおいて有用である。

１０、２０、３０、４０、５０、６０、７０ バス
８０ 車両異常検知サーバ
８１ ネットワーク
９０ ゲートウェイ
１００、１０１、２００、２０１、３００、３０１、３０２、４００、４０１、５００、６００、７００ ＥＣＵ
１１０ エンジン
１１１ トランスミッション
２１０ ブレーキ
２１１ ステアリング
３１０ 自動ブレーキシステム
３１１ 車線維持システム
３１２ 車車間通信システム
４１０ ドア
４１１ ライト
５１０ ヘッドユニット
６１０ ＩＴＳ装置
７１０ 診断ポート
８１０ 通信部（取得部）
８２０ 認証処理部
８３０ ログ収集部
８４０ ログ分析部
８５０ セキュリティ情報生成部
８５５ ログ収集対象車両選出部
８６０ 車両情報データベース
８６１ 車両情報テーブル
８６５ ＥＣＵ情報データベース
８７０ 車両ログ格納データベース
８８０ 分析結果格納データベース
８９０ セキュリティ情報データベース
９０１ フレーム送受信部
９０２ フレーム解釈部
９０３ 不正フレーム検知部
９０４ ルール保持部
９０５ フレーム生成部
９２０ 鍵処理部
９２１ 鍵保持部
９３０ 不正検知通知部
９４０ 更新処理部
９５０ フレームアップロード部
９６０ ログ送信判定部
１０００ サービスユーザ
１０１０、１０１０ａ、１０１０ｂ、１０１０ｃ、１０１０ｄ、１０１０ｅ、１０１０ｆ 車両
１０２０ ゲートウェイ
１１００ データセンタ運営会社
１１１０ クラウドサーバ
１２００ サービスプロバイダ
１２１０ サーバ
Ｄ１０ 運転者
Ｕ１０ 管理ユーザ

Claims (11)

1. 車両と通信して当該車両が備える車載ネットワークのログを受信する通信部と、
   前記通信の相手である複数台の車両の一である第一車両における異常の発生を示す情報を取得すると、前記第一車両の異常に応じた異常関連車両を前記複数台の車両から選出する車両選出部と、
   前記異常関連車両に、前記異常関連車両が備える車載ネットワークのログの送信を要求する第一リクエストを前記通信部を介して送信するログ収集部と、
   前記第一リクエストに応じて前記異常関連車両から送信され、前記通信部が受信したログが示す情報に基づいて前記異常関連車両における異常の発生有無の判定を行うログ分析部とを備える
   車両異常検知サーバ。
2. 前記車両選出部は、前記複数台の車両から第一標本車両を選出し、
   前記ログ収集部は、選出された前記第一標本車両に、前記第一標本車両が備える車載ネットワークのログの送信を要求する第二リクエストを前記通信部を介して送信し、
   前記ログ分析部は、前記第二リクエストに応じて前記第一標本車両から送信され、前記通信部が受信したログが示す情報に基づいて前記第一標本車両における異常の発生有無の判定を行い、
   前記第一標本車両における異常の発生がないと前記ログ分析部によって判定された場合、前記車両選出部は、前記複数台の車両から前記第一標本車両とは別の第二標本車両を選出し、
   前記ログ収集部は、選出された前記第二標本車両に、前記第二標本車両が備える車載ネットワークのログの送信を要求する第三リクエストを前記通信部を介して送信する
   請求項１に記載の車両異常検知サーバ。
3. 前記ログは、前記車載ネットワークで送受信されるフレームが含む情報の少なくとも一部の時系列データ又は前記フレームに関する情報の時系列データである
   請求項２に記載の車両異常検知サーバ。
4. 前記車両選出部は、前記異常関連車両は、前記異常が発生している車両と車種が共通である車両を前記異常関連車両として選出する
   請求項３に記載の車両異常検知サーバ。
5. 前記車載ネットワークにおいて送受信されるフレームの種類と前記フレームを送信する情報処理装置との対応を示す第一の車両情報を保持する記憶部をさらに備え、
   前記車両選出部は、前記第一車両において発生した異常に関連したフレームと種類が同じフレームを送信する情報処理装置を備える車両を、前記第一の車両情報を参照して前記複数台の車両から特定し、特定した前記車両を前記異常関連車両として選出する
   請求項１に記載の車両異常検知サーバ。
6. 前記記憶部は、前記車載ネットワークにおいて送受信されるフレームの種類を示すメッセージＩＤの車種間の対応を示す第二の車両情報をさらに保持し、
   前記車両選出部は、前記第二の車両情報を参照して、前記第一車両とは異なる車種が備える車載ネットワークで送受信されるフレームのメッセージＩＤであって、前記第一車両において発生した異常に関連したフレームのメッセージＩＤに対応するメッセージＩＤを特定し、
   特定した前記メッセージＩＤが示す種類のフレームを送信する情報処理装置を備える車両を、前記第一の車両情報を参照して前記複数台の車両から特定し、特定した前記車両を前記異常関連車両として選出する
   請求項５に記載の車両異常検知サーバ。
7. 前記第一リクエストの送信先の候補である車両を識別する車両ＩＤの車種別のリストである車両ＩＤリストを保持する記憶部をさらに備え、
   前記車両選出部は、前記車両ＩＤリストを用いて前記異常関連車両を選出する
   請求項１に記載の車両異常検知サーバ。
8. 前記車両ＩＤリストは、前記第一リクエストの送信先の候補である前記車両に関連する地域に応じた前記車両ＩＤの区分を示し、
   前記車両選出部は、前記車両ＩＤリストが示す地域に基づいて前記異常関連車両を選出する
   請求項７に記載の車両異常検知サーバ。
9. 前記車載ネットワークに接続される複数の情報処理装置間の関連を示す関連情報処理装置情報を保持する記憶部をさらに備え、
   前記車両選出部は、前記関連情報処理装置情報を参照して、前記第一車両において発生した異常に関連したフレームを送信した情報処理装置と関連する情報処理装置を備える車両を前記複数台の車両から特定し、特定した前記車両を前記異常関連車両として選出する
   請求項１に記載の車両異常検知サーバ。
10. 請求項１から９のいずれか一項に記載の車両異常検知サーバと、
    前記車両異常検知サーバと通信する複数台の車両であって、前記車両異常検知サーバからのリクエストに応じて前記ログを前記車両異常検知サーバに送信する車両とを含む
    車両異常検知システム。
11. 請求項１０に記載の車両異常検知システムで実行される車両異常検知方法であって、
    前記車両異常検知システムにおいて、前記複数台の車両の一である第一車両における異常の発生を示す情報を取得すると、前記複数台の車両から前記第一車両の異常に応じた異常関連車両を選出し、
    前記車両異常検知システムから前記異常関連車両に、前記異常関連車両が備える車載ネットワークのログの送信を要求する第一リクエストを送信し、
    前記車両異常検知システムが、前記第一リクエストに応じて前記異常関連車両から送信されたログが示す情報に基づいて、前記異常関連車両における異常の発生有無の判定を行う
    車両異常検知方法。

Images