JP4856080B2 - データ処理装置へのデータのセキュリティ上安全なロード及び格納 - Google Patents

Description

データをデータ処理装置にセキュリティ上安全にロード及び格納する方法、製品手段及び装置が開示される。

移動電話及び他のデータ処理装置のような組込みシステムは、使用許諾された正式なソフトウェアの実行に依存する。ソフトウェアの操作により、装置の挙動エラー又は装置の基本的なセキュリティ機能の無効化を招く恐れがある。従って、装置のコアソフトウェアを保護することが特に重要である。例えばこれは、プログラムを保護メモリに格納することにより達成される。メモリは、不法アクセスから物理的に保護されるか、あるいは暗号方式により保護される。実際には、適切な物理的な保護を有するメモリを製造すること及び特にメモリインタフェースを保護することは困難であり、費用がかかる。従って、最も好ましい解決策は、メモリに格納されたソフトウェアのいくつかの種類の暗号化保護を使用することである。

更に、非常に小さなシステムに対するソフトウェアも益々複雑になってきているため、特にソフトウェアのライフサイクルの間の初期のリリースにおいて、エラー及び意図しない特徴の危険性は高くなる。また、ソフトウェアの初期のリリースの機能性は、通常限定される。従って、組込み装置に格納されたソフトウェアの頻繁な更新が益々必要とされてきている。

頻繁な更新の必要性及びデータ処理装置のソフトウェアに十分な保護を提供することに対する要望により、格納の際にデータ処理装置のソフトウェアを保護するとともに、セキュリティ上安全なソフトウェアの更新を可能にするセキュリティの解決策が必要となる。

特許文献１は、電子装置における電子メモリの改竄を防止する方法を開示している。従来技術の方法によると、電子装置がデータ転送装置により再プログラムされる場合、電子装置は、公開鍵／秘密鍵を使用するチャレンジレスポンス認証方式を開始し、データ転送装置を認証する。認証されると、データ転送装置はアクセスを許可され、メモリを再プログラムする。メモリの再プログラミング後、電子装置は、変更されたメモリコンテンツのハッシュ計算を実行する。計算されたハッシュ値は、デジタル署名するためにデータ転送装置に送信され、署名されたハッシュ値は、格納するために電子装置に返される。その後、署名されたハッシュ値は、起動中に又は周期的にメモリコンテンツの完全性を監査するために使用される。
米国特許第６，０２６，２９３号公報

上述の従来技術の方法は、ロードする段階において認証保護及び電子装置のメモリコンテンツの完全性保護を提供するが、ハッシュ値を生成し、生成されたハッシュ値に署名する非常に複雑な方式を含むため、ロード処理は長時間かかる。

従って、ソフトウェアを装置にロードし、その後装置に格納する間にソフトウェアを保護する、計算量的により効率的なセキュリティ機構を提供することが課題である。

上記課題及び他の課題は、データ処理装置にデータをロードする方法であって、
−データ処理装置がペイロード・データ項目を受信する工程と、
−ペイロード・データ項目の信頼性を保証するために暗号認証処理を実行する工程と、
−認証し、受信したペイロード・データ項目をデータ処理装置に格納する工程と、
−格納したペイロード・データ項目の完全性を保護する工程と、
を備え、
暗号認証処理を実行する工程には、少なくとも受信したデータ項目の監査ハッシュ値を計算する工程が含まれ、
完全性を保護する工程には、データ処理装置に入力として格納された秘密鍵を使用して、少なくとも監査ハッシュ値の参照メッセージ認証コード値を計算する工程が更に含まれることを特徴とする方法により解決される。

特に、ロード処理中に計算される監査ハッシュ値が受信したペイロード・データから計算され、その後、監査ハッシュ値がメッセージ認証コードの計算において再利用されるため、ソフトウェアロード中に実行される必要な演算数は減少し、方法の計算量的な効率が向上する。

更に、通常の完全性保護がデータ処理装置に格納された秘密鍵に基づくため、完全性保護は、任意の外部暗号鍵に依存せず且つ特に公開鍵署名機構に依存しない。対称鍵に基づく完全性チェック、すなわちメッセージ認証コードに基づく完全性チェックは、署名検証を含む公開鍵に基づく完全性チェックより計算上更に効率的であるのが利点である。

用語「データ処理装置」は、データがデータ転送システム等の外部ソースからロードされるデータメモリを具備する任意の電子装置を含むことを意図する。特に、用語「データ処理装置」は、任意の電子機器、携帯無線通信機器、及び他のハンドヘルド又は携帯装置を含むことを意図する。用語「携帯無線通信機器」は、移動電話、ページャ、通信機、電子オーガナイザ、スマートフォン、パーソナルデジタルアシスタント（ＰＤＡ）又はハンドヘルドコンピュータ等の全ての機器を含む。

用語「ペイロード・データ項目」は、データ処理装置にロードされた任意のデータを含むことを意図する。特に、用語「ペイロード・データ項目」は、装置等による実行を意図したプラットフォームソフトウェア又はアプリケーションソフトウェア等のプログラムコード、あるいは構成データを含むことを意図する。

暗号認証処理は、受信したデータの信頼性を検証するための任意の適切な暗号処理、すなわちデータが名前を搬送されるエンティティにより実際に送信されたこと、及びデータが偽造又は変更されていないことを保証するための任意の適切な暗号処理であってもよい。

いくつかの実施形態において、暗号認証処理には、
−参照ハッシュ値を受信する工程と、
−受信したペイロード・データ項目の信頼性を検証するために、受信した参照ハッシュ値と計算した監査ハッシュ値とを比較する工程と、が含まれる。

更なる実施形態において、暗号認証処理には、公開鍵暗号方式に基づいてデータ項目にデジタル署名を行う工程が含まれる。ソフトウェアのデジタル署名は、移動装置にロードされたソフトウェアの検証に対して効率的でセキュリティ上安全な原理である。署名の正常な検証により、ソフトウェアが妥当なソースにより発行されたことが保証される。更に、公開鍵技術に基づくデジタル署名は、検証に使用される公開鍵が転送又は格納の際に秘密保護される必要がないという利点を有する。従って、同一の公開鍵は、セキュリティを損なわずに多くの装置にインストールされる。これにより、高速でセキュリティ上安全なソフトウェアアップグレードに対する効率的な手順が可能になる。

いくつかの実施形態において、方法は、
−ペイロード・データ項目と、第１の公開鍵を含みデジタル署名されたデジタル証明書データ項目と、第１の公開鍵に対応する第１の秘密鍵を用いて暗号化された参照ハッシュ値を含むデジタル署名データ項目と、を受信する工程と、
−デジタル署名されたデジタル証明書データ項目を、データ処理装置に格納されたルート公開鍵に対して認証する工程と、
−デジタル署名データ項目を認証されたデジタル証明書に対して認証する工程と、
−受信したペイロード・データ項目の信頼性を検証するために、受信した参照ハッシュ値と計算した監査ハッシュ値とを比較する工程と、
を備える。

従って、デジタル署名の認証はデジタル証明書により保証され、ロード処理のセキュリティを更に向上する。データ処理装置は、証明書チェーンを形成する２つ以上のデジタル証明書を受信してもよい。この時、チェーンの１つの証明書が、データ処理装置に格納された公開ルート鍵により検証される。

更なる実施形態においては、参照ハッシュ値が暗号的に認証され、参照メッセージ認証コード値を計算する工程は、参照ハッシュ値が正常に認証された場合にのみ実行される。従って、データ処理装置におけるメッセージ認証コード手順の実行は、認証された参照ハッシュ値の受信を条件とする。これにより、無許可のメッセージ認証コード値を計算するためにデータ処理装置のメッセージ認証コード手順を不正者が利用する危険性が低減される。

メッセージ認証コード（ＭＡＣ）は、完全性保護メッセージに対する周知の機構である。ＭＡＣは、可変長の入力及び鍵を利用して固定の長さの出力、いわゆるＭＡＣ値又はタグ値を生成する関数である。通常、秘密鍵を共有する２者間で送信される情報を有効にするために、ＭＡＣはそれら２者間で使用される。いくつかの実施形態において、ＭＡＣは、ペイロード・データに一方向ハッシュ関数を適用し、秘密鍵を使用してその結果を暗号化することにより計算される。暗号ハッシュ関数と組み合わされる適切なＭＡＣ関数の例には、ＨＭＡＣ（メッセージ認証のための鍵付ハッシング）、例えばＡＥＳ又はセキュリティ上安全な一方向ハッシュ関数を使用する暗号ブロック連鎖（ＣＢＣ）ＭＡＣが含まれる。本明細書において説明されるロード方法において、メッセージ認証コードは、信頼性のない又はセキュリティ上安全でない媒体に格納されたデータの完全性をチェックするのに使用される。すなわち、この状況において、ペイロード・データ項目を格納し、検索する場合、ＭＡＣは、１つの装置、すなわち移動端末によってのみ使用される。

従って、いくつかの実施形態において、完全性を保護する工程には、計算した参照メッセージ認証コード値を、受信したペイロード・データ項目と関連づけて格納する工程が含まれ、これにより、データ処理装置によるペイロード・データ項目のその後のメモリ監査に対して利用可能にする。メモリコンテンツを監査する場合、装置は、装置に格納された秘密鍵を使用して、格納されたペイロード・データ項目のメッセージ認証コード値を計算し、その結果を先に格納された参照ＭＡＣ値と比較する。従って、本実施形態において、デジタル処理装置のみが秘密鍵を知る必要がある。いくつかの実施形態において、秘密鍵は、データ処理装置に固有の秘密データ項目であり、例えばデータ処理装置のみが知る秘密データ項目である。

