JP2018160888A - 更新処理方法、車載ネットワークシステムおよび電子制御ユニット - Google Patents

Abstract

【課題】車載ネットワークシステムにおいて用いられる鍵の更新を効率よく確実に実施することができる更新処理方法車載ネットワークシステム及び電子制御ユニットを提供する。【解決手段】複数の電子制御ユニットを有し、車両に搭載される車載ネットワークシステムにおいて用いられる鍵の更新処理方法であって、複数の電子制御ユニットの少なくとも一つから送信される、車両の走行に関する情報である走行情報を取得する取得ステップＳ１０と、走行情報により得られる車両の走行に関する状態が所定状態であることを条件としてＳ１１、車載ネットワークシステムにおいて授受されるデータに付加されるメッセージ認証コード（ＭＡＣ：Message Authentication Code）であって改ざん防止のコードであるメッセージ認証コードの生成に利用される鍵であるＭＡＣ鍵を更新する鍵更新ステップＳ１２とを含む。【選択図】図１５

Description

本開示は、更新処理方法、車載ネットワークシステムおよび電子制御ユニットに関する。

近年、自動車の中のシステムには、電子制御ユニット（以下、ＥＣＵ：Engine Control Unit）と呼ばれる装置が多数配置されている。これらのＥＣＵをつなぐネットワークを車載ネットワークと呼ぶ。車載ネットワークには、多数の規格が存在する。その中でも最も主流な車載ネットワークの規格の一つに、Controller Area Network（以下、ＣＡＮ）という規格がある。

ＣＡＮでは、通信線として用いられるバス（bus）は２本のケーブル（ツイストペア・ケーブル）で構成され、このバスに接続されているＥＣＵはノードと呼ばれる。バスに接続されている各ノードは、フレームと呼ばれるメッセージを送受信する。フレームを送信するノード（以下、送信ノードともいう）は２本のケーブルに電圧をかけ、それぞれのケーブル間で発生させた電位差の有無に応じたレセシブと呼ばれる“１”の値とドミナントと呼ばれる“０”の値とを送信することで、フレームのデータを２進数に変換したバイナリデータで送信する。

なお、複数の送信ノードが全く同一のタイミングで、レセシブとドミナントとを送信した場合は、ドミナントが優先されて送信される。フレームを受信するノード（以下、受信ノードともいう）は、受け取ったフレームのフォーマットに異常がある場合には、例えば連続する６ｂｉｔのドミナントで始まるエラーフレームと呼ばれるフレームを送信する。受信ノードは、エラーフレームを送信することで、送信ノードおよび他の受信ノードにフレームの異常を通知することができる。

また、ＣＡＮでは、送信先または送信元を指す識別子は存在しない。送信ノードはフレーム毎にメッセージＩＤと呼ばれるＩＤを付けて送信し、各受信ノードは予め決められたメッセージＩＤを含むフレームのみ受信する。

また、ＣＡＮでは、ＣＳＭＡ／ＣＲ（Carrier Sense Multiple Access/Collision Resolution）方式が採用されており、複数ノードの同時送信時にはメッセージＩＤによる調停が行われ、メッセージＩＤの値が小さいフレームが優先的に送信される。

一方、ＣＡＮでは、不正なフレームが送信されるようなケースを想定したセキュリティ機能が存在しない。そのため、不正なノードが勝手にＣＡＮのバスに接続し、不正なフレームを送信することで、当該ＣＡＮが搭載された自動車の車体を不正にコントロールすることが可能である。

それに対して、例えば特許文献１では、ＣＡＮ通信に用いられるデータフレームおけるデータフィールドにメッセージ認証コード（以降、ＭＡＣ：Message Authentication Code)を埋め込んで送信する方法が開示されている。そして、通常のデータフレームに続けて、当該データフレームおけるデータフィールドにＭＡＣを埋め込んだデータフレームを送信することで、不正なフレームの送信を防止することができる。

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

RFC2104 HMAC: Keyed-Hashing for Message Authentication

ところで、ＣＡＮ通信に用いられるフレームには、ＭＡＣを付加するためのフィールドは存在しない。さらにＣＡＮ通信に用いられるデータフレームにおけるデータフィールドは８バイトと少なく、データフィールドに埋め込まれるＭＡＣのサイズでは、十分な攻撃の耐性を確保することが難しい。

そこで、データフィールドに埋め込まれるＭＡＣに対する総当り攻撃の耐性を高めるために、ＭＡＣの生成に利用される鍵（以下、ＭＡＣ鍵ともいう）を定期的に更新することが望ましいと考えられる。

しかしながら、定期的に鍵の更新を行うとすると、自動車の動作にかかわらず鍵を更新することになる。つまり、定期的に鍵の更新を行う場合、ＣＡＮにおいてフレームがほとんど送受信されていなくても鍵が更新されることから、車載ネットワークシステムにとって鍵の更新処理が負荷になることがある。

本開示は、上述の事情を鑑みてなされたもので、車載ネットワークシステムにおいて用いられる鍵の更新を効率よく確実に実施することができる更新処理方法等を提供することを目的とする。

本発明の一態様に係る更新処理方法は、複数の電子制御ユニットを有し、車両に搭載される車載ネットワークシステムにおいて用いられる鍵の更新処理方法であって、前記複数の電子制御ユニットの少なくとも一つから送信される、前記車両の走行に関する情報である走行情報を取得する取得ステップと、前記走行情報により得られる前記車両の走行に関する状態が所定状態であることを条件として、前記車載ネットワークシステムにおいて授受されるデータに付加されるメッセージ認証コード（ＭＡＣ：Message Authentication Code）であって改ざん防止のコードであるメッセージ認証コードの生成に利用される鍵であるＭＡＣ鍵を更新する鍵更新ステップとを含む。

本開示の更新処理方法等は、車載ネットワークシステムにおいて用いられる鍵の更新を効率よく確実に実施することができる。これにより、安全な状態の車載ネットワークシステムを維持することができる。

実施の形態における車載ネットワークシステムの構成を示すブロック図である。 図１に示す鍵更新管理装置の構成の一例を示すブロック図である。 実施の形態における車載ネットワークシステムの全体構成の一例を示す図である。 ＣＡＮプロトコルのデータフレームのフォーマットを示す図である。 ＣＡＮ通信におけるＭＡＣの送信方法の一例を示す図である。 イーサネット（登録商標）通信におけるＭＡＣの送信方法の一例を示す図である。 実施の形態におけるＥＣＵの機能構成を示すブロック図である。 実施の形態における受信ＩＤリストの一例を示す図である。 実施の形態における判定ルールの一例を示す図である。 実施の形態における判定ルールの一例を示す図である。 実施の形態におけるエンジンに接続されたＥＣＵが送信するメッセージＩＤとデータの一例を示す図である。 実施の形態におけるブレーキに接続されたＥＣＵが送信するメッセージＩＤとデータの一例を示す図である。 実施の形態におけるドア開閉センサに接続されたＥＣＵが送信するメッセージＩＤとデータの一例を示す図である。 実施の形態におけるウィンドウ開閉センサに接続されたＥＣＵが送信するメッセージＩＤとデータの一例を示す図である。 実施の形態におけるＧＰＳセンサに接続されたＥＣＵが送信するメッセージＩＤとデータの一例を示す図である。 実施の形態における更新処理方法を示すフローチャートである。 図１５に示すステップＳ１１の詳細処理を示すフローチャートである。 図１５に示すステップＳ１２の詳細処理を示すフローチャートの一例である。 図１５に示すステップＳ１２の詳細処理を示すフローチャートの別の一例である。

本開示の一態様の更新処理方法は、複数の電子制御ユニットを有し、車両に搭載される車載ネットワークシステムにおいて用いられる鍵の更新処理方法であって、前記複数の電子制御ユニットの少なくとも一つから送信される、前記車両の走行に関する情報である走行情報を取得する取得ステップと、前記走行情報により得られる前記車両の走行に関する状態が所定状態であることを条件として、前記車載ネットワークシステムにおいて授受されるデータに付加されるメッセージ認証コード（ＭＡＣ：Message Authentication Code）であって改ざん防止のコードであるメッセージ認証コードの生成に利用される鍵であるＭＡＣ鍵を更新する鍵更新ステップとを含む。

これにより、ＭＡＣ鍵の鍵更新処理、および、カウンタのリセット処理を含む更新処理を、走行距離および／または車の状態に応じて実行することで、更新処理を車の動作に応じて、適切な頻度で実行できる。つまり、ＥＣＵにおける鍵の更新処理が効率よく適切に実行できる。それにより、車載ネットワークシステム全体として、安全な状態を維持することができる。

また、前記所定状態は、前記走行情報により得られる前記車両の走行距離であって前記ＭＡＣ鍵の前回の更新時からの前記車両の走行距離が閾値を超えた状態であってもよい。

また、前記所定状態は、前記ＭＡＣ鍵の前回の更新時から所定時間経過後、かつ、前記走行情報により得られる前記車両の状態が駐車中である状態であってもよい。

また、前記鍵更新ステップでは、前記複数の電子制御ユニットのすべてが、前記条件を満たした同一のタイミングで、前記ＭＡＣ鍵を用いて新たなＭＡＣ鍵を生成することにより、前記ＭＡＣ鍵を前記新たなＭＡＣ鍵に更新してもよい。

また、前記鍵更新ステップでは、前記複数の電子制御ユニットの一が、前記条件を満たしたときに、前記ＭＡＣ鍵を用いて新たなＭＡＣ鍵を生成する生成ステップと、前記一の電子制御ユニットが生成した前記新たなＭＡＣ鍵を、前記一の電子制御ユニット以外の前記複数の電子制御ユニットのすべてに配布することにより、前記ＭＡＣ鍵を前記新たなＭＡＣ鍵に更新する配布ステップとを含んでもよい。

また、前記車載ネットワークは、前記複数の電子制御ユニットがバスに接続されたＣＡＮ（Controller Area Network）であり、前記更新処理方法は、前記複数の電子制御ユニットのうちの一である第１電子制御ユニットが、ＣＡＮプロトコルに従ってバスを介して、前記データとしてデータフレーム、および、前記データに付加されるメッセージ認証コードとして前記データフレームのデータフィールドを前記メッセージ認証コードとした検証用データフレームの送信を行う送信ステップと、前記複数の電子制御ユニットのうちの前記第１電子制御ユニット以外の複数の電子制御ユニットの少なくとも一である第２電子制御ユニットが、前記第１電子制御ユニットにより送信されたデータフレーム、および、検証用データフレームを、バスを介して受信する受信ステップとを含んでもよい。

また、前記送信ステップでは、前記第１電子制御ユニットが、前記データフレームを識別するためのＩＤと送信カウンタによりカウントされたデータフレームの送信回数とを少なくとも結合した値に対して前記ＭＡＣ鍵を用いて前記メッセージ認証コードを生成するＭＡＣ生成ステップを含み、前記受信ステップでは、前記第２電子制御ユニットが、前記検証用データフレームを受信して得た前記メッセージ認証コードと、受信した前記データフレームに対応するＩＤと、受信カウンタによりカウントされたデータの受信回数とを少なくとも結合した値に対して、前記ＭＡＣ鍵を用いて生成したメッセージ認証コードとの同一性を検証する検証ステップを含んでもよい。

