制御ユニット用のフラッシュウェアの正確性及び完全性を保証する方法
本発明は、現在の自動車のすべての制御装置においてできる限り使用され得る、簡略化された対称的な暗号方法に関する。前記方法は、アプリケーションプログラム、即ちフラッシュウェアに、秘密データストリングを連結し、連結されたアプリケーションプログラムからハッシュ値を計算することにより、安全な領域、即ち認証機関内で計算される認証コードに基づくものであり、前記ハッシュ値は、アプリケーションプログラム及び秘密データストリングの両方を用いて計算される。ハッシュ値とは、検査されるべきアプリケーションプログラムのための認証コードである。認証コードは、アプリケーションプログラムが使用されるマイクロプロセッサシステム内又は制御ユニット内で検証される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、制御ユニット内でソフトウェアをダウンロードするプロセスのためのセキュリティを確保する方法に関する。
【背景技術】
【０００２】
車両内での及び他の車両との通信が可能になるにつれて、自動車内の電子機器の存在がますます増加してきた。このため、セキュリティに対する要求も高まってきた。近頃、様々な技術領域における制御の目的に、マイクロコントローラが使用されている。これらの制御ユニットは、近頃しばしば、バスシステムを介して互いに接続され、通常、外部からこのバスにアクセスし、個々の制御ユニットと通信できるようになっている。ここでは、制御ユニットを機能させる方法は、アプリケーションプログラムによって決定される。これらのアプリケーションプログラムは、過去においては、通常、書き換えができないメモリ内、好ましくは制御ユニット内に格納されていた。この結果、ソフトウェアには、容易に手を加えることができない。たとえば、メモリモジュールが別のメモリモジュールに完全に置き換えられていることを検出し、これに対処することができる。しかし、プログラマブル制御ユニット、特にいわゆるフラッシュメモリを使ったプログラマブル制御ユニットが、車両内で将来使用されることになれば、アプリケーションプログラムに、したがって制御ユニットの操作方法に対して、不正な改ざんが行われる危険性が大きくなってくる。このため、制御ユニット内でのアプリケーションプログラムの不正な上書きを防止する対策を講じることが必要である。
【０００３】
フラッシュウェアと呼ばれるアプリケーションプログラムのための代表的なダウンロードプロセスが、特許文献１に開示されている。このシステムでは、フラッシュウェアと呼ばれるアプリケーションプログラムが、専門分野においてはフラッシュＥＰＲＯＭメモリ、又は略してフラッシュメモリと呼ばれる、不揮発性電気的消去可能プログラマブルメモリ内に格納される。このため、初期化ルーチンというプログラムが、電気的消去可能プログラマブル読み出し／書き込み用メモリ（フラッシュ）内のブート領域内に格納される。この初期化ルーチンは、マイクロプロセッサシステムを動作状態にする時に、ユーザプログラムをロードし、開始するために使用される。既存のアプリケーションプログラムを新しいものに取り替えることができるようにするために、初期化ルーチンは、さらに、いわゆる再書込ルーチンを含む。この再書込ルーチンは、システムインターフェースを介して特別な命令によって起動される。この起動後、再書込ルーチンは、まず最初に、バッファ内に新しいアプリケーションプログラムを取り込む。新しいアプリケーションプログラムの格納に誤りがあったかどうか検査するために、巡回ブロック保護方法が使用される。新しいアプリケーションプログラムが伝送され、正しくバッファされると、取り替えられるべきユーザプログラムの消去が、始動され、行われる。このため、新しいアプリケーションプログラムは、消去可能プログラマブル読み出し／書き込み用メモリ（フラッシュ）内で古いアプリケーションプログラムに上書きされる。プログラムし、フラッシュにコピーするというこのプロセスも、巡回ブロック保護方法によって検査され得る。巡回ブロック保護方法による検査は、プログラムがどの程度正しくコピーされたかを検査することができるだけである。データの正確さ及び完全である状態の検査は、巡回ブロック保護方法では不可能である。不正プログラム又は不正フラッシュウェアは、巡回ブロック保護方法では検出され得ない。
【０００４】
他方、暗号方法及びディジタル署名方法が、インターネットの分野で、特にホームバンキング及びホームショッピングのアプリケーションにおいて知られている。今日一般に普及している、基本的な暗号方法は、いわゆる公開鍵暗号方式である。これらの暗号化アルゴリズムは秘密鍵及び公開鍵で動作し、公開鍵は公開されうるものであるが、秘密鍵は許可された当事者、たとえば認証機関のみが知るものである。このような暗号アルゴリズムとは、たとえば、リベスト、シャミール、アデルマンにより開発された方式（ＲＳＡ方式）や、類似する暗号化アルゴリズム（ＤＥＡアルゴリズム）である。秘密又は公開鍵を用いて、手書き署名と同様の形で、電子文書用のディジタル署名を作成することができる。秘密又は公開鍵のユーザのみが、有効な署名を作成することができる。次いで、その文書が本物であるかどうかは、関連付けられた公開又は秘密鍵を用いて、その署名を検証することによって検査され得る。秘密鍵は、時に、プライベートキーとも呼ばれる。
【０００５】
電子署名は、署名の方法として知られてきた。電子署名の目的は、あるメッセージが確実に一定の送信者から来たものであり、このメッセージが伝送中に変造されていないことを保証することである。
【０００６】
送信者が公開鍵及び秘密鍵を生成した場合、次に、以下の方法が考えられる。
【０００７】
情報の送信者は、自分自身の秘密鍵を使用して、その送信者の公開鍵で読み取ることのできるメッセージを暗号化する。その公開鍵で読み取ることのできるメッセージは、その送信者から発信されたもののみであるはずである。何故なら、その送信者のみが、一致する秘密鍵を有しているからである。システムとしては、秘密鍵は暗号化用にのみ使用され、公開鍵は復号又は読取り用にのみ使用され得るようになっている。したがって、１人の人物によってのみ書き込まれ得るが、公開鍵を有するすべての人によって読み取られ得るメッセージが作成されることになる。
【０００８】
メッセージ全体の暗号化は、前述の暗号化方法を用いると、比較的演算時間を要するため、著者が本人であることのみを明らかにするためには、メッセージ全体の暗号化は不必要である。このため、実際には、やや異なる方法が使用される。
・ 送信者は、ハッシュコードと呼ばれる、メッセージの一種の要約又はチェックサムを計算する。この計算規則は、ハッシュコードを変更せずにメッセージ自体を変更することが実質上不可能である。
・ 次いで、送信者は、自分の秘密鍵でハッシュコードを暗号化する。これが電子署名である。したがって、署名は、それぞれのメッセージで異なり、メッセージの長さに関係なく、署名の長さのみが常に同じである。これは、常に同じ長さを有するハッシュコードの特性である。
・ 次いで、メッセージが、署名と共に送信される。
・ 受信者は、送信者の公開鍵で署名を復号し、次いで、送信者から取得したハッシュコードを受信する。
・ 次いで、受信者自身が、送信されたメッセージからハッシュコードを作成し、送信者により送信されてきたハッシュコードと比較する。両方のハッシュコードが一致していると、メッセージが実際に１人の送信者から発信されたものであり、伝送経路上で変造されていないことが保証される。
【０００９】
前述の署名方法は、復号のための方法は公開鍵方法ＲＳＡに基づくものであり、ハッシュコードの計算のための署名方法は、ハッシュ関数ＲＩＰＥＭＤ−１６０に基づくものである。
【００１０】
最後に、暗号化と電子署名とを組み合わせることにより、確実にかつ曖昧でなく送信者に割り当てられ得るメッセージを、変造なく送信することができる。
【００１１】
特許文献２において、自動車内の制御ユニット用のソフトウェアのデータが完全である状態を保証するための署名方法が、前述の暗号化方法及び署名方法に基づいて提案されている。この方法により、公開鍵は、制御ユニットのメモリ領域内に格納される。フラッシュウェアと呼ばれる、新たに書き込まれるソフトウェアは、第２の秘密鍵で署名される。署名されたソフトウェアをダウンロードするために、このフラッシュウェアは、まず最初に、制御ユニットのメモリ内に格納される。フラッシュウェアの署名は、制御ユニット自体内に格納されている公開鍵で検査される。電子署名の検査が肯定的な結果を有する場合には、バッファされたフラッシュウェアが、フラッシュメモリと呼ばれる、制御ユニットの電子的に消去可能プログラマブルメモリに書き込まれる。
【００１２】
制御ユニットには、移動小数点演算をサポートすることができない、又は十分なメモリ空間を利用できないものがあるので、すべての制御ユニットが、公開鍵アルゴリズムを実行できるわけではない。ＲＳＡ方式の信頼性を確実にするために、現在では、鍵の長さとして、少なくとも１０２４バイトが選択されるべきである。したがって、自動車内で現在使用されている制御ユニットの多くにおいて、前述の署名方法を使用することができない。
【００１３】
【特許文献１】独国特許発明第１９５０６９５７Ｃ２号明細書
【特許文献２】独国特許出願公開第１０００８９７４Ａ１号明細書
【発明の開示】
【発明が解決しようとする課題】
【００１４】
本発明の目的は、前述の先行技術を出発点として、現代の自動車内のすべての制御ユニットで、できる限り使用され得る、簡略化された署名方法を提供することである。
【課題を解決するための手段】
【００１５】
上記目的は、本発明に従って、独立請求項の特徴を有する方法によって達成される。本発明のさらに好ましい改良形態が、従属請求項及び例示的実施形態についての記述に記載されている。
【００１６】
上記目的は、簡略化された対称的な暗号方法によって達成される。この方法の基礎は、認証コードである。この認証コードは、フラッシュウェアと呼ばれるアプリケーションプログラムに秘密のデータストリングを連結し、連結されたアプリケーションプログラムに対してハッシュ値を計算することにより、認証機関と呼ばれる安全な領域内で計算される。このハッシュ値は、ここでは、アプリケーションプログラムと秘密データストリングを用いて計算される。このハッシュ値は、検査されるべきアプリケーションプログラム用の認証コードである。認証コードは、アプリケーションプログラムが使用されるマイクロプロセッサシステム内又は制御ユニット内で検査される。このため、第２の同一の秘密データストリングが、マイクロプロセッサシステム又は制御ユニット内に格納される。まず最初に、暗号化されていないアプリケーションプログラム及び認証コードが、マイクロプロセッサシステム内に又は制御ユニット内に伝送される。次いで、暗号化されていないアプリケーションプログラムが、マイクロプロセッサシステム内で又は制御ユニット内で、第２の同一の秘密データストリングに連結される。ハッシュ値が、マイクロプロセッサシステム内で又は制御ユニット内で、この連結されたアプリケーションプログラムに対して計算される。計算されたハッシュ値及び伝送された認証コードが一致していると、伝送されたアプリケーションプログラム又は伝送されたフラッシュウェアは、正確であると考えられ、フラッシュメモリ内に格納され、制御ユニット内に又はマイクロプロセッサシステム内に適用され得る。本発明の発展形態においては、アプリケーションプログラムには、プログラムの前端及びプログラムの後端において、両端部で秘密データストリングを連結してもよい。次いで、ハッシュ値が、両端部で連結されたアプリケーションプログラムによって計算される。マイクロプロセッサシステム内で又は制御ユニット内で、このようにして形成された認証コードを検査するために、暗号化されていない形式で伝送されたアプリケーションプログラムに対して、制御ユニット内に格納されている第２の秘密データストリングを両端部で付加し、両端部に連結されたアプリケーションプログラムに対して、制御ユニット内で又はマイクロプロセッサシステム内でハッシュ値が計算される。制御ユニット内で又はマイクロプロセッサシステム内で計算されたハッシュ値が、伝送された認証コードと一致していると、伝送されたアプリケーションプログラムは、正確であると考えられる。秘密データストリングを両端部で連結することは、アプリケーションソフトウェアの容認できない改ざんに対する保護が、より改良されるという利点を有する。
【００１７】
改ざんについてのさらなる改良形態が、ハッシュ値を２回計算することによって得られる。本発明のこの実施形態においては、アプリケーションプログラムは、まず最初に、一方の端部に秘密データストリングが付加され、次いでその一方の端部で連結されたアプリケーションプログラムに対してハッシュ値が計算される。連結は、ここでは、プログラムの前端及びプログラムの後端であり得る。この第１のハッシュ値ＨＭＡＣ１は、一方の端部でこの秘密データストリングに連結される。この連結は、ここでは、第１のハッシュ値の両端で行われても良い。最後に、認証コードを計算するために、第２のハッシュ値ＨＭＡＣが、さらに次のステップで、データストリングと第１のハッシュ値ＨＭＡＣ１との組合せによって計算される。制御ユニット内で又はマイクロプロセッサシステム内で認証コードを検査するために、マイクロプロセッサシステム内で又は制御ユニット内で、前述の計算ステップを同じシーケンスで繰り返さなければならない。したがって、計算されたハッシュ値が伝送された認証コードに一致していると、伝送されたアプリケーションソフトウェアには、誤りがないと考えられる。
【００１８】
フラッシュウェア自体をダウンロードするプロセスについては、様々な伝送の可能性がある。フラッシュウェア及び認証コードが、同じ伝送チャネル上で一緒に送られることもあれば、認証コードが、アプリケーションプログラムにより別個の伝送チャネル上で別々に送られることもある。別個の伝送については、ハードウェア記憶媒体上にフラッシュウェア又はアプリケーションプログラムを読み込む（ｍａｒｋｅｔ）ことが好ましい。コンパクトディスク、ＥＰＲＯＭ、又はメモリカードが、好ましい記憶媒体として可能なものである。
【００１９】
システムのフラッシュメモリ内に伝送されるべきアプリケーションプログラムが、正常に認証された場合には、新しいアプリケーションプログラムに、フラグと呼ばれる識別子が設けられることが好ましい。この識別子は、アプリケーションプログラムをそれぞれ有効なアプリケーションプログラムとして識別するために用いられる。
【００２０】
本発明は、主に、以下の利点を達成する。
【００２１】
制御ユニットには、移動小数点方式をサポートすることができない、又は必要な暗号化計算を行うことができる十分なメモリ空間を利用できないものがあるので、すべての制御ユニットが、公開鍵アルゴリズムを計算できるわけではない。公開鍵アルゴリズムを確実に形成できるようにするためには、現在、少なくとも１０２４バイトが、鍵の長さとして選択されるべきである。自動車内の多くの制御ユニットは、４キロバイトのメモリ領域しか有さないので、鍵だけで既にメモリの大きな部分を占める。本発明は、ここでは暗号化アルゴリズムを必要としない。使用される１つの計算方法は、ハッシュ値を計算することである。本発明による対称的な暗号方法を用いることにより、これらの制御ユニットに、公開鍵方法が適用できない認証検査を備えることもできる。
【００２２】
本発明による方法は、ハッシュ値の計算に基づく、いわゆるメッセージ認証コード方法である。したがって、署名方法はない。署名方法は、メッセージの受信者が、これも供給される署名をコピーすることができないことを義務付ける。埋め込みシステム、たとえば制御ユニット内のアプリケーションについては、受信側の制御ユニットは、メッセージ用のメッセージ認証コードを自動的に形成しないので、署名方法は不要である。制御ユニットは、与えられたメッセージ用の与えられた秘密データストリングを、単に検査するだけである。伝送経路を確保するために、ハッシュ値を計算することが必要である。本発明によれば、実際には、メッセージ認証コードのハッシュ値のみが伝送され、秘密データストリングは伝送されない。提案された、本発明によるハッシュ値方法は、実行時間及びメモリ空間の点で、たとえば公開鍵アルゴリズムなどの数式化及び復号方法より極めて効率的である。
【００２３】
フラッシュウェアメタ情報も、認証コード内に含まれ得る。フラッシュウェアメタ情報とは、たとえば、フラッシュウェアの記憶場所、フラッシュウェアの識別番号、制御ユニットの識別番号、又は車両識別番号である。このフラッシュウェアメタ情報は、秘密データストリング内に統合される。したがって、フラッシュウェアによる及び秘密データストリングによるハッシュ値の形成により、フラッシュウェアメタ情報も伝送経路上での改ざんに対して保護されることが保証される。
【００２４】
複数の制御ユニットで同じフラッシュウェアが使用される場合、認証コード内にフラッシュウェアメタ情報を含むことにより、この認証コードを用いて、様々な制御ユニット内へのフラッシュウェアのダウンロードプロセスを選択できる。様々な制御ユニットが様々な識別番号を有し、かつ様々な制御ユニット内のフラッシュウェア用の記憶場所が異なっているので、たとえフラッシュウェアが同じであっても、それぞれ、本発明による方法による、制御ユニット特有の認証コードがある。
【００２５】
以下、図を参照しながら、本発明の例示的実施形態についてより詳細に説明する。
【発明を実施するための最良の形態】
【００２６】
図１は、本発明が使用され得るダウンロードプロセスを示している。プログラムの開発が終結した後、アプリケーションプログラム及び／又はフラッシュウェアは、記憶装置１内に収集される。個々のアプリケーションプログラム又はフラッシュウェア２が、安全な経路上で、いわゆる認証機関３に転送される。アプリケーションプログラムは、認証機関自体内の認証コードで識別される。以下、図３〜図６と合わせて、認証機関自体内のシーケンスについてより詳細に説明する。暗号化されていないフラッシュウェアが、認証コードＨＭＡＣと共に、認証機関から外部システムインターフェース４に転送される。システムインターフェース自体は、最も簡単な方法では、自動車内に設けられた診断接続部として構成され得る。しかし一般には、システムインターフェースは、自動車整備工場内の診断システムによって形成される。認証機関からシステムインターフェースに伝送するために、ここでは、通常のデータ通信経路、つまり特に固定ネットワーク接続、インターネット接続、また移動無線接続を使用することができる。システムインターフェースは、伝送されたプログラムパッケージ、又は伝送されたフラッシュウェア、及び認証コードＨＭＡＣを、自動車の制御ユニット内にダウンロードするプロセスを生じさせる。このため、システムインターフェースは、自動車内のフラッシュウェアメモリをダウンロードプロセスのために準備する特別なコマンドを、自動車内の制御ユニットに伝送する。以下、図７と合わせて、新しいアプリケーションプログラムのフラッシュメモリへのプログラミングについてより詳細に説明する。伝送された認証コードＨＭＡＣは、自動車の制御ユニット内で検査され、検査が成功した場合には、これも伝送されたフラッシュウェアが、制御ユニットのフラッシュメモリ内に格納される。自動車の制御ユニット内の認証コードの検査は、基本的に、認証機関内で認証コードが生成されるステップを繰り返すことによって行われる。以下、図３〜図６についての記述において、認証コードの検査についてより詳細に記載する。
【００２７】
図２は、本発明によるダウンロードプロセスの別の可能性を示している。この例示的実施形態においても、アプリケーションプログラムは、記憶装置１内に格納されている。次いで、フラッシュウェアと呼ばれるアプリケーションプログラムは、プログラムパッケージ２として認証機関に転送される。認証コードが、認証機関３内でフラッシュウェア用に生成される。以下、図５及び図６と合わせて、認証コードの計算についてより詳細に説明する。図１のダウンロードプロセスとは異なり、ここに記述されているダウンロードプロセスを用いると、認証コードＨＭＡＣのみが、認証機関からシステムインターフェース４に伝送される。アプリケーションプログラム自体、いわゆるフラッシュウェアは、別個の伝送チャネル上で転送される。フラッシュウェアは、コンパクトディスク、記憶カード、ＥＰＲＯＭ、又は他のハードウェア記憶手段６に記録され、好適な読取り装置７を用いて、自動車の制御ユニット５内に伝送されることが好ましい。特にコンパクトディスクの場合には、自動車内の好適な読取り装置７は、今日自動車内で使用されているような映像／音響システムにより、特にＣＤ−ＲＯＭディスクドライブ又はＤＶＤディスクドライブによって形成されることがある。図２の例示的実施形態においては、ダウンロードプロセスはまた、車両内で、システムインターフェース４からの特別なコマンドによって始動される。このため、システムインターフェース４は、自動車内のＬＡＮへのアクセス機能を有する。読取り装置７から制御ユニット５へのフラッシュウェアの読取りは、システムインターフェースにより、ソフトウェアコマンドを用いて開始される。同時に、ソフトウェアコマンドは、フラッシュウェアを転送するために、制御ユニット５のフラッシュメモリを準備するために使用される。以下、図５及び図６についての記述において、制御ユニット内での認証コードＨＭＡＣの検査についてより詳細に説明する。基本的に、認証コードを検査するために、認証コードを作成するのに必要な計算ステップを、認証機関内と同じ順序で、制御ユニット内で繰り返さなければならない。この例示的実施形態においては、システムインターフェースはまた、最も簡単な場合、自動車内の診断接続部によって形成され得る。しかし、システムインターフェースは、自動車整備工場内の診断システム（テスター）であることが好ましい。
【００２８】
前述した認証コードの検査は、フラッシュウェア用の伝送経路の選択に関係なく適用される。認証シーケンスは、ＣＤ−ＲＯＭ又はＤＶＤからフラッシュウェアをダウンロードする場合と、無線又は有線通信によるデータ伝送方法を用いて中央システムからフラッシュウェアを直接ダウンロードする場合は、同じである。
【００２９】
本発明のすべての例示的実施形態は、共通して、ハッシュ値の計算を行う。ＲＩＰＥＭＤ−１６０アルゴリズムという呼称で知られているハッシュ関数は、所望の長さのデータ用の固定長の、コピーとも呼ばれる検査値を生成するために使用され得る。このコピーが、ハッシュ値と呼ばれる。ハッシュ関数及びハッシュ値が、ここでは、以下の特性を満たす。
・ ハッシュ値は、計算が簡単である。
・ 与えられたハッシュ値に基づいて、このハッシュ値の計算元のデータレコードを復元することが、殆ど不可能である（一方向性機能）。その上、衝突、即ち同じハッシュ値を有する２つのデータレコードを発見することが困難である（耐衝突性）。
・ ハッシュ関数は、そのビット長が最大２６４−１であるデータ又はデータレコード用にのみ適用され得る。比較的短いデータレコードの場合には、データレコードは、記入されたデータレコードの長さが５１２ビットの整数倍を有するまで、ゼロで満たされる。次いで、記入されたデータレコードは、少なくとも５１２ビット長のブロックに分割される。ハッシュ関数を５１２ビット長のブロックに適用した結果、最後に、１６０ビット長のハッシュ値が生じる。この関数は、ここでは、所望のデータレコードに、特にフラッシュウェアにも適用され得る。
【００３０】
図３は、以下認証機関と呼ばれる安全な領域３内で、認証コードを計算するための流れ図を示している。認証機関において、データストリングの形態の秘密識別子が、別個の安全な領域、好ましくは別個の安全な記憶装置８内にディジタル形式で管理される。認証コードが計算されるフラッシュウェアは、最初に、その両端部においてデータストリングが連結される。つまり、認証機関のメモリ８からの秘密データストリングが、アプリケーションプログラムのコードの先端部及び後端部において付加される。次のステップで、両端部に連結されたコード全体を用いて、フラッシュウェアのためのハッシュ値が計算される。このハッシュ値は、フラッシュウェア及び秘密データストリングの両方の情報を用いて作成される。前述したハッシュ関数の特性により、このハッシュ値は、フラッシュウェアの、正確さ及びデータが完全である状態のための認証コードＨＭＡＣとして好適である。次のステップで、認証コードＨＭＡＣが、暗号化されていないアプリケーションプログラム、いわゆるフラッシュウェアに追加され、自動車へのさらなるダウンロードのために、認証機関からシステムインターフェースに転送される。
【００３１】
図４は、認証機関内で認証コードを計算するためのより複雑なシーケンスを示している。この例示的実施形態においては、フラッシュウェアは、まず最初に、一方の端部に秘密データストリングが付加される。連結は、フラッシュウェアのデータレコードの前端又は後端のいずれかで行われ得る。一方の端部に秘密データストリングが連結されたフラッシュウェアに対して、第１のハッシュ値計算が行われ、第１のハッシュ値ＨＭＡＣ１が作成される。この第１のハッシュ値ＨＭＡＣ１の一方の端部に、メモリ８からの秘密データストリングが付加される。ここでも、連結は、第１のハッシュ値の前端又は後端に行われ得る。さらなるステップで、第２のハッシュ値計算が、秘密データストリングと第１のハッシュ値が組み合わされたデータストリングに対して行われる。この最後のハッシュ値計算の結果、認証コードＨＭＡＣが得られる。次いで、暗号化されていない元のフラッシュウェアが、認証コードに追加され、システムインターフェースに伝送される。図４の例示的実施形態は、図１のダウンロードプロセスに好適である。
【００３２】
図５は、図２のダウンロードプロセスで使用するための、認証機関内の認証コードの計算を示す流れ図を示している。認証機関において、暗号化されていない元のフラッシュウェアの両端部で、秘密データストリングが連結される。次のステップで、両端部に秘密データストリングが連結されたフラッシュウェアのハッシュ値が計算される。このハッシュ値計算の結果が、認証コードＨＭＡＣである。図３の例示的実施形態とは異なり、図５の例示的実施形態においては、認証コードのみがシステムインターフェースに伝送される。元の及び暗号化されていないフラッシュウェアの読み込み（ｍａｒｋｅｔｉｎｇ）は、ここでは、別個の伝送チャネル上で行われる。フラッシュウェアは、ここでは、ハード的な記憶手段に格納され、そこから自動車に読み込まれることが好ましい（これのより詳細については、図２参照）。
【００３３】
図６は、図２のダウンロードプロセスと合わせて使用されるような認証コードの、より複雑な計算のさらなる例示的実施形態を示している。この例示的実施形態においては、まず最初に、暗号化されていないフラッシュウェアの一方の端部に、認証機関内の秘密データストリングが連結される。連結は、ここでは、フラッシュウェアのデータレコードの先端又は後端のいずれかに行われ得る。ハッシュ値計算が、一方の端部で連結されたフラッシュウェアによって行われる。この結果が、第１のハッシュ値ＨＭＡＣ１である。この第１のハッシュ値ＨＭＡＣ１は、一方の端部で、メモリ８からの秘密データストリングに連結される。ここでも、連結は、第１のハッシュ値の先端又は後端部で行われ得る。さらなるステップで、第２のハッシュ値計算が、秘密データストリングと第１のハッシュ値との組合せに対して行われる。この最後のハッシュ値計算の結果、認証コードＨＭＡＣが得られる。この認証コードは、システムインターフェースに転送される。図４の例示的実施形態とは異なり、図６の例示的実施形態においては、認証コードのみがシステムインターフェースに転送される。ここでは、図２と同様に、暗号化されていない元のソフトウェアが、記憶媒体、好ましくはコンパクトディスクを介して自動車に読み込まれる。
【００３４】
以下、図７を参照しながら、自動車の制御ユニット内の又はマイクロプロセッサシステム内のフラッシュプロセスについてより詳細に記載する。電子制御ユニットＥＣＵなどの代表的な制御ユニットは、マイクロプロセッサＣＰＵなどの演算装置を含み、この演算装置はプロセッサバスＰＢＵＳを介して様々なメモリ又はメモリセクタに接続される。制御ユニットは、インターフェースを介して、外部からアドレス付けされ得るか、又はインターフェースに接続された他のユニットと通信できる。制御ユニットのメモリは、ブートセクタと、フラッシュメモリと、主記憶装置ＲＡＭとからなる。フラッシュメモリ「Ｆｌａｓｈ」は、電気的消去可能プログラマブルメモリ、たとえばＥＥＰＲＯＭである。フラッシュブートローダと呼ばれる、マイクロプロセッサのオペレーティングシステム、及びハッシュ関数用のＲＩＰＥＭＤ−１６０アルゴリズムが、ブートセクタ内に格納される。秘密データストリングが、外部アクセスに対して特別に保護されているメモリ又はメモリ領域内の制御ユニット内に格納される。この特別に保護されているデータ領域９は、ブート領域内に配置されても良い。また別の方法として、この特別に保護されているデータメモリ９を、上書きされ得ず、かつ不正な読取りに対して保護されているメモリカードの形態で、又は不正なアクセスが試みられた場合にそのコンテンツを消去する、いわゆるクリプトプロセッサの形態で具現化することも可能である。特別に保護されているメモリ領域９の、これらの手段及び実施形態は、ここに格納されているデータストリングの秘密が守られることを保証する。データストリングを特別に保護されているデータ領域９内でプログラムすることは、認証機関内で認証コードを計算するためのデータストリングと調整されなければならない。制御ユニット内のデータストリングは、認証コードを計算するための基礎として使用されたデータストリングと一致していなければならない。
【００３５】
フラッシュウェアとして使用され得るアプリケーションプログラムは、制御ユニットのフラッシュＦｌａｓｈ内に格納される。既に格納されているユーザプログラムが、基本的に以下の方法で、新しいフラッシュウェアにより上書きされる。制御ユニットでは、外部システムインターフェースから制御ユニットのインターフェースを介して伝送される特別なソフトウェアコマンドにより、ダウンロードプロセス及びフラッシュプロセスのための準備がなされる。いわゆるフラッシュブートローダは、ソフトウェアコマンドによって作動する。フラッシュブートローダは、基本的に、アプリケーションプログラムを制御ユニットのフラッシュメモリ内に書き込む再書込ルーチンである。ダウンロードプロセス中に、新しいフラッシュウェア及び伝送された認証コードが、まず最初に、制御ユニットの主記憶装置内にバッファされる。次いで、フラッシュブートローダの再書込ルーチンを用いて、バッファされたフラッシュウェアと認証コードの正確さ及びデータの完全性の保証ための検査が、制御ユニットのマイクロプロセッサ内で行われる。この検査は、伝送される認証コードを生成するために適用された同じ方法ステップが、暗号化されていないソフトウェア、及び制御ユニット内に格納されている秘密データストリングを用いて、マイクロプロセッサ内で行われるような形で行われる。したがって、認証コードを生成するために、認証機関内で行われるこれらの方法ステップが、制御ユニットのマイクロプロセッサ内で繰り返される。たとえば、図３の例示的実施形態に従って、制御ユニットのマイクロプロセッサ内で、認証コードが生成されると、バッファされたフラッシュウェアの両端部に、制御ユニット内に格納されている秘密データストリングが連結される。両端部で連結されたフラッシュウェアは、ＲＩＰＥＭＤ−１６０アルゴリズムを用いてハッシュ値計算を行う。制御ユニット内のこのハッシュ値計算の結果が、伝送された識別コードＨＭＡＣと比較される。両方のハッシュ値が同一であると、主記憶装置内にバッファされたフラッシュウェアは、正確でありかつ完全であると考えられる。図３、図４、図５、又は図６に対応する例示的実施形態の１つに従って、認証機関内の認証コードが取得されると、バッファされたフラッシュウェアの、制御ユニット内に格納されている秘密データストリングとの連結、及び制御ユニット内で又は制御ユニットのマイクロプロセッサ内で検査するための連結されたフラッシュウェアのハッシュ値計算が、それぞれ、転送される認証コードを生成するために認証機関内で行われるような形で行われなければならない。制御ユニットのマイクロプロセッサで取得されたハッシュ値と転送された認証コードとが対応していると、これらの比較により、それぞれ、主記憶装置内にバッファされた、伝送されたフラッシュウェアのデータの正確さ及び完全である状態についての決定的な情報がもたらされる。両方の値が一致していると、フラッシュウェアは、それぞれ、誤りがないと考えられる。
【００３６】
新しくダウンロードされ、かつバッファされたフラッシュウェアの検査が成功した後、フラッシュブートローダは、新しいバッファされたフラッシュウェアを制御ユニットのフラッシュメモリに書き込む。主記憶装置からフラッシュメモリへのコピープロセスが、さらにここで、巡回ブロック保護方法で完全性について検査され得る。正確さの検査及びコピープロセスに誤りがないと、いわゆるフラグが、フラッシュ内に置かれるフラッシュウェア用に設定される。このフラグが、有効なものとして使用されるアプリケーションプログラムとして、現在フラッシュ内に置かれているアプリケーションプログラムを識別する。図７に例として示されているように、フラグは、たとえばここでは、フラッシュメモリ自体内で設定でき、フラッシュメモリは、ＥＥＰＲＯＭとして具現化されることが好ましい。次いで、制御ユニットは、アプリケーションの実行に移ることができるようになり、その過程で、有効なフラグで識別されたアプリケーションプログラムを使用する。
【００３７】
フラッシュブートローダは、整備工場内の診断システムによって起動することが好ましい。この場合、整備工場の診断システムは、システムインターフェース４を形成する。図１のダウンロードプロセスの場合には、暗号化されていないフラッシュウェア及び認証コードが共に、システムインターフェースによりインターフェースを介して、制御ユニットの主記憶装置内にバッファされる。図２のダウンロードプロセスの場合には、認証コードは、システムインターフェースを介して制御ユニットの主記憶装置内にバッファされ、暗号化されていないフラッシュウェアは、さらなる読取り装置、好ましくはＣＤ−ＲＯＭディスクドライブ又はチップカード読取り装置を介して、制御ユニットの主記憶装置内にバッファされる。したがって、図２のダウンロードプロセスの場合には、フラッシュブートローダの再書込ルーチンは、適宜、異なる電子データ処理システムから、必要とされるデータレコードをダウンロードしなければならない。しかし、すべての場合において、車両内の通信は、自動車の内部データバスを介して行われる。自動車内の、近頃一般に普及しているデータバスが、いわゆるＣＡＮバスである。
【００３８】
自動車内のすべての制御ユニットが、フラッシュウェアをバッファできる十分なメモリ空間を有するわけではない。したがって、既存のメモリ領域がダウンロードされたフラッシュウェアをバッファするのに十分でない制御ユニットの場合には、ダウンロードプロセスは、以下の通り行われる。
− まず最初に、既存のフラッシュメモリが消去される。
− 次いで、新しいフラッシュウェアが、ダウンロードされ、プログラムされる。
− 次いで、ダウンロードされたフラッシュウェアが、検証される。つまり、伝送誤りについて検査される。
− 次いで、上記の例示的実施形態と同様に、認証検査が行われる。
− 正確さの検査が肯定的であった後、ダウンロードされたフラッシュウェアが、状態ビットの形態のフラグを設定することによって識別され、作動する。
− 次いで、次のアプリケーションが、新しいフラッシュウェアにアクセスする。
【００３９】
フラッシュウェアをバッファせずに直接ダウンロードすると、ダウンロードプロセス中の書き込みプロセスにおいて書き込み誤りも検出されるので、「エンドツーエンド」保護というさらなる利点を有する。
【００４０】
本発明のすべての例示的実施形態において、フラッシュウェアは、これに追加される、いわゆるメタ情報を有し得る。このフラッシュウェアメタ情報とは、特に、車両識別番号、制御ユニット部品番号、又はフラッシュウェアのための特別なメモリ位置である。フラッシュウェアメタ情報を含むことにより、たとえば、新しくダウンロードされるべきフラッシュウェア用の記憶位置を選択することができる。フラッシュウェアメタ情報も認証コードの計算に含まれるので、このフラッシュウェアメタ情報も、改ざんに対して保護される。
【図面の簡単な説明】
【００４１】
【図１】記憶装置から自動車の制御ユニットに、フラッシュウェアをダウンロードするプロセスを示す概略図である。
【図２】フラッシュウェア及び認証コードが別個の伝送チャネル上で自動車の制御ユニットに入る、フラッシュウェアをダウンロードするプロセスを示す図である。
【図３】図１のダウンロードプロセス用の認証コードの計算を示す流れ図である。
【図４】図１のダウンロードプロセス用の認証コードの計算を示す、より複雑な流れ図である。
【図５】図２のダウンロードプロセス用の認証コードの計算を示す流れ図である。
【図６】図２のダウンロードプロセス用の認証コードの計算を示す、より複雑な流れ図である。
【図７】本発明による方法に従って、アプリケーションプログラムがこの中にダウンロードされ得るフラッシュメモリを備えた、マイクロプロセッサシステム又は制御ユニットを示すブロック図である。
【技術分野】
【０００１】
本発明は、制御ユニット内でソフトウェアをダウンロードするプロセスのためのセキュリティを確保する方法に関する。
【背景技術】
【０００２】
車両内での及び他の車両との通信が可能になるにつれて、自動車内の電子機器の存在がますます増加してきた。このため、セキュリティに対する要求も高まってきた。近頃、様々な技術領域における制御の目的に、マイクロコントローラが使用されている。これらの制御ユニットは、近頃しばしば、バスシステムを介して互いに接続され、通常、外部からこのバスにアクセスし、個々の制御ユニットと通信できるようになっている。ここでは、制御ユニットを機能させる方法は、アプリケーションプログラムによって決定される。これらのアプリケーションプログラムは、過去においては、通常、書き換えができないメモリ内、好ましくは制御ユニット内に格納されていた。この結果、ソフトウェアには、容易に手を加えることができない。たとえば、メモリモジュールが別のメモリモジュールに完全に置き換えられていることを検出し、これに対処することができる。しかし、プログラマブル制御ユニット、特にいわゆるフラッシュメモリを使ったプログラマブル制御ユニットが、車両内で将来使用されることになれば、アプリケーションプログラムに、したがって制御ユニットの操作方法に対して、不正な改ざんが行われる危険性が大きくなってくる。このため、制御ユニット内でのアプリケーションプログラムの不正な上書きを防止する対策を講じることが必要である。
【０００３】
フラッシュウェアと呼ばれるアプリケーションプログラムのための代表的なダウンロードプロセスが、特許文献１に開示されている。このシステムでは、フラッシュウェアと呼ばれるアプリケーションプログラムが、専門分野においてはフラッシュＥＰＲＯＭメモリ、又は略してフラッシュメモリと呼ばれる、不揮発性電気的消去可能プログラマブルメモリ内に格納される。このため、初期化ルーチンというプログラムが、電気的消去可能プログラマブル読み出し／書き込み用メモリ（フラッシュ）内のブート領域内に格納される。この初期化ルーチンは、マイクロプロセッサシステムを動作状態にする時に、ユーザプログラムをロードし、開始するために使用される。既存のアプリケーションプログラムを新しいものに取り替えることができるようにするために、初期化ルーチンは、さらに、いわゆる再書込ルーチンを含む。この再書込ルーチンは、システムインターフェースを介して特別な命令によって起動される。この起動後、再書込ルーチンは、まず最初に、バッファ内に新しいアプリケーションプログラムを取り込む。新しいアプリケーションプログラムの格納に誤りがあったかどうか検査するために、巡回ブロック保護方法が使用される。新しいアプリケーションプログラムが伝送され、正しくバッファされると、取り替えられるべきユーザプログラムの消去が、始動され、行われる。このため、新しいアプリケーションプログラムは、消去可能プログラマブル読み出し／書き込み用メモリ（フラッシュ）内で古いアプリケーションプログラムに上書きされる。プログラムし、フラッシュにコピーするというこのプロセスも、巡回ブロック保護方法によって検査され得る。巡回ブロック保護方法による検査は、プログラムがどの程度正しくコピーされたかを検査することができるだけである。データの正確さ及び完全である状態の検査は、巡回ブロック保護方法では不可能である。不正プログラム又は不正フラッシュウェアは、巡回ブロック保護方法では検出され得ない。
【０００４】
他方、暗号方法及びディジタル署名方法が、インターネットの分野で、特にホームバンキング及びホームショッピングのアプリケーションにおいて知られている。今日一般に普及している、基本的な暗号方法は、いわゆる公開鍵暗号方式である。これらの暗号化アルゴリズムは秘密鍵及び公開鍵で動作し、公開鍵は公開されうるものであるが、秘密鍵は許可された当事者、たとえば認証機関のみが知るものである。このような暗号アルゴリズムとは、たとえば、リベスト、シャミール、アデルマンにより開発された方式（ＲＳＡ方式）や、類似する暗号化アルゴリズム（ＤＥＡアルゴリズム）である。秘密又は公開鍵を用いて、手書き署名と同様の形で、電子文書用のディジタル署名を作成することができる。秘密又は公開鍵のユーザのみが、有効な署名を作成することができる。次いで、その文書が本物であるかどうかは、関連付けられた公開又は秘密鍵を用いて、その署名を検証することによって検査され得る。秘密鍵は、時に、プライベートキーとも呼ばれる。
【０００５】
電子署名は、署名の方法として知られてきた。電子署名の目的は、あるメッセージが確実に一定の送信者から来たものであり、このメッセージが伝送中に変造されていないことを保証することである。
【０００６】
送信者が公開鍵及び秘密鍵を生成した場合、次に、以下の方法が考えられる。
【０００７】
情報の送信者は、自分自身の秘密鍵を使用して、その送信者の公開鍵で読み取ることのできるメッセージを暗号化する。その公開鍵で読み取ることのできるメッセージは、その送信者から発信されたもののみであるはずである。何故なら、その送信者のみが、一致する秘密鍵を有しているからである。システムとしては、秘密鍵は暗号化用にのみ使用され、公開鍵は復号又は読取り用にのみ使用され得るようになっている。したがって、１人の人物によってのみ書き込まれ得るが、公開鍵を有するすべての人によって読み取られ得るメッセージが作成されることになる。
【０００８】
メッセージ全体の暗号化は、前述の暗号化方法を用いると、比較的演算時間を要するため、著者が本人であることのみを明らかにするためには、メッセージ全体の暗号化は不必要である。このため、実際には、やや異なる方法が使用される。
・ 送信者は、ハッシュコードと呼ばれる、メッセージの一種の要約又はチェックサムを計算する。この計算規則は、ハッシュコードを変更せずにメッセージ自体を変更することが実質上不可能である。
・ 次いで、送信者は、自分の秘密鍵でハッシュコードを暗号化する。これが電子署名である。したがって、署名は、それぞれのメッセージで異なり、メッセージの長さに関係なく、署名の長さのみが常に同じである。これは、常に同じ長さを有するハッシュコードの特性である。
・ 次いで、メッセージが、署名と共に送信される。
・ 受信者は、送信者の公開鍵で署名を復号し、次いで、送信者から取得したハッシュコードを受信する。
・ 次いで、受信者自身が、送信されたメッセージからハッシュコードを作成し、送信者により送信されてきたハッシュコードと比較する。両方のハッシュコードが一致していると、メッセージが実際に１人の送信者から発信されたものであり、伝送経路上で変造されていないことが保証される。
【０００９】
前述の署名方法は、復号のための方法は公開鍵方法ＲＳＡに基づくものであり、ハッシュコードの計算のための署名方法は、ハッシュ関数ＲＩＰＥＭＤ−１６０に基づくものである。
【００１０】
最後に、暗号化と電子署名とを組み合わせることにより、確実にかつ曖昧でなく送信者に割り当てられ得るメッセージを、変造なく送信することができる。
【００１１】
特許文献２において、自動車内の制御ユニット用のソフトウェアのデータが完全である状態を保証するための署名方法が、前述の暗号化方法及び署名方法に基づいて提案されている。この方法により、公開鍵は、制御ユニットのメモリ領域内に格納される。フラッシュウェアと呼ばれる、新たに書き込まれるソフトウェアは、第２の秘密鍵で署名される。署名されたソフトウェアをダウンロードするために、このフラッシュウェアは、まず最初に、制御ユニットのメモリ内に格納される。フラッシュウェアの署名は、制御ユニット自体内に格納されている公開鍵で検査される。電子署名の検査が肯定的な結果を有する場合には、バッファされたフラッシュウェアが、フラッシュメモリと呼ばれる、制御ユニットの電子的に消去可能プログラマブルメモリに書き込まれる。
【００１２】
制御ユニットには、移動小数点演算をサポートすることができない、又は十分なメモリ空間を利用できないものがあるので、すべての制御ユニットが、公開鍵アルゴリズムを実行できるわけではない。ＲＳＡ方式の信頼性を確実にするために、現在では、鍵の長さとして、少なくとも１０２４バイトが選択されるべきである。したがって、自動車内で現在使用されている制御ユニットの多くにおいて、前述の署名方法を使用することができない。
【００１３】
【特許文献１】独国特許発明第１９５０６９５７Ｃ２号明細書
【特許文献２】独国特許出願公開第１０００８９７４Ａ１号明細書
【発明の開示】
【発明が解決しようとする課題】
【００１４】
本発明の目的は、前述の先行技術を出発点として、現代の自動車内のすべての制御ユニットで、できる限り使用され得る、簡略化された署名方法を提供することである。
【課題を解決するための手段】
【００１５】
上記目的は、本発明に従って、独立請求項の特徴を有する方法によって達成される。本発明のさらに好ましい改良形態が、従属請求項及び例示的実施形態についての記述に記載されている。
【００１６】
上記目的は、簡略化された対称的な暗号方法によって達成される。この方法の基礎は、認証コードである。この認証コードは、フラッシュウェアと呼ばれるアプリケーションプログラムに秘密のデータストリングを連結し、連結されたアプリケーションプログラムに対してハッシュ値を計算することにより、認証機関と呼ばれる安全な領域内で計算される。このハッシュ値は、ここでは、アプリケーションプログラムと秘密データストリングを用いて計算される。このハッシュ値は、検査されるべきアプリケーションプログラム用の認証コードである。認証コードは、アプリケーションプログラムが使用されるマイクロプロセッサシステム内又は制御ユニット内で検査される。このため、第２の同一の秘密データストリングが、マイクロプロセッサシステム又は制御ユニット内に格納される。まず最初に、暗号化されていないアプリケーションプログラム及び認証コードが、マイクロプロセッサシステム内に又は制御ユニット内に伝送される。次いで、暗号化されていないアプリケーションプログラムが、マイクロプロセッサシステム内で又は制御ユニット内で、第２の同一の秘密データストリングに連結される。ハッシュ値が、マイクロプロセッサシステム内で又は制御ユニット内で、この連結されたアプリケーションプログラムに対して計算される。計算されたハッシュ値及び伝送された認証コードが一致していると、伝送されたアプリケーションプログラム又は伝送されたフラッシュウェアは、正確であると考えられ、フラッシュメモリ内に格納され、制御ユニット内に又はマイクロプロセッサシステム内に適用され得る。本発明の発展形態においては、アプリケーションプログラムには、プログラムの前端及びプログラムの後端において、両端部で秘密データストリングを連結してもよい。次いで、ハッシュ値が、両端部で連結されたアプリケーションプログラムによって計算される。マイクロプロセッサシステム内で又は制御ユニット内で、このようにして形成された認証コードを検査するために、暗号化されていない形式で伝送されたアプリケーションプログラムに対して、制御ユニット内に格納されている第２の秘密データストリングを両端部で付加し、両端部に連結されたアプリケーションプログラムに対して、制御ユニット内で又はマイクロプロセッサシステム内でハッシュ値が計算される。制御ユニット内で又はマイクロプロセッサシステム内で計算されたハッシュ値が、伝送された認証コードと一致していると、伝送されたアプリケーションプログラムは、正確であると考えられる。秘密データストリングを両端部で連結することは、アプリケーションソフトウェアの容認できない改ざんに対する保護が、より改良されるという利点を有する。
【００１７】
改ざんについてのさらなる改良形態が、ハッシュ値を２回計算することによって得られる。本発明のこの実施形態においては、アプリケーションプログラムは、まず最初に、一方の端部に秘密データストリングが付加され、次いでその一方の端部で連結されたアプリケーションプログラムに対してハッシュ値が計算される。連結は、ここでは、プログラムの前端及びプログラムの後端であり得る。この第１のハッシュ値ＨＭＡＣ１は、一方の端部でこの秘密データストリングに連結される。この連結は、ここでは、第１のハッシュ値の両端で行われても良い。最後に、認証コードを計算するために、第２のハッシュ値ＨＭＡＣが、さらに次のステップで、データストリングと第１のハッシュ値ＨＭＡＣ１との組合せによって計算される。制御ユニット内で又はマイクロプロセッサシステム内で認証コードを検査するために、マイクロプロセッサシステム内で又は制御ユニット内で、前述の計算ステップを同じシーケンスで繰り返さなければならない。したがって、計算されたハッシュ値が伝送された認証コードに一致していると、伝送されたアプリケーションソフトウェアには、誤りがないと考えられる。
【００１８】
フラッシュウェア自体をダウンロードするプロセスについては、様々な伝送の可能性がある。フラッシュウェア及び認証コードが、同じ伝送チャネル上で一緒に送られることもあれば、認証コードが、アプリケーションプログラムにより別個の伝送チャネル上で別々に送られることもある。別個の伝送については、ハードウェア記憶媒体上にフラッシュウェア又はアプリケーションプログラムを読み込む（ｍａｒｋｅｔ）ことが好ましい。コンパクトディスク、ＥＰＲＯＭ、又はメモリカードが、好ましい記憶媒体として可能なものである。
【００１９】
システムのフラッシュメモリ内に伝送されるべきアプリケーションプログラムが、正常に認証された場合には、新しいアプリケーションプログラムに、フラグと呼ばれる識別子が設けられることが好ましい。この識別子は、アプリケーションプログラムをそれぞれ有効なアプリケーションプログラムとして識別するために用いられる。
【００２０】
本発明は、主に、以下の利点を達成する。
【００２１】
制御ユニットには、移動小数点方式をサポートすることができない、又は必要な暗号化計算を行うことができる十分なメモリ空間を利用できないものがあるので、すべての制御ユニットが、公開鍵アルゴリズムを計算できるわけではない。公開鍵アルゴリズムを確実に形成できるようにするためには、現在、少なくとも１０２４バイトが、鍵の長さとして選択されるべきである。自動車内の多くの制御ユニットは、４キロバイトのメモリ領域しか有さないので、鍵だけで既にメモリの大きな部分を占める。本発明は、ここでは暗号化アルゴリズムを必要としない。使用される１つの計算方法は、ハッシュ値を計算することである。本発明による対称的な暗号方法を用いることにより、これらの制御ユニットに、公開鍵方法が適用できない認証検査を備えることもできる。
【００２２】
本発明による方法は、ハッシュ値の計算に基づく、いわゆるメッセージ認証コード方法である。したがって、署名方法はない。署名方法は、メッセージの受信者が、これも供給される署名をコピーすることができないことを義務付ける。埋め込みシステム、たとえば制御ユニット内のアプリケーションについては、受信側の制御ユニットは、メッセージ用のメッセージ認証コードを自動的に形成しないので、署名方法は不要である。制御ユニットは、与えられたメッセージ用の与えられた秘密データストリングを、単に検査するだけである。伝送経路を確保するために、ハッシュ値を計算することが必要である。本発明によれば、実際には、メッセージ認証コードのハッシュ値のみが伝送され、秘密データストリングは伝送されない。提案された、本発明によるハッシュ値方法は、実行時間及びメモリ空間の点で、たとえば公開鍵アルゴリズムなどの数式化及び復号方法より極めて効率的である。
【００２３】
フラッシュウェアメタ情報も、認証コード内に含まれ得る。フラッシュウェアメタ情報とは、たとえば、フラッシュウェアの記憶場所、フラッシュウェアの識別番号、制御ユニットの識別番号、又は車両識別番号である。このフラッシュウェアメタ情報は、秘密データストリング内に統合される。したがって、フラッシュウェアによる及び秘密データストリングによるハッシュ値の形成により、フラッシュウェアメタ情報も伝送経路上での改ざんに対して保護されることが保証される。
【００２４】
複数の制御ユニットで同じフラッシュウェアが使用される場合、認証コード内にフラッシュウェアメタ情報を含むことにより、この認証コードを用いて、様々な制御ユニット内へのフラッシュウェアのダウンロードプロセスを選択できる。様々な制御ユニットが様々な識別番号を有し、かつ様々な制御ユニット内のフラッシュウェア用の記憶場所が異なっているので、たとえフラッシュウェアが同じであっても、それぞれ、本発明による方法による、制御ユニット特有の認証コードがある。
【００２５】
以下、図を参照しながら、本発明の例示的実施形態についてより詳細に説明する。
【発明を実施するための最良の形態】
【００２６】
図１は、本発明が使用され得るダウンロードプロセスを示している。プログラムの開発が終結した後、アプリケーションプログラム及び／又はフラッシュウェアは、記憶装置１内に収集される。個々のアプリケーションプログラム又はフラッシュウェア２が、安全な経路上で、いわゆる認証機関３に転送される。アプリケーションプログラムは、認証機関自体内の認証コードで識別される。以下、図３〜図６と合わせて、認証機関自体内のシーケンスについてより詳細に説明する。暗号化されていないフラッシュウェアが、認証コードＨＭＡＣと共に、認証機関から外部システムインターフェース４に転送される。システムインターフェース自体は、最も簡単な方法では、自動車内に設けられた診断接続部として構成され得る。しかし一般には、システムインターフェースは、自動車整備工場内の診断システムによって形成される。認証機関からシステムインターフェースに伝送するために、ここでは、通常のデータ通信経路、つまり特に固定ネットワーク接続、インターネット接続、また移動無線接続を使用することができる。システムインターフェースは、伝送されたプログラムパッケージ、又は伝送されたフラッシュウェア、及び認証コードＨＭＡＣを、自動車の制御ユニット内にダウンロードするプロセスを生じさせる。このため、システムインターフェースは、自動車内のフラッシュウェアメモリをダウンロードプロセスのために準備する特別なコマンドを、自動車内の制御ユニットに伝送する。以下、図７と合わせて、新しいアプリケーションプログラムのフラッシュメモリへのプログラミングについてより詳細に説明する。伝送された認証コードＨＭＡＣは、自動車の制御ユニット内で検査され、検査が成功した場合には、これも伝送されたフラッシュウェアが、制御ユニットのフラッシュメモリ内に格納される。自動車の制御ユニット内の認証コードの検査は、基本的に、認証機関内で認証コードが生成されるステップを繰り返すことによって行われる。以下、図３〜図６についての記述において、認証コードの検査についてより詳細に記載する。
【００２７】
図２は、本発明によるダウンロードプロセスの別の可能性を示している。この例示的実施形態においても、アプリケーションプログラムは、記憶装置１内に格納されている。次いで、フラッシュウェアと呼ばれるアプリケーションプログラムは、プログラムパッケージ２として認証機関に転送される。認証コードが、認証機関３内でフラッシュウェア用に生成される。以下、図５及び図６と合わせて、認証コードの計算についてより詳細に説明する。図１のダウンロードプロセスとは異なり、ここに記述されているダウンロードプロセスを用いると、認証コードＨＭＡＣのみが、認証機関からシステムインターフェース４に伝送される。アプリケーションプログラム自体、いわゆるフラッシュウェアは、別個の伝送チャネル上で転送される。フラッシュウェアは、コンパクトディスク、記憶カード、ＥＰＲＯＭ、又は他のハードウェア記憶手段６に記録され、好適な読取り装置７を用いて、自動車の制御ユニット５内に伝送されることが好ましい。特にコンパクトディスクの場合には、自動車内の好適な読取り装置７は、今日自動車内で使用されているような映像／音響システムにより、特にＣＤ−ＲＯＭディスクドライブ又はＤＶＤディスクドライブによって形成されることがある。図２の例示的実施形態においては、ダウンロードプロセスはまた、車両内で、システムインターフェース４からの特別なコマンドによって始動される。このため、システムインターフェース４は、自動車内のＬＡＮへのアクセス機能を有する。読取り装置７から制御ユニット５へのフラッシュウェアの読取りは、システムインターフェースにより、ソフトウェアコマンドを用いて開始される。同時に、ソフトウェアコマンドは、フラッシュウェアを転送するために、制御ユニット５のフラッシュメモリを準備するために使用される。以下、図５及び図６についての記述において、制御ユニット内での認証コードＨＭＡＣの検査についてより詳細に説明する。基本的に、認証コードを検査するために、認証コードを作成するのに必要な計算ステップを、認証機関内と同じ順序で、制御ユニット内で繰り返さなければならない。この例示的実施形態においては、システムインターフェースはまた、最も簡単な場合、自動車内の診断接続部によって形成され得る。しかし、システムインターフェースは、自動車整備工場内の診断システム（テスター）であることが好ましい。
【００２８】
前述した認証コードの検査は、フラッシュウェア用の伝送経路の選択に関係なく適用される。認証シーケンスは、ＣＤ−ＲＯＭ又はＤＶＤからフラッシュウェアをダウンロードする場合と、無線又は有線通信によるデータ伝送方法を用いて中央システムからフラッシュウェアを直接ダウンロードする場合は、同じである。
【００２９】
本発明のすべての例示的実施形態は、共通して、ハッシュ値の計算を行う。ＲＩＰＥＭＤ−１６０アルゴリズムという呼称で知られているハッシュ関数は、所望の長さのデータ用の固定長の、コピーとも呼ばれる検査値を生成するために使用され得る。このコピーが、ハッシュ値と呼ばれる。ハッシュ関数及びハッシュ値が、ここでは、以下の特性を満たす。
・ ハッシュ値は、計算が簡単である。
・ 与えられたハッシュ値に基づいて、このハッシュ値の計算元のデータレコードを復元することが、殆ど不可能である（一方向性機能）。その上、衝突、即ち同じハッシュ値を有する２つのデータレコードを発見することが困難である（耐衝突性）。
・ ハッシュ関数は、そのビット長が最大２６４−１であるデータ又はデータレコード用にのみ適用され得る。比較的短いデータレコードの場合には、データレコードは、記入されたデータレコードの長さが５１２ビットの整数倍を有するまで、ゼロで満たされる。次いで、記入されたデータレコードは、少なくとも５１２ビット長のブロックに分割される。ハッシュ関数を５１２ビット長のブロックに適用した結果、最後に、１６０ビット長のハッシュ値が生じる。この関数は、ここでは、所望のデータレコードに、特にフラッシュウェアにも適用され得る。
【００３０】
図３は、以下認証機関と呼ばれる安全な領域３内で、認証コードを計算するための流れ図を示している。認証機関において、データストリングの形態の秘密識別子が、別個の安全な領域、好ましくは別個の安全な記憶装置８内にディジタル形式で管理される。認証コードが計算されるフラッシュウェアは、最初に、その両端部においてデータストリングが連結される。つまり、認証機関のメモリ８からの秘密データストリングが、アプリケーションプログラムのコードの先端部及び後端部において付加される。次のステップで、両端部に連結されたコード全体を用いて、フラッシュウェアのためのハッシュ値が計算される。このハッシュ値は、フラッシュウェア及び秘密データストリングの両方の情報を用いて作成される。前述したハッシュ関数の特性により、このハッシュ値は、フラッシュウェアの、正確さ及びデータが完全である状態のための認証コードＨＭＡＣとして好適である。次のステップで、認証コードＨＭＡＣが、暗号化されていないアプリケーションプログラム、いわゆるフラッシュウェアに追加され、自動車へのさらなるダウンロードのために、認証機関からシステムインターフェースに転送される。
【００３１】
図４は、認証機関内で認証コードを計算するためのより複雑なシーケンスを示している。この例示的実施形態においては、フラッシュウェアは、まず最初に、一方の端部に秘密データストリングが付加される。連結は、フラッシュウェアのデータレコードの前端又は後端のいずれかで行われ得る。一方の端部に秘密データストリングが連結されたフラッシュウェアに対して、第１のハッシュ値計算が行われ、第１のハッシュ値ＨＭＡＣ１が作成される。この第１のハッシュ値ＨＭＡＣ１の一方の端部に、メモリ８からの秘密データストリングが付加される。ここでも、連結は、第１のハッシュ値の前端又は後端に行われ得る。さらなるステップで、第２のハッシュ値計算が、秘密データストリングと第１のハッシュ値が組み合わされたデータストリングに対して行われる。この最後のハッシュ値計算の結果、認証コードＨＭＡＣが得られる。次いで、暗号化されていない元のフラッシュウェアが、認証コードに追加され、システムインターフェースに伝送される。図４の例示的実施形態は、図１のダウンロードプロセスに好適である。
【００３２】
図５は、図２のダウンロードプロセスで使用するための、認証機関内の認証コードの計算を示す流れ図を示している。認証機関において、暗号化されていない元のフラッシュウェアの両端部で、秘密データストリングが連結される。次のステップで、両端部に秘密データストリングが連結されたフラッシュウェアのハッシュ値が計算される。このハッシュ値計算の結果が、認証コードＨＭＡＣである。図３の例示的実施形態とは異なり、図５の例示的実施形態においては、認証コードのみがシステムインターフェースに伝送される。元の及び暗号化されていないフラッシュウェアの読み込み（ｍａｒｋｅｔｉｎｇ）は、ここでは、別個の伝送チャネル上で行われる。フラッシュウェアは、ここでは、ハード的な記憶手段に格納され、そこから自動車に読み込まれることが好ましい（これのより詳細については、図２参照）。
【００３３】
図６は、図２のダウンロードプロセスと合わせて使用されるような認証コードの、より複雑な計算のさらなる例示的実施形態を示している。この例示的実施形態においては、まず最初に、暗号化されていないフラッシュウェアの一方の端部に、認証機関内の秘密データストリングが連結される。連結は、ここでは、フラッシュウェアのデータレコードの先端又は後端のいずれかに行われ得る。ハッシュ値計算が、一方の端部で連結されたフラッシュウェアによって行われる。この結果が、第１のハッシュ値ＨＭＡＣ１である。この第１のハッシュ値ＨＭＡＣ１は、一方の端部で、メモリ８からの秘密データストリングに連結される。ここでも、連結は、第１のハッシュ値の先端又は後端部で行われ得る。さらなるステップで、第２のハッシュ値計算が、秘密データストリングと第１のハッシュ値との組合せに対して行われる。この最後のハッシュ値計算の結果、認証コードＨＭＡＣが得られる。この認証コードは、システムインターフェースに転送される。図４の例示的実施形態とは異なり、図６の例示的実施形態においては、認証コードのみがシステムインターフェースに転送される。ここでは、図２と同様に、暗号化されていない元のソフトウェアが、記憶媒体、好ましくはコンパクトディスクを介して自動車に読み込まれる。
【００３４】
以下、図７を参照しながら、自動車の制御ユニット内の又はマイクロプロセッサシステム内のフラッシュプロセスについてより詳細に記載する。電子制御ユニットＥＣＵなどの代表的な制御ユニットは、マイクロプロセッサＣＰＵなどの演算装置を含み、この演算装置はプロセッサバスＰＢＵＳを介して様々なメモリ又はメモリセクタに接続される。制御ユニットは、インターフェースを介して、外部からアドレス付けされ得るか、又はインターフェースに接続された他のユニットと通信できる。制御ユニットのメモリは、ブートセクタと、フラッシュメモリと、主記憶装置ＲＡＭとからなる。フラッシュメモリ「Ｆｌａｓｈ」は、電気的消去可能プログラマブルメモリ、たとえばＥＥＰＲＯＭである。フラッシュブートローダと呼ばれる、マイクロプロセッサのオペレーティングシステム、及びハッシュ関数用のＲＩＰＥＭＤ−１６０アルゴリズムが、ブートセクタ内に格納される。秘密データストリングが、外部アクセスに対して特別に保護されているメモリ又はメモリ領域内の制御ユニット内に格納される。この特別に保護されているデータ領域９は、ブート領域内に配置されても良い。また別の方法として、この特別に保護されているデータメモリ９を、上書きされ得ず、かつ不正な読取りに対して保護されているメモリカードの形態で、又は不正なアクセスが試みられた場合にそのコンテンツを消去する、いわゆるクリプトプロセッサの形態で具現化することも可能である。特別に保護されているメモリ領域９の、これらの手段及び実施形態は、ここに格納されているデータストリングの秘密が守られることを保証する。データストリングを特別に保護されているデータ領域９内でプログラムすることは、認証機関内で認証コードを計算するためのデータストリングと調整されなければならない。制御ユニット内のデータストリングは、認証コードを計算するための基礎として使用されたデータストリングと一致していなければならない。
【００３５】
フラッシュウェアとして使用され得るアプリケーションプログラムは、制御ユニットのフラッシュＦｌａｓｈ内に格納される。既に格納されているユーザプログラムが、基本的に以下の方法で、新しいフラッシュウェアにより上書きされる。制御ユニットでは、外部システムインターフェースから制御ユニットのインターフェースを介して伝送される特別なソフトウェアコマンドにより、ダウンロードプロセス及びフラッシュプロセスのための準備がなされる。いわゆるフラッシュブートローダは、ソフトウェアコマンドによって作動する。フラッシュブートローダは、基本的に、アプリケーションプログラムを制御ユニットのフラッシュメモリ内に書き込む再書込ルーチンである。ダウンロードプロセス中に、新しいフラッシュウェア及び伝送された認証コードが、まず最初に、制御ユニットの主記憶装置内にバッファされる。次いで、フラッシュブートローダの再書込ルーチンを用いて、バッファされたフラッシュウェアと認証コードの正確さ及びデータの完全性の保証ための検査が、制御ユニットのマイクロプロセッサ内で行われる。この検査は、伝送される認証コードを生成するために適用された同じ方法ステップが、暗号化されていないソフトウェア、及び制御ユニット内に格納されている秘密データストリングを用いて、マイクロプロセッサ内で行われるような形で行われる。したがって、認証コードを生成するために、認証機関内で行われるこれらの方法ステップが、制御ユニットのマイクロプロセッサ内で繰り返される。たとえば、図３の例示的実施形態に従って、制御ユニットのマイクロプロセッサ内で、認証コードが生成されると、バッファされたフラッシュウェアの両端部に、制御ユニット内に格納されている秘密データストリングが連結される。両端部で連結されたフラッシュウェアは、ＲＩＰＥＭＤ−１６０アルゴリズムを用いてハッシュ値計算を行う。制御ユニット内のこのハッシュ値計算の結果が、伝送された識別コードＨＭＡＣと比較される。両方のハッシュ値が同一であると、主記憶装置内にバッファされたフラッシュウェアは、正確でありかつ完全であると考えられる。図３、図４、図５、又は図６に対応する例示的実施形態の１つに従って、認証機関内の認証コードが取得されると、バッファされたフラッシュウェアの、制御ユニット内に格納されている秘密データストリングとの連結、及び制御ユニット内で又は制御ユニットのマイクロプロセッサ内で検査するための連結されたフラッシュウェアのハッシュ値計算が、それぞれ、転送される認証コードを生成するために認証機関内で行われるような形で行われなければならない。制御ユニットのマイクロプロセッサで取得されたハッシュ値と転送された認証コードとが対応していると、これらの比較により、それぞれ、主記憶装置内にバッファされた、伝送されたフラッシュウェアのデータの正確さ及び完全である状態についての決定的な情報がもたらされる。両方の値が一致していると、フラッシュウェアは、それぞれ、誤りがないと考えられる。
【００３６】
新しくダウンロードされ、かつバッファされたフラッシュウェアの検査が成功した後、フラッシュブートローダは、新しいバッファされたフラッシュウェアを制御ユニットのフラッシュメモリに書き込む。主記憶装置からフラッシュメモリへのコピープロセスが、さらにここで、巡回ブロック保護方法で完全性について検査され得る。正確さの検査及びコピープロセスに誤りがないと、いわゆるフラグが、フラッシュ内に置かれるフラッシュウェア用に設定される。このフラグが、有効なものとして使用されるアプリケーションプログラムとして、現在フラッシュ内に置かれているアプリケーションプログラムを識別する。図７に例として示されているように、フラグは、たとえばここでは、フラッシュメモリ自体内で設定でき、フラッシュメモリは、ＥＥＰＲＯＭとして具現化されることが好ましい。次いで、制御ユニットは、アプリケーションの実行に移ることができるようになり、その過程で、有効なフラグで識別されたアプリケーションプログラムを使用する。
【００３７】
フラッシュブートローダは、整備工場内の診断システムによって起動することが好ましい。この場合、整備工場の診断システムは、システムインターフェース４を形成する。図１のダウンロードプロセスの場合には、暗号化されていないフラッシュウェア及び認証コードが共に、システムインターフェースによりインターフェースを介して、制御ユニットの主記憶装置内にバッファされる。図２のダウンロードプロセスの場合には、認証コードは、システムインターフェースを介して制御ユニットの主記憶装置内にバッファされ、暗号化されていないフラッシュウェアは、さらなる読取り装置、好ましくはＣＤ−ＲＯＭディスクドライブ又はチップカード読取り装置を介して、制御ユニットの主記憶装置内にバッファされる。したがって、図２のダウンロードプロセスの場合には、フラッシュブートローダの再書込ルーチンは、適宜、異なる電子データ処理システムから、必要とされるデータレコードをダウンロードしなければならない。しかし、すべての場合において、車両内の通信は、自動車の内部データバスを介して行われる。自動車内の、近頃一般に普及しているデータバスが、いわゆるＣＡＮバスである。
【００３８】
自動車内のすべての制御ユニットが、フラッシュウェアをバッファできる十分なメモリ空間を有するわけではない。したがって、既存のメモリ領域がダウンロードされたフラッシュウェアをバッファするのに十分でない制御ユニットの場合には、ダウンロードプロセスは、以下の通り行われる。
− まず最初に、既存のフラッシュメモリが消去される。
− 次いで、新しいフラッシュウェアが、ダウンロードされ、プログラムされる。
− 次いで、ダウンロードされたフラッシュウェアが、検証される。つまり、伝送誤りについて検査される。
− 次いで、上記の例示的実施形態と同様に、認証検査が行われる。
− 正確さの検査が肯定的であった後、ダウンロードされたフラッシュウェアが、状態ビットの形態のフラグを設定することによって識別され、作動する。
− 次いで、次のアプリケーションが、新しいフラッシュウェアにアクセスする。
【００３９】
フラッシュウェアをバッファせずに直接ダウンロードすると、ダウンロードプロセス中の書き込みプロセスにおいて書き込み誤りも検出されるので、「エンドツーエンド」保護というさらなる利点を有する。
【００４０】
本発明のすべての例示的実施形態において、フラッシュウェアは、これに追加される、いわゆるメタ情報を有し得る。このフラッシュウェアメタ情報とは、特に、車両識別番号、制御ユニット部品番号、又はフラッシュウェアのための特別なメモリ位置である。フラッシュウェアメタ情報を含むことにより、たとえば、新しくダウンロードされるべきフラッシュウェア用の記憶位置を選択することができる。フラッシュウェアメタ情報も認証コードの計算に含まれるので、このフラッシュウェアメタ情報も、改ざんに対して保護される。
【図面の簡単な説明】
【００４１】
【図１】記憶装置から自動車の制御ユニットに、フラッシュウェアをダウンロードするプロセスを示す概略図である。
【図２】フラッシュウェア及び認証コードが別個の伝送チャネル上で自動車の制御ユニットに入る、フラッシュウェアをダウンロードするプロセスを示す図である。
【図３】図１のダウンロードプロセス用の認証コードの計算を示す流れ図である。
【図４】図１のダウンロードプロセス用の認証コードの計算を示す、より複雑な流れ図である。
【図５】図２のダウンロードプロセス用の認証コードの計算を示す流れ図である。
【図６】図２のダウンロードプロセス用の認証コードの計算を示す、より複雑な流れ図である。
【図７】本発明による方法に従って、アプリケーションプログラムがこの中にダウンロードされ得るフラッシュメモリを備えた、マイクロプロセッサシステム又は制御ユニットを示すブロック図である。
【特許請求の範囲】
【請求項１】
− 少なくとも１つのマイクロプロセッサ（ＣＰＵ）と、
− ブートセクタと、フラッシュブートローダと、電気的消去可能プログラマブルメモリ（フラッシュ）と、読み出し／書き込み用メモリ（ＲＡＭ）とを備えた、少なくとも１つのメモリ部と、
− 前記マイクロプロセッサシステム（ＣＰＵ）のプロセッサバス（ＰＢＵＳ）に接続された少なくとも１つのシステムインターフェース（診断インターフェース、車載電気系統インターフェース）と、
を有する制御ユニット（ＥＣＵ）のプログラムメモリ（フラッシュ）内に格納される、少なくとも１つのアプリケーションプログラム（フラッシュウェア）をロードする方法であって、
− 認証コード（ＨＭＡＣ）が、前記アプリケーションプログラム（フラッシュウェア）用に作成され、
− 前記認証コード（ＨＭＡＣ）及び前記現在のアプリケーションプログラムが、前記システムインターフェースを介して読み込まれ、
− 前記読み込まれたアプリケーションプログラムが作動する前に、前記システムインターフェースで読み込まれた前記認証コード（ＨＭＡＣ）が検査される、方法において、
前記アプリケーションプログラム（フラッシュウェア）に秘密データストリング（ＳＴＲＩＮＧ）が連結され、該連結されたアプリケーションプログラムからハッシュ値を計算することにより前記認証コード（ＨＭＡＣ）が安全な領域（認証機関）内で計算され、該ハッシュ値が、前記システムインターフェースで認証コード（ＨＭＡＣ）として読み込まれ、
前記読み込まれたアプリケーションプログラム（フラッシュウェア）を前記制御ユニット内で連結するために、第２の同一の秘密データストリング（ＳＴＲＩＮＧ）が前記制御ユニット内にあらかじめ格納され、前記マイクロプロセッサ（ＣＰＵ）内で、ハッシュ値が前記読み込まれ、連結されたアプリケーションプログラムを用いて計算され、前記伝送された認証コード（ＨＭＡＣ）と比較されることを特徴とするアプリケーションプログラムのロード方法。
【請求項２】
前記アプリケーションプログラムが、前記安全な領域（認証機関）内での正確さの検査中に、前記プログラムの前端及び後端の両方に、前記マイクロプロセッサ内の前記秘密データストリングが付加され、この両端部で連結された前記アプリケーションプログラムに基づいてハッシュ値が計算され、計算されたハッシュ値が前記システムインターフェースで認証コード（ＨＭＡＣ）として読み込まれることを特徴とする請求項１に記載の方法。
【請求項３】
− 前記アプリケーションプログラムに、前記プログラムの前端又は後端のいずれかに、前記秘密データストリング（ＳＴＲＩＮＧ）が連結され、
− 次に、第１のハッシュ値（ＨＭＡＣ１）が、一方の端部で連結された前記アプリケーションプログラムを用いて前記安全な領域（認証機関）内で計算され、
− 次に、前記第１のハッシュ値（ＨＭＡＣ１）の一方の端部に、秘密データストリング（ＳＴＲＩＮＧ）が連結され、
− 次に、第２のハッシュ値（ＨＭＡＣ）が、第１のハッシュ値（ＨＭＡＣ１）と秘密データストリング（ＳＴＲＩＮＧ）との連結文字列から計算され、前記第２のハッシュ値（ＨＭＡＣ）が、前記システムインターフェースで認証コード（ＨＭＡＣ）として読み込まれ、
− 同一であって、第２の秘密データストリング（ＳＴＲＩＮＧ）が、前記制御ユニット内に格納され、前記安全な領域（認証機関）内で行われたステップが、前記マイクロプロセッサ内で前記第２の秘密データストリング（ＳＴＲＩＮＧ）を用いて、同じシーケンスで、元のアプリケーションプログラムに対して繰り返され、
− 前記マイクロプロセッサ内で計算された前記ハッシュ値が、前記システムインターフェースで読み込まれた前記ハッシュ値（ＨＭＡＣ）と比較されることを特徴とする請求項１に記載の方法。
【請求項４】
前記認証コード（ＨＭＡＣ）が、前記アプリケーションプログラム（フラッシュウェア）と共に転送されることを特徴とする請求項１〜３のいずれか一項に記載の方法。
【請求項５】
前記認証コード（ＨＭＡＣ）が、前記アプリケーションプログラム（フラッシュウェア）とは別に転送されることを特徴とする請求項１〜３のいずれか一項に記載の方法。
【請求項６】
前記アプリケーションプログラム（フラッシュウェア）が、メモリ媒体に格納され、前記メモリ媒体を介して前記制御ユニットに読み込まれ、
前記認証コード（ＨＭＡＣ）が、データ伝送により、前記安全な領域（認証機関）から前記システムインターフェースに伝送されることを特徴とする請求項５に記載の方法。
【請求項７】
前記アプリケーションプログラム（フラッシュウェア）及び前記認証コード（ＨＭＡＣ）が、データ伝送により、前記安全な領域（認証機関）から前記システムインターフェースに伝送されることを特徴とする請求項４に記載の方法。
【請求項８】
前記認証コードが、前記診断インターフェースを介して、自動車の制御ユニット（ＥＣＵ）に読み込まれることを特徴とする請求項１〜７のいずれか一項に記載の方法。
【請求項９】
読み込まれた認証コード（ＨＭＡＣ）及び前記マイクロプロセッサ内で計算されたハッシュ値が一致していると、前記関連付けられたアプリケーションプログラム（フラッシュウェア）に、有効なアプリケーションプログラムとして識別子（フラグ）が付加されることを特徴とする請求項１〜８のいずれか一項に記載の方法。
【請求項１０】
フラッシュウェアメタ情報が、前記認証コード（ＨＭＡＣ）内に含まれることを特徴とする請求項１〜９のいずれか一項に記載の方法。
【請求項１１】
前記認証コード（ＨＭＡＣ）が、様々な制御ユニットでの前記アプリケーションプログラムのダウンロードプロセスを選択するために使用されることを特徴とする請求項１０に記載の方法。
【請求項１２】
プログラムメモリ（フラッシュ）に格納される、自動車の制御ユニット（ＥＣＵ）用のアプリケーションプログラム（フラッシュウェア）の正確さを保証する方法であって、
前記アプリケーションプログラム（フラッシュウェア）に秘密データストリング（ＳＴＲＩＮＧ）を連結し、安全な領域（認証機関）内で前記連結されたアプリケーションプログラムからにハッシュ値が計算されることにより認証コード（ＨＭＡＣ）が求められ、この認証コードは前記制御ユニット（ＥＣＵ）に読み込まれ、
前記制御ユニット内では、前記読み込まれたアプリケーションプログラム（フラッシュウェア）に、前記制御ユニット（ＥＣＵ）に格納されている第２の同一の秘密データストリング（ＳＴＲＩＮＧ）が連結され、前記制御ユニット（ＥＣＵ）内で前記読み込まれ連結されたアプリケーションプログラムによりハッシュ値が計算され、該値が前記伝送された認証コード（ＨＭＡＣ）と比較されることを特徴とするアプリケーションプログラムの正確さを保証する方法。
【請求項１３】
前記アプリケーションプログラムの前端及び後端の両方で、前記制御ユニット（ＥＣＵ）内の格納されている前記秘密データストリングに連結され、前記安全な領域（認証機関）内で及び前記認証検査中に、ハッシュ値が、両端部に連結された前記アプリケーションプログラムを用いて計算され、前記ハッシュ値が、前記システムインターフェースで認証コード（ＨＭＡＣ）として読み込まれることを特徴とする請求項１２に記載の方法。
【請求項１４】
− 前記プログラムの前端又は後端のいずれかで、前記秘密データストリング（ＳＴＲＩＮＧ）が前記アプリケーションプログラムに連結され、
− 次に、第１のハッシュ値（ＨＭＡＣ１）が、一方の端部に連結された前記アプリケーションプログラムに対して前記安全な領域（認証機関）内で計算され、
− 次に、前記第１のハッシュ値（ＨＭＡＣ１）の一方の端部に秘密データストリング（ＳＴＲＩＮＧ）を連結し、
− 次に、第２のハッシュ値（ＨＭＡＣ）が、第１のハッシュ値（ＨＭＡＣ１）と秘密データストリング（ＳＴＲＩＮＧ）との連結に基づき計算され、前記第２のハッシュ値（ＨＭＡＣ）が、前記システムインターフェースで認証コード（ＨＭＡＣ）として読み込まれ、
− 第２の同一の秘密データストリング（ＳＴＲＩＮＧ）が、前記制御ユニット内（ＥＣＵ）に格納され、前記安全な領域（認証機関）内で行われたステップが、前記制御ユニット（ＥＣＵ）内の前記データストリング（ＳＴＲＩＮＧ）を用いて、同じシーケンスで、元のアプリケーションプログラムで繰り返され、
− 前記制御ユニット（ＥＣＵ）内で計算された前記ハッシュ値が、前記システムインターフェースで読み込まれた前記ハッシュ値（ＨＭＡＣ）と比較されることを特徴とする請求項１２に記載の方法。
【請求項１５】
前記認証コード（ＨＭＡＣ）が、前記アプリケーションプログラム（フラッシュウェア）と共に転送されることを特徴とする請求項１２〜１４のいずれか一項に記載の方法。
【請求項１６】
前記認証コード（ＨＭＡＣ）が、前記アプリケーションプログラム（フラッシュウェア）とは別に転送されることを特徴とする請求項１２〜１４のいずれか一項に記載の方法。
【請求項１７】
前記アプリケーションプログラム（フラッシュウェア）が、メモリ媒体に格納され、前記メモリ媒体を介して前記制御ユニットに読み込まれ、
前記認証コード（ＨＭＡＣ）が、データ伝送により、前記安全な領域（認証機関）から前記システムインターフェースに伝送されることを特徴とする請求項１６に記載の方法。
【請求項１８】
前記アプリケーションプログラム（フラッシュウェア）及び前記認証コード（ＨＭＡＣ）が、データ伝送により、前記安全な領域（認証機関）から前記システムインターフェースに伝送されることを特徴とする請求項１５に記載の方法。
【請求項１９】
前記認証コードが、前記診断インターフェースを介して、自動車の制御ユニット（ＥＣＵ）に読み込まれることを特徴とする請求項１２〜１８のいずれか一項に記載の方法。
【請求項２０】
読み込まれた認証コード（ＨＭＡＣ）及び前記制御ユニット内で計算されたハッシュ値が一致していると、前記関連付けられたアプリケーションプログラム（フラッシュウェア）に、有効なアプリケーションプログラムとして識別子（フラグ）を付加することを特徴とする請求項１２〜１９のいずれか一項に記載の方法。
【請求項２１】
フラッシュウェアメタ情報が、前記認証コード（ＨＭＡＣ）内に含まれることを特徴とする請求項１２〜２０のいずれか一項に記載の方法。
【請求項２２】
前記認証コード（ＨＭＡＣ）が、様々な制御ユニットでの前記アプリケーションプログラムのダウンロードプロセスを選択するために使用されることを特徴とする請求項２１に記載の方法。
【請求項１】
− 少なくとも１つのマイクロプロセッサ（ＣＰＵ）と、
− ブートセクタと、フラッシュブートローダと、電気的消去可能プログラマブルメモリ（フラッシュ）と、読み出し／書き込み用メモリ（ＲＡＭ）とを備えた、少なくとも１つのメモリ部と、
− 前記マイクロプロセッサシステム（ＣＰＵ）のプロセッサバス（ＰＢＵＳ）に接続された少なくとも１つのシステムインターフェース（診断インターフェース、車載電気系統インターフェース）と、
を有する制御ユニット（ＥＣＵ）のプログラムメモリ（フラッシュ）内に格納される、少なくとも１つのアプリケーションプログラム（フラッシュウェア）をロードする方法であって、
− 認証コード（ＨＭＡＣ）が、前記アプリケーションプログラム（フラッシュウェア）用に作成され、
− 前記認証コード（ＨＭＡＣ）及び前記現在のアプリケーションプログラムが、前記システムインターフェースを介して読み込まれ、
− 前記読み込まれたアプリケーションプログラムが作動する前に、前記システムインターフェースで読み込まれた前記認証コード（ＨＭＡＣ）が検査される、方法において、
前記アプリケーションプログラム（フラッシュウェア）に秘密データストリング（ＳＴＲＩＮＧ）が連結され、該連結されたアプリケーションプログラムからハッシュ値を計算することにより前記認証コード（ＨＭＡＣ）が安全な領域（認証機関）内で計算され、該ハッシュ値が、前記システムインターフェースで認証コード（ＨＭＡＣ）として読み込まれ、
前記読み込まれたアプリケーションプログラム（フラッシュウェア）を前記制御ユニット内で連結するために、第２の同一の秘密データストリング（ＳＴＲＩＮＧ）が前記制御ユニット内にあらかじめ格納され、前記マイクロプロセッサ（ＣＰＵ）内で、ハッシュ値が前記読み込まれ、連結されたアプリケーションプログラムを用いて計算され、前記伝送された認証コード（ＨＭＡＣ）と比較されることを特徴とするアプリケーションプログラムのロード方法。
【請求項２】
前記アプリケーションプログラムが、前記安全な領域（認証機関）内での正確さの検査中に、前記プログラムの前端及び後端の両方に、前記マイクロプロセッサ内の前記秘密データストリングが付加され、この両端部で連結された前記アプリケーションプログラムに基づいてハッシュ値が計算され、計算されたハッシュ値が前記システムインターフェースで認証コード（ＨＭＡＣ）として読み込まれることを特徴とする請求項１に記載の方法。
【請求項３】
− 前記アプリケーションプログラムに、前記プログラムの前端又は後端のいずれかに、前記秘密データストリング（ＳＴＲＩＮＧ）が連結され、
− 次に、第１のハッシュ値（ＨＭＡＣ１）が、一方の端部で連結された前記アプリケーションプログラムを用いて前記安全な領域（認証機関）内で計算され、
− 次に、前記第１のハッシュ値（ＨＭＡＣ１）の一方の端部に、秘密データストリング（ＳＴＲＩＮＧ）が連結され、
− 次に、第２のハッシュ値（ＨＭＡＣ）が、第１のハッシュ値（ＨＭＡＣ１）と秘密データストリング（ＳＴＲＩＮＧ）との連結文字列から計算され、前記第２のハッシュ値（ＨＭＡＣ）が、前記システムインターフェースで認証コード（ＨＭＡＣ）として読み込まれ、
− 同一であって、第２の秘密データストリング（ＳＴＲＩＮＧ）が、前記制御ユニット内に格納され、前記安全な領域（認証機関）内で行われたステップが、前記マイクロプロセッサ内で前記第２の秘密データストリング（ＳＴＲＩＮＧ）を用いて、同じシーケンスで、元のアプリケーションプログラムに対して繰り返され、
− 前記マイクロプロセッサ内で計算された前記ハッシュ値が、前記システムインターフェースで読み込まれた前記ハッシュ値（ＨＭＡＣ）と比較されることを特徴とする請求項１に記載の方法。
【請求項４】
前記認証コード（ＨＭＡＣ）が、前記アプリケーションプログラム（フラッシュウェア）と共に転送されることを特徴とする請求項１〜３のいずれか一項に記載の方法。
【請求項５】
前記認証コード（ＨＭＡＣ）が、前記アプリケーションプログラム（フラッシュウェア）とは別に転送されることを特徴とする請求項１〜３のいずれか一項に記載の方法。
【請求項６】
前記アプリケーションプログラム（フラッシュウェア）が、メモリ媒体に格納され、前記メモリ媒体を介して前記制御ユニットに読み込まれ、
前記認証コード（ＨＭＡＣ）が、データ伝送により、前記安全な領域（認証機関）から前記システムインターフェースに伝送されることを特徴とする請求項５に記載の方法。
【請求項７】
前記アプリケーションプログラム（フラッシュウェア）及び前記認証コード（ＨＭＡＣ）が、データ伝送により、前記安全な領域（認証機関）から前記システムインターフェースに伝送されることを特徴とする請求項４に記載の方法。
【請求項８】
前記認証コードが、前記診断インターフェースを介して、自動車の制御ユニット（ＥＣＵ）に読み込まれることを特徴とする請求項１〜７のいずれか一項に記載の方法。
【請求項９】
読み込まれた認証コード（ＨＭＡＣ）及び前記マイクロプロセッサ内で計算されたハッシュ値が一致していると、前記関連付けられたアプリケーションプログラム（フラッシュウェア）に、有効なアプリケーションプログラムとして識別子（フラグ）が付加されることを特徴とする請求項１〜８のいずれか一項に記載の方法。
【請求項１０】
フラッシュウェアメタ情報が、前記認証コード（ＨＭＡＣ）内に含まれることを特徴とする請求項１〜９のいずれか一項に記載の方法。
【請求項１１】
前記認証コード（ＨＭＡＣ）が、様々な制御ユニットでの前記アプリケーションプログラムのダウンロードプロセスを選択するために使用されることを特徴とする請求項１０に記載の方法。
【請求項１２】
プログラムメモリ（フラッシュ）に格納される、自動車の制御ユニット（ＥＣＵ）用のアプリケーションプログラム（フラッシュウェア）の正確さを保証する方法であって、
前記アプリケーションプログラム（フラッシュウェア）に秘密データストリング（ＳＴＲＩＮＧ）を連結し、安全な領域（認証機関）内で前記連結されたアプリケーションプログラムからにハッシュ値が計算されることにより認証コード（ＨＭＡＣ）が求められ、この認証コードは前記制御ユニット（ＥＣＵ）に読み込まれ、
前記制御ユニット内では、前記読み込まれたアプリケーションプログラム（フラッシュウェア）に、前記制御ユニット（ＥＣＵ）に格納されている第２の同一の秘密データストリング（ＳＴＲＩＮＧ）が連結され、前記制御ユニット（ＥＣＵ）内で前記読み込まれ連結されたアプリケーションプログラムによりハッシュ値が計算され、該値が前記伝送された認証コード（ＨＭＡＣ）と比較されることを特徴とするアプリケーションプログラムの正確さを保証する方法。
【請求項１３】
前記アプリケーションプログラムの前端及び後端の両方で、前記制御ユニット（ＥＣＵ）内の格納されている前記秘密データストリングに連結され、前記安全な領域（認証機関）内で及び前記認証検査中に、ハッシュ値が、両端部に連結された前記アプリケーションプログラムを用いて計算され、前記ハッシュ値が、前記システムインターフェースで認証コード（ＨＭＡＣ）として読み込まれることを特徴とする請求項１２に記載の方法。
【請求項１４】
− 前記プログラムの前端又は後端のいずれかで、前記秘密データストリング（ＳＴＲＩＮＧ）が前記アプリケーションプログラムに連結され、
− 次に、第１のハッシュ値（ＨＭＡＣ１）が、一方の端部に連結された前記アプリケーションプログラムに対して前記安全な領域（認証機関）内で計算され、
− 次に、前記第１のハッシュ値（ＨＭＡＣ１）の一方の端部に秘密データストリング（ＳＴＲＩＮＧ）を連結し、
− 次に、第２のハッシュ値（ＨＭＡＣ）が、第１のハッシュ値（ＨＭＡＣ１）と秘密データストリング（ＳＴＲＩＮＧ）との連結に基づき計算され、前記第２のハッシュ値（ＨＭＡＣ）が、前記システムインターフェースで認証コード（ＨＭＡＣ）として読み込まれ、
− 第２の同一の秘密データストリング（ＳＴＲＩＮＧ）が、前記制御ユニット内（ＥＣＵ）に格納され、前記安全な領域（認証機関）内で行われたステップが、前記制御ユニット（ＥＣＵ）内の前記データストリング（ＳＴＲＩＮＧ）を用いて、同じシーケンスで、元のアプリケーションプログラムで繰り返され、
− 前記制御ユニット（ＥＣＵ）内で計算された前記ハッシュ値が、前記システムインターフェースで読み込まれた前記ハッシュ値（ＨＭＡＣ）と比較されることを特徴とする請求項１２に記載の方法。
【請求項１５】
前記認証コード（ＨＭＡＣ）が、前記アプリケーションプログラム（フラッシュウェア）と共に転送されることを特徴とする請求項１２〜１４のいずれか一項に記載の方法。
【請求項１６】
前記認証コード（ＨＭＡＣ）が、前記アプリケーションプログラム（フラッシュウェア）とは別に転送されることを特徴とする請求項１２〜１４のいずれか一項に記載の方法。
【請求項１７】
前記アプリケーションプログラム（フラッシュウェア）が、メモリ媒体に格納され、前記メモリ媒体を介して前記制御ユニットに読み込まれ、
前記認証コード（ＨＭＡＣ）が、データ伝送により、前記安全な領域（認証機関）から前記システムインターフェースに伝送されることを特徴とする請求項１６に記載の方法。
【請求項１８】
前記アプリケーションプログラム（フラッシュウェア）及び前記認証コード（ＨＭＡＣ）が、データ伝送により、前記安全な領域（認証機関）から前記システムインターフェースに伝送されることを特徴とする請求項１５に記載の方法。
【請求項１９】
前記認証コードが、前記診断インターフェースを介して、自動車の制御ユニット（ＥＣＵ）に読み込まれることを特徴とする請求項１２〜１８のいずれか一項に記載の方法。
【請求項２０】
読み込まれた認証コード（ＨＭＡＣ）及び前記制御ユニット内で計算されたハッシュ値が一致していると、前記関連付けられたアプリケーションプログラム（フラッシュウェア）に、有効なアプリケーションプログラムとして識別子（フラグ）を付加することを特徴とする請求項１２〜１９のいずれか一項に記載の方法。
【請求項２１】
フラッシュウェアメタ情報が、前記認証コード（ＨＭＡＣ）内に含まれることを特徴とする請求項１２〜２０のいずれか一項に記載の方法。
【請求項２２】
前記認証コード（ＨＭＡＣ）が、様々な制御ユニットでの前記アプリケーションプログラムのダウンロードプロセスを選択するために使用されることを特徴とする請求項２１に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公表番号】特表２００６−５２４３７７（Ｐ２００６−５２４３７７Ａ）
【公表日】平成１８年１０月２６日（２００６．１０．２６）
【国際特許分類】
【出願番号】特願２００６−５０４５３４（Ｐ２００６−５０４５３４）
【出願日】平成１６年３月４日（２００４．３．４）
【国際出願番号】ＰＣＴ／ＥＰ２００４／００２１９４
【国際公開番号】ＷＯ２００４／０９５２３８
【国際公開日】平成１６年１１月４日（２００４．１１．４）
【出願人】（５９８０５１８１９）ダイムラークライスラー・アクチェンゲゼルシャフト (1,147)
【Ｆターム（参考）】
【公表日】平成１８年１０月２６日（２００６．１０．２６）
【国際特許分類】
【出願日】平成１６年３月４日（２００４．３．４）
【国際出願番号】ＰＣＴ／ＥＰ２００４／００２１９４
【国際公開番号】ＷＯ２００４／０９５２３８
【国際公開日】平成１６年１１月４日（２００４．１１．４）
【出願人】（５９８０５１８１９）ダイムラークライスラー・アクチェンゲゼルシャフト (1,147)
【Ｆターム（参考）】
[ Back to top ]