JP4912879B2 - プロセッサの保護された資源へのアクセスに対するセキュリティ保護方法 - Google Patents

Description

関連出願に関する言及
本出願は、２００２年７月３０日出願の米国仮出願第６０／３９９，５９２号、バラード他発明による“ファームウェアのランタイム認証”の同時継続の出願日の利点を主張するものである。

また、本出願は、工業所有権の保護に関するパリ条約の元に、２００２年１２月１０日に欧州特許庁に出願された、出願番号０２２９３０５７．２の優先権を主張するものである。１２月１０日以前の日付をもつ、本主題と同一の他国への出願はない。

連邦予算にもとずく研究あるいは開発に関する報告
なし。

本発明は、一般的に処理装置に関するものであり、特に、セキュア計算機システムに関するものである。

現在の計算機装置は、様々な形態と形状を有するものとなっている。従来の計算機装置としては、パーソナルコンピュータがある。さらに最近は、ＰＤＡ（個人用携帯情報端末）やスマートフォンなどの移動型計算機装置の出現により、計算機装置と通信装置との間の境界がはっきりしなくなってきている。さらに、計算機装置は、自動車の制御装置などのように、利用者に対して実質的に見えない方法で利用されるものとなっている。

計算機装置、あるいはプロセッサなどの計算機装置の部品の製造者は、以前であれば、これらの装置の動作に対してセキュリティを提供することが不可能であった。セキュリティに対して、よく知られた危険性の一つとしては、第三者による計算機装置に対する攻撃があげられる。攻撃者は、様々な手段を用いて、計算機装置のシステムファイル、アプリケーションファイル、あるいはデータを変更することが可能である。ある場合には、このような攻撃は、極めて迷惑なものであり、また、ある場合には、所有者に対して多大な出費を強いる恐れがある。

計算機システムを、権限のない状態で変更することは、必ずしも第三者によって行われるものとは限らない。計算機装置の意図された操作に対するいくつかの変更は、ユーザによって行われる場合がある。例えば、ユーザは、装置の意図された設定を変更するかもしれないし、時として、それは、装置の動作を改善するために、認められていないソフトウェアを用いて行われる場合もある。自動車の制御装置のファームウェアの変更などの場合には、このような変更は、極めて危険なものとなる可能性がある。

また、別の場合として、ユーザは、データやプログラムを、ある装置から別の装置に転送しようとする可能性もある。この場合、著作権保護の観点から不適切なものであったり、動作が不安定となる計算機プラットフォームにソフトウェアが移されてしまうこともありうる。

製造者は、システムファームウェア、ソフトウェアおよびデータの起源と完全性を証明することの必要性をますます認識している。ソフトウェア提供者の起源を証明するデジタル証明書などの仕掛けにより、ある程度の成功を収めてはいるが、これらの手段は、不完全なものであり、特に、巧妙な攻撃者やユーザによって、容易に回避されてしまうことがわかっている。

このように、セキュアな計算機プラットフォームへのニーズが高まってきている。

本発明では、計算機装置の資源へのアクセスは、計算機装置の既知のメモリ位置に暗号化されたアクセスコードを格納することによりセキュリティが確保される。計算機装置は、資源にアクセスするためのパスワードを受信し、暗号化されたパスワードを生成するために、そのパスワードは暗号化される。暗号化されたパスワードは、暗号化されたアクセスコードと照合され、暗号化されたアクセスコードと暗号化されたパスワードが一致した場合のみ、資源へのアクセスが許可される。

本発明は、従来技術に対して、特徴的な利点を有している。暗号化されたアクセスは、パスワードよりもかなり短く、これにより、アクセスコード情報を格納するために必要なメモリ容量をかなり削減することが可能となり、その一方で、アクセスを行うために必要なパスワードは、元の長さのままであるものではある。
本発明とその利点をより完全に理解できるように、添付図と併せて以下の記述を参照する。

以下、図１から１５を用いて本発明を説明する。なお、同一の符号は、全ての図で同じ部分を指すものである。

図１は、移動型計算機環境のファームウェア、アプリケーションソフトウェアおよびデータを保護するために用いられる様々な保護機構を示す基本ブロック図である。本発明の以下の説明は、携帯電話やＰＤＡなどの移動型計算機装置に関連して述べるものであるが、本発明は、他の計算機装置に対しても同様に適用可能である。

図１の移動型計算機装置１０の回路は、３つの主要ブロックに分けられている。すなわち、ベースバンド処理システム１２、不揮発性外部メモリシステム１４およびＲＦ（無線周波数）システム１６である。ベースバンド処理システムは、ＲＦ変調の前のデータ処理を担うものである。図１では、ベースバンド処理システム１２には、ＳＲＡＭ（静的ランダムアクセスメモリ）１０、ＲＯＭ（読み出し専用メモリ）２２およびヒューズメモリアレイ（ｅＦｕｓｅ）２４を含む内部メモリサブシステム１８が組み込まれている。一つあるいはそれ以上の数の、汎用プロセッサ、デジタル信号プロセッサおよびコプロセッサなどの処理装置２６が、内部メモリサブシステム１８に接続されている。入出力（Ｉ／Ｏ）回路２８は、プロセッサ２６および内部メモリサブシステム１８に接続されている。

ファームウェア３０、アプリケーションソフトウェア３２およびデータファイル３４が、外部不揮発性メモリシステム１４に格納されている。ファームウェア３０は、装置の販売に先立って、製造者によって装置に格納された基本システムコードである。ファームウェア３０は、機能の追加やエラー修正などのために製造者によって更新されるが、永久にプラットフォームに常駐するものである。多くの場合、製造者によって装置１０に搭載されたファームウェア３０のみが用いられ、ファームウェアは、製造者以外の者や、製造者の許可のもとに作業する者以外の者によっては、変更や置き換えがなされるものではないことは、特に重要なものとなっている。従って、ファームウェア３０に関しては、セキュリティが極めて重要な意味を持っている。さらに、許可されていないファームウェアは、実行されないことも重要である。また、セキュリティは、アプリケーションソフトウェア３２およびデータファイル３４に関しても、重要な意味を持っている。アプリケーションソフトウェア３２およびデータファイル３４に関して、これらのファイルの完全性を確保することは、しばしば重要なものとなる。例えば、これらのファイルが、他の“ウイルス”ソフトウェアにより、変更、削除あるいは置き換えがなされないように保証することが望ましい。また、アプリケーションソフトウェア３２および（音楽および映像ファイルなどの）データファイル３４の複写を防止し、これらの創作物の所有者の著作権を保護することが望ましい。

図１に示すように、二種類の保護機構を用いて、容易にアクセス可能となる外部メモリの内容を保護することが可能となる。ファームウェアについては、“製造者”証明３６は、ファームウェアを、特定の計算機装置１０に関連付ける（複数の製造者証明は、それぞれのファームウェアタスクに関連付けられる）。同様に、アプリケーションソフトウェア３２およびデータファイル３４は、それぞれの“プラットフォーム”証明３８によって、特定の計算機装置１０に関連付けられる。これらの証明は、以下で詳細に説明するように、ファームウェア、アプリケーションソフトウェアおよびデータの変更を防止し（および、オプションとして、これらの秘密保持を保護し）、さらに、ファームウェア、アプリケーションソフトウェアおよびデータが他の装置に複写されることを防止するために用いられる。

