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