また、前記車載ネットワークシステムは、前記複数の電子制御ユニットがＬＡＮ（Local Area Network）により接続されたネットワークであり、前記更新処理方法は、前記複数の電子制御ユニットのうちの一である第１電子制御ユニットが、前記データに付加される前記メッセージ認証コードとしてペイロード部分に前記メッセージ認証コードを含めて、前記データの送信を行う送信ステップと、前記複数の電子制御ユニットのうちの前記第１電子制御ユニット以外の複数の電子制御ユニットの少なくとも一である第２電子制御ユニットが、前記第１電子制御ユニットにより送信された前記データを受信する受信ステップとを含んでてもよい。

また、前記送信ステップでは、さらに、前記第１電子制御ユニットが、前記データに付加された送信元アドレスおよび送信先アドレスと送信カウンタによりカウントされたデータの送信回数とを少なくとも結合した値に対して前記ＭＡＣ鍵を用いて前記メッセージ認証コードを生成するＭＡＣ生成ステップを含み、前記受信ステップでは、前記第２電子制御ユニットが、ペイロード部分に前記メッセージ認証コードが含まれた前記データを受信して得た前記メッセージ認証コードと、受信した当該データに付加された送信元アドレスおよぎ送信先アドレスと受信カウンタによりカウントされたデータの受信回数とを少なくとも結合した値に対して、前記ＭＡＣ鍵を用いて生成したメッセージ認証コードとの同一性を検証する検証ステップを含んでもよい。

また、前記更新処理方法は、さらに、前記条件として前記送信カウンタおよび前記受信カウンタをリセットするリセットステップを含むとしてもよい。

また、前記複数の電子制御ユニットは、前記車両の制御用途により分類された複数のグループの一に属し、前記複数のグループのそれぞれにおける前記所定状態は、前記複数のグループごとに定められてもよい。

また、本開示の一態様の車載ネットワークシステムは、複数の電子制御ユニットを有し、車両に搭載される車載ネットワークシステムであって、前記複数の電子制御ユニットの少なくとも一つから送信される前記車両の走行に関する情報である走行情報を取得する取得部と、前記走行情報により得られる前記車両の走行に関する状態が所定状態であることを条件として、前記車載ネットワークシステムにおいて授受されるデータに付加されるメッセージ認証コード（ＭＡＣ：Message Authentication Code）であって改ざん防止のコードであるメッセージ認証コードの生成に利用される鍵であるＭＡＣ鍵を更新する更新処理部とを備える。

また、本開示の一態様の電子制御ユニットは、車両に搭載される車載ネットワークシステムに接続される電子制御ユニットであって、ＣＰＵとメモリとを有し、前記ＣＰＵは、複数の電子制御ユニットの少なくとも一つから送信される前記車両の走行に関する情報である走行情報を取得して前記メモリに格納し、前記ＣＰＵは、前記メモリに格納された前記走行情報により得られる前記車両の走行に関する状態が所定状態であることを条件として、前記車載ネットワークシステムにおいて授受されるデータに付加されるメッセージ認証コード（ＭＡＣ：Message Authentication Code）であって改ざん防止のコードであるメッセージ認証コードの生成に利用される鍵であるＭＡＣ鍵を更新する。

以下、図面を参照しながら、実施の形態について説明する。なお、以下で説明する実施の形態は、いずれも本開示の一具体例を示すものである。つまり、以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置および接続形態、ステップ、ステップの順序などは、一例であり、本開示を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素は、任意で含まれる構成要素として説明される。

（実施の形態）
以下では、図面を参照しながら、実施の形態における更新処理方法等の説明を行う。

［１．システムの構成］
図１は、本実施の形態における車載ネットワークシステム１００の構成を示すブロック図である。図２は、図１に示す鍵更新管理装置の構成の一例を示すブロック図である。

本実施の形態における車載ネットワークシステム１００は、複数の電子制御ユニット（ＥＣＵ）を有し、車両に搭載される。図１において、車載ネットワークシステム１００は、鍵更新管理装置１０と、複数のＥＣＵとを備える。複数のＥＣＵ間、複数のＥＣＵおよび鍵更新管理装置の間は、ネットワークで接続されている。ネットワークは、上記のＣＡＮであってもよいし、Ｅｔｈｅｒｎｅｔ（登録商標）等のＬＡＮであってもよい。

鍵更新管理装置１０は、車両の動作に応じて適切な頻度で鍵更新処理を行う。鍵更新管理装置１０は、例えば、ゲートウェイであってもよいし、複数のＥＣＵのうちの一つであってもよい。鍵更新管理装置１０は、図２に示すように、取得部１１と鍵更新部１２と鍵更新処理判定部１３とを備える。

取得部１１は、複数の電子制御ユニットの少なくとも一つから送信される車両の走行に関する情報である走行情報を取得する。走行情報により車両の走行距離等が得られる。

鍵更新処理判定部１３は、鍵更新部１２が鍵更新処理を実行する条件を満たしたか否かを判定する。

鍵更新部１２は、走行情報により得られる車両の走行に関する状態が所定状態であることを条件として、車載ネットワークシステム１００において授受されるデータに付加されるＭＡＣであって改ざん防止のコードであるＭＡＣの生成に利用される鍵であるＭＡＣ鍵を更新する。なお、鍵更新部１２は、走行情報により得られる車両の走行に関する状態が所定状態であることを条件として送信カウンタおよび受信カウンタをリセットするとしてもよい。

鍵更新部１２は、鍵更新処理を実行する条件を満たしたタイミングを通知することで、複数のＥＣＵすべてにＭＡＣ鍵を同一のタイミングで更新させる鍵更新処理を行ってもよい。また、鍵更新部１２は、鍵更新処理を実行する条件を満たしたタイミングにおいて生成した新たなＭＡＣ鍵を複数のＥＣＵすべてに配布することにより、複数のＥＣＵすべてにＭＡＣ鍵を同一のタイミングで更新させる鍵更新処理を行ってもよい。なお、鍵更新処理を実行する条件を満たしたタイミングを通知することは必須ではなく、ＣＡＮであれば複数のＥＣＵすべてがそれぞれ独立にタイミングを判定しても、複数のＥＣＵすべてが同一のタイミングで更新することになるからである。

以下、本実施の形態における車載ネットワークシステム１００の全体構成の一例について説明する。

［１．１ 車載ネットワークシステム１００ａの全体構成］
図３は、本実施の形態における車載ネットワークシステム１００ａの全体構成の一例を示す図である。車載ネットワークシステム１００ａは、上記の車載ネットワークシステム１００の一例である。複数の電子制御ユニットであるＥＣＵ１１１、ＥＣＵ１２１、ＥＣＵ１３１、ＥＣＵ１４１、ＥＣＵ１５１、ＥＣＵ１６１、ＥＣＵ１７１、ＥＣＵ１８１、ＥＣＵ１８２、ＥＣＵ１８４、ＥＣＵ１９１、および、ゲートウェイ１０１が車載ネットワークで接続されている。ここで、車載ネットワークは、ＣＡＮであってもよいし、Ｅｔｈｅｒｎｅｔ（登録商標）であってもよいし、ＣＡＮとＥｔｈｅｒｎｅｔが混在していてもよい。

車載ネットワークには、例えば、エンジン１１０、トランスミッション１２０、および、図示しないモータ、燃料、電池の制御に関連する駆動系のＥＣＵが接続されている。図３に示すように、車載ネットワークには、エンジン１１０用のＥＣＵ１１１およびトランスミッション１２０用のＥＣＵ１２１が接続されている。

また、車載ネットワークには、ブレーキ１３０およびステアリング１４０などの曲がる、止まるに関連するシャーシ系ＥＣＵが接続されている。図３に示すように、車載ネットワークには、ブレーキ１３０用のＥＣＵ１３１ステアリング１４０用のＥＣＵ１４１が接続されている。

また、車載ネットワークには、自動ブレーキ１５０、車線維持装置１６０、および、図示しない車間距離機能、衝突防止機能、エアバッグなどの安全快適機能系ＥＣＵが接続されている。図３に示すように、車載ネットワークには、自動ブレーキ１５０用のＥＣＵ１５１と、車線維持装置１６０用のＥＣＵ１６１とが接続されている。

また、車載ネットワークには、車車間通信装置１７０などに関連する通信系ＥＣＵが接続されている。図３に示すように、車載ネットワークには、車車間通信装置１７０用のＥＣＵ１７１が接続されている。車車間通信装置１７０は、他の車両からコンテンツデータを取得する。ＥＣＵ１７１は、取得したコンテンツデータを用いて自動運転などの動作処理を行う。

また、車載ネットワークには、ヘッドユニット１８０などインフォテイメント系ＥＣＵが接続されている。図３に示すように、車載ネットワークには、ヘッドユニット１８０用のＥＣＵ１８１が接続されている。なお、ヘッドユニット１８０用のＥＣＵ１８１がなく、ヘッドユニット１８０がＥＣＵ１８１を介さず直接車載ネットワークに接続されていてもよい。

また、車載ネットワークには、高度道路交通システムであるＩＴＳ（Intelligent Transport Systems）装置１９０用のＥＣＵ１９１が接続されている。図３に示すように、車載ネットワークには、ＩＴＳ装置１９０用のＥＣＵ１９１が接続されている。ＩＴＳ装置１９０は、道路情報だけでなく、道路および建物などの静的な地物を載せた地図データなどを外部のサーバから受信する。またＩＴＳ装置１９０は、センサ情報およびＧＰＳ（Global Positioning Syastem）による位置情報、カメラの画像情報などを外部のサーバに送信することで、外部のサーバが道路状況などの確認ができる。

また、車載ネットワークには、ウィンドウ開閉センサ１８３、ドア開閉センサ１８５およびＧＰＳセンサ１８７などが接続されている。図３に示すように、車載ネットワークには、ウィンドウ開閉センサ１８３用のＥＣＵ１８２と、ドア開閉センサ１８５用のＥＣＵ１８４と、ＧＰＳセンサ１８７用のＥＣＵ１８６とが接続されている。なお、図示しない各種センサおよびカメラの画像情報なども車載ネットワークには接続されている。

このような複数の電子制御ユニットは、接続されたものの状態等を取得し、定期的に取得した状態等を表すフレームを車載ネットワークに送信する。

［１．２ データフレームフォーマット］
図４は、ＣＡＮプロトコルのデータフレームのフォーマットを示す図である。ここではＣＡＮプロトコルにおける標準ＩＤフォーマットにおけるデータフレームを示している。

図４に示すように、データフレームは、Start Of Frame（以下、ＳＯＦ）と、ＩＤフィールド、Remote Transimission Request（以下、ＲＴＲ）、Identifier Extension（以下、ＩＤＥ）、予約ビット（ｒ）、データレングスコード（以下、ＤＬＣ）、データフィールド、Cycric Redundancy Check（以下、ＣＲＣ）シーケンス、ＣＲＣデリミタ（図中、左のＤＥＬ）と、Acknowledgement（以下、ＡＣＫ）スロットと、ＡＣＫデリミタ（図中、右のＤＥＬ）と、エンドオブフレーム（以下、ＥＯＦ）とから構成される。

ＳＯＦは、１ビットのドミナントである。バスがアイドルのときはレセシブになっている。送信ノードはバスをレセシブからドミナントへ変更することでフレームの送信開始を通知する。

ＩＤは、１１ビット長の値で、データフレームの種類を示す。ここでいうデータフレームの種類とは、例えばデータの内容またはデータフレームの送信元である送信ノードを指す。また、ＩＤは、同一ネットワーク上で複数のノードが同時にデータフレームの送信を開始した場合の通信調停にも用いられる。より具体的には、ＩＤがより小さい値を持つデータフレームはより優先されて送信される。

ＲＴＲは、１ビットのドミナントで、データフレームであることを示す。

ＩＤＥおよびｒは、それぞれ１ビットのドミナントである。