ここで説明するセキュリティ機能は、いくつかの暗号化技術を用いている。“対称鍵”（あるいは“秘密鍵”）による暗号化では、同一の秘密鍵を用いて、暗号化と暗号解読を行う。対称鍵による暗号化の例としては、ＤＥＳ（データ暗号化規格）がある。“非対称鍵”（あるいは“公開鍵”）による暗号化では、二つの鍵、秘密鍵と公開鍵が用いられる。鍵生成アルゴリズムにより、鍵のマッチドペアを生成し、（将来、送り手となる見込みのある者へ発行される）公開鍵を用いて情報を暗号化し、（受け手により秘密に保有される）秘密鍵を用いて暗号解読を行う。また、その反対に、秘密鍵を用いて情報を暗号化し、公開鍵を用いて暗号解読を行うことも可能である。公開鍵から秘密鍵を導出することは計算の上では可能なことではない。秘密鍵は、セキュリティが確保された経路によって送る必要がないため、非対称な暗号化システムを用いることにより、前もってセキュリティ上の取り決めを行っていない者であっても、情報交換が可能となる。（ＲＳＡセキュリティ社により開発された）ＲＳＡ暗号化技術は、公開鍵暗号化の一例である。

一方向ハッシュ関数は、可変長の入力をもち、“メッセージダイジェスト”あるいは“ハッシュ”として知られる固定長の出力を生成する。ハッシュ関数は、情報に何らかの変更が加えられた場合に、完全に異なる出力を生成することを保証する。通常、ハッシュアルゴリズムは、データの完全性を検証するために用いられる。ＳＨＡ−１（１６０ビットのハッシュ）およびＭＤ５（１２８ビットのハッシュ）は、一方向ハッシュ関数の一例である。

デジタル署名により、情報の受け手は、情報の起源の信憑性を検証し、また、情報が完全であることを検証することが可能となる。通常、情報の送り手は、その情報のハッシュを計算し、送り手の秘密鍵を用いてハッシュを暗号化することにより、メッセージに署名する。情報の受け手は、送り手の公開鍵により暗号解読し（すなわち、送られたハッシュを得て）、受信したメッセージのハッシュを計算し、これらの二つを比較することにより、メッセージの署名を検証する。従って、公開鍵によるデジタル署名は、認証とデータの完全性を提供するものとなる。また、デジタル署名は、非拒絶を提供するものであり、すなわち、送り手が情報の起源を否認することを不可能とするものである。ＤＳＡ（デジタル署名アルゴリズム）は、デジタル署名暗号化システムの一例である。

公開鍵暗号化システムの問題の一つとして、ユーザは、介入者攻撃に対する防護のため、正しい公開鍵を用いて暗号化あるいは暗号解読が行われていることを確かめるために、常に、注意しなければならないという点がある。（ここでは、攻撃者は、データストリーム中のパケットを途中で捕らえ、パケットを改変し、元の送り手が指定した本来の宛先に対してこれらのパケットを転送する。）デジタル証明は、公開鍵が、意図した所有者に正しく属しているかを確立する処理を簡単化するデジタル形式のパスポートあるいは保証書である。この簡単化された形式では、証明は、証明局などの、信頼されたものによりデジタル的に証明されたユーザの公開鍵である。また、証明は、バージョン番号、ユーザＩＤ番号、有効期限などの付加情報を含むことも可能である。

他のセキュリティ機能をサポートするため、所定のコードと鍵が、ベースバンド処理システム１２の内部に保持されている。悪意のある改ざんを防止するため、いくつかのシステムプログラムがＲＯＭ２２に搭載されている。これらのプログラムには、（図３で詳細に説明する）セキュア・ブート・ローダ、（図３で詳細に説明する）セキュア・リセット・ブート・ローダ、（図９で詳細に説明する）セキュア・ランタイム・プラットフォーム・データ・チェッカ、（図９で詳細に説明する）セキュア・ランタイム・チェッカ、（図１０および図１１で詳細に説明する）セキュア・ランタイム・ローダ、および、データ暗号化とハッシングをサポートするための様々な暗号ソフトウェアが含まれている。暗号化技術のいくつかあるいは全ては、専用の暗号プロセッサで実行される。

さらに、本実施例では、所定のシステムデータが、ｅＦｕｓｅアレイ２４（あるいは、ベースバンド処理システム１２に内臓された他の固定記憶装置）に保持されている。データがアレイに書き込まれた後は、データの上書きが不可能となるなど、特定のアレイ位置への書き込みが禁止される。

ＤＩＥ識別番号は、各々の個別機器に対応づけられた一意の番号である。本実施例では、この番号は、ＤＩＥ＿ＩＤ＿ＦＵＳＥとして、製造時にｅＦｕｓｅアレイ２４に格納される。この識別コードは、秘密であるとは考えられておらず、セキュリティのないソフトウェアによって読み取ることが可能である。

また、製造者の公開鍵も（ここで、“製造者”は、装置１０の製造者であり）、Ｈ＿Ｍａｎ＿Ｐｕｂ＿Ｋｅｙとして、ハッシングの後にｅＦｕｓｅアレイ２４に格納される。製造者の公開鍵は秘密ではないため、Ｈ＿Ｍａｎ＿Ｐｕｂ＿Ｋｅｙを格納する位置は、外部からのアクセス処理に対して保護される必要はないが、書き込みの後は、改変に対して保護する必要がある。Ｈ＿Ｍａｎ＿Ｐｕｂ＿Ｋｅｙの利用については、図４でより詳細に説明する。なお、製造者の公開鍵のハッシングはオプションであり、ハッシングは、鍵を格納するために必要なメモリ容量を削減するために、長いサイズの鍵を圧縮するために用いられる。

また、テストＩＤあるいは他のアクセスＩＤも、ハッシングの後にｅＦｕｓｅアレイ２４に格納される。ハッシュ処理されたテストＩＤ（Ｈ＿Ｔｅｓｔ＿ＩＤ）は、装置に対して、テストモードでは許可されていないアクセスを防止するために用いられる、これは、テストモードでは、いくつかの保護が解除されているためである。これに関しては、図１５を用いて詳細に説明する。

鍵暗号鍵（ＫＥＫ）は、装置の製造時に、ベースバンドプロセッサに内臓された乱数発生器により生成された秘密鍵である。ＫＥＫは、ｅＦｕｓｅアレイ２４に格納されており、変更が不可能であり、外部からもアクセスが不可能となっている。従って、特定の装置に対するＫＥＫは、製造者によってさえ決定することができない。ＫＥＫは、プラットフォーム証明３８に対する付加的な暗号鍵を動的に提供するために用いられ、これについては、図１０および図１１を用いて詳細に説明する。

図２は、製造者証明３６に関する一実施例を示す図である。なお、特定の装置に対する実際の製造者証明３６は、図２に示した実施例よりも多数あるいは少数のフィールドを含むものとなっている。図２に示した製造者証明３６のフィールドの要約を、表１に示す。

証明サイズ（ＣＥＲＴ＿ＳＩＺＥ）および証明種類（ＣＥＲＴ＿ＴＹＰＥ）のフィールドは、製造者証明３６のサイズと種類（すなわち、“製造者”）を示している。デバッグ要求（ＤＥＢＵＧ＿ＲＥＱ）が、装置上でのエミュレーションを可能とする、あるいは禁止するために、製造者によって設定されうる。下で述べるように、製造者のみがこのフィールドの値を設定できる。コードアドレス（ＣＯＤＥ＿ＡＤＤＲ）のフィールドは、外部メモリ１４中のコードの開始アドレスを示している。コードサイズ・フィールド（ＣＯＤＥ＿ＳＩＺＥ）は、ファームウェアの（バイト単位での）サイズを示している。コード開始アドレス（ＣＯＤＥ＿ＳＴＡＲＴ＿ＡＤＤＲ）は、実行時のファームウェアのエントリポイントを示している。

