(57)【要約】ＣＡＮプロトコルに従ってバスを介してＭＡＣが付加されたデータフレームの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムにおいて、ＭＡＣの生成に利用されるデータの更新のために用いられる更新処理方法は、車載ネットワークシステムを搭載する車両の状態を検出する検出ステップと、検出ステップで検出された車両の状態が所定状態であることを条件としてＭＡＣの生成に利用されるＭＡＣ鍵を更新する更新ステップとを含む。
2015170452.tif 000002
【特許請求の範囲】
【請求項１】
ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介してメッセージ認証コード（ＭＡＣ：Message Authentication Code）が付加されたデータフレームの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムにおいて、当該メッセージ認証コードの生成に利用されるＭＡＣ鍵の更新のために、用いられる更新処理方法であって、
前記車載ネットワークシステムを搭載する車両の状態を検出する検出ステップと、
前記検出ステップで検出された車両の状態が所定状態であることを条件として前記メッセージ認証コードの生成に利用されるＭＡＣ鍵を更新する更新ステップとを含む
更新処理方法。
【請求項２】
前記複数の電子制御ユニットのうち、所定メッセージＩＤで識別されるデータフレームを送信する第１電子制御ユニットは、送信回数をカウントする送信カウンタの値を反映するように前記ＭＡＣ鍵を用いてメッセージ認証コードを生成して前記データフレームに付加し、
前記複数の電子制御ユニットのうち、前記所定メッセージＩＤで識別されるデータフレームを受信する第２電子制御ユニットは、受信回数をカウントする受信カウンタの値を反映するように前記ＭＡＣ鍵を用いてメッセージ認証コードを生成して前記データフレームに当該メッセージ認証コードが付加されていることを検証し、
前記更新処理方法は更に、前記検出ステップで検出された車両の状態が前記所定状態であることを条件として前記送信カウンタ及び前記受信カウンタをリセットするリセットステップとを含む
請求項１記載の更新処理方法。
【請求項３】
前記車載ネットワークシステムは複数のバスを備え、
前記更新ステップでは、前記複数の電子制御ユニットのうち１以上の電子制御ユニット各々により、当該電子制御ユニットが保持して利用するＭＡＣ鍵について、前記更新が行われ、前記更新の条件となる前記所定状態は、当該電子制御ユニットが接続されているバスに対応して定められる
請求項１記載の更新処理方法。
【請求項４】
前記車載ネットワークシステムは複数のバスを備え、前記複数のバスの各々は、複数種類のグループのうちいずれかのグループに属し、
前記更新ステップでは、前記複数の電子制御ユニットのうち１以上の電子制御ユニット各々により、当該電子制御ユニットが保持して利用するＭＡＣ鍵について、前記更新が行われ、前記更新の条件となる前記所定状態は、当該電子制御ユニットが接続されているバスが属するグループに対応して定められる
請求項１記載の更新処理方法。
【請求項５】
前記更新ステップでは、前記ＭＡＣ鍵の前回の更新時から計数される所定の数量が一定数量に達したタイミングにおいて前記検出ステップで検出された車両の状態が前記所定状態であれば、前記ＭＡＣ鍵の更新を行う
請求項１記載の更新処理方法。
【請求項６】
前記更新ステップでは、前記ＭＡＣ鍵の前回の更新時から計数される所定の数量が一定数量に達したタイミングにおいて前記検出ステップで検出された車両の状態が前記所定状態でない場合に、前記検出ステップで検出された車両の状態が前記所定状態に変化したタイミングで前記ＭＡＣ鍵の更新を行う
請求項５記載の更新処理方法。
【請求項７】
前記所定状態は、前記車両が走行していない状態である
請求項１記載の更新処理方法。
【請求項８】
前記所定状態は、駐車状態である
請求項７記載の更新処理方法。
【請求項９】
ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介してメッセージ認証コード（ＭＡＣ：Message Authentication Code）が付加されたデータフレームの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムであって、
メッセージ認証コードを生成して、所定メッセージＩＤで識別されるデータフレームに付加して送信する第１電子制御ユニットと、
メッセージ認証コードを生成して、前記所定メッセージＩＤで識別されるデータフレームを受信して当該データフレームに当該メッセージ認証コードが付加されていることを検証する第２電子制御ユニットとを備え、
前記第１電子制御ユニット及び前記第２電子制御ユニットの各々は、
前記メッセージ認証コードの生成に利用されるＭＡＣ鍵を保持するＭＡＣ鍵保持部と、
前記車載ネットワークシステムを搭載する車両の状態が所定状態であることを条件として前記ＭＡＣ鍵保持部に保持されるＭＡＣ鍵を更新する更新処理部とを有する
車載ネットワークシステム。
【請求項１０】
前記第１電子制御ユニット及び前記第２電子制御ユニットの更新処理部は、
予め定められた特定メッセージＩＤで識別される特定フレームを受信した場合に前記車両の状態が所定状態であるか否かを判定し、当該車両の状態が所定状態であるときにＭＡＣ鍵の前記更新を行う
請求項９記載の車載ネットワークシステム。
【請求項１１】
ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介して、データフレームにメッセージ認証コード（ＭＡＣ：Message Authentication Code）を付加して送信するため、或いは、データフレームを受信して当該データフレームにメッセージ認証コードが付加されていることを検証するために、メッセージ認証コードを生成する電子制御ユニットであって、
前記メッセージ認証コードの生成に利用されるＭＡＣ鍵を保持するＭＡＣ鍵保持部と、
前記電子制御ユニットを搭載する車両の状態が所定状態であることを条件として前記ＭＡＣ鍵保持部に保持されるＭＡＣ鍵を更新する更新処理部とを備える
電子制御ユニット。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、電子制御ユニットが通信を行う車載ネットワークにおいて不正なフレームの送信に対抗する技術に関する。
【背景技術】
【０００２】
近年、自動車の中のシステムには、電子制御ユニット（ＥＣＵ：Electronic Control Unit）と呼ばれる装置が多数配置されている。これらのＥＣＵをつなぐネットワークは車載ネットワークと呼ばれる。車載ネットワークには、多数の規格が存在する。その中でも最も主流な車載ネットワークの一つに、ＩＳＯ１１８９８−１で規定されているＣＡＮ（Controller Area Network）という規格が存在する（「非特許文献１」参照）。【０００３】
ＣＡＮでは、通信路は２本のバスで構成され、バスに接続されているＥＣＵはノードと呼ばれる。バスに接続されている各ノードは、フレームと呼ばれるメッセージを送受信する。フレームを送信する送信ノードは、２本のバスに電圧をかけ、バス間で電位差を発生させることによって、レセシブと呼ばれる「１」の値と、ドミナントと呼ばれる「０」の値を送信する。複数の送信ノードが全く同一のタイミングで、レセシブとドミナントを送信した場合は、ドミナントが優先されて送信される。受信ノードは、受け取ったフレームのフォーマットに異常がある場合には、エラーフレームと呼ばれるフレームを送信する。エラーフレームとは、ドミナントを６ｂｉｔ連続して送信することで、送信ノードや他の受信ノードにフレームの異常を通知するものである。【０００４】
またＣＡＮでは送信先や送信元を指す識別子は存在せず、送信ノードはフレーム毎にメッセージＩＤと呼ばれるＩＤを付けて送信し（つまりバスに信号を送出し）、各受信ノードは予め定められたメッセージＩＤのみを受信する（つまりバスから信号を読み取る）。また、ＣＳＭＡ／ＣＡ（Carrier Sense Multiple Access/Collision Avoidance）方式を採用しており、複数ノードの同時送信時にはメッセージＩＤによる調停が行われ、メッセージＩＤの値が小さいフレームが優先的に送信される。【０００５】
ところで、車載ネットワークにおいて不正なノードがバスに接続され、不正なノードが不正にフレームを送信することで、車体を不正にコントロールしてしまう可能性がある。このような不正なフレームの送信によるコントロールを防止するために、一般にＣＡＮにおけるデータフィールドにメッセージ認証コード（ＭＡＣ：Message Authentication Code）を付加して送信する技術が知られている（「特許文献１」参照）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１３−９８７１９号公報
【非特許文献】
【０００７】
【非特許文献１】ＣＡＮ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  ２．０  Ｐａｒｔ  Ａ、［ｏｎｌｉｎｅ］、ＣＡＮ  ｉｎ  Ａｕｔｏｍａｔｉｏｎ（ＣｉＡ）、［平成２６年１１月１４日検索］、インターネット（ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｃａｎ−ｃｉａ．ｏｒｇ／ｆｉｌｅａｄｍｉｎ／ｃｉａ／ｓｐｅｃｉｆｉｃａｔｉｏｎｓ／ＣＡＮ２０Ａ．ｐｄｆ）
【非特許文献２】ＲＦＣ２１０４  ＨＭＡＣ：  Ｋｅｙｅｄ−Ｈａｓｈｉｎｇ  ｆｏｒ  Ｍｅｓｓａｇｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、ＣＡＮにおけるデータフィールドに格納できるＭＡＣのデータ長は十分に長いとは言えないため、バスに接続された不正なノードによるＭＡＣに対する総当り攻撃等が懸念される。【０００９】
そこで、本開示は、バスに接続された不正なノードによるＭＡＣに対する総当り攻撃への耐性を高めるための車載ネットワークシステムを提供する。また、本開示は、その車載ネットワークシステムで用いられる電子制御ユニット（ＥＣＵ）、及び、不正なノードによるＭＡＣに対する総当り攻撃への耐性を高めるためにＭＡＣの生成に利用されるデータ（ＭＡＣ鍵等）の更新に関連した更新処理を行う更新処理方法を提供する。
【課題を解決するための手段】
【００１０】
上記課題を解決するために本開示の一態様に係る更新処理方法は、ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介してメッセージ認証コード（ＭＡＣ：Message Authentication Code）が付加されたデータフレームの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムにおいて、当該メッセージ認証コードの生成に利用されるＭＡＣ鍵の更新のために、用いられる更新処理方法であって、前記車載ネットワークシステムを搭載する車両の状態を検出する検出ステップと、前記検出ステップで検出された車両の状態が所定状態であることを条件として前記メッセージ認証コードの生成に利用されるＭＡＣ鍵を更新する更新ステップとを含む更新処理方法である。【００１１】
また、上記課題を解決するために本開示の一態様に係る車載ネットワークシステムは、ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介してメッセージ認証コード（ＭＡＣ：Message Authentication Code）が付加されたデータフレームの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムであって、メッセージ認証コードを生成して、所定メッセージＩＤで識別されるデータフレームに付加して送信する第１電子制御ユニットと、メッセージ認証コードを生成して、前記所定メッセージＩＤで識別されるデータフレームを受信して当該データフレームに当該メッセージ認証コードが付加されていることを検証する第２電子制御ユニットとを備え、前記第１電子制御ユニット及び前記第２電子制御ユニットの各々は、前記メッセージ認証コードの生成に利用されるＭＡＣ鍵を保持するＭＡＣ鍵保持部と、前記車載ネットワークシステムを搭載する車両の状態が所定状態であることを条件として前記ＭＡＣ鍵保持部に保持されるＭＡＣ鍵を更新する更新処理部とを有する車載ネットワークシステムである。【００１２】
また、上記課題を解決するために本開示の一態様に係る電子制御ユニット（ＥＣＵ）は、ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介して、データフレームにメッセージ認証コード（ＭＡＣ：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）の各フィールドで構成される。
【００３３】
ＳＯＦは、１ｂｉｔのドミナントで構成される。バスがアイドルの状態はレセシブになっており、ＳＯＦによりドミナントへ変更することでフレームの送信開始を通知する。
【００３４】
ＩＤフィールドは、１１ｂｉｔで構成される、データの種類を示す値であるＩＤ（メッセージＩＤ）を格納するフィールドである。複数のノードが同時に送信を開始した場合、このＩＤフィールドで通信調停を行うために、ＩＤが小さい値を持つフレームが高い優先度となるよう設計されている。
【００３５】
ＲＴＲは、データフレームとリモートフレームとを識別するための値であり、データフレームにおいてはドミナント１ｂｉｔで構成される。
【００３６】
ＩＤＥと「ｒ」とは、両方ドミナント１ｂｉｔで構成される。
【００３７】
ＤＬＣは、４ｂｉｔで構成され、データフィールドの長さを示す値である。なお、ＩＤＥ、「ｒ」及びＤＬＣを合わせてコントロールフィールドと称する。
【００３８】
データフィールドは、最大６４ｂｉｔで構成される送信するデータの内容を示す値である。８ｂｉｔ毎に長さを調整できる。送られるデータの仕様については、ＣＡＮプロトコルで規定されておらず、車載ネットワークシステム１０において定められる。従って、車種、製造者（製造メーカ）等に依存した仕様となる。
【００３９】
ＣＲＣシーケンスは、１５ｂｉｔで構成される。ＳＯＦ、ＩＤフィールド、コントロールフィールド及びデータフィールドの送信値より算出される。
【００４０】
ＣＲＣデリミタは、１ｂｉｔのレセシブで構成されるＣＲＣシーケンスの終了を表す区切り記号である。なお、ＣＲＣシーケンス及びＣＲＣデリミタを合わせてＣＲＣフィールドと称する。
【００４１】
ＡＣＫスロットは、１ｂｉｔで構成される。送信ノードはＡＣＫスロットをレセシブにして送信を行う。受信ノードはＣＲＣシーケンスまで正常に受信ができていればＡＣＫスロットをドミナントとして送信する。レセシブよりドミナントが優先されるため、送信後にＡＣＫスロットがドミナントであれば、送信ノードは、いずれかの受信ノードが受信に成功していることを確認できる。
【００４２】
ＡＣＫデリミタは、１ｂｉｔのレセシブで構成されるＡＣＫの終了を表す区切り記号である。
【００４３】
ＥＯＦは、７ｂｉｔのレセシブで構成されており、データフレームの終了を示す。
【００４４】
［１．３  ＥＣＵ１００ａの構成］
図３は、ＥＣＵ１００ａの構成図である。ＥＣＵ１００ａは、フレーム送受信部１０１と、フレーム解釈部１０２と、受信ＩＤ判断部１０３と、受信ＩＤリスト保持部１０４と、フレーム処理部１０５と、車両状態保持部１０６と、判定ルール保持部１０７と、タイマー１０８と、更新判定部１０９と、更新処理部１１０と、ＭＡＣ鍵保持部１１１と、カウンタ保持部１１２と、ＭＡＣ生成部１１３と、フレーム生成部１１４と、データ取得部１１５とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、ＥＣＵ４００ａにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。なお、ＥＣＵ１００ｂ〜１００ｄも同様の構成を備える。
【００４５】
フレーム送受信部１０１は、バス２００に対して、ＣＡＮのプロトコルに従ったフレームを送受信する。バス２００からフレームを１ｂｉｔずつ受信し、フレーム解釈部１０２に転送する。また、フレーム生成部１１４より通知を受けたフレームの内容をバス２００に送信する。
【００４６】
フレーム解釈部１０２は、フレーム送受信部１０１よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。ＩＤフィールドと判断した値は受信ＩＤ判断部１０３へ転送する。フレーム解釈部１０２は、受信ＩＤ判断部１０３から通知される判定結果に応じて、ＩＤフィールドの値と、ＩＤフィールド以降に現れるデータフィールドとを、フレーム処理部１０５へ転送するか、その判定結果を受けた以降においてフレームの受信を中止する（つまりそのフレームとしての解釈を中止する）かを決定する。また、フレーム解釈部１０２は、ＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部１１４へ通知する。また、フレーム解釈部１０２は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。また、フレーム解釈部１０２は、データフレーム内のＡＣＫスロットの内容をフレーム処理部１０５へ通知する。
【００４７】
受信ＩＤ判断部１０３は、フレーム解釈部１０２から通知されるＩＤフィールドの値を受け取り、受信ＩＤリスト保持部１０４に保持しているメッセージＩＤのリストに従い、そのＩＤフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ＩＤ判断部１０３は、フレーム解釈部１０２へ通知する。
【００４８】
受信ＩＤリスト保持部１０４は、ＥＣＵ１００ａが受信するＩＤ（メッセージＩＤ）のリストである受信ＩＤリストを保持する。図４は、受信ＩＤリストの一例を示した図である。
【００４９】
フレーム処理部１０５は、フレーム解釈部１０２より受信した全てのデータフレームのメッセージＩＤとデータフィールドの値とに対して、ＭＡＣ鍵保持部１１１よりメッセージＩＤに対応したＭＡＣ鍵を取得し、カウンタ保持部１１２よりメッセージＩＤに対応したカウンタ値を取得し、データフィールドに含まれるＭＡＣを検証する。このＭＡＣの検証は、データフレーム（メッセージ）の正当性を検証する意義を有する。具体的には、フレーム処理部１０５は、ＭＡＣ生成部１１３と同様の方法（後述）でＭＡＣを計算により生成し、生成したＭＡＣとデータフィールド中のＭＡＣとを比較して、両ＭＡＣが一致すれば検証に成功したと判定し、一致しなければエラーと判定する（つまり検証に失敗したと判定する）。検証の結果、エラーと判定（つまり検証に失敗したと判定）すれば、フレーム解釈部１０２へ通知し、以降の受信処理を中止する。また、車両の状態（車両状態）を通知するフレームを受信した場合、車両状態保持部１０６へそのフレームに応じた車両状態を通知する。また、フレーム処理部１０５は、受信したフレームのデータに応じて、ＥＣＵ毎に異なる処理を行う。例えば、エンジン３１０に接続されたＥＣＵ１００ａは、時速が３０ｋｍを超えた状態でドアが開いている状態だと、アラーム音を鳴らす機能を備える。ＥＣＵ１００ａは、例えばアラーム音を鳴らすためのスピーカ等を有している。そして、ＥＣＵ１００ａのフレーム処理部１０５は、他のＥＣＵから受信したデータ（例えばドアの状態を示す情報）を管理し、エンジン３１０から取得された時速に基づいて一定条件下でアラーム音を鳴らす処理等を行う。ＥＣＵ１００ｃは、ブレーキがかかっていない状況でドアが開くとアラーム音を鳴らす機能を備える。ＥＣＵ１００ｂ、１００ｄでは特に何もしない。なお、ＥＣＵ１００ａ〜１００ｄは上記以外の機能を備えていてもよい。また、フレーム処理部１０５は、データフレーム内のＡＣＫスロットの値を確認し、ＥＣＵ１００ａが送信したフレームが、他のＥＣＵに正常に受信されているかどうかを確認し、確認した結果を更新処理部１１０へ通知する。なお、フレーム処理部１０５によりＭＡＣの検証が行われるので、バス２００に不正ＥＣＵが接続されて不正なフレームを送信したとしても検証に失敗し、不正なフレームによる車両の制御等が阻止される。
【００５０】
車両状態保持部１０６は、フレーム処理部１０５より通知された現在の車両状態（つまり現在迄に最後に通知された車両状態）を保持する。具体的な車両状態の一例としては、「走行中」、「停車中」、「駐車中」が挙げられる。車載ネットワークシステム１０は、例えば、車両におけるギアのセンサ等に接続されて、ギアポジション（例えばパーキング、ニュートラル、１速、２速等）から車両状態を特定して、特定した車両状態を通知するためのフレームをバス２００へと送信するＥＣＵ（不図示）を含み得る。また、車載ネットワークシステム１０は、複数のＥＣＵから通知された情報に基づいて車両状態を特定して、特定した車両状態を通知するためのフレームを送信するＥＣＵ（不図示）を含むこととしても良い。
【００５１】
判定ルール保持部１０７は、車両状態に応じて更新処理を行うかどうかを対応付けた判定ルールを保持する。図５は、車両状態に応じた判定ルールの一例を示した図である。
【００５２】
タイマー１０８は、経過時間に対応するタイマー値のカウントアップを繰り返す計時機構であり、前回の更新処理が完了してからの経過時間を更新判定部１０９へ通知する。また、更新判定部１０９からの更新処理完了通知に基づいて、リセットを行う。
【００５３】
更新判定部１０９は、タイマー１０８に基づき、予め定められた更新タイミングが到来したら、車両状態保持部１０６から現在の車両状態を取得し、車両状態に対応して判定ルール保持部１０７から取得した判定ルールに応じて、ＭＡＣの生成に利用されるデータ（つまりＭＡＣ鍵、カウンタ値）の更新に関連する更新処理を実行するか否かを判定する。更新処理は、具体的には、ＭＡＣを生成するために用いる鍵であるＭＡＣ鍵の値を更新する鍵更新処理と、ＭＡＣに反映するカウンタ値をリセット（つまりゼロ等の特定値に更新）するカウンタリセット処理とを意味する。更新判定部１０９は、ＭＡＣの生成に利用されるデータを更新すると決定（判定）した場合には、更新処理部１１０へ通知する。更新しないと判定（決定）した場合は、車両状態の変化を待つ。更新処理が完了した場合、更新判定部１０９は、タイマー１０８に更新処理完了通知を伝え、これによりタイマー１０８がリセットされる。更新タイミングは、タイマー１０８に基づき判定され、予め定められた一定時間（例えば６時間、１日等）が経過したタイミングである。
【００５４】
更新処理部１１０は、更新判定部１０９からの通知に従って更新処理を行う。即ち、更新判定部１０９から通知を受けた更新処理部１１０は、ＭＡＣ鍵保持部１１１が保持しているＭＡＣ鍵を取得し、旧鍵としてキャッシュしておき、新たにＭＡＣ鍵候補となる鍵を生成し、ＭＡＣ鍵保持部１１１へ通知する。また、更新判定部１０９から通知を受けた更新処理部１１０は、カウンタ保持部１１２が保持しているカウンタ値を取得し、キャッシュしておき（つまり一時的に記憶媒体に保持しておき）、カウンタ保持部１１２に対し、カウンタ値をリセットするよう通知する。また、フレーム解釈部１０２より正常な受信が確認できなかったという通知を受けた場合であって、かつ、ＭＡＣ鍵、カウンタ値のキャッシュを持っている場合（つまり一時的に記憶媒体に保持している場合）には、キャッシュしている鍵をＭＡＣ鍵保持部１１１へ通知し、キャッシュしているカウンタ値をカウンタ保持部１１２へ通知する。また、フレーム解釈部１０２より正常な受信が確認できたという通知を受けた場合であって、かつ、ＭＡＣ鍵、カウンタ値のキャッシュを持っている場合は、ＭＡＣ鍵、カウンタ値のキャッシュを削除する（つまり記憶媒体から削除する等により一時的に保持していた値を以後使用できないものと扱う）。ＭＡＣ鍵の生成方法については、例えば、現在のＭＡＣ鍵を、予め定められた一方向関数（例えばハッシュ関数等）に入力して導出される結果を新たなＭＡＣ鍵候補となる鍵とする方法を用いる。
【００５５】
ＭＡＣ鍵保持部１１１は、メモリ等の記憶媒体により実現され、ＭＡＣ生成部１１３及びフレーム処理部１０５がＭＡＣを計算する際に必要となるＭＡＣ鍵を、メッセージＩＤ毎に１つ保持する。ＭＡＣ鍵保持部１１１は、更新処理部１１０からの通知に従って、これまで持っていた鍵を破棄し、通知された鍵をＭＡＣ鍵として保持する。
【００５６】
カウンタ保持部１１２は、メモリ等の記憶媒体を含んで実現され、ＭＡＣ生成部１１３及びフレーム処理部１０５がＭＡＣを計算する際に必要となるカウンタ値を、メッセージＩＤ毎に１つ保持する。なお、カウンタ保持部１１２に保持されるカウンタ値は、フレームが正常に送信された場合にインクリメント（１増加）される。この方法として、データフレームを送信する場合においてはカウンタ値を送信カウンタとして扱い、送信回数をカウントする。また、データフレームを受信する場合においてはカウンタ値を受信カウンタとして扱い、受信回数をカウントする。例えば、メッセージＩＤが「１」のデータフレームを送信するＥＣＵ１００ａにおいては、カウンタ保持部１１２に保持しているメッセージＩＤが「１」に対応するカウンタ値を、送信カウンタとして扱い、１回送信する毎に送信カウンタをインクリメントする。また、例えばメッセージＩＤが「１」のデータフレームを受信するＥＣＵ１００ｂにおいては、カウンタ保持部１１２に保持しているメッセージＩＤが「１」に対応するカウンタ値を、受信カウンタとして扱い、送信されたデータフレームが正常に受信された毎に受信カウンタをインクリメントする。またカウンタ保持部１１２は、更新処理部１１０からの通知に従って、通知されたカウンタ値を保持し、また、更新処理部１１０からのリセットすべき旨の通知に従って、保持しているカウンタ値をリセットする。このリセットによりカウンタ値は、ゼロ等の特定値に更新される。
【００５７】
ＭＡＣ生成部１１３は、フレーム生成部１１４より通知されるメッセージＩＤとデータフィールド用のデータの値と、カウンタ保持部１１２で保持するカウンタ値（つまりメッセージＩＤに対応するカウンタ値）とを結合した値（結合値）に対し、ＭＡＣ鍵保持部１１１で保持するＭＡＣ鍵（つまりメッセージＩＤに対応するＭＡＣ鍵）を用いて、ＭＡＣを算出（つまりＭＡＣの値を計算により導出）して、この算出した結果であるＭＡＣをフレーム生成部１１４へと通知する。ここではＭＡＣの計算方法として、ＨＭＡＣ（Hash-based Message Authentication Code）（非特許文献２参照）を採用し、上述した結合値に対し、所定のブロック分（例えば４ｂｙｔｅｓ）までパディングした値でＭＡＣ鍵を使って計算し、出てきた計算結果の先頭４ｂｙｔｅｓをＭＡＣ値とする。なお、ここでのＭＡＣ値のサイズ、計算方法は一例であり、これに限定されるものではない。フレームが送信される毎にインクリメントされるカウンタ値を反映してＭＡＣは生成されるので、たとえ同じデータの値を含むデータフレームを複数回送信したとしても、データフレームに付与（つまり付加）されるＭＡＣは送信の都度変化する。
【００５８】
フレーム生成部１１４は、フレーム解釈部１０２から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部１０１へ通知して送信させる。また、フレーム生成部１１４は、予め定められたメッセージＩＤとデータ取得部１１５より通知されたデータの値（データフィールド用のデータの値）とをＭＡＣ生成部１１３へ通知することによりＭＡＣの通知を受ける。フレーム生成部１１４は、予め定められたメッセージＩＤと、通知されたＭＡＣと、通知されたデータフィールド用のデータの値とに基づきフレームを構成し、フレーム送受信部１０１へ通知する。なお、ＥＣＵ１００ａ〜１００ｄのそれぞれが送信するフレームの内容については後に図６〜図９を用いて説明する。
【００５９】
データ取得部１１５は、ＥＣＵにつながっている機器、センサ等の状態を示すデータを取得し、フレーム生成部１１４に通知する。
【００６０】
［１．４  受信ＩＤリスト例］
図４は、ＥＣＵ１００ａ〜１００ｄのそれぞれにおいて保持される受信ＩＤリストの一例を示す図である。同図に例示する受信ＩＤリストは、ＩＤ（メッセージＩＤ）の値が「１」、「２」、「３」及び「４」のいずれかであるメッセージＩＤを含むフレームを選択的に受信して処理するために用いられる。例えば、ＥＣＵの受信ＩＤリスト保持部１０４に図４の受信ＩＤリストが保持されていると、メッセージＩＤが「１」、「２」、「３」及び「４」のいずれでもないフレームについては、フレーム解釈部１０２でのＩＤフィールド以後のフレームの解釈が中止される。
【００６１】
［１．５  判定ルール例］
図５は、ＥＣＵ１００ａ〜１００ｄのそれぞれにおいて保持される判定ルールの一例を示す図である。この判定ルールは、更新処理を実行する条件としての、車載ネットワークシステム１０を搭載している車両の状態（車両状態）を定めるものであり、車両状態が判定ルールで定められた所定状態（例えば「駐車中」等）であれば更新処理の実行が可能となる。同図に例示する判定ルールは、車両状態が「走行中」及び「停車中」のいずれかの場合には、更新タイミング（つまり鍵更新、カウンタリセットの実行タイミング）が到来しても更新処理を実施せずに待機し、その後に車両状態が「駐車中」に変化したタイミングで更新処理を実施することを示し、また、車両状態が「駐車中」の場合には、更新タイミングが到来すれば更新処理を実施することを示している。
【００６２】
［１．６  エンジンに係るＥＣＵ１００ａの送信フレーム例］
図６は、エンジン３１０に接続されたＥＣＵ１００ａから送信されるデータフレームにおけるＩＤ（メッセージＩＤ）及びデータフィールド（データ）の一例を示す図である。ＥＣＵ１００ａが送信するフレームのメッセージＩＤは「１」である。データは、同図において１バイト毎に空白で区分して表しており、先頭の１ｂｙｔｅが時速（ｋｍ／時）を表し、次の１ｂｙｔｅはカウンタ値を表し、次の４ｂｙｔｅｓがＭＡＣを表す。なお、図６の例においてＭＡＣは１６進数で表記している。先頭１ｂｙｔｅの時速（ｋｍ／時）は、最低０（ｋｍ／時）〜最高１８０（ｋｍ／時）までの範囲の値を取る。図６の上行から下行へと、ＥＣＵ１００ａから逐次送信される各フレームに対応する各メッセージＩＤ及びデータを例示しており、カウンタ値が次第に増加し、時速が０ｋｍ／時から１ｋｍ／時ずつ加速されている様子を表している。
【００６３】
［１．７  ブレーキに係るＥＣＵ１００ｂの送信フレーム例］
図７は、ブレーキ３２０に接続されたＥＣＵ１００ｂから送信されるデータフレームにおけるＩＤ（メッセージＩＤ）及びデータフィールド（データ）の一例を示す図である。ＥＣＵ１００ｂが送信するフレームのメッセージＩＤは「２」である。データは、同図において１バイト毎に空白で区分して表しており、先頭の１ｂｙｔｅがブレーキのかかり具合を割合（％）で表し、次の１ｂｙｔｅはカウンタ値を表し、次の４ｂｙｔｅｓがＭＡＣを表す。なお、図７の例においてＭＡＣは１６進数で表記している。先頭１ｂｙｔｅのブレーキのかかり具合は、ブレーキを全くかけていない状態を０（％）、ブレーキを最大限かけている状態を１００（％）としたものである。図７の上行から下行へと、ＥＣＵ１００ｂから逐次送信される各フレームに対応する各メッセージＩＤ及びデータを例示しており、カウンタ値が次第に増加し、ブレーキについては１００％から徐々にブレーキを弱めている様子を表している。
【００６４】
［１．８  ドア開閉センサに係るＥＣＵ１００ｃの送信フレーム例］
図８は、ドア開閉センサ３３０に接続されたＥＣＵ１００ｃから送信されるデータフレームにおけるＩＤ（メッセージＩＤ）及びデータフィールド（データ）の一例を示す図である。ＥＣＵ１００ｃが送信するフレームのメッセージＩＤは「３」である。データは、同図において１バイト毎に空白で区分して表しており、先頭の１ｂｙｔｅがドアの開閉状態を表し、次の１ｂｙｔｅはカウンタ値を表し、次の４ｂｙｔｅｓがＭＡＣを表す。なお、図８の例においてＭＡＣは１６進数で表記している。先頭１ｂｙｔｅのドアの開閉状態は、ドアが開いている状態を「１」、ドアが閉まっている状態を「０」としたものである。図８の上行から下行へと、ＥＣＵ１００ｃから逐次送信される各フレームに対応する各メッセージＩＤ及びデータを例示しており、カウンタ値が次第に増加し、ドアが開いている状態から次第に閉められた状態へと移った様子を表している。
【００６５】
［１．９  窓開閉センサに係るＥＣＵ１００ｄの送信フレーム例］
図９は、窓開閉センサ３４０に接続されたＥＣＵ１００ｄから送信されるデータフレームにおけるＩＤ（メッセージＩＤ）及びデータフィールド（データ）の一例を示す図である。ＥＣＵ１００ｄが送信するフレームのメッセージＩＤは「４」である。データは、同図において１バイト毎に空白で区分して表しており、先頭の１ｂｙｔｅが窓の開閉状態を割合（％）で表し、次の１ｂｙｔｅはカウンタ値を表し、次の４ｂｙｔｅｓがＭＡＣを表す。なお、図９の例においてＭＡＣは１６進数で表記している。先頭１ｂｙｔｅの窓の開閉状態は、窓が完全に閉まっている状態を０（％）、窓が全開の状態を１００（％）としたものである。図９の上行から下行へと、ＥＣＵ１００ｄから逐次送信される各フレームに対応する各メッセージＩＤ及びデータを例示しており、カウンタ値が次第に増加し、窓が閉まっている状態から徐々に開いていく様子を表している。
【００６６】
［１．１０  更新処理］
以下、上述した各ＥＣＵによるデータフレームの送信に際してのＭＡＣの付与、及び、データフレームの受信に際してのＭＡＣの検証において用いられるＭＡＣの生成に必要となるデータの更新に関連した更新処理について説明する。
【００６７】
メッセージ毎にＭＡＣの付与及び検証に用いるＭＡＣ鍵及びカウンタ値に関する更新は、各ＥＣＵにおいて同期して実行される必要がある。ここでは、一例として、ＥＣＵ１００ａが更新の同期を確認するためのデータフレーム（「更新フレーム」と称する。）をバス２００に送信し、その他のＥＣＵ（ＥＣＵ１００ｂ等）が更新フレームをバス２００から受信する例を用いて、１つのメッセージＩＤに対応するＭＡＣに係る更新処理について説明する。なお、どのＥＣＵが更新フレームを送信しても良いが、例えば、メッセージＩＤ「１」のデータフレームを繰り返し送信するＥＣＵ１００ａが、メッセージＩＤ「１」に対応するＭＡＣに係る更新処理を同期させるための更新フレームを送信することとしても良い。
【００６８】
図１０及び図１１は、ＥＣＵ１００ａによる更新処理、及び、その更新処理の開始判断に係る処理の一例を示すフローチャートである。以下、図１０及び図１１に即してＥＣＵ１００ａの動作について説明する。
【００６９】
ＥＣＵ１００ａは、内部に持つタイマー１０８により、前回の更新処理からの経過時間を確認する（ステップＳ１００１）。そしてＥＣＵ１００ａは、経過時間が予め定められた一定時間に達して、更新タイミングが到来しているかどうかを判定する（ステップＳ１００２）。更新タイミングが到来していない場合には、経過時間がその一定時間に達するまでタイマー１０８による経過時間の確認を繰り返す。更新タイミングが到来している場合には、ＥＣＵ１００ａは、現在の車両状態の確認を行う（ステップＳ１００３）。
【００７０】
ＥＣＵ１００ａは、現在の車両状態に基づいて、判定ルール保持部１０７に保持されている判定ルールに従って、更新処理を行うかどうかを判定する（ステップＳ１００４）。車両状態が判定ルールで定められた更新処理を行う状態に変化するまで更新処理は行わず、車両状態の確認を継続する（ステップＳ１００３）。また、車両状態が判定ルールで定められた更新処理を行う状態であれば、図１１のステップＳ１００６以降の更新処理を開始する（ステップＳ１００５）。図５に示した判定ルールの例に従うと、車両状態が「走行中」「停車中」であれば、車両状態が「駐車中」に変化するまで待ってから更新処理を行い、また、車両状態が「駐車中」であれば即座に更新処理を開始する（ステップＳ１００５）。
【００７１】
更新処理を開始したＥＣＵ１００ａは、ＭＡＣ鍵保持部１１１により保持しているＭＡＣ鍵を、旧鍵としてキャッシュする（ステップＳ１００６）。続いて、ＥＣＵ１００ａは、新たにＭＡＣ鍵候補となる鍵を生成して、ＭＡＣ鍵としてＭＡＣ鍵保持部１１１に保持する（ステップＳ１００７）。
【００７２】
また、ＥＣＵ１００ａは、カウンタ保持部１１２により保持しているカウンタ値を、キャッシュする（ステップＳ１００８）。続いて、ＥＣＵ１００ａは、カウンタ保持部１１２により保持しているカウンタ値をゼロにリセットする（ステップＳ１００９）。
【００７３】
次に、ＥＣＵ１００ａは、予め定められたメッセージＩＤと、データフィールド用のデータ値と、リセット後のカウンタ保持部１１２に保持しているカウンタ値と、新たに生成されＭＡＣ鍵保持部１１１に保持しているＭＡＣ鍵とを用いてＭＡＣを生成する（ステップＳ１０１０）。そして、メッセージＩＤとデータフィールド用のデータ値とステップＳ１０１０において生成されたＭＡＣとを含む更新フレームを生成してブロードキャスト（つまり更新フレームのバス２００への送信）を行う（ステップＳ１０１１）。
【００７４】
ステップＳ１０１１での更新フレームの送信後にＥＣＵ１００ａは、更新フレームの受信に成功（つまり正常に受信）したノード（ＥＣＵ）が存在するかどうかを、ＡＣＫスロットの値を見ることで判定する（ステップＳ１０１２）。受信に成功したノードが存在する場合にはＥＣＵ１００ａは、キャッシュを破棄して（ステップＳ１０１５）、更新処理を終える。
【００７５】
ステップＳ１０１２での判定の結果として、更新フレームの受信に成功したノードが存在しなかった場合には、ＥＣＵ１００ａは、キャッシュしておいた旧鍵を、再度ＭＡＣ鍵としてＭＡＣ鍵保持部１１１に保持させ（ステップＳ１０１３）、キャッシュしておいたカウンタ値を、再度カウンタ値としてカウンタ保持部１１２に保持させる（ステップＳ１０１４）。次に、ＥＣＵ１００ａは、予め定められたメッセージＩＤと、データフィールド用のデータ値と、キャッシュから再設定したカウンタ保持部１１２のカウンタ値と、キャッシュから再設定したＭＡＣ鍵保持部１１１のＭＡＣ鍵とを用いてＭＡＣを生成する（ステップＳ１０１５）。そして、メッセージＩＤとデータフィールド用のデータ値とステップＳ１０１５において生成されたＭＡＣとを含む更新フレームを生成してブロードキャスト（つまり更新フレームのバス２００への送信）を行う（ステップＳ１０１６）。
【００７６】
ステップＳ１０１６での更新フレームの送信後にＥＣＵ１００ａは、更新フレームの受信に成功したノードが存在するかどうかを、ＡＣＫスロットの値を見ることで判定する（ステップＳ１０１７）。受信に成功したノードが存在する場合にはＥＣＵ１００ａは、予め定められた一定時間（例えば数秒間、数分間等）待機してから再びステップＳ１００６に戻って更新処理を実施する（ステップＳ１０１８）。また、ステップＳ１０１７において受信に成功したノードが存在しない場合には、致命的なエラーが発生したものと看做して、更新処理を中止する（ステップＳ１０１９）。更新処理を中止した場合には、ＥＣＵ１００ａは、エラー発生について報知、ログの記録等の処理を実行しても良い。また、エラー発生の報知は、他のＥＣＵへのエラー発生を示すデータフレームの送信、ディスプレイ等への表示、音声出力、発光等により、実行され得る。
【００７７】
図１２及び図１３は、ＥＣＵ１００ｂによる更新処理、及び、その更新処理の開始判断に係る処理の一例を示すフローチャートである。なお、図１２及び図１３に示す処理手順（ステップ）のうち図１０及び図１１で示したステップと同一のステップについては、同じ符号を用いており、説明を適宜省略する。また、ＥＣＵ１００ｃ及びＥＣＵ１００ｄもＥＣＵ１００ｂと同様の更新処理を行い得る。以下、図１２及び図１３に即してＥＣＵ１００ｂの動作について説明する。
【００７８】
ＥＣＵ１００ｂは、前回の更新処理からの経過時間を確認する（ステップＳ１００１）。そしてＥＣＵ１００ｂは、経過時間が予め定められた一定時間に達して、更新タイミングが到来しているかどうかを判定する（ステップＳ１００２）。更新タイミングが到来していない場合には、経過時間がその一定時間に達するまで経過時間の確認を繰り返す。更新タイミングが到来している場合には、ＥＣＵ１００ｂは、現在の車両状態の確認を行う（ステップＳ１００３）。
【００７９】
ＥＣＵ１００ｂは、現在の車両状態に基づいて、判定ルールに従って更新処理を行うかどうかを判定する（ステップＳ１００４）。車両状態が判定ルールで定められた更新処理を行う状態に変化するまで更新処理は行わず、車両状態の確認を継続する（ステップＳ１００３）。また、車両状態が判定ルールで定められた更新処理を行う状態であれば、図１３のステップＳ１１０１以降の更新処理を開始する（ステップＳ１００５）。
【００８０】
更新処理を開始したＥＣＵ１００ｂは、バス２００上に更新フレームが送信されるまで、つまり更新フレームが受信できるまで、待機する（ステップＳ１１０１）。
【００８１】
続いて、更新フレームを受信したＥＣＵ１００ｂは、ＭＡＣ鍵保持部１１１により保持しているＭＡＣ鍵を、旧鍵としてキャッシュする（ステップＳ１００６）。続いて、ＥＣＵ１００ｂは、新たにＭＡＣ鍵候補となる鍵を生成して、ＭＡＣ鍵としてＭＡＣ鍵保持部１１１に保持する（ステップＳ１００７）。
【００８２】
また、ＥＣＵ１００ｂは、カウンタ保持部１１２により保持しているカウンタ値を、キャッシュする（ステップＳ１００８）。続いて、ＥＣＵ１００ｂは、カウンタ保持部１１２により保持しているカウンタ値をゼロにリセットする（ステップＳ１００９）。
【００８３】
次に、ＥＣＵ１００ｂは、受信した更新フレームのメッセージＩＤと、データフィールドのデータ値と、リセット後のカウンタ保持部１１２に保持しているカウンタ値と、新たに生成されＭＡＣ鍵保持部１１１に保持しているＭＡＣ鍵とを用いてＭＡＣを生成し、更新フレームに含まれるＭＡＣと比較することによりＭＡＣを検証する（ステップＳ１１０２）。両ＭＡＣが一致すれば検証に成功する。ＥＣＵ１００ｂは、ＭＡＣの検証に成功したか否かを判定し（ステップＳ１１０３）、検証に成功した場合には、受信に成功した旨を示すためにＡＣＫスロットをドミナントにし、キャッシュを破棄して（ステップＳ１０１５）、更新処理を終える。
【００８４】
ステップＳ１１０３での判定の結果として、検証に成功しなかった場合には、ＥＣＵ１００ｂは、キャッシュしておいた旧鍵を、再度ＭＡＣ鍵としてＭＡＣ鍵保持部１１１に保持させ（ステップＳ１０１３）、キャッシュしておいたカウンタ値を、再度カウンタ値としてカウンタ保持部１１２に保持させる（Ｓ１０１４）。次に、ＥＣＵ１００ｂは、バス２００上に更新フレームが送信されるまで、つまり更新フレームが受信できるまで、待機する（ステップＳ１１０４）。
【００８５】
続いて、更新フレームを再び受信したＥＣＵ１００ｂは、受信した更新フレームのメッセージＩＤと、データフィールドのデータ値と、キャッシュからカウンタ保持部１１２に再設定したカウンタ値と、キャッシュからＭＡＣ鍵保持部１１１に再設定したＭＡＣ鍵とを用いてＭＡＣを生成し、更新フレームに含まれるＭＡＣと比較することによりＭＡＣを検証する（ステップＳ１１０５）。ＥＣＵ１００ｂは、ＭＡＣの検証に成功したか否かを判定し（ステップＳ１１０６）、検証に成功した場合には、受信に成功した旨を示すためにＡＣＫスロットをドミナントにし、予め定められた一定時間（送信側のステップＳ１０１８での一定時間と同じ時間）待機してから再びステップＳ１１０１に戻って更新処理を実施する（ステップＳ１１０７）。また、ステップＳ１１０６において検証に失敗した場合には、致命的なエラーが発生したものと看做して、更新処理を中止する（ステップＳ１０１９）。更新処理を中止した場合には、ＥＣＵ１００ｂは、エラー発生について報知、ログの記録等の処理を実行しても良い。
【００８６】
［１．１１  実施の形態１の効果］
実施の形態１で示したＥＣＵは、ＭＡＣの生成に用いるデータの更新に関する更新処理（ＭＡＣ鍵の更新、カウンタ値のリセット等）を、車両の状態に応じて実行する。この更新処理が適時に実行されるようになるため、バスに接続された不正ＥＣＵ（不正なノード）によるＭＡＣに対する総当り攻撃への耐性が高まる。なお、ＥＣＵの実行する処理の処理量（処理負荷）は、車両の状態に応じて変動し得る。従って、例えば処理負荷の低い駐車状態等においてＭＡＣ鍵の更新等を行わせることで、効率良く、また、処理遅延等によりエラーが生じることを避けて、複数のＥＣＵ（あるフレームの送信ノードと対応する受信ノード）が更新を同期して実行できるようになる。なお、同期が的確に実行できなければ、その後において送信ノードが送信したフレームを受信ノードでは正しく検証できなくなる。また、ＥＣＵが送信するフレームでバスのトラフィック量が比較的高い場合（例えば走行中の状態等）を避けるように車両の状態に応じて更新処理を行わせることが可能になる。車両状態とＥＣＵの処理負荷或いはバスのトラフィック量とは、ある程度の関連性を有するので、車両状態が適切な状態である場合に更新処理を行うことは有用である。例えば、駐車状態において更新処理を実行すること、或いは、車両が走行していない状態において更新処理を実行することは、車載ネットワークシステムにおける処理効率を高める効果を生じ、また、走行中のＥＣＵの処理負荷が高まることを抑制できる。また、適切に車両の状態に応じて更新処理を実行することで、更新処理の同期ずれによる通信エラーを抑えることができる。
【００８７】
（実施の形態２）
以下、本開示の別の実施の形態として、複数のバスと、バス間でフレームを転送するゲートウェイとを含む車載ネットワークシステム２０について説明する。車載ネットワークシステム２０は、車両の状態に応じてＭＡＣの生成に利用されるデータの更新に関連した更新処理を行う更新処理方法を実現する。車載ネットワークシステム２０では、各ＥＣＵは、車両の状態と、自機が接続されているバスに送信される更新開始フレームに応じて更新処理を行う。
【００８８】
［２．１  車載ネットワークシステム２０の全体構成］
図１４は、実施の形態２に係る車載ネットワークシステム２０の全体構成を示す図である。車載ネットワークシステム２０は、実施の形態１で示した車載ネットワークシステム１０の一部を変形したものであり、特に説明しない点は車載ネットワークシステム１０と同様である。車載ネットワークシステム２０は、バス２２００ａ、２２００ｂと、ゲートウェイ２４００、及び、各種機器に接続されたＥＣＵ２１００ａ〜２１００ｄ等のＥＣＵといったバスに接続された各ノードとを含んで構成される。車載ネットワークシステム２０の構成要素のうち、実施の形態１と同様の機能を有する構成要素は、同じ符号を付して説明を省略する。
【００８９】
ＥＣＵ２１００ａ〜２１００ｄは、それぞれ、エンジン３１０、ブレーキ３２０、ドア開閉センサ３３０、窓開閉センサ３４０に接続されており、接続されている機器（エンジン３１０等）の状態を取得し、定期的に状態を表すフレームをネットワークに送信している。車載ネットワークシステム２０においてはＣＡＮプロトコルに従って各ＥＣＵがフレームの授受を行う。
【００９０】
ゲートウェイ２４００は、一種のＥＣＵであり、ＥＣＵ２１００ａ及びＥＣＵ２１００ｂがつながるバス２２００ａと、ＥＣＵ２１００ｃ及びＥＣＵ２１００ｄがつながるバス２２００ｂとに接続しており、それぞれのバスから受信したフレームを他のバスに転送する機能を有する。また、受信したフレームを転送するかしないかを接続されたバス間毎に切り替えることも可能である。また、ゲートウェイ２４００は、内部に持つタイマーが予め定められた値になったタイミングで更新開始フレームを送信する機能を有する。更新開始フレームは、予め定められた特定メッセージＩＤで識別され、更新処理の開始を通知する特定フレームである。この更新開始フレームは、ＭＡＣの生成に用いるデータの更新に関連する更新処理を複数のＥＣＵが同期して実行するために、有効に働く。
【００９１】
車載ネットワークシステム２０は、実施の形態１で示した車載ネットワークシステム１０と同様に、例えば、車両におけるギアのセンサ等に接続されて、ギアポジション（例えばパーキング、ニュートラル、１速、２速等）から車両状態を特定して、特定した車両状態を通知するためのフレームを送信するＥＣＵ（不図示）を含み得る。また、車載ネットワークシステム１０は、複数のＥＣＵから通知された情報に基づいて車両状態を特定して、特定した車両状態を通知するためのフレームを送信するＥＣＵ（不図示）を含むこととしても良い。
【００９２】
［２．２  ＥＣＵ２１００ａの構成］
図１５は、ＥＣＵ２１００ａの構成図である。ＥＣＵ２１００ａは、フレーム送受信部１０１と、フレーム解釈部１０２と、受信ＩＤ判断部１０３と、受信ＩＤリスト保持部１０４と、フレーム処理部２１０５と、車両状態保持部１０６と、判定ルール保持部２１０７と、更新判定部２１０９と、更新処理部１１０と、ＭＡＣ鍵保持部１１１と、カウンタ保持部１１２と、ＭＡＣ生成部１１３と、フレーム生成部１１４と、データ取得部１１５と、エリア種別保持部２１１６とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、ＥＣＵ２１００ａにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。なお、ＥＣＵ２１００ｂ〜２１００ｄも同様の構成である。実施の形態１と同様の機能を有する構成要素は、同じ符号を付して説明を省略する。
【００９３】
判定ルール保持部２１０７は、エリア種別（後述）及び車両状態に応じて更新処理を行うかどうかを対応付けた判定ルールを保持する。図１６は、各エリア種別についての車両状態に応じた判定ルールの一例を示した図である。
【００９４】
フレーム処理部２１０５は、実施の形態１で示したフレーム処理部１０５の一部を変形したものであり、フレーム解釈部１０２より受信した全てのデータフレームのメッセージＩＤとデータフィールドの値とに対して、ＭＡＣ鍵保持部１１１よりメッセージＩＤに対応したＭＡＣ鍵を取得し、カウンタ保持部１１２よりメッセージＩＤに対応したカウンタ値を取得し、データフィールドに含まれるＭＡＣ値を検証する。検証の結果、エラーと判定（つまり検証に失敗したと判定）すれば、フレーム解釈部１０２へ通知し、以降の受信処理を中止する。また、車両状態を通知するフレームを受信した場合、車両状態保持部１０６へそのフレームに応じた車両状態を通知する。また、フレーム処理部２１０５は、更新開始フレームを受信した場合、更新判定部２１０９に通知する。また、フレーム処理部２１０５は、受信したフレームのデータに応じて、ＥＣＵ毎に異なる処理を行う。例えば、ＥＣＵ２１００ａでは、時速が３０ｋｍを超えた状態でドアが開いている状態だと、アラーム音を鳴らす機能を備える。ＥＣＵ２１００ｃでは、ブレーキがかかっていない状況でドアが開くとアラーム音を鳴らす機能を備える。ＥＣＵ２１００ｂ、２１００ｄでは特に何もしない。なお、ＥＣＵ２１００ａ〜２１００ｄは上記以外の機能を備えていてもよい。また、データフレーム内のＡＣＫフィールドの値を確認し、ＥＣＵ２１００ａが送信したフレームが、他のＥＣＵに正常に受信されているかどうかを確認し、確認した結果を更新処理部１１０へ通知する。
【００９５】
更新判定部２１０９は、ゲートウェイ２４００から送信された更新開始フレームを受信した旨をフレーム処理部２１０５から通知されたタイミングで、エリア種別保持部２１１６からＥＣＵ２１００ａが接続されたバス２２００ａの種別を取得し、車両状態保持部１０６から現在の車両状態を取得し、判定ルール保持部１０７から取得した判定ルールに応じて、ＭＡＣの生成に利用されるデータ（つまりＭＡＣ鍵、カウンタ値）の更新に関連する更新処理を実行するか否かを判定する。更新処理は、具体的には、ＭＡＣを生成するために用いる鍵であるＭＡＣ鍵の値を更新する鍵更新処理と、ＭＡＣに反映するカウンタ値をリセット（つまりゼロ等の特定値に更新）するカウンタリセット処理とを意味する。更新判定部１０９は、ＭＡＣの生成に利用されるデータを更新すると決定（判定）した場合には、更新処理部１１０へ通知する。更新しないと判定（決定）した場合は、車両状態の変化を待つ。
【００９６】
エリア種別保持部２１１６は、自機（ＥＣＵ２１００ａ）が接続されているバス２２００ａの種別としてのエリア種別を保持する。エリア種別は、バス及びそのバスに接続されたＥＣＵが、複数のグループのいずれに属しているかを識別し得るものであり、そのグループは、例えば「駆動系」、「ボディ系」等の、ＥＣＵが接続された機器群の性質等により区別される。ここでは説明の便宜上、車載ネットワークシステム２０が２つのバス（バス２２００ａ、バス２２００ｂ）を有する例示しているが、車載ネットワークシステムにおいて、より多くのバスを含むことは想定され、多数のバスのうちの一部の複数のバスが同じエリア種別に該当（つまり同じグループに所属）しても良い。バスのエリア種別の具体的な一例としては、エンジン３１０と接続するＥＣＵ２１００ａ及びブレーキ３２０と接続するＥＣＵ２１００ａと接続されたバスは、「駆動系」というエリア種別に該当し、ドア開閉センサ３３０と接続するＥＣＵ２１００ｃ及び窓開閉センサ３４０と接続するＥＣＵ２１００ｄと接続されたバスは、「ボディ系」というエリア種別に該当する。この例によれば、ＥＣＵ２１００ａのエリア種別保持部２１１６には、「駆動系」というエリア種別が保持される。
【００９７】
［２．３  判定ルール例］
図１６は、ＥＣＵ２１００ａ〜２１００ｄが保持する判定ルールの一例を示す図である。この判定ルールは、エリア種別毎に、更新処理を実行する条件としての、車載ネットワークシステム２０を搭載している車両の状態（車両状態）を定めるものであり、あるエリア種別のバスに接続されたＥＣＵにおいてそのエリア種別に対応して車両状態が判定ルールで定められた所定状態（例えば「駐車中」等）であれば、更新処理の実行が可能となる。同図に例示する判定ルールは、「駆動系」というエリア種別のバスに接続されているＥＣＵ２１００ａ及びＥＣＵ２１００ｂについては、車両状態が「走行中」及び「停車中」のいずれかの場合には、ＭＡＣ鍵更新等に関する更新処理を実施すべき更新タイミング（つまり更新開始フレームを受信したタイミング）が到来しても更新処理を実施せずに待機し、その後に車両状態が「駐車中」に変化したタイミングで更新処理を実施することを示し、また、車両状態が「駐車中」の場合には、更新タイミングが到来すれば更新処理を実施することを示している。また、「ボディ系」というエリア種別のバスに接続されているＥＣＵ２１００ｃ及びＥＣＵ２１００ｄについては、車両状態が「走行中」では、更新タイミングが到来しても更新処理を実施せずに待機し、その後に車両状態が「停車中」又は「駐車中」に変化したタイミングで更新処理を実施することを示し、また、車両状態が「停車中」及び「駐車中」のいずれかの場合には、更新タイミングが到来すれば更新処理を実施することを示している。
【００９８】
［２．４  ゲートウェイ２４００の構成］
図１７は、ゲートウェイ２４００の構成図である。ゲートウェイ２４００は、フレーム送受信部２４０１と、フレーム解釈部２４０２と、受信ＩＤ判断部２４０３と、受信ＩＤリスト保持部２４０４と、フレーム処理部２４０５と、車両状態保持部２４０６と、判定ルール保持部２４０７と、更新判定部２４０９と、更新処理部２４１０と、ＭＡＣ鍵保持部２４１１と、カウンタ保持部２４１２と、ＭＡＣ生成部２４１３と、フレーム生成部２４１４と、エリア種別保持部２４１６と、転送処理部２４１７と、転送ルール保持部２４１８と、更新処理タイマー２４１９とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、ゲートウェイ２４００における通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。
【００９９】
フレーム送受信部２４０１は、ＥＣＵ２１００ａのフレーム送受信部１０１と同様であり、バス２２００ａ、２２００ｂそれぞれに対して、ＣＡＮプロトコルに従ったフレームを送受信する。フレーム送受信部２４０１は、バスからフレームを受信し、フレーム解釈部２４０２に転送する。また、フレーム送受信部２４０１は、フレーム生成部２４１４より通知を受けた転送先のバスを示すバス情報及びフレームに基づいて、そのフレームの内容をバス２２００ａ、２２００ｂに送信する。
【０１００】
フレーム解釈部２４０２は、フレーム送受信部２４０１よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。ＩＤフィールドと判断した値は受信ＩＤ判断部２４０３へ転送する。フレーム解釈部２４０２は、受信ＩＤ判断部２４０３から通知される判定結果に応じて、ＩＤフィールドの値と、ＩＤフィールド以降に現れるデータフィールド（データ）とを、転送処理部２４１７及びフレーム処理部２４０５へ転送するか、フレームの受信を中止するかを決定する。また、フレーム解釈部２４０２は、ＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するように、フレーム生成部２４１４へ通知する。また、フレーム解釈部２４０２は、エラーフレームを受信した場合、受信中のフレームについてそれ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。フレーム解釈部２４０２は、更新開始フレームにおけるＡＣＫスロットをフレーム処理部２４０５へと通知する。フレーム解釈部２４０２は、更新開始フレーム以外のデータフレームについては、転送処理部２４１７へと通知する。
【０１０１】
受信ＩＤ判断部２４０３は、フレーム解釈部２４０２から通知されるＩＤフィールドの値を受け取り、受信ＩＤリスト保持部２４０４が保持しているメッセージＩＤのリストに従い、そのＩＤフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ＩＤ判断部２４０３は、フレーム解釈部２４０２へ通知する。
【０１０２】
受信ＩＤリスト保持部２４０４は、ＥＣＵ２１００ａの受信ＩＤリスト保持部１０４と同様であり、ゲートウェイ２４００が受信するメッセージＩＤのリストである受信ＩＤリストを保持する。
【０１０３】
フレーム処理部２４０５は、ＥＣＵ２１００ａのフレーム処理部１０５と同様である。車両状態保持部２４０６は、ＥＣＵ２１００ａの車両状態保持部１０６と同様である。判定ルール保持部２４０７は、ＥＣＵ２１００ａの判定ルール保持部１０７と同様である。
【０１０４】
更新判定部２４０９は、自機（ゲートウェイ２４００）が送信した更新開始フレームをフレーム処理部２４０５より受信したタイミングで、エリア種別保持部２４１６からゲートウェイ２４００が接続されているバス２２００ａ及びバス２２００ｂのそれぞれの種別を取得し、車両状態保持部１０６から現在の車両状態を取得し、判定ルール保持部１０７から取得した判定ルールに応じて、更新処理（ＭＡＣ鍵の更新及びカウンタ値のリセット）を実行するか否かを判定する。更新判定部２４０９は、更新処理を実行すると判定した場合には、更新処理部２４１０へ通知する。
【０１０５】
更新処理部２４１０は、ＥＣＵ２１００ａの更新処理部１１０と同様である。
【０１０６】
ＭＡＣ鍵保持部２４１１は、メモリ等の記憶媒体で実現され、ＭＡＣ生成部２４１３及びフレーム処理部２４０５がＭＡＣを計算する際に必要となるＭＡＣ鍵を、バス毎に、かつ、メッセージＩＤ毎に、１つ保持する。ＭＡＣ鍵保持部２４１１は、更新処理部２４１０からの通知に従って、これまで持っていた鍵を破棄し、通知された鍵をＭＡＣ鍵として保持する。本実施の形態では、同一のメッセージＩＤであってもバス毎にＭＡＣ鍵が異なる方式を採るものとして説明する。
【０１０７】
カウンタ保持部２４１２は、メモリ等の記憶媒体を含んで実現され、ＭＡＣ生成部２４１３及びフレーム処理部２４０５がＭＡＣを計算する際に必要となるカウンタ値を、バス毎に、かつ、メッセージＩＤ毎に１つ保持する。なお、カウンタ保持部２４１２に保持されるカウンタ値は、フレームが正常に送信された場合にインクリメント（１増加）される。この方法として、データフレームを送信する場合にカウンタ値を送信カウンタとして扱い、送信回数をカウントする。また、データフレームを受信する場合にカウンタ値を受信カウンタとして扱い、受信回数をカウントする。また、カウンタ保持部２４１２は、更新処理部２４１０からの通知に従って、通知されたカウンタ値を保持し、また、更新処理部２４１０からのリセットすべき旨の通知に従って、保持しているカウンタ値をリセットする。このリセットによりカウンタ値は、ゼロ等の特定値に更新される。本実施の形態では、同一のメッセージＩＤであってもバス毎にカウンタ値が異なる方式を採るものとして説明する。
【０１０８】
ＭＡＣ生成部２４１３は、フレーム生成部２４１４より通知されるメッセージＩＤとデータフィールド用のデータの値と、カウンタ保持部２４１２で保持するカウンタ値（つまり送信するバスとメッセージＩＤに対応したカウンタ値）とを結合した値（結合値）に対し、ＭＡＣ鍵保持部２４１１で保持するＭＡＣ鍵（つまり送信するバスとメッセージＩＤに対応したＭＡＣ鍵）を用いて、ＭＡＣを算出（つまりＭＡＣの値を計算により導出）して、この算出した結果であるＭＡＣをフレーム生成部２４１４へと通知する。ここではＭＡＣの計算方法として、ＨＭＡＣ（非特許文献２参照）を採用し、上述した結合値に対し、所定のブロック分（例えば４ｂｙｔｅｓ）までパディングした値でＭＡＣ鍵を使って計算し、出てきた計算結果の先頭４ｂｙｔｅｓをＭＡＣ値とする。なお、ここでのＭＡＣ値のサイズ、計算方法は一例であり、これに限定されるものではない。
【０１０９】
フレーム生成部２４１４は、フレーム解釈部２４０２から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部２４０１へ通知して送信させる。また、フレーム生成部２４１４は、転送処理部２４１７から通知されたメッセージＩＤと、データフィールドの値をＭＡＣ生成部２４１３へ通知することによりＭＡＣの通知を受ける。フレーム生成部２４１４は、転送処理部２４１７より通知されたメッセージと、データフィールドの値と、ＭＡＣ生成部２４１３より通知されたＭＡＣとに基づきフレームを構成し、フレーム送受信部２４０１へ通知する。また、フレーム生成部２４１４は、更新処理タイマー２４１９より通知された送信指示に従って、更新開始フレーム用に予め決められた特定メッセージＩＤとデータフィールドの値とをＭＡＣ生成部２４１３へ通知することによりＭＡＣの通知を受け取り、その特定メッセージＩＤとデータフィールドの値とＭＡＣとを含む更新開始フレームを生成し、フレーム送受信部２４０１へ通知して送信させる。フレーム生成部２４１４は、更新開始フレームを送信した場合には、更新処理タイマー２４１９でのタイマー値（つまり計時される経過時間の値）をゼロにリセットする。
【０１１０】
更新処理タイマー２４１９は、経過時間に対応するタイマー値のカウントアップを繰り返す計時機構を含んで実現され、タイマー値を０から逐次カウントアップして、タイマー値が予め更新開始フレームを送信するタイミングとして設定された経過時間（例えば、６時間、１日等）を示す値になったら、更新開始フレームを送信する指示をフレーム生成部２４１４へ通知する。また、フレーム生成部２４１４からの通知に従って、タイマー値を０にリセットする。なお、ゲートウェイ２４００は、複数のバス（バス２２００ａ、バス２２００ｂ）に接続しているため、更新処理タイマー２４１９は、それぞれのバスに対応する計時機構（タイマー）を持つこととして、バスそれぞれに更新開始フレームを送信するタイミングは相違しても良い。また、更新開始フレームを送信するタイミングを、計時機構に依らずに他の方法で決定しても良い。例えば、フレーム（メッセージ）の送信毎にカウントアップするカウンタを用いてカウンタ値が予め定められた閾値に到達した時等に更新開始フレームを送信してカウンタをゼロにリセットする方法等がある。
【０１１１】
エリア種別保持部２４１６は、自機（ゲートウェイ２４００）が接続されているバス２２００ａ、バス２２００ｂそれぞれの種別を保持する。例えば、バス２２００ａについては「駆動系」、バス２２００ｂについては「ボディ系」というエリア種別が保持される。
【０１１２】
転送処理部２４１７は、転送ルール保持部２４１８が保持する転送ルールに従って、受信したフレームのメッセージＩＤに応じて、転送するバスを決定し、転送するバスを示すバス情報とフレーム解釈部２４０２より通知されたメッセージＩＤとデータとをフレーム生成部２４１４へ通知する。転送されるべきフレームについては、転送元のバスからゲートウェイ２４００に受信され、ゲートウェイ２４００により転送先のバスに対応したＭＡＣが付与されて、転送先のバスへと送信されることになる。なお、ゲートウェイ２４００は、あるバスから受信されたエラーフレーム、及び、自機が送信したバスから受信される更新開始フレームについては他のバスに転送しない。
【０１１３】
転送ルール保持部２４１８は、バス毎のフレームの転送についてのルールを表す情報である転送ルールを保持する。図１８は、転送ルールの一例を示した図である。
【０１１４】
［２．５  転送ルール例］
図１８は、ゲートウェイ２４００が保有する転送ルールの一例を示す。この転送ルールは、転送元のバスと転送先のバスと転送対象のＩＤ（メッセージＩＤ）とを対応付けている。図１８中の「＊」はメッセージＩＤにかかわらずフレームの転送がなされることを表している。同図の例は、バス２２００ａから受信するフレームはメッセージＩＤにかかわらず、バス２２００ｂに転送するように設定されていることを示している。また、バス２２００ｂから受信するフレームのうちメッセージＩＤが「３」であるフレームのみがバス２２００ａに転送されるように設定されていることを示している。
【０１１５】
［２．６  更新処理］
以下、各ＥＣＵによるデータフレームの送信に際してのＭＡＣの付与、及び、データフレームの受信に際してのＭＡＣの検証において用いられるＭＡＣの生成に必要となるデータの更新に関連した更新処理について説明する。各バスにおいて、そのバスに接続された複数のＥＣＵにおいてメッセージ毎にＭＡＣの付与及び検証に用いるＭＡＣ鍵及びカウンタ値に関する更新は、同期して実行される必要がある。ここでは、一例として、ゲートウェイ２４００が、バス２２００ａに更新開始フレームを送信するために更新開始フレーム送信処理を実行し、その後に一定条件下でＥＣＵ２１００ａが更新の同期を確認するための更新フレームをバス２２００ａに送信し、ＥＣＵ２１００ｂが更新フレームをバス２２００ａから受信する例を用いて、１つのバスに接続された複数のＥＣＵにおける、１つのメッセージＩＤに対応するＭＡＣに係る更新処理について説明する。
【０１１６】
図１９は、ゲートウェイ２４００による更新開始フレーム送信処理の一例を示すフローチャートである。
【０１１７】
ゲートウェイ２４００は、更新処理タイマー２４１９により、前回の更新開始フレームを送信した時からの経過時間を確認する（ステップＳ２００１）。そしてゲートウェイ２４００は、経過時間が予め定められた時間に達して、更新開始フレームを送信すべきタイミングが到来しているかどうかを判定する（ステップＳ２００２）。送信すべきタイミングが到来していない場合には、経過時間がその予め定められた時間に達するまで、経過時間の確認を繰り返す。送信すべきタイミングが到来している場合には、ゲートウェイ２４００は、更新開始フレームを生成する（ステップＳ２００３）。即ち、ゲートウェイ２４００は、予め定められたメッセージＩＤ、データフィールドのデータ値、カウンタ値及びＭＡＣ鍵を用いてＭＡＣを生成して、ＭＡＣを付加した更新開始フレームを生成する。
【０１１８】
ゲートウェイ２４００は、ステップＳ２００３で生成した更新開始フレームをバス２２００ａへと送信する（ステップＳ２００４）。このバス２２００ａに送信された更新開始フレームは、バス２２００ａに接続されたＥＣＵ２１００ａ及びＥＣＵ２１００ｂに受信されることになる。
【０１１９】
図２０及び図２１は、ＥＣＵ２１００ａによる更新処理、及び、その更新処理の開始判断に係る処理の一例を示すフローチャートである。なお、図２０及び図２１に示す処理手順（ステップ）のうち図１０及び図１１で示したステップと同一のステップについては、同じ符号を用いており、説明を適宜省略する。以下、図２０及び図２１に即してＥＣＵ２１００ａの動作について説明する。
【０１２０】
ＥＣＵ２１００ａは、ゲートウェイ２４００が送信した更新開始フレームを受信する（ステップＳ２１０１）。そしてＥＣＵ２１００ａは、更新開始フレームのＭＡＣを検証する（ステップＳ２１０２）。ＭＡＣの検証に失敗すれば処理を終える。
【０１２１】
ステップＳ２１０２でのＭＡＣの検証に成功すれば、ＥＣＵ２１００ａは、エリア種別保持部２１１６が保持するエリア種別を確認する（ステップＳ２１０３）。続いて、現在の車両状態を確認し（ステップＳ１００３）、現在の車両状態に基づいて、ステップＳ２１０３で確認したエリア種別に対応して判定ルール保持部２４０７で保持されている判定ルールに従って、更新処理を行うかどうかを判定する（ステップＳ２１０４）。車両状態が判定ルールで定められた更新処理を行う状態に変化するまで更新処理は行わず、車両状態の確認を継続する（ステップＳ１００３）。また、車両状態が判定ルールで定められた更新処理を行う状態であれば、図２１のステップＳ１００６以降の更新処理を開始する（ステップＳ１００５）。図１６に示した「駆動系」に対応する判定ルールの例に従うと、車両状態が「走行中」「停車中」であれば、車両状態が「駐車中」に変化するまで待ってから更新処理を行い、また、車両状態が「駐車中」であれば即座に更新処理を開始する（ステップＳ１００５）。
【０１２２】
更新処理を開始したＥＣＵ２１００ａは、実施の形態１で示したＥＣＵ１００ａと同様に更新処理を行う（図２１のステップＳ１００６〜Ｓ１０１９）。
【０１２３】
図２２及び図２３は、ＥＣＵ２１００ｂによる更新処理、及び、その更新処理の開始判断に係る処理の一例を示すフローチャートである。なお、図２２及び図２３に示す処理手順（ステップ）のうち図１２、図１３及び図２０で示したステップと同一のステップについては、同じ符号を用いており、説明を適宜省略する。以下、図２２及び図２３に即してＥＣＵ２１００ｂの動作について説明する。
【０１２４】
ＥＣＵ２１００ｂは、ゲートウェイ２４００が送信した更新開始フレームを受信する（ステップＳ２１０１）。そしてＥＣＵ２１００ｂは、更新開始フレームのＭＡＣを検証する（ステップＳ２１０２）。ＭＡＣの検証に失敗すれば処理を終える。
【０１２５】
ステップＳ２１０２でのＭＡＣの検証に成功すれば、ＥＣＵ２１００ｂは、エリア種別保持部２１１６が保持するエリア種別を確認する（ステップＳ２１０３）。続いて、現在の車両状態を確認し（ステップＳ１００３）、現在の車両状態に基づいて、ステップＳ２１０３で確認したエリア種別に対応して判定ルール保持部２４０７で保持されている判定ルールに従って、更新処理を行うかどうかを判定する（ステップＳ２１０４）。車両状態が判定ルールで定められた更新処理を行う状態に変化するまで更新処理は行わず、車両状態の確認を継続する（ステップＳ１００３）。また、車両状態が判定ルールで定められた更新処理を行う状態であれば、図２３のステップＳ２１０１以降の更新処理を開始する（ステップＳ１００５）。図１６に示した「駆動系」に対応する判定ルールの例に従うと、車両状態が「走行中」「停車中」であれば、車両状態が「駐車中」に変化するまで待ってから更新処理を行い、また、車両状態が「駐車中」であれば即座に更新処理を開始する（ステップＳ１００５）。
【０１２６】
更新処理を開始したＥＣＵ２１００ｂは、実施の形態１で示したＥＣＵ１００ｂと同様に更新処理を行う（図２３のステップＳ２１０１〜Ｓ１０１９）。
【０１２７】
また、上述した図２２及び図２３に示した更新処理、及び、その更新処理の開始判断に係る処理については、ゲートウェイ２４００もＥＣＵ２１００ｂと同様に行う。
【０１２８】
なお、ゲートウェイ２４００は、同様に更新開始フレーム送信処理（図１９参照）によりバス２２００ｂに更新開始フレームを送信することができ、これに対して、図２０〜図２３に示す処理手順によりＥＣＵ２１００ｃ及びＥＣＵ２１００ｄが更新処理を実行し得る。
【０１２９】
［２．７  実施の形態２の効果］
実施の形態２で示したＥＣＵは、ＭＡＣの生成に用いるデータの更新に関する更新処理（ＭＡＣ鍵の更新、カウンタ値のリセット等）を、自機が接続するバスのエリア種別と、車両の状態とに応じて実行する。この更新処理が適時に実行されるようになるため、不正なノードによるＭＡＣに対する総当り攻撃への耐性が高まる。なお、駆動系、ボディ系等といったエリア種別で区別されるバス毎にそのバスに接続されるＥＣＵの実行する処理の処理量と車両状態との関係は変動し得る。従って、エリア種別毎及び車両状態毎に判定ルールを定めることにより、例えば駆動系のバスに接続される複数のＥＣＵの処理負荷の低い駐車中等においてその複数のＥＣＵのＭＡＣ鍵の更新等を行わせることで、効率良く、複数のＥＣＵが更新を同期して実行できるようになる。これにより、ＭＡＣの生成に用いるＭＡＣ鍵の更新及びカウンタ値のリセットを関連性の高いＥＣＵのグループ毎（接続されるバスのエリア種別毎）に分散して適切なタイミングで実行することができるようになる。また、ＥＣＵが送信するフレームでバスのトラフィック量が比較的高い場合（例えば走行中等）を避けるように車両の状態に応じて更新処理を行わせることが可能になる。
【０１３０】
（他の実施の形態）
以上のように、本開示に係る技術の例示として実施の形態１、２を説明した。しかしながら、本開示に係る技術は、これに限定されず、適宜、変更、置き換え、付加、省略等を行った実施の形態にも適用可能である。例えば、以下のような変形例も本開示の一実施態様に含まれる。
【０１３１】
（１）上記実施の形態では、ＥＣＵ１００ａ〜１００ｄ或いはＥＣＵ２１００ａ〜２１００ｄによりフレームが定期的に送信される例を示したが、フレームは、状態変化を通知するイベントとして送信されることとしても良い。例えば、ＥＣＵは、ドアの開閉状態を定期的に送信するのではなく、ドアの開閉状態が変化した場合にのみ、フレームを送信するとしても良い。また、ＥＣＵがフレームを、定期的に送信、かつ、状態変化が発生した時に送信することとしても良い。
【０１３２】
（２）上記実施の形態では、データ値とカウンタ値からＭＡＣを算出する例を示したが、データ値のみからＭＡＣを算出することとしても良い。またカウンタ値のみからＭＡＣを算出することとしても良い。また、データフレームに含まれる他のフィールドの値を用いてＭＡＣを算出することとしても良い。また、フレームに含まれるＭＡＣのサイズは４ｂｙｔｅｓに制限されるものではなく、送信毎に異なるサイズであっても良い。同様にカウンタ値のサイズも１ｂｙｔｅに制限されるものではない。また、必ずしもフレームにカウンタ値が含まれていなくても良い。また、全部又は一部のカウンタ値をフレームに含めて送信しても良い。また、ＭＡＣサイズは固定のサイズに限定されるものではなく、メッセージＩＤ毎に異なるサイズであってもよい。また、複数のフレームに跨ってＭＡＣが送信されるようにしても良い。
【０１３３】
（３）上記実施の形態では、データフレームの送信回数（或いは受信回数）をカウントする構成としてカウンタ値を送信毎にインクリメントする例を示したが、カウンタの値に対する演算は、インクリメント（１増加）には限定されない。２以上の増加を行っても良いし、インクリメントによるアップカウントに限らず、デクリメントによるダウンカウントでも良い。また、カウンタ値に対する演算は、例えば、ビットシフトであっても良いし、前回の演算結果を入力値として予め定められたアルゴリズムに基づいて特定された出力値を演算結果とする演算等であっても良い。なお、更新処理では、カウンタ値をリセットによりゼロ等の特定値にする。
【０１３４】
（４）上記実施の形態では、ＣＡＮプロトコルにおけるデータフレームを標準ＩＤフォーマットで記述しているが、拡張ＩＤフォーマットで合っても良い。拡張ＩＤフォーマットの場合には、標準ＩＤフォーマットにおけるＩＤ位置のベースＩＤと、拡張ＩＤとを合わせて２９ビットでＩＤ（メッセージＩＤ）を表すので、この２９ビットのＩＤを上述の実施の形態におけるＩＤ（メッセージＩＤ）と扱えば良い。
【０１３５】
（５）上記実施の形態では、ＭＡＣ算出のアルゴリズムをＨＭＡＣとしているが、これＣＢＣ−ＭＡＣ（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）、半導体メモリ等に記録したものとしても良い。また、これらの記録媒体に記録されている前記デジタル信号であるとしても良い。また、本開示の一態様としては、前記コンピュータプログラムまたは前記デジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしても良い。また、本開示の一態様としては、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記録しており、前記マイクロプロセッサは、前記コンピュータプログラムに従って動作するとしても良い。また、前記プログラムまたは前記デジタル信号を前記記録媒体に記録して移送することにより、または前記プログラムまたは前記デジタル信号を前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしても良い。
【０１５４】
（２４）上記実施の形態及び上記変形例で示した各構成要素及び機能を任意に組み合わせることで実現される形態も本開示の範囲に含まれる。
【産業上の利用可能性】
【０１５５】
本開示は、車載ネットワークシステムにおいて不正なノードによる攻撃への耐性を高めるために利用可能である。
【符号の説明】
【０１５６】
１０，２０  車載ネットワークシステム
１０１，２４０１  フレーム送受信部
１０２，２４０２  フレーム解釈部
１０３，２４０３  受信ＩＤ判断部
１０４，２４０４  受信ＩＤリスト保持部
１０５，２１０５，２４０５  フレーム処理部
１０６，２４０６  車両状態保持部
１０７，２１０７，２４０７  判定ルール保持部
１０８  タイマー
１０９，２１０９，２４０９  更新判定部
１１０，２４１０  更新処理部
１１１，２４１１  ＭＡＣ鍵保持部
１１２，２４１２  カウンタ保持部
１１３，２４１３  ＭＡＣ生成部
１１４，２４１４  フレーム生成部
１１５  データ取得部
２００，２２００ａ，２２００ｂ  バス
３１０  エンジン
３２０  ブレーキ
３３０  ドア開閉センサ
３４０  窓開閉センサ
２１１６，２４１６  エリア種別保持部
２４００  ゲートウェイ
２４１７  転送処理部
２４１８  転送ルール保持部
２４１９  更新処理タイマー
【図１】
2015170452.tif 000003
【図２】
2015170452.tif 000004
【図３】
2015170452.tif 000005
【図４】
2015170452.tif 000006
【図５】
2015170452.tif 000007
【図６】
2015170452.tif 000008
【図７】
2015170452.tif 000009
【図８】
2015170452.tif 000010
【図９】
2015170452.tif 000011
【図１０】
2015170452.tif 000012
【図１１】
2015170452.tif 000013
【図１２】
2015170452.tif 000014
【図１３】
2015170452.tif 000015
【図１４】
2015170452.tif 000016
【図１５】
2015170452.tif 000017
【図１６】
2015170452.tif 000018
【図１７】
2015170452.tif 000019
【図１８】
2015170452.tif 000020
【図１９】
2015170452.tif 000021
【図２０】
2015170452.tif 000022
【図２１】
2015170452.tif 000023
【図２２】
2015170452.tif 000024
【図２３】
2015170452.tif 000025
【国際調査報告】
2015170452.tif 000026
2015170452.tif 000027
2015170452.tif 000028
2015170452.tif 000029