JP2022533105A - コンピューティングコンポーネントをインストールするための方法および関連付けられた電子デバイス - Google Patents

Abstract

車両に備え付けられた電子デバイスにコンピューティングコンポーネント（ＣＯＭＰ１）をインストールするための方法であって、－ コンピューティングコンポーネントのハッシュ値（Ｈ（ＣＯＭＰ１）を含むマニフェスト（ＥＣＵＰＡＣＫＩＮＤ）を含むデバイスパケット（ＥＣＵＰＡＣＫＩＮＤ）を受信することと、－ マニフェストの整合性（ＥＣＵＰＡＣＫＩＮＤ）をチェックすることと、－ コンピューティングコンポーネント（ＣＯＭＰ１）を受信することと、－ コンピューティングコンポーネントのハッシュ値（Ｈ（ＣＯＭＰ１））と、受信されたコンピューティングコンポーネント（ＣＯＭＰｉ）との間の相関性をチェックすることと、－ マニフェストの整合性（ＥＣＵＰＡＣＫＩＮＤ）の肯定的チェック、および相関性の肯定的チェックの場合のみ、コンピューティングコンポーネント（ＣＯＭＰ１）をインストールすることとから成るステップを含む、方法。関連付けられた電子デバイスも説明される。【選択図】図２

Description

本発明は、一般に、車両、特に自動車内への、データ処理コンポーネントのインストールに関する。

本発明は、このようなデータ処理コンポーネントを車両内にダウンロードする状況で特に好都合に使用されるが、データ処理コンポーネントが、例えばメモリカードから、車両にローカルにロードされるときにも使用される。

本発明は、より詳細には、データ処理コンポーネントをインストールするための方法および関連付けられた電子機器に関する。

状況によっては、車両に設置された電子機器にデータ処理コンポーネントをインストールすることが望ましい。このことは、電子機器内に実装されるソフトウェア、または電子機器によって操作されるデータをアップデートすることが望ましいときに、特に当てはまる。

このようなデータ処理コンポーネントのインストールは当然、車両のその後の動作に関する影響があり、制御された手法で実行されなければならない。

この状況において、本発明は、車両に設置された電子機器にデータ処理コンポーネントをインストールするための方法であって、
－ データ処理コンポーネントのハッシュ値を含む第１のマニフェストを含むデバイスパケットを受信することと、
－ 第１のマニフェストの整合性を検証することと、
－ データ処理コンポーネントを受信することと、
－ データ処理コンポーネントのハッシュ値と、受信されたデータ処理コンポーネントとの間の対応関係を検証することと、
－ 第１のマニフェストの整合性の肯定的検証、および対応関係の肯定的検証の場合のみ、データ処理コンポーネントをインストールすることと
を伴うステップを含む、方法を提案する。

このように、本発明の結果として、車両は、データ処理コンポーネントに関連付けられ、（ハッシュ値を特に使用した）データ処理コンポーネントの整合性の検証に関与する、データ構造を受信する。提案されるソリューションは、デバイスパケットとデータ処理コンポーネント自体を別々に伝送することをさらに可能にし、車両および車両の電子機器の設計中に、より大きな柔軟性をもたらす。

第１の車両識別子を含めるための上述の第１のマニフェスト、および、以下を伴うステップをさらに含むことになるインストール方法を提供することがさらに可能である：
－ 第１の車両識別子を、車両内に格納された第２の車両識別子と比較すること
－ 第１の識別子と第２の識別子との肯定的比較の場合のみ、データ処理コンポーネントをインストールすること。

本発明による方法の他の有利かつ非限定的特徴は個別に行われるか、全ての技術的に可能な組合せに従って行われ、以下のようなものである。

－ デバイスパケットは、第１の署名を含む。

－ マニフェストの整合性は、暗号署名検証アルゴリズムを第１の署名および第１のマニフェストに適用することによって検証される。

－ データ処理コンポーネントは、デバイスパケットから独立して受信される。

－ データ処理コンポーネントは、デバイスパケット内で受信される。

－ データ処理コンポーネントは、第２の署名およびコンテンツを含む。

－ 方法は、第２の署名を使用してコンテンツの整合性を検証するステップを含む。

方法は、以下を伴うステップをさらに含むことができる：
－ デバイスパケットおよび第２のマニフェストを含むコンテナを受信すること
－ 第２のマニフェストの整合性を検証すること

したがって、この第２のマニフェストは、第１の車両識別子を含むことができ、インストール方法は、このケースでは、以下を伴うステップを含むことができる。
－ 第１の車両識別子を、車両内に格納された第２の車両識別子と比較すること
－ 第１の識別子と第２の識別子との肯定的比較の場合のみ、デバイスパケットを伝送すること。

したがってコンテナは、例えば、別の電子機器のための別のデバイスパケットを含むことができる。

このコンテナは、車両によって伝送されたリクエストに応答してリモートサーバから（例えばリモートサーバと車両との間で確立された通信（この通信は、車両とセルラー電話ネットワークとの間の無線リンクを部分的に使用することができる）を介して直接的に）さらに受信されてよく、１つの変形形態では、コンテナは、車両に設置されたリーダに挿入されたメモリカードから受信されてよい。

最後に、本発明は、車両に提供するための電子機器に関し、電子機器は以下を備える：
－ データ処理コンポーネントのハッシュ値を含むマニフェストを含むデバイスパケットを受信するためのモジュール
－ マニフェストの整合性を検証するためのモジュール
－ データ処理コンポーネントを受信するためのモジュール
－ データ処理コンポーネントのハッシュ値と、受信されたデータ処理コンポーネントとの間の対応関係を検証するためのモジュール
－ マニフェストの整合性の肯定的検証、および対応関係の肯定的検証の場合のみ、データ処理コンポーネントをインストールするように構成されたインストールモジュール。

第１の車両識別子を含めるためのマニフェストをさらに提供することができ、したがって電子機器は、第１の車両識別子と、車両内に格納された車両の第２の識別子とを比較するためのモジュールを備えることができる。

インストールモジュールは、マニフェストの整合性の肯定的検証、第１の識別子と第２の識別子との肯定的比較、および対応関係の肯定的検証の場合のみ、データ処理コンポーネントをインストールするように構成されてよい。

マニフェストの検証がもたらす整合性および信憑性の保護以上に、マニフェスト内の対象の車両識別子を使用すると、合法性の保護を追加することができる。これは、アップデートするオンボード処理が、受信されたイメージが破損しておらず、正式で、かつ特定のハードウェアに対して互換性があることを間違いなく検証できるからであるが、これは、車両がイメージを正当に受信し得ることを必ずしも示唆していない。サイバー攻撃、またはエンドツーエンドの伝送チェーンにおける悪意の処理のイベントでは、ソースイメージの代わりに互換性のある車両イメージが挿入されることがある。したがってマニフェスト内の車両識別子により、本シナリオにおける詐欺のどのような発生も防ぐことができる。

このような電子機器は、例えば、プロセッサと、プロセッサによって実行可能なコンピュータプログラム命令を格納するメモリとを備える電子制御ユニット（またはコンピュータ）である。

上述のモジュールは、例えば、この事例では、（下記で説明されるような）当該のモジュールに帰する機能を実行するように構成された特定の命令がプロセッサによって実行されるとき、プロセッサと特定の命令との協働によって実行される。

当然、本発明の様々な特徴、変形形態、および実施形態は、非互換でないか、相互に排他的でない限り、様々な組合せに従って互いに関連付けられてよい。

添付の図面を参照しながら下記で行われる説明は、非限定的な例として示されており、本発明が含むもの、およびこれをどのように実装可能かについて、十分な理解をもたらすはずである。

本発明を実装可能なシステムを概略的に示す図である。 本発明の状況で使用可能なデータ編成の例を示す図である。 本発明の状況で使用可能なデータ編成の別の例を示す図である。 本発明による車両内にデータ処理コンポーネントをインストールするための方法の例を示す図である。