製造者証明３６は、さらに、製造者の公開鍵（ＭＡＮ＿ＰＵＢ＿ＫＥＹ）および、ソフトウェア発信者の公開鍵（ＯＲＩＧ＿ＰＵＢ＿ＫＥＹ）を含んでいる。ここでは、ファームウェアは、独自の署名を有する第三者により作成されたものと仮定している。ファームウェアが、製造者によって作成された場合には、製造者に対する第二の公開鍵がオプションとして用いられることができる。発信者の公開鍵に対する署名は、ＯＲＩＧ＿ＰＵＢ＿ＫＥＹをハッシングし、ハッシングされたＯＲＩＧ＿ＰＵＢ＿ＫＥＹを製造者の秘密鍵（ＭＡＮ＿ＰＲＩ＿ＫＥＹ）を用いて暗号化することにより作成される。

ソフトウェア署名は、ファームウェア３０のコードをハッシングし、ハッシングにより得られたハッシュコードを発信者の秘密鍵（ＯＲＩＧ＿ＰＲＩ＿ＫＥＹ）を用いて暗号化することにより作成される。ＯＲＩＧ＿ＰＲＩ＿ＫＥＹは、発信者に対してのみ秘密が保たれているため、ＳＷ＿ＳＩＧは、発信者から製造者に対して提供されなければならない。

特定の装置１０のＤＩＥ＿ＩＤが、製造者証明３６に付加される。このデータは、単一の装置に対してコードを組み合わせるものであり、このファームウェアが他の装置にコピーされるのを防ぐためのものである。

構成パラメータは、製造者証明３６のＣＯＮＦ＿ＰＡＲＡＭフィールドに設定される。図１３と図１４に示すように、このフィールドの情報は、装置１０で機能的に設定するのに用いられる。例えば、ＣＯＮＦ＿ＰＡＲＡＭフィールドのパラメータは、ＤＰＬＬ（デジタル・フェーズ・ロック・ループ）周波数、メモリアクセスの待ち状態、ＲＦ回路１６のフィルタおよびゲインの値、および（充電曲線などの）バッテリ管理パラメータを設定するために用いられる。

特定の装置に固有なデータは、ＰＬＡＴＦＯＲＭ＿ＤＡＴＡフィールドに格納される。例えば、ＩＭＥＩ番号は、このフィールドに格納される。この特徴は、図１２で詳細に説明する。

製造者証明署名（ＳＩＧ＿ＣＥＲＴ）は、製造者証明３６の任意のフィールドの改ざんを防止するものである。ＳＩＧ＿ＣＥＲＴは、製造者証明の他のフィールドをハッシングし、ハッシングされたコードをＭＡＮ＿ＰＲＩ＿ＫＥＹを用いて暗号化することにより作成される。

図３は、セキュア・ブート・ローダ５０とセキュア・ブート・チェッカ・プログラム５２での製造者証明３６の利用手順を示すフローチャートであり、このプログラムは、好ましくはＲＯＭ２２に格納され、プログラムが変更されることを防止している。セキュア・ブート・ローダは、ブートシステム・ファームウェアが、電源投入時にアップロード可能となっているかどうかを判定する。もし可能ならば、セキュア・ブート・ローダは、最初に、フラッシュ・プログラマーをロードする。フラッシュ・プログラマーは、システムブート・ファームウェアをロードするために用いられる。また、フラッシュ・プログラマーは、製造者証明３６を有していなければならず、セキュア・ブート・ローダは、フラッシュ・プログラマーの実行に先立ち、フラッシュ・プログラマーの製造者証明とフラッシュ・プログラマー・プログラムの信憑性と完全性を保証する責任を担っている。これらの後、フラッシュ・プログラマーは、システムブート・ファームウェアをアップロードする。

セキュア・リセット・ブート・チェッカ５２は、外部メモリ１４に格納されているシステムブート・ファームウェア（および他のファームウェア）の実行前に、それらの証明の信憑性と完全性をチェックする。セキュア・ブート・ローダ５０あるいはセキュア・リセット・ブート・チェッカ５２の実行時には、装置１０は、これらの実行が完了する前に、実行に対する割り込みやバイパスが発生しないように構成される。

ステップ５４では、セキュア・ブート・ローダ５０あるいはセキュア・リセット・ブート・チェッカ５２は、電源投入あるいはシステムリセットを待つ。ステップ５６では、電源投入あるいはシステムリセットの際に、セキュア・ブート・ローダ５０は、ＵＡＲＴ（汎用非同期受信送信機）など、インターフェースの物理的バス上の同期信号のための、所定のインターフェースをチェックする。一定のタイムアウトやウォッチドッグリセット（ステップ５８）の後でも、物理バス上での動作が検知されなかった場合には、ファームウェアのダウンロードは行われていないと考えられ、制御をセキュア・リセット・ブート・チェッカ５２に切り換える。

物理バス上でダウンロード動作が検知された場合には、フラッシュ・プログラマーの実行に先立ち、ステップ６０から７０によって、フラッシュ・プログラマーの製造者証明３６をチェックする。ステップ６０では、フラッシュ・プログラマーの製造者証明の中の、製造者公開鍵（ＭＡＮ＿ＰＵＢ＿ＫＥＹ）の認証を行う。ＭＡＮ＿ＰＵＢ＿ＫＥＹの認証処理を、図４に示す。

図４は、製造者証明３６に格納された製造者公開鍵の認証処理を示したフローチャートである。ステップ１００において、ファームウェア（本例では、フラッシュ・プログラマー）の製造者証明中のＭＡＮ＿ＰＵＢ＿ＫＥＹをハッシングして、ステップ１０２において、ハッシュされた結果が、ｅＦｕｓｅアレイ２４からのＨ＿ＭＡＮ＿ＰＵＢ＿ＫＥＹとを比較される。ステップ１０４において、両者が合致すると判断した場合には、認証処理は“合格”を返し、そうでない場合には、不合格を返す。

他の実施例としては、製造者公開鍵をハッシングした結果を、製造者証明３６に格納しておくものがある。この場合は、ハッシング処理のステップ１００が不要となる。また、ハッシングされた製造者公開鍵の予め定められた数の最下位ビットのみを、ｅＦｕｓｅアレイ２４に格納しておくものがある。この場合は、ステップ１０４において、対応するビットのみを比較する。

図３によれば、ステップ６２において、製造者公開鍵の認証結果が“不合格”である場合には、ステップ６４に進み、処理手順は中止され、フラッシュ・プログラマーのローディングは中止される。装置１０は、リセットされ、フラッシュ・プログラマーのダウンロードが再び試みられる。

ステップ６２において、製造者公開鍵の認証結果が“合格”である場合には、ステップ６６に進み、証明署名（ＳＩＧ＿ＣＥＲＴ）が認証される。