別の実施形態において、参照メッセージ認証コード値を計算する工程には、少なくとも監査ハッシュ値及び乱数から得られる組合せデータ項目の参照メッセージ認証コード値を計算する工程が更に含まれる。本実施形態の利点は、ＭＡＣに対する入力が認証処理の結果に完全に依存せず、データ保護のセキュリティを更に向上させることである。

参照メッセージ認証コード値を計算する工程に、少なくとも監査ハッシュ値とバージョン制御データ項目とから得られる組合せデータ項目の参照メッセージ認証コード値を計算する工程が更に含まれる場合、メモリコンテンツ及びバージョン制御情報が一貫している場合にのみ後続するメモリ監査が正常に行なわれるため、完全性保護はバージョン制御機構と効率的に組み合わされる。

いくつかの実施形態において、バージョン制御データレコードはバージョン制御データ構造に格納され、バージョン制御データレコードには、少なくともバージョン制御データ項目を含む受信したペイロード・データ項目に関する情報が含まれる。いくつかの実施形態において、制御データ構造の完全性が保護される。

いくつかの実施形態において、バージョン制御データレコードはバージョンカウンタを備える。いくつかの実施形態において、バージョン制御データレコードは、ペイロード・データ項目の現在のバージョンを置換してもよい先のバージョン数を識別するバックカウンタを更に備える。それにより、上位互換性を制御する機構を含む単純で効率的なバージョン制御機構が提供される。

既存のソフトウェアがソフトウェアの新しいバージョンによりアップグレードされる周知のソフトウェアアップグレード方式において、ソフトウェアアップグレードは、いわゆるデルタファイル又はデルタ更新として受信されることが多い。そのようなデルタ更新は、現在のソフトウェアに対する新しい（更新された）ソフトウェアの差異を含み、それによりアップグレードパケットのサイズを減少する。いくつかのデルタファイル技術において、更新ファイルは、現在のソフトウェア及び受信した更新データから更新されたソフトウェアバージョンを生成することを制御するコマンドを更に含む。デルタファイル技術は、従来技術において周知であり、例えばChristian Reichenbergerによる「Delta storage for arbitrary non-text files」Proc. Of the 3rd International Workshop on Software Configuration Management、１４４〜１５２ページ、ノルウェー、１９９１年６月において説明される。デルタ更新に適用可能な効率的でセキュリティ上安全な機構を提供するのが望ましい。ペイロード・データ項目を受信する工程に、先に受信した現在のデータ項目のデルタ更新を受信する工程と、先に受信した現在のデータ項目と受信したデルタ更新とから、更新されたペイロード・データ項目としてペイロード・データ項目を生成する工程とが含まれる場合、この課題は解決される。本実施形態によると、更新されたペイロード・データ項目が生成され、監査ハッシュ値は、生成された更新ペイロード・データ項目から計算される。従って、鑑査ハッシュ値は、装置に格納された更新ペイロード・データの参照メッセージ認証コードの計算に対して再利用される。

第２の側面によると、上記の従来技術のシステムの課題は、格納されたデータ項目の異なるバージョンのアップグレードが頻繁に発生する場合に、データ処理装置に格納されたデータ項目の現在のバージョンの完全性を保護する効率的でセキュリティ上安全な方法を提供することである。

上記課題及び他の課題は、データ処理装置に格納されたデータ項目の現在のバージョンの完全性を保護する方法であって、
−少なくとも前記データ項目の参照ハッシュ値を決定する工程と、
−前記データ処理装置に格納された秘密鍵を使用して、前記決定された参照ハッシュ値から参照メッセージ認証コード値を計算する工程と、
−前記計算した参照メッセージ認証コード値を、前記データ項目と関連づけて格納する工程と、
を備え、
前記参照メッセージ認証コード値を計算する工程には、前記決定された参照ハッシュ値と少なくともバージョン制御データレコードの一部とから得られる組合せデータ項目から前記参照メッセージ認証コード値を計算する工程が含まれ、
前記バージョン制御データレコードには、前記データ項目の現在のバージョンに関するバージョン制御情報が含まれる
ことを特徴とする方法により解決される。

従って、判定された参照ハッシュ値及び少なくともバージョン制御データレコードの一部から得られる組合せデータ項目から参照メッセージ認証コードを計算することにより、格納されたペイロード・データの完全性保護は、格納されたデータのセキュリティ上安全なバージョン制御と効率的に組み合わされる。

少なくともデータ項目の参照ハッシュ値は、データ項目からハッシュ値を計算することにより判定されてもよく、あるいは上述のように、データ項目と共にハッシュ値を受信することにより又はデータ項目の受信に関連する認証処理からハッシュ値を受信することにより判定されてもよい。

用語「組合せデータ項目」は、２つ以上のデータ項目の関数として、例えば一方のデータ項目が他方のデータ項目の最後に追加される２つ以上のデータ項目の連結として生成される任意のデータ項目を含むことを意図する。判定された参照ハッシュ値及び少なくともバージョン制御データレコードの一部から得られる組合せデータ項目は、少なくとも参照ハッシュ値の関数として及び少なくともバージョン制御データレコードの一部の関数として生成される。

いくつかの実施形態において、バージョン制御データレコードの完全性が保護される。

いくつかの実施形態において、バージョン制御データレコードにはバージョンカウンタが含まれ、参照メッセージ認証コード値を計算することには、判定された監査ハッシュ値と少なくともバージョンカウンタとから得られる組合せデータ項目から参照メッセージ認証コード値を計算することが含まれる。

いくつかの実施形態において、バージョン制御データレコードには、ペイロード・データ項目の現在のバージョンを置換してもよい先のバージョン数を識別するバックカウンタが含まれる。それにより、上位互換性を制御する機構を含む単純で効率的なバージョン制御機構が提供される。いくつかの実施形態において、参照メッセージ認証コード値を計算する工程には、判定された参照ハッシュ値と少なくともバックカウンタとから得られる組合せデータ項目から参照メッセージ認証コード値を計算する工程が含まれる。

別の実施形態において、バージョン制御データレコードは、データ項目の現在のバージョンに対する参照ハッシュ値を更に含み、それによりデータ項目のコンパクトな「指紋」を提供する。

いくつかの実施形態において、デジタル処理装置のみが秘密鍵を知っている。更に、秘密鍵は、データ処理装置に固有の秘密データ項目であってもよい。

いくつかの実施形態において、ペイロード・データは、最初に説明した方法によりロードされる。それにより、セキュリティ上安全なロード及び格納をセキュリティ上安全なバージョン制御と効率的に組み合わせる。

更に別の実施形態において、方法は、
−先に受信した現在のデータ項目のデルタ更新を受信する工程と、
−先に受信した現在のデータ項目と受信したデルタ更新とから、更新されたデータ項目としてデータ項目を生成する工程と、
を更に備える。

更に別の実施形態において、方法は、バージョン制御データレコードを生成することと、バージョン制御データ構造にバージョン制御データレコードを格納することとを更に含み、後続するメモリ監査に対して利用可能にする。

別の側面において、データ処理装置に格納されたデータ項目の現在のバージョンの完全性を検証する方法は、
−前記データ項目の監査ハッシュ値を計算する工程と、
−前記データ処理装置に格納された秘密鍵を使用して、前記計算された監査ハッシュ値から監査メッセージ認証コード値を計算する工程と、
−前記計算された監査メッセージ認証コード値と、前記データ項目と関連づけて格納された参照メッセージ認証コード値とを比較する工程と、
を備える。

この側面においては、方法は、バージョン制御データレコードを検索する工程を更に備え、
前記バージョン制御データレコードには、前記データ項目の前記現在のバージョンに関するバージョン制御情報が含まれ、
前記監査メッセージ認証コード値を計算する工程には、前記計算された監査ハッシュ値と少なくとも前記バージョン制御データレコードの一部とから得られる、組合せデータ項目から監査メッセージ認証コード値を計算する工程が含まれる。

本発明は、上述され且つ以下に説明される方法、対応する装置及びコンピュータプログラムを含む種々の面に関する。それら方法、装置及びコンピュータプログラムの各々は、上述の方法の１つと関連して説明された１つ以上の利点及び特長をもたらし、上述の方法の１つと関連して説明された実施形態に対応する１つ以上の実施形態を有する。

更に詳細には、別の面によると、データ処理装置は、上述され且つ以下に説明されるデータ処理装置にデータをロードする方法を実行できる第１の処理回路を具備する。

特に、本明細書において説明されるセキュリティ機構は、マルチチップアーキテクチャを有する装置に有利に適用されてもよいことが分かる。特に、２つのチップのうち第１のチップが第２のチップを介してメモリにアクセスする場合、データの信頼性及びメモリコンテンツの完全性を保証することが第１のチップにとって特に重要である。

従って、いくつかの実施形態において、データ処理装置は、受信したペイロード・データ項目を格納できる格納手段と、格納手段及び第１の処理回路に接続された第２の処理回路とを更に具備し、第２の処理回路は、少なくとも格納手段に対する読み出しアクセスを第１の処理回路に提供できる。