ＤＬＣは、４４ビット長の値で、続くデータフィールドの長さを示す。

データフィールドは、最大６４ビット長で送信されるデータの部分であり、データフレームのペイロードである。長さは８ビット単位で調整可能である。送信されるデータの部分への割り当てに関する仕様は、車種および製造者の少なくとも一方に依存する。

ＣＲＣシーケンスは、１５ビット長で、ＳＯＦ、ＩＤフィールド、コントロールフィールド、および、データフィールドの送信値より算出される値を示す。受信ノードは、各データフレームについてＳＯＦ、ＩＤフィールド、コントロールフィールド、および、データフィールドの受信値から算出した結果をＣＲＣシーケンスの値と比較することで異常の有無を判断する。

ＣＲＣデリミタは、１ビットのレセシブで、ＣＲＣシーケンスの終了を表す区切り記号である。

ＡＣＫスロットは、１ビット長であり、送信ノードはこの部分でレセシブを送信する。受信ノードはＣＲＣシーケンスまで正常に受信ができていれば、この部分でドミナントを送信する。ＣＡＮの規格では、同時に送信されたドミナントとレセシブとでは上述のとおりドミナントが優先される。そのため、通信が正常に行われている車載ネットワークシステムでは、ＡＣＫスロットの送信中、バスはドミナントの状態である。

ＡＣＫデリミタは、１ビット長さのレセシブで、ＡＣＫスロットの終了を表す区切り記号である。

ＥＯＦは、７ビット長さのレセシブで、データフレームの終了を示す。

［１．３ メッセージ認証コード（ＭＡＣ）の送信］
図５は、ＣＡＮ通信におけるＭＡＣの送信方法の一例を示す図である。図５の（ａ）には、ＣＡＮ通信に用いられるデータフレームが示され、図４と同一となっている。図５の（ｂ）には、ＭＡＣの送信に用いられる検証用データフレームが示されている。

図５の（ｂ）に示すように、ＭＡＣは、図５の（ａ）に示す通常のデータフレームのデータフィールドをＭＡＣとした検証用データフレームにより送信される。つまり、通常のデータフレームに続けて、当該データフレームおけるデータフィールドをＭＡＣとした検証用データフレームを送信する。より具体的には、複数の電子制御ユニットのうちの一である第１電子制御ユニットが、ＣＡＮプロトコルに従ってバスを介して、データとしてデータフレーム、および、データに付加されるＭＡＣとしてデータフレームのデータフィールドをＭＡＣとした検証用データフレームの送信を行う。

なお、詳細は後述するが、第１電子制御ユニットが、データフレームを識別するためのＩＤと送信カウンタによりカウントされたデータフレームの送信回数とを少なくとも結合した値に対して、ＭＡＣ鍵を用いてＭＡＣを生成する。また、複数の電子制御ユニットのうちの第１電子制御ユニット以外の複数の電子制御ユニットの少なくとも一である第２電子制御ユニットが、第１電子制御ユニットにより送信されたデータフレーム、および、検証用データフレームを、バスを介して受信する。そして、第２電子制御ユニットが、検証用データフレームを受信して得たＭＡＣと、受信したデータフレームに対応するＩＤと、受信カウンタによりカウントされたデータの受信回数とを少なくとも結合した値に対して、ＭＡＣ鍵を用いて生成したＭＡＣとの同一性を検証する。

なお、検証用フレームは、データフレームに付加されるＭＡＣの一例であり、これに限られない。データフレームに付加されるＭＡＣとしては、通常のデータフレームにＭＡＣを追加する方法であってもよい。例えばデータフィールドの８バイトのうち、４バイトのみデータの送信用として用いられる場合、データフィールドの残りの４バイトに、ＭＡＣ値の１６バイトのうち、上位または下位の４バイトのみを付加される場合が考えられる。また、データフィールドの残りの４バイトに、ＭＡＣ値の１６バイトのうち、１バイトのみを付加する場合も考えられる。

図６は、イーサネット（登録商標）通信におけるＭＡＣの送信方法の一例を示す図である。図６の（ａ）には、イーサネット（登録商標）通信において送信される情報の固まりであるＭＡＣフレーム(Media Access Control Frame)が示されている。ＭＡＣフレーム（以下、フレームともいう）は、イーサネット（登録商標）通信において送信すべき通信データが一定の長さ以下に分割されたデータと、ヘッダ、送信元アドレスおよび送信先アドレス等とを含む、決められた形式による情報の固まりである。図６の（ｂ）には、ＭＡＣの送信に用いられるＭＡＣフレームの一例が示されている。つまり、ＭＡＣフレームをＡＥＳなどの暗号方式で鍵（ＭＡＣ鍵と呼ぶ）を用いて暗号化したものをメッセージ認証コード（つまりＭＡＣ）としてペイロード部分に含めてＭＡＣフレームを送信することでＭＡＣを送信する。より具体的には、複数の電子制御ユニットのうちの一である第１電子制御ユニットが、ＭＡＣフレームに付加されるＭＡＣとしてペイロード部分にＭＡＣを含めて、ＭＡＣフレームの送信を行う。

なお、第１電子制御ユニットが、ＭＡＣフレームに付加された送信元アドレスおよび送信先アドレスと送信カウンタによりカウントされたＭＡＣフレームの送信回数とを少なくとも結合した値に対してＭＡＣ鍵を用いＭＡＣを生成する。また、複数の電子制御ユニットのうちの第１電子制御ユニット以外の複数の電子制御ユニットの少なくとも一である第２電子制御ユニットが、第１電子制御ユニットにより送信されたＭＡＣフレームを受信する。そして、第２電子制御ユニットが、ペイロード部分にＭＡＣが含まれたフレームを受信して得たＭＡＣと、受信した当該ＭＡＣフレームに付加された送信元アドレスおよび送信先アドレスと受信カウンタによりカウントされたＭＡＣフレームの受信回数とを少なくとも結合した値に対して、ＭＡＣ鍵を用いて生成したＭＡＣとの同一性を検証する。

なお、図６の（ｂ）にはＭＡＣフレームのペイロードにおけるデータ部分を暗号化した場合の例が示されているが、データ部分を暗号化することは必須ではない。また、ＭＡＣフレームに、その種類等を識別するためのＩＤが付加または含まれる場合には、ＭＡＣフレームに付加された送信元アドレスおよび送信先アドレスに代えて、ＭＡＣフレームを識別するためのＩＤと送信カウンタによりカウントされたデータフレームの送信回数とを少なくとも結合した値に対して、ＭＡＣ鍵を用いてＭＡＣを生成してもよいのはいうまでもない。

［１．４ ＥＣＵ１１１の構成］
図３に示す車載ネットワークに接続されるＥＣＵ１１１が、鍵更新管理装置１０として機能する場合について、以下説明する。

図７は、本実施の形態におけるＥＣＵ１１１の機能構成を示すブロック図である。

ＥＣＵ１１１は、車両に搭載される車載ネットワークに接続される電子制御ユニットであって、ＣＰＵ（Central Processing Unit）とメモリとを有する。ＥＣＵ１１１は、図７に示すように、フレーム送受信部１１１１と、フレーム解釈部１１１２と、受信ＩＤ判断部１１１３と、受信ＩＤリスト保持部１１１４と、フレーム処理部１１１５と、車体状態保持部１１１６と、判定ルール保持部１１１７と、タイマー１１１８と、鍵更新判定部１１１９と、更新処理部１１２０と、ＭＡＣ鍵保持部１１２１と、カウンタ保持部１１２２と、ＭＡＣ生成部１１２３と、フレーム生成部１１２４と、データ取得部１１２５とを備える。なお、車体状態保持部１１１６、判定ルール保持部１１１７、タイマー１１１８および鍵更新判定部は、鍵更新処理判定部１３の一例である鍵更新処理判定部１３ａを構成する。また、更新処理部１１２０、ＭＡＣ鍵保持部１１２１、カウンタ保持部１１２２およびＭＡＣ生成部１１２３は、鍵更新部１２の一例である鍵更新部１２ａを構成する。

これらの各構成要素は、機能的な構成要素であり、その各機能は、ＥＣＵ１１１における通信回路、メモリに格納された制御プログラムを実行するプロセッサあるいはデジタル回路等により実現される。なお、ＥＣＵ１３１〜ＥＣＵ１９１も同様の構成を備え、鍵更新管理装置１０として機能する。また、以下では、車載ネットワークがＣＡＮであるとして説明する。

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

＜フレーム解釈部１１１２＞
フレーム解釈部１１１２は、フレーム送受信部１１１１により転送されて受け取ったフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。

フレーム解釈部１１１２は、ＩＤフィールドと解釈した値を受信ＩＤ判断部１１１３へ通知する。フレーム解釈部１１１２は、受信ＩＤ判断部１１１３から通知される判定結果に応じて、ＩＤフィールドの値と、ＩＤフィールド以降に現れるデータフィールドの値とを、フレーム処理部１１１５に転送する、または、当該判定結果が通知された以降において解釈を中止することでフレームの受信を中止する。

フレーム解釈部１１１２は、ＩＤフィールド以降に現れるデータフィールドの値をフレーム処理部１１１５に転送する場合、その後に受け取ったフレームの値から解釈したデータフレーム内のＡＣＫスロットの内容をフレーム処理部１１１５へ通知する。

一方、フレーム解釈部１１１２は、受け取ったフレームの値から、当該フレームがＣＡＮプロトコルに則っていないフレームであると解釈した場合、フレーム生成部１１２４にエラーフレームを送信する旨の指示を通知する。

フレーム解釈部１１１２は、受け取ったフレームの値から、当該フレームがエラーフレームであると解釈した場合、それ以降は、当該フレームの解釈を中止し、当該フレームを破棄する。

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

＜受信ＩＤリスト保持部１１１４＞
受信ＩＤリスト保持部１１１４は、ＥＣＵ１１１が受信するＩＤ（メッセージＩＤ）のリストである受信ＩＤリストを保持する。受信ＩＤリストの一例を図８を用いて説明する。

図８は、本実施の形態における受信ＩＤリストの一例を示す図である。図８には、例えば、ＥＣＵ１１１、ＥＣＵ１３１、ＥＣＵ１８２、ＥＣＵ１８４およびＥＣＵ１８６が受信するメッセージＩＤリストの一例が示されており、メッセージＩＤ「１」、「２」、「３」、「４」を受信する設定が表されている。

＜フレーム処理部１１１５＞
フレーム処理部１１１５は、フレーム解釈部１１１２より受信した全てのデータフレームに付加される、改ざん防止のコードであるＭＡＣを検証する。このＭＡＣの検証は、データフレーム（メッセージ）の正当性を検証する意義を有する。

例えば、フレーム処理部１１１５は、受信したデータフレームのメッセージＩＤに対応したＭＡＣ鍵をＭＡＣ鍵保持部１１２１より取得し、当該メッセージＩＤに対応したカウンタ値をカウンタ保持部１１２２より取得することで、当該データフレームに続いて受信した検証用データフレームのデータフィールドに含まれるＭＡＣを検証する。

具体的には、フレーム処理部１１１５は、検証用データフレームを受信して得たＭＡＣと、受信したデータフレームに対応するＩＤと、受信カウンタによりカウントされたデータの受信回数とを少なくとも結合した値に対して、ＭＡＣ鍵を用いて生成したＭＡＣとの同一性を検証する。本実施の形態では、フレーム処理部１１１５は、まず、ＭＡＣ生成部１１２３と同様の方法（後述）を用いて、ＭＡＣを計算により生成し、続いて、生成したＭＡＣと当該検証用データフレームのデータフィールドに含まれるＭＡＣとを比較する。そして、フレーム処理部１１１５は、両ＭＡＣが一致すれば検証に成功したと判定し、一致しなければ検証に失敗した、つまりエラーと判定する。フレーム処理部１１１５は、エラーと判定すれば、フレーム解釈部１１１２へ通知して、以降の受信処理を中止する。

