図面 (/)

技術 ネットワーク監視装置、ネットワークシステムおよびプログラム

出願人 株式会社東芝
発明者 鬼頭利之川端健
出願日 2016年9月13日 (3年5ヶ月経過) 出願番号 2016-178932
公開日 2018年3月22日 (1年10ヶ月経過) 公開番号 2018-045392
状態 特許登録済
技術分野 デバッグ/監視 ストアードプログラムにおける機密保護 ストアードプログラム 小規模ネットワーク(3)ループ,バス以外
主要キーワード CANメッセージ 復旧条件 車載ネットワークシステム 検証結果データ 車載ゲートウェイ装置 OEM 復旧制御 復旧動作
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2018年3月22日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (11)

課題

検証に失敗した電子機器ソフトウェアを簡便且つ安全に復旧させる。

解決手段

実施形態のネットワーク監視装置は、ソフトウェア保持部と、制御部と、を備える。ソフトウェア保持部は、ネットワークに接続された第1の電子機器に適用しているソフトウェアを保持する。制御部は、ソフトウェアの検証失敗を示す検証結果データを前記第1の電子機器から受信したことに応じて、前記第1の電子機器においてソフトウェアを復旧させる条件として予め定めた復旧条件を満たすか否かを判定し、前記復旧条件を満たすと判定した場合に、前記ソフトウェア保持部が保持するソフトウェアを前記第1の電子機器に送信するように制御する。

概要

背景

ネットワークに接続された電子機器は、例えば当該電子機器に適用(インストール)されているソフトウェアが不正に改竄されたりすると正常に動作しなくなり、ネットワーク全体に悪影響を及ぼす虞がある。このため、ネットワークに接続される電子機器は、当該電子機器に適用されているソフトウェアが正規のものであることを保証することが望まれる。ソフトウェアの正しさを確認する方法として、セキュアブートなどの検証機能が知られている。セキュアブートは、電子機器の起動時にファームウェアなどのソフトウェアが正規のものであることを確認する機能である。セキュアブートによるソフトウェアの検証が成功する場合のみそのソフトウェア(プログラム)が実行され、電子機器が正常に起動できる。

セキュアブートはネットワークの信頼性を確保する上で有効であり、例えば車載ネットワークシステムに接続される電子制御ユニット(ECU:Electronic Control Unit)などの電子機器への適用も検討されている。しかし、セキュアブートによるソフトウェアの検証が失敗すると電子機器が起動できなくなるため、検証に失敗したときの対策を考慮する必要がある。また、セキュアブートに限らず、検証に失敗した電子機器のソフトウェアを簡便且つ安全に復旧させることができる仕組みが求められている。

概要

検証に失敗した電子機器のソフトウェアを簡便且つ安全に復旧させる。実施形態のネットワーク監視装置は、ソフトウェア保持部と、制御部と、を備える。ソフトウェア保持部は、ネットワークに接続された第1の電子機器に適用しているソフトウェアを保持する。制御部は、ソフトウェアの検証失敗を示す検証結果データを前記第1の電子機器から受信したことに応じて、前記第1の電子機器においてソフトウェアを復旧させる条件として予め定めた復旧条件を満たすか否かを判定し、前記復旧条件を満たすと判定した場合に、前記ソフトウェア保持部が保持するソフトウェアを前記第1の電子機器に送信するように制御する。

目的

本発明が解決しようとする課題は、検証に失敗した電子機器のソフトウェアを簡便且つ安全に復旧させることができるネットワーク監視装置、ネットワークシステムおよびプログラムを提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

ネットワーク監視するネットワーク監視装置であって、前記ネットワークに接続された第1の電子機器に適用しているソフトウェアを保持するソフトウェア保持部と、ソフトウェアの検証失敗を示す検証結果データを前記第1の電子機器から受信したことに応じて、前記第1の電子機器においてソフトウェアを復旧させる条件として予め定めた復旧条件を満たすか否かを判定し、前記復旧条件を満たすと判定した場合に、前記ソフトウェア保持部が保持するソフトウェアを前記第1の電子機器に送信するように制御する制御部と、を備えるネットワーク監視装置。

請求項2

前記制御部は、ソフトウェアの検証失敗を示す検証結果データを前記第1の電子機器から受信した場合に、前記ネットワークに接続された第2の電子機器に対して、該第2の電子機器に適用しているソフトウェアの検証を要求し、前記復旧条件は、前記第2の電子機器からソフトウェアの検証成功を示す検証結果データを受信するという条件を含む、請求項1に記載のネットワーク監視装置。

請求項3

前記第2の電子機器は、要求されるセキュリティレベルが前記第1の電子機器以上の電子機器である、請求項2に記載のネットワーク監視装置。

請求項4

前記第2の電子機器は、前記第1の電子機器と同じドメインに属する電子機器である、請求項2または3に記載のネットワーク監視装置。

請求項5

前記ネットワーク上に流れるデータおよび前記ネットワークに接続された電子機器の動作に関する情報をログとして記録するログ記録部と、前記ログを保持するログ保持部と、をさらに備え、前記制御部は、前記ログ保持部が保持するログを分析して、前記復旧条件を満たすか否かを判定する、請求項1乃至4のいずれか一項に記載のネットワーク監視装置。

請求項6

前記復旧条件は、セキュリティ上の問題が発生した兆候を示すログが記録されていないという条件を含む、請求項5に記載のネットワーク監視装置。

請求項7

前記復旧条件は、前記第1の電子機器においてソフトウェアの復旧が行われたことを示すログの記録回数所定回数以下であるという条件を含む、請求項5または6に記載のネットワーク監視装置。

請求項8

前記第1の電子機器の識別子と、前記第1の電子機器に適用しているソフトウェアの識別子との対応関係を示すテーブルを保持するテーブル保持部をさらに備え、前記検証結果データは、前記第1の電子機器の識別子を含み、前記制御部は、前記検証結果データに含まれる前記第1の電子機器の識別子と、前記テーブルとに基づいて、前記第1の電子機器に送信すべきソフトウェアを特定する、請求項1乃至7のいずれか一項に記載のネットワーク監視装置。