更なる実施形態において、第１の処理回路は、非対称暗号方式のルート公開鍵を格納するローカル格納手段を含む。更なる実施形態において、第１の処理回路は、前記秘密鍵を格納するローカル格納手段を含む。それにより、データ信頼性及び完全性機構において使用される暗号鍵の第１のチップの制御下でセキュリティ上安全な格納を提供する。

別の側面によると、データ処理装置は、データ項目の現在のバージョン及びバージョン制御データレコードを格納する格納手段と処理手段を備え、バージョン制御データレコードは、データ項目の現在のバージョンに関するバージョン制御情報を含み、処理手段は、上述され且つ以下に説明されるデータ項目の現在のバージョンの完全性を検証する方法を実行できる。

尚、上述され且つ以下に説明される方法の特徴は、ソフトウェアにおいて実現されてもよく、コンピュータ実行可能命令等のプログラムコード手段の実行によりデータ処理装置又は他の処理手段において実行されてもよい。以降、用語「処理手段」には、上記機能を適切に実行できる任意の回路と装置との少なくともいずれかが含まれる。特に、上記用語は、汎用又は専用プログラマブルマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、プログラマブルロジックアレイ（ＰＬＡ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、専用電子回路等、あるいはそれらの組合せを含む。

別の側面によると、コンピュータプログラムがデータ処理装置上で実行される場合、前記コンピュータプログラムは、上述され且つ以下に説明される方法のステップをデータ処理装置に実行させるプログラムコード手段を含む。

例えば、プログラムコード手段は、コンピュータネットワークを介して記憶媒体又は別のコンピュータからＲＡＭ（ランダムアクセスメモリ）等のメモリにロードされてもよい。あるいは、説明された特徴は、ソフトウェアの代わりに又はソフトウェアと組み合わせてハードウェア回路網により実現されてもよい。

上記面及び他の面は、図面を参照して以下に説明される実施形態から明らかとなるだろう。

図１は、データを移動端末にロードするシステムを示す概略ブロック図である。システムは、ローディング装置１０１及び移動端末１０２を含む。

ローディング装置は、適切な通信インタフェースを含むＰＣ等の従来の適切にプログラムされたコンピュータであってもよい。いくつかの実施形態において、ローディング装置は、ロードされるソフトウェアバージョンや構成データ等のペイロード・データを生成してもよい。特に、ローディング装置は、ペイロード・データと共にロードされる証明書及びデジタル署名を生成してもよい。他の実施形態において、ローディング装置は、パーソナルコンピュータ、ワークステーション、ネットワークサーバ等のリモートコンピュータからペイロード・データ及びヘッダ情報を受信する。データは、例えばフロッピディスク、ＣＤ ＲＯＭ等のコンピュータ可読媒体上に、インターネット、ローカルエリアネットワーク、イントラネット、エクストラネット等のコンピュータネットワークを介して又は他の適切な手段により受信されてもよい。本実施形態において、署名の計算及び証明書の生成は、ローディング装置ではなくリモートコンピュータにより実行されてもよい。ローディング装置は、移動端末と協働して移動端末へのデータのロードを実行する。

移動端末１０２は、通信インタフェース１０４を含む。通信インタフェース１０４は、移動端末が直接データリンク又は通信ネットワーク等の有線又は無線通信リンクを介してローディング装置とデータを通信することを可能にするのに適した装置と回路網との少なくともいずれかを含む。例えば、データは、Ｂｌｕｅｔｏｏｔｈ接続又は赤外線接続等のローカル狭域無線通信リンクを介して、あるいは有線インタフェースを介してロードされてもよい。他の実施形態において、データは、ＧＳＭ ＷＣＤＭＡ等の携帯通信網を介するＯＴＡ（over-the-air）等の通信網を介して移動端末にロードされてもよい。

従って、適切な通信ユニットの例には、ＩＥＥＥ１３９４規格等で説明されるようなＲＳ−２３２リンク、ＵＳＢ接続、ＦｉｒｅＷｉｒｅ接続等の有線シリアル接続が含まれる。更なる例として、携帯電話（不図示）のメインアンテナ又はＢｌｕｅｔｏｏｔｈトランシーバ等の携帯電話内の別のアンテナ等のＲＦインタフェース又は無線赤外線インタフェースを含む。適切なインタフェースの他の例は、ケーブルモデム、電話モデム、統合デジタル通信網（ＩＳＤＮ）アダプタ、デジタル加入者回線（ＤＳＬ)アダプタ、衛星トランシーバ又はイーサネット（登録商標）アダプタを含む。

移動端末は、移動端末の動作を制御する処理ユニット１０５及びメモリ１０６を更に含む。例えば、処理ユニットは、汎用又は専用プログラマブルマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、プログラマブルロジックアレイ（ＰＬＡ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）又はそれらの組合せを含んでもよい。メモリ１０６は、不揮発性メモリ等のフラッシュメモリ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、あるいは任意の他の種類のメモリ又は記憶装置であってもよい。

データが移動端末にロードされる場合、処理ユニット１０５は、本明細書において説明されるデータ認証及び完全性保護を実行し、データをメモリ１０６に格納する。

移動端末の後続の動作中に、処理ユニットは、ロードされたデータをメモリ１０６から検索できる。例えばソフトウェアの場合、処理ユニットは、実行するためにソフトウェアをメモリ１０６からＲＡＭにロードする。

図２は、シングルチップアーキテクチャを有する移動端末の一例を示すブロック図である。移動端末１０１は、移動端末の動作を制御する制御器１０５を含む。制御器１０５は、フラッシュプログラムメモリ１０６及びランダムアクセスメモリ（ＲＡＭ）２０９と連携して動作する。制御器１０５は、マイクロプロセッサ２０８、内部読み出し専用メモリ（ＲＯＭ）２０７及びセキュリティ上安全に格納された秘密鍵２１８を含む。例えば、秘密鍵２１８は、例えばいわゆるe-fuse技術を使用してハードウェアに格納されたチップ固有の鍵であってもよい。あるいは、秘密鍵はＲＯＭ２０７に格納されてもよい。ＲＯＭ２０７は、ブートコード、ハッシュコード、ＭＡＣコード、認証コード及び公開ルート鍵を含む。いくつかの実施形態において、ハッシュコード及び／又はＭＡＣコードは、ＲＯＭに実装される代わりに又はそれに加えて少なくとも部分的にハードウェアに実装されてもよい。携帯電話の一般的な動作に関わる命令コードは、フラッシュプログラムメモリ１０６に含まれる。ＲＡＭメモリ２０９は、正常な移動端末通話処理の一部である動作に対して使用される。いくつかの実施形態において、感知可能データ、ハッシュ値の計算及び認証処理を含む動作は、マイクロコントローラ１０５に含まれる保護スタティックランダムアクセスメモリ（ＰＳＲＡＭ）（不図示）と連携して実行される。制御器１０５は、メモリバス２１９を介してフラッシュプログラムメモリ１０６及びＲＡＭ２０９と通信する。

図３は、２チップアーキテクチャを有する移動端末の一例を示す概略ブロック図である。本実施形態において、制御器１０５は、２つのチップ３１０及び３１３、外部メモリ１０６、並びに内部メモリ２０９を含む。２つのチップは、少なくとも１つのマイクロプロセッサ３１２及び３１５、並びにＲＯＭ３１１及び３１４をそれぞれ含む。外部メモリ１０６は、任意の適切な種類の不揮発性メモリであり、例えばフラッシュメモリである。内部メモリ２０９は高速アクセスメモリであり、例えばＲＡＭである。図３の実施形態において、２つのチップは、内部メモリ２０９を共有する。更に、本実施形態において、チップ３１３のみが外部メモリ１０６に直接アクセスする。従って、チップ３１０のプロセッサ３１２が外部メモリ１０６に格納されたソフトウェアを実行する場合、実行されるソフトウェアは、実行される前にチップ３１３を介して内部メモリ２０９にロードされる。本実施形態において、ＲＯＭ３１１及び３１４の双方がブートコードを含むが、ＲＯＭ３１１のみがハッシュコード、ＭＡＣコード、認証コード及び公開ルート鍵を含み、チップ３１０のみが秘密鍵３１８を含む。上述のように、秘密鍵３１８は、例えばいわゆるe-fuse技術を使用してハードウェアに格納されてもよい。あるいは、秘密鍵はＲＯＭ３１１に格納されてもよい。更に、いくつかの実施形態において、ハッシュコードとＭＡＣコードとの少なくともいずれかは、ＲＯＭに実装される代わりに又はそれに加えて少なくとも部分的にハードウェアに実装されてもよい。

図４は、２チップアーキテクチャを有する移動端末の別の例を示す概略ブロック図である。本実施形態は、本実施形態の２つのチップ３１０及び３１３が共通の内部メモリを共有しないことを除いて図３の実施形態と同様である。各チップは、各々の内部メモリ４１６及び４１７を有する。図３の実施形態と同様に、チップ３１３のみが外部メモリ１０６に直接アクセスする。従って、チップ３１０のプロセッサ３１２が外部メモリ１０６に格納されたソフトウェアを実行する場合、実行されるソフトウェアは、実行される前にチップ３１３を介してチップ３１０の内部メモリ４１６にロードされる。

共有の又は個別のＲＡＭ（ランダムアクセスメモリ）を含む別の２チップの実施形態において、双方のチップは、外部不揮発性メモリに直接アクセスし、実行されるソフトウェアをメモリから直接実行してもよく、あるいは最初にＲＡＭにロードして、その後実行してもよい。

