(57)【要約】【課題】データの認証に失敗した際に従来技術とは別の手法でデータの認証を実行可能なネットワークシステムを提供する。【解決手段】ネットワークシステム１は、複数の電子装置２Ａ，２Ｂ，２Ｃ，２Ｄのうち、いずれか１つの電子装置をマスタ装置、当該マスタ装置以外の電子装置をスレーブ装置として、複数の電子装置それぞれのメッセージ認証機能が正常に機能するか否かを検証するための検証処理を実行可能に構成される。検証処理では、検証用データをローカルバス経由で送受信し、検証用データに対してメッセージ認証を実行し、複数の電子装置それぞれのメッセージ認証機能が正常に機能するか否かを判断する。【選択図】図１
2020188314.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークシステム（１）であって、
複数の電子装置（２Ａ，２Ｂ，２Ｃ，２Ｄ）と、前記複数の電子装置それぞれが接続されるグローバルバス（５Ａ，５Ｂ）と、前記複数の電子装置それぞれが接続されるローカルバス（６）とを含み、
前記複数の電子装置は、前記グローバルバス経由及び前記ローカルバス経由で相互に通信可能、かつ前記グローバルバス経由で前記ネットワークシステムの外部にある外部機器と通信可能に構成され、
前記複数の電子装置のうち、いずれか１つの前記電子装置をマスタ装置、当該マスタ装置以外の前記電子装置をスレーブ装置として、
前記マスタ装置及び前記スレーブ装置は、前記複数の電子装置それぞれのメッセージ認証機能が正常に機能するか否かを検証するための検証処理（Ｓ４０１−Ｓ４１５，Ｓ５０１−Ｓ５１５，Ｓ６０１−Ｓ６１９）を実行可能に構成され、当該検証処理では、検証用データを前記ローカルバス経由で送受信し（Ｓ４０１，Ｓ６０１）、前記検証用データに対してメッセージ認証を実行し（Ｓ６０３，Ｓ６０７，Ｓ６０９，Ｓ６１７）、その認証結果に基づいて、前記複数の電子装置それぞれのメッセージ認証機能が正常に機能するか否かを判断するように構成され（Ｓ４０５−Ｓ４０９，Ｓ４１３，Ｓ５０３−Ｓ５０９，Ｓ５１３）、
前記電子装置は、前記グローバルバス経由で処理対象データを受信した際、前記検証処理において前記メッセージ認証機能が正常に機能すると判断されている場合には第１処理（Ｓ８０１−Ｓ８０９）を実行する一方、前記検証処理において前記メッセージ認証機能が正常に機能しないと判断されている場合には第２処理（Ｓ１００１−Ｓ１００５，Ｓ１２０１−Ｓ１２１５）を実行するように構成され、前記第１処理を実行した場合には、前記処理対象データに対するメッセージ認証を実行し（Ｓ８０３）、その認証結果に応じた処理（Ｓ８０５−Ｓ８０９）を実行するように構成され、前記第２処理を実行した場合には、自身以外の前記電子装置に対して前記処理対象データに対するメッセージ認証の代行を依頼し（Ｓ１００５）、その依頼先の前記電子装置で前記処理対象データに対するメッセージ認証を実行し（Ｓ１１０７）、前記依頼先の電子装置から提供される認証結果に応じた処理（Ｓ１２０３−Ｓ１２１３）を実行するように構成されている
ネットワークシステム。
【請求項２】
請求項１に記載のネットワークシステムであって、
前記マスタ装置は、前記検証用データを前記スレーブ装置に対して前記ローカルバス経由で送信するように構成され（Ｓ４０１）、
前記スレーブ装置は、前記マスタ装置から前記検証用データを受信した場合に（Ｓ６０１）、前記検証用データに対してメッセージ認証を実行し（Ｓ６０３，Ｓ６０７，Ｓ６０９，Ｓ６１７）、その認証結果を前記マスタ装置に対して前記ローカルバス経由で送信するように構成されている（Ｓ６０５，Ｓ６１１，Ｓ６１３，Ｓ６１９）
ネットワークシステム。
【請求項３】
請求項２に記載のネットワークシステムであって、
前記マスタ装置は、前記スレーブ装置から前記認証結果を受信した場合に（Ｓ５０１）、前記認証結果に基づいて、前記複数の電子装置それぞれのメッセージ認証機能が正常に機能するか否かを判断するように構成されている（Ｓ５０３−Ｓ５０９，Ｓ５１３）
ネットワークシステム。
【請求項４】
請求項１から請求項３までのいずれか一項に記載のネットワークシステムであって、
前記マスタ装置及び前記スレーブ装置は、各装置において既知のデータである第１データが含まれる前記検証用データを利用するように構成されている
ネットワークシステム。
【請求項５】
請求項４に記載のネットワークシステムであって、
前記第１データは、前記グローバルバス経由でフレッシュネス値管理マスタから送信されてくるフレッシュネス値である
ネットワークシステム。
【請求項６】
請求項５に記載のネットワークシステムであって、
前記スレーブ装置は、前記フレッシュネス値管理マスタから受信した前記フレッシュネス値である第１フレッシュネス値と、前記マスタ装置から受信した前記検証用データに含まれる前記フレッシュネス値である第２フレッシュネス値とが一致するか否かを検証するように構成され（Ｓ６０３）、しかも、前記第１フレッシュネス値と前記第２フレッシュネス値とが一致しない場合には、前記第１フレッシュネス値を変更して再検証を実行するように構成され（Ｓ６１７）、当該再検証は、当該再検証を実行した回数があらかじめ定められた上限回数以下である場合に実行されるように構成されている（Ｓ６１５）
ネットワークシステム。
【請求項７】
請求項１から請求項６までのいずれか一項に記載のネットワークシステムであって、
前記マスタ装置及び前記スレーブ装置は、前記グローバルバス経由での通信が実施される頻度と同等以上の頻度で前記検証処理を実行するように構成されている
ネットワークシステム。
【請求項８】
請求項１から請求項７までのいずれか一項に記載のネットワークシステムであって、
前記複数の電子装置は、カウント値が順に変更されるように構成されたカウンタ（１２Ｂ）を備え、前記カウント値に基づいて、前記マスタ装置として機能すべきか前記スレーブ装置として機能すべきかの判断を実行するように構成されている（Ｓ１０１）
ネットワークシステム。
【請求項９】
請求項８に記載のネットワークシステムであって、
前記マスタ装置は、前記スレーブ装置に対して前記カウント値を送信し（Ｓ２０１）、当該カウント値の送信後に所定の時間が経過しても前記スレーブ装置から応答がない場合には（Ｓ２０３−Ｓ２０５）、当該スレーブ装置を前記ネットワークシステムから切り離すように構成されている（Ｓ２０７）
ネットワークシステム。
【請求項１０】
請求項８又は請求項９に記載のネットワークシステムであって、
前記スレーブ装置は、所定の時間が経過しても前記マスタ装置から前記カウント値を受信できない場合には（Ｓ３０１−Ｓ３０３）、前記マスタ装置を前記ネットワークシステムから切り離すように構成されている（Ｓ３０５）
ネットワークシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、ネットワークシステムに関する。
【背景技術】
【０００２】
セキュリティ処理ＣＰＵが故障した場合でも、セキュリティ処理ＣＰＵに代わって、汎用処理ＣＰＵが、データの暗号化、復号、認証等を実行するように構成された情報処理装置が提案されている（例えば、特許文献１参照。）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１５−１１９３５７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、上記特許文献１に記載の情報処理装置では、暗号ハードウェアにおいてセキュリティ処理ＣＰＵ以外の箇所が故障した場合には、データの認証等を実行できなくなるおそれがある。一例を挙げれば、例えば上記特許文献１に記載の情報処理装置において、セキュア記憶装置が故障した場合には、汎用処理ＣＰＵからセキュア記憶装置へのアクセスでエラーが発生し、汎用処理ＣＰＵではデータの認証等を実行できなくなるおそれがある。
【０００５】
本開示の一局面は、データの認証に失敗した際に上記従来技術とは別の手法でデータの認証を実行可能なネットワークシステムを提供することにある。
【課題を解決するための手段】
【０００６】
本開示の一態様は、ネットワークシステム（１）である。当該ネットワークシステムは、複数の電子装置（２Ａ，２Ｂ，２Ｃ，２Ｄ）と、グローバルバス（５Ａ，５Ｂ）と、ローカルバス（６）とを含む。グローバルバスは、複数の電子装置それぞれが接続される。ローカルバスは、複数の電子装置それぞれが接続される。複数の電子装置は、グローバルバス経由及びローカルバス経由で相互に通信可能、かつグローバルバス経由でネットワークシステムの外部にある外部機器と通信可能に構成される。複数の電子装置のうち、いずれか１つの電子装置をマスタ装置、当該マスタ装置以外の電子装置をスレーブ装置として、マスタ装置及びスレーブ装置は、複数の電子装置それぞれのメッセージ認証機能が正常に機能するか否かを検証するための検証処理（Ｓ４０１−Ｓ４１５，Ｓ５０１−Ｓ５１５，Ｓ６０１−Ｓ６１９）を実行可能に構成され、当該検証処理では、検証用データをローカルバス経由で送受信し（Ｓ４０１，Ｓ６０１）、検証用データに対してメッセージ認証を実行し（Ｓ６０３，Ｓ６０７，Ｓ６０９，Ｓ６１７）、その認証結果に基づいて、複数の電子装置それぞれのメッセージ認証機能が正常に機能するか否かを判断するように構成される（Ｓ４０５−Ｓ４０９，Ｓ４１３，Ｓ５０３−Ｓ５０９，Ｓ５１３）。電子装置は、グローバルバス経由で処理対象データを受信した際、検証処理においてメッセージ認証機能が正常に機能すると判断されている場合には第１処理（Ｓ８０１−Ｓ８０９）を実行する一方、検証処理においてメッセージ認証機能が正常に機能しないと判断されている場合には第２処理（Ｓ１００１−Ｓ１００５，Ｓ１２０１−Ｓ１２１５）を実行するように構成され、第１処理を実行した場合には、処理対象データに対するメッセージ認証を実行し（Ｓ８０３）、その認証結果に応じた処理（Ｓ８０５−Ｓ８０９）を実行するように構成され、第２処理を実行した場合には、自身以外の電子装置に対して処理対象データに対するメッセージ認証の代行を依頼し（Ｓ１００５）、その依頼先の電子装置で処理対象データに対するメッセージ認証を実行し（Ｓ１１０７）、依頼先の電子装置から提供される認証結果に応じた処理（Ｓ１２０３−Ｓ１２１３）を実行するように構成されている。
【０００７】
このように構成されたネットワークシステムによれば、複数の電子装置は、上述のような検証処理を実行し、複数の電子装置それぞれのメッセージ認証機能が正常に機能するか否かを判断する。各電子装置は、グローバルバス経由で処理対象データを受信した際、検証処理においてメッセージ認証機能が正常に機能すると判断されている場合には第１処理を実行する。第１処理を実行した場合、電子装置は、処理対象データに対するメッセージ認証を実行し、その認証結果に応じた処理を実行する。一方、検証処理においてメッセージ認証機能が正常に機能しないと判断されている場合には第２処理を実行する。第２処理を実行した場合、電子装置は、自身以外の電子装置に対して処理対象データに対するメッセージ認証の代行を依頼し、その依頼先の電子装置で処理対象データに対するメッセージ認証を実行し、依頼先の電子装置から提供される認証結果に応じた処理を実行する。
【０００８】
したがって、いずれかの電子装置において処理対象データに対するメッセージ認証に失敗した場合でも、依頼先の電子装置において処理対象データに対するメッセージ認証に成功すれば、依頼先の電子装置から提供される認証結果に応じた処理を実行できる。
【０００９】
また、上記ネットワークシステムの場合、検証用データに対するメッセージ認証を、処理対象データに対するメッセージ認証とは別に実行する。そのため、処理対象データに対するメッセージ認証を実行する際に、加えてメッセージ認証機能が正常に機能するか否かを検証する場合に比べ、処理対象データに対する処理を簡素化し、当該処理を迅速に完了させることができる。また、処理対象データに対する処理を実行していない空き時間を利用して、検証用データに対するメッセージ認証を実行することができる。よって、処理対象データに応じた制御等を遅滞なく実行することができ、当該制御等のリアルタイム性を向上させることができる。
【図面の簡単な説明】
【００１０】
【図１】図１はネットワークシステムを示す説明図である。
【図２】図２はＥＣＵを示す説明図である。
【図３】図３はネットワークにおいて伝送されるデータの構造を示す説明図である。
【図４】図４はＥＣＵが実行するマスタ判別処理のフローチャートである。
【図５】図５はマスタＥＣＵが実行するマスタ判別カウンタ同期処理のフローチャートである。
【図６】図６はスレーブＥＣＵが実行するマスタ判別カウンタ同期処理のフローチャートである。
【図７】図７はマスタＥＣＵが実行するフレッシュネス値の異常検証処理のフローチャートである。
【図８】図８はマスタＥＣＵが実行するメッセージ認証機能の異常判断処理のフローチャートである。
【図９】図９はスレーブＥＣＵが実行するフレッシュネス値及びメッセージ認証機能の異常判断処理のフローチャートである。
【図１０】図１０はスレーブＥＣＵが実行する代替処理移行処理のフローチャートである。
【図１１】図１１はＥＣＵがグローバルバス経由で処理対象データを受信した際に実行する通常処理のフローチャートである。
【図１２】図１２はメッセージ認証処理のフローチャートである。
【図１３】図１３はＥＣＵがグローバルバス経由で処理対象データを受信した際に実行する代替処理のフローチャートである。
【図１４】図１４は依頼先となるＥＣＵがローカルバス経由でデータを受信した際に実行する処理のフローチャートである。
【図１５】図１５は依頼元となるＥＣＵがローカルバス経由でデータを受信した際に実行する代替処理のフローチャートである。
【図１６】図１６はネットワークシステムにおける通信シーケンスの一例を示すシーケンスチャートである。
【図１７】図１７は検証処理シーケンスの一例を示すシーケンスチャートである。
【発明を実施するための形態】
【００１１】
次に、上述のネットワークシステムについて、例示的な実施形態を挙げて説明する。
［ネットワークシステムの構成］
図１に示すネットワークシステム１は、例えば自動車に搭載される車載ネットワークシステムである。ネットワークシステム１は、複数のＥＣＵ２Ａ，２Ｂ，２Ｃ，２Ｄ，３Ａ，３Ｂ，３Ｃ，３Ｄ、ＣＧＷ４、複数のグローバルバス５Ａ，５Ｂ、ローカルバス６及びフレッシュネス値管理マスタ７等を有する。ＥＣＵは「Electronic Control Unit」の略称である。ＣＧＷは「Central Gateway」の略称である。
【００１２】
ＥＣＵ３Ａ，３Ｂ，２Ａ，２Ｂは、グローバルバス５Ａに接続されている。ＥＣＵ２Ｃ，２Ｄ，３Ｃ，３Ｄは、グローバルバス５Ｂに接続されている。各グローバルバス５Ａ，５Ｂには、例えば、機能的に同系統に分類されるＥＣＵが接続されている。一例を挙げれば、例えば、グローバルバス５Ａにはボデー系ＥＣＵが接続される。グローバルバス５Ｂには制御系ＥＣＵが接続される。
【００１３】
グローバルバス５Ａ，５Ｂは、ＣＧＷ４を介して相互に接続されている。これらの構成により、ＥＣＵ２Ａ〜２Ｄ、ＥＣＵ３Ａ〜３Ｄ、ＣＧＷ４及びグローバルバス５Ａ，５Ｂは、第１ネットワーク１Ａを構成している。ＥＣＵ２Ａ〜２Ｄは、ローカルバス６に接続されている。これにより、ＥＣＵ２Ａ〜２Ｄ及びローカルバス６は、第２ネットワーク１Ｂを構成している。すなわち、ＥＣＵ２Ａ〜２Ｄは、第１ネットワーク１Ａのノードとして機能するように構成され、かつ、第２ネットワーク１Ｂのノードとしても機能するように構成されている。
【００１４】
第１ネットワーク１Ａ及び第２ネットワーク１Ｂでは、各ネットワークを構成するノードに対してブロードキャスト通信によってデータが伝送される。ただし、第１ネットワーク１Ａと第２ネットワーク１Ｂは、互いに独立したネットワークである。そのため、例えば、第１ネットワーク１Ａにおいてデータが伝送された場合でも、そのデータが第２ネットワーク１Ｂへと伝送されることはない。同様に、第２ネットワーク１Ｂにおいてデータが伝送された場合でも、そのデータが第１ネットワーク１Ａへと伝送されることはない。
【００１５】
ＣＧＷ４は、グローバルバス５Ａ，５Ｂの間に介在して、いずれか１つのグローバルバスから残りのグローバルバスへデータを中継する。また、ＣＧＷ４は、外部通信路８に接続可能に構成され、外部通信路８とグローバルバス５Ａ，５Ｂとの間でデータを中継する。これにより、ＥＣＵ２Ａ〜２Ｄ及びＥＣＵ３Ａ〜３Ｄは、第１ネットワーク１Ａ経由で図示しない外部機器と通信可能となっている。なお、第２ネットワーク１Ｂには、外部通信路に接続可能なノードが設けられていない。そのため、第２ネットワーク１Ｂのノードが第２ネットワーク１Ｂ経由で外部機器と通信することはできない。
【００１６】
フレッシュネス値管理マスタ７は、第１ネットワーク１Ａを構成するノードに対してフレッシュネス値を提供する。フレッシュネス値は、フレッシュネス値管理マスタ７において定期的に新たな値に更新される。更新後のフレッシュネス値は、更新前のフレッシュネス値よりも大きい値となる。
【００１７】
外部通信路８は、無線通信路及び有線通信路のうちの少なくとも一方であればよい。また、外部通信路８は、単一の機器と接続可能な通信路及び複数の機器と接続可能な通信路のうちの少なくとも一方であればよい。複数の機器と接続可能な通信路としては、例えば複数の機器がノードとして含まれる外部ネットワークに接続可能な通信路であればよい。外部通信路８は、全部が専用線で構成されていてもよいし、一部が公衆回線で構成されていてもよい。
【００１８】
［ＥＣＵの構成］
次に、ＥＣＵの内部構成について説明する。以下の説明では、図２に示すＥＣＵ２Ｂを例に挙げる。ただし、本実施形態において、ＥＣＵ２Ａ，２Ｃ，２Ｄは、ＥＣＵ２Ｂと同様に構成される。また、本実施形態において、ＥＣＵ３Ａ〜３Ｄは、第２ネットワーク１Ｂに接続されていない点で、ＥＣＵ２Ｂとは相違するが、その他の点はＥＣＵ２Ｂと同様に構成される。
【００１９】
ＥＣＵ２Ｂは、図２に示すように、ＣＰＵ１１、ＲＡＭ１２、フラッシュメモリ１３、第一通信部１６及び第二通信部１７等を有する。ＣＰＵは「Central Processing Unit」の略称である。ＲＡＭは「Random Access Memory」の略称である。第一通信部１６は、グローバルバス５Ａに接続するためのネットワークインターフェースである。第二通信部１７は、ローカルバス６に接続するためのネットワークインターフェースである。
【００２０】
ＥＣＵ２Ａ〜２Ｄの各種機能は、ＣＰＵ１１が非遷移的実体的記録媒体に格納されたプログラムに従って各種処理を実行することにより実現される。この例では、フラッシュメモリ１３が、非遷移的実体的記録媒体に該当する。ＣＰＵ１１がプログラムに従って各種処理を実行する際には、フラッシュメモリ１３に格納されたプログラムをＲＡＭ１２によって構成されるメインメモリにロードするように構成されていてもよい。この場合、ＣＰＵ１１は、メインメモリに格納されたプログラムに従って各種処理を実行する。
【００２１】
ＣＰＵ１１がプログラムに従って各種処理を実行することにより、プログラムに対応する方法が実行され、ＥＣＵ２Ａ〜２Ｄが備える各種機能が実現される。ただし、ＥＣＵ２Ａ〜２Ｄが備える各種機能を実現する手法はソフトウェアに限るものではなく、機能の一部又は全部を、ディジタル回路やアナログ回路等を組み合わせたハードウェアを用いて実現してもよい。
【００２２】
ＲＡＭ１２及びフラッシュメモリ１３には、各種記憶領域が確保される。本実施形態に関連する主要な記憶領域としては、ＲＡＭ１２には受信データバッファ１２Ａ及びマスタ判別カウンタ１２Ｂが確保される。フラッシュメモリ１３には、共通鍵記憶部１３Ａ及びＣＶＮ記憶部１３Ｂが確保される。
【００２３】
受信データバッファ１２Ａは、第１ネットワーク１Ａ経由で受信したデータを一時的に蓄積するためのバッファである。受信データバッファ１２Ａには受信したデータが順次格納され、格納領域が満杯になった場合には、最も古いデータが格納されている領域に新しいデータが上書きで格納される。受信データバッファ１２Ａのサイズは、第１ネットワーク１Ａ経由で受信するデータ量が最大となる状況を考慮して、少なくとも一定期間分（例えば２０ミリ秒分。）のデータについては確実に蓄積できる程度のサイズが確保される。マスタ判別カウンタ１２Ｂは、カウント値が順に増大するように構成されたカウンタである。
【００２４】
共通鍵記憶部１３Ａには、後述する処理の中で、受信データに対するメッセージ認証を実行する際に使用する共通鍵が記憶されている。ＣＶＮ記憶部１３Ｂには、後述する処理の中で、データの送信元が正当な依頼先装置か否かを確認する際に必要となるＣＶＮのリストが記憶されている。ＣＶＮは「Calibration Verification Numbers」の略称である。ＣＶＮは、ＥＣＵに実装されたソフトウェア等に基づいて生成される照合用コードである。
【００２５】
車両に搭載されるＥＣＵには、ＣＶＮの生成及び出力を行う機能を実装することが法令等によって義務づけられている。車両に搭載される複数のＥＣＵがＣＶＮを生成すると、ＥＣＵ毎に異なるＣＶＮが生成される。本実施形態においては、ＥＣＵ２Ａ〜２Ｄにおいて生成、出力されるＣＶＮが、車両生産時に収集、リスト化されて、ＣＶＮ記憶部１３Ｂに記憶されている。
【００２６】
ＥＣＵに実装されたソフトウェアが更新された場合、あるいはＥＣＵに実装されたソフトウェアが改ざんされた場合には、ＥＣＵにおいて生成されるＣＶＮが変化する。したがって、車両生産時にＣＶＮ記憶部１３Ｂに記憶されたＣＶＮと、ＥＣＵから出力されたＣＶＮとを比較して、その比較結果が一致しなければ、ＣＶＮを出力したＥＣＵの換装ないしはソフトウェアの改ざん等があったのではないかと疑うことができる。なお、ＥＣＵに実装されたソフトウェアが正当に更新される場合には、その更新後のＥＣＵから出力されるＣＶＮでＣＶＮ記憶部１３Ｂに記憶されているＣＶＮを更新すればよい。
【００２７】
［認証処理の概要］
第１ネットワーク１Ａのノードは、外部通信路８経由で到来するデータを受信することができる。そのため、例えば外部通信路８に接続された不正な外部機器から悪意のある不正なデータが伝送され得ることも想定して、そのような不正なデータに対して適切な対処をすることが重要となる。また、ＥＣＵ２Ａ〜２Ｄ及びＥＣＵ３Ａ〜３Ｄにおいてプログラムの改ざんが行われた場合、あるいは不正なＥＣＵへの換装が行われた場合にも、そのような不正なＥＣＵから伝送される不正なデータに対し、適切な対処をすることが重要である。
【００２８】
そこで、本実施形態のネットワークシステム１において、ＥＣＵ２Ａ〜２Ｄ及びＥＣＵ３Ａ〜３Ｄは、第１ネットワーク１Ａ経由でデータを受信した際に認証処理を実行し、データの正当性を確認する。本実施形態において、ＥＣＵ２Ａ〜２Ｄ及びＥＣＵ３Ａ〜３Ｄは、メッセージ認証によってデータの正当性を確認する。図３に示すように、第１ネットワーク１Ａにおいて伝送されるデータＤ１には、ＩＤ、通常データ、送信用フレッシュネス値及び暗号データ等が含まれる。
【００２９】
ＩＤは、データの種別又は内容、送信元又は送信先のノード及び通信時の優先度等、様々な情報を含み得る識別子である。送信元のノードからブロードキャスト通信によって第１ネットワーク１Ａへと送出されるデータＤ１は、第１ネットワーク１Ａにおける送信元ノード以外のノード全てにおいて受信される。データＤ１を受信したノードは、データＤ１中に含まれるＩＤに基づいて、処理対象とすべきデータ（以下、処理対象データとも称する。）か否かを判断することができる。
【００３０】
通常データは、送信元ノードが送信先ノードへ送信しようとしたデータの実体部分である。送信用フレッシュネス値は、送信元ノードがフレッシュネス値管理マスタ７から取得した最新のフレッシュネス値である。暗号データは、第１ネットワーク１Ａのノードが共通に使用する共通鍵を使って、所定の暗号化方式により通常データを暗号化したデータである。共通鍵は、上述の共通鍵記憶部１３Ａに記憶されている。データＤ１中に含まれる暗号データは、データＤ１を送信する送信元ノードにおいて、共通鍵を使って通常データを暗号化し、その暗号化済みのデータの一部を抽出したものである。暗号化済みのデータの一部を抽出するのはデータ量を削減するためである。データ量の削減が不要であれば、暗号化済みのデータの全部を暗号データとして利用してもよい。
【００３１】
以上のようなデータＤ１を受信したノードにおいて、メッセージ認証を実施する際には、データＤ１中に含まれる通常データを取り出し、取り出した通常データを送信元ノードと同様の手順で暗号化し、その暗号化済みのデータの一部を抽出する。このようにして受信側ノードで生成される暗号データは、送信元ノードと同じ共通鍵を使って生成されるので、通常は、データＤ１中に含まれる暗号データと一致する。
【００３２】
しかし、通常データが伝送途中で改ざんされた場合やデータ化けした場合には、受信側ノードで生成される暗号データとデータＤ１中に含まれる暗号データとが不一致となる。あるいは、共通鍵を知らない不正なノードがデータを送信した場合には、適正な暗号データを生成できないため、受信側ノードで生成される暗号データとデータＤ１中に含まれる暗号データとが不一致となる。したがって、受信側ノードでは、受信側ノードで生成される暗号データとデータＤ１中に含まれる暗号データが一致する場合には、認証が成立したと判断する。一方、受信側ノードで生成される暗号データとデータＤ１中に含まれる暗号データとが不一致となった場合には、認証に失敗したと判断する。
【００３３】
また、データＤ１を受信したノードにおいて、メッセージ認証を実施する際には、データＤ１中に含まれる送信用フレッシュネス値を取り出し、取り出した送信用フレッシュネス値と、データＤ１を受信したノードが保有するフレッシュ値とを比較する。送信元のノードと送信先のノードが並列に機能している場合、フレッシュネス値管理マスタ７からは同じフレッシュネス値が提供されるので、比較対象とされる２つのフレッシュネス値は一致する。
【００３４】
しかし、フレッシュネス値を知らない不正なノードがデータを送信した場合には、適正なフレッシュネス値を生成できないため、受信側ノードが保有するフレッシュネス値とデータＤ１中に含まれるフレッシュネス値が不一致となる。したがって、受信側ノードでは、受信側ノードで保有するフレッシュネス値とデータＤ１中に含まれるフレッシュネス値が一致する場合には、認証が成立したと判断する。一方、受信側ノードで保有するフレッシュネス値とデータＤ１中に含まれるフレッシュネス値が所定回数以上にわたって不一致となった場合には、認証に失敗したと判断する。
【００３５】
また、本実施形態のネットワークシステム１において、ＥＣＵ２Ａ〜２Ｄは、第２ネットワーク１Ｂ経由でデータを伝送することができる。ただし、第２ネットワーク１Ｂは、第１ネットワーク１Ａとは異なり、第２ネットワーク１Ｂの外部とは隔離されたネットワークとなっている。そのため、第１ネットワーク１Ａとは異なり、少なくとも第２ネットワーク１Ｂの外部から不正なデータが伝送されてくることはない。
【００３６】
そこで、ＥＣＵ２Ａ〜２Ｄは、第２ネットワーク１Ｂ経由でデータを受信した際には、第１ネットワーク１Ａの場合とは異なり、認証処理を実行しない。そのため、第２ネットワーク１Ｂにおいて伝送されるデータＤ２は、図３に示すように、ＩＤ及び通常データ等が含まれるものの、暗号データは含まれないデータとされている。
【００３７】
さらに、本実施形態のネットワークシステム１において、ＥＣＵ２Ａ〜２Ｄは、第２ネットワーク１Ｂ経由で、図３に示す検証用データＤ３を伝送することができる。詳しくは後述するが、検証用データＤ３は、ＥＣＵ２Ａ〜２Ｄのメッセージ認証機能が正常に機能する状態にあるか否かを検証するためのデータである。本実施形態の場合、検証用データＤ３には、図３に示すように、ＩＤ、送信用フレッシュネス値及び暗号データ等が含まれる。検証用データＤ３に含まれる暗号データは、検証用データＤ３に含まれる送信用フレッシュネス値を暗号化したデータである。
【００３８】
なお、検証用データＤ３は、データＤ１と同様に通常データを含んでいてもよい。この場合、検証用データＤ３に含まれる暗号データは、検証用データＤ３に含まれる通常データを暗号化したデータであればよい。ただし、通常データを省略して、送信用フレッシュネス値から暗号データを生成すれば、検証用データＤ３のデータ量を削減することができるので、ネットワークやノードにかかる負荷を軽減することができる。
【００３９】
ＥＣＵ２Ａ〜２Ｄは、後述する処理を実行することにより、ＥＣＵ２Ａ〜２Ｄそれぞれのメッセージ認証機能が正常に機能する状態にあるか否かを検証する。その検証の結果、メッセージ認証機能が正常に機能すると判断された場合、ＥＣＵ２Ａ〜２Ｄは、処理対象データを受信した際に通常処理を実行する。一方、検証の結果、メッセージ認証機能が正常に機能しないと判断された場合、ＥＣＵ２Ａ〜２Ｄは、処理対象データを受信した際に代替処理を実行する。
【００４０】
ＥＣＵ２Ａ〜２Ｄが通常処理を実行する場合、ＥＣＵ２Ａ〜２Ｄは、処理対象データを受信するとメッセージ認証を実行し、認証に成功すれば、処理対象データを利用する。具体例を挙げれば、例えば、処理対象データ中から通常データが取り出され、その通常データを変数として用いた演算処理、通常データに基づく制御、通常データに応じて判断が分かれる分岐処理等が実行される。
【００４１】
一方、ＥＣＵ２Ａ〜２Ｄが代替処理を実行する場合、ＥＣＵ２Ａ〜２Ｄは、処理対象データを受信すると、他のＥＣＵに認証の代行を依頼する。ここでは、ＥＣＵ２Ｂが代替処理を実行する場合を想定して説明を続ける。認証の代行を依頼する依頼元となるＥＣＵ２Ｂは、ＥＣＵ２Ａ，２Ｃ，２Ｄ（すなわち、ＥＣＵ２Ｂ以外のＥＣＵ。）の中から依頼先を選定する。ここでは、ＥＣＵ２ＢがＥＣＵ２Ｃを依頼先として選定した場合を想定して説明を続ける。依頼元のＥＣＵ２Ｂは、依頼先のＥＣＵ２Ｃへ第２ネットワーク１Ｂ経由で代行依頼データを送信することにより、認証処理の代行を依頼する。本実施形態の場合、代行依頼データであること及びどのＥＣＵが依頼先として選定されたのかは、代行依頼データ中のＩＤによって示される。
【００４２】
具体的には、代行依頼データであることを示すＩＤとしては、依頼先として選定され得るＥＣＵ２Ａ〜２Ｄそれぞれに対応付けられた複数のＩＤが用意されている。ＥＣＵ２Ｃへ認証処理の代行を依頼する際には、ＥＣＵ２Ｃに対応するＩＤを選択し、そのＩＤを含む代行依頼データをブロードキャスト通信により第２ネットワーク１Ｂへと送出する。
【００４３】
ＥＣＵ２Ｃでは、代行依頼データを受信した際、そのデータ中に含まれるＩＤに基づいてＥＣＵ２Ｃが依頼先に選定されたことを認識し、それを契機にして依頼先としての処理を実行する。なお、ＥＣＵ２Ａ，２Ｄにおいても、ＥＣＵ２Ｂから送信された代行依頼データを受信する。ただし、そのデータ中に含まれるＩＤに基づいてＥＣＵ２Ａ，２Ｄでの対処が必要なデータではないと判断できるので、その判断以降の処理は実行しない。
【００４４】
依頼先となるＥＣＵ２Ｃでは、処理対象データに対してメッセージ認証による認証処理を実行する。本実施形態において、ＥＣＵ２Ｃは、上述のような受信データバッファ１２Ａを有し、第１ネットワーク１Ａ経由で受信したデータを一定期間分だけ受信データバッファ１２Ａに蓄積している。そのため、ＥＣＵ２Ｃが代行依頼データを受信した際、ＥＣＵ２Ｃは、代行依頼データ中に含まれる情報に基づいて、処理対象データを受信データバッファ１２Ａの中から探し出し、処理対象データに対する認証処理を実行する。なお、上述のような受信データバッファ１２Ａを使う代わりに、ＥＣＵ２ＢからＥＣＵ２Ｃへ処理対象データが提供されてもよい。
【００４５】
依頼先のＥＣＵ２Ｃにおいて処理対象データに対する認証に成功した場合、ＥＣＵ２Ｃは、認証に成功した処理対象データの内容を含む認証済みデータを第２ネットワーク１Ｂ経由でＥＣＵ２Ｂに対して送信する。認証済みデータであることは、認証済みデータ中のＩＤによって示される。依頼元のＥＣＵ２Ｂでは、認証済みデータを受信したことにより、依頼先での認証に成功したことを認識することができる。そこで、ＥＣＵ２Ｂでは、認証済みデータを受信した場合、ＥＣＵ２Ｂは認証済みデータに含まれる処理対象データを利用して、所期の処理を実行することができる。
【００４６】
したがって、このように構成されたネットワークシステム１によれば、ＥＣＵ２Ｂにおいて処理対象データの認証に失敗した場合でも、ＥＣＵ２Ｃにおいて処理対象データの認証に成功すれば、ＥＣＵ２Ｂは認証済みデータに含まれる処理対象データを利用することができる。よって、例えば、ＥＣＵ２Ｂにおいて認証処理を実行するために必要となるハードウェア又はソフトウェアに故障等の問題が生じていたとしても、ＥＣＵ２Ｂは認証済みの処理対象データを利用することができる。
【００４７】
［ＥＣＵにおいて実行される処理の詳細］
次に、ＥＣＵ２Ａ〜２Ｄにおいて実行される処理について、図４〜図１５のフローチャートに基づいて説明する。
【００４８】
［ＥＣＵが実行するマスタＥＣＵ判別処理］
まず、ＥＣＵ２Ａ〜２Ｄが実行するマスタＥＣＵ判別処理について、図４のフローチャートを用いて説明する。Ｓ１０１において、ＥＣＵ２Ａ〜２Ｄは、マスタ判別カウンタ１２Ｂの値を参照し、自身がマスタＥＣＵかスレーブＥＣＵかを判別する。本実施形態の場合は、４つのＥＣＵ２Ａ〜２Ｄのうち、いずれか１つがマスタＥＣＵとなり、マスタＥＣＵ以外のＥＣＵがスレーブＥＣＵとなる。
【００４９】
そこで、Ｓ１０１では、例えば、マスタ判別カウンタ１２Ｂの値をＥＣＵの数（すなわち、本実施形態の場合は４。）で除算し、その剰余に基づいて、自身がマスタＥＣＵかスレーブＥＣＵかを判別する。具体的には、例えば、各ＥＣＵ２Ａ〜２Ｄは、上述の剰余が０である場合に、自身がマスタＥＣＵであると判別し、剰余が０以外であれば自身がスレーブＥＣＵであると判別する。Ｓ１０１を終えたら、図４のマスタＥＣＵ判別処理を終了する。
【００５０】
マスタ判別カウンタ１２Ｂの値は、後述する処理が繰り返し実行されることで、経時的にインクリメントされる。そのため、マスタ判別カウンタ１２Ｂの値がインクリメントされた後に、再び各ＥＣＵ２Ａ〜２ＤがマスタＥＣＵ判別処理を実行すれば、その時点でマスタＥＣＵが交代することになる。これにより、ある時点でマスタＥＣＵに問題が発生した場合でも、経時的にマスタＥＣＵを交代させることができ、システム内においてマスタＥＣＵが不在となる状態が継続するのを回避ないしは抑制することができる。
【００５１】
［マスタＥＣＵが実行するマスタ判別カウンタ１２Ｂ同期処理］
上述のマスタＥＣＵ判別処理により、マスタＥＣＵとスレーブＥＣＵが決まると、マスタＥＣＵ及びスレーブＥＣＵは、それぞれに対応する処理を実行する。以下の説明では、ＥＣＵ２ＡがマスタＥＣＵとなった場合を想定して説明を続ける。まず、マスタＥＣＵが実行するマスタ判別カウンタ１２Ｂ同期処理について、図５のフローチャートを用いて説明する。
【００５２】
マスタ判別カウンタ１２Ｂ同期処理を開始すると、Ｓ２０１において、マスタＥＣＵ２Ａは、マスタ判別カウンタ１２Ｂの値をスレーブＥＣＵ２Ｂ〜２Ｄに送信する。続いて、Ｓ２０３において、マスタＥＣＵ２Ａは、所定の時間（例えば、数ｍｍ秒。）、スレーブＥＣＵ２Ｂ〜２Ｄからマスタ判別カウンタ１２Ｂ完了通知が応答されるまで待機する。続いて、Ｓ２０５において、マスタＥＣＵ２Ａは、応答のないスレーブＥＣＵ２Ｂ〜２Ｄがあるか否かを判断する。
【００５３】
マスタＥＣＵ２Ａは、Ｓ２０５において応答のないスレーブＥＣＵ２Ｂ〜２Ｄがあると判断した場合には、Ｓ２０７へ進み、応答のないスレーブＥＣＵ２Ｂ〜２Ｄの切り離し処置を実施する。Ｓ２０７で実行される切り離し処置の具体的手法は任意である。例えば、マスタＥＣＵ２Ａがシステム内の全ＥＣＵのリストを記憶するとともに、各ＥＣＵに対応付けてＥＣＵが有効か無効かを示すフラグを記憶していれば、そのフラグを無効にすることで、以降は、マスタＥＣＵ２Ａが無効となったＥＣＵを無視すればよい。あるいは、応答のないスレーブＥＣＵ２Ｂ〜２Ｄを対象に電力供給を停止する制御を実行してもよい。
【００５４】
一方、マスタＥＣＵ２Ａは、Ｓ２０５において応答のないスレーブＥＣＵ２Ｂ〜２Ｄがないと判断した場合には、Ｓ２０９へ進む。また、Ｓ２０７を終えた場合にも、Ｓ２０９へ進む。Ｓ２０９へ進んだ場合、マスタＥＣＵ２Ａは、マスタ判別カウンタ１２Ｂの値を更新する。Ｓ２０９を終えたら、図５のマスタ判別カウンタ１２Ｂ同期処理を終了する。
【００５５】
［スレーブＥＣＵが実行するマスタ判別カウンタ１２Ｂ同期処理］
次に、スレーブＥＣＵ２Ｂ〜２Ｄが実行するマスタ判別カウンタ１２Ｂ同期処理について、図６のフローチャートを用いて説明する。まず、Ｓ３０１において、スレーブＥＣＵ２Ｂ〜２Ｄは、所定の時間（例えば、数ｍｍ秒。）、マスタＥＣＵ２Ａからマスタ判別カウンタ１２Ｂの値が受信できるまで待機する。続いて、Ｓ３０３において、スレーブＥＣＵ２Ｂ〜２Ｄは、マスタＥＣＵ２Ａからマスタ判別カウンタ１２Ｂの値が受信できたか否かを判断する。スレーブＥＣＵ２Ｂ〜２Ｄは、Ｓ３０３においてマスタＥＣＵ２Ａからマスタ判別カウンタ１２Ｂの値が受信できたと判断した場合には、Ｓ３０５へ進み、マスタ判別カウンタ１２Ｂの値を更新する。Ｓ３０５を実行することにより、マスタＥＣＵ２ＡとスレーブＥＣＵ２Ｂ〜２Ｄとの間でマスタ判別カウンタ１２Ｂの値を一致させることができる。Ｓ３０５を終えたら、図６のマスタ判別カウンタ１２Ｂ同期処理を終了する。
【００５６】
一方、スレーブＥＣＵ２Ｂ〜２Ｄは、Ｓ３０３においてマスタＥＣＵ２Ａからマスタ判別カウンタ１２Ｂの値が受信できないと判断した場合には、Ｓ３０７へ進み、マスタＥＣＵ２Ａの切り離し処置を実施する。Ｓ３０７では、Ｓ２０７と同様な処置が実行される。続いて、Ｓ３０９において、スレーブＥＣＵ２Ｂ〜２Ｄは、マスタ判別カウンタ１２Ｂをインクリメントする。Ｓ３０９では、マスタＥＣＵ２Ａとの同期を断念し、マスタ判別カウンタ１２Ｂの値を自ら更新することになる。Ｓ３０９を終えたら、図６のマスタ判別カウンタ１２Ｂ同期処理を終了する。
【００５７】
なお、Ｓ３０７を実行した場合、その時点でマスタＥＣＵ２Ａはシステムから切り離されることになるが、その後、再び図４のマスタＥＣＵ判別処理が実行されれば、その時点でＥＣＵ２Ｂ〜２ＤのいずれかがマスタＥＣＵとなる。したがって、マスタＥＣＵ２Ａをシステムから切り離しても、システムが機能不全に陥ることはない。
【００５８】
［マスタＥＣＵ２Ａが実行するフレッシュネス値の異常検証処理］
次に、マスタＥＣＵ２Ａが実行するフレッシュネス値の異常検証処理について、図７のフローチャートを用いて説明する。まず、Ｓ４０１において、マスタＥＣＵ２Ａは、検証用データを各スレーブＥＣＵ２Ｂ〜２Ｄに送信する。続いて、Ｓ４０３において、マスタＥＣＵ２Ａは、スレーブＥＣＵ２Ｂ〜２Ｄからフレッシュネス値検証結果を受信する。続いて、Ｓ４０５において、マスタＥＣＵ２Ａは、全てのスレーブＥＣＵ２Ｂ〜２Ｄからフレッシュネス値ＯＫ通知を受信したか否かを判断する。
【００５９】
マスタＥＣＵ２Ａは、Ｓ４０５において全てのスレーブＥＣＵ２Ｂ〜２Ｄからフレッシュネス値ＯＫ通知を受信したと判断した場合には、図７のフレッシュネス値の異常検証処理を終了する。一方、マスタＥＣＵ２Ａは、Ｓ４０５においてスレーブＥＣＵ２Ｂ〜２Ｄのうちの少なくとも１つからフレッシュネス値ＯＫ通知を受信しなかったと判断した場合には、Ｓ４０７へ進み、フレッシュネス値ＮＧ通知を返したＥＣＵが過半数か否かを判断する。
【００６０】
マスタＥＣＵ２Ａは、Ｓ４０７においてフレッシュネス値ＮＧ通知を返したＥＣＵが過半数であると判断した場合には、Ｓ４０９へ進み、マスタＥＣＵ２Ａのフレッシュネス値異常を確定する。続いて、Ｓ４１１において、マスタＥＣＵ２Ａは、通常処理から代替処理へ移行する。通常処理と代替処理の詳細については後述する。Ｓ４１１を終えたら、図７のフレッシュネス値の異常検証処理を終了する。
【００６１】
一方、マスタＥＣＵ２Ａは、Ｓ４０７においてフレッシュネス値ＮＧ通知を返したＥＣＵが過半数ではないと判断した場合には、Ｓ４１３へ進み、スレーブＥＣＵ２Ｂ〜２Ｄのフレッシュネス値異常を確定する。続いて、Ｓ４１５において、マスタＥＣＵ２Ａは、スレーブＥＣＵ２Ｂ〜２Ｄに代替処理移行要求を送信する。代替処理移行要求を受けたスレーブＥＣＵ２Ｂ〜２Ｄは、通常処理から代替処理へ移行する。通常処理と代替処理の詳細については後述する。Ｓ４１５を終えたら、図７のフレッシュネス値の異常検証処理を終了する。
【００６２】
つまり、Ｓ４０７では、マスタＥＣＵ２Ａに問題があるか否かについて、スレーブＥＣＵ２Ｂ〜２Ｄによる多数決を実施する。スレーブＥＣＵ２Ｂ〜２Ｄのうち、過半数がフレッシュネス値ＮＧ通知を返す場合には、マスタＥＣＵ２Ａに問題があると判断する。逆に、フレッシュネス値ＮＧ通知を返すスレーブＥＣＵが半数に満たない場合は、フレッシュネス値ＮＧ通知を返すスレーブＥＣＵに問題があると判断する。
【００６３】
［マスタＥＣＵ２Ａが実行するメッセージ認証機能の異常判断処理］
次に、マスタＥＣＵ２Ａが実行するメッセージ認証機能の異常判断処理について、図８のフローチャートを用いて説明する。まず、Ｓ５０１において、マスタＥＣＵ２Ａは、メッセージ認証機能の検証結果を受信する。続いて、Ｓ５０３において、マスタＥＣＵ２Ａは、全てのスレーブＥＣＵ２Ｂ〜２Ｄから検証ＯＫ通知を受信したか否かを判断する。マスタＥＣＵ２Ａは、Ｓ５０３において全てのスレーブＥＣＵ２Ｂ〜２Ｄから検証ＯＫ通知を受信したと判断した場合には、Ｓ５０５へ進み、マスタＥＣＵ２Ａ、スレーブＥＣＵ２Ｂ〜２Ｄに異常なしと確定する。Ｓ５０５を終えたら、図８のメッセージ認証機能の異常判断処理を終了する。
【００６４】
一方、マスタＥＣＵ２Ａは、Ｓ５０３においてスレーブＥＣＵ２Ｂ〜２Ｄのうちの少なくとも１つから検証ＯＫ通知を受信できなかったと判断した場合には、Ｓ５０７へ進み、検証ＮＧ通知を返したＥＣＵが過半数か否かを判断する。マスタＥＣＵ２Ａは、Ｓ５０７において検証ＮＧ通知を返したＥＣＵが過半数であると判断した場合には、Ｓ５０９へ進み、マスタＥＣＵ２Ａの鍵故障や復号・暗号機能異常などを確定する。続いて、Ｓ５１１において、マスタＥＣＵ２Ａは、通常処理から代替処理へ移行する。通常処理と代替処理の詳細については後述する。Ｓ５１１を終えたら、図８のメッセージ認証機能の異常判断処理を終了する。
【００６５】
一方、マスタＥＣＵ２Ａは、Ｓ５０７において検証ＮＧ通知を返したＥＣＵが過半数ではないと判断した場合には、Ｓ５１３へ進み、スレーブＥＣＵ２Ｂ〜２Ｄの鍵故障や復号・暗号機能異常などを確定する。続いて、Ｓ５１５において、マスタＥＣＵ２Ａは、スレーブＥＣＵ２Ｂ〜２Ｄに代替処理移行要求を送信する。代替処理移行要求を受けたスレーブＥＣＵ２Ｂ〜２Ｄは、通常処理から代替処理へ移行する。通常処理と代替処理の詳細については後述する。Ｓ５１５を終えたら、図８のメッセージ認証機能の異常判断処理を終了する。
【００６６】
つまり、Ｓ５０７でも、Ｓ４０７と同様に、マスタＥＣＵ２Ａに問題があるか否かについて、スレーブＥＣＵ２Ｂ〜２Ｄによる多数決を実施する。スレーブＥＣＵ２Ｂ〜２Ｄのうち、過半数が検証ＮＧ通知を返す場合には、マスタＥＣＵ２Ａに問題があると判断する。逆に、検証ＮＧ通知を返すスレーブＥＣＵが半数に満たない場合は、検証ＮＧ通知を返すスレーブＥＣＵに問題があると判断する。
【００６７】
［フレッシュネス値及びメッセージ認証機能の異常判断処理］
次に、スレーブＥＣＵ２Ｂ〜２Ｄが実行するフレッシュネス値及びメッセージ認証機能の異常判断処理について、図９のフローチャートを用いて説明する。まず、Ｓ６０１において、スレーブＥＣＵ２Ｂ〜２Ｄは、検証用データを受信する。続いて、Ｓ６０３において、スレーブＥＣＵ２Ｂ〜２Ｄは、受信した検証用データに含まれるフレッシュネス値を検証する。Ｓ６０３において、スレーブＥＣＵ２Ｂ〜２Ｄは、受信したフレッシュネス値とスレーブＥＣＵ２Ｂ〜２Ｄが内部で保有するフレッシュネス値とを比較し、両者が一致すれば検証ＯＫ、一致しなければ検証ＮＧと判断する。
【００６８】
スレーブＥＣＵ２Ｂ〜２Ｄは、Ｓ６０３において検証ＯＫと判断した場合には、Ｓ６０５へ進み、マスタＥＣＵ２Ａにフレッシュネス値検証ＯＫ通知を送信する。続いて、Ｓ６０７において、スレーブＥＣＵ２Ｂ〜２Ｄは、検証用データとスレーブＥＣＵ２Ｂ〜２Ｄが保有する共通鍵の鍵値からＭＡＣを生成する。ＭＡＣは「Message Authentication Code」の略称である。続いて、Ｓ６０９において、スレーブＥＣＵ２Ｂ〜２Ｄは、検証用ＭＡＣと内部生成したＭＡＣとを比較する。
【００６９】
検証用ＭＡＣは、検証用データに含まれる暗号データである。この暗号データは、マスタＥＣＵ２Ａがフレッシュネス値と共通鍵の鍵値とを用いて生成したデータである。したがって、スレーブＥＣＵ２Ｂ〜２Ｄがフレッシュネス値と共通鍵の鍵値とを用いてＭＡＣを内部生成すれば、通常であれば検証用ＭＡＣと同一のＭＡＣを生成できるはずである。
【００７０】
そこで、スレーブＥＣＵ２Ｂ〜２Ｄは、Ｓ６０９において検証用ＭＡＣと内部生成したＭＡＣとを比較し、両者が一致する場合には検証ＯＫと判断し、その場合はＳ６１１へ進み、マスタＥＣＵ２Ａに検証ＯＫ通知を送信する。Ｓ６１１を終えたら、図９のフレッシュネス値及びメッセージ認証機能の異常判断処理を終了する。
【００７１】
一方、スレーブＥＣＵ２Ｂ〜２Ｄは、Ｓ６０９において検証用ＭＡＣと内部生成したＭＡＣとが一致しない場合には検証ＮＧと判断し、その場合はＳ６１３へ進み、マスタＥＣＵ２Ａに検証ＮＧ通知を送信する。Ｓ６１３を終えたら、図９のフレッシュネス値及びメッセージ認証機能の異常判断処理を終了する。
【００７２】
一方、スレーブＥＣＵ２Ｂ〜２Ｄは、Ｓ６０３において検証ＮＧと判断した場合には、Ｓ６１５へ進み、再検証回数が上限を超えているか否かを判断する。スレーブＥＣＵ２Ｂ〜２Ｄは、Ｓ６１５において再検証回数が上限を超えていないと判断した場合には、Ｓ６１７へ進み、内部で保有する１回前のフレッシュネス値を用いて、検証用フレッシュネス値を再構築し、Ｓ６０３に戻る。これにより、Ｓ６０３以降の処理では、再構築された検証用フレッシュネス値で改めて検証が実行される。
【００７３】
Ｓ６１５及びＳ６１７を設けてある理由は、例えば、マスタＥＣＵ２Ａが検証用データを送信した直後に、スレーブＥＣＵ２Ｂ〜２Ｄにおいてフレッシュネス値が更新されたような場合に、検証用データに含まれるフレッシュネス値とスレーブＥＣＵ２Ｂ〜２Ｄが保持するフレッシュネス値に差異が生じる場合があるからである。ただし、このような現象は頻発する現象ではないので、再検証回数の上限は例えば３〜４回程度に設定し、それ以上の検証ＮＧが発生した場合には、フレッシュネス値異常と判断すればよい。
【００７４】
一方、スレーブＥＣＵ２Ｂ〜２Ｄは、Ｓ６１５において再検証回数が上限を超えていると判断した場合には、Ｓ６１９へ進み、マスタＥＣＵ２Ａにフレッシュネス値異常通知を送信する。Ｓ６１９を終えたら、図９のフレッシュネス値及びメッセージ認証機能の異常判断処理を終了する。
【００７５】
以上のようなフレッシュネス値及びメッセージ認証機能の異常判断処理において、Ｓ６０５で送信されるフレッシュネス値検証ＯＫ通知又はＳ６１９で送信されるフレッシュネス値異常通知は、マスタＥＣＵ２Ａが図７のＳ４０３を実行する際にマスタＥＣＵ２Ａによって受信される。また、Ｓ６１１で送信される検証ＯＫ通知又はＳ６１３で送信される検証ＮＧ通知は、マスタＥＣＵ２Ａが図８のＳ５０１を実行する際にマスタＥＣＵ２Ａによって受信される。これにより、各スレーブＥＣＵ２Ｂ〜２Ｄでのフレッシュネス値の検証結果及びＭＡＣに基づくメッセージ認証機能の検証結果は、全てマスタＥＣＵ２Ａで掌握されて管理されることになる。
【００７６】
［スレーブＥＣＵが実行する代替処理移行処理］
次に、スレーブＥＣＵ２Ｂ〜２Ｄが実行する代替処理移行処理について、図１０のフローチャートを用いて説明する。まず、Ｓ７０１において、スレーブＥＣＵ２Ｂ〜２Ｄは、代替処理移行要求を受信する。Ｓ７０１では、マスタＥＣＵ２Ａが図７のＳ４１５を実行した場合又はマスタＥＣＵ２Ａが図８のＳ５１５を実行した場合に、代替処理移行要求を受信する。続いて、Ｓ７０３において、スレーブＥＣＵ２Ｂ〜２Ｄは、マスタＥＣＵ２Ａから代替処理以降要求があるか否かを判断する。
【００７７】
スレーブＥＣＵ２Ｂ〜２Ｄは、Ｓ７０３においてマスタＥＣＵ２Ａから代替処理移行要求があると判断した場合には、Ｓ７０５へ進み、通常処理から代替処理へ移行する。Ｓ７０５を終えたら、図１０の代替処理移行処理を終了する。一方、スレーブＥＣＵ２Ｂ〜２Ｄは、Ｓ７０３においてマスタＥＣＵ２Ａから代替処理移行要求がないと判断した場合には、Ｓ７０５を実行することなく、図１０の代替処理移行処理を終了する。この場合、スレーブＥＣＵ２Ｂ〜２Ｄは、通常処理から代替処理へ移行しないので、通常処理のままとなる。
【００７８】
［ＥＣＵが実行する通常処理］
次に、ＥＣＵが実行する通常処理について、図１１のフローチャートを用いて説明する。まず、Ｓ８０１において、ＥＣＵ２Ａ〜２Ｄは、グローバルバス５Ａから処理対象データを受信する。処理対象データは、例えば、ＥＣＵ３Ｄがブロードキャスト通信によって第１ネットワーク１Ａへと送信したデータである。なお、この処理対象データは第１ネットワーク１ＡにおいてＥＣＵ３Ｄ以外のノード全てに届く。処理対象データを受信したノードは、処理対象データ中に含まれるＩＤに基づいて、処理対象とすべきデータか否か等を判断する。また、本実施形態の場合、少なくともＥＣＵ２Ａ〜２Ｄにおいては、処理対象データを受信したら、処理対象データを受信データバッファ１２Ａに格納する。
【００７９】
続いて、Ｓ８０３において、ＥＣＵ２Ａ〜２Ｄは、メッセージ認証処理を実行する。このメッセージ認証処理の詳細を図１２に示す。メッセージ認証処理を開始すると、Ｓ９０１において、ＥＣＵ２Ａ〜２Ｄは、処理対象データに含まれる通常データと暗号データを取り出す。ここでいう処理対象データは、Ｓ８０１において受信した処理対象データである。
【００８０】
続いて、Ｓ９０３において、ＥＣＵ２Ａ〜２Ｄは、通常データを共通鍵で暗号化し、暗号データを生成する。ここで暗号化されるデータは、Ｓ９０１において処理対象データから取り出された通常データである。続いて、Ｓ９０５において、ＥＣＵ２Ａ〜２Ｄは、受信した暗号データと生成したデータが一致するか否かを判断する。受信した暗号データと生成したデータが一致する場合は、Ｓ９０７へ進む。
【００８１】
Ｓ９０７へ進んだ場合は、ＥＣＵ２Ａ〜２Ｄにおいて認証が成立したことになり、図１２に示す処理を終了して、図１１のＳ８０５へ進む。一方、受信した暗号データと生成したデータが一致しない場合は、Ｓ９０９へ進む。Ｓ９０９へ進んだ場合は、ＥＣＵ２Ａ〜２Ｄにおいて認証に失敗したことになり、図１２に示す処理を終了して、図１１のＳ８０５へ進む。
【００８２】
Ｓ８０５において、ＥＣＵ２Ａ〜２Ｄは、認証が成立したか否かを判断する。上述のＳ９０７において認証が成立している場合は、Ｓ８０７へ進む。Ｓ８０７において、ＥＣＵ２Ａ〜２Ｄは、処理対象データに含まれる通常データを取り出して、以降の処理で利用する。ここでいう「以降の処理」としては、ＥＣＵ２Ａ〜２Ｄの機能に応じた様々な処理を考え得るが、当該処理そのものは本実施形態における要部ではないので、これ以上の説明は省略する。Ｓ８０７を終えたら、図１１に示す処理を終了する。
【００８３】
一方、上述のＳ９０９において認証に失敗している場合には、Ｓ８０９へ進む。Ｓ８０９において、ＥＣＵ２Ａ〜２Ｄは、受信した処理対象データを破棄して、フェイルセーフデータを以降の処理で利用する。フェイルセーフデータは、ＥＣＵ２Ａ〜２Ｄが受信する処理対象データに問題があって使用できない場合に、代替使用されるデータである。
【００８４】
このようなフェイルセーフデータは、例えばフラッシュメモリ１３にあらかじめ記憶されていればよい。あるいは、処理対象データを過去に一定期間以上の長期にわたって受信できていた場合は、その平均値、最大値、あるいは最小値等を経時的に算出し、いつでもフェイルセーフデータとして利用できるように準備しておいてもよい。どのようなかたちでフェイルセーフデータを用意するかは、ＥＣＵ２Ａ〜２Ｄによる制御対象の挙動なども考慮して最適化されていればよい。Ｓ８０９を終えたら、図１１に示す処理を終了する。
【００８５】
［依頼元ＥＣＵがグローバルバス経由でのデータ受信時に実行する代替処理］
次に、認証代行の依頼元ＥＣＵがグローバルバス経由でのデータ受信時に実行する代替処理について、図１３のフローチャートを用いて説明する。なお、以下の説明では、ＥＣＵ２Ｂが代替処理へ移行したＥＣＵであり、ＥＣＵ２Ｃが認証代行の依頼先となる場合を想定して説明を続ける。ただし、ＥＣＵ２Ａ〜２Ｄは、それぞれが代替処理へ移行し得るＥＣＵであり、また、それぞれが認証代行の依頼先となり得るＥＣＵである。
【００８６】
まず、Ｓ１００１において、ＥＣＵ２Ｂは、グローバルバス５Ａから処理対象データを受信する。この処理は、図１０の通常処理におけるＳ８０１と同等な処理である。続いて、Ｓ１００３において、ＥＣＵ２Ｂは、処理対象データに含まれるＩＤを取り出して他の部分は破棄する。続いて、Ｓ１００５において、ＥＣＵ２Ｂは、取り出したＩＤを含む代行依頼データを作成し、その代行依頼データに認証代行依頼を示すＩＤを設定し、代行依頼データをローカルバス６へ送信する。Ｓ１００５を終えたら、図１３に示す処理を終了する。
【００８７】
［認証代行の依頼先ＥＣＵが実行する処理］
次に、認証代行の依頼先ＥＣＵが実行する処理について、図１４のフローチャートを用いて説明する。まず、Ｓ１１０１において、ＥＣＵ２Ｃは、ローカルバス６からデータを受信する。続いて、Ｓ１１０３において、ＥＣＵ２Ｃは、上記Ｓ１１０１において受信したデータがＥＣＵ２Ｃ宛の代行依頼データか否かを判断する。ここで、代行依頼データであること及びＥＣＵ２Ｃ宛であることは、受信データ中に含まれるＩＤに基づいて判断することができる。
【００８８】
ＥＣＵ２Ｂにおいて上述のＳ１００５が実行された場合、代行依頼データはブロードキャスト通信によって第２ネットワーク１Ｂへと送信される。そのため、代行依頼データは第２ネットワーク１ＢにおいてＥＣＵ２Ｂ以外のノード全てに届く。ＥＣＵ２ＣにおいてＥＣＵ２Ｃ宛の代行依頼データを受信した場合、Ｓ１１０５へ進む。その場合、Ｓ１１０５において、ＥＣＵ２Ｃは、処理対象データを受信データバッファ１２Ａから取得する。上述の通り、ＥＣＵ２ＢがＳ１００５において代行依頼データを作成する際には、処理対象データから取り出されたＩＤを含む代行依頼データが作成される。そこで、Ｓ１１０５においては、ＥＣＵ２Ｃは、代行依頼データ中に含まれている「処理対象データから取り出されたＩＤ」と一致するＩＤを持つデータを、受信データバッファ１２Ａから探し出し、そのデータを処理対象データとして取得する。
【００８９】
続いて、Ｓ１１０７において、ＥＣＵ２Ｃは、受信データバッファ１２Ａから探し出された処理対象データに対し、メッセージ認証処理を実行する。このメッセージ認証処理は、図１２に示した処理となる。ただし、図１２に示した処理については既に詳細を説明したので、重ねての説明は省略する。なお、Ｓ１１０７においてメッセージ認証処理を実行する場合、図１２のＳ９０１における「処理対象データ」は、Ｓ１１０５において受信データバッファ１２Ａから探し出された処理対象データである。
【００９０】
続いて、Ｓ１１０９において、ＥＣＵ２Ｃは、認証が成立したか否かを判断する。Ｓ１１０７において認証が成立している場合は、Ｓ１１１１へ進む。Ｓ１１１１において、ＥＣＵ２Ｂは、処理対象データに含まれる通常データを取り出して、その通常データを含む認証済みデータを作成し、認証済みデータにＣＶＮを付加して、ローカルバス６へ送信する。認証済みデータであることは、認証済みデータ中に含まれるＩＤによって示すことができる。認証済みデータに付加されるＣＶＮは、ＥＣＵ２Ｃにおいて生成されるＣＶＮである。Ｓ１１１１を終えたら、図１４に示す処理を終了する。一方、Ｓ１１０７において認証に失敗している場合には、Ｓ１１１３へ進む。Ｓ１１１３において、ＥＣＵ２Ｂは、認証失敗を示す失敗通知データをローカルバス６へ送信する。失敗通知データであることは、失敗通知データ中に含まれるＩＤによって示すことができる。Ｓ１１１３を終えたら、図１４に示す処理を終了する。
【００９１】
上述のＳ１１０３において代行依頼データではなかった場合は、Ｓ１１１５へ進み、ＥＣＵ２Ｃは、通常のローカルバスからのデータ受信に対応する処理を実行する。Ｓ１１１５において実行される処理としては、ＥＣＵ２Ｃの機能に応じた様々な処理を考え得るが、当該処理そのものは本実施形態における要部ではないので、これ以上の説明は省略する。Ｓ１１１５を終えたら、図１４に示す処理を終了する。
【００９２】
［依頼元ＥＣＵがローカルバス経由でのデータ受信時に実行する代替処理］
次に、認証代行の依頼元ＥＣＵがローカルバス経由でのデータ受信時に実行する代替処理について、図１５のフローチャートを用いて説明する。ＥＣＵ２Ｃにおいて図１４に示す処理が実行されている際、ＥＣＵ２Ｂでは図１５に示す処理が実行される。まず、Ｓ１２０１において、ＥＣＵ２Ｂは、ローカルバス６からデータを受信する。続いて、Ｓ１２０３において、ＥＣＵ２Ｃは、上記Ｓ１２０１において受信したデータが認証済みデータか否かを判断する。ここで、認証済みデータであることは、受信データ中に含まれるＩＤに基づいて判断することができる。
【００９３】
なお、ＥＣＵ２Ｃにおいて上述のＳ１１１１が実行された場合、認証済みデータはブロードキャスト通信によって第２ネットワーク１Ｂへと送信される。そのため、認証済みデータは第２ネットワーク１ＢにおいてＥＣＵ２Ｃ以外のノード全てに届く。
【００９４】
上述のＳ１２０３において認証済みデータであった場合は、Ｓ１２０５へ進み、ＥＣＵ２Ｃは、認証済みデータに付加されたＣＶＮを取り出す。そして、Ｓ１２０７において、ＣＶＮが適正か否かを判断する。Ｓ１２０７においては、受信した認証済みデータから取り出されたＣＶＮと、ＣＶＮ記憶部１３Ｂに記憶されたＣＶＮとを比較する。ＣＶＮ記憶部１３Ｂには、ＥＣＵ２Ａ〜２Ｄにおいて生成、出力されたＣＶＮが記憶されているので、Ｓ１２０７においては、ＥＣＵ２Ｃに対応するＣＶＮが比較対象として選択される。
【００９５】
この比較の結果、両者が一致すれば、ＣＶＮは適正であり、Ｓ１２０９へ進む。Ｓ１２０９へ進んだ場合、ＥＣＵ２Ｂは、認証済みデータに含まれる通常データを取り出して、以降の処理で利用する。ここでいう「以降の処理」としては、ＥＣＵ２Ｂの機能に応じた様々な処理を考え得るが、当該処理そのものは本実施形態における要部ではないので、これ以上の説明は省略する。Ｓ１２０９を終えたら、図１５に示す処理を終了する。
【００９６】
一方、上述のＳ１２０７において、比較結果が一致しなければ、受信した認証済みデータから取り出されたＣＶＮが不適正である可能性が高い。この場合、ＥＣＵ２Ｃ以外のノードがＥＣＵ２Ｃになりすまして認証済みデータを送信している可能性がある。あるいは、ＥＣＵ２Ｃのソフトウェアが改ざんされている可能性や、ＥＣＵ２Ｃが換装されている可能性もある。よって、このような状況下では、認証済みデータを受信したとしても、認証済みデータそのものの信頼性が低い。
【００９７】
そこで、上述のＳ１２０７における比較結果が一致しなければ、Ｓ１２１１へ進む。Ｓ１２１１において、ＥＣＵ２Ｂは、受信した認証済みデータを破棄して、フェイルセーフデータを以降の処理で利用する。フェイルセーフデータは、ＥＣＵ２Ｂが受信する処理対象データや認証済みデータに問題があって使用できない場合に、代替使用されるデータである。
【００９８】
このようなフェイルセーフデータは、例えばフラッシュメモリ１３にあらかじめ記憶されていればよい。あるいは、処理対象データを過去に一定期間以上の長期にわたって受信できていた場合は、その平均値、最大値、あるいは最小値等を経時的に算出し、いつでもフェイルセーフデータとして利用できるように準備しておいてもよい。どのようなかたちでフェイルセーフデータを用意するかは、ＥＣＵ２Ｂによる制御対象の挙動なども考慮して最適化されていればよい。Ｓ１２１１を終えたら、図１５に示す処理を終了する。
【００９９】
また、上述のＳ１２０３において、上記Ｓ１２０１において受信したデータが認証済みデータではなかった場合は、Ｓ１２１３へ進み、ＥＣＵ２Ｃは、上記Ｓ１２０１において受信したデータが失敗通知データか否かを判断する。ここで、失敗通知データであることは、受信データ中に含まれるＩＤに基づいて判断することができる。失敗通知データであった場合は、Ｓ１２１１へ進む。Ｓ１２１１については既に説明したので、重ねての説明は省略する。Ｓ１２１１を終えたら、図１５に示す処理を終了する。
【０１００】
上述のＳ１２１３において失敗通知データではなかった場合は、Ｓ１２１５へ進み、ＥＣＵ２Ｂは、通常のローカルバスからのデータ受信に対応する処理を実行する。Ｓ１２１５において実行される処理としては、ＥＣＵ２Ｂの機能に応じた様々な処理を考え得るが、当該処理そのものは本実施形態における要部ではないので、これ以上の説明は省略する。Ｓ１２１５を終えたら、図１５に示す処理を終了する。
【０１０１】
［システム内の通信シーケンスの例］
次に、ネットワークシステム１における通信シーケンスの一例を図１６及び図１７に基づいて説明する。マスタＥＣＵ２ＡとスレーブＥＣＵ２Ｂ〜２Ｄは、図１６に示すように、グローバルバス５Ａ，５Ｂ経由で通信を行う。その際、送信側のＥＣＵ（例えば、マスタＥＣＵ２Ａ。）は、処理対象データとして通常データ、フレッシュネス値及び暗号データを送信する。処理対象データを受信した受信側ＥＣＵ（例えば、スレーブＥＣＵ２Ｂ〜２Ｄ。）では、送信側ＥＣＵに対して応答データを返信する。本実施形態の場合、このようなグローバルバス５Ａ，５Ｂ経由での通信が、例えば３０ミリ秒に１回程度の頻度で実行される。
【０１０２】
一方、上述のようなグローバルバス５Ａ，５Ｂ経由での通信が実行されるのと並行して、マスタＥＣＵ２ＡとスレーブＥＣＵ２Ｂ〜２Ｄは、ローカルバス６経由でも通信を行い、検証処理シーケンスを実施する。検証処理シーケンスは、グローバルバス５Ａ，５Ｂ経由での通信と同等以上の頻度（例えば１６ミリ秒に１回程度の頻度。）で実行されている。これにより、グローバルバス５Ａ，５Ｂ経由での通信が実行される前に、少なくとも１回の検証処理シーケンスが実行される可能性を高めることができる。よって、メッセージ認証機能に障害が発生した場合には、そのような障害の発生を、グローバルバス５Ａ，５Ｂ経由での通信が実行される前にリアルタイムで検出することができる。
【０１０３】
検証処理シーケンスの一例を図１７に示す。ＥＣＵ２Ａ〜２Ｄは、図１７に示すように、それぞれにおいてマスタ判別カウンタ１２Ｂを確認し、自身がマスタＥＣＵかスレーブＥＣＵかの判別を行う。これにより、例えば、ＥＣＵ２Ａは自身がマスタＥＣＵであると自覚し、ＥＣＵ２Ｂ〜２Ｄは自身がスレーブＥＣＵであると自覚する。マスタＥＣＵ２Ａは、スレーブＥＣＵ２Ｂ〜２Ｄとの間でマスタ判別カウンタ１２Ｂを同期させるため、スレーブＥＣＵ２Ｂ〜２Ｄに対してマスタ判別カウンタ１２Ｂの値を送信する。スレーブＥＣＵ２Ｂ〜２Ｄは、マスタＥＣＵ２Ａからマスタ判別カウンタ１２Ｂの値を受信したら、マスタＥＣＵ２Ａに対してマスタ判別カウンタ１２Ｂの受信完了通知を送信する。
【０１０４】
マスタ判別カウンタ１２Ｂを同期させる際には、マスタＥＣＵ２Ａ及びスレーブＥＣＵ２Ｂ〜２Ｄそれぞれにおいて、タイムアウト判定を実施する。具体的には、マスタＥＣＵ２Ａは、スレーブＥＣＵ２Ｂ〜２Ｄに対してマスタ判別カウンタ１２Ｂの値を送信した後、所定時間が経過してもスレーブＥＣＵ２Ｂ〜２Ｄからマスタ判別カウンタ１２Ｂの受信完了通知を受信できない場合には、タイムアウトと判定する。この場合、マスタＥＣＵ２Ａは、スレーブ切り離し処置を実施する。一方、スレーブＥＣＵ２Ｂ〜２Ｄは、所定時間が経過してもマスタＥＣＵ２Ａからマスタ判別カウンタ１２Ｂの値を受信できない場合に、タイムアウトと判定する。この場合、スレーブＥＣＵ２Ｂ〜２Ｄは、マスタ切り離し処置を実施する。
【０１０５】
マスタ判別カウンタ１２Ｂの同期に成功した場合、マスタＥＣＵ２Ａ及びスレーブＥＣＵ２Ｂ〜２Ｄは、マスタ判別カウンタ１２Ｂを更新する。続いて、マスタＥＣＵ２Ａは、スレーブＥＣＵ２Ｂ〜２Ｄに対し、フレッシュネス値及び暗号データを含む検証用データを送信する。スレーブＥＣＵ２Ｂ〜２Ｄは、フレッシュネス値及び暗号データを含む検証用データを受信し、フレッシュネス値の検証を実施する。この検証の結果、フレッシュネス値に問題がなければ、フレッシュネス値検証ＯＫとなり、スレーブＥＣＵ２Ｂ〜２Ｄは、マスタＥＣＵ２Ａに対し、フレッシュネス値ＯＫ通知を送信する。
【０１０６】
フレッシュネス値検証ＯＫの場合、スレーブＥＣＵ２Ｂ〜２Ｄは、ＭＡＣに基づくメッセージ認証機能の検証を実施する。この検証の結果、メッセージ認証機能に問題がなければ、メッセージ認証検証ＯＫとなり、スレーブＥＣＵ２Ｂ〜２Ｄは、マスタＥＣＵ２Ａに対し、検証ＯＫ通知を送信する。一方、検証の結果、メッセージ認証機能に問題があれば、メッセージ認証検証ＮＧとなり、スレーブＥＣＵ２Ｂ〜２Ｄは、マスタＥＣＵ２Ａに対し、検証ＮＧ通知を送信する。
【０１０７】
マスタＥＣＵ２Ａは、スレーブＥＣＵ２Ｂ〜２Ｄからの通知に基づき、検証ＯＫか検証ＮＧかの多数決を実施する。多数決の結果、検証ＮＧが過半数となった場合、マスタＥＣＵ２Ａは、マスタ側故障と判断する。この場合、マスタＥＣＵ２Ａは、通常処理から代替処理へ移行する。一方、多数決の結果、検証ＯＫが過半数となった場合、マスタＥＣＵ２Ａは、スレーブ側故障と判断する。この場合、マスタＥＣＵ２Ａは、スレーブＥＣＵ２Ｂ〜２Ｄのうち、検証ＮＧ通知を送信したＥＣＵに対し、代替処理移行要求を送信する。スレーブＥＣＵ２Ｂ〜２Ｄのうち、代替処理移行要求を受信したＥＣＵは、通常処理から代替処理へ移行する。
【０１０８】
一方、フレッシュネス値の検証の結果、フレッシュネス値に問題があれば、フレッシュネス値検証ＮＧとなり、スレーブＥＣＵ２Ｂ〜２Ｄは、マスタＥＣＵ２Ａに対し、フレッシュネス値ＮＧ通知を送信する。マスタＥＣＵ２Ａは、スレーブＥＣＵ２Ｂ〜２Ｄからの通知に基づき、フレッシュネス値検証ＯＫかフレッシュネス値検証ＮＧかの多数決を実施する。多数決の結果、フレッシュネス値検証ＮＧが過半数となった場合、マスタＥＣＵ２Ａは、マスタ側故障と判断する。この場合、マスタＥＣＵ２Ａは、通常処理から代替処理へ移行する。一方、多数決の結果、フレッシュネス値検証ＯＫが過半数となった場合、マスタＥＣＵ２Ａは、スレーブ側故障と判断する。この場合、マスタＥＣＵ２Ａは、スレーブＥＣＵ２Ｂ〜２Ｄのうち、フレッシュネス値検証ＮＧ通知を送信したＥＣＵに対し、代替処理移行要求を送信する。スレーブＥＣＵ２Ｂ〜２Ｄのうち、代替処理移行要求を受信したＥＣＵは、通常処理から代替処理へ移行する。
【０１０９】
［効果］
以上説明した通り、上記ネットワークシステム１によれば、ＥＣＵ２Ｂにおいて処理対象データの認証に失敗した場合でも、依頼先のＥＣＵ２Ｃにおいて処理対象データの認証に成功すれば、依頼元のＥＣＵ２Ｂは認証済みデータに含まれる処理対象データを利用することができる。したがって、例えば、ＥＣＵ２Ｂにおいて認証処理を実行するために必要となるハードウェア又はソフトウェアに故障等の問題が生じていたとしても、ＥＣＵ２Ｂは認証済みの処理対象データを利用することができる。
【０１１０】
また、上記ネットワークシステム１の場合、検証用データに対するメッセージ認証を、処理対象データに対するメッセージ認証とは別に実行する。そのため、処理対象データに対するメッセージ認証を実行する際に、加えてメッセージ認証機能が正常に機能するか否かを検証する場合に比べ、処理対象データに対する処理を簡素化し、当該処理を迅速に完了させることができる。また、処理対象データに対する処理を実行していない空き時間を利用して、検証用データに対するメッセージ認証を実行することができる。よって、処理対象データに応じた制御等を遅滞なく実行することができ、当該制御等のリアルタイム性を向上させることができる。
【０１１１】
また、上記ネットワークシステム１の場合、マスタＥＣＵ２Ａで異常発生要因がマスタＥＣＵ２ＡもあるのかスレーブＥＣＵ２Ｂ〜２Ｄにあるのかを判別し、代替処理への移行又は移行要求の送信を行う。したがって、スレーブＥＣＵ２Ｂ〜２Ｄが個々に代替処理へ移行することはなく、マスタＥＣＵ２Ａでシステム全体の状態を一元的に把握することができる。
【０１１２】
また、上記ネットワークシステム１の場合、スレーブＥＣＵ２Ｂ〜２Ｄは、自身の機能に問題がないかどうかを自ら確認し、その結果をマスタＥＣＵ２Ａへ通知する。したがって、マスタＥＣＵ２ＡがスレーブＥＣＵ２Ｂ〜２Ｄそれぞれの機能を診断しなくても済み、マスタＥＣＵ２ＡはスレーブＥＣＵ２Ｂ〜２Ｄからの通知を待つだけでよい。よって、マスタＥＣＵ２Ａにかかる負荷を軽減でき、スレーブＥＣＵ２Ｂ〜２ＤからマスタＥＣＵ２Ａへの通知もＯＫかＮＧかを示す通知があれば足り、ローカルバス６にかかる負荷を低減することができる。
【０１１３】
また、上記ネットワークシステム１の場合、検証用データ中の暗号データは、フレッシュネス値に基づいて生成されている。したがって、検証用データを送信する際には、暗号化前の通常データを送信しなくても、受信側で暗号化前のデータであるフレッシュネス値を把握することができる。よって、暗号化前の通常データを送信しなくても済む分だけ、検証用データのデータ量を削減でき、ネットワークにかかる負荷を低減することができる。
【０１１４】
また、上記ネットワークシステム１の場合、ＥＣＵ２Ａ〜２Ｄそれぞれにマスタ判別カウンタ１２Ｂを持たせ、そのカウンタ値を参照することで、マスタＥＣＵかスレーブＥＣＵかを判定し、マスタＥＣＵを順次切り替えている。したがって、仮にマスタＥＣＵで故障が発生したとしても、別のＥＣＵがマスタＥＣＵとなって、所期の処理を継続することができる。
【０１１５】
また、上記ネットワークシステム１の場合、フレッシュネス値の検証については、上限回数の範囲内で再検証を実施する。したがって、各ＥＣＵでフレッシュネス値の更新タイミングにばらつきが発生しても、それが原因で直ちにメッセージ認証機能に問題があると判定されてしまうのを抑制することができる。
【０１１６】
また、上記ネットワークシステム１の場合、マスタ判別カウンタ同期処理でタイムアウトが発生した場合、応答がなかったスレーブＥＣＵに対してマスタＥＣＵが本システムからの切り離しを実施する。あるいは、マスタＥＣＵに対してスレーブＥＣＵが本システムからの切り離しを実施する。したがって、メッセージ認証機能以外の通信バス異常やＥＣＵ不具合といった異常があっても対応することができ、異常のあったＥＣＵを本システムの対象外として切り離すことで、不要な通信を減らし、バス負荷を低減することができる
［他の実施形態］
以上、ネットワークシステムについて、例示的な実施形態を挙げて説明したが、上述の実施形態は本開示の一態様として例示されるものにすぎない。すなわち、本開示は、上述の例示的な実施形態に限定されるものではなく、本開示の技術的思想を逸脱しない範囲内において、様々な形態で実施することができる。
【０１１７】
例えば、上記実施形態では、検証用データに含まれる暗号データを、フレッシュネス値から生成していたが、マスタＥＣＵ２ＡとスレーブＥＣＵ２Ｂ〜２Ｄとが共通に認識しているデータであれば、フレッシュネス値以外のデータを暗号化してもよい。この場合でも、暗号化前のデータを通常データとして送信しなくても済むので、検証用データのデータ量を削減することができる。
【０１１８】
例えば、車両固有の番号やネットワークシステム１における固有の番号が存在する場合には、そのような番号を暗号化して検証用データに含めればよい。この場合も、検証用データには通常データを含めなくても、スレーブＥＣＵ２Ｂ〜２Ｄでは、暗号化前のデータを把握できる。よって、検証用データに含める通常データを省略しても、スレーブＥＣＵ２Ｂ〜２Ｄでは、暗号データが適正か否かを判断することができる。
【０１１９】
ただし、上述のような固有の番号は、通常は固定値になるのに対し、フレッシュネス値であれば経時的に変化する可変値となる。よって、このような可変値を検証用データとして用いれば、データを盗み見して解析することが困難になるので、セキュリティ性を高める観点からは、フレッシュネス値のような可変値を利用するとよい。
【０１２０】
また、上記実施形態では上記２つのグローバルバス５Ａ，５Ｂを例示したが、グローバルバスの数は任意である。例えば、グローバルバスの数は、１つ又は３つ以上であってもよい。また、上記実施形態では、８個のＥＣＵ２Ａ〜２Ｄ及びＥＣＵ３Ａ〜３Ｄを例示したが、ＥＣＵ数は任意である。例えば、ＥＣＵの数は、７個以下又は９個以上であってもよい。
【０１２１】
また、上記実施形態では、ＥＣＵ２Ａ〜２Ｄがローカルバス６に接続されている例を示したが、ＥＣＵ３Ａ〜３Ｄのうちの少なくとも１つがローカルバス６に接続されていてもよい。あるいは、ＥＣＵ３Ａ〜３Ｄのうちの少なくとも１つがローカルバス６とは別のローカルバスに接続されていてもよい。
【０１２２】
本開示に記載のＥＣＵ２Ａ〜２Ｄ及びその手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリを構成することによって提供された専用コンピュータにより、実現されてもよい。あるいは、本開示に記載のＥＣＵ２Ａ〜２Ｄ及びその手法は、一つ以上の専用ハードウェア論理回路によってプロセッサを構成することによって提供された専用コンピュータにより、実現されてもよい。もしくは、本開示に記載のＥＣＵ２Ａ〜２Ｄ及びその手法は、一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリと一つ以上のハードウェア論理回路によって構成されたプロセッサとの組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されてもよい。ＥＣＵ２Ａ〜２Ｄに含まれる各部の機能を実現する手法には、必ずしもソフトウェアが含まれている必要はなく、その全部の機能が、一つあるいは複数のハードウェアを用いて実現されてもよい。
【０１２３】
この他、上記各実施形態における１つの構成要素によって実現していた機能を、複数の構成要素によって実現するように構成してもよい。また、複数の構成要素によって実現していた機能を１つの構成要素によって実現するように構成してもよい。また、上記各実施形態の構成の一部を省略してもよい。また、上記各実施形態の構成の少なくとも一部を、他の上記実施形態の構成に対して付加、置換等してもよい。
【０１２４】
また、上述したネットワークシステムの他、本開示でいう電子装置を構成要素とするシステム、本開示でいう電子装置としてコンピュータを機能させるためのプログラム、このプログラムを記録した記録媒体など、種々の形態で本開示を実現することもできる。
【０１２５】
［補足］
なお、以上説明した例示的な実施形態から明らかなように、本開示のネットワークシステムは、更に以下に挙げるような構成を備えていてもよい。
【０１２６】
（Ａ）マスタ装置は、検証用データをスレーブ装置に対してローカルバス経由で送信するように構成されてもよい。スレーブ装置は、マスタ装置から検証用データを受信した場合に、検証用データに対してメッセージ認証を実行し、その認証結果をマスタ装置に対してローカルバス経由で送信するように構成されていてもよい。
【０１２７】
（Ｂ）マスタ装置は、スレーブ装置から認証結果を受信した場合に、認証結果に基づいて、複数の電子装置それぞれのメッセージ認証機能が正常に機能するか否かを判断するように構成されていてもよい。
【０１２８】
（Ｃ）マスタ装置及びスレーブ装置は、各装置において既知のデータである第１データが含まれる検証用データを利用するように構成されていてもよい。
（Ｄ）第１データは、グローバルバス経由でフレッシュネス値管理マスタから送信されてくるフレッシュネス値であってもよい。
【０１２９】
（Ｅ）スレーブ装置は、フレッシュネス値管理マスタから受信したフレッシュネス値である第１フレッシュネス値と、マスタ装置から受信した検証用データに含まれるフレッシュネス値である第２フレッシュネス値とが一致するか否かを検証するように構成され、しかも、第１フレッシュネス値と第２フレッシュネス値とが一致しない場合には、第１フレッシュネス値を変更して再検証を実行するように構成され、当該再検証は、当該再検証を実行した回数があらかじめ定められた上限回数以下である場合に実行されるように構成されていてもよい。
【０１３０】
（Ｆ）マスタ装置及びスレーブ装置は、グローバルバス経由での通信が実施される頻度と同等以上の頻度で検証処理を実行するように構成されていてもよい。
（Ｇ）複数の電子装置は、カウント値が順に変更されるように構成されたカウンタを備え、カウント値に基づいて、マスタ装置として機能すべきかスレーブ装置として機能すべきかの判断を実行するように構成されていてもよい。
【０１３１】
（Ｈ）マスタ装置は、スレーブ装置に対してカウント値を送信し、当該カウント値の送信後に所定の時間が経過してもスレーブ装置から応答がない場合には、当該スレーブ装置をネットワークシステムから切り離すように構成されていてもよい。
【０１３２】
（Ｉ）スレーブ装置は、所定の時間が経過してもマスタ装置からカウント値を受信できない場合には、マスタ装置をネットワークシステムから切り離すように構成されていてもよい。
【符号の説明】
【０１３３】
１…ネットワークシステム、１Ａ…第１ネットワーク、１Ｂ…第２ネットワーク、２Ａ，２Ｂ，２Ｃ，２Ｄ，３Ａ，３Ｂ，３Ｃ，３Ｄ…ＥＣＵ、５Ａ，５Ｂ…グローバルバス、６…ローカルバス、７…フレッシュネス値管理マスタ、８…外部通信路、１１…ＣＰＵ、１２…ＲＡＭ、１２Ａ…受信データバッファ、１２Ｂ…マスタ判別カウンタ、１３…フラッシュメモリ、１３Ａ…共通鍵記憶部、１３Ｂ…ＣＶＮ記憶部、１６…第一通信部、１７…第二通信部。
【図１】
2020188314.tif 000003
【図２】
2020188314.tif 000004
【図３】
2020188314.tif 000005
【図４】
2020188314.tif 000006
【図５】
2020188314.tif 000007
【図６】
2020188314.tif 000008
【図７】
2020188314.tif 000009
【図８】
2020188314.tif 000010
【図９】
2020188314.tif 000011
【図１０】
2020188314.tif 000012
【図１１】
2020188314.tif 000013
【図１２】
2020188314.tif 000014
【図１３】
2020188314.tif 000015
【図１４】
2020188314.tif 000016
【図１５】
2020188314.tif 000017
【図１６】
2020188314.tif 000018
【図１７】
2020188314.tif 000019