JP2023005717A - 車載通信システム，センタ装置，車両側システム及び車載通信の更新データ検証方法 - Google Patents

Abstract

【課題】センタ装置からストリーミング方式で送信される更新データについても、完全性を検証できる車載通信システムを提供する。【解決手段】車載通信システム１において、ＯＴＡセンタ２は、ストリーミング方式で更新データを車両側のＯＴＡマスタ２１に送信する際に、更新データについて計算したハッシュ値もＯＴＡマスタ２１に送信する。ＯＴＡマスタ２１は、更新データを受信するとターゲットＥＣＵ２２に転送する。ターゲットＥＣＵ２２は、更新データについてハッシュ値を計算すると、そのハッシュ値をＯＴＡマスタ２１に送信し、ＯＴＡマスタ２１は、ＯＴＡセンタ２より送信されたハッシュ値とターゲットＥＣＵ２２より送信されたハッシュ値とを比較して更新データの完全性を検証する。【選択図】図１

Description

本発明は、車両に搭載される電子制御装置に書き込ませる更新データを含む配信パッケージをストリーミング方式で送信するセンタ装置と、配信パッケージを受信して電子制御装置に更新データを転送するマスタ装置とを備える車載通信システム，そのシステムに使用されるセンタ装置及び車両側システム並びに車載通信の更新データ検証方法に関する。

近年、運転支援機能や自動運転機能等の車両制御の多様化に伴い、車両の電子制御装置（以下、ＥＣＵ（Electronic Control Unit）と称する）に搭載される車両制御や診断等のアプリプログラムの規模が増大している。また、機能改善等によるバージョンアップに伴い、ＥＣＵのアプリプログラムを書換える，所謂リプログを行う機会も増えつつある。一方、通信ネットワークの進展等に伴い、コネクッテッドカーの技術も普及している。このような事情から、例えば特許文献１には、サーバよりＥＣＵの更新プログラムを含むデータパッケージをＯＴＡ（Over The Air）により車載装置に配信し、車両側で更新プログラムを書換える技術が開示されている。

上記の更新プログラムを書換える方式には、センタ装置から更新プログラムの全てを車両側のメモリにダウンロードしてから更新を行うストレージ方式と、センタ装置から更新プログラムを車両側にダウンロードしながら更新を行うストリーミング方式とがある。車両側では、一般にＤＣＭ（Data Communication Module）やＣＧＷ（Central Gate Way）等と称されるユニットを有するＯＴＡマスタが、センタ装置から更新プログラムを含む配信パッケージを受信して、更新対象となるターゲットＥＣＵに更新プログラムを転送して書き込む。

ストレージ方式では、配信パッケージにデジタル署名が付与されており、ＯＴＡマスタは、そのデジタル署名を用いて配信パッケージの完全性を確認してから、ターゲットＥＣＵに書き込みを行っている。

特開２０２０－２７６２４号公報

しかしながら、ストリーミング方式では、ＯＴＡマスタが上記のように完全性を確認することなく、受信した更新プログラムを逐次ターゲットＥＣＵに書き込んでいる。そのため、センタ装置からターゲットＥＣＵまでのデータ転送経路において、配信パッケージに含まれるプログラムのデータが差し替えられると、その不正なデータがそのままターゲットＥＣＵに書き込まれてしまうおそれがあった。

本発明は上記事情に鑑みてなされたものであり、その目的は、センタ装置からストリーミング方式で送信される更新データについても、完全性を検証できる車載通信システム，センタ装置，車両側システム及び車載通信の更新データ検証方法を提供することにある。

請求項１記載の車載通信システムによれば、センタ装置は、更新データを配信パッケージとしてストリーミング方式で車両側のマスタ装置に送信する際に、更新データについて計算したハッシュ値もマスタ装置に送信する。マスタ装置は、配信パッケージを受信すると更新データを電子制御装置に転送する。電子制御装置は、前記更新データについてハッシュ値を計算すると、そのハッシュ値をマスタ装置に送信し、マスタ装置は、センタ装置より送信されたハッシュ値と、電子制御装置より送信されたハッシュ値とを比較して更新データの完全性を検証する。

このように構成すれば、センタ装置からストリーミング方式で車両側に送信される配信パッケージ含まれる更新データが、途中で改竄される等して不完全なデータに置き換わったとしても、マスタ装置においてハッシュ値を用いた検証が行われるので、不完全な更新データが電子制御装置にインストールされてしまうことを防止できる。したがって、通信システムのセキュリティを向上させることが可能になる。

請求項２記載の車載通信システムによれば、センタ装置は、複数の電子制御装置にそれぞれ更新データを書き込ませる際には、各更新データについて計算した複数のハッシュ値もマスタ装置に送信する。マスタ装置は、各更新データを各電子制御装置にそれぞれ転送し、各電子制御装置は、それぞれの更新データについてハッシュ値を計算すると、そのハッシュ値をマスタ装置に送信する。マスタ装置は、複数の電子制御装置より送信されたハッシュ値を、センタ装置より送信された対応するハッシュ値と比較する。したがって、複数の電子制御装置にそれぞれ更新データを送信するケースについても同様に、不完全な更新データが各電子制御装置にインストールされてしまうことを防止できる。

請求項７記載の車載通信システムによれば、センタ装置は請求項１と同様に、ストリーミング方式で配信パッケージを車両側のマスタ装置に送信する際に、更新データについて計算したハッシュ値もマスタ装置に送信する。マスタ装置は、更新データについて所定のデータサイズ毎にハッシュ値を計算することで、更新データ全体についてのハッシュ値を得ると、そのハッシュ値とセンタ装置より送信されたハッシュ値とを比較して、更新データの完全性を検証する。

すなわち、請求項１の電子制御装置に替ってマスタ装置が、更新データについてのハッシュ値を計算し完全性を検証するので、マスタ装置で検証処理を完結させて請求項１と同様の効果が得られる。