図５は、ソフトウェアを移動端末にロードするロード処理において使用されるメッセージ構成の一例を示す。メッセージ５２０は、ヘッダセクション５２１、ペイロードセクション５２２、デジタル証明書セクション５２３及びデジタル署名５２４を含む。

ペイロードセクション５２２は、移動端末にロードされる実際のペイロード・データを含む。ペイロード・データは、アプリケーションソフトウェア、他のソフトウェアのロードを管理及び／又は制御するためのプリローダソフトウェア、あるいは移動端末のオペレーティングシステムの一部等のソフトウェアを含んでもよい。あるいは又はそれに加えて、ペイロード・データは、フラッシュメモリ、あるいはＥＰＲＯＭ又はＥＥＰＲＯＭ等の移動端末の他のメモリに格納する構成データ等の他のデータを含んでもよい。

ヘッダセクション５２１は、バージョン制御データ等のペイロード・データに関する情報、移動端末に関する情報及び／又は移動端末のデータ処理方法を判定する制御パラメータ等のロード処理に関連する情報を含む。

署名セクションは、ペイロード５２２のデジタル署名を含む。デジタル署名は、ＲＳＡ（Rivest、Shamir及びAdleman）方式等の非対称暗号方式の１組の公開鍵／秘密鍵を使用して計算される。デジタル署名は、ペイロード・データの一方向ハッシュ関数、すなわち移動端末にロードされるソフトウェア及び／又はデータの一方向ハッシュ関数を最初に計算することにより計算される。計算されたハッシュ値は、１組の公開鍵／秘密鍵の秘密鍵を使用して暗号化される。

一方向ハッシュ関数は、ペイロード・データ５２２のハッシュ値の例を得るのに使用される。公開鍵／秘密鍵方式は、有効なハッシュ値に対してセキュリティを提供し且つメッセージ５２０を送信するデータ転送装置又はローディング装置を認証するために使用される。

一方向ハッシュ関数は、順方向の演算が容易であり且つ逆方向の演算が困難な関数である。一方向ハッシュ関数Ｈ（Ｍ）は、任意の長さの入力Ｍに作用する。いくつかの実施形態において、Ｍは、ペイロード・データ５２２又はペイロード・データの選択された部分により構成される。Ｍに対して実行されるハッシュ関数は、固定の長さのハッシュ値ｈ＝Ｈ（Ｍ）を返す。

任意の長さの入力を使用し且つ固定の長さの出力を返す関数が多く存在するが、一方向ハッシュ関数は以下の追加の特性を有する。Ｍを与えた場合にｈを演算するのは容易であるが、ｈを与えた場合にＭを演算するのは困難であり、Ｍを与えた場合にＨ（Ｍ）＝Ｈ（Ｍ’）となるような他のメッセージＭ’を見つけるのは困難である。一方向ハッシュの目的は、Ｍの「指紋」又は固有の署名を提供することである。ハッシュ関数の出力は、ハッシュ値又はメッセージダイジェストと呼ばれる。

本明細書において説明される方法の実施形態において、移動端末にメッセージ５２０を送信する前に、セキュリティ上安全な一方向ハッシュ関数は、ペイロード・データ５２２又はペイロード・データ５２２の選択されたコンテンツに対して実行され、参照ハッシュ値を生成する。以下に更に説明するように、参照ハッシュ値は、デジタル署名としてメッセージ５２０に含まれる。メッセージ５２０を受信すると、移動端末は、ペイロード・データ５２２（又はペイロード・データ５２２の選択されたコンテンツ）の監査ハッシュ値を計算し、メッセージ５２０の一部として受信された参照ハッシュ値と監査ハッシュ値を比較する。

適切な一方向ハッシュ関数は、例えばＳＨＡ−１関数である。適切な関数の他の例は、ＭＤ５アルゴリズム、Ｓｎｅｒｆｕ、Ｈ−Ｈａｓｈ、ＭＤ２又はＭＤ４等を含む。

公開鍵アルゴリズムは、メッセージの暗号化及び復号化、メッセージ認証、並びにデジタル署名等のタスクに対して、２つの鍵、すなわち非公開に保持される（秘密の）鍵と公開されて利用可能な鍵とを使用する。送信者が秘密鍵でメッセージを暗号化する場合、秘密鍵を所有してる送信者のみがメッセージを暗号化できたため、対応する公開鍵を有する任意の受信者は送信者の信頼性を保証される。本明細書において説明されるロード処理に従ってペイロード・データを認証するのに利用されるのは後者の方式である。適切な公開鍵アルゴリズムはＲＳＡアルゴリムである。他の適切な例は、Ｆｉａｔ−Ｓｈａｍｉｒ（ＦＳ）アルゴリズム、ＥＬＧＡＭＡＬ、ＤＳＡ又はＦｉｅｇａ−Ｆｉａｔ−Ｓｈａｍｉｒ等を含む。

特に、本明細書において説明されるロード処理において、計算されたハッシュ値は、ローディング装置（又はペイロードの発生器）の秘密鍵で暗号化され、メッセージ５２０に含まれるデジタル署名５２４を生成する。

対応する公開鍵は、メッセージ５２０のデジタル証明書セクション５２３に含まれる証明書に含まれる。デジタル証明書は、特定の認証された個人を特定の公開鍵に結び付ける公開鍵方式において使用されるデータ構造である。デジタル証明書は情報のデジタル表現であり、その情報は、デジタル証明書を発行する認証機関を識別し、公開鍵が含まれる個人に名前を付けるか又はその個人を識別し、且つ個人の公開鍵を含む。デジタル証明書はデジタル証明書を発行する認証機関によりデジタル署名され、それにより、受信者は認証機関の公開鍵を使用することにより証明書を認証できる。

デジタル証明書セクションは、単一のデジタル証明書を含んでもよく、あるいは証明書のチェーンを含んでもよいことが理解される。いずれの場合においても、証明書又は証明書のチェーンは、単一の証明書又は証明書チェーンの最後の証明書に対応するルート公開鍵を使用して移動端末により認証される。国際公開第ＷＯ０３／０６０６７３号において、ソフトウェアの移動電話へのロードに関連する鍵階層の一例が説明される。

いくつかの実施形態において、例えば国際公開第ＷＯ０３／０６０６７３号において説明されるように、ペイロードはデジタル署名を計算する目的で複数の小さな部分に分割されてもよく、あるいは署名のみが計算されてもよいことが理解される。

通常、ペイロード・データ５２２と共にヘッダデータ５２１を保護することが望ましい。いくつかの実施形態において、これは、デジタル署名によりヘッダデータ５２１自体を保護することにより達成される。他の実施形態において、計算されたハッシュ値の上述の暗号化は、例えばソフトウェア（及びデータ）５２２に対して計算されたハッシュ値ｈ（ＳＷ）及びヘッダデータ５２１に対して計算されたハッシュ値ｈ（Ｈ）の連結ｈ（ＳＷ）｜ｈ（Ｈ）を暗号化／署名することによりヘッダデータ５２１に対して計算されたハッシュ値を暗号化することを更に含む。

図６は、ソフトウェアバージョンの最初のロードに対するソフトウェアロード処理を示すフローチャートである。

最初のステップ６０１において、上述したように、移動端末は、ＧＳＭ、ＷＣＤＭＡ等のローカルインタフェース又はリモートインタフェースを介して再プログラミングツールからソフトウェアデータパケットを受信する。図５と関連して上述したように、パケットは、新しいソフトウェアＳＷ、１つ以上の証明書Ｃ、並びに保護されたソフトウェア及びデータのデジタル署名Ｓ（ｈ_r）を含む。オプションとして、新しいソフトウェアは構成データ等のデータを含んでもよい。署名Ｓ（ｈ_r）は、少なくともソフトウェア及びデータから計算された暗号化ハッシュ値を含む。まずソフトウェア及びデータＳＷの１方向ハッシュｈ_r＝Ｈ（ＳＷ）が計算され、次に少なくとも計算されたハッシュ値が１組のＲＳＡ公開鍵／秘密鍵等の１組の公開鍵／秘密鍵の秘密鍵を使用して暗号化されるように、署名は計算される。対応する公開鍵は、ソフトウェアデータパケットに含まれる証明書に含まれる。ソフトウェア及びデータパケットを受信すると、移動端末は、ソフトウェア、データ、証明書及び署名を外部メモリ１０６に格納する。図５と関連して上述したように、いくつかの実施形態において、署名は、例えばソフトウェアから計算されたハッシュ値とヘッダから計算されたハッシュ値との組合せを暗号化することにより、ペイロードだけでなくヘッダデータも保護してもよい。

ステップ６０２において、移動端末のプロセッサは、新しく格納されたソフトウェア及びデータＳＷ、証明書Ｃ、並びに署名Ｓ（ｈ_r）を内部メモリに読み出す。

ステップ６０３において、プロセッサは、新しいソフトウェア及びデータＳＷの一方向監査ハッシュ値ｈ_a＝Ｈ（ＳＷ）を計算する。

