(57)【特許請求の範囲】
【請求項１】
自動車両の制御装置のメモリ内に記憶可能なソフトウェアであって、前記制御装置の作動に影響を及ぼす該ソフトウェアのデータ保全性を保証するための方法であって、
電子データを暗号化し、また復号化するための第１鍵、第２鍵を、秘密鍵と公開鍵を用いた非対称性の一対の鍵として、権限のあるサイトが用意し、
前記第１鍵をブートセクタにファイルし、その後に前記ブートセクタをロックして、書き込みアクセスに対して保護し、
前記第２鍵を用いて、鍵の所有者が取り入れるべきソフトウェアに署名し、
署名されたソフトウェアを前記制御装置のメモリ内に取り入れ、
前記第１鍵を用いて前記制御装置が前記ソフトウェアの署名をチェックし、
そのチェックが肯定的な結果である場合に、取り入れられたソフトウェアを受諾する、方法において、
前記ソフトウェアに、前記制御装置を設置する自動車両に関する少なくとも１つの車両固有情報を付け加え、
前記ソフトウェアの署名の際に前記車両固有情報も署名され、
署名された車両固有情報も前記制御装置のメモリ内に取り入れ、その署名をチェックして、チェックされた車両固有情報が自動車両の車両固有情報と一致する場合にだけ、取り入れたソフトウェアを受諾することを特徴とする方法。
【請求項２】
ソフトウェアを先ずは所定の長さを有する情報に写像し、この情報を署名することを特徴とする、請求項１に記載の方法。
【請求項３】
写像機能としてハッシュ機能を選択することを特徴とする、請求項２に記載の方法。
【請求項４】
車両固有情報をチェックするために車両固有の一対の鍵を生成し、車両固有情報及び前記車両固有の一対の鍵の第１鍵を車両安全ユニット内に存在させ、車両固有情報に加えて前記車両固有の一対の鍵の第２鍵をソフトウェア内にファイルし、取り入れられたソフトウェアを受諾するために、前記車両固有の一対の鍵の両方の鍵がマッチしているかどうかを車両内の別個のルーチンでチェックすることを特徴とする、請求項１に記載の方法。
【請求項５】
少なくとも制御装置の最初の立ち上げ時にソフトウェアを検査し、更に対応してマーキングすることを特徴とする、請求項１〜４のいずれか一項に記載の方法。
【請求項６】
制御装置に外部からアクセスする際に、アクセスのための資格があるかどうかをアクセスユニットが検査することを特徴とする、請求項１〜５のいずれか一項に記載の方法。
【請求項７】
制御装置からコードを要求し、このコードの正確性をチェックすることを特徴とする、請求項６に記載の方法。
【請求項８】
アクセス側によって署名されるべき乱数を制御装置が発信し、この署名を制御装置で確認鍵を用いてチェックすることを特徴とする、請求項６または７に記載の方法。
【請求項９】
アクセス資格の試問時に資格レベルを決定し、この資格レベルに依存してアクセス行為を受諾または非受諾とすることを特徴とする、請求項６〜８のいずれか一項に記載の方法。
【請求項１０】
車両内の安全装置が、少なくとも散発的に制御装置の信頼性検査を実施し、否定的な結果の場合にはその制御装置を記録することを特徴とする、請求項１〜９のいずれか一項に記載の方法。
【請求項１１】
制御装置内に制御装置固有の秘密コードをファイルすることを特徴とする、請求項１０に記載の方法。
【請求項１２】
安全装置が、制御装置に特有の特徴を試問し、この特徴を信頼性に関してチェックすることを特徴とする、請求項１０または１１に記載の方法。
【請求項１３】
信頼性検査時に、安全装置か制御装置の少なくとも一方にファイルされている鍵を使用することを特徴とする、請求項１０〜１２のいずれか一項に記載の方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、自動車両の制御装置のためのソフトウェアのデータ保全性を保証するための方法に関する。
【０００２】
【従来の技術】
車両内の電子装置、並びに車両との通信可能性が増加することにより、その安全性に対する要求も高まることになる。
【０００３】
車両の極めて異なる領域には制御用のマイクロコントローラが組み込まれている。これらの制御装置は今日では頻繁にバスシステムを介して互いに接続されている。更に、多くの場合において、前記バスに外部からアクセスし、個々の制御装置と通信する可能性（例えば診断接続）が提供されている。
【０００４】
制御装置の機能方式はソフトウェアプログラムにより決定される。従来、制御装置（即ちコントローラ）内に組み込まれているソフトウェアは、多くの場合、プログラミング不可能なメモリ内（例えば、マスクプログラミングされているマイクロプロセッサ）に整理（ファイル）されている。それにより、ソフトウェアの改ざんは簡単には実現され得ない。例えば、メモリ構成要素と他のメモリ構成要素との完全な交換は認識され、それに対応した反応が成され得る。
【０００５】
プログラミング可能、特に所謂フラッシュプログラミング可能な制御装置を将来的に車両にて使用することにより、資格を伴わない改ざんがソフトウェア並びにそれと共に制御装置の作動方式に施されるという危険性が増加する。つまり、権限をもたない人物により、手間のかからない新たなプログラミングによって簡単にソフトウェアの交換が実行されてしまう。
【０００６】
安全上の理由から、並びに法的な要求を満たすためには、オリジナルソフトウェアの変更が防止されるか、またはその種の変更が権限をもつ人物にだけ認められるという措置がとられなければならない。
【０００７】
また、様々なモデルにて同じハードウェアを使用するという同部材コンセプトに注目することは将来的に有利であろう。そうすれば、機能方式における差異はソフトウェア内だけに留まることになる。このコンセプトにより、所定のソフトウェアは、固有の車両においてだけ実行可能であり、簡単に複写することは不可能となる。
【０００８】
従来の技術から、多数の確認方法（認証方法）並びに確認装置（認証装置）が知られている。
【０００９】
米国特許第５８４４９８６号明細書(US5844986)では、ＰＣのＢＩＯＳシステムへの許可されない侵入を回避するために使用される方法について記載されている。ＢＩＯＳメモリを含む暗号コプロセッサが、公開鍵と秘密鍵を用いる所謂公開鍵方式（パブリックキー方式）をベースにしてＢＩＯＳ変更の確認並びにチェックを実施する。この場合、前記チェックは、投入すべきソフトウェア内に埋め込まれているデジタル署名を検査することにより行われる。
【００１０】
ヨーロッパ特許出願公開第０８１６９７０号明細書(EP0816970A2)からは、ファームウェアをチェックするための装置が知られている。ブートＰＲＯＭメモリを確認するための前記装置は、マイクロコードを有するメモリ部分を含む。確認セクタは、マイクロコードの実施に対する応答としてハッシュデータを生成するハッシュジェネレータを含む。
【００１１】
しかし、上述の方法または装置では、自動車両の制御装置内に移入すべきソフトウェアを直接的にチェックすることはできない。
【００１２】
【発明が解決しようとする課題】
本発明の課題は、自動車両の制御装置に真正なソフトウェアを移入することを保証するための方法を提供することにある。
【００１３】
【課題を解決するための手段】
前記課題は、請求項１に記載した特徴により解決される。
【００１４】
それに応じて、先ず、電子データを暗号化及び復号化するための一対の鍵（鍵ペア）が生成される。この場合、鍵としては、通常、周知の暗号アルゴリズムから知られているコード化パラメータ及び／またはデコード化パラメータ（即ち、コード化パラメータ、またはデコード化パラメータ、またはコード化パラメータ及びデコード化パラメータ）として理解される。
【００１５】
ここで、ソフトウェアには第１鍵を用いて電子署名（電子サイン）がもたらされる。ソフトウェアの真実性（信憑性）を検証するために、付属する第２鍵は、このソフトウェアが移入されるべき制御装置内または制御装置のためにファイルされている。この第２鍵を用いてソフトウェアの電子署名がチェックされる。このチェックが肯定的であると、ソフトウェアは受諾され、制御装置を制御するために導入され得る。
【００１７】
本発明に従い、秘密鍵と公開鍵を用いた非対称暗号方式が選択される。この場合、公開鍵は、制御装置内または制御装置のためにファイルされ得る。更に、秘密鍵を用いてソフトウェアが署名される。代替的に、制御装置または車両自体は、非共通性の一対の鍵（非同期性の一対の鍵）を生成し得て、秘密鍵を制御装置内にファイルし得る。この場合、公開鍵は読み出し可能でなければならず、この公開鍵を用いてソフトウェアが署名され得る。この後者の選択肢では当然のことながら秘密鍵が読み出し不可能であることが保証されなくてはならない。
【００１８】
秘密鍵と公開鍵を用いた暗号アルゴリズムは所謂公開鍵方式と称され、公開鍵は公然と既知であり、それに対して秘密鍵は権限のある箇所（サイト）、例えばトラストセンタにだけ知らされているというである。この種の暗号アルゴリズムは、例えば、リベスト(Rivest)、シャミール(Shamir)、エイドルマン(Adleman)によるＲＳＡアルゴリズム、データ暗号アルゴリズム（ＤＥＡアルゴリズム）等のアルゴリズムである。秘密鍵または公開鍵を用いて、手書きのサインに対応するように、電子文書に対してデジタル署名が生成される。秘密鍵ないしは公開鍵の所有者だけが有効な署名を提供することができる。この際、文書の真実性は、付属する公開鍵ないしは秘密鍵を用いた署名の検証を介してチェックされ得る。秘密鍵は、しばしばプライベート鍵とも称される。
【００１９】
正しい鍵を知らない権限のない第三者は、有効な署名を生成することができない。改ざんされていて且つ不正確に署名されているソフトウェアが制御装置にロードされると、このことは付属する鍵を用いて認識され、前記制御装置は例えば実行不可能な状態に置き換えられる。
【００２０】
本発明に従い、鍵は制御装置のブートセクタにファイルされる。ブートセクタは、多くの場合、特有の方式で保護されていて、簡単に書き換えることはできない。本発明に従い、ブートセクタは、書き込み及び鍵の入力の後に「ロック」されるので、更なるアクセス、特に更なる書き込みは不可能となる。それにより、ブートセクタにファイルされている鍵が改ざんに対して保護されていることが保証される。
【００２１】
ソフトウェアを独占的に車両固有に使用するという要求を可能とするためには、特定車両の制御装置のために設けられているソフトウェアが、車両を個別化する情報、例えば車体番号または他の車両固有データを含む。これらの情報は、ソフトウェアに割り当てられ、またはソフトウェアに組み込まれている。これらのデータのソフトウェアへの割り当て、またはこれらのデータのソフトウェアへの組み込みの後に初めて、このソフトウェアは、このソフトウェアのために設けられている鍵を用いて署名される。制御装置は、上述したように、割り当てられている他の鍵を用いて署名が正しいと認識される場合にだけソフトウェアを受諾する。署名は、ソフトウェアに含まれている車両固有情報に依存するので、後から追加的に変更され得ない。車両固有情報が変更されていなくて且つ車両の車両固有情報と一致する場合には、車両の制御装置によって実行可能であるようにソフトウェアが単純に入力され得る。車両に個別化されているこの種のソフトウェアを他の車両にコピーすることは、車両固有情報が署名の侵害なしには変更され得ないので不可能である。
【００２２】
車両の始動時、並びに制御装置の立ち上げ時に毎回ソフトウェアをチェックする必要をなくすために、この種のチェックは有利には少なくとも投入（移入、取り入れ）時に実施される。正しく署名されているソフトウェアにおいて、このソフトウェアは、例えば通常は影響を及ぼすべきではないフラグを制御装置内に設定することにより特徴付けられ得る。このフラグの設定後、ソフトウェアは更なる立ち上げの際にも受諾される。このようにして、通常の車両始動時の遅延が回避されるが、この場合、前記フラグが外部から影響されないということが保証されなくてはならない。
【００２３】
制御装置のメモリにソフトウェアを投入する際に他の安全レベルを提供するために、本発明に従い、ソフトウェアの投入以前に、制御装置のメモリに対するアクセスは対応する資格を用いてのみ可能となるべきである。そのために、署名されているソフトウェアの移す前に、申告（ログオン）ステップにて制御装置の「アンロック」が設けられている。ログオン時に様々なアクセスレベルを使用する場合、それにより、異なって形成されているアクセス権が与えられ得る。診断アクセス時には、例えば先ずログオンが必要不可欠であり、それにより制御装置は入力されたアクセス情報を介してアクセス権、並びにこのアクセス権と結び付けられている資格レベルを認識する。権利授与に応じて、アクセス資格は厳しくないものから極めて厳しいものまでレベル付けされ得る。実施形態に従い、制御装置からコードが要求され、有効性がチェックされる。そのためには、例えば制御装置内にて乱数が生成され得て、この乱数は、例えば別にコード化または署名するというような処理方式で引き続きアクセス側から返却される。この情報は更に制御装置内にて例えば固有の確認鍵を用いてチェックされる。
【００２４】
アクセス権授与を動的に形成することも可能である。例えば、アクセス認可証が与えられ得て、この認可証情報からアクセスレベルが得られる。アクセス認可証が一度受諾されると、それにより再び署名のチェックが鍵を用い行われ、このアクセス認可証にリストされている権利が与えられる。
【００２５】
場合によってはアクセス制御のためだけに設けられている制御装置は、他の制御装置に比べて、確認権利の授与に関する中央安全機能があるために、車両内で自由にアクセスできないように設けられている。これは、制御装置の物理的な取り外しにより上述の保護機構がすり抜けられてしまうためである。それにより、この種の安全制御装置では特に例えば機械的な取り外し防止策が望まれる。
【００２６】
それに加えて、特有な安全レベルが制御装置接続の形成により達成され得て、この制御装置接続では様々な制御装置が相互接続されていて、互いに条件付けられ、ないしは相互にチェックされる。
【００２７】
更に、個々の制御装置が取り外され、他の制御装置と取り替えられる危険性を排除するために、追加的な固有の制御装置取り外し防止策を設けることは有意義である。この目的のために、例えば、制御装置が組み込まれている車両内で、散発的に制御装置信頼性検査が実施される。このためには、照会が制御装置に向けて発せられ、これらの制御装置はその照会に対して所定の期待情報を用いて回答しなくてはならない。実際にチェックすべき制御装置からの発信情報が期待情報と一致しない場合、または制御装置が回答しない場合には、適切な保護措置がとられる。安全性に関して厳しくない制御装置においては、この制御装置は例えば通信接続から除外され得る。制御装置が車両の作動のために重要である場合には、この制御装置は例えば記録、マーク、またはリストに登録されるので、それぞれの制御装置におけるハードウェア的なごまかし操作は少なくとも追従され得る。一つの実施形態において、制御装置は照会に対して秘密確認鍵を用いて回答されなくてはならない。不法に交換された制御装置は、その種の鍵を有しておらず、更には認識され、対応して処理される。
【００２８】
【発明の実施の形態】
次に、添付の図面を用いて実施形態に基づき本発明を更に詳細に説明する。
【００２９】
図１には、互いにネットワーク接続されているユニットを有する制御装置構成がブロック図として図示されている。この際、搭載ネットワークは、部分的に異なる伝送速度を有し且つ所謂ゲートウェイ（中央ゲートウェイモジュール、コントローラゲートウェイ）により互いに接続されている複数の部分ネットワーク（ＬＷＬ−ＭＯＳＴ（光導波路−ＭＯＳＴ(Medi Oriental Systems Transport)）、Ｋ−ＣＡＮシステム（カロッセリ（車体）−コントローラエリアネットワーク−システム）、パワートレーン−ＣＡＮ等）から構成されている。
【００３０】
診断バス１６は中央ゲートウェイ１４を用いて他の全てのネットワークと間接的または直接的に接続されている。この診断バス１６は周囲環境への最も重要な接続部の１つである。この診断バス１６の端部におけるＯＢＤソケット(On Board Diagnose ソケット)に接続されている診断テスタを介して、並びに中央ゲートウェイ１４を介在して、全システム内の全てのコントローラ、ゲートウェイ、及び制御装置が応答可能である。
【００３１】
代替的に、ＧＳＭネットワーク(Global System for Mobile Communication ネットワーク)２０及び車両内の電話システム１８を介して、車両内の装置にアクセスする可能性がある。それにより、原則的には車両搭載ネットワークへのリモートアクセスが可能である。この場合、電話システム１８は、同様に移動無線電信ネットワーク（ＧＳＭネットワーク）とその他の車両バス加入部との間のゲートウェイを意味する。
【００３２】
車両バス内には、車両へのアクセスを監視するカーアクセスシステム（ＣＡＳ）２２が組み込まれている。このＣＡＳ２２は、他の機能として電子的な発進遮断部を含む。
【００３３】
コントローラゲートウェイ２１は、ＣＤプレーヤと搭載ネットワークとの間のインタフェースをも意味する。このコントローラゲートウェイ２１にて、運転者が様々な器具を介して行う入力も通知情報に変換され、それぞれに応答される制御装置に転送される。
【００３４】
その他に、複数の制御装置（ＳＴＧ１〜ＳＴＧ５）が示されている。これらの制御装置の課題は、車両内の所定のユニットの制御に限らず、これらの装置自体の間の通信にもある。車両内の通信は「同報通信（ブロードキャスト）」に対応している。バスアクセスを獲得した情報発生源は、その情報を基本的に全ての制御装置に送信する。そのために、コントローラと接続されているデータバスは持続的に試問される。それに対して周囲環境との通信では、例えば診断バスを介して、各制御装置が一義的なアドレスを用いて的確に応答される。
【００３５】
制御ユニットの機能性を決定するソフトウェアは、将来的には、主にプログラミング可能なメモリ、例えばフラッシュメモリに格納される。フラッシュプログラミングでは、全ブロックだけが消去され、新たに書き込まれ得る。個々のビットの消去は不可能である。制御装置に応じて、様々な種類のマイクロコンピュータが使用される。これは、要求に応じて、８ビットプロセッサ、１６ビットプロセッサ、または３２ビットプロセッサである。これらの全制御装置または全コントローラは、様々なバリエーションで使用可能である。それらは、例えば、車両に搭載されているフラッシュメモリまたはプロセッサ自体に直接的に組み込まれているフラッシュメモリを有する。
【００３６】
次に、フラッシュメモリを有する制御装置用のソフトウェアのデータ保全性を保証するフローを、図２ａ及び図２ｂを用いて詳細に説明する。
【００３７】
先ず、権限のある唯一の箇所、例えば所謂トラストセンタにおける第１ステップでは、公開鍵５８と秘密鍵５２から成る一対の鍵（鍵ペア）が提供される。この場合、鍵とは情報を暗号化及び／または復号化することのできる電子コードである。ここでは例えば、既に上述したＲＳＡアルゴリズムまたはＤＥＡアルゴリズム、即ち非共通性の一対の鍵を有する所謂「公開鍵アルゴリズム（パブリックキーアルゴリズム）」のような周知の暗号アルゴリズムが使用される。
【００３８】
先ず、使用される暗号方式（コード化）について詳細に説明する。本確認方法では、非共通暗号方式（非同期暗号方式）が有利とされる。対称鍵（共通鍵）では、各側面に「秘密」が所有されなくてはならない。共通鍵が権限のある箇所の他に第三者にも知られたら、正しい安全措置は保証され得ない。一対の鍵（鍵ペア）の１つの鍵は本方法にて自動車両の制御装置内に保存される必要があり、それによりその秘密性が保証され得ないので、対称性の一対の鍵の選択は賢明ではない。
【００３９】
対称暗号方式（対称コード化）に対して、Ｗ．ディフィー(W.Diffie)とＭ．ヘルマン(M.Hellman)は1976年に所謂公開鍵暗号方式を開発した。この暗号方式では公開鍵と秘密鍵を有する一対の鍵が形成される。秘密鍵を用いて電子文書の署名が実施され得る。この署名は、一義的であり、通常は再構成され得ない。この署名は公開鍵を用いてチェックされ得る。
【００４０】
公開鍵方式は、一対の鍵の１つの鍵を公開して周知としてよいという長所を有する。しかし、今日の周知の公開鍵方式は極めて多くの計算を必要とするので、ハイブリッド方式、即ち対称方式と非対称方式の組合せが頻繁に使用されている。ハイブリッド方式では、対称鍵が公開鍵方式を用いて通信パートナー間で交換される。その際、実際の通信情報は前記対称鍵で暗号化される。
【００４１】
秘密鍵と公開鍵を区別することにより、確認方法並びにデジタル署名が上述したように実現される。秘密鍵を所有することにより、同一性が一義的に証明され、手書きのサインにおけるような署名が作成され得る。有名な公開鍵暗号システムは上述したＲＳＡ方式である。他の公開鍵暗号方式は、所定の数学的な群において、対数を計算するという問題に基づいている（離散対数問題）。
【００４２】
文書をデジタル方式で署名するために、唯一権限のある箇所では、文書が秘密鍵を用いて暗号化され、署名値が文書に付加される。署名を検証するために、この署名は公開鍵を用いて復号化され、結果として得られる値が本来の文書値と比較される。両方の文書値が一致すると、署名は有効であり、ソフトウェアが受諾され得る。
【００４３】
ここで公開鍵は、車両生産において権限のある箇所により、ソフトウェアに関して修正可能であるべき車両の各制御装置（例えば変速機制御装置）内にそれぞれ保存されている。
【００４４】
ディーラー１００（図４参照）にて顧客が自らの自動車両のために所定の追加機能、例えばギア比の選択における所定の切替特性を注文したとする。この機能は、新たなソフトウェアをそれぞれの車両の変速機制御装置に投入することにより実現され得る。
【００４５】
それに基づいてディーラー１００は、対応するソフトウェア１５０を使用可能とし、このソフトウェア１５０を顧客の車両の車体番号（ＦＧＮ）と共に、このソフトウェアにサイン（署名）する権利が唯一付与されているトラストセンタ１０４に送信する。トラストセンタ１０４では、伝達された車体番号と共に前記ソフトウェアが秘密鍵を用いて署名される。
【００４６】
このプロセス方式は、図２ａにも図示（ソフトウェア５０、秘密鍵５２）されているが、ここでは車体番号は伝達されないものとしている。
【００４７】
その後、署名されたソフトウェア１０６（図４、並びに図２ａの符号５６を参照）は、ディーラー１００に戻るように伝達され、ディーラー１００は前記ソフトウェア１０６を顧客の車両１２に投入することができる。
【００４８】
トラストセンタ１０４への伝達、署名、並びに戻りの伝達は、電子経路で比較的迅速に執り行われ得る。
【００４９】
次のステップでは、署名されたソフトウェア５６、１０６がディーラー１００によって車両１２、即ち変速機制御装置に投入される。この伝送は診断ソケット及び診断バス１６を介して行われる。ソフトウェアの投入（移入、取り入れ）は代替的にＧＳＭネットワークを介しても遠隔制御されて行われ得る。
【００５０】
投入時には先ずディーラーの申告と識別が行われる（図７のステップ５００参照）。そのために、ディーラー１００は制御装置アドレスと付属の識別情報を車両に送信する。識別が成功すると制御装置（ここでは変速機制御装置）が新たなソフトウェアを読み取るために準備される。それにより新たなソフトウェアの読み取り（フラッシング）が制御装置にて可能となる（図７の５０２参照）。新たなソフトウェアを制御装置に投入し、ディーラー１００は自分の役割を果たしたことになる。
【００５１】
次のオペレーションでは、制御装置２４（図２）が、立ち上げの際に、投入されている新たなソフトウェア５６の署名を公開鍵５８を用いてチェックする。このことを図２ｂに基づいて詳細に説明する。暗号化された電子文書６２と一致しなくてはならない値が、制御装置２４における１つのユニット６０にて公開鍵５８を用いて署名から決定される。この一致はコンパレータ６４にて検査される。一致する場合には、投入されているソフトウェア５０が受諾され、このソフトウェアを用いて制御装置２４が稼動される。一致しない場合には、制御装置２４がマークされてリストに保存される。その後、診断により前記リストのデータが読み出され得る。更に、正しいソフトウェアを投入するための他の機会が与えられる。正しく署名されていないソフトウェアが投入されると、車両は引き続き稼動されない。
【００５２】
図３ａ及び図３ｂでは、より正確に暗号化及び復号化が示されている。ソフトウェアの署名では全ソフトウェアが署名されるわけではない。全ソフトウェアを署名することは非効果的である。正確に述べると、周知のハッシュ機能を介してソフトウェアから所謂ハッシュコード５１が生成される。ここでハッシュコード５１とは、所定の長さを有するデジタル情報に関するものであり、この長さとしては、安全性の要求に応じて、１６ビット、６４ビット、または１２８ビットが選択され得る。つまり、前記ハッシュコード５１が署名され（署名５４）、この署名がソフトウェア５０に付加される。ハッシュコードを署名することは、長いソフトウェア文書の署名よりも基本的に効果的である。
【００５３】
この場合、ハッシュ機能は次のような本質的な特徴を有する。即ち、与えられているハッシュ値ｈに対して文書の値Ｍを見つけることは困難である（一方向機能）。更に、衝突、即ちハッシュ値が同じである２つの値Ｍ及びＭ’を見つけることは困難である（耐衝突性）。
【００５４】
署名のチェックでは、公開鍵を署名に適用（図３ｂにおける符号５３）することによりハッシュ値５１’が検出され、このハッシュ値５１’はコンパレータ６６にてソフトウェア５０の実際のハッシュ値５１と比較される。両方のハッシュ値が一致する場合には、ソフトウェア５０が受諾される。その際には真正なソフトウェアであり、投入されているこのソフトウェアを用いて制御装置が稼動され得る。比較が肯定的でない場合には、制御装置はその稼動を中断し、正しい署名を有する正しいソフトウェアが投入されるまで待機する。
【００５５】
上述の確認フローの他に、通信パートナーＡを通信パートナーＢに対して確認するために、所謂チャレンジ−レスポンス−方式が頻繁に使用されている。そこでは、Ｂが先ず乱数ＲＮＤをＡに送信する。Ａは秘密鍵を用いて前記乱数に署名し、この値を回答としてＢに送信する。Ｂは公開鍵を用いて前記回答を検証し、Ａの確認を検査する。
【００５６】
この種の確認法を図６ａ及び図６ｂに示す。図６ａには、診断テスタと制御装置との間の通信ループが示されている。チャレンジ−レスポンス−方式による確認法では、先ず利用者が、所定のアクセスレベルＬｌを有する情報を診断テスタを用いて制御装置へ送信し、制御装置からの乱数を要求する（ステップ４００）。制御装置は、乱数の伝達を用いて回答する（ステップ４０２）。診断テスタでは乱数が秘密鍵を用いて署名され、引き続いてその結果が再び制御装置に送信される（ステップ４０４）。制御装置では、公開鍵を用いて署名から再び乱数を決定する。このように計算された数値が、以前に制御装置から伝達された乱数と一致する場合には、前記利用者のために、所望の安全レベルを有するアクセスが診断プロセスの期間に渡って許可される。それにより、前記利用者は対応する安全性のレベル付けに応じてソフトウェアを制御装置のメモリに読み込ませることができる。
【００５７】
次に、所定の車両のためのソフトウェアの個別化について説明する。図４に従う署名プロセスに関連して、所定の車両にだけ該当する車両識別情報がソフトウェアと共に伝達されることは既に述べた。引き続いてこのソフトウェアは車両識別情報（例えば車体番号）と共に署名され、このパケットはディーラーに返送される。この場合、署名はハッシュコードに成され（図３ａ及び図３ｂによる実施形態にて記載）、ハッシュコードが署名に決定的な影響を及ぼすことになる。
【００５８】
制御装置は、上述したように、正しく署名されたソフトウェアだけを受諾する。署名が正しい場合には、ソフトウェアに割り当てられている車両識別情報が車両の車両識別情報と実際に一致するかどうかが更にチェックされる。一致する場合にはソフトウェアが解放される。このプロセス方式により、車両に個別化されるソフトウェアが所定の目標車両においてだけ使用され得る。更に、他の車両のためには固有の署名を有する他のソフトウェアが提供されなくてはならない。
【００５９】
ソフトウェアの個別化を実施し得るためには、既に製造段階にて、対応する制御装置に、改ざん不能な形式で車体番号が登録されるべきである。この車体番号はメモリの消去後にも制御装置内に存在しなくてはならない。このことは、車体番号が例えば特にガードされている上述のカーアクセスシステムにて非揮発性の交換不可能なメモリ内に登録されていることにより実現可能である。
【００６０】
図５による次のプロセス方式は、改ざん不可能な試問を保証する。車体番号に加えて、秘密鍵ＩＦＳｓと公開鍵ＩＦＳｐから成る車両固有の他の一対の鍵が必要とされる。これらの２つの鍵の割り当てと車体番号の割り当ては中央箇所、即ちトラストセンタにて行われる。秘密鍵ＩＦＳｓはカーアクセスシステム２１０内に読み出し不可能な形式で記憶されている。
【００６１】
今日では、車体番号（ＦＧＮ）はカーアクセスシステム２１０のアクセス領域に既に設けられている。
【００６２】
新たに投入すべきソフトウェア内には、車体番号に加えて車両固有の公開鍵ＩＦＳｐ２０２も保管される。その後、ソフトウェア全体がトラストセンタにて署名２０４により保護される。制御装置へのソフトウェアの投入後には、先ず署名２０４の正確性が検査される。
【００６３】
その後、制御装置２０６は、既述のチャレンジ−レスポンス−試問を用いて、ソフトウェア内の車体番号が車両の車体番号と一致するかどうかをチェックする。そのために制御装置２０６は、ソフトウェア内に含まれている車体番号ＦＧＮｓｗと乱数ＲＡＮＤＯＭをカーアクセスシステム２１０に送信する。カーアクセスシステム２１０では、記憶されている車体番号ＦＧＮが、受信された車体番号ＦＧＮｓｗと比較される。引き続いて前記の両方の値が秘密鍵ＩＦＳｓを用いて署名され、再び制御装置２０６に戻るように送信される。制御装置２０６は、署名されている送信情報を公開鍵ＩＦＳｐを用いてチェックすることが可能で、この送信情報に含まれている値を、カーアクセスシステムに初めに送信されたチャレンジ値と比較することができる。それらの値が一致する場合にはソフトウェアが受諾され得る（ステップ２１６、ｏ．ｋ．）。それ以外の場合には、ソフトウェアは受諾されない（ステップ２１８、いいえ）。
【００６４】
この方法の変形例として、固有の一対の鍵ＩＦＳｓ及びＩＦＳｐの代わりに、車両に個別化されていない対応的な一対の鍵も使用され得て、この一対の鍵は既に車両内に記憶されている。それにより前記の鍵用の管理が省略される。同様に、対称暗号方式を用いた対応的な機構も当然のことながら可能である。これは、処理において有利であるが、対称鍵が制御装置から読み出される危険性をもたらしてしまう。
【００６５】
当然のことながら、上述した全ての方法において、トラストセンタの秘密鍵が秘密であり続けるということが絶対的に保証されなくてはならない。全体的に既述の暗号手法は、正しいソフトウェアだけを車両ないしは所定の車両に投入し、それにより資格を伴わない改ざんを防止する良好な可能性を提供する。
【図面の簡単な説明】
【図１】車両における制御装置構成を示す図である。
【図２】図２ａ及び図２ｂは、ソフトウェアのデジタル署名、並びにそのチェックのフローを示す図である。
【図３】図３ａ及び図３ｂは、図２によるソフトウェアのデジタル署名のフローを他の形式で示す図である。
【図４】トラストセンタによる署名作成のフローを示す図である。
【図５】車両固有情報の特有なチェック方法のためのアルゴリズムを示す図である。
【図６】図６ａ及び図６ｂは、制御装置に対する確認のためのブロック図とフロー図を示す。
【図７】制御装置内にソフトウェアを読み込ませるためのフローを示す図である。
【符号の説明】
１２    車両
１４    中央ゲートウェイ
１６    診断バス
１８    電話システム
２０    ＧＳＭネットワーク
２１    コントローラゲートウェイ（ＭＭＩ(Men Machine Interface)コントローラゲートウェイ）
２２    ＣＡＳ（カーアクセスシステム）
２４    制御装置
３２    ブートセクタ
５０    ソフトウェア
５１    ハッシュコード
５１’  署名から検出されたハッシュコード
５２    秘密鍵
５３    公開鍵を署名に適用すること
５４    署名（ハッシュコードに署名したもの）
５６    署名されたソフトウェア
５８    公開鍵
６０    制御装置における１つのユニット
６２    暗号化された電子文書
６４    コンパレータ
６６    コンパレータ
１００    ディーラー
１０４    トラストセンタ
１０６    署名されたソフトウェア
１０８    投入されるソフトウェア（署名済）
１５０    ソフトウェア（車体番号（ＦＧＮ）と共にトラストセンタへ送信される）
２００    投入されているソフトウェア（署名済）
２０２    車両固有の公開鍵
２０４    署名
２０６    制御装置
２０８    車体番号ＦＧＮｓｗと乱数ＲＡＮＤＯＭを制御装置がＣＡＳへ送信するステップ
２１０    ＣＡＳ（カーアクセスシステム）
２１２    ＣＡＳにて署名された車体番号ＦＧＮと乱数ＲＡＮＤＯＭをＣＡＳが制御装置へ送信するステップ
２１４    制御装置がチャレンジ値を比較するステップ
２１６    ソフトウェアの受諾
２１８    ソフトウェアの非受諾
４００    制御装置からの乱数を診断テスタにより要求するステップ
４０２    制御装置が乱数の伝達を用いて回答するステップ
４０４    診断テスタにより、前記乱数が秘密鍵を用いて署名され、その結果を再び制御装置に送信するステップ
４０６    制御装置が公開鍵を用いて前記署名から乱数を決定するステップ。
４０８    前記乱数と、以前に制御装置から伝達された乱数とが一致するかを比較するステップ。
４１０    前記比較の結果に対応する処理を行うステップ
４１２    前記比較の結果に対応する処理を行うステップ
５００    ディーラーの申告と識別を行うステップ
５０２    ソフトウェアを読み取るステップ
５０４    署名を検査するステップ
【図１】
0004733840.tif 000002
【図２】
0004733840.tif 000003
【図３】
0004733840.tif 000004
【図４】
0004733840.tif 000005
【図５】
0004733840.tif 000006
【図６】
0004733840.tif 000007
【図７】
0004733840.tif 000008