請求項9

前記テーブルは、前記第1の電子機器がソフトウェアの検証に用いる検証用参照値を示す項目をさらに含み、前記検証結果データは、前記第1の電子機器がソフトウェアの検証時に算出した検証値をさらに含み、前記制御部は、前記検証結果データに含まれる前記検証値と前記テーブルが示す前記検証用参照値とが異なり、かつ、前記復旧条件を満たすと判定した場合に、前記ソフトウェア保持部が保持するソフトウェアを前記第1の電子機器に送信するように制御する、請求項8に記載のネットワーク監視装置。

請求項10

前記制御部は、前記検証結果データに含まれる前記検証値と前記テーブルが示す前記検証用参照値とが一致する場合に、前記テーブルが示す前記検証用参照値を前記第1の電子機器に送信するように制御する、請求項9に記載のネットワーク監視装置。

請求項11

前記テーブルは、前記第1の電子機器に適用しているソフトウェアのバージョン情報を示す項目と、前記第1の電子機器に要求されるセキュリティレベルを示す項目と、前記第1の電子機器が有するセキュリティ機能の種類を示す項目と、前記第1の電子機器が属するドメインを示す項目と、の少なくともいずれかをさらに含む、請求項8乃至10のいずれか一項に記載のネットワーク監視装置。

請求項12

ネットワークに接続された第1の電子機器と、前記ネットワークを監視するネットワーク監視装置と、を含むネットワークシステムであって、前記第1の電子機器は、ソフトウェアの検証を行う検証部と、ソフトウェアの検証に失敗した場合に検証失敗を示す検証結果データを前記ネットワーク監視装置に送信し、前記ネットワーク監視装置からソフトウェアを受信する通信部と、を備え、前記ネットワーク監視装置は、前記第1の電子機器に適用しているソフトウェアを保持するソフトウェア保持部と、ソフトウェアの検証失敗を示す検証結果データを前記第1の電子機器から受信したことに応じて、前記第1の電子機器においてソフトウェアを復旧させる条件として予め定めた復旧条件を満たすか否かを判定し、前記復旧条件を満たすと判定した場合に、前記ソフトウェア保持部が保持するソフトウェアを前記第1の電子機器に送信するように制御する制御部と、を備えるネットワークシステム。

請求項13

ネットワークを監視するコンピュータが実行するプログラムであって、前記コンピュータは、前記ネットワークに接続された第1の電子機器に適用しているソフトウェアを保持し、前記コンピュータに、ソフトウェアの検証失敗を示す検証結果データを前記第1の電子機器から受信したことに応じて、前記第1の電子機器においてソフトウェアを復旧させる条件として予め定めた復旧条件を満たすか否かを判定し、前記復旧条件を満たすと判定した場合に、前記ソフトウェア保持部が保持するソフトウェアを前記第1の電子機器に送信するように制御する機能を実現させるためのプログラム。

技術分野

0001

本発明の実施形態は、ネットワーク監視装置ネットワークシステムおよびプログラムに関する。

背景技術

0002

ネットワークに接続された電子機器は、例えば当該電子機器に適用(インストール)されているソフトウェアが不正に改竄されたりすると正常に動作しなくなり、ネットワーク全体に悪影響を及ぼす虞がある。このため、ネットワークに接続される電子機器は、当該電子機器に適用されているソフトウェアが正規のものであることを保証することが望まれる。ソフトウェアの正しさを確認する方法として、セキュアブートなどの検証機能が知られている。セキュアブートは、電子機器の起動時にファームウェアなどのソフトウェアが正規のものであることを確認する機能である。セキュアブートによるソフトウェアの検証が成功する場合のみそのソフトウェア(プログラム)が実行され、電子機器が正常に起動できる。

0003

セキュアブートはネットワークの信頼性を確保する上で有効であり、例えば車載ネットワークシステムに接続される電子制御ユニット(ECU:Electronic Control Unit)などの電子機器への適用も検討されている。しかし、セキュアブートによるソフトウェアの検証が失敗すると電子機器が起動できなくなるため、検証に失敗したときの対策を考慮する必要がある。また、セキュアブートに限らず、検証に失敗した電子機器のソフトウェアを簡便且つ安全に復旧させることができる仕組みが求められている。

先行技術

0004

特許第5864510号公報
特開2014−179047号公報

発明が解決しようとする課題

0005

本発明が解決しようとする課題は、検証に失敗した電子機器のソフトウェアを簡便且つ安全に復旧させることができるネットワーク監視装置、ネットワークシステムおよびプログラムを提供することである。

課題を解決するための手段

0006

実施形態のネットワーク監視装置は、ソフトウェア保持部と、制御部と、を備える。ソフトウェア保持部は、ネットワークに接続された第1の電子機器に適用しているソフトウェアを保持する。制御部は、ソフトウェアの検証失敗を示す検証結果データを前記第1の電子機器から受信したことに応じて、前記第1の電子機器においてソフトウェアを復旧させる条件として予め定めた復旧条件を満たすか否かを判定し、前記復旧条件を満たすと判定した場合に、前記ソフトウェア保持部が保持するソフトウェアを前記第1の電子機器に送信するように制御する。

図面の簡単な説明

0007

車載ネットワークシステムの概略構成を示す図。
GWのハードウェア構成例を示すブロック図。
GWの機能的な構成例を示すブロック図。
ECU管理テーブルの構成例を示す図。
ログの構成例を示す図。
ECUの機能的な構成例を示すブロック図。
セキュアブートの処理手順の一例を示すフローチャート
ファームウェア復旧処理の処理手順の一例を示すフローチャート。
車載ネットワークシステムの概略構成を示す図。
サーバ装置が保持するログの構成例を示す図。

実施例

0008

