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

車載ネットワークシステム、電子制御ユニット及び更新処理方法 Download PDF

Info

Publication number
JP6377143B2
JP6377143B2 JP2016517805A JP2016517805A JP6377143B2 JP 6377143 B2 JP6377143 B2 JP 6377143B2 JP 2016517805 A JP2016517805 A JP 2016517805A JP 2016517805 A JP2016517805 A JP 2016517805A JP 6377143 B2 JP6377143 B2 JP 6377143B2
Authority
JP
Japan
Prior art keywords
electronic control
update
mac
mac key
frame
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2016517805A
Other languages
English (en)
Other versions
JPWO2015170452A1 (ja
Inventor
良浩 氏家
良浩 氏家
松島　秀樹
秀樹 松島
芳賀　智之
智之 芳賀
前田　学
学 前田
勇二 海上
勇二 海上
剛 岸川
剛 岸川
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Intellectual Property Corp of America
Original Assignee
Panasonic Intellectual Property Corp of America
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Intellectual Property Corp of America filed Critical Panasonic Intellectual Property Corp of America
Publication of JPWO2015170452A1 publication Critical patent/JPWO2015170452A1/ja
Application granted granted Critical
Publication of JP6377143B2 publication Critical patent/JP6377143B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/067—Network architectures or network communication protocols for network security for supporting key management in a packet data network using one-time keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40208—Bus networks characterized by the use of a particular bus standard
    • H04L2012/40215—Controller Area Network CAN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40267—Bus for use in transportation systems
    • H04L2012/40273—Bus for use in transportation systems the transportation system being a vehicle
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84—Vehicles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/46—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for vehicle-to-vehicle communication [V2V]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Power Engineering (AREA)
  • Small-Scale Networks (AREA)
  • Mechanical Engineering (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)

Description

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

Claims (13)

  1. ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介してメッセージ認証コード（ＭＡＣ：Message Authentication Code）が付加されたデータフレームの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムの前記複数の電子制御ユニットの各々において、当該メッセージ認証コードの生成に利用されるＭＡＣ鍵の更新のために、用いられる更新処理方法であって、
    前記車載ネットワークシステムを搭載する車両の走行状態を検出する検出ステップと、
    前記検出ステップで検出された車両の走行状態が所定状態であることを条件として前記メッセージ認証コードの生成に利用されるＭＡＣ鍵を更新する更新ステップとを含み、
    前記車載ネットワークシステムは複数のバスを備え、
    前記更新ステップでは、前記複数の電子制御ユニットのうち１以上の電子制御ユニット各々により、当該電子制御ユニットが保持して利用するＭＡＣ鍵について、前記更新が行われ、前記更新の条件となる前記所定状態は、当該電子制御ユニットが接続されているバスに対応して定められる
    更新処理方法。
  2. ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介してメッセージ認証コード（ＭＡＣ：Message Authentication Code）が付加されたデータフレームの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムの前記複数の電子制御ユニットの各々において、当該メッセージ認証コードの生成に利用されるＭＡＣ鍵の更新のために、用いられる更新処理方法であって、
    前記車載ネットワークシステムを搭載する車両の走行状態を検出する検出ステップと、
    前記検出ステップで検出された車両の走行状態が所定状態であることを条件として前記メッセージ認証コードの生成に利用されるＭＡＣ鍵を更新する更新ステップとを含み、
    前記車載ネットワークシステムは複数のバスを備え、前記複数のバスの各々は、複数種類のグループのうちいずれかのグループに属し、
    前記更新ステップでは、前記複数の電子制御ユニットのうち１以上の電子制御ユニット各々により、当該電子制御ユニットが保持して利用するＭＡＣ鍵について、前記更新が行われ、前記更新の条件となる前記所定状態は、当該電子制御ユニットが接続されているバスが属するグループに対応して定められる
    更新処理方法。
  3. ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介してメッセージ認証コード（ＭＡＣ：Message Authentication Code）が付加されたデータフレームの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムの前記複数の電子制御ユニットの各々において、当該メッセージ認証コードの生成に利用されるＭＡＣ鍵の更新のために、用いられる更新処理方法であって、
    前記車載ネットワークシステムを搭載する車両の走行状態を検出する検出ステップと、
    前記検出ステップで検出された車両の走行状態が所定状態であることを条件として前記メッセージ認証コードの生成に利用されるＭＡＣ鍵を更新する更新ステップとを含み、
    前記更新ステップでは、前記ＭＡＣ鍵の前回の更新時から計数される所定の数量が一定数量に達したタイミングにおいて前記検出ステップで検出された車両の走行状態が前記所定状態であれば、前記ＭＡＣ鍵の更新を行う
    更新処理方法。
  4. 前記更新ステップでは、前記ＭＡＣ鍵の前回の更新時から計数される所定の数量が一定数量に達したタイミングにおいて前記検出ステップで検出された車両の走行状態が前記所定状態でない場合に、前記検出ステップで検出された車両の走行状態が前記所定状態に変化したタイミングで前記ＭＡＣ鍵の更新を行う
    請求項３記載の更新処理方法。
  5. 前記所定状態は、前記車両が走行していない状態である
    請求項１から３のいずれか１項に記載の更新処理方法。
  6. 前記所定状態は、駐車状態である
    請求項５記載の更新処理方法。
  7. ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介してメッセージ認証コード（ＭＡＣ：Message Authentication Code）が付加されたデータフレームの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムであって、
    メッセージ認証コードを生成して、所定メッセージＩＤで識別されるデータフレームに付加して送信する第１電子制御ユニットと、
    メッセージ認証コードを生成して、前記所定メッセージＩＤで識別されるデータフレームを受信して当該データフレームに当該メッセージ認証コードが付加されていることを検証する第２電子制御ユニットとを備え、
    前記第１電子制御ユニット及び前記第２電子制御ユニットの各々は、
    前記メッセージ認証コードの生成に利用されるＭＡＣ鍵を保持するＭＡＣ鍵保持部と、
    前記車載ネットワークシステムを搭載する車両の走行状態が所定状態であることを条件として前記ＭＡＣ鍵保持部に保持されるＭＡＣ鍵を更新する更新処理部とを有し、
    前記車載ネットワークシステムは複数のバスを備え、
    前記更新処理部は、当該更新処理部を有する前記電子制御ユニットが保持して利用するＭＡＣ鍵について、前記更新を行い、前記更新の条件となる前記所定状態は、当該電子制御ユニットが接続されているバスに対応して定められる
    車載ネットワークシステム。
  8. ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介してメッセージ認証コード（ＭＡＣ：Message Authentication Code）が付加されたデータフレームの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムであって、
    メッセージ認証コードを生成して、所定メッセージＩＤで識別されるデータフレームに付加して送信する第１電子制御ユニットと、
    メッセージ認証コードを生成して、前記所定メッセージＩＤで識別されるデータフレームを受信して当該データフレームに当該メッセージ認証コードが付加されていることを検証する第２電子制御ユニットとを備え、
    前記第１電子制御ユニット及び前記第２電子制御ユニットの各々は、
    前記メッセージ認証コードの生成に利用されるＭＡＣ鍵を保持するＭＡＣ鍵保持部と、
    前記車載ネットワークシステムを搭載する車両の走行状態が所定状態であることを条件として前記ＭＡＣ鍵保持部に保持されるＭＡＣ鍵を更新する更新処理部とを有し、
    前記車載ネットワークシステムは複数のバスを備え、前記複数のバスの各々は、複数種類のグループのうちいずれかのグループに属し、
    前記更新処理部は、当該更新処理部を有する前記電子制御ユニットが保持して利用するＭＡＣ鍵について、前記更新を行い、前記更新の条件となる前記所定状態は、当該電子制御ユニットが接続されているバスが属するグループに対応して定められる
    車載ネットワークシステム。
  9. ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介してメッセージ認証コード（ＭＡＣ：Message Authentication Code）が付加されたデータフレームの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムであって、
    メッセージ認証コードを生成して、所定メッセージＩＤで識別されるデータフレームに付加して送信する第１電子制御ユニットと、
    メッセージ認証コードを生成して、前記所定メッセージＩＤで識別されるデータフレームを受信して当該データフレームに当該メッセージ認証コードが付加されていることを検証する第２電子制御ユニットとを備え、
    前記第１電子制御ユニット及び前記第２電子制御ユニットの各々は、
    前記メッセージ認証コードの生成に利用されるＭＡＣ鍵を保持するＭＡＣ鍵保持部と、
    前記車載ネットワークシステムを搭載する車両の走行状態が所定状態であることを条件として前記ＭＡＣ鍵保持部に保持されるＭＡＣ鍵を更新する更新処理部とを有し、
    前記更新処理部は、前記ＭＡＣ鍵の前回の更新時から計数される所定の数量が一定数量に達したタイミングにおいて前記走行状態が前記所定状態であれば、前記ＭＡＣ鍵の更新を行う
    車載ネットワークシステム。
  10. 前記第１電子制御ユニット及び前記第２電子制御ユニットの更新処理部は、
    予め定められた特定メッセージＩＤで識別される特定フレームを受信した場合に前記車両の走行状態が所定状態であるか否かを判定し、当該車両の走行状態が所定状態であるときにＭＡＣ鍵の前記更新を行う
    請求項７から９のいずれか１項記載の車載ネットワークシステム。
  11. ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介して、データフレームにメッセージ認証コード（ＭＡＣ：Message Authentication Code）を付加して送信するため、或いは、データフレームを受信して当該データフレームにメッセージ認証コードが付加されていることを検証するために、メッセージ認証コードを生成する電子制御ユニットであって、
    前記メッセージ認証コードの生成に利用されるＭＡＣ鍵を保持するＭＡＣ鍵保持部と、
    前記電子制御ユニットを搭載する車両の走行状態が所定状態であることを条件として前記ＭＡＣ鍵保持部に保持されるＭＡＣ鍵を更新する更新処理部とを備え、
    前記更新処理部は、前記電子制御ユニットが保持して利用するＭＡＣ鍵について、前記更新を行い、前記更新の条件となる前記所定状態は、当該電子制御ユニットが接続されているバスに対応して定められる
    電子制御ユニット。
  12. ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介して、データフレームにメッセージ認証コード（ＭＡＣ：Message Authentication Code）を付加して送信するため、或いは、データフレームを受信して当該データフレームにメッセージ認証コードが付加されていることを検証するために、メッセージ認証コードを生成する電子制御ユニットであって、
    前記メッセージ認証コードの生成に利用されるＭＡＣ鍵を保持するＭＡＣ鍵保持部と、
    前記電子制御ユニットを搭載する車両の走行状態が所定状態であることを条件として前記ＭＡＣ鍵保持部に保持されるＭＡＣ鍵を更新する更新処理部とを備え、
    前記電子制御ユニットが接続されているバスは、複数種類のグループのうちいずれかのグループに属し、
    前記更新処理部は、前記電子制御ユニットが保持して利用するＭＡＣ鍵について、前記更新を行い、前記更新の条件となる前記所定状態は、当該電子制御ユニットが接続されている前記バスが属するグループに対応して定められる
    電子制御ユニット。
  13. ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介して、データフレームにメッセージ認証コード（ＭＡＣ：Message Authentication Code）を付加して送信するため、或いは、データフレームを受信して当該データフレームにメッセージ認証コードが付加されていることを検証するために、メッセージ認証コードを生成する電子制御ユニットであって、
    前記メッセージ認証コードの生成に利用されるＭＡＣ鍵を保持するＭＡＣ鍵保持部と、
    前記電子制御ユニットを搭載する車両の走行状態が所定状態であることを条件として前記ＭＡＣ鍵保持部に保持されるＭＡＣ鍵を更新する更新処理部とを備え、
    前記更新処理部は、前記ＭＡＣ鍵の前回の更新時から計数される所定の数量が一定数量に達したタイミングにおいて前記走行状態が前記所定状態であれば、前記ＭＡＣ鍵の更新を行う
    電子制御ユニット。
JP2016517805A 2014-05-08 2015-04-21 車載ネットワークシステム、電子制御ユニット及び更新処理方法 Active JP6377143B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201461990150P 2014-05-08 2014-05-08
US61/990,150 2014-05-08
JP2015032210 2015-02-20
JP2015032210 2015-02-20
PCT/JP2015/002162 WO2015170452A1 (ja) 2014-05-08 2015-04-21 車載ネットワークシステム、電子制御ユニット及び更新処理方法

Publications (2)

Publication Number Publication Date
JPWO2015170452A1 JPWO2015170452A1 (ja) 2017-04-20
JP6377143B2 true JP6377143B2 (ja) 2018-08-22

Family

ID=54392312

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016517805A Active JP6377143B2 (ja) 2014-05-08 2015-04-21 車載ネットワークシステム、電子制御ユニット及び更新処理方法

Country Status (5)

Country Link
US (1) US10227053B2 (ja)
EP (1) EP3142288B1 (ja)
JP (1) JP6377143B2 (ja)
CN (1) CN105594155B (ja)
WO (1) WO2015170452A1 (ja)

Families Citing this family (54)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6875576B2 (ja) * 2014-05-08 2021-05-26 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 不正対処方法
JP6407981B2 (ja) * 2014-05-08 2018-10-17 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 車載ネットワークシステム、電子制御ユニット及び不正対処方法
CN111478836B (zh) * 2014-07-10 2024-02-20 松下电器（美国）知识产权公司 车载网络***、电子控制单元、接收方法以及发送方法
CN111376848B (zh) * 2015-01-20 2024-07-02 松下电器（美国）知识产权公司 不正常检测规则更新方法、电子控制单元和车载网络***
JP6573819B2 (ja) * 2015-01-20 2019-09-11 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 不正検知ルール更新方法、不正検知電子制御ユニット及び車載ネットワークシステム
JP2016218932A (ja) * 2015-05-26 2016-12-22 京セラ株式会社 ソフトウェア更新装置およびソフトウェア更新システム
US9779247B2 (en) * 2015-05-29 2017-10-03 GM Global Technology Operations LLC Boot control systems and methods for vehicles
WO2017013622A1 (en) 2015-07-22 2017-01-26 Arilou Information Security Technologies Ltd. Vehicle communications bus data security
JP6555209B2 (ja) * 2015-08-07 2019-08-07 株式会社デンソー 通信システム、管理ノード、通信ノード、カウンタ同期方法、カウント値配信方法、カウント値初期化方法、プログラム、記録媒体
US10223294B2 (en) 2015-09-01 2019-03-05 Nxp Usa, Inc. Fast secure boot from embedded flash memory
JP6601244B2 (ja) * 2016-02-01 2019-11-06 トヨタ自動車株式会社 通信システム
JP6260064B2 (ja) * 2016-03-14 2018-01-17 Kddi株式会社 通信ネットワークシステム及び車両
JP6782188B2 (ja) * 2016-05-27 2020-11-11 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 電子制御ユニット、通信方法及び車載ネットワークシステム
JP6890025B2 (ja) * 2016-05-27 2021-06-18 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 電子制御ユニット、フレーム生成方法及びプログラム
WO2017203903A1 (ja) * 2016-05-27 2017-11-30 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 電子制御ユニット、通信方法及び車載ネットワークシステム
JP6846991B2 (ja) * 2016-07-05 2021-03-24 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 異常検知電子制御ユニット、車載ネットワークシステム及び異常検知方法
JP6849528B2 (ja) * 2016-07-28 2021-03-24 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ フレーム伝送阻止装置、フレーム伝送阻止方法及び車載ネットワークシステム
CN106341392B (zh) * 2016-08-23 2019-09-13 北京航空航天大学 电动汽车obdⅱ接口安全通信防护装置、***及方法
JP2018030464A (ja) * 2016-08-25 2018-03-01 株式会社オートネットワーク技術研究所 車両用認証装置
WO2018048279A1 (ko) * 2016-09-12 2018-03-15 엘지전자 주식회사 통신 시스템
US10140116B2 (en) * 2016-09-26 2018-11-27 Ford Global Technologies, Llc In-vehicle auxiliary memory storage
CN106385420A (zh) * 2016-09-29 2017-02-08 中国联合网络通信集团有限公司 一种ecu软件下载方法及装置
JP6547719B2 (ja) * 2016-09-30 2019-07-24 トヨタ自動車株式会社 車載通信ネットワーク
TWI688252B (zh) * 2016-10-03 2020-03-11 日商日本電氣股份有限公司 通信裝置、通信方法及記錄媒體
JP6756225B2 (ja) * 2016-10-04 2020-09-16 株式会社オートネットワーク技術研究所 車載更新システム、車載更新装置及び更新方法
JP6409849B2 (ja) * 2016-10-31 2018-10-24 トヨタ自動車株式会社 通信システム及び通信方法
CN108111460B (zh) * 2016-11-24 2020-12-08 飞天联合（北京）***技术有限公司 一种用户认证方法及***
US10705820B2 (en) * 2017-02-02 2020-07-07 Ford Global Technologies, Llc Method and apparatus for secure multi-cycle vehicle software updates
US10516683B2 (en) * 2017-02-15 2019-12-24 Ford Global Technologies, Llc Systems and methods for security breach detection in vehicle communication systems
CN106897627B (zh) * 2017-02-21 2020-02-11 成都信息工程大学 一种保证汽车ecu免受攻击和自动更新的方法
DE102017203185B4 (de) * 2017-02-28 2018-09-06 Audi Ag Kraftfahrzeug mit einem in mehrere getrennte Domänen eingeteilten Datennetzwerk sowie Verfahren zum Betreiben des Datennetzwerks
JP6956624B2 (ja) * 2017-03-13 2021-11-02 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 情報処理方法、情報処理システム、及びプログラム
JP6959155B2 (ja) * 2017-05-15 2021-11-02 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 検証方法、検証装置およびプログラム
CN115795435A (zh) * 2017-05-15 2023-03-14 松下电器（美国）知识产权公司 验证方法、验证装置和计算机可读取记录介质
SG10201705960QA (en) 2017-07-20 2019-02-27 Huawei Int Pte Ltd System and method for managing secure communications between modules in a controller area network
JP6828632B2 (ja) * 2017-08-03 2021-02-10 住友電気工業株式会社 検知装置、検知方法および検知プログラム
CN108073156B (zh) * 2017-11-20 2019-11-01 广州汽车集团股份有限公司 一种汽车电子控制单元的安全算法管理方法及***
EP3720055A4 (en) * 2017-12-01 2021-01-06 Panasonic Intellectual Property Corporation of America ELECTRONIC CONTROL DEVICE, SERVER FOR DETECTING AUTHORIZED USE, VEHICLE-MOUNTED NETWORK SYSTEM, VEHICLE-MOUNTED NETWORK MONITORING SYSTEM AND VEHICLE-MOUNTED NETWORK MONITORING METHOD
JP7010049B2 (ja) * 2018-02-16 2022-01-26 トヨタ自動車株式会社 車両制御装置、プログラムの更新確認方法および更新確認プログラム
CN110224907A (zh) * 2018-03-01 2019-09-10 上海汽车集团股份有限公司 一种车载ecu的刷新***、方法及终端
JP6967664B2 (ja) * 2018-04-23 2021-11-17 日立Astemo株式会社 ゲートウェイ装置
DE112018007680T5 (de) * 2018-06-29 2021-04-22 Mitsubishi Electric Corporation Aktualisierungssteuervorrichtung, Aktualisierungssteuersystem und Aktualisierungssteuerverfahren
WO2020021715A1 (ja) * 2018-07-27 2020-01-30 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 不正対処方法、不正対処装置および通信システム
DE102018215141A1 (de) * 2018-09-06 2020-03-12 Continental Teves Ag & Co. Ohg Verfahren zur Verbesserung des Nutzungsgrades einer Fahrzeug-zu-X Kommunikationsvorrichtung sowie Fahrzeug-zu-X Kommunikationsvorrichtung
CN109495893B (zh) * 2018-12-13 2019-12-24 深圳美克拉网络技术有限公司 一种移动通信数据流量异常监测***
EP3921976A1 (en) * 2019-02-06 2021-12-15 ABB Power Grids Switzerland AG Method for authenticating messages in resource limited systems
JP7163813B2 (ja) * 2019-02-18 2022-11-01 日本電気株式会社 鍵管理システム、鍵管理方法及びプログラム
WO2020179124A1 (ja) * 2019-03-05 2020-09-10 住友電気工業株式会社 管理装置、通信システム、車両、車両通信管理方法および車両通信管理プログラム
CN111835627B (zh) * 2019-04-23 2022-04-26 华为技术有限公司 车载网关的通信方法、车载网关及智能车辆
US11258755B2 (en) * 2019-09-19 2022-02-22 GM Global Technology Operations LLC Method and system for processing coherent data
US11303455B2 (en) * 2020-02-18 2022-04-12 Bae Systems Controls Inc. Authenticating devices over a public communication network
US11968639B2 (en) * 2020-11-11 2024-04-23 Magna Electronics Inc. Vehicular control system with synchronized communication between control units
JP2022190844A (ja) * 2021-06-15 2022-12-27 株式会社オートネットワーク技術研究所 車載制御装置、イーサネットスイッチおよび機器設定方法
US11940973B1 (en) * 2022-12-30 2024-03-26 Monday.com Ltd. Limiting concurrent database updates

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6665601B1 (en) * 1998-12-22 2003-12-16 Case Corporation Communications system for managing messages across a vehicle data bus
JP3849675B2 (ja) * 2003-07-25 2006-11-22 トヨタ自動車株式会社 車両診断方法、車両診断システム、車両およびセンター
JP4168866B2 (ja) * 2003-07-25 2008-10-22 トヨタ自動車株式会社 車両情報通信方法、車両情報通信システムおよびセンター
JP2005203882A (ja) * 2004-01-13 2005-07-28 Denso Corp 通信システム及び鍵送信方法
KR20050091134A (ko) * 2004-03-10 2005-09-15 (주)포트컴 Ｃａｎ 통신을 이용한 차량 원격 제어 시스템
JP2006352706A (ja) * 2005-06-17 2006-12-28 Hitachi Ltd マイクロプロセッサ、ネットワークシステム及び通信方法
ES2391786T3 (es) * 2007-02-13 2012-11-29 Secunet Security Networks Aktiengesellschaft Unidad de seguridad
JP4922120B2 (ja) * 2007-10-05 2012-04-25 株式会社オートネットワーク技術研究所 通信システム及び中継装置
EP2194257A1 (en) * 2008-12-05 2010-06-09 Delphi Technologies Holding S.à.r.l. A method of controlling a vehicle engine system
CN102114883B (zh) * 2010-09-21 2012-11-28 浙江吉利汽车研究院有限公司 汽车电子控制单元配置自检测装置及自检测方法
WO2012040392A2 (en) * 2010-09-21 2012-03-29 Cellepathy Ltd. System and method for sensor-based determination of user role, location, and/or state of one of more in-vehicle mobile devices and enforcement of usage thereof
US8919848B2 (en) * 2011-11-16 2014-12-30 Flextronics Ap, Llc Universal console chassis for the car
US9088454B2 (en) * 2010-11-03 2015-07-21 Broadcom Corporation Vehicle network node module
CN102004478B (zh) * 2010-11-08 2012-05-23 湖北三江航天万山特种车辆有限公司 一种车辆多总线协调通信与控制***
US20120215491A1 (en) * 2011-02-21 2012-08-23 Snap-On Incorporated Diagnostic Baselining
JP5310761B2 (ja) * 2011-03-04 2013-10-09 トヨタ自動車株式会社 車両ネットワークシステム
JP5479408B2 (ja) * 2011-07-06 2014-04-23 日立オートモティブシステムズ株式会社 車載ネットワークシステム
DE102012219093A1 (de) * 2011-10-25 2013-04-25 GM Global Technology Operations LLC (n.d. Ges. d. Staates Delaware) Cyber-Sicherheit in einem Kraftfahrzeugnetzwerk
JP5770602B2 (ja) * 2011-10-31 2015-08-26 トヨタ自動車株式会社 通信システムにおけるメッセージ認証方法および通信システム
WO2013090282A1 (en) * 2011-12-12 2013-06-20 Clay Skelton Systems, devices and methods for vehicles
JP2013138304A (ja) * 2011-12-28 2013-07-11 Toyota Motor Corp セキュリティシステム及び鍵データの運用方法
WO2013128317A1 (en) * 2012-03-01 2013-09-06 Nds Limited Anti-replay counter measures
WO2013175633A1 (ja) * 2012-05-25 2013-11-28 トヨタ自動車 株式会社 通信装置、通信システム及び通信方法
CN104349947B (zh) * 2012-05-29 2016-11-02 丰田自动车株式会社 认证***和认证方法
CN202827418U (zh) * 2012-08-31 2013-03-27 长城汽车股份有限公司 适用于混合动力汽车的车载网络***
SE1250982A1 (sv) * 2012-09-03 2014-03-04 Scania Cv Ab Kommunikationssystem i motorfordon
US9231936B1 (en) * 2014-02-12 2016-01-05 Symantec Corporation Control area network authentication

Also Published As

Publication number Publication date
WO2015170452A1 (ja) 2015-11-12
JPWO2015170452A1 (ja) 2017-04-20
US20160264071A1 (en) 2016-09-15
EP3142288B1 (en) 2018-12-26
CN105594155A (zh) 2016-05-18
CN105594155B (zh) 2019-08-02
EP3142288A1 (en) 2017-03-15
EP3142288A4 (en) 2017-05-17
US10227053B2 (en) 2019-03-12

Similar Documents

Publication Publication Date Title
JP6377143B2 (ja) 車載ネットワークシステム、電子制御ユニット及び更新処理方法
JP6396464B2 (ja) 車載ネットワークシステム、電子制御ユニット、受信方法及び送信方法
JP7008100B2 (ja) 不正対処方法、不正検知電子制御ユニットおよびネットワーク通信システム
US10609049B2 (en) Method for sensing fraudulent frames transmitted to in-vehicle network
JP6713415B2 (ja) 鍵管理方法、車載ネットワークシステム及び鍵管理装置
JP6407981B2 (ja) 車載ネットワークシステム、電子制御ユニット及び不正対処方法
WO2017119246A1 (ja) 異常検知方法、異常検知装置及び異常検知システム
US11516045B2 (en) Anomaly determination method, anomaly determination device, and recording medium
JP6651662B2 (ja) 不正検知電子制御ユニット及び不正検知方法
JPWO2019187350A1 (ja) 不正検知方法、不正検知装置及びプログラム
JP6698190B2 (ja) 不正対処方法、不正検知電子制御ユニット、および、ネットワーク通信システム
CN111788800B (zh) 帧传送方法以及安全星型耦合器

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20171214

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180417

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180607

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20180703

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180724

R150 Certificate of patent or registration of utility model

Ref document number: 6377143

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150