このように、フレーム処理部１１１５は、ＭＡＣの検証を行うので、バスに接続された不正ＥＣＵにより送信された不正なフレームを受信したとしてもエラーと判定し受信処理を中止できるので、不正なフレームによる車両の制御等を阻止することができる。

また、フレーム処理部１１１５は、車両の状態（以降、車両状態）および／または走行情報を通知するフレームを受信した場合、車体状態保持部１１１６に受信した車両状態および／または走行情報を通知する。

ここで、車両状態は、例えば、「走行中」、「停車中」または「駐車中」であり、車両が走行中か走行中に移り得る状態かを示す。車両状態は、例えば、トランスミッション１２０に接続されるＥＣＵ１２１が、トランスミッション１２０から得た例えばパーキング、ニュートラル、１速、２速などのギアポジションに基づいて特定し、フレームに含めてバスに通知するものでもよい。また、車両状態は、例えば、図３に不図示のＥＣＵが、複数のＥＣＵから通知された情報に基づいて車両状態を特定し、フレームに含めてバスに通知するものでもよい。

走行情報は、車両の走行に関する情報であり、例えばＧＰＳセンサ１８７が取得した位置、または、他のセンサにより検出した車両の走行距離もしくは走行時間でもよいし、ＥＣＵ１１１がエンジン１１０から取得した車速および当該車速の時間などである。このように、フレーム処理部１１１５は、上述した取得部１１の機能を有し、複数の電子制御ユニットの少なくとも一つから送信される車両の走行に関する情報である走行情報を取得する。

また、フレーム処理部１１１５は、受信したフレームのデータに応じた処理を行う。ＥＣＵ１１１が車両の搭乗者に対してアラーム音を鳴らすためのスピーカ等を有するなどアラーム音を鳴らす機能を有しているとする。そして、例えば走行情報またはエンジン１１０等から得た情報により得られる車両の時速が３０ｋｍを超えた状況でドアが開いている旨を示す情報を受信する場合には、フレーム処理部１１１５は、車両の搭乗者に対してアラーム音を鳴らしてもよい。このように、フレーム処理部１１１５は、他のＥＣＵから受信した、例えばドアの状態を通知するデータフレームを管理し、エンジン１１０より得られる車速に基づいて一定条件下でアラーム音を鳴らす処理を行うなど、受信したフレームのデータに応じた処理を行う。なお、フレーム処理部１１１５は、複数のＥＣＵで共通するとして説明したがＥＣＵ毎に異なる処理を行ってもよい。例えば、ブレーキがかかっていない状況でドアが開いた場合に、ＥＣＵ１８４は、車両の搭乗者に対してアラーム音を鳴らす処理を行う一方で、ＥＣＵ１３１、ＥＣＵ１８２等は、アラーム音を鳴らす処理を行わないとしてもよい。ＥＣＵ１１１〜ＥＣＵ１８６は、アラーム音を鳴らす機能以外の機能をそれぞれ備えてもよいし備えないでもよい。

また、フレーム処理部１１１５は、フレーム解釈部１１１２より受信したデータフレーム内のＡＣＫスロットの値を確認し、フレーム送受信部１１１１から送信したフレームが、他のＥＣＵで正常に受信されているかどうかを確認する。そして、フレーム処理部１１１５は、確認した結果を更新処理部１１２０に通知する。

＜車体状態保持部１１１６＞
車体状態保持部１１１６は、フレーム処理部１１１５より通知された現在の車両状態および現在の走行状態を保持する。この結果、車体状態保持部１１１６は、現在までに通知された車両状態および走行情報を保持することになる。具体的には、車体状態保持部１１１６は、車両状態として、上述したが例えば「走行中」、「停車中」、「駐車中」を保持する。また、走行情報として、上述したが例えば走行距離、車速、および車両の位置を示すＧＰＳ情報を保持する。

車体状態保持部１１１６は、走行情報により得られる走行距離であってＭＡＣ鍵の前回の更新時からの車両の走行距離が閾値を超えた状態になった場合に、鍵更新判定部１１１９に通知する。ここで、走行情報により得られる走行距離は、他のセンサにより検出した車両の走行距離でもよいし、ＧＰＳセンサ１８７が取得した位置により計算される移動距離でもよいし、エンジン１１０から取得した車速および当該車速の時間から計算される距離でもよい。

＜判定ルール保持部１１１７＞
判定ルール保持部１１１７は、鍵更新判定部１１１９により用いられる判定ルールを保持する。ここで、判定ルールは、更新処理部１１２０が更新処理を実行する条件を満たしたか否かを判定するためのルールである。以下、判定ルールの一例を図９Ａおよび図９Ｂを用いて説明する。

図９Ａおよび図９Ｂは、本実施の形態における判定ルールの一例を示す図である。図９Ａには車両状態に応じた判定ルールの一例が示され、図９Ｂには走行情報に応じた判定ルールの一例が示されている。

図９Ａでは、車両状態が「走行中」または「停車中」である場合、更新処理を実施しない判定ルールが示されている。一方、車両状態が「駐車中」である場合、更新処理を実施する判定ルールが示されている。つまり、図９Ａに示す判定ルールによれば、例えば車両状態が「走行中」または「停車中」であるとき、ＭＡＣ鍵更新の更新タイミングが到来しても更新処理部１１２０が更新処理を実行する条件を満たさないと判定され、更新処理されない。そして、車両状態が「駐車中」に変わったときに、更新処理部１１２０が更新処理を実行する条件を満たすと判定され、更新処理が実行される。また、車両状態が「駐車中」であるときに、ＭＡＣ鍵更新の更新タイミングが到来すれば更新処理部１１２０が更新処理を実行する条件を満たすと判定される。

図９Ｂでは、車両の走行距離が閾値Ｄ１以下であれば更新処理を実施せずに、閾値Ｄ１より上であれば更新処理を実施する判定ルールが示されている。また、ＧＰＳによる車両の移動距離が閾値Ｄ２以下であれば更新処理を実施せず、閾値Ｄ２より上であれば更新処理を実施する判定ルールが示されている。なお、ＧＰＳによる車両の移動距離は、走行情報に含まれるＧＰＳセンサ１８７が取得した位置により得られる。つまり、ＧＰＳによる車両の移動距離は、走行情報により得られる車両の走行距離に含まれるとしてもよい。このように、車両の走行距離が閾値Ｄ１以下、または、ＧＰＳによる車両の移動距離が閾値Ｄ２以下であれば、更新処理部１１２０が更新処理を実行する条件を満たさないと判定され、更新処理されない。車両の走行距離が閾値Ｄ１より上、または、ＧＰＳによる車両の移動距離が閾値Ｄ２より上であれば、ＭＡＣ鍵更新の更新タイミングが到来する前であっても更新処理部１１２０が更新処理を実行する条件を満たすと判定され、更新処理される。

なお、更新処理部１１２０が更新処理を実行する条件を満たしたか否かの判定は、車両状態と走行情報の判定ルールのいずれかの判定ルールに従って行うとしてもよいし、車両状態と走行情報の両方の判定ルールに従って行うとしてもよい。

例えば、図９Ａに示す車両状態と図９Ｂに示す走行情報の両方の判定ルールに従って、例えば車両状態が走行中、または、走行距離が閾値Ｄ１以下の場合には、更新処理部１１２０が更新処理を実行する条件を満たさないと判定され、更新処理がされないとしてもよい。

また、車両状態の判定ルールと走行状態の判定ルールとが、相反する等で異なり、更新処理の判定ができない場合は、更新処理部１１２０が更新処理を実行する条件を満たしていないと判定されるとしてもよい。

＜タイマー１１１８＞
タイマー１１１８は、経過時間に対応するタイマー値のカウントアップを繰り返す計時機構である。タイマー１１１８は、ＭＡＣ鍵の前回の更新処理完了時からの経過時間を鍵更新判定部１１１９へ通知する。また、タイマー１１１８は、鍵更新判定部１１１９からの更新処理の完了通知に基づいて、タイマー値のリセットを行う。

＜鍵更新判定部１１１９＞
鍵更新判定部１１１９は、更新処理部１１２０が更新処理を実行する条件を満たしているか否かを判定する。また、鍵更新判定部１１１９は、ＭＡＣ鍵更新の更新タイミングが到来したかを判定してもよい。ここで、更新タイミングとは、予め定められた一定時間（例えば６時間、１日等）が経過したタイミングであり、タイマー１１１８に基づき、判定される。更新処理部１１２０が更新処理を実行する条件とは、走行情報により得られる車両の走行に関する状態が所定状態であることを満たすことである。所定状態とは、ＭＡＣ鍵更新の更新タイミングが到来する前であれば、走行情報により得られる車両の走行距離であってＭＡＣ鍵の前回の更新時からの車両の走行距離が閾値を超えた状態である。または、所定状態とは、ＭＡＣ鍵更新の更新タイミングが到来した後であれば、車両の状態が駐車中である状態である。

本実施の形態では、鍵更新判定部１１１９は、タイマー１１１８に基づき、予め定められた更新タイミングが到来したとき、車体状態保持部１１１６から現在の車両状態を取得し、判定ルール保持部１１１７から取得した判定ルールに応じて、更新処理部１１２０が更新処理を実行する条件を満たすか否かを判定する。ここで、更新処理とは、ＭＡＣ鍵の更新処理を少なくとも含み、ＭＡＣの生成に利用されるデータの更新に関連する更新処理も含む。より具体的には、更新処理は、ＭＡＣを生成するために用いる鍵であるＭＡＣ鍵の値を更新する鍵更新処理と、ＭＡＣに反映するカウンタ値をリセット（つまりゼロ等の特定値に更新）するカウンタリセット処理とを意味する。

そして、この場合、鍵更新判定部１１１９は、更新処理部１１２０が更新処理を実行する条件を満たすと判定したとき、更新処理部１１２０へその旨を通知する。一方、鍵更新判定部１１１９は、更新処理部１１２０が更新処理を実行する条件を満たさないと判定したときには、車両状態の変化を待つ。

また、鍵更新判定部１１１９は、予め定められた更新タイミングが到来していなくても、車体状態保持部１１１６から現在を含む走行情報を取得し、判定ルール保持部１１１７から取得した判定ルールに応じて、更新処理部１１２０が更新処理を実行する条件を満たすか否かを判定する。鍵更新判定部１１１９は、更新処理部１１２０が更新処理を実行する条件を満たすと判定したとき、更新処理部１１２０へその旨を通知する。一方、鍵更新判定部１１１９は、更新処理部１１２０が更新処理を実行する条件を満たさないと判定したときには、予め定められた更新タイミングが到来するまで待って、車両状態に基づく判定を行えばよい。

また、鍵更新判定部１１１９は、更新処理が完了した場合、タイマー１１１８にタイマー値のリセットを行わせるために、タイマー１１１８に更新処理の完了通知を通知する。

＜更新処理部１１２０＞
更新処理部１１２０は、鍵更新判定部１１１９からの通知に従って更新処理を行う。すなわち、更新処理部１１２０は、走行情報により得られる車両の走行に関する状態が所定状態であることを条件として、ＭＡＣ鍵を更新する更新処理を行う。

