JP2018045392A - ネットワーク監視装置、ネットワークシステムおよびプログラム - Google Patents

Abstract

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

Description

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

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

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

特許第５８６４５１０号公報 特開２０１４−１７９０４７号公報

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

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

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

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

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

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

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

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

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

＜車載ネットワークシステムの概要＞
図１は、本実施形態における車載ネットワークシステムの概略構成を示す図である。車載ネットワークシステムは、図１に示すように、ネットワーク監視装置として構成されるＧＷ１０と、複数のＥＣＵ２０ａ，２０ｂ，２０ｃ，・・・（以下、これらを総称する場合はＥＣＵ２０と表記する）とを含む。図１では、３つのＥＣＵ２０ａ，２０ｂ，２０ｃを例示しているが、実際にはより多くのＥＣＵ２０がネットワークに接続される。これら多数のＥＣＵ２０は、複数のバスに分散して配置され、相互にメッセージの送受信を行う。図１では、ＥＣＵ２０ａとＥＣＵ２０ｂとがバスＢ１に接続され、ＥＣＵ２０ｃがバスＢ２に接続された例を示している。

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

なお、図１に示した車載ネットワークシステムの構成は一例であり、この例に限らない。また、通信方式もＣＡＮに限らず、例えばＦｌｅｘＲａｙ（登録商標）など、他の通信方式であってもよい。また、互いに通信方式の異なるサブネットワークがＧＷ１０を介して接続された構成であってもよい。また、本実施形態ではＧＷ１０がネットワーク監視装置としての機能を持つものとするが、ＧＷ１０に代えて、あるいはＧＷ１０とともに他の１以上のＥＣＵ２０にネットワーク監視装置としての機能を持たせてもよい。また、ＧＷ１０やＥＣＵ２０とは別体の（独立の）ネットワーク監視装置を車載ネットワークシステムに接続する構成であってもよい。

＜ハードウェア構成＞
図２は、本実施形態におけるＧＷ１０のハードウェア構成例を示すブロック図である。ＧＷ１０は、例えば図２に示すように、マイコン１００と、バスＢ１に接続されたトランシーバ１１０ａおよびバスＢ２に接続されたトランシーバ１１０ｂと、フラッシュメモリ１２０とを備える。トランシーバ１１０ａ，１１０ｂは、バスＢ１，Ｂ２における差動電位をデジタル信号に変換したり、デジタル信号を差動電位に変換したりといったアナログ処理を行う送受信機である。フラッシュメモリ１２０は、ＧＷ１０が保持する各種データ、例えば、後述のＥＣＵ管理テーブル、各ＥＣＵ２０に適用しているファームウェア、記録されたログなどを記憶する大容量記憶装置である。

マイコン１００は、デジタル信号処理を行う集積回路であり、ＣＰＵ１０１、ＲＡＭ１０２、ＲＯＭ１０３、通信コントローラ１０４ａ，１０４ｂ、およびＳＳＤ（Solid State Drive）１０５などが実装されている。ＣＰＵ１０１は、所定のプログラムを実行してＧＷ１０全体の動作を制御するプロセッサである。ＲＡＭ１０２は、ＣＰＵ１０１がプログラムを実行する際のワークエリアとなるメモリであり、ＲＯＭ１０３は、ＣＰＵ１０１が実行するプログラムやデータを格納するメモリである。通信コントローラ１０４ａ，１０４ｂは、トランシーバ１１０ａ，１２０ｂと協働して、バスＢ１，Ｂ２間で送受信されるメッセージの転送を行うためのコントローラである。ＳＳＤ１０５は、フラッシュメモリ１２０に対するデータの書き込みや読み出しを制御する機器である。

なお、図２はＧＷ１０のハードウェア構成例を示しているが、ＥＣＵ２０のハードウェア構成も、基本的には図２に示したＧＷ１０のハードウェア構成と同様である。図２の構成例では、ＧＷ１０が２つのバスＢ１，Ｂ２に接続されていることを想定して、２つのバスＢ１，Ｂ２に対応する２つのトランシーバ１１０ａ，１１０ｂおよびマイコン１００内の通信コントローラ１０４ａ，１０４ｂを備えるが、各ＥＣＵ２０は、自身が接続されるバスに対応するトランシーバおよび通信コントローラを備えていればよい。

