(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-09-09
(45)【発行日】2022-09-20
(54)【発明の名称】車両搭載機器アップグレード方法および関連機器
(51)【国際特許分類】
H04L 9/32 20060101AFI20220912BHJP
G06F 21/57 20130101ALI20220912BHJP
G06F 21/64 20130101ALI20220912BHJP
G06F 8/65 20180101ALI20220912BHJP
B60R 16/02 20060101ALI20220912BHJP
【FI】
H04L9/32 200B
H04L9/32 200A
G06F21/57 320
G06F21/64
G06F8/65
B60R16/02 660U
(21)【出願番号】P 2020523294
(86)(22)【出願日】2017-10-24
(86)【国際出願番号】 SG2017050530
(87)【国際公開番号】W WO2019083440
(87)【国際公開日】2019-05-02
【審査請求日】2020-06-03
【前置審査】
(73)【特許権者】
【識別番号】517307072
【氏名又は名称】ホアウェイ インターナショナル ピーティーイー. リミテッド
(74)【代理人】
【識別番号】100110364
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100133569
【氏名又は名称】野村 進
(72)【発明者】
【氏名】▲楊▼ ▲艶▼江
(72)【発明者】
【氏名】魏 卓
(72)【発明者】
【氏名】林 孝盈
(72)【発明者】
【氏名】李 ▲鉄▼岩
(72)【発明者】
【氏名】沈 ▲駿▼▲強▼
【審査官】中里 裕正
(56)【参考文献】
【文献】特開2015-079440(JP,A)
【文献】特開2002-144983(JP,A)
【文献】特開2003-202931(JP,A)
【文献】特開2017-017616(JP,A)
【文献】国際公開第2010/024379(WO,A1)
【文献】米国特許出願公開第2016/0344705(US,A1)
【文献】中国特許出願公開第106528125(CN,A)
(58)【調査した分野】(Int.Cl.,DB名)
H04L 9/32
G06F 21/57
G06F 21/64
G06F 8/65
B60R 16/02
(57)【特許請求の範囲】
【請求項1】
車両搭載システムに適用される、車両搭載機器アップグレード方法であって、前記車両搭載システムが車両搭載制御装置と1つまたは複数の更新の対象である車両搭載機器とを含み、前記方法が、
前記車両搭載制御装置が、車両搭載アップグレードパッケージを取得するステップであって、前記車両搭載アップグレードパッケージが複数のアップグレードファイルを含み、各アップグレードファイルが少なくとも1つの前記
車両搭載機器をアップグレードするために使用される、ステップと、
前記車両搭載制御装置が、前記複数のアップグレードファイルに対してセキュリティ検証を行うステップと、
前記車両搭載制御装置が、ターゲットアップグレードファイルを使用してアップグレードされるべきターゲット車両搭載機器に前記ターゲットアップグレードファイルを送信するステップであって、前記ターゲットアップグレードファイルが、前記セキュリティ検証が成功したアップグレードファイルである、ステップと
を含
み、
前記車両搭載制御装置が、ターゲットアップグレードファイルを使用してアップグレードされるべきであるターゲットアップグレード対象車両搭載機器に前記ターゲットアップグレードファイルを送信する前記ステップが、
前記車両搭載制御装置が、前記ターゲットアップグレードファイルを複数のアップグレードサブファイルに分割するステップと、
前記車両搭載制御装置が、事前設定アルゴリズムを使用して前記複数のアップグレードサブファイルから複数の相互関連データブロックを生成し、第2の鍵を使用して前記複数のデータブロックの第1のメッセージ認証コードMACを生成するステップであって、前記第2の鍵が対称アルゴリズム鍵である、ステップと、
前記車両搭載制御装置が前記ターゲットアップグレード対象車両搭載機器に、前記第1のMACを搬送する前記複数のデータブロックを順次に送信するステップと
を含む、
車両搭載機器アップグレード方法。
【請求項2】
前記車両搭載アップグレードパッケージが第1のデジタル署名を含み、前記車両搭載制御装置が、前記複数のアップグレードファイルに対してセキュリティ検証を行う前記ステップが、
前記車両搭載制御装置が、前記第1のデジタル署名を使用して前記複数のアップグレードファイルに対してデジタル署名検証を行うステップ
を含む、請求項1に記載の方法。
【請求項3】
前記方法が、
前記車両搭載制御装置が、アップグレードサーバに識別認証情報を送信するステップと、
前記識別認証情報が前記アップグレードサーバによって認証された場合、前記車両搭載制御装置と前記アップグレードサーバとの間にセキュアなチャネルを確立するステップと
をさらに含み、
前記車両搭載制御装置が、車両搭載アップグレードパッケージを取得する前記ステップが、
前記車両搭載制御装置が、前記セキュアなチャネルを介して前記アップグレードサーバから前記車両搭載アップグレードパッケージを取得するステップ
を含む、請求項2に記載の方法。
【請求項4】
前記車両搭載アップグレードパッケージが第1の鍵を使用して暗号化され、前記第1の鍵が対称鍵であり、前記方法が、前記車両搭載制御装置が、鍵サーバから前記第1の鍵を取得するステップ、をさらに含み、
前記車両搭載制御装置が、前記第1のデジタル署名を使用して前記複数のアップグレードファイルに対してデジタル署名検証を行う前記ステップの後に、前記方法が、
前記車両搭載制御装置が、前記デジタル署名検証が成功した場合、前記第1の鍵を使用して前記複数のアップグレードファイルを解読するステップ
を含む、請求項2に記載の方法。
【請求項5】
前記方法が、
前記車両搭載制御装置が、第3の鍵を使用して前記複数のアップグレードサブファイルの各々を暗号化するステップ
をさらに含み、
前記車両搭載制御装置が、事前設定アルゴリズムを使用して前記複数のアップグレードサブファイルから複数の相互関連データブロックを生成する前記ステップが、
前記車両搭載制御装置が前記事前設定アルゴリズムを使用して、前記第3の鍵を使用して暗号化された前記複数のアップグレードサブファイルから前記複数の相互関連データブロックを生成するステップ
を含む、請求項
1から4のいずれか一項に記載の方法。
【請求項6】
車両搭載システムに適用される、車両搭載機器アップグレード方法であって、前記車両搭載システムが車両搭載制御装置と1つまたは複数の更新の対象である車両搭載機器とを含み、前記方法が、
前記車両搭載制御装置が、車両搭載アップグレードパッケージを取得するステップであって、前記車両搭載アップグレードパッケージが複数のアップグレードファイルを含み、各アップグレードファイルが少なくとも1つの前記車両搭載機器をアップグレードするために使用される、ステップと、
前記車両搭載制御装置が、前記複数のアップグレードファイルに対してセキュリティ検証を行うステップと、
前記車両搭載制御装置が、ターゲットアップグレードファイルを使用してアップグレードされるべきターゲット車両搭載機器に前記ターゲットアップグレードファイルを送信するステップであって、前記ターゲットアップグレードファイルが、前記セキュリティ検証が成功したアップグレードファイルである、ステップと
を含み、
前記ターゲットアップグレードファイルが複数のアップグレードサブファイルを含み、事前設定アルゴリズムを使用して前記複数のアップグレードサブファイルから複数の相互関連データブロックが生成され、前記複数のアップグレードサブファイルが、第4の鍵を使用して生成された前記複数のデータブロックの第2のデジタル署名を搬送し、前記第4の鍵が非対称鍵であり、
前記車両搭載制御装置が、前記複数のアップグレードファイルに対してセキュリティ検証を行う前記ステップが、
前記車両搭載制御装置が、前記複数のデータブロックの前記第2のデジタル署名を検査するステップ
を含み、
前記車両搭載制御装置が、ターゲットアップグレードファイルを使用してアップグレードされるべきであるターゲット車両搭載機器に前記ターゲットアップグレードファイルを送信する前記ステップが、
前記車両搭載制御装置が、第5の鍵を使用して前記複数のデータブロックの第2のMACを生成するステップであって、前記第5の鍵が対称アルゴリズム鍵である、ステップと、
前記車両搭載制御装置が前記ターゲットアップグレード対象車両搭載機器に、前記第2のMACを搬送する前記複数のデータブロックを順次に送信するステップと
を含む、
車両搭載機器アップグレード方法。
【請求項7】
前記事前設定アルゴリズムが、Hash Chainアルゴリズム、Hash Treeアルゴリズム、およびBloom Filterアルゴリズムのいずれか1つを含む、請求項
1から
6のいずれか一項に記載の方法。
【請求項8】
前記方法が、
前記車両搭載制御装置が、前記ターゲットアップグレード対象車両搭載機器にターゲットデータブロックを再送するステップであって、前記ターゲットデータブロックが、前記複数のデータブロック内の前記ターゲットアップグレード対象車両搭載機器でその検証が失敗したデータブロックである、ステップ
をさらに含む、請求項
1から
7のいずれか一項に記載の方法。
【請求項9】
インテリジェント車両であって、前記インテリジェント車両が車両搭載制御装置と少なくとも1つのアップグレード対象車両搭載機器とを含み、
前記車両搭載機器が、車両搭載アップグレードパッケージを取得し、前記車両搭載アップグレードパッケージ内の複数のアップグレードファイルに対してセキュリティ検証を行い、ターゲットアップグレードファイルを使用してアップグレードされるべきであるターゲットアップグレード対象車両搭載機器に前記ターゲットアップグレードファイルを送信し、各アップグレードファイルが少なくとも1つのアップグレード対象車両搭載機器をアップグレードするために使用され、前記ターゲットアップグレードファイルが、前記複数のアップグレードファイル内のその検証が成功したアップグレードファイルである、ように構成され、
前記車両搭載制御装置が、
前記ターゲットアップグレードファイルを複数のアップグレードサブファイルに分割し、事前設定アルゴリズムを使用して複数の相互関連データブロックを生成し、第2の鍵を使用して前記複数のデータブロックの第1のメッセージ認証コードMACを生成し、前記ターゲットアップグレード対象車両搭載機器に、前記第1のMACを搬送する前記複数のデータブロックを順次に送信し、前記第2の鍵が対称アルゴリズム鍵である、
ように特に構成され、
前記アップグレード対象車両搭載機器が、前記車両搭載制御装置によって送信された前記ターゲットアップグレードファイルを受信し、前記ターゲットアップグレードファイルを使用してセキュアなアップグレードを行い、前記アップグレード対象車両搭載機器が前記ターゲットアップグレード対象車両搭載機器である、ように構成さ
れ、
前記アップグレード対象車両搭載機器が、
前記第1のMACを搬送する、前記車両搭載制御装置によって送信された前記複数のデータブロックを順次に受信し、前記第2の鍵を使用して前記事前設定アルゴリズムに基づいて前記複数のデータブロックに対する検証を順次に行い、前記複数のデータブロックすべてが検証されると、前記複数の順次に検証されたデータブロックをアップグレードのために結合する、
ように特に構成される、
インテリジェント車両。
【請求項10】
前記車両搭載制御装置が、
第1のデジタル署名を使用して前記複数のアップグレードファイルに対してデジタル署名検証を行う
ように特に構成される、請求項
9に記載のインテリジェント車両。
【請求項11】
前記車両搭載制御装置が、
アップグレードサーバに識別認証情報を送信し、前記識別認証情報が前記アップグレードサーバによって認証された場合、前記車両搭載制御装置と前記アップグレードサーバとの間にセキュアなチャネルを確立し、前記セキュアなチャネルを介して前記アップグレードサーバから前記車両搭載アップグレードパッケージを取得する、
ように特に構成されるか、または
前記車両搭載アップグレードパッケージが第1の鍵を使用して暗号化され、前記第1の鍵が対称鍵であり、前記車両搭載制御装置が、
前記第1の鍵を鍵サーバから取得し、前記第1のデジタル署名を使用して前記複数のアップグレードファイルに対して行われたデジタル署名検証が成功した後、前記第1の鍵を使用して前記複数のアップグレードファイルを解読する、
ように特に構成される、請求項
10に記載のインテリジェント車両。
【請求項12】
車両搭載システムに適用される、車両搭載機器アップグレード装置であって、前記車両搭載システムが車両搭載制御装置と1つまたは複数の更新の対象である車両搭載機器とを含み、前記方法が、
アップグレードサーバから車両搭載アップグレードパッケージを取得するように構成されたアップグレードパッケージ取得部であって、前記車両搭載アップグレードパッケージが複数のアップグレードファイルを含み、各アップグレードファイルが少なくとも1つのアップグレード対象車両搭載機器をアップグレードするために使用される、アップグレードパッケージ取得部と、
前記複数のアップグレードファイルに対してセキュリティ検証を行うように構成された、アップグレード管理部と、
ターゲットアップグレードファイルを使用してアップグレードされるべきターゲットアップグレード対象車両搭載機器に前記ターゲットアップグレードファイルを送信するように構成されたアップグレード伝送部であって、前記ターゲットアップグレードファイルが、前記複数のアップグレードファイル内のそのセキュリティ検証が成功したアップグレードファイルである、アップグレード伝送部と
を含
み、
前記アップグレード伝送部が、
前記ターゲットアップグレードファイルを複数のアップグレードサブファイルに分割し、事前設定アルゴリズムを使用して前記複数のアップグレードサブファイルから複数の相互関連データブロックを生成し、第2の鍵を使用して前記複数のデータブロックの第1のメッセージ認証コードMACを生成し、前記第2の鍵が対称アルゴリズム鍵であり、前記ターゲットアップグレード対象車両搭載機器に、前記第1のMACを搬送する前記複数のデータブロックを順次に送信する
ように特に構成される、
車両搭載機器アップグレード装置。
【請求項13】
前記車両搭載アップグレードパッケージが第1のデジタル署名を含み、前記アップグレード管理部が、前記第1のデジタル署名を使用して前記複数のアップグレードファイルに対してデジタル署名検証を行うように特に構成され、
前記装置が、
前記アップグレードサーバに識別認証情報を送信するように構成された、識別認証部と、
前記識別認証情報が前記アップグレードサーバによって認証された場合、前記車両搭載制御装置と前記アップグレードサーバとの間にセキュアなチャネルを確立する、ように構成された、チャネル確立部と
をさらに含み、
前記アップグレードパッケージ取得部が、前記セキュアなチャネルを介して前記アップグレードサーバから前記車両搭載アップグレードパッケージを取得するように特に構成される、請求項
12に記載の装置。
【発明の詳細な説明】
【技術分野】
【0001】
本出願は、車両搭載技術の分野に関し、特に、車両搭載機器アップグレード方法および関連機器に関する。
【背景技術】
【0002】
将来は、各車両が車両のインターネット上のネットワークになり、コンピュータや携帯電話などのウェブ接続された機器と実質的に同じになる。北米の車両リコールの60%から70%がファームウェア/ソフトウェア問題によって引き起こされていると推定される。したがって、車両搭載機器のファームウェア/ソフトウェアのアップグレードは不可欠な措置である。従来のアップグレード対象車両搭載機器車両は、ファームウェア/ソフトウェアアップグレードのために回収される。そのような方法にはコストが高くサイクルが長いという短所がある。
【0003】
したがって、将来の車両搭載機器では、今日コンピュータや携帯電話に対して行われるリモートアップグレードと全く同様に、無線(Over-The-Air、OTA)技術を使用してより柔軟なリモートアップグレードが実施される必要がある。車両搭載機器のリモートファームウェア/ソフトウェアアップグレードは多くの利益をもたらし得る。例えば、これは、重要なファームウェア/ソフトウェアのbugsを迅速に修正するのに役立ち、車両安全性を改善し、全耐用期間にわたって車両に適時に新しい機能や機構を付加する。したがって、このOTA方式では、車両を回収せずにファームウェア/ソフトウェアアップグレードを実施することができる。これにより、車両の製造者または販売者の多くのコストを削減するとともに、車両所有者に利便性をもたらすことができる。
【0004】
しかしながら、アップグレード対象車両搭載機器のリモートアップグレード中には、一部の更新の対象である車両搭載機器に計算能力の限界や記憶空間の限界などの問題があるので、更新の対象である車両搭載機器のアップグレードの効率が比較的低く、車両搭載システム全体のアップグレードに影響を及ぼすことさえある。したがって、どのようにして車両搭載機器のセキュアで効率的なファームウェア/ソフトウェアアップグレードを保証するかが喫緊の解決を要する問題である。
【発明の概要】
【課題を解決するための手段】
【0005】
本発明の実施形態は、車両搭載機器のセキュアで効率的なファームウェア/ソフトウェアアップグレードを実施できないという問題を解決する、車両搭載機器アップグレード方法および関連機器を提供する。
【0006】
第1の態様によれば、本発明の一実施形態は車両搭載機器アップグレード方法を提供し、本車両搭載機器アップグレード方法は、
車両搭載制御装置が、車両搭載アップグレードパッケージを取得するステップであって、車両搭載アップグレードパッケージが複数のアップグレードファイルを含み、各アップグレードファイルが少なくとも1つのアップグレード対象車両搭載機器をアップグレードするために使用される、ステップと、車両搭載制御装置が、複数のアップグレードファイルに対してセキュリティ検証を行うステップと、車両搭載制御装置が、ターゲットアップグレードファイルを使用してアップグレードされるべきターゲットアップグレード対象車両搭載機器にターゲットアップグレードファイルを送信するステップであって、ターゲットアップグレードファイルが、複数のアップグレードファイル内のそのセキュリティ検証が成功したアップグレードファイルである、ステップと
を含む。本発明の本実施形態によれば、車両搭載制御装置側で、車両搭載機器をアップグレードするために必要な車両搭載アップグレードパッケージに対してセキュリティ検証処理が行われて、異なるアップグレード能力を有する更新の対象である車両搭載機器がセキュリティ検証プロセスに関与するのを防止し、それによって、車両搭載機器が車両搭載アップグレードパッケージを使用してセキュアかつ効率的にアップグレードされることが保証される。
【0007】
1つの可能な実施態様では、車両搭載アップグレードパッケージは第1のデジタル署名を含み、車両搭載制御装置が、複数のアップグレードファイルに対してセキュリティ検証を行うステップは、車両搭載制御装置が、第1のデジタル署名を使用して複数のアップグレードファイルに対してデジタル署名検証を行うステップ、を含む。言い換えると、車両搭載アップグレードパッケージはデジタル署名を使用して検証され、それによって、車両搭載制御装置によって車両搭載機器の外部から取得された車両搭載アップグレードパッケージの妥当性が保証される。
【0008】
1つの可能な実施態様では、本方法は、車両搭載制御装置が、アップグレードサーバに識別認証情報を送信するステップと、識別認証情報がアップグレードサーバによって認証された場合、車両搭載制御装置とアップグレードサーバとの間にセキュアなチャネルを確立するステップと、をさらに含み、車両搭載制御装置が、アップグレードサーバから車両搭載アップグレードパッケージを取得するステップは、車両搭載制御装置が、セキュアなチャネルを介してアップグレードサーバから車両搭載アップグレードパッケージを取得するステップ、を含む。言い換えると、伝送プロセスでの車両搭載アップグレードパッケージの機密性を保証するために、車両搭載制御装置とアップグレードサーバとの間にセキュアなチャネルが確立される。この場合、車両搭載アップグレードパッケージはさらに暗号化されなくてもよい。
【0009】
1つの可能な実施態様では、車両搭載アップグレードパッケージは第1の鍵を使用して暗号化され、第1の鍵は対称鍵であり、本方法は、車両搭載制御装置が、鍵サーバから第1の鍵を取得するステップ、をさらに含み、車両搭載制御装置が、第1のデジタル署名を使用して複数のアップグレードファイルに対してデジタル署名検証を行うステップの後に、本方法は、車両搭載制御装置が、デジタル署名検証が成功した場合、第1の鍵を使用して複数のアップグレードファイルを解読するステップ、を含む。言い換えると、車両搭載アップグレードパッケージは暗号化され、暗号鍵が専用鍵サーバに格納され、それによって、伝送プロセスでの車両搭載アップグレードパッケージの機密性が効果的に保証される。
【0010】
1つの可能な実施態様では、車両搭載制御装置が、ターゲットアップグレードファイルを使用してアップグレードされるべきであるターゲットアップグレード対象車両搭載機器にターゲットアップグレードファイルを送信するステップは、車両搭載制御装置が、ターゲットアップグレードファイルを複数のアップグレードサブファイルに分割するステップと、車両搭載制御装置が、事前設定アルゴリズムを使用して複数のアップグレードサブファイルから複数の相互関連データブロックを生成し、第2の鍵を使用して複数のデータブロックの第1のメッセージ認証コードMACを生成するステップであって、第2の鍵が対称アルゴリズム鍵である、ステップと、車両搭載制御装置がターゲットアップグレード対象車両搭載機器に、第1のMACを搬送する複数のデータブロックを順次に送信するステップと、を含む。言い換えると、車両搭載機器間での車両搭載アップグレードパッケージの伝送中に、事前設定アルゴリズムを使用してアップグレードファイルが複数の関連データブロックに分割され、それらの関連データブロックに対してMAC処理が行われるので、車両搭載制御装置は完全なアップグレードファイルを、別々に伝送することができ、それに対する妥当性検証を別々に行うことができる複数のデータブロックに分割する。加えて、複数のデータブロックが関連付けられているので、セキュリティ問題のあるデータブロックを、関連したアルゴリズムを使用して迅速に特定することもできる。したがって、能力が比較的弱いアップグレード対象車両搭載機器の単位時間あたりの計算作業負荷および計算の複雑さが減少する。アップグレードファイル伝送誤りが発生した後、誤り部分を可能な限り迅速に見つけることができるので、アップグレードファイル全体ではなく誤り部分のみが再送を要求される。このようにして、車両搭載機器のセキュアで効率的なアップグレードがさらに保証される。
【0011】
1つの可能な実施態様では、本方法は、車両搭載制御装置が、第3の鍵を使用して複数のアップグレードサブファイルの各々を暗号化するステップ、をさらに含み、車両搭載制御装置が、事前設定アルゴリズムを使用して複数のアップグレードサブファイルから複数の相互関連データブロックを生成するステップは、車両搭載制御装置が事前設定アルゴリズムを使用して、第3の鍵を使用して暗号化された複数のアップグレードサブファイルから複数の相互関連データブロックを生成するステップ、を含む。車両搭載アップグレードパッケージの妥当性が保証されると同時に車両搭載アップグレードパッケージの機密性がさらに保証され、それによって、車両搭載アップグレードパッケージが権限のない者によって取得されることが防止される。
【0012】
1つの可能な実施態様では、ターゲットアップグレードファイルが複数のアップグレードサブファイルを含み、複数の相互関連データブロックが事前設定アルゴリズムを使用して複数のアップグレードサブファイルから生成され、複数のアップグレードサブファイルは、第4の鍵を使用して生成された複数のデータブロックの第2のデジタル署名を搬送し、第4の鍵は非対称鍵であり、車両搭載制御装置が、複数のアップグレードファイルに対してセキュリティ検証を行うステップは、車両搭載制御装置が、複数のデータブロックの第2のデジタル署名を検査するステップ、を含み、車両搭載制御装置が、ターゲットアップグレードファイルを使用してアップグレードされるべきであるターゲットアップグレード対象車両搭載機器にターゲットアップグレードファイルを送信するステップは、車両搭載制御装置が、第5の鍵を使用して複数のデータブロックの第2のMACを生成するステップであって、第5の鍵が対称アルゴリズム鍵である、ステップと、車両搭載制御装置がターゲットアップグレード対象車両搭載機器に、第2のMACを搬送する複数のデータブロックを順次に送信するステップと、を含む。言い換えると、車両搭載アップグレードパッケージのブロック伝送および署名がアップグレード開発者側で実施され得る。すなわち、車両搭載制御装置によって取得される前に、事前設定アルゴリズムを使用した分割によってデータブロックが取得され、署名される。この場合、車両搭載機器は、データブロックの妥当性をまず検査する必要があり、次いで妥当と検査されたデータブロックに対してMAC処理を行う。このようにして、車両内伝送プロセスでの車両搭載アップグレードファイルの妥当性が保証されると同時に、アップグレード対象車両搭載機器の計算作業負荷および計算の複雑さが減少する。したがって、車両搭載機器はセキュアかつ効率的にアップグレードされる。
【0013】
1つの可能な実施態様では、事前設定アルゴリズムは、Hash Chainアルゴリズム、Hash Treeアルゴリズム、および Bloom Filterアルゴリズムのいずれか1つを含む。事前設定アルゴリズムは、前述のアルゴリズムのハッシュ関数を使用して、ターゲットアップグレードファイルを複数の相互関連データブロックに分割する。このようにして、MAC処理中に、MAC処理は複数のデータブロックのうちの1つに対してのみ行われ、他の関連データブロックはハッシュ値を使用して相互関連性を検査され得る。
【0014】
1つの可能な実施態様では、本方法は、車両搭載制御装置が、ターゲットアップグレード対象車両搭載機器にターゲットデータブロックを再送するステップであって、ターゲットデータブロックが、複数のデータブロック内のターゲットアップグレード対象車両搭載機器でその検証が失敗したデータブロックである、ステップ、をさらに含む。関連ブロックの伝送に基づき、その検証が失敗したデータブロックを迅速に特定することができ、そのような伝送誤りが発生した場合、アップグレードファイル全体ではなく対応するデータブロックのみが再度要求されさえすればよく、それによって、オーバーヘッドが削減され、アップグレード効率が改善され、アップグレードセキュリティが保証される。
【0015】
第2の態様によれば、本発明の一実施形態は、車両搭載制御装置と少なくとも1つのアップグレード対象車両搭載機器とを含み得る、インテリジェント車両であって、
車両搭載機器が、車両搭載アップグレードパッケージを取得し、車両搭載アップグレードパッケージ内の複数のアップグレードファイルに対してセキュリティ検証を行い、ターゲットアップグレードファイルを使用してアップグレードされるべきであるターゲットアップグレード対象車両搭載機器にターゲットアップグレードファイルを送信し、各アップグレードファイルが少なくとも1つのアップグレード対象車両搭載機器をアップグレードするために使用され、ターゲットアップグレードファイルが、複数のアップグレードファイル内のその検証が成功したアップグレードファイルである、ように構成され、
アップグレード対象車両搭載機器が、車両搭載制御装置によって送信されたターゲットアップグレードファイルを受信し、ターゲットアップグレードファイルを使用してセキュアなアップグレードを行い、アップグレード対象車両搭載機器がターゲットアップグレード対象車両搭載機器である、ように構成される、
インテリジェント車両を提供する。
【0016】
1つの可能な実施態様では、車両搭載制御装置は、第1のデジタル署名を使用して複数のアップグレードファイルに対してデジタル署名検証を行うように特に構成される。言い換えると、本発明の本実施形態のインテリジェント車両の車両搭載制御装置は、車両の外部から取得される車両搭載アップグレードパッケージ内の複数のアップグレードファイルの妥当性を検査する必要がある。
【0017】
1つの可能な実施態様では、車両搭載制御装置は、
アップグレードサーバに識別認証情報を送信し、識別認証情報がアップグレードサーバによって認証された場合、車両搭載制御装置とアップグレードサーバとの間にセキュアなチャネルを確立し、セキュアなチャネルを介してアップグレードサーバから車両搭載アップグレードパッケージを取得する、ように特に構成されるか、または車両搭載アップグレードパッケージは第1の鍵を使用して暗号化され、第1の鍵は対称鍵であり、車両搭載制御装置は、第1の鍵を鍵サーバから取得し、第1のデジタル署名を使用して複数のアップグレードファイルに対して行われたデジタル署名検証が成功した後、第1の鍵を使用して複数のアップグレードファイルを解読する、ように特に構成される。言い換えると、本発明の本実施形態のインテリジェント車両の車両搭載制御装置は、車両搭載アップグレードパッケージを取得するプロセスのセキュリティを保証するために、サーバ端へのセキュアなチャネルを確立し得る。
【0018】
1つの可能な実施態様では、車両搭載制御装置は、ターゲットアップグレードファイルを複数のアップグレードサブファイルに分割し、事前設定アルゴリズムを使用して複数の相互関連データブロックを生成し、第2の鍵を使用して複数のデータブロックの第1のメッセージ認証コードMACを生成し、ターゲットアップグレード対象車両搭載機器に、第1のMACを搬送する複数のデータブロックを順次に送信し、第2の鍵が対称アルゴリズム鍵である、ように特に構成され、
アップグレード対象車両搭載機器は、第1のMACを搬送する、車両搭載制御装置によって送信された複数のデータブロックを順次に受信し、第2の鍵を使用して事前設定アルゴリズムに基づいて複数のデータブロックに対する検証を順次に行い、複数のデータブロックすべてが検証されると、それら複数の順次に検証されたデータブロックをアップグレードのために結合する、ように特に構成される。
【0019】
言い換えると、車両の外部から取得された車両搭載アップグレードパッケージの妥当性を検証した後、本発明の本実施形態のインテリジェント車両の車両搭載制御装置は、車両内伝送中のアップグレードファイルの妥当性を保証するために、アップグレードファイルをブロックに分割し、車両内でMAC処理を行う。加えて、アップグレード対象車両搭載機器がアップグレードファイルのブロックを受信および検査することができるので、誤りを迅速に特定することができる。さらに、MAC検査の計算の複雑さが比較的低い。したがって、車両内のアップグレード能力が比較的弱いアップグレード対象車両搭載機器にとって検査およびアップグレードが比較的容易であることを保証できる。このようにして、車両アップグレードの効率およびセキュリティが保証される。
【0020】
1つの可能な実施態様では、車両搭載制御装置は、
第3の鍵を使用して複数のアップグレードサブファイルの各々を暗号化し、事前設定アルゴリズムを使用して、第3の鍵を使用して暗号化された複数のアップグレードサブファイルから複数の相互関連データブロックを生成する、
ように特に構成され、
アップグレード対象車両搭載機器は、複数のデータブロックすべてが検証されると、第3の鍵を使用してそれら複数の順次に検証されたデータブロックの各々を解読し、第3の鍵を使用して解読された複数のデータブロックをアップグレードのために結合する、ように特に構成される。
【0021】
言い換えると、本発明の本実施形態のインテリジェント車両の車両搭載制御装置では、アップグレードファイルの機密性が車両内でのアップグレードファイルの伝送中の暗号化によってさらに保証される。
【0022】
1つの可能な実施態様では、ターゲットアップグレードファイルが複数のアップグレードサブファイルを含み、事前設定アルゴリズムを使用して複数のアップグレードサブファイルから複数の相互関連データブロックが生成され、複数のアップグレードサブファイルは、第4の鍵を使用して生成された複数のデータブロックの第2のデジタル署名を搬送し、第4の鍵は非対称鍵であり、
車両搭載制御装置は、複数のデータブロックの第2のデジタル署名を検査し、第5の鍵を使用して複数のデータブロックの第2のMACを生成し、ターゲットアップグレード対象車両搭載機器に、第2のMACを搬送する複数のデータブロックを順次に送信し、第5の鍵が対称アルゴリズム鍵である、ように特に構成され、
アップグレード対象車両搭載機器は、第2のMACを搬送する、車両搭載制御装置によって送信された複数のデータブロックを順次に受信し、第5の鍵を使用して事前設定アルゴリズムに基づいて複数のデータブロックに対する検証を順次に行い、複数のデータブロックすべてが検証されると、それら複数の順次に検証されたデータブロックをアップグレードのために結合する、ように特に構成される。
【0023】
言い換えると、車両の外部から取得された、分割および署名されたアップグレードファイルの妥当性を検証した後、本発明の本実施形態のインテリジェント車両の車両搭載制御装置は、車両内伝送中のアップグレードファイルの妥当性を保証するために、アップグレードファイルをブロックに分割し、車両内でMAC処理を行う。加えて、アップグレード対象車両搭載機器がアップグレードファイルのブロックを受信および検査することができるので、誤りを迅速に特定することができる。さらに、MAC検査の計算の複雑さが比較的低い。したがって、車両内のアップグレード能力が比較的弱いアップグレード対象車両搭載機器にとって検査およびアップグレードが比較的容易であることを保証できる。このようにして、車両アップグレードの効率およびセキュリティが保証される。
【0024】
第3の態様によれば、本発明の一実施形態は車両搭載機器アップグレード方法を提供し、本車両搭載機器アップグレード方法は、
ターゲットアップグレード対象車両搭載機器が、車両搭載制御装置によって送信されたターゲットアップグレードファイルを受信するステップであって、ターゲットアップグレードファイルが、車両搭載制御装置によって行われたそのセキュリティ検証が成功した、少なくともターゲットアップグレード対象車両搭載機器をアップグレードするために使用されるアップグレードファイルである、ステップと、ターゲットアップグレード対象車両搭載機器が、ターゲットアップグレードファイルを使用してセキュアなアップグレードを行うステップと
を含み得る。本発明の本実施形態では、ターゲットアップグレード対象車両搭載機器は、そのセキュリティ検証処理が車両搭載制御装置側ですでに行われたアップグレードファイルを受信し、異なるアップグレード能力を有する更新の対象である車両搭載機器がセキュリティ検証プロセスに関与するのを防止するために、アップグレードファイルを使用して機器アップグレードを行い、それによって、アップグレード対象車両搭載機器が車両搭載アップグレードパッケージを使用してセキュアかつ効率的にアップグレードされることが保証される。
【0025】
1つの可能な実施態様では、ターゲットアップグレード対象車両搭載機器が、ターゲットアップグレードファイルを使用してセキュアなアップグレードを行うステップは、ターゲットアップグレード対象車両搭載機器が、A/Bシステム更新アップグレードモードを使用し、ターゲットアップグレードファイルを使用してセキュアなアップグレードを行うステップであって、アップグレード対象車両搭載機器が、そのリソース記憶能力および/もしくは処理能力が事前設定値を超える第1のアップグレード対象車両搭載機器、または事前に指定された第1のアップグレード対象車両搭載機器である、ステップ、を含む。能力が比較的強いアップグレード対象車両搭載機器では、A/Bシステム更新アップグレードモードがアップグレードに使用され得る。
【0026】
1つの可能な実施態様では、ターゲットアップグレードファイルは複数のアップグレードサブファイルを含み、ターゲットアップグレード対象車両搭載機器が、車両搭載制御装置によって送信されたターゲットアップグレードファイルを受信するステップは、ターゲットアップグレード対象車両搭載機器が、第1のMACを搬送する、車両搭載制御装置によって送信された複数のデータブロックを順次に受信するステップであって、複数のデータブロックが、事前設定アルゴリズムを使用して複数のアップグレードサブファイルから生成された複数の相互関連データブロックであり、第1のMACが第2の鍵を使用して生成された複数のデータブロックのメッセージ認証コードであり、第2の鍵が対称鍵である、ステップ、を含み、ターゲットアップグレード対象車両搭載機器が、ターゲットアップグレードファイルを使用してセキュアなアップグレードを行うステップは、ターゲットアップグレード対象車両搭載機器が、第2の鍵を使用して事前設定アルゴリズムに基づいて複数のデータブロックに対する検証を順次に行うステップと、複数のデータブロックすべてが検証されると、ターゲットアップグレード対象車両搭載機器が、順次に検証された複数のデータブロックをアップグレードのために結合するステップと、を含む。言い換えると、車両搭載機器間での車両搭載アップグレードパッケージの伝送中に、事前設定アルゴリズムを使用してアップグレードファイルが複数の関連データブロックに分割され、それらの関連データブロックに対してMAC処理が行われるので、車両搭載制御装置は完全なアップグレードファイルを、別々に伝送することができ、それに対する妥当性検証を別々に行うことができる複数のデータブロックに分割する。加えて、複数のデータブロックが関連付けられているので、セキュリティ問題のあるデータブロックを、関連したアルゴリズムを使用して迅速に特定することもできる。したがって、能力が比較的弱いアップグレード対象車両搭載機器の単位時間あたりの計算作業負荷および計算の複雑さが減少する。アップグレードファイル伝送誤りが発生した後、誤り部分を可能な限り迅速に見つけることができるので、アップグレードファイル全体ではなく誤り部分のみが再送を要求される。このようにして、車両搭載機器のセキュアで効率的なアップグレードがさらに保証される。
【0027】
1つの可能な実施態様では、複数のアップグレードサブファイルは第3の鍵を使用して暗号化され、複数のデータブロックすべてが検証されると、ターゲットアップグレード対象車両搭載機器が、順次に検証された複数のデータブロックをアップグレードのために結合するステップは、複数のデータブロックすべてが検証されると、ターゲットアップグレード対象車両搭載機器が、第3の鍵を使用して複数の順次に検証されたデータブロックの各々を解読し、第3の鍵を使用して解読された複数のデータブロックをアップグレードのために結合するステップ、を含む。車両搭載アップグレードパッケージの妥当性が保証されると同時に車両搭載アップグレードパッケージの機密性がさらに保証され、それによって、車両搭載アップグレードパッケージが権限のない者によって取得されることが防止される。
【0028】
1つの可能な実施態様では、ターゲットアップグレードファイルは複数のアップグレードサブファイルを含み、ターゲットアップグレード対象車両搭載機器が、車両搭載制御装置によって送信されたターゲットアップグレードファイルを受信するステップは、ターゲットアップグレード対象車両搭載機器が、第2のMACを搬送する、車両搭載制御装置によって送信された複数のデータブロックを順次に受信するステップであって、複数のデータブロックが、事前設定アルゴリズムを使用して複数のアップグレードサブファイルから生成された複数の相互関連データブロックであり、第2のMACが第5の鍵を使用して生成された複数のデータブロックのメッセージ認証コードであり、第5の鍵が対称鍵である、ステップ、を含み、ターゲットアップグレード対象車両搭載機器が、ターゲットアップグレードファイルを使用してセキュアなアップグレードを行うステップは、ターゲットアップグレード対象車両搭載機器が、第5の鍵を使用して事前設定アルゴリズムに基づいて複数のデータブロックに対する検証を順次に行うステップと、複数のデータブロックすべてが検証されると、ターゲットアップグレード対象車両搭載機器が、順次に検証された複数のデータブロックをアップグレードのために結合するステップと、を含む。言い換えると、車両搭載アップグレードパッケージのブロック伝送および署名がアップグレード開発者側で実施され得る。すなわち、車両搭載制御装置によって取得される前に、事前設定アルゴリズムを使用した分割によってデータブロックが取得され、署名される。この場合、車両搭載機器は、データブロックの妥当性をまず検査する必要があり、次いで妥当と検査されたデータブロックに対してMAC処理を行う。このようにして、車両内伝送プロセスでの車両搭載アップグレードファイルの妥当性が保証されると同時に、アップグレード対象車両搭載機器の計算作業負荷および計算の複雑さが減少する。したがって、車両搭載機器はセキュアかつ効率的にアップグレードされる。
【0029】
1つの可能な実施態様では、本方法は、ターゲットアップグレード対象車両搭載機器が、車両搭載制御装置からターゲットデータブロックを再取得するステップであって、ターゲットデータブロックが、複数のデータブロック内のターゲットアップグレード対象車両搭載機器でその検証が失敗したデータブロックである、ステップ、をさらに含む。関連ブロックの伝送に基づき、その検証が失敗したデータブロックを迅速に特定することができ、そのような伝送誤りが発生した場合、アップグレードファイル全体ではなく対応するデータブロックのみが再度要求されさえすればよく、それによって、オーバーヘッドが削減され、アップグレード効率が改善され、アップグレードセキュリティが保証される。
【0030】
第4の態様によれば、本出願は、車両搭載機器アップグレード装置を提供する。本車両搭載機器アップグレード装置は、前述の車両搭載機器アップグレード方法実施形態のいずれか1つの方法を実施する機能を有する。この機能は、ハードウェアを使用するか、またはハードウェアが対応するソフトウェアを実行することによって実施され得る。ハードウェアまたはソフトウェアは機能に対応する1つまたは複数のモジュールを含む。
【0031】
第5の態様によれば、本出願は、アップグレード対象車両搭載装置を提供する。装置は、前述の車両搭載機器アップグレード方法実施形態のいずれか1つの方法を実施する機能を有する。この機能は、ハードウェアを使用するか、またはハードウェアが対応するソフトウェアを実行することによって実施され得る。ハードウェアまたはソフトウェアは機能に対応する1つまたは複数のモジュールを含む。
【0032】
第6の態様によれば、本出願は、車両搭載制御装置を提供する。本車両搭載制御装置はプロセッサを含み、プロセッサは、第1の態様で提供される車両搭載機器アップグレード方法における対応する機能を行う際に車両搭載制御装置を支援するように構成される。車両搭載制御装置はメモリをさらに含んでいてもよく、メモリは、プロセッサに結合され、車両搭載制御装置に必要なプログラム命令およびデータを格納する、ように構成される。車両搭載制御装置は、車両搭載制御装置と別の機器または通信ネットワークとの間の通信のための通信インターフェースをさらに含み得る。
【0033】
第7の態様によれば、本出願は、ターゲットアップグレード対象車両搭載機器を提供する。ターゲットアップグレード対象車両搭載機器はプロセッサを含み、プロセッサは、第3の態様で提供される車両搭載機器アップグレード方法における対応する機能を行う際にターゲットアップグレード対象車両搭載機器を支援するように構成される。ターゲットアップグレード対象車両搭載機器はメモリをさらに含んでいてもよく、メモリは、プロセッサに結合され、ターゲットアップグレード対象車両搭載機器に必要なプログラム命令およびデータを格納する、ように構成される。ターゲットアップグレード対象車両搭載機器は、ターゲットアップグレード対象車両搭載機器と別の機器または通信ネットワークとの間の通信のための通信インターフェースをさらに含み得る。
【0034】
第8の態様によれば、本出願は、第6の態様で提供される車両搭載制御装置によって使用されるコンピュータソフトウェア命令を格納するように構成された、コンピュータ記憶媒体を提供する。コンピュータソフトウェア命令は、前述の態様を実施するように設計されたプログラムを含む。
【0035】
第9の態様によれば、本出願は、第7の態様で提供されるターゲットアップグレード対象車両搭載機器によって使用されるコンピュータソフトウェア命令を格納するように構成された、コンピュータ記憶媒体を提供する。コンピュータソフトウェア命令は、前述の態様を実施するように設計されたプログラムを含む。
【0036】
第10の態様によれば、本発明の一実施形態はコンピュータプログラムを提供する。本コンピュータプログラムは命令を含み、本コンピュータプログラムがコンピュータによって実行されると、コンピュータは、第1の態様の任意の可能な実施態様における車両搭載機器アップグレード方法のステップを行うことができるようになる。
【0037】
第11の態様によれば、本発明の一実施形態はコンピュータプログラムを提供する。本コンピュータプログラムは命令を含み、本コンピュータプログラムがコンピュータによって実行されると、コンピュータは、第3の態様の任意の可能な実施態様における車両搭載機器アップグレード方法のステップを行うことができるようになる。
【0038】
第12の態様によれば、本出願はチップシステムを提供する。本チップシステムは、前述の態様に関連した機能を実施する際、例えば、前述の方法においてデータおよび/または情報を受信または処理する際に、ターゲットアップグレード対象車両搭載機器または車両搭載制御装置を支援するように構成された、プロセッサを含む。1つの可能な設計では、本チップシステムはメモリをさらに含み、メモリは、ターゲットアップグレード対象車両搭載機器または車両搭載制御装置に必要なプログラム命令およびデータを格納するように構成される。本チップシステムはチップを含み得るか、またはチップと別のディスクリートデバイスとを含み得る。
【図面の簡単な説明】
【0039】
【
図1】本発明の一実施形態による車両搭載システムアップグレードアーキテクチャの図である。
【
図2】本発明の一実施形態によるOTA Orchestratorの概略的構造図である。
【
図3】本発明の一実施形態によるアップグレード対象車両搭載機器の概略的構造図である。
【
図4】本発明の一実施形態による別の車両搭載システムアップグレードアーキテクチャの図である。
【
図5】本発明の一実施形態による車両搭載機器アップグレード方法の概略的流れ図である。
【
図6】本発明の一実施形態による車両搭載アップグレード装置の概略的構造図である。
【
図7】本発明の一実施形態によるアップグレード対象車両搭載装置の概略的構造図である。
【
図8】本発明の一実施形態による機器の概略的構造図である。
【
図9】本発明の一実施形態によるインテリジェント車両の概略的構造図である。
【発明を実施するための形態】
【0040】
以下で、本発明の実施形態における添付の図面を参照して本発明の実施形態を説明する。
【0041】
本出願の明細書、特許請求の範囲および添付の図面において、「第1」、「第2」、「第3」、「第4」などの用語は、異なる対象を区別するためのものであり、特定の順序を示すものではない。加えて、「including」および「having」およびそれらの任意の他の変形は、非排他的包含を対象として含むことが意図されている。例えば、一連のステップもしくはユニットを含むプロセス、方法、システム、製品、もしくは機器は、記載されたステップもしくはユニットに限定されず、任意選択で、記載されていないステップもしくはユニットをさらに含み、または任意選択で、そのプロセス、方法、製品、もしくは機器の別の固有のステップもしくはユニットをさらに含む。
【0042】
本明細書で「実施形態」という場合それは、その実施形態を参照して説明される特定の特性、構造、または特徴が、本出願の少なくとも1つの実施形態に含まれ得ることを意味する。本明細書の様々な箇所に示されている語句は、必ずしも同じ実施形態を指しているとは限らず、別の実施形態を排除する独立した、または任意選択の実施形態ではない。本明細書に記載される実施形態が別の実施形態と組み合わされ得ることが、当業者には明示的にも暗黙的にも理解される。
【0043】
本明細書で使用される「構成要素」、「モジュール」、「システム」などの用語は、コンピュータに関連したエンティティ、ハードウェア、ファームウェア、ハードウェアとソフトウェアの組み合わせ、ソフトウェア、または実行されているソフトウェアを指示するのに使用される。例えば、構成要素は、プロセッサ上で実行されるプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行スレッド、プログラム、および/またはコンピュータであり得るが、これに限定されない。各図に示されるように、コンピューティングデバイスとコンピューティングデバイス上で実行されるアプリケーションはどちらも構成要素であり得る。プロセスおよび/または実行スレッド内に1つまたは複数の構成要素があってもよく、構成要素は、1つのコンピュータ上に位置していてもよく、かつ/または少なくとも2台のコンピュータ間で分散されてもよい。加えて、これらの構成要素は、様々なデータ構造を格納する様々なコンピュータ可読媒体から実行されてもよい。例えば、構成要素は、例えば、1つまたは複数のデータパケット(例えば、ローカルシステムで、分散システムで、かつ/または信号を使用して他のシステムとやりとりするインターネットなどのネットワークを介して別の構成要素とやりとりする2つの構成要素からのデータ)を有する信号に基づき、ローカルプロセスおよび/またはリモートプロセスを使用して通信し得る。
【0044】
まず、当業者の理解を容易にするために、本出願におけるいくつかの用語を説明する。
【0045】
(1).無線技術(Over-the-air Technology、OTA)とは、移動通信においてエアインターフェースを介してリモートファームウェアまたはソフトウェアアップグレードを行うための技術である。
【0046】
(2).車両搭載情報サービス(Telematics)とは、電気通信(Telecommunications)と情報科学(Informatics)の複合語であり、自動車、航空機、船舶、または列車などのビークルに組み込まれたコンピュータシステム、無線通信技術、衛星航法装置、またはテキストや音声などの情報を交換するためのインターネット技術を使用して情報を提供するサービスシステムとして文字通り定義され得る。手短には、このサービスシステムは、無線ネットワークを使用してビークルをインターネットに接続し、ビークル所有者に、運転および生活に必要な様々な情報を提供する。
【0047】
(3).電子制御ユニット(Electronic Control Unit、ECU)とは、使用の観点から見た車両固有のマイクロコントローラである。一般のコンピュータと同様に、電子制御ユニットは、マイクロプロセッサ(CPU)、メモリ(ROM、RAM)、入力/出力インターフェース(I/O)、アナログ・デジタル変換器(A/D)、整形器、およびドライブなどの大規模集積回路を含む。
【0048】
(4).車両制御ユニット(Vehicle control unit、VCU)は、統合電気自動車コントローラとも呼ばれ得る。VCUは、電気自動車パワートレインの全体のコントローラであり、エンジン、駆動モータ、ギアボックス、および動力バッテリなどの部品の動作を調整する責任を負い、車両の電力性能、安全性能、および経済効率を改善する機能を有する。VCUは、統合電気自動車制御システムの中核部であり、電気自動車のモータの始動、動作、前進および後退、速度、ならびに停止を制御し、電気自動車の別の電気機器を制御するように構成されたコアコントローラである。純粋な電気自動車の制御システムの中核部として、VCUは、データ交換、安全管理、運転者意図解釈、および電力ストリーム管理などのタスクの責任を負う。VCUは、モータ制御システムの信号、アクセルペダルの信号、ブレーキペダルの信号、および別の部品の信号を収集し、包括的な解析を行った後で運転者の運転意図を判断し、応答し、下位層部品のコントローラの動作を監視する。VCUは、通常の車両運転、バッテリ電力の制動および再生、ネットワーク管理、故障診断および処理、ならびに車両状況監視などの機能で重要な役割を果たす。
【0049】
(5).コントローラエリアネットワーク(Controller Area Network、CAN)バスとは、世界で最も広く適用されているフィールドバスである。CANバスの高信頼性と強力な誤り検出能力は多くの注目を集めており、したがってCANバスは、車両コンピュータ制御システム、ならびにハッシュ周囲温度、強い電磁放射、および激しい振動を伴う産業環境に広く適用されている。CANバスは、広く適用されているフィールドバスであり、工業計測および制御ならびに工業自動化などの分野で大きな応用展望を有する。CANは、シリアル通信バスネットワークである。CANバスには、データ通信における信頼性、リアルタイム、および柔軟性という利点がある。透過的な設計および柔軟な実行のために、CANバスの構造は、ISO/OSI標準モデルに従って物理層とデータリンク層(論理リンク制御LLC副層と媒体アクセス制御MAC副層とを含む)とに分割される。
【0050】
(6).メッセージ認証コード(Message Authentication Code、MAC)とは、信号源のための符号化機能である。MACは、ダイジェストアルゴリズムと類似しているが、計算時に鍵を使用する必要があり、したがってMACは、使用される鍵とそのMACが計算される必要がある情報の両方に依存する。実際には、MACは通常、ダイジェストアルゴリズムに基づく構築によって取得される。
【0051】
(7).鍵導出アルゴリズム(Key Derivation Function、KDF)とは、暗号化および解読時に使用される鍵導出関数である。鍵導出関数の機能は、共有秘密ビットシリアルポートから鍵データを導出することである。鍵折衝時に、鍵導出関数は、鍵交換において取得された秘密ビットストリングに作用して、必要なセッション鍵またはさらなる暗号化に必要な鍵データを生成する。
【0052】
(8).公開鍵暗号(非対称暗号):公開鍵暗号は非対称暗号とも呼ばれる。非対称鍵アルゴリズムとは、暗号化アルゴリズムの暗号鍵がその暗号化アルゴリズムの解読鍵と異なるか、または暗号化アルゴリズムの一方の鍵を他方の鍵を使用して推定できないことを意味する。公開鍵暗号を有するユーザは暗号鍵と解読鍵を有し、暗号鍵を使用して解読鍵を取得することができない。加えて、暗号鍵は公開である。公開鍵暗号はこの原理に基づいて、秘密鍵として支援情報(トラップドア情報)を使用するように設計される。このタイプの暗号のセキュリティは、このタイプの暗号が基礎とする問題の計算の複雑さに依存する。現在、一般的な公開鍵暗号には、RSA公開鍵暗号、ElGamal公開鍵暗号、および楕円曲線暗号が含まれる。
【0053】
(9).対称暗号:対称鍵暗号化は専用鍵暗号化とも呼ばれる。具体的には、データ送信側とデータ受信側とが必ず同じ鍵を使用して平文に対する暗号化操作および解読操作を行う。すなわち、暗号鍵を解読鍵から推定することができ、逆もまた同様である。ほとんどの対称アルゴリズムでは、暗号鍵は解読鍵と同じである。これらのアルゴリズムは、秘密鍵アルゴリズムまたは単一鍵アルゴリズムとも呼ばれ、送信側と受信側とがセキュアな通信の前に鍵に同意することを必要とする。対称アルゴリズムのセキュリティは鍵に依存し、鍵の漏出は、誰でもメッセージを暗号化および解読することができることを意味する。鍵は、通信が機密性を必要とするならば秘密に保持される必要がある。
【0054】
対称鍵アルゴリズムおよび非対称鍵アルゴリズムに関する前述の説明から次のことが分かる。同じ鍵が対称鍵暗号化と対称鍵解読の両方に使用されるか、または暗号鍵から解読鍵を推定するのが容易である。加えて、対称鍵アルゴリズムには、暗号化処理が容易、暗号化および解読が速い、鍵が比較的短い、開発の歴史が長いなどの特徴があり、非対称鍵アルゴリズムには、暗号化および解読が遅い、鍵が長い、開発の歴史が短いなどの特徴がある。
【0055】
(10).トランスポート層セキュリティ(Transport Layer Security、TLS)プロトコルが、機密性と、2つのアプリケーションプログラム間のデータ整合性を提供するために使用される。プロトコルは2つの層、TLSレコード(TLS Record)プロトコルとTLSハンドシェイク(TLS Handshake)プロトコルとを含む。トランスポート層セキュリティ(TLS)プロトコルは、機密性と、2つの通信アプリケーションプログラム間のデータ整合性を提供するために使用される。
【0056】
まず、本出願で解決される必要がある技術的問題および適用シナリオを示す。先行技術では、従来の車両搭載機器がファームウェア/ソフトウェアアップグレードのために回収される。具体的には、車両が、その具体的な実施態様が以下の解決策1および解決策2である以下の方法を使用してファームウェア/ソフトウェアをアップグレードするために、自動車修理工場や4Sストアなどの指定場所に回収される。
【0057】
解決策1:ジェイタグ(Joint Test Action Group、JTAG)インターフェースまたはバックグラウンドデバッグモード(Background Debug Mode、BDM)インターフェースを使用して、オンライン書込みを行うか、または車両搭載機器が分解された後で書込みを行う。具体的には、方法1および方法2が含まれ得る。
【0058】
方法1:まず、パーソナルコンピュータ(personal computer、PC)を使用してプログラマにアップグレード対象ソフトウェアをダウンロードし、プログラマをプログラミング機器に接続し、プログラミング機器に車両電子制御システムのプリント回路基板(Printed Circuit Board、PCB)を配置してプリント回路基板をダウンロードインターフェースと位置合わせし、最後にプログラマの電源を入れてソフトウェアを書き込む。
【0059】
方法2:PCおよびシングルチップマイクロコンピュータのプログラムダウンロードデータラインを車両電子制御システムのPCBに直列に接続し、PCを操作してシングルチップマイクロコンピュータにプログラムを直接ダウンロードする。
【0060】
前述の方法1および方法2には、熟練者を要し、コストが高く、操作が非常に不便であるという問題がある。
【0061】
解決策2:CANバスの車載式故障診断(On-Board Diagnostic、OBD)に基づいてフラッシュ書込みを行う。
【0062】
ステップ1.車両電子システムの通常のアプリケーションプログラム動作状態からリフレッシュモードに入る(割込または診断をトリガする)。
【0063】
ステップ2.車両電子コントローラチップのメモリを検査し、メモリに正しいアプリケーションプログラムが格納されているかどうかを判断する。
【0064】
ステップ3.メモリに正しいアプリケーションプログラムがない場合、診断機器からアプリケーションプログラムソフトウェアをダウンロードし、CANバスを介してアプリケーションプログラムソフトウェアを伝送し、Flash内のアプリケーションプログラムをリフレッシュする(リフレッシュモジュールがソフトウェア書込みを開始および案内するように構成される)。
【0065】
解決策2には、熟練者を要し、サイクルが長いという問題がある。
【0066】
前述の解決策1および解決策2に加えて、現在、リモートアップグレードが一部の車両に実施されている。しかしながら、リモートアップグレードは一般に、主として計算能力が比較的強く記憶空間が比較的大きい車両搭載機器に実施される。言い換えると、現在、計算能力が比較的弱いかまたは記憶空間が比較的小さい車両搭載機器に、セキュアで効率的なファームウェア/ソフトウェアアップグレード方法を提供することができない。したがって、車両搭載システム内の様々なアップグレード能力を有する更新の対象である車両搭載機器のためにセキュアで効率的なファームウェア/ソフトウェアアップグレードをどのように実施するかが、本出願で実際に解決される必要がある技術的問題である。
【0067】
本発明の実施形態の理解を容易にするために、前述の説明に基づき、以下でまず、本発明の実施形態に適用される車両搭載アップグレードシステムアーキテクチャを説明する。
図1は、本発明の一実施形態による車両搭載システムアップグレードアーキテクチャ(略してアーキテクチャ1)の図である。本出願で提供される車両搭載機器アップグレード方法はこのシステムアーキテクチャに適用され得る。システムアーキテクチャは、アップグレードサーバと、車両搭載制御装置と、HMI(ヒューマンマシンインターフェース)、BMS(バッテリ管理システム)、ECU1、およびECU2などの複数の
更新の対象である車両搭載機器とを含む。車両搭載制御装置は、複数の
更新の対象である車両搭載機器のアップグレードプロセスを管理および支援するように構成されたTelematics ユニットおよびOTAオーケストレータ(OTA Orchestrator)ユニットを含み得る。このシステムアーキテクチャでは、車両搭載機器のリモートアップグレードは、アップグレードパッケージのリリース、アップグレードパッケージの取得、アップグレードパッケージの車両内伝送、ならびにアップグレードおよび確認、の基本プロセスを含み得る。
【0068】
アップグレードサーバは、開発者から暗号化されていない車両搭載アップグレードパッケージを取得するように構成される。
【0069】
車両搭載制御装置内のTelematics は、外部との通信の責任を負う。本出願では、テレマティクスは、車両搭載アップグレードパッケージを取得するタスクを実施し、車両搭載アップグレードパッケージを伝送するいくつかの動作を実施する(車両搭載アップグレードパッケージをOTA Orchestratorに送信する)ための、アップグレードサーバおよび鍵サーバとの通信の責任を負う。
【0070】
車両搭載制御装置内のOTA Orchestratorは、車両内の
更新の対象である車両搭載機器との通信の責任を負う。本出願では、車両搭載アップグレードパッケージは、Telematicsおよび管理ユニット/モジュールを通り、最終的にはターゲットアップグレード対象車両搭載機器に到達する。OTA Orchestratorの主機能は、車両搭載機器のアップグレードプロセスの管理および支援である。具体的には、OTA Orchestratorは以下の機能を持つ必要がある:鍵の配布および管理、OTAプロセス管理、大きな計算作業負荷を必要とする動作で能力の弱い別のアップグレード対象車両搭載機器を支援すること、例えば、アップグレードパッケージの整合性および信憑性を検証することや、Transcoding(コード変換)、ならびにアップグレードが失敗したときのロールバックのために、能力の弱い別のアップグレード対象車両搭載機器のバックアップノードの役割を果たすこと。OTA Orchestratorは論理エンティティであり、Telematics、Gateway、またはVCUなどの任意の強力なユニットまたはモジュール上に物理的に配置することができる。OTA Orchestratorの構造は
図2に示され得る。
図2は、本発明の一実施形態によるOTA Orchestratorの概略的構造図である。OTA Orchestratorは、プロセッサCPU、関連した揮発性メモリRAM、関連した不揮発性メモリROM、および鍵、例えば、車両搭載機器と共有される静的鍵を格納するように構成されたセキュアな記憶装置を含み得る。OTA Orchestratorは、OTA管理プログラムを格納するように構成されたメモリをさらに含み、OTA管理プログラムは、アップグレードプロセスを管理するために使用され、CAN busまたは別の車両内ネットワークを介して別の車両搭載機器と通信できるネットワークインターフェースをさらに含む。OTA OrchestratorがTelematics上で実施される場合、OTA Orchestratorは、ネットワークインターフェースが外部ネットワークと通信することをさらに必要とすることが理解できよう。すなわち、OTA Orchestratorは、車両搭載機器がリモートアップグレードを完了するのを支援し、別の車両搭載機器によって信頼されるように、比較的強力な計算能力と比較的大容量のリソースとを有する必要がある。論理アーキテクチャ分割に関して、OTA Orchestratorはアーキテクチャを、車両外通信部分と車両内通信部分とに分割する。車両内部分の機器は、公開鍵暗号操作ではなく、対称暗号操作を行いさえすればよい。
公開鍵暗号操作が行われる必要がある場合、
公開鍵暗号操作は、車両内のアップグレード対象機器の計算作業負荷および計算の複雑さを低減させるために、OTA Orchestratorに割り当てられる。
【0071】
更新の対象である車両搭載機器について、
更新の対象である車両搭載機器のいずれか1つの構成は
図3に示され得る。
図3は、本発明の一実施形態によるアップグレード対象車両搭載機器の概略的構造図である。アップグレード対象車両搭載機器は、マイクロコントローラ(Micro controller)と、CANコントローラ(CAN controller)と、送受信機(Transceiver)とを含み得る。アップグレード対象車両搭載機器は、送受信機Transceiverを使用してCAN busなどの車両内ネットワークと通信する。CAN controllerは、CANプロトコルを実施するように構成され、マイクロコントローラは、アップグレードの前後の関連した計算処理を実施するように構成される。例えば、マイクロコントローラは、本出願でアップグレード対象車両搭載機器によって行われる車両搭載機器アップグレード方法を実施し得る。前述の概略的構造図を参照すると、本出願では、ターゲットアップグレード対象車両搭載機器が、送受信機(Transceiver)を使用してCAN busなどの車両内ネットワークに基づいて、車両搭載制御装置によって送信されたターゲットアップグレードファイルを受信し、ターゲットアップグレードファイルおよびマイクロコントローラ(Micro Controller)を使用してセキュアなアップグレードを行う。より具体的な機能については、後続の実施形態におけるアップグレード対象車両搭載機器に関連した機能に関する説明を参照されたい。
【0072】
アップグレード対象車両搭載機器の概略的構造図から、CANバスは現在の車両で一般に使用されているが、CANバスは帯域幅に影響を及ぼすことが分かる。ゆえに、いくつかのアップグレードシナリオでは、車両搭載機器のファームウェア/ソフトウェアのリモートアップグレードで最大アップグレード効率を達成することができない。
【0073】
図4は、本発明の一実施形態による別の車両搭載システムアップグレードアーキテクチャ(略してアーキテクチャ2)の図である。
図1に示されているシステムアップグレードアーキテクチャとは異なり、この車両搭載システムアップグレードアーキテクチャは鍵サーバをさらに含む。
【0074】
アップグレードサーバは、開発者から、開発者によって暗号化された車両搭載アップグレードパッケージを取得するように構成される。
【0075】
鍵サーバは、車両搭載アップグレードパッケージが開発者によって暗号化されるときに、セキュアなチャネルを介して開発者から鍵を取得し、鍵を格納し、最後に鍵を車両搭載制御装置に提供する、ように構成される。
【0076】
車両搭載制御装置および複数の
更新の対象である車両搭載機器の具体的な機能などの他の態様については、
図1に対応する車両搭載システムアップグレードアーキテクチャ内の機能エンティティまたはユニットに関する説明を参照することが理解できよう。ここでは詳細を繰り返さない。
【0077】
本出願の車両搭載システムアップグレードアーキテクチャは開発者をさらに含み得ることがさらに理解できよう。アップグレードプログラム(ファームウェア/ソフトウェア)の開発および試験の後、開発者は車両搭載アップグレードパッケージをアップグレードサーバに配布する。配布された車両搭載アップグレードパッケージはデジタル署名を使用して署名される必要がある。任意選択で、デジタル署名を使用して署名される前に、車両搭載アップグレードパッケージはさらに暗号化されてもよい。車両搭載アップグレードパッケージが暗号化されない場合、アーキテクチャは
図1のシステムアーキテクチャであり、車両搭載アップグレードパッケージが暗号化される場合、アーキテクチャは
図2のシステムアーキテクチャである。対応する実施形態を以下の説明で詳述する。
【0078】
図1および
図4の車両搭載システムアップグレードアーキテクチャは、本発明の実施形態の実施態様の2つの例にすぎないことに留意されたい。本発明の実施形態の通信システムアーキテクチャは、前述のシステムアーキテクチャを含むがこれに限定されない。
【0079】
以下で、本出願で提供される車両搭載機器アップグレード方法の実施形態を使用して、本出願で示される技術的問題を具体的に分析および解決する。
【0080】
図5は、本発明の一実施形態による車両搭載機器アップグレード方法の概略的流れ図である。本方法は、
図1または
図4の車両搭載システムアップグレードアーキテクチャに適用され得る。
図5を参照して、以下で、車両搭載制御装置とターゲットアップグレード対象車両搭載機器との間のインタラクションの観点から本方法を説明する。本方法は、ステップS501からステップS505を含み得る。
【0081】
ステップS501.車両搭載制御装置が車両搭載アップグレードパッケージを取得する。
【0082】
ステップS502.車両搭載制御装置が複数のアップグレードファイルに対してセキュリティ検証を行う。
【0083】
ステップS503.車両搭載制御装置が、ターゲットアップグレードファイルを使用してアップグレードされるべきターゲットアップグレード対象車両搭載機器にターゲットアップグレードファイルを送信し、ターゲットアップグレードファイルが、複数のアップグレードファイル内のそのセキュリティ検証が成功したアップグレードファイルである。
【0084】
ステップS504.ターゲットアップグレード対象車両搭載機器が、車両搭載制御装置によって送信されたターゲットアップグレードファイルを受信し、ターゲットアップグレードファイルが、車両搭載制御装置によって行われたそのセキュリティ検証が成功した、アップグレード対象車両搭載機器をアップグレードするために使用されるアップグレードファイルである。
【0085】
ステップS505.ターゲットアップグレード対象車両搭載機器が、ターゲットアップグレードファイルを使用してセキュアなアップグレードを行う。
【0086】
具体的には、車両搭載アップグレードパッケージは複数のアップグレードファイルを含み、各アップグレードファイルは少なくとも1つのアップグレード対象車両搭載機器をアップグレードするために使用される。言い換えると、車両搭載システム内の1つのアップグレード対象車両搭載機器は1つまたは複数のアップグレードファイルに対応し得る。
【0087】
車両搭載制御装置がステップS501を行う前に、車両搭載アップグレードパッケージがリリースされる。一般に、アップグレードプログラムの開発および試験の後、車両搭載アップグレードパッケージ(ファームウェア/ソフトウェア)の開発者は、車両搭載アップグレードパッケージをアップグレードサーバに配布する。1つの可能な実施態様では、車両搭載アップグレードパッケージは第1のデジタル署名を含む。車両搭載アップグレードパッケージがMであり、バージョン情報がverである(例えば、プログラム名、新バージョン番号、および旧バージョン番号などのすべてのメタデータ(meta-data)情報)であると仮定する。本発明の本実施形態では、
図6に示されるように、車両搭載アップグレードパッケージのリリース時に、開発者がアップグレードパッケージにデジタル署名するか、またはアップグレードサーバがアップグレードパッケージにデジタル署名する、という2つのデジタル署名方法が提供され得る。
図6は、本発明の一実施形態による2つのタイプのデジタル署名の概略図である。ケース1およびケース2が含まれる。
【0088】
ケース1:σ=SignD(M||ver)は、開発者がM||verにデジタル署名することを示し、本出願の第1のデジタル署名の役割を果たす。
【0089】
ケース2:σ=SignS(M||ver)は、アップグレードサーバがM||verにデジタル署名することを示し、本出願の第1のデジタル署名の役割を果たす。
【0090】
前述の2つの署名方法で使用されるデジタル署名アルゴリズムは本出願では特に限定されない。任意選択で、情報を転送するために開発者とアップグレードサーバとの間にセキュアなチャネルが確立されてもよく、セキュアなチャネルはネットワークチャネルであり得るか、または書留郵便などの物理チャネルであり得る。結論として、車両搭載アップグレードパッケージがリリースされるときに、アップグレードサーバは、車両搭載アップグレードパッケージ[M,ver,σ]を更新し、更新されたかまたは新しい車両搭載アップグレードパッケージに関する情報を対外的にリリースする。
【0091】
本出願は、2つの車両搭載システムアップグレードアーキテクチャ、すなわち、
図1に示される鍵サーバなしのアーキテクチャ1と、
図4に示される鍵サーバを含むアーキテクチャ2とを提供する。
【0092】
アーキテクチャ1では、車両搭載アップグレードパッケージは暗号化されない。アップグレードサーバは、車両搭載制御装置の識別情報に対して認証を行い、認証の成功後に車両搭載制御装置へのセキュアなチャネルを確立し、セキュアなチャネルを介して車両搭載アップグレードパッケージを取得する必要がある。このプロセスは、車両搭載制御装置内のOTA OrchestratorがTelematicsユニットを使用してアップグレードサーバからアップグレードパッケージを取得するプロセスである。
【0093】
具体的には、車両搭載制御装置はアップグレードサーバに識別認証情報を送信する。識別認証情報がアップグレードサーバによって認証された場合、車両搭載制御装置とアップグレードサーバとの間にセキュアなチャネルが確立され、車両搭載制御装置は、セキュアなチャネルを介してアップグレードサーバから、アップグレードに必要な車両搭載アップグレードパッケージを取得する。
【0094】
1つの具体的な実施態様では、OTA Orchestratorがアップグレードサーバに問い合わせるか、またはアップグレードサーバがOTA Orchestratorに更新メッセージをプッシュする。アップグレードパッケージは具体的には、以下のステップで取得され得る。
【0095】
1.OTAオーケストレータOTA Orchestratorがターゲットアップグレード対象車両搭載機器の現行バージョン情報を取得する。この情報は、ターゲットアップグレード対象車両搭載機器に問い合わせることによって、またはOTAオーケストレータによって維持されるデータベースに問い合わせることによって取得され得る(OTA Orchestratorはすべての車両搭載機器のファームウェア/ソフトウェアの基本情報を維持していると仮定する)。
【0096】
2.OTA Orchestratorがアップグレードが必要かどうかを判断する。アップグレードが必要な場合、OTA Orchestratorはアップグレードを行うかどうかを車両所有者に確認することを選択し得る。車両所有者が同意した場合、アップグレードが開始する。
【0097】
3.OTA Orchestratorがアップグレードサーバに対する認証を開始し、アップグレードサーバへのセキュアなチャネルを確立し、セキュアなチャネルを介してデータパケットを送信する。
【0098】
4.OTA Orchestratorがアップグレードサーバに車両搭載機器の現行バージョン情報を報告し、アップグレードサーバが同意した場合、OTA Orchestratorがアップグレードパッケージ[M,ver,σ,{M’}]をダウンロードする。Mは、車両搭載アップグレードパッケージであり、verは、プログラム名、新バージョン番号、および対応する旧バージョン番号などのすべてのメタデータ(meta-data)情報を含む、バージョン情報を表し、σ=SignD(M||ver)またはσ=SignS(M||ver)は、第1のデジタル署名であり、M’は、ロールバックファイルを表し、{M’}は、M’が任意選択であり、ターゲットアップグレード対象車両搭載機器が能力の弱い機器であるときにのみ有効であることを示す。
【0099】
5.OTA Orchestratorは、第1のデジタル署名σの信憑性に対する検証を行い、検証が失敗した場合、OTA Orchestratorはアップグレードを断念する。任意選択で、必要な場合、OTA Orchestratorは、M’に対する検証も行う。M’もまたデジタル署名を搬送すると仮定する。
【0100】
アーキテクチャ2では、車両搭載アップグレードパッケージはアップグレードサーバで暗号化される。したがって、車両搭載制御装置とアップグレードサーバとの間に専用のセキュアなチャネルが確立されなくてもよい。加えて、車両搭載制御装置が第1の署名を使用して車両搭載アップグレードパッケージに対する検証を行った後、車両搭載アップグレードパッケージは第1の鍵を使用して解読される必要がさらにある。本実施形態では、アップグレードファイルは開発者によって暗号化される。開発者がアップグレードファイルを暗号化することのさらなる利点は、開発者がアップグレードサーバの信頼性を考慮しなくてもよいことである。したがって、アップグレードファイルの機密性がさらに保護される。
【0101】
具体的には、車両搭載アップグレードパッケージは第1の鍵を使用して暗号化される。第1の鍵は対称鍵である。車両搭載制御装置は第1の鍵を鍵サーバから取得する。車両搭載制御装置が、第1のデジタル署名を使用して複数のアップグレードファイルに対してデジタル署名検証を行った後、デジタル署名検証が成功した場合、車両搭載制御装置は、第1の鍵を使用して複数のアップグレードファイルを解読する。
【0102】
アップグレードプログラムの開発および試験の後、車両搭載アップグレードパッケージ(ファームウェア/ソフトウェア)の開発者はアップグレードサーバにアップグレードファイルを配布する。このプロセスは
図4に示されるアーキテクチャに対応している。アーキテクチャ1と異なり、このアーキテクチャは追加の鍵サーバを必要とする。
【0103】
アップグレードファイルはMであり、verは、プログラム名、新バージョン番号、および対応する旧バージョン番号などのすべてのメタデータ(meta-data)情報を含む、バージョン情報を表すと仮定する。開発者は、任意の鍵K(第1の鍵)を選択し、Kを使用してMを暗号化するので、C=E(K,M)が得られる。式中、E(K,.)は、Kに基づく暗号化、例えば、グループ暗号化を表す。
【0104】
上述のように、第1のデジタル署名では、2つのシナリオ、すなわち、開発者がアップグレードパッケージにデジタル署名するか、またはアップグレードサーバがアップグレードパッケージにデジタル署名する、がある。どちらの場合にも、開発者は、暗号化されたアップグレードファイルの鍵Kを、セキュアなチャネルを介して鍵サーバに送信する必要があり、暗号化されたアップグレードファイルを伝送するためのチャネルは保護を必要としない。開発者と鍵サーバとの間の秘密のチャネルは、多くの方法を使用して、例えばTLSを使用して確立され得る。これについては本出願では特に限定されない。
【0105】
1つの具体的な実施態様では、このプロセスは、OTA Orchestratorがアップグレードサーバからアップグレードパッケージを取得し、鍵サーバから、アップグレードソフトウェアを解読するための鍵を取得するプロセスである。具体的には、車両搭載機器のための新しいアップグレードパッケージがあることを知った後、OTA Orchestratorがこのプロセスを開始する。OTA Orchestratorがアップグレードサーバに問い合わせることによってメッセージを知り得るか、またはアップグレードサーバがOTA Orchestratorに情報をプッシュする。アップグレードパッケージは以下のステップで取得され得る。
【0106】
1.OTA Orchestratorがターゲットアップグレード対象車両搭載機器の現行バージョン情報を取得する。この情報は、ターゲットアップグレード対象車両搭載機器に問い合わせることによって、またはOTAオーケストレータによって維持されるデータベースに問い合わせることによって取得され得る(OTA Orchestratorはすべての車両搭載機器のファームウェア/ソフトウェアの基本情報を維持していると仮定する)。
【0107】
2.OTA Orchestratorがアップグレードが必要かどうかを判断する。アップグレードが必要な場合、OTA Orchestratorはアップグレードを行うかどうかを車両所有者に確認することを選択し得る。車両所有者が同意した場合、アップグレードが開始する。
【0108】
3.OTA Orchestratorがアップグレードサーバからアップグレードパッケージ[C,ver,σ,{C’}]をダウンロードする。C’は、デジタル署名を使用して署名された、アップグレードが失敗したときにロールバックに使用されるべき暗号化ファイルを表し、{C’}は、C’が任意選択であり、ターゲットアップグレード対象車両搭載機器が能力の弱い機器であるときにのみ有効であることを示すことに留意されたい。
【0109】
4.OTA Orchestratorは、σの信憑性に対する検証を行い(すなわち、第1のデジタル署名の信憑性に対する検証を行い)、検証が失敗した場合、OTA Orchestratorはアップグレードを断念する。必要な場合、OTA Orchestratorは、C’に対する検証も行う。
【0110】
5.OTA Orchestratorが鍵サーバに対する認証を開始し、鍵サーバへのセキュアなチャネルを確立し、セキュアなチャネルを介してアップグレードパッケージの解読鍵K(すなわち、第1の鍵)を取得する。必要な場合、OTA Orchestratorは、C’を解読するための解読鍵を取得する必要もある。
【0111】
6.OTA Orchestratorが、アップグレードファイルMを取得するためにKを使用してCを解読し、必要な場合、OTA Orchestratorは、M’(M’は、アップグレードが失敗したときのロールバックに使用される)を取得するためにC’を解読する必要もある。
【0112】
1つの可能な実施態様では、アップグレードファイルの機密性も保護される必要がある場合、アップグレードパッケージを取得した後、OTA Orchestratorは、Cを解読せず、Cをn個の部分:C1,C2,...,およびCnに分割し、次いで、C1,C2,...,およびCnを、Hash Chain、Hash Tree、およびBloom Filterに基づくものである後続の処理方法で使用する。OTA Orchestratorは、秘密のチャネルを介してターゲットアップグレード対象車両搭載機器に共有鍵Kを転送する必要もあるので、ターゲットアップグレード対象車両搭載機器は解読を行う。
【0113】
ステップS502で、車両搭載制御装置は、アップグレードサーバから取得された車両搭載アップグレードパッケージ内の複数のアップグレードファイルに対してセキュリティ検証を行う必要がある。1つの可能な実施態様では、車両搭載アップグレードパッケージは第1のデジタル署名を含み、車両搭載制御装置のOTA Orchestratorは、第1のデジタル署名を使用して複数のアップグレードファイルに対してデジタル署名検証を行う。具体的には、車両搭載制御装置が車両搭載アップグレードパッケージを取得した後、アップグレードパッケージがアップグレードのために対応するアップグレード対象車両搭載機器に直接送信される先行技術とは異なり、セキュリティ検証(例えば、信憑性検証)が車両搭載制御装置側で車両搭載アップグレードパッケージ内の複数のアップグレードファイルに対してまず行われ、そのセキュリティ検証が成功したアップグレードファイルが次いでコード変換(transcoding)を受け、コード変換されたアップグレードファイルがセキュアなアップグレードのために対応するアップグレード対象車両搭載機器に送信される。本出願のコード変換は、分割によって取得された複数のアップグレードサブファイルの各々に対して、アルゴリズム(Hash Chainアルゴリズム、Hash Treeアルゴリズム、またはBloom Filterアルゴリズム)を使用して、ハッシュ関連付け処理が行われ、車両内ネットワークに適用可能なセキュアなデータパッケージセグメント伝送をさらに実施するために、MAC処理が、ハッシュチェーン、ハッシュツリー、またはブルームフィルタ内の1つまたは複数のノードで行われることを意味することに留意されたい。このようにして、アップグレード対象車両搭載機器によって行われる必要がある大量のセキュリティ検証操作が減少する。言い換えると、単一のアップグレード対象車両搭載機器によって行われるセキュリティ検証中の計算作業負荷、計算の複雑さなどが減少する。
【0114】
ステップS503では、異なる更新の対象である車両搭載機器が、車両搭載アップグレードパッケージ内の一部のアップグレードファイルのみに対応し得る。したがって、車両搭載制御装置は、複数のアップグレードファイル内のそのセキュリティ検証が成功したターゲットアップグレードファイルを、ターゲットアップグレードファイルを使用してアップグレードされるべきターゲットアップグレード対象車両搭載機器に送信する必要がある。ターゲットアップグレードファイル内のアップグレードサブファイルのサイズおよびコンテンツは異なり得ることが理解できよう。
【0115】
1つの可能な実施態様では、車両搭載制御装置は、ターゲットアップグレードファイルを複数のアップグレードサブファイル(複数のセグメントとしても理解され得る)に分割し、事前設定アルゴリズムを使用して複数のアップグレードサブファイルから複数の相互関連データブロックを生成し、第2の鍵を使用して複数のデータブロックの第1のメッセージ認証コードMACを生成し、ターゲットアップグレード対象車両搭載機器に、第1のMACを搬送する複数のデータブロックを順次に送信する。第2の鍵は対称アルゴリズム鍵である。
【0116】
具体的には、車両搭載機器間での車両搭載アップグレードパッケージの伝送中に、車両搭載制御装置は、事前設定アルゴリズムを使用して、アップグレードファイルを複数の関連データブロックに分割し、関連データブロックに対してMAC処理を行うので、車両搭載制御装置は完全なアップグレードファイルを、別々に伝送することができ、それに対する妥当性検証を別々に行うことができる複数のデータブロックに分割する。加えて、複数のデータブロックが関連付けられているので、セキュリティ問題のあるデータブロックを、関連したアルゴリズムを使用して迅速に特定することもできる。事前設定アルゴリズムは、Hash Chainアルゴリズム、Hash Treeアルゴリズム、およびBloom Filterアルゴリズムのいずれか1つを含む。本出願では、車両搭載制御装置は、ターゲットアップグレードファイルをアップグレード対象車両搭載機器に一度に送信することを回避するために、ターゲットアップグレードファイルを複数のアップグレードサブファイルに分割するので、アップグレード対象車両搭載機器はアップグレードサブファイルを別々に受信および処理することができる。したがって、本出願の「順次に」は、「次々に」を含み得るか、または「別の複数のアップグレードサブファイルの後の複数のアップグレードサブファイル」、例えば、2つのアップグレードサブファイルをまず送信し、次いで別の2つのアップグレードサブファイルを送信するなどであることを指示し得るか、または1つのアップグレードサブファイルをまず送信し、次いで別の2つのアップグレードサブファイルを送信するなどであることを指示し得る。すなわち、車両搭載制御装置は、ターゲットアップグレードファイルを複数のアップグレードサブファイルに分割し、それらのアップグレードサブファイルをアップグレード対象車両搭載機器にバッチで送信しさえすればよい。ターゲットアップグレードファイルを分割し、アップグレードサブファイルをアップグレード対象車両搭載機器に順次に送信する具体的な方法は、本出願では特に限定されない。本出願では、車両搭載機器の能力が弱く、記憶リソースが不十分であり、車両内ネットワークの帯域幅が限られているという問題を解決するために、配置されるOTA Orchestratorは、車両搭載アップグレードパッケージをコ
ード変換(transcoding)することができる。OTA Orchestratorのコード変換機能により、車両搭載機器は公開鍵暗号操作を行う必要がなく、それによって車両搭載機器の作業負荷が低減する。したがって、能力が比較的弱いアップグレード対象車両搭載機器の単位時間あたりの計算作業負荷および計算の複雑さが減少する。加えて、アップグレードファイル伝送誤りが発生した後、誤り部分を可能な限り迅速に見つけることができるので、アップグレードファイル全体ではなく誤り部分のみが再送を要求される。このようにして、車両搭載機器のセキュアで効率的なアップグレードがさらに保証される。
【0117】
1つの可能な実施態様では、車両搭載制御装置は、ターゲットアップグレードファイルを複数のアップグレードサブファイルに分割し、複数のアップグレードサブファイルを(機密性を保証するために)暗号化し(信憑性を保証するために)コード変換し、暗号化されコード変換されたアップグレードサブファイルをターゲットアップグレード対象車両搭載機器に順次に送信する。具体的には、車両搭載制御装置は、第3の鍵を使用して複数のアップグレードサブファイルの各々を暗号化し、事前設定アルゴリズムを使用して、第3の鍵を使用して暗号化された複数のアップグレードサブファイルから複数の相互関連データブロックを生成し、ターゲットアップグレード対象車両搭載機器に、第1のMACを搬送する複数のデータブロックを順次に送信する。言い換えると、本発明の本実施形態は、車両搭載制御装置が、複数のアップグレードサブファイルの機密性を保証するために、コード変換の前に複数のアップグレードサブファイルを暗号化する必要があり、次いで暗号化されたアップグレードサブファイルをコード変換するという点で本発明の前述の実施形態と異なる。
【0118】
1つの可能な実施態様では、ターゲットアップグレードファイルは複数のアップグレードサブファイルを含み、事前設定アルゴリズムを使用して複数のアップグレードサブファイルから複数の相互関連データブロックが生成され、複数のアップグレードサブファイルは、第4の鍵を使用して生成された複数のデータブロックの第2のデジタル署名を搬送し、第4の鍵は非対称鍵であり、車両搭載制御装置は、複数のデータブロックの第2のデジタル署名を検査し、車両搭載制御装置は、第5の鍵を使用して複数のデータブロックの第2のMACを生成し、第5の鍵は対称アルゴリズム鍵であり、車両搭載制御装置は、ターゲットアップグレード対象車両搭載機器に、第2のMACを搬送する複数のデータブロックを順次に送信する。言い換えると、車両搭載アップグレードパッケージのブロック伝送および署名がアップグレード開発者側で実施され得る。すなわち、車両搭載制御装置によって取得される前に、事前設定アルゴリズムを使用した分割によってデータブロックが取得され、署名される。この場合、車両搭載機器は、データブロックの妥当性をまず検査する必要があり、次いで妥当と検査されたデータブロックに対してMAC処理を行う。MAC検査での計算作業負荷および計算の複雑さは、署名の場合のものよりはるかに小さい。したがって、車両内伝送プロセスでの車両搭載アップグレードファイルの妥当性が保証されると同時に、アップグレード対象車両搭載機器の計算作業負荷および計算の複雑さが減少し得る。したがって、車両搭載機器はセキュアかつ効率的にアップグレードされる。
【0119】
ステップS504では、ターゲットアップグレード対象車両搭載機器は、車両搭載制御装置によって送信されたターゲットアップグレードファイルを受信する。ターゲットアップグレードファイルは、車両搭載制御装置によって行われたそのセキュリティ検証が成功した、少なくともターゲットアップグレード対象車両搭載機器に使用されるアップグレードファイルである。具体的には、このプロセスは、車両搭載アップグレードパッケージの車両内のセキュアな伝送のプロセスである。
【0120】
ステップS505では、ターゲットアップグレード対象車両搭載機器は、ターゲットアップグレードファイルを使用してセキュアなアップグレードを行う。1つの可能な実施態様では、アップグレード対象車両搭載機器が、そのリソース記憶能力および/もしくは処理能力が事前設定値を超える第1のアップグレード対象車両搭載機器、または事前に指定された第1のアップグレード対象車両搭載機器、例えば、処理能力が比較的強いかもしくは記憶能力が比較的強い機器、または指定された機器である場合、A/Bシステム更新(A/B System Updates)アップグレードモードがターゲットアップグレード対象車両搭載機器に使用される。具体的には、ターゲットアップグレード対象車両搭載機器は領域Aおよび領域Bを有し、アップグレード対象プログラム(ファームウェアまたはソフトウェア)が領域Aで実行され、新しいアップグレードプログラムが領域Bに書き込まれ、プログラムは、アップグレードが完了した後に領域Bで実行される。これは、車両搭載アップグレードプロセスにおける旧バージョンシステムの通常の動作に影響しない。例えば、能力が強い機器または主要な機器はA/Bシステム更新アップグレード方法を使用し、能力が弱い機器は、アップグレードが失敗したときにロールバックを行うために、バックアップノードとしてOTA Orchestratorを使用する。アップグレードが成功したとき、車両搭載機器はアップグレードパッケージを削除し、OTA Orchestratorに通知する。OTA Orchestratorは、アップグレードパッケージを削除し、データベースを更新し、車両所有者に正常なアップグレードを通知する。あるいは、OTA Orchestratorは、アップグレードサーバに通知することを選択してもよい。加えて、OTA Orchestratorは、アップグレードが成功したことを証明するために、ターゲットアップグレード対象車両搭載機器にremote attestationを行うよう命令することをさらに選択してもよい。
【0121】
1つの可能な実施態様では、ターゲットアップグレード対象車両搭載機器は、第1のMACを搬送する、車両搭載制御装置によって送信された複数のデータブロックを順次に受信する。複数のデータブロックは、事前設定アルゴリズムを使用して複数のアップグレードサブファイルから生成された複数の相互関連データブロックであり、第1のMACは、第2の鍵を使用して生成された複数のデータブロックのメッセージ認証コードであり、第2の鍵は対称鍵である。言い換えると、第2の鍵は共有鍵である。したがって、ターゲットアップグレード対象機器と車両搭載制御装置との間で単純な対称鍵を使用して信憑性検証が行われさえすればよい。これにより、ターゲットアップグレード対象機器の計算作業負荷および計算の複雑さが低減される。このようにして、計算能力が比較的弱いかまたは記憶空間が比較的小さい「弱い」アップグレード対象車両搭載機器でさえも、セキュアで効率的なアップグレードが必要とし得る計算作業負荷が比較的小さく、計算の複雑さが比較的低くて済む。
【0122】
1つの可能な実施態様では、ターゲットアップグレード対象車両搭載機器は、第2の鍵を使用して事前設定アルゴリズムに基づいて複数のデータブロックに対する検証を順次に行い、複数のデータブロックすべてが検証されると、ターゲットアップグレード対象車両搭載機器は、順次に検証された複数のデータブロックをアップグレードのために結合する。具体的には、第2の鍵を使用して暗号化され、事前設定アルゴリズムを使用してコード変換され、車両搭載制御装置によって送信された複数のアップグレードサブファイルを受信した後、ターゲットアップグレード対象機器は、第2の鍵を使用して第1のMACを検査する必要があり、事前設定アルゴリズムを使用して生成された相互関連データブロックの特徴を使用して複数のデータブロックに対して関連値検査を行う。すべてのデータブロックが復号および検証された後、すなわち、すべてのデータブロックに対する検証が成功した後、ターゲットアップグレード対象機器は複数のアップグレードサブファイルをアップグレードのために完全なファイルへと結合する。
【0123】
1つの可能な実施態様では、複数のアップグレードサブファイルは第3の鍵を使用して暗号化され、複数のデータブロックすべてが検証されると、ターゲットアップグレード対象車両搭載機器は、第3の鍵を使用して複数の順次に検証されたデータブロックの各々を解読し、ターゲットアップグレード対象車両搭載機器は、第3の鍵を使用して解読された複数のデータブロックをアップグレードのために結合する。言い換えると、本発明の本実施形態は、ターゲットアップグレード対象車両搭載機器が、検証された複数のアップグレードサブファイルを解読する前に暗号化され、コード変換されたアップグレードサブファイルに対して検証を行う必要があり、解読が成功した後で複数のアップグレードサブファイルをアップグレードのために結合するという点で本発明の前述の実施形態と異なる。
【0124】
1つの可能な実施態様では、ターゲットアップグレードファイルは複数のアップグレードサブファイルを含み、ターゲットアップグレード対象車両搭載機器は、第2のMACを搬送する、車両搭載制御装置によって送信された複数のデータブロックを順次に受信する。複数のデータブロックは、事前設定アルゴリズムを使用して複数のアップグレードサブファイルから生成された複数の相互関連データブロックであり、第2のMACは第5の鍵を使用して生成された複数のデータブロックのメッセージ認証コードであり、第5の鍵は対称アルゴリズムである。ターゲットアップグレード対象車両搭載機器は、第5の鍵を使用して事前設定アルゴリズムに基づいて複数のデータブロックに対する検証を順次に行い、複数のデータブロックすべてが検証されると、ターゲットアップグレード対象車両搭載機器は、順次に検証された複数のデータブロックをアップグレードのために結合する。言い換えると、車両搭載アップグレードパッケージのブロック伝送および署名がアップグレード開発者側で実施され得る。すなわち、車両搭載制御装置によって取得される前に、事前設定アルゴリズムを使用した分割によってデータブロックが取得され、署名される。この場合、車両搭載機器は、データブロックの妥当性をまず検査する必要があり、次いで妥当と検査されたデータブロックに対してMAC処理を行う。MAC検査での計算作業負荷および計算の複雑さは、署名でのものよりはるかに小さい。したがって、車両内伝送プロセスでの車両搭載アップグレードファイルの妥当性が保証されると同時に、アップグレード対象車両搭載機器の計算作業負荷および計算の複雑さが減少し得る。したがって、車両搭載機器はセキュアかつ効率的にアップグレードされる。
【0125】
さらに、ターゲットアップグレード対象車両搭載機器がアップグレード操作を行うとき、ターゲットアップグレード対象車両搭載機器で複数のデータブロック内のターゲットデータブロックに対する検証が失敗した場合、車両搭載制御装置は、ターゲットアップグレード対象車両搭載機器にターゲットデータブロックを再送する。言い換えると、ターゲットアップグレード対象車両搭載機器は、車両搭載制御装置からターゲットデータブロックを再取得する。結合およびアップグレードは、すべてのデータブロックが検証されたときにのみ行われる。本発明の本実施形態では、ターゲットアップグレードファイルは複数のデータブロックに分割されるので、1つまたは複数のデータブロックに対する検証が失敗したときに、ターゲットアップグレードファイル全体ではなく1つまたは複数のデータブロックだけが再度ダウンロードされさえすればよく、それによって、オーバーヘッドが減少しアップグレード効率が向上する。
【0126】
以下で、車両搭載制御装置とターゲットアップグレード対象機器との間の信憑性検証、すなわち、車両搭載制御装置が事前設定アルゴリズムを使用して車両搭載アップグレードパッケージのターゲットアップグレードファイルをどのようにしてコード変換するかを説明する。
【0127】
1つの具体的な実施態様では、車両搭載アップグレードパッケージの信憑性を検証した後、OTA Orchestratorは、適時に、例えば、駐車した状態でこのプロセスを開始するか、またはOTA Orchestratorは、車両所有者にアップグレードを再度確認するよう要求することを選択し得る。OTA Orchestratorは、車両搭載アップグレードパッケージに対して分割およびコード変換処理を行い、コード変換されたアップグレードサブファイルをターゲットアップグレード対象車両搭載機器に順次に転送する。本出願は、3つの独立したコード変換方法、すなわち、Hash Chainベースの解決策、Hash Treeベースの解決策、およびBloom Filterベースの解決策を提供する。3つのコード変換方法に基づくアップグレードパッケージ車両内伝送プロセスを以下で説明する。まず、OTA Orchestratorはターゲットアップグレード対象車両搭載機器と鍵kを共有すると仮定する。共有kは静的であり得るか、またはOTA Orchestratorとターゲットアップグレード対象車両搭載機器とによって一時的に生成され得る。
【0128】
方法1:Hash Chainベースのコード変換方法
【0129】
1.OTA OrchestratorがアップグレードファイルMをn個の部分:M1,M2,...,およびMnに分割する。
【0130】
2.M1,M2,...,およびMnを使用して以下のようにHash Chainを形成し、式中、H(.)は、Cryptographic Hash Functionを表す。
hn=H(Mn)
hi=H(Mi,hi+1)
h2=H(M2,h3)
【0131】
3.OTA Orchestratorが共有鍵k(第2の鍵)を使用してv=MAC(k,M1||ver,h2)を計算する。式中、MACは、標準的なメッセージ認証コードMessage Authentication Code、すなわち、第1のMACである。
【0132】
4.第1の部分から開始して、OTA OrchestratorがMiをターゲットアップグレード対象車両搭載機器に順次に転送する。第1の部分では、OTA Orchestratorは、v,M1,ver,およびh2を転送する必要があり、残りの部分では、OTA OrchestratorはMiおよびhi+1のみを転送しさえすればよい。
【0133】
5.ターゲットアップグレード対象車両搭載機器が共有鍵kを使用してMiに対する検証を順次に行う。ある部分に対する検証が失敗した場合、ターゲットアップグレード対象車両搭載機器は再送を要求し得る。すべての部分を受信および検証した後、ターゲットアップグレード対象車両搭載機器はすべての部分を結合して完全なアップグレードファイルMにする。
【0134】
方法2:Hash Treeベースのコード変換方法
【0135】
1.OTA OrchestratorがアップグレードファイルMをn個の部分:M1,M2,...,およびMnに分割する。
【0136】
2.M1,M2,...,およびMnを使用してbinary treeを形成する。図に示されるように、葉ノードはデータを表し、各中間ノードは、hashを使用して中間ノードのサブノードの値に基づいて取得され得るルートノードの値を含み、例えば、h1=H(M1||ver||M2)、およびh5=H(h1||h2)である。
【0137】
3.OTA Orchestratorが共有鍵k(第2の鍵)を使用してルートノードの値を計算する。図に示されるように、例えば、v=MAC(k,h5||h6)、すなわち、第1のMACである。
【0138】
4.M1およびM2から開始して、OTA Orchestratorが2つの部分をターゲットアップグレード対象車両搭載機器にその都度転送する。最初の2つの部分では、OTA Orchestratorは、v,M1||ver,M2,h2およびh6を転送する必要があり、残りの部分では、OTA Orchestratorは、2つのデータ、および2つのデータに対応する補助検証データを転送する必要がある。図では、M1およびM2の補助検証データはh2およびh6であり、M3およびM4の補助検証データは、M3およびM4に対する検証を、h2を使用して行うことができるので、空欄であり、M5およびM6の補助検証データはh4であり、M7およびM8の補助検証データは空欄である。
【0139】
5.ターゲットアップグレード対象車両搭載機器が共有鍵kを使用して2つずつの部分に対する検証を行う。2つの部分に対する検証が失敗した場合、ターゲットアップグレード対象車両搭載機器は再送を要求し得る。すべての部分を受信および検証した後、ターゲットアップグレード対象車両搭載機器はすべての部分を結合して完全なアップグレードファイルMにする。
【0140】
方法3:Bloom Filterベースのコード変換方法
【0141】
Bloom Filterとは、データがセット内に存在するかどうかを判断するために使用される記憶効率のよいデータ構造である。一例は以下のとおりである。
【0142】
長さlの配列F(Bloom Filter)が設定され、各要素の値は0に初期設定される。t個のhash function、H1,H2,...,およびHtが選択される。各hash functionは、そのセットから{1,2,...,l}へのマッピングである。具体的には、セットの各要素は{1,2,...,l}内の任意の値にマップされる。セット内の要素eをBloom Filterに追加するための方法は:Hi(e)を計算するステップ、およびF内のHi(e)によって指示される位置を1に変更するステップである。Fに基づいて、セット内に要素e’が存在するかどうかを判断するための方法は、e’のすべてのhash値を計算するステップ、およびF内のすべてのhash値によって指示されるすべての位置が1であるときにのみ、セット内に要素が存在すると判断するステップ、である。
【0143】
Bloom Filterを使用してセット内に要素が存在するかどうかを判断することには以下の特徴がある。
【0144】
F内の要素の1つのhash値によって指示される位置が0である場合、その要素はセット内にないと判断でき、要素のすべてのhash値によって指示される位置が1である場合、要素はセット内にあると判断できるが、false positiveが存在し、false positiveの確率は
【数1】
であり、式中、nは、Bloom Filterに追加される要素の数である。
【0145】
要素を追加するか、または要素がセット内にあるかどうかを判断するための時間は定数である。
【0146】
Bloom Filterコード変換に基づくアップグレードパッケージ車両内伝送プロセスは以下のとおりである。
【0147】
1.OTA OrchestratorがアップグレードファイルMをn個の部分:M1,M2,...,およびMnに分割する。
【0148】
2.OTA Orchestratorが、Bloom Filter Fを設定し、FにM1,M2,...,およびMnを追加し、共有鍵k(第2の鍵)を使用してv=MAC(k,F)、すなわち、第2のMACを計算する。
【0149】
3.Fおよびvをターゲットアップグレード対象車両搭載機器に転送し、Miを順次に転送する。
【0150】
4.ターゲットアップグレード対象車両搭載機器が、まず共有鍵kを使用してFに対する検証を行い、検証が失敗した場合、Fおよびvを再送するよう要求してもよく、各Miを受信すると、MiがF内にあるかどうかを判断し、MiがF内にない場合、Miを再送するよう要求し、最後に、受信したすべてのM1,M2,...,およびMnを結合して完全なアップグレードファイルMにする。
【0151】
前述の3つの方法では、車両内通信中にアップグレードファイルの機密性(confidentiality)が保護されなくてもよいと仮定されている。アップグレードファイルの機密性が保護される必要がある場合、OTA Orchestratorは、(本出願では第3の鍵を使用して)各Miを暗号化することによって暗号文Ciをまず取得する必要があり、前述のHash Chainベースの方法、Hash Treeベースの方法、またはBloom Filterベースの方法におけるMiをCiで置き換える。言い換えると、上述のように、暗号化が第3の鍵を使用して行われる。各部分を受信した後、ターゲットアップグレード対象車両搭載機器は、信憑性が検証された後にMiを取得するためにCiを暗号化する。暗号化のための鍵は好ましくはMAC処理で使用される鍵とは異なることに留意されたい。例えば、共有kが十分な長さである場合、kは2つの異なる鍵に分割されてもよく、そうでない場合、key derivation functionを使用してkに基づいて2つの鍵が生成され得る。
【0152】
OTA Orchestratorがアップグレードファイルを分割およびコード変換する前述の3つの方法には以下の利点がある。ターゲットアップグレード対象車両搭載機器は、デジタル署名に対する検証を行わなくてもよく、対称暗号操作、すなわち、MACおよびHashの計算のみを行う。加えて、対称暗号操作は公開鍵暗号操作よりずっと効率がよい。さらに、アップグレード対象車両搭載機器は、各セグメントの妥当性に対するセグメント検証を行うことができ、したがって、無効のまたは誤ったセグメントを適時に検出して、OTA Orchestratorに、アップグレードファイル全体の再送ではなく、そのセグメントの再送を要求することができる。セグメントコード変換ではなく一般のコード変換が行われる場合、すなわち、デジタル署名の代わりにMACが使用される場合、ターゲットアップグレード対象車両搭載機器は、誤り位置を正確に特定することができず、OTA Orchestratorにアップグレードファイル全体を再送するよう要求する必要がある。したがって、本発明の本実施形態によれば、誤り位置を正確に特定することができるのみならず、車両内のアップグレード対象機器の計算作業負荷および計算の複雑さを低減させることもできるので、アップグレード対象車両搭載機器をセキュアかつ効率的にアップグレードすることができる。
【0153】
前述の説明では、OTA Orchestratorはアップグレードファイルを分割する。別の実施形態では、分割がアップグレードパッケージ開発者によって行われ得る。具体的には、Hash Chainベースの方法を例にとる。
【0154】
1.アップグレードパッケージ開発者がアップグレードファイルMをn個の部分:M1,M2,...,およびMnに分割する。
【0155】
2.M1,M2,...,およびMnを使用して以下のようにHash Chainを形成し、式中、H(.)は、Cryptographic Hash Functionを表す。
hn=H(Mn)
hi=H(Mi,hi+1)
h2=H(M2,h3)
【0156】
3.署名秘密鍵を使用して、σ=SignD(M||ver,h2)を計算する。署名は本出願の第2のデジタル署名であり、署名秘密鍵は第4の鍵である。
【0157】
4.[M,ver,σ]をアップグレードパッケージとして使用し、アップグレードパッケージをアップグレードサーバに配布する。任意選択で、M1,M2,...,およびMnは、車両搭載アップグレードパッケージの機密性を保証するためにさらに暗号化され得る。アップグレードファイルの暗号化およびアップグレードファイルの機密性の保証については前述の関連説明を参照されたい。ここでは詳細を繰り返さない。
【0158】
OTA Orchestratorがアップグレードサーバからアップグレードパッケージを取得する必要があるとき、第1の部分から開始して、アップグレードサーバはMiをターゲットアップグレード対象車両搭載機器に順次に転送する。第1の部分では、アップグレードサーバは、σ,M1,ver,およびh2を転送する必要があり、残りの部分では、アップグレードサーバはMiおよびhi+1のみを転送しさえすればよい。
【0159】
第1の部分M1では、OTA Orchestratorはデジタル署名σに対する検証を行う必要があり、残りの部分では、OTA Orchestratorはhi=H(Mi,hi+1)に対してのみ検証を行いさえすればよい。
【0160】
すべての部分の受信および検証の後、OTA Orchestratorは、上述のようにコード変換を行い、すなわち、共有鍵k(本出願の第5の鍵)を使用してv=MAC(k,M1||ver,h2)を計算する。MACは第2のMACである。後続のアップグレードパッケージ車両内伝送については、アップグレードおよび確認プロセスは方法1、方法2、および方法3のプロセスと同じである。加えて、Hash Treeベースのコード変換方法およびBloom Filterベースのコード変換方法についても本発明の本実施形態ならびに前述の方法2および方法3を参照されたい。ここでは詳細を繰り返さない。
【0161】
本発明の本実施形態では、車両搭載制御装置内の車両搭載アップグレードパッケージに対する信憑性検証が完了した後(任意選択で、信憑性検証の前に機密性検証がさらに行われ得る)、車両搭載制御装置は、その信憑性検証(任意選択で、機密性検証が含まれ得る)が成功した複数のアップグレードファイルを、車両搭載システム内の対応するアップグレード対象車両搭載機器に伝送する必要がある。伝送の送信側と受信側とが変更され、すなわち、車両搭載アップグレードパッケージの車両外伝送が車両搭載アップグレードパッケージの車両内伝送になる。したがって、信憑性検証または機密性検証さえもが再度行われる必要がある。加えて、本発明の本実施形態によれば、大きな計算作業負荷および高い計算の複雑さを必要とする署名検証が車両搭載制御装置側で実施され、小さい計算作業負荷および低い計算の複雑さで済むMAC検証は依然としてアップグレード対象車両搭載機器で実施される。これにより、能力が弱いアップグレード対象車両搭載機器の高いアップグレード効率が保証されるのみならず、車両搭載アップグレードプロセスにおける車両内および車両外のセキュリティも保証される。
【0162】
前述の説明に基づき、本出願が以下の重要なテクニカルポイントを提供することが理解できよう。
【0163】
第1のポイントは、車両搭載アップグレードパッケージの信憑性(Authenticity)である。すなわち、アップグレード対象車両搭載機器はアップグレードパッケージの信憑性を検査する。アップグレードパッケージの信憑性を保証するために、アップグレードパッケージのデジタル署名が開発者またはアップグレードサーバ(パッケージサーバ)によって提供される必要がある。アップグレードパッケージがOTA Orchestratorに到達すると、OTA Orchestratorは、アップグレード対象車両搭載機器がデジタル署名に対する検証を行うのを支援する。次いで、OTA Orchestratorはコード変換(Transcoding)を行う。コード変換操作では、アップグレード対象車両搭載機器のためのアップグレードパッケージ信憑性検証を提供するために対称暗号が使用される。OTA Orchestratorは各アップグレード対象車両搭載機器と鍵を共有すると仮定する。この鍵は、OTA Orchestratorによって事前に配布されてもよく、具体的な配布プロセスは本出願の範囲外である。アップグレードパッケージは、コード変換(Transcoding)操作によって複数の部分に分割され、部分ごとにアップグレード対象車両搭載機器に伝送される。具体的には、Hash Chainベースのコード変換操作、Hash Treeベースのコード変換操作、およびBloom Filterベースのコード変換操作、が提供される。部分ごとのコード変換操作および部分ごとの伝送技術の利点は以下のとおりである。車両搭載機器の計算能力の限界および車両内通信ネットワークの帯域幅の限界が十分に考慮に入れられる。アップグレードパッケージ伝送誤りが発生した後、車両搭載機器は伝送誤りが発生した部分を見つけることができるので、アップグレードパッケージ全体ではなく誤り部分のみが再送を要求される。
【0164】
第2のポイントは、車両搭載アップグレードパッケージの機密性(Confidentiality)である。すなわち、攻撃者はリバースエンジニアリング技術を使用してアップグレードパッケージのコンテンツを解析し得る。したがって、車両搭載アップグレードパッケージの機密性が保護される必要がある。保護解決策は以下の2つのケースに基づいて提供される。
【0165】
a.アップグレードパッケージがアップグレードサーバで暗号化されない場合、車両搭載Telematicsがアップグレードパッケージを取得するときに、アップグレードサーバは、セキュアなチャネルを介してアップグレードパッケージを送信するために、車両搭載Telematicsに対して識別認証を行い、セキュアなチャネルを確立する必要がある。
【0166】
b.アップグレードパッケージがアップグレードサーバで(対称鍵を使用して)暗号化される場合、車両搭載Telematicsは、鍵サーバから暗号鍵を取得する必要があり、他のステップはケースaのステップと同じである。
【0167】
最後のポイントは、能力ベースのアップグレードポリシーである。すなわち、異なる車両搭載機器は異なる計算能力および記憶リソースを有する。例えば、車両搭載Telematics、ゲートウェイ、およびVCUは通常、比較的強い能力を有するが、ほとんどの車両搭載機器(ECU)は比較的弱い処理能力を有する。したがって、能力ベースのアップグレードポリシーが提供される。具体的には、能力が強い機器または主要機器にはA/Bシステム更新アップグレードモードが使用される必要があるが、能力が弱い機器では、アップグレードが失敗したときのロールバックを行うために、OTA Orchestratorの助けを借りてアップグレード対象車両搭載機器の旧バージョンのファームウェアまたはソフトウェアがバックアップされ得る。
【0168】
以上で本発明の実施形態の方法を詳細に説明した。以下で、本発明の実施形態の関連装置を示す。
【0169】
図6は、本発明の一実施形態による車両搭載アップグレード装置の概略的構造図である。本車両搭載アップグレード装置は車両搭載システムに適用され、車両搭載システムは、車両搭載制御装置と、1つまたは複数の
更新の対象である車両搭載機器とを含む。車両搭載アップグレード装置10は、前述のシステムにおける車両搭載制御装置であってもよく、装置10は、アップグレードパッケージ取得部101と、アップグレード管理部102と、アップグレード伝送部103とを含み得る。以下でこれらのユニットを具体的に説明する。
【0170】
アップグレードパッケージ取得部101は、車両搭載アップグレードパッケージを取得し、車両搭載アップグレードパッケージが複数のアップグレードファイルを含み、各アップグレードファイルが少なくとも1つのアップグレード対象車両搭載機器をアップグレードするために使用される、ように構成される。
【0171】
アップグレード管理部102は、複数のアップグレードファイルに対してセキュリティ検証を行うように構成される。
【0172】
アップグレード伝送部103は、ターゲットアップグレードファイルを使用してアップグレードされるべきターゲットアップグレード対象車両搭載機器にターゲットアップグレードファイルを送信し、ターゲットアップグレードファイルが、複数のアップグレードファイル内のそのセキュリティ検証が成功したアップグレードファイルである、ように構成される。
【0173】
1つの可能な実施態様では、車両搭載アップグレードパッケージは第1のデジタル署名を含み、アップグレード管理部は、第1のデジタル署名を使用して複数のアップグレードファイルに対してデジタル署名検証を行うように特に構成される。
【0174】
1つの可能な実施態様では、装置10は、
アップグレードサーバに識別認証情報を送信するように構成された、識別認証部と、
識別認証情報がアップグレードサーバによって認証された場合、車両搭載制御装置とアップグレードサーバとの間にセキュアなチャネルを確立する、ように構成された、チャネル確立部と
をさらに含み、
アップグレードパッケージ取得部は、セキュアなチャネルを介してアップグレードサーバから車両搭載アップグレードパッケージを取得するように特に構成される。
【0175】
1つの可能な実施態様では、車両搭載アップグレードパッケージは第1の鍵を使用して暗号化され、第1の鍵は対称鍵であり、本装置は、
鍵サーバから第1の鍵を取得するように構成された、鍵取得部
をさらに含み、
装置10は、
第1のデジタル署名を使用して複数のアップグレードファイルに対してデジタル署名検証が行われた後、車両搭載制御装置のために、デジタル署名検証が成功した場合、第1の鍵を使用して複数のアップグレードファイルを解読する、ように構成された、解読部
をさらに含む。
【0176】
1つの可能な実施態様では、アップグレード伝送部103は、
ターゲットアップグレードファイルを複数のアップグレードサブファイルに分割し、事前設定アルゴリズムを使用して複数のアップグレードサブファイルから複数の相互関連データブロックを生成し、第2の鍵を使用して複数のデータブロックの第1のメッセージ認証コードMACを生成し、第2の鍵が対称アルゴリズム鍵であり、ターゲットアップグレード対象車両搭載機器に、第1のMACを搬送する複数のデータブロックを順次に送信する
ように特に構成される。
【0177】
1つの可能な実施態様では、装置10は、
第3の鍵を使用して複数のアップグレードサブファイルの各々を暗号化するように構成された、暗号化部
をさらに含み、
アップグレード伝送部103は、
ターゲットアップグレードファイルを複数のアップグレードサブファイルに分割し、車両搭載制御装置のために事前設定アルゴリズムを使用して、第3の鍵を使用して暗号化された複数のアップグレードサブファイルから複数の相互関連データブロックを生成し、第2の鍵を使用して複数のデータブロックの第1のメッセージ認証コードMACを生成し、第2の鍵が対称アルゴリズム鍵であり、ターゲットアップグレード対象車両搭載機器に、第1のMACを搬送する複数のデータブロックを順次に送信する、
ように特に構成される。
【0178】
1つの可能な実施態様では、ターゲットアップグレードファイルは複数のアップグレードサブファイルを含み、事前設定アルゴリズムを使用して複数のアップグレードサブファイルから複数の相互関連データブロックが生成され、複数のアップグレードサブファイルは、第4の鍵を使用して生成された複数のデータブロックの第2のデジタル署名を搬送し、第4の鍵は非対称鍵であり、
アップグレード管理部102は、車両搭載制御装置のために、複数のデータブロックの第2のデジタル署名を検査するように特に構成され、
アップグレード伝送部103は、第5の鍵を使用して複数のデータブロックの第2のMACを生成し、第5の鍵が対称アルゴリズム鍵であり、ターゲットアップグレード対象車両搭載機器に、第2のMACを搬送する複数のデータブロックを順次に送信する、ように特に構成される。
【0179】
1つの可能な実施態様では、事前設定アルゴリズムは、Hash Chainアルゴリズム、Hash Treeアルゴリズム、および Bloom Filterアルゴリズムのいずれか1つを含む。
【0180】
1つの可能な実施態様では、装置10は、
ターゲットアップグレード対象車両搭載機器にターゲットデータブロックを再送するように構成された再送部であって、ターゲットデータブロックが、複数のデータブロック内のターゲットアップグレード対象車両搭載機器でその検証が失敗したデータブロックである、再送部
をさらに含む。
【0181】
本発明の本実施形態に記載される車両搭載アップグレード装置10の各機能部の機能については、
図1から
図5に示される方法実施形態の関連説明を参照することに留意されたい。ここでは詳細を繰り返さない。
【0182】
図7は、本発明の一実施形態によるアップグレード対象車両搭載装置の概略的構造図である。アップグレード対象車両搭載装置20は車両搭載システムに適用され、車両搭載システムは、車両搭載制御装置と、1つまたは複数の
更新の対象である車両搭載機器とを含む。アップグレード対象車両搭載装置20は前述のシステムにおけるアップグレード対象車両搭載機器であってもよく、装置20は、受信部201とアップグレード部202とを含み得る。以下でこれらのユニットを具体的に説明する。
【0183】
受信部201は、車両搭載制御装置によって送信されたターゲットアップグレードファイルを受信し、ターゲットアップグレードファイルが、車両搭載制御装置によって行われたそのセキュリティ検証が成功した、少なくともターゲットアップグレード対象車両搭載機器をアップグレードするために使用されるアップグレードファイルである、ように構成される。
【0184】
アップグレード部202は、ターゲットアップグレードファイルを使用してセキュアなアップグレードを行うために使用される。
【0185】
1つの可能な実施態様では、アップグレード部202は、
A/Bシステム更新アップグレードモードを使用し、ターゲットアップグレードファイルを使用してセキュアなアップグレードを行い、アップグレード対象車両搭載機器が、そのリソース記憶能力および/もしくは処理能力が事前設定値を超える第1のアップグレード対象車両搭載機器、または事前に指定された第1のアップグレード対象車両搭載機器である、
ように特に構成される。
【0186】
1つの可能な実施態様では、ターゲットアップグレードファイルは複数のアップグレードサブファイルを含み、受信部201は、
第1のMACを搬送する、車両搭載制御装置によって送信された複数のデータブロックを順次に受信し、複数のデータブロックが、事前設定アルゴリズムを使用して複数のアップグレードサブファイルから生成された複数の相互関連データブロックであり、第1のMACが第2の鍵を使用して生成された複数のデータブロックのメッセージ認証コードであり、第2の鍵が対称鍵である、
ように特に構成され、
アップグレード部202は、
第2の鍵を使用して事前設定アルゴリズムに基づいて複数のデータブロックに対する検証を順次に行い、複数のデータブロックすべてが検証されると、それら複数の順次に検証されたデータブロックをアップグレードのために結合する、
ように特に構成される。
【0187】
1つの可能な実施態様では、複数のアップグレードサブファイルは第3の鍵を使用して暗号化され、
アップグレード部202は、
第2の鍵を使用して事前設定アルゴリズムに基づいて複数のデータブロックに対する検証を順次に行い、複数のデータブロックすべてが検証されると、第3の鍵を使用してそれら複数の順次に検証されたデータブロックの各々を解読し、第3の鍵を使用して解読された複数のデータブロックを解読のために結合する、
ように特に構成される。
【0188】
1つの可能な実施態様では、受信部201は、
第2のMACを搬送する、車両搭載制御装置によって送信された複数のデータブロックを順次に受信し、複数のデータブロックが、事前設定アルゴリズムを使用して複数のアップグレードサブファイルから生成された複数の相互関連データブロックであり、第2のMACが第5の鍵を使用して生成された複数のデータブロックのメッセージ認証コードであり、第5の鍵が対称アルゴリズムである、
ように特に構成され、
アップグレード部202は、
第5の鍵を使用して事前設定アルゴリズムに基づいて複数のデータブロックに対する検証を順次に行い、複数のデータブロックすべてが検証されると、それら複数の順次に検証されたデータブロックをアップグレードのために結合する、
ように特に構成される。
【0189】
1つの可能な実施態様では、装置20は、
車両搭載制御装置からターゲットデータブロックを再取得するように構成された再送部であって、ターゲットデータブロックが、複数のデータブロック内のターゲットアップグレード対象車両搭載機器でその検証が失敗したデータブロックである、再送部
をさらに含む。
【0190】
本発明の本実施形態に記載されるアップグレード対象車両搭載装置20の各機能部の機能については、
図1から
図6に示される方法実施形態の関連説明を参照することに留意されたい。ここでは詳細を繰り返さない。
【0191】
図8は、本発明の一実施形態による機器の概略的構造図である。
図8の構造ではアップグレード対象車両搭載装置10とアップグレード対象車両搭載装置20の両方が実施され得る。機器30は、少なくとも1つのプロセッサ301と、少なくとも1つのメモリ302と、少なくとも1つの通信インターフェース303とを含む。加えて、この機器は、アンテナなどの汎用構成要素をさらに含んでいてもよく、ここでは詳細を述べない。
【0192】
プロセッサ301は、汎用中央処理装置(CPU)、マイクロプロセッサ、特定用途向け集積回路(Application Specific Integrated Circuit、ASIC)、または前述の解決策のプログラムの実行を制御するための1つもしくは複数の集積回路であり得る。
【0193】
通信インターフェース303は、アップグレードサーバ、鍵サーバ、もしくは車両内機器などの別の機器と、または通信ネットワークと通信するように構成される。
【0194】
メモリ302は、静的情報および命令を格納することができる読取り専用メモリ(read-only memory、ROM)もしくは任意のタイプの静的記憶デバイス、または情報および命令を格納することができるランダムアクセスメモリ(random access memory、RAM)もしくは任意のタイプの動的記憶デバイスであってもよく、または電気的消去可能プログラム可能読取り専用メモリ(Electrically Erasable Programmable Read-Only Memory、EEPROM)、コンパクトディスク読取り専用メモリ(Compact Disc Read-Only Memory、CD-ROM)もしくは他の光ディスク記憶、(コンパクトディスク、レーザディスク、光ディスク、デジタル多用途ディスク、ブルーレイディスクなどを含む)光ディスク、磁気ディスク記憶媒体もしくは別の磁気記憶デバイス、または命令またはデータ構造形態で予期されるプログラムコードを搬送もしくは格納するために使用することができ、コンピュータによってアクセスできる任意の他の媒体であってもよいが、これに限定されない。メモリは独立して存在していてもよく、バスを使用してプロセッサに接続される。あるいは、メモリはプロセッサと一体化されていてもよい。
【0195】
メモリ302は、前述の解決策を実行するためのアプリケーションプログラムコードを格納するように構成され、プロセッサ301は実行を制御する。プロセッサ301は、メモリ302に格納されたアプリケーションプログラムコードを実行するように構成される。
【0196】
図8に示される機器が車両搭載機器アップグレード装置10であるとき、メモリ302に格納されたコードは、
図5に示される車両搭載機器アップグレード方法、例えば、車両搭載アップグレードパッケージを取得するステップであって、車両搭載アップグレードパッケージが複数のアップグレードファイルを含み、各アップグレードファイルが少なくとも1つのアップグレード対象車両搭載機器をアップグレードするために使用される、ステップや、複数のアップグレードファイルに対してセキュリティ検証を行うステップや、ターゲットアップグレードファイルを使用してアップグレードされるべきであるターゲットアップグレード対象車両搭載機器にターゲットアップグレードファイルを送信するステップであって、ターゲットアップグレードファイルが、複数のアップグレードファイル内のそのセキュリティ検証が成功したアップグレードファイルである、ステップ、を行うために使用され得る。
【0197】
本発明の本実施形態に記載される車両搭載機器アップグレード装置10の各機能部の機能については、
図5に示される方法実施形態のステップS502およびステップS503の関連説明を参照することに留意されたい。ここでは詳細を繰り返さない。
【0198】
図8に示される機器がアップグレード対象車両搭載装置20であるとき、メモリ302に格納されたコードは、
図5に示される車両搭載機器アップグレード方法、例えば、車両搭載制御装置によって送信されたターゲットアップグレードファイルを受信するステップであって、ターゲットアップグレードファイルが、車両搭載制御装置によって行われたそのセキュリティ検証が成功した、少なくともターゲットアップグレード対象車両搭載機器をアップグレードするために使用されるアップグレードファイルである、ステップや、ターゲットアップグレードファイルを使用してセキュアなアップグレードを行うステップ、を行うために使用され得る。
【0199】
本発明の本実施形態に記載されるアップグレード対象車両搭載装置20の各機能部の機能については、
図5に示される方法実施形態のステップS504およびステップS505の関連説明を参照することに留意されたい。ここでは詳細を繰り返さない。
【0200】
図9は、本発明の一実施形態によるインテリジェント車両の概略的構造図である。インテリジェント車両40は、車両搭載制御装置401と、少なくとも1つのアップグレード対象車両搭載機器402とを含む。
【0201】
車両搭載装置401は、車両搭載アップグレードパッケージを取得し、車両搭載アップグレードパッケージ内の複数のアップグレードファイルに対してセキュリティ検証を行い、ターゲットアップグレードファイルを使用してアップグレードされるべきであるターゲットアップグレード対象車両搭載機器にターゲットアップグレードファイルを送信し、各アップグレードファイルが少なくとも1つのアップグレード対象車両搭載機器をアップグレードするために使用され、ターゲットアップグレードファイルが、複数のアップグレードファイル内のその検証が成功したアップグレードファイルである、ように構成される。
【0202】
アップグレード対象車両搭載機器402は、車両搭載制御装置によって送信されたターゲットアップグレードファイルを受信し、ターゲットアップグレードファイルを使用してセキュアなアップグレードを行い、アップグレード対象車両搭載機器がターゲットアップグレード対象車両搭載機器である、ように構成される、
【0203】
1つの可能な実施態様では、車両搭載制御装置401は、第1のデジタル署名を使用して複数のアップグレードファイルに対してデジタル署名検証を行うように特に構成される。
【0204】
1つの可能な実施態様では、車両搭載制御装置401は、
アップグレードサーバに識別認証情報を送信し、識別認証情報がアップグレードサーバによって認証された場合、車両搭載制御装置とアップグレードサーバとの間にセキュアなチャネルを確立し、セキュアなチャネルを介してアップグレードサーバから車両搭載アップグレードパッケージを取得する、
ように特に構成されるか、または
車両搭載アップグレードパッケージは第1の鍵を使用して暗号化され、第1の鍵は対称鍵であり、車両搭載制御装置401は、
第1の鍵を鍵サーバから取得し、第1のデジタル署名を使用して複数のアップグレードファイルに対して行われたデジタル署名検証が成功した後、第1の鍵を使用して複数のアップグレードファイルを解読する、
ように特に構成される。
【0205】
1つの可能な実施態様では、車両搭載制御装置401は、
ターゲットアップグレードファイルを複数のアップグレードサブファイルに分割し、事前設定アルゴリズムを使用して複数の相互関連データブロックを生成し、第2の鍵を使用して複数のデータブロックの第1のメッセージ認証コードMACを生成し、ターゲットアップグレード対象車両搭載機器に、第1のMACを搬送する複数のデータブロックを順次に送信し、第2の鍵が対称アルゴリズム鍵である、
ように特に構成され、
アップグレード対象車両搭載機器402は、
第1のMACを搬送する、車両搭載制御装置によって送信された複数のデータブロックを順次に受信し、第2の鍵を使用して事前設定アルゴリズムに基づいて複数のデータブロックに対する検証を順次に行い、複数のデータブロックすべてが検証されると、それら複数の順次に検証されたデータブロックをアップグレードのために結合する、
ように特に構成される。
【0206】
1つの可能な実施態様では、車両搭載制御装置401は、
第3の鍵を使用して複数のアップグレードサブファイルの各々を暗号化し、事前設定アルゴリズムを使用して、第3の鍵を使用して暗号化された複数のアップグレードサブファイルから複数の相互関連データブロックを生成する、
ように特に構成され、
アップグレード対象車両搭載機器402は、
複数のデータブロックすべてが検証されると、第3の鍵を使用してそれら複数の順次に検証されたデータブロックの各々を解読し、第3の鍵を使用して解読された複数のデータブロックをアップグレードのために結合する、
ように特に構成される。
【0207】
1つの可能な実施態様では、ターゲットアップグレードファイルは複数のアップグレードサブファイルを含み、事前設定アルゴリズムを使用して複数のアップグレードサブファイルから複数の相互関連データブロックが生成され、複数のアップグレードサブファイルは、第4の鍵を使用して生成された複数のデータブロックの第2のデジタル署名を搬送し、第4の鍵は非対称鍵であり、
車両搭載制御装置401は、
複数のデータブロックの第2のデジタル署名を検査し、第5の鍵を使用して複数のデータブロックの第2のMACを生成し、ターゲットアップグレード対象車両搭載機器に、第2のMACを搬送する複数のデータブロックを順次に送信し、第5の鍵が対称アルゴリズム鍵である、
ように特に構成され、
アップグレード対象車両搭載機器402は、
第2のMACを搬送する、車両搭載制御装置によって送信された複数のデータブロックを順次に受信し、第5の鍵を使用して事前設定アルゴリズムに基づいて複数のデータブロックに対する検証を順次に行い、複数のデータブロックすべてが検証されると、それら複数の順次に検証されたデータブロックをアップグレードのために結合する、
ように特に構成される。
【0208】
本発明の本実施形態に記載されるインテリジェント車両40の車両搭載制御装置401およびアップグレード対象車両搭載機器402については、
図5に示される方法実施形態における車両搭載制御装置およびアップグレード対象車両搭載機器の関連説明を参照することに留意されたい。ここでは詳細を繰り返さない。
【0209】
インテリジェント車両40は、コンピュータ、最新の感知法、情報収束、通信、人工知能、自動制御、および他の技術を使用して、インテリジェント運転システム、ライフサービスシステム、安全保護システム、測位サービスシステム、カーサービスシステムなどの機能とさらに統合され得ることが理解できよう。これについては本出願では特に限定されず、ここでは詳細を述べない。
【0210】
本発明の一実施形態はコンピュータ記憶媒体をさらに提供する。本コンピュータ記憶媒体はプログラムを格納し、実行されると、プログラムは、前述の方法実施形態のいずれか1つに記載されるステップの一部または全部を行う。
【0211】
本発明の一実施形態はコンピュータプログラムをさらに提供する。本コンピュータプログラムは命令を含み、本コンピュータプログラムがコンピュータによって実行されると、コンピュータは、車両搭載機器アップグレード方法のいずれか1つのステップの一部または全部を行うことができるようになる。
【0212】
前述の各実施形態において、各実施形態の記述にはそれぞれの視点がある。ある実施形態で詳細に記載されていない部分については、他の実施形態の関連説明を参照されたい。
【0213】
説明を簡単にするために、前述の方法実施形態は一連の動作として表されていることに留意されたい。しかしながら、本出願によれば、いくつかのステップは他の順序でまたは同時に行われ得るので、本出願は記載の動作順序に限定されないことを、当業者は理解するはずである。本明細書に記載されている実施形態はすべて実施形態の例であり、関連した動作およびモジュールは必ずしも本出願に必要であるとは限らないことが当業者にはさらに理解されるはずである。
【0214】
本出願で提供されるいくつかの実施形態では、開示の装置は他のやり方でも実施され得ることを理解されたい。例えば、記載の装置実施形態は一例にすぎない。例えば、ユニット分割は論理的機能分割にすぎず、実際の実装に際しては他の分割であってもよい。例えば、複数のユニットもしくはコンポーネントが別のシステムに結合もしくは統合される場合もあり、またはいくつかの特徴が無視されるかもしくは実行されない場合もある。加えて、図示または記載の相互結合または直接結合または通信接続が、いくつかのインターフェースを介して実現されてもよい。装置間またはユニット間の間接結合または通信接続は、電気的形態または他の形態として実現され得る。
【0215】
別々の部品として記載された前述のユニットは物理的に分離している場合もそうでない場合もあり、ユニットとして図示された部品は物理的ユニットである場合もそうでない場合もあり、一箇所に位置する場合もあり、複数のネットワークユニット上に分散されている場合もある。ユニットの一部または全部が、各実施形態の解決策の目的を達成するための実際の要件に基づいて選択されてもよい。
【0216】
加えて、本出願の各実施形態における機能ユニットは1つの処理ユニットに統合されてもよく、またはユニットの各々が物理的に独立して存在していてもよく、または2つ以上のユニットが1つのユニットに統合される。統合ユニットはハードウェアの形態で実現されてもよく、ソフトウェア機能部の形態で実現されてもよい。
【0217】
前述の統合ユニットがソフトウェア機能ユニットの形態で実現され、独立した製品として販売または使用される場合、その統合ユニットはコンピュータ可読記憶媒体に記憶され得る。そうした理解に基づき、本出願の技術解決策は本質的に、または先行技術に寄与する部分、または技術解決策の全部もしくは一部は、ソフトウェア製品の形態で実現され得る。コンピュータソフトウェア製品は記憶媒体に格納され、(パーソナルコンピュータ、サーバ、ネットワーク機器などとし得る)コンピュータデバイスに、本出願の実施形態に記載される方法のステップの全部または一部を実行するよう命令するためのいくつかの命令を含む。前述の記憶媒体は、USBフラッシュドライブ、リムーバブルハードディスク、磁気ディスク、光ディスク、読取り専用メモリ(Read-Only Memory、略称ROM)、ランダムアクセスメモリ(Random Access Memory、略称RAM)、などの、プログラムコードを格納することができる任意の媒体を含む。
【0218】
前述の実施形態は、本出願を限定するためのものではなく、本出願の技術的解決策を説明するためのものにすぎない。本出願は前述の実施形態に関連して詳細に説明されているが、本出願の実施形態の技術的解決策の範囲を逸脱することなく、前述の実施形態に記載されている技術的解決策にさらに改変を行い得るかまたは前述の実施形態の一部の技術的特徴に対する等価の置換を行い得ることを当業者は理解するはずである。
【符号の説明】
【0219】
10 車両搭載アップグレード装置
101 アップグレードパッケージ取得部
102 アップグレード管理部
103 アップグレード伝送部
20 アップグレード対象車両搭載装置
201 受信部
202 アップグレード部
30 機器
301 プロセッサ
302 メモリ
303 通信インターフェース
40 インテリジェント車両
401 車両搭載制御装置
402 アップグレード対象車両搭載機器