例えば更新処理部１１２０は、当該所定状態であるという鍵更新処理を実行する条件を満たしたタイミングを通知することで、自ＥＣＵ１１１を含む複数のＥＣＵすべてにＭＡＣ鍵を同一のタイミングで更新させる鍵更新処理を行ってもよい。つまり、更新処理部１１２０は、複数のＥＣＵのすべてが、上記条件を満たした同一のタイミングで、ＭＡＣ鍵を用いて新たなＭＡＣ鍵を生成するとしてもよい。そして、更新処理部１１２０は、上記条件を満たした同一のタイミングで送信カウンタおよび受信カウンタをリセットしてもよい。

また、例えば鍵更新部１２は、上記条件を満たしたときに、ＭＡＣ鍵を用いて新たなＭＡＣ鍵を生成するとしてもよい。そして、鍵更新部１２は、上記条件を満たしたタイミングにおいて生成した新たなＭＡＣ鍵を、自ＥＣＵ１１１を除く複数のＥＣＵすべてに配布することにより、複数のＥＣＵすべてにＭＡＣ鍵を同一のタイミングで更新させる鍵更新処理を行ってもよい。同様に、更新処理部１１２０は、上記条件を満たした同一のタイミングで送信カウンタおよび受信カウンタをリセットしてもよい。

本実施の形態では、更新処理部１１２０は、鍵更新判定部１１１９から更新処理部１１２０が更新処理を実行する条件を満たすと判定した旨の通知を受けて、新たにＭＡＣ鍵候補となる鍵を生成し、ＭＡＣ鍵保持部１１２１へ通知する。また、更新処理部１１２０は、当該通知を受けて、カウンタ保持部１１２２に対し、カウンタ値をリセットするよう通知する。なお、更新処理部１１２０は、当該通知を受けたとき、ＭＡＣ鍵保持部１１２１が保持していたＭＡＣ鍵を取得して旧鍵としてキャッシュ（つまり一時的に記憶媒体に保持）するとともに、カウンタ保持部１１２２が保持しているカウンタ値を取得してキャッシュする。

更新処理部１１２０は、ＭＡＣ鍵の更新が複数のＥＣＵのうち一つでも成功しなかった場合、キャッシュしている旧鍵であるＭＡＣ鍵をＭＡＣ鍵保持部１１２１へ通知し、キャッシュしているリセット前のカウンタ値をカウンタ保持部１１２２へ通知する。

一方、更新処理部１１２０は、ＭＡＣ鍵の更新が複数のＥＣＵすべてで成功した場合、キャッシュしている旧鍵であるＭＡＣ鍵と、リセット前のカウンタ値を削除する。なお、これらの削除は、一時的に保持していたこれらの値を以後使用できないものと扱うことができれば、図示しない一時記憶装置に記憶されている値の削除に限らない。

なお、更新処理部１１２０は、ＭＡＣ鍵の生成方法として、例えば、旧鍵となる現在のＭＡＣ鍵を、例えばハッシュ関数等の予め定められた一方向関数に入力することで導出される結果を新たなＭＡＣ鍵候補とする方法を用いればよい。

＜ＭＡＣ鍵保持部１１２１＞
ＭＡＣ鍵保持部１１２１は、メモリ等の記憶媒体により実現され、ＭＡＣ鍵を、メッセージＩＤ毎に１つ保持する。保持されるＭＡＣ鍵は、上述したように、ＭＡＣ生成部１１２３およびフレーム処理部１１１５がＭＡＣを計算する際に必要となる。また、ＭＡＣ鍵保持部１１２１は、更新処理部１１２０からの通知に従って、これまで持っていたＭＡＣ鍵を破棄し、通知された新たなＭＡＣ鍵を保持することでＭＡＣ鍵を更新する。

＜カウンタ保持部１１２２＞
カウンタ保持部１１２２は、メモリ等の記憶媒体を含んで実現され、カウンタ値を、メッセージＩＤ毎に１つ保持する。カウンタ保持部１１２２は、更新処理部１１２０からの通知に従って、通知されたカウンタ値を保持し、また、更新処理部１１２０からのリセットすべき旨の通知に従って、保持しているカウンタ値をリセットする。このリセットによりカウンタ値は、ゼロ等の特定値に更新される。

ここで、カウンタ値は、ＭＡＣ生成部１１２３およびフレーム処理部１１１５がＭＡＣを計算する際に必要となる。また、カウンタ値は、フレーム送受信部１１１１からフレームが正常に送信された場合にインクリメント（１増加）される。カウンタ値は、フレーム送受信部１１１１からデータフレームが送信される場合においては送信カウンタとして扱われ、送信回数がカウントされる。また、カウンタ値は、フレーム送受信部１１１１でデータフレームを受信する場合においては受信カウンタとして扱われ、受信回数がカウントされる。

カウンタ保持部１１２２は、例えばメッセージＩＤが「１」のデータフレームをフレーム送受信部１１１１から送信する場合、保持するカウンタ値のうちメッセージＩＤが「１」に対応するカウンタ値を送信カウンタとして扱い、正常に１回送信される毎にインクリメントする。

また、カウンタ保持部１１２２は、例えばメッセージＩＤが「１」のデータフレームをフレーム送受信部１１１１で受信する場合、保持するカウンタ値のうちメッセージＩＤが「１」に対応するカウンタ値を、受信カウンタとして扱い、正常に受信される毎にインクリメントする。

＜ＭＡＣ生成部１１２３＞
ＭＡＣ生成部１１２３は、データフレームを識別するためのＩＤと送信カウンタによりカウントされたデータフレームの送信回数とを少なくとも結合した値に対して、ＭＡＣ鍵を用いてＭＡＣを生成する。

本実施の形態では、ＭＡＣ生成部１１２３は、フレーム生成部１１２４より通知されるメッセージＩＤとデータフィールド用のデータの値と、カウンタ保持部１１２２で保持するカウンタ値（つまりメッセージＩＤに対応するカウンタ値）とを結合した値（結合値）を算出する。そして、ＭＡＣ生成部１１２３は、算出した結合値に対し、ＭＡＣ鍵保持部１１２１で保持するＭＡＣ鍵（つまりメッセージＩＤに対応するＭＡＣ鍵）を用いて、ＭＡＣを算出（つまりＭＡＣの値を計算により導出）して、この算出した結果であるＭＡＣをフレーム生成部１１２４へと通知する。

ここで、ＭＡＣの計算方法として、例えば非特許文献１に示されるＨＭＡＣ（Hash-based Message Authentication Code）を採用してもよい。この場合、ＭＡＣ生成部１１２３は、算出した結合値に対し、例えば４バイトの所定のブロック分までパディングした値でＭＡＣ鍵を使って計算し、出てきた計算結果の先頭４バイトをＭＡＣ値とすればよい。

なお、本実施の形態で説明するＭＡＣ値のサイズ、計算方法は一例であり、これに限定されるものではない。また、ＭＡＣは、フレームが送信される毎にインクリメントされるカウンタ値を反映して生成される。つまり、たとえＥＣＵ１１１が同じデータの値を含むデータフレームを複数回送信したとしても、データフレームに付与（つまり付加）されるＭＡＣは送信毎に変化する。

なお、上述したが、車載ネットワークがＥｔｈｅｒｎｅｔ（登録商標）である場合には、フレームには通常ＩＤが付与されず、代わりに送信元アドレスおよび送信先アドレスが付加されている。そのため、フレームに付加された送信元アドレスおよび送信先アドレスと送信カウンタによりカウントされたＭＡＣフレームの送信回数とを少なくとも結合した値に対してＭＡＣ鍵を用いＭＡＣを生成すればよい。

＜フレーム生成部１１２４＞
フレーム生成部１１２４は、フレーム解釈部１１１２から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成してフレーム送受信部１１１１へ通知する。

また、フレーム生成部１１２４は、予め定められたメッセージＩＤとデータ取得部１１２５より通知されたデータの値（データフィールド用のデータの値）とをＭＡＣ生成部１１２３へ通知することによりＭＡＣの通知を受ける。そして、フレーム生成部１１２４は、予め定められたメッセージＩＤと、通知されたＭＡＣと、通知されたデータフィールド用のデータの値とに基づきフレームを構成してフレーム送受信部１１１１へ通知する。

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

［１．５ 送信されるフレームの例］
以下、例えばＥＣＵ１１１、ＥＣＵ１３１、ＥＣＵ１８２、ＥＣＵ１８４およびＥＣＵ１８６のそれぞれが送信するフレームの一例について図１０〜図１４を用いて説明する。

＜ＥＣＵ１１１が送信するフレームの例＞
図１０は、本実施の形態におけるエンジン１１０に接続されたＥＣＵ１１１が送信するメッセージＩＤと、データの一例を示す図である。図１０に示すように、ＥＣＵ１１１が送信するメッセージＩＤは例えば「１」である。そして、ＥＣＵ１１１が送信するデータフィールドの値のうち、先頭１バイトは時速を表し、次の１バイトはカウンタを表し、次の４バイトはＭＡＣ値を表している。時速は最低０ｋｍ〜最高１８０ｋｍまでの範囲を取るとしている。つまり、ＥＣＵ１１１は、時速を表す先頭１バイトの値と、それぞれに対応したカウンタ値とＭＡＣ値とをセットにして６バイトで送信する。図１０では、車両が０ｋｍから１ｋｍずつ加速されている様子が示されている。

＜ＥＣＵ１３１が送信するフレームの例＞
図１１は、本実施の形態におけるブレーキ１３０に接続されたＥＣＵ１３１が送信するメッセージＩＤと、データの一例を示す図である。図１１に示すように、ＥＣＵ１３１が送信するメッセージＩＤは例えば「２」である。そして、ＥＣＵ１３１が送信するデータフィールドの値のうち、先頭１バイトはブレーキのかかり具合を％で表し、次の１バイトはカウンタを表し、次の４バイトはＭＡＣ値を表している。ブレーキを全くかけていない状態を０％とし、ブレーキを最大限かけている状態を１００％としている。つまり、ＥＣＵ１３１は、ブレーキのかかり具合を表す先頭１バイトの値と、それぞれの値に対応したカウンタ値と、ＭＡＣ値とをセットにして６バイトで送信する。図１１では、車両が１００％から徐々にブレーキを弱める様子が示されている。

＜ＥＣＵ１８４が送信するフレームの例＞
図１２は、本実施の形態におけるドア開閉センサ１８５に接続されたＥＣＵ１８４が送信するメッセージＩＤと、データの一例を示す図である。図１２に示すように、ＥＣＵ１８４が送信するメッセージＩＤは例えば「３」である。そして、ＥＣＵ１８４が送信するデータフィールドの値のうち、先頭の１バイトはドアの開閉状態を表し、次の１バイトはカウンタを表し、次の４バイトはＭＡＣ値を表している。ドアが開いている状態を「１」、ドアが閉まっている状態を「０」としている。つまり、ＥＣＵ１８４は、ドアの開閉状態を表す先頭１バイトの値と、それぞれの値に対応したカウンタ値と、ＭＡＣ値とをセットにして６バイトで送信する。図１２では、ドアが開いている状態から、途中で閉められた様子が示されている。

＜ＥＣＵ１８２が送信するフレームの例＞
図１３は、本実施の形態におけるウィンドウ開閉センサ１８３に接続されたＥＣＵ１８２が送信するメッセージＩＤと、データの一例を示す図である。図１３に示すように、ＥＣＵ１８２が送信するメッセージＩＤは例えば「４」である。そして、ＥＣＵ１８２が送信するデータフィールドの値のうち、先頭の１バイトは窓の開閉状態を％で表し、次の１バイトはカウンタを表し、次の４バイトはＭＡＣ値を表している。窓が閉まっている状態を０％、窓が全開の状態を１００％としている。つまり、ＥＣＵ１８２は、窓の開閉状態を表す先頭１バイトの値と、それぞれに対応したカウンタ値と、ＭＡＣ値とをセットにして６バイトで送信する。図１３では、窓が閉まっている状態から、徐々に開いていく様子が示されている。