＜ＧＷの機能構成＞
図３は、本実施形態におけるＧＷ１０の機能的な構成例を示すブロック図である。ＧＷ１０は、ＥＣＵ２０におけるファームウェアの復旧に関わる機能的な構成要素として、図３に示すように、通信部１１と、復旧制御部１２（制御部）と、ログ記録部１３と、保持部１４と、を備える。保持部１４は、ソフトウェア保持部１５、テーブル保持部１６、およびログ保持部１７を有する。

これら図３に示すＧＷ１０の機能的な構成要素は、一例として、図２に示したハードウェアとソフトウェア（プログラム）との協働により実現することができる。通信部１１は、例えば、マイコン１００内の通信コントローラ１０４ａ，１０４ｂとトランシーバ１１０ａ，１１０ｂとにより実現できる。復旧制御部１２は、例えば、マイコン１００内のＣＰＵ１０１が、ＲＡＭ１０２をワークエリアとして利用して、ＲＯＭ１０３に格納されたプログラムを読み出して実行することにより実現できる。ログ記録部１３は、例えば、マイコン１００内のＣＰＵ１０１が実行するプログラムとＳＳＤ１０５とにより実現できる。保持部１４は、例えば、マイコン１００内のＳＳＤ１０５とフラッシュメモリ１２０とにより実現できる。

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

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

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

条件１：ファームウェアの検証に失敗したＥＣＵ２０（第１の電子機器）以外の他のＥＣＵ２０（第２の電子機器）において、ファームウェアの検証に失敗しないこと。

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

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

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

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

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

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

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

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

テーブル保持部１６は、ネットワークに接続されたＥＣＵ２０の識別子（ＥＣＵ ＩＤ）と、現ファームウェアの識別子（ＦＷ ＩＤ）との対応関係を示すＥＣＵ管理テーブルを保持する機能である。復旧制御部１２は、このテーブル保持部１６が保持するＥＣＵ管理テーブルを参照することで、ソフトウェア保持部１５が保持する現ファームウェアのうち、検証結果データの送信元のＥＣＵ２０に対応する現ファームウェアを特定することができる。

テーブル保持部１６が保持するＥＣＵ管理テーブルの構成例を図４に示す。ＥＣＵ管理テーブルは、例えば図４に示すように、ＥＣＵ２０の識別子である「ＥＣＵ ＩＤ」と、現ファームウェアの識別子である「ＦＷ ＩＤ」のほかに、現ファームウェアのバージョン情報である「Ｖｅｒ．Ｎｏ」、「検証用参照値」、「セキュリティレベル」、「セキュリティ機能の種類」、および「ドメイン」を項目として含む。テーブル保持部１６が保持するＥＣＵ管理テーブルは、例えば、図４に例示する項目の情報をＥＣＵ２０ごとに持つテーブルである。

「検証用参照値」は、セキュアブートによるファームウェアの検証に用いる値であり、ＥＣＵ２０との間で事前に共有した値である。セキュアブートによるファームウェアの検証にＭＡＣ（Message Authentication Code）を用いる場合、ＥＣＵ２０との間で事前に共有したＭＡＣ値が検証用参照値となる。セキュアブートによるファームウェアの検証にハッシュを用いる場合、ＥＣＵ２０との間で事前に共有したハッシュ値が検証用参照値となる。ＥＣＵ２０がセキュアブートによるファームウェアの検証を行う場合、ファームウェアから算出される検証値（ＭＡＣ値あるいはハッシュ値）が、ＧＷ１０との間で事前に共有した検証用参照値と一致する場合に検証成功となり、一致しない場合は検証失敗となる。

「セキュリティレベル」は、ＥＣＵ２０に要求されるセキュリティレベルである。セキュリティレベルは、機能により車両の安全運転に対する影響度を表す。例えば、ＩＳＯ２６２６２のＡＳＩＬ（Automotive Safety Integrity Level）で決定されたレベルがあり、エネルギ系のＥＣＵ２０のセキュリティレベルはボディ系のＥＣＵのセキュリティレベルよりも高い。

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

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

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

ログ保持部１７が保持するログの構成例を図５に示す。図５（ａ）はＣＡＮプロトコルの定義に従った通信エラーのログの構成例を示し、図５（ｂ）はＥＣＵ２０のセキュアブートに関する動作エラーのログの構成例を示している。

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

