(57)【要約】【課題】ソフトウェアが正しく更新されたことを保証できる更新制御装置、ソフトウェア更新システムおよび更新制御方法を提供する。【解決手段】実施形態の更新制御装置は、ネットワークに接続された端末のソフトウェアの更新を制御する更新制御装置であって、第１通信部と、第２通信部と、制御部と、検証部と、を備える。第１通信部は、ネットワークの外部のサーバと通信する。第２通信部は、ネットワークを介して端末と通信する。制御部は、第１通信部を用いて、ソフトウェアを更新するための更新用データをサーバから受信し、第２通信部を用いて、更新用データを端末に送信するとともに、ソフトウェアの更新に成功したか否かを示す更新結果を検証用データとともに端末から受信する。検証部は、検証用データを用いて更新結果が正当なデータであるか否かを検証する。【選択図】図２
2019036251.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに接続された端末のソフトウェアの更新を制御する更新制御装置であって、
前記ネットワークの外部のサーバと通信する第１通信部と、
前記ネットワークを介して前記端末と通信する第２通信部と、
前記第１通信部を用いて、前記ソフトウェアを更新するための更新用データを前記サーバから受信し、前記第２通信部を用いて、前記更新用データを前記端末に送信するとともに、前記ソフトウェアの更新に成功したか否かを示す更新結果を検証用データとともに前記端末から受信する制御部と、
前記検証用データを用いて前記更新結果が正当なデータであるか否かを検証する検証部と、
を備える更新制御装置。
【請求項２】
前記制御部は、前記検証用データとして、前記端末が前記更新結果をもとに生成した第１データを前記端末から受信し、
前記検証部は、前記端末から受信した前記第１データ、または、前記端末から受信した前記第１データをもとに生成した第２データが、前記端末から受信した前記更新結果をもとに生成した第３データと一致するか否かにより、前記更新結果が正当なデータであるか否かを検証する
請求項１に記載の更新制御装置。
【請求項３】
前記制御部は、前記サーバから、更新後の前記ソフトウェアをもとに前記端末と共有された秘密鍵を用いて生成された第４データ、または、該第４データをもとに生成された第５データをさらに受信し、前記検証用データとして、前記端末が前記更新用データを用いて更新した前記ソフトウェアをもとに前記秘密鍵を用いて生成した第６データを前記端末から受信し、
前記検証部は、前記端末から受信した前記第６データが、前記サーバから受信した前記第４データと一致するか否か、または、前記端末から受信した前記第６データから生成した第７データが、前記サーバから受信した前記第５データと一致するか否かにより、前記更新結果が正当なデータであるか否かを検証する
請求項１に記載の更新制御装置。
【請求項４】
前記制御部は、前記サーバから、複数の前記端末ごとに生成された複数の第４データであって、各第４データが、複数の前記端末のうちのいずれかに対応する更新後の前記ソフトウェアをもとに該端末と共有された秘密鍵を用いて生成されたデータである複数の第４データを集約することで生成された第８データをさらに受信し、複数の前記端末ごとの前記検証用データとして、前記端末が前記更新用データを用いて更新した前記ソフトウェアをもとに前記秘密鍵を用いて生成した第６データを複数の前記端末の各々から受信し、
前記検証部は、複数の前記端末から受信した複数の前記第６データを集約することで生成した第９データが、前記サーバから受信した前記第８データと一致するか否かにより、複数の前記端末から受信した複数の前記更新結果が全て正当なデータであるか否かを検証する
請求項１に記載の更新制御装置。
【請求項５】
前記制御部は、前記サーバから、複数の前記第４データの各々に対応する複数の第１０データをさらに受信し、
前記検証部は、複数の前記端末から受信した複数の前記更新結果の少なくとも一部が正当なデータではないと判断した場合に、複数の前記端末から受信した複数の前記第６データと、前記サーバから受信した複数の前記第１０データとを用いて、複数の前記更新結果のうち、正当なデータでない前記更新結果を特定する
請求項４に記載の更新制御装置。
【請求項６】
前記制御部は、前記更新結果が正当なデータでないと判断された場合に、前記第２通信部を用いて前記更新用データを前記端末に再度送信する、または、前記第２通信部を用いて更新前の前記ソフトウェアを復元するための復元用データを前記端末に送信する
請求項１乃至５のいずれか一項に記載の更新制御装置。
【請求項７】
前記ネットワークは自動車に搭載された車載ネットワークであり、
前記制御部は、前記ソフトウェアの更新に成功したか否かに応じて、前記自動車の状態を制御する
請求項１乃至６のいずれか一項に記載の更新制御装置。
【請求項８】
ネットワークに接続された端末と、
前記端末のソフトウェアの更新を制御する更新制御装置と、を備え、
前記更新制御装置は、
前記ネットワークの外部のサーバと通信する第１通信部と、
前記ネットワークを介して前記端末と通信する第２通信部と、
前記第１通信部を用いて、前記ソフトウェアを更新するための更新用データを前記サーバから受信し、前記第２通信部を用いて、前記更新用データを前記端末に送信するとともに、前記ソフトウェアの更新に成功したか否かを示す更新結果を検証用データとともに前記端末から受信する制御部と、
前記検証用データを用いて前記更新結果が正当なデータであるか否かを検証する検証部と、
を備えるソフトウェア更新システム。
【請求項９】
ネットワークに接続された端末のソフトウェアの更新を制御する更新制御装置において実行される更新制御方法であって、
前記ネットワークの外部のサーバと通信する第１通信部を用いて、前記ソフトウェアを更新するための更新用データを前記サーバから受信し、
前記ネットワークを介して前記端末と通信する第２通信部を用いて、前記更新用データを前記端末に送信するとともに、前記ソフトウェアの更新に成功したか否かを示す更新結果を検証用データとともに前記端末から受信し、
前記検証用データを用いて前記更新結果が正当なデータであるか否かを検証する
更新制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、更新制御装置、ソフトウェア更新システムおよび更新制御方法に関する。
【背景技術】
【０００２】
例えば、自動車に搭載される車載ネットワークでは、ＣＡＮ（Controller  Area  Network）やＦｌｅｘＲａｙ（登録商標）といった規格のネットワークバスを介して、数多くのＥＣＵ（Electronic  Control  Unit）などの端末が接続されている。これらＥＣＵなどの端末は、端末内部にファームウェアを保持しており、ファームウェアに記載された処理を実行することで動作する。端末の機能を拡張したり、新たに発見された脆弱性への対策を施したりするために、端末に記憶されたファームウェアの更新が行われる。ここで、車載ネットワークのように、セキュリティ対策が必ずしも万全ではないネットワーク上で端末のファームウェアなどのソフトウェアを更新する場合、ソフトウェアが正しく更新されたことを保証できるようにすることが望まれる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１７−５９２１０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明が解決しようとする課題は、ソフトウェアが正しく更新されたことを保証できる更新制御装置、ソフトウェア更新システムおよび更新制御方法を提供することである。
【課題を解決するための手段】
【０００５】
実施形態の更新制御装置は、ネットワークに接続された端末のソフトウェアの更新を制御する更新制御装置であって、第１通信部と、第２通信部と、制御部と、検証部と、を備える。第１通信部は、前記ネットワークの外部のサーバと通信する。第２通信部は、前記ネットワークを介して前記端末と通信する。制御部は、前記第１通信部を用いて、前記ソフトウェアを更新するための更新用データを前記サーバから受信し、前記第２通信部を用いて、前記更新用データを前記端末に送信するとともに、前記ソフトウェアの更新に成功したか否かを示す更新結果を検証用データとともに前記端末から受信する。検証部は、前記検証用データを用いて前記更新結果が正当なデータであるか否かを検証する。
【図面の簡単な説明】
【０００６】
【図１】実施形態のソフトウェア更新システムの概略構成を示すブロック図。
【図２】更新制御装置の機能的な構成例を示すブロック図。
【図３】第１実施形態における動作の概要を示すシーケンス図。
【図４】更新制御装置の処理手順の一例を示すフローチャート。
【図５】第２実施形態における動作の概要を示すシーケンス図。
【図６】第３実施形態における動作の概要を示すシーケンス図。
【図７】更新制御装置のハードウェア構成例を示すブロック図。
【発明を実施するための形態】
【０００７】
以下、実施形態の更新制御装置、ソフトウェア更新システムおよび更新制御方法について、図面を参照して詳細に説明する。実施形態のソフトウェア更新システムは、例えば、自動車に搭載された車載ネットワークシステムにおいて、端末として車載ネットワークに接続されたＥＣＵのファームウェア（「ソフトウェア」の一例）を更新する用途で有効に適用することができる。この場合、例えば、車載ネットワークに接続された車載ゲートウェイ装置に、実施形態の更新制御装置としての機能を持たせることができる。以下では、このような車載ネットワークシステムへの適用例を想定して説明するが、適用可能なシステムはこれに限らない。
【０００８】
＜第１実施形態＞
図１は、本実施形態のソフトウェア更新システムの概略構成を示すブロック図である。本実施形態のソフトウェア更新システムは、例えば図１に示すように、インターネットなどの外部ネットワーク１１０を介して配信サーバ１２０と通信可能な車載ネットワークシステム１００として構成される。
【０００９】
車載ネットワークシステム１００は、更新制御装置１０と複数の端末２０とが、ネットワークバス３０を介して接続された構成である。更新制御装置１０は、ネットワークバス３０を介して各端末２０と通信する機能を持つほか、例えば、３ＧＰＰ（3rd  Generation  Partnership  Project；登録商標）やＬＴＥ（Long  Term  Evolution；登録商標）などの移動体通信網や、Ｗｉ−Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）などの無線を用いて、インターネットなどの外部ネットワーク１１０に接続し、外部ネットワーク１１０を介して配信サーバ１２０と通信する機能を持つ。なお、外部ネットワーク１１０に接続する機能は必ずしも更新制御装置１０の内部に持つ必要はなく、更新制御装置１０とは別の外部通信装置を利用して外部ネットワーク１１０に接続する構成であってもよい。
【００１０】
配信サーバ１２０は、車載ネットワークシステム１００の端末２０が記憶するファームウェアを更新するための更新用データを提供するサーバである。更新制御装置１０は、外部ネットワーク１１０を介して配信サーバ１２０から更新用データを受信し、受信した更新用データを、ネットワークバス３０を介して、ファームウェア更新の対象となる端末２０に送信する。ここで、車載ネットワークシステム１００の更新制御装置１０と配信サーバ１２０との間で外部ネットワーク１１０を介して行われる通信は、例えば、暗号化やデジタル署名あるいはメッセージ認証などの技術により、適切に保護されているものとする。
【００１１】
端末２０は、更新制御装置１０からネットワークバス３０を介して受信した更新用データを用いて、内部に記憶するファームウェアを更新する処理を行う。そして、端末２０は、ファームウェアの更新に成功したか否かを示す更新結果を検証用データとともに、ネットワークバス３０を介して更新制御装置１０に送信する。検証用データは、更新制御装置１０において、端末２０から受信した更新結果が正当なデータであるか否かを検証するために用いられる。検証用データの具体例については詳細を後述する。
【００１２】
図２は、更新制御装置１０の機能的な構成例を示すブロック図である。更新制御装置１０は、機能的な構成要素として、例えば図２に示すように、車外通信部１１（第１通信部）と、車内通信部１２（第２通信部）と、制御部１３と、検証部１４とを備える。
【００１３】
車外通信部１１は、外部ネットワーク１１０を介して配信サーバ１２０と通信する機能である。車内通信部１２は、車載ネットワークシステム１００のネットワークバス３０を介して、ネットワークバス３０に接続された端末２０と通信する機能である。
【００１４】
制御部１３は、車外通信部１１を用いて、配信サーバ１２０から更新用データを受信する。また、制御部１３は、車内通信部１２を用いて、配信サーバ１２０から受信した更新用データを端末２０に送信し、端末２０から上述の更新結果を検証用データとともに受信する。制御部１３が端末２０から受信した更新結果と検証用データは、検証部１４に渡される。
【００１５】
検証部１４は、制御部１３から受け取った検証用データを用いて、この検証用データとともに端末２０から受信した更新結果が正当なデータであるか否かを検証する。検証用データとしては、例えば、端末２０が更新制御装置１０との間で共有する秘密鍵（共有鍵）を用いて更新結果をもとに生成したメッセージ認証子（ＭＡＣ：Message  Authentication  Code）や、端末２０が秘密鍵を用いて更新結果をもとに生成し、更新制御装置１０が端末２０の公開鍵を用いて検証可能なデジタル署名などを用いることができる。
【００１６】
検証用データとしてメッセージ認証子を用いる場合、端末２０は、更新結果と予め記憶した秘密鍵（共有鍵）をＭＡＣアルゴリズムに入力し、メッセージ認証子（「第１データ」の一例）を生成する。そして、端末２０は、更新結果にメッセージ認証子を付加して更新制御装置１０に送信する。更新制御装置１０の検証部１４は、端末２０から受信した更新結果と予め記憶した秘密鍵（共有鍵）をＭＡＣアルゴリズムに入力し、メッセージ認証子（「第３データ」の一例）を生成する。そして、検証部１４は、端末２０から受信したメッセージ認証子（「第１データ」の一例）が、自身が生成したメッセージ認証子（「第３データ」の一例）と一致するか否かにより、端末２０から受信した更新結果が正当なデータであるか否かを検証する。
【００１７】
検証用データとしてデジタル署名を用いる場合、端末２０は、更新結果を所定のハッシュ関数に入力してハッシュ値を生成し、このハッシュ値と秘密鍵とを用いてデジタル署名（「第１データ」の一例）を生成する。そして、端末２０は、更新結果にデジタル署名を付加して更新制御装置１０に送信する。更新制御装置１０の検証部１４は、端末２０から受信した更新結果を端末２０と共通の所定のハッシュ関数に入力してハッシュ値（「第２データ」の一例）を生成するとともに、端末２０から受信したデジタル署名と端末２０の秘密鍵に対応する公開鍵とを用いてハッシュ値（「第３データ」の一例）を生成する。そして、検証部１４は、更新結果から生成したハッシュ値（「第２データ」の一例）が、デジタル署名から生成したハッシュ値（「第３データ」の一例）と一致するか否かにより、端末２０から受信した更新結果が正当なデータであるか否かを検証する。
【００１８】
検証部１４が更新結果の検証を行った結果は、制御部１３に渡される。制御部１３は、検証部１４から更新結果が正当なデータでないことを示す検証結果を受け取った場合、すなわち、端末２０から送信された更新結果が正当なデータではないと検証部１４により判断された場合、当該端末２０のファームウェア更新を再実行したり、当該端末２０あるいは複数の端末２０のファームウェアの復元を実行したりしてもよい。ファームウェア更新を再実行する場合、制御部１３は、車内通信部１２を用いて、配信サーバ１２０から受信した更新用データを端末２０に再度送信する。ファームウェアの復元を実行する場合、制御部１３は、車内通信部１２を用いて、更新前のファームウェアを復元するための復元用データを端末２０に送信する。
【００１９】
また、制御部１３は、端末２０のファームウェアの更新や復元の成否に応じて、車載ネットワークシステム１００が搭載された自動車の状態を制御するようにしてもよい。例えば、制御部１３は、端末２０のファームウェア更新を実行する際に、まず自動車の状態を「ファームウェア更新モード」に変更し、端末２０のファームウェアの更新や復元に成功した場合は自動車の状態を「走行可能モード」に復帰させ、端末２０のファームウェアの更新や復元に失敗した場合は自動車の状態を「異常モード」に変更するといった制御を行うようにしてもよい。
【００２０】
次に、本実施形態のソフトウェア更新システムの動作を、図３を参照して説明する。図３は、本実施形態の動作の概要を示すシーケンス図である。なお、図３では、車載ネットワークシステム１００内に含まれる多数の端末２０のうちの２つのみを図示し、他の端末２０の図示を省略している。
【００２１】
まず、車載ネットワークシステム１００内に含まれる各端末２０は、端末２０の識別子（ＩＤ）や端末２０が記憶するファームウェアのバージョンなどを含む端末情報を、更新制御装置１０に送信する（ステップＳ１０１）。なお、配信サーバ１２０あるいは更新制御装置１０が、車載ネットワークシステム１００内に含まれる端末２０の端末情報を記憶している場合には、この処理は省略されてもよい。
【００２２】
更新制御装置１０は、それぞれの端末２０から端末情報を受信したら、それらを配信サーバ１２０に送信して、ファームウェアを更新するための更新用データの有無を問い合わせる（ステップＳ１０２）。なお、配信サーバ１２０が、車載ネットワークシステム１００内に含まれる端末２０の端末情報を記憶している場合には、この処理は省略されてもよい。
【００２３】
配信サーバ１２０は、端末情報に基づき、更新用データの有無を確認する。そして、少なくともいずれかの端末２０に対応する更新用データがある場合には、その更新用データを更新制御装置１０に送信する（ステップＳ１０３）。ここで、更新用データとは、最新のファームウェアやそれを圧縮したデータ、あるいは、端末２０に記憶されているファームウェアと更新後に記憶されるファームウェアとの差分（パッチ）のデータなどである。また、更新用データは、更新後のファームウェアが正当なベンダーにより開発されたものであるか否かを検査するための、ファームウェア検証情報を含んでいてもよい。ファームウェア検証情報は、例えば、更新後のファームウェアのハッシュ値であったり、ベンダーと端末２０で予め共有している秘密鍵を用いて計算された更新後のファームウェアに対するメッセージ認証子であったり、ベンダーの秘密鍵を用いて計算された更新後のファームウェアに対するデジタル署名であったりしてもよい。
【００２４】
配信サーバ１２０は、更新用データとともに、更新対象となる端末２０のＩＤなどを更新制御装置１０に送信してもよい。あるいは、配信サーバ１２０は、複数の端末２０に対応する複数の更新用データが存在する場合には、これら複数の更新用データとともに、後述の更新制御情報を更新制御装置１０に送信してもよい。あるいは、配信サーバ１２０は、更新用データとともに、ファームウェア更新で異常が発生した場合に元のファームウェア（更新前のファームウェア）を復元するための復元用データを更新制御装置１０に送信してもよい。
【００２５】
更新制御装置１０は、配信サーバ１２０から更新用データを受け取ったら、更新用データを車載ネットワークシステム１００内の記憶領域に記憶する。ここで記憶領域は、更新制御装置１０の内部に搭載されていてもよいし、ネットワークバス３０を介して更新制御装置１０と接続された記憶装置に搭載されていてもよい。更新制御装置１０は、更新用データとともに、更新対象の端末２０のＩＤや更新制御情報、復元用データなどを配信サーバ１２０から受け取った場合には、更新用データとともに、それらの情報を記憶領域に記憶してもよい。
【００２６】
更新制御装置１０は、配信サーバ１２０から更新用データを受け取った後、車載ネットワークシステム１００を搭載する自動車の状態を「ファームウェア更新モード」に変更する。自動車は、「ファームウェア更新モード」の状態にあるときには、走行不能となるように制御されてもよいし、一部の機能を制限した上で走行可能となるように制御されてもよい。
【００２７】
更新制御装置１０は、配信サーバ１２０から更新制御情報を受信することなく、複数の更新用データを受信した場合には、これら更新用データが適用される複数の端末２０の依存関係に基づき、更新制御情報を生成する。更新制御情報は、連携して動作する端末２０同士のファームウェア更新が連動するように制御するための情報である。
【００２８】
ここで、更新制御情報とこれに応じた更新手順の一例について説明する。ファームウェア更新の対象となる複数の端末２０のうち、端末Ａと端末Ｃとが連携して動作する端末であると仮定する。このとき、端末Ａと端末Ｃのどちらか一方だけがファームウェアを更新すると、連携した動作が保証できなくなる虞がある。そのため、更新制御装置１０は、これら端末Ａと端末Ｃの両方でファームウェアを更新したことを確認する必要がある。端末Ａと端末Ｃの一方のファームウェア更新が確認できない場合には、他方の端末のファームウェアを復元して、ファームウェア更新を実行する前の状態に戻してもよい。
【００２９】
ここで、連携して動作する端末Ａと端末Ｃに加え、これらとは独立に動作する端末Ｆのファームウェアを更新する場面を考える。このとき、更新制御情報は、端末Ａと端末Ｃが組であることを示す情報を含む。例えば、更新制御情報は、［（ａ，ｃ），ｆ］とする。ここで、“（ａ，ｃ）”は、端末Ａと端末Ｃが組であり、それらのすべてのファームウェアを更新するか、あるいは、それらのすべてのファームウェアを更新しない（一部のみ更新したのであれば、更新したものを復元する）ことを表す。“，”は、その前後で更新の順番を問わないことを表す。あるいは、例えば、更新制御情報は、［（ａ，ｃ）→ｆ］とする。ここで、“→”は、その直前の更新処理が完了したら、その直後の更新処理を実行することを表す。
【００３０】
図３に戻り、更新制御装置１０は、ファームウェア更新の対象となる端末２０（最新のファームウェアが存在する端末２０）に対して、更新用データを送信してファームウェアの更新を指示する（ステップＳ１０４）。該当する端末２０が複数である場合には、更新制御情報に基づいて、端末２０に更新を指示する。
【００３１】
更新制御装置１０から更新用データを受信した各端末２０は、更新用データを用いて自身が記憶するファームウェアを更新する処理を行い、ファームウェアの更新に成功したか否かを示す更新結果を更新制御装置１０に送信する。このとき、各端末２０は、更新結果が正当なデータであるか否かを更新制御装置１０において検証するための検証用データを生成し、その検証用データを更新結果とともに更新制御装置１０に送信する（ステップＳ１０５）。なお、ファームウェアを更新する際には、各端末２０は、ファームウェア検証情報を利用して、新たに記憶する更新後のファームウェアが正当なものであるか否かを検査してもよい。
【００３２】
更新制御装置１０は、端末２０から更新結果と検証用データを受信したら、検証用データを用いて更新結果が正当なデータであるか否かを検証する。更新用データを送信したすべての端末２０に関して、更新結果が正当なデータであることが確認できたら、更新制御装置１０は次に、すべての端末２０でファームウェアが更新されたか否かを確認し、すべての端末２０でファームウェアが更新されていれば、配信サーバ１２０に、各端末２０のファームウェアを更新したことを示す全体更新結果を送信する（ステップＳ１０６）。そして、更新制御装置１０は、自動車の状態を「走行可能モード」へと変更する。
【００３３】
一方、正当ではない更新結果が存在する場合には、更新制御装置１０は、後述するように、当該端末２０のファームウェア更新を再実行したり、当該端末２０あるいは当該端末２０と連携動作する他の端末２０も含めた複数の端末２０のファームウェアの復元を実行したりしてもよい。その後、更新制御装置１０は、ファームウェアの更新や復元の成否に応じて、自動車の状態を「走行可能モード」や「異常モード」などに変更してもよい。「異常モード」とは、ファームウェアの更新に失敗し、自動車の所有者にディーラでの点検を受けるように促すモードである。「異常モード」においては、走行不能となるように制御されてもよいし、一部の機能を制限した上で走行可能となるように制御されてもよい。その上で、更新制御装置１０は、配信サーバ１２０に、一部あるいはすべての更新用データを適用できなかったことを示す全体更新結果を送信してもよい。
【００３４】
端末２０がファームウェアの更新に失敗した場合には、更新制御装置１０は端末２０のファームウェアの更新の再実行やファームウェアの復元を試みてもよい。更新用データのみでファームウェアを構築できる場合には、更新制御装置１０は、ファームウェアの更新に失敗した端末２０に更新用データを再送して更新の再実行を行ってもよい。あるいは、例えば、更新用データは以前のバージョンのファームウェアとの差分のみを含んでおり、更新用データのみではファームウェアを構築できない場合には、復元用データを利用して端末２０のファームウェアを復元し、その後で更新用データを端末２０に再送してもよい。あるいは、更新制御装置１０は、新しいファームウェアを構築可能な新たな更新用データを配信サーバ１２０に要求し、それを端末２０に転送してもよい。
【００３５】
復元用データは、過去のバージョンのファームウェアを構築可能とするデータであり、必要なときに更新制御装置１０が配信サーバ１２０に要求してもよいし、更新用データとともに配信サーバ１２０が更新制御装置１０に送信してもよいし、ファームウェア更新とは別のタイミングで配信サーバ１２０が更新制御装置１０に送信してもよい。復元用データは、それ単独で過去のバージョンのファームウェアを構築可能とするデータであってもよいし、新たなバージョンのファームウェアとの差分のみを含んでいて、新しいバージョンのファームウェアから古いバージョンのファームウェアにバージョンを戻すことはできるが、それ単体で古いバージョンのファームウェアは構築不可能なデータであってもよい。
【００３６】
次に、配信サーバ１２０から更新用データを受信した後に実施される更新制御装置１０の処理手順について、図４を参照して説明する。図４は、更新制御装置１０の処理手順の一例を示すフローチャートである。
【００３７】
更新制御装置１０は、配信サーバ１２０から更新用データを受信すると、まず、自動車の状態を「走行可能モード」から「ファームウェア更新モード」に変更する（ステップＳ２０１）。そして、更新制御装置１０は、配信サーバ１２０から受信した更新用データを、ファームウェア更新の対象となる端末２０に送信する（ステップＳ２０２）。その後、更新制御装置１０は、更新用データを送信した端末２０から更新結果と検証用データを受信し（ステップＳ２０３）、受信した検証用データを用いて、更新結果が正当なデータであるか否かを検証する（ステップＳ２０４）。ステップＳ２０２からステップＳ２０４までの処理は、ファームウェア更新の対象となる端末２０ごとに繰り返し行われる処理である。
【００３８】
そして、更新用データを送信したすべての端末２０について更新結果の検証が終わると、更新制御装置１０は、すべての更新結果が正当なデータであったか否かを確認し（ステップＳ２０５）、不正なデータと判断された更新結果があれば（ステップＳ２０５：Ｎｏ）、その更新結果の送信元として認識している端末２０を対象として検証失敗処理を行う（ステップＳ２０６）。ここで、検証失敗処理とは、例えば、ファームウェア更新の再実行、あるいはファームウェアの復元などである。ファームウェア更新を再実行する場合は、その端末２０から更新結果と検証用データとを再度受信し、検証用データを用いて更新結果の検証を行う処理も検証失敗処理に含まれる。
【００３９】
一方、すべての更新結果が正当なデータであったことが確認されると（ステップＳ２０５：Ｙｅｓ）、更新制御装置１０は、ファームウェアの更新に失敗した端末２０があるかどうかを確認する（ステップＳ２０７）。そして、ファームウェアの更新に失敗した端末２０がある場合（ステップＳ２０７：Ｙｅｓ）、更新制御装置１０は、自動車の状態を「異常モード」に変更し（ステップＳ２０８）、処理を終了する。一方、すべての端末２０でファームウェアが更新された場合は（ステップＳ２０７：Ｎｏ）、更新制御装置１０は、各端末２０のファームウェアを更新したことを示す全体更新結果を配信サーバ１２０に送信し（ステップＳ２０９）、自動車の状態を「走行可能モード」に復帰させて（ステップＳ２１０）、処理を終了する。
【００４０】
なお、ファームウェアの更新に失敗した端末２０がある場合に（ステップＳ２０７：Ｙｅｓ）、更新制御装置１０は、更新失敗処理を行うようにしてもよい。更新失敗処理とは、上述の検証失敗処理と同様に、例えば、ファームウェア更新の再実行、あるいはファームウェアの復元などである。そして、更新失敗処理を実行してもファームウェアを更新できない、あるいはファームウェアが復元されない場合に、更新制御装置１０は、自動車の状態を「異常モード」に変更し（ステップＳ２０８）、処理を終了するようにしてもよい。また、ファームウェアを更新できない端末２０がある場合、更新制御装置１０は、配信サーバ１２０に、一部あるいはすべての更新用データを適用できなかったことを示す全体更新結果を送信してもよい。
【００４１】
以上、具体的な例を挙げながら詳細に説明したように、本実施形態によれば、更新制御装置１０が、端末２０から受信した検証用データを用いて更新結果が正当なデータであるか否かを検証するので、ファームウェア（ソフトウェア）が正しく更新されたことを保証することができる。
【００４２】
すなわち、更新制御装置１０が端末２０から受信した更新結果が、改ざんやなりすましにより不正に送信されたものである場合には、実際には当該端末２０のファームウェアは更新されていないにもかかわらず、更新制御装置１０が当該端末２０のファームウェアが更新されたと誤認してしまう。このようなことが起こると、端末２０の機能更新や脆弱性対策が正しく行われなかったり、端末２０間の連携動作を実現することができなかったりする。これに対して本実施形態では、更新制御装置１０が、端末２０から更新結果とともに検証用データを受信し、検証用データを用いて更新結果が正当なデータであるか否かを検証するので、改ざんやなりすましにより不正に送信された更新結果に基づいてファームウェアが更新されたと誤認することを有効に防止することができ、ファームウェアが正しく更新されたことを保証することができる。
【００４３】
＜第２実施形態＞
上述の第１実施形態では、更新制御装置１０が端末２０から受信した更新結果が正当なデータであるか否かを確認することはできるが、端末２０のファームウェアが、ベンダーが開発したとおりの最新のファームウェアに確実に更新されたかどうかを、更新制御装置１０は必ずしも確認することはできない。それに加え、端末２０がデジタル署名を生成するだけの計算リソースをもたず、かつ、更新制御装置１０と端末２０が固有の秘密鍵を共有してメッセージ認証を行うことができない場合には、端末２０のファームウェアが最新のファームウェアに確実に更新されたことを、更新制御装置１０が確認することができない。
【００４４】
本実施形態では、更新制御装置１０における更新結果の検証にベンダーが関与することで、各端末２０のファームウェアがベンダーにより開発された最新のファームウェアに確実に更新されたことを、更新制御装置１０が確認できるようにする。以下では、第１実施形態と重複する説明は適宜省略し、第１実施形態と異なる部分についてのみ説明する。
【００４５】
配信サーバ１２０は、端末２０および該端末２０が記憶するファームウェアを開発するベンダーから、車載ネットワークシステム１００内の端末２０が記憶するファームウェアを最新のファームウェアに更新するための更新用データを取得して記憶している。本実施形態では、配信サーバ１２０が、更新用データとともに参照用データをベンダーから取得して記憶する。参照用データとは、ファームウェアを開発するベンダーと端末２０が予め共有する秘密鍵を利用して生成されるデータであり、例えば、その秘密鍵を用いて計算された最新のファームウェアのメッセージ認証子である。
【００４６】
本実施形態の配信サーバ１２０は、更新制御装置１０に対して更新用データを送信する際に、更新用データとともに参照用データ（「第４データ」の一例）を送信する。更新制御装置１０は、配信サーバ１２０から更新用データを受信する際に、参照用データをさらに受信する。そして、更新制御装置１０は、端末２０から更新結果と検証用データとを受信した際に、配信サーバ１２０から受信した参照用データと、端末２０から受信した検証用データとを用いて、端末２０から受信した更新結果が正当なデータであるか否かを検証する。
【００４７】
本実施形態において、更新制御装置１０が端末２０から受信する検証用データは、端末２０がベンダーと共有する秘密鍵を利用して生成するデータであり、例えば、端末２０がその秘密鍵を用いて計算した更新後のファームウェアのメッセージ認証子である。すなわち、端末２０は、更新制御装置１０から受信した更新用データを用いて自身が記憶するファームウェアを更新した後、ベンダーと共有する秘密鍵を用いて更新後のファームウェアをもとにメッセージ認証子（「第６データ」の一例）を生成し、これを検証用データとして更新結果に付加して更新制御装置１０に送信する。
【００４８】
更新制御装置１０の検証部１４は、端末２０から受信した更新後のファームウェアのメッセージ認証子（「第６データ」の一例）が、配信サーバ１２０から受信した参照用データ（「第４データ」の一例）と一致するか否かにより、端末２０から受信した更新結果が正当なデータであるか否かを検証する。
【００４９】
図５は、本実施形態の動作の概要を示すシーケンス図である。以下、図５を参照して、本実施形態のソフトウェア更新システムの動作を説明する。
【００５０】
端末情報の送信（ステップＳ３０１およびステップＳ３０２）に関しては、上述の第１実施形態と同様であるため、説明を省略する。
【００５１】
配信サーバ１２０は、端末情報に基づき、更新用データの有無を確認する。そして、少なくともいずれかの端末２０に対応する更新用データがある場合には、その更新用データを更新制御装置１０に送信する（ステップＳ３０３）。ここで本実施形態では、配信サーバ１２０が、更新用データとともに参照用データを更新制御装置１０に送信する。参照用データは、例えば、ベンダーと端末２０とが予め共有する秘密鍵を用いて計算された更新後のファームウェアのメッセージ認証子である。その他、配信サーバ１２０は、第１実施形態と同様に、更新用データとともに、更新対象となる端末２０のＩＤや更新制御情報、復元用データなどを更新制御装置１０に送信してもよい。
【００５２】
更新制御装置１０は、配信サーバ１２０から更新用データと参照用データを受け取ったら、これら更新用データと参照用データを車載ネットワークシステム１００内の記憶領域に記憶する。
【００５３】
更新制御装置１０は、配信サーバ１２０から更新用データを受け取った後、第１実施形態と同様に、車載ネットワークシステム１００を搭載する自動車の状態を「ファームウェア更新モード」に変更する。そして、必要であれば更新制御情報を生成し、更新制御情報に基づいて、各端末２０に更新用データを送信してファームウェアの更新を指示する（ステップＳ３０４）。ただし、更新制御装置１０は、端末２０に対して参照用データは送信しない。
【００５４】
更新制御装置１０から更新用データを受信した各端末２０は、更新用データを用いて自身が記憶するファームウェアを更新し、更新結果を更新制御装置１０に送信する。このとき、各端末２０は、例えば、予めベンダーと共有された秘密鍵を用いて更新後のファームウェアのメッセージ認証子を生成し、これを検証用データとして更新結果に付加して、更新制御装置１０に送信する（ステップＳ３０５）。
【００５５】
更新制御装置１０は、端末２０から更新結果と検証用データを受信したら、端末２０から受信した検証用データが配信サーバ１２０から受信した参照用データと一致するか否かにより、端末２０から受信した更新結果が正当なデータであるか否かを検証する。その後、更新制御装置１０は、正当なデータであることが確認された更新結果をもとに各端末２０におけるファームウェア更新の状態を把握し、それに応じて配信サーバ１２０に全体更新結果を送信したり（ステップＳ３０６）、自動車の状態を「走行可能モード」や「異常モード」に変更したりするが、これらは第１実施形態と同様であるため、詳細な説明を省略する。
【００５６】
以上説明したように、本実施形態では、ベンダーと端末２０との間で予め共有された秘密鍵を用いて生成された参照用データと、端末２０がベンダーと共有する秘密鍵を用いて生成した検証用データとが一致するか否かにより、更新結果が正当なデータであるか否かを検証する。したがって、各端末２０のファームウェアがベンダーにより開発された最新のファームウェアに確実に更新されたことを、更新制御装置１０が確認することができる。特に、第１実施形態において、端末２０がデジタル署名を生成するだけの計算リソースを持たず、かつ、更新制御装置１０と端末２０とが固有の秘密鍵を共有してメッセージ認証を行うことができない場合には、ベンダーが関与することで、端末２０のファームウェアが確実に最新のファームウェアに更新されたことを、更新制御装置１０が確認できるようになる。
【００５７】
（変形例）
上述の第２実施形態では、参照用データと検証用データとが同一の値を持つ。この場合には、更新制御装置１０が参照用データを保有するため、不正端末が更新制御装置１０あるいは記憶領域から参照用データを不正に読み出し、ファームウェアの更新対象となっている端末２０になりすまして不正に読み出した参照用データを更新制御装置１０に送信すると、これをファームウェアの更新対象となっている端末２０が送信する検証用データと区別することができず、更新結果を正当なデータと誤って判断してしまう可能性がある。
【００５８】
そこで、本変形例では、配信サーバ１２０が、上述の第２実施形態における参照用データの代わりに、参照用データをもとに生成される変形参照用データ（「第５データ」の一例）を更新制御装置１０に送信する。ここで、変形参照用データは、参照用データから計算される値であり、例えば、参照用データのハッシュ値や、参照用データの部分データなどである。
【００５９】
本変形例の場合、更新制御装置１０は、端末２０から更新後のファームウェアのメッセージ認証子などの検証データを受信すると、参照用データをもとに変形参照用データを生成する方法と同じ方法により、端末２０から受信した検証用データをもとに変形検証用データ（「第７データ」の一例）を生成する。そして、更新制御装置１０の検証部１４は、生成した変形検証用データが配信サーバ１２０から受信した変形参照用データと一致するか否かにより、端末２０から受信した更新結果が正当なデータであるか否かを検証する。これにより、更新制御装置１０は、端末２０から受信した更新結果が正当なデータであるか否かを正しく検証することができる。
【００６０】
さらに、更新制御装置１０は、端末２０から受信した検証用データをもとに生成した変形検証用データを全体更新結果に含めて配信サーバ１２０に送信してもよい。この場合、配信サーバ１２０あるいはベンダーは、更新制御装置１０から受信した変形検証用データが変形参照用データと一致することを確認することで、確かに端末２０がファームウェアを更新して検証用データを生成したことを確認できる。
【００６１】
＜第３実施形態＞
上述の第２実施形態とその変形例では、配信サーバ１２０は、更新用データとともに参照用データあるいは変形参照用データを更新制御装置１０に送信する。この構成の場合、自動車内の端末２０の数が増大し、同時に多数の端末２０のファームウェアを更新するような場面では、参照用データあるいは変形参照用データを送信し、記憶し、比較検証するコストが増大することが課題となる。
【００６２】
そこで、本実施形態では、配信サーバ１２０が、複数の端末２０ごとの参照用データあるいは変形参照用データの代わりに、複数の端末２０ごとの参照用データを集約することで生成された集約参照用データ（「第８データ」の一例）を更新制御装置１０に送信する。複数の端末２０ごとの参照用データは、例えば、それぞれが各端末２０とベンダーとの間で予め共有された秘密鍵を用いて計算された更新後のファームウェアのメッセージ認証子などである。集約参照用データは、例えば、これら各端末２０ごとの更新後のファームウェアのメッセージ認証子を連結したデータのハッシュ値である。
【００６３】
本実施形態の更新制御装置１０は、配信サーバ１２０から受信した集約参照用データを記憶領域に記憶する。そして、更新制御装置１０は、各端末２０がファームウェアを更新した後に生成する更新後のファームウェアのメッセージ認証子などの検証用データを各端末２０から受信すると、上述の集約参照用データを生成する方法と同じ方法により、これら各端末２０から受信した検証用データを集約することで集約検証用データ（「第９データ」の一例）を生成する。そして、更新制御装置１０の検証部１４は、生成した集約検証用データが配信サーバ１２０から受信した集約参照用データと一致するか否かにより、各端末２０から受信した更新結果が正当なデータであるか否かを検証する。このようにすることで、複数の端末２０に対応する参照用データの各々を送信、記憶、比較検証する必要がなくなる。
【００６４】
上述の集約検証用データと集約参照用データとの比較では、各端末２０から受信した更新結果のすべてが正当なデータであるか、あるいは少なくとも一部が不正なデータであるかを判断することはできるが、更新結果の一部が不正なデータであると判断した場合に、どの端末２０に対応する更新結果が不正なデータであるかを特定できない。そこで、配信サーバ１２０は、端末２０ごとに、各々の参照用データのダイジェスト（「第１０データ」の一例）を集約参照用データとともに更新制御装置１０に送信してもよい。参照用データのダイジェストは、例えば、参照用データのうちの特定の数ビット、あるいは参照用データのハッシュ値の特定の数ビットなどである。ダイジェストのデータサイズが小さければ、複数の端末２０に対応する参照用データの各々を送信、記憶、比較検証するよりは、処理や記憶のコストを抑えることができる。
【００６５】
この例の場合、更新制御装置１０は、配信サーバ１２０から受信した集約参照用データとダイジェストとを記憶領域に記憶する。そして、集約検証用データと集約参照用データとの比較によっていずれかの更新結果が不正なデータであると判断された場合に、各端末２０から受信した検証用データを対応するダイジェストと照らし合わせることで、どの端末２０に対応する更新結果が不正なデータであるかを特定することができる。
【００６６】
なお、集約参照用データの一例として、各端末２０ごとの更新後のファームウェアのメッセージ認証子を連結したデータのハッシュ値を例示したが、集約参照用データはこれに限らない。集約参照用データは、例えば、複数の端末２０に対応する更新後のファームウェアのそれぞれを平文ブロックに配置して、ＣＭＡＣ（Cipher  based  MAC、NIST  Special  Publication  800-38B）により計算されたメッセージ認証子としてもよい。この場合には、各暗号処理の演算結果（ＣＭＡＣでは出力されない値）のダイジェストを、上述のダイジェストとして用いてもよい。
【００６７】
あるいは、集約参照用データは、複数の端末２０に対応する更新後のファームウェアのメッセージ認証子それぞれの排他的論理和としてもよい。この場合には、各端末２０に対応するメッセージ認証子の一部のビットを、上述のダイジェストとしてもよい。Ｎ個の端末２０の参照用データから集約参照用データとダイジェストを計算する場合に、排他的論理和の性質により、更新制御装置１０は、集約参照用データと、Ｎ−１個の端末２０に対する同一のビット位置のダイジェストとから、残りの１個の端末２０に対する参照用データの当該ビットを計算できる。この性質を利用することで、いずれかの端末２０のファームウェア更新に誤りが生じた場合に、当該端末２０を効率よく検出することが可能となる。
【００６８】
図６は、本実施形態の動作の概要を示すシーケンス図である。以下、図６を参照して、本実施形態のソフトウェア更新システムの動作を説明する。
【００６９】
端末情報の送信（ステップＳ４０１およびステップＳ４０２）に関しては、上述の第１実施形態と同様であるため、説明を省略する。
【００７０】
配信サーバ１２０は、端末情報に基づき、更新用データの有無を確認する。そして、複数の端末２０に対応する更新用データがある場合に、それらの更新用データと、集約参照用データと、各参照用データのダイジェストを更新制御装置１０に送信する（ステップＳ４０３）。その他、配信サーバ１２０は、第１実施形態と同様に、更新用データとともに、更新対象となる端末２０のＩＤや更新制御情報、復元用データなどを更新制御装置１０に送信してもよい。
【００７１】
更新制御装置１０は、配信サーバ１２０から更新用データと集約参照用データとダイジェストを受け取ったら、これらを車載ネットワークシステム１００内の記憶領域に記憶する。
【００７２】
更新制御装置１０は、配信サーバ１２０から更新用データを受け取った後、第１実施形態と同様に、車載ネットワークシステム１００を搭載する自動車の状態を「ファームウェア更新モード」に変更する。そして、必要であれば更新制御情報を生成し、更新制御情報に基づいて、各端末２０に更新用データを送信してファームウェアの更新を指示する（ステップＳ４０４）。
【００７３】
更新制御装置１０から更新用データを受信した各端末２０は、更新用データを用いて自身が記憶するファームウェアを更新し、更新結果を更新制御装置１０に送信する。このとき、各端末２０は、例えば、予めベンダーと共有された秘密鍵を用いて更新後のファームウェアのメッセージ認証子を生成し、これを検証用データとして更新結果に付加して、更新制御装置１０に送信する（ステップＳ４０５）。
【００７４】
更新制御装置１０は、各端末２０から更新結果と検証用データを受信したら、各端末２０から受信した検証用データをもとに集約検証用データを生成し、生成した集約検証用データが配信サーバ１２０から受信した集約参照用データと一致するか否かにより、各端末２０から受信した更新結果の全てが正当なデータであるか否かを検証する。このとき、本実施形態では、更新結果の一部が不正なデータであると判断した場合に、各端末２０から受信した検証用データと配信サーバ１２０から受信したダイジェストとを用いて、どの端末２０に対応する更新結果が不正なデータであるかを特定することができる。
【００７５】
その後、更新制御装置１０は、正当なデータであることが確認された更新結果をもとに各端末２０におけるファームウェア更新の状態を把握し、それに応じて配信サーバ１２０に全体更新結果を送信したり（ステップＳ４０６）、自動車の状態を「走行可能モード」や「異常モード」に変更したりするが、これらは第１実施形態と同様であるため、詳細な説明を省略する。
【００７６】
以上説明したように、本実施形態では、配信サーバ１２０が、複数の端末２０ごとの参照用データあるいは変形参照用データの代わりに、集約参照用データを更新制御装置１０に送信する。そして、更新制御装置１０は、各端末２０から受信した検証用データをもとに集約検証用データを生成し、集約検証用データが集約参照用データと一致するか否かにより、各端末２０から受信した更新結果が正当なデータであるか否かを検証する。したがって、自動車内の端末２０の数が増大し、同時に多数の端末２０のファームウェアを更新するような場面においても、データを送信、記憶、比較検証するコストを抑えつつ、複数の端末２０が確実にファームウェアを更新したことを更新制御装置１０が確認できる。
【００７７】
なお、本実施形態においても、上述の第２実施形態の変形例と同様に、更新制御装置１０は、各端末２０から受信した検証用データをもとに生成した集約検証用データを全体更新結果に含めて配信サーバ１２０に送信してもよい。この場合には、配信サーバ１２０は、更新制御装置１０から受信した集約検証用データが集約参照用データと一致することを確認することで、確かに端末２０がファームウェアを更新して検証用データを生成したことを確認できる。
【００７８】
＜補足説明＞
上述した実施形態の更新制御装置１０は、例えば、一般的なコンピュータシステムのハードウェア構成を利用して実現することができる。図７は、上述した実施形態の更新制御装置１０のハードウェア構成例を示すブロック図である。更新制御装置１０は、例えば図７に示すように、ＣＰＵ（Central  Processing  Unit）やＧＰＵ（Graphics  Processing  Unit）などのプロセッサ（プロセッサ回路）１０１と、ＲＡＭ（Random  Access  Memory）やＲＯＭ（Read  Only  Memory）などの内部メモリ１０２と、ＨＤＤ（Hard  Disk  Drive）やＳＤＤ（Solid  State  Drive）などのストレージデバイス１０３と、外部ネットワーク１１０に接続するための物理インタフェースである通信Ｉ／Ｆ１０４と、車載ネットワークシステム１００のネットワークバス３０に接続するための物理インタフェースであるバスＩ／Ｆ１０５とを備える。
【００７９】
そして、例えばプロセッサ１０１が内部メモリ１０２を作業領域として利用しながら、ストレージデバイス１０３や内部メモリ１０２などに格納された所定の制御プログラムを実行することで、上述の制御部１３や検証部１４の機能を実現することができる。また、プロセッサ１０１が制御プログラムを実行して通信Ｉ／Ｆ１０４の動作を制御することで、上述の車外通信部１１の機能を実現することができ、プロセッサ１０１が制御プログラムを実行してバスＩ／Ｆ１０５の動作を制御することで、上述の車内通信部１２の機能を実現することができる。
【００８０】
更新制御装置１０の機能的な構成要素を実現するための制御プログラムは、例えば、磁気ディスク（フレキシブルディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ±Ｒ、ＤＶＤ±ＲＷ、Ｂｌｕ−ｒａｙ（登録商標）  Ｄｉｓｃなど）、半導体メモリ、またはこれに類する記録媒体に記録されて提供される。なお、制御プログラムを記録する記録媒体は、コンピュータが読み取り可能な記録媒体であれば、その記録形式は何れの形態であってもよい。また、上記制御プログラムを、更新制御装置１０のコンピュータシステムに予めインストールするように構成してもよいし、ネットワークを介して配布される上記の制御プログラムをコンピュータシステムに適宜インストールするように構成してもよい。
【００８１】
なお、上述した実施形態の更新制御装置１０は、機能的な構成要素の一部または全部を、ＡＳＩＣ（Application  Specific  Integrated  Circuit）やＦＰＧＡ（Field-Programmable  Gate  Array）などの専用のハードウェアにより実現する構成であってもよい。
【００８２】
また、上述した実施形態の更新制御装置１０は、必ずしも単体の装置として構成されている必要はなく、複数台の装置（コンピュータ）を連携させて実現する構成であってもよい。すなわち、上述した更新制御装置１０の機能的な構成要素を複数台の装置（コンピュータ）に分散して実現する構成であってもよい。また、上述した実施形態の更新制御装置１０は、クラウドシステム上で動作する仮想マシンであってもよい。
【００８３】
以上、本発明の実施形態を説明したが、この実施形態は例として提示したものであり、発明の範囲を限定することは意図していない。この新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【００８４】
１０  更新制御装置
１１  車外通信部
１２  車内通信部
１３  制御部
１４  検証部
２０  端末
１００  車載ネットワークシステム
１２０  配信サーバ
【図１】
2019036251.tif 000003
【図２】
2019036251.tif 000004
【図３】
2019036251.tif 000005
【図４】
2019036251.tif 000006
【図５】
2019036251.tif 000007
【図６】
2019036251.tif 000008
【図７】
2019036251.tif 000009