第１実施形態において、車載通信システムの構成を概略的に示す機能ブロック図 リプロポリシーメタデータの一例を示す図 ダウンロードメタデータの一例を示す図 ＯＴＡセンタより車載システムに、ストリーミング方式で配信パッケージを伝送する態様をイメージ的に示す図 ＯＴＡセンタが行うパッケージ生成処理を示すフローチャート 同署名生成処理を示すフローチャート 同署名伝送処理を示すフローチャート ＯＴＡマスタが行うパッケージ及び署名受信処理を示すフローチャート ターゲットＥＣＵ側の処理を示すフローチャート ターゲットＥＣＵが単一である場合の図４相当図 第２実施形態において、ハッシュチェーンを用いて配信パッケージを伝送する態様をイメージ的に示す図 ＯＴＡセンタが行う署名生成処理を示すフローチャート ＯＴＡマスタ側の処理を示すフローチャート 第３実施形態において、配信パッケージを伝送する際に、ＯＴＡマスタがハッシュ値を計算する態様をイメージ的に示す図 ＯＴＡマスタ側の処理を示すフローチャート ターゲットＥＣＵ側の処理を示すフローチャート 第４実施形態において、ストレージ方式が混在して配信パッケージを伝送する態様をイメージ的に示す図 ＯＴＡマスタ側の処理を示すフローチャート 第５実施形態において、スマートホンを経由して配信パッケージを伝送する態様をイメージ的に示す図 ＯＴＡセンタ側の処理を示すフローチャート スマートホン側の処理を示すフローチャート ＯＴＡマスタ側の処理を示すフローチャート

（第１実施形態）
図１に示すように、本実施形態の車載通信システム１は、センタ装置に相当するＯＴＡセンタ２と、車両側システム３とを備えている。ＯＴＡセンタ２は、ＰＫＧ生成サーバ４，配信サーバ５及びＤＢ部１００を有し、ＤＢ部１００は、ソフトウェアパッケージＤＢ１０１，デジタル署名ＤＢ１０２，構成情報ＤＢ１０３，個車情報ＤＢ１０４，ＥＣＵリプロデータＤＢ１０５及びＥＣＵメタデータＤＢ１０６を有している。尚、「データベース」をＤＢと表記し、「パッケージ」をＰＫＧと表記することがある。

ＰＫＧ生成サーバ４は、ソフトパッケージ生成部９，ハッシュ値収集部１０，ハッシュ値計算部１１，デジタル署名生成部１２を備えている。ソフトパッケージ生成部９は、データの更新対象となるターゲットＥＣＵが搭載されている車両に配信するソフトウェアパッケージを生成する機能部であり、その詳細については、例えば特開２０２０－２７６２４号公報の図１５，図１６，図１９等に開示されている。以下、特開２０２０－２７６２４号公報を「参照公報」と称する。ソフトウェアパッケージには、プログラムの更新データや書換え諸元データ等が含まれる。ハッシュ値を含むソフトウェアパッケージは、ソフトウェアパッケージＤＢ１０１に記憶される。

ハッシュ値収集部１０は、上記のソフトウェアパッケージからハッシュ値を計算する対象となる更新データを収集する機能部であり、ハッシュ値計算部１１は、収集されたデータにハッシュ関数を適用してハッシュ値を計算する機能部である。デジタル署名生成部１２は、計算されたハッシュ値と対応するターゲットＥＣＵのＩＤであるターゲットＩＤとを紐付けたハッシュ値連結情報に、生成したデジタル署名を付与する機能部である。デジタル署名は、デジタル署名ＤＢ１０２に記憶される。

配信サーバ５は、配信管理部１３，車両情報管理部１４，ソフトウェア管理部１５，キャンペーン管理部１６，構成情報管理部１７及び個車状態管理部１８を備えている。配信管理部１３は、各車両に対するソフトウェアパッケージやキャンペーン情報の配信を管理する機能部である。車両情報管理部１４は、個々の車両よりアップロードされる個車情報を個車情報ＤＢ１０４に登録して管理する。ソフトウェア管理部１５には、ターゲットＥＣＵの更新プログラムがＯＥＭ（Original Equipment Manufacturer）等により登録される。キャンペーン管理部１６には、主に車両側システム３で表示するプログラム更新に関する情報であるキャンペーン情報がＯＥＭ等により登録される。

構成情報管理部１７は、構成情報ＤＢ１０３に登録される車両型式毎の構成情報を管理する。構成情報は、車両に搭載されるＥＣＵのハードウェア及びソフトウェアに関する識別情報であり、複数のＥＣＵから成るシステム構成の識別情報や、複数のシステムから成る車両構成の識別情報も含まれる。個車状態管理部１８は、各車両におけるターゲットＥＣＵのプログラム更新の状態、バージョン等の情報を管理する。尚、ＰＫＧ生成サーバ４及び配信サーバ５は、コンピュータのハードウェア及びソフトウェアにより実現されている機能である。

ＤＢ部１００の構成情報ＤＢ１０３，個車情報ＤＢ１０４，ＥＣＵリプロデータＤＢ１０５及びＥＣＵメタデータＤＢ１０６は、参照公報における「構成情報ＤＢ２０８，個車情報ＤＢ２１３，ＥＣＵリプロデータＤＢ２０４及びＥＣＵメタデータＤＢ２０５」に対応している。

車両側システム３は、マスタ装置に相当するＯＴＡマスタ２１と、プログラムが更新される対象となる電子制御装置である更新対象ＥＣＵ２２（１），２２（２），２２（３），…を備えている。以下、更新対象ＥＣＵ２２をターゲットＥＣＵ２２と称する。

ＯＴＡマスタ２１は、参照公報では図１に示すＤＣＭ１２及びＣＧＷ１３を合わせた機能部であり、ダウンロード処理部２３，アンパック処理部２４，ハッシュ値計算部２５及びハッシュ値比較部２６を備えている。ダウンロード処理部２３は、ＯＴＡセンタ２と無線通信を行い、配信パッケージのデータやデジタル署名のデータをダウンロードする。アンパック処理部２４は、ダウンロードされた配信パッケージを、各処理を行うデータセクション毎に分離するアンパック処理を行う。ハッシュ値計算部２５は、ハッシュ値の計算対象となるデータ値についてハッシュ値を計算するが、この機能部は第２実施形態において使用される。ハッシュ値比較部２６は、後述するようにターゲットＥＣＵ２２側で計算されたハッシュ値を、ダウンロードされた配信パッケージに含まれているハッシュ値と比較する。