図５は、ＳＩＧ＿ＣＥＲＴの認証処理を示すフローチャートである。ステップ１１０において、製造者証明３６のＳＩＧ＿ＣＥＲＴフィールド以外のフィールドがハッシングされる。ステップ１１２において、製造者証明３６のＳＩＧ＿ＣＥＲＴフィールドを、ＭＡＮ＿ＰＵＢ＿ＫＥＹを用いて暗号解読する。なお、製造者証明の認証は、ＭＡＮ＿ＰＵＢ＿ＫＥＹの認証の後で行われ、これにより、ＳＩＧ＿ＣＥＲＴが製造者の秘密鍵を用いて元々暗号化されている場合には、ＳＩＧ＿ＣＥＲＴのみが正しく暗号解読されることになる。ステップ１１４において、ステップ１１０で得られた証明のハッシュ結果と、暗号解読されたＳＩＧ＿ＣＥＲＴとを比較する。ステップ１１６において、両者が合致すると判断した場合には、認証処理は“合格”であり、そうでない場合は不合格である。認証が不合格ということは、ファームウェアの製造者証明３６の一つあるいはそれ以上の数のフィールドが変更されたことを示している。

さらに、図３において、ステップ６８において、製造者の証明署名の認証結果が“不合格”である場合には、ステップ６４に進み、処理手順は中止され、フラッシュ・プログラマーのローディングは中止される。装置１０は、リセットされ、フラッシュ・プログラマーのダウンロードが再び試みられる。

製造者の証明署名の認証が合格した場合には、ステップ７０に進み、発信者の公開鍵とソフトウェア署名（ＳＷ＿ＳＩＧ）に関して、製造者証明の発信者公開鍵フィールド（ＯＲＩＧ＿ＰＵＢ＿ＫＥＹ）を認証し、実際のファームウェアコードとソフトウエア署名（ＳＷ−ＳＩＧ）を認証する。

図６は、ＯＲＩＧ＿ＰＵＢ＿ＫＥＹの認証処理を示すフローチャートである。ステップ１２０において、ＭＡＮ＿ＰＵＢ＿ＫＥＹを用いて、ＯＲＩＧ＿ＰＵＢ＿ＫＥＹ＿ＳＩＧを暗号解読する。ステップ１２２において、製造者証明３６のＯＲＩＧ＿ＰＵＢ＿ＫＥＹフィールドが、ハッシングされ、ステップ１２４において、暗号化された署名と比較される。判断ブロック１２６において、両者が合致すると判断した場合には、認証処理は合格である。そうでない場合は不合格であり、ＯＲＩＧ＿ＰＵＢ＿ＫＥＹあるいはＯＲＩＧ＿ＰＵＢ＿ＫＥＹ＿ＳＩＧのいずれかが変更されたことを示している。

図７は、製造者証明３６が関連付けられたファームウェアの認証処理を示すフローチャートである。ステップ１３０において、すでに認証済みのＯＲＩＧ＿ＰＵＢ＿ＫＥＹを用いて、製造者証明３６のＳＷ＿ＳＩＧフィールドを暗号解読する。次に、ステップ１３２において、ファームウェア３０をハッシングする。ブロック１３４において、ハッシュの結果を、暗号解読された署名と比較する。ステップ１３６において、両者が合致すると判定した場合には、認証結果は合格である。そうでない場合は不合格であり、ファームウェアが変更されたことを示している。

さらに、図３において、ステップ７２において、発信者の公開鍵あるいはファームウェア（本例では、フラッシュ・プログラマー）のいずれか一方の認証が不合格となった場合には、ステップ６４に進み、処理手順は中止され、フラッシュ・プログラマーのローディングは中止される。装置１０は、リセットされ、フラッシュ・プログラマーのダウンロードが再び試みられる。

全ての認証試験が合格となったら、ブロック７４において、フラッシュ・プログラマーが実行される。フラッシュ・プログラマーは、システムブート・ソフトウェアをロードし、ステップ７６において、強制リセットする。通常、フラッシュ・プログラマーは、リセットの前に、メモリ上から消去される。

セキュア・リセット・ブートチェッカ５２は、判定ブロック５８でのタイムアウト処理の後、動作する。これは、通常、（他のファームウェアがダウンロードされていなければ）フラッシュ・プログラマーの実行完了後、あるいは、電源投入もしくはリセット後にダウンロードする他のファームウェアがない場合に、動作するものとなっている。セキュア・リセット・ブートチェッカは、セキュア・ブート・ローダの動作に関して説明したように、フラッシュ・プログラマーの製造者証明とは対照的に、システムブート・ソフトウェアのフィールドを認証する。

ステップ７８において、システムブート・ソフトウェアに関する製造者証明３６の製造者公開鍵が、図４に示す認証処理を用いて認証される。ブロック８０で、認証処理が不合格と判定された場合には、ブロック６４に進み、処理手順は中止される。

判断ブロック８０で、製造者公開鍵の認証処理が合格と判断された場合には、ブロック８２に進み、システムブート・ファームウェア証明（ＣＥＲＴ＿ＳＩＧ）の認証を行う。ファームウェア証明の認証処理を図５に示す。ブロック８４において、認証処理が不合格と判定された場合には、ブロック６４に進み、処理手順は中止される。

判断ブロック８４において、ファームウェア証明の認証が、合格と判定された場合には、ブロック８６に進み、発信者の公開鍵（ＯＲＩＧ＿ＰＵＢ＿ＫＥＹ）の認証を行う。発信者の公開鍵の認証処理を図６に示す。ブロック８８において、認証処理が不合格と判定された場合には、ブロック６４に進み、処理手順は中止される。

判断ブロック８８において、発信者の公開鍵の認証が、合格と判定された場合には、ブロック９０に進み、システムブート・ファームウェアの認証を行う。ファームウェアの認証処理を図７に示す。ブロック９２において、認証処理が不合格と判定された場合には、ブロック６４に進み、処理手順は中止される。

判断ブロック９２において、ファームウェア証明の認証が、合格と判定された場合には、ブロック９４に進み、ＤＩＥ識別コードを検証する。図８は、ＤＩＥ識別コードを検証する手順を示すフローチャートである。ステップ１４０において、製造者証明３６のＤＩＥ＿ＩＤフィールドが“０”に設定されている場合には、“０”を戻す。そうでない場合には、ＤＩＥ＿ＩＤフィールドを、ｅＦｕｓｅアレイ２４に格納されているＤＩＥ＿ＩＤ＿ＦＵＳＥ値と比較する。この場合には、比較された二つのフィールドの一致、不一致を表す値が戻される。

さらに、図３において、ＤＩＥ＿ＩＤフィールドが“０”に設定されている場合には、ＤＩＥ ＩＤ有効状態が戻され、処理手順がブロック９６で継続される。

ＤＩＥ＿ＩＤフィールドが“０”に設定されておらず、製造者証明３６のダイＩＤがｅＦｕｓｅアレイ２４に格納されているＤＩＥ＿ＩＤ＿ＦＵＳＥ値と一致しないならば、所定の機能が無効となる。しかし、緊急呼び出し機能など、いくつかの機能は動作可能である。

セキュア・ブート・ローダとセキュア・リセット・ブート・チェッカは、製造の時点もしくは改造の際に、有効なファームウェアのみが装置１０にロードされていることを確認する。製造者の秘密鍵を用いた暗号化がなければ、システムファームウェアはロードできないため、ユーザあるいは第三者による、格納されたファームウェアの変更あるいは置き換えが防止される。

しかし、ファームウェアのインストールが保護されていたとしても、ファームウェアの実行中に、ファームウェアや特定のデータの変更されるのを防止するために、更に他の手段を講じることが必要である。このように付加されるセキュリティ機能によって、実行の特権を変更することにより、装置内に格納されたデータが外部に公開されたり、許可されていないファームウェアから装置１０が再利用されることを防止する。

装置１０の動作中は、システムファームウェアのローディング後に、セキュア・ランタイム・プラットフォーム・データ・チェッカとセキュア・ランタイム・チェッカが、システムソフトウェアが変更されていないことを確認し、システムソフトウェアの製造者証明３６のＰＬＡＴＦＯＲＭ＿ＤＡＴＡフィールドに設定が行われていることを確認する。

