JP2021121109A - 不正対処方法、および電子制御ユニット - Google Patents

Abstract

【課題】ＣＡＮプロトコル等に従って通信する車載ネットワークシステムにおいて、ＭＡＣに対する総当たり攻撃への耐性を高め、不正なフレームの送信に対して適切に対処する不正対処方法を提供する。【解決手段】車載ネットワークにおいてＭＡＣが付加されたデータフレームの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムにおいて用いられる不正対処方法は、車載ネットワークに送信されたデータフレームを受信する受信ステップ（シーケンスＳ４００４）と、データを利用してＭＡＣを生成して、受信ステップで受信されたデータフレームに当該ＭＡＣが付加されていることを検証する検証ステップ（シーケンスＳ４００５）と、検証ステップでの検証が失敗した場合に、ＭＡＣの生成に利用されるデータについての更新処理を行う更新処理ステップ（シーケンスＳ４００７等）とを含む。【選択図】図４３

Description

本発明は、電子制御ユニットが通信を行う車載ネットワークにおいて送信された不正なフレームを検知して対処する技術に関する。

近年、自動車の中のシステムには、電子制御ユニット（ＥＣＵ：Electronic Control Unit）と呼ばれる装置が多数配置されている。これらのＥＣＵをつなぐネットワークは車載ネットワークと呼ばれる。車載ネットワークには、多数の規格が存在する。その中でも最も主流な車載ネットワークの一つに、ＩＳＯ１１８９８−１で規定されているＣＡＮ（Controller Area Network）という規格が存在する（「非特許文献１」参照）。

ＣＡＮでは、通信路は２本のバスで構成され、バスに接続されているＥＣＵはノードと呼ばれる。バスに接続されている各ノードは、フレームと呼ばれるメッセージを送受信する。フレームを送信する送信ノードは、２本のバスに電圧をかけ、バス間で電位差を発生させることによって、レセシブと呼ばれる「１」の値と、ドミナントと呼ばれる「０」の値を送信する。複数の送信ノードが全く同一のタイミングで、レセシブとドミナントを送信した場合は、ドミナントが優先されて送信される。受信ノードは、受け取ったフレームのフォーマットに異常がある場合には、エラーフレームと呼ばれるフレームを送信する。エラーフレームとは、ドミナントを６ｂｉｔ連続して送信することで、送信ノードや他の受信ノードにフレームの異常を通知するものである。

またＣＡＮでは送信先や送信元を指す識別子は存在せず、送信ノードはフレーム毎にメッセージＩＤと呼ばれるＩＤを付けて送信し（つまりバスに信号を送出し）、各受信ノードは予め定められたメッセージＩＤのみを受信する（つまりバスから信号を読み取る）。また、ＣＳＭＡ／ＣＡ（Carrier Sense Multiple Access/Collision Avoidance）方式を採用しており、複数ノードの同時送信時にはメッセージＩＤによる調停が行われ、メッセージＩＤの値が小さいフレームが優先的に送信される。

ところで、車載ネットワークにおいて不正なノードがバスに接続され、不正なノードが不正にフレームを送信することで、車体を不正にコントロールしてしまう可能性がある。このような不正なフレームの送信によるコントロールを防止するために、一般にＣＡＮにおけるデータフィールドにメッセージ認証コード（ＭＡＣ：Message Authentication Code）を付加して送信する技術が知られている（「特許文献１」参照）。

特開２０１３−９８７１９号公報

ＣＡＮ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ２．０ Ｐａｒｔ Ａ、［ｏｎｌｉｎｅ］、ＣＡＮ ｉｎ Ａｕｔｏｍａｔｉｏｎ（ＣｉＡ）、［平成２６年１１月１４日検索］、インターネット（ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｃａｎ−ｃｉａ．ｏｒｇ／ｆｉｌｅａｄｍｉｎ／ｃｉａ／ｓｐｅｃｉｆｉｃａｔｉｏｎｓ／ＣＡＮ２０Ａ．ｐｄｆ） ＲＦＣ２１０４ ＨＭＡＣ： Ｋｅｙｅｄ−Ｈａｓｈｉｎｇ ｆｏｒ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ

しかしながら、ＣＡＮにおけるデータフィールドに格納できるＭＡＣのデータ長は十分に長いとは言えないため、バスに接続された不正なノードによるＭＡＣに対する総当り攻撃等が懸念される。

そこで、本発明は、ＭＡＣに対する総当たり攻撃への耐性を高め、不正なフレームの送信に対して適切に対処するための車載ネットワークシステムを提供する。また、本発明は、その車載ネットワークシステムで不正なフレームの送信を検知するために用いられる不正検知電子制御ユニット（不正検知ＥＣＵ）、及び、不正なフレームの送信に対して適切に対処するための不正対処方法を提供する。

上記課題を解決するために本発明の一態様に係る不正対処方法は、車載ネットワークにおいてメッセージ認証コード（ＭＡＣ：Message Authentication Code）が付加されたデータフレームの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムにおいて、前記複数の電子制御ユニットのうちの１つの電子制御ユニットにおいて用いられる不正対処方法であって、前記車載ネットワークに送信されたデータフレームを受信し、メッセージ認証コードが付加されたデータフレームが送信される回数をカウントするカウンタの値及びＭＡＣ鍵を利用して第１のメッセージ認証コードを生成し、前記受信されたデータフレームに前記生成した第１のメッセージ認証コードが付加されていることを検証し、所定ＩＤを含むデータフレームについて前記検証が失敗した場合に、エラー発生回数をインクリメントし、前記エラー発生回数が所定閾値を超えた場合に、当該所定ＩＤと予め対応付けられている処理を実行する不正対処方法である。

本発明によれば、ＭＡＣに対する総当たり攻撃への耐性を高め、不正なフレームの送信に対して適切に対処することができる。

実施の形態１に係る車載ネットワークシステムの全体構成を示す図である。 ＣＡＮプロトコルで規定されるデータフレームのフォーマットを示す図である。 ＣＡＮプロトコルで規定されるエラーフレームのフォーマットを示す図である。 ヘッドユニットの構成図である。 受信ＩＤリストの一例を示した図である。 ゲートウェイの構成図である。 転送ルールの一例を示した図である。 実施の形態１に係るＥＣＵの構成図である。 受信ＩＤリストの一例を示した図である。 エンジンに接続されたＥＣＵから送信されるフレームにおけるＩＤ及びデータフィールドの一例を示す図である。 ブレーキに接続されたＥＣＵから送信されるフレームにおけるＩＤ及びデータフィールドの一例を示す図である。 ドア開閉センサに接続されたＥＣＵから送信されるフレームにおけるＩＤ及びデータフィールドの一例を示す図である。 窓開閉センサに接続されたＥＣＵから送信されるフレームにおけるＩＤ及びデータフィールドの一例を示す図である。 実施の形態１に係る不正検知ＥＣＵの構成図である。 不正検知ＥＣＵに保持される正規ＩＤリストの一例を示した図である。 不正検知ＥＣＵに保持される正規ＩＤリストの一例を示した図である。 メッセージＩＤ毎の不正検知カウンタの状態の一例を示す図である。 実施の形態１における不正なフレームの検知及び実行阻止に係る動作例を示すシーケンス図である。 実施の形態２に係る車載ネットワークシステムの全体構成を示す図である。 実施の形態２に係る不正検知ＥＣＵの構成図である。 不正検知ＥＣＵに保持されるデータ範囲リストの一例を示した図である。 実施の形態２における不正なフレームの検知及び実行阻止に係る動作例を示すシーケンス図である（図２３に続く）。 実施の形態２における不正なフレームの検知及び実行阻止に係る動作例を示すシーケンス図である（図２２から続く）。 実施の形態３に係る車載ネットワークシステムの全体構成を示す図である。 実施の形態３に係るＥＣＵの構成図である。 エンジンに接続されたＥＣＵから送信されるデータフレームにおけるＩＤ及びデータフィールドの一例を示す図である。 ブレーキに接続されたＥＣＵから送信されるデータフレームにおけるＩＤ及びデータフィールドの一例を示す図である。 ドア開閉センサに接続されたＥＣＵから送信されるデータフレームにおけるＩＤ及びデータフィールドの一例を示す図である。 窓開閉センサに接続されたＥＣＵから送信されるデータフレームにおけるＩＤ及びデータフィールドの一例を示す図である。 実施の形態３に係る不正検知ＥＣＵの構成図である。 実施の形態３に係るカウンタ保持部に保持されているメッセージＩＤ毎のカウンタ値の一例を示す図である。 実施の形態３における不正なフレームの検知及び実行阻止に係る動作例を示すシーケンス図である（図３３に続く）。 実施の形態３における不正なフレームの検知及び実行阻止に係る動作例を示すシーケンス図である（図３２から続く）。 実施の形態４に係る車載ネットワークシステムの全体構成を示す図である。 実施の形態４に係るＥＣＵの構成図である。 実施の形態４に係る不正検知ＥＣＵの構成図である。 実施の形態４に係る受信ＩＤリストの一例を示す図である。 実施の形態４に係る更新フレームの一例を示す図である。 実施の形態４に係る鍵テーブルの一例を示す図である。 実施の形態４に係るカウンタテーブルの一例を示す図である。 実施の形態４に係るセキュリティ条件テーブルの一例を示す図である。 実施の形態４に係る不正ＩＤリストの一例を示す図である。 実施の形態４における不正なフレームの検知、ＭＡＣ鍵の更新及びカウンタ値のリセット等の動作例を示すシーケンス図である（図４４に続く）。 実施の形態４における不正なフレームの検知、ＭＡＣ鍵の更新及びカウンタ値のリセット等の動作例を示すシーケンス図である（図４５に続く）。 実施の形態４における不正なフレームの検知、ＭＡＣ鍵の更新及びカウンタ値のリセット等の動作例を示すシーケンス図である（図４４から続く）。 実施の形態４におけるセキュリティアクション処理を示すフローチャートである。

本発明の一態様に係る不正対処方法は、ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介してメッセージ認証コード（ＭＡＣ：Message Authentication Code）が付加されたデータフレームの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムにおいて用いられる不正対処方法であって、前記バス上で送信されたデータフレームを受信する受信ステップと、データを利用してメッセージ認証コードを生成して前記受信ステップで受信されたデータフレームに当該メッセージ認証コードが付加されていることを検証する検証ステップと、前記検証ステップでの検証が失敗した場合に、メッセージ認証コードの生成に利用されるデータについての更新処理を行う更新処理ステップとを含む不正対処方法である。これにより、データフレームの送信に際してＭＡＣを付与する場合或いはデータフレームを受信してＭＡＣを検証する場合にＭＡＣの生成に用いられるデータ（例えばＭＡＣ鍵等）を更新するので、不正なフレームを送信する不正なＥＣＵによるＭＡＣに対する総当たり攻撃への車載ネットワークシステムの耐性を高め得る。

また、前記不正対処方法は更に、前記検証ステップでの検証が失敗した場合に、メッセージ認証コードの生成に利用されるデータとしてのＭＡＣ鍵の更新要求を示すＭＡＣ鍵更新要求フレームを、前記バスを介して送信する対処ステップを含み、前記更新処理ステップでは、前記ＭＡＣ鍵更新要求フレームが送信された場合にＭＡＣ鍵を更新することで前記更新処理を行うこととしても良い。これにより、例えば不正なＥＣＵからの攻撃の可能性がある場合等において、バスに接続されている各ＥＣＵにおいて同期してＭＡＣ鍵の更新が可能となり、ＭＡＣの不正な解読を困難化し得る。

また、前記メッセージ認証コードは、メッセージ認証コードが付加されたデータフレームが送信される回数をカウントするカウンタの値を反映して生成され、前記不正対処方法は更に、前記検証ステップでの検証が失敗した場合に、メッセージ認証コードの生成に利用されるデータとしてのカウンタのリセット要求を示すカウンタリセット要求フレームを、前記バスを介して送信する対処ステップを含み、前記更新処理ステップでは、前記カウンタリセット要求フレームが送信された場合にカウンタをリセットすることで前記更新処理を行うこととしても良い。これにより、例えば不正なＥＣＵからの攻撃の可能性がある場合等において、バスに接続されている各ＥＣＵにおいて同期してカウンタのリセットが可能となり、ＭＡＣの不正な解読を困難化し得る。

また、前記車載ネットワークシステムは複数のバスを備え、前記複数のバスの各々は、複数種類のグループのうちいずれかのグループに属し、前記不正対処方法は更に、前記検証ステップでの検証が失敗した場合に、前記電子制御ユニットが、前記複数のバスのうち自ユニットが接続されているバスが属するグループと対応付けて予め定められている処理を実行する対処ステップを含むこととしても良い。これにより、不正なデータフレームが送信された場合等においてＥＣＵのグループ毎に予め定められた対処を行うことができる。

また、前記不正対処方法は更に、所定メッセージＩＤを含むデータフレームについて前記検証ステップでの検証が失敗した回数が所定閾値を超えた場合に、当該所定メッセージＩＤと予め対応付けられている処理を実行する対処ステップを含むこととしても良い。これにより、ＭＡＣの検証に一定回数以上失敗したときに予め定められた対処を行うことができる。

また、前記対処ステップで実行される前記処理は、前記車載ネットワークシステムを搭載する車両の機能に一定の抑制を加えて予め定められた特定状態とするための制御であることとしても良い。これにより、不正の検知が一定回数以上なされた場合に車両の状態を予め定められた状態にする制御がなされ、例えば不正なＥＣＵによる弊害を抑制し得る。

また、前記不正対処方法は更に、前記バス上で送信が開始されたデータフレームのメッセージＩＤが、所定の不正ＩＤリストが示す１以上のメッセージＩＤのいずれかと同一である場合に、当該データフレームの最後尾が送信される前にエラーフレームを送信する不正ＩＤ対応処理ステップを含み、前記対処ステップで実行される前記処理は、前記所定メッセージＩＤの前記不正ＩＤリストへの追加であることとしても良い。これにより、ＭＡＣの検証に一定回数以上失敗した場合に再び同じメッセージＩＤの不正なフレームの送信がなされてもその内容をエラーフレームで上書きすることで不正なフレームによる悪影響を抑制できる。

また、前記対処ステップで実行される前記処理は、前記所定メッセージＩＤを示すログ情報の記録媒体への記録であることとしても良い。これにより、例えば不正な攻撃の証拠等の保存が可能になる。

また、前記メッセージ認証コードの生成には、メッセージ認証コードが付加されたデータフレームが送信される回数をカウントするカウンタの値及びＭＡＣ鍵が利用され、前記不正対処方法は更に、ＭＡＣ鍵を利用して生成したメッセージ認証コードを用いた前記検証ステップでの検証が失敗した場合において、当該ＭＡＣ鍵の更新前のＭＡＣ鍵を利用して生成したメッセージ認証コードを用いて再び行った検証に成功したときには、ＭＡＣ鍵の更新要求を示す鍵更新フレームを、前記バスを介して送信する対処ステップを含み、前記更新処理ステップでは、前記鍵更新フレームが送信された場合にＭＡＣ鍵を更新することで前記更新処理を行うこととしても良い。これにより、例えばカウンタ値のリセットを省略し得るようになる。

また、前記メッセージ認証コードの生成には、メッセージ認証コードが付加されたデータフレームが送信される回数をカウントするカウンタの値及びＭＡＣ鍵が利用され、前記不正対処方法は更に、ＭＡＣ鍵を利用して生成したメッセージ認証コードを用いた前記検証ステップでの検証が失敗した場合において、当該ＭＡＣ鍵の更新前のＭＡＣ鍵を利用して生成したメッセージ認証コードを用いて再び行った検証にも失敗したときには、メッセージ認証コードの生成に利用されるカウンタのリセット要求を示すカウンタリセットフレームを、前記バスを介して送信する対処ステップを含み、前記更新処理ステップでは、前記カウンタリセットフレームが送信された場合にカウンタをリセットすることで前記更新処理を行うこととしても良い。これにより、カウンタ値のリセットが必要な状況においてカウンタ値のリセットを行うことができる。

また、本発明の一態様に係る車載ネットワークシステムは、ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介してメッセージ認証コード（ＭＡＣ：Message Authentication Code）が付加されたデータフレームの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムであって、メッセージ認証コードの生成に利用されるＭＡＣ鍵を保持するＭＡＣ鍵保持部を有し、当該ＭＡＣ鍵を用いてメッセージ認証コードを生成して、データフレームに付加して送信する第１電子制御ユニットと、メッセージ認証コードの生成に利用されるＭＡＣ鍵を保持するＭＡＣ鍵保持部を有し、当該ＭＡＣ鍵を用いてメッセージ認証コードを生成して、データフレームを受信して当該データフレームに当該メッセージ認証コードが付加されていることを検証する第２電子制御ユニットとを備え、前記第１電子制御ユニット及び前記第２電子制御ユニットの各々は、更に、前記第２電子制御ユニットでの前記検証が失敗した場合に、自ユニットが有する前記ＭＡＣ鍵保持部に保持されるＭＡＣ鍵を更新するＭＡＣ鍵更新部を有する車載ネットワークシステムである。これにより、ＭＡＣ鍵が更新されるので、車載ネットワークシステムにおいて、不正なフレームを送信する不正なＥＣＵによるＭＡＣに対する総当たり攻撃への耐性が高まり得る。

また、本発明の一態様に係る不正検知電子制御ユニット（不正検知ＥＣＵ）は、ＣＡＮ（Controller Area Network）プロトコルに従って通信する複数の電子制御ユニットが通信に用いるバスに接続される不正検知電子制御ユニットであって、前記バスからフレームを受信し前記バスにフレームを送信するためのフレーム送受信部と、前記フレーム送受信部により受信されたフレームにメッセージ認証コード（ＭＡＣ：Message Authentication Code）が付加されていることを検証する不正ＭＡＣ検知部とを備え、前記フレーム送受信部は、前記不正ＭＡＣ検知部による前記検証が失敗した場合に、メッセージ認証コードの生成に利用されるＭＡＣ鍵の更新要求を示すＭＡＣ鍵更新要求フレームを送信する不正検知電子制御ユニットである。これにより、バスに接続されたＥＣＵが、ＭＡＣ鍵更新要求フレームを受信することでＭＡＣ鍵の更新を同期して行えるようになる。

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