＜ＥＣＵ１８６が送信するフレームの例＞
図１４は、実施の形態におけるＧＰＳセンサ１８７に接続されたＥＣＵ１８６が送信するメッセージＩＤと、データの一例を示す図である。図１４に示すように、ＥＣＵ１８２が送信するメッセージＩＤは例えば「５」である。そして、ＥＣＵ１８６が送信するデータフィールドの値のうち、先頭の３バイトはＧＰＳの差分を表し、次の１バイトはカウンタを表し、次の４バイトはＭＡＣ値を表す。つまり、ＥＣＵ１８６は、前回の位置からの差分値と、カウンタ値と、ＭＡＣ値とをセットとして８バイトで送信する。

［１．６ 更新処理］
次に、車載ネットワークシステム１００の動作について説明する。

図１５は、本実施の形態における更新処理方法を示すフローチャートである。以下では、車載ネットワークシステム１００を構成する鍵更新管理装置１０が更新処理を行うとして説明するが、これに限らない。各ＥＣＵが更新処理を行ってもよいし、全ＥＣＵの一が鍵更新管理装置１０として更新処理を行うとしてもよいし、車載ネットワークシステム１００ａを構成するゲートウェイ１０１が更新処理を行うとしてもよい。

まず、鍵更新管理装置１０は、複数の電子制御ユニットの少なくとも一つから送信される、車両の走行に関する情報である走行情報を取得する（Ｓ１０）。

次に、鍵更新管理装置１０は、走行情報により得られる車両の走行に関する状態が所定状態であるという条件を満たすか否かを判定する（Ｓ１１）。

ステップＳ１１において、上記の条件を満たせば（Ｓ１１でＹ）、鍵更新管理装置１０は、車載ネットワークシステム１００において授受されるデータに付加されるＭＡＣ（メッセージ認証コード）であって改ざん防止のコードであるＭＡＣの生成に利用される鍵であるＭＡＣ鍵を更新する（Ｓ１２）。なお、ステップＳ１１において、上記の条件を満たさない場合（Ｓ１１でＮ）、ステップＳ１０に戻る。

図１６は、図１５に示すステップＳ１１の詳細処理を示すフローチャートである。以下では、車載ネットワークシステム１００ａを構成する複数のＥＣＵの一であるＥＣＵ１１１が鍵更新管理装置１０として更新処理を実行する場合を例に挙げて説明する。

ステップＳ１１において、ＥＣＵ１１１は、内部に持つタイマー１１１８により、前回の更新処理完了時からの経過時間を確認する（Ｓ１１０１）。

次に、ＥＣＵ１１１は、前回の更新処理完了時から予め定められた一定時間経過しているかどうかを判定する（Ｓ１１０２）。より具体的には、ＥＣＵ１１１は、タイマー１１１８がカウントする経過時間に基づき、ＭＡＣ鍵更新の更新タイミングが到来したかを判定する。

ステップＳ１１０２において、前回の更新処理完了時から一定時間が経過していない場合（Ｓ１１０２でＮ）、ＥＣＵ１１１は、前回の更新処理完了時から車両が走行した距離を確認する（Ｓ１１０３）。より具体的には、ＥＣＵ１１１は、走行情報により得られる車両の走行距離であってＭＡＣ鍵の前回の更新時からの車両の走行距離を確認する。

次に、ＥＣＵ１１１は、前回の更新処理完了時から車両が走行した距離があらかじめ定められた閾値より大きいかを判定する（Ｓ１１０４）。例えば図９Ｂに示すような判定ルールに従い、ＥＣＵ１１１は、前回の更新処理完了時から車両が走行した距離が閾値より大きいかを判定する。

ステップＳ１１０４において、ＥＣＵ１１１は、前回の更新処理完了時から車両が走行した距離が閾値以下の場合（Ｓ１１０４でＮ）、Ｓ１１０１へ戻る。

一方、ステップＳ１１０４において、ＥＣＵ１１１は、前回の更新処理完了時から車両が走行した距離が閾値より大きい場合（Ｓ１１０４でＹ）、ステップＳ１１の処理を終了し、図１５に示すステップＳ１２に進む。なお、ステップＳ１１０４において、前回の更新処理完了時から車両が走行した距離が閾値以下の場合（Ｓ１１０４でＮ）、ＥＣＵ１１１は、図１５に示すステップＳ１０に戻る。

また、ステップＳ１１０２において、前回の更新処理完了時から一定時間が経過している場合（Ｓ１１０２でＹ）、ＥＣＵ１１１は、現在の車両状態を確認し（Ｓ１１０５）、車両が駐車中であるか否かを判定する（Ｓ１１０６）。

車両が駐車中であれば（Ｓ１１０６でＹ）、ＥＣＵ１１１は、ステップＳ１１の処理を終了し、図１５に示すステップＳ１２に進む。一方、車両が駐車中であれば（Ｓ１１０６でＮ）、ＥＣＵ１１１は、ステップＳ１１０５に戻る。

なお、ステップＳ１１０４において、ＥＣＵ１１１は、前回の更新処理完了時から車両が走行した距離が閾値より大きい場合（Ｓ１１０４でＹ）、ステップＳ１１の処理を終了するとしたが、これに限らない。さらに、ステップＳ１１０５およびＳ１１０６の処理を行うとしてもよい。

このように、ＥＣＵ１１１は、現在の車両状態または走行情報により得られる車両の走行距離であってＭＡＣ鍵の前回の更新時からの車両の走行距離から、判定ルール保持部１１１７に保持されている判定ルールに従って更新処理を実行するかどうかを判定することができる。

例えば図９Ａに示した判定ルールに従う場合、ＥＣＵ１１１は、車両状態が「走行中」「停車中」であれば、更新処理を実行しない。一方、車両状態が「駐車中」であれば更新処理を実行する。また、図９Ｂに示した判定ルールに従う場合、ＥＣＵ１１１は、走行情報により得られる車両の走行距離であってＭＡＣ鍵の前回の更新時からの車両の走行距離が閾値Ｄ１以下であれば、更新処理を実行しない。また、ＧＰＳの移動距離で示される走行距離が閾値Ｄ２以下であれば、更新処理を実行しない。

図１７は、図１５に示すステップＳ１２の詳細処理を示すフローチャートの一例である。図１７でも、図１６と同様に、車載ネットワークシステム１００ａを構成する複数のＥＣＵの一であるＥＣＵ１１１が更新処理を実行する場合を例に挙げて説明する。ここで、図１７には、鍵更新処理を実行する条件を満たしたタイミングにおいて生成した新たなＭＡＣ鍵を、自ＥＣＵ１１１を除く複数のＥＣＵすべてに配布することにより、複数のＥＣＵすべてにＭＡＣ鍵を同一のタイミングで更新させる更新処理が示されている。

図１７に示すように、ステップＳ１２において、ＥＣＵ１１１は、ＭＡＣ鍵保持部１１２１が保持しているＭＡＣ鍵を、旧鍵としてキャッシュする（Ｓ１２０１）。続いて、ＥＣＵ１１１は、生成した鍵をＭＡＣ鍵とする（Ｓ１２０２）。より具体的には、ＥＣＵ１１１は、新たにＭＡＣ鍵候補となる鍵を生成して、ＭＡＣ鍵としてＭＡＣ鍵保持部１１２１に保持する。

次に、ＥＣＵ１１１は、カウンタ保持部１１２２が保持しているカウンタ値を、キャッシュする（Ｓ１２０３）。続いて、ＥＣＵ１１１は、カウンタ保持部１１２２が保持しているカウンタ値をゼロにリセットする（Ｓ１２０４）。

次に、ＥＣＵ１１１は、生成したＭＡＣ鍵を用いてＭＡＣを生成する（Ｓ１２０５）。より具体的には、ＥＣＵ１１１は、予め定められたメッセージＩＤと、データフィールド用のデータ値と、リセット後のカウンタ保持部１１２２が保持しているカウンタ値と、ＭＡＣ鍵保持部１１２１が保持している新たに生成したＭＡＣ鍵とを用いてＭＡＣを生成する。

次に、ＥＣＵ１１１は、生成したＭＡＣ鍵を配布するためのデータフレームである鍵配布フレームを生成してブロードキャストし、続けて更新の同期を確認するためのデータフレームである更新フレームをブロードキャストする（Ｓ１２０６）。より具体的には、まず、ＥＣＵ１１１は、メッセージＩＤとデータフィールド用のデータ値とステップＳ１２０２において生成したＭＡＣ鍵とを含む鍵配布フレームを生成してバスへ送信を行い、自ＥＣＵ１１１を除く複数のＥＣＵすべてに同一タイミングでＭＡＣ鍵を更新させる。続けて、ＥＣＵ１１１は、メッセージＩＤとデータフィールド用のデータ値とステップＳ１２０５において生成したＭＡＣとを含む更新フレームを生成してバスへ送信する。なお、鍵配布フレームを受信した他のＥＣＵは、ＥＣＵ１１１同様に、旧鍵であるＭＡＣ鍵と、リセット前のカウンタ値とをキャッシュしている。

次に、ＥＣＵ１１１は、自ＥＣＵ１１１を除く複数のＥＣＵすべてが更新フレームの受信に成功したかどうかを判定する（Ｓ１２０７）。より具体的には、ＥＣＵ１１１は、ステップＳ１２０６において更新フレームをバスに送信後、自ＥＣＵ１１１を除く複数のＥＣＵすべてが更新フレームの受信に成功（つまり正常に受信）したかどうかを、ＡＣＫスロットの値を見ることで判定する。

ステップＳ１２０７において、自ＥＣＵ１１１を除く複数のＥＣＵすべてが更新フレームの受信に成功したと判定した場合（Ｓ１２０７でＹ）、ＥＣＵ１１１は、キャッシュしていた旧鍵であるＭＡＣ鍵とリセット前のカウンタ値とを破棄して（Ｓ１２０８）、更新処理を終了する。自ＥＣＵ１１１を除く複数のＥＣＵすべてが更新フレームの受信に成功した場合、複数のＥＣＵすべてにおいて新たなＭＡＣ鍵によりＭＡＣ鍵の更新が完了したことがわかるからである。

一方、ステップＳ１２０７において、更新フレームの受信に成功しなかった場合（Ｓ１２０７でＮ）、ＥＣＵ１１１は、キャッシュしておいた旧鍵であるＭＡＣ鍵を、再度ＭＡＣ鍵に設定し（Ｓ１２１０）、キャッシュしておいたリセット前のカウンタ値を再度設定する（Ｓ１２１１）。より具体的には、ＥＣＵ１１１は、更新フレームの受信に失敗したＥＣＵがあった場合、キャッシュしておいた旧鍵であるＭＡＣ鍵をＭＡＣ鍵保持部１１２１に保持させる。また、ＥＣＵ１１１は、キャッシュしておいたリセット前のカウンタ値を、再度カウンタ値としてカウンタ保持部１１２２に保持させる。なお、他のＥＣＵは、ＥＣＵ１１１同様に、キャッシュしておいた旧鍵であるＭＡＣ鍵を、再度ＭＡＣ鍵に設定し、キャッシュしておいたリセット前のカウンタ値を再度設定する。また、更新フレームの受信に成功しなかったＥＣＵがあった場合でも、再度鍵配布フレームをブロードキャストして新たなＭＡＣ鍵を再度配布した上で、更新フレームの受信に失敗したＥＣＵがあったかどうかを判定してもよい。