図１のシステムは、車両Ｖ（例えば自動車）、携帯電話ネットワークＮ、ワイドエリアネットワークＩ（インターネット等）、およびリモートサーバＳを備える。

車両Ｖは、通信ユニット２、処理ユニット４、第１の電子制御ユニット６、ゲートウェイ８、および第２の電子制御ユニット１０を備える。

図１は本発明を理解するのに有利な車両Ｖの要素を示しているが、車両Ｖは当然、実際には他の要素、具体的には他の電子制御ユニットすなわちプロセッサを備える。

上述の電子機器（通信ユニット２、処理ユニット４、第１の電子制御ユニット６、ゲートウェイ８、および第２の電子制御ユニット１０）はそれぞれ、実際にはマイクロプロセッサアーキテクチャの形で製造されてよく、特に本文脈では、これらの電子機器のそれぞれは、プロセッサならびに少なくとも１つのメモリ（例えばＲＡＭおよび／または不揮発性メモリ）を備える。

処理ユニット４はそれ自体が、実際には、利用可能であれば、下記で説明される機能以外の機能を有する電子制御ユニットを使用して実行されてよい。

図１に概略的に示しているように、処理ユニット４は、通信ユニット２、第１の電子制御ユニット６、およびゲートウェイ８とデータを交換できるように、これらの種々の電子機器とに接続される。通信ユニット２、処理ユニット４、電子制御ユニット６、およびゲートウェイ８は、例えば、このために、例えばＣＡＮバス（「コントローラエリアネットワーク」）など、（同じ）ボード上のデータ処理ネットワーク（図示せず）に接続される。

ゲートウェイ８は、例えば専用バスによって、第２の電子制御ユニット１０にさらに接続される。

車両Ｖは、下記で述べるような、本発明の構造上の変形形態で使用可能なメモリカード２０用のリーダ１２をさらに備えることができる。

通信ユニット２は、携帯電話ネットワークＮ内の（接続が例えば３Ｇ／４Ｇ、Ｗｉ－Ｆｉ等の物理的なタイプの接続であることを表す連続線で図１に概略的に示されているような）通信Ｃを実行するように構成され、したがって、（車両Ｖと、携帯電話ネットワークＮの一部であるセルラー電話ネットワークとの間の無線リンクを特に使用することによる）携帯電話ネットワークＮ、およびワイドエリアネットワークＩを介したリモートサーバＳとの接続を確立することができ、これにより、処理ユニット４とリモートサーバＳは、下記で説明されるような、特に車両Ｖ内のデータ処理コンポーネントのインストールの状況において、（接続が論理タイプの接続であることを表す点線で図１に概略的に示されているような）データＤを交換することができる。

図２は、本発明の状況で使用可能なデータ編成の例を示す。

これらのデータは、具体的にはデータ処理コンポーネントＣＯＭＰ１、ＣＯＭＰ２、ＣＯＭＰｉを備え、この事例では、１つ１つが用語「電子機器」を使用して呼ばれる、具体的には第１の電子制御ユニット６および／または第２の電子制御ユニット１０といった、車両Ｖの１つまたは複数の電子機器にインストールすることが望ましい。

データ処理コンポーネントＣＯＭＰ１、ＣＯＭＰ２、ＣＯＭＰｉは、この事例では、以下のように木構造および分岐構造内にカプセル化される。
－ ダウンロードパケットＤＰＡＣＫは、それぞれが車両Ｖの電子機器に関連する１つまたは複数のデバイスパケットＥＣＵＰＡＣＫ１、ＥＣＵＰＡＣＫ２、ＥＣＵＰＡＣＫｎを備える。
－ 各デバイスパケットＥＣＵＰＡＣＫは、特定の電子機器のための１つまたは複数のデータ処理コンポーネントＣＯＭＰ１、ＣＯＭＰ２、ＣＯＭＰｉに関するデータを含む。

ロシア人形型のこのカプセル化方法は、対象コンポーネントごと、つまり本明細書では、電子制御ユニットのソフトウェアをリモートアップデート（またはファームウェアオーバジエアー（ＦＯＴＡ））で修正可能な電子制御ユニット２、４、６、８、および１０ごとにコンテンツを分けることを可能にするということの他に、同じ電子コンポーネント内でアップデートの一貫性を保証することも可能なので、特に有利である。さらに、このカプセル化によって、いくつかのステージを含む整合性／信憑性の検証のレベルを達成することができる。より具体的には、通信ユニット２は、ダウンロードパケットＤＰＡＣＫにおける第１のレベルの検証を実行可能になり、この検証が正しいことが証明されるとすぐ、デバイスパケットＥＣＵＰＡＣＫが抽出され、対象コンポーネント２、４、６、８、および１０に配布されることになる。したがって対象コンポーネント２、４、６、８、および１０は、種々の暗号ハードウェアを用いるレベル２検証を実行可能になり、レベル２検証は、生成されることになるコンポーネントごとにコンテンツの分離を可能にする（コンポーネントの多くのプロバイダが存在し得る）。デバイスパケットＥＣＵＰＡＣＫが認証された後、データ処理コンポーネントＣＯＭＰ１、ＣＯＭＰ２、ＣＯＭＰｉが抽出され、次に第３の暗号レベルで正しいことが証明され、肯定的検証の場合、最終的にインストールされてよい。したがってこの処理は、しばしばセキュアなゾーンまたは保護されたゾーン（すなわち信頼できるゾーン）、およびセキュアでないゾーン（すなわち信頼できないゾーン）から成る通信ユニット２のために、２つのレベル（ダウンロードパケットＤＰＡＣＫが、信頼できない接続ゾーン内で検証され、デバイスパケットＥＣＵＰＡＣＫが抽出されて信頼できるゾーンと共有されること、および、その検証が、信頼できるゾーンで実行されることになること）でリモートプロセッサのように検証を実行することをこの方法がこのように可能にするので、対象プロセッサが通信ユニット２の場合、特に有利である。このように、最終的に、対象ＥＣＵがローカルであろうとリモート（車両ネットワークの他のＥＣＵ）であろうと、方法は、いくつかのレベルでの検証を可能にする。コンポーネントＣＯＭＰがデバイスパケットＥＣＵＰＡＣＫ内にない図２にさらに示されている別の方式では、コンポーネントＣＯＭＰは、２次交換処理で受信され、デバイスパケットＥＣＵＰＡＣＫ内の第１のインスタンスに収められたハッシュ値Ｈ（ＣＯＭＰ１）、Ｈ（ＣＯＭＰ２）、Ｈ（ＣＯＭＰｉ）で正しいことが証明されることになる。コンポーネント内にアップデートコンテンツをカプセル化することは、導入の制御を保証するために、イメージの証明を保証するようにコンストラクタレベルの電子署名が制御されることを可能にする。コンポーネントのこの署名動作は、車両製造業者の敷地で（特定の特権を有する）認定済のセキュリティエージェントによって、例えば手動で、実行されることになる。この動作がないと、破損していないコンテンツを車両に導入することができない。この署名レベルは、例えば手動式であり（特にＡＳＳＩＭ署名（ＡＳＳＩＭ ｓｉｇｎｉｎｇ））、導入の認可を制御することができる。このように、サプライヤによって提供された破損していない正式なバイナリアップデートコンテンツは、車両製造業者によって認定されたイメージだけを車両に伝送できることをプロセッサ２、４、６、８、または１０に保証できるこの検証レベルがないと、プロセッサ２、４、６、８、または１０によって利用されることが不可能になる。これは、導入前に対象ソフトウェアの品質が保証されることをさらに可能にする。

下記で説明されるように、これらのパケットのそれぞれが、データ処理コンポーネントのインストールのために使用されるデジタル署名を収める。下記で想定されるように、デジタル署名の検証は、本明細書で説明されることになる固有の暗号インフラストラクチャを必要とする。