以下、実施の形態に係る不正検知ＥＣＵを含む車載ネットワークシステムについて、図面を参照しながら説明する。ここで示す実施の形態は、いずれも本発明の一具体例を示すものである。従って、以下の実施の形態で示される数値、構成要素、構成要素の配置及び接続形態、並びに、ステップ（工程）及びステップの順序等は、一例であって本発明を限定するものではない。以下の実施の形態における構成要素のうち、独立請求項に記載されていない構成要素については、任意に付加可能な構成要素である。また、各図は、模式図であり、必ずしも厳密に図示されたものではない。

（実施の形態１）
以下、本発明の実施の形態として、メッセージＩＤを用いて不正なフレームを検知して対処するための不正対処方法を実現する不正検知ＥＣＵを含む車載ネットワークシステム１０について図面を用いて説明する。

［１．１ 車載ネットワークシステム１０の全体構成］
図１は、実施の形態１に係る車載ネットワークシステム１０の全体構成を示す図である。車載ネットワークシステム１０は、ＣＡＮプロトコルに従って通信するネットワーク通信システムの一例であり、制御装置、センサ等の各種機器が搭載された自動車におけるネットワーク通信システムである。車載ネットワークシステム１０は、バス５００ａ、５００ｂと、不正検知ＥＣＵ１００ａ、１００ｂ、ヘッドユニット２００、ゲートウェイ３００、及び、各種機器に接続されたＥＣＵ４００ａ〜４００ｄ等のＥＣＵといったバスに接続された各ノードとを含んで構成される。なお、図１では省略しているものの、車載ネットワークシステム１０にはＥＣＵ４００ａ〜４００ｄ以外にもいくつものＥＣＵが含まれ得るが、ここでは、便宜上ＥＣＵ４００ａ〜４００ｄに注目して説明を行う。ＥＣＵは、例えば、プロセッサ（マイクロプロセッサ）、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置である。メモリは、ＲＯＭ、ＲＡＭ等であり、プロセッサにより実行される制御プログラム（コンピュータプログラム）を記憶することができる。例えばプロセッサが、制御プログラム（コンピュータプログラム）に従って動作することにより、ＥＣＵは各種機能を実現することになる。なお、コンピュータプログラムは、所定の機能を達成するために、プロセッサに対する指令を示す命令コードが複数個組み合わされて構成されたものである。ここでは、バス５００ａ、５００ｂには不正なフレームを送信する不正ＥＣＵが接続されている可能性があることを前提として説明する。

不正検知ＥＣＵ１００ａ、１００ｂは、それぞれバス５００ａ、バス５００ｂに接続され、ＥＣＵ４００ａ〜４００ｄ等により送信されたフレームが不正であるかどうかを判定し、不正であればエラーフレームを送信する機能を有するＥＣＵである。

ＥＣＵ４００ａ〜４００ｄは、いずれかのバスと接続され、また、それぞれエンジン４０１、ブレーキ４０２、ドア開閉センサ４０３、窓開閉センサ４０４に接続されている。ＥＣＵ４００ａ〜４００ｄのそれぞれは、接続されている機器（エンジン４０１等）の状態を取得し、定期的に状態を表すフレーム（後述するデータフレーム）等をネットワーク（つまりバス）に送信している。

ゲートウェイ３００は、不正検知ＥＣＵ１００ａ、ＥＣＵ４００ａ及びＥＣＵ４００ｂがつながるバス５００ａと、不正検知ＥＣＵ１００ｂ、ＥＣＵ４００ｃ及びＥＣＵ４００ｄがつながるバス５００ｂと、ヘッドユニット２００がつながるバス５００ｃとに接続しており、それぞれのバスから受信したフレームを他のバスに転送する機能を有する。また受信したフレームを転送するかしないかを接続されたバス間毎に切り替えることも可能である。ゲートウェイ３００も一種のＥＣＵである。

ヘッドユニット２００は、フレームを受信する機能を持ち、ＥＣＵ４００ａ〜４００ｄから送信されるフレームを受信し、各種状態をディスプレイ（図示しない）に表示して、ユーザに提示する機能を持つ。ヘッドユニット２００も一種のＥＣＵである。

この車載ネットワークシステム１０においてはＣＡＮプロトコルに従って各ＥＣＵがフレームの授受を行う。ＣＡＮプロトコルにおけるフレームには、データフレーム、リモートフレーム、オーバーロードフレーム及びエラーフレームがある。説明の便宜上、まずはデータフレーム及びエラーフレームを中心に説明する。

［１．２ データフレームフォーマット］
以下、ＣＡＮプロトコルに従ったネットワークで用いられるフレームの１つであるデータフレームについて説明する。

図２は、ＣＡＮプロトコルで規定されるデータフレームのフォーマットを示す図である。同図には、ＣＡＮプロトコルで規定される標準ＩＤフォーマットにおけるデータフレームを示している。データフレームは、ＳＯＦ（Start Of Frame）、ＩＤフィールド、ＲＴＲ（Remote Transmission Request）、ＩＤＥ（Identifier Extension）、予約ビット「ｒ」、ＤＬＣ（Data Length Code）、データフィールド、ＣＲＣ（Cyclic Redundancy Check）シーケンス、ＣＲＣデリミタ「ＤＥＬ」、ＡＣＫ（Acknowledgement）スロット、ＡＣＫデリミタ「ＤＥＬ」、及び、ＥＯＦ（End Of Frame）の各フィールドで構成される。

ＳＯＦは、１ｂｉｔのドミナントで構成される。バスがアイドルの状態はレセシブになっており、ＳＯＦによりドミナントへ変更することでフレームの送信開始を通知する。

ＩＤフィールドは、１１ｂｉｔで構成される、データの種類を示す値であるＩＤ（メッセージＩＤ）を格納するフィールドである。複数のノードが同時に送信を開始した場合、このＩＤフィールドで通信調停を行うために、ＩＤが小さい値を持つフレームが高い優先度となるよう設計されている。

ＲＴＲは、データフレームとリモートフレームとを識別するための値であり、データフレームにおいてはドミナント１ｂｉｔで構成される。

ＩＤＥと「ｒ」とは、両方ドミナント１ｂｉｔで構成される。

ＤＬＣは、４ｂｉｔで構成され、データフィールドの長さを示す値である。なお、ＩＤＥ、「ｒ」及びＤＬＣを合わせてコントロールフィールドと称する。

データフィールドは、最大６４ｂｉｔで構成される送信するデータの内容を示す値である。８ｂｉｔ毎に長さを調整できる。送られるデータの仕様については、ＣＡＮプロトコルで規定されておらず、車載ネットワークシステム１０において定められる。従って、車種、製造者（製造メーカ）等に依存した仕様となる。

ＣＲＣシーケンスは、１５ｂｉｔで構成される。ＳＯＦ、ＩＤフィールド、コントロールフィールド及びデータフィールドの送信値より算出される。

ＣＲＣデリミタは、１ｂｉｔのレセシブで構成されるＣＲＣシーケンスの終了を表す区切り記号である。なお、ＣＲＣシーケンス及びＣＲＣデリミタを合わせてＣＲＣフィールドと称する。

ＡＣＫスロットは、１ｂｉｔで構成される。送信ノードはＡＣＫスロットをレセシブにして送信を行う。受信ノードはＣＲＣシーケンスまで正常に受信ができていればＡＣＫスロットをドミナントとして送信する。レセシブよりドミナントが優先されるため、送信後にＡＣＫスロットがドミナントであれば、送信ノードは、いずれかの受信ノードが受信に成功していることを確認できる。

ＡＣＫデリミタは、１ｂｉｔのレセシブで構成されるＡＣＫの終了を表す区切り記号である。

ＥＯＦは、７ｂｉｔのレセシブで構成されており、データフレームの終了を示す。

［１．３ エラーフレームフォーマット］
図３は、ＣＡＮプロトコルで規定されるエラーフレームのフォーマットを示す図である。エラーフレームは、エラーフラグ（プライマリ）と、エラーフラグ（セカンダリ）と、エラーデリミタとから構成される。

エラーフラグ（プライマリ）は、エラーの発生を他のノードに知らせるために使用される。エラーを検知したノードはエラーの発生を他のノードに知らせるために６ｂｉｔのドミナントを連続で送信する。この送信は、ＣＡＮプロトコルにおけるビットスタッフィングルール（連続して同じ値を６ｂｉｔ以上送信しない）に違反し、他のノードからのエラーフレーム（セカンダリ）の送信を引き起こす。

エラーフラグ（セカンダリ）は、エラーの発生を他のノードに知らせるために使用される連続した６ビットのドミナントで構成される。エラーフラグ（プライマリ）を受信してビットスタッフィングルール違反を検知した全てのノードがエラーフラグ（セカンダリ）を送信することになる。

エラーデリミタ「ＤＥＬ」は、８ｂｉｔの連続したレセシブであり、エラーフレームの終了を示す。

［１．４ ヘッドユニット２００の構成］
ヘッドユニット２００は、例えば、自動車のインパネ（インストルメントパネル）等に設けられ、運転者に視認されるための情報を表示する液晶ディスプレイ（ＬＣＤ：liquid crystal display）等の表示装置、運転者の操作を受け付ける入力手段等を備える一種のＥＣＵである。

図４は、ヘッドユニット２００の構成図である。ヘッドユニット２００は、フレーム送受信部２７０と、フレーム解釈部２６０と、受信ＩＤ判断部２４０と、受信ＩＤリスト保持部２５０と、フレーム処理部２２０と、表示制御部２１０と、フレーム生成部２３０とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、ヘッドユニット２００における通信回路、ＬＣＤ、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。

フレーム送受信部２７０は、バス５００ｃに対して、ＣＡＮプロトコルに従ったフレームを送受信する。バス５００ｃからフレームを１ｂｉｔずつ受信し、フレーム解釈部２６０に転送する。また、フレーム生成部２３０より通知を受けたフレームの内容をバス５００ｃに１ｂｉｔずつ送信する。

フレーム解釈部２６０は、フレーム送受信部２７０よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。フレーム解釈部２６０は、ＩＤフィールドと判断した値は受信ＩＤ判断部２４０へ転送する。フレーム解釈部２６０は、受信ＩＤ判断部２４０から通知される判定結果に応じて、ＩＤフィールドの値と、ＩＤフィールド以降に現れるデータフィールドとを、フレーム処理部２２０へ転送するか、その判定結果を受けた以降においてフレームの受信を中止する（つまりそのフレームとしての解釈を中止する）かを決定する。また、フレーム解釈部２６０は、例えば、ＣＲＣの値が合わなかったり、ドミナント固定とされている項目がレセシブだったりする等、ＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部２３０へ通知する。また、フレーム解釈部２６０は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。例えばデータフレームの途中からエラーフレームと解釈された場合においては、そのデータフレームの解釈は中止され、そのデータフレームに応じて特段の処理を行うことがなくなる。

受信ＩＤ判断部２４０は、フレーム解釈部２６０から通知されるＩＤフィールドの値を受け取り、受信ＩＤリスト保持部２５０が保持しているメッセージＩＤのリストに従い、そのＩＤフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ＩＤ判断部２４０は、フレーム解釈部２６０へ通知する。

受信ＩＤリスト保持部２５０は、ヘッドユニット２００が受信するＩＤ（メッセージＩＤ）のリストである受信ＩＤリストを保持する。図５は、受信ＩＤリストの一例を示した図である。ヘッドユニット２００は、エンジン４０１に接続されたＥＣＵ４００ａからメッセージＩＤが「１」であるフレーム（メッセージ）を受信し、ブレーキ４０２に接続されたＥＣＵ４００ｂからメッセージＩＤが「２」であるフレームを受信し、ドア開閉センサ４０３に接続されたＥＣＵ４００ｃからメッセージＩＤが「３」であるフレームを受信し、窓開閉センサ４０４に接続されたＥＣＵ４００ｄからメッセージＩＤが「４」であるフレームを受信する。

フレーム処理部２２０は、受信したフレームの内容（例えばメッセージＩＤ及びデータフィールドの内容）に基づいて、例えばＬＣＤに表示されるべき画像を形成して、表示制御部２１０に通知する。なお、フレーム処理部２２０は、受信したデータフィールドの内容を保持し、入力手段を通じて受け付けた運転者による操作に応じて、ＬＣＤに表示されるべき画像（例えば車速表示用の画像、窓開閉状態表示用の画像等）を選択して通知しても良い。

表示制御部２１０は、フレーム処理部２２０より通知を受けた内容をＬＣＤ等に表示する。

フレーム生成部２３０は、フレーム解釈部２６０からのエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部２７０へ通知して送信させる。

［１．５ 受信ＩＤリスト例１］
図５は、ヘッドユニット２００、ゲートウェイ３００、ＥＣＵ４００ｃ及びＥＣＵ４００ｄのそれぞれにおいて保持される受信ＩＤリストの一例を示す図である。同図に例示する受信ＩＤリストは、ＩＤ（メッセージＩＤ）の値が「１」、「２」、「３」及び「４」のいずれかであるメッセージＩＤを含むフレームを選択的に受信して処理するために用いられる。例えば、ヘッドユニット２００の受信ＩＤリスト保持部２５０に図５の受信ＩＤリストが保持されていると、メッセージＩＤが「１」、「２」、「３」及び「４」のいずれでもないフレームについては、フレーム解釈部２６０でのＩＤフィールド以後のフレームの解釈が中止される。

［１．６ ゲートウェイ３００の構成］
図６は、ゲートウェイ３００の構成図である。ゲートウェイ３００は、フレーム送受信部３６０と、フレーム解釈部３５０と、受信ＩＤ判断部３３０と、受信ＩＤリスト保持部３４０と、フレーム生成部３２０と、転送処理部３１０と、転送ルール保持部３７０とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、ゲートウェイ３００における通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。

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

フレーム解釈部３５０は、フレーム送受信部３６０よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。ＩＤフィールドと判断した値は受信ＩＤ判断部３３０へ転送する。フレーム解釈部３５０は、受信ＩＤ判断部３３０から通知される判定結果に応じて、ＩＤフィールドの値と、ＩＤフィールド以降に現れるデータフィールド（データ）とを、転送処理部３１０へ転送するか、その判定結果を受けた以降においてフレームの受信を中止する（つまりそのフレームとしての解釈を中止する）かを決定する。また、フレーム解釈部３５０は、ＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部３２０へ通知する。また、フレーム解釈部３５０は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。

受信ＩＤ判断部３３０は、フレーム解釈部３５０から通知されるＩＤフィールドの値を受け取り、受信ＩＤリスト保持部３４０が保持しているメッセージＩＤのリストに従い、そのＩＤフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ＩＤ判断部３３０は、フレーム解釈部３５０へ通知する。

受信ＩＤリスト保持部３４０は、ゲートウェイ３００が受信するＩＤ（メッセージＩＤ）のリストである受信ＩＤリスト（図５参照）を保持する。

転送処理部３１０は、転送ルール保持部３７０が保持する転送ルールに従って、受信したフレームのメッセージＩＤに応じて、転送するバスを決定し、転送するバスを示すバス情報とフレーム解釈部３５０より通知されたメッセージＩＤとデータとをフレーム生成部３２０へ通知する。なお、ゲートウェイ３００は、あるバスから受信されたエラーフレームについては他のバスに転送しない。

転送ルール保持部３７０は、バス毎のフレームの転送についてのルールを表す情報である転送ルールを保持する。図７は、転送ルールの一例を示した図である。

フレーム生成部３２０は、フレーム解釈部３５０から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部３６０へ通知して送信させる。また、フレーム生成部３２０は、転送処理部３１０より通知されたメッセージＩＤとデータとを使ってフレームを構成し、フレーム及びバス情報をフレーム送受信部３６０へ通知する。

［１．７ 転送ルール例］
図７は、ゲートウェイ３００が保有する転送ルールの一例を示す。この転送ルールは、転送元のバスと転送先のバスと転送対象のＩＤ（メッセージＩＤ）とを対応付けている。図７中の「＊」はメッセージＩＤにかかわらずフレームの転送がなされることを表している。また、同図中の「−」は転送対象のフレームがないことを示す。同図の例は、バス５００ａから受信するフレームはメッセージＩＤにかかわらず、バス５００ｂ及びバス５００ｃに転送するように設定されていることを示している。また、バス５００ｂから受信するフレームのうち、バス５００ｃには全てのフレームが転送されるが、バス５００ａにはメッセージＩＤが「３」であるフレームのみが転送されるように設定されていることを示している。また、バス５００ｃから受信されるフレームは、バス５００ａにもバス５００ｂにも転送されないように設定されていることを示している。

［１．８ ＥＣＵ４００ａの構成］
図８は、ＥＣＵ４００ａの構成図である。ＥＣＵ４００ａは、フレーム送受信部４６０と、フレーム解釈部４５０と、受信ＩＤ判断部４３０と、受信ＩＤリスト保持部４４０と、フレーム処理部４１０と、フレーム生成部４２０と、データ取得部４７０とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、ＥＣＵ４００ａにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。

フレーム送受信部４６０は、バス５００ａに対して、ＣＡＮプロトコルに従ったフレームを送受信する。バス５００ａからフレームを１ｂｉｔずつ受信し、フレーム解釈部４５０に転送する。また、フレーム生成部４２０より通知を受けたフレームの内容をバス５００ａに送信する。

フレーム解釈部４５０は、フレーム送受信部４６０よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。ＩＤフィールドと判断した値は受信ＩＤ判断部４３０へ転送する。フレーム解釈部４５０は、受信ＩＤ判断部４３０から通知される判定結果に応じて、ＩＤフィールドの値と、ＩＤフィールド以降に現れるデータフィールドとを、フレーム処理部４１０へ転送するか、その判定結果を受けた以降においてフレームの受信を中止する（つまりそのフレームとしての解釈を中止する）かを決定する。また、フレーム解釈部４５０は、ＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部４２０へ通知する。また、フレーム解釈部４５０は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。

受信ＩＤ判断部４３０は、フレーム解釈部４５０から通知されるＩＤフィールドの値を受け取り、受信ＩＤリスト保持部４４０が保持しているメッセージＩＤのリストに従い、そのＩＤフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ＩＤ判断部４３０は、フレーム解釈部４５０へ通知する。

受信ＩＤリスト保持部４４０は、ＥＣＵ４００ａが受信するＩＤ（メッセージＩＤ）のリストである受信ＩＤリストを保持する。図９は、受信ＩＤリストの一例を示した図である。