次に、ＥＣＵ１１１は、再設定したＭＡＣ鍵とカウンタ値を用いてＭＡＣを生成する（Ｓ１２１２）。より具体的には、ＥＣＵ１１１は、予め定められたメッセージＩＤと、データフィールド用のデータ値と、キャッシュから再設定したカウンタ保持部１１２２のカウンタ値と、キャッシュから再設定したＭＡＣ鍵保持部１１２１のＭＡＣ鍵とを用いて、ＭＡＣを生成する。

次に、ＥＣＵ１１１は、更新の同期を確認するためのデータフレームである更新フレームをブロードキャストする（Ｓ１２１３）。より具体的には、ＥＣＵ１１１は、メッセージＩＤとデータフィールド用のデータ値とステップＳ１２１２において生成されたＭＡＣとを含む更新フレームを生成してバスに送信する。

次に、ＥＣＵ１１１は、自ＥＣＵ１１１を除く複数のＥＣＵすべてが更新フレームの受信に成功したかどうかを判定する（Ｓ１２１４）。より具体的には、ＥＣＵ１１１は、ステップＳ１２１３において更新フレームをバスに送信後、自ＥＣＵ１１１を除く複数のＥＣＵすべてが更新フレームの受信に成功したかどうかを、ＡＣＫスロットの値を見ることで判定する。

ステップＳ１２１４において、自ＥＣＵ１１１を除く複数のＥＣＵすべてが更新フレームの受信に成功したと判定した場合（Ｓ１２１４でＹ）、ＥＣＵ１１１は、一定時間待機後、再度更新処理を実施する（Ｓ１２１５）。つまり、ＥＣＵ１１１は、ＭＡＣ鍵の更新が失敗したのは軽微なエラーであったとしてステップＳ１２０１に戻り更新処理を再度行う。

一方、ステップＳ１２１４において、更新フレームの受信に失敗したと判定した場合（Ｓ１２１４でＮ）、ＥＣＵ１１１は、致命的なエラー発生につき処理を中止する（Ｓ１２１６）。ＥＣＵ１１１は、ＭＡＣ鍵の更新が失敗したため、旧鍵に戻したことを確認するために送信した更新フレームの受信が失敗するのは、システム上致命的なエラーとみなせるからである。

なお、更新処理を中止した場合には、ＥＣＵ１１１は、エラー発生について報知、ログの記録等の処理を実行しても良い。また、エラー発生の報知は、他のＥＣＵへのエラー発生を示すデータフレームの送信、ディスプレイ等への表示、音声出力、発光等により、実行され得る。

図１７を用いて、全ＥＣＵの一であるＥＣＵ１１１が新たに生成したＭＡＣ鍵を配布することで新たなＭＡＣ鍵に更新する更新処理について説明したが、それに限らない。複数のＥＣＵのすべてが、所定状態である条件を満たした同一のタイミングで、ＭＡＣ鍵を用いて新たなＭＡＣ鍵を生成することにより、ＭＡＣ鍵を新たなＭＡＣ鍵に更新する更新処理を実行するとしてもよい。これについて図１８を用いて説明する。

図１８は、図１５に示すステップＳ１２の詳細処理を示すフローチャートの別の一例である。図１８でも、図１７と同様に車載ネットワークシステム１００ａを構成する複数のＥＣＵの一であるＥＣＵ１１１が更新処理を実行する場合を例に挙げて説明する。図１７と同様の要素には同一の符号を付しており、詳細な説明は省略する。

図１８では、まず、Ｓ１２１７Ａにおいて、ＥＣＵ１１１は、鍵更新のタイミングを示す通知フレームをブロードキャストする。より具体的には、ＥＣＵ１１１は、所定状態であるという鍵更新処理を実行する条件を満たしたタイミングを通知するために、鍵更新のタイミングを示す通知フレームをバスに送信する。鍵更新のタイミングを示す通知フレームとして、旧鍵である現在のＭＡＣ鍵をデータフィールドに含めて送るとしてもよいし、鍵更新のタイミングを示す旨をデータフィールドに含めて送るとしてもよい。これにより、自ＥＣＵ１１１を含む複数のＥＣＵすべてに同一タイミングでＭＡＣ鍵を更新させることができる。なお、上述したように、鍵更新処理を実行する条件を満たしたタイミングを通知することは必須ではない。ＣＡＮであれば複数のＥＣＵすべてがそれぞれ独立に鍵更新処理を実行する条件を満たしたタイミングを判定しても、同一のタイミングを判定できるので、複数のＥＣＵすべてが同一のタイミングで更新することができるからである。

次に、ＥＣＵ１１１は、ステップＳ１２０１〜Ｓ１２０５を行う。なお、鍵更新のタイミングを示す通知フレーム受信した他のＥＣＵは、ＥＣＵ１１１同様に、旧鍵であるＭＡＣ鍵と、リセット前のカウンタ値とをキャッシュしている。

次に、ＥＣＵ１１１は、Ｓ１２０６Ａにおいて、更新の同期を確認するためのデータフレームである更新フレームをブロードキャストする。より具体的には、ＥＣＵ１１１は、メッセージＩＤとデータフィールド用のデータ値とステップＳ１２０５において生成したＭＡＣとを含む更新フレームを生成してバスへ送信する。

次に、ＥＣＵ１１１は、ステップＳ１２０７Ａにおいて、自ＥＣＵ１１１を除く複数のＥＣＵすべてが更新フレームの受信に成功したかどうかを判定する。

ステップＳ１２０７Ａにおいて、自ＥＣＵ１１１を除く複数のＥＣＵすべてが更新フレームの受信に成功したと判定した場合（Ｓ１２０７ＡでＹ）、ＥＣＵ１１１は、キャッシュしていた旧鍵であるＭＡＣ鍵とリセット前のカウンタ値とを破棄して（Ｓ１２０８）、更新処理を終了する。

一方、ステップＳ１２０７Ａにおいて、更新フレームの受信に成功しなかった場合（Ｓ１２０７ＡでＮ）、ＥＣＵ１１１は、キャッシュしておいた旧鍵であるＭＡＣ鍵を、再度ＭＡＣ鍵に設定し、キャッシュしておいたリセット前のカウンタ値を再度設定する（Ｓ１２１８）。

なお、複数のＥＣＵは更新フレームの受信に成功したかどうかを、ＡＣＫスロットの値を見ることで判定できるので、ＥＣＵ１１１と同様に、複数のＥＣＵはステップＳ１２１８の処理を行う。

次に、ＥＣＵ１１１は、一定時間待機後、再度更新処理を実施する（Ｓ１２１９）。つまり、ＥＣＵ１１１は、ＭＡＣ鍵の更新が失敗したのは軽微なエラーであったとしてステップＳ１２１７に戻り更新処理を再度行う。

なお、どのＥＣＵが更新フレームを送信しても良い。本実施の形態では、例えば、メッセージＩＤ「１」のデータフレームを繰り返し送信するＥＣＵ１１１が、メッセージＩＤ「１」に対応するＭＡＣに係る更新処理を同期させるための更新フレームを送信するとして説明した。

［１．７ 実施の形態の効果］
以上のように、本実施の形態によれば、ＭＡＣ鍵の鍵更新処理、および、カウンタのリセット処理を含む更新処理を、走行距離および／または車の状態に応じて実行することができる。これにより、更新処理を車両の動作に応じて適切な頻度で実行できる。

より具体的には、本実施の形態によれば、車両の走行距離が閾値以下であるかを判定し、走行距離が短い、かつ、車の動作があるまたは予定されている場合に、更新処理をしないと判定することで、走行距離および／または車の状態に応じて更新処理を実行することができる。これにより、過度に更新処理が行われることを抑制できるので、ＣＡＮへの負荷を低減できる。つまり、ＥＣＵにおける鍵の更新処理が効率よく適切に実行され、車載ネットワークシステム全体として、安全な状態を維持することができる。

［２．その他変形例］
なお、本開示を上記実施の形態に基づいて説明してきたが、本開示は、上記実施の形態に限定されないのはもちろんである。以下のような場合も本開示に含まれる。

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

（２）上記実施の形態では、フレームに含まれるＭＡＣのサイズは４バイトに制限するものではなく、送信毎に異なるサイズであってもよい。同様にカウンタサイズも１バイトに制限するものではない。

また、フレームにデータ値、カウンタ値、ＭＡＣ値、データフレームに含まれるその他のフィールドの値全てが含まれている必要はなく、それぞれの組み合わせであっても良い。

また、ＭＡＣサイズは固定のサイズに限定するものではなく、メッセージＩＤ毎に異なるサイズであってもよい。また、複数のメッセージにまたがって送信されるものであっても良い。

（３）上記実施の形態では、カウンタ値を送信毎にインクリメントするとしているが、時刻に応じて自動的にインクリメントされる値であっても良い。また、時刻そのものの値をカウンタの代わりに使用してもよい。

（４）上記実施の形態では、ＣＡＮプロトコルにおけるデータフレームを標準ＩＤフォーマットで記述しているが、拡張ＩＤフォーマットであっても良い。

（５）上記実施の形態では、ＭＡＣ算出のアルゴリズムをＨＭＡＣとしているが、これに限らない。ＣＢＣ−ＭＡＣ、ＣＭＡＣであっても良い。また、ＭＡＣ計算に登場するパディングについては、ゼロパディング、ＩＳＯ１０１２６、ＰＫＣＳ１、ＰＫＣＳ５、ＰＫＣＳ７、その他、データサイズが計算に必要となるパディングの方式であれば何でもよい。

また４バイトへのサイズの変更方法についても、先頭、最後尾、中間、いずれをとっても良い。また、連続している４バイトでなくても、特定のルールに従って１ビットずつ収集して結合しても良い。

（６）上記実施の形態では、更新処理として、ＭＡＣ鍵の更新処理と、カウンタリセットの処理を同時に行っているが、いずれか一方のみ行ってもよい。また、ＭＡＣ鍵の更新処理についても、新たにＭＡＣ鍵更新処理専用の鍵を埋め込んでも良い。

（７）上記実施の形態では、ＭＡＣ鍵をメッセージＩＤ毎に１つ保持しているが、ＥＣＵ毎に１つであっても良い。また、全てのＥＣＵが共通のＭＡＣ鍵を保持していても良い。同一のバスにつながるＥＣＵは全て共通のＭＡＣ鍵を保持していても良い。

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

（９）上記実施の形態では、カウンタ値はＭＡＣ算出のために使用しているが、データフィールドに含めて送信しても良い。また、その際は、全てのカウンタ値を送信してもよいし、一部のみを送信してもよい。

（１０）上記実施の形態では、判定ルールは一例に限定されるわけではなく、他の判定ルールであってもよいし、複数の判定ルールがあってもよい。また、判定ルールはＥＣＵにそれぞれ出荷時に設定されてもよいし、搭載される車体の出荷時に設定されてもよいし、部品として、あるいは、搭載される車体自体が販売される時に設定されてもよい。また、判定ルールは、外部との通信、各種メディア、または、各種診断ツールによって設定されてもよい。

（１１）上記実施の形態では、ＥＣＵ間で送受信されるデータフレームに対して、受信したＥＣＵがＭＡＣの検証を行っているが、全てのデータフレームに付与するＭＡＣの検証を一手に行うＭＡＣ検証用のＥＣＵであってもよい。