実施形態のネットワーク監視装置、ネットワークシステムおよびプログラムは、例えば、車両に搭載される車載ネットワークシステムに適用できる。車載ネットワークシステムは、車両を制御する多数のECU(電子機器の一例)が通信を行うネットワークシステムである。一般的に、車載ネットワークシステムは、ECU間送受信されるメッセージ転送などを行う車載ゲートウェイ装置(以下、「GW」と略称する)を備える。GWは、メッセージの転送可否を適切に判断できるようにするために、ネットワークを監視する機能を持つものが多い。以下では、このような車載ネットワークシステムが備えるGWを、実施形態のネットワーク監視装置として構成した例を説明する。ただし、適用可能な装置やシステムは以下の例に限らない。本発明は、電子機器が通信を行う様々なネットワークシステムに対して広く適用可能である。

0009

<実施形態の概要
本実施形態では、車載ネットワークシステムの信頼性を確保するため、ネットワークに接続されたECUが、ソフトウェアの検証を行う検証機能を持つものとする。検証機能の一例として、本実施形態ではセキュアブートを想定する。また、検証の対象となるソフトウェアとして、ECUに適用されているファームウェアを想定する。ECUがセキュアブートを利用する場合、検証に成功した場合のみファームウェアのプログラムが実行され、ECUが正常に起動できる。一方、検証に失敗した場合はECUが起動できなくなるため、正規のファームウェアをECUに送信して、ECUのファームウェアを復旧させる必要がある。

0010

本実施形態では、ECUがセキュアブートによる検証に失敗して起動できない状態となったときに、このECUのファームウェアを簡便且つ安全に復旧できるようにするために、ネットワーク監視装置として機能するGWが、ネットワークに接続された各ECUに現在適用されているファームウェアを保持する。そして、GWは、ECUから検証失敗を示す検証結果データを受信すると、車載ネットワークシステムにセキュリティ上の問題がないことを確認した上で、ファームウェアの検証に失敗したECUに対して自身が保持するファームウェアを送信する。GWからファームウェアを受信したECUは、検証に失敗したファームウェアをGWから受信したファームウェアに置き換えることで、ファームウェアを復旧する。なお、本実施形態ではECUのファームウェアを検証する検証機能としてセキュアブートを想定するが、例えばTPM(Trusted Platform Module)を利用した検証機能など、セキュアブート以外の他の検証機能であってもよい。

0011

車載ネットワークシステムにセキュリティ上の問題がないことを確認するため、本実施形態では、GWが、ファームウェアの検証に失敗したECU(第1の電子機器)以外の他のECU(第2の電子機器)に対してファームウェアの検証を要求する。ファームウェアの検証を要求する対象となる他のECUとしては、例えば、セキュアブートによる検証機能を持ったすべてのECUであってもよいし、ファームウェアの検証に失敗したECUと同等以上のセキュリティレベルが要求されているECUであってもよい。電源FFしないECUについても、GWからの命令によりファームウェアの検証を行うことが可能である。GWは、例えば、ファームウェアの検証を要求したすべてのECUから検証成功を示す検証結果データを受信した場合、車載ネットワークシステムにセキュリティ上の問題がないと判断できる。

0012

また、GWは、ネットワーク上を流れるデータおよびネットワークに接続された各ECUの動作に関する情報をログとして記録・保持する機能を持つ。GWは、この機能により保持するログを分析することで、車載ネットワークシステム全体のセキュリティ状況を把握し、車載ネットワークシステムにセキュリティ上の問題がないことを確認することもできる。例えば、GWは、ログを分析して、セキュリティ上の問題が発生した兆候がないこと、ファームウェアの検証に失敗したECUにおいて過去にファームウェアの復旧が行われた回数所定回数を超えていないことなどを確認することで、車載ネットワークシステムにセキュリティ上の問題がないことを確認することができる。

0013

本実施形態のGWは、ファームウェアの検証に失敗したECUから検証失敗を示す検証結果データを受信した場合に、車載ネットワークシステムにセキュリティ上の問題がないと確認できたことを条件として、ファームウェアの検証に失敗したECUに対して自身が保持するファームウェアを送信する。つまり、上記の方法で車載ネットワークシステムにセキュリティ上の問題がないと確認できたことが、ファームウェアの検証に失敗したECUにおいてファームウェアを復旧させる条件(復旧条件)となる。本実施形態のGWは、ファームウェアの検証に失敗したECUから検証失敗を示す検証結果データを受信することに応じて、このような復旧条件を満たすか否かを判定し、復旧条件を満たす場合に、ファームウェアの検証に失敗したECUに対して自身が保持するファームウェアを送信し、ファームウェアを復旧させる。以下、添付図面を参照しながら、本実施形態をより詳細に説明する。

0014

<車載ネットワークシステムの概要>
図1は、本実施形態における車載ネットワークシステムの概略構成を示す図である。車載ネットワークシステムは、図1に示すように、ネットワーク監視装置として構成されるGW10と、複数のECU20a,20b,20c,・・・(以下、これらを総称する場合はECU20と表記する)とを含む。図1では、3つのECU20a,20b,20cを例示しているが、実際にはより多くのECU20がネットワークに接続される。これら多数のECU20は、複数のバスに分散して配置され、相互にメッセージの送受信を行う。図1では、ECU20aとECU20bとがバスB1に接続され、ECU20cがバスB2に接続された例を示している。

0015

GW10は、ネットワークの伝送路を構成する複数のバスのそれぞれに接続される。図1では、GW10がバスB1とバスB2の双方に接続された例を示している。あるバス上のECU20が他のバス上のECU20に対してメッセージを送信する場合、GW10は、そのメッセージの転送を行う。本実施形態では、各ECU20がCAN(Controller Area Network)のプロトコルに従った通信を行うことを想定する。本実施形態におけるGW10は、このようなECU20間の通信を中継する本来の機能のほかに、上述したECU20におけるファームウェアの復旧を制御する機能を持つ。

0016