フレーム処理部４１０は、受信したフレームのデータに応じてＥＣＵ毎に異なる機能に係る処理を行う。例えば、エンジン４０１に接続されたＥＣＵ４００ａは、時速が３０ｋｍを超えた状態でドアが開いている状態だと、アラーム音を鳴らす機能を備える。ＥＣＵ４００ａは、例えばアラーム音を鳴らすためのスピーカ等を有している。そして、ＥＣＵ４００ａのフレーム処理部４１０は、他のＥＣＵから受信したデータ（例えばドアの状態を示す情報）を管理し、エンジン４０１から取得された時速に基づいて一定条件下でアラーム音を鳴らす処理等を行う。

データ取得部４７０は、ＥＣＵにつながっている機器、センサ等の状態を示すデータを取得し、フレーム生成部４２０に通知する。

フレーム生成部４２０は、フレーム解釈部４５０から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部４６０へ通知して送信させる。また、フレーム生成部４２０は、データ取得部４７０より通知されたデータの値に対して、予め定められたメッセージＩＤをつけてフレームを構成し、フレーム送受信部４６０へ通知する。

なお、ＥＣＵ４００ｂ〜４００ｄも、上述したＥＣＵ４００ａと基本的に同様の構成を備える。但し、受信ＩＤリスト保持部４４０に保持される受信ＩＤリストはＥＣＵ毎に異なる内容となり得る。ＥＣＵ４００ｂは図９に例示する受信ＩＤリストを保持し、ＥＣＵ４００ｃ及びＥＣＵ４００ｄは図５に例示する受信ＩＤリストを保持する。また、フレーム処理部４１０の処理内容は、ＥＣＵ毎に異なる。例えば、ＥＣＵ４００ｃにおけるフレーム処理部４１０の処理内容は、ブレーキがかかっていない状況でドアが開くとアラーム音を鳴らす機能に係る処理を含む。例えば、ＥＣＵ４００ｂ及びＥＣＵ４００ｄにおけるフレーム処理部４１０では特段の処理を行わない。なお、各ＥＣＵは、ここで例示した以外の機能を備えていても良い。なお、ＥＣＵ４００ａ〜４００ｄのそれぞれが送信するフレームの内容については後に図１０〜図１３を用いて説明する。

［１．９ 受信ＩＤリスト例２］
図９は、ＥＣＵ４００ａ及びＥＣＵ４００ｂのそれぞれにおいて保持される受信ＩＤリストの一例を示す図である。同図に例示する受信ＩＤリストは、ＩＤ（メッセージＩＤ）の値が「１」、「２」及び「３」のいずれかであるメッセージＩＤを含むフレームを選択的に受信して処理するために用いられる。例えば、ＥＣＵ４００ａの受信ＩＤリスト保持部４４０に図９の受信ＩＤリストが保持されていると、メッセージＩＤが「１」、「２」及び「３」のいずれでもないフレームについては、フレーム解釈部４５０でのＩＤフィールド以後のフレームの解釈が中止される。

［１．１０ エンジンに係るＥＣＵ４００ａの送信フレーム例］
図１０は、エンジン４０１に接続されたＥＣＵ４００ａから送信されるフレームにおけるＩＤ（メッセージＩＤ）及びデータフィールド（データ）の一例を示す図である。ＥＣＵ４００ａが送信するフレームのメッセージＩＤは「１」である。データは、時速（ｋｍ／時）を表し、最低０（ｋｍ／時）〜最高１８０（ｋｍ／時）までの範囲の値を取り、データ長は１ｂｙｔｅである。図１０の上行から下行へと、ＥＣＵ４００ａから逐次送信される各フレームに対応する各メッセージＩＤ及びデータを例示しており、０ｋｍ／時から１ｋｍ／時ずつ加速されている様子を表している。

［１．１１ ブレーキに係るＥＣＵ４００ｂの送信フレーム例］
図１１は、ブレーキ４０２に接続されたＥＣＵ４００ｂから送信されるフレームにおけるＩＤ（メッセージＩＤ）及びデータフィールド（データ）の一例を示す図である。ＥＣＵ４００ｂが送信するフレームのメッセージＩＤは「２」である。データは、ブレーキのかかり具合を割合（％）で表し、データ長は１ｂｙｔｅである。この割合は、ブレーキを全くかけていない状態を０（％）、ブレーキを最大限かけている状態を１００（％）としたものである。図１１の上行から下行へと、ＥＣＵ４００ｂから逐次送信される各フレームに対応する各メッセージＩＤ及びデータを例示しており、１００％から徐々にブレーキを弱めている様子を表している。

［１．１２ ドア開閉センサに係るＥＣＵ４００ｃの送信フレーム例］
図１２は、ドア開閉センサ４０３に接続されたＥＣＵ４００ｃから送信されるフレームにおけるＩＤ（メッセージＩＤ）及びデータフィールド（データ）の一例を示す図である。ＥＣＵ４００ｃが送信するフレームのメッセージＩＤは「３」である。データは、ドアの開閉状態を表し、データ長は１ｂｙｔｅである。データの値は、ドアが開いている状態が「１」、ドアが閉まっている状態が「０」である。図１２の上行から下行へと、ＥＣＵ４００ｃから逐次送信される各フレームに対応する各メッセージＩＤ及びデータを例示しており、ドアが開いている状態から次第に閉められた状態へと移った様子を表している。

［１．１３ 窓開閉センサに係るＥＣＵ４００ｄの送信フレーム例］
図１３は、窓開閉センサ４０４に接続されたＥＣＵ４００ｄから送信されるフレームにおけるＩＤ（メッセージＩＤ）及びデータフィールド（データ）の一例を示す図である。ＥＣＵ４００ｄが送信するフレームのメッセージＩＤは「４」である。データは、窓の開閉状態を割合（％）で表し、データ長は１ｂｙｔｅである。この割合は、窓が完全に閉まっている状態を０（％）、窓が全開の状態を１００（％）としたものである。図１３の上行から下行へと、ＥＣＵ４００ｄから逐次送信される各フレームに対応する各メッセージＩＤ及びデータを例示しており、窓が閉まっている状態から徐々に開いていく様子を表している。

［１．１４ 不正検知ＥＣＵ１００ａの構成］
図１４は、不正検知ＥＣＵ１００ａの構成図である。不正検知ＥＣＵ１００ａは、フレーム送受信部１６０と、フレーム解釈部１５０と、不正フレーム検知部１３０と、正規ＩＤリスト保持部１２０と、不正検知カウンタ保持部１１０と、フレーム生成部１４０とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、不正検知ＥＣＵ１００ａにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。なお、不正検知ＥＣＵ１００ｂも基本的に同様の構成を備えるが、正規ＩＤリスト保持部１２０が保持するリスト情報（正規ＩＤリスト）の内容が不正検知ＥＣＵ１００ａと不正検知ＥＣＵ１００ｂとでは異なる。

フレーム送受信部１６０は、バス５００ａに対して、ＣＡＮプロトコルに従ったフレームを送受信する。即ち、フレーム送受信部１６０は、バス上でのフレームの送信が開始された場合においてフレームを受信する言わば受信部として働き、また、バスにエラーフレーム等を送信する言わば送信部として働く。即ち、フレーム送受信部１６０は、バス５００ａからフレームを１ｂｉｔずつ受信し、フレーム解釈部１５０に転送する。また、フレーム生成部１４０より通知を受けたフレームの内容をバス５００ａに送信する。

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

不正フレーム検知部１３０は、フレーム解釈部１５０から通知されるＩＤフィールドの値を受け取り、ＩＤフィールドの値が不正を示す所定条件に該当するか否かを判定する。即ち不正フレーム検知部１３０は、受信されたフレームにおける所定フィールドの内容が不正を示す所定条件に該当するか否かを判定する言わば判定部として機能する。この不正を示す所定条件は、ＩＤフィールドの値が、正規ＩＤリスト保持部１２０が保持しているメッセージＩＤのリストに載っていないという条件である。即ち、正規ＩＤリスト保持部１２０が保持しているメッセージＩＤのリストに従い、通知されたＩＤフィールドの値（メッセージＩＤ）が不正かどうかの判定を行う。このリスト（つまり後述する正規ＩＤリスト）に載っていないメッセージＩＤを受信した場合は、不正の検知回数をインクリメントするために、受信したメッセージＩＤを不正検知カウンタ保持部１１０へ通知する。また、正規ＩＤリストに載っていないメッセージＩＤを受信した場合は、エラーフレームを送信するように、フレーム生成部１４０へ通知する。また、不正の検知回数が一定回数以上に達した場合に、不正検知カウンタ保持部１１０より通知を受け、該当するメッセージＩＤを発行する不正なＥＣＵが存在することを示すエラー表示メッセージ（フレーム）を送信するようフレーム生成部１４０へ通知する。エラー表示メッセージのメッセージＩＤは予め定められており、このメッセージＩＤのメッセージ（フレーム）をヘッドユニット２００が受信してエラー表示を行うようになっている。このエラー表示メッセージについては便宜上説明を省略していたが、エラー表示メッセージのメッセージＩＤは、ゲートウェイ３００及びヘッドユニット２００が保持する受信ＩＤリスト、及び、後述する正規ＩＤリストに掲載される。但し、図１５、図１６ではエラー表示メッセージについてのメッセージＩＤを省略している。

正規ＩＤリスト保持部１２０は、車載ネットワークシステム１０においてバス５００ａ上を送信されることとなるフレームに含まれるメッセージＩＤを予め規定したリストである正規ＩＤリストを保持する（図１５、図１６参照）。

不正検知カウンタ保持部１１０は、メッセージＩＤ毎に検知回数をカウントするための不正検知カウンタを保持しており、不正フレーム検知部１３０からメッセージＩＤが通知されると、該当する不正検知カウンタをインクリメント（増加）する。不正検知カウンタが一定数（所定回数）以上に達した場合、不正フレーム検知部１３０に一定数を超えたことを通知する。ここでいう一定数（所定回数）の一例は、ＣＡＮプロトコルにおける送信エラーカウンタの取り扱い規則に対応して定められた値である。ＣＡＮプロトコルでは、ＥＣＵがエラーフレームによって送信を阻止する度に送信エラーカウンタが８カウントアップする。そして、この結果として送信ノードにおける送信エラーカウンタが１２８迄カウントアップすれば送信ノードはパッシブ状態に遷移してフレーム送信をしなくなるように規定されている。従って、１２８／８（＝１６）より大きな１７をこの一定数として定めておけば、ＣＡＮプロトコルにおける送信エラーカウンタに係る規則を無視した送信ノード（不正なＥＣＵ）の存在が推定される場合に不正検知ＥＣＵ１００ａからエラー表示メッセージが送信されるようになる。なお、不正なフレームを送信する、不正なＥＣＵが、ＣＡＮプロトコルにおける送信エラーカウンタに係る規則に従うものであった場合には、不正検知ＥＣＵ１００ａによるエラーフレームの送信によって、不正なＥＣＵの送信エラーカウンタは８インクリメントされる。この場合、不正なフレームの送信を繰り返すことで不正なＥＣＵの送信エラーカウンタが１２８まで上昇すると、不正なＥＣＵがパッシブ状態に遷移し、不正なＥＣＵによる不正なフレームの送信が停止することになる。

フレーム生成部１４０は、フレーム解釈部１５０から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部１６０へ通知して送信させる。また、フレーム生成部１４０は、不正フレーム検知部１３０から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部１６０へ通知して送信させる。更にフレーム生成部１４０は、不正フレーム検知部１３０から通知されたエラー表示メッセージの送信を指示する通知に従い、エラー表示メッセージをフレーム送受信部１６０へ通知して送信させる。

［１．１５ 不正検知ＥＣＵ１００ａの正規ＩＤリスト例］
図１５は、不正検知ＥＣＵ１００ａの正規ＩＤリスト保持部１２０に保持される正規ＩＤリストの一例を示した図である。同図に例示する正規ＩＤリストは、ＩＤ（メッセージＩＤ）の値が「１」、「２」及び「３」のいずれかであるメッセージＩＤを含むフレームがバス５００ａに流れ得ることを示している。

［１．１６ 不正検知ＥＣＵ１００ｂの正規ＩＤリスト例］
図１６は、不正検知ＥＣＵ１００ｂの正規ＩＤリスト保持部１２０に保持される正規ＩＤリストの一例を示した図である。同図に例示する正規ＩＤリストは、ＩＤ（メッセージＩＤ）の値が「１」、「２」、「３」及び「４」のいずれかであるメッセージＩＤを含むフレームがバス５００ｂに流れ得ることを示している。

［１．１７ 不正検知カウンタ保存リスト例］
図１７は、メッセージＩＤ毎の不正検知カウンタの状態の一例を示す図である。同図の例は、メッセージＩＤが「４」の不正検知カウンタだけが、不正を一度検知しており、その他のメッセージＩＤでは一度も検知していないことを示す。即ち、この例はバス５００ａに本来流れるはずがないメッセージＩＤ「４」のメッセージ（フレーム）が一度送信されたことを不正検知ＥＣＵ１００ａが検知し、該当するメッセージＩＤ「４」に対応する不正検知カウンタを１インクリメントした場合を示している。

［１．１８ 不正フレームの検知に係るシーケンス］
以下、上述の構成を備える車載ネットワークシステム１０のバス５００ａに不正なＥＣＵが接続された場合について、バス５００ａに接続された不正検知ＥＣＵ１００ａ、ＥＣＵ４００ａ、ＥＣＵ４００ｂ、ゲートウェイ３００等の動作について説明する。

図１８は、不正検知ＥＣＵ１００ａが不正なフレーム（メッセージ）を検知して、他のＥＣＵによりその不正なフレームに対応した処理がなされることを阻止する動作例を示すシーケンス図である。同図では、不正なＥＣＵが、バス５００ａにメッセージＩＤが「４」でデータフィールド（データ）が「２５５（０ｘＦＦ）」となるデータフレームを送信する場合の例を示している。ここでの各シーケンスは、各種装置における各処理手順（ステップ）を意味する。

まず、不正なＥＣＵは、メッセージＩＤが「４」、データが「２５５（０ｘＦＦ）」となるデータフレームの送信を開始する（シーケンスＳ１００１）。フレームを構成する各ビットの値は、上述したデータフレームフォーマットに従ってＳＯＦ、ＩＤフィールド（メッセージＩＤ）といった順に逐次バス５００ａ上に送出される。

不正なＥＣＵがＩＤフィールド（メッセージＩＤ）までをバス５００ａに送出し終えたときにおいて、不正検知ＥＣＵ１００ａ、ＥＣＵ４００ａ、ＥＣＵ４００ｂ及びゲートウェイ３００はそれぞれメッセージＩＤを受信する（シーケンスＳ１００２）。

ＥＣＵ４００ａ、ＥＣＵ４００ｂ及びゲートウェイ３００はそれぞれ、保持している受信ＩＤリストを用いてメッセージＩＤをチェックする（シーケンスＳ１００３）。このとき、不正検知ＥＣＵ１００ａは、保持している正規ＩＤリストを用いてメッセージＩＤをチェックする（シーケンスＳ１００４）。即ち、不正検知ＥＣＵ１００ａは、送信されたフレームにおけるＩＤフィールドの内容が、不正を示す所定条件（正規ＩＤリストに掲載されていないこと）に該当するか否かを判定する。

シーケンスＳ１００３において、ＥＣＵ４００ａ及びＥＣＵ４００ｂは、それぞれが保持している受信ＩＤリストに「４」が含まれていないため（図９参照）、受信を終了する。つまりこれ以上不正なＥＣＵが送信を継続するフレームの解釈をせずフレームに対応した処理を行わない。また、シーケンスＳ１００３においてゲートウェイ３００は、保持している受信ＩＤリストに「４」が含まれているため（図５参照）、受信を継続する。また、シーケンスＳ１００４において不正検知ＥＣＵ１００ａは、保持している正規ＩＤリストに「４」が含まれていないため、不正なメッセージＩＤであると判断して、続いてエラーフレームの発行準備を開始する（シーケンスＳ１００５）。

シーケンスＳ１００３に続いて、ゲートウェイ３００はフレームの受信を継続する。例えば、不正検知ＥＣＵ１００ａがエラーフレームの発行準備をしている間に、不正なＥＣＵからはバス５００ａ上にＩＤフィールドより後の部分であるＲＴＲ、コントロールフィールド（ＩＤＥ、ｒ、ＤＬＣ）が逐次送出され、続いてデータフィールドが１ビットずつ逐次送出される。ゲートウェイ３００はこのＲＴＲ、コントロールフィールド（ＩＤＥ、ｒ、ＤＬＣ）を受信し、続いてデータフィールドの受信を開始する（シーケンスＳ１００６）。

次にエラーフレームの発行準備が終わって、不正検知ＥＣＵ１００ａがエラーフレームを送信する（シーケンスＳ１００７）。このエラーフレームの送信は、不正なフレームの最後尾が送信される前（例えばＣＲＣシーケンスの最後尾が送信される前等）に行われる。この動作例においては、データフィールドの途中で行われる。このエラーフレームの送信が開始されることによりバス５００ａでは、不正なＥＣＵから送信中のフレームのデータフィールドの途中部分がエラーフレーム（優先されるドミナントのビット列）により上書きされることになる。

シーケンスＳ１００７において送信されたエラーフレームを受信したゲートウェイ３００は、データフィールドの受信途中で不正なＥＣＵが送信していたフレームの受信を中止する（シーケンスＳ１００８）。つまり、ゲートウェイ３００は、不正なＥＣＵからのデータフィールドがエラーフレームで上書きされており、エラーフレームを検出するので、不正なＥＣＵが送信していたフレームの受信を継続しない。

不正検知ＥＣＵ１００ａは、エラーフレームを送信する対象となったデータフレームのメッセージＩＤ「４」に対応する不正検知カウンタをインクリメントする（シーケンスＳ１００９）。

インクリメントした結果としてメッセージＩＤ「４」に対応する不正検知カウンタが１７以上となった場合、不正検知ＥＣＵ１００ａは、ヘッドユニット２００に受信されるようにエラー表示を通知するフレーム（エラー表示メッセージ）を送信する（シーケンスＳ１０１０）。この結果としてヘッドユニット２００のフレーム処理部２２０によってエラー表示のための処理がなされＬＣＤ等を介してエラーが報知される。なお、エラーの報知は、ＬＣＤ等への表示の他、音声出力、発光等によるものでも良い。