図９は、セキュア・ランタイム・プラットフォーム・データ・チェッカとセキュア・ランタイム・チェッカの動作を示したフローチャートである。セキュア・ランタイム・プラットフォーム・データ・チェッカ２００は、製造者証明３６のＰＬＡＴＦＯＲＭ＿ＤＡＴＡフィールドに格納された、装置１０の特定のデータの変更を防止するものである。セキュア・ランタイム・チェッカ２０２は、ファームウェアの変更あるいは交換を防止するものである。

ステップ２０４において、セキュア・サービスが起動される。本実施例では、セキュア・サービスの呼び出しは、プロセッサ２６の休止する時期が検出された際に行われ、チェッカ２００および２０２は、他のアプリケーションに対する介入を最小限に抑えるようにしている。また、セキュア・サービスは、オンチップのハードウェアタイマによっても起動が可能となっており、休止時期に関わらず、予め定められた時間内にセキュア・サービスの呼び出しが確実に行うことが可能である。この予め定められた時間は、製造者証明３６のＣＯＮＦＩＧ＿ＰＡＲＡＭフィールドに格納された構成パラメータに従って、ブート時に設定される。また、セキュア・サービスは、ソフトウェア・アプリケーションからの要求に応じても起動が可能となっている。一度、セキュア・サービス呼び出しが起動されると、全ての割り込み処理が禁止され、セキュア・ランタイム・プラットフォーム・データ・チェッカ２００とセキュア・ランタイム・チェッカ２０２を実行するプロセッサは、割り込みを受けず、また、チェッカの処理が完了するまでその実行が中断することはない。

セキュア・ランタイム・プラットフォーム・データ・チェッカについて、ステップ２０６において、図４に示した手順と同様に、製造者証明３６に格納された製造者の公開鍵（ＭＡＮ＿ＰＵＢ＿ＫＥＹ）が認証される。ＭＡＮ＿ＰＵＢ＿ＫＥＹの認証により、後に行われる認証ステップで、公開鍵と秘密鍵の組み合わせが偽値で置き換えられることを防止する。

ステップ２０８において、製造者の公開鍵の認証が不合格となった場合には、セキュア・ランタイム・プラットフォーム・データ・チェッカの処理は中止され、ステップ２１０で、装置はリセットされる。

ステップ２０８において、製造者の公開鍵の認証が合格となった場合には、ステップ２１２に進み、システムブート・ファームウェア証明の認証が行われる。システムブート・ファームウェア証明の認証は、図５に示した手順と同様に行われる。このステップにより、製造者証明３６中のデータ、特に、ＰＬＡＴＦＯＲＭ＿ＤＡＴＡフィールドに格納された値に変更が加えられていないことを確認する。

ステップ２１４において、システムブート・ファームウェア証明の認証が不合格となった場合には、セキュア・ランタイム・プラットフォーム・データ・チェッカ２００の処理は中止され、ステップ２１０で、装置はリセットされる。

製造者証明のＤＩＥ＿ＩＤが０に設定されていない場合は、ＤＩＥ＿ＩＤフィールドの値は、ｅＦｕｓｅアレイ２４に格納されたＤＩＥ＿ＩＤ＿ＦＵＳＥと比較される。両者が一致することが、製造者証明のプラットフォームに関したデータがプラットフォームに属することを保証することになる。製造者証明のＤＩＥ＿ＩＤが０に設定されている場合は、製造者証明３６中のＰＬＡＴＦＯＲＭ＿ＤＡＴＡフィールドと、プラットフォーム証明３８のＰＬＡＴＦＯＲＭ＿ＤＡＴＡフィールドの値が一致することが、製造者証明のプラットフォームに関したデータがプラットフォームに属することを保証することになる。

ステップ２１８において、プラットフォームデータの有効状態が、（もしあるとすれば）呼び出し側のソフトウェアに戻される。プラットフォームデータが、期待されるプラットフォームデータと一致しない場合には、装置のなんらかの機能が動作不可とされるが、緊急呼び出しなどのいくつかの機能は動作可能な状態が維持される。

ステップ２２０からステップ２４０は、セキュア・ランタイム・チェッカ２０２の動作を示したものである。これらのステップは、各ファームウェアのタスクで実行される。ステップ２２０では、テスト対象となるファームウェアの製造者証明３６に格納された製造者の公開鍵（ＭＡＮ＿ＰＵＢ＿ＫＥＹ）を、図４に示した方法と同様に、認証する。ＭＡＮ＿ＰＵＢ＿ＫＥＹを認証することにより、後に行われる認証ステップで、公開鍵と秘密鍵の組み合わせが偽値で置き換えられることを防止する。

ステップ２２２で、製造者の公開鍵認証が不合格であると判定された場合、もし、（ステップ２２４に進んで判定を行い）テスト対象のファームウェアがシステムブートファームウェアならば、セキュア・ランタイム・チェッカ２０２の処理は中止され、ステップ２１０で、装置はリセットされる。もし、テスト対象のファームウェアがシステムブートファームウェアでないならば、ステップ２２６で処理を終了する。

ステップ２２２において、製造者の公開鍵認証が合格と判断された場合には、ステップ２２８に進み、テスト対象のファームウェアのファームウェア証明（ＳＩＧ＿ＣＥＲＴ）が認証される。ファームウェア証明の認証は、図５で示した方法と同様に行われる。

ステップ２３０において、ファームウェア証明の認証が不合格と判断された場合には、（ステップ２２４に進んで判定を行ない）テスト対象のファームウェアがシステムブートファームウェアならば、セキュア・ランタイム・チェッカ２０２の処理は中止され、ステップ２１０で、装置はリセットされる。もし、テスト対象のファームウェアがシステムブートファームウェアでないならば、ステップ２２６で処理を終了する。

ステップ２３０において、ファームウェア証明の認証が合格と判断された場合には、ステップ２３２に進み、発信者の公開鍵（ＯＲＩＧ＿ＰＵＢ＿ＫＥＹ）の認証を行う。ファームウェアの製造者証明のＯＲＩＧ＿ＰＵＢ＿ＫＥＹの認証は、図６で示した方法と同様に行われる。

ステップ２３４において、発信者の公開鍵の認証が不合格と判定された場合には、（ステップ２２４に進んで判定を行ない）テスト対象のファームウェアがシステムブートファームウェアならば、セキュア・ランタイム・チェッカ２０２の処理は中止され、ステップ２１０で、装置はリセットされる。もし、テスト対象のファームウェアがシステムブートファームウェアでないならば、ステップ２２６で処理を終了する。

ステップ２３４において、発信者の公開鍵の認証が合格と判定された場合には、ステップ２３６に進み、ファームウェアの認証が行なわれる。ファームウェアの認証は、図７に示した方法と同様に行なわれる。

ステップ２３８において、ファームウェアの認証が不合格と判定された場合には、（ステップ２２４に進んで判定を行ない）テスト対象のファームウェアがシステムブートファームウェアならば、セキュア・ランタイム・チェッカ２０２の処理は中止され、ステップ２１０で、装置はリセットされる。もし、テスト対象のファームウェアがシステムブートファームウェアでないならば、ステップ２２６で処理を終了する。

全ての認証テストが合格となった場合には、ステップ２４０において、ＤＩＥ＿ＩＤの検証が行なわれる。ＤＩＥ＿ＩＤの検証は、図８に示した方法と同様に行われる。