なお、図1に示した車載ネットワークシステムの構成は一例であり、この例に限らない。また、通信方式もCANに限らず、例えばFlexRay(登録商標)など、他の通信方式であってもよい。また、互いに通信方式の異なるサブネットワークがGW10を介して接続された構成であってもよい。また、本実施形態ではGW10がネットワーク監視装置としての機能を持つものとするが、GW10に代えて、あるいはGW10とともに他の1以上のECU20にネットワーク監視装置としての機能を持たせてもよい。また、GW10やECU20とは別体の(独立の)ネットワーク監視装置を車載ネットワークシステムに接続する構成であってもよい。

0017

<ハードウェア構成>
図2は、本実施形態におけるGW10のハードウェア構成例を示すブロック図である。GW10は、例えば図2に示すように、マイコン100と、バスB1に接続されたトランシーバ110aおよびバスB2に接続されたトランシーバ110bと、フラッシュメモリ120とを備える。トランシーバ110a,110bは、バスB1,B2における差動電位をデジタル信号に変換したり、デジタル信号を差動電位に変換したりといったアナログ処理を行う送受信機である。フラッシュメモリ120は、GW10が保持する各種データ、例えば、後述のECU管理テーブル、各ECU20に適用しているファームウェア、記録されたログなどを記憶する大容量記憶装置である。

0018

マイコン100は、デジタル信号処理を行う集積回路であり、CPU101、RAM102、ROM103、通信コントローラ104a,104b、およびSSD(Solid State Drive)105などが実装されている。CPU101は、所定のプログラムを実行してGW10全体の動作を制御するプロセッサである。RAM102は、CPU101がプログラムを実行する際のワークエリアとなるメモリであり、ROM103は、CPU101が実行するプログラムやデータを格納するメモリである。通信コントローラ104a,104bは、トランシーバ110a,120bと協働して、バスB1,B2間で送受信されるメッセージの転送を行うためのコントローラである。SSD105は、フラッシュメモリ120に対するデータの書き込みや読み出しを制御する機器である。

0019

なお、図2はGW10のハードウェア構成例を示しているが、ECU20のハードウェア構成も、基本的には図2に示したGW10のハードウェア構成と同様である。図2の構成例では、GW10が2つのバスB1,B2に接続されていることを想定して、2つのバスB1,B2に対応する2つのトランシーバ110a,110bおよびマイコン100内の通信コントローラ104a,104bを備えるが、各ECU20は、自身が接続されるバスに対応するトランシーバおよび通信コントローラを備えていればよい。

0020

<GWの機能構成
図3は、本実施形態におけるGW10の機能的な構成例を示すブロック図である。GW10は、ECU20におけるファームウェアの復旧に関わる機能的な構成要素として、図3に示すように、通信部11と、復旧制御部12(制御部)と、ログ記録部13と、保持部14と、を備える。保持部14は、ソフトウェア保持部15、テーブル保持部16、およびログ保持部17を有する。

0021

これら図3に示すGW10の機能的な構成要素は、一例として、図2に示したハードウェアとソフトウェア(プログラム)との協働により実現することができる。通信部11は、例えば、マイコン100内の通信コントローラ104a,104bとトランシーバ110a,110bとにより実現できる。復旧制御部12は、例えば、マイコン100内のCPU101が、RAM102をワークエリアとして利用して、ROM103に格納されたプログラムを読み出して実行することにより実現できる。ログ記録部13は、例えば、マイコン100内のCPU101が実行するプログラムとSSD105とにより実現できる。保持部14は、例えば、マイコン100内のSSD105とフラッシュメモリ120とにより実現できる。

0022

通信部11は、ネットワークに接続されたECU20の通信部21(図6参照)との間でネットワークの伝送路を介したデータ交換を行う機能である。通信部11は、例えば、ネットワークに接続されたECU20から検証結果データを受信したり、復旧制御部12により指定されたECU20に対して検証要求やファームウェアを送信したりする。

0023

復旧制御部12は、ネットワークに接続されたECU20におけるファームウェアの復旧を制御する機能である。復旧制御部12は、ネットワークに接続されたECU20(第1の電子機器)からセキュアブートによるファームウェアの検証失敗を示す検証結果データを通信部11が受信した場合に、ECU20においてファームウェアを復旧させるための条件として予め定めた復旧条件を満たすか否かを判定する。そして、復旧条件を満たすと判定した場合、復旧制御部12は、検証結果データの送信元のECU20に対応するファームウェアをソフトウェア保持部15から取得し、取得したファームウェアを通信部11から検証結果データの送信元のECU20に送信するように制御する。

0024

本実施形態では、上述の復旧条件として、以下の条件1と条件2と条件3の3つの条件が定められているものとする。

0025

条件1:ファームウェアの検証に失敗したECU20(第1の電子機器)以外の他のECU20(第2の電子機器)において、ファームウェアの検証に失敗しないこと。

0026

復旧制御部12は、通信部11がネットワーク上のあるECU20からファームウェアの検証失敗を示す検証結果データを受信した場合に、ファームウェアの検証に失敗したECU20以外の他のECU20に対して、ファームウェアの検証要求を通信部11から送信するように制御する。そして、ファームウェアの検証を要求した他のECU20から、検証要求に対する応答として検証成功を示す検証結果データを通信部11が受信した場合に、上記の条件1を満たすと判定する。ここで、ファームウェアの検証を要求する対象となる他のECU20としては、例えば、セキュアブートによる検証機能を持ったすべてのECU20であってもよいし、ファームウェアの検証に失敗したECU20と同等以上のセキュリティレベルが要求されているECU20であってもよい。

0027

条件2:車載ネットワークシステムにセキュリティ上の問題が発生した兆候を示すログが記録されていないこと。

0028

復旧制御部12は、後述のログ記録部13により記録され、ログ保持部17に保持されたログを分析して、車載ネットワークシステムにセキュリティ上の問題が発生した兆候を示すログが記録されていないことが確認できた場合に、上記の条件2を満たすと判定する。ここで、車載ネットワークシステムにセキュリティ上の問題が発生した兆候とは、例えば、あるECU20においてファームウェアが更新された後にネットワーク上で通信エラーが頻発するようになった状況などである。こうした状況は、後述のログ記録部13により記録され、ログ保持部17に保持されたログを分析することで確認できる。