［１．１９ 実施の形態１の効果］
実施の形態１で示した不正検知ＥＣＵは、送信されたフレーム（データフレーム）が不正なフレームか否かを、フレームのＩＤフィールドについて正規ＩＤリストを用いて判定する。これにより、データフレームにおけるＩＤフィールドによって不正を判定できるため、既存のノード（つまり不正検知ＥＣＵ及び不正なＥＣＵ以外のＥＣＵ）において不正なフレームが解釈されてそのフレームに対応する処理が実行されることを阻止できる。また、データフレームの先頭のＳＯＦに続くＩＤフィールドまで受信するだけで判定ができるため、データフレームの後部等を受信して判定を行う場合よりも、バスのトラフィックを抑えることが可能となる。

また、不正検知ＥＣＵが、不正検知カウンタを用いてエラーフレームを送信した回数をカウントすることで、エラーフレームの受信により不正なメッセージＩＤを送信するノードにおける送信エラーカウンタがＣＡＮプロトコルに従えばパッシブ状態に遷移すべき上限値まで到達していることを検出することができる。これにより、不正なメッセージＩＤを送信するノードが、ＣＡＮプロトコルのエラーカウンタの仕様に準拠しているか否かを判定することが可能となる。

また、不正なフレームの判定を行うノードを不正検知ＥＣＵのみとすることで、既存のネットワーク構成への影響を最小限に抑えることができ、システム全体として処理量、電力消費量を抑えることができる。

（実施の形態２）
以下、本発明の実施の形態として、メッセージＩＤ毎に許容されるデータ範囲に基づいて、他のノード（ＥＣＵ）において不正なフレームに基づく処理が実行されることを阻止するための不正対処方法を実現する不正検知ＥＣＵを含む車載ネットワークシステム１１について説明する。

［２．１ 車載ネットワークシステム１１の全体構成］
図１９は、実施の形態２に係る車載ネットワークシステム１１の全体構成を示す図である。車載ネットワークシステム１１は、実施の形態１で示した車載ネットワークシステム１０の一部を変形したものである。車載ネットワークシステム１１は、バス５００ａ、５００ｂと、不正検知ＥＣＵ２１００ａ、２１００ｂ、ヘッドユニット２００、ゲートウェイ３００、及び、各種機器に接続されたＥＣＵ４００ａ〜４００ｄ等のＥＣＵといったバスに接続された各ノードとを含んで構成される。車載ネットワークシステム１１の構成要素のうち、実施の形態１と同様の機能を有する構成要素は、同じ符号を付して説明を省略する。

不正検知ＥＣＵ２１００ａ、２１００ｂは、それぞれバス５００ａ、バス５００ｂに接続され、ＥＣＵ４００ａ〜４００ｄ等により送信されたフレームが不正であるかどうかを判定し、不正であればエラーフレームを送信する機能を有するＥＣＵである。

［２．２ 不正検知ＥＣＵ２１００ａの構成］
図２０は、不正検知ＥＣＵ２１００ａの構成図である。不正検知ＥＣＵ２１００ａは、フレーム送受信部１６０と、フレーム解釈部２１５０と、不正フレーム検知部２１３０と、データ範囲リスト保持部２１２０と、不正検知カウンタ保持部１１０と、フレーム生成部１４０とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、不正検知ＥＣＵ２１００ａにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。不正検知ＥＣＵ２１００ａは、実施の形態１で示した不正検知ＥＣＵ１００ａの一部を変形したものであり、実施の形態１と同様の機能を有する構成要素は、同じ符号を付して説明を省略する。なお、不正検知ＥＣＵ２１００ｂも不正検知ＥＣＵ２１００ａと同様の構成を備える。

フレーム解釈部２１５０は、実施の形態１で示したフレーム解釈部１５０を変形したものであり、フレーム送受信部１６０よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。フレームがデータフレームであると判断した場合においてデータフィールドと判断した値（データ）は、ＩＤフィールドのＩＤ（メッセージＩＤ）と共に、不正フレーム検知部２１３０へ転送する。また、フレーム解釈部２１５０は、ＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部１４０へ通知する。また、フレーム解釈部２１５０は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。

不正フレーム検知部２１３０は、実施の形態１で示した不正フレーム検知部１３０を変形したものであり、フレーム解釈部２１５０から通知されるメッセージＩＤと、データフィールドの値（データ）を受け取り、これらの値が不正を示す所定条件に該当するか否かを判定する。即ち不正フレーム検知部２１３０は、受信されたフレームにおける所定フィールドの内容が不正を示す所定条件に該当するか否かを判定する言わば判定部として機能する。この不正を示す所定条件は、データが、データ範囲リスト保持部２１２０が保持しているデータ範囲リストにメッセージＩＤと対応付けて載っているデータ範囲に入らないという条件である。不正フレーム検知部２１３０は、データ範囲リスト保持部２１２０に保持しているメッセージＩＤ毎のデータ範囲を定めたリストであるデータ範囲リストに従い、不正かどうかの判定を行う。不正フレーム検知部２１３０は、データ範囲リストで示される範囲以外のデータを受信した場合は、不正の検知回数をインクリメントするために、受信したメッセージＩＤを不正検知カウンタ保持部１１０へ通知する。この不正の検知回数が一定回数以上に達した場合において、ヘッドユニット２００で受信されるようにエラー表示メッセージを送信するための制御については実施の形態１で説明した通りであるため、ここでの説明を省略する。また、データ範囲リストで示される範囲以外のデータを受信した場合は、エラーフレームを送信するように、フレーム生成部１４０へ通知する。

データ範囲リスト保持部２１２０は、車載ネットワークシステム１１においてバス上を送信されるデータフレームに含まれるデータ（データフィールドの値）について許容される範囲を予め規定したリストであるデータ範囲リストを保持する（図２１参照）。

［２．３ データ範囲リスト例］
図２１は、不正検知ＥＣＵ２１００ａのデータ範囲リスト保持部２１２０に保持されるデータ範囲リストの一例を示した図である。このデータ範囲リストは、各ＩＤ（メッセージＩＤ）と、そのメッセージＩＤのデータフレームにおけるデータフィールドの値（データ）として許容されるデータ範囲とを対応付けたものである。図２１の例では、メッセージＩＤが「１」のデータフレームについては、データ範囲「０〜１８０」、メッセージＩＤが「２」又は「４」のデータフレームについては、データ範囲「０〜１００」、メッセージＩＤが「３」のデータフレームについて、データ範囲「０、１」をそれぞれ正常としている。

［２．４ 不正フレームの検知に係るシーケンス］
以下、上述の構成を備える車載ネットワークシステム１１のバス５００ａに不正なＥＣＵが接続された場合について、バス５００ａに接続された不正検知ＥＣＵ２１００ａ、ＥＣＵ４００ａ、ＥＣＵ４００ｂ、ゲートウェイ３００等の動作について説明する。

図２２及び図２３は、不正検知ＥＣＵ２１００ａが不正なフレーム（メッセージ）を検知して、他のＥＣＵによりその不正なフレームに対応した処理がなされることを阻止する動作例を示すシーケンス図である。図２２及び図２３では、実施の形態１で示した図１８の場合と同様に、不正なＥＣＵが、バス５００ａにメッセージＩＤが「４」でデータフィールド（データ）が「２５５（０ｘＦＦ）」となるデータフレームを送信する場合の例を示している。実施の形態１で示したシーケンスと同じシーケンスには同じ符号を付しており、ここでは説明を簡略化する。

まず、不正なＥＣＵは、不正なデータフレームの送信を開始する（シーケンスＳ１００１）。不正検知ＥＣＵ２１００ａ、ＥＣＵ４００ａ、ＥＣＵ４００ｂ及びゲートウェイ３００はそれぞれメッセージＩＤを受信する（シーケンスＳ１００２）。ＥＣＵ４００ａ、ＥＣＵ４００ｂ及びゲートウェイ３００はそれぞれ、保持している受信ＩＤリストを用いてメッセージＩＤをチェックする（シーケンスＳ１００３）。ＥＣＵ４００ａ及びＥＣＵ４００ｂは、それぞれが保持している受信ＩＤリストに「４」が含まれていないため（図９参照）、受信を終了する。ゲートウェイ３００は、保持している受信ＩＤリストに「４」が含まれているため（図５参照）、受信を継続しデータフィールドの受信を行う（シーケンスＳ１００６ａ）。同様に不正検知ＥＣＵ２１００ａもデータフィールドの受信を行う（シーケンスＳ１００６ａ）。

シーケンスＳ１００６ａに続いて、不正検知ＥＣＵ２１００ａは、データ範囲リスト（図２１参照）を用いて、データフィールドのデータをチェックする（シーケンスＳ２００１）。即ち、不正検知ＥＣＵ２１００ａは、送信されたフレームにおけるＩＤフィールドの内容が、不正を示す所定条件（データ範囲リストに記載されているデータの範囲に入らないこと）に該当するか否かを判定する。不正検知ＥＣＵ２１００ａは、データ範囲リストにおいてＩＤ「４」に対応する「２５５（０ｘＦＦ）」の値が記載されていないため、不正なデータフレームであると判断し、続いてエラーフレームの発行準備を開始する（シーケンスＳ１００５）。

不正検知ＥＣＵ２１００ａがエラーフレームの発行準備をしている間に、不正なＥＣＵからはバス５００ａ上にデータフィールドより後の部分であるＣＲＣフィールド（ＣＲＣシーケンス及びＣＲＣデリミタ）が１ビットずつ逐次送出される。ゲートウェイ３００はこのＣＲＣフィールドの受信を開始する（シーケンスＳ２００２）。

次にエラーフレームの発行準備が終わって、不正検知ＥＣＵ２１００ａがエラーフレームを送信する（シーケンスＳ１００７）。このエラーフレームの送信が開始されることによりバス５００ａでは、不正なＥＣＵから送信中のフレームのＣＲＣシーケンスの途中部分がエラーフレーム（優先されるドミナントのビット列）により上書きされることになる。

シーケンスＳ１００７において送信されたエラーフレームを受信したゲートウェイ３００は、ＣＲＣシーケンスを含むＣＲＣフィールドの受信途中で、不正なＥＣＵが送信していたデータフレームの受信を中止する（シーケンスＳ２００３）。つまり、ゲートウェイ３００は、不正なＥＣＵからのＣＲＣシーケンスがエラーフレームで上書きされており、エラーフレームを検出するので、不正なＥＣＵが送信していたデータフレームの受信を継続しない。

不正検知ＥＣＵ２１００ａは、エラーフレームを送信する対象となったデータフレームのＩＤ「４」に対応する不正検知カウンタをインクリメントする（シーケンスＳ１００９）。インクリメントした結果としてＩＤ「４」に対応する不正検知カウンタが１７以上となった場合、不正検知ＥＣＵ２１００ａは、エラー表示メッセージを送信する（シーケンスＳ１０１０）。

［２．５ 実施の形態２の効果］
実施の形態２で示した不正検知ＥＣＵは、送信されたフレームが不正なフレームか否かを、フレーム（データフレーム）のＩＤフィールド及びデータフィールドについてデータ範囲リストを用いて判定する。これにより、データフレームにおけるＩＤフィールドとデータフィールドとの組み合わせによって不正を判定できるため、既存のＥＣＵ（つまり不正検知ＥＣＵ及び不正なＥＣＵ以外のＥＣＵ）において不正なフレームが解釈されてそのフレームに対応する処理が実行されることを阻止することができる。また、データフレームのデータフィールドまで受信するだけで判定ができるため、データフレームの後部を受信して判定を行う場合よりも、バスのトラフィックを抑えることが可能となる。

また、不正検知ＥＣＵが、不正検知カウンタを用いてエラーフレームを送信した回数をカウントすることで、エラーフレームの受信により不正なメッセージＩＤを送信するノードにおける送信エラーカウンタがＣＡＮプロトコルに従えばパッシブ状態に遷移すべき上限値まで到達していることを検出することができる。これにより、不正なメッセージＩＤを送信するノードが、ＣＡＮプロトコルのエラーカウンタの仕様に準拠しているか否かを判定することが可能となる。

また、不正なフレームの判定を行うノードを不正検知ＥＣＵのみとすることで、既存のネットワーク構成への影響を最小限に抑えることができ、システム全体として処理量、電力消費量を抑えることができる。

（実施の形態３）
以下、本発明の実施の形態として、メッセージＩＤ、データ及びカウンタ値から算出されるメッセージ認証コード（ＭＡＣ：Message Authentication Code）を用いて、他のノード（ＥＣＵ）において不正なフレームに基づく処理が実行されることを阻止するための不正対処方法を実現する不正検知ＥＣＵを含む車載ネットワークシステム１２について説明する。

［３．１ 車載ネットワークシステム１２の全体構成］
図２４は、実施の形態３に係る車載ネットワークシステム１２の全体構成を示す図である。車載ネットワークシステム１２は、実施の形態１で示した車載ネットワークシステム１０の一部を変形したものである。車載ネットワークシステム１２は、バス５００ａ、５００ｂと、不正検知ＥＣＵ３１００ａ、３１００ｂ、ヘッドユニット２００、ゲートウェイ３００、及び、各種機器に接続されたＥＣＵ３４００ａ〜３４００ｄ等のＥＣＵといったバスに接続された各ノードとを含んで構成される。車載ネットワークシステム１２の構成要素のうち、実施の形態１と同様の機能を有する構成要素は、同じ符号を付して説明を省略する。

不正検知ＥＣＵ３１００ａ、３１００ｂは、それぞれバス５００ａ、バス５００ｂに接続され、ＥＣＵ３４００ａ〜３４００ｄ等により送信されたフレームが不正であるかどうかを判定し、不正であればエラーフレームを送信する機能を有するＥＣＵである。

ＥＣＵ３４００ａ〜３４００ｄは、いずれかのバスと接続され、また、それぞれエンジン４０１、ブレーキ４０２、ドア開閉センサ４０３、窓開閉センサ４０４に接続されている。ＥＣＵ３４００ａ〜３４００ｄのそれぞれは、接続されている機器（エンジン４０１等）の状態を取得し、定期的に状態を表すデータフレームをネットワーク（つまりバス）に送信している。送信されるデータフレームのデータフィールドには、メッセージＩＤとデータ値と送信毎にインクリメントされるカウンタ値とから計算により導出されるメッセージ認証コード（ＭＡＣ）が付与される。

［３．２ ＥＣＵ３４００ａの構成］
図２５は、ＥＣＵ３４００ａの構成図である。ＥＣＵ３４００ａは、フレーム送受信部４６０と、フレーム解釈部４５０と、受信ＩＤ判断部４３０と、受信ＩＤリスト保持部４４０と、フレーム処理部４１０と、フレーム生成部３４２０と、データ取得部４７０と、ＭＡＣ生成部３４１０と、ＭＡＣ鍵保持部３４３０と、カウンタ保持部３４４０とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、ＥＣＵ３４００ａにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。ＥＣＵ３４００ａは、実施の形態１で示したＥＣＵ４００ａの一部を変形したものであり、実施の形態１と同様の機能を有する構成要素は、同じ符号を付して説明を省略する。

フレーム生成部３４２０は、実施の形態１で示したフレーム生成部４２０の一部を変形したものである。フレーム生成部３４２０は、フレーム解釈部４５０から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部４６０へ通知して送信させる。また、フレーム生成部３４２０は、データ取得部４７０より通知されたデータの値と予め定められたメッセージＩＤとをＭＡＣ生成部３４１０へ通知して、算出されたＭＡＣを受け取る。フレーム生成部３４２０は、予め定められたメッセージＩＤとデータ取得部４７０より通知されたデータの値とＭＡＣ生成部３４１０から受け取ったＭＡＣとを含むようにフレームを構成し（図２６参照）、フレーム送受信部４６０へ通知する。

ＭＡＣ生成部３４１０は、フレーム生成部３４２０より通知されるメッセージＩＤとデータの値と、カウンタ保持部３４４０で保持するカウンタ値とを結合した値（結合値）に対し、ＭＡＣ鍵保持部３４３０で保持するＭＡＣ鍵を用いて、ＭＡＣを算出（計算により導出）して、この算出した結果であるＭＡＣをフレーム生成部３４２０へと通知する。ここではＭＡＣの計算方法として、ＨＭＡＣ（Hash-based Message Authentication Code)（非特許文献２参照）を採用し、上述した結合値に対し、所定のブロック分（例えば４ｂｙｔｅｓ）までパディングした値でＭＡＣ鍵を使って計算し、出てきた計算結果の先頭４ｂｙｔｅｓをＭＡＣとする。なお、ここでは、ＭＡＣを算出するために用いる結合値は、メッセージＩＤとデータの値とカウンタ保持部３４４０で保持するカウンタ値とを使用しているが、これらの３つのうち、いずれか１つ又は２つの組み合わせを用いてＭＡＣを算出しても良い。

ＭＡＣ鍵保持部３４３０は、ＭＡＣを計算するため必要となるＭＡＣ鍵を保持する。

カウンタ保持部３４４０は、ＭＡＣを計算するために必要となるカウンタ値を保持する。なお、このカウンタ値は、フレーム送受信部４６０においてデータフレームが正常に送信された度にインクリメントされる。

なお、ＥＣＵ３４００ｂ〜３４００ｄは、それぞれ実施の形態１で示したＥＣＵ４００ｂ〜４００ｄの一部を変形したものであり、上述したＥＣＵ３４００ａと基本的に同様の構成を備える。但し、受信ＩＤリスト保持部４４０に保持される受信ＩＤリストはＥＣＵ毎に異なる内容となり得る。例えばＥＣＵ３４００ａ及びＥＣＵ３４００ｂは図９に例示する受信ＩＤリストを保持し、ＥＣＵ３４００ｃ及びＥＣＵ３４００ｄは図５に例示する受信ＩＤリストを保持する。また、フレーム処理部４１０の処理内容は、実施の形態１で示したようにＥＣＵ毎に異なる。以下、ＥＣＵ３４００ａ〜３４００ｄのそれぞれが送信するフレームの内容について図２６〜図２９を用いて説明する。

