本発明の一態様に係る更新管理方法は、車載ネットワークシステムにおける更新管理装置で実行される更新管理方法であって、前記車載ネットワークシステムは、ネットワークを介して通信を行う複数の電子制御ユニットを備え、外部ツールが接続され、前記更新管理装置は、前記複数の電子ユニットのうちの1つの電子ユニットであり、前記更新管理装置と前記更新管理装置以外の電子制御ユニットとの間の暗号処理用の第1のセッション鍵の伝達に用いる共有鍵と、前記共有鍵の有効期限とを保持し、前記更新管理方法は、前記外部ツールの権限を示す更新権限情報の検証を行い、前記更新権限情報の検証が成功し、かつ、前記外部ツールから、前記共有鍵の更新を指示する更新メッセージを受信した場合に、前記外部ツールによる前記更新メッセージの送信が前記外部ツールの権限範囲内であるか否かの判定を行い、(i)前記外部ツールによる前記更新メッセージの送信が前記外部ツールの権限範囲内であることを前記更新権限情報が示すと判定したときには、前記更新メッセージを前記ネットワークに転送し、(ii)前記外部ツールによる前記更新メッセージの送信が前記外部ツールの権限範囲内であることを前記更新権限情報が示さないと判定したときには、前記転送を抑止し、現在時刻が前記有効期限内であるかどうかを判断し、前記有効期限の一定時間前、又は、前記有効期限が過ぎている場合に、前記共有鍵の更新を促すアラートメッセージを送信する。
また、前記複数の電子制御ユニットは、Controller Area Network(CAN)プロトコルに従って通信し、前記外部ツールは、CANプロトコルに従って前記更新メッセージを送信することとしても良い。
また、前記外部ツールからの前記更新メッセージの送信が前記外部ツールの権限範囲内であるか否かの判定は、前記更新メッセージのメッセージIDに基づいて、判定し、前記更新メッセージの送信が前記外部ツールの権限範囲内であることを前記更新権限情報が示すと判定したときには、前記メッセージIDを有する前記更新メッセージを受信するように定められている前記電子制御ユニットに対して前記更新を実行することとしても良い。
また、前記更新権限情報は、前記電子制御ユニットの分類用の複数の機能種別のうち1つ又は複数の機能種別を特定し、特定した当該1つ又は複数の機能種別のいずれかに分類される前記電子制御ユニットに前記更新を行わせる権限を前記外部ツールが有することを表し、前記更新メッセージのメッセージIDに基づいて、前記メッセージIDを受信するように定められている前記電子制御ユニットの機能種別が、前記更新権限情報により特定される1つ又は複数の機能種別のいずれかと一致するか否かを判別することにより、前記判定を行うこととしても良い。
また、前記更新権限情報は、1つ又は複数の前記機能種別を特定するための複数のレベルのうち1つのレベルを示し、相対的に高いレベルは、相対的に低いレベルが特定する1つ又は複数の機能種別を包含した複数の機能種別を特定することとしても良い。
また、前記車載ネットワークシステムを搭載する車両の状態が所定状態でないときには、前記更新メッセージの前記ネットワークへの転送を抑止することとしても良い。
また、前記車載ネットワークシステムにおける各電子制御ユニットに電力を供給する電池が所定電池残量を有さないときには、前記更新メッセージの前記ネットワークへの転送を抑止することとしても良い。
また、(i)前記車載ネットワークシステムを、複数の車載ネットワークシステムの中で識別する識別情報と、(ii)前記更新メッセージの処理結果を示す結果情報とを前記外部ツールに送信することとしても良い。
また、前記更新メッセージが指示する、前記電子制御ユニットが保持するデータの前記更新は、前記電子制御ユニットのファームウェアの更新であることとしても良い。
また、前記アラートメッセージは、ディスプレイを制御する電子制御ユニットに送信することとしても良い。
また、上記課題を解決するために本発明の一態様に係る更新管理装置は、車載ネットワークシステムにおける更新管理装置であって、前記車載ネットワークシステムは、ネットワークを介して通信を行う複数の電子制御ユニットを備え、外部ツールが接続され、前記更新管理装置は、前記複数の電子ユニットのうちの1つの電子ユニットであり、前記更新管理装置と前記更新管理装置以外の電子制御ユニットとの間の暗号処理用の第1のセッション鍵の伝達に用いられる共有鍵と、前記共有鍵の有効期限とを保持する保持部と、前記外部ツールから前記外部ツールの権限を示す更新権限情報、及び、前記共有鍵の更新を指示する更新メッセージを、受信する受信部と、前記受信部により受信された前記更新権限情報を検証する検証部と、前記検証部による検証が成功し、前記受信部により前記更新メッセージが受信された場合において、(i)前記更新メッセージの送信が前記外部ツールの権限範囲内であることを前記更新権限情報が示すときには、前記更新メッセージを前記ネットワークに転送し、(ii)当該更新メッセージの送信が前記外部ツールの権限範囲内であることを前記更新権限情報が示さないときには、前記転送を抑止する転送部と、現在時刻が前記有効期限内であるかどうかを判断する判断部と、前記有効期限の一定時間前、又は、有効期限が過ぎている場合に、前記共有鍵の更新を促すアラートメッセージを送信する送信部とを備える。
また、上記課題を解決するために本発明の一態様に係る制御プログラムは、車載ネットワークシステムにおける更新管理装置を制御するための制御プログラムであって、前記車載ネットワークシステムは、ネットワークを介して通信を行う複数の電子制御ユニットを備え、外部ツールが接続され、前記更新管理装置は、前記複数の電子制御ユニットのうちの1つの前記電子制御ユニットであり、前記更新管理装置と前記更新管理装置以外の電子制御ユニットとの間の暗号処理用の第1のセッション鍵の伝達に用いる共有鍵と、前記共有鍵の有効期限とを保持し、前記制御プログラムは、前記外部ツールの権限を示す更新権限情報の検証を行い、前記更新権限情報の検証が成功し、かつ、前記外部ツールから、前記共有鍵の更新を指示する更新メッセージを受信した場合に、前記外部ツールによる前記更新メッセージの送信が前記外部ツールの権限範囲内であるか否かの判定を行い、(i)前記外部ツールによる前記更新メッセージの送信が前記外部ツールの権限範囲内であることを前記更新権限情報が示すと判定したときには、前記更新メッセージを前記ネットワークに転送し、(ii)前記外部ツールによる前記更新メッセージの送信が前記外部ツールの権限範囲内であることを前記更新権限情報が示さないと判定したときには、前記転送を抑止し、現在時刻が前記有効期限内であるかどうかを判断し、前記有効期限の一定時間前、又は、前記有効期限が過ぎている場合に、前記共有鍵の更新を促すアラートメッセージを送信する。
本発明の一態様に係る更新管理方法は、バスを介して通信を行う複数の電子制御ユニットを備え、外部ツールが接続される車載ネットワークシステムにおいて用いられる更新管理方法であって、前記外部ツールの権限を示す更新権限情報を受信して検証し、前記外部ツールから、1つ又は複数の前記電子制御ユニットが保持するデータの更新を指示する更新メッセージが送信された場合において、前記検証が成功し、かつ、当該更新メッセージの送信が当該外部ツールの権限範囲内であることを前記更新権限情報が示すときには、前記更新メッセージに対応して前記1つ又は複数の電子制御ユニットにより前記更新を実行し、前記検証が失敗したとき、又は、当該更新メッセージの送信が当該外部ツールの権限範囲内であることを前記更新権限情報が示さないときには、前記1つ又は複数の電子制御ユニットによる前記更新メッセージに対応した前記更新を抑止する更新管理方法である。これにより、検証可能な更新権限情報により外部ツール毎に、ECU内のデータの更新を指示する更新メッセージを送信する権限を異なるように定め得る。そして、車載ネットワークシステムにおける一部のECU内のデータの更新メッセージについて送信する権限を有している外部ツールだけがその一部のECU内のデータを更新させ得る。また、その一部のECU内のデータの更新メッセージについての送信の権限を有している外部ツールについて機密情報が漏洩しても、その一部のECU以外のECUについては不正に書き換えられない。このため、車載ネットワークの全てのECUのファームウェア等が不正に書き換えられるリスクを低減して、外部ツールにECU内のデータを更新させ得る。
また、前記複数の電子制御ユニットは、Controller Area Network(CAN)プロトコルに従って前記バスを介して通信を行い、前記外部ツールは、CANプロトコルに従って前記更新メッセージを送信することとしても良い。これにより、CANに従った車載ネットワークシステムにおいて適切に権限を有する外部ツールにECU内のデータを更新させ得る。
また、前記外部ツールから前記更新メッセージが送信された場合において、当該更新メッセージのメッセージIDに基づいて、当該更新メッセージの送信が当該外部ツールの権限範囲内であることを前記更新権限情報が示すか否かを判定し、当該更新メッセージの送信が当該外部ツールの権限範囲内であることを前記更新権限情報が示すと判定したときには、前記メッセージIDを有する前記更新メッセージを受信するように定められている前記電子制御ユニットにより前記更新を実行することとしても良い。これにより、CANのフレームのID(メッセージID)により更新メッセージでの更新指示の対象となるECUか否かの区別がなされる。このため、特定の1又は複数のECUに対しての更新の権限を、他の1又は複数のECUに対しての更新の権限と区別でき、例えば更新指示の対象となるECUに応じた権限を有する適切な外部ツールに限ってその更新を許可することが可能になる。
また、前記更新権限情報は、前記電子制御ユニットの分類用の複数の機能種別のうち1つ又は複数の機能種別を特定し、特定した当該1つ又は複数の機能種別のいずれかに分類される前記電子制御ユニットに前記更新を行わせる権限を前記外部ツールが有することを表し、前記外部ツールから前記更新メッセージが送信された場合において、当該更新メッセージのメッセージIDに基づいて、当該メッセージIDを受信するように定められている前記電子制御ユニットの機能種別が、前記更新権限情報により特定される1つ又は複数の機能種別のいずれかと一致するか否かを判別することにより、前記判定を行うこととしても良い。これにより、ECUを機能面で分類する機能種別毎に、更新の権限を区別して外部ツールに認定するような運用が可能となる。この認定は、例えば検証可能な更新権限情報の付与により行われる。
また、前記更新権限情報は、1つ又は複数の前記機能種別を特定するための複数のレベルのうち1つのレベルを示し、相対的に高いレベルは、相対的に低いレベルが特定する1つ又は複数の機能種別を包含した複数の機能種別を特定することとしても良い。これにより、外部ツール毎に更新の権限のレベルを異ならせることが可能となる。例えば、低いレベルの権限を有する外部ツールについての機密情報が漏洩してもそのレベルに対応して更新可能なECUの機能種別以外のECU(つまり高いレベルの権限を有する外部ツールによって更新可能なECU)については不正に書き換えられない。
また、1つの前記電子制御ユニットである更新管理装置が、当該更新管理装置と繋がった診断ポートに接続された前記外部ツールから前記更新権限情報を受信して前記検証を行い、前記外部ツールから前記更新メッセージが送信された場合に当該更新メッセージを受信し、当該受信した場合において、前記検証が成功し、かつ、当該更新メッセージの送信が当該外部ツールの権限範囲内であることを前記更新権限情報が示すときには、前記更新メッセージを前記バスに転送し、前記検証が失敗したとき、又は、当該更新メッセージの送信が当該外部ツールの権限範囲内であることを前記更新権限情報が示さないときには、前記転送を抑止することとしても良い。これにより、更新管理装置(マスタECU)が更新メッセージを他のECUへ転送するか否かを制御するので、他のECUは外部ツールの権限に係る検査を省略し得る。
また、前記更新メッセージにセッション鍵を用いた所定暗号処理が施されていなければ当該更新メッセージに対応した前記電子制御ユニットによる前記更新を抑止し、前記更新管理装置は、前記更新権限情報の前記受信を、当該更新権限情報を記載した、前記外部ツールの公開鍵に係る公開鍵証明書の受信により行い、前記検証に成功した場合に、前記外部ツールが前記更新メッセージの送信に際して当該更新メッセージに対して所定暗号処理を施すために用いる前記セッション鍵を、前記外部ツールの公開鍵で暗号化して前記外部ツールに送信することとしても良い。これにより、外部ツールの更新の権限について公開鍵証明書を発行することで認定できる。また、公開鍵証明書における公開鍵を利用して外部ツールによる通信内容に係るセキュリティの確保を図ることが可能になる。
また、前記更新管理装置は、前記外部ツールから前記更新メッセージが送信された場合において、前記車載ネットワークシステムを搭載する車両の状態が所定状態でないときには、前記更新メッセージの前記バスへの転送を抑止することとしても良い。これにより、所定状態として例えば停車状態、エンジンを停止した状態等を定めておくと、例えば走行に関連するECUの負荷が低下しバストラフィックが比較的少なくなる停車状態等においてECU内のデータを更新できるので、例えば更新に不具合が生じる可能性等を低減し得る。
また、前記更新管理装置は、前記外部ツールから前記更新メッセージが送信された場合において、前記車載ネットワークシステムにおける各電子制御ユニットに電力を供給する電池が所定電池残量を有さないときには、前記更新メッセージの前記バスへの転送を抑止することとしても良い。これにより、所定電池残量として例えば電池の残量が更新に足りる程度に十分な量を定めておくと、更新中の電池切れによる不具合を防ぐことが可能となる。
また、前記更新管理装置以外の電子制御ユニットと前記更新管理装置とは、通信内容に係る暗号処理用のセッション鍵の伝達に用いるために相互間で共有する共有鍵を保持し、前記更新メッセージが指示する、前記電子制御ユニットが保持するデータの前記更新は、前記共有鍵の更新であることとしても良い。これにより、外部ツールによりマスタECUとそれ以外のECUとの間で共有する共有鍵を更新できるようになる。
また、前記共有鍵の有効期限の一定期間前に前記共有鍵の更新を促す警告情報を出力することとしても良い。これにより、共有鍵の有効期限が切れる前に、鍵更新を促すことができ、共有鍵が有効期限を過ぎて利用し続けられるリスクを低減し得る。
また、前記更新管理装置は、前記車載ネットワークシステムを、複数の車載ネットワークシステムの中で識別する識別情報と前記更新メッセージの処理結果を示す結果情報とを前記外部ツールに送信することとしても良い。これにより、外部ツール側で車両毎(つまり車載ネットワークシステム毎)におけるECU内のデータの更新結果を管理することが可能となる。
また、前記外部ツールは、前記結果情報と前記識別情報とをサーバに送信することとしても良い。これにより、サーバにおいて車両毎におけるECU内のデータの更新結果を管理することが可能となる。
また、前記更新メッセージが指示する、前記電子制御ユニットが保持するデータの前記更新は、前記電子制御ユニットのファームウェアの更新であることとしても良い。これにより、ECUのファームウェアの更新についての権限を外部ツール毎に柔軟に設定できるようになる。
また、本発明の一態様に係る更新管理装置は、バスを介して通信を行う複数の電子制御ユニットを備える車載ネットワークシステムにおいて診断ポートと繋がった1つの電子制御ユニットである更新管理装置であって、前記診断ポートに接続された外部ツールから前記診断ポートを介して送信される、当該外部ツールの権限を示す更新権限情報、及び、1つ又は複数の前記電子制御ユニットが保持するデータの更新を指示する更新メッセージを、受信する受信部と、前記受信部により受信された前記更新権限情報を検証する検証部と、前記受信部により前記更新メッセージが受信された場合において、前記検証部による前記検証が成功し、かつ、当該更新メッセージの送信が前記外部ツールの権限範囲内であることを前記更新権限情報が示すときには、前記更新メッセージを前記バスに転送し、前記検証部による前記検証が失敗したとき、又は、当該更新メッセージの送信が前記外部ツールの権限範囲内であることを前記更新権限情報が示さないときには、前記転送を抑止する転送部とを備える更新管理装置である。これにより、外部ツールに付与された機密情報が漏洩した場合に全てのECU内のファームウェア等が不正に書き換えられるリスクを低減して、外部ツールにECU内のデータを更新させることが可能になる。
また、本発明の一態様に係る制御プログラムは、バスを介して通信を行う複数の電子制御ユニットを備える車載ネットワークシステムにおいて診断ポートと繋がった1つの電子制御ユニットとしての、プロセッサを有する更新管理装置に、所定の更新管理処理を実行させるための制御プログラムであって、前記更新管理処理は、前記診断ポートに接続された外部ツールから前記診断ポートを介して送信される、当該外部ツールの権限を示す更新権限情報を受信する更新権限情報受信ステップと、前記更新権限情報受信ステップにおいて受信された前記更新権限情報を検証する検証ステップと、前記外部ツールから前記診断ポートを介して送信される、1つ又は複数の前記電子制御ユニットが保持するデータの更新を指示する更新メッセージを受信する更新メッセージ受信ステップと、前記更新メッセージ受信ステップで前記更新メッセージが受信された場合において、前記検証ステップでの前記検証が成功し、かつ、当該更新メッセージの送信が前記外部ツールの権限範囲内であることを前記更新権限情報が示すときには、前記更新メッセージを前記バスに転送し、前記検証ステップでの前記検証が失敗したとき、又は、当該更新メッセージの送信が前記外部ツールの権限範囲内であることを前記更新権限情報が示さないときには、前記転送を抑止する転送制御ステップとを含む制御プログラムである。このプログラムを更新管理装置にインストールして、プロセッサに実行させることにより、外部ツールに付与された機密情報が漏洩した場合に全てのECU内のファームウェア等が不正に書き換えられるリスクを低減して、外部ツールにECU内のデータを更新させることが可能になる。
なお、これらの全般的又は具体的な態様は、システム、方法、集積回路、コンピュータプログラム又はコンピュータで読み取り可能なCD-ROM等の記録媒体で実現されても良く、システム、方法、集積回路、コンピュータプログラム又は記録媒体の任意な組み合わせで実現されても良い。
以下、実施の形態に係る更新管理方法を用いる車載ネットワークシステムについて、図面を参照しながら説明する。ここで示す実施の形態は、いずれも本発明の一具体例を示すものである。従って、以下の実施の形態で示される数値、構成要素、構成要素の配置及び接続形態、並びに、ステップ(工程)及びステップの順序等は、一例であって本発明を限定するものではない。以下の実施の形態における構成要素のうち、独立請求項に記載されていない構成要素については、任意に付加可能な構成要素である。また、各図は、模式図であり、必ずしも厳密に図示されたものではない。
(実施の形態1)
以下、本発明の実施の形態として、更新管理装置としてのマスタECU100を含む複数のECUがバスを介して通信する車載ネットワークシステム10において用いられる更新管理方法について、図面を用いて説明する。
更新管理方法として、本実施の形態では、車載ネットワークシステム10の診断ポートに外部ツールが接続された場合においてマスタECU100が、外部ツール30を認証して、一定条件を満たすときに限って外部ツール30にECUのデータ(ファームウェア等)の更新を許可する例を示す。
[1.1 車載ネットワークシステム10の全体構成]
図1は、実施の形態1に係る車載ネットワークシステム10の全体構成を示す図である。なお、同図には車載ネットワークシステム10の他に、外部ツール30が示されている。この外部ツール30は、例えば各種ECUの製造、メンテナンスを行う事業者等により製造された、個々の各種外部ツール(例えば後述する外部ツール30a、30b)を代表して表したものである。車載ネットワークシステム10は、CANプロトコルに従って通信するネットワーク通信システムの一例であり、制御装置、センサ等の各種機器が搭載された自動車(車両)におけるネットワーク通信システムである。車載ネットワークシステム10は、CANプロトコルに従ってバスを介してフレームに係る通信を行う複数の装置(ノード)を備え、更新管理方法を用いる。具体的には図1に示すように車載ネットワークシステム10は、診断ポート600と、バス500a~500dと、マスタECU(更新管理装置)100、ヘッドユニット200、ゲートウェイ300、各種機器に接続されたECU400a~400f等のECUといったバスに接続された各ノードとを含んで構成される。なお、車載ネットワークシステム10には、マスタECU100及びECU400a~400f以外にもいくつものECUが含まれ得るが、ここでは、便宜上マスタECU100及びECU400a~400fに注目して説明を行う。ECUは、例えば、プロセッサ(マイクロプロセッサ)、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置である。メモリは、ROM、RAM等であり、プロセッサにより実行される制御プログラム(コンピュータプログラム)を記憶することができる。例えばプロセッサが、制御プログラムに従って動作することにより、ECUは各種機能を実現することになる。なお、コンピュータプログラムは、所定の機能を達成するために、プロセッサに対する指令を示す命令コードが複数個組み合わされて構成されたものである。
診断ポート600は、車載ネットワークシステム10を構成するECUのメンテナンスを行う際に外部ツール30を接続するポートであり、マスタECU100とバス500dで繋がっている。診断ポート600は、例えばOBD2に準拠したコネクタである。外部ツール30は、診断ポート600と接続することにより、車載ネットワークシステム10へとCANプロトコルに従ったフレームを送信できる。例えば、外部ツール30は、ECUのファームウェア等を更新するための更新メッセージ或いはECUの故障診断のための診断用のメッセージ等、車載ネットワークシステム10において予め定められた一定範囲のメッセージIDを含むメッセージを送信し得る。ここでは、特に、ECUのファームウェア及び共有鍵のそれぞれを更新するために予め定められている一定範囲のメッセージIDを含む更新メッセージ(つまり更新要求用のフレーム)を外部ツールが送信することに注目して説明する。
マスタECU100は、外部ツール30の認証を行い、外部ツール30の証明書(後述する公開鍵証明書)に記載された更新権限情報に基づいて、外部ツールからの更新メッセージに対して更新を許可するか否かに係る判定等を行う役割を有する更新管理装置としての一種のECUである。また、マスタECU100は、車載ネットワークシステム10における複数のECUのうち自装置以外の1以上のECUそれぞれとの相互間で、フレームでの通信内容に係る暗号処理用のセッション鍵の伝達に用いるための、事前に共有した同一の共有鍵を保持し、セッション鍵を各ECUに伝達する機能を有する。
ECU400a~400fは、バス500a~500cのいずれかと接続され、それぞれエンジン310、ブレーキ320、ドア開閉センサ330、窓開閉センサ340、エアバッグ350、ヘッドユニット200に接続されている。ECU400a~400eのそれぞれは、接続されている機器(エンジン310等)の状態を取得し、定期的に状態を表すフレームをネットワーク(つまりバス)に送信している。ヘッドユニット200は、例えば、自動車のインストルメントパネル(インパネ)等に設けられた液晶ディスプレイ(LCD:Liquid Crystal Display)等の表示装置を含み、車両の運転者への報知を行い得る。ヘッドユニット200に接続されたECU400fは、バス500cからフレームを受信して、フレームが表す各種状態を、ヘッドユニット200の表示装置に表示させる機能を有する。
ゲートウェイ300は、ECU400a及びECU400bと繋がるバス500aと、マスタECU100及びECU400c~400eと繋がるバス500bと、ECU400fと繋がるバス500cとに接続しており、それぞれのバスから受信したフレームを他のバスに転送する機能を有する。また受信したフレームを転送するかしないかを接続されたバス間毎に切り替えることも可能である。ゲートウェイ300は一種のECUである。
車載ネットワークシステム10においてはCANプロトコルに従って、マスタECU400を含む各ECUがバスを介してフレームの授受を行う。CANプロトコルにおけるフレームには、データフレーム、リモートフレーム、オーバーロードフレーム及びエラーフレームがあるが、説明の便宜上、ここではデータフレームを中心に説明する。
[1.2 データフレームフォーマット]
以下、CANプロトコルに従ったネットワークで用いられるフレームの1つであるデータフレームについて説明する。
図2は、CANプロトコルで規定されるデータフレームのフォーマットを示す図である。同図には、CANプロトコルで規定される標準IDフォーマットにおけるデータフレームを示している。データフレームは、SOF(Start Of Frame)、IDフィールド、RTR(Remote Transmission Request)、IDE(Identifier Extension)、予約ビット「
r」、DLC(Data Length Code)、データフィールド、CRC(Cyclic Redundancy Check)シーケンス、CRCデリミタ「DEL」、ACK(Acknowledgement)スロット、ACKデリミタ「DEL」、及び、EOF(End Of Frame)の各フィールドで構成される。
SOFは、1bitのドミナントで構成される。バスがアイドルの状態はレセシブになっており、SOFによりドミナントへ変更することでフレームの送信開始を通知する。
IDフィールドは、11bitで構成される、データの種類を示す値であるID(つまりメッセージID)を格納するフィールドである。複数のノードが同時に送信を開始した場合、このIDフィールドで通信調停を行うために、IDが小さい値を持つフレームが高い優先度となるよう設計されている。
RTRは、データフレームとリモートフレームとを識別するための値であり、データフレームにおいてはドミナント1bitで構成される。
IDEと「r」とは、両方ドミナント1bitで構成される。
DLCは、4bitで構成され、データフィールドの長さを示す値である。なお、IDE、「r」及びDLCを合わせてコントロールフィールドと称する。
データフィールドは、最大64bitで構成される送信するデータの内容を示す値である。8bit毎に長さを調整できる。送られるデータの仕様については、CANプロトコルで規定されておらず、車載ネットワークシステム10において定められる。従って、車種、製造者(メーカ)等に依存した仕様となる。
CRCシーケンスは、15bitで構成される。SOF、IDフィールド、コントロールフィールド及びデータフィールドの送信値より算出される。
CRCデリミタは、1bitのレセシブで構成されるCRCシーケンスの終了を表す区切り記号である。なお、CRCシーケンス及びCRCデリミタを合わせてCRCフィールドと称する。
ACKスロットは、1bitで構成される。送信ノードはACKスロットをレセシブにして送信を行う。受信ノードはCRCシーケンスまで正常に受信ができていればACKスロットをドミナントとして送信する。レセシブよりドミナントが優先されるため、送信後にACKスロットがドミナントであれば、送信ノードは、いずれかの受信ノードが受信に成功していることを確認できる。
ACKデリミタは、1bitのレセシブで構成されるACKの終了を表す区切り記号である。
EOFは、7bitのレセシブで構成されており、データフレームの終了を示す。
[1.3 鍵発行システム]
図3は、上述したECU及び外部ツールに関わる鍵発行システムを示す図である。鍵発行機関20は、公開鍵証明書40a~40c、秘密鍵50a~50c、共有鍵60をメーカ21に配布する。配布された鍵や証明書は、メーカ21によって製造段階等において、外部ツール30a、30b、マスタECU100、ECU400a~400fに書き込まれる。メーカ21は、例えばOEMメーカ(Original Equipment Manufacturer)、EC
Uベンダー等である。公開鍵を記載した公開鍵証明書と、秘密鍵とは、公開鍵基盤(PKI:Public Key Infrastructure)で利用され、公開鍵及び秘密鍵が、楕円暗号、RSA
暗号等の鍵ペアである。この秘密鍵及び公開鍵証明書は、マスタECU100と外部ツール30a~b間の認証に用いられる。共有鍵60は、個々の共有鍵を代表的に表している。この共有鍵60は、共通鍵暗号方式のAES(Advanced Encryption Standard)の鍵であり、マスタECU100と他の各ECUとの間で共有され、フレームに係る暗号処理用のセッション鍵の伝達に用いられる。フレームに係る暗号処理としては、フレームのデータフィールドの内容の暗号化及び復号の他に、例えば、フレームの送信側で、フレームのデータフィールドに、メッセージ認証コード(MAC:Message Authentication Code)
を生成して付加して送信し、受信側ではそのMACについて検証する処理が挙げられる。このMACによりデータの改ざんの検出が可能となる。セッション鍵は、例えばMACの生成に用いられる。
図3の例では、外部ツール30aには、公開鍵証明書40aと秘密鍵50aとが書き込まれ、外部ツール30bには、公開鍵証明書40bと秘密鍵50bとが書き込まれ、マスタECU20には公開鍵証明書40cと秘密鍵50cと共有鍵60とが書き込まれ、ECU400a~400fには、共有鍵60が書き込まれることを示している。図3の例では、公開鍵証明書40aに記載された更新権限情報のレベルは3であり、公開鍵証明書40bに記載された更新権限情報のレベルは4である。
[1.4 公開鍵証明書]
図4は、鍵発行機関20が、外部ツール30a、30bに書き込まれるために発行つまり配布する公開鍵証明書40aの構成の一例を示す図である。公開鍵証明書40bも同様の構成を有する。
同図に示すように、公開鍵証明書は、バージョン、発行者、有効期間の開始と終了、証明書識別情報(ID)、公開鍵、更新権限情報(レベル)、及びこれらに対する署名を含んで構成される。署名は、鍵発行機関20或いはポータルサーバ等の認証局により付与される。このため、マスタECU100は外部ツール30の認証を、外部ツール30から公開鍵証明書を取得して署名の検証等により、行うことができる。
公開鍵証明書中の更新権限情報は、外部ツール30(外部ツール30a、30b等)に対して、どの種別のECUについてのECU内のデータの更新を指示する更新メッセージを送信する権限が認められているかについて示す情報であり、具体的には、権限について複数段階に区分されたレベルのうち1つを示す。このため、外部ツール30について署名主体である認証局等により認定された権限のレベルが更新権限情報に示されていることになる。
なお、マスタECU100に書き込まれる公開鍵証明書40cは、図4に示す構成例のうち更新権限情報以外の各要素を含む。
[1.5 更新権限情報]
図5は、図3の公開鍵証明書に記載された更新権限情報の内容としてのレベル(つまり権限のレベル)と、ECUの機能の分類用の複数の機能種別との対応関係の一例を示す図である。
まず、ECUの機能種別について説明する。駆動系機能は、エンジン、モータ、燃料、電池、トランスミッション等の制御といった車両の走行に関連する機能である。駆動系機能の機能種別には、例えば、エンジン310に関わるECU400aが該当する。シャーシ系機能は、ブレーキ、ステアリング等の「曲がる」、「止まる」等といった車両の挙動等の制御に関連する機能である。シャーシ系機能の機能種別には、例えば、ブレーキ320に関わるECU400bが該当する。ボディ系機能は、ドアロック、エアコン、ライト、ウィンカー等といった車両の装備の制御に関連する機能である。ボディ系機能の機能種別には、例えば、ドア開閉センサ330に関わるECU400c及び窓開閉センサ340に関わるECU400dが該当する。また、安全快適機能は、自動ブレーキ、車線維持機能、車間距離維持機能、衝突防止機能、エアバッグ等といった自動的に安全で快適な運転を実現するための機能である。安全快適機能の機能種別には、エアバッグ350に関わるECU400eが該当する。ITS(Intelligent Transport Systems)系機能は、ET
C(Electronic Toll Collection System)等の高度道路交通システムに対応した機能で
ある。テレマティクス系機能は、移動体通信を用いたサービスに対応する機能である。インフォテインメント系機能は、カーナビゲーション、オーディオ等に関連したエンターテインメント機能である。インフォテインメント系機能の機能種別には、例えば、ヘッドユニット200に関わるECU400fが該当する。
公開鍵証明書の署名主体である認証局等に認定された、更新権限情報の内容としての権限のレベルは、図5に例示する対応関係等に基づき、上述した複数の機能種別のうち1つ又は複数の機能種別を特定する。そして、その公開鍵証明書を付与された外部ツールは、更新権限情報のレベルにより特定されるその1つ又は複数の機能種別のいずれかに分類されるECUにそのECU内のデータ(ファームウェア、共有鍵)の更新を行わせる権限を、つまりファームウェア或いは共有鍵の更新用の更新メッセージを送信する権限を、有すると認定されていることになる。
図5の例によれば、更新権限について最も高いレベル4から最も低いレベル1の4段階のいずれかのレベルを示す更新権限情報を記載した公開鍵証明書が、個々の外部ツールに付与される(つまり書き込まれる)ことになる。個々の外部ツールは、機能、構成等がそれぞれ相違し得る。このため、例えば、外部ツールが取り扱う対象となるECUの機能種別、外部ツールの機密性、信頼性、その外部ツールを製造する事業者の信頼性その他の各種事情を勘案して個々の外部ツールに対する更新権限情報を定め得る。なお、図5は、レベルの一例を示すに過ぎず、この例と異なるように、レベルの段階数、レベルと機能種別との対応関係等を定めても良い。また、ある複数のレベル(例えばレベル4及びレベル2)のそれぞれが同じ1つの機能種別と対応するような対応関係を定めても良い。また、機能種別の分類についても図5の例と異なるように定め得る。ここでは、更新権限情報において相対的に高いレベルは、それより低いレベルが特定する1つ又は複数の機能種別を包含した複数の機能種別を特定するもの、つまり高いレベルは低いレベルの権限を包含するものとして説明する。しかし、権限のレベル間において権限の包含関係がないように、レベルと機能種別との対応関係を定めても良い。但し、外部ツールに対して認定された権限のレベルが相対的に低い場合において、車両の走行、挙動等に関連しない一部のECU内のデータの更新だけを許可してその一部以外のECU内のデータの更新をさせないことは有用である。具体的には、外部ツールについて認められた権限のレベル(つまり更新権限情報の内容であるレベル)が3であれば、その外部ツールは、レベル3以下の全てのレベル(つまりレベル1~レベル3)それぞれに対応する機能種別に分類される各ECUに対して更新メッセージを送信してECU内のデータの更新を実行させることが許可される。
なお、車載ネットワークシステム10においてマスタECU100は、外部ツール30が診断ポート600に接続された場合に、権限のレベルを定める更新権限情報を外部ツール30から受信しこの更新権限情報に基づいて、外部ツール30が送信する更新メッセージに対して、更新を許可するか否かに係る判定を行う。マスタECU100は、この判定において、上述したレベルと機能種別との対応関係(図5参照)に基づいて定められたレベル情報1040を参照する。レベル情報1040については、図8を用いて後に説明する。
[1.6 共有鍵]
図6は、マスタECU100、ECU400a~400fが保持する共有鍵を示す図である。上述した共有鍵60は、具体的には同図に示すように、全ECUで共有される共有鍵60aと、ECU400fとマスタECU100とで共有される共有鍵60bと、ECU400c、400dとマスタECU100とで共有される共有鍵60cと、ECU400a、400bとマスタECU100とで共有される共有鍵60dと、ECU400eとマスタECU100とで共有される共有鍵60eがある。
[1.7 マスタECU(更新管理装置)100の構成]
図7は、マスタECU100の構成図である。マスタECU100は、送受信部101と、鍵保持部102と、判定部103と、レベル情報保持部104と、フレーム送受信部160と、フレーム解釈部150と、受信ID判断部130と、受信IDリスト保持部140と、フレーム処理部110と、フレーム生成部120とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、マスタECU100における通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。
送受信部101は、マスタECU100と外部ツール30(外部ツール30a、30b)との認証のためにマスタECU100の公開鍵証明書40cの送信及び外部ツール30からの公開鍵証明書(公開鍵証明書40a或いは公開鍵証明書40b)を受信する。また、送受信部101は、外部ツール30から診断ポート600を介してバス500dに対して送信されるCANプロトコルに従った更新メッセージを受信し、また、更新メッセージによる更新の結果の送信を行う。
鍵保持部102は、マスタECU100の公開鍵証明書40c、秘密鍵50c、共有鍵60a~60eを保持する。なお、CANプロトコルに従ったデータフレームにおけるデータへの暗号処理としてMACを付与する場合に用いるMAC鍵を鍵保持部102に保持しても良い。また、外部ツール30等との間での通信に係る暗号処理に用いるセッション鍵を鍵保持部102に保持しても良い。セッション鍵はMACの生成にも利用され得る。
フレーム送受信部160は、バス500bに対して、CANプロトコルに従ったフレームを送受信する。つまり、ECU400a~400fからのフレームを受信し、ECU400a~400fへフレームを送信する。バス500bからフレームを1bitずつ受信し、フレーム解釈部150に伝達する。また、フレーム生成部120より通知を受けたフレームの内容をバス500bに1ビットずつ送信する。
フレーム解釈部150は、フレーム送受信部160よりフレームの値を受け取り、CANプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。フレーム解釈部150は、IDフィールドと判断した値(メッセージID)を受信ID判断部130へ転送する。受信ID判断部130から通知される判定結果に応じて、IDフィールドの値と、IDフィールド以降に現れるデータフィールドとを、フレーム処理部110へ転送するか、フレームの受信を中止する(つまりそのフレームとしての解釈を中止する)かを決定する。また、CANプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するように、フレーム生成部120へ通知する。また、フレーム解釈部150は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。
受信ID判断部130は、フレーム解釈部150から通知されるIDフィールドの値を受け取り、受信IDリスト保持部140が保持しているメッセージIDのリストに従い、そのIDフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ID判断部130は、フレーム解釈部150へ通知する。また、受信ID判断部130は、フレーム解釈部150と同様に、判定部103に対しても、メッセージIDが受信すべきフレームのものであるかどうかの判定を行って判定結果を通知する。
受信IDリスト保持部140は、マスタECU100が受信するメッセージIDのリストである受信IDリストを保持する。
フレーム生成部120は、フレーム解釈部150から通知されたエラーフレーム送信の要求に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部160へ通知して送信させる。また、判定部103よりフレームの生成の指示を受けると、データへの暗号処理(例えばセッション鍵等に対応したMACの付加等)を施してフレームを構成し、フレーム送受信部160へ通知して送信させる。
判定部103は、外部ツール30から受信した、更新権限情報を含む公開鍵証明書を検証することで、外部ツール30を認証する。判定部103が外部ツール30から受信した公開鍵証明書の検証に成功すると外部ツール30の認証に成功したことになる。なお、判定部103が公開鍵証明書の検証に成功したことは更新権限情報の検証に成功したことでもある。判定部103は、送受信部101により更新メッセージが受信された場合に、更新権限情報の検証が成功しており、かつ、その更新メッセージの送信が外部ツール30の権限範囲内であることを更新権限情報が示すか否かを判定することで、更新メッセージに対応した更新を許可するか否かの判定を行う。この判定は、受信した更新メッセージのメッセージIDと受信した公開鍵証明書に記載された更新権限情報が示すレベルとが、レベル情報保持部104が保持しているレベル情報1040(後述)に照らして適切に対応したものであるか否かを判別することにより行われる。判定部103は、外部ツール30によりなされた更新メッセージの送信が外部ツール30の権限範囲内であることを更新権限情報が示すと判定した場合(つまり許可される更新メッセージであると判定した場合)には、フレーム生成部120に、他のECUへの転送用(つまりバス500bへの送出用)にその(元の)更新メッセージに対応したフレームである新たな更新メッセージを生成するよう指示する。なお、フレーム生成部120が転送用に生成する新たな更新メッセージは、元の更新メッセージとメッセージIDは同じで更新メッセージのデータフィールド内におけるデータも実質的には同じであり、データに暗号処理を施す場合においてそのデータに施された暗号処理(例えばデータに付加されたMAC)が異なるものである。フレーム生成部120で生成された更新メッセージはフレーム送受信部160によりバス500bに送出される。これにより、外部ツール30からの更新権限情報の検証が成功しており、かつ、外部ツール30からの更新メッセージが許可される更新メッセージであると判定した場合にはマスタECU100によってその更新メッセージが他のECUへと(つまりバス500bへと)転送されることになる。また、判定部103は、外部ツール30からの共有鍵の更新用の更新メッセージが許可される更新メッセージであると判定した場合には、鍵保持部102に保持されている共有鍵を更新する。
フレーム処理部110は、バス500bから受信したフレームのデータに応じて予め定められた処理を行う。フレーム処理部110は、例えば、バス500bから更新メッセージによる各ECUでの更新の結果を示すフレームを受信した場合には、その更新の結果を内容とするメッセージ(フレーム)を生成して送受信部101に診断ポート600へ繋がるバス500dへと送出させる。
レベル情報保持部104は、レベル情報1040を保持する。
[1.8 レベル情報]
図8は、レベル情報保持部104が保持するレベル情報1040の一例を示す図である。
レベル情報1040は、メッセージID1041とレベル1042とを対応付けた情報であり、判定部103において外部ツール30からの更新メッセージを許可するか否かの判定に用いられる。
メッセージID1041は、外部ツール30から送信され得る更新メッセージのメッセージIDを示す。ここでは、ECUが保持する共有鍵の更新用の更新メッセージについてのメッセージIDとして、「0x100」~「0x104」が定められており、ECUのファームウェアの更新用の更新メッセージについてのメッセージIDとして、「0x200」~「0x206」が定められているものとして説明する。
レベル1042は、対応するメッセージIDの更新メッセージを送信するために必要な権限のレベルを示す。このレベルは、更新権限情報の内容としてのレベルと呼応している。例えば、外部ツール30の公開鍵証明書に記載された更新権限情報が示すレベルの値が、レベル1042の値と同じかこれより高い権限を示す値を示せば、そのレベル1042の値と対応付けられたメッセージID1041の更新メッセージを送信する権限を外部ツール30が有することになる。逆に、外部ツール30の公開鍵証明書に記載された更新権限情報が示すレベルの値が、レベル1042の値より低い権限を示す値であれば、そのレベル1042と対応付けられたメッセージID1041の更新メッセージを送信する権限を外部ツール30が有さないことになる。
図8に示すメッセージID「0x100」は、マスタECU100及びECU400a~400fが保持している共有鍵60aの更新用の更新メッセージについてのメッセージIDである。レベル情報1040において、このメッセージID「0x100」に対応するレベル1042の値は、最も高い4と設定されている。この4は、共有鍵60aの更新の対象となる各ECUの機能種別に対応するレベルのうち最も高いレベル(具体的にはECU400eの機能種別である安全快適機能に対応するレベル)の値である(図5参照)。
メッセージID「0x101」は、マスタECU100及びECU400eが保持している共有鍵60eの更新用の更新メッセージについてのメッセージIDである。安全快適機能を有するECU400eに対応して、レベル1042の値は、4と設定されている。
メッセージID「0x102」は、マスタECU100及びECU400a、400bが保持している共有鍵60dの更新用の更新メッセージについてのメッセージIDである。駆動系機能を有するECU400a及びシャーシ系機能を有するECU400bに対応して、レベル1042の値は、3と設定されている。
メッセージID「0x103」は、マスタECU100及びECU400c、400dが保持している共有鍵60cの更新用の更新メッセージについてのメッセージIDである。ボディ系機能を有するECU400c、400dに対応して、レベル1042の値は、2と設定されている。
メッセージID「0x104」は、マスタECU100及びECU400fが保持している共有鍵60bの更新用の更新メッセージについてのメッセージIDである。インフォテインメント系機能を有するECU400fに対応して、レベル1042の値は、1と設定されている。
メッセージID「0x200」は、マスタECU100のファームウェアの更新用の更新メッセージについてのメッセージIDである。このメッセージIDに対応するレベル1042の値は、マスタECU100を特別に扱って、最高レベルの4と設定されている。
メッセージID「0x201」は、ECU400eのファームウェアの更新用の更新メッセージについてのメッセージIDである。このメッセージIDに対応するレベル1042の値は、安全快適機能を有するECU400eに対応して、4と設定されている。
メッセージID「0x202」は、ECU400bのファームウェアの更新用の更新メッセージについてのメッセージIDである。このメッセージIDに対応するレベル1042の値は、シャーシ系機能を有するECU400bに対応して、3と設定されている。
メッセージID「0x203」は、ECU400aのファームウェアの更新用の更新メッセージについてのメッセージIDである。このメッセージIDに対応するレベル1042の値は、駆動系機能を有するECU400aに対応して、3と設定されている。
メッセージID「0x204」は、ECU400cのファームウェアの更新用の更新メッセージについてのメッセージIDである。このメッセージIDに対応するレベル1042の値は、ボディ系機能を有するECU400cに対応して、2と設定されている。
メッセージID「0x205」は、ECU400dのファームウェアの更新用の更新メッセージについてのメッセージIDである。このメッセージIDに対応するレベル1042の値は、ボディ系機能を有するECU400dに対応して、2と設定されている。
メッセージID「0x206」は、ECU400fのファームウェアの更新用の更新メッセージについてのメッセージIDである。このメッセージIDに対応するレベル1042の値は、インフォテインメント系機能を有するECU400fに対応して、1と設定されている。
[1.9 ECU400aの構成]
図9は、ECU400aの構成図である。ECU400aは、鍵保持部402と、フレーム送受信部460と、フレーム解釈部450と、受信ID判断部430と、受信IDリスト保持部440と、フレーム処理部410と、フレーム生成部420と、データ取得部470とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、ECU400aにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。なお、ECU400b~400fも、ECU400aと基本的に同様の構成を備える。
鍵保持部402は、図6に示した共有鍵を保持する。即ちECU400aの鍵保持部402は、共有鍵60a、60dを保持する。CANプロトコルに従ったデータフレームにおけるデータへの暗号処理としてMACを付与する場合に用いるMAC鍵を鍵保持部402に保持しても良い。また、他のECU等との間での通信に係る暗号処理に用いるセッション鍵を鍵保持部402に保持しても良い。セッション鍵はMACの生成にも利用され得る。
フレーム送受信部460は、バス500aに対して、CANのプロトコルに従ったフレームを送受信する。バス500aからフレームを1bitずつ受信し、フレーム解釈部450に転送する。また、フレーム生成部420より通知を受けたフレームの内容をバス500aに送信する。
フレーム解釈部450は、フレーム送受信部460よりフレームの値を受け取り、CANプロトコルにおける各フィールドにマッピングするよう解釈を行う。IDフィールドと判断した値は受信ID判断部430へ転送する。受信ID判断部430から通知される判定結果に応じて、IDフィールドの値(メッセージID)と、IDフィールド以降に現れるデータフィールドとを、フレーム処理部410へ転送するか、その判定結果を受けた以降においてフレームの受信を中止する(つまりそのフレームとしての解釈を中止する)かを決定する。また、CANプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するように、フレーム生成部420へ通知する。また、フレーム解釈部450は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。
受信ID判断部430は、フレーム解釈部450から通知されるIDフィールドの値を受け取り、受信IDリスト保持部440が保持しているメッセージIDのリストに従い、そのIDフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ID判断部430は、フレーム解釈部450へ通知する。
受信IDリスト保持部440は、ECU400aが受信するメッセージIDのリストである受信IDリスト(図10参照)を保持する。
フレーム処理部410は、受信したフレームのデータに応じてECU毎に異なる機能に係る処理を行う。例えば、エンジン310に接続されたECU400aは、エンジン310の回転速度と他のECUから受信したフレームのデータが示す車両の一部の状態との関係に応じて、予め定められた制御を行い得る。
データ取得部470は、ECUに繋がっている機器、センサの状態を示すデータを取得し、フレーム生成部420に通知する。
フレーム生成部420は、フレーム解釈部450から通知されたエラーフレーム送信の要求に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部460へ通知して送信させる。また、フレーム生成部420は、データ取得部470より通知されたデータに基づいて定めたデータフィールドの値に、予め定められたメッセージIDをつけてデータフレームを構成し、フレーム送受信部460へ通知して送信させる。なお、フレーム生成部420は、データフィールドの値に、MAC鍵或いはセッション鍵を用いて生成したMACを付加し得る。
[1.10 受信IDリスト]
図10は、ECU400aの受信IDリスト保持部440が保持する受信IDリスト900の一例を示す。
図10の例は、ECU400aが、メッセージID「0x102」が付された共有鍵の更新用の更新メッセージ、メッセージID「0x203」が付されたファームウェアの更新用の更新メッセージ等を受信することを示している。ECU400aが受信するメッセージ(フレーム)のメッセージIDは、「0x102」、「0x203」に限られないが、図10の例では特に更新メッセージのメッセージIDに注目して表している。
なお、マスタECU100の受信IDリスト保持部140が保持する受信IDリストも、受信IDリスト900と同様に、マスタECU100が受信可能なメッセージのメッセージIDを列挙した構成である。
[1.11 共有鍵更新シーケンス]
以下、更新管理方法の一例として、外部ツール30aを診断ポート600に接続して、外部ツール30aから車載ネットワークシステム10におけるECUが保持する共有鍵を更新させる場合の動作(共有鍵更新シーケンス)について、図11及び図12を用いて説明する。
図11及び図12は、外部ツール30aとマスタECU100とECU400aとの間で行われる共有鍵更新シーケンスの一例を示す図である。ここでは、便宜上、外部ツール30の1つとしての外部ツール30a、及び、ECU400a~400fのうちの1つであるECU400aに注目して説明する。また、駆動系機能及びシャーシ系機能を有する各ECUが保持する共有鍵を更新するために外部ツール30aが用いられる場面を想定して説明する。具体的には、駆動系機能を有するECU400a及びシャーシ系機能を有するECU400bのそれぞれが保持する共有鍵60dの更新のためのメッセージID「0x102」が付された更新メッセージが外部ツール30aから車載ネットワークシステム10へと送信されることになる。ECU400bの動作は、ECU400aの動作と同様であるため、ここでは説明を省略する。
まず、マスタECU100にバス500dで繋がった診断ポート600に外部ツール30aが物理的に接続された状態で、外部ツール30aが、証明書(つまり外部ツール30aが保持する公開鍵証明書40a)をバス500dに送出することで、ECU100に対して通信接続のために認証要求を送信する(ステップS1001)。なお、外部ツール30aは、例えば、利用者の操作等に応じて車載ネットワークシステム10のECU内のデータ(共有鍵、ファームウェア)の更新用の更新メッセージを送信し得る。但し、更新メッセージによって更新が実現されるためには更新メッセージの送信に先行して、例えば利用者の操作等に応じて、認証要求(証明書)を送信する必要がある。
マスタECU100の送受信部101が公開鍵証明書40aを受信して、判定部103において、公開鍵証明書40aを検証する(ステップS1002)。公開鍵証明書40aの検証については、例えば、認証局による署名を検証し、更に、チャレンジレスポンス(CR)認証方式で公開鍵証明書40aに記載された公開鍵と対応する秘密鍵を外部ツール30aが保持しているかについて確認する。CR認証方式では、例えば、マスタECU100は、乱数を外部ツール30aに送信し、外部ツール30aが乱数を秘密鍵で暗号化した結果である暗号化乱数をマスタECU100に返信すると、マスタECUは、公開鍵証明書40a内の公開鍵で暗号化乱数を復号し、最初に送信した乱数と等しいかを確認する。ステップS1002における検証に失敗すれば、マスタECU100は、エラー処理を行う(ステップS1003)。ステップS1003でのエラー処理により、外部ツール30aからの通信接続が認められなくなり、外部ツール30aは例えば更新メッセージを送信してECUのデータを更新することができなくなる。なお、マスタECU100は、エラー処理として外部ツール30aにエラーの旨のレスポンスを返しても良いし、返さなくても良い。
ステップS1002における検証に成功すれば、マスタECU100は、外部ツール30aとの通信において暗号処理を実施するために用いるセッション鍵を、乱数を用いて生成する(ステップS1004)。例えば、更新メッセージ内のデータを暗号化する場合においては、セッション鍵は暗号化のための鍵として用いられ、また、更新メッセージ内のデータにMACを付加する場合には、セッション鍵はMACを生成するための鍵として用いられる。
ステップS1004に続いて、マスタECU100の送受信部101は、セッション鍵を外部ツール30aの公開鍵で暗号化して、暗号化の結果である暗号化セッション鍵と、マスタECU100の公開鍵証明書40cとを外部ツール30aへと送信する(ステップS1005)。
外部ツール30aでは、マスタECU100の公開鍵証明書40cの検証を行う(ステップS1006)。検証に失敗すれば、エラー処理を行う(ステップS1007)。また、検証に成功すれば、外部ツール30aは、ステップS1004においてマスタECU100から送信されて受信した暗号化セッション鍵を、外部ツール30aの保持する秘密鍵で復号して、セッション鍵を取得する(ステップS1008)。
ステップS1008の次に、外部ツール30aは、メッセージID「0x102」が付された、共有鍵60dの更新用の更新メッセージを生成し、セッション鍵を用いて更新メッセージに暗号処理を実施する(ステップS1009)。更新メッセージへの暗号処理の例としては、データフィールドに、例えば共有鍵60dの更新に必要なデータ(例えばECU400aにおいて鍵付きハッシュ関数等により更新を行うこととした場合においてはその鍵となるデータ)を格納しそのデータを暗号化する或いはそのデータにMACを付加する等が挙げられる。また、共有鍵60dの更新にデータを必要としない場合であっても例えば更新メッセージの全体又は一部に対応したMACをデータフィールドに格納することも可能である。例えば、車載ネットワークシステム10において、更新メッセージに対応する暗号処理としてどのような処理を行うかについて、行うべき所定暗号処理(つまりセッション鍵を用いた所定暗号処理)を、予め規定しておく。そして、各ECUはその規定に従って所定暗号処理(例えばMACの付加)が適切に(つまりセッション鍵を用いた検証に成功するように)実施されている更新メッセージに対応して更新を行い、所定暗号処理が適切に実施されていなければその更新メッセージに対しては更新を抑止する。
外部ツール30aは、ステップS1009で生成した更新メッセージをマスタECU100に送信する(ステップS1010)。
ステップS1010で外部ツール30aが送信することでマスタECU100の送受信部101が受信したメッセージ(フレーム)のメッセージIDが受信すべきIDであるか否かを判定部103は、受信ID判断部130により判別する(ステップS1011)。共有鍵の更新用のメッセージID「0x100」~「0x104」及びファームウェアの更新用のメッセージID「0x200」~「0x206」は受信すべきIDであると判別される。ここでは、外部ツール30aが更新メッセージを送信することを想定して説明しているので、外部ツール30aからのメッセージ(フレーム)を更新メッセージと称しているが、実際には更新メッセージではないことも、あり得るため、ステップS1011で判別が行われる。つまり、外部ツール30aから送信されたメッセージ(フレーム)が、実際に更新メッセージであれば受信すべきと判別されることになる。なお、ここでは説明の便宜上、診断ポート600に接続された外部ツール30(例えば外部ツール30a等)からマスタECU100は、更新メッセージ以外のメッセージについてのメッセージIDを受信すべきIDとして取り扱わないこととしている。
ステップS1011において、送受信部101が受信したメッセージのメッセージIDが、受信すべきIDでないと判定した場合には、マスタECU100の判定部103は、そのメッセージIDのメッセージに係る処理を中止し、送受信部101ではIDフィールド以降の内容(データフィールド等)を受信せずに処理を終える(ステップS1012)。
ステップS1011において、送受信部101が受信したメッセージのメッセージIDが、受信すべきIDであると判定した場合には、マスタECU100の判定部103は、受信したメッセージのメッセージID「0x102」と外部ツール30aの公開鍵証明書40aに記載された更新権限情報のレベルとが、レベル情報保持部104に保持されているレベル情報1040におけるメッセージID1041とレベル1042との対応関係と合致するか否かにより、受信したメッセージが、許可される更新メッセージであるか否かを判定する(ステップS1013)。即ち、判定部103は、外部ツール30aによる更新メッセージの送信が外部ツール30aの権限範囲内であることを更新権限情報が示すか否かをレベル情報1040に基づいて判定する。受信したメッセージが許可される更新メッセージでなければエラー処理を行う(ステップS1014)。ステップS1014でのエラー処理により、更新メッセージに対応した更新は抑止される。ここでは、公開鍵証明書40aの更新権限情報のレベルが3である(図3参照)とすると、メッセージID「0x102」の更新メッセージとの対応関係は、レベル情報1040が示す対応関係(図8参照)に合致するので、判定部103は、外部ツール30aから受信した更新メッセージが、許可される更新メッセージであると判定する。
ステップS1013において、受信したメッセージの送信が外部ツール30aの権限範囲内であると判定した場合(つまり受信したメッセージが許可される更新メッセージであると判定した場合)には、判定部103は、フレーム生成部120へ転送用の更新メッセージを生成するよう指示する(ステップS1015)。これによりフレーム生成部120では、マスタECU100が外部ツール30aから受信した、元の更新メッセージに基づいて、バス500bへの転送用(つまり他のECUへの転送用)に新たな更新メッセージ(フレーム)を生成する。例えば、マスタECU100が外部ツール30aとの通信に用いるセッション鍵と、他のECU(少なくともバス500bに接続された各ECU)との通信に用いるセッション鍵とを異ならせている場合においては、フレーム生成部120は、元の更新メッセージに施された暗号処理が暗号化であれば復号を外部ツール30aとの通信用のセッション鍵を用いて行い、その処理の結果に他のECUとの通信に用いるセッション鍵を用いて暗号化を施すことで新たな更新メッセージを生成する。また、元の更新メッセージに施された暗号処理がMACの付加であれば、フレーム生成部120は、他のECUとの通信に用いるセッション鍵を用いてMACを生成して元の更新メッセージのMACを生成したMACで置き換えることで新たな更新メッセージを生成する。この場合において、元の更新メッセージのMACについて検証を行って検証に失敗した場合にエラー処理を行っても良い。また、例えば、マスタECU100が外部ツール30aとの通信に用いるセッション鍵と、他のECUとの通信に用いるセッション鍵とを同一にしている場合においては、フレーム生成部120は、元の更新メッセージと同一の新たな更新メッセージを生成する。
ステップS1015に続いて、マスタECU100のフレーム生成部120が生成した更新メッセージをフレーム送受信部160がバス500bに送出する(ステップS1016)。即ち、マスタECU100は、外部ツール30aから更新メッセージが送信された場合において、更新権限情報の検証(つまり公開鍵証明書の検証)が成功しており、かつ、更新メッセージの送信が外部ツール30aの権限範囲内であることを更新権限情報が示すときには、更新メッセージをバス500bに転送する。なお、更新権限情報の検証が失敗していたとき、又は、更新メッセージの送信が外部ツール30aの権限範囲内であることを更新権限情報が示さないときには、更新メッセージのバス500bへの転送は行われない。
マスタECU100によりバス500bに送出された更新メッセージは、ゲートウェイ300によりバス500a及びバス500cに転送される。これにより、ECU400a~400fは、更新メッセージを受信可能になる。従って、あるメッセージIDの更新メッセージの送信が外部ツール30aの権限範囲内であることを更新権限情報が示すとマスタECU100が判定したときには、そのメッセージIDの更新メッセージを受信するように予め定められているECUにより、更新メッセージに対応した更新が実行され得る。
ECU400a(図9参照)では、フレーム送受信部460により更新メッセージを受信し、フレーム解釈部450でそのメッセージの内容を解釈し、受信すべきIDがどうかを受信ID判断部430へ問い合わせる。受信ID判断部430は、受信IDリスト保持部440が保持している受信IDリストを参照し、受信したメッセージのIDフィールドの値が、受信すべきIDかどうかを判断する(ステップS1017)。受信ID判断部430が、ステップS1017において、フレーム送受信部460により受信されたメッセージのメッセージIDが、受信すべきIDでないと判定した場合には、フレーム解釈部450は、その受信されたメッセージに係る処理を中止し、フレーム送受信部460ではIDフィールド以降の内容を受信せずに処理を終える(ステップS1018)。
受信ID判断部430が、ステップS1017において、フレーム送受信部460により受信されたメッセージのIDフィールドの値が、受信すべきIDであると判断した場合は、ECU400aは、フレーム処理部410により、そのメッセージ(つまり更新メッセージ)に対応した処理(つまり共有鍵60dの更新)を実行する(ステップS1019)。フレーム処理部410では、現在、鍵保持部402が保持している共有鍵60dから、更新メッセージのデータフィールド内の鍵データを用いて鍵付きハッシュ関数により、更新後となる新たな共有鍵60dを生成する。更新には必ずしも鍵付きハッシュ関数を利用する必要はなく、他の例としては、鍵のないハッシュ関数(一方向性関数)を用いて元の共有鍵を新たな共有鍵に更新することが挙げられる。なお、ECU400aにおいて、更新メッセージに施された暗号処理(暗号化或いはMAC付加)に対応する処理(復号或いはMAC検証)を、セッション鍵を用いて行って更新メッセージの鍵データを取得する。
ECU400aは、共有鍵60dの更新後に更新の結果を示すメッセージ(更新結果メッセージと称する)をマスタECU100に伝達されるようにバス500aに送出する(S1020)。なお、更新結果メッセージのメッセージIDは予め定められており、マスタECU100は更新結果メッセージのメッセージIDを受信IDリスト保持部140のリストに保持している。更新結果メッセージは、例えば更新を完了した旨(つまり更新成功の旨)を示す。なお、更新に際してエラーが生じたような場合(例えば鍵データのMAC検証に失敗した場合等)には更新結果メッセージが更新失敗の旨を示すようにしても良い。更新結果メッセージは、ゲートウェイ300によりバス500aからバス500bに転送される。
マスタECU100は、更新結果メッセージを受信すると、鍵保持部102が保持している共有鍵60d(図6参照)をECU400aと同様の方法で更新する(ステップS1021)。なお、マスタECU100は、例えばECU400aからの更新成功の旨を示す更新結果メッセージとECU400bからの更新成功の旨を示す更新結果メッセージとの両方を受けた場合に限って、鍵保持部102が保持している共有鍵60dを更新するようにしても良い。
マスタECU100は、ステップS1020において受信した更新結果メッセージを、バス500dに送出することで診断ポート600を介して外部ツール30aに送信する(ステップS1022)。これにより、外部ツール30aでは更新結果メッセージを受信して、車載ネットワークシステム10において目的な更新が完了したこと等を知り、例えば更新の完了を利用者に報知(例えば外部ツール30aが表示装置を有していれば表示等)し得る。
以上、外部ツール30aが、ECU400a、400b及びマスタECU100のそれぞれが保持する共有鍵60dの更新用の更新メッセージを送信する例を示したが、他のECUが保持する共有鍵の更新用の更新メッセージを送信した場合、或いは、ECU内のファームウェアの更新用の更新メッセージを送信した場合においても、各装置は同様の動作を行う。なお、外部ツール30aは認証要求を1度送信した後において、各更新メッセージを逐次送信しても良い。この場合には、ステップS1001からステップS1008までの処理が一度実行された後に、外部ツール30aが各更新メッセージを送信する毎に、ステップS1009以降の処理が繰り返されるようになる。また、ECU内のファームウェアの更新用の更新メッセージは、例えば更新後のファームウェアの内容を特定するための情報を含み、更新メッセージの対象となるECUでは、その更新後のファームウェアの内容を特定するための情報に基づいてファームウェアを書き換える。ファームウェアは、例えば、ECU内のプログラム等のソフトウェア、プログラムで用いられるデータを含み、例えば、ECU内のプロセッサにおけるマイクロコードを含み得る。またファームウェアは、例えばECUがFPGA(Field Programmable Gate Array)等を含む場合におい
て、回路構成用のデータを含み得る。また、ここでの説明では便宜上、共有鍵とファームウェアとは別々に扱ったが、ファームウェアが共有鍵を含むと扱っても良い。
[1.12 実施の形態1の効果]
実施の形態1に係る車載ネットワークシステム10では、診断ポート600に接続される外部ツール30が特定のECU内のデータを更新する更新メッセージの送信権限を有するか否か、つまり外部ツール30が特定のECU内のデータを更新する権限を有するか否かを、外部ツール30に対して認定された権限を示す更新権限情報が示す、ECUの機能種別に対応して定められたレベルに基づいて、判定している。これにより、不正な外部ツールによるECU内の共有鍵或いはファームウェアの更新を防ぐことができる。また。外部ツール毎に、例えば外部ツールの機密性、信頼性、外部ツールを扱う事業者の信頼性その他の各種事情に応じて、更新権限情報のレベルを異ならせて設定(及び認定)できる。レベルを変えた外部ツールを別々のメンテナンス業者等に対して配布することも可能となり、各種事情に応じて柔軟に更新権限を制限した運用が可能になる。例えば、機密性、信頼性等のセキュリティ確保が十分である外部ツールほど、高い権限のレベルを認定する等が可能となる。このように外部ツール毎に更新権限情報のレベルを設定できることは、外部ツールを用途等に応じて効率的に柔軟に設計及び製造するために、或いは、外部ツールの運用上のセキュリティ確保等を用途に応じて柔軟に行うために、有用となる。
(実施の形態2)
以下、実施の形態1で示した車載ネットワークシステム10を一部変形してなる車載ネットワークシステム10aについて説明する。
実施の形態1に係る車載ネットワークシステム10では、診断ポート600に外部ツール30が接続された場合においてマスタECU100が、外部ツール30を認証して、外部ツール30からの更新メッセージが、更新権限情報が示す権限(レベル)の範囲内である場合に限って、外部ツール30にその更新メッセージでECU内のデータを更新することを許可した。
本実施の形態に係る車載ネットワークシステム10aでは、外部ツール30の更新メッセージを許可するか否かの判定において、レベルだけでなく車載ネットワークシステム10aを搭載している車両の状態、及び、車両における電池の残量の状態を参照する。本実施の形態に係る車載ネットワークシステム10aの構成は概ね実施の形態1で示した車載ネットワークシステム10(図1参照)と同様であり、以下、実施の形態1と同様のものについて同じ符号を用いる。
[2.1 車載ネットワークシステム10aの全体構成]
図13は、実施の形態2に係る車載ネットワークシステム10aの全体構成を示す図である。なお、同図には車載ネットワークシステム10aの他に、外部ツール30が示されている。
車載ネットワークシステム10aでは、車載ネットワークシステム10(図1)に対して、蓄電池800とECU400gとが追加されている。ここでは、実施の形態1と同様な構成要素の説明を省略する。
ECU400gは、バス500bと接続され、電池(蓄電池)800の充放電に係る制御を行い、蓄電池800の残量を取得して管理し、定期的に電池残量の状態を表すフレームをネットワーク(つまりバス500b)に送信している。
蓄電池800は、車載ネットワークシステム10における各ECUへ電力を供給する。
[2.2 レベル情報]
図14は、実施の形態2におけるマスタECU100のレベル情報保持部104が保持するレベル情報2040の一例を示す図である。
レベル情報2040は、メッセージID2014とレベル2042と電池残量条件2043と車両状態条件2044とを対応付けた情報であり、判定部103において外部ツール30からの更新メッセージを許可するか否かの判定に用いられる。メッセージID2041及びレベル2042は、実施の形態1で示したメッセージID1041及びレベル1042と同様である。電池残量条件2043は、更新メッセージを許可するために必要とされる電池の残量の条件を示し、例えば、電池の残量が更新に足りる程度に十分な量に設定され、具体例としては満充電の充電量を100%として充電50%以上の残量及び充電80%以上の残量のいずれかが設定される。また、車両状態条件2044は、更新メッセージを許可するために必要とされる車両状態の条件を示し、例えば停車状態(車両の速度がゼロとなっている状態)及びエンジンOFF状態(エンジン310を停止した状態)のいずれかが設定される。
例えば、メッセージID「0x104」の共有鍵の更新用の更新メッセージは、更新権限情報のレベルが1又はそれ以上で、蓄電池800の電池残量が充電50%以上で、且つ、車両状態が停車状態であるときに許可されることを示している。また、メッセージID「0x201」のファームウェアの更新用の更新メッセージは、更新権限情報のレベルが4で、蓄電池800の電池残量が充電80%以上で、且つ、車両状態がエンジンOFF状態であるときに許可されることを示している。
[2.3 共有鍵更新シーケンス]
以下、更新管理方法の一例として、外部ツール30aを診断ポート600に接続して、外部ツール30aから車載ネットワークシステム10aにおけるECUが保持する共有鍵を更新させる場合の動作(共有鍵更新シーケンス)について、図15及び図16を用いて説明する。
図15及び図16は、外部ツール30aとマスタECU100とECU400aとの間で行われる共有鍵更新シーケンスの一例を示す図である。ここでは、便宜上、外部ツール30の1つとしての外部ツール30a、及び、ECU400a~400gのうちの1つであるECU400aに注目して説明する。また、駆動系機能及びシャーシ系機能を有する各ECUが保持する共有鍵を更新するために外部ツール30aが用いられる場面を想定して説明する。具体的には、駆動系機能を有するECU400a及びシャーシ系機能を有するECU400bのそれぞれが保持する共有鍵60dの更新のためのメッセージID「0x102」が付された更新メッセージが外部ツール30aから車載ネットワークシステム10へと送信されることになる。ECU400bの動作は、ECU400aの動作と同様であるため、ここでは説明を省略する。また、ステップS2001からステップS2012とステップS2014からステップS2022との処理は、実施の形態1で示したステップS1001からステップS1012とステップS1014からステップS1022との処理(図11及び図12参照)と同等なので説明を省略し、ここでは、実施の形態1と異なるステップS2013a~S2013cのみを説明する。
ステップS2013aでは、マスタECU100の判定部103は、受信したメッセージのメッセージID「0x102」と外部ツール30aの公開鍵証明書40aに記載された更新権限情報のレベルとが、レベル情報保持部104に保持されているレベル情報2040におけるメッセージID2041とレベル2042との対応関係と合致するか否かにより、受信したメッセージが、適切な更新メッセージとして権限のレベルについての条件を満たすか否かを判定する。即ち、判定部103は、外部ツール30aによる更新メッセージの送信が外部ツール30aの権限範囲内であることを更新権限情報が示すか否かをレベル情報2040に基づいて判定する。受信したメッセージが権限のレベルについての条件を満たさない場合にはエラー処理を行う(ステップS2014)。ここでは、公開鍵証明書40aの更新権限情報のレベルが3である(図3参照)とすると、メッセージID「0x102」の更新メッセージとの対応関係は、レベル情報2040が示す対応関係(図14参照)に合致するので、判定部103は、外部ツール30aから受信した更新メッセージが、レベルの点で適切な更新メッセージであると判定し、次のステップS2013bへ処理を移す。
ステップS2013bでは、判定部103は、蓄電池800の電池残量が条件を満たすか否かをチェックする。蓄電池800の電池残量を管理するECU400gが定期的に電池残量の状態を示すメッセージ(電池残量フレームと称する)を送信している場合において、マスタECU100は、ECU400gからの電池残量フレームをフレーム送受信部160で受信する。なお、マスタECU100の受信IDリスト保持部140が保持する受信IDリストには、ECU400gからの電池残量フレームのメッセージIDが含まれているものとする。判定部103は、ECU400gから受信した電池残量フレームが示す電池残量が、レベル情報保持部104に保持されているメッセージID2041に対応する電池残量条件2043を満たすか否かをチェックする。電池残量の条件が満たされていれば、次のステップS2013cへ処理を移す。電池残量の条件が満たされていない場合(つまりチェックの結果がNGである場合)には、エラー処理を行う(ステップS2014)。なお、ECU400gが定期的に電池残量の状態を示す電池残量フレームを送信しないこととしても良く、この場合には、ステップS2013bにおいてマスタECU100は、例えばECU400gに電池残量フレームの送信を依頼するフレームを送信することで、ECU400gから電池残量フレームを受信して、更新メッセージが受信された時(つまり現在)における電池残量の状態を取得しても良い。
ステップS2013cでは、判定部103は、車両状態が条件を満たすか否かをチェックする。エンジン310に係るECU400aがエンジン状態や車速等の車両状態情報を示すメッセージ(車両状態フレームと称する)を定期的に送信している場合において、マスタECU100は、ECU400aからの車両状態フレームをフレーム送受信部160で受信する。なお、マスタECU100の受信IDリスト保持部140が保持する受信IDリストには、ECU400aからの車両状態フレームのメッセージIDが含まれているものとする。判定部103は、ECU400aから受信した車両状態フレームが示すエンジン状態、車速等の車両状態が、レベル情報保持部104に保持されているメッセージID2041に対応する車両状態条件2044を満たすか否かをチェックする。車両状態の条件が満たされていれば、判定部103は、外部ツール30aから受信した更新メッセージが許可されるものであると判定し、ステップS2015へと処理を移す。また、車両状態の条件が満たされていない場合(つまりチェックの結果がNGである場合)には、エラー処理を行う(ステップS2014)。なお、ECU400aが定期的に車両状態フレームを送信しないこととしても良く、この場合には、ステップS2013cにおいてマスタECU100は、例えばECU400aに車両状態フレームの送信を依頼するフレームを送信することで、ECU400aから車両状態フレームを受信して、更新メッセージが受信された時(つまり現在)における車両状態を取得しても良い。
[2.4 実施の形態2の効果]
実施の形態2に係る車載ネットワークシステム10aでは、外部ツール30からの更新メッセージに係る処理(更新)を許可するか否かについて、権限のレベルだけでなく電池残量の状態及び車両状態がどのような場合に更新メッセージが送信されたかに応じて判定している。このため、実施の形態1に係る車載ネットワークシステム10の効果に加え、次の効果を有する。即ち、電池残量を確認することで、ECU内のデータ(共有鍵或いはファームウェア)の更新処理が途中で途切れることなく確実に完了させられる。また、車両状態を確認することで、例えば、車両の走行中等のECUの負荷が高くバストラフィックが増大するときに更新メッセージを転送して更新を行うことを回避でき、更新が成功する可能性を高められる。
(実施の形態3)
本実施の形態では、実施の形態1に係る車載ネットワークシステム10におけるマスタECU100を部分的に変形し、共有鍵の有効期限に係る報知を行えるようにした例について説明する。
[3.1 マスタECU(更新管理装置)100aの構成]
図17は、マスタECU100aの構成図である。マスタECU100aは、実施の形態1で示したマスタECU100の構成要素に、共有鍵の有効期限をチェックするために、時刻情報取得部180と鍵更新確認部190とを加えた構成を有する。これらの各構成要素は、機能的な構成要素であり、その各機能は、マスタECU100aにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。ここでは、実施の形態1で示した構成要素についての説明を省略する。
時刻情報取得部180は、例えばリアルタイムクロック等の計時機構で構成され、現在時刻(つまり現在の日時)を取得して鍵更新確認部190に逐次通知する。
鍵更新確認部190は、時刻情報取得部180から通知された現在時刻と、鍵保持部102が保持している共有鍵について予め定めている有効期限を確認し、予めアラート通知タイミングとして設定されているタイミングを過ぎた時点(つまり有効期限の一定期間前)に、鍵更新アラートメッセージを、フレーム生成部120に生成させてフレーム送受信部160から送信させる。
図18に、鍵保持部102が保持している共有鍵それぞれについて、共有鍵識別情報3310と有効期限3311とアラート通知タイミング3312とを対応付けた情報の一例を示す。共有鍵識別情報3310は、各共有鍵を区別する情報である。有効期限3311は、対応する共有鍵識別情報が指す共有鍵についてセキュリティの確保のために予め定められた有効期限を示す。アラート通知タイミング3312は、有効期限より先行して鍵更新を促すべきタイミングを示す。鍵更新確認部190は、この図18に示す情報を参照する。例えば、共有鍵60aであれば、有効期限の3ヶ月前から鍵更新アラートメッセージを送信し、共有鍵60dであれば、有効期限の1ヶ月前から鍵更新アラートメッセージを送信する。
鍵更新アラートメッセージは、ヘッドユニット200に接続されたECU400fにより受信される。ECU400fは、鍵更新アラートメッセージを受信すると、共有鍵の有効期限が近付いている旨等を示す、共有鍵の更新を促す警告情報(画面)をヘッドユニット200の表示装置に表示する。
[3.2 鍵更新アラートメッセージ]
図19は、共有鍵の有効期限が近付いた場合に、ヘッドユニット200の表示装置に表示される画面の一例を示す図である。
図19の例では、画面3320は、現在日時とECUの共有鍵の有効期限とを含み、更に、共有鍵の更新を行うためのメンテナンス業者(この例ではディーラー)の連絡先、そのウェブサイトのURL(Uniform Resource Locator)を含む。また、画面3320は、ナビゲーションシステムにより目的地をディーラーの住所に設定する画面へ遷移するためのGUI(Graphical User Interface)のボタン3321を含む。なお、このディーラーの情報については、例えば販売時等において予めマスタECU100aに登録されていても良いし、テレマティクス系機能を有するECUを介して取得しても良い。
例えば、図19に例示する画面3320を見た運転者が車両を運転して、ディーラー等のメンテナンス業者へ行けば、ディーラー等は、実施の形態1、2等で説明したように、外部ツール30を用いて車載ネットワークシステムにおけるECUが保持する共有鍵の更新を実行させ得る。
[3.3 実施の形態3の効果]
実施の形態3に係る車載ネットワークシステムにおいては、共有鍵の有効期限を管理し、有効期限が近付いた場合に、車両の運転者等に鍵更新を促すような警告情報(画面)をヘッドユニットの表示装置に表示する。これにより、ディーラー等でのメンテナンスを受けるべきことの警告等といった共有鍵に係るセキュリティを確保するための注意喚起が実現される。
(実施の形態4)
本実施の形態では、実施の形態1に係る車載ネットワークシステム10におけるマスタECU100を、更新結果メッセージに車両識別情報を付して外部ツール30へ送信するように変形し、外部ツール30がサーバ35と通信するようにした例について説明する。
[4.1 サーバ]
外部ツール30と通信するサーバ35は、車載ネットワークシステム10が搭載される車両の外部に所在するコンピュータである。複数の車両それぞれに車載ネットワークシステム10が搭載されていることを前提として、サーバ35は、外部ツール30が、どの車両(つまり車載ネットワークシステム)に対して、どのような更新(ECU内のデータの更新)を行ったかを管理する。
[4.2 共有鍵更新シーケンス]
以下、本実施の形態での更新管理方法の一例として、サーバ35と通信する外部ツール30aを、ある車両の車載ネットワークシステム10における診断ポート600に接続して、外部ツール30aから車載ネットワークシステム10におけるECUが保持する共有鍵を更新させる場合の動作(共有鍵更新シーケンス)について、図20及び図21を用いて説明する。
図20及び図21は、サーバ35と通信する外部ツール30aとマスタECU100とECU400aとの間で行われる共有鍵更新シーケンスの一例を示す図である。ステップS3001からステップS3021までの処理は、実施の形態1で示したステップS1001からステップS1021までの処理(図11及び図12参照)と同等なので説明を省略し、ここでは、実施の形態1と異なるステップS3000a、S3000b、S3022、S3023及びS3024のみを説明する。
ステップS3000aでは、外部ツール30aは、サーバ35に接続要求を出す。即ち外部ツール30aは、例えば予め登録されたID(例えばツールID)及びパスワードを用いたログイン要求をサーバ35に送信する。
ステップS3000bでは、サーバ35は、外部ツール30aからの接続要求を受け、ID及びパスワードが予め登録されている情報と一致すればログイン処理を行って正常応答を返信する。
ステップS3000bの後において、外部ツール30a、マスタECU100及びECU400aは、実施の形態1で説明した通りに共有鍵の更新に係る処理を行う。これにより、ステップS3020では、マスタECU100がECU400aからの更新結果を示す更新結果メッセージを受信している。
ステップS3022では、マスタECU100は、ECU400aからの更新結果に加えて、車両識別情報を含めたメッセージである車両識別情報付き更新結果メッセージをバス500dに送出することで診断ポート600を介して外部ツール30aに送信する。これにより、外部ツール30aでは車両識別情報付き更新結果メッセージを受信する。車両識別情報は、この外部ツール30aが接続している車載ネットワークシステムを複数の車載ネットワークシステムの中で識別する情報であれば足り、例えばマスタECU100の公開鍵証明書40c(図3参照)等である。
ステップS3023では、外部ツール30aは、受信した車両識別情報付き更新結果メッセージが示す車両識別情報及び更新結果をサーバ35に送信する。
ステップS3024では、サーバ35は、受信した車両識別情報及び更新結果と、現在日時と、ログイン時に受信していたIDと対応付けてログ情報4000として保存する。
[4.3 診断ログ情報]
図22は、サーバ35が保存するログ情報4000の一例を示す図である。ログ情報4000は、車両識別情報4001と、外部ツールID4002と、更新メッセージのメッセージID4003と、日時4004と、更新結果4005とを含む。
[4.4 実施の形態4の効果]
本実施の形態では、サーバ35が、ログ情報4000を保存し、どの車両がどの外部ツールによって更新されたか等の情報が残るので、メンテナンス状況の把握が可能となる。また、不正な外部ツールが発見された場合にその外部ツールによる影響範囲の特定のためにログ情報4000が利用できる。
(他の実施の形態)
以上のように、本発明に係る技術の例示として実施の形態1~4を説明した。しかしながら、本発明に係る技術は、これに限定されず、適宜、変更、置き換え、付加、省略等を行った実施の形態にも適用可能である。例えば、以下のような変形例も本発明の一実施態様に含まれる。
(1)上記実施の形態で示した共有鍵は、機能を分類する機能種別により共有範囲を区別している例を示したが、これに限定されることはなく、マスタECUとその他の1又は複数のECUとが共有鍵を持ち合う単位は、車載ネットワークシステムにおいて任意に定め得る。例えば、車内ネットワークを複数のドメインに分けてドメイン毎に共有鍵を設定しても良い。その場合、更新のために必要な権限のレベルとしてドメインを区別してレベル情報を設定しても良い。また、上記実施の形態では、外部ツール30が、機能種別を踏まえて権限のレベルを設定された更新権限情報を含む公開鍵証明書を有する例を示したが、自動車メーカや車種に対応した更新の権限が設定された更新権限情報を含む公開鍵証明書を有しても良い。
(2)上記実施の形態では、共有鍵の更新は、現在各ECUが保持している共有鍵から鍵付きハッシュ関数を利用して新たな共有鍵を生成することで行うこととしたが、外部ツール30が新たな共有鍵自体を更新メッセージに含めて送信しても良い。この場合、共有鍵の値がCANの1フレーム内に収まらない場合は、複数フレームに分割して送信するようにしても良い。
(3)上記実施の形態では、外部ツール30からECU内のデータ(共有鍵、ファームウェア等)を更新するための更新メッセージを送信する例を示したが、この他に故障診断用等のメッセージを送信し得る。更新メッセージ以外のメッセージについては、車載ネットワークシステム(例えばマスタECU)において、レベル情報に基づく権限の判定を行うことなく、メッセージに対応した処理をすることとしても良い。更に、故障診断用等のメッセージを含む任意のメッセージについて、車載ネットワークシステム(例えばマスタECU)においてそのメッセージの送信が外部ツール30に認められた権限範囲内であるかを権限のレベルを示す権限情報に基づいて判定することとしても良い。
(4)上記実施の形態では、権限のレベルを1から4に設定しているが、レベルは、4段階でなくても良く、それ以上、それ以下に設定するようにしても良い。
(5)上記実施の形態で示した機能種別の分類の仕方は一例に過ぎず、例えばより詳細に細分化しても良い。機能種別を最も細かく分類して例えばECU毎にECU内のデータの更新に係る権限のレベルを設定しても良い。
(6)実施の形態2では、電池残量条件2043として蓄電池800の満充電に対する割合(パーセント)により区別する例を示したが、蓄電池800の電圧等で区別しても良い。また、車両の外部に所在する外部電源から蓄電池800へ充電中か否かを区別する条件を設定しても良い。これにより、例えば、一定の共有鍵、ファームウェアの更新を充電中に限って許可すること等が実現できる。
(7)実施の形態3では、共有鍵の有効期限が近付いた場合に、鍵更新アラートメッセージに基づき鍵更新の有効期限が近付いている旨等を示す情報(画面)を表示する例を示したが、その情報を繰り返し或いは継続的に表示しても良いし、有効期限が切れた場合に警告を報知(表示等)するようにしても良い。
(8)実施の形態3では、共有鍵の有効期限切れの確認のために、マスタECU100aの時刻情報取得部180が計時機構で現在時刻を取得する例を示したが、WiFi(登録商標)、携帯電話のキャリア網から現在時刻を示す時刻情報を取得しても、GPS(Global Positioning System)信号から時刻情報を取得しても良い。また、マスタECU1
00aが、他のECUから時刻情報を取得しても良い。
(9)上記実施の形態で示した外部ツール30は、更新メッセージを、サーバから受信することで取得して、診断ポート600を介してマスタECUに転送しても良い。
(10)上記実施の形態では、外部ツール30とマスタECUとの間で認証を行っているが、OBD2に準拠したコネクタ等である診断ポート600に、認証を担う電子回路(例えばメモリ、プロセッサ等)等を付加し、診断ポート600において外部ツール30の認証を行うこととしても良い。この場合に診断ポート600により外部ツール30の認証が完了していれば、マスタECUは外部ツール30の認証を省略し得る。なお、診断ポート600により外部ツール30の認証が完了していても上記実施の形態で示したように外部ツール30とマスタECUとの間で認証を行っても良い。なお、診断ポート600を、OBD2に準拠したコネクタ等でなく、他のコネクタで実現しても良い。また、診断ポート600を、無線通信回路を含めて実現することで外部ツール30との間で無線通信により接続できるようにしても良い。
(11)実施の形態2では、更新メッセージを受信したときにマスタECU100が電池残量の状態及び車両状態をチェックする例を示したが、電池残量及び車両状態のいずれか一方のみをチェックすることとしても良い。また、更新権限情報が権限のレベルを示すのみならず、実施の形態2で示した電池残量条件、車両状態条件等といった更新権限についての条件をも示すこととしても良い。例えば、更新権限情報は、車両状態条件として車両の状態である停車状態、又は、エンジンを停止した状態を特定し、車両が、特定したその状態であるときに更新メッセージを送信することを少なくとも1つの条件としてECUに更新を行わせる権限を外部ツールが有することを表すこととしても良い。また、例えば、更新権限情報は、電池残量条件としてECUに電力を供給する電池の残量の状態を特定し、その電池が、特定したその電池残量を有する状態であるときに更新メッセージを送信することを少なくとも1つの条件としてECUに更新を行わせる権限を外部ツールが有することを表すこととしても良い。そして、例えば、マスタECU100は、レベル情報2040における電池残量条件2043及び車両状態条件2044の代わりに、更新権限情報が示す電池残量条件、車両状態条件に基づいてチェック(ステップS2013b、S2013c)を行うようにしても良い。これにより、外部ツールに対して、外部ツールの信頼性等に応じて、一定の条件を付した権限を認定して、その条件及び権限のレベルを示す更新権限情報を記載した公開鍵証明書を発行するような運用が可能になる。
(12)上記実施の形態では、CANプロトコルにおけるデータフレームを標準IDフォーマットで記述しているが、拡張IDフォーマットで合っても良い。拡張IDフォーマットの場合には、標準IDフォーマットにおけるID位置のベースIDと、拡張IDとを合わせて29ビットでメッセージIDを表す。
(13)上記実施の形態では、外部ツール30が接続される診断ポート600とマスタECUとを繋ぐバス500dには他のECUが接続されていない例を示したが、ECUを接続しても良い。但し、マスタECU以外でバス500dに接続されるECUはそのデータ(共有鍵、ファームウェア等)を、外部ツール30(例えばマスタECUによる認証に成功してセッション鍵を得た外部ツール30)が送信する更新メッセージにより更新され得る。このため、例えば、更新の権限のレベルとして最も低いレベルに対応する機能種別の機能を有するECU等に限ってバス500dに接続することが有用となる。
(14)上記実施の形態では、外部ツール30が、認められた権限のレベルを超えてECUに更新を指示する更新メッセージを送信した場合にマスタECUが、その更新メッセージが、許可される更新メッセージであるか否かを判定し(ステップS1013)、許可される更新メッセージでなければエラー処理を行って(ステップS1014)、更新メッセージに対応した更新を抑止することとした。しかし、マスタECU以外のECU(例えば更新メッセージによる更新の指示対象となるECU)が、外部ツール30の更新権限情報に基づいて、更新を実行するか抑止するかを切り替えるようにしても良い。即ち、車載ネットワークシステムのいずれかのECUにおいて、外部ツール30から更新メッセージが送信された場合において、更新権限情報の検証が成功し、かつ、更新メッセージの送信が外部ツール30の権限範囲内であることを更新権限情報が示すときには、更新メッセージに対応して1つ又は複数のECUにより更新を実行し、その検証が失敗したとき、又は、更新メッセージの送信が外部ツール30の権限範囲内であることを更新権限情報が示さないときには、1つ又は複数のECUによる更新メッセージに対応した更新を抑止するようにしても良い。なお、実施の形態で示したようにマスタECUが一括して更新メッセージの転送を行うか否かを切り替える方式は、効率面で有用である。また、ゲートウェイ300で転送先のバスに接続されたECUの機能種別或いはそのECUが受信可能なメッセージIDを管理することとし、ゲートウェイ300が、更新メッセージを受信した場合に、転送先のバスに接続されたECUの機能種別或いはそのECUが受信可能なメッセージIDに基づいて、不要な更新メッセージの転送を行わないようにしても良い。
(15)上記実施の形態で示したマスタECU100、100a、ECU400a等の機能構成は、一例に過ぎず、上述した機能構成とは異なる機能分割を行っても良い。例えば、マスタECU100、100aは、送受信部101の受信機能に相当する受信部、判定部103における公開鍵証明書(更新権限情報を含む公開鍵証明書)の検証を担当する検証部、判定部103の一部とフレーム生成部120の一部とフレーム送受信部160の一部とに相当して更新メッセージの送信に係る制御を行う転送部とを含むこととしても良い。この場合に、例えば、受信部は、診断ポート600に接続された外部ツール30から診断ポート600を介して送信される、外部ツール30の権限を示す更新権限情報、及び、1つ又は複数のECUが保持するデータの更新を指示する更新メッセージを受信する機能を担う。また、検証部は、受信部により受信された更新権限情報を検証する機能を担う。また、転送部は、受信部により更新メッセージが受信された場合において、検証部による検証が成功し、かつ、更新メッセージの送信が外部ツール30の権限範囲内であることを更新権限情報が示すときには、更新メッセージをバス500bに転送し、検証部による検証が失敗したとき、又は、更新メッセージの送信が外部ツール30の権限範囲内であることを更新権限情報が示さないときには、転送を抑止する機能を担う。また、プロセッサを有するマスタECU100、100aにおいてプロセッサに実行される制御プログラムは、マスタECU100、100aに例えば次の所定の更新管理処理を実行させるためのプログラムであっても良い。所定の更新管理処理は、診断ポートに接続された外部ツールから診断ポートを介して送信される、その外部ツールの権限を示す更新権限情報を受信する更新権限情報受信ステップと、更新権限情報受信ステップにおいて受信された更新権限情報を検証する検証ステップと、外部ツールから診断ポートを介して送信される更新メッセージを受信する更新メッセージ受信ステップと、更新メッセージ受信ステップで更新メッセージが受信された場合において、検証ステップでの検証が成功しており、かつ、その更新メッセージの送信が外部ツールの権限範囲内であることを更新権限情報が示すときには、更新メッセージをECUとの通信用のバスに転送し、検証ステップでの検証が失敗したとき、又は、その更新メッセージの送信が外部ツールの権限範囲内であることを更新権限情報が示さないときには、転送を抑止する転送制御ステップとを含む。
(16)上記実施の形態におけるマスタECU及び他のECUは、例えば、プロセッサ、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置であることとしたが、ハードディスク装置、ディスプレイ、キーボード、マウス等の他のハードウェア構成要素を含んでいても良い。また、メモリに記憶された制御プログラムがプロセッサにより実行されてソフトウェア的に機能を実現する代わりに、専用のハードウェア(デジタル回路等)によりその機能を実現することとしても良い。
(17)上記実施の形態における各装置を構成する構成要素の一部又は全部は、1個のシステムLSI(Large Scale Integration:大規模集積回路)から構成されているとし
ても良い。システムLSIは、複数の構成部を1個のチップ上に集積して製造された超多機能LSIであり、具体的には、マイクロプロセッサ、ROM、RAM等を含んで構成されるコンピュータシステムである。前記RAMには、コンピュータプログラムが記録されている。前記マイクロプロセッサが、前記コンピュータプログラムに従って動作することにより、システムLSIは、その機能を達成する。また、上記各装置を構成する構成要素の各部は、個別に1チップ化されていても良いし、一部又は全部を含むように1チップ化されても良い。また、ここでは、システムLSIとしたが、集積度の違いにより、IC、LSI、スーパーLSI、ウルトラLSIと呼称されることもある。また、集積回路化の手法はLSIに限るものではなく、専用回路又は汎用プロセッサで実現しても良い。LSI製造後に、プログラムすることが可能なFPGAや、LSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用しても良い。さらには、半導体技術の進歩又は派生する別技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行っても良い。バイオ技術の適用等が可能性としてあり得る。
(18)上記各装置を構成する構成要素の一部又は全部は、各装置に脱着可能なICカード又は単体のモジュールから構成されているとしても良い。前記ICカード又は前記モジュールは、マイクロプロセッサ、ROM、RAM等から構成されるコンピュータシステムである。前記ICカード又は前記モジュールは、上記の超多機能LSIを含むとしても良い。マイクロプロセッサが、コンピュータプログラムに従って動作することにより、前記ICカード又は前記モジュールは、その機能を達成する。このICカード又はこのモジュールは、耐タンパ性を有するとしても良い。
(19)本発明の一態様としては、上記に示す共有鍵更新シーケンス等の更新管理方法であるとしても良い。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしても良いし、前記コンピュータプログラムからなるデジタル信号であるとしても良い。また、本発明の一態様としては、前記コンピュータプログラム又は前記デジタル信号をコンピュータで読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、CD-ROM、MO、DVD、DVD-ROM、DVD-RAM、BD(Blu-ray(登録商標) Disc)、半導体メモリ等に記録したものとしても良い。また、これらの記録媒体に記録されている前記デジタル信号であるとしても良い。また、本発明の一態様としては、前記コンピュータプログラム又は前記デジタル信号を、電気通信回線、無線又は有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしても良い。また、本発明の一態様としては、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記録しており、前記マイクロプロセッサは、前記コンピュータプログラムに従って動作するとしても良い。また、前記プログラム若しくは前記デジタル信号を前記記録媒体に記録して移送することにより、又は、前記プログラム若しくは前記デジタル信号を前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしても良い。
(20)上記実施の形態及び上記変形例で示した各構成要素及び機能を任意に組み合わせることで実現される形態も本発明の範囲に含まれる。