(57)【要約】  共有鍵を保持する複数のＥＣＵを備える車載ネットワークのセキュリティを確保するための鍵管理方法を提供する。バスを介してフレームに係る通信を行う複数の電子制御ユニット（ＥＣＵ）を備える車載ネットワークシステムにおける鍵管理方法では、マスタＥＣＵＣ（４００）が、１以上のＥＣＵ（１００ａ〜１００ｄ）それぞれとの相互間で共有する共有鍵を保持し、ＥＣＵ（１００ａ〜１００ｄ）の各々が、保持する共有鍵に基づいてマスタＥＣＵ（４００）との通信によりセッション鍵を取得し、取得後においてバスを介して送信又は受信するフレームに対する暗号処理を、セッション鍵を用いて実施し、車載ネットワークシステムを搭載する車両が特定状態である場合に、マスタＥＣＵ（４００）は、ＥＣＵ（１００ａ）等が保持する共有鍵のセキュリティ状態の検査（例えばステップＳ１２０１、Ｓ１２０３）を実行する。
2016075869.tif 000002
【特許請求の範囲】
【請求項１】
バスを介してフレームに係る通信を行う複数の電子制御ユニットを備える車載ネットワークシステムにおける鍵管理方法であって、
前記複数の電子制御ユニットのうち第１種電子制御ユニットが、前記第１種電子制御ユニット以外の１以上の第２種電子制御ユニットそれぞれとの相互間で共有する共有鍵を保持し、
前記第２種電子制御ユニット各々が、保持する前記共有鍵に基づいて前記第１種電子制御ユニットとの通信によりセッション鍵を取得し、当該取得後において、前記バスを介して送信又は受信するフレームに対する暗号処理を、当該セッション鍵を用いて実施し、
前記車載ネットワークシステムを搭載する車両が特定状態である場合に、前記第１種電子制御ユニットは、前記第２種電子制御ユニットが保持する前記共有鍵のセキュリティ状態の検査を実行する
鍵管理方法。
【請求項２】
前記検査は、前記共有鍵の有効期限に関する検査である
請求項１記載の鍵管理方法。
【請求項３】
前記第１種電子制御ユニットは、前記第２種電子制御ユニットから、当該第２種電子制御ユニットが保持する前記共有鍵についての有効期限を示す情報を含むフレームを受信して、当該有効期限が既に経過しているか否かを判別することで前記検査を行い、当該有効期限が経過していない場合には当該第２種電子制御ユニットにセッション鍵を与えるための通信を行い、当該有効期限が経過している場合には報知のための制御を実行する
請求項２記載の鍵管理方法。
【請求項４】
前記検査は、前記共有鍵を保持する前記第２種電子制御ユニットのシリアルＩＤに関する検査である
請求項１記載の鍵管理方法。
【請求項５】
前記第１種電子制御ユニットは、前記第２種電子制御ユニットから、当該第２種電子制御ユニットのシリアルＩＤを示す情報を含むフレームを受信して、当該シリアルＩＤ及び予め保持する所定の照合用情報に基づいて、前記共有鍵のセキュリティ状態が適切であるか否かを判別することで前記検査を行い、当該セキュリティ状態が適切である場合には当該第２種電子制御ユニットにセッション鍵を与えるための通信を行い、当該セキュリティ状態が適切でない場合には報知のための制御を実行する
請求項４記載の鍵管理方法。
【請求項６】
前記複数の電子制御ユニットが、複数の前記第２種電子制御ユニットを含む場合において、前記検査は、複数の前記第２種電子制御ユニットにおける、フレームの送信順序に関する検査である
請求項１記載の鍵管理方法。
【請求項７】
前記第１種電子制御ユニットは、所定要求を示すフレームを送信した後に複数の前記第２種電子制御ユニットから逐次受信した各フレームのＩＤに基づいて、所定順序リストが示す順序で当該各ＩＤが受信されたか否かを判別することで前記検査を行う
請求項６記載の鍵管理方法。
【請求項８】
前記特定状態は、前記車両が走行していない状態であり、
前記第１種電子制御ユニットは、前記特定状態である場合に限って、前記検査を実行する
請求項１〜７のいずれか一項に記載の鍵管理方法。
【請求項９】
前記第１種電子制御ユニットは、前記検査を、前記車両の外部に所在するサーバと通信することにより、実行する
請求項１〜８のいずれか一項に記載の鍵管理方法。
【請求項１０】
前記複数の電子制御ユニットが、ＣＡＮ（Controller Area Network）プロトコルに従って前記バスを介してフレームに係る通信を行う
請求項１〜９のいずれか一項に記載の鍵管理方法。
【請求項１１】
バスを介してフレームに係る通信を行う複数の電子制御ユニットを備える車載ネットワークシステムであって、
前記複数の電子制御ユニットのうち第１種電子制御ユニットは、前記第１種電子制御ユニット以外の１以上の第２種電子制御ユニットそれぞれとの相互間で共有する共有鍵を保持し、
前記第２種電子制御ユニット各々は、保持する前記共有鍵に基づいて前記第１種電子制御ユニットとの通信によりセッション鍵を取得し、当該取得後において、前記バスを介して送信又は受信するフレームに対する暗号処理を、当該セッション鍵を用いて実施し、
前記第１種電子制御ユニットは、自ユニットを搭載する車両が特定状態である場合に、前記第２種電子制御ユニットが保持する前記共有鍵のセキュリティ状態の検査を実行する
車載ネットワークシステム。
【請求項１２】
バスを介してフレームに係る通信を行う複数の電子制御ユニットを備える車載ネットワークシステムにおける１つの電子制御ユニットとしての鍵管理装置であって、
前記複数の電子制御ユニットのうち自装置以外の１以上の電子制御ユニットそれぞれとの相互間で共有する、フレームに係る暗号処理用のセッション鍵の伝達に用いるための、共有鍵を保持し、
自装置を搭載する車両が特定状態である場合に、自装置以外の前記電子制御ユニットが保持する前記共有鍵のセキュリティ状態の検査を実行する
鍵管理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、車載ネットワークでメッセージ（フレーム）を安全に送受信するための暗号処理で用いられる鍵の管理技術に関する。
【背景技術】
【０００２】
近年、自動車の中のシステムには、電子制御ユニット（ＥＣＵ：Electronic Control Unit）と呼ばれる装置が多数配置されている。これらのＥＣＵをつなぐネットワークは車載ネットワークと呼ばれる。車載ネットワークには、多数の規格が存在する。その中でも最も主流な車載ネットワークの一つに、ＩＳＯ１１８９８−１で規定されているＣＡＮ（Controller Area Network）という規格が存在する（「非特許文献１」参照）。【０００３】
ＣＡＮでは、通信路は２本のバスで構成され、バスに接続されているＥＣＵはノードと呼ばれる。バスに接続されている各ノードは、フレームと呼ばれるメッセージを送受信する。ＣＡＮでは送信先や送信元を指す識別子は存在せず、送信ノードはフレーム毎にＩＤ（ＣＡＮ−ＩＤと称する）を付けて送信し（つまりバスに信号を送出し）、各受信ノードは予め定められたＣＡＮ−ＩＤのみを受信する（つまりバスから信号を読み取る）。また、ＣＳＭＡ／ＣＡ（Carrier Sense Multiple Access/Collision Avoidance）方式を採用しており、複数ノードの同時送信時にはＣＡＮ−ＩＤによる調停が行われ、ＣＡＮ−ＩＤの値が小さいフレームが優先的に送信される。【０００４】
ところで、ＣＡＮでは、不正なフレームが送信されるようなケースを想定したセキュリティ機能が存在しないため、車載ネットワークにおいて不正なノードがバスに接続され、不正なノードが不正にフレームを送信することで、車体を不正にコントロールしてしまう可能性がある。このような不正なフレームの送信によるコントロールを防止するために、ＣＡＮにおけるデータフィールドにメッセージ認証コード（ＭＡＣ：Message Authentication Code）を付加して送信することで、正規のＥＣＵが送信したフレームを識別する技術が知られている（「特許文献１」参照）。ＭＡＣを生成する鍵の特定を図ろうとするＭＡＣに対する総当り攻撃への耐性を高めるために、定期的に一時的なセッション鍵を生成して、ＭＡＣの生成に用いることが望ましい。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１３−９８７１９号公報
【非特許文献】
【０００６】
【非特許文献１】ＣＡＮ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  ２．０  Ｐａｒｔ  Ａ、［ｏｎｌｉｎｅ］、ＣＡＮ  ｉｎ  Ａｕｔｏｍａｔｉｏｎ（ＣｉＡ）、［平成２６年１１月１４日検索］、インターネット（ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｃａｎ−ｃｉａ．ｏｒｇ／ｆｉｌｅａｄｍｉｎ／ｃｉａ／ｓｐｅｃｉｆｉｃａｔｉｏｎｓ／ＣＡＮ２０Ａ．ｐｄｆ）
【非特許文献２】ＲＦＣ４４９３：Ｔｈｅ  ＡＥＳ−ＣＭＡＣ  Ａｌｇｏｒｉｔｈｍ
【発明の概要】
【０００７】
ところで、セッション鍵の生成を特定のＥＣＵが担う場合には、正規のＥＣＵ間で事前に共有した鍵（「共有鍵」と称する）を用いてセッション鍵を暗号化すると、ＥＣＵ間で安全にセッション鍵の配布（伝達）を行うことができる。
【０００８】
しかし、共有鍵の漏洩を適切に検知することができないと、不正なＥＣＵがセッション鍵を受信し、ＭＡＣを生成することが可能となってしまう。
【０００９】
そこで、本開示は、共有鍵を保持する複数のＥＣＵを備える車載ネットワークのセキュリティを確保するための鍵管理方法を提供する。また、本開示は、共有鍵を保持するＥＣＵ間での通信におけるセキュリティを確保するための車載ネットワークシステム及び鍵管理装置を提供する。
【００１０】
上記課題を解決するために本開示の一態様に係る鍵管理方法は、バスを介してフレームに係る通信を行う複数の電子制御ユニットを備える車載ネットワークシステムにおける鍵管理方法であって、前記複数の電子制御ユニットのうち第１種電子制御ユニットが、前記第１種電子制御ユニット以外の１以上の第２種電子制御ユニットそれぞれとの相互間で共有する共有鍵を保持し、前記第２種電子制御ユニット各々が、保持する前記共有鍵に基づいて前記第１種電子制御ユニットとの通信によりセッション鍵を取得し、当該取得後において、前記バスを介して送信又は受信するフレームに対する暗号処理を、当該セッション鍵を用いて実施し、前記車載ネットワークシステムを搭載する車両が特定状態である場合に、前記第１種電子制御ユニットは、前記第２種電子制御ユニットが保持する前記共有鍵のセキュリティ状態の検査を実行する鍵管理方法である。
【００１１】
また、上記課題を解決するために本開示の一態様に係る車載ネットワークシステムは、バスを介してフレームに係る通信を行う複数の電子制御ユニットを備える車載ネットワークシステムであって、前記複数の電子制御ユニットのうち第１種電子制御ユニットは、前記第１種電子制御ユニット以外の１以上の第２種電子制御ユニットそれぞれとの相互間で共有する共有鍵を保持し、前記第２種電子制御ユニット各々は、保持する前記共有鍵に基づいて前記第１種電子制御ユニットとの通信によりセッション鍵を取得し、当該取得後において、前記バスを介して送信又は受信するフレームに対する暗号処理を、当該セッション鍵を用いて実施し、前記第１種電子制御ユニットは、自ユニットを搭載する車両が特定状態である場合に、前記第２種電子制御ユニットが保持する前記共有鍵のセキュリティ状態の検査を実行する車載ネットワークシステムである。
【００１２】
また、上記課題を解決するために本開示の一態様に係る鍵管理装置は、バスを介してフレームに係る通信を行う複数の電子制御ユニットを備える車載ネットワークシステムにおける１つの電子制御ユニットとしての鍵管理装置であって、前記複数の電子制御ユニットのうち自装置以外の１以上の電子制御ユニットそれぞれとの相互間で共有する、フレームに係る暗号処理用のセッション鍵の伝達に用いるための、共有鍵を保持し、自装置を搭載する車両が特定状態である場合に、自装置以外の前記電子制御ユニットが保持する前記共有鍵のセキュリティ状態の検査を実行する鍵管理装置である。
【００１３】
本開示によれば、適時に共有鍵のセキュリティ状態の検査がなされるため、車載ネットワークシステムのセキュリティが確保され得る。
【図面の簡単な説明】
【００１４】
【図１】実施の形態１に係る車載ネットワークシステムの全体構成を示す図である。
【図２】ＣＡＮプロトコルで規定されるデータフレームのフォーマットを示す図である。
【図３】実施の形態１に係るマスタＥＣＵ（鍵管理装置）の構成図である。
【図４】マスタＥＣＵ（鍵管理装置）が保持する受信ＩＤリストの一例を示す図である。
【図５】実施の形態１に係るマスタＥＣＵ（鍵管理装置）が保持する共有鍵リストの一例を示す図である。
【図６】マスタＥＣＵ（鍵管理装置）が保持するセッション鍵リストの一例を示す図である。
【図７】実施の形態１に係るＥＣＵの構成図である。
【図８】ＥＣＵの保持する受信ＩＤリストの一例を示す図である。
【図９】ＥＣＵの保持する受信ＩＤリストの一例を示す図である。
【図１０】エンジンに接続されたＥＣＵから送信されるフレームにおけるＣＡＮ−ＩＤ及びデータフィールドの一例を示す図である。
【図１１】ブレーキに接続されたＥＣＵから送信されるフレームにおけるＣＡＮ−ＩＤ及びデータフィールドの一例を示す図である。
【図１２】ドア開閉センサに接続されたＥＣＵから送信されるフレームにおけるＣＡＮ−ＩＤ及びデータフィールドの一例を示す図である。
【図１３】窓開閉センサに接続されたＥＣＵから送信されるフレームにおけるＣＡＮ−ＩＤ及びデータフィールドの一例を示す図である。
【図１４】ＥＣＵが保持する共有鍵の一例を示す図である。
【図１５】マスタＥＣＵ（鍵管理装置）とＥＣＵとの間でのセッション鍵配布シーケンスの一例を示す図である。
【図１６】ＥＣＵ間でのメッセージ認証シーケンスの一例を示す図である。
【図１７】実施の形態１に係るマスタＥＣＵ（鍵管理装置）とＥＣＵとの間での共有鍵検証シーケンスの一例を示す図である。
【図１８】実施の形態１の変形例に係るマスタＥＣＵ（鍵管理装置）の構成図である。
【図１９】実施の形態１の変形例に係るマスタＥＣＵ（鍵管理装置）とＥＣＵとの間での共有鍵検証シーケンスの一例を示す図である。
【図２０】実施の形態２に係るマスタＥＣＵ（鍵管理装置）の構成図である。
【図２１】実施の形態２に係るマスタＥＣＵ（鍵管理装置）が保持する共有鍵リストの一例を示す図である。
【図２２】実施の形態２に係るＥＣＵの構成図である。
【図２３】実施の形態２に係るマスタＥＣＵ（鍵管理装置）とＥＣＵとの間での共有鍵検証シーケンスの一例を示す図である。
【図２４】実施の形態２の変形例に係るマスタＥＣＵ（鍵管理装置）の構成図である。
【図２５】実施の形態２の変形例に係るマスタＥＣＵ（鍵管理装置）とＥＣＵとの間での共有鍵検証シーケンスの一例を示す図である。
【図２６】実施の形態３に係るマスタＥＣＵ（鍵管理装置）の構成図である。
【図２７】実施の形態３に係るシーケンス記録リストの一例を示す図である。
【図２８】実施の形態３に係るマスタＥＣＵ（鍵管理装置）とＥＣＵとの間での共有鍵検証シーケンスの一例を示す図である。
【図２９】実施の形態３の変形例に係るマスタＥＣＵ（鍵管理装置）の構成図である。
【図３０】実施の形態３の変形例に係るマスタＥＣＵ（鍵管理装置）とＥＣＵとの間での共有鍵検証シーケンスの一例を示す図である。
【発明を実施するための形態】
【００１５】
本開示の一態様に係る鍵管理方法は、バスを介してフレームに係る通信を行う複数の電子制御ユニットを備える車載ネットワークシステムにおける鍵管理方法であって、前記複数の電子制御ユニットのうち第１種電子制御ユニットが、前記第１種電子制御ユニット以外の１以上の第２種電子制御ユニットそれぞれとの相互間で共有する共有鍵を保持し、前記第２種電子制御ユニット各々が、保持する前記共有鍵に基づいて前記第１種電子制御ユニットとの通信によりセッション鍵を取得し、当該取得後において、前記バスを介して送信又は受信するフレームに対する暗号処理を、当該セッション鍵を用いて実施し、前記車載ネットワークシステムを搭載する車両が特定状態である場合に、前記第１種電子制御ユニットは、前記第２種電子制御ユニットが保持する前記共有鍵のセキュリティ状態の検査を実行する鍵管理方法である。これにより、車載ネットワークシステムのセキュリティを確保し得る。
【００１６】
また、前記検査は、前記共有鍵の有効期限に関する検査であることとしても良い。これにより、共有鍵の有効期限切れを検知でき、有効期限が過ぎた共有鍵を有する不正なＥＣＵによるセッション鍵の取得を防止し得る。
【００１７】
また、前記第１種電子制御ユニットは、前記第２種電子制御ユニットから、当該第２種電子制御ユニットが保持する前記共有鍵についての有効期限を示す情報を含むフレームを受信して、当該有効期限が既に経過しているか否かを判別することで前記検査を行い、当該有効期限が経過していない場合には当該第２種電子制御ユニットにセッション鍵を与えるための通信を行い、当該有効期限が経過している場合には報知のための制御を実行することとしても良い。これにより、有効期限が過ぎた共有鍵を有するＥＣＵの存在により共有鍵のセキュリティ状態が不適切であれば報知がなされるため、セキュリティの確保が可能となる。
【００１８】
また、前記検査は、前記共有鍵を保持する前記第２種電子制御ユニットのシリアルＩＤに関する検査であることとしても良い。これにより、共有鍵を不正にコピー（複製）している不正なＥＣＵの存在を検知でき、不正なＥＣＵによるセッション鍵の取得を防止し得る。
【００１９】
また、前記第１種電子制御ユニットは、前記第２種電子制御ユニットから、当該第２種電子制御ユニットのシリアルＩＤを示す情報を含むフレームを受信して、当該シリアルＩＤ及び予め保持する所定の照合用情報に基づいて、前記共有鍵のセキュリティ状態が適切であるか否かを判別することで前記検査を行い、当該セキュリティ状態が適切である場合には当該第２種電子制御ユニットにセッション鍵を与えるための通信を行い、当該セキュリティ状態が適切でない場合には報知のための制御を実行することとしても良い。これにより、シリアルＩＤが不正であるＥＣＵの存在により共有鍵のセキュリティ状態が不適切であれば報知がなされるため、セキュリティの確保が可能となる。
【００２０】
また、前記複数の電子制御ユニットが、複数の前記第２種電子制御ユニットを含む場合において、前記検査は、複数の前記第２種電子制御ユニットにおける、フレームの送信順序に関する検査であることとしても良い。これにより、ＥＣＵ間でのフレームの送信順序が不適切であることを検知でき、不正なＥＣＵによるセッション鍵の取得を防止し得る。
【００２１】
また、前記第１種電子制御ユニットは、所定要求を示すフレームを送信した後に複数の前記第２種電子制御ユニットから逐次受信した各フレームのＩＤに基づいて、所定順序リストが示す順序で当該各ＩＤが受信されたか否かを判別することで前記検査を行うこととしても良い。これにより、所定要求を示すフレーム（生存確認用のフレーム等）を送信した後の各ＥＣＵによるレスポンスの順序により、不正なＥＣＵが存在するか否かを検知できる。
【００２２】
また、前記特定状態は、前記車両が走行していない状態であり、前記第１種電子制御ユニットは、前記特定状態である場合に限って、前記検査を実行することとしても良い。これにより、車両の走行中における各ＥＣＵの処理負荷の増大、バスのトラフィックの増大等を避けて、セキュリティ状態の検査を適切に行い得る。
【００２３】
また、前記第１種電子制御ユニットは、前記検査を、前記車両の外部に所在するサーバと通信することにより、実行することとしても良い。これにより、車載ネットワークシステム内でのセキュリティ状態の検査の負担を軽減し得る。また、車両の外部で収集される情報（他の車載ネットワークシステムから得られた情報等）を利用した検査も可能となり得る。
【００２４】
また、前記複数の電子制御ユニットが、ＣＡＮ（Controller Area Network）プロトコルに従って前記バスを介してフレームに係る通信を行うこととしても良い。これにより、ＣＡＮに従った車載ネットワークシステムにおけるセキュリティの確保が可能となる。
【００２５】
また、本開示の一態様に係る車載ネットワークシステムは、バスを介してフレームに係る通信を行う複数の電子制御ユニットを備える車載ネットワークシステムであって、前記複数の電子制御ユニットのうち第１種電子制御ユニットは、前記第１種電子制御ユニット以外の１以上の第２種電子制御ユニットそれぞれとの相互間で共有する共有鍵を保持し、前記第２種電子制御ユニット各々は、保持する前記共有鍵に基づいて前記第１種電子制御ユニットとの通信によりセッション鍵を取得し、当該取得後において、前記バスを介して送信又は受信するフレームに対する暗号処理を、当該セッション鍵を用いて実施し、前記第１種電子制御ユニットは、自ユニットを搭載する車両が特定状態である場合に、前記第２種電子制御ユニットが保持する前記共有鍵のセキュリティ状態の検査を実行する車載ネットワークシステムである。これにより、車載ネットワークシステムのセキュリティが確保され得る。
【００２６】
また、本開示の一態様に係る鍵管理装置は、バスを介してフレームに係る通信を行う複数の電子制御ユニットを備える車載ネットワークシステムにおける１つの電子制御ユニットとしての鍵管理装置であって、前記複数の電子制御ユニットのうち自装置以外の１以上の電子制御ユニットそれぞれとの相互間で共有する、フレームに係る暗号処理用のセッション鍵の伝達に用いるための、共有鍵を保持し、自装置を搭載する車両が特定状態である場合に、自装置以外の前記電子制御ユニットが保持する前記共有鍵のセキュリティ状態の検査を実行する鍵管理装置である。これにより、車載ネットワークシステムにおける共有鍵に係るセキュリティが確保され得る。
【００２７】
なお、これらの全般的又は具体的な態様は、システム、方法、集積回路、コンピュータプログラム又はコンピュータで読み取り可能なＣＤ−ＲＯＭ等の記録媒体で実現されても良く、システム、方法、集積回路、コンピュータプログラム又は記録媒体の任意な組み合わせで実現されても良い。
【００２８】
以下、実施の形態に係る車載ネットワークシステムについて、図面を参照しながら説明する。ここで示す実施の形態は、いずれも本発明の一具体例を示すものである。従って、以下の実施の形態で示される数値、構成要素、構成要素の配置及び接続形態、並びに、ステップ（工程）及びステップの順序等は、一例であって本発明を限定するものではない。以下の実施の形態における構成要素のうち、独立請求項に記載されていない構成要素については、任意に付加可能な構成要素である。また、各図は、模式図であり、必ずしも厳密に図示されたものではない。
【００２９】
（実施の形態１）
以下、本発明の実施の形態として、マスタＥＣＵ（鍵管理装置）４００を含む複数のＥＣＵがバスを介して通信する車載ネットワークシステム１０において用いられる鍵管理方法について、図面を用いて説明する。
【００３０】
鍵管理方法として、本実施の形態では、セキュリティ上、各ＥＣＵが保持する共有鍵の漏洩のリスクが高まった状態であるか否か（つまり共有鍵の更新が必要な状態か否か）について、車両の状態に応じて共有鍵の有効期限に基づいて判断（検証）する例を示す。
【００３１】
［１．１  車載ネットワークシステム１０の全体構成］
図１は、実施の形態１に係る車載ネットワークシステム１０の全体構成を示す図である。車載ネットワークシステム１０は、ＣＡＮプロトコルに従って通信するネットワーク通信システムの一例であり、制御装置、センサ等の各種機器が搭載された自動車におけるネットワーク通信システムである。車載ネットワークシステム１０は、ＣＡＮプロトコルに従ってバスを介してフレームに係る通信を行う複数の装置を備え、鍵管理方法を用いる。具体的には図１に示すように車載ネットワークシステム１０は、バス２００と、マスタＥＣＵ（鍵管理装置）４００、各種機器に接続されたＥＣＵ１００ａ〜１００ｄ等のＥＣＵといったバスに接続された各ノードとを含んで構成される。なお、車載ネットワークシステム１０には、マスタＥＣＵ４００及びＥＣＵ１００ａ〜１００ｄ以外にもいくつものＥＣＵが含まれ得るが、ここでは、便宜上マスタＥＣＵ４００及びＥＣＵ１００ａ〜１００ｄに注目して説明を行う。ＥＣＵは、例えば、プロセッサ（マイクロプロセッサ）、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置である。メモリは、ＲＯＭ、ＲＡＭ等であり、プロセッサにより実行される制御プログラム（コンピュータプログラム）を記憶することができる。例えばプロセッサが、制御プログラム（コンピュータプログラム）に従って動作することにより、ＥＣＵは各種機能を実現することになる。なお、コンピュータプログラムは、所定の機能を達成するために、プロセッサに対する指令を示す命令コードが複数個組み合わされて構成されたものである。
【００３２】
ＥＣＵ１００ａ〜１００ｄは、バス２００と接続され、それぞれエンジン３１０、ブレーキ３２０、ドア開閉センサ３３０、窓開閉センサ３４０に接続されている。ＥＣＵ１００ａ〜１００ｄのそれぞれは、接続されている機器（エンジン３１０等）の状態を取得し、定期的に状態を表すフレーム（後述するデータフレーム）等をネットワーク（つまりバス）に送信している。
【００３３】
バス２００に１台接続されているマスタＥＣＵ４００は、ＥＣＵ間でフレームの送受信を行う上で用いられる鍵に関する処理を担う役割を有する鍵管理装置としての一種のＥＣＵである。マスタＥＣＵ４００は、バス２００に接続されている複数のＥＣＵのうち自装置以外の１以上のＥＣＵそれぞれとの相互間で、フレームに係る暗号処理（ＭＡＣ処理を含む）用のセッション鍵の伝達に用いるための、同一の共有鍵を保持し、共有鍵のセキュリティ状態を管理する機能を有する。マスタＥＣＵ４００は、共有鍵のセキュリティ状態に関して必要に応じてメモリ、ハードディスク等の記録媒体にログを記録し得る。また、マスタＥＣＵ４００は、例えば、自動車のインストルメントパネル（インパネ）等に設けられた液晶ディスプレイ（ＬＣＤ：Liquid Crystal Display）等の表示装置を備え、共有鍵のセキュリティ状態に応じて情報を表示することにより運転者への報知を行い得る。
【００３４】
車載ネットワークシステム１０においてはＣＡＮプロトコルに従って、マスタＥＣＵ４００を含む各ＥＣＵがフレームの授受を行う。ＣＡＮプロトコルにおけるフレームには、データフレーム、リモートフレーム、オーバーロードフレーム及びエラーフレームがある。説明の便宜上、ここではデータフレームを中心に説明する。
【００３５】
［１．２  データフレームフォーマット］
以下、ＣＡＮプロトコルに従ったネットワークで用いられるフレームの１つであるデータフレームについて説明する。
【００３６】
図２は、ＣＡＮプロトコルで規定されるデータフレームのフォーマットを示す図である。同図には、ＣＡＮプロトコルで規定される標準ＩＤフォーマットにおけるデータフレームを示している。データフレームは、ＳＯＦ（Start Of Frame）、ＩＤフィールド、ＲＴＲ（Remote Transmission Request）、ＩＤＥ（Identifier Extension）、予約ビット「ｒ」、ＤＬＣ（Data Length Code）、データフィールド、ＣＲＣ（Cyclic Redundancy Check）シーケンス、ＣＲＣデリミタ「ＤＥＬ」、ＡＣＫ（Acknowledgement）スロット、ＡＣＫデリミタ「ＤＥＬ」、及び、ＥＯＦ（End Of Frame）の各フィールドで構成される。
【００３７】
ＳＯＦは、１ｂｉｔのドミナントで構成される。バスがアイドルの状態はレセシブになっており、ＳＯＦによりドミナントへ変更することでフレームの送信開始を通知する。
【００３８】
ＩＤフィールドは、１１ｂｉｔで構成される、データの種類を示す値であるＩＤ（ＣＡＮ−ＩＤ）を格納するフィールドである。複数のノードが同時に送信を開始した場合、このＩＤフィールドで通信調停を行うために、ＩＤが小さい値を持つフレームが高い優先度となるよう設計されている。
【００３９】
ＲＴＲは、データフレームとリモートフレームとを識別するための値であり、データフレームにおいてはドミナント１ｂｉｔで構成される。
【００４０】
ＩＤＥと「ｒ」とは、両方ドミナント１ｂｉｔで構成される。
【００４１】
ＤＬＣは、４ｂｉｔで構成され、データフィールドの長さを示す値である。なお、ＩＤＥ、「ｒ」及びＤＬＣを合わせてコントロールフィールドと称する。
【００４２】
データフィールドは、最大６４ｂｉｔで構成される送信するデータの内容を示す値である。８ｂｉｔ毎に長さを調整できる。送られるデータの仕様については、ＣＡＮプロトコルで規定されておらず、車載ネットワークシステム１０において定められる。従って、車種、製造者（製造メーカ）等に依存した仕様となる。
【００４３】
ＣＲＣシーケンスは、１５ｂｉｔで構成される。ＳＯＦ、ＩＤフィールド、コントロールフィールド及びデータフィールドの送信値より算出される。
【００４４】
ＣＲＣデリミタは、１ｂｉｔのレセシブで構成されるＣＲＣシーケンスの終了を表す区切り記号である。なお、ＣＲＣシーケンス及びＣＲＣデリミタを合わせてＣＲＣフィールドと称する。
【００４５】
ＡＣＫスロットは、１ｂｉｔで構成される。送信ノードはＡＣＫスロットをレセシブにして送信を行う。受信ノードはＣＲＣシーケンスまで正常に受信ができていればＡＣＫスロットをドミナントとして送信する。レセシブよりドミナントが優先されるため、送信後にＡＣＫスロットがドミナントであれば、送信ノードは、いずれかの受信ノードが受信に成功していることを確認できる。
【００４６】
ＡＣＫデリミタは、１ｂｉｔのレセシブで構成されるＡＣＫの終了を表す区切り記号である。
【００４７】
ＥＯＦは、７ｂｉｔのレセシブで構成されており、データフレームの終了を示す。
【００４８】
［１．３  マスタＥＣＵ４００の構成］
図３は、マスタＥＣＵ４００の構成図である。マスタＥＣＵ４００は、フレーム送受信部４０１と、フレーム解釈部４０２と、受信ＩＤ判断部４０３と、受信ＩＤリスト保持部４０４と、有効期限確認部４０５と、ＭＡＣ処理部４０６と、カウンタ保持部４０７と、セッション鍵リスト保持部４０８と、暗号処理部４０９と、共有鍵リスト保持部４１０と、セッション鍵生成部４１１と、フレーム生成部４１２とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、マスタＥＣＵ４００における通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。
【００４９】
フレーム送受信部４０１は、バス２００に対して、ＣＡＮプロトコルに従ったフレームを送受信する。バス２００からフレームを１ｂｉｔずつ受信し、フレーム解釈部４０２に転送する。また、フレーム生成部４１２より通知を受けたフレームの内容をバス２００に１ｂｉｔずつ送信する。
【００５０】
フレーム解釈部４０２は、フレーム送受信部４０１よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。フレーム解釈部４０２は、ＩＤフィールドと判断した値は受信ＩＤ判断部４０３へ転送する。フレーム解釈部４０２は、受信ＩＤ判断部４０３から通知される判定結果に応じて、ＩＤフィールドの値（ＣＡＮ−ＩＤ）と、ＩＤフィールド以降に現れるデータフィールドとを、ＭＡＣ処理部４０６へ転送するか、その判定結果を受けた以降においてフレームの受信を中止する（つまりそのフレームとしての解釈を中止する）かを決定する。また、ＭＡＣ処理部４０６に転送した後にＭＡＣ処理部４０６での処理結果（ＭＡＣの検証結果）を受け取り、正常と判定された場合（つまりＭＡＣの検証に成功した場合）には、ＩＤフィールドの値と、ＩＤフィールド以降に現れるデータフィールドとを、有効期限確認部４０５へと通知する。また、フレーム解釈部４０２は、例えば、ＣＲＣの値が合わなかったり、ドミナント固定とされている項目がレセシブだったりする等、ＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部４１２へ通知する。また、フレーム解釈部４０２は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。
【００５１】
受信ＩＤ判断部４０３は、フレーム解釈部４０２から通知されるＩＤフィールドの値を受け取り、受信ＩＤリスト保持部４０４が保持しているＣＡＮ−ＩＤのリストに従い、そのＩＤフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ＩＤ判断部４０３は、フレーム解釈部４０２へ通知する。
【００５２】
受信ＩＤリスト保持部４０４は、マスタＥＣＵ４００が受信するＣＡＮ−ＩＤのリストである受信ＩＤリストを保持する。図４に、受信ＩＤリストの一例を示す。
【００５３】
有効期限確認部４０５は、フレーム解釈部４０２より受信した、ＣＡＮ−ＩＤで特定される有効期限通知用フレームについて、データフィールドの値である、共有鍵の有効期限を示す値を取得し、現在時刻との比較を行うことで有効期限を検査する。有効期限確認部４０５は、有効期限が既に過ぎている場合は、ログに記録する。また、有効期限が過ぎている場合に、有効期限確認部４０５は、表示装置に有効期限が過ぎていることに関する情報を表示することで運転者への報知を行う。有効期限が過ぎている場合においてマスタＥＣＵ４００は、各ＥＣＵへのセッション鍵の伝達を行わないようにすることができる。
【００５４】
ＭＡＣ処理部４０６は、フレーム解釈部４０２より通知されるＣＡＮ−ＩＤと、データフィールドのＭＡＣ値を除く部分と、カウンタ保持部４０７で保持するＣＡＮ−ＩＤに対応する受信カウンタ値と、を結合した値に対し、セッション鍵リスト保持部４０８で保持する、ＣＡＮ−ＩＤに対応するセッション鍵を用いて、ＭＡＣ値を計算し、データフィールドに含まれるＭＡＣ値との比較検証を行い、検証結果をフレーム解釈部４０２へと通知する。また、フレーム生成部４１２より通知されるＣＡＮ−ＩＤと、送信するデータフィールド用のデータの値と、カウンタ保持部４０７で保持するＣＡＮ−ＩＤに対応する送信カウンタ値とを結合した値（結合値）に対し、ＭＡＣ値を計算により導出した結果をフレーム生成部４１２へと通知する。ここではＭＡＣの計算方法として、ＡＥＳ−ＣＭＡＣ（非特許文献２）を採用し、上述した結合値に対し、所定のブロック分までパディングした値でＭＡＣ鍵（セッション鍵）を使って計算し、出てきた計算結果の先頭４ｂｙｔｅｓをＭＡＣ値とする。なお、ここでのＭＡＣ値のサイズ、計算方法は一例であり、これに限定するものではない。フレームが送信される毎にインクリメントされる送信カウンタ値を反映してＭＡＣは生成されるので、たとえ同じデータの値を含むデータフレームを複数回送信したとしても、データフレームに付与（つまり付加）されるＭＡＣ値は送信の都度変化する。
【００５５】
カウンタ保持部４０７は、ＭＡＣ値を計算するために必要となるカウンタ値を、ＣＡＮ−ＩＤ毎に、送信用、受信用、各１つずつ保持する。フレームを正常に送信した場合は送信カウンタ値を、フレームを正常に受信した場合は受信カウンタ値を、それぞれインクリメントする。
【００５６】
セッション鍵リスト保持部４０８は、フレームに係る暗号処理用のセッション鍵、つまりＭＡＣ処理部４０６がＭＡＣ値の計算に用いるセッション鍵を、ＣＡＮ−ＩＤに対応付けたリスト（セッション鍵リスト）を保持する。セッション鍵リスト保持部４０８は、暗号処理部４０９からＣＡＮ−ＩＤと共に通知されたセッション鍵を、セッション鍵リストとして保存する。
【００５７】
暗号処理部４０９は、フレーム生成部４１２よりＣＡＮ−ＩＤと共にセッション鍵生成要求を受けて、セッション鍵生成部４１１へセッション鍵生成要求を通知し、セッション鍵生成部４１１により生成されて発行（送信）されたセッション鍵を受信する。暗号処理部４０９は、発行されたセッション鍵を、共有鍵リスト保持部４１０に保持する共有鍵（ＣＡＮ−ＩＤに対応した共有鍵）を用いて暗号化して、フレーム生成部４１２へ通知する。また、暗号処理部４０９は、セッション鍵生成部４１１により発行されたセッション鍵をＣＡＮ−ＩＤと共に、セッション鍵リスト保持部４０８に通知して、セッション鍵リスト保持部４０８に保存させる。
【００５８】
共有鍵リスト保持部４１０は、セッション鍵のＥＣＵ間での伝達に用いるために事前に共有される共有鍵を各ＣＡＮ−ＩＤに対応付けたリストである共有鍵リストを保存する。ＣＡＮ−ＩＤ毎に１つの共有鍵を定める。共有鍵リストにおける、あるＣＡＮ−ＩＤと共有鍵との対応関係は、そのＣＡＮ−ＩＤを含むフレームを送信するＥＣＵと共有鍵との対応を示す。なお、ＣＡＮ−ＩＤ毎に共有鍵を定める他、全ＥＣＵで１つの共有鍵を定めることとしても良い。また、バス２００が、複数のサブネットをゲートウェイで接続して構成される場合において、サブネット毎（１つのサブネットに接続されるＥＣＵの集合毎）に１つの共有鍵を定めても良い。図５に、共有鍵リスト保持部４１０が保持する共有鍵リストの一例を示す。
【００５９】
セッション鍵生成部４１１では、セッション鍵の生成要求を受けて、セッション鍵を生成して発行する。セッション鍵の生成の方法としては、例えば、マスタＥＣＵ４００に固有なシリアルＩＤから一方向関数であるハッシュ関数を使ってセッション鍵を算出する方法を用いる。セッション鍵生成部４１１が生成してセッション鍵リスト保持部４０８が保存するセッション鍵リストの一例を図６に示す。
【００６０】
フレーム生成部４１２は、フレーム解釈部４０２から通知されたエラーフレーム送信の要求に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部４０１へ通知して送信させる。
【００６１】
また、フレーム生成部４１２は、暗号処理部４０９に対して、セッション鍵生成要求を通知し、暗号化されたセッション鍵を受け取る。フレーム生成部４１２は、予め定められたＣＡＮ−ＩＤと、暗号処理部より通知された暗号化セッション鍵とをＭＡＣ処理部４０６へ通知し、ＭＡＣ値の計算結果を受信する。フレーム生成部４１２は、暗号処理部４０９から受け取った、暗号化されたセッション鍵と、ＭＡＣ処理部４０６より通知されたＭＡＣ値と、予め定められたＣＡＮ−ＩＤをつけてデータフレームを構成し、データフレームをフレーム送受信部４０１へ通知して送信させる。
【００６２】
また、マスタＥＣＵ４００は、車載ネットワークシステム１０を搭載する車両がアクセサリ−オン（ＡＣＣ−ＯＮ）の状態になったことを検知すると、フレーム生成部４１２に、共有鍵の有効期限の問い合わせ用のフレームを生成させて、フレーム送受信部４０１に送信させる機能を有する。なお、エンジン始動、ＡＣＣ−ＯＮ、停車中等といった車両の状態については各種センサ等の検知機構で検知され、検知機構からマスタＥＣＵ４００に直接又は他のＥＣＵを介して伝達され得る。
【００６３】
［１．４  受信ＩＤリスト例１］
図４は、マスタＥＣＵ４００が、受信ＩＤリスト保持部４０４において保持する受信ＩＤリスト（ＣＡＮ−ＩＤのリスト）の一例を示す図である。同図に例示する受信ＩＤリストは、ＣＡＮ−ＩＤの値が「１」、「２」、「３」、「４」、「１０１」、「１０２」、「１０３」及び「１０４」のいずれかであるフレームをマスタＥＣＵ４００が選択的に受信して処理するために用いられる。なお、この例では、各ＥＣＵが送信する有効期限通知用フレームのＣＡＮ−ＩＤ「１０１」、「１０２」、「１０３」或いは「１０４」は、そのＥＣＵが基本的に送信するデータフレームのＣＡＮ−ＩＤ「１」、「２」、「３」或いは「４」に対して、一定値を加算した値となっている。
【００６４】
［１．５  共有鍵リスト例］
図５は、マスタＥＣＵ４００が、共有鍵リスト保持部４１０において保持する共有鍵リストの一例を示す図である。共有鍵リストは、ＣＡＮ−ＩＤと共有鍵（Ｋｍ）とを対応付けたリストである。同図に例示する共有鍵リストは、ＣＡＮ−ＩＤ「１」に対して、共有鍵「０ｘ１Ａ４ＤＥ４ＦＣ０２Ｆ６６Ｂ７７」が、ＣＡＮ−ＩＤ「２」に対して、共有鍵「０ｘ２７ＡＢ６ＥＡＣ８１７７３Ｆ６５」が、ＣＡＮ−ＩＤ「３」に対して、共有鍵「０ｘＣＢ９３９ＥＡ０ＣＥ３７８Ａ７Ｅ」が、ＣＡＮ−ＩＤ「４」に対して、共有鍵「０ｘ０３Ｅ４６ＦＦ２８ＣＢＣ８Ｄ７Ａ」が、それぞれ割り当てられていることを示す。
【００６５】
［１．６  セッション鍵リスト例］
図６は、マスタＥＣＵ４００が、セッション鍵リスト保持部４０８において保持するセッション鍵リストの一例を示す図である。セッション鍵リストは、ＣＡＮ−ＩＤとセッション鍵（Ｋｓ）とを対応付けたリストである。同図に例示するセッション鍵リストは、ＣＡＮ−ＩＤ「１」、「２」、「３」及び「４」に対して、同一のセッション鍵「０ｘ７６７８Ａ８７Ｂ」が割り当てられていることを示す。
【００６６】
［１．７  ＥＣＵ１００ａの構成］
図７は、ＥＣＵ１００ａの構成図である。ＥＣＵ１００ａは、フレーム送受信部１０１と、フレーム解釈部１０２と、受信ＩＤ判断部１０３と、受信ＩＤリスト保持部１０４と、復号処理部１０５と、共有鍵保持部１０６と、ＭＡＣ処理部１０７と、セッション鍵保持部１０８と、カウンタ保持部１０９と、フレーム生成部１１０と、データ取得部１１１とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、ＥＣＵ１００ａにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。なお、ＥＣＵ１００ｂ〜１００ｄも、ＥＣＵ１００ａと基本的に同様の構成を備える。
【００６７】
フレーム送受信部１０１は、バス２００に対して、ＣＡＮプロトコルに従ったフレームを送受信する。バス２００からフレームを１ｂｉｔずつ受信し、フレーム解釈部１０２に転送する。また、フレーム生成部１１０より通知を受けたフレームの内容をバス２００に送信する。
【００６８】
フレーム解釈部１０２は、フレーム送受信部１０１よりフレームの値を受け取り、ＣＡＮプロトコルにおける各フィールドにマッピングするよう解釈を行う。ＩＤフィールドと判断した値は受信ＩＤ判断部１０３へ転送する。受信ＩＤ判断部１０３から通知される判定結果に応じて、ＩＤフィールドの値（ＣＡＮ−ＩＤ）と、ＩＤフィールド以降に現れるデータフィールドとをＭＡＣ処理部１０７へ転送するか、その判定結果を受けた以降においてフレームの受信を中止する（つまりそのフレームとしての解釈を中止する）かを決定する。また、ＭＡＣ処理部１０７に転送した後にＭＡＣ処理部１０７での処理結果（ＭＡＣの検証結果）を受け取り、正常と判定された場合には、ＩＤフィールドの値と、ＩＤフィールド以降に現れるデータフィールドとを、復号処理部１０５へと通知する。また、フレーム解釈部１０２は、ＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するように、フレーム生成部１１０へ通知する。また、フレーム解釈部１０２は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。
【００６９】
受信ＩＤ判断部１０３は、フレーム解釈部１０２から通知されるＩＤフィールドの値を受け取り、受信ＩＤリスト保持部１０４が保持しているＣＡＮ−ＩＤのリストに従い、そのＩＤフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ＩＤ判断部１０３は、フレーム解釈部１０２へ通知する。
【００７０】
受信ＩＤリスト保持部１０４は、ＥＣＵ１００ａが受信するＣＡＮ−ＩＤのリストである受信ＩＤリストを保持する。図８に、ＣＡＮ−ＩＤのリストである受信ＩＤリストの一例を示す。
【００７１】
復号処理部１０５は、フレーム解釈部１０２より、セッション鍵の伝達用に予め定められているＣＡＮ−ＩＤと共に、暗号化されたセッション鍵の通知を受けると、共有鍵保持部１０６が保持する共有鍵を用いて、復号処理を行い、セッション鍵を取得する。取得したセッション鍵は、セッション鍵保持部１０８に通知して保存させる。また、復号処理部１０５は、フレーム解釈部１０２より、セッション鍵の伝達用以外のＣＡＮ−ＩＤと共にデータの通知を受けた場合には、受信したデータに応じてＥＣＵ毎に異なる機能に係る処理を行う。例えば、エンジン３１０に接続されたＥＣＵ１００ａは、時速が３０ｋｍを超えた状態でドアが開いている状態だと、アラーム音を鳴らす機能を備える。ＥＣＵ１００ａは、例えばアラーム音を鳴らすためのスピーカ等を有している。ＥＣＵ１００ａは、例えば、他のＥＣＵから受信したデータ（例えばドアの状態を示す情報）を管理し、エンジン３１０から取得された時速に基づいて一定条件下でアラーム音を鳴らす処理等を行う。
【００７２】
共有鍵保持部１０６は、ＥＣＵ１００ａが送信に用いるＣＡＮ−ＩＤに対応する共有鍵（つまりＥＣＵ１００ａに対応する共有鍵）と、その共有鍵の有効期限を示す情報を保持する。共有鍵保持部１０６が保持する共有鍵の一例を後に図１４を用いて説明する。
【００７３】
ＭＡＣ処理部１０７は、フレーム解釈部１０２より通知されるＣＡＮ−ＩＤと、データフィールドのＭＡＣ値を除く部分と、カウンタ保持部１０９で保持するＣＡＮ−ＩＤに対応する受信カウンタ値と、を結合した値に対し、セッション鍵保持部１０８で保持する、ＣＡＮ−ＩＤに対応するセッション鍵を用いて、ＭＡＣ値を計算し、データフィールドに含まれるＭＡＣ値との比較検証を行い、検証結果をフレーム解釈部１０２へと通知する。また、フレーム生成部１１０より通知されるＣＡＮ−ＩＤと、送信するデータフィールド用のデータの値と、カウンタ保持部１０９で保持するＣＡＮ−ＩＤに対応する送信カウンタ値とを結合した値（結合値）に対し、ＭＡＣ値を計算により導出した結果をフレーム生成部１１０へと通知する。ここではＭＡＣの計算方法として、ＡＥＳ−ＣＭＡＣ（非特許文献２）を採用し、上述した結合値に対し、所定のブロック分までパディングした値でＭＡＣ鍵（セッション鍵）を使って計算し、出てきた計算結果の先頭４ｂｙｔｅｓをＭＡＣ値とする。なお、ここでのＭＡＣ値のサイズ、計算方法は一例であり、これに限定するものではない。
【００７４】
セッション鍵保持部１０８は、フレームに係る暗号処理用のセッション鍵、つまりＭＡＣ処理部１０７がＭＡＣ値の計算に用いるセッション鍵を、ＥＣＵ１００ａが送信に用いるＣＡＮ−ＩＤに対応付けて保持する。セッション鍵保持部１０８は、復号処理部１０５から通知されたセッション鍵を保存する。
【００７５】
カウンタ保持部１０９は、ＭＡＣ値を計算するために必要となるカウンタ値を、ＣＡＮ−ＩＤ毎に、送信用、受信用、各１つずつ保持する。フレームを正常に送信した場合は送信カウンタ値を、フレームを正常に受信した場合は受信カウンタ値を、それぞれインクリメントする。
【００７６】
フレーム生成部１１０は、フレーム解釈部１０２から通知されたエラーフレーム送信の要求に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部１０１へ通知して送信させる。
【００７７】
また、フレーム生成部１１０は、データ取得部１１１より通知されたデータに基づいて定めたデータフィールドの値をＭＡＣ処理部１０７へ通知し、ＭＡＣ値の計算結果を受け取る。データ取得部１１１より通知されたデータに基づいて定めたデータフィールドの値と、ＭＡＣ処理部１０７より通知されたＭＡＣ値と、予め定められたＣＡＮ−ＩＤとによりデータフレームを構成し、データフレームをフレーム送受信部１０１へ通知して送信させる。
【００７８】
データ取得部１１１は、ＥＣＵにつながっている機器、センサ等の状態を示すデータを取得し、フレーム生成部１１０に通知する。
【００７９】
なお、ＥＣＵ１００ａは、共有鍵の有効期限の問い合わせ用のフレームを受信した場合においては、有効期限をデータとして含みＭＡＣを付加した有効期限通知用フレームをフレーム生成部１１０に生成させて送信する機能を有する。ＥＣＵ１００ａ及び他の各ＥＣＵは、ここで例示した以外の機能を備えていても良い。なお、ＥＣＵ１００ａ〜１００ｄのそれぞれが送信するフレームの内容については後に図１０〜図１３を用いて説明する。
【００８０】
［１．８  受信ＩＤリスト例２］
図８は、ＥＣＵ１００ａ及びＥＣＵ１００ｃのそれぞれにおいて保持される受信ＩＤリストの一例を示す図である。同図に例示する受信ＩＤリストは、ＣＡＮ−ＩＤの値が「１」、「３」等のいずれかであるＣＡＮ−ＩＤを含むフレームを選択的に受信して処理するために用いられる。図８では、省略しているが、ＥＣＵ１００ａ及びＥＣＵ１００ｃのそれぞれにおいて保持される受信ＩＤリストには他に、各ＥＣＵについてセッション鍵の伝達用に予め定められているＣＡＮ−ＩＤ、及び、マスタＥＣＵ４００からの共有鍵の有効期限の問い合わせ用に予め定められているＣＡＮ−ＩＤが含まれる。
【００８１】
［１．９  受信ＩＤリスト例３］
図９は、ＥＣＵ１００ｂ及びＥＣＵ１００ｄのそれぞれにおいて保持される受信ＩＤリストの一例を示す図である。同図に例示する受信ＩＤリストは、ＣＡＮ−ＩＤの値が「２」、「４」等のいずれかであるＣＡＮ−ＩＤを含むフレームを選択的に受信して処理するために用いられる。図９では、省略しているが、ＥＣＵ１００ｂ及びＥＣＵ１００ｄのそれぞれにおいて保持される受信ＩＤリストには他に、各ＥＣＵについてセッション鍵の伝達用に予め定められているＣＡＮ−ＩＤ、及び、マスタＥＣＵ４００からの共有鍵の有効期限の問い合わせ用に予め定められているＣＡＮ−ＩＤが含まれる。
【００８２】
［１．１０  エンジンに係るＥＣＵ１００ａの送信フレーム例］
図１０は、エンジン３１０に接続されたＥＣＵ１００ａから送信されるフレームにおけるＣＡＮ−ＩＤ及びデータフィールド（データ）の一例を示す図である。ＥＣＵ１００ａが時速について送信するフレームのＣＡＮ−ＩＤは「１」である。データフィールドの値は、先頭１ｂｙｔｅが時速を表し、次の１ｂｙｔｅがカウンタ（送信カウンタ値）を表し、次の４ｂｙｔｅｓがＭＡＣ値を表す。時速（ｋｍ／時）は、最低０（ｋｍ／時）〜最高１８０（ｋｍ／時）までの範囲の値を取る。図１０の上行から下行へと、ＥＣＵ１００ａから逐次送信される各フレームに対応する各ＣＡＮ−ＩＤ及びデータを例示しており、０ｋｍ／時から１ｋｍ／時ずつ加速されている様子を表している。
【００８３】
［１．１１  ブレーキに係るＥＣＵ１００ｂの送信フレーム例］
図１１は、ブレーキ３２０に接続されたＥＣＵ１００ｂから送信されるフレームにおけるＣＡＮ−ＩＤ及びデータフィールド（データ）の一例を示す図である。ＥＣＵ１００ｂがブレーキのかかり具合について送信するフレームのＣＡＮ−ＩＤは「２」である。データフィールドの値は、先頭１ｂｙｔｅがブレーキのかかり具合を表し、次の１ｂｙｔｅがカウンタ（送信カウンタ値）を表し、次の４ｂｙｔｅｓがＭＡＣ値を表す。ブレーキのかかり具合は、割合（％）で表し、ブレーキを全くかけていない状態を０（％）、ブレーキを最大限かけている状態を１００（％）としたものである。図１１の上行から下行へと、ＥＣＵ１００ｂから逐次送信される各フレームに対応する各ＣＡＮ−ＩＤ及びデータを例示しており、１００％から徐々にブレーキを弱めている様子を表している。
【００８４】
［１．１２  ドア開閉センサに係るＥＣＵ１００ｃの送信フレーム例］
図１２は、ドア開閉センサ３３０に接続されたＥＣＵ１００ｃから送信されるフレームにおけるＣＡＮ−ＩＤ及びデータフィールド（データ）の一例を示す図である。ＥＣＵ１００ｃがドアの開閉状態について送信するフレームのＣＡＮ−ＩＤは「３」である。データフィールドの値は、先頭の１Ｂｙｔｅがドアの開閉状態を表し、次の１ｂｙｔｅがカウンタ（送信カウンタ値）を表し、次の４ｂｙｔｅｓがＭＡＣ値を表す。ドアの開閉状態は、ドアが開いている状態が「１」、ドアが閉まっている状態が「０」である。図１２の上行から下行へと、ＥＣＵ１００ｃから逐次送信される各フレームに対応する各ＣＡＮ−ＩＤ及びデータを例示しており、ドアが開いている状態から次第に閉められた状態へと移った様子を表している。
【００８５】
［１．１３  窓開閉センサに係るＥＣＵ１００ｄの送信フレーム例］
図１３は、窓開閉センサ３４０に接続されたＥＣＵ１００ｄから送信されるフレームにおけるＣＡＮ−ＩＤ及びデータフィールド（データ）の一例を示す図である。ＥＣＵ１００ｄが窓の開閉状態について送信するフレームのＣＡＮ−ＩＤは「４」である。データフィールドの値は、先頭の１ｂｙｔｅが窓の開閉状態を表し、次の１ｂｙｔｅがカウンタ（送信カウンタ値）を表し、次の４ｂｙｔｅｓがＭＡＣ値を表す。窓の開閉状態は、割合（％）で表し、窓が完全に閉まっている状態を０（％）、窓が全開の状態を１００（％）としたものである。図１３の上行から下行へと、ＥＣＵ１００ｄから逐次送信される各フレームに対応する各ＣＡＮ−ＩＤ及びデータを例示しており、窓が閉まっている状態から徐々に開いていく様子を表している。
【００８６】
［１．１４  ＥＣＵ１００ａが保持する共有鍵］
図１４は、ＥＣＵ１００ａが保持する共有鍵と、その有効期限を示す情報の一例を示す図である。同図は、ＥＣＵ１００ａが送信するＣＡＮ−ＩＤ「１」に対して、「２０３４年１２月３１日」の有効期限をもつ、共有鍵「０ｘ１Ａ４ＤＥ４ＦＣ０２Ｆ６６Ｂ７７」が割り当てられていることを示す。この共有鍵は、マスタＥＣＵ４００から伝達されるセッション鍵の復号に用いられる。なお、共有鍵は、例えばＥＣＵの製造或いは販売段階等においてＥＣＵに設定され、例えば専用ツールを車載ネットワークシステム１０に接続することで、更新され得る。
【００８７】
［１．１５  セッション鍵配布シーケンス］
以下、マスタＥＣＵ４００がＥＣＵ１００ａにセッション鍵を伝達する動作について図１５を用いて説明する。
【００８８】
図１５は、マスタＥＣＵ４００とＥＣＵ１００ａとの間で行われるセッション鍵配布シーケンスの一例を示す図である。なお、マスタＥＣＵ４００は、ＥＣＵ１００ｂ〜１００ｄに対しても同様にセッション鍵を配布するが、ここではＣＡＮ−ＩＤ「１」のフレームを送信するＥＣＵであるＥＣＵ１００ａに注目して説明する。
【００８９】
まず、マスタＥＣＵ４００は、セッション鍵生成部４１１により、あるセッション鍵Ｋｓ１を生成する（ステップＳ１００１）。
【００９０】
次に、マスタＥＣＵ４００は、暗号処理部４０９により、セッション鍵Ｋｓ１を、ＣＡＮ−ＩＤ「１」に対応する共有鍵Ｋｍ（図５参照）を用いて暗号化することで、暗号化セッション鍵Ｋｓ１’を生成する（ステップＳ１００２）。
【００９１】
マスタＥＣＵ４００は、ＭＡＣ処理部４０６により、生成した暗号化セッション鍵Ｋｓ１’と、カウンタ（送信カウンタ値）とを用いて、ＭＡＣを生成する（ステップＳ１００３）。
【００９２】
マスタＥＣＵ４００は、ＣＡＮ−ＩＤ「１」に対応するＥＣＵ１００ａに対してのセッション鍵の伝達用に予め定められているＣＡＮ−ＩＤを付して、データフィールドに暗号化セッション鍵Ｋｓ１‘とＭＡＣ値とを含めたデータフレームを送信する（ステップＳ１００４）。これにより、バス２００上にデータフレームが現れる。
【００９３】
マスタＥＣＵ４００は、送信したフレームの確認のためにバス上を流れるデータフレームの受信を開始し（ステップＳ１００５）、バス上を流れるデータと、自身が送信するデータフレームの一致を確認し（ステップＳ１００６）、不一致の場合はエラーフレームを送信する（ステップＳ１００７）。
【００９４】
また、バス２００上にデータフレームが現れると、ＥＣＵ１００ａは、バス上を流れるデータフレームの受信を開始する（ステップＳ１００８）。
【００９５】
ＥＣＵ１００ａは、受信ＩＤ判断部１０３により、バス上を流れるデータフレームに含まれるＣＡＮ−ＩＤを受信して、受信ＩＤリスト保持部１０４が保持する受信ＩＤリストに記載されているＩＤかどうかをチェックする（ステップＳ１００９）。受信したＣＡＮ−ＩＤが、受信ＩＤリストに記載されていないＣＡＮ−ＩＤの場合には、受信中のデータフレームを破棄し、フレームの受信を終了する。なお、セッション鍵の伝達用に予め定められているＣＡＮ−ＩＤは受信ＩＤリストに記載されている。
【００９６】
ＥＣＵ１００ａは、ＭＡＣ処理部１０７により受信したデータフレームのデータフィールドより、ＭＡＣ値を抽出し、検証を行う（ステップＳ１０１０）。検証に失敗する場合は、受信中のデータフレームを破棄し、フレームの受信を終了する。
【００９７】
ＥＣＵ１００ａは、受信したデータフィールドより、暗号化セッション鍵Ｋｓ１‘を取得して、復号処理部１０５により、共有鍵保持部１０６が保持している共有鍵を用いて復号処理を行うことで、セッション鍵Ｋｓ１を抽出する（ステップＳ１０１１）。復号に失敗する場合は、受信したフレームについての処理を終了する。
【００９８】
ＥＣＵ１００ａは、抽出したセッション鍵Ｋｓ１をセッション鍵保持部１０８に保存する（ステップＳ１０１２）。ＥＣＵ１００ａは、このセッション鍵Ｋｓ１を、次回以降のデータフレームの送信又は受信に際して、ＭＡＣ値の生成或いは検証に使用する。
【００９９】
また、ＥＣＵ１００ｂ〜１００ｄは、それぞれがマスタＥＣＵ４００と共有する共有鍵を用いることで、ＥＣＵ１００ａと同様にマスタＥＣＵ４００からセッション鍵Ｋｓ１を得ることができる。
【０１００】
［１．１６  メッセージ認証シーケンス］
以下、ＥＣＵ１００ａとＥＣＵ１００ｃとの間におけるデータフレームの送信に係るメッセージ認証の動作について図１６を用いて説明する。
【０１０１】
図１６は、ＥＣＵ１００ａとＥＣＵ１００ｃとの間で行われるメッセージ認証シーケンスの一例を示す図である。なお、ここでは、ＥＣＵ１００ａと、ＥＣＵ１００ｃとの間でのメッセージ認証を示すが、他のＥＣＵ間、例えばＥＣＵ１００ｂとＥＣＵ１００ｄとの間、ＥＣＵ１００ａとマスタＥＣＵ４００との間等においても同様の動作が行われる。ＥＣＵ１００ｃは、ＥＣＵ１００ａと基本的に同様の構成を有するため、ＥＣＵ１００ｃの構成要素についてＥＣＵ１００ａの構成要素と同じ符号を用いて参照する（図７参照）。
【０１０２】
まず、ＥＣＵ１００ａは、フレーム生成部１１０により、送信するデータを生成する（ステップＳ１１０１）。
【０１０３】
次に、ＥＣＵ１００ａは、ＭＡＣ処理部１０７により、ステップＳ１１０１において生成したデータの値とカウンタ（送信カウンタ値）とに対応したＭＡＣを生成する（ステップＳ１１０２）。ＥＣＵ１００ａでは、このＭＡＣの生成において、セッション鍵保持部１０８に保持されたセッション鍵Ｋｓ１が用いられる。
【０１０４】
続いて、ＥＣＵ１００ａは、ＣＡＮ−ＩＤ「１」に対応する送信カウンタ値を１インクリメントする（ステップＳ１１０３）。
【０１０５】
そして、ＥＣＵ１００ａは、フレーム送受信部１０１により、ＣＡＮ−ＩＤ「１」を付して、データフィールドにデータの値とカウンタとＭＡＣとを含めたデータフレームを送信する（ステップＳ１１０４）。これにより、バス２００上にデータフレームが現れる。
【０１０６】
ＥＣＵ１００ａは、送信したフレームの確認のためにバス上を流れるデータフレームの受信を開始し（ステップＳ１１０５）、バス上を流れるデータと、自身が送信するデータフレームの一致を確認し（ステップＳ１１０６）、不一致の場合はエラーフレームを送信する（ステップＳ１１０７）。
【０１０７】
また、バス２００上にデータフレームが現れると、ＥＣＵ１００ｃは、バス上を流れるデータフレームの受信を開始する（ステップＳ１１０８）。
【０１０８】
ＥＣＵ１００ｃは、受信ＩＤ判断部１０３により、バス上を流れるデータフレームに含まれるＣＡＮ−ＩＤを受信して、受信ＩＤリスト保持部１０４が保持する受信ＩＤリスト（図８参照）に記載されているＩＤかどうかをチェックする（ステップＳ１１０９）。受信したＣＡＮ−ＩＤが、受信ＩＤリストに記載されていないＣＡＮ−ＩＤの場合には、受信中のデータフレームを破棄し、フレームの受信を終了する。
【０１０９】
ＥＣＵ１００ｃは、ＭＡＣ処理部１０７により受信したデータフレームのデータフィールドより、ＭＡＣ値を抽出し、検証を行う（ステップＳ１１１０）。検証に失敗する場合は、受信中のデータフレームを破棄し、フレームの受信を終了する。ＥＣＵ１００ｃでは、ステップＳ１１１０でのＭＡＣの検証において、セッション鍵保持部１０８に保持されたセッション鍵Ｋｓ１が用いられる。検証に成功した場合には、ＥＣＵ１００ｃは、ＣＡＮ−ＩＤ「１」に対応する受信カウンタ値を１インクリメントする（ステップＳ１１１１）。
【０１１０】
ＥＣＵ１００ｃは、ステップＳ１１１１に続いて、受信したデータフレームに応じた処理を行う（ステップＳ１１１２）。
【０１１１】
［１．１７  共有鍵検証シーケンス］
以下、マスタＥＣＵ４００が、共有鍵に関するセキュリティ状態を、有効期限の確認により、検査（検証）する動作について、図１７を用いて説明する。
【０１１２】
図１７は、マスタＥＣＵ４００と、ＥＣＵ１００ａと、ＥＣＵ１００ｂと、ＥＣＵ１００ｃと、ＥＣＵ１００ｄとによる共有鍵検証シーケンスの一例を示す。なお、この共有鍵検証シーケンスは、例えば車載ネットワークシステム１０を搭載する車両が特定状態（例えば走行前の停車状態）であるときにおいて実行される。具体的な一例としては、アクセサリ−オン（ＡＣＣ−ＯＮ）になった直後において実行される。
【０１１３】
マスタＥＣＵ４００は、各ＥＣＵがマスタＥＣＵ４００と共有して保持する共有鍵についての有効期限の問い合わせ用のフレームを送信する（ステップＳ１２０１）。これにより、バス２００上に、有効期限の問い合わせ用のフレームが現れる。
【０１１４】
バス２００から有効期限の問い合わせ用のフレームをＥＣＵ１００ａ〜１００ｄの各々が受信し、それぞれが保持する共有鍵の有効期限にＭＡＣを付したデータをデータフィールドに含む有効期限通知用フレームを送信する（ステップＳ１２０２）。即ち、ＥＣＵ１００ａ、ＥＣＵ１００ｂ、ＥＣＵ１００ｃ及びＥＣＵ１００ｄは、それぞれＣＡＮ−ＩＤ「１０１」、「１０２」、「１０３」、「１０４」を付した有効期限通知用フレームを送信する。これにより各有効期限通知用フレームが順次バス２００上に現れることになる。
【０１１５】
このバス２００上に順次現れる各有効期限通知用フレームに対してマスタＥＣＵ４００は、有効期限通知用フレームに含まれるＭＡＣ値を検証した上で有効期限通知用フレームに含まれる有効期限と現在時刻とを比較することにより、全てのＥＣＵから得られた共有鍵の有効期限のいずれも現在時刻より後であること（つまり全ての共有鍵が有効期限内であること）を確認する（ステップＳ１２０３）。マスタＥＣＵ４００は、有効期限内でない共有鍵があれば、有効期限が過ぎている旨を示す情報をログに記録して保存し（ステップＳ１２０４）、表示装置に有効期限が過ぎていることに関する情報（共有鍵の更新が必要なことを示す情報等）を表示することで運転者への報知を行う（ステップＳ１２０５）。なお、マスタＥＣＵ４００は、例えばいずれかの共有鍵の有効期限が過ぎている場合において、セッション鍵の伝達を行わないようにすることができる。
【０１１６】
［１．１８  実施の形態１の効果］
実施の形態１に係る車載ネットワークシステム１０では、車両が停車状態等の特定の状態である場合において、マスタＥＣＵ４００（言わば鍵管理装置としての第１種ＥＣＵ）が、各ＥＣＵ（第２種ＥＣＵ）が保持する共有鍵の有効期限を確認（検査）することで、セキュリティ上、各ＥＣＵが保持する共有鍵の漏洩のリスクが高まった状態であるか否か（共有鍵の更新が必要な状態か否か）を検査する。つまり、第１種ＥＣＵが、第２種ＥＣＵが保持する共有鍵についての有効期限を示す情報を含むフレームを受信して有効期限が既に経過しているか否かを判別することで共有鍵のセキュリティ状態を検査し、有効期限が経過していない場合には第２種ＥＣＵにセッション鍵を与えるための通信を行い、有効期限が経過している場合には報知等（表示装置への表示等）の制御を行う。各ＥＣＵ（第２種ＥＣＵ）が保持する共有鍵は、各ＥＣＵがマスタＥＣＵ（第１種ＥＣＵ）との間で共有するものであり、セッション鍵の伝達のために用いられる。そしてセッション鍵は、ＥＣＵ間でフレームを送受信する際における暗号処理（ＭＡＣ生成、検証等を含む処理）に鍵として用いられる。なお、この暗号処理は、暗号化、復号、署名、検証等の各種の変換処理を含み得る。従って、有効期限を用いて共有鍵のセキュリティ状態が確認される車載ネットワークシステム１０では、セキュリティ状態が不適切な場合（共有鍵の漏洩のリスクが高まった状態である場合）に、報知、ログへの記録等により安全性を確保でき、無効なセッション鍵の配布を防止し得る。なお、車両の走行中における各ＥＣＵの処理負荷の増大、バス２００のトラフィックの増大等を避けて、共有鍵のセキュリティ状態の検査をＡＣＣ−ＯＮの際といった車両の走行前の停車状態で行うことは有用である。
【０１１７】
［１．１９  実施の形態１の変形例］
以下、上述したマスタＥＣＵ４００を一部変形したマスタＥＣＵ（鍵管理装置）１４００を含む車載ネットワークシステム１０について説明する。
【０１１８】
マスタＥＣＵ１４００は、マスタＥＣＵ４００と基本的に同様であるが、各ＥＣＵが保持する共有鍵の有効期限の検証の方法が異なる。即ち、マスタＥＣＵ１４００は、各ＥＣＵが保持する共有鍵の有効期限を、車載ネットワークシステム１０の外部（車両の外部）のサーバと通信することで検証する機能を有する。
【０１１９】
［１．２０  マスタＥＣＵ１４００の構成］
図１８は、マスタＥＣＵ１４００の構成図である。マスタＥＣＵ１４００は、フレーム送受信部４０１と、フレーム解釈部４０２と、受信ＩＤ判断部４０３と、受信ＩＤリスト保持部４０４と、ＭＡＣ処理部４０６と、カウンタ保持部４０７と、セッション鍵リスト保持部４０８と、暗号処理部４０９と、共有鍵リスト保持部４１０と、セッション鍵生成部４１１と、フレーム生成部４１２と、サーバ通信部１４１２とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、マスタＥＣＵ１４００における通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。なお、マスタＥＣＵ１４００の構成要素のうちマスタＥＣＵ４００の構成要素（図３参照）と同一のものには、同一の符号を付し、説明を適宜省略する。
【０１２０】
フレーム解釈部４０２は、データフレームについてＭＡＣ処理部４０６でＭＡＣを検証した結果として検証に成功した場合に、そのデータフレームのＣＡＮ−ＩＤと、データフィールドの値とをサーバ通信部１４１２に通知する。
【０１２１】
サーバ通信部１４１２は、無線により外部のサーバと通信する機能を有する。サーバ通信部１４１２は、フレーム解釈部４０２より受信した全てのデータフレームのＣＡＮ−ＩＤと、データフィールドの値とを対応付けて、サーバに通知し、サーバでの判定結果を受信する。判定の結果、エラーが発生している場合は、例えば表示装置にエラー内容を表示させることで運転者への報知を行う。有効期限通知用フレームについて、サーバでの判定結果がエラーであれば、マスタＥＣＵ１４００は、各ＥＣＵへのセッション鍵の伝達を行わないようにすることができる。
【０１２２】
なお、外部のサーバは、マスタＥＣＵ４００と通信可能なコンピュータであり、有効期限通知用フレームについてのＣＡＮ−ＩＤとデータフィールドの値である有効期限を示す値とをマスタＥＣＵ４００から受信した場合においては、現在時刻或いは他の情報に基づいて有効期限が過ぎていないかを判断し、過ぎていなければ正常という判定結果、過ぎていればエラーという判定結果を、マスタＥＣＵ４００に送信する機能を有する。
【０１２３】
［１．２１  共有鍵検証シーケンス］
以下、マスタＥＣＵ１４００が、共有鍵に関するセキュリティ状態を、サーバとの通信により、検査する動作について、図１９を用いて説明する。
【０１２４】
図１９は、マスタＥＣＵ１４００と、ＥＣＵ１００ａと、ＥＣＵ１００ｂと、ＥＣＵ１００ｃと、ＥＣＵ１００ｄとによる共有鍵検証シーケンスの一例を示す。なお、この共有鍵検証シーケンスは、例えば車載ネットワークシステム１０を搭載する車両が特定状態（例えば走行前の停車状態）であるときにおいて実行される。具体的な一例としては、アクセサリ−オン（ＡＣＣ−ＯＮ）になった直後において実行される。なお、図１９において図１７で示した処理（ステップ）と同一の処理については同一の符号を付しており、ここでは説明を適宜省略する。
【０１２５】
ステップＳ１２０２において、ＥＣＵ１００ａ、ＥＣＵ１００ｂ、ＥＣＵ１００ｃ及びＥＣＵ１００ｄのそれぞれが送信した有効期限通知用フレームが順次バス２００上に現れることになる。
【０１２６】
このバス２００上に順次現れる各有効期限通知用フレームに対してマスタＥＣＵ１４００は、有効期限通知用フレームのＣＡＮ−ＩＤと有効期限通知用フレームに含まれる有効期限とをサーバに送信する。そして、サーバから返信される判定結果が正常か否かによって、共有鍵の有効期限が過ぎていないかを確認する（ステップＳ１３０３）。マスタＥＣＵ１４００は、サーバによる判定結果がエラーである場合、つまり共有鍵の有効期限が過ぎている場合には、表示装置に有効期限が過ぎていることに関する情報（共有鍵の更新が必要なことを示す情報等）を表示することで運転者への報知を行う（ステップＳ１３０４）。なお、マスタＥＣＵ１４００は、例えばいずれかの共有鍵の有効期限が過ぎている場合において、セッション鍵の伝達を行わないようにすることができる。
【０１２７】
［１．２２  実施の形態１の変形例の効果］
実施の形態１の変形例に係る車載ネットワークシステム１０では、車両が停車状態等の特定の状態である場合において、マスタＥＣＵ４００が外部のサーバと通信することにより、各ＥＣＵが保持する共有鍵の有効期限をサーバで判定させることで、共有鍵のセキュリティ状態が適切か否か、つまり各ＥＣＵが保持する共有鍵の漏洩のリスクが高まった状態であるか否か（共有鍵の更新が必要な状態か否か）を検証する。そして、セキュリティ状態が不適切な場合に、報知等により安全性を確保でき、無効なセッション鍵の配布を防止し得る。また、外部のサーバは、複数の車両それぞれに搭載された車載ネットワークシステム１０におけるマスタＥＣＵ４００から各ＥＣＵの共有鍵の有効期限の情報を収集して整合性等を確認し得るため、より適切に共有鍵のセキュリティ状態を判定し得る。
【０１２８】
（実施の形態２）
以下、本発明の実施の形態として、ＣＡＮ−ＩＤと、ＥＣＵ毎のシリアルＩＤとを対応付けた情報である共有鍵リストを保存しておき、共有鍵リストに基づいて、共有鍵のセキュリティ状態を検査するマスタＥＣＵ（鍵管理装置）２０４００を含む車載ネットワークシステムについて説明する。本実施の形態に係る車載ネットワークシステムは、実施の形態１で示した車載ネットワークシステム１０（図１参照）のマスタＥＣＵ４００をマスタＥＣＵ２０４００（後述）に置き換えたものである。また、本実施の形態に係る車載ネットワークシステムは、実施の形態１で示した車載ネットワークシステム１０におけるＥＣＵ１００ａの代わりに、ＥＣＵに固有なシリアルＩＤを保持してそのシリアルＩＤを通知するためのシリアルＩＤ通知用フレームを送信する機能を有するＥＣＵ２０１００ａ（後述）を備える。また、本実施の形態に係る車載ネットワークシステムは、ＥＣＵ１００ｂ〜１００ｄそれぞれの代わりに、ＥＣＵ２０１００ａと同様の機能を有するＥＣＵ２０１００ｂ〜２０１００ｄを備える。
【０１２９】
［２．１  マスタＥＣＵ２０４００の構成］
マスタＥＣＵ２０４００は、マスタＥＣＵ４００と同様に、鍵管理装置としての一種のＥＣＵであり、バス２００に接続されている。マスタＥＣＵ２０４００は、バス２００に接続されている複数のＥＣＵのうち自装置以外の１以上のＥＣＵそれぞれとの相互間で共有する、フレームに係る暗号処理（ＭＡＣ処理を含む）用のセッション鍵の伝達に用いるための、共有鍵を保持し、共有鍵のセキュリティ状態を管理する機能を有する。
【０１３０】
図２０は、マスタＥＣＵ２０４００の構成図である。同図に示すようにマスタＥＣＵ２０４００は、フレーム送受信部４０１と、フレーム解釈部４０２と、受信ＩＤ判断部４０３と、受信ＩＤリスト保持部４０４と、ＭＡＣ処理部４０６と、カウンタ保持部４０７と、セッション鍵リスト保持部４０８と、暗号処理部４０９と、共有鍵リスト保持部２０４１０と、セッション鍵生成部４１１と、フレーム生成部４１２と、リスト確認部２０４２１とを含んで構成される。なお、実施の形態１で示した構成要素と同一のものには同じ符号を付しており、これらについては説明を適宜省略する。
【０１３１】
共有鍵リスト保持部２０４１０は、セッション鍵のＥＣＵ間での伝達に用いるために事前に共有される共有鍵を各ＣＡＮ−ＩＤに対応付け、更にＥＣＵ毎のシリアルＩＤに対応付けたリストである共有鍵リストを保持する。ＣＡＮ−ＩＤ毎に、そのＣＡＮ−ＩＤを付したフレームを送信する１台のＥＣＵのシリアルＩＤと、対応する１つの共有鍵とを定める。なお、ＣＡＮ−ＩＤ毎に共有鍵を定める他、全ＥＣＵ或いは複数のＥＣＵに対して１つの共有鍵を定めることとしても良い。この場合には、１つの共有鍵に対して複数のシリアルＩＤが対応することになる。また、バス２００が、複数のサブネットをゲートウェイで接続して構成される場合において、サブネット毎（１つのサブネットに接続されるＥＣＵの集合毎）に１つの共有鍵を定めても良い。図２１に、共有鍵リスト保持部２０４１０が保持する共有鍵リストの一例を示す。
【０１３２】
フレーム解釈部４０２は、データフレームについてＭＡＣ処理部４０６でＭＡＣを検証した結果として検証に成功した場合に、そのデータフレームのＣＡＮ−ＩＤと、データフィールドの値とをリスト確認部２０４２１に通知する。
【０１３３】
リスト確認部２０４２１は、フレーム解釈部４０２より、ＣＡＮ−ＩＤで特定されるシリアルＩＤ通知用フレームについて、データフィールドの値である、フレームの送信元のＥＣＵに固有のシリアルＩＤを示す値を取得し、共有鍵リスト保持部４１０が保持する共有鍵リストのシリアルＩＤと比較して、一致するか否かを判断する。リスト確認部２０４２１は、両シリアルＩＤが一致しない場合には、ログに記録する等のエラー処理を行う。エラー処理の他の例としては、ログに記録する他に、表示装置にエラーに関する情報を表示することで運転者への報知を行うこと、各ＥＣＵへのセッション鍵の伝達を行わないようにすること等が挙げられる。
【０１３４】
なお、受信ＩＤリスト保持部４０４が保持する受信ＩＤリストには、実施の形態１で示した有効期限通知用フレームのＣＡＮ−ＩＤ「１０１」、「１０２」、「１０３」及び「１０４」の代わりにＥＣＵ２０１００ａ〜２０１００ｄが送信するシリアルＩＤ通知用フレームのＣＡＮ−ＩＤ「２０１」、「２０２」、「２０３」及び「２０４」が記載されている。ここで説明に用いるＣＡＮ−ＩＤの例では、各ＥＣＵが送信するシリアルＩＤ通知用フレームのＣＡＮ−ＩＤ「２０１」、「２０２」、「２０３」或いは「２０４」は、そのＥＣＵが基本的に送信するデータフレームのＣＡＮ−ＩＤ「１」、「２」、「３」或いは「４」に対して、一定値を加算した値となっている。
【０１３５】
［２．２  共有鍵リスト例］
図２１は、マスタＥＣＵ２０４００が、共有鍵リスト保持部２０４１０において保持する共有鍵リストの一例を示す図である。共有鍵リストは、ＣＡＮ−ＩＤと共有鍵（Ｋｍ）とシリアルＩＤとを対応付けたリストである。シリアルＩＤは、各ＥＣＵに固有のＩＤである。例えばＥＣＵの製造者等が、各ＥＣＵに別個のシリアルＩＤを付している。図２１に例示する共有鍵リストは、ＣＡＮ−ＩＤ「１」に対して、共有鍵「０ｘ１Ａ４ＤＥ４ＦＣ０２Ｆ６６Ｂ７７」とシリアルＩＤ「０ｘ１００００００１」とが、ＣＡＮ−ＩＤ「２」に対して、共有鍵「０ｘ２７ＡＢ６ＥＡＣ８１７７３Ｆ６５」とシリアルＩＤ「０ｘ１００００００２」とが、ＣＡＮ−ＩＤ「３」に対して、共有鍵「０ｘＣＢ９３９ＥＡ０ＣＥ３７８Ａ７Ｅ」とシリアルＩＤ「０ｘ１００００００３」とが、ＣＡＮ−ＩＤ「４」に対して、共有鍵「０ｘ０３Ｅ４６ＦＦ２８ＣＢＣ８Ｄ７Ａ」とシリアルＩＤ「０ｘ１００００００４」とが、それぞれ割り当てられていることを示す。
【０１３６】
［２．３  ＥＣＵ２０１００ａの構成］
図２２は、ＥＣＵ２０１００ａの構成図である。ＥＣＵ２０１００ａは、フレーム送受信部１０１と、フレーム解釈部１０２と、受信ＩＤ判断部１０３と、受信ＩＤリスト保持部１０４と、復号処理部１０５と、共有鍵保持部１０６と、ＭＡＣ処理部１０７と、セッション鍵保持部１０８と、カウンタ保持部１０９と、フレーム生成部１１０と、データ取得部１１１と、シリアルＩＤ保持部２０１２１とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、ＥＣＵ２０１００ａにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。なお、ＥＣＵ２０１００ｂ〜２０１００ｄも、ＥＣＵ２０１００ａと同様の構成を備える。なお、ＥＣＵ２０１００ａの構成要素のうちＥＣＵ１００ａ（図７参照）と同一の構成要素については、同一の符号を付しており、ここでの説明を省略する。
【０１３７】
シリアルＩＤ保持部２０１２１は、ＥＣＵ２０１００ａに固有なＩＤであるシリアルＩＤを保持する。
【０１３８】
フレーム生成部１１０は、シリアルＩＤ通知用フレームを生成する際には、シリアルＩＤ保持部２０１２１が保持するシリアルＩＤを取得する。フレーム生成部１１０は、データフィールドに取得したシリアルＩＤと、そのシリアルＩＤに対応してＭＡＣ処理部１０７で生成されたＭＡＣ値とを含めたシリアルＩＤ通知用フレームを生成する。
【０１３９】
ＥＣＵ２０１００ａは、マスタＥＣＵ２０４００からのシリアルＩＤの問い合わせ用のフレームを受信した場合においては、シリアルＩＤ通知用フレームをフレーム生成部１１０に生成させて送信する機能を有する。
【０１４０】
［２．４  共有鍵検証シーケンス］
以下、マスタＥＣＵ２０４００が、共有鍵に関するセキュリティ状態を、シリアルＩＤの確認により、検査する動作について、図２３を用いて説明する。
【０１４１】
図２３は、マスタＥＣＵ２０４００と、ＥＣＵ２０１００ａと、ＥＣＵ２０１００ｂと、ＥＣＵ２０１００ｃと、ＥＣＵ２０１００ｄとによる共有鍵検証シーケンスの一例を示す。なお、この共有鍵検証シーケンスは、例えば車載ネットワークシステム１０を搭載する車両が特定状態（例えば走行前の停車状態）であるときにおいて実行される。具体的な一例としては、アクセサリ−オン（ＡＣＣ−ＯＮ）になった直後において実行される。
【０１４２】
マスタＥＣＵ２０４００は、各ＥＣＵが有するシリアルＩＤの問い合わせ用のフレームを送信する（ステップＳ２１０１）。これにより、バス２００上に、シリアルＩＤの問い合わせ用のフレームが現れる。
【０１４３】
バス２００からシリアルＩＤの問い合わせ用のフレームをＥＣＵ２０１００ａ〜２０１００ｄの各々が受信し、それぞれが保持するシリアルＩＤにＭＡＣを付したデータをデータフィールドに含むシリアルＩＤ通知用フレームを送信する（ステップＳ２１０２）。即ち、ＥＣＵ２０１００ａ、ＥＣＵ２０１００ｂ、ＥＣＵ２０１００ｃ及びＥＣＵ２０１００ｄは、それぞれＣＡＮ−ＩＤ「２０１」、「２０２」、「２０３」、「２０４」を付したシリアルＩＤ通知用フレームを送信する。これにより各シリアルＩＤ通知用フレームが順次バス２００上に現れることになる。
【０１４４】
このバス２００上に順次現れる各シリアルＩＤ通知用フレームに対してマスタＥＣＵ２０４００は、シリアルＩＤ通知用フレームに含まれるＭＡＣ値を検証した上で、シリアルＩＤ通知用フレームに含まれるシリアルＩＤと共有鍵リスト保持部２０４１０に保持する共有鍵リストにおけるシリアルＩＤとを照合することで、共有鍵とシリアルＩＤとの対応関係が変更されていないかについて判定を行う（ステップＳ２１０３）。具体的には、例えば、シリアルＩＤ通知用フレームのＣＡＮ−ＩＤが「２０１」である場合においては、その「２０１」に対応して一定値の減算等により特定されるＣＡＮ−ＩＤ「１」と、共有鍵リストにおいて対応するシリアルＩＤを特定し、そのシリアルＩＤとシリアルＩＤ通知用フレームに含まれるシリアルＩＤとを比較して、両シリアルＩＤが一致すれば正常（共有鍵とシリアルＩＤとの対応関係が変更されていない）と判定し、一致しなければエラーと判定する。
【０１４５】
マスタＥＣＵ２０４００は、ステップＳ２１０３における判定の結果が正常でない場合には、エラーを通知するメッセージ（フレーム）を送信する（ステップＳ２１０４）。エラーを通知するメッセージがバス２００上に流れるとそれを特定のＥＣＵが受信して、その特定のＥＣＵが、エラーの報知（エラーを示す音の発生、エラー表示、エラーランプの点灯等）を行う。なお、マスタＥＣＵ２０４００は、メッセージを送信してエラーに対する処理を他のＥＣＵに委ねる他、エラーを表示装置に表示しても良いし、エラーに関する情報をログに記録して保存しても良いし、外部のサーバにエラーを通知しても良い。また、マスタＥＣＵ２０４００は、エラーと判定した場合に、セッション鍵の伝達を行わないようにすることができる。
【０１４６】
［２．５  実施の形態２の効果］
実施の形態２に係る車載ネットワークシステムでは、車両が停車状態等の特定の状態である場合において、マスタＥＣＵ２０４００（言わば鍵管理装置としての第１種ＥＣＵ）が、各ＥＣＵ（第２種ＥＣＵ）が保持するシリアルＩＤを確認（検査）することで、共有鍵を不正にコピーしたＥＣＵ等が追加されていないことを確認できる。従って、シリアルＩＤの確認により、共有鍵のセキュリティ状態が検証でき、つまり各ＥＣＵが保持する共有鍵の漏洩のリスクが高まった状態であるか否かが確認できる。つまり、第１種ＥＣＵが、第２種ＥＣＵから、シリアルＩＤを示す情報を含むフレームを受信して、そのシリアルＩＤ及び予め保持する所定の照合用情報（例えば共有鍵リスト）に基づいて、共有鍵のセキュリティ状態が適切であるか否かを判別することでセキュリティ状態の検査を行い、共有鍵のセキュリティ状態が適切である場合には第２種ＥＣＵにセッション鍵を与えるための通信を行い、セキュリティ状態が適切でない場合には報知等のための制御を実行することで安全性を確保できる。なお、車両の走行中における各ＥＣＵの処理負荷の増大、バス２００のトラフィックの増大等を避けて、共有鍵のセキュリティ状態の検査をＡＣＣ−ＯＮの際といった車両の走行前の停車状態で行うことは有用である。また、第１種ＥＣＵが第２種ＥＣＵから受信したシリアルＩＤ及び照合用情報（共有鍵リスト等）に基づいて共有鍵のセキュリティ状態が適切か否かの区別をする方法として、シリアルＩＤを直接照合用情報と比較して一致するか否かを判別しても良いし、シリアルＩＤに予め定めた演算を施した結果と照合用情報とを比較しても良い。
【０１４７】
［２．６  実施の形態２の変形例］
以下、上述したマスタＥＣＵ２０４００を一部変形したマスタＥＣＵ（鍵管理装置）２１４００を含む車載ネットワークシステムについて説明する。
【０１４８】
マスタＥＣＵ２１４００は、マスタＥＣＵ２０４００と基本的に同様であるが、各ＥＣＵが保持するシリアルＩＤについての検証の方法が異なる。即ち、マスタＥＣＵ２１４００は、各ＥＣＵが保持するシリアルＩＤを、車載ネットワークシステムの外部（車両の外部）のサーバと通信することで検証する機能を有する。このサーバは、ＣＡＮ−ＩＤと、ＥＣＵ毎のシリアルＩＤとの対応を示す情報を管理するコンピュータである。
【０１４９】
［２．７  マスタＥＣＵ２１４００の構成］
図２４は、マスタＥＣＵ２１４００の構成図である。マスタＥＣＵ２１４００は、フレーム送受信部４０１と、フレーム解釈部４０２と、受信ＩＤ判断部４０３と、受信ＩＤリスト保持部４０４と、ＭＡＣ処理部４０６と、カウンタ保持部４０７と、セッション鍵リスト保持部４０８と、暗号処理部４０９と、共有鍵リスト保持部２０４１０と、セッション鍵生成部４１１と、フレーム生成部４１２と、サーバ通信部２１４１２とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、マスタＥＣＵ２１４００における通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。なお、マスタＥＣＵ２１４００の構成要素のうちマスタＥＣＵ４００或いはマスタＥＣＵ２０４００の構成要素（図３、図２０参照）と同一のものには、同一の符号を付し、説明を適宜省略する。
【０１５０】
フレーム解釈部４０２は、データフレームについてＭＡＣ処理部４０６でＭＡＣを検証した結果として検証に成功した場合に、そのデータフレームのＣＡＮ−ＩＤと、データフィールドの値とをサーバ通信部２１４１２に通知する。
【０１５１】
サーバ通信部２１４１２は、無線により外部のサーバと通信する機能を有する。サーバ通信部２１４１２は、フレーム解釈部４０２より受信した全てのデータフレームのＣＡＮ−ＩＤと、データフィールドの値とを対応付けて、サーバに通知し、サーバでの判定結果を受信する。判定の結果、エラーが発生している場合は、例えば表示装置にエラー内容を表示させることで運転者への報知を行う。シリアルＩＤ通知用フレームについて、サーバでの判定結果がエラーであれば、マスタＥＣＵ２１４００は、各ＥＣＵへのセッション鍵の伝達を行わないようにすることができる。
【０１５２】
なお、サーバは、マスタＥＣＵ２１４００と通信可能なコンピュータであり、シリアルＩＤ通知用フレームについてのＣＡＮ−ＩＤとデータフィールドの値であるシリアルＩＤを示す値とをマスタＥＣＵ２１４００から受信した場合においては、送信元のＥＣＵ毎に予め定められているそのＣＡＮ−ＩＤからＥＣＵを特定して、そのＥＣＵと対応付けて管理しているシリアルＩＤと、受信したシリアルＩＤとが一致するか否かを確認することで、一致すれば正常、一致しなければエラーという判定結果を、マスタＥＣＵ２１４００に送信する機能を有する。
【０１５３】
［２．８  共有鍵検証シーケンス］
以下、マスタＥＣＵ２１４００が、共有鍵に関するセキュリティ状態を、サーバとの通信により、検査する動作について、図２５を用いて説明する。
【０１５４】
図２５は、マスタＥＣＵ２１４００と、ＥＣＵ２０１００ａと、ＥＣＵ２０１００ｂと、ＥＣＵ２０１００ｃと、ＥＣＵ２０１００ｄとによる共有鍵検証シーケンスの一例を示す。なお、この共有鍵検証シーケンスは、例えば車載ネットワークシステムを搭載する車両が特定状態（例えば走行前の停車状態）であるときにおいて実行される。具体的な一例としては、アクセサリ−オン（ＡＣＣ−ＯＮ）になった直後において実行される。なお、図２５において図２３で示した処理（ステップ）と同一の処理については同一の符号を付しており、ここでは説明を適宜省略する。
【０１５５】
ステップＳ２１０２において、ＥＣＵ２０１００ａ、ＥＣＵ２０１００ｂ、ＥＣＵ２０１００ｃ及びＥＣＵ２０１００ｄのそれぞれが送信したシリアルＩＤ通知用フレームが順次バス２００上に現れることになる。
【０１５６】
このバス２００上に順次現れる各シリアルＩＤ通知用フレームに対してマスタＥＣＵ２１４００は、シリアルＩＤ通知用フレームのＣＡＮ−ＩＤと、シリアルＩＤ通知用フレームに含まれるシリアルＩＤとをサーバに送信する。そして、サーバから返信される判定結果が正常か否かによって、共有鍵のセキュリティ状態が適切か否かを検査する（ステップＳ２２０３）。マスタＥＣＵ２１４００は、サーバによる判定結果がエラーである場合、つまり、シリアルＩＤが一致しないため共有鍵のセキュリティ状態が不適切である場合には、表示装置にエラーを示す情報（例えば不正なＥＣＵが存在することを示す情報等）を表示することで運転者への報知を行う（ステップＳ２２０４）。
【０１５７】
［２．９  実施の形態２の変形例の効果］
実施の形態２の変形例に係る車載ネットワークシステムでは、車両が停車状態等の特定の状態である場合において、マスタＥＣＵ２１４００が外部のサーバと通信することにより、各ＥＣＵが保持するシリアルＩＤが適切か否かをサーバで判定させることで、共有鍵のセキュリティ状態が適切か否かを検査する。共有鍵を不正にコピーした不正なＥＣＵが車載ネットワークシステムに接続されている場合のように、サーバが管理しているＥＣＵとシリアルＩＤとの対応関係とは異なるように車載ネットワークシステムの構成が変更されていれば、サーバによりエラーと判定されることになる。そして、セキュリティ状態が不適切な場合に、報知等により安全性を確保できる。また、外部のサーバは、複数の車両それぞれに搭載された車載ネットワークシステムにおけるマスタＥＣＵ２１４００から各ＥＣＵのシリアルＩＤの情報を収集して整合性等を確認し得るため、より適切に共有鍵のセキュリティ状態を検査し得る。
【０１５８】
（実施の形態３）
以下、本発明の実施の形態として、生存確認フレームに対する各ＥＣＵからのレスポンスの順序を確認することで共有鍵のセキュリティ状態を検査するマスタＥＣＵ（鍵管理装置）３０４００を含む車載ネットワークシステムについて説明する。本実施の形態に係る車載ネットワークシステムは、実施の形態１で示した車載ネットワークシステム１０（図１参照）のマスタＥＣＵ４００をマスタＥＣＵ３０４００に置き換え、ＥＣＵ１００ａ〜１００ｄを実施の形態２で示したＥＣＵ２０１００ａ〜２０１００ｄに置き換えたものである。
【０１５９】
［３．１  マスタＥＣＵ３０４００の構成］
マスタＥＣＵ３０４００は、マスタＥＣＵ４００と同様に、鍵管理装置としての一種のＥＣＵであり、バス２００に接続されている。マスタＥＣＵ３０４００は、バス２００に接続されている複数のＥＣＵのうち自装置以外の１以上のＥＣＵそれぞれとの相互間で共有する、フレームに係る暗号処理（ＭＡＣ処理を含む）用のセッション鍵の伝達に用いるための、共有鍵を保持し、共有鍵のセキュリティ状態を管理する機能を有する。マスタＥＣＵ３０４００は、各ＥＣＵに情報の送信（レスポンス）を要求するための生存確認フレームを送信して、各ＥＣＵのレスポンスを受信した順序を記憶し、車両の状態に応じて、レスポンスを受信した順序を比較することで、共有鍵のセキュリティ状態を検査する。ここでは、生存確認フレームへのレスポンスとしての各ＥＣＵからの情報の送信の一例として、シリアルＩＤを含むシリアルＩＤ通知用フレームを送信する例を用いて説明を行う。
【０１６０】
図２６は、マスタＥＣＵ３０４００の構成図である。同図に示すようにマスタＥＣＵ３０４００は、フレーム送受信部４０１と、フレーム解釈部４０２と、受信ＩＤ判断部４０３と、受信ＩＤリスト保持部４０４と、ＭＡＣ処理部４０６と、カウンタ保持部４０７と、セッション鍵リスト保持部４０８と、暗号処理部４０９と、共有鍵リスト保持部２０４１０と、セッション鍵生成部４１１と、フレーム生成部４１２と、シーケンス検証部３０４３１と、シーケンス記録部３０４３２とを含んで構成される。なお、実施の形態１、２で示した構成要素と同一のものには同じ符号を付しており、これらについては説明を適宜省略する。
【０１６１】
受信ＩＤリスト保持部４０４が保持する受信ＩＤリストは、実施の形態２で示したように各ＥＣＵのシリアルＩＤ通知用フレームのＣＡＮ−ＩＤ等を含んでいる。
【０１６２】
フレーム解釈部４０２は、データフレームについてＭＡＣ処理部４０６でＭＡＣを検証した結果として検証に成功した場合に、そのデータフレームのＣＡＮ−ＩＤと、データフィールドの値とをシーケンス検証部３０４３１に通知する。
【０１６３】
シーケンス検証部３０４３１は、１回の生存確認フレームへのレスポンスとして受信した、ＣＡＮ−ＩＤで特定されるシリアルＩＤ通知用フレームについてのＣＡＮ−ＩＤとデータフィールドの値との組をフレーム解釈部４０２より取得し、取得した順に各組をシーケンス記録部３０４３２に通知することでシーケンス記録リストとして記録させる。また、シーケンス検証部３０４３１は、シーケンス記録部３０４３２より、前回記録されたＣＡＮ−ＩＤとデータフィールドの値との組が順序付けられたシーケンス記録リストを読み出し、フレーム解釈部４０２より取得した各組の順序と一致するか否かを確認する。シーケンス検証部３０４３１は、前回と今回との生存確認フレームへのレスポンスとしての各ＥＣＵからのシリアルＩＤ通知用フレームの受信順序が一致しない場合には、表示装置にエラーを示す表示を行う等のエラー処理を行う。エラー処理の他の例としては、エラーの表示の他に、ログを記録すること、各ＥＣＵへのセッション鍵の伝達を行わないようにすること等が挙げられる。なお、シーケンス検証部３０４３１において更に、例えば実施の形態２で示したリスト確認部２０４２１のように、共有鍵リスト保持部２０４１０に保持された共有鍵リストに基づいてシリアルＩＤを確認しても良い。
【０１６４】
シーケンス記録部３０４３２は、通知された順にＣＡＮ−ＩＤとデータフィールドの値との組をシーケンス記録リストとして記録する。なお、ＣＡＮ−ＩＤだけを順序（順番）と対応付けて記録しても良い。この場合には、シーケンス検証部３０４３１は、受信されたＣＡＮ−ＩＤを順にシーケンス記録部３０４３２に通知することで記録させ、前回記録されたＣＡＮ−ＩＤの順序と、今回受信されたＣＡＮ−ＩＤの順序とが一致するか否かを確認する。
【０１６５】
［３．２  シーケンス記録リストの一例］
図２７に、シーケンス記録リストの一例を示す。同図の例は、例えば前回の生存確認フレームへのレスポンスとして、ＣＡＮ−ＩＤ「２０１」、「２０２」、「２０３」、「２０４」の順番でシリアルＩＤ通知用フレームが送信されたことを示す。
【０１６６】
［３．３  共有鍵検証シーケンス］
以下、マスタＥＣＵ３０４００が、共有鍵に関するセキュリティ状態を、生存確認フレームへの各ＥＣＵによるレスポンスの順序の確認により、検査する動作について、図２８を用いて説明する。
【０１６７】
図２８は、マスタＥＣＵ３０４００と、ＥＣＵ２０１００ａと、ＥＣＵ２０１００ｂと、ＥＣＵ２０１００ｃと、ＥＣＵ２０１００ｄとによる共有鍵検証シーケンスの一例を示す。なお、この共有鍵検証シーケンスは、例えば車載ネットワークシステムを搭載する車両が特定状態（例えば走行前の停車状態）であるときにおいて実行される。具体的な一例としては、アクセサリ−オン（ＡＣＣ−ＯＮ）になった直後及びアクセサリ−オフ（ＡＣＣ−ＯＦＦ）になった直後において実行される。
【０１６８】
マスタＥＣＵ３０４００は、各ＥＣＵに対して生存確認フレームを送信する（ステップＳ３１０１）。これにより、バス２００上に、生存確認フレームが現れる。
【０１６９】
バス２００から生存確認フレームをＥＣＵ２０１００ａ〜２０１００ｄの各々が受信し、それぞれが保持するシリアルＩＤにＭＡＣを付したデータをデータフィールドに含むシリアルＩＤ通知用フレームを送信する（ステップＳ３１０２）。なお、各ＥＣＵは、生存確認フレームを受信した後に、各ＥＣＵに固有の待機時間を待機してから生存確認フレームへのレスポンスとしてのシリアルＩＤ通知用フレームを送信する。図２８の例では、ＥＣＵ２０１００ａ、ＥＣＵ２０１００ｂ、ＥＣＵ２０１００ｃ及びＥＣＵ２０１００ｄは、この順に、それぞれＣＡＮ−ＩＤ「２０１」、「２０２」、「２０３」、「２０４」を付したシリアルＩＤ通知用フレームを送信する。これにより各シリアルＩＤ通知用フレームが順次バス２００上に現れることになる。
【０１７０】
このバス２００上に順次現れる各シリアルＩＤ通知用フレームに対してマスタＥＣＵ３０４００は、シリアルＩＤ通知用フレームのＣＡＮ−ＩＤを受信順にシーケンス記録リストとして記録する（ステップＳ３１０３）。そして、マスタＥＣＵ３０４００は、生存確認フレームを前回送信した際に得られたレスポンスに係るＣＡＮ−ＩＤの受信順の記録（前回記録したシーケンス記録リスト）に基づいて、その前回の受信順と今回のレスポンスであるＣＡＮ−ＩＤの受信順とを比較し、受信順が前回と同一か否かを判別する（ステップＳ３１０４）。同一でなければ、エラーを表示装置に表示する（ステップＳ３１０５）。なお、ステップＳ３１０４においてマスタＥＣＵ３０４００は、受信順のみならず、更に受信したＣＡＮ−ＩＤとデータフィールドから取得したシリアルＩＤとの組が前回と同一か否かを判別しても良い。ステップＳ３１０５では、エラーを表示装置に表示する他、エラーのログへの記録、外部のサーバへの通知、エラーを通知するメッセージ（フレーム）の送信等を行っても良い。エラーを通知するメッセージがバス２００上に流れるとそれを特定のＥＣＵが受信して、その特定のＥＣＵが、エラーの報知（エラーを示す音の発生、エラー表示、エラーランプの点灯等）を行うこととしても良い。
【０１７１】
［３．４  実施の形態３の効果］
実施の形態３に係る車載ネットワークシステムでは、車両が停車状態等の特定の状態である場合において、マスタＥＣＵ３０４００（言わば鍵管理装置としての第１種ＥＣＵ）から、ＥＣＵ２０１００ａ、ＥＣＵ２０１００ｂ、ＥＣＵ２０１００ｃ及びＥＣＵ２０１００ｄ（各第２種ＥＣＵ）に対して、要求としての生存確認フレームを送信し、この要求に対応するレスポンス（シリアルＩＤ通知用フレーム）がバス２００に現れる順序を確認することで、車載ネットワークシステムの構成が変更されていないかを確認できる。つまり、第１種ＥＣＵが、所定要求を示すフレーム（例えば生存確認フレーム）を送信した後に複数の第２種ＥＣＵから逐次受信した各フレームのＣＡＮ−ＩＤに基づいて、所定順序リスト（例えば前回記録したシーケンス記録リスト）が示す順序で各ＣＡＮ−ＩＤが受信されたか否かを判別することで、レスポンスの順序の確認（検査）を行う。従って、レスポンスの順序の確認により、共有鍵のセキュリティ状態が検査（検証）でき、セキュリティ状態が不適切な場合に報知等により安全性を確保できる。なお、車両の走行中における各ＥＣＵの処理負荷の増大、バス２００のトラフィックの増大等を避けて、共有鍵のセキュリティ状態の検査をＡＣＣ−ＯＮ及びＡＣＣ−ＯＦＦの際といった車両の停車状態において行うことは有用である。
【０１７２】
［３．５  実施の形態３の変形例］
以下、上述したマスタＥＣＵ３０４００を一部変形したマスタＥＣＵ（鍵管理装置）３１４００を含む車載ネットワークシステムについて説明する。
【０１７３】
マスタＥＣＵ３１４００は、マスタＥＣＵ３０４００と基本的に同様であるが、要求としての生存確認フレームを送信した後に各ＥＣＵがレスポンスを返す順序の確認の方法が異なる。即ち、マスタＥＣＵ３１４００は、各ＥＣＵから受信したレスポンス（シリアルＩＤ通知用フレーム）の順序を、車載ネットワークシステムの外部（車両の外部）のサーバと通信することで確認する機能を有する。このサーバは、生存確認フレームに対してのレスポンスとして送信されるシリアルＩＤ通知用フレームにおけるＣＡＮ−ＩＤの順序を示す情報を管理するコンピュータである。
【０１７４】
［３．６  マスタＥＣＵ３１４００の構成］
図２９は、マスタＥＣＵ３１４００の構成図である。マスタＥＣＵ３１４００は、フレーム送受信部４０１と、フレーム解釈部４０２と、受信ＩＤ判断部４０３と、受信ＩＤリスト保持部４０４と、ＭＡＣ処理部４０６と、カウンタ保持部４０７と、セッション鍵リスト保持部４０８と、暗号処理部４０９と、共有鍵リスト保持部２０４１０と、セッション鍵生成部４１１と、フレーム生成部４１２と、サーバ通信部３１４１２とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、マスタＥＣＵ３１４００における通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。なお、マスタＥＣＵ３１４００の構成要素のうちマスタＥＣＵ４００或いはマスタＥＣＵ２０４００の構成要素（図３、図２０参照）と同一のものには、同一の符号を付し、説明を適宜省略する。
【０１７５】
フレーム解釈部４０２は、データフレームについてＭＡＣ処理部４０６でＭＡＣを検証した結果として検証に成功した場合に、そのデータフレームのＣＡＮ−ＩＤと、データフィールドの値とをサーバ通信部３１４１２に通知する。
【０１７６】
サーバ通信部３１４１２は、無線により外部のサーバと通信する機能を有する。サーバ通信部３１４１２は、フレーム解釈部４０２より受信した全てのデータフレームのＣＡＮ−ＩＤと、データフィールドの値とを対応付けて、受信順にサーバに通知し、サーバでの判定結果を受信する。判定の結果、エラーが発生している場合は、表示装置にエラーを示す表示を行う等のエラー処理を行う。要求としての生存確認フレームへのレスポンスとして各ＥＣＵから送信されるシリアルＩＤ通知用フレームの順序について、サーバでの判定結果がエラーであれば、マスタＥＣＵ３１４００は、エラーの表示、ログの記録等を行い得る。またエラーの場合に、マスタＥＣＵ３１４００は、各ＥＣＵへのセッション鍵の伝達を行わないようにすることができる。
【０１７７】
なお、サーバは、マスタＥＣＵ３１４００と通信可能なコンピュータであり、シリアルＩＤ通知用フレームについてのＣＡＮ−ＩＤとデータフィールドの値であるシリアルＩＤを示す値とをマスタＥＣＵ３１４００から連続的に受信した場合においては、送信元のＥＣＵ毎に予め定められているそのＣＡＮ−ＩＤとシリアルＩＤとを連続的に受信した順に記録して管理し、前回連続的に受信して記録済みの内容と比較する。その比較により、連続的に受信したシリアルＩＤ通知用フレームが前回記録済みの内容と一致する場合（つまりＣＡＮ−ＩＤの順序が一致し、かつ、シリアルＩＤとの組み合わせも一致する場合）には正常、一致しない場合にはエラーという判定結果を、マスタＥＣＵ３１４００に送信する機能を有する。
【０１７８】
［３．７  共有鍵検証シーケンス］
以下、マスタＥＣＵ３１４００が、共有鍵に関するセキュリティ状態を、サーバとの通信により、検査する動作について、図３０を用いて説明する。
【０１７９】
図３０は、マスタＥＣＵ３１４００と、ＥＣＵ２０１００ａと、ＥＣＵ２０１００ｂと、ＥＣＵ２０１００ｃと、ＥＣＵ２０１００ｄとによる共有鍵検証シーケンスの一例を示す。なお、この共有鍵検証シーケンスは、例えば車載ネットワークシステムを搭載する車両が特定状態（例えば停車状態）であるときにおいて実行される。具体的な一例としては、アクセサリ−オン（ＡＣＣ−ＯＮ）になった直後及びアクセサリ−オフ（ＡＣＣ−ＯＦＦ）になった直後において実行される。なお、図３０において図２８で示した処理（ステップ）と同一の処理については同一の符号を付しており、ここでは説明を適宜省略する。
【０１８０】
ステップＳ３１０２において、ＥＣＵ２０１００ａ、ＥＣＵ２０１００ｂ、ＥＣＵ２０１００ｃ及びＥＣＵ２０１００ｄのそれぞれが生存確認フレームへのレスポンスとして送信したシリアルＩＤ通知用フレームが順次バス２００上に現れることになる。
【０１８１】
このバス２００上に連続的に順次現れる各ＥＣＵからのレスポンスとしてのシリアルＩＤ通知用フレームに対してマスタＥＣＵ３１４００は、シリアルＩＤ通知用フレームのＣＡＮ−ＩＤと、シリアルＩＤ通知用フレームに含まれるデータフィールドの値であるシリアルＩＤとの組を連続的に受信順にサーバに送信する。そして、サーバから返信される判定結果が正常か否かによって、共有鍵のセキュリティ状態が適切か否かを検査する（ステップＳ３２０３）。マスタＥＣＵ３１４００は、サーバによる判定結果がエラーである場合、つまり、各ＥＣＵからの生存確認フレームへのレスポンスの順序が前回の生存確認フレームへのレスポンスの順序と一致しない、或いは、前回とレスポンスの内容（シリアルＩＤ）が一致しないことから共有鍵のセキュリティ状態が不適切である場合には、表示装置にエラーを示す情報（例えば不正なＥＣＵが存在することを示す情報等）を表示することで運転者への報知を行う（ステップＳ３２０４）。
【０１８２】
［３．８  実施の形態３の変形例の効果］
実施の形態３の変形例に係る車載ネットワークシステムでは、車両が停車状態等の特定の状態である場合において、マスタＥＣＵ３１４００が外部のサーバと通信することにより、各ＥＣＵが送信するフレームの順序等が適切か否かをサーバで判定させることで、共有鍵のセキュリティ状態が適切か否かを検査する。これにより、車載ネットワークシステムの構成が変更されているような場合には、各ＥＣＵが送信するフレームの順序がその変更前と比べて変化するので、サーバによりエラーと判定されることになる。そして、セキュリティ状態が不適切な場合（エラーと判定された場合）に、報知等により安全性を確保できる。また、外部のサーバは、複数の車両それぞれに搭載された車載ネットワークシステムにおけるマスタＥＣＵ３１４００から各ＥＣＵのシリアルＩＤの情報を収集して整合性等を確認し得るため、より適切に共有鍵のセキュリティ状態を検査し得る。
【０１８３】
（他の実施の形態）
以上のように、本発明に係る技術の例示として実施の形態１〜３を説明した。しかしながら、本発明に係る技術は、これに限定されず、適宜、変更、置き換え、付加、省略等を行った実施の形態にも適用可能である。例えば、以下のような変形例も本発明の一実施態様に含まれる。
【０１８４】
（１）上記実施の形態では、各ＥＣＵによりフレームが定期的に送信される例を示したが、フレームは状態変化を通知するイベントとして送信されることとしても良い。例えば、ＥＣＵは、ドアの開閉状態を定期的に送信するのではなく、ドアの開閉状態が変化した場合にのみ、フレームを送信するとしても良い。また、ＥＣＵがフレームを、定期的に送信、かつ、状態変化が発生した時に送信することとしても良い。
【０１８５】
（２）上記実施の形態では、ＣＡＮ−ＩＤとデータ値とカウンタ値とに基づく演算によりＭＡＣを生成（計算）しているが、データフレームの一部の内容を反映して（つまり一部の内容に基づいて）ＭＡＣを生成すれば良く、データ値のみからＭＡＣを生成することとしても良い。またカウンタ値のみからＭＡＣを生成するとしても良い。データフレームを受信するＥＣＵにおけるＭＡＣの検証方式は、データフレームを送信するＥＣＵがデータフレームにＭＡＣを付与する方式に対応したものであれば良い。また、ＭＡＣを付与するデータフレームにおいてはデータフィールド内にデータ値及びＭＡＣの他に、一部又は全てのカウンタ値を含めても良い。また、フレームに含まれるＭＡＣのサイズは４ｂｙｔｅｓに制限されるものではなく、ＣＡＮ−ＩＤ毎に異なるサイズであっても良い。また、ＭＡＣを複数に分割して、分割されたＭＡＣを各フレームに含ませることで、複数のフレームに跨ってＭＡＣが送信されるようにしても良い。また、カウンタ値のサイズも１ｂｙｔｅに制限されるものではない。
【０１８６】
（３）上記実施の形態では、カウンタ値を送信毎にインクリメントする例を示したが、カウンタ値が時刻に応じて自動的にインクリメントされる値であっても良い。また、時刻そのものの値をカウンタの代わりに使用しても良い。また、カウンタの値に対する演算は、インクリメント（１増加）には限定されない。２以上の増加を行っても良いし、インクリメントによるアップカウントに限らず、デクリメントによるダウンカウントでも良い。また、カウンタ値に対する演算は、例えば、ビットシフトであっても良いし、前回の演算結果を入力値として予め定められたアルゴリズムに基づいて特定された出力値を演算結果とする演算等であっても良い。
【０１８７】
（４）上記実施の形態では、ＣＡＮプロトコルにおけるデータフレームを標準ＩＤフォーマットで記述しているが、拡張ＩＤフォーマットで合っても良い。拡張ＩＤフォーマットの場合には、標準ＩＤフォーマットにおけるＩＤ位置のベースＩＤと、拡張ＩＤとを合わせて２９ビットでＣＡＮ−ＩＤを表す。
【０１８８】
（５）上記実施の形態では、ＭＡＣ算出のアルゴリズムをＡＥＳ−ＣＭＡＣ（Advanced Encryption Standard−Cipher-based Message Authentication Code）としているが、これはＣＢＣ−ＭＡＣ（Cipher Block Chaining Message Authentication Code）、ＨＭＡＣ（Hash-based Message Authentication Code)であっても良い。また、ＭＡＣ計算に用いられるパディングについては、ゼロパディング、ＩＳＯ１０１２６、ＰＫＣＳ＃１、ＰＫＣＳ＃５、ＰＫＣＳ＃７、その他、ブロックのデータサイズが計算に必要となるパディングの方式であれば何でも良い。また４ｂｙｔｅｓ等のブロックへのサイズの変更方法についても、先頭、最後尾、中間のいずれの部分にパディングを行っても良い。また、ＭＡＣ算出に用いるデータは、連続しているデータ（例えば４ｂｙｔｅｓ分の連続データ）でなくても、特定のルールに従って１ｂｉｔずつ収集して結合したものでも良い。
【０１８９】
（６）上記実施の形態では、セッション鍵が４Ｂｙｔｅｓの例を示したが（図６参照）、セッション鍵のサイズはこれに限定されず、８Ｂｙｔｅｓ等であっても良い。そして１フレームに格納できないサイズのセッション鍵であれば、セッション鍵の伝達を複数フレームによって行っても良い。なお、セッション鍵の伝達は、送信側と受信側で同じセッション鍵を持ち合える方法であればいかなる方法で実現しても良く、暗号化したセッション鍵の送信によって実現する他に、セッション鍵の生成に必要な情報を送信することにより実現しても良い。
【０１９０】
（７）上記実施の形態では、共有鍵のセキュリティ状態の検査（共有鍵検証シーケンス）を行うための車両の特定状態として、特定状態（ＡＣＣ−ＯＮになった直後、ＡＣＣ−ＯＦＦになった直後等）を例示したが、他の特定状態であっても良い。例えば、特定状態は、エンジン始動直後或いはエンジン停止となった状態でも良い。また、ＡＣＣ−ＯＮになった直後、ＡＣＣ−ＯＦＦになった直後、エンジン停止となった状態等といった、車両が走行していない状態が共有鍵のセキュリティ状態の検査（確認等）のための車両の特定状態であることとしても良い。車両が走行していない状態である特定状態に限って共有鍵のセキュリティ状態の検査を行うことは、各ＥＣＵの負荷増大を防止する等の点で有用となる。また、給油口の開閉に応じて「給油中」を判定し、給油中に共有鍵検証シーケンスを開始しても良い。また、電気自動車であれば、充電プラグが接続されたことを検知することで「充電中」を判定し、充電中に共有鍵検証シーケンスを開始しても良い。また、車両のギア等に基づいて「駐車中」、「停車中」、「走行中」等の切り替えを区別して、例えば、駐車中において共有鍵検証シーケンス処理を開始しても良いし、「高速走行中」及び「低速走行中」を区別して例えば低速走行中に共有鍵検証シーケンスを開始しても良い。また、実施の形態３及びその変形例で示した共有鍵検証シーケンスの実行タイミングはＡＣＣ−ＯＮになった直後及びＡＣＣ−ＯＦＦになった直後に限られず、ＡＣＣ−ＯＮになった直後のみとしても良いし、ＡＣＣ−ＯＦＦになった直後のみとしても良いし、その他のタイミング（エンジン始動直後等）としても良い。
【０１９１】
（８）上記実施の形態で示した共有鍵は、ＥＣＵ毎に１つ保持しても良いし、ＥＣＵが複数のＣＡＮ−ＩＤを用いたフレームの送信を行う場合にはＣＡＮ−ＩＤ毎に１つ保持することとしても良い。マスタＥＣＵとその他の１又は複数のＥＣＵとが共有鍵を持ち合う単位は、車載ネットワークシステムにおいて任意に定め得る。
【０１９２】
（９）上記実施の形態では、カウンタ（送信カウンタ値、受信カウンタ値）をＣＡＮ−ＩＤ毎に１つ保持しているが、ＥＣＵ毎（つまり１以上のＣＡＮ−ＩＤ群毎）に１つであっても良い。また、同一のバス上を流れる全てのフレームに対して共通のカウンタ値を使用しても良い。
【０１９３】
（１０）上記実施の形態３での生存確認フレームに対するレスポンスとしての情報（フレーム）の送信は、必ずしもシリアルＩＤ通知用フレームの送信でなくても良く、必ずしもデータフィールドにシリアルＩＤを含ませなくても良い。また、生存確認フレームに対する各ＥＣＵからのレスポンスとしてのフレームの送信順序の確認（検査）の方法として、前回の順序との一致を確認する方法の他に、予め定められた順序を記録したリストに基づいてそのリストの順序との一致を確認する方法を用いても良い。
【０１９４】
（１１）上記実施の形態で示したマスタＥＣＵ（鍵管理装置）とその他の複数のＥＣＵそれぞれとの間で共有された共有鍵（セッション鍵の伝達の事前に共有される鍵）は、共通鍵暗号方式における共通鍵（秘密鍵）であっても良いし、その他に公開鍵暗号方式における鍵ペア（公開鍵、秘密鍵）であっても良い。即ち、鍵管理装置としての第１種電子制御ユニット（マスタＥＣＵ）と１以上の第２種電子制御ユニット（マスタＥＣＵ以外のＥＣＵ）それぞれとの相互間では、同一又は鍵ペアとなる共有鍵を共有して保持すれば良い。なお、同一の鍵をそれぞれの装置（第１種ＥＣＵ及び第２種ＥＣＵ）が持ち合うことに加えて、公開鍵と秘密鍵との鍵ペアをそれぞれの装置（第１種ＥＣＵ及び第２種ＥＣＵ）が持ち合うことも、共有鍵を共有すると言う。一例としては、車載ネットワークシステムにおける各ＥＣＵがそれぞれ別個の秘密鍵を有し、マスタＥＣＵが各ＥＣＵの秘密鍵に対応する各公開鍵を有し、マスタＥＣＵが各公開鍵でセッション鍵を暗号化して各ＥＣＵに配送することとしても良い。
【０１９５】
（１２）上記実施の形態では、ＥＣＵ間で送受信されるデータフレームに対して、受信したＥＣＵがＭＡＣの検証を行っているが、車載ネットワークシステムにおいて全てのデータフレームに付与されたＭＡＣの検証を単独で担うＭＡＣ検証用ＥＣＵが存在しても良い。このＭＡＣ検証用ＥＣＵが全てのＣＡＮ−ＩＤに対応するＭＡＣの生成用の鍵とカウンタ値とを取得し保持することとしても良い。また、このＭＡＣ検証用ＥＣＵがＭＡＣ検証の結果としてエラーと判定した場合に、その他のＥＣＵでの受信を防止するため、エラーフレームを送信しても良い。
【０１９６】
（１３）上記実施の形態１、２では、全てのＥＣＵの持つ共有鍵の有効性等のセキュリティ状態を一度に検査（検証）する例を示したが、ＥＣＵ毎に個別に検査（検証）を行っても良い。また、車両の状態に応じて特定の種類のＥＣＵについては検査（検証）の処理をスキップすることとしても良い。例えば、車両が走行中である状態においては、走行に関連する駆動系のＥＣＵ（例えばエンジンに関連するＥＣＵ１００ａ等）については検査（検証）の処理（例えば有効期限通知用フレームの送信等）をスキップすることとしても良い。
【０１９７】
（１４）上記実施の形態におけるマスタＥＣＵ及び他のＥＣＵは、例えば、プロセッサ、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置であることとしたが、ハードディスク装置、ディスプレイ、キーボード、マウス等の他のハードウェア構成要素を含んでいても良い。また、メモリに記憶された制御プログラムがプロセッサにより実行されてソフトウェア的に機能を実現する代わりに、専用のハードウェア（デジタル回路等）によりその機能を実現することとしても良い。
【０１９８】
（１５）上記実施の形態における各装置を構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Large Scale Integration：大規模集積回路）から構成されているとしても良い。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ等を含んで構成されるコンピュータシステムである。前記ＲＡＭには、コンピュータプログラムが記録されている。前記マイクロプロセッサが、前記コンピュータプログラムに従って動作することにより、システムＬＳＩは、その機能を達成する。また、上記各装置を構成する構成要素の各部は、個別に１チップ化されていても良いし、一部又はすべてを含むように１チップ化されても良い。また、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現しても良い。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用しても良い。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行っても良い。バイオ技術の適用等が可能性としてあり得る。
【０１９９】
（１６）上記各装置を構成する構成要素の一部または全部は、各装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしても良い。前記ＩＣカードまたは前記モジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭ等から構成されるコンピュータシステムである。前記ＩＣカードまたは前記モジュールは、上記の超多機能ＬＳＩを含むとしても良い。マイクロプロセッサが、コンピュータプログラムに従って動作することにより、前記ＩＣカードまたは前記モジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしても良い。
【０２００】
（１７）本発明の一態様としては、上記に示す共有鍵検証シーケンス等の鍵管理方法であるとしても良い。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしても良いし、前記コンピュータプログラムからなるデジタル信号であるとしても良い。また、本発明の一態様としては、前記コンピュータプログラムまたは前記デジタル信号をコンピュータで読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＢＤ（Blu-ray（登録商標） Disc）、半導体メモリ等に記録したものとしても良い。また、これらの記録媒体に記録されている前記デジタル信号であるとしても良い。また、本発明の一態様としては、前記コンピュータプログラムまたは前記デジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしても良い。また、本発明の一態様としては、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記録しており、前記マイクロプロセッサは、前記コンピュータプログラムに従って動作するとしても良い。また、前記プログラムまたは前記デジタル信号を前記記録媒体に記録して移送することにより、または前記プログラムまたは前記デジタル信号を前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしても良い。
【０２０１】
（１８）上記実施の形態及び上記変形例で示した各構成要素及び機能を任意に組み合わせることで実現される形態も本発明の範囲に含まれる。
【産業上の利用可能性】
【０２０２】
本発明は、車載ネットワークシステムのＥＣＵにおいて用いられる鍵の管理に利用可能である。
【符号の説明】
【０２０３】
１０  車載ネットワークシステム
１００ａ，１００ｂ，１００ｃ，１００ｄ，２０１００ａ，２０１００ｂ，２０１００ｃ，２０１００ｄ  電子制御ユニット（ＥＣＵ、第２種ＥＣＵ）
１０１，４０１  フレーム送受信部
１０２，４０２  フレーム解釈部
１０３，４０３  受信ＩＤ判断部
１０４，４０４  受信ＩＤリスト保持部
１０５  復号処理部
１０６  共有鍵保持部
１０７，４０６  ＭＡＣ処理部
１０８  セッション鍵保持部
１０９，４０７  カウンタ保持部
１１０，４１２  フレーム生成部
１１１  データ取得部
２００  バス
３１０  エンジン
３２０  ブレーキ
３３０  ドア開閉センサ
３４０  窓開閉センサ
４００，１４００，２０４００，２１４００，３０４００，３１４００  マスタＥＣＵ（鍵管理装置、第１種ＥＣＵ）
４０５  有効期限確認部
４０８  セッション鍵リスト保持部
４０９  暗号処理部
４１０，２０４１０  共有鍵リスト保持部
４１１  セッション鍵生成部
１４１２，２１４１２，３１４１２  サーバ通信部
２０１２１  シリアルＩＤ保持部
２０４２１  リスト確認部
３０４３１  シーケンス検証部
３０４３２  シーケンス記録部
【図１】
2016075869.tif 000003
【図２】
2016075869.tif 000004
【図３】
2016075869.tif 000005
【図４】
2016075869.tif 000006
【図５】
2016075869.tif 000007
【図６】
2016075869.tif 000008
【図７】
2016075869.tif 000009
【図８】
2016075869.tif 000010
【図９】
2016075869.tif 000011
【図１０】
2016075869.tif 000012
【図１１】
2016075869.tif 000013
【図１２】
2016075869.tif 000014
【図１３】
2016075869.tif 000015
【図１４】
2016075869.tif 000016
【図１５】
2016075869.tif 000017
【図１６】
2016075869.tif 000018
【図１７】
2016075869.tif 000019
【図１８】
2016075869.tif 000020
【図１９】
2016075869.tif 000021
【図２０】
2016075869.tif 000022
【図２１】
2016075869.tif 000023
【図２２】
2016075869.tif 000024
【図２３】
2016075869.tif 000025
【図２４】
2016075869.tif 000026
【図２５】
2016075869.tif 000027
【図２６】
2016075869.tif 000028
【図２７】
2016075869.tif 000029
【図２８】
2016075869.tif 000030
【図２９】
2016075869.tif 000031
【図３０】
2016075869.tif 000032
【国際調査報告】
2016075869.tif 000033
2016075869.tif 000034