提示を簡素化するために、どのデジタル署名も、単に「署名」と下記で呼ばれる。

以下は、特に下記で使用される：
－ メタデータＲＯＯＴ．ｍｄ、および秘密鍵ＲＯＯＴ．Ｋｐｒｉｖに関連付けられた公開鍵ＲＯＯＴ．Ｋｐｕｂを収めるルート証明書ＲＯＯＴ．ｃｅｒｔ
－ メタデータＣＡ．ｍｄ、公開鍵ＣＡ．Ｋｐｕｂ、および署名ＣＡ．ｓｉｇを収める当局の証明書ＣＡ．ｃｅｒｔ
－ メタデータＲ．ｍｄ、公開鍵Ｒ．Ｋｐｕｂ、および署名Ｒ．ｓｉｇを収める製造業者の証明書Ｒ．ｃｅｒｔ
－ 秘密鍵ＢＫ．Ｋｐｒｉｖに関連付けられた公開鍵ＢＫ．Ｋｐｕｂ。

秘密鍵ＣＡ．Ｋｐｒｉｖは、公開鍵ＣＡ．Ｋｐｕｂに関連付けられる。

同様に、秘密鍵Ｒ．Ｋｐｒｉｖは、公開鍵Ｒ．Ｋｐｕｂに関連付けられる。

用語、関連付けられた公開鍵および秘密鍵は、この事例では、「公開鍵インフラストラクチャ」（すなわちＰＫＩ）における関連付けられた公開鍵および秘密鍵を指すと理解されることを意図する。

このような文脈では、データのグループは、秘密鍵を使用する（この事例ではＲＳＡタイプの）暗号署名アルゴリズムをデータのこのグループに適用することによって署名されてよく、次に、上述の秘密鍵に関連付けられた公開鍵を使用する（この事例では同様にＲＳＡタイプの）関連付けられた暗号署名検証アルゴリズムを使用して、署名を検証することができる。

当局の証明書ＣＡ．ｃｅｒｔの署名ＣＡ．ｓｉｇは、秘密鍵ＲＯＯＴ．Ｋｐｒｉｖを使用する暗号署名アルゴリズムを、メタデータＣＡ．ｍｄおよび公開鍵ＣＡ．Ｋｐｕｂによって形成されるグループに適用することによって取得される（この動作は、例えば証明当局によって実行される）。

製造業者の証明書Ｒ．ｃｅｒｔの署名Ｒ．ｓｉｇはそれ自体が、秘密鍵ＣＡ．Ｋｐｒｉｖを使用する暗号署名アルゴリズムを、メタデータＲ．ｍｄおよび公開鍵Ｒ．Ｋｐｕｂによって形成されるグループに適用することによって取得される（この動作も、上述の証明当局によって実行されることが可能である）。

図２に示されている様々なデータ構造が、ここで詳細に説明される。

インストールされることになる各データ処理コンポーネントＣＯＭＰは以下を含む：
－ 当該の電子機器にインストールされることになる（実際には格納されることになる）データを含むコンテンツＣＯＮＴＥＮ
－ 特に、インストールされることになるコンテンツのハッシュ値Ｈ（ＣＯＮＴＥＮ）、および利用可能であれば、例えばこのコンポーネントによってアップデートされる機能を記述したものなど、データ処理コンポーネントを記述したものを収めるマニフェストＣＯＭＰＩＮＤ
－ マニフェストＣＯＭＰＩＮＤの署名ＳＩＧ（ＣＯＭＰＩＮＤ）。

インストールされることなるこれらのデータは、ソフトウェアまたはソフトウェアの一部（例えばソフトウェアアップデート）を構成することができる。したがって、このソフトウェアまたはソフトウェアの一部は、当該の電子機器のプロセッサによって少なくとも部分的に実行されるように構成される。１つの変形形態では、インストールされることになるこれらのデータは、当該の電子機器のプロセッサによるその後の操作のために格納されることになるデータ（例えば地図データ）でよい。

ハッシュ値Ｈ（ＣＯＮＴＥＮ）は、（例えばタイプＳＨＡ－２５６の）ハッシュ値機能をコンテンツＣＯＮＴＥＮに適用することによって取得される。

署名ＳＩＧ（ＣＯＭＰＩＮＤ）は、秘密鍵ＢＫ．Ｋｐｒｉｖを使用する暗号署名アルゴリズムをマニフェストＣＯＭＩＮＤに適用することによって取得される。

例えばこれらの動作は、当該の（例えばソフトウェアの）コンテンツＣＯＮＴＥＮの証明機関によって実行される。

各デバイスパケットＥＣＵＰＡＣＫは、この事例では、以下を含む：
－ 上記で説明されたような１つまたは複数のデータ処理コンポーネントＣＯＭＰ１、ＣＯＭＰ２、ＣＯＭＰｉ
－ デバイスパケットＥＣＵＰＡＣＫに収められたデータ処理コンポーネントＣＯＭＰ１、ＣＯＭＰ２、ＣＯＭＰｉのそれぞれのためのハッシュ値Ｈ（ＣＯＭＰ１）、Ｈ（ＣＯＭＰ２）、Ｈ（ＣＯＭＰｉ）、ならびに利用可能であれば、車両識別子ＶＩＮ、および／または、パケットに収められたデータ処理コンポーネントＣＯＭＰ１、ＣＯＭＰ２、ＣＯＭＰｉを記述したものを含むマニフェストＥＣＵＰＡＣＫＩＮＤ
－ マニフェストＥＣＵＰＡＣＫＩＮＤの署名ＳＩＧ（ＥＣＵＰＡＣＫＩＮＤ）。

識別子ＶＩＮを提供するためのいくつかの変形形態が実行されてよい。上述のようにデバイスパケットＥＣＵＰＡＣＫに識別子ＶＩＮを含めることによって、電子機器（例えば車両のプロセッサ）にインストールされたデータ処理コンポーネントが本当にこの車両に帰するコンポーネントであることをデバイスパケットＥＣＵＰＡＣＫに保証することができる。これは、１つのコンポーネントが同じタイプの多くの車両に非常に適したものになり、例えば自分の車両のプロセッサを同じタイプの別の車両のプロセッサで置き替えるという可能性をユーザに提供するからである。デバイスパケットＥＣＵＰＡＣＫにＶＩＮ識別子を含めることによって、この操作を回避することができる。

１つの変形形態では、それでも、図３に示されている変形形態におけるケースのように、例えば下記で説明されるマニフェストＤＰＡＣＫＩＮＤ内に車両識別子ＶＩＮを入れることによって、この操作に権限付与することが、それでもなお可能である。このケースでは、マニフェストＤＰＡＣＫＩＮＤ内で受信された識別子ＶＩＮと、（この事例では処理ユニット４内に）格納されているような車両Ｖの識別子との間の肯定的比較の場合のみ、（処理ユニット４を使用して）デバイスパケットＥＣＵＰＡＣＫを当該の電子機器に伝送することを想定することが可能である。

想定され得る他の実施形態によれば、識別子ＶＩＮは、例えばナビゲーションシステムの地図データを含むデータ処理コンポーネントなどの、特にいずれの車両とも互換性のあるデータ処理コンポーネントのためのマニフェストＤＰＡＣＫＩＮＤとマニフェストＥＣＵＰＡＣＫＩＮＤの両方に入れられてよく、またはこれらの２つのマニフェストのどちらにも入れられなくてよい。

この事例では、車両Ｖの識別子ＶＩＮは、車両に一意に関連付けられた番号であり、一般にＶＩＮ「車両識別番号（Ｖｅｈｉｃｌｅ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｎｕｍｂｅｒ）」と呼ばれる。