［３．３ エンジンに係るＥＣＵ３４００ａの送信フレーム例］
図２６は、エンジン４０１に接続されたＥＣＵ３４００ａから送信されるデータフレームにおけるＩＤ（メッセージＩＤ）及びデータフィールド（データ）の一例を示す図である。ＥＣＵ３４００ａが送信するフレームのメッセージＩＤは「１」である。データは、同図において１バイト毎に空白で区分して表しており、先頭の１ｂｙｔｅが時速（ｋｍ／時）を表し、次の１ｂｙｔｅはカウンタ値を表し、次の４ｂｙｔｅｓがＭＡＣを表す。なお、図２６の例においてＭＡＣは１６進数で表記している。先頭１ｂｙｔｅの時速（ｋｍ／時）は、最低０（ｋｍ／時）〜最高１８０（ｋｍ／時）までの範囲の値を取る。図２６の上行から下行へと、ＥＣＵ３４００ａから逐次送信される各フレームに対応する各メッセージＩＤ及びデータを例示しており、カウンタ値が次第に増加し、時速が０ｋｍ／時から１ｋｍ／時ずつ加速されている様子を表している。

［３．４ ブレーキに係るＥＣＵ３４００ｂの送信フレーム例］
図２７は、ブレーキ４０２に接続されたＥＣＵ３４００ｂから送信されるデータフレームにおけるＩＤ（メッセージＩＤ）及びデータフィールド（データ）の一例を示す図である。ＥＣＵ３４００ｂが送信するフレームのメッセージＩＤは「２」である。データは、同図において１バイト毎に空白で区分して表しており、先頭の１ｂｙｔｅがブレーキのかかり具合を割合（％）で表し、次の１ｂｙｔｅはカウンタ値を表し、次の４ｂｙｔｅｓがＭＡＣを表す。なお、図２７の例においてＭＡＣは１６進数で表記している。先頭１ｂｙｔｅのブレーキのかかり具合は、ブレーキを全くかけていない状態を０（％）、ブレーキを最大限かけている状態を１００（％）としたものである。図２７の上行から下行へと、ＥＣＵ３４００ｂから逐次送信される各フレームに対応する各メッセージＩＤ及びデータを例示しており、カウンタ値が次第に増加し、ブレーキについては１００％から徐々にブレーキを弱めている様子を表している。

［３．５ ドア開閉センサに係るＥＣＵ３４００ｃの送信フレーム例］
図２８は、ドア開閉センサ４０３に接続されたＥＣＵ３４００ｃから送信されるデータフレームにおけるＩＤ（メッセージＩＤ）及びデータフィールド（データ）の一例を示す図である。ＥＣＵ３４００ｃが送信するフレームのメッセージＩＤは「３」である。データは、同図において１バイト毎に空白で区分して表しており、先頭の１ｂｙｔｅがドアの開閉状態を表し、次の１ｂｙｔｅはカウンタ値を表し、次の４ｂｙｔｅｓがＭＡＣを表す。なお、図２８の例においてＭＡＣは１６進数で表記している。先頭１ｂｙｔｅのドアの開閉状態は、ドアが開いている状態を「１」、ドアが閉まっている状態を「０」としたものである。図２８の上行から下行へと、ＥＣＵ３４００ｃから逐次送信される各フレームに対応する各メッセージＩＤ及びデータを例示しており、カウンタ値が次第に増加し、ドアが開いている状態から次第に閉められた状態へと移った様子を表している。

［３．６ 窓開閉センサに係るＥＣＵ３４００ｄの送信フレーム例］
図２９は、窓開閉センサ４０４に接続されたＥＣＵ３４００ｄから送信されるデータフレームにおけるＩＤ（メッセージＩＤ）及びデータフィールド（データ）の一例を示す図である。ＥＣＵ３４００ｄが送信するフレームのメッセージＩＤは「４」である。データは、同図において１バイト毎に空白で区分して表しており、先頭の１ｂｙｔｅが窓の開閉状態を割合（％）で表し、次の１ｂｙｔｅはカウンタ値を表し、次の４ｂｙｔｅｓがＭＡＣを表す。なお、図２９の例においてＭＡＣは１６進数で表記している。先頭１ｂｙｔｅの窓の開閉状態は、窓が完全に閉まっている状態を０（％）、窓が全開の状態を１００（％）としたものである。図２９の上行から下行へと、ＥＣＵ３４００ｄから逐次送信される各フレームに対応する各メッセージＩＤ及びデータを例示しており、カウンタ値が次第に増加し、窓が閉まっている状態から徐々に開いていく様子を表している。

［３．７ 不正検知ＥＣＵ３１００ａの構成］
図３０は、不正検知ＥＣＵ３１００ａの構成図である。不正検知ＥＣＵ３１００ａは、フレーム送受信部１６０と、フレーム解釈部３１５０と、不正ＭＡＣ検知部３１３０と、ＭＡＣ鍵保持部３１８０と、カウンタ保持部３１９０と、フレーム生成部１４０と、ＭＡＣ生成部３１７０と、不正検知カウンタ保持部１１０から構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、不正検知ＥＣＵ３１００ａにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。不正検知ＥＣＵ３１００ａは、実施の形態１で示した不正検知ＥＣＵ１００ａの一部を変形したものであり、実施の形態１と同様の機能を有する構成要素は、同じ符号を付して説明を省略する。なお、不正検知ＥＣＵ３１００ｂも同様の構成である。

フレーム解釈部３１５０は、実施の形態１で示したフレーム解釈部１５０を変形したものであり、フレーム送受信部１６０よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。フレームがデータフレームであると判断した場合においてデータフィールドと判断した値（データ）は、ＩＤフィールドのＩＤ（メッセージＩＤ）と共に、不正ＭＡＣ検知部３１３０へ転送する。また、フレーム解釈部３１５０は、ＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部１４０へ通知する。また、フレーム解釈部３１５０は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。

不正ＭＡＣ検知部３１３０は、フレーム解釈部３１５０から通知されるメッセージＩＤと、データフィールドの値（データ）を受け取ってデータフィールド中のＭＡＣを検証する機能を有する。不正ＭＡＣ検知部３１３０は、通知されたメッセージＩＤ及びデータフィールドの値を、ＭＡＣ生成部３１７０へと通知し、ＭＡＣ生成部３１７０により生成されたＭＡＣを取得する。不正ＭＡＣ検知部３１３０は、データフィールドのデータが不正を示す所定条件に該当するか否かを判定する。即ち不正ＭＡＣ検知部３１３０は、受信されたフレームにおける所定フィールドの内容が不正を示す所定条件に該当するか否かを判定する言わば判定部として機能する。この不正を示す所定条件は、定められた検証処理手順（ＭＡＣの生成、ＭＡＣの比較等を含む手順）での検証に失敗することであり、つまり、データに含まれるＭＡＣが、ＭＡＣ生成部３１７０により生成されたＭＡＣと相違するという条件である。不正ＭＡＣ検知部３１３０は、ＭＡＣ生成部３１７０から取得したＭＡＣと、データフィールド中のＭＡＣとを比較することで、不正かどうかの判定（即ちＭＡＣの検証）を行う。両ＭＡＣの値の比較の結果、不一致の場合は、不正の検知回数をインクリメントするために、受信したメッセージＩＤを不正検知カウンタ保持部１１０へ通知する。この不正の検知回数が一定回数以上に達した場合において、ヘッドユニット２００で受信されるようにエラー表示メッセージを送信するための制御については実施の形態１で説明した通りであるため、ここでの説明を省略する。また、両ＭＡＣの値の比較の結果、不一致の場合は、エラーフレームを送信するように、フレーム生成部１４０へ通知する。ＭＡＣ値の比較の結果、一致する場合は、カウンタ保持部３１９０が保持する、メッセージＩＤに対応するカウンタ値をインクリメントするようにＭＡＣ生成部３１７０へ通知する。

ＭＡＣ生成部３１７０は、不正ＭＡＣ検知部３１３０より通知されたメッセージＩＤを使って、ＭＡＣ鍵保持部３１８０より、対応するＭＡＣ鍵を取得し、カウンタ保持部３１９０より対応するカウンタをそれぞれ取得する。ＭＡＣ生成部３１７０は、不正ＭＡＣ検知部３１３０より通知されたデータフィールドの値（先頭１ｂｙｔｅの値）と、カウンタ保持部３１９０より取得したカウンタ値に対して、ＭＡＣ鍵保持部３１８０より取得したＭＡＣ鍵を使ってＭＡＣを算出（計算により導出）し、算出したＭＡＣを不正ＭＡＣ検知部３１３０へ通知する。なお、不正検知ＥＣＵ３１００ａ、３１００ｂ及びＥＣＵ３４００ａ〜３４００ｄのいずれにおいても、ＭＡＣ鍵を用いてＭＡＣを算出するアルゴリズムは同一のものを用いる。

ＭＡＣ鍵保持部３１８０は、ＭＡＣを計算するため必要となるＭＡＣ鍵をメッセージＩＤ毎に対応付けて保持する。このＭＡＣ鍵保持部３１８０が保持するＭＡＣ鍵は、対応付けられたメッセージＩＤ毎に異なる値である。なお、ＥＣＵ及び不正検知ＥＣＵにおいて用いられるＭＡＣ鍵は、１つの送信ノードが複数のメッセージＩＤそれぞれのフレームを送信する場合を想定すると、送信ノード毎に異なる鍵であることとしても良い。また、ＭＡＣ鍵は、例えば同一のバス上で送信されるフレームに同一の値が用いられるようにしても良いし、異なるバス上であっても同一の鍵（値）としても良いし、車両一台あたり同一の鍵としても良く、同一車種で同一の鍵としても良く、同一製造メーカ毎に同一の鍵としても良く、異なる製造メーカであっても同一の鍵としても良い。

カウンタ保持部３１９０は、ＭＡＣ値を計算するために必要となるカウンタ値をメッセージＩＤ毎に保持する。このカウンタ値は、フレームを正常に受信した場合（つまり不正ＭＡＣ検知部３１３０において比較した両ＭＡＣが一致する場合）には、インクリメントされる。

［３．８ カウンタ値の例］
図３１は、カウンタ保持部３１９０に保持されているメッセージＩＤ毎のカウンタ値の一例を示す図である。同図では、メッセージＩＤが「１」のカウンタが１回、メッセージＩＤが「２」のカウンタが１０回、メッセージＩＤが「３」のカウンタが１５回、メッセージＩＤが「４」のカウンタが１００回をそれぞれ示している。この各メッセージＩＤに対応するカウンタ値は、そのメッセージＩＤを含むフレームが正常に受信されている回数を表している。

［３．９ 不正フレームの検知に係るシーケンス］
以下、上述の構成を備える車載ネットワークシステム１２のバス５００ａに不正なＥＣＵが接続された場合について、バス５００ａに接続された不正検知ＥＣＵ３１００ａ、ＥＣＵ３４００ａ、ＥＣＵ３４００ｂ、ゲートウェイ３００等の動作について説明する。

図３２及び図３３は、不正検知ＥＣＵ３１００ａが不正なフレーム（メッセージ）を検知して、他のＥＣＵによりその不正なフレームに対応した処理がなされることを阻止する動作例を示すシーケンス図である。図３２及び図３３では、実施の形態１で示した図１８並びに実施の形態２で示した図２２及び図２３の場合と同様に、不正なＥＣＵが、バス５００ａに接続された例を示している。この不正なＥＣＵは、メッセージＩＤが「４」でデータフィールド（データ）が「０ｘＦＦ ＦＦ ＦＦＦＦＦＦＦＦ」（６ｂｙｔｅｓ）となるデータフレームを送信する。実施の形態１又は２で示したシーケンスと同じシーケンスには同じ符号を付しており、ここでは説明を簡略化する。

まず、不正なＥＣＵは、上述した不正なデータフレームの送信を開始する（シーケンスＳ１００１ａ）。不正検知ＥＣＵ３１００ａ、ＥＣＵ３４００ａ、ＥＣＵ３４００ｂ及びゲートウェイ３００はそれぞれメッセージＩＤを受信する（シーケンスＳ１００２）。ＥＣＵ３４００ａ、ＥＣＵ３４００ｂ及びゲートウェイ３００はそれぞれ、保持している受信ＩＤリストを用いてメッセージＩＤをチェックする（シーケンスＳ１００３）。ＥＣＵ３４００ａ及びＥＣＵ３４００ｂは、それぞれが保持している受信ＩＤリストに「４」が含まれていないため（図９参照）、受信を終了する。ゲートウェイ３００は、保持している受信ＩＤリストに「４」が含まれているため（図５参照）、受信を継続しデータフィールドの受信を行う（シーケンスＳ１００６ａ）。同様に不正検知ＥＣＵ３１００ａもデータフィールドの受信を行う（シーケンスＳ１００６ａ）。

シーケンスＳ１００６ａに続いて、不正検知ＥＣＵ３１００ａは、データフィールドにおけるデータに含まれるＭＡＣを検証（チェック）する（シーケンスＳ３００１）。即ち、不正検知ＥＣＵ３１００ａは、送信されたフレームにおけるＩＤフィールドの内容が、不正を示す所定条件（ＭＡＣの検証に失敗すること）に該当するか否かを判定する。不正検知ＥＣＵ３１００ａは、不正なＥＣＵにより送信されたデータフレームにおけるデータフィールドの６ｂｙｔｅｓのデータ「０ｘＦＦＦＦＦＦＦＦ」について、後半４ｂｙｔｅｓのＭＡＣと、メッセージＩＤ「４」に対応するＭＡＣ鍵とカウンタを用いて算定したＭＡＣとを比較することでＭＡＣの検証を行う。この比較の結果は不一致になり検証が失敗するので、不正検知ＥＣＵ３１００ａでは、不正なデータフレームであると判断し、続いてエラーフレームの発行準備を開始する（シーケンスＳ１００５）。

不正検知ＥＣＵ３１００ａがエラーフレームの発行準備をしている間に、ゲートウェイ３００はＣＲＣフィールドの受信を開始する（シーケンスＳ２００２）。

次にエラーフレームの発行準備が終わって、不正検知ＥＣＵ３１００ａがエラーフレームを送信する（シーケンスＳ１００７）。このエラーフレームの送信が開始されることによりバス５００ａでは、不正なＥＣＵから送信中のフレームのＣＲＣシーケンスの途中部分がエラーフレームにより上書きされることになる。

シーケンスＳ１００７において送信されたエラーフレームを受信したゲートウェイ３００は、ＣＲＣシーケンスを含むＣＲＣフィールドの受信途中で、不正なＥＣＵが送信していたデータフレームの受信を中止する（シーケンスＳ２００３）。

不正検知ＥＣＵ３１００ａは、エラーフレームを送信する対象となったデータフレームのＩＤ「４」に対応する不正検知カウンタをインクリメントする（シーケンスＳ１００９）。インクリメントした結果としてＩＤ「４」に対応する不正検知カウンタが１７以上となった場合、不正検知ＥＣＵ３１００ａは、エラー表示メッセージを送信する（シーケンスＳ１０１０）。

［３．１０ 実施の形態３の効果］
実施の形態３で示した不正検知ＥＣＵは、送信されたフレームが不正なフレームか否かを、フレーム（データフレーム）のデータフィールドに含ませたＭＡＣを検証することによって判定する。これにより、既存のＥＣＵ（つまり不正検知ＥＣＵ及び不正なＥＣＵ以外のＥＣＵ）において不正なフレームが解釈されてそのフレームに対応する処理が実行されることを阻止することができる。また、データフレームのデータフィールドまで受信するだけで判定ができるため、データフレームの後部を受信して判定を行う場合よりも、バスのトラフィックを抑えることが可能となる。

また、不正検知ＥＣＵが、不正検知カウンタを用いてエラーフレームを送信した回数をカウントすることで、エラーフレームの受信により不正なメッセージＩＤを送信するノードにおける送信エラーカウンタがＣＡＮプロトコルに従えばパッシブ状態に遷移すべき上限値まで到達していることを検出することができる。これにより、不正なメッセージＩＤを送信するノードが、ＣＡＮプロトコルのエラーカウンタの仕様に準拠しているか否かを判定することが可能となる。

また、ＭＡＣの検証を行うノードを不正検知ＥＣＵのみとすることで、不正検知ＥＣＵ以外のＥＣＵで検証する必要がなく、システム全体として処理量、電力消費量を抑えることができる。

（実施の形態４）
以下、本発明の実施の形態として、データフレームを受信した場合にメッセージ認証コード（ＭＡＣ）の検証に失敗した場合に、ＭＡＣを含むデータフレームの送信元のＥＣＵに対してＭＡＣの生成に利用されるデータの更新を要求する更新フレームを送信し、ＭＡＣを再度検証する不正検知ＥＣＵを含む車載ネットワークシステム１３について説明する。車載ネットワークシステム１３では、実施の形態３で示したようにＥＣＵがメッセージＩＤ、データの値及びカウンタ値から計算により生成されるＭＡＣを含ませたフレーム（データフレーム）を送信することとして、不正検知ＥＣＵが、受信したフレームにおけるＭＡＣの検証を行うものとする。車載ネットワークシステム１３では、ＭＡＣの検証に失敗した場合において、ＭＡＣの生成に利用されるＭＡＣ鍵及びカウンタ値の一方又は両方の更新等を行うための不正対処方法が実行される。

［４．１ 車載ネットワークシステム１３の全体構成］
図３４は、実施の形態４に係る車載ネットワークシステム１３の全体構成を示す図である。車載ネットワークシステム１３は、実施の形態３で示した車載ネットワークシステム１２（或いは実施の形態１で示した車載ネットワークシステム１０）の一部を変形したものである。車載ネットワークシステム１３は、バス５００ａ、５００ｂ、５００ｃと、不正検知ＥＣＵ４１００ａ、４１００ｂ、ヘッドユニット２００、ゲートウェイ３００、及び、各種機器に接続されたＥＣＵ４４００ａ〜４４００ｄ等のＥＣＵといったバスに接続された各ノードとを含んで構成される。車載ネットワークシステム１３の構成要素のうち、実施の形態１（或いは実施の形態３）と同様の機能を有する構成要素は、同じ符号を付して説明を省略する。