ターゲットＥＣＵ２２は、マイコン２７，メモリ２８及びハッシュ値計算部２９を備えている。メモリ２８は、例えばフラッシュメモリであり、ＯＴＡマスタ２１がダウンロードした更新データが転送されてインストールされる。ハッシュ値計算部２９は、ＯＴＡマスタ２１より転送された更新データについてハッシュ値を計算する。

≪リプロポリシーメタデータ≫
図２に示すリプロポリシーメタデータは、データのダウンロードに先立って、ＯＴＡセンタ２よりＯＴＡマスタ２１に送信される。
＜リプロポリシーメタデータバージョン＞
リプロポリシーメタデータのバージョンであり、例えば「１．０．０」や「２．０．０」などのバージョン情報が格納される。

＜配信レイヤ＞
ＯＴＡセンタ２との通信に使用されるプロトコル，例えばＵｐｔａｎｅ（登録商標）やＯＭＡ－ＤＭ（Open Mobile Alliance-Device Management）等を示す情報や、通信手段がＯＴＡマスタ２１であることを示す「セルラー」や、その他後述するスマートホンやＵＳＢメモリであること等の情報が格納される。

＜マスタレイヤ＞
ＯＴＡマスタ２１について、そのプラットフォーム（ＰＦ）が、例えばＡＰ，ＣＰ，ＡＧＬ(Automotive Grade Linux)，Ａｎｄｒｏｉｄ（登録商標）であること等を示す情報が格納される。ＥＣＵのプラットフォームに応じた更新プログラムを配信するためのパッケージ構造について、一般社団法人ＪＡＳＰＡＲの仕様では、標準化団体ＡＵＴＯＳＡＲの静的ＯＳで動作するクラシックプラットフォーム（ＣＰ）に適用可能なデータ要件が規定されている。また、ＡＵＴＯＳＡＲでは、動的ＯＳで動作する新たなタイプのアダプティブプラットフォーム（ＡＰ）に適用可能なデータ要件が規定されている。ＡＧＬは、車載Ｌｉｎｕｘ（登録商標）であり、Ａｎｄｒｏｉｄは、Android Automotive OSである。

加えて、制御方式については、特定のフォーマットに従い設定されたパラメータに応じて処理する「パラメータ」や、特定のフォーマットがなくより自由な記載形式で処理する「スクリプト」等の情報が格納される。

＜ターゲットレイヤ＞
ターゲットＥＣＵ２２に対応した情報である。ＰＦ，転送方式，制御方式については、前述したものと同様である。ターゲットＩＤは、ターゲットＥＣＵ２２に対応したＩＤであるが、ここに格納するのはオプションである。

≪ダウンロードメタデータ≫
図３に示すダウンロードメタデータは、リプロポリシーメタデータに続いてＯＴＡセンタ２よりＯＴＡマスタ２１に送信される。

＜配信レイヤ＞
例えば通信プロトコルがＵｐｔａｎｅであれば、Ｕｐｔａｎｅメタデータを取得するための情報であり、それに対応したＵＲＩ，データ名，データサイズ，ハッシュ値，ターゲットＩＤ,転送方式等が格納される。

＜マスタレイヤ＞
例えばＶｅｈｉｃｌｅ ＰＫＧを取得するための情報であり、各項目は配信レイヤと同様である。この情報は、複数の場合がある。

＜ターゲットレイヤ＞
例えばＳｏｆｔｗａｒｅ ＰＫＧを取得するための情報であり、各項目は配信レイヤと同様である。この情報も、複数の場合がある。尚、Ｖｅｈｉｃｌｅ ＰＫＧやＳｏｆｔｗａｒｅ ＰＫＧについては、例えば“Specification of Update Configuration Management AUTOSAR AP R20-11,Document ID No.706”のp50,52，53に掲載されており、当該文献の関連する記載を参照。

ここで、ＡＰとＣＰとの違いについて説明する。ＡＰ及びＣＰはソフトウェアプラットフォームを表している。ソフトウェアプラットフォームは、ソフトウェアアーキテクチャとも呼ばれる。ＣＰは、AUTOSAR Classic Platformを表し、ＡＰはAUTOSAR Adaptive Platformを表す。さらに、ＣＰ仕様書に準拠して動作するＥＣＵをＣＰ ＥＣＵ又はＣＰのＥＣＵと表記し、ＡＰ仕様書に準拠して動作するＥＣＵをＡＰ ＥＣＵ又はＡＰのＥＣＵと表記することがある。

ＡＰ及びＣＰにおいては、使用されるオペレーティングシステム，いわゆるＯＳや開発言語が異なる。ＣＰ ＥＣＵとＡＰ ＥＣＵは、受信できるパッケージの構造が異なる。 これらのパッケージの構造の違いは、主にＥＣＵの処理性能の違いに起因するものであり、一般的にＣＰのＥＣＵの処理性能は低いため、パッケージに含まれる諸元データなどもバイナリデータで記載されており、処理性能の低いＥＣＵでも解釈・処理しやすいパッケージデータ構造となっている。

一方、ＡＰのＥＣＵは処理性能が高いものが用いられるため、何らかの言語で記述された構造的な文字データを解析してプログラムで扱えるデータ構造に変換するパーサー機能を搭載することが可能であり、データ構造には単純なバイナリデータではなく、例えばＪＳＯＮ（JavaScript Object Notation）のようなオブジェクト指向のデータ形式を採用できるため、柔軟なパッケージデータ構造となっている。

次に、本実施形態の作用について説明する。図４は、本実施形態の作用を概念的に示している。ターゲットＥＣＵ２２（１）～２２（３）に対応する更新データをＡ～Ｃとすると、ＯＴＡセンタ２の配信サーバ４は、ハッシュ値計算部１１により、各更新データＡ～Ｃについて、例えばＳＨＡ（Secure Hush Algorithm）－２等のハッシュ関数を適用してハッシュ値ａ～ｃを算出する（図５，Ｓ０）。また、前述のダウンロードメタデータＤについても同様にハッシュ値ｄを算出するが、図４から図９に示すフローチャートでは、ハッシュ値ａ～ｃに関する処理のみを現している。