ハッシュ値Ｈ（ＣＯＭＰ１）、Ｈ（ＣＯＭＰ２）、Ｈ（ＣＯＭＰｉ）は、例えば（当該の機器の要件、特にこの機器のアップデート要件による）デバイスパケットＥＣＵＰＡＣＫの定義中に、当該のデータ処理コンポーネントＣＯＭＰ１、ＣＯＭＰ２、ＣＯＭＰｉを構成するデータに（例えばタイプＳＨＡ－２５６の）ハッシュ関数をそれぞれ適用することによって取得される。

署名ＳＩＧ（ＥＣＵＰＡＣＫＩＮＤ）は、（製造業者の証明書Ｒ．ｃｅｒｔに関連付けられた）秘密鍵Ｒ．Ｋｐｒｉｖを使用する暗号署名アルゴリズムをマニフェストＥＣＵＰＡＣＫＩＮＤに適用することによって取得される。

例えば、これらの動作は、インストールされることになるデータ処理コンポーネントが、（識別子ＶＩＮを使用して識別された）特定の車両における当該の電子機器のために定義されるとき、車両製造業者によって（または車両製造業者の代わりに）実行される。

実際には、例えば署名ＳＩＧ（ＥＣＵＰＡＣＫＩＮＤ）は、例えばｃｍｓフォーマット（「暗号メッセージシンタックス（Ｃｒｙｐｔｏｇｒａｐｈｉｃ Ｍｅｓｓａｇｅ Ｓｙｎｔａｘ）」）内のフィールドなど、デバイスパケットＥＣＵＰＡＣＫに専用のフィールドに収められる。このケースでは、このフィールドは、署名ＳＩＧ（ＥＣＵＰＡＣＫＩＮＤ）、当局の証明書ＣＡ．ｃｅｒｔ、および製造業者の証明書Ｒ．ｃｅｒｔを含むことができる。

ダウンロードパケットＤＰＡＣＫは、以下を含む：
－ 上記で説明されたような、１つまたは複数のデバイスパケットＥＣＵＰＡＣＫ１、ＥＣＵＰＡＣＫ２、ＥＣＵＰＡＣＫｎ
－ 特にダウンロードパケットＤＰＡＣＫに収められたデバイスパケットＥＣＵＰＡＣＫ１、ＥＣＵＰＡＣＫ２、ＥＣＵＰＡＣＫｎのそれぞれのためのハッシュ値Ｈ（ＥＣＵＰＡＣＫ１）、Ｈ（ＥＣＵＰＡＣＫ２）、Ｈ（ＥＣＵＰＡＣＫｎ）、および利用可能であれば、（当該のデバイスパケットの対象電子機器の各デバイスパケットＥＣＵＰＡＣＫ１、ＥＣＵＰＡＣＫ２、ＥＣＵＰＡＣＫｎについての例えば指示と共に）ダウンロードパケットＤＰＡＣＫに収められたデバイスパケットＥＣＵＰＡＣＫ１、ＥＣＵＰＡＣＫ２、ＥＣＵＰＡＣＫｎを記述したものを含むマニフェストＤＰＡＣＫＩＮＤ
－ マニフェストＤＰＡＣＫＩＮＤの署名ＳＩＧ（ＤＰＡＣＫＩＮＤ）。

ハッシュ値Ｈ（ＥＣＵＰＡＣＫ１）、Ｈ（ＥＣＵＰＡＣＫ２）、Ｈ（ＥＣＵＰＡＣＫｎ）は、例えば、（対象電子機器、および機器のそれぞれについてのそれぞれの必要性の定義の後）ダウンロードパケットＤＰＡＣＫの定義中に、当該のデバイスパケットＥＣＵＰＡＣＫ１、ＥＣＵＰＡＣＫ２、ＥＣＵＰＡＣＫｎに（例えばタイプＳＨＡ－２５６の）ハッシュ関数をそれぞれ適用することによって取得される。

署名ＳＩＧ（ＤＰＡＣＫＩＮＤ）は、（製造業者の証明書Ｒ．ｃｅｒｔに関連付けられた）秘密鍵Ｒ．Ｋｐｒｉｖを使用する暗号署名アルゴリズムをマニフェストＤＰＡＣＫＩＮＤに適用することによって取得される。

例えば、これらの動作は、当該の電子機器、およびこれらの電子機器にインストールされることになるデータ処理コンポーネントが定義されるとき、車両製造業者によって（または車両製造業者の代わりに）実行される。

実際には、例えば、署名ＳＩＧ（ＤＰＡＣＫＩＮＤ）は、例えばｃｍｓフォーマット（「暗号メッセージシンタックス」）内のフィールドなど、ダウンロードパケットＤＰＡＣＫの専用フィールドに収められる。このケースでは、このフィールドは、署名ＳＩＧ（ＤＰＡＣＫＩＮＤ）、当局の証明書ＣＡ．ｃｅｒｔ、および製造業者の証明書Ｒ．ｃｅｒｔを含むことができる。

上記で説明されたアーキテクチャでは、データ処理コンポーネントＣＯＭＰ１、ＣＯＭＰ２、ＣＯＭＰｉのそれぞれは、インストールの対象になる車両Ｖから独立している（また例えば車両全体のために使用され得る）ことに留意されたい。それでもデバイスパケットＥＣＵＰＡＣＫ１、ＥＣＵＰＡＣＫ２、ＥＣＵＰＡＣＫｎ（および必然的にダウンロードパケットＤＰＡＣＫ）は、車両Ｖのために特に構成される。

図３は、ダウンロードパケットＤＰＡＣＫ内のデータの編成のために想定され得る変形形態を含む。

既に示されたように、この変形形態では、車両識別子ＶＩＮは、マニフェストＤＰＡＣＫＩＮＤ内に入れられる。

さらに、特定の電子機器に関するデータ処理コンポーネントＣＯＭＰ１、ＣＯＭＰ２、ＣＯＭＰｉは、この電子機器のためのデバイスパケットＥＣＵＰＡＣＫ１に含まれないが、代わりに、下記において説明されるように、利用可能であれば、デバイスパケットＥＣＵＰＡＣＫ１から別々に伝送可能にするために、電子機器の外部にある。

デバイスパケットＥＣＵＰＡＣＫ１は、この事例では、以下を含む：
－ 当該の電子機器に関連付けられたデータ処理コンポーネントＣＯＭＰ１、ＣＯＭＰ２、ＣＯＭＰｉのそれぞれのためのハッシュ値Ｈ（ＣＯＭＰ１）、Ｈ（ＣＯＭＰ２）、Ｈ（ＣＯＭＰｉ）を含むマニフェストＥＣＵＰＡＣＫＩＮＤ
－ マニフェストＥＣＵＰＡＣＫＩＮＤの署名ＳＩＧ（ＥＣＵＰＡＣＫＩＮＤ）。

本発明による車両Ｖ内にデータ処理コンポーネントをインストールするための方法の例が、図４を参照しながらここで説明される。

この方法はステップＥ２で始まり、ステップＥ２の間に、処理ユニット４は、リモートサーバＳに向けたリクエストＲＥＱを伝送する。このリクエストにより、車両Ｖは、例えば特定のソフトウェアコンポーネントまたは特定のデータ（地図データなど）をアップデートするために、データ処理コンポーネントが車両Ｖ内でのインストールに利用可能かどうかを決定しようとする。

例えば、リクエストＲＥＱは、処理ユニット４によって周期的に伝送される。実際には、例えばリモートサーバＳの電子座標（ｃｏｏｒｄｏｎｎｅｅｓ ｅｌｅｃｔｒｏｎｉｑｕｅｓ）が処理ユニット４内に格納され、リモートサーバＳに向けたリクエストＲＥＱを伝送するために使用される。電子座標は、ＳＳＬ（セキュアソケットレイヤ）などのセキュア接続を指すのが好ましい。

リクエストＲＥＱは、車両Ｖの識別子ＶＩＮを含むことができる。