不正検知ＥＣＵ４１００ａ、４１００ｂは、それぞれバス５００ａ、バス５００ｂに接続され、ＥＣＵ４４００ａ〜４４００ｄ等により送信されたフレームが不正であるかどうかを判定し、不正であればエラーフレームを送信する機能、ＭＡＣ鍵及びカウンタ値の一方又は両方の更新を指示する更新フレームを送信する機能等を有するＥＣＵである。更新フレームとしては具体的には、ＭＡＣ鍵の更新を指示する鍵更新フレーム、ＭＡＣ鍵の更新及びカウンタ値のリセットを指示する鍵更新＆カウンタリセットフレーム、並びに、カウンタのリセットを指示するカウンタリセットフレームがある。この更新フレームのうち、鍵更新フレーム、及び、鍵更新＆カウンタリセットフレームは、ＭＡＣ鍵の更新を要求するためのフレームとしての性質を有する、言わばＭＡＣ鍵更新要求フレームである。また、更新フレームのうち、カウンタリセットフレーム、及び、鍵更新＆カウンタリセットフレームは、カウンタ値の更新（リセット）を要求するためのフレームとしての性質を有する、言わばカウンタリセット要求フレームである。データフレームのデータフィールドにＭＡＣを格納する例を実施の形態３で示したが、データフィールドに格納できるＭＡＣのデータ長は十分に長いとは言えない。これに対し、車載ネットワークシステム１３においてＭＡＣ鍵の更新或いはカウンタ値のリセットを適時に行うことで、不正なＥＣＵによるＭＡＣに対する総当り攻撃等への耐性を高める効果が生じる。

ＥＣＵ４４００ａ〜４４００ｄは、いずれかのバスと接続され、また、それぞれエンジン４０１、ブレーキ４０２、ドア開閉センサ４０３、窓開閉センサ４０４に接続されている。ＥＣＵ４４００ａ〜４４００ｄのそれぞれは、接続されている機器（エンジン４０１等）の状態を取得し、定期的に状態を表すデータフレームをネットワーク（つまりバス）に送信している。送信されるデータフレームのデータフィールドには、メッセージＩＤとデータ値と送信毎にインクリメントされるカウンタ値とから計算により導出されるメッセージ認証コード（ＭＡＣ）が付与される。

［４．２ ＥＣＵ４４００ａの構成］
図３５は、ＥＣＵ４４００ａの構成図である。ＥＣＵ４４００ａは、フレーム送受信部４６０と、フレーム解釈部４５０と、受信ＩＤ判断部４３０と、受信ＩＤリスト保持部４４０と、フレーム処理部４１０と、フレーム生成部３４２０と、データ取得部４７０と、ＭＡＣ生成部３４１０と、ＭＡＣ鍵保持部４４３０と、カウンタ保持部３４４０と、ＭＡＣ鍵更新部４４１０と、カウンタリセット部４４２０とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、ＥＣＵ４４００ａにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。ＥＣＵ４４００ａは、実施の形態３で示したＥＣＵ３４００ａ（或いは実施の形態１で示したＥＣＵ４００ａ）の一部を変形したものであり、実施の形態１及び３と同様の機能を有する構成要素は、同じ符号を付して説明を省略する。

ＭＡＣ鍵保持部４４３０は、メモリ等の記憶媒体により実現され、ＭＡＣ鍵を識別する鍵ＩＤ毎について、更新前と更新後との２つのＭＡＣ鍵（ＭＡＣを計算するために必要となる鍵）を対応付けた鍵テーブルを保持する。鍵テーブル及びＭＡＣ鍵の更新については後に図３９を用いて説明する。ここでは、メッセージＩＤ毎に異なるＭＡＣ鍵を利用することとし、このため鍵ＩＤはメッセージＩＤと同じである。なお、ＭＡＣ生成部３４１０によりＭＡＣが生成される場合には特に言及しない限り基本的に更新後のＭＡＣ鍵が用いられる。

カウンタ保持部３４４０は、メモリ等の記憶媒体により実現され、カウンタ鍵を識別するカウンタＩＤ毎について、カウンタ値を対応付けたカウンタテーブルを保持する。カウンタテーブル及びカウンタ値の更新（リセット）については後に図４０を用いて説明する。ここでは、メッセージＩＤ毎に異なるカウンタを利用することとし、このためカウンタＩＤはメッセージＩＤと同じである。

ＭＡＣ鍵更新部４４１０は、フレーム送受信部４６０で鍵更新フレーム或いは鍵更新＆カウンタリセットフレームが受信された場合に、これらのフレームに従ってＭＡＣ鍵保持部４４３０が保持するＭＡＣ鍵を更新する。

カウンタリセット部４４２０は、フレーム送受信部４６０でカウンタリセットフレーム或いは鍵更新＆カウンタリセットフレームが受信された場合に、これらのフレームに従ってカウンタ保持部３４４０が保持するカウンタ値をリセットする。

なお、ＥＣＵ４４００ｂ〜４４００ｄは、それぞれ実施の形態３で示したＥＣＵ３４００ｂ〜３４００ｄの一部を変形したものであり、上述したＥＣＵ４４００ａと基本的に同様の構成を備える。但し、受信ＩＤリスト保持部４４０に保持される受信ＩＤリスト、ＭＡＣ鍵保持部４４３０に保持される鍵テーブル、及び、カウンタ保持部３４４０に保持されるカウンタテーブルは、ＥＣＵ毎に異なる内容となり得る。また、フレーム処理部４１０の処理内容は、実施の形態１で示したようにＥＣＵ毎に異なる。

［４．３ 不正検知ＥＣＵ４１００ａの構成］
図３６は、不正検知ＥＣＵ４１００ａの構成図である。不正検知ＥＣＵ４１００ａは、フレーム送受信部１６０と、フレーム解釈部４１５１と、不正ＭＡＣ検知部４１３１と、ＭＡＣ鍵保持部４１８０と、カウンタ保持部３１９０と、フレーム生成部１４０と、ＭＡＣ生成部３１７０と、ＭＡＣ鍵更新部４１１０と、カウンタリセット部４１２０と、セキュリティ処理部４１３０と、セキュリティ条件保持部４１４０と、不正ＩＤリスト保持部４１５０と、不正ログ保持部４１６０と、モード変更処理部４１７０とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、不正検知ＥＣＵ４１００ａにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。不正検知ＥＣＵ４１００ａは、実施の形態３で示した不正検知ＥＣＵ３１００ａ（或いは実施の形態１で示した不正検知ＥＣＵ１００ａ）の一部を変形したものであり、実施の形態１及び３と同様の機能を有する構成要素は、同じ符号を付して説明を省略する。なお、不正検知ＥＣＵ４１００ｂも同様の構成である。

フレーム解釈部４１５１は、実施の形態３で示したフレーム解釈部３１５０の一部を変形して機能を追加したものである。フレーム解釈部４１５１は、フレーム送受信部１６０よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。フレームがデータフレームであると判断した場合においてデータフィールドと判断した値（データ）は、ＩＤフィールドのＩＤ（メッセージＩＤ）と共に、不正ＭＡＣ検知部４１３１へ転送する。また、フレーム解釈部４１５１は、ＣＡＮプロトコルに則っていないフレームと判断した場合或いはメッセージＩＤが不正ＩＤリスト保持部４１５０により保持される不正ＩＤリストに含まれるＩＤである場合には、エラーフレームを送信するようにフレーム生成部１４０へ通知する。また、フレーム解釈部４１５１は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。

ＭＡＣ鍵保持部４１８０は、メモリ等の記憶媒体により実現され、ＭＡＣ鍵を識別する鍵ＩＤ毎について、更新前と更新後との２つのＭＡＣ鍵（ＭＡＣを計算するために必要となる鍵）を対応付けた鍵テーブルを保持する。ここでは、メッセージＩＤ毎に異なるＭＡＣ鍵を利用することとし、このため鍵ＩＤはメッセージＩＤと同じである。なお、ＭＡＣ生成部３１７０によりＭＡＣが生成される場合には特に言及しない限り基本的に更新後のＭＡＣ鍵が用いられる。

カウンタ保持部３１９０は、メモリ等の記憶媒体により実現され、カウンタ鍵を識別するカウンタＩＤ毎について、カウンタ値（ＭＡＣを計算するために必要となるカウンタ値）を対応付けたカウンタテーブルを保持する。ここでは、メッセージＩＤ毎に異なるカウンタを利用することとし、このためカウンタＩＤはメッセージＩＤと同じである。このカウンタ値は、フレームが正常に受信された場合には、インクリメントされる。

ＭＡＣ鍵更新部４１１０は、フレーム送受信部１６０で鍵更新フレーム或いは鍵更新＆カウンタリセットフレームが受信された場合に、これらのフレームに従ってＭＡＣ鍵保持部４１８０が保持するＭＡＣ鍵を更新する。

カウンタリセット部４１２０は、フレーム送受信部１６０でカウンタリセットフレーム或いは鍵更新＆カウンタリセットフレームが受信された場合に、これらのフレームに従ってカウンタ保持部３１９０が保持するカウンタ値をリセットする。

不正ＭＡＣ検知部４１３１は、実施の形態３で示した不正ＭＡＣ検知部３１３０の一部を変形したものであり、フレーム解釈部４１５１から通知されるメッセージＩＤと、データフィールドの値（データ）を受け取ってデータフィールド中のＭＡＣを検証する機能を有する。不正ＭＡＣ検知部４１３１は、通知されたメッセージＩＤ及びデータフィールドの値を、ＭＡＣ生成部３１７０へと通知し、ＭＡＣ生成部３１７０により生成されたＭＡＣを取得する。不正ＭＡＣ検知部４１３１は、データフィールドのデータが不正を示す所定条件に該当するか否かを判定する。この不正を示す所定条件は、定められた検証処理手順（ＭＡＣの生成、ＭＡＣの比較等を含む手順）での検証に失敗することであり、つまり、データに含まれるＭＡＣが、ＭＡＣ生成部３１７０により生成されたＭＡＣと相違するという条件である。不正ＭＡＣ検知部４１３１は、ＭＡＣ生成部３１７０から取得したＭＡＣと、データフィールド中のＭＡＣとを比較することで、不正かどうかの判定（即ちＭＡＣの検証）を行う。両ＭＡＣの値の比較の結果、不一致の場合は、セキュリティ条件保持部４１４０のセキュリティ条件テーブルにおける該当メッセージＩＤの不正カウントをインクリメントする。また、両ＭＡＣの値の比較の結果、不一致の場合は、エラーフレームを送信するように、フレーム生成部１４０へ通知する。また、両ＭＡＣの値の比較の結果、不一致の場合はさらに、自機（不正検知ＥＣＵ４１００ａ）とデータフレームの送信元のＥＣＵの間でＭＡＣ鍵或いはカウンタ値が同期して更新されていない可能性があるので、更新フレームを送信するようにフレーム生成部１４０へ依頼する。この場合に送信する更新フレームは、基本的に鍵更新＆カウンタリセットフレームである。但し、鍵更新＆カウンタリセットフレームの代わりに、鍵更新フレーム及びカウンタリセットフレームを順次送信することとしても良い。なお、不正ＭＡＣ検知部４１３１は、鍵更新＆カウンタリセットフレームを送信するようにフレーム生成部１４０へ依頼する前に、更新前のＭＡＣ鍵を用いてＭＡＣを生成することで上述のデータフィールドに含まれるＭＡＣを再び検証しても良い。この再検証で成功した場合（つまり両ＭＡＣが一致した場合）には、カウンタが同期していると推定してＭＡＣ鍵の同期のみを必要とし、不正ＭＡＣ検知部４１３１は、鍵更新＆カウンタリセットフレームの代わりに鍵更新フレームを送信するようにフレーム生成部１４０に依頼しても良い。また、再検証でも失敗した場合において、カウンタが同期していない可能性に鑑みて、カウンタリセットフレームを送信する方法も採り得る。また、不正ＭＡＣ検知部４１３１は、ＭＡＣの検証に成功した場合（比較した両ＭＡＣの値が一致した場合）には、カウンタ保持部３１９０が保持する、メッセージＩＤに対応するカウンタ値をインクリメントするようにＭＡＣ生成部３１７０へ通知する。

セキュリティ条件保持部４１４０は、メモリ等の記憶媒体により実現され、更新フレーム（鍵更新フレーム、カウンタリセットフレーム或いは鍵更新＆カウンタリセットフレーム）を送信したにもかかわらず、その後のＭＡＣの検証の結果として検証失敗（生成したＭＡＣの値と受信したデータフィールド中のＭＡＣの値との比較の結果として不一致の状態）が続く場合における対処処理であるセキュリティアクションを定義したセキュリティ条件テーブル６２０を保持する。セキュリティ条件テーブル６２０については後に図４１を用いて説明する。

セキュリティ処理部４１３０は、セキュリティ条件保持部４１４０が保持するセキュリティ条件テーブル６２０に従って、セキュリティアクションを実行する。セキュリティアクションには、ＭＡＣの検証に失敗したフレームのメッセージＩＤを不正ＩＤリスト保持部４１５０が保持する不正ＩＤリストに追加する処理、そのメッセージＩＤを不正ログ保持部４１６０が保持するログに記録する処理、車両を安全状態にするようモード変更処理部４１７０に指示する処理等がある。

不正ＩＤリスト保持部４１５０は、メモリ等の記憶媒体により実現され、不正と判断されたデータフレーム（ＭＡＣの検証に失敗したデータフレーム等）のメッセージＩＤを列挙するための不正ＩＤリストを保持する。

不正ログ保持部４１６０は、メモリ、ハードディスク等の記憶媒体（記録媒体）により実現され、不正なデータフレームが送信されたこと等といったイベントを記録するためのログを保持する。ログに記録されるイベントに係る情報としては、例えば、不正なデータフレームのメッセージＩＤ、不正なデータフレームが送信された日時、不正なデータフレームが送信された回数等が挙げられる。なお、ログが改ざんされないようにログの内容にデジタル署名等を付加したり、ログの内容を暗号化したりしても良い。

モード変更処理部４１７０は、セキュリティ処理部４１３０から車両を安全状態にするよう指示された場合に、車両を安全状態（例えば一定速度以下に速度を限定した状態等）にすべきことを他のＥＣＵに伝達するために予め定められたフレームであるモード変更フレームをフレーム生成部１４０に生成させる。モード変更フレームがフレーム生成部１４０に生成され、フレーム送受信部１６０により送信されると、他のＥＣＵは、モード変更フレームを受信して予め定められた制御（例えば車両のエンジンの回転数を一定回転以下に限定する制御等）を実行することができる。なお、車両を安全状態にするために予め定められた制御内容は、特に車両の速度を低速にすることに限られない。

［４．４ ＥＣＵ４４００ａの受信ＩＤリスト例］
図３７は、ＥＣＵ４４００ａの受信ＩＤリスト保持部４４０に保持される受信ＩＤリストの一例を示す図である。ＥＣＵ４４００ａは、バスを流れるフレームのうち、受信ＩＤリストに列挙されたメッセージＩＤのいずれかを含むフレームを選択的に受信して処理する。ＥＣＵ４４００ａは、ＭＡＣ鍵の更新を指示する鍵更新フレーム、カウンタ値の更新を指示するカウンタリセットフレーム、及び、ＭＡＣ鍵更新とカウンタリセットとを指示する鍵更新＆カウンタリセットフレームを受信するため、これらのＩＤが受信ＩＤリストに登録される。図３７に示す受信ＩＤリストの例において「２００１」が鍵更新フレームのＩＤであり、「２００２」がカウンタリセットフレームのＩＤであり、「２００３」が鍵更新＆カウンタリセットフレームのＩＤである。なお、ＥＣＵ４４００ｂにおいても同様の受信ＩＤリストが保持される。なお、本実施の形態では、ＭＡＣ鍵等の更新の同期をとる必要があるため、ゲートウェイ３００が保持する受信ＩＤリスト（図５参照）には更に、鍵更新フレームのＩＤ「２００１」、カウンタリセットフレームのＩＤ「２００２」及び鍵更新＆リセットフレームのＩＤ「２００３」が含まれているものとする。

［４．５ 更新フレーム］
図３８は、更新フレームの一例を示す図である。同図では、更新フレームのうち鍵更新＆カウンタリセットフレームの例を挙げているが、鍵更新フレーム及びカウンタリセットフレームについても同様の構成である。

ＭＡＣ鍵更新＆カウンタリセットフレームでは、ＩＤフィールドのメッセージＩＤとしては、「２００３」という鍵更新＆カウンタリセットＩＤ（鍵更新＆カウンタリセットフレーム用のＩＤ）が用いられる。また、データフィールドには、ＭＡＣ鍵更新、カウンタリセット等の対象となるメッセージＩＤ（更新対象ＩＤ）とＭＡＣとが設定される。図３８において（ａ）は、メッセージＩＤを問わず全てのＭＡＣ鍵更新とカウンタリセットとを一度に行うことを指示する鍵更新＆カウンタリセットフレームの具体例を示している。「０ｘＦＦＦＦ」というデータにより全てのメッセージＩＤを表すこととしている。また、図３８において（ｂ）は、「４」というメッセージＩＤについてのＭＡＣ鍵更新とカウンタリセットとを一度に行うことを指示する鍵更新＆カウンタリセットフレームの具体例を示している。

［４．６ 鍵テーブル］
図３９は、不正検知ＥＣＵ４１００ａのＭＡＣ鍵保持部４１８０に保持される鍵テーブルの一例を示す図である。鍵テーブルは、鍵ＩＤと、更新前のＭＡＣ鍵であるのか、更新後のＭＡＣ鍵であるのかを識別するための更新情報と、鍵値とを対応付けて構成される。ＭＡＣ鍵を更新する際に、ＭＡＣ鍵更新部４１１０で生成された新しいＭＡＣ鍵は「更新後」の鍵値としてテーブルに書き込まれ、それまで利用していたＭＡＣ鍵は「更新前」の鍵値として記録される。ここでは、メッセージＩＤ毎に異なるＭＡＣ鍵を利用することとし、このため鍵ＩＤはメッセージＩＤと同じである。不正検知ＥＣＵ４１００ａは、自機が受信し得るフレームに対応して複数の鍵ＩＤのＭＡＣ鍵を保持している。また、不正検知ＥＣＵ４１００ａと同様に、不正検知ＥＣＵ４１００ｂ及びＥＣＵ４４００ａ〜４４００ｄのそれぞれも、自機が送信又は受信するフレームのメッセージＩＤ毎について更新前後のＭＡＣ鍵を対応付けて格納するためのＭＡＣ鍵テーブルを保持する。