動作エラーのログは、例えば図５（ｂ）に示すように、「ＥＣＵ ＩＤ」、「ＦＷ ＩＤ」、「Ｖｅｒ．Ｎｏ」、「エラー情報」、および「時間情報」を項目として含む。「ＥＣＵ ＩＤ」は、エラーが発生したＥＣＵ２０の識別子である。「ＦＷ ＩＤ」は、そのＥＣＵ２０の現ファームウェアの識別子であり、「Ｖｅｒ．Ｎｏ」は、そのＥＣＵ２０の現ファームウェアのバージョン情報である。「エラー情報」は、エラーの種類（セキュアブートに関する動作エラーであれば“復旧”や“検証失敗”など）を示す情報である。なお、“復旧”はＥＣＵ２０において検証に失敗したファームウェアが復旧したことを示し、厳密には動作エラーではないが、本実施形態では、復旧制御部１２がＥＣＵ２０のファームウェアを復旧させた場合に、ログ記録部１３がその情報を動作エラーのログとして記録するようにしている。「時間情報」は、エラーの発生時間を示す情報である。

＜ＥＣＵの機能構成＞
図６は、ＥＣＵ２０の機能的な構成例を示すブロック図である。ＥＣＵ２０は、ファームウェアの検証に関わる機能的な構成要素として、図６に示すように、通信部２１と、保持部２２と、検証部２３と、を備える。これら図６に示すＥＣＵ２０の機能的な構成要素は、一例として、図２に示したＧＷ１０と同様のハードウェアとソフトウェア（プログラム）との協働により実現することができる。

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

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

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

＜セキュアブートの処理手順＞
図７は、ＥＣＵ２０の検証部２３により実行されるセキュアブートの処理手順の一例を示すフローチャートである。この図７に示す一連の処理は、例えば、ＥＣＵ２０が通電されたときに開始される。

図７に示す処理が開始されると、まず検証部２３が、保持部２２からファームウェアを読み出す（ステップＳ１０１）。そして、検証部２３は、ステップＳ１０１で読み出したファームウェアの検証値を算出する（ステップＳ１０２）。

次に、検証部２３は、ステップＳ１０２で算出した検証値を事前に保持した検証用参照値と比較して、検証値が検証用参照値と一致するか否かを判定する（ステップＳ１０３）。ここで、検証値が検証用参照値と一致する場合（ステップＳ１０３：Ｙｅｓ）、ファームウェアのプログラムが実行され（ステップＳ１０４）、ＥＣＵ２０が正常にブートすることでセキュアブートの処理が終了する。

一方、検証値が検証用参照値と一致しない場合（ステップＳ１０３：Ｎｏ）、通信部２１からＧＷ１０に対して検証失敗を示す検証結果データが送信される（ステップＳ１０５）。この検証結果データには、例えば、ＥＣＵ２０の識別子（ＥＣＵ ＩＤ）や、ステップＳ１０２で算出したファームウェアの検証値などが含まれる。また、検証に失敗したファームウェアの識別子（ＦＷ ＩＤ）およびバージョン情報（Ｖｅｒ．Ｎｏ）が検証結果データに含まれていてもよい。なお、ステップＳ１０２の検証値の算出において、本実施形態ではファームウェアのプログラムに限定しているが、必要によりプログラムを含めるデータ全体の検証も可能である。

その後、通信部２１が、ＧＷ１０から送信された現ファームウェアを受信する（ステップＳ１０６）。ＧＷ１０から受信した現ファームウェアは、保持部２２に格納される。なお、以上はＥＣＵ２０が通電されたときに開始されるセキュアブートの処理手順を示しているが、通信部２１がＧＷ１０からファームウェアの検証要求を受信した場合も、同様の手順によりファームウェアの検証が行われる。ただし、ＧＷ１０からの検証要求に応じてファームウェアの検証を行う場合は、ステップＳ１０２で算出した検証値が事前に保持した検証用参照値と一致しない場合（ステップＳ１０３：Ｎｏ）だけでなく、検証値が検証用参照値と一致する場合（ステップＳ１０３：Ｙｅｓ）にも、通信部２１からＧＷ１０に対して検証結果データ（この場合は検証成功を示す検証結果データ）が送信される。

＜ファームウェア復旧処理の処理手順＞
図８は、主にＧＷ１０の復旧制御部１２により実施されるファームウェア復旧処理の処理手順の一例を示すフローチャートである。この図８に示す一連の処理は、ＧＷ１０の通信部１１が、ネットワーク上のあるＥＣＵ２０からファームウェアの検証失敗を示す検証結果データを受信したときに開始される。