リモートサーバＳはステップＥ４においてリクエストＲＥＱを受信し、データ処理コンポーネントが車両Ｖのためのダウンロードに利用可能かどうかを（例えばリクエストＲＥＱに含まれる識別子ＶＩＮに基づいて）決定する。

この事例では、データ処理コンポーネントが車両Ｖでのダウンロードおよびインストールに利用可能であると仮定される。必然的にサーバＳは、ステップＥ６においてグローバルコンテナＧＬＯＢを処理ユニット４に伝送する。

このグローバルコンテナＧＬＯＢは、マニフェストＤＰＡＣＫＩＮＤ、関連付けられた署名ＳＩＧ（ＤＰＡＣＫＩＮＤ）、およびデバイスパケットＥＣＵＰＡＣＫ１、ＥＣＵＰＡＣＫ２、ＥＣＵＰＡＣＫｎを含む。必然的に、実施形態によれば、このグローバルコンテナＧＬＯＢは、データ処理コンポーネントＣＯＭＰ１、ＣＯＭＰ２、ＣＯＭＰｉを備えるか、備えない。

これは、第１の実施形態によれば、このステップＥ６において、データ処理コンポーネントＣＯＭＰ１、ＣＯＭＰ２、ＣＯＭＰｉの全てまたは一部を伝送することもできるからである（したがって、ステップＥ６において伝送されたこれらのコンポーネントは、下記で説明されるステップＥ２６では伝送されない）。したがって、これらのデータ処理コンポーネントは、デバイスパケットＥＣＵＰＡＣＫ内で（例えば図２に示されているデータ構造のフレームワーク内で）、または、当該のデバイスパケットＥＣＵＰＡＣＫ１と共に（例えば図３に示されているデータ構造のフレームワーク内で）伝送されてよい。

第２の実施形態によれば、ステップＥ６において伝送されたグローバルコンテナＧＬＯＢは、データ処理コンポーネントＣＯＭＰ１、ＣＯＭＰ２、ＣＯＭＰｉのいずれも収めない（したがって、これらのデータ処理コンポーネントは、下記で説明されるステップＥ２６による１つまたは複数のステップの間に伝送される）。

処理ユニット４は、ステップＥ８においてグローバルコンテナＧＬＯＢを受信し、したがって、グローバルコンテナＧＬＯＢを格納することができる。グローバルコンテナＧＬＯＢは、この事例では、リモートサーバＳと車両Ｖとの間に確立された通信を介して直接的に受信され、この通信は、この事例では、既に言及された車両Ｖとセルラー電話ネットワークとの間の無線リンクを部分的に使用する。

１つの変形形態では、上記に示されているように、ステップＥ８において、リーダ１２に挿入された（またこれにより処理ユニット４に接続された）メモリカード２０からグローバルコンテナＧＬＯＢを（データ処理コンポーネントの有無に関わらず）受信することができる。ステップＥ２からＥ６は、このケースでは実行されない。

伝送されるグローバルコンテナＧＬＯＢがデータ処理コンポーネントＣＯＭＰ１、ＣＯＭＰ２、ＣＯＭＰｉ（またはこれらのうちの少なくともいくつか）を収めない実施形態では、受信されたグローバルコンテナＧＬＯＢを格納するために処理ユニット４内で必要とされるメモリサイズを削減できることに留意されたい。言い換えれば、ダウンロードパケットＤＰＡＣＫの全てを格納するのに適したバッファメモリを処理ユニット４内に用意する必要はない。

したがって処理ユニット４は、ステップＥ１０において、特に署名を検証するためにその後使用される公開鍵Ｒ．Ｋｐｕｂを収める製造業者の証明書Ｒ．ｃｅｒｔの検証を実行する。

上記に示されているように、証明書Ｒ．ｃｅｒｔは、この事例では、ダウンロードパケットＤＰＡＣＫの（およびしたがってステップＥ８において受信されたグローバルコンテナＧＬＯＢの）ｃｍｓフォーマットのフィールド内に収められる。

製造業者の証明書Ｒ．ｃｅｒｔを検証するために、公開鍵ＣＡ．Ｋｐｕｂを使用する暗号署名検証アルゴリズムが、署名Ｒ．ｓｉｇおよび署名済データ（この事例ではメタデータＲ．ｍｄおよび公開鍵Ｒ．Ｋｐｕｂ）に適用される。（公開鍵ＣＡ．Ｋｐｕｂは、上述のフォーマットＣＭＳでフィールドにそれ自体が収められた証明書ＣＡ．ｃｅｒｔの一部であることに留意されたい。）実際には、例えば、署名済データのハッシュ値と、公開鍵ＣＡ．Ｋｐｕｂを使用する（この事例ではＲＳＡタイプの）暗号アルゴリズムを署名Ｒ．ｓｉｇに適用することによって取得された結果とが比較される。

検証できない場合（つまり上述のハッシュ値と上述の結果を比較するステップにおいて等しくない場合）、インストールプロセスを終了し、利用可能であれば、エラーメッセージをリモートサーバＳに送信する。

ステップＥ１０において肯定的検証の場合（つまり上述のハッシュ値と上述の結果を比較するステップにおいて等しい場合）、処理ユニットは、含められたときの日時と、メタデータＲ．ｍｄに記載された有効期限の日時とを比較することによって、証明書Ｒ．ｃｅｒｔが期限切れになっていないかどうかを検証することができる。

証明書の有効期限が切れている場合、インストールプロセスを終了し、利用可能であれば、エラーメッセージをリモートサーバＳに送信する。

証明書が有効な場合、処理ユニット４はステップＥ１２において、（上記で説明されたように使用される公開鍵ＣＡ．Ｋｐｕｂを特に収める）当局の証明書ＣＡ．ｃｅｒｔの検証を実行する。

上記に示されているように、証明書ＣＡ．ｃｅｒｔは、この事例では、ダウンロードパケットＤＰＡＣＫの（およびしたがってステップＥ８において受信されたグローバルコンテナＧＬＯＢの）ｃｍｓフォーマットのフィールドに収められる。

当局の証明書ＣＡ．ｃｅｒｔを検証するために、公開鍵ＲＯＯＴ．Ｋｐｕｂを使用する暗号署名検証アルゴリズムが、署名ＣＡ．ｓｉｇおよび署名済データ（この事例では、メタデータＣＡ．ｍｄおよび公開鍵ＣＡ．Ｋｐｕｂ）に適用される。実際には、例えば、署名済データのハッシュ値と、公開鍵ＲＯＯＴ．ＫＰｕｂを使用する（この事例ではＲＳＡタイプの）暗号アルゴリズムを署名ＣＡ．ｓｉｇに適用することによって取得された結果とが比較される。

例えば、公開鍵ＲＯＯＴ．Ｋｐｕｂは、（処理ユニット４の製造中に）処理ユニット４の不揮発性メモリ内に格納される。

検証できない場合（つまり上述のハッシュ値と上述の結果を比較するステップにおいて等しくない場合）、インストールプロセスを終了し、利用可能であれば、エラーメッセージをリモートサーバＳに送信する。

ステップＥ１２において肯定的検証の場合（つまり上述のハッシュ値と上述の結果を比較するステップにおいて等しい場合）、処理ユニットは、含められたときの日時と、メタデータＣＡ．ｍｄに記載された有効期限の日時とを比較することによって、証明書ＣＡ．ｃｅｒｔが期限切れになっていないかどうかを検証することができる。

証明書の有効期限が切れている場合、インストールプロセスを終了し、利用可能であれば、エラーメッセージをリモートサーバＳに送信する。

証明書が有効な場合、所与の時間の日時と、メタデータＲＯＯＴ．ｍｄに記載されたルート証明書ＲＯＯＴ．ｃｅｒｔの有効期限の日時とを比較することによって、ルート証明書ＲＯＯＴ．ｃｅｒｔの有効性を同様に検証することができる。