ステップ２４２において、ＤＩＥ＿ＩＤの有効状態が、（もしあるとすれば）呼び出し側のソフトウェアに戻される。ＤＩＥ＿ＩＤフィールドが“０”に設定されておらず、製造者証明３６のＤＩＥ＿ＩＤの値が、ｅＦｕｓｅアレイ２４に格納されたＤＩＥ＿ＩＤ＿ＦＵＳＥの値と一致しない場合は、装置のなんらかの機能が動作不可とされるが、緊急呼び出しなどのいくつかの機能は動作可能な状態が維持される。

チェッカのタスク２００および２０２が完了した後、ファームウェアのテストが合格となった場合には、以前からの処理は、停止位置から再開され、割り込みが再度可能となる状態となる。

ファームウェアの動作中に、ファームウェアとプラットフォームのデータ認証を行なうことにより、ファームウェアの起動後にファームウェアの置き換え行為を検知し、それを防止することが可能となる。チェッカのタスク２００および２０２を実行する前後に、プロセッサの状態を管理することにより、システムを再度初期化することなく、これらのタスクの実行が可能とすることができる。

図１０は、プラットフォーム証明３８をアプリケーションファイル３２あるいはデータファイル３４に関連付けを示した図である。表２は、プラットフォーム証明の一実施例におけるフィールドを列挙したものである。

プラットフォーム証明３８は、ｅＦｕｓｅアレイ２４に格納されたＫＥＫを利用する。本実施例では、ＫＥＫは、製造時にオンチップで生成された乱数であり、ＫＥＫの値は、誰にも知られないようになっている。ｅＦｕｓｅアレイ２４に格納されたＫＥＫは、Ｉ／Ｏポートによっても、あるいはアプリケーションソフトウェアによってもアクセスできないようになっている。各チップのＫＥＫは、他のプログラムによって外部から決定されたり、検知されることができないように用いられることが望ましい。ＫＥＫはｅＦｕｓｅアレイ２４に格納されているため、ヒューズメモリの融解状態を物理的に検出することによりＫＥＫを求めることができるが、このような検出は、チップ自身を破壊することによってのみ可能となる。各チップは個別にＫＥＫを生成するため、一つのチップのＫＥＫが知られたからといって、他のチップのセキュリティを脅かすことにはならない。

ＫＥＫは、装置の動作中に、ランダムに生成される他のソフトウェア鍵を暗号化するために用いられる。図１０に示すように、（ハードウェアあるいはソフトウェアのいずれかの形態で実装することが可能な）乱数発生器２５０は、必要に応じ、ランダムソフトウェア鍵（ＳＷ＿ＫＥＹ）を生成する。このように、各アプリケーションには、異なるソフトウェア鍵を付与することが可能となる。ステップ２５２において、ＫＥＫを用いてＳＷ＿ＫＥＹは暗号化され、ＥＮＣ＿ＳＷ＿ＫＥＹとしてプラットフォーム証明３８に格納される。ＥＮＣ＿ＳＷ＿ＫＥＹは、ＫＥＫを用いてのみ暗号解読が可能であり、ＫＥＫは秘密であり、チップ内部に格納されているため、ＥＮＣ＿ＳＷ＿ＫＥＹは、ＫＥＫにアクセスするアプリケーションによってのみ暗号解読が可能である。従って、ＲＯＭ中のシステムソフトウェアのみが、ＫＥＫにアクセス可能となる。

プラットフォーム証明３８中の他のセキュリティ値は、ＳＷ＿ＫＥＹを用いて暗号化される。証明の一部ではないが、アプリケーションファイル３２あるいはデータファイル３４は、暗号化ステップ２５４および２５６に示した機密保持要求に応じて、オプションとして、ＳＷ＿ＫＥＹによって暗号化される。アプリケーションファイル３２あるいはデータファイル３４が暗号化されるか、されないかは、ソフトウェア署名（ＳＷ＿ＳＩＧ）あるいは署名証明（ＳＩＧ＿ＣＥＲＴ）にも影響を与える。ステップ２５８において、ソフトウェアファイル３２あるいはデータファイルは（暗号化はオプションとなるが）ハッシングされ、ステップ２６０において、ＳＷ＿ＫＥＹを用いて暗号化される。この値は、ＳＷ＿ＳＩＧとして格納される。ステップ２６２において、証明フィールドはハッシングされ、ステップ２６４において、ＳＷ＿ＫＥＹにより暗号化される。この値は、ＳＩＧ＿ＣＥＲＴとして格納される。

プラットフォーム証明は、アプリケーションあるいはデータファイルを、それがロードされる装置１０に関連付けを行なう。一度関連付けが行なわれると、プラットフォーム証明は無効となり、アプリケーションあるいはデータファイルは、他の装置へは移動することができなくなる。さらに、アプリケーションファイル３２あるいはデータファイル３４を、特定のプログラムに関連付けるために、ＡＰＰＬＩ＿ＩＤフィールドが用いられる。たとえオーディオあるいはビデオファイルが、様々なアプリケーションで再生可能な標準形式のものであったとしても、例えば、オーディオあるいはビデオファイルのみを、特定のメディア再生アプリケーションに関連付けるために、これが用いられる。

図１１は、アプリケーションあるいはデータファイルをアプリケーションで実行するために必要となるプラットフォーム証明に対して、アプリケーションあるいはデータファイルの関連付けを解除する処理を示すものである。ステップ２７０において、ｅＦｕｓｅアレイ２４に格納されたＫＥＫを用いて、プラットフォーム証明３８のＥＮＣ＿ＳＷ＿ＫＥＹから、ＳＷ＿ＫＥＹを求める。ＳＷ＿ＫＥＹを用いて、ステップ２７２において、プラットフォーム証明３８のＳＩＧ＿ＣＥＲＴフィールドを暗号解読し、ステップ２７４において、ＳＷ＿ＳＩＧフィールドを暗号解読する。

ステップ２７６において、プラットフォーム証明３８のＳＩＧ＿ＣＥＲＴ以外のフィールドをハッシングする。ステップ２７８において、ハッシングした結果を、暗号解読されたＳＷ＿ＣＥＲＴフィールドの値と比較する。同様に、ステップ２８０において、格納されたアプリケーションあるいはデータファイルをハッシングし、ステップ２８２において、ステップ２７４で暗号化されたＳＷ＿ＳＩＧと比較される。ステップ２７８での比較、あるいはステップ３００での比較のいずれかが不一致となった場合には、ステップ３０２において、システムエラーが発行される。そうでない場合には、ステップ３０４および３０６でオプションとしての暗号解読の後、アプリケーションが実行される（もしくは、データファイルがアプリケーションで利用される）。

プラットフォーム証明は、従来例に対して、大きな利点をもたらすものである。ソフトウェアあるいはデータファイルを、装置１０に関連付けることにより、元のソフトウェアモジュールが変更されたことを明らかにし、ソースプログラムがコピーされ、ほかのプラットフォームで実行されることを防止でき、クローンによる攻撃に対する効果的な保護を提供し、特に、重要なこととして、著作権管理と媒体の保護を可能とする。

本方式は、一方向ハッシングおよびバルク暗号化など、プラットフォーム署名と検証に対する強力な暗号化技術に基づいたものであるため、高レベルのセキュリティを提供するものとなる。本方式は、任意のコンピュータ・ハードウェア・プラットフォームに対して、容易に適用することが可能である。ＫＥＫと、関連付けの際にランダムに生成されたソフトウェア鍵とを用いることにより、外部メモリ中の暗号化鍵を外部に格納することが可能となる。無制限数の異なるソフトウェア鍵を、アプリケーションおよびデータファイルに用いることができる。さらに、署名の計算のために、対称性のあるバルク暗号化技術を用いることにより、非対称な暗号化技術に比べ、計算機の処理負荷を削減することが可能となる。