図８に示す処理が開始されると、まず、復旧制御部１２が、受信部１１により受信された検証結果データに含まれるＥＣＵ ＩＤをキーとしてテーブル保持部１６が保持するＥＣＵ管理テーブルを検索し、検証結果データの送信元のＥＣＵ２０に対応する検証用参照値を取得する（ステップＳ２０１）。

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

一方、検証結果データに含まれる検証値がステップＳ２０１で取得した検証用参照値と一致しない場合は（ステップＳ２０２：Ｎｏ）、復旧制御部１２は、次に、ファームウェアの検証を要求する対象となるＥＣＵ２０を決定し（ステップＳ２０４）、ステップＳ２０４で決定したＥＣＵ２０に対して、通信部１１からファームウェアの検証要求を送信するように制御する（ステップＳ２０５）。ファームウェアの検証を要求する対象となるＥＣＵ２０は、上述したように、セキュアブートによる検証機能を持ったすべてのＥＣＵ２０（ファームウェアの検証に失敗したＥＣＵ２０と同じセキュリティ機能を有するＥＣＵ２０）であってもよいし、ファームウェアの検証に失敗したＥＣＵ２０と同等以上のセキュリティレベルが要求されているＥＣＵ２０であってもよい。復旧制御部１２は、例えばテーブル保持部１６が保持するＥＣＵ管理テーブルを参照することで、ファームウェアの検証を要求する対象となるＥＣＵ２０を決定することができる。

その後、復旧制御部１２は、通信部１１が検証要求を送信したすべてのＥＣＵ２０から検証成功を示す検証結果データを受信したか否かを判定する（ステップＳ２０６）。ここで、いずれかのＥＣＵ２０から検証失敗を示す検証結果データを受信した場合や検証結果データを受信できないＥＣＵ２０がある場合（ステップＳ２０６：Ｎｏ）、復旧制御部１２は、ファームウェアの復旧不可を示すアラートが出力されるように制御する（ステップＳ２０７）。アラートの一例としては、車両のメーターパネルにアラートマークを示すことなどが挙げられる。また、この場合、ログ記録部１３が、ステップＳ２１１において、ファームウェアの検証失敗を示す動作エラーのログを記録し、ファームウェア復旧処理を終了する。このログは、例えば図５（ｂ）に例示した動作エラーのログとして、ログ保持部１７に保持される。

一方、検証要求を送信したすべてのＥＣＵ２０から検証成功を示す検証結果データを受信した場合は（ステップＳ２０６：Ｙｅｓ）、復旧制御部１２は、次に、ログ保持部１７が保持するログを分析して、車載ネットワークシステムにセキュリティ上の問題が発生した兆候を示すログが記録されているか否かを判定する（ステップＳ２０８）。ここで、車載ネットワークシステムにセキュリティ上の問題が発生した兆候を示すログが記録されていると判定した場合（ステップＳ２０８：Ｙｅｓ）、復旧制御部１２は、ステップＳ２０７において、ファームウェアの復旧不可を示すアラートが出力されるように制御する。また、ログ記録部１３が、ステップＳ２１１において、ファームウェアの検証失敗を示す動作エラーのログを記録し、ファームウェア復旧処理を終了する。

一方、車載ネットワークシステムにセキュリティ上の問題が発生した兆候を示すログが記録されていないと判定した場合は（ステップＳ２０８：Ｎｏ）、復旧制御部１２は、次に、ログ保持部１７が保持するログを分析して、ファームウェアの検証に失敗したＥＣＵ２０において、過去にファームウェアの復旧が行われたことを示すログの記録回数が所定回数を超えるか否かを判定する（ステップＳ２０９）。ここで、過去にファームウェアの復旧が行われたことを示すログの記録回数が所定回数を超える場合（ステップＳ２０９：Ｙｅｓ）、復旧制御部１２は、ステップＳ２０７において、ファームウェアの復旧不可を示すアラートが出力されるように制御する。また、ログ記録部１３が、ステップＳ２１１において、ファームウェアの検証失敗を示す動作エラーのログを記録し、ファームウェア復旧処理を終了する。