ステップ６０４において、プロセッサは、メモリ６０５からルート公開鍵ＰＫを読み出す。いくつかの実施形態において、ルート公開鍵はセキュリティ上安全に格納される。すなわち、ルート公開鍵の完全性が保護される。一実施形態において、上述のように、ルート公開鍵はプロセッサの内部ＲＯＭに格納される。プロセッサは、ルート公開鍵ＰＫを使用して新しいソフトウェア及びデータの署名Ｓ（ｈ_r）を検証する。１つの証明書のみが使用される場合、署名Ｓ（ｈ_r）は、証明書Ｃの公開鍵に対して検証される。その結果、証明書Ｃはルート公開鍵ＰＫに対して検証される。いくつかの証明書が使用される場合、証明書のチェーン全体が検証される。そのような場合、チェーンの最後の証明書の署名がルート公開鍵に対して検証される。従って、ステップ６０４において、プロセッサは、新しいソフトウェア及びデータに署名するのに使用される公開鍵を検証する。検証が正常に行なわれた場合、プロセッサはステップ６０６に進み、署名を検証する。検証が正常に行なわれなかった場合、ソフトウェアロード処理は中止される。

ステップ６０６において、プロセッサは、ステップ６０４で検証された公開鍵を使用してソフトウェア及びデータのデジタル署名Ｓ（ｈ_r）を復号化し、参照ハッシュ値ｈ_rを結果として得る。

ステップ６０７において、復号化された署名、すなわち参照ハッシュ値ｈ_rは、ステップ６０３で計算された一方向監査ハッシュ値ｈ_aに対して検証される。検証が正常に行なわれた場合、すなわち監査ハッシュ値ｈ_aと参照ハッシュ値ｈ_rとが同等である場合、プロセッサはステップ６０８に進み、参照メッセージ認証コード（ＭＡＣ）を計算する。値が同等でない場合、ソフトウェアロード処理は中止される。

ステップ６０８において、プロセッサは、検証された一方向ハッシュ値ｈ_a（＝ｈ_r）及びチップ固有の鍵Ｋ（又はＫから得られる値）をＭＡＣ計算関数に対する入力値として使用し、参照メッセージ認証コード値ｔ_r＝ＭＡＣ（ｈ_a；Ｋ）を結果として得る。ＭＡＣ関数の出力値は、新しいソフトウェア及びデータの参照ＭＡＣ値である。いくつかの実施形態において、チップ固有の鍵Ｋは、プロセッサのみがアクセス可能なセキュリティ上安全なメモリに格納される。例えば、固有の鍵Ｋは、例えばいわゆるe-fuse技術を使用して、製造工程中にチップに焼き付けられてもよい。メッセージ認証コードの実施形態については以下に説明する。プロセッサは、新しいソフトウェア及びデータＳＷと共に新しい参照ＭＡＣ値ｔ_rを外部メモリ１０６に格納する。オプションとして、証明書及びデジタル署名値は外部メモリから除去される。

上述のロード処理は、移動端末のプロセッサにより制御される。図３及び図４と関連して説明されたような２チップアーキテクチャにおいて、上記ステップはチップ３１１により実行され、チップ３１１はその後ソフトウェアを実行する。

受信データを認証する暗号化関数及び実際にはＭＡＣ関数は、上記ステップを実行するプロセッサの内部ＲＯＭに例えばブートコードの一部として格納される専用ソフトウェアにより実行されてもよい。

従って、この時点において、格納された参照ＭＡＣ値は、プロセッサによるソフトウェア及びデータの後続の監査に対して利用可能である。例えば格納されたソフトウェアの完全性を検証するために、プロセッサは、チップ固有の鍵Ｋを使用して、格納されたソフトウェア及びデータの監査ハッシュ値ｈ（ＳＷ）、並びに計算された監査ハッシュ値の監査ＭＡＣ値ｔ_a＝ＭＡＣ（ｈ（ＳＷ）；Ｋ）を計算する。プロセッサは、計算された監査ＭＡＣ値ｔ_aを格納された参照ＭＡＣ値ｔ_rと比較する。２つの値が同等である場合、ソフトウェアの完全性が検証される。

例えば米国特許第６，０２６，２９３号公報において説明されるように、そのような監査は、移動端末のブート処理中及び／又はソフトウェアが実行される度及び／又は所定の時間間隔で周期的に実行されてもよい。

図７は、メッセージ認証コード（ＭＡＣ）の一実施形態の計算を示す。ＭＡＣは、可変長の入力Ｍ及び鍵Ｋを利用して固定の長さの出力ｔ、いわゆるＭＡＣ値又はタグ値ｔ＝ＭＡＣ（Ｍ；Ｋ）を生成する関数である。いくつかの実施形態において、Ｍの知識を有し且つＫの値に関する情報を有さない侵入者にとって、同一のタグ値を有するＭとは異なるメッセージＭ’を見つけるのが計算上困難（実行不可能）となるように、ＭＡＣは規定される。更に、ＭＡＣ関数は、メッセージＭの知識を有し且つＫの値に関する情報を有さない侵入者にとって正確なタグ値ｔを予測することが困難であるように規定されてもよい。本明細書において説明されるロード方法において、ＭＡＣは、信頼性のない又はセキュリティ上安全でない媒体に格納されたデータの完全性をチェックするのに使用される。すなわち、この状況において、ペイロード・データを格納し且つ検索する場合、ＭＡＣは、１つの装置、すなわち移動端末によってのみ使用される。いくつかの実施形態において、ＭＡＣ関数は、暗号ハッシュ関数に基づき、特に上述のように受信したペイロード・データを認識するのに使用されるハッシュ関数Ｈに基づく。これにより、後続する完全性保護のためにＭＡＣ値を計算する場合、受信したペイロード・データの認証中に計算されたハッシュ値を再利用できるため、ＭＡＣ値の演算に対する計算上の労力が大幅に減り、インストール時間が減少される。

図７は、ＭＡＣ計算モジュールを示すブロック図である。ＭＡＣ計算モジュールは、ＭＡＣ関数計算機７３２を含む。ＭＡＣ関数計算機７３２は、受信したペイロードに対する先の署名検証処理７３６の間に計算された検証ハッシュ値であるｈを入力として受信する。すなわち、ｈ＝ｈa又はｈ＝ｈ_rである。ＭＡＣ関数７３２は、チップ固有の鍵Ｋから得られる秘密鍵Ｋ’を第２の入力として受信する。特に鍵Ｋ’は、例えばＳＨＡ−１等のハッシュ関数に基づく擬似ランダム関数である擬似ランダム関数７３１を使用して、チップ固有の鍵Ｋ及びモード識別子７３５から生成されてもよい。例えば、チップ固有の鍵Ｋは、チップのＡＳＩＣ製造中に生成される乱数であってもよい。マスタ鍵Ｋから鍵Ｋ’を得ることは、異なる鍵Ｋ’が、例えば異なる種類のソフトウェアを保護するために又はソフトウェアの異なる部分を保護するためになど、異なる目的で使用されてもよいという利点を有する。これにより暗号分離を保証し、方法の融通性を向上する。モード識別子７３５は、異なるモードの選択を可能にする。例えば、マルチチップの例において、異なるモードは、ソフトウェアの各目標チップに対して使用されてもよい。適切なＭＡＣ関数の例は、ＨＭＡＣ（メッセージ認証のための鍵付ハッシング）、例えばＡＥＳ又はセキュリティ上安全な一方向ハッシュ関数を使用する暗号ブロック連鎖（ＣＢＣ）ＭＡＣを含む。例えばＣＢＣ−ＭＡＣは、A.J. Menezes、P.C van Oorschot、S.A. Vanstoneによる「Handbook of Cryptology」３５３ページ、CRC Press、１９９７年に示される。ここで、ＡＥＳブロック暗号化暗号文は、ブロック暗号文Ｅとして使用される。上述のように、ＭＡＣ関数７３２は対応するタグ値ｔを生成する。

ＭＡＣ値の無許可の演算を防止するために、ＭＡＣ回路網は、正常な署名検証が演算前に行われた場合のみ、演算されたＭＡＣ値ｔを解放する。従って、ＭＡＣ計算モジュールは、受信したペイロード・データのデジタル署名が正常に検証されたかを示す署名検証処理７３６から更なる入力７３３を受信する。ブロック７３４は、タグ値及び信号７３３を入力として受信し、ハッシュ値ｈが検証されたハッシュ値、すなわち信頼できるハッシュ値であることを信号７３３が示す場合に計算されたタグ値を解放する。例えば、図６の方法において、信号７３３はステップ６０７により生成される。

尚、ＭＡＣ演算モジュールは、プロセッサチップ上の別個のＭＡＣ演算回路網として実現されてもよい。更に、演算されたＭＡＣ値と参照値との間の後続する比較は、ＭＡＣ回路網に接続される比較回路の内部で実行される。更に、秘密鍵Ｋは、回路網の一部として格納されてもよい。従って、ＭＡＣ演算の全体は専用回路に制限されてもよいため、演算されたＭＡＣの回路網外への露出／解放を必要としない。

図７のＭＡＣ計算は、セキュリティ上安全なバージョン制御を更に含み且つＭＡＣ演算への入力ｈの予測可能度をなくすように、計算上非常に安価に更に改善される。次に、ＭＡＣ計算のこの別の実施形態について、図８及び図９を参照して説明する。

図８は、バージョン制御機構を含むメッセージ認証コードの別の実施形態の計算を示す。図９は、バージョン制御処理を示すフローチャートである。