証明書の有効期限が切れている場合、インストールプロセスを終了し、利用可能であれば、エラーメッセージをリモートサーバＳに送信する。

証明書が有効な場合、処理ユニット４はステップＥ１４において、ステップＥ８において受信されたグローバルコンテナＧＬＯＢの特定部分を検証する。

処理ユニットはステップＥ１４において、（グローバルコンテナＧＬＯＢの中で受信された）マニフェストＤＰＡＣＫＩＮＤの整合性を特に検証する。

このために、処理ユニットは、公開鍵Ｒ．Ｋｐｕｂを使用する暗号署名検証アルゴリズムを署名ＳＩＧ（ＤＰＡＣＫＩＮＤ）およびマニフェストＤＰＡＣＫＩＮＤに適用する。実際には、例えば、マニフェストＤＰＡＣＫＩＮＤのハッシュ値と、公開鍵Ｒ．Ｋｐｕｂを使用する（この事例ではＲＳＡタイプの）暗号アルゴリズムを署名ＳＩＧ（ＤＰＡＣＫＩＮＤ）に適用することによって取得された結果とが比較される。ステップＥ１０において、公開鍵Ｒ．Ｋｐｕｂを収める証明書Ｒ．ｃｅｒｔの有効性が検証されたことに留意されたい。

検証できない場合（つまり上述のハッシュ値と上述の結果を比較するステップにおいて等しくない場合）、インストールプロセスを終了し、利用可能であれば、エラーメッセージをリモートサーバＳに送信する。

ステップＥ１４において肯定的検証の場合（つまり上述のハッシュ値と上述の結果を比較するステップにおいて等しくない場合）、ステップＥ１６においてインストールプロセスを続け、ステップＥ１６はここで説明される。

処理ユニット４はステップＥ１６において、データ処理コンポーネントのインストールを担う電子機器（この事例では例えば第１の電子制御ユニット６および／またはゲートウェイ８）に様々なデバイスパケットＥＣＵＰＡＣＫを配布する。

各デバイスパケットＥＣＵＰＡＣＫは、当該の実施形態に応じて、データ処理コンポーネントＣＯＭＰ１、ＣＯＭＰ２、ＣＯＭＰｉ自体の有無に関わらず、特定の電子機器（この事例では、第１の電子制御ユニット６またはゲートウェイ８）のためのグローバルコンテナＧＬＯＢのデータ、つまり、この電子機器のためのデバイスパケットＥＣＵＰＡＣＫｎのデータを収める。

既に示されているように、実際には、ステップＥ６の中で、グローバルコンテナＧＬＯＢで伝送されることになる電子コンポーネントの全てまたは一部、およびしたがって、１つまたは複数のデータ処理コンポーネントを含むことになる少なくともいくつかのデバイスパケットＥＣＵＰＡＣＫを提供することができる。

したがって当該の各電子機器は、ステップＥ１８において、デバイスパケットＥＣＵＰＡＣＫを受信する。このような電子機器（この事例では第１の電子制御ユニット６またはゲートウェイ８）のための方法の実装形態が下記で説明されるが、実際にはデバイスパケットＥＣＵＰＡＣＫを受信する他の電子機器のために同様のステップが実行される。

したがって電子機器（この事例では第１の電子制御ユニット６またはゲートウェイ８）は、利用可能であれば、ステップＥ２０において、製造業者の証明書Ｒ．ｃｅｒｔおよび当局の証明書ＣＡ．ｃｅｒｔの検証のステップを実行することができる。この事例で説明される例では、これらの証明書Ｒ．ｃｅｒｔおよびＣＡ．ｃｅｒｔが、デバイスパケットＥＣＵＰＡＣＫのｃｍｓタイプのフィールドの一部であることに留意されたい。

（当該の電子機器６、８によって実行される）ステップＥ２０の検証は、上記で説明されたステップＥ１０およびＥ１２において処理ユニット４によって実行される検証と同様であり、ここでは詳細に説明されない。

ステップＥ２０において検証できない場合、当該の機器６、８内のインストールプロセスを終了する。さらにエラーメッセージを（例えばリモートサーバＳへの伝送の可能性のために）処理ユニット４に送信することができる。

ステップＥ２０において肯定的検証の場合、当該の電子機器６、８は、ステップＥ２２において、（デバイスパケットＥＣＵＰＡＣＫＩＮＤ内で受信された）マニフェストＥＣＵＰＡＣＫＩＮＤの整合性の検証を実行する。

このために、当該の電子機器６、８は、公開鍵Ｒ．Ｋｐｕｂを使用する暗号署名検証アルゴリズムを署名ＳＩＧ（ＥＣＵＰＡＣＫＩＮＤ）およびマニフェストＥＣＵＰＡＣＫＩＮＤに適用する。実際には、例えば、マニフェストＥＣＵＰＡＣＫＩＮＤのハッシュ値と、公開鍵Ｒ．Ｋｐｕｂを使用する（この事例ではＲＳＡタイプの）暗号アルゴリズムを署名ＳＩＧ（ＥＣＵＰＡＣＫＩＮＤ）に適用することによって取得された結果とが比較される。（公開鍵Ｒ．Ｋｐｕｂを収める証明書Ｒ．ｃｅｒｔの有効性がステップＥ２０の中で検証されたことに留意されたい。）

検証できない場合（つまり上述のハッシュ値と上述の結果を比較するステップにおいて等しくない場合）、当該の電子機器６、８におけるインストールプロセスを終了し、利用可能であれば、（例えばリモートサーバＳへの伝送の可能性のために）エラーメッセージを処理ユニット４に送信する。

ステップＥ２２において肯定的検証の場合（つまり上述のハッシュ値と上述の結果を比較するステップにおいて等しくない場合）、当該の電子機器６、８は、ステップＥ２４において、マニフェストＥＣＵＰＡＣＫＩＮＤに含まれる車両Ｖの識別子ＶＩＮが電子機器６、８内の（例えば不揮発性メモリに）格納された車両Ｖの識別子ＶＩＮに対応するかどうか（つまり実際に等しいかどうか）を検証する。

検証できない場合（つまりマニフェストＥＣＵＰＡＣＫＩＮＤ内で示された識別子ＶＩＮと格納された識別子とが等しくない場合）、当該の電子機器６、８におけるインストールプロセスを終了し、利用可能であれば、（例えばリモートサーバＳへの伝送の可能性のために）エラーメッセージを処理ユニット４に送信する。

ステップＥ２４において肯定的検証の場合（つまりマニフェストＥＣＵＰＡＣＫＩＮＤ内で示された識別子ＶＩＮと格納された識別子とが等しい場合）、インストールは、（ここで説明されるように、データ処理コンポーネントを受信した後）下記で説明されるステップＥ３２において続けることができる。

インストールを担う電子機器６、８内の言及された処理と同時に、リモートサーバＳは、ステップＥ２６において、ダウンロードパケットＤＰＡＣＫの少なくとも１つのデータ処理コンポーネントＣＯＭＰｉを処理ユニット４に伝送する。（これは図４に示されていないが、データ処理コンポーネントＣＯＭＰｉのこの伝送が、処理ユニット４からの指示がリモートサーバＳによって受信された後、開始されてよく、例えばこの指示は、データ処理コンポーネントＣＯＭＰｉを格納するためのバッファメモリ内の空間が十分であることを示す。）

処理ユニット４は、ステップＥ２８において、データ処理コンポーネントＣＯＭＰｉを受信する。

１つのデータ処理コンポーネントＣＯＭＰｉの処理がここで、下記で説明される。実際には、いくつかのデータ処理コンポーネントは、処理ユニット４のバッファメモリの容量に応じて同時にまたは後で受信され、データ処理コンポーネントＣＯＭＰｉについて説明されたように処理される。