次に、ハッシュ値収集部１０により、各ハッシュ値ａ～ｃを収集すると（図６，Ｓ１）、これらのハッシュ値ａ～ｃとターゲットＩＤとを紐付けたハッシュ値連結情報を生成する（Ｓ２）。それから、デジタル署名生成部１２が、ハッシュ値連結情報に対し、デジタル署名を生成して付与する、つまり秘密鍵により暗号化すると（Ｓ３）、そのデジタル署名をデジタル署名ＤＢ１０２に伝送して保存する（Ｓ４，Ｓ５）。その後、ＯＴＡマスタ２１よりハッシュ値連結情報の伝送要求があると（図７，Ｓ６；ＹＥＳ）、配信サーバ５は、ＯＴＡマスタ２１にハッシュ値連結情報と、配信パッケージとを順次伝送する（Ｓ７，Ｓ７ａ）。

次に、車両側システム３側の処理について説明する。図８に示すように、ＯＴＡマスタ２１のダウンロード処理部２３は、配信サーバ５よりストリーミング方式で送信された配信パッケージを受信すると、各更新データＡ～Ｃを各ターゲットＥＣＵ２２（１）～２２（３）に転送する（Ｓ１１）。続いて、ダウンロード処理部２３は、デジタル署名を受信する（Ｓ１２）。尚、この場合の通信プロトコルは、ＵｐｔａｎｅやＳＳＬ（Secure Sockets Layer）等の暗号化を用いたものを使用する。

一方、ターゲットＥＣＵ２２は、図９に示すように、ＯＴＡマスタ２１から受信した更新データをダウンロードすると（Ｓ２１）、その更新データにハッシュ関数を適用してハッシュ値を計算する（Ｓ２２）。それから、計算したハッシュ値を、ＯＴＡマスタ２１に伝送する（Ｓ２３）。

ＯＴＡマスタ２１は、受信したデジタル署名を検証する、つまり公開鍵で復号化して、ハッシュ値連結情報を取得する（Ｓ１３）。それから、各ターゲットＥＣＵ２２（１）～２２（３）にハッシュ値の転送を要求するが（Ｓ１４）、ステップＳ２３において、ターゲットＥＣＵ２２がＯＴＡマスタ２１に自動的にハッシュ値を転送する仕様の場合、この処理は不要である。

全てのターゲットＥＣＵ２２からハッシュ値ａ’～ ｃ’を受信すると（Ｓ１５；ＹＥＳ）、ハッシュ値比較部２６は、ハッシュ値連結情報より取得したハッシュ値ａ～ｃと、ターゲットＥＣＵ２２から取得したハッシュ値ａ’～ ｃ’とをそれぞれ比較する（Ｓ１６）。そして、両者が全て一致すれば（Ｓ１７；ＹＥＳ）、各ターゲットＥＣＵ２２（１）～２２（３）に対してインストール指示を発行する（Ｓ１８）。一方、何れか１つでも不一致があれば（Ｓ１７；ＮＯ）、不一致があったターゲットＥＣＵ２２にロールバック指示を発行する（Ｓ１９）。この処理はオプションである。

ターゲットＥＣＵ２２は、ＯＴＡマスタ２１からのインストール要求があると（Ｓ２４；ＹＥＳ）ダウンロードした更新データをインストールする（Ｓ２５）。また、インストール要求がなく（Ｓ２４；ＮＯ）、ＯＴＡマスタ２１から中止要求があると（Ｓ２６；ＹＥＳ）処理を終了する。

尚、以上の処理は、ターゲットＥＣＵ２２が複数の場合であるが、図１０はターゲットＥＣＵ２２が単一の場合を示す。メタデータＥについてのハッシュ値がｅとなるだけで、基本的には図４に示す処理と同様である。

以上のように本実施形態によれば、車載通信システム１において、ＯＴＡセンタ２は、ストリーミング方式で配信パッケージを車両側のＯＴＡマスタ２１に送信する際に、更新データについて計算したハッシュ値もＯＴＡマスタ２１に送信する。ＯＴＡマスタ２１は、配信パッケージを受信すると、更新データをターゲットＥＣＵ２２に転送する。ターゲットＥＣＵ２２は、更新データについてハッシュ値を計算すると、そのハッシュ値をＯＴＡマスタ２１に送信し、ＯＴＡマスタ２１は、ＯＴＡセンタ２より送信されたハッシュ値と、ターゲットＥＣＵ２２より送信されたハッシュ値とを比較して更新データの完全性を検証する。

このように構成すれば、ＯＴＡセンタ２からストリーミング方式で車両側システム３に送信される配信パッケージに含まれる更新データが、途中で改竄される等して不完全なデータに置き換わったとしても、ＯＴＡマスタ２１においてハッシュ値を用いた検証が行われるので、不完全な更新データがターゲットＥＣＵ２２にインストールされてしまうことを防止できる。したがって、通信システム１のセキュリティを向上させることが可能になる。

また、ＯＴＡセンタ２は、複数のターゲットＥＣＵ２２（１）～２２（３）にそれぞれ更新データＡ～Ｃを書き込ませる際には、各更新データＡ～Ｃについて計算した複数のハッシュ値ａ～ｃもＯＴＡマスタ２１に送信する。ＯＴＡマスタ２１は、各更新データＡ～Ｃを各ターゲットＥＣＵ２２（１）～２２（３）にそれぞれ転送し、各ターゲットＥＣＵ２２（１）～２２（３）は、それぞれの更新データＡ～Ｃについてハッシュ値ａ’～ｃ’を計算すると、そのハッシュ値ａ’～ｃ’をＯＴＡマスタ２１に送信する。ＯＴＡマスタ２１は、複ハッシュ値ａ’～ｃ’を、ハッシュ値ａ～ｃと比較する。したがって、複数のターゲットＥＣＵ２２（１）～２２（３）にそれぞれ更新データＡ～Ｃを送信するケースについても同様に、不完全な更新データがインストールされてしまうことを防止できる。