また、このＭＡＣ検証用ＥＣＵが全てのメッセージＩＤに対応するＭＡＣ鍵と、カウンタ値を保持していてもよい。また、このＭＡＣ検証用ＥＣＵがＭＡＣ検証の結果、エラーと判定した場合、その他のＥＣＵでの受信を防止するため、エラーフレームを送信してもよい。

（１２）上記実施の形態では、走行距離が閾値より大きい場合に、すべてのＭＡＣ鍵に関して、鍵更新処理を行っているが、これに限定するわけではなく、走行距離に関するメッセージＩＤのＭＡＣ鍵のみを更新するとしてもよい。

（１３）上記実施の形態では、走行距離が閾値より大きい場合に、すべてのＭＡＣ鍵に関して、鍵更新処理を行っているが、これに限定するわけではなく、走行距離に関するメッセージＩＤが送信されるバスのみのＭＡＣ鍵を更新するとしてもよい。

（１４）上記実施の形態では、所定の時間が経過、または走行距離が閾値より大きい場合に、判定ルールに基づいて更新処理を行っているが、これに限定するわけではなく、カウンタ値が閾値より大きい場合に更新処理を実行するとしてもよい。このとき、カウンタ値が閾値より大きいメッセージＩＤに対応するＭＡＣ鍵のみを更新するとしてもよい。

（１５）上記の実施の形態における各装置は、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ、ハードディスクユニット、ディスプレイユニット、キーボード、マウスなどから構成されるコンピュータシステムである。ＲＡＭまたはハードディスクユニットには、コンピュータプログラムが記録されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、各装置は、その機能を達成する。ここでコンピュータプログラムは、所定の機能を達成するために、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。

（１６）上記の実施の形態における各装置は、構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Large Scale Integration：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどを含んで構成されるコンピュータシステムである。ＲＡＭには、コンピュータプログラムが記録されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、システムＬＳＩは、その機能を達成する。

また、上記の各装置を構成する構成要素の各部は、個別に１チップ化されていても良いし、一部またはすべてを含むように１チップ化されてもよい。

また、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路または汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）、ＬＳＩ内部の回路セルの接続または設定を再構成可能なリコンフィギュラブル・プロセッサを利用しても良い。

さらには、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。

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

（１８）本開示は、上記に示す方法であるとしてもよい。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、コンピュータプログラムからなるデジタル信号であるとしてもよい。

また、本開示は、コンピュータプログラムまたはデジタル信号をコンピュータで読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＢＤ（Blu-ray（登録商標） Disc）、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されている前記デジタル信号であるとしてもよい。

また、本開示は、コンピュータプログラムまたはデジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。

また、本開示は、マイクロプロセッサとメモリを備えたコンピュータシステムであって、メモリは、上記コンピュータプログラムを記録しており、マイクロプロセッサは、コンピュータプログラムにしたがって動作するとしてもよい。

また、プログラムまたはデジタル信号を記録媒体に記録して移送することにより、またはプログラムまたはデジタル信号を、ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。

（１９）上記実施の形態および上記変形例をそれぞれ組み合わせるとしてもよい。

本開示は、ＥＣＵにおけるＭＡＣ鍵の更新処理が特定のタイミングに集中することなく、確実に実行され、車載ネットワークシステム全体として、安全な状態を維持することができる。

１０ 鍵更新管理装置
１１ 取得部
１２、１２ａ 鍵更新部
１３、１３ａ 鍵更新処理判定部
１００、１００ａ 車載ネットワークシステム
１０１ ゲートウェイ
１１１、１２１、１３１、１４１、１５１、１６１、１７１、１８１、１８２、１８４、１８６、１９１ ＥＣＵ
１１０ エンジン
１２０ トランスミッション
１３０ ブレーキ
１４０ ステアリング
１５０ 自動ブレーキ
１６０ 車線維持装置
１７０ 車車間通信装置
１８０ ヘッドユニット
１８３ ウィンドウ開閉センサ
１８５ ドア開閉センサ
１８７ ＧＰＳセンサ
１９０ ＩＴＳ装置
１１１１ フレーム送受信部
１１１２ フレーム解釈部
１１１３ 受信ＩＤ判断部
１１１４ 受信ＩＤリスト保持部
１１１５ フレーム処理部
１１１６ 車体状態保持部
１１１７ 判定ルール保持部
１１１８ タイマー
１１１９ 鍵更新判定部
１１２０ 更新処理部
１１２１ ＭＡＣ鍵保持部
１１２２ カウンタ保持部
１１２３ ＭＡＣ生成部
１１２４ フレーム生成部
１１２５ データ取得部

Claims (13)

1. 複数の電子制御ユニットを有し、車両に搭載される車載ネットワークシステムにおいて用いられる鍵の更新処理方法であって、
   前記複数の電子制御ユニットの少なくとも一つから送信される、前記車両の走行に関する情報である走行情報を取得する取得ステップと、
   前記走行情報により得られる前記車両の走行に関する状態が所定状態であることを条件として、前記車載ネットワークシステムにおいて授受されるデータに付加されるメッセージ認証コード（ＭＡＣ：Message Authentication Code）であって改ざん防止のコードであるメッセージ認証コードの生成に利用される鍵であるＭＡＣ鍵を更新する鍵更新ステップとを含む、
   更新処理方法。
2. 前記所定状態は、前記走行情報により得られる前記車両の走行距離であって前記ＭＡＣ鍵の前回の更新時からの前記車両の走行距離が閾値を超えた状態である、
   請求項１に記載の更新処理方法。
3. 前記所定状態は、前記ＭＡＣ鍵の前回の更新時から所定時間経過後、かつ、前記走行情報により得られる前記車両の状態が駐車中である状態である、
   請求項１に記載の更新処理方法。
4. 前記鍵更新ステップでは、
   前記複数の電子制御ユニットのすべてが、前記条件を満たした同一のタイミングで、前記ＭＡＣ鍵を用いて新たなＭＡＣ鍵を生成することにより、前記ＭＡＣ鍵を前記新たなＭＡＣ鍵に更新する、
   請求項１〜３のいずれか１項に記載の更新処理方法。
5. 前記鍵更新ステップでは、
   前記複数の電子制御ユニットの一が、前記条件を満たしたときに、前記ＭＡＣ鍵を用いて新たなＭＡＣ鍵を生成する生成ステップと、
   前記一の電子制御ユニットが生成した前記新たなＭＡＣ鍵を、前記一の電子制御ユニット以外の前記複数の電子制御ユニットのすべてに配布することにより、前記ＭＡＣ鍵を前記新たなＭＡＣ鍵に更新する配布ステップとを含む、
   請求項１〜３のいずれか１項に記載の更新処理方法。
6. 前記車載ネットワークは、前記複数の電子制御ユニットがバスに接続されたＣＡＮ（Controller Area Network）であり、
   前記更新処理方法は、
   前記複数の電子制御ユニットのうちの一である第１電子制御ユニットが、ＣＡＮプロトコルに従ってバスを介して、前記データとしてデータフレーム、および、前記データに付加されるメッセージ認証コードとして前記データフレームのデータフィールドを前記メッセージ認証コードとした検証用データフレームの送信を行う送信ステップと、
   前記複数の電子制御ユニットのうちの前記第１電子制御ユニット以外の複数の電子制御ユニットの少なくとも一である第２電子制御ユニットが、前記第１電子制御ユニットにより送信されたデータフレーム、および、検証用データフレームを、バスを介して受信する受信ステップとを含む、
   請求項１〜５のいずれか１項に記載の更新処理方法。
7. 前記送信ステップでは、
   前記第１電子制御ユニットが、前記データフレームを識別するためのＩＤと送信カウンタによりカウントされたデータフレームの送信回数とを少なくとも結合した値に対して前記ＭＡＣ鍵を用いて前記メッセージ認証コードを生成するＭＡＣ生成ステップを含み、
   前記受信ステップでは、
   前記第２電子制御ユニットが、前記検証用データフレームを受信して得た前記メッセージ認証コードと、受信した前記データフレームに対応するＩＤと、受信カウンタによりカウントされたデータの受信回数とを少なくとも結合した値に対して、前記ＭＡＣ鍵を用いて生成したメッセージ認証コードとの同一性を検証する検証ステップを含む、
   請求項６に記載の更新処理方法。
8. 前記車載ネットワークシステムは、前記複数の電子制御ユニットがＬＡＮ（Local Area Network）により接続されたネットワークであり、
   前記更新処理方法は、
   前記複数の電子制御ユニットのうちの一である第１電子制御ユニットが、前記データに付加される前記メッセージ認証コードとしてペイロード部分に前記メッセージ認証コードを含めて、前記データの送信を行う送信ステップと、
   前記複数の電子制御ユニットのうちの前記第１電子制御ユニット以外の複数の電子制御ユニットの少なくとも一である第２電子制御ユニットが、前記第１電子制御ユニットにより送信された前記データを受信する受信ステップとを含む、
   請求項１〜５のいずれか１項に記載の更新処理方法。
9. 前記送信ステップでは、さらに、
   前記第１電子制御ユニットが、前記データに付加された送信元アドレスおよび送信先アドレスと送信カウンタによりカウントされたデータの送信回数とを少なくとも結合した値に対して前記ＭＡＣ鍵を用いて前記メッセージ認証コードを生成するＭＡＣ生成ステップを含み、
   前記受信ステップでは、
   前記第２電子制御ユニットが、ペイロード部分に前記メッセージ認証コードが含まれた前記データを受信して得た前記メッセージ認証コードと、受信した当該データに付加された送信元アドレスおよぎ送信先アドレスと受信カウンタによりカウントされたデータの受信回数とを少なくとも結合した値に対して、前記ＭＡＣ鍵を用いて生成したメッセージ認証コードとの同一性を検証する検証ステップを含む、
   請求項８に記載の更新処理方法。
10. 前記更新処理方法は、さらに、
    前記条件として前記送信カウンタおよび前記受信カウンタをリセットするリセットステップを含む、
    請求項９に記載の更新処理方法。
11. 前記複数の電子制御ユニットは、前記車両の制御用途により分類された複数のグループの一に属し、
    前記複数のグループのそれぞれにおける前記所定状態は、前記複数のグループごとに定められる、
    請求項１〜１０のいずれか１項に記載の更新処理方法。
12. 複数の電子制御ユニットを有し、車両に搭載される車載ネットワークシステムであって、
    前記複数の電子制御ユニットの少なくとも一つから送信される前記車両の走行に関する情報である走行情報を取得する取得部と、
    前記走行情報により得られる前記車両の走行に関する状態が所定状態であることを条件として、前記車載ネットワークシステムにおいて授受されるデータに付加されるメッセージ認証コード（ＭＡＣ：Message Authentication Code）であって改ざん防止のコードであるメッセージ認証コードの生成に利用される鍵であるＭＡＣ鍵を更新する更新処理部とを備える、
    車載ネットワークシステム。
13. 車両に搭載される車載ネットワークシステムに接続される電子制御ユニットであって、
    ＣＰＵとメモリとを有し、
    前記ＣＰＵは、複数の電子制御ユニットの少なくとも一つから送信される前記車両の走行に関する情報である走行情報を取得して前記メモリに格納し、
    前記ＣＰＵは、
    前記メモリに格納された前記走行情報により得られる前記車両の走行に関する状態が所定状態であることを条件として、前記車載ネットワークシステムにおいて授受されるデータに付加されるメッセージ認証コード（ＭＡＣ：Message Authentication Code）であって改ざん防止のコードであるメッセージ認証コードの生成に利用される鍵であるＭＡＣ鍵を更新する、
    電子制御ユニット。

Images