ステップＥ２８において受信されたコンポーネントＣＯＭＰＩによって、（グローバルコンテナＧＬＯＢのデータを使用して）デバイスパケットＥＣＵＰＡＣＫｎを補足することが可能になると、処理ユニット４は、利用可能であれば、ステップＥ２９において、例えばマニフェストＤＰＡＣＫＩＮＤに収められたハッシュ値Ｈ（ＥＣＵＰＡＣＫｎ）と、受信されたときにデバイスパケットＥＣＵＰＡＣＫｎにハッシュ関数（この事例ではＳＨＡ２５６）を適用することによって取得されたハッシュ値とを比較することによって、当該のデバイスパケットＥＣＵＰＡＣＫｎのコンテンツの検証を実行することができる。

検証できない場合（つまりマニフェストＤＰＡＣＫＩＮＤのハッシュ値Ｈ（ＥＣＵＰＡＣＫｎ）が、受信されたデバイスパケットＥＣＵＰＡＣＫｎに基づいて取得されたハッシュ値とは異なる場合）、データ処理コンポーネントＣＯＭＰｉを当該の電子機器６、８に通信せず、利用可能であれば、エラーメッセージをリモートサーバＳに送信することができる。

ステップＥ２９において肯定的検証の場合、つまりマニフェストＤＰＡＣＫＩＮＤのハッシュ値Ｈ（ＥＣＵＰＡＣＫｎ）と、受信されたデバイスパケットＥＣＵＰＡＣＫｎに基づいて取得されたハッシュ値とが等しい場合、データ処理コンポーネントＣＯＭＰｉは、ステップＥ３０において、当該の電子機器６、８に配布される。

したがって当該の電子機器６、８は、ステップＥ３２において、データ処理コンポーネントＣＯＭＰｉを受信する。

したがって電子機器６、８は、このデータ処理コンポーネントＣＯＭＰｉを検証することができる。

まず第１に、ステップＥ３４において、電子機器６、８は、マニフェストＥＣＵＰＡＣＫＩＮＤに収められたハッシュ値Ｈ（ＣＯＭＰｉ）と、受信されたデータ処理コンポーネントＣＯＭＰｉにハッシュ関数（この事例ではＳＨＡ２５６）を適用することによって取得されたハッシュ値とを比較する。（ステップＥ２２においてマニフェストＥＣＵＰＡＣＫＩＮＤの整合性が検証されたことに留意されたい。）

否定的検証の場合（つまりマニフェストＥＣＵＰＡＣＫＩＮＤに収められたハッシュ値Ｈ（ＣＯＭＰｉ）が、取得されたハッシュ値とは異なる場合）、データ処理コンポーネントＣＯＭＰｉのインストールを終了する。

ステップＥ３４において肯定的検証の場合（つまりマニフェストＥＣＵＰＡＣＫＩＮＤに収められたハッシュ値Ｈ（ＣＯＭＰｉ）と、取得されたハッシュ値とが等しい場合）、データ処理コンポーネントＣＯＭＰｉの検証は、ステップＥ３６において続く。

電子機器６、８はまず、ステップＥ３６において、データ処理コンポーネントＣＯＭＰｉのマニフェストＣＯＭＰＩＮＤの整合性を検証する。

このために、当該の電子機器６、８は、公開鍵ＢＫ．Ｋｐｕｂを使用する暗号署名検証アルゴリズムを署名ＳＩＧ（ＣＯＭＰＩＮＤ）およびマニフェストＣＯＭＰＩＮＤに適用する。実際には、マニフェストＣＯＭＰＩＮＤのハッシュ値と、（この事例ではＲＳＡタイプの）暗号アルゴリズムの署名ＳＩＧ（ＣＯＭＰＩＮＤ）を適用することによって取得された結果とが、例えば、公開鍵ＢＫ．ＫＰｕｂを使用して比較される。

例えば公開鍵ＢＫ．Ｋｐｕｂは、当該の電子機器６、８の不揮発性メモリに格納される。

検証できない場合（つまり上述のハッシュ値と上述の結果を比較するステップにおいて等しくない場合）、データ処理コンポーネントＣＯＭＰｉのインストールプロセスを終了し、利用可能であれば、（例えばリモートサーバＳへの伝送の可能性のために）エラーメッセージを処理ユニット４に送信する。

署名ＳＩＧ（ＣＯＭＰＩＮＤ）の肯定的検証の場合（つまり上述のハッシュ値と上述の結果を比較するステップにおいて等しい場合）、電子機器６、８は、マニフェストＣＯＭＰＩＮＤに収められたハッシュ値Ｈ（ＣＯＮＴＥＮ）と、受信されたデータ処理コンポーネントＣＯＭＰｉのコンテンツＣＯＮＴＥＮにハッシュ関数（この事例ではＳＨＡ２５６）を適用することによって取得されたハッシュ値とを比較する。

検証できない場合（つまりマニフェストＣＯＭＰＩＮＤのハッシュ値Ｈ（ＣＯＮＴＥＮ）と取得されたハッシュ値とが等しくない場合）、データ処理コンポーネントＣＯＭＰｉのインストールプロセスを終了し、利用可能であれば、（例えばリモートサーバＳへの伝送の可能性のために）エラーメッセージを処理ユニット４に送信する。

肯定的検証の場合（つまりマニフェストＣＯＭＰＩＮＤのハッシュ値Ｈ（ＣＯＮＴＥＮ）と取得されたハッシュ値とが等しくない場合）、インストール方法は、ここで説明されるように続く。

例えば車両Ｖが熱機関を有する車両のケースでは、したがって、熱機関の動作を待つステップＥ３８を行うことができる（このステップにより、電子機器全てが動作しており、データ処理コンポーネントＣＯＭＰｉが当該の電子機器に正しくインストールできることを熱機関に実際に保証することができる）。

熱機関が動作可能なとき（または熱機関のない車両についてはこの条件はない）、当該の電子機器６、８は、その後使用されることを視野に入れて、データ処理コンポーネントＣＯＭＰｉのインストール、つまり不揮発性（書換え可能）メモリへのデータ処理コンポーネントＣＯＭＰｉの格納を制御する。

いくつかのケースでは（例えば第１の電子制御ユニット６については）、データ処理コンポーネントＣＯＭＰｉのインストールは、上記で説明された前の検証ステップＥ２０からＥ３６を実行したことがある電子機器自体（この事例では第１の電子制御ユニット６）の中で実行される。

対照的に他のケースでは（この事例では、ゲートウェイ８については）、インストールを担い、この文脈で前の検証ステップＥ２０からＥ３６を実行したことがある電子機器（この事例ではゲートウェイ８）は、別の電子機器、この事例では第２の電子制御ユニット１０内でのデータ処理コンポーネントＣＯＭＰｉのインストールを制御する。したがってゲートウェイ８は、例えば、第２の電子制御ユニット１０の不揮発性（書換え可能な）メモリへのデータ処理コンポーネントＣＯＭＰｉの格納を制御する。

この事例では、ここで説明されるように、インストールされてもすぐに使用される予定はないが、代わりに他の条件に従うときのデータ処理コンポーネントを提供する。

車両Ｖが熱機関を有する車両のとき、熱機関の動作が停止するのを待つステップＥ４２を使用することができる。

車両Ｖの熱機関が停止すると（または車両Ｖが熱機関を使用しないとき）、処理ユニット４は、データ処理コンポーネントがインストールされ、使用する準備が整ったという指示をユーザインターフェース（例えば車両Ｖの客室内に配置された画面）に表示する（ステップＥ４４）。

したがって処理ユニット４は、ステップＥ４６において、例えば上述のユーザインターフェース（利用可能であれば、この画面がタッチスクリーンのとき上述の画面）を介して、ユーザ（例えば車両Ｖのドライバ）からの応答を待つ。

ユーザの否定的応答のケースでは、ステップＥ４０においてインストールされたデータ処理コンポーネントは使用されない。