不正検知ＥＣＵ４１００ａ等のＭＡＣ鍵更新部４１１０或いはＥＣＵ４４００ａ等のＭＡＣ鍵更新部４４１０においてＭＡＣ鍵を更新する方法は、例えば、ＭＡＣの生成の際に用いられる「更新後」の鍵値（ＭＡＣ鍵）を、「更新前」の鍵値として鍵テーブルに記録し、その「更新後」のＭＡＣ鍵を、予め定められた一方向関数（例えばハッシュ関数等）に入力して導出される結果を新たなＭＡＣ鍵として、つまり新たに「更新後」の鍵値として、鍵テーブルに記録する手順等による。新たなＭＡＣ鍵を導出する演算としては、入力されたシードに基づいて予め定められたアルゴリズムで新たなＭＡＣ鍵を出力する関数を用いても良い。この場合には、例えば、ＭＡＣ鍵の更新を指示する更新フレーム（鍵更新フレーム又は鍵更新＆カウンタリセットフレーム）のデータフィールド中にシードを含ませるようにしても良いし、カウンタ値、現在時刻の情報等をシードとして利用することとしても良い。即ち、ＭＡＣ鍵を同期して更新すべき複数のＥＣＵ（或いは不正検知ＥＣＵ）の間で、同一のＭＡＣ鍵が生成できれば良い。

［４．７ カウンタテーブル］
図４０は、不正検知ＥＣＵ４１００ａのカウンタ保持部３１９０に保持されるカウンタテーブルの一例を示す図である。カウンタテーブルは、カウンタＩＤと、カウンタ値とを対応付けて構成される。ここでは、メッセージＩＤ毎に異なるカウンタを利用することとし、このためカウンタＩＤはメッセージＩＤと同じである。不正検知ＥＣＵ４１００ａは、自機が受信し得るフレームに対応して複数のカウンタＩＤのカウンタ値を保持している。また、不正検知ＥＣＵ４１００ａと同様に、不正検知ＥＣＵ４１００ｂ及びＥＣＵ４４００ａ〜４４００ｄのそれぞれも、自機が送信又は受信するフレームのメッセージＩＤ毎についてカウンタ値を対応付けて格納するためのカウンタテーブルを保持する。カウンタテーブルのメッセージＩＤと対応したカウンタ値は、そのメッセージＩＤのフレームが正常に送信又は受信された場合にインクリメント（１増加）される。この方法として、データフレームを送信する場合においてはカウンタ値を送信カウンタとして扱い、送信回数をカウントする。また、データフレームを受信する場合においてはカウンタ値を受信カウンタとして扱い、受信回数をカウントする。例えば、メッセージＩＤが「１」のデータフレームを送信するＥＣＵ４４００ａにおいては、カウンタテーブルのカウンタＩＤが「１」に対応するカウンタ値を、送信カウンタとして扱い、１回送信する毎に送信カウンタをインクリメントする。また、例えばメッセージＩＤが「１」のデータフレームを受信するＥＣＵ４４００ｂにおいては、カウンタテーブルのカウンタＩＤが「１」に対応するカウンタ値を、受信カウンタとして扱い、送信されたデータフレームが正常に受信された毎に受信カウンタをインクリメントする。

不正検知ＥＣＵ４１００ａ等のカウンタリセット部４１２０或いはＥＣＵ４４００ａ等のカウンタリセット部４４２０におけるカウンタ値のリセットは、例えばゼロ等の予め定めた特定値になるようカウンタ値を更新することで実現される。カウンタ値を同期して更新（リセット）すべき複数のＥＣＵ（或いは不正検知ＥＣＵ）の間で、リセット後に同一のカウンタ値が保持されるのであれば、特定値は必ずしもゼロでなくても良い。

［４．８ セキュリティ条件テーブル６２０］
図４１は、セキュリティ条件保持部４１４０が保持するセキュリティ条件テーブル６２０の一例を示す図である。セキュリティ条件テーブル６２０は、機能分類６２１、メッセージＩＤ６２２、不正カウント６２３、不正カウント閾値６２４、セキュリティアクション６２５から構成される。機能分類６２１は、フレーム（データフレーム）の内容とされるデータ或いはその送信元のＥＣＵが関連する機能（送信元のＥＣＵが接続された機器の機能等）によりフレームのメッセージＩＤを分類するための項目である。車載ネットワークシステム１３における複数のバスのそれぞれが、バスに接続されたＥＣＵに関連する機能の面で、複数種類のグループ（機能グループ）のいずれか１つ或いは複数のグループに属している。従って、機能分類６２１は、対応するメッセージＩＤのフレームがどのバスで送信されるか、つまり、複数種類のグループのうちのいずれのグループに属するバスで送信されるかを示すものとも言える。「駆動系」は、エンジン、モータ、燃料、電池、トランスミッションの制御等といった車両の走行に関連する機能であり、例えばＥＣＵ４４００ａに対応する。「シャーシ系」は、ブレーキ、ステアリング等の「曲がる」、「止まる」等といった車両の挙動等の制御に関連する機能であり、例えばＥＣＵ４４００ｂが対応する。「ボディ系」は、ドアロック、エアコン、ライト、ウィンカー等といった車両の装備の制御機能であり、例えばＥＣＵ４４００ｃ、４４００ｄが対応する。また、例えば「安全快適機能」は、自動ブレーキ、車線維持機能、車間距離維持機能、衝突防止機能等といった自動的に安全で快適な運転を実現するための機能であり、「ＩＴＳ（Intelligent Transport Systems）機能」は、ＥＴＣ（Electronic Toll Collection System）等の高度道路交通システムに対応した機能であり、「テレマティクス」は、車両盗難時の追跡等といった移動体通信を用いたサービスに対応する機能であり、「インフォテイメント」は、カーナビゲーション、オーディオ等に関連したエンターテイメント機能である。メッセージＩＤ６２２は、ＣＡＮプロトコルにおけるフレームのＩＤである。不正カウント６２３は、ＭＡＣの検証に失敗した回数（エラー発生回数）を格納するための項目（領域）である。不正カウント閾値６２４は、不正カウント６２３の値がこの閾値以上になった場合にセキュリティアクションが実行されるところの閾値を示す。セキュリティアクション６２５は、不正カウント６２３の値が、不正カウント閾値６２４が示す閾値以上となった場合に実行される、不正への対処処理である各種のセキュリティアクションについて、その実行を行うか否かを定めた情報である。図４１に示すように、セキュリティアクション６２５は、ＭＡＣの検証に失敗したメッセージＩＤを不正ＩＤリストに追加するか否か、不正があったことをヘッドユニット２００に通知するか否か、不正があったことについてログに記録するか否か、モード変更処理部４１７０に車両を安全状態にするためのモード変更を行う指示を出すか否かを定めている。

図４１に示すセキュリティ条件テーブル６２０では、「駆動系」及び「シャーシ系」については、不正カウント閾値６２４を「５」に設定し、「ボディ系」については、不正カウント閾値６２４を「１０」に設定している。図４１の例では、セキュリティアクション６２５は、全ての機能分類について、不正なフレーム（検証に失敗したフレーム）のメッセージＩＤの不正ＩＤリストへの追加、及び、不正があったことのヘッドユニット２００への通知については実行される旨を示す「有効」にしている。また、車両を安全状態にするためのモード変更を行う指示（「有効（安全状態に移行）」）は、「駆動系」、「シャーシ系」及び「安全快適機能」といった安全面に関連する機能分類についてのみ定めている。セキュリティ条件テーブル６２０では、このように機能分類別にセキュリティアクションの実行条件及び処理内容を定義できる。なお、セキュリティ条件テーブル６２０の内容は、例えば車載ネットワークシステムの製造時、販売時等において設定し得る。

［４．９ 不正ＩＤリスト］
図４２は、不正ＩＤリスト保持部４１５０が保持する不正ＩＤリストの一例を示す図である。不正ＩＤリストには、セキュリティ条件テーブルのセキュリティアクション６２５として不正ＩＤリストの追加が「有効」と定められているメッセージＩＤのフレームを不正と判断した場合（つまりそのフレームのＭＡＣの検証に失敗した場合）に、セキュリティ処理部４１３０によってメッセージＩＤが追加される。なお、不正ＩＤリストには、車載ネットワークシステム１３において送信されるはずがないメッセージＩＤを予め含ませておいても良い。

［４．１０ 不正フレームの検知及びセキュリティアクションに係るシーケンス］
以下、上述の構成を備える車載ネットワークシステム１３のバス５００ａに不正なＥＣＵが接続された場合について、バス５００ａに接続された不正検知ＥＣＵ４１００ａ、ＥＣＵ４４００ａ、ＥＣＵ４４００ｂ、ゲートウェイ３００等の動作について説明する。

図４３〜図４５は、不正検知ＥＣＵ４１００ａによる不正なフレーム（メッセージ）の検知、各ＥＣＵにおけるＭＡＣ鍵の更新及びカウンタ値のリセット、並びに、不正検知ＥＣＵ４１００ａによるセキュリティアクションの動作例を示すシーケンス図である。ここでは、不正検知ＥＣＵ４１００ａが保持するセキュリティ条件テーブルは図４１に例示する内容であることとして説明する。ここでは、不正なＥＣＵが、バス５００ａに接続された例を想定している。この不正なＥＣＵは、メッセージＩＤが「４」でデータフィールドにデータ「０ｘＦＦ」等を含ませたデータフレームを送信する。

まず、不正なＥＣＵは、上述した不正なデータフレームの送信を開始する（シーケンスＳ４００１）。不正検知ＥＣＵ４１００ａ、ＥＣＵ４４００ａ、ＥＣＵ４４００ｂ及びゲートウェイ３００はそれぞれメッセージＩＤを受信する（シーケンスＳ４００２）。ＥＣＵ４４００ａ、ＥＣＵ４４００ｂ及びゲートウェイ３００はそれぞれ、保持している受信ＩＤリストを用いてメッセージＩＤをチェックする（シーケンスＳ４００３）。ＥＣＵ３４００ａ及びＥＣＵ３４００ｂは、それぞれが保持している受信ＩＤリストに「４」が含まれていないため（図３７参照）、受信を終了する。ゲートウェイ３００は、保持している受信ＩＤリストに「４」が含まれているため（図５参照）、受信を継続しデータフィールドの受信を行う（シーケンスＳ４００４）。同様に不正検知ＥＣＵ４１００ａもデータフィールドの受信を行う（シーケンスＳ４００４）。

シーケンスＳ４００４に続いて、不正検知ＥＣＵ４１００ａは、データフィールドにおけるデータに含まれるＭＡＣを検証する（シーケンスＳ４００５）。即ち、不正検知ＥＣＵ４１００ａは、送信されたフレームにおけるデータフィールドのデータにおけるＭＡＣが含まれるはずの所定位置の内容と、ＭＡＣ鍵（つまり鍵テーブルにおいてＩＤ「４」に対応する「更新後」の鍵値として保持されているＭＡＣ鍵）等を用いてＭＡＣ生成部３１７０により生成したＭＡＣとを比較することでＭＡＣを検証する。不正なＥＣＵにより送信された不正なデータフレームには正しいＭＡＣは格納されていないため、比較の結果が不一致となり、ＭＡＣの検証に失敗する。ＭＡＣの検証に失敗した場合に、不正検知ＥＣＵ４１００ａでは、セキュリティ条件テーブル６２０のメッセージＩＤ「４」に対応する不正カウント６２３の値をインクリメントする。

車載ネットワークシステム１３において、不正なＥＣＵが接続されている可能性があれば不正なＥＣＵからのＭＡＣに対する総当り攻撃等への耐性を高めるべく、ＭＡＣの生成に用いられるデータの更新（つまりＭＡＣ鍵の更新或いはカウンタ値のリセット）を行うことが有用である。このデータの更新に関連して、ＭＡＣの検証に失敗した場合には、正規なＥＣＵとの間でＭＡＣ鍵又はカウンタ値の同期に失敗している可能性がある。また、不正なＥＣＵが送信した不正なデータフレームによりＭＡＣの検証に失敗した可能性もある。そこで、これらを鑑みて不正検知ＥＣＵ４１００ａは、ＭＡＣの検証に失敗した場合には、更新フレームを送信することとしている。即ち、不正検知ＥＣＵ４１００ａは、ＭＡＣの検証に失敗した場合に、フレーム生成部１４０によりメッセージＩＤが「４」を更新対象ＩＤとして設定した鍵更新＆カウンタリセットフレーム（図３８参照）を生成し（シーケンスＳ４００６）、フレーム送受信部１６０により鍵更新＆カウンタリセットフレームを送信する（シーケンスＳ４００７）。

ＥＣＵ４４００ａ，ＥＣＵ４４００ｂ及びゲートウェイ３００は、受信ＩＤリストに更新フレームである鍵更新＆カウンタリセットフレームのメッセージＩＤ「２００３」が含まれているため、鍵更新＆カウンタリセットフレームを受信する（シーケンスＳ４００８）。

続いてＥＣＵ４４００ａ，ＥＣＵ４４００ｂ及びゲートウェイ３００は、受信した更新フレームがＭＡＣ鍵の更新を指示するものであるか否かを判断して（シーケンスＳ４００９）、ＭＡＣ鍵の更新を指示する鍵更新フレーム又は鍵更新＆カウンタリセットフレームであれば、ＭＡＣ鍵の更新を行う（シーケンスＳ４０１０）。

また、ＥＣＵ４４００ａ，ＥＣＵ４４００ｂ及びゲートウェイ３００は、受信した更新フレームがカウンタ値の更新（リセット）を指示するものであるか否かを判断して（シーケンスＳ４０１１）、カウンタ値のリセットを指示するカウンタリセットフレーム又は鍵更新＆カウンタリセットフレームであれば、カウンタ値のリセットを行う（シーケンスＳ４０１２）。

なお、図４４では省略しているが、不正検知ＥＣＵ４１００ａも、シーケンスＳ４００８〜Ｓ４０１２の処理手順を行い、同様にメッセージＩＤ「４」に対応するＭＡＣ鍵の更新及びカウンタ値のリセットを行い得る。

また、不正検知ＥＣＵ４１００ａは、セキュリティ条件テーブル６２０のいずれかのメッセージＩＤに対応する不正カウント６２３の値が、不正カウント閾値６２４が示す閾値以上になったか否かを判断し（シーケンスＳ４０１３）、閾値以上になった場合にはセキュリティアクション処理（図４６）を行う（シーケンスＳ４０１４）。ここで、図４５でのシーケンスの説明を中断して、このセキュリティアクション処理について図４６に即して説明する。なお、セキュリティ条件テーブル６２０におけるメッセージＩＤ「４」に対応する不正カウント６２３の値が、不正カウント閾値６２４が示す閾値以上になった例を用いて説明する。

図４６は、不正検知ＥＣＵ４１００ａにおけるセキュリティアクション処理を示すフローチャートである。

不正検知ＥＣＵ４１００ａは、セキュリティ条件テーブル６２０における不正カウント６２３の値が、不正カウント閾値６２４により示される閾値以上となったメッセージＩＤ（図４５のシーケンスの例では「４」）に対応するセキュリティアクション６２５に従って、不正ＩＤリストへの追加が「有効」であるか否かを判別する（ステップＳ４０２０）。「有効」であれば、不正検知ＥＣＵ４１００ａのセキュリティ処理部４１３０は、不正ＩＤリスト保持部４１５０が保持する不正ＩＤリストにメッセージＩＤを追加する（ステップＳ４０２１）。

また、不正検知ＥＣＵ４１００ａは、セキュリティ条件テーブル６２０におけるメッセージＩＤ「４」に対応するセキュリティアクション６２５に従って、ヘッドユニットへの通知が「有効」であるか否かを判別する（ステップＳ４０２２）。「有効」であれば、不正検知ＥＣＵ４１００ａのセキュリティ処理部４１３０は、不正なフレームの送信が行われた旨を示す情報を含むフレームを送信する制御等によりヘッドユニット２００への通知を行う（ステップＳ４０２３）。

また、不正検知ＥＣＵ４１００ａは、セキュリティ条件テーブル６２０におけるメッセージＩＤ「４」に対応するセキュリティアクション６２５に従って、ログの記録が「有効」であるか否かを判別する（ステップＳ４０２４）。「有効」であれば、不正検知ＥＣＵ４１００ａのセキュリティ処理部４１３０は、不正ログ保持部４１６０が保持するログに不正なフレームの送信が行われたことに係るイベントの情報を追記する（ステップＳ４０２５）。

また、不正検知ＥＣＵ４１００ａは、セキュリティ条件テーブル６２０におけるメッセージＩＤ「４」に対応するセキュリティアクション６２５に従って、車両を安全状態にするためのモード変更することが「有効」か否かを判別する（ステップＳ４０２６）。「有効」であれば、不正検知ＥＣＵ４１００ａのセキュリティ処理部４１３０は、モード変更処理部４１７０に車両を安全状態にするためのモード変更を行う指示を出す（ステップＳ４０２７）。

メッセージＩＤ「４」に対応する不正カウント６２３の値が、不正カウント閾値６２４が示す閾値以上になった場合においては、不正ＩＤリストへのメッセージＩＤの追加（ステップＳ４０２１）、及び、不正なフレームの送信に係る情報のヘッドユニット２００への通知（ステップＳ４０２３）が、実行されることになる。

以下、再び図４５でのシーケンスの説明に戻る。

ここでは、不正検知ＥＣＵ４１００ａが上述のセキュリティアクション処理を行った後において、メッセージＩＤが「４」でデータフィールドにデータ「０ｘＦＦ」等を含ませたデータフレームを不正なＥＣＵが再び送信したとする（シーケンスＳ４０１５）。

この時点では、不正検知ＥＣＵ４１００ａが受信したメッセージＩＤ「４」と同一のメッセージＩＤが、不正ＩＤリスト保持部４１５０により保持される不正ＩＤリストに含まれているため（シーケンスＳ４０１６）、不正検知ＥＣＵ４１００ａのフレーム解釈部４１５１はフレーム生成部１４０にエラーフレームを生成させる（シーケンスＳ４０１７）。