0029

条件3:ファームウェアの検証に失敗したECU20において、過去にファームウェアの復旧が行われたことを示すログの記録回数が所定回数以下であること。

0030

復旧制御部12は、後述のログ記録部13により記録され、ログ保持部17に保持されたログを分析して、ファームウェアの検証に失敗したECU20において、過去にファームウェアの復旧が行われたことを示すログの記録回数が所定回数以下であることが確認できた場合に、上記の条件3を満たすと判定する。この条件3の判定を可能にするため、後述のログ記録部13は、復旧制御部12の制御によりファームウェアの検証に失敗したECU20に対してファームウェアが送信された場合に、ECU20においてファームウェアが復旧されたことをログとして記録する。

0031

復旧制御部12は、例えば、上記の条件1から条件3のすべてを満たす場合に、ファームウェアの検証に失敗したECU20に対して、そのECU20に対応したファームウェアを送信するように制御し、ECU20においてファームウェアを復旧させる。なお、上記の条件1から条件3は復旧条件の一例であり、これに限らない。例えば、上記条件1から条件3のいずれか、または任意の組み合わせを復旧条件として予め定めてもよいし、上記の条件1から条件3以外の他の条件が含まれていてもよい。

0032

ログ記録部13は、ネットワーク上を流れるデータおよびネットワークに接続された各ECU20の動作に関する情報をログとして記録する機能である。ネットワーク上を流れるデータに関する情報としては、例えば、メッセージの通信履歴や、ネットワーク上で発生した通信エラーの履歴などが挙げられる。また、ネットワークに接続された各ECU20の動作に関する情報としては、例えば、各ECU20におけるファームウェアの更新や復旧動作の履歴などが挙げられる。ログ記録部13がログとして記録する情報は、これらネットワーク上を流れるデータおよびネットワークに接続された各ECU20の動作に関する情報に限らず、ログ形態で記録することが可能な他の情報が含まれていてもよい。

0033

ソフトウェア保持部15は、ネットワークに接続されたECU20(第1の電子機器)に現在適用しているファームウェアの実体データ(例えばプログラム本体)および関連データ(例えば当該ファームウェアを適用しているECU20の識別子(ECU ID))を保持する機能である。以下では、ECU20に現在適用しているファームウェアの実体データを「現ファームウェア」と呼ぶ。ソフトウェア保持部15は、ネットワークに接続されたすべてのECU20について、現ファームウェアおよび関連データを保持する構成であってもよいし、ネットワークに接続されたECU20のうち、セキュアブートによる検証機能を持ったECU20のみについて、現ファームウェアおよび関連データを保持する構成であってもよい。

0034

テーブル保持部16は、ネットワークに接続されたECU20の識別子(ECU ID)と、現ファームウェアの識別子(FW ID)との対応関係を示すECU管理テーブルを保持する機能である。復旧制御部12は、このテーブル保持部16が保持するECU管理テーブルを参照することで、ソフトウェア保持部15が保持する現ファームウェアのうち、検証結果データの送信元のECU20に対応する現ファームウェアを特定することができる。

0035

テーブル保持部16が保持するECU管理テーブルの構成例を図4に示す。ECU管理テーブルは、例えば図4に示すように、ECU20の識別子である「ECU ID」と、現ファームウェアの識別子である「FW ID」のほかに、現ファームウェアのバージョン情報である「Ver.No」、「検証用参照値」、「セキュリティレベル」、「セキュリティ機能の種類」、および「ドメイン」を項目として含む。テーブル保持部16が保持するECU管理テーブルは、例えば、図4に例示する項目の情報をECU20ごとに持つテーブルである。

0036

「検証用参照値」は、セキュアブートによるファームウェアの検証に用いる値であり、ECU20との間で事前共有した値である。セキュアブートによるファームウェアの検証にMAC(Message Authentication Code)を用いる場合、ECU20との間で事前に共有したMAC値が検証用参照値となる。セキュアブートによるファームウェアの検証にハッシュを用いる場合、ECU20との間で事前に共有したハッシュ値が検証用参照値となる。ECU20がセキュアブートによるファームウェアの検証を行う場合、ファームウェアから算出される検証値(MAC値あるいはハッシュ値)が、GW10との間で事前に共有した検証用参照値と一致する場合に検証成功となり、一致しない場合は検証失敗となる。

0037

「セキュリティレベル」は、ECU20に要求されるセキュリティレベルである。セキュリティレベルは、機能により車両の安全運転に対する影響度を表す。例えば、ISO26262のASIL(Automotive Safety Integrity Level)で決定されたレベルがあり、エネルギ系のECU20のセキュリティレベルはボディ系のECUのセキュリティレベルよりも高い。

0038

「セキュリティ機能の種類」は、ECU20が有するセキュリティ機能の種類を示す情報である。例えば、セキュアブートによる検証にMACを用いる、あるいはハッシュを用いるといった情報などが、セキュリティ機能の種類として格納される。

0039

「ドメイン」は、ECU20が属するドメインを示す情報である。ドメインは、機能によりECU20をグループ分けした場合のグループであり、例えばドアミラーなどで構成されるボディ系ドメイン、エンジンブレーキなどで構成されるエネルギ系ドメインなどが挙げられる。

0040

ログ保持部17は、ログ記録部13が記録したログを保持する機能である。復旧制御部12は、このログ保持部17が保持するログを分析することで、上記の条件2や条件3を満たすか否かを判定することができる。

0041

ログ保持部17が保持するログの構成例を図5に示す。図5(a)はCANプロトコルの定義に従った通信エラーのログの構成例を示し、図5(b)はECU20のセキュアブートに関する動作エラーのログの構成例を示している。

0042