図１２は、セキュリティを保ちながら、外部メモリ中のＩＭＥＩ（国際携帯機器識別）番号を格納するための、製造者および、あるいはプラットフォーム証明の特別な利用方法を示したものである。ＩＭＥＩ番号は、ＵＭＴＳ（欧州の第３世代移動体通信システム）標準規格、第５版で規定され、電話のクローンと旧規格や不適合の利用者機器に対して、電話の製造者と運用者の両者を保護するためのものである。ＩＭＥＩ番号は、携帯電話のどこかに格納され、要求に応じて供用されるネットワークに送り出される必要がある。（ハードウェア、ソフトウェアあるいは物理的な）何らかの手段による改ざんに対して、ＩＭＥＩ番号を保護することは、モバイル機器に求められるセキュリティレベルを大いに向上させてきた。改ざんを防止するために、多くの製造者は、製造プロセスの最後に、個々の電話に一意となるＩＭＥＩ番号を、チップに格納してきた。しかし、改ざん防止となるようにチップ上に番号を格納することは、コストのかかるものである。

図１２に示すように、ＩＭＥＩは、各電話ごとにカストマイズされた製造者証明（特に、ＰＬＡＴＦＯＲＭ＿ＤＡＴＡフィールド）に記された外部メモリ、および、あるいは、プラットフォーム証明に関連付けられた外部メモリに格納されている。ベースバンド処理システム１２は、システムブート・ファームウェアの製造者証明３６、あるいは、プラットフォーム証明３８に関連付けられたメモリ位置のいずれかから、外部メモリ中のＩＭＥＩにアクセスする。

ＩＭＥＩ番号が、製造者証明３６のＰＬＡＴＦＯＲＭ＿ＤＡＴＡフィールドで変更された場合、その変更は、システムブート・ソフトウェアの実行に先立ち、セキュア・リセット・ブート・チェッカにより検出される。もし、システムブート・ソフトウェアがロードされた後で変更された場合には、ＩＭＥＩ番号の変更は、セキュア・ランタイム・プラットフォームデータ・チェッカにより検出される。

もし、ＩＭＥＩが、プラットフォーム証明に関連付けられた外部メモリに格納されている場合には、ＩＭＥＩ番号の変更は、無効なＳＷ＿ＳＩＧとして検出される。プラットフォーム証明を用いて、ＩＭＥＩは、外部メモリの任意の位置に格納することができる。

装置１０をプログラムすることにより、たとえ、ＩＭＥＩが無効な製造者証明３６あるいは無効なプラットフォーム証明３８をもたらした場合でも、緊急呼び出しが可能となる。

図１３は、装置１０の動作を制御するために、製造者証明３６のフィールドを用いる処理を示すブロック図である。図１３に示すように、製造者証明３６のＤＥＢＵＧ＿ＲＥＱフィールドを用いて、テストアクセスおよびエミュレーション回路３２０を制御する。製造者証明３６のＣＯＮＦ＿ＰＡＲＡＭフィールドのパラメータを用いて、ブロック３３２および３２４で示すように、ハードウェアあるいはソフトウェアを適切に構成することにより、装置１０の動作の様々な状態を制御することができる。

システムの動作中は、システムブート・ソフトウェアが、製造者証明中の構成パラメータにアクセスし、ハードウェアおよびソフトウェア資源を構成する。製造者証明３６中に構成パラメータを配置することにより、製造者は、柔軟なハードウェアおよび、あるいはソフトウェア構成を有する装置を設計し、安全にセキュリティを確保しながら適切に装置を構成することが可能となる。

セキュリティを確保しながら構成パラメータを製造者証明３６に格納する第一の利用には、装置１０に対して、管理された状況で構成を入力することを可能とすることがあげられるが、ここでは、構成によっては、装置１０が攻撃に対して無防備な状況にさらしてしまう場合がある。例えば、テストモードの間、装置１０は、通常は隠されたメモリ位置が、読み出しおよび、あるいは書き込みを許すような構成状態に置かれることもある。また、メモリ性能設定、バス速度、処理速度などのハードウェアパラメータが、システム動作を分析するために、テストモードの間に変更が可能とされることもある。

セキュリティを確保しながら構成パラメータを製造者証明３６に格納する第二の利用では、装置１０の性能を制御することがあげられる。計算機産業ではよく知られているように、装置を限界性能まで到達させようとして、装置のハードウェアおよび、あるいはソフトウェアのパラメータを、ユーザ自身が再構成する場合がある。例えば、多くのユーザにより、プロセッサが動作するシステムクロック速度あるいは複数のシステムクロックを変化させ、パソコンのプロセッサ速度の“オーバークロック”を行なう場合がある。さらに、メモリアクセスおよびスループットを向上させるために、メモリ設定を変更することもありうる。確かに、オーバークロックは、計算機装置の性能を向上させることが可能であるが、それにより、ハードウェアをその仕様温度を上回る温度で動作させることにより、ハードウェアの寿命を短くしてしまうこともある。さらに、計算機装置は、オーバークロック設定では、誤動作する可能性もある。このように、オーバークロック設定は、保証とサポートの観点からは、製造者にとってコストのかかる面をもっている。

製造者証明３６でパラメータを設定することにより、性能設定に対する変更の試みを防止することができる。これは、性能設定は、製造者証明３６で定義され、製造者の許可の元でのみ変更が可能となるためである。システムブート・ソフトウェアは、定義されたパラメータにリセットされた後、装置を構成する。証明で許可された設定を変更しようとする試みは、（リセット後の）セキュア・リセット・ブート・チェッカ５２あるいはセキュア・ランタイム・チェッカ２０２によって、検出される。システムファームウェアの外にあるソフトウェアにより、構成パラメータを変更しようとする試みは、セキュア・ランタイム・プラットフォーム・データ・チェッカ２００によって、検出される。

セキュリティを確保しながら構成パラメータを製造者証明３６に格納する第三の利用では、異なる性能および、あるいは異なる機能性に対する設定を有する単一の装置を提供することがあげられる。装置は、製造者証明３６に格納された構成設定に基づき販売され、その構成は、ユーザあるいは第三者によって変更できないようにしたものである。装置１０は、製造者により、容易にアップグレード可能である。

例えば、携帯型の計算機装置プラットフォームは、複数のプロセッサ速度で動作し、無線ネットワーク、オーディオおよびビデオ機能のような、異なるオプションの機能性を有するように設計することが可能となっている。装置は、ＰＣカードやメモリポートの拡張などの高価なハードウェアアップグレードではなく、後日、アップグレード可能となるように、所望の構成を持たせて販売される。

図１４は、図１３の変形であり、構成データは、プラットフォーム証明で保護されたデータファイル３４に格納されている。構成パラメータを格納したデータファイル３４を変更させようとする試みは、システムファームウェアによって検出される。セキュア・ランタイム・プラットフォーム・データ・チェッカ２００は、装置の動作中に、データファイルの内容をチェックするように、変更されている。