（第２実施形態）
以下、第１実施形態と同一部分には同一符号を付して説明を省略し、異なる部分について説明する。図１１に示すように、第２実施形態では、ＰＫＧ生成サーバ４は、更新データＡ～Ｃに対応して得られたハッシュ値ａ～ｃ及びメタデータに対応して得られたハッシュ値ｄに対してハッシュ関数を適用する。そして、得られたハッシュ値ｆを「ハッシュチェーン」と称する（図１２，Ｓ８）。ハッシュチェーンｆは上位ハッシュ値に相当する。そして、ハッシュチェーンｆに対してデジタル署名を付与すると（Ｓ９）、ステップＳ４及びＳ５を実行する。

ＯＴＡマスタ２１は、ＯＴＡセンタ２の配信サーバ５から配信パッケージを受信すると（図１３，Ｓ３１）、各更新データＡ～Ｃを各ターゲットＥＣＵ２２（１）～２２（３）に転送する（Ｓ３２）。尚、ターゲットＥＣＵ２２が行う処理は、図９と同様である。

続いて、ダウンロード処理部２３は、ハッシュチェーンｆに対して付与されたデジタル署名を受信すると（Ｓ３３）、受信したデジタル署名を検証する（Ｓ３４）。検証が成功すれば、ハッシュチェーンｆが得られる。

ＯＴＡマスタ２１は、各ターゲットＥＣＵ２２（１）～２２（３）が計算したハッシュ値ａ’～ｃ’を受信する（Ｓ３５）。ハッシュ値計算部１１は、受信したハッシュ値ａ’～ｃ’（及びｄ’）についてハッシュチェーンｆ’を計算する（Ｓ３６）。

そして、ハッシュ値比較部２６は、ＯＴＡセンタ２より取得したハッシュチェーンｆと、ハッシュ値計算部１１が計算したハッシュチェーンｆ’とを比較する（Ｓ３７）。両者が全て一致すれば（Ｓ３８；ＹＥＳ）、各ターゲットＥＣＵ２２（１）～２２（３）に対してインストール指示を発行する（Ｓ１８）。一方、不一致であれば（Ｓ３８；ＮＯ）、処理を終了するか、又はターゲットＥＣＵ２２にロールバック指示を発行する（Ｓ４０）。

以上のように第２実施形態によれば、ＯＴＡセンタ２は、複数のハッシュ値ａ～ｃについて計算したハッシュ値であるハッシュチェーンｆもＯＴＡマスタ２１に送信する。ＯＴＡマスタ２１は、ＥＣＵ２２（１）～２２（３）より受信したハッシュ値ａ’～ｃ’についてハッシュチェーンｆ’を計算すると、ハッシュチェーンｆ’とハッシュチェーンｆとを比較する。これにより、複数のハッシュ値ａ～ｃの何れかが不完全なデータとなった場合も検証によって検知できるので、通信システムのセキュリティを更に向上させることができる。

（第３実施形態）
図１４に示すように、第３実施形態では、ＯＴＡセンタ２からストリーミング方式で配信パッケージを受信する際に、ＯＴＡマスタ２１が更新データについて順次ハッシュ値を計算する。ハッシュ関数には、前述したＳＨＡ－２を用いる。以下、一例として、ＳＨＡ－２関数を使用した事例を説明する。ＯＴＡセンタ２側の処理は、図５と同様である。ＯＴＡマスタ２１は、ＯＴＡセンタ２から受信したダウンロードメタデータより、受信するデータのサイズを把握すると（図１５，Ｓ４１）、そのデータサイズが５１２ビットの何倍になるかを計算してから（Ｓ４２）、ＯＴＡセンタ２よりストリーミング方式で配信パッケージを受信する（Ｓ４３）。

ＯＴＡマスタ２１は、受信したデータを５１２ビット単位で分割する（Ｓ４４）。分割したデータを「メッセージ」と称すると、例えば、Ｎ個のメッセージに分割されたとする。そして、ハッシュ値計算部２５は、メッセージにＳＨＡ－２関数を適用し（Ｓ４５）、その出力結果を次のＳＨＡ－２関数の初期バッファ値として保持する（Ｓ４６）。例えばＳＨＡ－２５６であれば、５１２ビットのデータに適用して得られるハッシュ値のハッシュ長は２５６ビットになる。そして、（Ｎ―１）個のメッセージにＳＨＡ－２関数を適用するまで（Ｓ４７；ＮＯ）ステップＳ４５，Ｓ４６の処理を繰り返す。

Ｎ個目のメッセージについては（Ｓ４７；ＹＥＳ）、そのデータサイズが５１２ビットの整数倍か否かを判断し（Ｓ４８）、整数倍でなければ（ＮＯ）パディングを行って整数倍にしてからＳＨＡ－２関数を適用し、その出力結果をハッシュ値とする（Ｓ４９）。そして、ＯＴＡマスタ２１は、配信サーバ４から受信したデジタル署名を検証してハッシュ値を得る（Ｓ５０）。ステップＳ４８において、メッセージのデータサイズが５１２ビットの整数倍であれば（ＹＥＳ）、最終的なハッシュ値が得られているのでステップＳ５０に移行する。

それから、ハッシュ値比較部２６は、ステップＳ５０で取得したハッシュ値と、ハッシュ値計算部２５が計算したハッシュ値とを比較し（Ｓ５１）、両者が一致すれば（Ｓ５２；ＹＥＳ）ターゲットＥＣＵ２２に対してインストール指示を発行する（Ｓ５３）。一方、不一致であれば（Ｓ５２；ＮＯ）、処理を終了するか、又はターゲットＥＣＵ２２にロールバック指示を発行する（Ｓ５４）。

尚、図１５に示す処理は、１つのターゲットＥＣＵ２２に対応したもので、ターゲットＥＣＵ２２が複数の場合は、図１５に示す処理を繰り返し実行する。また、図１６に示すターゲットＥＣＵ２２の処理は、図９におけるステップＳ２１，Ｓ２４、Ｓ２５のみを実行するもので、ステップＳ２４で「ＮＯ」と判断すると処理を終了する。