通信エラーのログは、例えば図5(a)に示すように、「CAN ID」、「エラー情報」、および「時間情報」を項目として含む。「CAN ID」は、エラー発生時のCANメッセージの識別子である。「エラー情報」は、CANプロトコルで定義されたエラーの種類を示す情報である。「時間情報」は、エラーの発生時間を示す情報である。なお、ネットワークの通信プロトコルとしてCAN以外を使用する場合は、使用する通信プロトコルの定義に従って、通信エラーのログに含まれる項目を予め設定すればよい。

0043

動作エラーのログは、例えば図5(b)に示すように、「ECU ID」、「FW ID」、「Ver.No」、「エラー情報」、および「時間情報」を項目として含む。「ECU ID」は、エラーが発生したECU20の識別子である。「FW ID」は、そのECU20の現ファームウェアの識別子であり、「Ver.No」は、そのECU20の現ファームウェアのバージョン情報である。「エラー情報」は、エラーの種類(セキュアブートに関する動作エラーであれば“復旧”や“検証失敗”など)を示す情報である。なお、“復旧”はECU20において検証に失敗したファームウェアが復旧したことを示し、厳密には動作エラーではないが、本実施形態では、復旧制御部12がECU20のファームウェアを復旧させた場合に、ログ記録部13がその情報を動作エラーのログとして記録するようにしている。「時間情報」は、エラーの発生時間を示す情報である。

0044

<ECUの機能構成>
図6は、ECU20の機能的な構成例を示すブロック図である。ECU20は、ファームウェアの検証に関わる機能的な構成要素として、図6に示すように、通信部21と、保持部22と、検証部23と、を備える。これら図6に示すECU20の機能的な構成要素は、一例として、図2に示したGW10と同様のハードウェアとソフトウェア(プログラム)との協働により実現することができる。

0045

通信部21は、GW10の通信部11との間でネットワークの伝送路を介したデータ交換を行う機能である。通信部21は、例えば、検証部23によるファームウェアの検証結果に応じた検証結果データをGW10に送信したり、GW10から現ファームウェアや検証要求を受信したりする。

0046

保持部22は、ECU20のファームウェアを保持する機能である。保持部22が保持するファームウェアは、プログラム本体および実行データ集合である。実行データの具体例としては、そのファームウェアの検証値が挙げられる。

0047

検証部23は、保持部22が保持するファームウェアに対して、セキュアブートによる検証を行う機能である。セキュアブートによるファームウェアの検証は、保持部22が保持するファームウェアの検証値を算出し、算出した検証値を、事前に保持した検証用参照値と比較することにより行う。算出した検証値が検証用参照値と一致する場合、セキュアブートによるファームウェアの検証は成功となる。一方、算出した検証値が検証用参照値と一致しない場合、セキュアブートによるファームウェアの検証は失敗となる。セキュアブートによる検証が成功した場合のみ、保持部22が保持するファームウェアが実行され、ECU20が正常に動作する。セキュアブートによるファームウェアの検証が失敗した場合は、通信部21からGW10に対して、検証失敗を示す検証結果データが送信され、GW10から現ファームウェアを受信する。なお、GW10からの検証要求に応じて検証部23がファームウェアの検証を行った場合は、検証が成功した場合も失敗した場合も、その検証結果を示す検証結果データが通信部21からGW10に送信される。

0048

<セキュアブートの処理手順>
図7は、ECU20の検証部23により実行されるセキュアブートの処理手順の一例を示すフローチャートである。この図7に示す一連の処理は、例えば、ECU20が通電されたときに開始される。

0049

図7に示す処理が開始されると、まず検証部23が、保持部22からファームウェアを読み出す(ステップS101)。そして、検証部23は、ステップS101で読み出したファームウェアの検証値を算出する(ステップS102)。

0050

次に、検証部23は、ステップS102で算出した検証値を事前に保持した検証用参照値と比較して、検証値が検証用参照値と一致するか否かを判定する(ステップS103)。ここで、検証値が検証用参照値と一致する場合(ステップS103:Yes)、ファームウェアのプログラムが実行され(ステップS104)、ECU20が正常にブートすることでセキュアブートの処理が終了する。

0051

一方、検証値が検証用参照値と一致しない場合(ステップS103:No)、通信部21からGW10に対して検証失敗を示す検証結果データが送信される(ステップS105)。この検証結果データには、例えば、ECU20の識別子(ECU ID)や、ステップS102で算出したファームウェアの検証値などが含まれる。また、検証に失敗したファームウェアの識別子(FW ID)およびバージョン情報(Ver.No)が検証結果データに含まれていてもよい。なお、ステップS102の検証値の算出において、本実施形態ではファームウェアのプログラムに限定しているが、必要によりプログラムを含めるデータ全体の検証も可能である。

0052

その後、通信部21が、GW10から送信された現ファームウェアを受信する(ステップS106)。GW10から受信した現ファームウェアは、保持部22に格納される。なお、以上はECU20が通電されたときに開始されるセキュアブートの処理手順を示しているが、通信部21がGW10からファームウェアの検証要求を受信した場合も、同様の手順によりファームウェアの検証が行われる。ただし、GW10からの検証要求に応じてファームウェアの検証を行う場合は、ステップS102で算出した検証値が事前に保持した検証用参照値と一致しない場合(ステップS103:No)だけでなく、検証値が検証用参照値と一致する場合(ステップS103:Yes)にも、通信部21からGW10に対して検証結果データ(この場合は検証成功を示す検証結果データ)が送信される。

0053

<ファームウェア復旧処理の処理手順>
図8は、主にGW10の復旧制御部12により実施されるファームウェア復旧処理の処理手順の一例を示すフローチャートである。この図8に示す一連の処理は、GW10の通信部11が、ネットワーク上のあるECU20からファームウェアの検証失敗を示す検証結果データを受信したときに開始される。

0054

図8に示す処理が開始されると、まず、復旧制御部12が、受信部11により受信された検証結果データに含まれるECU IDをキーとしてテーブル保持部16が保持するECU管理テーブルを検索し、検証結果データの送信元のECU20に対応する検証用参照値を取得する(ステップS201)。