ＭＡＣ回路８００の本実施形態によると、ブロック７３２におけるＭＡＣ演算は、４個組（ｒａｎｄ，ｈ，ｃｎｔ，ｂａｃｋ_ｃｎｔ）８４４に対して実行される。４個組８４４は、短い（例えば、６４ビット）乱数randを含み、ＭＡＣ演算への入力が署名検証処理７３６からの入力による完全な制御下にないことを保証する。４個組は、先の実施形態と同様に検証されたハッシュ値ｈを更に含む。最後に、４個組は、以下に説明されるバージョン制御機構のバージョン制御カウンタｃｎｔ及びバージョン制御バックカウンタｂａｃｋ_ｃｎｔを含む。ＨＭＡＣ又はＣＢＣ−ＭＡＣ等のＭＡＣ関数７３２は、図７と関連して説明されたように秘密鍵Ｋ’を更に受信し、４個組及び秘密鍵Ｋ’からＭＡＣ値ｔを計算する。同様に、図７と関連して説明したように、計算されたタグ値ｔは、署名検証処理がハッシュ値ｈを検証したことを署名信号７３３が示す場合にのみ解放される。

４個組８４４は、先に受信したソフトウェアバージョンのバージョン制御リスト８４２を維持するバージョン制御モジュール８４１により生成される。特に、バージョン制御リスト８４２は、データレコードのリストを含む。ここで、各データレコードは、先に観察したハッシュ値に対応する４個組を含む。最後のハッシュ値を含むレコードは、実際にインストールされた／使用されているソフトウェアに対応するリスト８４２の最上位の要素と呼ばれる。

上述のように、バージョン制御モジュール８４１は、署名が正常に検証されたことを示すデジタル信号７３３及び検証されたハッシュ値ｈを署名検証処理から受信する。更に、バージョン制御モジュール８４１は、ソフトウェアバージョンカウンタｃｎｔ及び数ｂａｃｋ_ｃｎｔを署名検証処理７３６から受信する。数ｂａｃｋ_ｃｎｔは、所定のソフトウェアバージョンがインストールされてからインストールされてもよい先のバージョンの数を示す。例えば、ｂａｃｋ_ｃｎｔは、０〜Ｃ_MAXの間の数であってもよい。例えば、Ｃ_MAX＝１５である。ｂａｃｋ_ｃｎｔ＝０は、新しいソフトウェアが先のバージョンと置換されることを許可しないことを意味する。従って、ｂａｃｋ_ｃｎｔは、ロードされたソフトウェアの上位互換性及び下位互換性を制御する単純で効果的な機構を実現する。いくつかの実施形態において、ｃｎｔ及びｂａｃｋ_ｃｎｔの値は、ロード処理中に受信されるソフトウェアパケットの一部として、例えば受信したソフトウェアパケットのヘッダセクションの一部として受信される。

ロード処理中に新しいハッシュｈ、新しいカウンタｃｎｔ、新しいｂａｃｋ_ｃｎｔ値及び信号７３３を署名検証処理７３６から受信すると（ステップ９０１）、バージョン制御モジュール８４１は、信号７３３を使用して、ハッシュ値ｈが署名検証処理７３６中に検証されたかを検証する（ステップ９０２）。ハッシュ値ｈが検証されなかった場合、バージョン制御モジュール８４１はｈの値を保護する。すなわち、バージョン制御及びＭＡＣ計算処理が中止される。ハッシュ値の信頼性があることを信号７３３が示す場合、バージョン制御モジュール８４１はステップ９０３に進む。

ステップ９０３において、バージョン制御モジュール８４１は、受信したハッシュ値をバージョン制御リスト８４２のハッシュ値と比較する。受信したハッシュ値ｈがバージョン制御リスト８４２中の先のハッシュ値ｈ_prevの１つと同等である場合、バージョン制御モジュール８４１はステップ９０４に進む。同等でない場合、ステップ９０６に進む。

ステップ９０４において、すなわち受信したハッシュ値ｈが先のハッシュ値ｈ_prevの１つと同等である場合、処理は、対応する４個組（ｒａｎｄ，ｈ，ｃｎｔ，ｂａｃｋ_ｃｎｔ）_prevを検索し、先のバージョンのカウンタ値ｃｎｔ_prevが署名検証処理７３６から受信された値ｃｎｔ及びｂａｃｋ_ｃｎｔにより規定される許容範囲内にあるかを判定する。いくつかの実施形態において、許容範囲は範囲［ｃｎｔ_top−ｂａｃｋ_ｃｎｔ，∞）と定義される。ここで、ｃｎｔ_topは、リストの現在最上位にある要素のｃｎｔ値である。単純化するために、許容値の範囲に対して上限は存在しないと仮定する。しかし、他の実施形態において、上限が規定されてもよいことは理解される。

ｃｎｔ_prevが許容範囲内にある場合、バージョン制御モジュール８４１は、構成要素ｒａｎｄ_new＝バージョン制御モジュール８４１により生成された新しい乱数、ｈ_new＝ｈ、ｃｎｔ_new＝ｃｎｔ_prev、ｂａｃｋ_ｃｎｔ_new＝ｂａｃｋ_ｃｎｔ_prevを含む新しい４個組（ｒａｎｄ，ｈ，ｃｎｔ，ｂａｃｋ_ｃｎｔ）_newを生成し（ステップ９０５）、バージョン制御モジュールは、同一のｈ値を含む先の組を新しい組で置換し、新しい組を最上位の要素としてリストに設定する。

ステップ９０３のテストにより、ｈが先のハッシュ値の１つと同等でないことが示される場合、新しい乱数、ハッシュ値ｈ及びカウンタは、許容されるｂａｃｋ_ｃｎｔ（ｈと関連付けられる）と共にバージョン制御リストに格納される（ステップ９０６）。この場合、新しい４個組（ｒａｎｄ，ｈ，ｃｎｔ，ｂａｃｋ_ｃｎｔ）_newは、ｒａｎｄ_new＝新しい乱数、ｈ_new＝ｈ、ｃｎｔ_new＝ｃｎｔ、ｂａｃｋ_ｃｎｔ_new＝ｍｉｎ（ｂａｃｋ_ｃｎｔ，ｃｎｔ−ｍｉｎ_ａｌｌｏｗｅｄ_ｖｅｒｓｉｏｎ）に従って作成され、新しい組がリストの最上位の要素となる。ここで、ｍｉｎ_ａｌｌｏｗｅｄ_ｖｅｒｓｉｏｎは、更新リストの任意の組により現在許容される最小のバージョンである。エントリが更新リストの最上位に配置された後、ｍｉｎ_ａｌｌｏｗｅｄ_ｖｅｒｓｉｏｎは、ｃｎｔ_top−ｂａｃｋ_ｃｎｔ_topとして、すなわち最上位の要素のカウンタｃｎｔ_top及びｂａｃｋ_ｃｎｔバージョンから再度演算される（ステップ９０７）。最後に、リストの全ての要素は、それらのｂａｃｋ_ｃｎｔ値が許容される最小のバージョンｍｉｎ_ａｌｌｏｗｅｄ_ｖｅｒｓｉｏｎより小さいバージョン番号を与えない可能な最大値となるように更新される（ステップ９０８）。リストが許容範囲外のバージョンを有するエントリを含む場合、そのエントリは削除される。

いくつかの実施形態において、ＭＡＣチェック値（ＭＡＣＬＩＳＴ）は、リスト中のエントリの無許可の操作を防止するためにバージョン制御リストと関連付けられ、それにより方法のセキュリティを更に向上させる。ＭＡＣＬＩＳＴ値は、リストが更新された場合にのみ、すなわち正常な署名検証の後にのみ更新される。バージョン制御リストにアクセスする前／リストを使用する前に、現在のＭＡＣチェック値はＭＡＣＬＩＳＴ値に対してチェックされる。ＭＡＣＬＩＳＴ値の無許可の演算を防止するために、正常な署名検証が演算の前に行なわれた場合のみ、ＭＡＣ回路網は演算したＭＡＣ値を解放する（図７及び図８のブロック７３４により制御されるように）。

従って、この時点で、格納された参照ＭＡＣ値及びバージョン制御リストは、プロセッサによるソフトウェア及びデータの後続する監査に対して利用可能である。例えば、格納されたソフトウェアの完全性を検証するために、プロセッサは、格納されたソフトウェア及びデータの監査ハッシュ値ｈ_a＝ｈ（ＳＷ）を計算し、バージョン制御リストから検索される値ｒａｎｄ、ｃｎｔ及びｂａｃｋ_ｃｎｔを含む監査組（ｒａｎｄ，ｈ_a，ｃｎｔ，ｂａｃｋ_ｃｎｔ）を生成する。プロセッサは、これをもとに、チップ固有の鍵Ｋを使用して、計算された監査組の監査ＭＡＣ値ｔ_a＝ＭＡＣ（（ｒａｎｄ，ｈ_a，ｃｎｔ，ｂａｃｋ_ｃｎｔ）；Ｋ）を計算する。プロセッサは、計算された監査ＭＡＣ値ｔ_aを格納された参照ＭＡＣ値ｔ_rと比較する。２つの値が同等である場合、ソフトウェアの完全性は検証される。

上述のように、そのような監査は、移動端末のブート処理中及び／又はソフトウェアが実行される度及び／又は所定の時間間隔で周期的に実行されてもよい。

次に、上記処理について、一例として図１０を参照して更に説明する。

図１０は、サイズが３のバージョン制御リストが使用される場合、すなわちバージョン制御リストが３個組を格納できる場合のバージョン制御機構の一例を示す。この例において、署名検証処理から受信したハッシュ値ｈ、バージョンカウンタｃｎｔ及びバックカウンタｂａｃｋ_ｃｎｔの以下の値（ｈ，ｃｎｔ，ｂａｃｋ_ｃｎｔ）を含む８つのソフトウェアバージョンリリースのシーケンスが存在すると更に仮定する。