以上のように第３実施形態によれば、ＯＴＡマスタ２１は、更新データについて所定のデータサイズ毎にハッシュ値を計算することで、更新データ全体についてのハッシュ値を得ると、そのハッシュ値とＯＴＡセンタ２より送信されたハッシュ値とを比較して更新データの完全性を検証する。このように構成すれば、完全性の検証をＯＴＡマスタ２１内の処理として行うことができる。

（第４実施形態）
図１７に示すように、第４実施形態は、ストリーミング方式とストレージ方式とが混在している場合の処理を示す。ＯＴＡセンタ２の処理は、第１実施形態と同様である。図１８に示すように、ＯＴＡマスタ２１は、配信サーバ５よりストレージ方式のパッケージＡ及びストリーミング方式のパッケージＢを受信する（Ｓ６１）。パッケージＡはｚｉｐ形式であり、パッケージＡについての検証データが含まれている。続いて、ＯＴＡマスタ２１は、検証データによってパッケージＡを検証し、パッケージＢに含まれている更新データＫ，ＬをターゲットＥＣＵ２２（４），２２（５）に伝送する（Ｓ６２）。ここで、パッケージＡ，Ｂのダウンロードが開始される。

パッケージＡであり（Ｓ６３；ＹＥＳ）検証が正常に終了すれば（Ｓ７０；ＹＥＳ）、パッケージＡに含まれている更新データＧ～ＩをターゲットＥＣＵ２２（１）～２２（３）に書き込む（Ｓ７１）。ここで、パッケージＡのインストールが開始される。一方、検証が正常に終了しなければ（Ｓ７０；ＮＯ）、パッケージＡについての処理を終了する。また、パッケージＢのインストール処理を開始しているターゲットＥＣＵ２２に対しては、ロールバック指示を発行する（Ｓ７２）。

パッケージＢであれば（Ｓ６３；ＮＯ）、ＯＴＡマスタ２１は、更新データＫ，Ｌについて、ターゲットＥＣＵ２２（４），２２（５）が計算したハッシュ値ｋ’，ｌ’を受信する（Ｓ６４）。尚、これらのターゲットＥＣＵ２２の処理は図９と同様である。続いて、配信サーバ５よりデジタル署名を受信すると、検証を行う（Ｓ６５）。

そして、復号したハッシュ値ｋ，ｌとハッシュ値ｋ’，ｌ’とを比較し（Ｓ６６）、両者が一致すれば（Ｓ６７；ＹＥＳ）、各ターゲットＥＣＵ２２（４），２２（５）に対してインストール指示を発行する（Ｓ６８）。ここで、パッケージＢのインストールが開始される。また、両者が不一致であれば（Ｓ６７；ＮＯ）、パッケージＢについての処理を終了する。また、パッケージＡのインストール処理を開始しているターゲットＥＣＵ２２に対しては、ロールバック指示を発行する（Ｓ６９）。

ここで、図１８について別の態様を説明する。上記実施形態では、Ｓ６３にて、パッケージがパッケージＡであるか否かを判定した。それに替えて、ＯＴＡマスタ２１は、パッケージの種別を判定し、その結果に応じた処理を実行しても良い。パッケージＡ及びパッケージＢを受信すると、ＯＴＡマスタ２１はパッケージの種別を判定する。その結果、ＯＴＡマスタ２１は、パッケージがストレージ方式のパッケージＡであると判定するとＳ７０へ移行し、Ｓ７０からＳ７２の処理を実行する。また、ＯＴＡマスタ２１は、パッケージがストリーミング方式のパッケージＢであると判定するとＳ６４に移行し、Ｓ６４からＳ６９の処理を実行する。ＯＴＡマスタ２１によるパッケージ種別の判定は、受信したパッケージの数だけ繰り返される。

以上のように第４実施形態によれば、ＯＴＡセンタ２は、複数のターゲットＥＣＵ２２の一部に書き込ませる更新データをストレージ方式で送信する際には、その更新データと当該データについて計算したハッシュ値とをＯＴＡマスタ２１に送信する。ＯＴＡマスタ２１は、前記更新データについてハッシュ値を計算し、ＯＴＡセンタ２より送信された対応するハッシュ値と比較して前記更新データの完全性を検証する。完全性が検証されると、ストレージ方式に対応するターゲットＥＣＵ２２（１）～２２（３）に更新データを転送する。これにより、ストレージ方式に対応するターゲットＥＣＵ２２が混在している場合でも、セキュリティを向上させることができる。

（第５実施形態）
図１９に示すように、第５実施形態は、ＯＴＡセンタ２から配信パッケージを一旦スマートホン３１にダウンロードし、スマートホン３１からＯＴＡマスタ２１に転送する場合を示す。尚、「スマートホン」を「スマホ」と表記し、カーナビゲーション装置を「ナビ」と表記する場合がある。図２０に示すように、ＯＴＡセンタ２は、ステップＳ１～Ｓ４を実行すると、後述するように、ユーザが図示しないカーナビゲーション装置やスマートホン３１によりＯＴＡセンタ２と通信を行っており、パッケージの配信先としてスマートホン３１を選択しているか否かを判断する（Ｓ７３）。スマートホン３１を選択していれば（ＹＥＳ）スマートホン３１にパッケージを配信し（Ｓ７４）、スマートホン３１を選択していなければ（ＮＯ）、従前通りＯＴＡマスタ２１にパッケージを配信する（Ｓ７）。

図２１に示すように、スマートホン３１を所持しているユーザは、そのスマートホン３１と車両側の機器とで無線通信のペアリングが行われていることを前提として、ＯＴＡセンタ２よりプッシュ通知を受け取る（Ｓ８１）。そして、スマートホン３１により、どこに配信パッケージをダウンロードするか選択する（Ｓ８２）。すると、ＯＴＡセンタ２の配信サーバ５に選択結果が通知される（Ｓ８３）。

ユーザがスマートホン３１を選択すれば（Ｓ８４；ＹＥＳ）、スマートホン３１の指定パスにパッケージがダウンロード（ＤＬ）される（Ｓ８５）。続いて、スマートホン３１が、パッケージのダウンロードが完了したことを配信サーバ５に通知すると（Ｓ８６）、スマートホン３１は、パッケージをＯＴＡマスタ２１に転送する（Ｓ８７）。