0055

次に、復旧制御部12は、受信部11により受信された検証結果データに含まれる検証値をステップS201で取得した検証用参照値と比較して、検証値が検証用参照値と一致するか否かを判定する(ステップS202)。ここで両者が一致する場合(ステップS202:Yes)、ECU20が保持する検証用参照値の故障(変化、破損)が原因でファームウェアの検証に失敗したと判断できる。このため、復旧制御部12は、ステップS201で取得した検証用参照値を通信部11から検証結果データの送信元のECU20に送信するように制御する(ステップS203)。これにより、ECU20の検証用参照値を復旧させることができる。また、この場合、ログ記録部13が、ECU20の検証用参照値が復旧されたことを示すログを記録して(ステップS211)、ファームウェア復旧処理を終了する。その後、ECU20は、復旧した検証用参照値を用いてセキュアブートの処理を再度実行することで、正常に起動するようになる。

0056

一方、検証結果データに含まれる検証値がステップS201で取得した検証用参照値と一致しない場合は(ステップS202:No)、復旧制御部12は、次に、ファームウェアの検証を要求する対象となるECU20を決定し(ステップS204)、ステップS204で決定したECU20に対して、通信部11からファームウェアの検証要求を送信するように制御する(ステップS205)。ファームウェアの検証を要求する対象となるECU20は、上述したように、セキュアブートによる検証機能を持ったすべてのECU20(ファームウェアの検証に失敗したECU20と同じセキュリティ機能を有するECU20)であってもよいし、ファームウェアの検証に失敗したECU20と同等以上のセキュリティレベルが要求されているECU20であってもよい。復旧制御部12は、例えばテーブル保持部16が保持するECU管理テーブルを参照することで、ファームウェアの検証を要求する対象となるECU20を決定することができる。

0057

その後、復旧制御部12は、通信部11が検証要求を送信したすべてのECU20から検証成功を示す検証結果データを受信したか否かを判定する(ステップS206)。ここで、いずれかのECU20から検証失敗を示す検証結果データを受信した場合や検証結果データを受信できないECU20がある場合(ステップS206:No)、復旧制御部12は、ファームウェアの復旧不可を示すアラートが出力されるように制御する(ステップS207)。アラートの一例としては、車両のメーターパネルにアラートマークを示すことなどが挙げられる。また、この場合、ログ記録部13が、ステップS211において、ファームウェアの検証失敗を示す動作エラーのログを記録し、ファームウェア復旧処理を終了する。このログは、例えば図5(b)に例示した動作エラーのログとして、ログ保持部17に保持される。

0058

一方、検証要求を送信したすべてのECU20から検証成功を示す検証結果データを受信した場合は(ステップS206:Yes)、復旧制御部12は、次に、ログ保持部17が保持するログを分析して、車載ネットワークシステムにセキュリティ上の問題が発生した兆候を示すログが記録されているか否かを判定する(ステップS208)。ここで、車載ネットワークシステムにセキュリティ上の問題が発生した兆候を示すログが記録されていると判定した場合(ステップS208:Yes)、復旧制御部12は、ステップS207において、ファームウェアの復旧不可を示すアラートが出力されるように制御する。また、ログ記録部13が、ステップS211において、ファームウェアの検証失敗を示す動作エラーのログを記録し、ファームウェア復旧処理を終了する。

0059

一方、車載ネットワークシステムにセキュリティ上の問題が発生した兆候を示すログが記録されていないと判定した場合は(ステップS208:No)、復旧制御部12は、次に、ログ保持部17が保持するログを分析して、ファームウェアの検証に失敗したECU20において、過去にファームウェアの復旧が行われたことを示すログの記録回数が所定回数を超えるか否かを判定する(ステップS209)。ここで、過去にファームウェアの復旧が行われたことを示すログの記録回数が所定回数を超える場合(ステップS209:Yes)、復旧制御部12は、ステップS207において、ファームウェアの復旧不可を示すアラートが出力されるように制御する。また、ログ記録部13が、ステップS211において、ファームウェアの検証失敗を示す動作エラーのログを記録し、ファームウェア復旧処理を終了する。

0060

一方、ファームウェアの検証に失敗したECU20において、過去にファームウェアの復旧が行われたことを示すログの記録回数が所定回数以下である場合は(ステップS209:No)、復旧制御部12は、ファームウェアの検証に失敗したECU20においてファームウェアを復旧させる条件である復旧条件を満たすと判断し、このECU20に対して、ソフトウェア保持部15が保持する現ファームウェアを通信部11から送信するように制御する(ステップS210)。例えば、復旧制御部12は、このECU20から受信した検証結果データに含まれるECU IDをキーとしてテーブル保持部16が保持するECU管理テーブルを検索し、このECU20に対応するFW IDを取得する。そして、取得したFW IDで識別される現ファームウェアをソフトウェア保持部15から読み出して、通信部11からECU20に対して送信する。なお、ECU20で検証に失敗したファームウェアのFW IDやVer.Noが検証結果データに含まれている場合は、これらの情報をもとにECU20に送信する現ファームウェアを特定することもできる。

0061

ファームウェアの検証に失敗したECU20に対し、復旧制御部12の制御によりソフトウェア保持部15が保持する現ファームウェアが送信された場合は、ログ記録部13が、ステップS211において、ECU20のファームウェアが復旧されたことを示すログを記録して、ファームウェア復旧処理を終了する。このログは、例えば図5(b)に例示した動作エラーのログとして、ログ保持部17に保持される。

0062

<実施形態の効果>
以上、具体的な例を挙げながら詳細に説明したように、本実施形態では、車載ネットワークシステムのGW10が、ネットワークに接続された各ECU20の現ファームウェアを保持する。そして、GW10は、あるECU20からファームウェアの検証失敗を示す検証結果データを受信すると復旧条件を満たすか否かを判定し、復旧条件を満たすと判定した場合に、検証結果データの送信元のECU20に対して、当該ECU20に対応する現ファームウェアを送信して復旧させる。したがって、本実施形態によれば、検証に失敗したECU20のファームウェアを簡便且つ安全に復旧させることができる。