図１５は、テストモードなどのモードで装置１０にアクセスするための他の設計を示したものである。この設計では、アクセスコードのハッシュ（Ｈ＿Ｔｅｓｔ＿ＩＤ）を格納する。このコードは、ｅＦｕｓｅメモリ２４に格納されている。テストモードにアクセスするため、第三者は、アクセスコード（Ｉｎｐｕｔ＿Ｔｅｓｔ＿ＩＤ）を入力する必要がある。ブロック３３０において、Ｉｎｐｕｔ＿Ｔｅｓｔ＿ＩＤはハッシングされ、ブロック３３２において、Ｈ＿Ｔｅｓｔ＿ＩＤと比較される。ブロック３３０でハッシングされたアクセスコードが、格納されたハッシングされたアクセスコードと一致した場合には、このモードへのアクセスが可能となる。

システムの動作中は、Ｈ＿Ｔｅｓｔ＿ＩＤは、通常は、Ｉｎｐｕｔ＿Ｔｅｓｔ＿ＩＤに比べて極めて小さな長さを持つため、アクセスコードを格納するために必要な格納領域を削減することが可能となる。しかし、所望のモードに入るためには、第三者は、より大きな数を必要とする。複数の入力をハッシングして、Ｈ＿Ｔｅｓｔ＿ＩＤに一致させるものを得ることは可能ではあるが、ＳＨＡ−１あるいはＮＤ５などの現在のハッシングアルゴリズムを用いて、不当に入力されたアクセスコードが一致する結果を生み出すことは、統計的な観点からはありえないことである。

さらに、図１５の設計は、さらにセキュリティ上の利点をもたらすものとなっている。格納されたハッシング結果、Ｈ＿Ｔｅｓｔ＿ＩＤが知られてしまった場合でも、ハッシングすることによりＨ＿Ｔｅｓｔ＿ＩＤを得るような入力コードを決定することは、計算機処理の観点からは困難なものとなっている。

テストモードへのアクセスについて、ハッシングされたアクセスコードを用いることを説明したが、これは、上述したように、システムパラメータを変更するためのアクセスなど、任意の状況でセキュリティを確保することに適用することが可能である。

本発明の詳細な説明を、一例となる実施例に対して行なってきたが、これらの実施例の様々な変形や、他の実施例は、当業者であれば思いつくものである。本発明は、クレームの範囲内であれば、任意の変形や代わりの実施例を包含したものとなっている。

図１は、移動型計算機環境のファームウェア、アプリケーションソフトウェアおよびデータを保護するために用いられる様々な保護機構を示す基本ブロック図である。 図２は、図１に示した製造者証明のための一実施例を示す図である。 図３は、セキュア・ブート・ローダおよびセキュア・ブート・チェッカ・プログラムでの、製造者証明の利用を示すフローチャートである。 図４は、製造者証明に格納された製造者の公開鍵の認証処理を示すフローチャートである。 図５は、製造者証明の証明署名フィールドの認証処理を示すフローチャートである。 図６は、製造者証明の発信者の公開鍵フィールドの認証処理を示すフローチャートである。 図７は、製造者証明に関連付けられたファームウェアの認証処理を示すフローチャートである。 図８は、製造者証明のＤＩＥ識別コードの検証処理を示すフローチャートである。 図９は、セキュア・ランタイム・プラットフォーム・データ・チェッカとセキュア・ランタイム・チェッカの動作を示すフローチャートである。 図１０は、プラットフォーム証明による、アプリケーションファイルあるいはデータファイルの計算機プラットフォームへの関連付けを示す図である。 図１１は、アプリケーション内でアプリケーションの実行あるいはデータファイルの利用に必要な、アプリケーションあるいはデータファイルのプラットフォーム証明からの関連付けの解除を示す図である。 図１２は、セキュリティを確保してＩＭＥＩ（内部移動機器識別）番号を外部メモリに格納するための、製造者および、あるいはプラットフォーム証明の特定利用を示す図である。 図１３は、装置の動作を制御するために、製造者証明のフィールドを利用するブロック図である。 図１４は、プラットフォーム証明によって保護されたデータファイル中に構成データを格納した、図１３のブロック図の変更例を示す図である。 図１５は、装置１０へのアクセスのための他の設計例を示す図である。

Claims (13)

1. 計算機装置の資源へのアクセスのセキュリティを確保する方法であって、
   チップ上に発生されるランダム番号の値が誰にも知られぬように、計算機装置の製造の間に前記ランダム番号を発生するステップと、
   計算機装置内の永久メモリ内に前記ランダム番号を格納するステップと、
   暗号化されたアクセスコードを発生するために前記ランダム番号を用いるステップと、
   計算機装置内の不揮発性メモリ内に前記暗号化されたアクセスコードを格納するステップと、
   前記資源にアクセスするために、パスワードを計算機装置内に受取るステップと、
   暗号化されたパスワードを生成するために、前記パスワードを計算機装置内に暗号化するステップと、
   前記暗号化されたパスワードと前記暗号化されたアクセスコードとを計算機装置内で比較するステップと、
   前記暗号化されたアクセスコードが前記暗号化されたパスワードに一致した場合に、計算機装置内の前記資源へのアクセスを許可するステップと、
   を含む、方法。
2. 請求項１記載の方法において、暗号化されたアクセスコードは、外部から変更が不可能なメモリに格納される、方法。
3. 請求項１記載の方法において、アクセスを許可するステップは、前記暗号化されたアクセスコードが前記暗号化されたパスワードと一致した場合に、計算機装置内の性能設定へのアクセスを許可するステップを含む、方法。
4. 請求項３記載の方法において、前記性能設定が、メモリ性能設定、バス速度、処理速度の少なくとも１つを含む、方法。
5. ランダム番号の値が誰にも知られないように、計算機装置の製造の間にチップ上に発生される前記ランダム番号を格納する永久メモリと、
   前記永久メモリに結合される処理回路と、
   前記処理回路に結合され、前記ランダム番号を用いて発生された暗号化されたアクセスコードを格納するメモリと、
   前記処理回路に結合され、資源にアクセスするためのパスワードを受取る入力回路と、
   を含む計算機装置であって、
   処理回路は、
   暗号化されたパスワードを生成するために前記パスワードを暗号化し、
   前記暗号化されたパスワードと前記暗号化されたアクセスコードとを比較し、
   前記暗号化されたアクセスコードが前記暗号化されたパスワードと一致した場合に、前記資源へのアクセスを許可する、
   計算機装置。
6. 請求項５記載の計算機装置において、前記暗号化されたアクセスコードが、前記暗号化されたパスワードと一致した場合に、前記処理回路が、計算機装置内の性能設定へのアクセスを許可する、計算機装置。
7. 請求項６記載の計算機装置において、前記性能設定が、メモリ性能設定、バス速度、処理速度の少なくとも１つ含む、計算機装置。
8. 請求項１記載の方法において、前記メモリがメモリアレイを含み、前記メモリアレイにデータが書き込まれた後、前記データが上書きされないように、特定のメモリ位置への更なる書き込みが禁止される、方法。
9. 請求項８記載の方法において、前記メモリアレイの幾つかの部分は、外部からアクセス不能であり、修正不能である、方法。
10. 請求項８記載の方法において、前記メモリアレイに暗号化鍵が格納される、方法。
11. 請求項５記載の計算機装置において、前記メモリがメモリアレイを含み、前記メモリアレイにデータが書き込まれた後、前記データが上書きされないように、特定のメモリ位置への更なる書き込みが禁止される、計算機装置。
12. 請求項１１記載の計算機装置において、前記メモリアレイの幾つかの部分は、外部からアクセス不能であり、修正不能である、計算機装置。
13. 請求項１２記載の計算機装置において、前記メモリアレイに暗号化鍵が格納される、計算機装置。

Images