バージョン１：（Ｈ１，１，０）
バージョン２：（Ｈ２，２，１）
バージョン３：（Ｈ３，３，２）
バージョン４：（Ｈ４，４，３）
バージョン５：（Ｈ５，５，２）
バージョン６：（Ｈ６，６，３）
バージョン７：（Ｈ７，７，４）
バージョン８：（Ｈ８，８，４）。

上記バージョンが、適用されたなかったバージョン７を除くシーケンスに適用されたと更に仮定する。図１０は、バージョン８のインストール後のバージョン制御リスト１００１を示す。バージョン制御リスト１００１の各行は、インストールされたバージョンの１つに対する対応する４個組を含む。リストの最上位の要素である行１００２はバージョン８に対応し、行１００３はバージョン６に対応し、行１００４はバージョン５に対応する。Ｒ８、Ｒ６及びＲ５は、上述のようにバージョン制御モジュールにより生成された乱数である。バージョン８が適用された後、許容される最小のバージョンは４（バージョン８のｃｎｔが８であり且つバージョン８のｂａｃｋ_ｃｎｔが４であるため、８−４＝４）であったため、ｍｉｎ_ａｌｌｏｗｅｄ_ｖｅｒｓｉｏｎ＝４である。従って、リスト中の残りのエントリのｂａｃｋ_ｃｎｔ値は、バージョン８が追加された後の許容される最小のバージョンに対する制限を満足するためにバージョン８のインストール中に調整されている。特に、行１００２のｂａｃｋ_ｃｎｔ値は２に設定され、行１００３のｂａｃｋ_ｃｎｔ値は１に設定されている。バージョン８で更新する前、許容される最小のバージョンは３であったが、この値はバージョン８により４に増加されている。

図１０は、バージョン７のインストール後のバージョン制御テーブル１０１１を更に示す。最初に、バージョン７のカウンタ値ｃｎｔは７であり、すなわち現在のバージョンの許容範囲内にある。ハッシュ値Ｈ７は、バージョン制御リスト１００１に存在していないため、新しいハッシュ値Ｈ７を含む新しい４個組１００７は、バージョン制御テーブル１０１１の新しい最上位の要素１０１２として格納される。前の最上位の要素は、リストの下方に移動し、行１０１３に対応する。この時、バージョン６は行１０１４に配置されている。この例において、バージョン制御リストには３つの４個組に対する空間しか存在しないため、バージョン５はリストから除去される。現在許容される最小のバージョンの制限（ｍｉｎ_ａｌｌｏｗｅｄ_ｖｅｒｓｉｏｎ＝４)を満足するために、新しい最上位の要素１０１２のｂａｃｋ_ｃｎｔの値は３に設定される。

図１１は、ソフトウェアのアップグレードに対するソフトウェアロード処理を示すフローチャートである。処理は、最初にソフトウェアをロードする図６に示される処理と同様である。

最初のステップ１１０１において、上述のように、移動端末は、ＧＳＭ、ＷＣＤＭＡ等のローカルインタフェース又はリモートインタフェースを介して再プログラミングツールからソフトウェアアップグレードデータパケットを受信する。図５と関連して上述したように、パケットは、保護されたソフトウェアの新しいソフトウェアアップグレードΔ、１つ以上の証明書Ｃ及びデジタル署名Ｓ（ｈ_r）を含む。オプションとして、ソフトウェアは、更新された構成データ等のデータを更に含んでもよい。一実施形態において、新しいソフトウェアは、現在のソフトウェアに対する新しいソフトウェアの差異を含むいわゆるデルタファイルとしてロードされ、アップグレードパケットのサイズを減少する。デルタファイル技術は、従来技術において周知であり、例えばChristian Reichenbergerによる「Delta storage for arbitrary non-text files」Proc. Of the 3rd International Workshop on Software Configuration Management、１４４〜１５２ページ、ノルウェー、１９９１年６月において説明される。あるいは、他のアップグレードファイル生成方法が使用されてもよく、又は新しいソフトウェア全体が受信されてもよい。署名Ｓ（ｈ_r）は、新しいソフトウェアから計算される暗号化ハッシュ値を含む。まず新しいソフトウェアＳＷの一方向ハッシュｈ_r＝Ｈ（ＳＷ）が計算され、次にハッシュ値が１組のＲＳＡ公開鍵／秘密鍵等の１組の公開鍵／秘密鍵の秘密鍵を使用して暗号化される。対応する公開鍵は、ソフトウェアアップグレードパケットに含まれる証明書に含まれる。ソフトウェアアップグレードパケットを受信すると、移動端末は、ソフトウェアアップグレード、証明書及び署名を外部メモリ１０６に格納する。

ステップ１１０２において、移動端末のプロセッサは、新しく格納されたソフトウェアアップグレード、証明書Ｃ及び署名Ｓ（ｈ_r）を内部メモリに読み出す。

ステップ１１２２において、プロセッサはバージョン制御を実行する。移動端末は、新しいソフトウェアバージョンのソフトウェアバージョン番号をアップグレードパケットの一部として受信した。新しいソフトウェアイメージのソフトウェアバージョン番号は、外部メモリ（ＭＡＣにより保護される）に格納された現在のソフトウェアのバージョン番号に対してチェックされる。新しいソフトウェアバージョン番号が旧ソフトウェアバージョン番号より小さい場合、移動端末は更新処理を中止する。別の実施形態において、図８及び図９に関連して説明されたバージョン制御処理が実行される。

ステップ１１２２のバージョン制御が正常に行なわれた場合、ステップ１１２３に進む。ステップ１１２３において、プロセッサは、受信したデルタファイルΔ及び外部メモリ（ＭＡＣにより保護される）に格納された現在のソフトウェアバージョンＳＷ_prevから新しいソフトウェアＳＷ_newを生成する。

ステップ１１０３において、プロセッサは、新しいソフトウェアＳＷ_newの一方向監査ハッシュ値ｈ_a＝Ｈ（ＳＷ_new）を計算する。

ステップ１１０４において、プロセッサはメモリ１１０５からルート公開鍵ＰＫを読み出す。いくつかの実施形態において、ルート公開鍵はセキュリティ上安全に格納される。すなわち、ルート公開鍵の完全性が保護される。一実施形態において、上述のように、ルート公開鍵はプロセッサの内部ＲＯＭに格納される。プロセッサは、ルート公開鍵ＰＫを使用して新しいソフトウェアの署名Ｓ（ｈ_r）を検証する。１つの証明書のみが使用される場合、署名Ｓ（ｈ_r）は証明書Ｃの公開鍵に対して検証される。その結果、証明書Ｃは、ルート公開鍵ＰＫに対して検証される。いくつかの証明書が使用される場合、証明書のチェーン全体が検証される。この場合、チェーンの最後の証明書の署名がルート公開鍵に対して検証される。従ってステップ１１０４において、プロセッサは、新しいソフトウェアに署名するために使用される公開鍵を検証する。検証が正常に行なわれた場合、プロセッサはステップ１１０６に進み、署名を検証する。検証が正常に行なわれなかった場合、ソフトウェアロード処理は中止される。

ステップ１１０６において、プロセッサは、ステップ１１０４で検証された公開鍵を使用してソフトウェアのデジタル署名Ｓ（ｈ_r）を復号化し、参照ハッシュ値ｈ_rを結果として得る。

ステップ１１０７において、復号化された署名、すなわち参照ハッシュ値ｈ_rは、ステップ１１０３で計算された一方向監査ハッシュ値ｈ_aに対して検証される。検証が正常に行なわれた場合、すなわち監査ハッシュ値ｈ_aと参照ハッシュ値ｈ_rとが同等である場合、プロセッサはステップ１１０８に進み、参照メッセージ認証コード（ＭＡＣ）を計算する。値が同等でない場合、ソフトウェアロード処理は中止される。

ステップ１１０８において、プロセッサは、検証された一方向ハッシュ値ｈ_a及びチップ固有の鍵Ｋ（又はＫから得られる値）をＭＡＣ計算関数に対する入力値として使用し、参照メッセージ認証コード値ｔ_r＝ＭＡＣ（ｈ_a；Ｋ）を結果として得る。ＭＡＣ関数の出力値は、新しいソフトウェアの参照ＭＡＣ値である。いくつかの実施形態において、チップ固有の鍵Ｋは、例えばいわゆるe-fuse技術を使用して、製造工程中にチップに焼き付けられる。あるいは、鍵Ｋは、プロセッサのみがアクセス可能な別のセキュリティ上安全なメモリに格納される。メッセージ認証コードの実施形態については上述した。プロセッサは、新しいソフトウェアと共に新しい参照ＭＡＣ値ｔ_rを外部メモリ１０６に格納する。先のＭＡＣ値は削除される。オプションとして、証明書及びデジタル署名値は、外部メモリから除去される。新しいソフトウェアバージョンＳＷ_newは外部メモリに格納され、旧ソフトウェアバージョンは削除される。

上述のロード処理は、移動端末のプロセッサにより制御される。図３及び図４と関連して説明されたような２チップアーキテクチャにおいて、上記ステップはチップ３１１により実行され、チップ３１１はその後ソフトウェアを実行する。