続いて不正検知ＥＣＵ４１００ａは、エラーフレームをフレーム送受信部１６０により送信する（シーケンスＳ４０１８）。これにより、不正なＥＣＵによるメッセージＩＤ「４」のデータフレームの送信が完了する前に、そのデータフレームの一部がエラーフレームにより上書きされることになる。従って、他のＥＣＵが不正なデータフレームを受信して対応した処理を行ってしまうことが阻止される。なお、データフレームを受信した際に、もし不正ＩＤリストに、受信したメッセージＩＤと同一のメッセージＩＤが含まれていない場合には、不正検知ＥＣＵ４１００ａは、データフレームの受信を継続し（シーケンスＳ４０１９）、シーケンスＳ４００４からシーケンスＳ４０１４の手順を実行する。

［４．１１ 実施の形態４の効果］
実施の形態４で示した車載ネットワークシステム１３においては、不正検知ＥＣＵと正当なＥＣＵとの間でＭＡＣ鍵の更新或いはカウンタ値のリセットの同期がとれずにデータフレームでのＭＡＣの検証に失敗する場合に、不正検知ＥＣＵからＭＡＣ鍵更新又はカウンタ値のリセットを指示する更新フレームを送信することで、同期ずれが解消され得る。また、ＭＡＣ鍵更新及びカウンタ値のリセットを正しく行えない不正なＥＣＵを判別できることになり、不正なＥＣＵからのフレームに基づき、他のＥＣＵがそのフレームに従って処理を行うことを阻止し得るようになる。また、セキュリティ条件テーブルにより、ＭＡＣの検証により不正なデータフレームが検出される回数等に応じて対処処理を適切に定義して、不正に対処し得るようになる。

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

（１）上記実施の形態では、各ＥＣＵによりフレームが定期的に送信される例を示したが、フレームは状態変化を通知するイベントとして送信されることとしても良い。例えば、ＥＣＵは、ドアの開閉状態を定期的に送信するのではなく、ドアの開閉状態が変化した場合にのみ、フレームを送信するとしても良い。また、ＥＣＵがフレームを、定期的に送信、かつ、状態変化が発生した時に送信することとしても良い。

（２）上記実施の形態では、メッセージＩＤとデータ値とカウンタ値とに基づく演算によりＭＡＣを生成（計算）しているが、データフレームの一部の内容を反映して（つまり一部の内容に基づいて）ＭＡＣを生成すれば良く、データ値のみからＭＡＣを生成することとしても良い。またカウンタ値のみからＭＡＣを生成するとしても良い。データフレームを受信するＥＣＵにおけるＭＡＣの検証方式は、データフレームを送信するＥＣＵがデータフレームにＭＡＣを付与する方式に対応したものであれば良い。また、ＭＡＣを付与するデータフレームにおいてはデータフィールド内にデータ値及びＭＡＣの他に、一部又は全てのカウンタ値を含めても良い。また、フレームに含まれるＭＡＣのサイズは４ｂｙｔｅｓに制限されるものではなく、送信毎に異なるサイズであっても良い。同様に時速等のデータ値のサイズ及びカウンタ値のサイズも１ｂｙｔｅに制限されるものではない。

（３）上記実施の形態では、カウンタ値を送信毎にインクリメントする例を示したが、カウンタ値が時刻に応じて自動的にインクリメントされる値であっても良い。また、時刻そのものの値をカウンタの代わりに使用しても良い。即ち、データフレームが送信される度に変化する変数（カウンタ、時刻等）に基づいてＭＡＣが生成されるようにすると、ＭＡＣの不正な解読を困難化することが可能となる。また、カウンタの値に対する演算は、インクリメント（１増加）には限定されない。２以上の増加を行っても良いし、インクリメントによるアップカウントに限らず、デクリメントによるダウンカウントでも良い。また、カウンタ値に対する演算は、例えば、ビットシフトであっても良いし、前回の演算結果を入力値として予め定められたアルゴリズムに基づいて特定された出力値を演算結果とする演算等であっても良い。

（４）上記実施の形態では、ＣＡＮプロトコルにおけるデータフレームを標準ＩＤフォーマットで記述しているが、拡張ＩＤフォーマットであっても良い。拡張ＩＤフォーマットの場合には、標準ＩＤフォーマットにおけるＩＤ位置のベースＩＤと、拡張ＩＤとを合わせて２９ビットでＩＤ（メッセージＩＤ）を表すので、この２９ビットのＩＤを上述の実施の形態におけるＩＤ（メッセージＩＤ）と扱えば良い。

（５）上記実施の形態では、ＭＡＣ算出のアルゴリズムをＨＭＡＣとしているが、これはＣＢＣ−ＭＡＣ（Cipher Block Chaining Message Authentication Code）、ＣＭＡＣ（Cipher-based MAC）であっても良い。また、ＭＡＣ計算に用いられるパディングについては、ゼロパディング、ＩＳＯ１０１２６、ＰＫＣＳ＃１、ＰＫＣＳ＃５、ＰＫＣＳ＃７、その他、ブロックのデータサイズが計算に必要となるパディングの方式であれば何でも良い。また４ｂｙｔｅｓ等のブロックへのサイズの変更方法についても、先頭、最後尾、中間のいずれの部分にパディングを行っても良い。また、ＭＡＣ算出に用いるデータは、連続しているデータ（例えば４ｂｙｔｅｓ分の連続データ）でなくても、特定のルールに従って１ｂｉｔずつ収集して結合したものでも良い。

（６）上記実施の形態で示した不正フレーム検知部及び不正ＭＡＣ検知部はＣＡＮコントローラと呼ばれるハードウェア、または、ＣＡＮコントローラと接続して動作するプロセッサ上で動作するファームウェアに実装しても良い。また、ＭＡＣ鍵保持部、カウンタ保持部、正規ＩＤリスト保持部、データ範囲リスト保持部、不正ＩＤリスト保持部、セキュリティ条件保持部は、ＣＡＮコントローラと呼ばれるハードウェアのレジスタ、または、ＣＡＮコントローラと接続して動作するプロセッサ上で動作するファームウェアに格納されていても良い。

（７）上記実施の形態のセキュリティ条件テーブルは一例であり、例示した値と異なる値にしても良いし、複数の条件を定めたものであっても良い。また、セキュリティ条件テーブルは不正検知ＥＣＵに事前に設定されているものとしているが、車載ネットワークシステムの出荷時或いは車載ネットワークシステムが搭載される車体の出荷時に設定されても良い。上述したセキュリティ条件テーブル等の情報類は、セキュリティ条件保持部に保持された後において、アップデートされても良く、セキュリティ条件テーブル等の情報類は、外部との通信に基づいて設定されても、各種記録媒体等を用いて設定されても、ツール類等によって設定されても良い。

（８）上記実施の形態では、ＭＡＣ鍵をメッセージＩＤ毎に１つ保持しているが、ＥＣＵ毎（つまり１以上のメッセージＩＤ群毎）に１つであっても良い。また、全てのＥＣＵが同じＭＡＣ鍵を保持している必要はない。また、同一のバスに接続された各ＥＣＵは、共通のＭＡＣ鍵を保持していても良い。但し、同じメッセージＩＤのフレームを送信するＥＣＵとそのフレームを受信して検証するＥＣＵとでは同じＭＡＣ鍵を保持する必要がある。また、同一のＭＡＣ鍵を保持する範囲については、互いに異なるバスに接続されたＥＣＵ間であっても同一の鍵、車両一台あたり同一の鍵、同一車種の車両で同一の鍵、同一製造メーカ毎に同一の鍵、互いに異なる製造メーカであっても同一の鍵等であっても良い。なお、更新前と更新後のＭＡＣ鍵を、ＭＡＣ鍵保持部において暗号化して保持しても良い。

（９）上記実施の形態では、カウンタ値をメッセージＩＤ毎に１つ保持しているが、ＥＣＵ毎（つまり１以上のメッセージＩＤ群毎）に１つであっても良い。また、同一のバス上を流れる全てのフレームに対して共通のカウンタ値を使用しても良い。

（１０）上記実施の形態では、不正検知ＥＣＵがＭＡＣの検証に失敗した場合（その失敗回数が閾値を超えた場合）に、不正なフレームの送信が行われた旨をヘッドユニットに通知することとしたが、ヘッドユニットは、その不正に係る情報を、車載ネットワークシステムの外部のサーバ装置等へ通信により通知しても良い。これにより、外部サーバ装置等において、車載ネットワークシステムで生じた不正に係る情報を収集することが可能となる。また、ヘッドユニットは、不正なフレームの送信が行われた旨の通知を受けると、ディスプレイへの表示、ブザーの鳴動等で運転者に報知しても良い。また、上記実施の形態では、不正検知がＭＡＣの検証に失敗した場合（その失敗回数が閾値を超えた場合）に、車両の状態を安全状態にするための制御を行うこととしたが、これは車両の機能に一定の抑制を加えて予め定められた特定状態にするための制御であれば足りる。この特定状態にするための制御は、例えば、車両の一部の機構を制御すること、車両の一部の機構の制御を１台又は複数のＥＣＵに指示するためのフレームを、バスを介して送信すること等である。

（１１）上記実施の形態で不正検知ＥＣＵがＭＡＣの検証に失敗した場合に送信することとした鍵更新＆カウンタリセットフレームの代わりに、不正検知ＥＣＵは、鍵更新フレーム及びカウンタリセットフレームのいずれかのみを用いることとしても良い。例えば、不正検知ＥＣＵを含む各ＥＣＵにおいてＭＡＣの生成にカウンタ値を用いない場合或いはカウンタ値を用いるがカウンタ値のリセットを行わないこととした場合には、不正検知ＥＣＵはＭＡＣの検証に失敗したときに更新フレームのうち鍵更新フレームのみを送信することが有用となる。また、不正検知ＥＣＵにおいて受信したデータフレームに係るＭＡＣの検証に失敗した場合に、そのデータフレームと同一のメッセージＩＤのデータフレームの送信側及び受信側となるＥＣＵ及び不正検知ＥＣＵは、更新フレームの送受信以外の方法（例えばＣＡＮプロトコルを利用しない通信路を介して信号の授受を行う等）で同期してＭＡＣ鍵の更新或いはカウンタ値のリセットを行っても良い。

（１２）上記実施の形態で示したＣＡＮプロトコルは、ＴＴＣＡＮ（Time-Triggered CAN)、ＣＡＮＦＤ（CAN with Flexible Data Rate）等の派生的なプロトコルをも包含する広義の意味を有するものであっても良い。

（１３）上記実施の形態における各ＥＣＵ（不正検知ＥＣＵ、ゲートウェイ及びヘッドユニットを含む）は、例えば、プロセッサ、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置であることとしたが、ハードディスク装置、ディスプレイ、キーボード、マウス等の他のハードウェア構成要素を含んでいても良い。また、メモリに記憶された制御プログラムがプロセッサにより実行されてソフトウェア的に機能を実現する代わりに、専用のハードウェア（デジタル回路等）によりその機能を実現することとしても良い。

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

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

（１６）本発明の一態様としては、上記に示す不正対処方法等の方法であるとしても良い。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしても良いし、前記コンピュータプログラムからなるデジタル信号であるとしても良い。また、本発明の一態様としては、前記コンピュータプログラムまたは前記デジタル信号をコンピュータで読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＢＤ（Blu-ray（登録商標） Disc）、半導体メモリ等に記録したものとしても良い。また、これらの記録媒体に記録されている前記デジタル信号であるとしても良い。また、本発明の一態様としては、前記コンピュータプログラムまたは前記デジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしても良い。また、本発明の一態様としては、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記録しており、前記マイクロプロセッサは、前記コンピュータプログラムに従って動作するとしても良い。また、前記プログラムまたは前記デジタル信号を前記記録媒体に記録して移送することにより、または前記プログラムまたは前記デジタル信号を前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしても良い。

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

本発明は、車載ネットワークシステムにおいて不正なフレームの送信に対処するために利用可能である。

１０、１１、１２、１３ 車載ネットワークシステム
１００ａ、１００ｂ、２１００ａ、２１００ｂ、３１００ａ、３１００ｂ、４１００ａ、４１００ｂ 不正検知電子制御ユニット（不正検知ＥＣＵ）
１１０ 不正検知カウンタ保持部
１２０ 正規ＩＤリスト保持部
１３０、２１３０ 不正フレーム検知部
１４０、２３０、３２０、４２０、３４２０ フレーム生成部
１５０、２６０、３５０、４５０、２１５０、３１５０、４１５１ フレーム解釈部
１６０、２７０、３６０、４６０ フレーム送受信部
２００ ヘッドユニット
２１０ 表示制御部
２２０、４１０ フレーム処理部
２４０、３３０、４３０ 受信ＩＤ判断部
２５０、３４０、４４０ 受信ＩＤリスト保持部
３００ ゲートウェイ
３１０ 転送処理部
３７０ 転送ルール保持部
４００ａ〜４００ｄ、３４００ａ〜３４００ｄ、４４００ａ〜４４００ｄ 電子制御ユニット（ＥＣＵ）
４０１ エンジン
４０２ ブレーキ
４０３ ドア開閉センサ
４０４ 窓開閉センサ
４７０ データ取得部
５００ａ〜５００ｃ バス
２１２０ データ範囲リスト保持部
３１３０、４１３１ 不正ＭＡＣ検知部
３１７０、３４１０ ＭＡＣ生成部
３１８０、３４３０、４１８０、４４３０ ＭＡＣ鍵保持部
３１９０、３４４０ カウンタ保持部
４１１０、４４１０ ＭＡＣ鍵更新部
４１２０、４４２０ カウンタリセット部
４１３０ セキュリティ処理部
４１４０ セキュリティ条件保持部
４１５０ 不正ＩＤリスト保持部
４１６０ 不正ログ保持部
４１７０ モード変更処理部

上記課題を解決するために本発明の一態様に係る不正対処方法は、データフレームの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムにおいて、前記複数の電子制御ユニットのうちの１つの電子制御ユニットで用いられる不正対処方法であって、前記車載ネットワークシステムは複数のネットワークを備え、前記複数のネットワークの各々は、複数種類のグループのうちいずれかのグループに属し、前記車載ネットワークシステム上で送信されたデータフレームを受信する受信ステップと、鍵を用いて前記受信ステップで受信された前記データフレームが不正か否かを検証する検証ステップと、前記検証ステップでの検証において、前記データフレームが不正である場合に、前記複数のネットワークのうち送信元の電子制御ユニットが接続されているネットワークが属するグループと対応付けて予め定められている処理を実行する対処ステップとを含む不正対処方法である。

Claims (11)

1. 車載ネットワークにおいてメッセージ認証コード（ＭＡＣ：Message Authentication Code）が付加されたデータフレームの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムにおいて、前記複数の電子制御ユニットのうちの１つの電子制御ユニットにおいて用いられる不正対処方法であって、
   前記車載ネットワークに送信されたデータフレームを受信し、
   メッセージ認証コードが付加されたデータフレームが送信される回数をカウントするカウンタの値及びＭＡＣ鍵を利用して第１のメッセージ認証コードを生成し、
   前記受信されたデータフレームに前記生成した第１のメッセージ認証コードが付加されていることを検証し、
   所定ＩＤを含むデータフレームについて前記検証が失敗した場合に、エラー発生回数をインクリメントし、前記エラー発生回数が所定閾値を超えた場合に、当該所定ＩＤと予め対応付けられている処理を実行する、
   不正対処方法。
2. 前記所定ＩＤが、所定の不正ＩＤリストが示す１以上のＩＤのいずれかと同一である場合に、前記所定ＩＤと予め対応付けられている処理は、前記所定ＩＤの前記不正ＩＤリストへの追加である
   請求項１記載の不正対処方法。
3. 前記所定ＩＤと予め対応付けられている前記処理は、不正なフレームの送信が行われた旨を示す情報を含むフレームの送信である
   請求項１記載の不正対処方法。
4. 前記所定ＩＤと予め対応付けられている前記処理は、前記車載ネットワークシステムを搭載する車両の機能に一定の抑制を加えて予め定められた特定状態とするための制御である
   請求項１記載の不正対処方法。
5. 前記制御は、前記車両を所定速度以下に制限する制御である、
   請求項４記載の不正対処方法。
6. 前記制御は、前記特定状態へ変更するための、予め定められたフレームを生成して送信することである、
   請求項４記載の不正対処方法。
7. 前記不正対処方法は更に、前記車載ネットワークにおいて送信が開始されたデータフレームのＩＤが、所定の不正ＩＤリストが示す１以上のＩＤのいずれかと同一である場合に、当該データフレームの最後尾が送信される前にエラーフレームを送信し、
   前記所定ＩＤと予め対応付けられている処理は、前記所定ＩＤの前記不正ＩＤリストへの追加である
   請求項１記載の不正対処方法。
8. 前記所定ＩＤと予め対応付けられている処理は、前記所定ＩＤを示すログ情報の記録媒体への記録である
   請求項１記載の不正対処方法。
9. 前記車載ネットワークは複数のネットワークを備え、前記複数のネットワークの各々は、複数種類のグループのうちいずれかのグループに属し、
   前記不正対処方法は更に、前記検証が失敗した場合に、前記電子制御ユニットが、前記複数のネットワークのうち自ユニットが接続されているネットワークが属するグループと対応付けて予め定められている処理を実行する
   請求項１記載の不正対処方法。
10. 前記車載ネットワークは複数のネットワークを備え、前記複数のネットワーク電子制御ユニットの各々は、複数種類のグループのうちいずれかのグループに属し、
    前記車載ネットワークに送信が開始されたデータフレームのＩＤは、複数種類のグループのうちいずれかのグループにおいて送信されており、
    前記不正対処方法は更に、所定グループに属するネットワークにおいて送信されている所定ＩＤを含むデータフレームについて前記検証が失敗した回数が所定閾値を越えた場合に、前記所定グループと予め対応付けられている処理を実行する
    請求項１記載の不正対処方法。
11. 前記不正対処方法は更に、
    前記検証が失敗した場合において、前記ＭＡＣ鍵の更新前のＭＡＣ鍵を利用して生成した第２のメッセージ認証コードを用いて再び行った検証に第２のメッセージ認証コードを用いて再び行った検証に失敗したときには、前記カウンタのリセット要求を示すカウンタリセットフレームを、前記車載ネットワークを介して送信し、
    前記カウンタリセットフレームが送信された場合に前記カウンタをリセットする
    請求項１記載の不正対処方法。

Images