一方、ファームウェアの検証に失敗したＥＣＵ２０において、過去にファームウェアの復旧が行われたことを示すログの記録回数が所定回数以下である場合は（ステップＳ２０９：Ｎｏ）、復旧制御部１２は、ファームウェアの検証に失敗したＥＣＵ２０においてファームウェアを復旧させる条件である復旧条件を満たすと判断し、このＥＣＵ２０に対して、ソフトウェア保持部１５が保持する現ファームウェアを通信部１１から送信するように制御する（ステップＳ２１０）。例えば、復旧制御部１２は、このＥＣＵ２０から受信した検証結果データに含まれるＥＣＵ ＩＤをキーとしてテーブル保持部１６が保持するＥＣＵ管理テーブルを検索し、このＥＣＵ２０に対応するＦＷ ＩＤを取得する。そして、取得したＦＷ ＩＤで識別される現ファームウェアをソフトウェア保持部１５から読み出して、通信部１１からＥＣＵ２０に対して送信する。なお、ＥＣＵ２０で検証に失敗したファームウェアのＦＷ ＩＤやＶｅｒ．Ｎｏが検証結果データに含まれている場合は、これらの情報をもとにＥＣＵ２０に送信する現ファームウェアを特定することもできる。

ファームウェアの検証に失敗したＥＣＵ２０に対し、復旧制御部１２の制御によりソフトウェア保持部１５が保持する現ファームウェアが送信された場合は、ログ記録部１３が、ステップＳ２１１において、ＥＣＵ２０のファームウェアが復旧されたことを示すログを記録して、ファームウェア復旧処理を終了する。このログは、例えば図５（ｂ）に例示した動作エラーのログとして、ログ保持部１７に保持される。

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

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

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

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

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

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

＜第３変形例＞
上述の実施形態では、ＧＷ１０が、上記の条件２および条件３の判定のために、ログ保持部１７が保持するログを分析しているが、ＯＥＭサーバなどの外部サーバが保持するログも併せて分析することで、例えば同一車種の他の車両などにおいて、同様のセキュリティ上の問題が発生していないかなどを確認することも可能となる。

図９は、本変形例における車載ネットワークシステムの概略構成を示す図である。図９に示す車載ネットワークシステムの構成は、基本的には図１に示した構成と同様であるが、バスＢ２に接続されたＥＣＵ２０ｃが図示しないデジタル通信モジュール（ＤＣＭ：Digital Communication Module）に接続され、移動体通信網を含む車外のネットワークＮを介して、ＯＥＭサーバなどの車外のサーバ装置３０と通信可能な構成となっている。

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

サーバ装置３０が保持するログの構成例を図１０に示す。この図１０に例示するログは、ＥＣＵ２０のセキュアブートに関する動作エラーのログであり、図５（ｂ）に示したＧＷ１０が保持する動作エラーのログに対し、車両の識別子である車両ＩＤの項目が追加されている。

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

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

１０ ＧＷ
１１ 通信部
１２ 復旧制御部
１３ ログ記録部
１４ 保持部
１５ ソフトウェア保持部
１６ テーブル保持部
１７ ログ保持部
２０ ＥＣＵ
２１ 通信部
２２ 保持部
２３ 検証部

Claims (13)

1. ネットワークを監視するネットワーク監視装置であって、
   前記ネットワークに接続された第１の電子機器に適用しているソフトウェアを保持するソフトウェア保持部と、
   ソフトウェアの検証失敗を示す検証結果データを前記第１の電子機器から受信したことに応じて、前記第１の電子機器においてソフトウェアを復旧させる条件として予め定めた復旧条件を満たすか否かを判定し、前記復旧条件を満たすと判定した場合に、前記ソフトウェア保持部が保持するソフトウェアを前記第１の電子機器に送信するように制御する制御部と、
   を備えるネットワーク監視装置。
2. 前記制御部は、ソフトウェアの検証失敗を示す検証結果データを前記第１の電子機器から受信した場合に、前記ネットワークに接続された第２の電子機器に対して、該第２の電子機器に適用しているソフトウェアの検証を要求し、
   前記復旧条件は、前記第２の電子機器からソフトウェアの検証成功を示す検証結果データを受信するという条件を含む、
   請求項１に記載のネットワーク監視装置。
3. 前記第２の電子機器は、要求されるセキュリティレベルが前記第１の電子機器以上の電子機器である、
   請求項２に記載のネットワーク監視装置。