ステップＥ４６においてユーザの肯定的応答のケースでは、処理ユニット４は、当該の様々な電子機器に（この事例では第１の電子制御ユニット６に、およびゲートウェイ８を介して第２の電子制御ユニット１０に）、インストールされたデータ処理コンポーネントをアクティブにするためのコマンドＣＭＤを伝送する（ステップＥ４８）。

次に、インストールされたデータ処理コンポーネントをアクティブにする（ステップＥ５０）。

ソフトウェアデータ処理コンポーネントについては、次に、当該のデータ処理コンポーネントに含まれる命令は、データ処理コンポーネントがインストールされた電子機器６、１０のプロセッサによって実行されてよい。

操作可能なデータから形成されたデータ処理コンポーネントについては、当該のデータ処理コンポーネントに含まれるデータは、データ処理コンポーネントがインストールされた電子機器６、１０のプロセッサによって操作されてよい。

Claims (13)

1. 車両（Ｖ）に提供される電子機器（６、１０）内にデータ処理コンポーネント（ＣＯＭＰ１）をインストールするための方法であって、
   － 前記データ処理コンポーネントのハッシュ値（Ｈ（ＣＯＭＰ１））を含む第１のマニフェスト（ＥＣＵＰＡＣＫＩＮＤ）を含むデバイスパケット（ＥＣＵＰＡＣＫ）を受信すること（Ｅ１８）と、
   － 前記第１のマニフェスト（ＥＣＵＰＡＣＫＩＮＤ）の整合性を検証すること（Ｅ２２）と、
   － 前記データ処理コンポーネント（ＣＯＭＰ１）を受信すること（Ｅ３２）と、
   － 前記データ処理コンポーネントの前記ハッシュ値（Ｈ（ＣＯＭＰ１））と受信された前記データ処理コンポーネント（ＣＯＭＰ１）との間の対応関係を検証すること（Ｅ３４）と、
   － 前記第１のマニフェスト（ＥＣＵＰＡＣＫＩＮＤ）の前記整合性の肯定的検証、および前記対応関係の肯定的検証の場合のみ、前記データ処理コンポーネント（ＣＣＯＭＰ１）をインストールすること（Ｅ４０）と
   を伴うステップを含む、方法。
2. 前記第１のマニフェスト（ＥＣＵＰＡＣＫＩＮＤ）が、第１の車両識別子（ＶＩＮ）を含み、前記方法が、
   － 前記車両の第１の識別子（ＶＩＮ）を、前記車両（Ｖ）内に格納された前記車両の第２の識別子と比較すること（Ｅ２４）と、
   － 前記第１の識別子（ＶＩＮ）と前記第２の識別子との肯定的比較の場合のみ、前記データ処理コンポーネント（ＣＯＭＰ１）をインストールすること（Ｅ４０）と
   を伴うステップを含む、請求項１に記載の方法。
3. 前記デバイスパケット（ＥＣＵＰＡＣＫ）が、第１の署名（ＳＩＧ（ＥＣＵＰＡＣＫＩＮＤ））を含み、前記マニフェスト（ＥＣＵＰＡＣＫＩＮＤ）の前記整合性が、暗号署名検証アルゴリズムを前記第１の署名（ＳＩＧ（ＥＣＵＰＡＣＫＩＮＤ））および前記第１のマニフェスト（ＥＣＵＰＡＣＫＩＮＤ）に適用することによって検証される、請求項１または２に記載の方法。
4. 前記データ処理コンポーネント（ＣＯＭＰ１）が、前記デバイスパケット（ＥＣＵＰＡＣＫ）から独立して受信される、請求項１から３のいずれか一項に記載の方法。
5. 前記データ処理コンポーネント（ＣＯＭＰ１）が、前記デバイスパケット（ＥＣＵＰＡＣＫ）内で受信される、請求項１から３のいずれか一項に記載の方法。
6. － 前記デバイスパケット（ＥＣＵＰＡＣＫ）および第２のマニフェスト（ＤＰＡＣＫＩＮＤ）を含むコンテナ（ＧＬＯＢ）を受信すること（Ｅ８）と、
   － 前記第２のマニフェスト（ＤＰＡＣＫＩＮＤ）の整合性を検証すること（Ｅ１４）と
   を伴うステップを含む、請求項１から５のいずれか一項に記載の方法。
7. 前記コンテナ（ＧＬＯＢ）が、別の電子機器のための別のデバイスパケット（ＥＣＵＰＡＣＫ２）を含む、請求項６に記載の方法。
8. 前記第２のマニフェスト（ＤＰＡＣＫＩＮＤ）が、第１の車両識別子（ＶＩＮ）を含み、前記方法が、
   － 前記第１の車両識別子（ＶＩＮ）を、前記車両（Ｖ）内に格納された第２の車両識別子と比較すること（Ｅ１２）と、
   － 前記第１の識別子（ＶＩＮ）と前記第２の識別子との肯定的比較の場合のみ、前記デバイスパケット（ＥＣＵＰＡＣＫ）を伝送すること（Ｅ１６）と
   を伴うステップを含む、請求項６または７に記載の方法。
9. 前記コンテナ（ＧＬＯＢ）が、前記車両（Ｖ）によって伝送されたリクエスト（ＲＥＱ）に応答して、リモートサーバ（Ｓ）から受信される、請求項６から８のいずれか一項に記載の方法。
10. 前記コンテナ（ＧＬＯＢ）が、前記車両（Ｖ）に設置されたリーダ（１２）に挿入されたメモリカード（２０）から受信される、請求項６から８のいずれか一項に記載の方法。
11. 前記データ処理コンポーネント（ＣＯＭＰ１）が、第２の署名（ＳＩＧ（ＣＯＭＰＩＮＤ））およびコンテンツ（ＣＯＮＴＥＮ）を含み、前記方法が、前記第２の署名（ＳＩＧ（ＣＯＭＰＩＮＤ））を使用して前記コンテンツ（ＣＯＮＴＥＮ）の整合性を検証するステップ（Ｅ３６）を含む、請求項１から１０のいずれか一項に記載の方法。
12. 車両に提供するための電子機器（６、８）であって、
    － データ処理コンポーネントのハッシュ値（Ｈ（ＣＯＭＰｉ））を含むマニフェスト（ＥＣＵＰＡＣＫＩＮＤ）を含むデバイスパケット（ＥＣＵＰＡＣＫ）を受信するためのモジュールと、
    － 前記マニフェスト（ＥＣＵＰＡＣＫＩＮＤ）の整合性を検証するためのモジュールと、
    － 前記データ処理コンポーネント（ＣＯＭＰｉ）を受信するためのモジュールと、
    － 前記データ処理コンポーネントの前記ハッシュ値（Ｈ（ＣＯＭＰｉ））と、受信された前記データ処理コンポーネント（ＣＯＭＰｉ）との間の対応関係を検証するためのモジュールと、
    － 前記マニフェスト（ＥＣＵＰＡＣＫＩＮＤ）の前記整合性の肯定的検証、および前記対応関係の肯定的検証の場合のみ、前記データ処理コンポーネント（ＣＯＭＰｉ）をインストールするように構成されたインストールモジュールと
    を備える、電子機器（６、８）。
13. 前記マニフェスト（ＥＣＵＰＡＣＫＩＮＤ）が、前記車両の第１の識別子（ＶＩＮ）を含み、前記電子機器が、
    － 前記第１の識別子（ＶＩＮ）を、前記車両（Ｖ）内に格納された前記車両（Ｖ）の第２の識別子と比較するためのモジュール
    を備え、
    前記インストールモジュールが、前記マニフェスト（ＥＣＵＰＡＣＫＩＮＤ）の前記整合性の肯定的検証、前記第１の識別子（ＶＩＮ）と前記第２の識別子との肯定的比較、および前記対応関係の肯定的検証の場合のみ、前記データ処理コンポーネント（ＣＯＭＰｉ）をインストールするように構成される、請求項１２に記載の電子機器（６、８）。
    

Images