0063

検証に失敗したECU20のファームウェアを復旧させる方法としては、例えば、車載ネットワークシステムをOEMサーバなどの外部サーバに接続し、この外部サーバから検証に失敗したECU20の現ファームウェアをダウンロードさせる方法が考えられる。しかしこの方法は、車載ネットワークシステム(つまり車両)が外部サーバに接続できる環境下にあることが前提となるため、車両がこのような環境下にない場合はECU20のファームウェアを復旧させることができず、車両を運転できなくなる場合がある。また、外部サーバは車載ネットワークシステムのセキュリティ状況を把握できないため、車載ネットワークシステムにセキュリティ上の問題が発生しているにも関わらず、外部サーバからECU20の現ファームウェアをダウンロードさせてしまい、問題が深刻化する虞もある。

0064

これに対し、本実施形態によれば、車載ネットワークシステム内のGW10がECU20の現ファームウェアを保持し、復旧条件を満たすか否かの判定により車載ネットワークシステムにセキュリティ上の問題がないことを確認した上で、ファームウェアの検証に失敗したECU20に対して当該ECU20に対応する現ファームウェアを送信するようにしているので、検証に失敗したECU20のファームウェアを簡便且つ安全に復旧させることができる。

0065

なお、上述の実施形態においては様々な変形例が考えられる。以下では、変形例のいくつかを説明する。

0066

<第1変形例>
上述の実施形態では、GW10が、上記の条件1の判定のために、セキュアブートによる検証機能を持ったすべてのECU20、あるいはファームウェアの検証に失敗したECU20と同等以上のセキュリティレベルが要求されているECU20を対象としてファームウェアの検証を要求しているが、ファームウェアの検証を要求する対象となるECU20はこれに限らない。例えば、ファームウェアの検証に失敗したECU20と同じドメインに属するECU20を、ファームウェアの検証を要求する対象に加えてもよい。ファームウェアの検証に失敗したECU20と同じドメインに属するECU20は、例えばテーブル保持部16が保持するECU管理テーブルを参照することで特定できる。

0067

<第2変形例>
上述の実施形態では、ECU20においてセキュアブートによるファームウェアの検証を行う場合、ファームウェアの検証値を1つ算出し、この検証値を予め保持した1つの検証用参照値と比較するものとしているが、ファームウェアをプログラムと設定データに分けて検証することも可能である。この場合、ファームウェアのプログラムの検証値と設定データの検証値とを算出する。そして、プログラムの検証値をプログラムの検証に用いる検証用参照値と比較するとともに、設定データの検証値を設定データの検証に用いる検証用参照値とを比較して、それぞれの検証値と検証用参照値とがともに一致する場合にプログラムが実行される構成としてもよい。この場合、ECU20は、プログラムの検証に用いる検証用参照値と設定データの検証に用いる検証用参照値とを保持する。また、GW10のテーブル保持部16が保持するECU管理テーブルには、プログラムの検証に用いる検証用参照値と設定データの検証に用いる検証用参照値とが格納される。

0068

<第3変形例>
上述の実施形態では、GW10が、上記の条件2および条件3の判定のために、ログ保持部17が保持するログを分析しているが、OEMサーバなどの外部サーバが保持するログも併せて分析することで、例えば同一車種の他の車両などにおいて、同様のセキュリティ上の問題が発生していないかなどを確認することも可能となる。

0069

図9は、本変形例における車載ネットワークシステムの概略構成を示す図である。図9に示す車載ネットワークシステムの構成は、基本的には図1に示した構成と同様であるが、バスB2に接続されたECU20cが図示しないデジタル通信モジュール(DCM:Digital Communication Module)に接続され、移動体通信網を含む車外のネットワークNを介して、OEMサーバなどの車外のサーバ装置30と通信可能な構成となっている。

0070

本変形例においては、GW10が上述したログを記録する際に、他の車両における故障診断などに役立つ情報(例えばECU20の動作エラーのログ)については、ECU20cからネットワークNを介してサーバ装置30にアップロードする。サーバ装置20は、ある車両の車載ネットワークシステムから受信したログを、その車両の識別子(車両ID)と対応付けて保持する。また、GW10は、例えば上述のファームウェア復旧処理を実施する際に、ECU20cからネットワークNを介してサーバ装置30にアクセスし、同一車種の他の車両のログを取得して、自身が保持するログに加えて同一車種の他の車両のログも分析することにより、上述の復旧条件を満たすか否かを判定することも可能である。

0071

サーバ装置30が保持するログの構成例を図10に示す。この図10に例示するログは、ECU20のセキュアブートに関する動作エラーのログであり、図5(b)に示したGW10が保持する動作エラーのログに対し、車両の識別子である車両IDの項目が追加されている。

0072

<第4変形例>
上述の実施形態は、車両に搭載される車載ネットワークシステムに本発明を適用した例であるが、本発明は、電子機器が通信を行う様々なネットワークシステムに対して広く適用できる。例えば、通信機能を持った家電機器が接続されたホームネットワークシステムなどへの適用が考えられる。このようなホームネットワークシステムでは、ネットワークを監視するホームゲートウェイが、例えばロボット掃除機などの動作履歴をログとして記録・保持するものがあり、このホームゲートウェイに、上述のGW10と同様の機能を持たせることができる。

0073

以上、本発明の実施形態を説明したが、ここで説明した実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。ここで説明した新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。ここで説明した実施形態やその変形は、発明の範囲や要旨に含まれるとともに、請求の範囲に記載された発明とその均等の範囲に含まれる。

0074

10 GW
11通信部
12復旧制御部
13ログ記録部
14 保持部
15ソフトウェア保持部
16 テーブル保持部
17ログ保持部
20 ECU
21 通信部
22 保持部
23 検証部

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