上述において、多くの異なるシステムに対するソフトウェアを保護する強力なソフトウェア署名機構が説明された。その機構は、セキュリティ上安全にソフトウェアを格納する対称鍵に基づく完全性保護機構と効率的に組み合わされる。ＳＷがプラットフォームにインストールされると、対称鍵に基づく機構が使用され、先の演算から利点が得られる。更に、保護するための組合せ機構及びバージョン制御ソフトウェアが、本明細書において説明される。

不揮発性メモリが信頼できないＣＰＵに接続され、ＳＷ更新を必要とする場合、格納の際に提供された完全性保護は、２ＣＰＵアーキテクチャに関して特に有利である。

いくつかの実施形態を詳細に説明し示したが、本発明はそれらに限定されず、以下の請求の範囲に規定される趣旨の範囲内で他の方法により実現されてもよい。

特に、実施形態は、データ処理装置の一例として移動端末を参照して主に説明された。しかし、本明細書において説明された方法、製品手段及び装置は、他のデータ処理装置に適用されてもよいことが理解される。

本明細書において説明された方法、製品手段及び装置は、いくつかの別個の要素を含むハードウェア及び適切にプログラムされたマイクロプロセッサにより実現される。いくつかの手段を列挙する装置の請求項において、それら手段のいくつかは、適切にプログラムされたマイクロプロセッサ又は１つ以上のデジタル信号プロセッサ等のハードウェアの全く同一の項目により実現される。ある特定の手段が相互に異なる独立請求項において示されるか又は異なる実施形態において説明されるが、利点を得るために、それら手段の組合せが使用されないということを示すわけではない。

尚、用語「具備する」は、本明細書において使用される場合、記載される特徴、数字、ステップ又は構成要素の存在を特定するために使用されるが、１つ以上の他の特徴、数字、ステップ、構成要素又はそれらの集合の存在又は追加を除外するわけではない。

データを移動端末にロードするシステムを示す概略ブロック図である。 シングルチップアーキテクチャを有する移動端末の一例を示す概略ブロック図である。 ２チップアーキテクチャを有する移動端末の一例を示す概略ブロック図である。 ２チップアーキテクチャを有する移動端末の別の例を示す概略ブロック図である。 ソフトウェアを移動端末にロードするロード処理において使用されるメッセージ構成の一例を示す図である。 ソフトウェアバージョンの最初のロードに対するソフトウェアロード処理を示すフローチャートである。 メッセージ認証コードの一実施形態の計算を示す図である。 バージョン制御機構を含むメッセージ認証コードの別の実施形態の計算を示す図である。 バージョン制御処理を示すフローチャートである。 バージョン制御機構の一例を示す図である。 ソフトウェアのアップグレードに対するソフトウェアロード処理を示すフローチャートである。

Claims (20)

1. データ処理装置にデータをロードする方法であって、
   −前記データ処理装置がペイロード・データ項目を受信する工程と、
   −前記データ処理装置が前記ペイロード・データ項目の信頼性を保証するために暗号認証処理を実行する工程と、
   −前記データ処理装置が、認証し、受信した前記ペイロード・データ項目を前記データ処理装置に格納する工程と、
   −前記データ処理装置が、格納した前記ペイロード・データ項目の完全性を保護する工程と、
   を備え、
   前記暗号認証処理を実行する工程には、少なくとも前記受信したデータ項目の監査ハッシュ値を計算する工程が含まれ、
   前記完全性を保護する工程には、前記暗号認証処理において計算された少なくとも前記監査ハッシュ値の参照メッセージ認証コード値を計算する工程が更に含まれ、
   前記メッセージ認証コード値を計算する工程は、少なくとも前記ハッシュ値と前記データ処理装置に記憶された秘密鍵とからメッセージ認証コード値を計算するための回路を備えた計算モジュールにより実行され、前記計算モジュールは前記暗号認証処理の正常終了を示す前記暗号認証処理からの信号の受信に応じてのみ、計算されたメッセージ認証コード値を解放する、ことを特徴とする方法。
2. 前記暗号認証処理には、
   −参照ハッシュ値を受信する工程と、
   −前記受信したペイロード・データ項目の信頼性を検証するために、前記受信した参照ハッシュ値と前記計算した監査ハッシュ値とを比較する工程と、
   が含まれる請求項１記載の方法。
3. 前記暗号認証処理には、公開鍵暗号方式に基づいて前記データ項目にデジタル署名を行う工程が含まれる、請求項２記載の方法。
4. −前記データ処理装置が、前記ペイロード・データ項目と、第１の公開鍵を含みデジタル署名されたデジタル証明書データ項目と、前記第１の公開鍵に対応する第１の秘密鍵を用いて暗号化された参照ハッシュ値を含むデジタル署名データ項目と、を受信する工程と、
   −前記データ処理装置が、前記デジタル署名されたデジタル証明書データ項目を、前記データ処理装置に格納されたルート公開鍵に対して認証する工程と、
   −前記データ処理装置が、前記デジタル署名データ項目を前記認証されたデジタル証明書に対して認証する工程と、
   −前記データ処理装置が、前記受信したペイロード・データ項目の信頼性を検証するために、前記受信した参照ハッシュ値と前記計算した監査ハッシュ値とを比較する工程と、
   を備える請求項３記載の方法。
5. 前記データ処理装置が、前記参照ハッシュ値を暗号的に認証する工程を更に備え、
   前記参照メッセージ認証コード値を計算する工程は、前記参照ハッシュ値が正常に認証された場合にのみ実行される、請求項３又は４記載の方法。
6. 前記完全性を保護する工程には、前記計算した参照メッセージ認証コード値を、前記受信したペイロード・データ項目と関連づけて格納する工程が含まれる、請求項１から５のいずれか１項に記載の方法。
7. 前記参照メッセージ認証コード値を計算する工程には、少なくとも前記監査ハッシュ値及び乱数から得られる組合せデータ項目の前記参照メッセージ認証コード値を計算する工程が更に含まれる、請求項１から６のいずれか１項に記載の方法。
8. 前記参照メッセージ認証コード値を計算する工程には、少なくとも前記監査ハッシュ値及びバージョン制御データ項目から得られる組合せデータ項目の前記参照メッセージ認証コード値を計算する工程が更に含まれる、請求項１から７のいずれか１項に記載の方法。
9. 前記データ処理装置が、バージョン制御データレコードをバージョン制御データ構造に格納する工程を更に含み、
   前記バージョン制御データレコードには、少なくとも前記バージョン制御データ項目を含む前記受信したペイロード・データ項目に関する情報が含まれる、請求項８記載の方法。
10. 前記格納されたバージョン制御データレコードの完全性が保護される、請求項９記載の方法。
11. 前記バージョン制御データレコードはバージョンカウンタを備える、請求項９又は１０記載の方法。
12. 前記バージョン制御データレコードは、前記ペイロード・データ項目の現在のバージョンを置換してもよい先のバージョン数を識別するバックカウンタを更に備える、請求項１１記載の方法。
13. 前記秘密鍵は、前記データ処理装置に固有の秘密データ項目である、請求項１から１２のいずれか１項に記載の方法。
14. 前記秘密鍵は、前記データ処理装置のみが知る秘密データ項目である、請求項１から１３のいずれか１項に記載の方法。
15. 前記ペイロード・データ項目を受信する工程には、
    先に受信した現在のデータ項目のデルタ更新を受信する工程と、
    前記先に受信した現在のデータ項目と前記受信したデルタ更新とから、更新されたペイロード・データ項目として前記ペイロード・データ項目を生成する工程と、
    が含まれる請求項１から１４のいずれか１項に記載の方法。
16. 当該コンピュータプログラムがデータ処理装置上で実行された場合、請求項１から１５のいずれか１項に記載の方法のステップを前記データ処理装置に実行させるプログラムコード手段を備える、コンピュータプログラム。
17. −ペイロード・データ項目を受信する工程と、
    −前記ペイロード・データ項目の信頼性を保証するために暗号認証処理を実行する工程と、
    −前記データ処理装置において、認証し、受信した前記ペイロード・データ項目を格納する工程と、
    −格納した前記ペイロード・データ項目の完全性を保護する工程と、
    の各工程を実行する第１の処理回路を備えるデータ処理装置であって、
    前記暗号認証処理を実行する工程には、少なくとも前記受信したデータ項目の監査ハッシュ値を計算する工程が含まれ、
    前記完全性を保護する工程には、前記暗号認証処理において計算された少なくとも前記監査ハッシュ値の参照メッセージ認証コード値を計算する工程が更に含まれ、
    前記メッセージ認証コード値を計算する工程は、少なくとも前記ハッシュ値と前記データ処理装置に記憶された秘密鍵とからメッセージ認証コード値を計算するための回路を備えた計算モジュールにより実行され、前記計算モジュールは前記暗号認証処理の正常終了を示す前記暗号認証処理からの信号の受信に応じてのみ、計算されたメッセージ認証コード値を発行する、ことを特徴とするデータ処理装置。
18. 前記受信したペイロード・データ項目を格納する格納手段と、
    前記格納手段及び前記第１の処理回路に接続される第２の処理回路と、
    を更に備え、
    前記第２の処理回路は、少なくとも前記格納手段に対する読み出しアクセスを前記第１の処理回路に提供する
    請求項１７記載のデータ処理装置。
19. 前記第１の処理回路は、非対称暗号方式のルート公開鍵を格納するローカル格納手段を備える、請求項１７又は１８記載のデータ処理装置。
20. 前記第１の処理回路は、前記秘密鍵を格納するローカル格納手段を備える、請求項１７から１９のいずれか１項に記載のデータ処理装置。

Images