図２２に示すように、ＯＴＡマスタ２１は、ＯＴＡセンタ２側と車両構成情報の同期を図るため、ＯＴＡセンタ２に車両構成情報を送信する（Ｓ９１）。カーナビゲーション装置に表示された指示をユーザが実行すると（Ｓ９２；ＹＥＳ）、ＯＴＡマスタ２１は、ＯＴＡセンタ２より受信したデジタル署名を検証し、ハッシュ値連結情報を取得する（Ｓ９３）。

そして、カーナビゲーション装置又はスマートホン３１によって、配信パッケージの送信先としてスマートホン３１を選択したことをＯＴＡセンタ２に送信すると（Ｓ９４；ＹＥＳ）、ＯＴＡマスタ２１は、ＯＴＡセンタ２から通知されたディレクトリに従い、スマートホン３１から配信パッケージをダウンロードする（Ｓ９５）。一方、送信先としてスマートホン３１が選択されなければ（Ｓ９４；ＮＯ）、ＯＴＡマスタ２１は、ＯＴＡセンタ２から配信パッケージをダウンロードする（Ｓ９６）。以降は、第１実施形態のステップＳ１２～Ｓ１９を実行する。

以上のように第５実施形態によれば、ＯＴＡマスタ２１は、選択的に、ＯＴＡセンタ２からスマートホン３１にダウンロードされた配信パッケージを、スマートホン３１からダウンロードすることができる。これにより、配信パッケージをより柔軟な態様で取得できる。

（その他の実施形態）
リプロポリシーメタデータ及びダウンロードメタデータの内容は、個別の設計に応じて適宜変更すれば良い。
ハッシュ関数は、ＳＨＡ－２に限らない。
本開示は、実施例に準拠して記述されたが、本開示は当該実施例や構造に限定されるものではないと理解される。本開示は、様々な変形例や均等範囲内の変形をも包含する。加えて、様々な組み合わせや形態、さらには、それらに一要素のみ、それ以上、あるいはそれ以下、を含む他の組み合わせや形態をも、本開示の範疇や思想範囲に入るものである。

各装置等が提供する手段および／または機能は、実体的なメモリ装置に記録されたソフトウェアおよびそれを実行するコンピュータ、ソフトウェアのみ、ハードウェアのみ、あるいはそれらの組合せによって提供することができる。例えば、制御装置がハードウェアである電子回路によって提供される場合、それは多数の論理回路を含むデジタル回路、またはアナログ回路によって提供することができる。

本開示に記載の制御部及びその手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリを構成することによって提供された専用コンピュータにより、実現されてもよい。あるいは、本開示に記載の制御部及びその手法は、一つ以上の専用ハードウェア論理回路によってプロセッサを構成することによって提供された専用コンピュータにより、実現されてもよい。もしくは、本開示に記載の制御部及びその手法は、一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリと一つ以上のハードウェア論理回路によって構成されたプロセッサとの組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されていてもよい。

図面中、１は車載通信システム、２はＯＴＡセンタ、４はＰＫＧ生成サーバ、５は配信サーバ、３は車両側システム、２１はＯＴＡマスタ、２２はターゲットＥＣＵを示す。

Claims (20)

1. 車両に搭載される電子制御装置（２２）に、ストリーミング方式で更新データを配信パッケージとして送信するセンタ装置（２）と、
   前記車両に搭載され、前記配信パッケージを受信して、前記電子制御装置に更新データを転送するマスタ装置（２１）と、
   このマスタ装置より転送された更新データを記憶部に書き込む前記電子制御装置とを備え、
   前記センタ装置は、前記更新データについて計算したハッシュ値も前記マスタ装置に送信し、
   前記電子制御装置は、前記更新データについてハッシュ値を計算すると、前記ハッシュ値を前記マスタ装置に送信し、
   前記マスタ装置は、前記センタ装置より送信されたハッシュ値と、前記電子制御装置より送信されたハッシュ値とを比較して、前記更新データの完全性を検証する車載通信システム。
2. 前記センタ装置は、複数の電子制御装置にそれぞれ更新データを書き込ませる際には、各更新データについて計算した複数のハッシュ値も前記マスタ装置に送信し、
   前記マスタ装置は、各更新データを各電子制御装置にそれぞれ転送し、
   各電子制御装置は、前記更新データについてハッシュ値を計算すると、前記ハッシュ値を前記マスタ装置に送信し、
   前記マスタ装置は、複数の電子制御装置より送信されたハッシュ値を、前記センタ装置より送信された対応するハッシュ値と比較する請求項１記載の車載通信システム。
3. 前記センタ装置は、前記複数のハッシュ値について計算したハッシュ値を上位ハッシュ値として、前記上位ハッシュ値も前記マスタ装置に送信し、
   前記マスタ装置は、複数の電子制御装置より受信した複数のハッシュ値について上位ハッシュ値を計算すると、計算した上位ハッシュ値を、前記センタ装置より送信された上位ハッシュ値と比較する請求項２記載の車載通信システム。
4. 前記センタ装置は、複数の電子制御装置の一部についてストレージ方式で更新データを送信する際には、前記更新データと前記更新データについて計算したハッシュ値とを前記マスタ装置に送信し、
   前記マスタ装置は、前記更新データについてハッシュ値を計算し、前記センタ装置より送信された対応するハッシュ値と比較して、前記更新データの完全性を検証し、
   前記更新データの完全性が検証されると、前記ストレージ方式に対応する電子制御装置に更新データを転送する請求項２又は３記載の車載通信システム。
5. 前記センタ装置は、少なくともデータ取得先のアドレス，データ名及びデータサイズ，更新データの配信先である電子制御装置のＩＤ並びにデータ転送方式の情報を含むダウンロードメタデータに、前記ハッシュ値を加えて前記マスタ装置に送信する請求項１から４の何れか一項に記載の車載通信システム。
6. 前記センタ装置より、前記更新データを受信可能な携帯型情報端末を備え、
   前記マスタ装置は、前記携帯型情報端末を介しても、前記更新データを受信可能である請求項１から５の何れか一項に記載の車載通信システム。