4. 前記第２の電子機器は、前記第１の電子機器と同じドメインに属する電子機器である、
   請求項２または３に記載のネットワーク監視装置。
5. 前記ネットワーク上に流れるデータおよび前記ネットワークに接続された電子機器の動作に関する情報をログとして記録するログ記録部と、
   前記ログを保持するログ保持部と、をさらに備え、
   前記制御部は、前記ログ保持部が保持するログを分析して、前記復旧条件を満たすか否かを判定する、
   請求項１乃至４のいずれか一項に記載のネットワーク監視装置。
6. 前記復旧条件は、セキュリティ上の問題が発生した兆候を示すログが記録されていないという条件を含む、
   請求項５に記載のネットワーク監視装置。
7. 前記復旧条件は、前記第１の電子機器においてソフトウェアの復旧が行われたことを示すログの記録回数が所定回数以下であるという条件を含む、
   請求項５または６に記載のネットワーク監視装置。
8. 前記第１の電子機器の識別子と、前記第１の電子機器に適用しているソフトウェアの識別子との対応関係を示すテーブルを保持するテーブル保持部をさらに備え、
   前記検証結果データは、前記第１の電子機器の識別子を含み、
   前記制御部は、前記検証結果データに含まれる前記第１の電子機器の識別子と、前記テーブルとに基づいて、前記第１の電子機器に送信すべきソフトウェアを特定する、
   請求項１乃至７のいずれか一項に記載のネットワーク監視装置。
9. 前記テーブルは、前記第１の電子機器がソフトウェアの検証に用いる検証用参照値を示す項目をさらに含み、
   前記検証結果データは、前記第１の電子機器がソフトウェアの検証時に算出した検証値をさらに含み、
   前記制御部は、前記検証結果データに含まれる前記検証値と前記テーブルが示す前記検証用参照値とが異なり、かつ、前記復旧条件を満たすと判定した場合に、前記ソフトウェア保持部が保持するソフトウェアを前記第１の電子機器に送信するように制御する、請求項８に記載のネットワーク監視装置。
10. 前記制御部は、前記検証結果データに含まれる前記検証値と前記テーブルが示す前記検証用参照値とが一致する場合に、前記テーブルが示す前記検証用参照値を前記第１の電子機器に送信するように制御する、
    請求項９に記載のネットワーク監視装置。
11. 前記テーブルは、前記第１の電子機器に適用しているソフトウェアのバージョン情報を示す項目と、前記第１の電子機器に要求されるセキュリティレベルを示す項目と、前記第１の電子機器が有するセキュリティ機能の種類を示す項目と、前記第１の電子機器が属するドメインを示す項目と、の少なくともいずれかをさらに含む、
    請求項８乃至１０のいずれか一項に記載のネットワーク監視装置。
12. ネットワークに接続された第１の電子機器と、前記ネットワークを監視するネットワーク監視装置と、を含むネットワークシステムであって、
    前記第１の電子機器は、
    ソフトウェアの検証を行う検証部と、
    ソフトウェアの検証に失敗した場合に検証失敗を示す検証結果データを前記ネットワーク監視装置に送信し、前記ネットワーク監視装置からソフトウェアを受信する通信部と、を備え、
    前記ネットワーク監視装置は、
    前記第１の電子機器に適用しているソフトウェアを保持するソフトウェア保持部と、
    ソフトウェアの検証失敗を示す検証結果データを前記第１の電子機器から受信したことに応じて、前記第１の電子機器においてソフトウェアを復旧させる条件として予め定めた復旧条件を満たすか否かを判定し、前記復旧条件を満たすと判定した場合に、前記ソフトウェア保持部が保持するソフトウェアを前記第１の電子機器に送信するように制御する制御部と、を備える
    ネットワークシステム。
13. ネットワークを監視するコンピュータが実行するプログラムであって、
    前記コンピュータは、前記ネットワークに接続された第１の電子機器に適用しているソフトウェアを保持し、
    前記コンピュータに、
    ソフトウェアの検証失敗を示す検証結果データを前記第１の電子機器から受信したことに応じて、前記第１の電子機器においてソフトウェアを復旧させる条件として予め定めた復旧条件を満たすか否かを判定し、前記復旧条件を満たすと判定した場合に、前記ソフトウェア保持部が保持するソフトウェアを前記第１の電子機器に送信するように制御する機能を実現させるためのプログラム。

Images