7. 車両に搭載される電子制御装置に、ストリーミング方式で更新データを配信パッケージとして送信するセンタ装置と、
   前記配信パッケージを受信して、前記電子制御装置に更新データを転送するマスタ装置と、
   このマスタ装置より転送された更新データを記憶部に書き込む前記電子制御装置とを備え、
   前記センタ装置は、前記更新データについて計算したハッシュ値も前記マスタ装置に送信し、
   前記マスタ装置は、前記更新データについて所定のデータサイズ毎にハッシュ値を計算することで、前記更新データ全体についてのハッシュ値を得ると、前記ハッシュ値と前記センタ装置より送信されたハッシュ値とを比較して、前記更新データの完全性を検証する車載通信システム。
8. 車両に搭載される電子制御装置に、ストリーミング方式で更新データを送信する際に、前記更新データについて計算したハッシュ値も送信するセンタ装置。
9. 複数の電子制御装置にそれぞれ更新データを送信する際には、各更新データについて計算した複数のハッシュ値も送信する請求項８記載のセンタ装置。
10. 前記複数のハッシュ値について計算したハッシュ値を上位ハッシュ値として、前記上位ハッシュ値も送信する請求項９記載のセンタ装置。
11. 複数の電子制御装置の一部についてストレージ方式で更新データを送信する際には、前記更新データと前記更新データについて計算したハッシュ値とを送信する請求項９又は１０記載のセンタ装置。
12. 少なくともデータ取得先のアドレス，データ名及びデータサイズ，更新データの配信先である電子制御装置のＩＤ並びにデータ転送方式の情報を含むダウンロードメタデータに、前記ハッシュ値を加えて送信する請求項８から１１の何れか一項に記載のセンタ装置。
13. 車両に搭載され、センタ装置よりストリーミング方式で送信され、更新データを含む配信パッケージを受信するマスタ装置と、
    前記車両に搭載され、前記マスタ装置より転送された更新データを記憶部に書き込む電子制御装置とを備え、
    前記マスタ装置は、前記センタ装置が前記更新データについて計算して送信したハッシュ値を受信し、
    前記電子制御装置は、前記更新データについてハッシュ値を計算すると、前記ハッシュ値を前記マスタ装置に送信し、
    前記マスタ装置は、前記センタ装置より送信されたハッシュ値と、前記電子制御装置より送信されたハッシュ値とを比較して、前記更新データの完全性を検証する車両側システム。
14. 前記マスタ装置は、前記センタ装置が、複数の電子制御装置にそれぞれ更新データを送信する際に、各更新データについて計算し送信した複数のハッシュ値も受信すると、各更新データを各電子制御装置にそれぞれ転送し、
    各電子制御装置は、前記更新データについてハッシュ値を計算すると、前記ハッシュ値を前記マスタ装置に送信し、
    前記マスタ装置は、複数の電子制御装置より送信されたハッシュ値を、前記センタ装置より送信された対応するハッシュ値と比較する請求項１３記載の車両側システム。
15. 前記マスタ装置は、前記センタ装置が、前記複数のハッシュ値について計算したハッシュ値を上位ハッシュ値として送信したものも受信し、
    複数の電子制御装置より受信した複数のハッシュ値について上位ハッシュ値を計算すると、計算した上位ハッシュ値を、前記センタ装置より送信された上位ハッシュ値と比較する請求項１４記載の車両側システム。
16. 前記マスタ装置は、前記センタ装置が、複数の電子制御装置の一部に対する更新データを含む配信パッケージをストレージ方式で送信する際に、前記更新データと前記更新データについて計算したハッシュ値とを受信し、
    前記更新データについてハッシュ値を計算し、前記センタ装置より送信された対応するハッシュ値と比較して、前記更新データの完全性を検証し、
    前記更新データの完全性が検証されると、前記ストレージ方式に対応する電子制御装置に更新データを転送する請求項１４又は１５記載の車両側システム。
17. 前記センタ装置より、前記配信パッケージを受信可能な携帯型情報端末を備え、
    前記マスタ装置は、前記センタ装置より、前記携帯型情報端末を介しても、前記配信パッケージを受信可能である請求項１３から１６の何れか一項に記載の車両側システム。
18. 車両に搭載され、センタ装置よりストリーミング方式で送信される更新データを配信パッケージとして受信するマスタ装置と、
    前記車両に搭載され、前記マスタ装置より転送された更新データを記憶部に書き込む電子制御装置とを備え、
    前記センタ装置は、前記更新データについて計算したハッシュ値も前記マスタ装置に送信し、
    前記マスタ装置は、前記センタ装置が、前記更新データについて計算したハッシュ値も受信し、前記更新データについて所定のデータサイズ毎にハッシュ値を計算することで、前記更新データ全体についてのハッシュ値を得ると、前記ハッシュ値と前記センタ装置より送信されたハッシュ値とを比較して、前記更新データの完全性を検証する車両側システム。
19. センタ装置が、車両に搭載される電子制御装置に、ストリーミング方式で更新データを送信する際に、
    前記車両に搭載されるマスタ装置が前記更新データを配信パッケージとして受信すると前記電子制御装置に転送し、
    前記センタ装置が、前記更新データについて計算したハッシュ値も前記マスタ装置に送信し、
    前記電子制御装置が、前記更新データについて計算したハッシュ値を前記マスタ装置に送信し、
    前記マスタ装置が、前記センタ装置より送信されたハッシュ値と、前記電子制御装置より送信されたハッシュ値とを比較して、前記更新データの完全性を検証する車載通信の更新データ検証方法。
20. センタ装置が、車両に搭載される電子制御装置に、ストリーミング方式で更新データを送信する際に、
    前記車両に搭載されるマスタ装置が前記更新データを配信パッケージとして受信すると、前記電子制御装置に転送し、
    前記センタ装置が、前記更新データについて計算したハッシュ値も前記マスタ装置に送信し、
    前記マスタ装置が、前記センタ装置が前記更新データについて計算したハッシュ値も受信し、前記更新データについて所定のデータサイズ毎にハッシュ値を計算することで、前記更新データ全体についてのハッシュ値を得ると、前記ハッシュ値と前記センタ装置より送信されたハッシュ値とを比較して、前記更新データの完全性を検証する車載通信の更新データ検証方法。

Images