プロセッサの保護された資源へのアクセスに対するセキュリティ保護方法
計算機プラットフォーム(10)は、製造者証明(36)を用いて、システムファームウェア(30)を保護する。製造者証明は、システムファームウェア(30)を、特定の計算機プラットフォーム(10)に関連付ける。セキュア・ランタイム・プラットフォーム・データ・チェッカは(200)およびセキュア・ランタイム・チェッカ(202)は、計算機プラットフォーム(10)の動作中にシステムファームウェアをチェックし、製造者証明中のシステムファームウェア(30)あるいは情報が変更されていないことを確認する。パスワードを入力することにより、テスト構成へのアクセスなど、装置の所定の構成へのアクセスが可能となる。パスワードは、長さを短くするためにハッシング処理により暗号化され、計算機プラットフォーム上でハッシングされ格納されたアクセスコードと比較される。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願に関する言及
本出願は、2002年7月30日出願の米国仮出願第60/399,592号、バラード他発明による“ファームウェアのランタイム認証”の同時継続の出願日の利点を主張するものである。
【0002】
また、本出願は、工業所有権の保護に関するパリ条約の元に、2002年12月10日に欧州特許庁に出願された、出願番号02293057.2の優先権を主張するものである。12月10日以前の日付をもつ、本主題と同一の他国への出願はない。
【0003】
連邦予算にもとずく研究あるいは開発に関する報告
なし。
【0004】
本発明は、一般的に処理装置に関するものであり、特に、セキュア計算機システムに関するものである。
【背景技術】
【0005】
現在の計算機装置は、様々な形態と形状を有するものとなっている。従来の計算機装置としては、パーソナルコンピュータがある。さらに最近は、PDA(個人用携帯情報端末)やスマートフォンなどの移動型計算機装置の出現により、計算機装置と通信装置との間の境界がはっきりしなくなってきている。さらに、計算機装置は、自動車の制御装置などのように、利用者に対して実質的に見えない方法で利用されるものとなっている。
【発明の開示】
【発明が解決しようとする課題】
【0006】
計算機装置、あるいはプロセッサなどの計算機装置の部品の製造者は、以前であれば、これらの装置の動作に対してセキュリティを提供することが不可能であった。セキュリティに対して、よく知られた危険性の一つとしては、第三者による計算機装置に対する攻撃があげられる。攻撃者は、様々な手段を用いて、計算機装置のシステムファイル、アプリケーションファイル、あるいはデータを変更することが可能である。ある場合には、このような攻撃は、極めて迷惑なものであり、また、ある場合には、所有者に対して多大な出費を強いる恐れがある。
【0007】
計算機システムを、権限のない状態で変更することは、必ずしも第三者によって行われるものとは限らない。計算機装置の意図された操作に対するいくつかの変更は、ユーザによって行われる場合がある。例えば、ユーザは、装置の意図された設定を変更するかもしれないし、時として、それは、装置の動作を改善するために、認められていないソフトウェアを用いて行われる場合もある。自動車の制御装置のファームウェアの変更などの場合には、このような変更は、極めて危険なものとなる可能性がある。
【0008】
また、別の場合として、ユーザは、データやプログラムを、ある装置から別の装置に転送しようとする可能性もある。この場合、著作権保護の観点から不適切なものであったり、動作が不安定となる計算機プラットフォームにソフトウェアが移されてしまうこともありうる。
【0009】
製造者は、システムファームウェア、ソフトウェアおよびデータの起源と完全性を証明することの必要性をますます認識している。ソフトウェア提供者の起源を証明するデジタル証明書などの仕掛けにより、ある程度の成功を収めてはいるが、これらの手段は、不完全なものであり、特に、巧妙な攻撃者やユーザによって、容易に回避されてしまうことがわかっている。
【0010】
このように、セキュアな計算機プラットフォームへのニーズが高まってきている。
【課題を解決するための手段】
【0011】
本発明では、計算機装置の資源へのアクセスは、計算機装置の既知のメモリ位置に暗号化されたアクセスコードを格納することによりセキュリティが確保される。計算機装置は、資源にアクセスするためのパスワードを受信し、暗号化されたパスワードを生成するために、そのパスワードは暗号化される。暗号化されたパスワードは、暗号化されたアクセスコードと照合され、暗号化されたアクセスコードと暗号化されたパスワードが一致した場合のみ、資源へのアクセスが許可される。
【発明の効果】
【0012】
本発明は、従来技術に対して、特徴的な利点を有している。暗号化されたアクセスは、パスワードよりもかなり短く、これにより、アクセスコード情報を格納するために必要なメモリ容量をかなり削減することが可能となり、その一方で、アクセスを行うために必要なパスワードは、元の長さのままであるものではある。
本発明とその利点をより完全に理解できるように、添付図と併せて以下の記述を参照する。
【0013】
以下、図1から15を用いて本発明を説明する。なお、同一の符号は、全ての図で同じ部分を指すものである。
【実施例】
【0014】
図1は、移動型計算機環境のファームウェア、アプリケーションソフトウェアおよびデータを保護するために用いられる様々な保護機構を示す基本ブロック図である。本発明の以下の説明は、携帯電話やPDAなどの移動型計算機装置に関連して述べるものであるが、本発明は、他の計算機装置に対しても同様に適用可能である。
【0015】
図1の移動型計算機装置10の回路は、3つの主要ブロックに分けられている。すなわち、ベースバンド処理システム12、不揮発性外部メモリシステム14およびRF(無線周波数)システム16である。ベースバンド処理システムは、RF変調の前のデータ処理を担うものである。図1では、ベースバンド処理システム12には、SRAM(静的ランダムアクセスメモリ)10、ROM(読み出し専用メモリ)22およびヒューズメモリアレイ(eFuse)24を含む内部メモリサブシステム18が組み込まれている。一つあるいはそれ以上の数の、汎用プロセッサ、デジタル信号プロセッサおよびコプロセッサなどの処理装置26が、内部メモリサブシステム18に接続されている。入出力(I/O)回路28は、プロセッサ26および内部メモリサブシステム18に接続されている。
【0016】
ファームウェア30、アプリケーションソフトウェア32およびデータファイル34が、外部不揮発性メモリシステム14に格納されている。ファームウェア30は、装置の販売に先立って、製造者によって装置に格納された基本システムコードである。ファームウェア30は、機能の追加やエラー修正などのために製造者によって更新されるが、永久にプラットフォームに常駐するものである。多くの場合、製造者によって装置10に搭載されたファームウェア30のみが用いられ、ファームウェアは、製造者以外の者や、製造者の許可のもとに作業する者以外の者によっては、変更や置き換えがなされるものではないことは、特に重要なものとなっている。従って、ファームウェア30に関しては、セキュリティが極めて重要な意味を持っている。さらに、許可されていないファームウェアは、実行されないことも重要である。また、セキュリティは、アプリケーションソフトウェア32およびデータファイル34に関しても、重要な意味を持っている。アプリケーションソフトウェア32およびデータファイル34に関して、これらのファイルの完全性を確保することは、しばしば重要なものとなる。例えば、これらのファイルが、他の“ウイルス”ソフトウェアにより、変更、削除あるいは置き換えがなされないように保証することが望ましい。また、アプリケーションソフトウェア32および(音楽および映像ファイルなどの)データファイル34の複写を防止し、これらの創作物の所有者の著作権を保護することが望ましい。
【0017】
図1に示すように、二種類の保護機構を用いて、容易にアクセス可能となる外部メモリの内容を保護することが可能となる。ファームウェアについては、“製造者”証明36は、ファームウェアを、特定の計算機装置10に関連付ける(複数の製造者証明は、それぞれのファームウェアタスクに関連付けられる)。同様に、アプリケーションソフトウェア32およびデータファイル34は、それぞれの“プラットフォーム”証明38によって、特定の計算機装置10に関連付けられる。これらの証明は、以下で詳細に説明するように、ファームウェア、アプリケーションソフトウェアおよびデータの変更を防止し(および、オプションとして、これらの秘密保持を保護し)、さらに、ファームウェア、アプリケーションソフトウェアおよびデータが他の装置に複写されることを防止するために用いられる。
【0018】
ここで説明するセキュリティ機能は、いくつかの暗号化技術を用いている。“対称鍵”(あるいは“秘密鍵”)による暗号化では、同一の秘密鍵を用いて、暗号化と暗号解読を行う。対称鍵による暗号化の例としては、DES(データ暗号化規格)がある。“非対称鍵”(あるいは“公開鍵”)による暗号化では、二つの鍵、秘密鍵と公開鍵が用いられる。鍵生成アルゴリズムにより、鍵のマッチドペアを生成し、(将来、送り手となる見込みのある者へ発行される)公開鍵を用いて情報を暗号化し、(受け手により秘密に保有される)秘密鍵を用いて暗号解読を行う。また、その反対に、秘密鍵を用いて情報を暗号化し、公開鍵を用いて暗号解読を行うことも可能である。公開鍵から秘密鍵を導出することは計算の上では可能なことではない。秘密鍵は、セキュリティが確保された経路によって送る必要がないため、非対称な暗号化システムを用いることにより、前もってセキュリティ上の取り決めを行っていない者であっても、情報交換が可能となる。(RSAセキュリティ社により開発された)RSA暗号化技術は、公開鍵暗号化の一例である。
【0019】
一方向ハッシュ関数は、可変長の入力をもち、“メッセージダイジェスト”あるいは“ハッシュ”として知られる固定長の出力を生成する。ハッシュ関数は、情報に何らかの変更が加えられた場合に、完全に異なる出力を生成することを保証する。通常、ハッシュアルゴリズムは、データの完全性を検証するために用いられる。SHA−1(160ビットのハッシュ)およびMD5(128ビットのハッシュ)は、一方向ハッシュ関数の一例である。
【0020】
デジタル署名により、情報の受け手は、情報の起源の信憑性を検証し、また、情報が完全であることを検証することが可能となる。通常、情報の送り手は、その情報のハッシュを計算し、送り手の秘密鍵を用いてハッシュを暗号化することにより、メッセージに署名する。情報の受け手は、送り手の公開鍵により暗号解読し(すなわち、送られたハッシュを得て)、受信したメッセージのハッシュを計算し、これらの二つを比較することにより、メッセージの署名を検証する。従って、公開鍵によるデジタル署名は、認証とデータの完全性を提供するものとなる。また、デジタル署名は、非拒絶を提供するものであり、すなわち、送り手が情報の起源を否認することを不可能とするものである。DSA(デジタル署名アルゴリズム)は、デジタル署名暗号化システムの一例である。
【0021】
公開鍵暗号化システムの問題の一つとして、ユーザは、介入者攻撃に対する防護のため、正しい公開鍵を用いて暗号化あるいは暗号解読が行われていることを確かめるために、常に、注意しなければならないという点がある。(ここでは、攻撃者は、データストリーム中のパケットを途中で捕らえ、パケットを改変し、元の送り手が指定した本来の宛先に対してこれらのパケットを転送する。)デジタル証明は、公開鍵が、意図した所有者に正しく属しているかを確立する処理を簡単化するデジタル形式のパスポートあるいは保証書である。この簡単化された形式では、証明は、証明局などの、信頼されたものによりデジタル的に証明されたユーザの公開鍵である。また、証明は、バージョン番号、ユーザID番号、有効期限などの付加情報を含むことも可能である。
【0022】
他のセキュリティ機能をサポートするため、所定のコードと鍵が、ベースバンド処理システム12の内部に保持されている。悪意のある改ざんを防止するため、いくつかのシステムプログラムがROM22に搭載されている。これらのプログラムには、(図3で詳細に説明する)セキュア・ブート・ローダ、(図3で詳細に説明する)セキュア・リセット・ブート・ローダ、(図9で詳細に説明する)セキュア・ランタイム・プラットフォーム・データ・チェッカ、(図9で詳細に説明する)セキュア・ランタイム・チェッカ、(図10および図11で詳細に説明する)セキュア・ランタイム・ローダ、および、データ暗号化とハッシングをサポートするための様々な暗号ソフトウェアが含まれている。暗号化技術のいくつかあるいは全ては、専用の暗号プロセッサで実行される。
【0023】
さらに、本実施例では、所定のシステムデータが、eFuseアレイ24(あるいは、ベースバンド処理システム12に内臓された他の固定記憶装置)に保持されている。データがアレイに書き込まれた後は、データの上書きが不可能となるなど、特定のアレイ位置への書き込みが禁止される。
【0024】
DIE識別番号は、各々の個別機器に対応づけられた一意の番号である。本実施例では、この番号は、DIE_ID_FUSEとして、製造時にeFuseアレイ24に格納される。この識別コードは、秘密であるとは考えられておらず、セキュリティのないソフトウェアによって読み取ることが可能である。
【0025】
また、製造者の公開鍵も(ここで、“製造者”は、装置10の製造者であり)、H_Man_Pub_Keyとして、ハッシングの後にeFuseアレイ24に格納される。製造者の公開鍵は秘密ではないため、H_Man_Pub_Keyを格納する位置は、外部からのアクセス処理に対して保護される必要はないが、書き込みの後は、改変に対して保護する必要がある。H_Man_Pub_Keyの利用については、図4でより詳細に説明する。なお、製造者の公開鍵のハッシングはオプションであり、ハッシングは、鍵を格納するために必要なメモリ容量を削減するために、長いサイズの鍵を圧縮するために用いられる。
【0026】
また、テストIDあるいは他のアクセスIDも、ハッシングの後にeFuseアレイ24に格納される。ハッシュ処理されたテストID(H_Test_ID)は、装置に対して、テストモードでは許可されていないアクセスを防止するために用いられる、これは、テストモードでは、いくつかの保護が解除されているためである。これに関しては、図15を用いて詳細に説明する。
【0027】
鍵暗号鍵(KEK)は、装置の製造時に、ベースバンドプロセッサに内臓された乱数発生器により生成された秘密鍵である。KEKは、eFuseアレイ24に格納されており、変更が不可能であり、外部からもアクセスが不可能となっている。従って、特定の装置に対するKEKは、製造者によってさえ決定することができない。KEKは、プラットフォーム証明38に対する付加的な暗号鍵を動的に提供するために用いられ、これについては、図10および図11を用いて詳細に説明する。
【0028】
図2は、製造者証明36に関する一実施例を示す図である。なお、特定の装置に対する実際の製造者証明36は、図2に示した実施例よりも多数あるいは少数のフィールドを含むものとなっている。図2に示した製造者証明36のフィールドの要約を、表1に示す。
【表1】
【0029】
証明サイズ(CERT_SIZE)および証明種類(CERT_TYPE)のフィールドは、製造者証明36のサイズと種類(すなわち、“製造者”)を示している。デバッグ要求(DEBUG_REQ)が、装置上でのエミュレーションを可能とする、あるいは禁止するために、製造者によって設定されうる。下で述べるように、製造者のみがこのフィールドの値を設定できる。コードアドレス(CODE_ADDR)のフィールドは、外部メモリ14中のコードの開始アドレスを示している。コードサイズ・フィールド(CODE_SIZE)は、ファームウェアの(バイト単位での)サイズを示している。コード開始アドレス(CODE_START_ADDR)は、実行時のファームウェアのエントリポイントを示している。
【0030】
製造者証明36は、さらに、製造者の公開鍵(MAN_PUB_KEY)および、ソフトウェア発信者の公開鍵(ORIG_PUB_KEY)を含んでいる。ここでは、ファームウェアは、独自の署名を有する第三者により作成されたものと仮定している。ファームウェアが、製造者によって作成された場合には、製造者に対する第二の公開鍵がオプションとして用いられることができる。発信者の公開鍵に対する署名は、ORIG_PUB_KEYをハッシングし、ハッシングされたORIG_PUB_KEYを製造者の秘密鍵(MAN_PRI_KEY)を用いて暗号化することにより作成される。
【0031】
ソフトウェア署名は、ファームウェア30のコードをハッシングし、ハッシングにより得られたハッシュコードを発信者の秘密鍵(ORIG_PRI_KEY)を用いて暗号化することにより作成される。ORIG_PRI_KEYは、発信者に対してのみ秘密が保たれているため、SW_SIGは、発信者から製造者に対して提供されなければならない。
【0032】
特定の装置10のDIE_IDが、製造者証明36に付加される。このデータは、単一の装置に対してコードを組み合わせるものであり、このファームウェアが他の装置にコピーされるのを防ぐためのものである。
【0033】
構成パラメータは、製造者証明36のCONF_PARAMフィールドに設定される。図13と図14に示すように、このフィールドの情報は、装置10で機能的に設定するのに用いられる。例えば、CONF_PARAMフィールドのパラメータは、DPLL(デジタル・フェーズ・ロック・ループ)周波数、メモリアクセスの待ち状態、RF回路16のフィルタおよびゲインの値、および(充電曲線などの)バッテリ管理パラメータを設定するために用いられる。
【0034】
特定の装置に固有なデータは、PLATFORM_DATAフィールドに格納される。例えば、IMEI番号は、このフィールドに格納される。この特徴は、図12で詳細に説明する。
【0035】
製造者証明署名(SIG_CERT)は、製造者証明36の任意のフィールドの改ざんを防止するものである。SIG_CERTは、製造者証明の他のフィールドをハッシングし、ハッシングされたコードをMAN_PRI_KEYを用いて暗号化することにより作成される。
【0036】
図3は、セキュア・ブート・ローダ50とセキュア・ブート・チェッカ・プログラム52での製造者証明36の利用手順を示すフローチャートであり、このプログラムは、好ましくはROM22に格納され、プログラムが変更されることを防止している。セキュア・ブート・ローダは、ブートシステム・ファームウェアが、電源投入時にアップロード可能となっているかどうかを判定する。もし可能ならば、セキュア・ブート・ローダは、最初に、フラッシュ・プログラマーをロードする。フラッシュ・プログラマーは、システムブート・ファームウェアをロードするために用いられる。また、フラッシュ・プログラマーは、製造者証明36を有していなければならず、セキュア・ブート・ローダは、フラッシュ・プログラマーの実行に先立ち、フラッシュ・プログラマーの製造者証明とフラッシュ・プログラマー・プログラムの信憑性と完全性を保証する責任を担っている。これらの後、フラッシュ・プログラマーは、システムブート・ファームウェアをアップロードする。
【0037】
セキュア・リセット・ブート・チェッカ52は、外部メモリ14に格納されているシステムブート・ファームウェア(および他のファームウェア)の実行前に、それらの証明の信憑性と完全性をチェックする。セキュア・ブート・ローダ50あるいはセキュア・リセット・ブート・チェッカ52の実行時には、装置10は、これらの実行が完了する前に、実行に対する割り込みやバイパスが発生しないように構成される。
【0038】
ステップ54では、セキュア・ブート・ローダ50あるいはセキュア・リセット・ブート・チェッカ52は、電源投入あるいはシステムリセットを待つ。ステップ56では、電源投入あるいはシステムリセットの際に、セキュア・ブート・ローダ50は、UART(汎用非同期受信送信機)など、インターフェースの物理的バス上の同期信号のための、所定のインターフェースをチェックする。一定のタイムアウトやウォッチドッグリセット(ステップ58)の後でも、物理バス上での動作が検知されなかった場合には、ファームウェアのダウンロードは行われていないと考えられ、制御をセキュア・リセット・ブート・チェッカ52に切り換える。
【0039】
物理バス上でダウンロード動作が検知された場合には、フラッシュ・プログラマーの実行に先立ち、ステップ60から70によって、フラッシュ・プログラマーの製造者証明36をチェックする。ステップ60では、フラッシュ・プログラマーの製造者証明の中の、製造者公開鍵(MAN_PUB_KEY)の認証を行う。MAN_PUB_KEYの認証処理を、図4に示す。
【0040】
図4は、製造者証明36に格納された製造者公開鍵の認証処理を示したフローチャートである。ステップ100において、ファームウェア(本例では、フラッシュ・プログラマー)の製造者証明中のMAN_PUB_KEYをハッシングして、ステップ102において、ハッシュされた結果が、eFuseアレイ24からのH_MAN_PUB_KEYとを比較される。ステップ104において、両者が合致すると判断した場合には、認証処理は“合格”を返し、そうでない場合には、不合格を返す。
【0041】
他の実施例としては、製造者公開鍵をハッシングした結果を、製造者証明36に格納しておくものがある。この場合は、ハッシング処理のステップ100が不要となる。また、ハッシングされた製造者公開鍵の予め定められた数の最下位ビットのみを、eFuseアレイ14に格納しておくものがある。この場合は、ステップ104において、対応するビットのみを比較する。
【0042】
図3によれば、ステップ62において、製造者公開鍵の認証結果が“不合格”である場合には、ステップ64に進み、処理手順は中止され、フラッシュ・プログラマーのローディングは中止される。装置10は、リセットされ、フラッシュ・プログラマーのダウンロードが再び試みられる。
【0043】
ステップ62において、製造者公開鍵の認証結果が“合格”である場合には、ステップ66に進み、証明署名(SIG_CERT)が認証される。
【0044】
図5は、SIG_CERTの認証処理を示すフローチャートである。ステップ110において、製造者証明36のSIG_CERTフィールド以外のフィールドがハッシングされる。ステップ112において、製造者証明36のSIG_CERTフィールドを、MAN_PUB_KEYを用いて暗号解読する。なお、製造者証明の認証は、MAN_PUB_KEYの認証の後で行われ、これにより、SIG_CERTが製造者の秘密鍵を用いて元々暗号化されている場合には、SIG_CERTのみが正しく暗号解読されることになる。ステップ114において、ステップ110で得られた証明のハッシュ結果と、暗号解読されたSIG_CERTとを比較する。ステップ116において、両者が合致すると判断した場合には、認証処理は“合格”であり、そうでない場合は不合格である。認証が不合格ということは、ファームウェアの製造者証明36の一つあるいはそれ以上の数のフィールドが変更されたことを示している。
【0045】
さらに、図3において、ステップ68において、製造者の証明署名の認証結果が“不合格”である場合には、ステップ64に進み、処理手順は中止され、フラッシュ・プログラマーのローディングは中止される。装置10は、リセットされ、フラッシュ・プログラマーのダウンロードが再び試みられる。
【0046】
製造者の証明署名の認証が合格した場合には、ステップ70に進み、発信者の公開鍵とソフトウェア署名(SW_SIG)に関して、製造者証明の発信者公開鍵フィールド(ORIG_PUB_KEY)を認証し、実際のファームウェアコードとソフトウエア署名(SW−SIG)を認証する。
【0047】
図6は、ORIG_PUB_KEYの認証処理を示すフローチャートである。ステップ120において、MAN_PUB_KEYを用いて、ORIG_PUB_KEY_SIGを暗号解読する。ステップ122において、製造者証明36のORIG_PUB_KEYフィールドが、ハッシングされ、ステップ124において、暗号化された署名と比較される。判断ブロック126において、両者が合致すると判断した場合には、認証処理は合格である。そうでない場合は不合格であり、ORIG_PUB_KEYあるいはORIG_PUB_KEY_SIGのいずれかが変更されたことを示している。
【0048】
図7は、製造者証明36が関連付けられたファームウェアの認証処理を示すフローチャートである。ステップ130において、すでに認証済みのORIG_PUB_KEYを用いて、製造者証明36のSW_SIGフィールドを暗号解読する。次に、ステップ132において、ファームウェア30をハッシングする。ブロック134において、ハッシュの結果を、暗号解読された署名と比較する。ステップ136において、両者が合致すると判定した場合には、認証結果は合格である。そうでない場合は不合格であり、ファームウェアが変更されたことを示している。
【0049】
さらに、図3において、ステップ72において、発信者の公開鍵あるいはファームウェア(本例では、フラッシュ・プログラマー)のいずれか一方の認証が不合格となった場合には、ステップ64に進み、処理手順は中止され、フラッシュ・プログラマーのローディングは中止される。装置10は、リセットされ、フラッシュ・プログラマーのダウンロードが再び試みられる。
【0050】
全ての認証試験が合格となったら、ブロック74において、フラッシュ・プログラマーが実行される。フラッシュ・プログラマーは、システムブート・ソフトウェアをロードし、ステップ76において、強制リセットする。通常、フラッシュ・プログラマーは、リセットの前に、メモリ上から消去される。
【0051】
セキュア・リセット・ブートチェッカ52は、判定ブロック58でのタイムアウト処理の後、動作する。これは、通常、(他のファームウェアがダウンロードされていなければ)フラッシュ・プログラマーの実行完了後、あるいは、電源投入もしくはリセット後にダウンロードする他のファームウェアがない場合に、動作するものとなっている。セキュア・リセット・ブートチェッカは、セキュア・ブート・ローダの動作に関して説明したように、フラッシュ・プログラマーの製造者証明とは対照的に、システムブート・ソフトウェアのフィールドを認証する。
【0052】
ステップ78において、システムブート。ソフトウェアに関する製造者証明36の製造者公開鍵が、図4に示す認証処理を用いて認証される。ブロック80で、認証処理が不合格と判定された場合には、ブロック64に進み、処理手順は中止される。
【0053】
判断ブロック80で、製造者公開鍵の認証処理が合格と判断された場合には、ブロック82に進み、システムブート・ファームウェア証明(CERT_SIG)の認証を行う。ファームウェア証明の認証処理を図5に示す。ブロック84において、認証処理が不合格と判定された場合には、ブロック64に進み、処理手順は中止される。
【0054】
判断ブロック84において、ファームウェア証明の認証が、合格と判定された場合には、ブロック86に進み、発信者の公開鍵(ORIG_PUB_KEY)の認証を行う。発信者の公開鍵の認証処理を図6に示す。ブロック88において、認証処理が不合格と判定された場合には、ブロック64に進み、処理手順は中止される。
【0055】
判断ブロック88において、発信者の公開鍵の認証が、合格と判定された場合には、ブロック90に進み、システムブート・ファームウェアの認証を行う。ファームウェアの認証処理を図7に示す。ブロック92において、認証処理が不合格と判定された場合には、ブロック64に進み、処理手順は中止される。
【0056】
判断ブロック92において、ファームウェア証明の認証が、合格と判定された場合には、ブロック94に進み、DIE識別コードを検証する。図8は、DIE識別コードを検証する手順を示すフローチャートである。ステップ140において、製造者証明36のDIE_IDフィールドが“0”に設定されている場合には、“0”を戻す。そうでない場合には、DIE_IDフィールドを、eFuseメモリ14に格納されているDIE_ID_FUSE値と比較する。この場合には、比較された二つのフィールドの一致、不一致を表す値が戻される。
【0057】
さらに、図3において、DIE_IDフィールドが“0”に設定されている場合には、DIE ID有効状態が戻され、処理手順がブロック96で継続される。
【0058】
DIE_IDフィールドが“0”に設定されておらず、製造者証明36のダイIDがeFuseメモリ14に格納されているDIE_ID_FUSE値と一致しないならば、所定の機能が無効となる。しかし、緊急呼び出し機能など、いくつかの機能は動作可能である。
【0059】
セキュア・ブート・ローダとセキュア・リセット・ブート・チェッカは、製造の時点もしくは改造の際に、有効なファームウェアのみが装置10にロードされていることを確認する。製造者の秘密鍵を用いた暗号化がなければ、システムファームウェアはロードできないため、ユーザあるいは第三者による、格納されたファームウェアの変更あるいは置き換えが防止される。
【0060】
しかし、ファームウェアのインストールが保護されていたとしても、ファームウェアの実行中に、ファームウェアや特定のデータの変更されるのを防止するために、更に他の手段を講じることが必要である。このように付加されるセキュリティ機能によって、実行の特権を変更することにより、装置内に格納されたデータが外部に公開されたり、許可されていないファームウェアから装置10が再利用されることを防止する。
【0061】
装置10の動作中は、システムファームウェアのローディング後に、セキュア・ランタイム・プラットフォーム・データ・チェッカとセキュア・ランタイム・チェッカが、システムソフトウェアが変更されていないことを確認し、システムソフトウェアの製造者証明36のPLATFORM_DATAフィールドに設定が行われていることを確認する。
【0062】
図9は、セキュア・ランタイム・プラットフォーム・データ・チェッカとセキュア・ランタイム・チェッカの動作を示したフローチャートである。セキュア・ランタイム・プラットフォーム・データ・チェッカ200は、製造者証明36のPLATFORM_DATAフィールドに格納された、装置10の特定のデータの変更を防止するものである。セキュア・ランタイム・チェッカ202は、ファームウェアの変更あるいは交換を防止するものである。
【0063】
ステップ204において、セキュア・サービスが起動される。本実施例では、セキュア・サービスの呼び出しは、プロセッサ26の休止する時期が検出された際に行われ、チェッカ200および202は、他のアプリケーションに対する介入を最小限に抑えるようにしている。また、セキュア・サービスは、オンチップのハードウェアタイマによっても起動が可能となっており、休止時期に関わらず、予め定められた時間内にセキュア・サービスの呼び出しが確実に行うことが可能である。この予め定められた時間は、製造者証明36のCONFIG_PARAMフィールドに格納された構成パラメータに従って、ブート時に設定される。また、セキュア・サービスは、ソフトウェア・アプリケーションからの要求に応じても起動が可能となっている。一度、セキュア・サービス呼び出しが起動されると、全ての割り込み処理が禁止され、セキュア・ランタイム・プラットフォーム・データ・チェッカ200とセキュア・ランタイム・チェッカ202を実行するプロセッサは、割り込みを受けず、また、チェッカの処理が完了するまでその実行が中断することはない。
【0064】
セキュア・ランタイム・プラットフォーム・データ・チェッカについて、ステップ206において、図4に示した手順と同様に、製造者証明36に格納された製造者の公開鍵(MAN_PUB_KEY)が認証される。MAN_PUB_KEYの認証により、後に行われる認証ステップで、公開鍵と秘密鍵の組み合わせが偽値で置き換えられることを防止する。
【0065】
ステップ208において、製造者の公開鍵の認証が不合格となった場合には、セキュア・ランタイム・プラットフォーム・データ・チェッカの処理は中止され、ステップ210で、装置はリセットされる。
【0066】
ステップ208において、製造者の公開鍵の認証が合格となった場合には、ステップ212に進み、システムブート・ファームウェア証明の認証が行われる。システムブート・ファームウェア証明の認証は、図5に示した手順と同様に行われる。このステップにより、製造者証明36中のデータ、特に、PLATFORM_DATAフィールドに格納された値に変更が加えられていないことを確認する。
【0067】
ステップ214において、システムブート・ファームウェア証明の認証が不合格となった場合には、セキュア・ランタイム・プラットフォーム・データ・チェッカ200の処理は中止され、ステップ210で、装置はリセットされる。
【0068】
製造者証明のDIE_IDが0に設定されていない場合は、DIE_IDフィールドの値は、eFuseアレイ24に格納されたDIE_ID_FUSEと比較される。両者が一致することが、製造者証明のプラットフォームに関したデータがプラットフォームに属することを保証することになる。製造者証明のDIE_IDが0に設定されている場合は、製造者証明36中のPLATFORM_DATAフィールドと、プラットフォーム証明38のPLATFORM_DATAフィールドの値が一致することが、製造者証明のプラットフォームに関したデータがプラットフォームに属することを保証することになる。
【0069】
ステップ218において、プラットフォームデータの有効状態が、(もしあるとすれば)呼び出し側のソフトウェアに戻される。プラットフォームデータが、期待されるプラットフォームデータと一致しない場合には、装置のなんらかの機能が動作不可とされるが、緊急呼び出しなどのいくつかの機能は動作可能な状態が維持される。
【0070】
ステップ220からステップ240は、セキュア・ランタイム・チェッカ202の動作を示したものである。これらのステップは、各ファームウェアのタスクで実行される。ステップ220では、テスト対象となるファームウェアの製造者証明36に格納された製造者の公開鍵(MAN_PUB_KEY)を、図4に示した方法と同様に、認証する。MAN_PUB_KEYを認証することにより、後に行われる認証ステップで、公開鍵と秘密鍵の組み合わせが偽値で置き換えられることを防止する。
【0071】
ステップ222で、製造者の公開鍵認証が不合格であると判定された場合、もし、(ステップ224に進んで判定を行い)テスト対象のファームウェアがシステムブートファームウェアならば、セキュア・ランタイム・チェッカ202の処理は中止され、ステップ210で、装置はリセットされる。もし、テスト対象のファームウェアがシステムブートファームウェアでないならば、ステップ226で処理を終了する。
【0072】
ステップ222において、製造者の公開鍵認証が合格と判断された場合には、ステップ228に進み、テスト対象のファームウェアのファームウェア証明(SIG_CERT)が認証される。ファームウェア証明の認証は、図5で示した方法と同様に行われる。
【0073】
ステップ230において、ファームウェア証明の認証が不合格と判断された場合には、(ステップ224に進んで判定を行ない)テスト対象のファームウェアがシステムブートファームウェアならば、セキュア・ランタイム・チェッカ202の処理は中止され、ステップ210で、装置はリセットされる。もし、テスト対象のファームウェアがシステムブートファームウェアでないならば、ステップ226で処理を終了する。
【0074】
ステップ230において、ファームウェア証明の認証が合格と判断された場合には、ステップ232に進み、発信者の公開鍵(ORIG_PUB_KEY)の認証を行う。ファームウェアの製造者証明のORIG_PUB_KEYの認証は、図6で示した方法と同様に行われる。
【0075】
ステップ234において、発信者の公開鍵の認証が不合格と判定された場合には、(ステップ224に進んで判定を行ない)テスト対象のファームウェアがシステムブートファームウェアならば、セキュア・ランタイム・チェッカ202の処理は中止され、ステップ210で、装置はリセットされる。もし、テスト対象のファームウェアがシステムブートファームウェアでないならば、ステップ226で処理を終了する。
【0076】
ステップ234において、発信者の公開鍵の認証が合格と判定された場合には、ステップ236に進み、ファームウェアの認証が行なわれる。ファームウェアの認証は、図7に示した方法と同様に行なわれる。
【0077】
ステップ238において、ファームウェアの認証が不合格と判定された場合には、(ステップ224に進んで判定を行ない)テスト対象のファームウェアがシステムブートファームウェアならば、セキュア・ランタイム・チェッカ202の処理は中止され、ステップ210で、装置はリセットされる。もし、テスト対象のファームウェアがシステムブートファームウェアでないならば、ステップ226で処理を終了する。
【0078】
全ての認証テストが合格となった場合には、ステップ240において、DieIDの検証が行なわれる。DieIDの検証は、図8に示した方法と同様に行われる。
【0079】
ステップ242において、DieIDの有効状態が、(もしあるとすれば)呼び出し側のソフトウェアに戻される。DIE_IDフィールドが“0”に設定されておらず、製造者証明36のDieIDの値が、eFuseアレイ24に格納されたDIE_ID_FUSEの値と一致しない場合は、装置のなんらかの機能が動作不可とされるが、緊急呼び出しなどのいくつかの機能は動作可能な状態が維持される。
【0080】
チェッカのタスク200および202が完了した後、ファームウェアのテストが合格となった場合には、以前からの処理は、停止位置から再開され、割り込みが再度可能となる状態となる。
【0081】
ファームウェアの動作中に、ファームウェアとプラットフォームのデータ認証を行なうことにより、ファームウェアの起動後にファームウェアの置き換え行為を検知し、それを防止することが可能となる。チェッカのタスク200および202を実行する前後に、プロセッサの状態を管理することにより、システムを再度初期化することなく、これらのタスクの実行が可能とすることができる。
【0082】
図10は、プラットフォーム証明38をアプリケーションファイル32あるいはデータファイル34に関連付けを示した図である。表2は、プラットフォーム証明の一実施例におけるフィールドを列挙したものである。
【表2】
【0083】
プラットフォーム証明38は、eFuseメモリ14に格納されたKEKを利用する。本実施例では、KEKは、製造時にオンチップで生成された乱数であり、KEKの値は、誰にも知られないようになっている。eFuseメモリ14に格納されたKEKは、I/Oポートによっても、あるいはアプリケーションソフトウェアによってもアクセスできないようになっている。各チップのKEKは、他のプログラムによって外部から決定されたり検知されることができないように用いられることが望ましい。KEKはeFuseメモリ14に格納されているため、ヒューズメモリの融解状態を物理的に検出することによりKEKを求めることができるが、このような検出は、チップ自身を破壊することによってのみ可能となる。各チップは個別にKEKを生成するため、一つのチップのKEKが知られたからといって、他のチップのセキュリティを脅かすことにはならない。
【0084】
KEKは、装置の動作中に、ランダムに生成される他のソフトウェア鍵を暗号化するために用いられる。図9に示すように、(ハードウェアあるいはソフトウェアのいずれかの形態で実装することが可能な)乱数発生器250は、必要に応じ、ランダムソフトウェア鍵(SW_KEY)を生成する。このように、各アプリケーションには、異なるソフトウェア鍵を付与することが可能となる。ステップ252において、KEKを用いてSW_KEYは暗号化され、ENC_SW_KEYとしてプラットフォーム証明38に格納される。ENC_SW_KEYは、KEKを用いてのみ暗号解読が可能であり、KEKは秘密であり、チップ内部に格納されているため、ENC_SW_KEYは、KEKにアクセスするアプリケーションによってのみ暗号解読が可能である。従って、ROM中のシステムソフトウェアのみが、KEKにアクセス可能となる。
【0085】
プラットフォーム証明38中の他のセキュリティ値は、SW_KEYを用いて暗号化される。証明の一部ではないが、アプリケーションファイル32あるいはデータファイル34は、暗号化ステップ254および256に示した機密保持要求に応じて、オプションとして、SW_KEYによって暗号化される。アプリケーションファイル32あるいはデータファイル34が暗号化されるか、されないかは、ソフトウェア署名(SW_SIG)あるいは署名証明(SIG_CERT)にも影響を与える。ステップ258において、ソフトウェアファイル32あるいはデータファイルは(暗号化はオプションとなるが)ハッシングされ、ステップ260において、SW_KEYを用いて暗号化される。この値は、SW_SIGとして格納される。ステップ262において、証明フィールドはハッシングされ、ステップ264において、SW_KEYにより暗号化される。この値は、SIG_CERTとして格納される。
【0086】
プラットフォーム証明は、アプリケーションあるいはデータファイルを、それがロードされる装置10に関連付けを行なう。一度関連付けが行なわれると、プラットフォーム証明は無効となり、アプリケーションあるいはデータファイルは、他の装置へは移動することができなくなる。さらに、アプリケーションファイル32あるいはデータファイル34を、特定のプログラムに関連付けるために、APPLI_IDフィールドが用いられる。たとえオーディオあるいはビデオファイルが、様々なアプリケーションで再生可能な標準形式のものであったとしても、例えば、オーディオあるいはビデオファイルのみを、特定のメディア再生アプリケーションに関連付けるために、これが用いられる。
【0087】
図11は、アプリケーションあるいはデータファイルをアプリケーションで実行するために必要となるプラットフォーム証明に対して、アプリケーションあるいはデータファイルの関連付けを解除する処理を示すものである。ステップ270において、eFuseメモリ14に格納されたKEKを用いて、プラットフォーム証明38のENC_SW_KEYから、SW_KEYを求める。SW_KEYを用いて、ステップ272において、プラットフォーム証明38のSIG_CERTフィールドを暗号解読し、ステップ274において、SW_SIGフィールドを暗号解読する。
【0088】
ステップ276において、プラットフォーム証明38のSIG_CERT以外のフィールドをハッシングする。ステップ278において、ハッシングした結果を、暗号解読されたSW_CERTフィールドの値と比較する。同様に、ステップ280において、格納されたアプリケーションあるいはデータファイルをハッシングし、ステップ282において、ステップ274で暗号化されたSW_SIGと比較される。ステップ278での比較、あるいはステップ300での比較のいずれかが不一致となった場合には、ステップ302において、システムエラーが発行される。そうでない場合には、ステップ304および306でオプションとしての暗号解読の後、アプリケーションが実行される(もしくは、データファイルがアプリケーションで利用される)。
【0089】
プラットフォーム証明は、従来例に対して、大きな利点をもたらすものである。ソフトウェアあるいはデータファイルを、装置10に関連付けることにより、元のソフトウェアモジュールが変更されたことを明らかにし、ソースプログラムがコピーされ、ほかのプラットフォームで実行されることを防止でき、クローンによる攻撃に対する効果的な保護を提供し、特に、重要なこととして、著作権管理と媒体の保護を可能とする。
【0090】
本方式は、一方向ハッシングおよびバルク暗号化など、プラットフォーム署名と検証に対する強力な暗号化技術に基づいたものであるため、高レベルのセキュリティを提供するものとなる。本方式は、任意のコンピュータ・ハードウェア・プラットフォームに対して、容易に適用することが可能である。KEKと、関連付けの際にランダムに生成されたソフトウェア鍵とを用いることにより、外部メモリ中の暗号化鍵を外部に格納することが可能となる。無制限数の異なるソフトウェア鍵を、アプリケーションおよびデータファイルに用いることができる。さらに、署名の計算のために、対称性のあるバルク暗号化技術を用いることにより、非対称な暗号化技術に比べ、計算機の処理負荷を削減することが可能となる。
【0091】
図12は、セキュリティを保ちながら、外部メモリ中のIMEI(国際携帯機器識別)番号を格納するための、製造者および、あるいはプラットフォーム証明の特別な利用方法を示したものである。IMEI番号は、UMTS(欧州の第3世代移動体通信システム)標準規格、第5版で規定され、電話のクローンと旧規格や不適合の利用者機器に対して、電話の製造者と運用者の両者を保護するためのものである。IMEI番号は、携帯電話のどこかに格納され、要求に応じて供用されるネットワークに送り出される必要がある。(ハードウェア、ソフトウェアあるいは物理的な)何らかの手段による改ざんに対して、IMEI番号を保護することは、モバイル機器に求められるセキュリティレベルを大いに向上させてきた。改ざんを防止するために、多くの製造者は、製造プロセスの最後に、個々の電話に一意となるIMEI番号を、チップに格納してきた。しかし、改ざん防止となるようにチップ上に番号を格納することは、コストのかかるものである。
【0092】
図12に示すように、IMEIは、各電話ごとにカストマイズされた製造者証明(特に、PLATFORM_DATAフィールド)に記された外部メモリ、および、あるいは、プラットフォーム証明に関連付けられた外部メモリに格納されている。ベースバンド処理システム12は、システムブート・ファームウェアの製造者証明36、あるいは、プラットフォーム証明38に関連付けられたメモリ位置のいずれかから、外部メモリ中のIMEIにアクセスする。
【0093】
IMEI番号が、製造者証明36のPLATFORM_DATAフィールドで変更された場合、その変更は、システムブート・ソフトウェアの実行に先立ち、セキュア・リセット・ブート・チェッカにより検出される。もし、システムブート・ソフトウェアがロードされた後で変更された場合には、IMEI番号の変更は、セキュア・ランタイム・プラットフォームデータ・チェッカにより検出される。
【0094】
もし、IMEIが、プラットフォーム証明に関連付けられた外部メモリに格納されている場合には、IMEI番号の変更は、無効なSW_SIGとして検出される。プラットフォーム証明を用いて、IMEIは、外部メモリの任意の位置に格納することができる。
【0095】
装置10をプログラムすることにより、たとえ、IMEIが無効な製造者証明36あるいは無効なプラットフォーム証明38をもたらした場合でも、緊急呼び出しが可能となる。
【0096】
図13は、装置10の動作を制御するために、製造者証明36のフィールドを用いる処理を示すブロック図である。図13に示すように、製造者証明36のDEBUG_REQフィールドを用いて、テストアクセスおよびエミュレーション回路320を制御する。製造者証明36のCONF_PARAMフィールドのパラメータを用いて、ブロック332および324で示すように、ハードウェアあるいはソフトウェアを適切に構成することにより、装置10の動作の様々な状態を制御することができる。
【0097】
システムの動作中は、システムブート・ソフトウェアが、製造者証明中の構成パラメータにアクセスし、ハードウェアおよびソフトウェア資源を構成する。製造者証明36中に構成パラメータを配置することにより、製造者は、柔軟なハードウェアおよび、あるいはソフトウェア構成を有する装置を設計し、安全にセキュリティを確保しながら適切に装置を構成することが可能となる。
【0098】
セキュリティを確保しながら構成パラメータを製造者証明36に格納する第一の利用には、装置10に対して、管理された状況で構成を入力することを可能とすることがあげられるが、ここでは、構成によっては、装置10が攻撃に対して無防備な状況にさらしてしまう場合がある。例えば、テストモードの間、装置10は、通常は隠されたメモリ位置が、読み出しおよび、あるいは書き込みを許すような構成状態に置かれることもある。また、メモリ性能設定、バス速度、処理速度などのハードウェアパラメータが、システム動作を分析するために、テストモードの間に変更が可能とされることもある。
【0099】
セキュリティを確保しながら構成パラメータを製造者証明36に格納する第二の利用では、装置10の性能を制御することがあげられる。計算機産業ではよく知られているように、装置を限界性能まで到達させようとして、装置のハードウェアおよび、あるいはソフトウェアのパラメータを、ユーザ自身が再構成する場合がある。例えば、多くのユーザにより、プロセッサが動作するシステムクロック速度あるいは複数のシステムクロックを変化させ、パソコンのプロセッサ速度の“オーバークロック”を行なう場合がある。さらに、メモリアクセスおよびスループットを向上させるために、メモリ設定を変更することもありうる。確かに、オーバークロックは、計算機装置の性能を向上させることが可能であるが、それにより、ハードウェアをその仕様温度を上回る温度で動作させることにより、ハードウェアの寿命を短くしてしまうこともある。さらに、計算機装置は、オーバークロック設定では、誤動作する可能性もある。このように、オーバークロック設定は、保証とサポートの観点からは、製造者にとってコストのかかる面をもっている。
【0100】
製造者証明36でパラメータを設定することにより、性能設定に対する変更の試みを防止することができる。これは、性能設定は、製造者証明36で定義され、製造者の許可の元でのみ変更が可能となるためである。システムブート・ソフトウェアは、定義されたパラメータにリセットされた後、装置を構成する。証明で許可された設定を変更しようとする試みは、(リセット後の)セキュア・リセット・ブート・チェッカ52あるいはセキュア・ランタイム・チェッカ202によって、検出される。システムファームウェアの外にあるソフトウェアにより、構成パラメータを変更しようとする試みは、セキュア・ランタイム・プラットフォーム・データ・チェッカ200によって、検出される。
【0101】
セキュリティを確保しながら構成パラメータを製造者証明36に格納する第三の利用では、異なる性能および、あるいは異なる機能性に対する設定を有する単一の装置を提供することがあげられる。装置は、製造者証明36に格納された構成設定に基づき販売され、その構成は、ユーザあるいは第三者によって変更できないようにしたものである。装置10は、製造者により、容易にアップグレード可能である。
【0102】
例えば、携帯型の計算機装置プラットフォームは、複数のプロセッサ速度で動作し、無線ネットワーク、オーディオおよびビデオ機能のような、異なるオプションの機能性を有するように設計することが可能となっている。装置は、PCカードやメモリポートの拡張などの高価なハードウェアアップグレードではなく、後日、アップグレード可能となるように、所望の構成を持たせて販売される。
【0103】
図14は、図13の変形であり、構成データは、プラットフォーム証明で保護されたデータファイル34に格納されている。構成パラメータを格納したデータファイル34を変更させようとする試みは、システムファームウェアによって検出される。セキュア・ランタイム・プラットフォーム・データ・チェッカ200は、装置の動作中に、データファイルの内容をチェックするように、変更されている。
【0104】
図15は、テストモードなどのモードで装置10にアクセスするための他の設計を示したものである。この設計では、アクセスコードのハッシュ(H_Test_ID)を格納する。このコードは、eFuseメモリ24に格納されている。テストモードにアクセスするため、第三者は、アクセスコード(Input_Test_ID)を入力する必要がある。ブロック330において、Input_Test_IDはハッシングされ、ブロック332において、H_Test_IDと比較される。ブロック330でハッシングされたアクセスコードが、格納されたハッシングされたアクセスコードと一致した場合には、このモードへのアクセスが可能となる。
【0105】
システムの動作中は、H_Test_IDは、通常は、Input_Test_IDに比べて極めて小さな長さを持つため、アクセスコードを格納するために必要な格納領域を削減することが可能となる。しかし、所望のモードに入るためには、第三者は、より大きな数を必要とする。複数の入力をハッシングして、H_Test_IDに一致させるものを得ることは可能ではあるが、SHA−1あるいはND5などの現在のハッシングアルゴリズムを用いて、不当に入力されたアクセスコードが一致する結果を生み出すことは、統計的な観点からはありえないことである。
【0106】
さらに、図15の設計は、さらにセキュリティ上の利点をもたらすものとなっている。格納されたハッシング結果、H_Test_IDが知られてしまった場合でも、ハッシングすることによりH_Test_IDを得るような入力コードを決定することは、計算機処理の観点からは困難なものとなっている。
【0107】
テストモードへのアクセスについて、ハッシングされたアクセスコードを用いることを説明したが、これは、上述したように、システムパラメータを変更するためのアクセスなど、任意の状況でセキュリティを確保することに適用することが可能である。
【0108】
本発明の詳細な説明を、一例となる実施例に対して行なってきたが、これらの実施例の様々な変形や、他の実施例は、当業者であれば思いつくものである。本発明は、クレームの範囲内であれば、任意の変形や代わりの実施例を包含したものとなっている。
【図面の簡単な説明】
【0109】
【図1】図1は、移動型計算機環境のファームウェア、アプリケーションソフトウェアおよびデータを保護するために用いられる様々な保護機構を示す基本ブロック図である。
【図2】図2は、図1に示した製造者証明のための一実施例を示す図である。
【図3】図3は、セキュア・ブート・ローダおよびセキュア・ブート・チェッカ・プログラムでの、製造者証明の利用を示すフローチャートである。
【図4】図4は、製造者証明に格納された製造者の公開鍵の認証処理を示すフローチャートである。
【図5】図5は、製造者証明の証明署名フィールドの認証処理を示すフローチャートである。
【図6】図6は、製造者証明の発信者の公開鍵フィールドの認証処理を示すフローチャートである。
【図7】図7は、製造者証明に関連付けられたファームウェアの認証処理を示すフローチャートである。
【図8】図8は、製造者証明のDIE識別コードの検証処理を示すフローチャートである。
【図9】図9は、セキュア・ランタイム・プラットフォーム・データ・チェッカとセキュア・ランタイム・チェッカの動作を示すフローチャートである。
【図10】図10は、プラットフォーム証明による、アプリケーションファイルあるいはデータファイルの計算機プラットフォームへの関連付けを示す図である。
【図11】図11は、アプリケーション内でアプリケーションの実行あるいはデータファイルの利用に必要な、アプリケーションあるいはデータファイルのプラットフォーム証明からの関連付けの解除を示す図である。
【図12】図12は、セキュリティを確保してIMEI(内部移動機器識別)番号を外部メモリに格納するための、製造者および、あるいはプラットフォーム証明の特定利用を示す図である。
【図13】図13は、装置の動作を制御するために、製造者証明のフィールドを利用するブロック図である。
【図14】図14は、プラットフォーム証明によって保護されたデータファイル中に構成データを格納した、図13のブロック図の変更例を示す図である。
【図15】図15は、装置10へのアクセスのための他の設計例を示す図である。
【技術分野】
【0001】
関連出願に関する言及
本出願は、2002年7月30日出願の米国仮出願第60/399,592号、バラード他発明による“ファームウェアのランタイム認証”の同時継続の出願日の利点を主張するものである。
【0002】
また、本出願は、工業所有権の保護に関するパリ条約の元に、2002年12月10日に欧州特許庁に出願された、出願番号02293057.2の優先権を主張するものである。12月10日以前の日付をもつ、本主題と同一の他国への出願はない。
【0003】
連邦予算にもとずく研究あるいは開発に関する報告
なし。
【0004】
本発明は、一般的に処理装置に関するものであり、特に、セキュア計算機システムに関するものである。
【背景技術】
【0005】
現在の計算機装置は、様々な形態と形状を有するものとなっている。従来の計算機装置としては、パーソナルコンピュータがある。さらに最近は、PDA(個人用携帯情報端末)やスマートフォンなどの移動型計算機装置の出現により、計算機装置と通信装置との間の境界がはっきりしなくなってきている。さらに、計算機装置は、自動車の制御装置などのように、利用者に対して実質的に見えない方法で利用されるものとなっている。
【発明の開示】
【発明が解決しようとする課題】
【0006】
計算機装置、あるいはプロセッサなどの計算機装置の部品の製造者は、以前であれば、これらの装置の動作に対してセキュリティを提供することが不可能であった。セキュリティに対して、よく知られた危険性の一つとしては、第三者による計算機装置に対する攻撃があげられる。攻撃者は、様々な手段を用いて、計算機装置のシステムファイル、アプリケーションファイル、あるいはデータを変更することが可能である。ある場合には、このような攻撃は、極めて迷惑なものであり、また、ある場合には、所有者に対して多大な出費を強いる恐れがある。
【0007】
計算機システムを、権限のない状態で変更することは、必ずしも第三者によって行われるものとは限らない。計算機装置の意図された操作に対するいくつかの変更は、ユーザによって行われる場合がある。例えば、ユーザは、装置の意図された設定を変更するかもしれないし、時として、それは、装置の動作を改善するために、認められていないソフトウェアを用いて行われる場合もある。自動車の制御装置のファームウェアの変更などの場合には、このような変更は、極めて危険なものとなる可能性がある。
【0008】
また、別の場合として、ユーザは、データやプログラムを、ある装置から別の装置に転送しようとする可能性もある。この場合、著作権保護の観点から不適切なものであったり、動作が不安定となる計算機プラットフォームにソフトウェアが移されてしまうこともありうる。
【0009】
製造者は、システムファームウェア、ソフトウェアおよびデータの起源と完全性を証明することの必要性をますます認識している。ソフトウェア提供者の起源を証明するデジタル証明書などの仕掛けにより、ある程度の成功を収めてはいるが、これらの手段は、不完全なものであり、特に、巧妙な攻撃者やユーザによって、容易に回避されてしまうことがわかっている。
【0010】
このように、セキュアな計算機プラットフォームへのニーズが高まってきている。
【課題を解決するための手段】
【0011】
本発明では、計算機装置の資源へのアクセスは、計算機装置の既知のメモリ位置に暗号化されたアクセスコードを格納することによりセキュリティが確保される。計算機装置は、資源にアクセスするためのパスワードを受信し、暗号化されたパスワードを生成するために、そのパスワードは暗号化される。暗号化されたパスワードは、暗号化されたアクセスコードと照合され、暗号化されたアクセスコードと暗号化されたパスワードが一致した場合のみ、資源へのアクセスが許可される。
【発明の効果】
【0012】
本発明は、従来技術に対して、特徴的な利点を有している。暗号化されたアクセスは、パスワードよりもかなり短く、これにより、アクセスコード情報を格納するために必要なメモリ容量をかなり削減することが可能となり、その一方で、アクセスを行うために必要なパスワードは、元の長さのままであるものではある。
本発明とその利点をより完全に理解できるように、添付図と併せて以下の記述を参照する。
【0013】
以下、図1から15を用いて本発明を説明する。なお、同一の符号は、全ての図で同じ部分を指すものである。
【実施例】
【0014】
図1は、移動型計算機環境のファームウェア、アプリケーションソフトウェアおよびデータを保護するために用いられる様々な保護機構を示す基本ブロック図である。本発明の以下の説明は、携帯電話やPDAなどの移動型計算機装置に関連して述べるものであるが、本発明は、他の計算機装置に対しても同様に適用可能である。
【0015】
図1の移動型計算機装置10の回路は、3つの主要ブロックに分けられている。すなわち、ベースバンド処理システム12、不揮発性外部メモリシステム14およびRF(無線周波数)システム16である。ベースバンド処理システムは、RF変調の前のデータ処理を担うものである。図1では、ベースバンド処理システム12には、SRAM(静的ランダムアクセスメモリ)10、ROM(読み出し専用メモリ)22およびヒューズメモリアレイ(eFuse)24を含む内部メモリサブシステム18が組み込まれている。一つあるいはそれ以上の数の、汎用プロセッサ、デジタル信号プロセッサおよびコプロセッサなどの処理装置26が、内部メモリサブシステム18に接続されている。入出力(I/O)回路28は、プロセッサ26および内部メモリサブシステム18に接続されている。
【0016】
ファームウェア30、アプリケーションソフトウェア32およびデータファイル34が、外部不揮発性メモリシステム14に格納されている。ファームウェア30は、装置の販売に先立って、製造者によって装置に格納された基本システムコードである。ファームウェア30は、機能の追加やエラー修正などのために製造者によって更新されるが、永久にプラットフォームに常駐するものである。多くの場合、製造者によって装置10に搭載されたファームウェア30のみが用いられ、ファームウェアは、製造者以外の者や、製造者の許可のもとに作業する者以外の者によっては、変更や置き換えがなされるものではないことは、特に重要なものとなっている。従って、ファームウェア30に関しては、セキュリティが極めて重要な意味を持っている。さらに、許可されていないファームウェアは、実行されないことも重要である。また、セキュリティは、アプリケーションソフトウェア32およびデータファイル34に関しても、重要な意味を持っている。アプリケーションソフトウェア32およびデータファイル34に関して、これらのファイルの完全性を確保することは、しばしば重要なものとなる。例えば、これらのファイルが、他の“ウイルス”ソフトウェアにより、変更、削除あるいは置き換えがなされないように保証することが望ましい。また、アプリケーションソフトウェア32および(音楽および映像ファイルなどの)データファイル34の複写を防止し、これらの創作物の所有者の著作権を保護することが望ましい。
【0017】
図1に示すように、二種類の保護機構を用いて、容易にアクセス可能となる外部メモリの内容を保護することが可能となる。ファームウェアについては、“製造者”証明36は、ファームウェアを、特定の計算機装置10に関連付ける(複数の製造者証明は、それぞれのファームウェアタスクに関連付けられる)。同様に、アプリケーションソフトウェア32およびデータファイル34は、それぞれの“プラットフォーム”証明38によって、特定の計算機装置10に関連付けられる。これらの証明は、以下で詳細に説明するように、ファームウェア、アプリケーションソフトウェアおよびデータの変更を防止し(および、オプションとして、これらの秘密保持を保護し)、さらに、ファームウェア、アプリケーションソフトウェアおよびデータが他の装置に複写されることを防止するために用いられる。
【0018】
ここで説明するセキュリティ機能は、いくつかの暗号化技術を用いている。“対称鍵”(あるいは“秘密鍵”)による暗号化では、同一の秘密鍵を用いて、暗号化と暗号解読を行う。対称鍵による暗号化の例としては、DES(データ暗号化規格)がある。“非対称鍵”(あるいは“公開鍵”)による暗号化では、二つの鍵、秘密鍵と公開鍵が用いられる。鍵生成アルゴリズムにより、鍵のマッチドペアを生成し、(将来、送り手となる見込みのある者へ発行される)公開鍵を用いて情報を暗号化し、(受け手により秘密に保有される)秘密鍵を用いて暗号解読を行う。また、その反対に、秘密鍵を用いて情報を暗号化し、公開鍵を用いて暗号解読を行うことも可能である。公開鍵から秘密鍵を導出することは計算の上では可能なことではない。秘密鍵は、セキュリティが確保された経路によって送る必要がないため、非対称な暗号化システムを用いることにより、前もってセキュリティ上の取り決めを行っていない者であっても、情報交換が可能となる。(RSAセキュリティ社により開発された)RSA暗号化技術は、公開鍵暗号化の一例である。
【0019】
一方向ハッシュ関数は、可変長の入力をもち、“メッセージダイジェスト”あるいは“ハッシュ”として知られる固定長の出力を生成する。ハッシュ関数は、情報に何らかの変更が加えられた場合に、完全に異なる出力を生成することを保証する。通常、ハッシュアルゴリズムは、データの完全性を検証するために用いられる。SHA−1(160ビットのハッシュ)およびMD5(128ビットのハッシュ)は、一方向ハッシュ関数の一例である。
【0020】
デジタル署名により、情報の受け手は、情報の起源の信憑性を検証し、また、情報が完全であることを検証することが可能となる。通常、情報の送り手は、その情報のハッシュを計算し、送り手の秘密鍵を用いてハッシュを暗号化することにより、メッセージに署名する。情報の受け手は、送り手の公開鍵により暗号解読し(すなわち、送られたハッシュを得て)、受信したメッセージのハッシュを計算し、これらの二つを比較することにより、メッセージの署名を検証する。従って、公開鍵によるデジタル署名は、認証とデータの完全性を提供するものとなる。また、デジタル署名は、非拒絶を提供するものであり、すなわち、送り手が情報の起源を否認することを不可能とするものである。DSA(デジタル署名アルゴリズム)は、デジタル署名暗号化システムの一例である。
【0021】
公開鍵暗号化システムの問題の一つとして、ユーザは、介入者攻撃に対する防護のため、正しい公開鍵を用いて暗号化あるいは暗号解読が行われていることを確かめるために、常に、注意しなければならないという点がある。(ここでは、攻撃者は、データストリーム中のパケットを途中で捕らえ、パケットを改変し、元の送り手が指定した本来の宛先に対してこれらのパケットを転送する。)デジタル証明は、公開鍵が、意図した所有者に正しく属しているかを確立する処理を簡単化するデジタル形式のパスポートあるいは保証書である。この簡単化された形式では、証明は、証明局などの、信頼されたものによりデジタル的に証明されたユーザの公開鍵である。また、証明は、バージョン番号、ユーザID番号、有効期限などの付加情報を含むことも可能である。
【0022】
他のセキュリティ機能をサポートするため、所定のコードと鍵が、ベースバンド処理システム12の内部に保持されている。悪意のある改ざんを防止するため、いくつかのシステムプログラムがROM22に搭載されている。これらのプログラムには、(図3で詳細に説明する)セキュア・ブート・ローダ、(図3で詳細に説明する)セキュア・リセット・ブート・ローダ、(図9で詳細に説明する)セキュア・ランタイム・プラットフォーム・データ・チェッカ、(図9で詳細に説明する)セキュア・ランタイム・チェッカ、(図10および図11で詳細に説明する)セキュア・ランタイム・ローダ、および、データ暗号化とハッシングをサポートするための様々な暗号ソフトウェアが含まれている。暗号化技術のいくつかあるいは全ては、専用の暗号プロセッサで実行される。
【0023】
さらに、本実施例では、所定のシステムデータが、eFuseアレイ24(あるいは、ベースバンド処理システム12に内臓された他の固定記憶装置)に保持されている。データがアレイに書き込まれた後は、データの上書きが不可能となるなど、特定のアレイ位置への書き込みが禁止される。
【0024】
DIE識別番号は、各々の個別機器に対応づけられた一意の番号である。本実施例では、この番号は、DIE_ID_FUSEとして、製造時にeFuseアレイ24に格納される。この識別コードは、秘密であるとは考えられておらず、セキュリティのないソフトウェアによって読み取ることが可能である。
【0025】
また、製造者の公開鍵も(ここで、“製造者”は、装置10の製造者であり)、H_Man_Pub_Keyとして、ハッシングの後にeFuseアレイ24に格納される。製造者の公開鍵は秘密ではないため、H_Man_Pub_Keyを格納する位置は、外部からのアクセス処理に対して保護される必要はないが、書き込みの後は、改変に対して保護する必要がある。H_Man_Pub_Keyの利用については、図4でより詳細に説明する。なお、製造者の公開鍵のハッシングはオプションであり、ハッシングは、鍵を格納するために必要なメモリ容量を削減するために、長いサイズの鍵を圧縮するために用いられる。
【0026】
また、テストIDあるいは他のアクセスIDも、ハッシングの後にeFuseアレイ24に格納される。ハッシュ処理されたテストID(H_Test_ID)は、装置に対して、テストモードでは許可されていないアクセスを防止するために用いられる、これは、テストモードでは、いくつかの保護が解除されているためである。これに関しては、図15を用いて詳細に説明する。
【0027】
鍵暗号鍵(KEK)は、装置の製造時に、ベースバンドプロセッサに内臓された乱数発生器により生成された秘密鍵である。KEKは、eFuseアレイ24に格納されており、変更が不可能であり、外部からもアクセスが不可能となっている。従って、特定の装置に対するKEKは、製造者によってさえ決定することができない。KEKは、プラットフォーム証明38に対する付加的な暗号鍵を動的に提供するために用いられ、これについては、図10および図11を用いて詳細に説明する。
【0028】
図2は、製造者証明36に関する一実施例を示す図である。なお、特定の装置に対する実際の製造者証明36は、図2に示した実施例よりも多数あるいは少数のフィールドを含むものとなっている。図2に示した製造者証明36のフィールドの要約を、表1に示す。
【表1】
【0029】
証明サイズ(CERT_SIZE)および証明種類(CERT_TYPE)のフィールドは、製造者証明36のサイズと種類(すなわち、“製造者”)を示している。デバッグ要求(DEBUG_REQ)が、装置上でのエミュレーションを可能とする、あるいは禁止するために、製造者によって設定されうる。下で述べるように、製造者のみがこのフィールドの値を設定できる。コードアドレス(CODE_ADDR)のフィールドは、外部メモリ14中のコードの開始アドレスを示している。コードサイズ・フィールド(CODE_SIZE)は、ファームウェアの(バイト単位での)サイズを示している。コード開始アドレス(CODE_START_ADDR)は、実行時のファームウェアのエントリポイントを示している。
【0030】
製造者証明36は、さらに、製造者の公開鍵(MAN_PUB_KEY)および、ソフトウェア発信者の公開鍵(ORIG_PUB_KEY)を含んでいる。ここでは、ファームウェアは、独自の署名を有する第三者により作成されたものと仮定している。ファームウェアが、製造者によって作成された場合には、製造者に対する第二の公開鍵がオプションとして用いられることができる。発信者の公開鍵に対する署名は、ORIG_PUB_KEYをハッシングし、ハッシングされたORIG_PUB_KEYを製造者の秘密鍵(MAN_PRI_KEY)を用いて暗号化することにより作成される。
【0031】
ソフトウェア署名は、ファームウェア30のコードをハッシングし、ハッシングにより得られたハッシュコードを発信者の秘密鍵(ORIG_PRI_KEY)を用いて暗号化することにより作成される。ORIG_PRI_KEYは、発信者に対してのみ秘密が保たれているため、SW_SIGは、発信者から製造者に対して提供されなければならない。
【0032】
特定の装置10のDIE_IDが、製造者証明36に付加される。このデータは、単一の装置に対してコードを組み合わせるものであり、このファームウェアが他の装置にコピーされるのを防ぐためのものである。
【0033】
構成パラメータは、製造者証明36のCONF_PARAMフィールドに設定される。図13と図14に示すように、このフィールドの情報は、装置10で機能的に設定するのに用いられる。例えば、CONF_PARAMフィールドのパラメータは、DPLL(デジタル・フェーズ・ロック・ループ)周波数、メモリアクセスの待ち状態、RF回路16のフィルタおよびゲインの値、および(充電曲線などの)バッテリ管理パラメータを設定するために用いられる。
【0034】
特定の装置に固有なデータは、PLATFORM_DATAフィールドに格納される。例えば、IMEI番号は、このフィールドに格納される。この特徴は、図12で詳細に説明する。
【0035】
製造者証明署名(SIG_CERT)は、製造者証明36の任意のフィールドの改ざんを防止するものである。SIG_CERTは、製造者証明の他のフィールドをハッシングし、ハッシングされたコードをMAN_PRI_KEYを用いて暗号化することにより作成される。
【0036】
図3は、セキュア・ブート・ローダ50とセキュア・ブート・チェッカ・プログラム52での製造者証明36の利用手順を示すフローチャートであり、このプログラムは、好ましくはROM22に格納され、プログラムが変更されることを防止している。セキュア・ブート・ローダは、ブートシステム・ファームウェアが、電源投入時にアップロード可能となっているかどうかを判定する。もし可能ならば、セキュア・ブート・ローダは、最初に、フラッシュ・プログラマーをロードする。フラッシュ・プログラマーは、システムブート・ファームウェアをロードするために用いられる。また、フラッシュ・プログラマーは、製造者証明36を有していなければならず、セキュア・ブート・ローダは、フラッシュ・プログラマーの実行に先立ち、フラッシュ・プログラマーの製造者証明とフラッシュ・プログラマー・プログラムの信憑性と完全性を保証する責任を担っている。これらの後、フラッシュ・プログラマーは、システムブート・ファームウェアをアップロードする。
【0037】
セキュア・リセット・ブート・チェッカ52は、外部メモリ14に格納されているシステムブート・ファームウェア(および他のファームウェア)の実行前に、それらの証明の信憑性と完全性をチェックする。セキュア・ブート・ローダ50あるいはセキュア・リセット・ブート・チェッカ52の実行時には、装置10は、これらの実行が完了する前に、実行に対する割り込みやバイパスが発生しないように構成される。
【0038】
ステップ54では、セキュア・ブート・ローダ50あるいはセキュア・リセット・ブート・チェッカ52は、電源投入あるいはシステムリセットを待つ。ステップ56では、電源投入あるいはシステムリセットの際に、セキュア・ブート・ローダ50は、UART(汎用非同期受信送信機)など、インターフェースの物理的バス上の同期信号のための、所定のインターフェースをチェックする。一定のタイムアウトやウォッチドッグリセット(ステップ58)の後でも、物理バス上での動作が検知されなかった場合には、ファームウェアのダウンロードは行われていないと考えられ、制御をセキュア・リセット・ブート・チェッカ52に切り換える。
【0039】
物理バス上でダウンロード動作が検知された場合には、フラッシュ・プログラマーの実行に先立ち、ステップ60から70によって、フラッシュ・プログラマーの製造者証明36をチェックする。ステップ60では、フラッシュ・プログラマーの製造者証明の中の、製造者公開鍵(MAN_PUB_KEY)の認証を行う。MAN_PUB_KEYの認証処理を、図4に示す。
【0040】
図4は、製造者証明36に格納された製造者公開鍵の認証処理を示したフローチャートである。ステップ100において、ファームウェア(本例では、フラッシュ・プログラマー)の製造者証明中のMAN_PUB_KEYをハッシングして、ステップ102において、ハッシュされた結果が、eFuseアレイ24からのH_MAN_PUB_KEYとを比較される。ステップ104において、両者が合致すると判断した場合には、認証処理は“合格”を返し、そうでない場合には、不合格を返す。
【0041】
他の実施例としては、製造者公開鍵をハッシングした結果を、製造者証明36に格納しておくものがある。この場合は、ハッシング処理のステップ100が不要となる。また、ハッシングされた製造者公開鍵の予め定められた数の最下位ビットのみを、eFuseアレイ14に格納しておくものがある。この場合は、ステップ104において、対応するビットのみを比較する。
【0042】
図3によれば、ステップ62において、製造者公開鍵の認証結果が“不合格”である場合には、ステップ64に進み、処理手順は中止され、フラッシュ・プログラマーのローディングは中止される。装置10は、リセットされ、フラッシュ・プログラマーのダウンロードが再び試みられる。
【0043】
ステップ62において、製造者公開鍵の認証結果が“合格”である場合には、ステップ66に進み、証明署名(SIG_CERT)が認証される。
【0044】
図5は、SIG_CERTの認証処理を示すフローチャートである。ステップ110において、製造者証明36のSIG_CERTフィールド以外のフィールドがハッシングされる。ステップ112において、製造者証明36のSIG_CERTフィールドを、MAN_PUB_KEYを用いて暗号解読する。なお、製造者証明の認証は、MAN_PUB_KEYの認証の後で行われ、これにより、SIG_CERTが製造者の秘密鍵を用いて元々暗号化されている場合には、SIG_CERTのみが正しく暗号解読されることになる。ステップ114において、ステップ110で得られた証明のハッシュ結果と、暗号解読されたSIG_CERTとを比較する。ステップ116において、両者が合致すると判断した場合には、認証処理は“合格”であり、そうでない場合は不合格である。認証が不合格ということは、ファームウェアの製造者証明36の一つあるいはそれ以上の数のフィールドが変更されたことを示している。
【0045】
さらに、図3において、ステップ68において、製造者の証明署名の認証結果が“不合格”である場合には、ステップ64に進み、処理手順は中止され、フラッシュ・プログラマーのローディングは中止される。装置10は、リセットされ、フラッシュ・プログラマーのダウンロードが再び試みられる。
【0046】
製造者の証明署名の認証が合格した場合には、ステップ70に進み、発信者の公開鍵とソフトウェア署名(SW_SIG)に関して、製造者証明の発信者公開鍵フィールド(ORIG_PUB_KEY)を認証し、実際のファームウェアコードとソフトウエア署名(SW−SIG)を認証する。
【0047】
図6は、ORIG_PUB_KEYの認証処理を示すフローチャートである。ステップ120において、MAN_PUB_KEYを用いて、ORIG_PUB_KEY_SIGを暗号解読する。ステップ122において、製造者証明36のORIG_PUB_KEYフィールドが、ハッシングされ、ステップ124において、暗号化された署名と比較される。判断ブロック126において、両者が合致すると判断した場合には、認証処理は合格である。そうでない場合は不合格であり、ORIG_PUB_KEYあるいはORIG_PUB_KEY_SIGのいずれかが変更されたことを示している。
【0048】
図7は、製造者証明36が関連付けられたファームウェアの認証処理を示すフローチャートである。ステップ130において、すでに認証済みのORIG_PUB_KEYを用いて、製造者証明36のSW_SIGフィールドを暗号解読する。次に、ステップ132において、ファームウェア30をハッシングする。ブロック134において、ハッシュの結果を、暗号解読された署名と比較する。ステップ136において、両者が合致すると判定した場合には、認証結果は合格である。そうでない場合は不合格であり、ファームウェアが変更されたことを示している。
【0049】
さらに、図3において、ステップ72において、発信者の公開鍵あるいはファームウェア(本例では、フラッシュ・プログラマー)のいずれか一方の認証が不合格となった場合には、ステップ64に進み、処理手順は中止され、フラッシュ・プログラマーのローディングは中止される。装置10は、リセットされ、フラッシュ・プログラマーのダウンロードが再び試みられる。
【0050】
全ての認証試験が合格となったら、ブロック74において、フラッシュ・プログラマーが実行される。フラッシュ・プログラマーは、システムブート・ソフトウェアをロードし、ステップ76において、強制リセットする。通常、フラッシュ・プログラマーは、リセットの前に、メモリ上から消去される。
【0051】
セキュア・リセット・ブートチェッカ52は、判定ブロック58でのタイムアウト処理の後、動作する。これは、通常、(他のファームウェアがダウンロードされていなければ)フラッシュ・プログラマーの実行完了後、あるいは、電源投入もしくはリセット後にダウンロードする他のファームウェアがない場合に、動作するものとなっている。セキュア・リセット・ブートチェッカは、セキュア・ブート・ローダの動作に関して説明したように、フラッシュ・プログラマーの製造者証明とは対照的に、システムブート・ソフトウェアのフィールドを認証する。
【0052】
ステップ78において、システムブート。ソフトウェアに関する製造者証明36の製造者公開鍵が、図4に示す認証処理を用いて認証される。ブロック80で、認証処理が不合格と判定された場合には、ブロック64に進み、処理手順は中止される。
【0053】
判断ブロック80で、製造者公開鍵の認証処理が合格と判断された場合には、ブロック82に進み、システムブート・ファームウェア証明(CERT_SIG)の認証を行う。ファームウェア証明の認証処理を図5に示す。ブロック84において、認証処理が不合格と判定された場合には、ブロック64に進み、処理手順は中止される。
【0054】
判断ブロック84において、ファームウェア証明の認証が、合格と判定された場合には、ブロック86に進み、発信者の公開鍵(ORIG_PUB_KEY)の認証を行う。発信者の公開鍵の認証処理を図6に示す。ブロック88において、認証処理が不合格と判定された場合には、ブロック64に進み、処理手順は中止される。
【0055】
判断ブロック88において、発信者の公開鍵の認証が、合格と判定された場合には、ブロック90に進み、システムブート・ファームウェアの認証を行う。ファームウェアの認証処理を図7に示す。ブロック92において、認証処理が不合格と判定された場合には、ブロック64に進み、処理手順は中止される。
【0056】
判断ブロック92において、ファームウェア証明の認証が、合格と判定された場合には、ブロック94に進み、DIE識別コードを検証する。図8は、DIE識別コードを検証する手順を示すフローチャートである。ステップ140において、製造者証明36のDIE_IDフィールドが“0”に設定されている場合には、“0”を戻す。そうでない場合には、DIE_IDフィールドを、eFuseメモリ14に格納されているDIE_ID_FUSE値と比較する。この場合には、比較された二つのフィールドの一致、不一致を表す値が戻される。
【0057】
さらに、図3において、DIE_IDフィールドが“0”に設定されている場合には、DIE ID有効状態が戻され、処理手順がブロック96で継続される。
【0058】
DIE_IDフィールドが“0”に設定されておらず、製造者証明36のダイIDがeFuseメモリ14に格納されているDIE_ID_FUSE値と一致しないならば、所定の機能が無効となる。しかし、緊急呼び出し機能など、いくつかの機能は動作可能である。
【0059】
セキュア・ブート・ローダとセキュア・リセット・ブート・チェッカは、製造の時点もしくは改造の際に、有効なファームウェアのみが装置10にロードされていることを確認する。製造者の秘密鍵を用いた暗号化がなければ、システムファームウェアはロードできないため、ユーザあるいは第三者による、格納されたファームウェアの変更あるいは置き換えが防止される。
【0060】
しかし、ファームウェアのインストールが保護されていたとしても、ファームウェアの実行中に、ファームウェアや特定のデータの変更されるのを防止するために、更に他の手段を講じることが必要である。このように付加されるセキュリティ機能によって、実行の特権を変更することにより、装置内に格納されたデータが外部に公開されたり、許可されていないファームウェアから装置10が再利用されることを防止する。
【0061】
装置10の動作中は、システムファームウェアのローディング後に、セキュア・ランタイム・プラットフォーム・データ・チェッカとセキュア・ランタイム・チェッカが、システムソフトウェアが変更されていないことを確認し、システムソフトウェアの製造者証明36のPLATFORM_DATAフィールドに設定が行われていることを確認する。
【0062】
図9は、セキュア・ランタイム・プラットフォーム・データ・チェッカとセキュア・ランタイム・チェッカの動作を示したフローチャートである。セキュア・ランタイム・プラットフォーム・データ・チェッカ200は、製造者証明36のPLATFORM_DATAフィールドに格納された、装置10の特定のデータの変更を防止するものである。セキュア・ランタイム・チェッカ202は、ファームウェアの変更あるいは交換を防止するものである。
【0063】
ステップ204において、セキュア・サービスが起動される。本実施例では、セキュア・サービスの呼び出しは、プロセッサ26の休止する時期が検出された際に行われ、チェッカ200および202は、他のアプリケーションに対する介入を最小限に抑えるようにしている。また、セキュア・サービスは、オンチップのハードウェアタイマによっても起動が可能となっており、休止時期に関わらず、予め定められた時間内にセキュア・サービスの呼び出しが確実に行うことが可能である。この予め定められた時間は、製造者証明36のCONFIG_PARAMフィールドに格納された構成パラメータに従って、ブート時に設定される。また、セキュア・サービスは、ソフトウェア・アプリケーションからの要求に応じても起動が可能となっている。一度、セキュア・サービス呼び出しが起動されると、全ての割り込み処理が禁止され、セキュア・ランタイム・プラットフォーム・データ・チェッカ200とセキュア・ランタイム・チェッカ202を実行するプロセッサは、割り込みを受けず、また、チェッカの処理が完了するまでその実行が中断することはない。
【0064】
セキュア・ランタイム・プラットフォーム・データ・チェッカについて、ステップ206において、図4に示した手順と同様に、製造者証明36に格納された製造者の公開鍵(MAN_PUB_KEY)が認証される。MAN_PUB_KEYの認証により、後に行われる認証ステップで、公開鍵と秘密鍵の組み合わせが偽値で置き換えられることを防止する。
【0065】
ステップ208において、製造者の公開鍵の認証が不合格となった場合には、セキュア・ランタイム・プラットフォーム・データ・チェッカの処理は中止され、ステップ210で、装置はリセットされる。
【0066】
ステップ208において、製造者の公開鍵の認証が合格となった場合には、ステップ212に進み、システムブート・ファームウェア証明の認証が行われる。システムブート・ファームウェア証明の認証は、図5に示した手順と同様に行われる。このステップにより、製造者証明36中のデータ、特に、PLATFORM_DATAフィールドに格納された値に変更が加えられていないことを確認する。
【0067】
ステップ214において、システムブート・ファームウェア証明の認証が不合格となった場合には、セキュア・ランタイム・プラットフォーム・データ・チェッカ200の処理は中止され、ステップ210で、装置はリセットされる。
【0068】
製造者証明のDIE_IDが0に設定されていない場合は、DIE_IDフィールドの値は、eFuseアレイ24に格納されたDIE_ID_FUSEと比較される。両者が一致することが、製造者証明のプラットフォームに関したデータがプラットフォームに属することを保証することになる。製造者証明のDIE_IDが0に設定されている場合は、製造者証明36中のPLATFORM_DATAフィールドと、プラットフォーム証明38のPLATFORM_DATAフィールドの値が一致することが、製造者証明のプラットフォームに関したデータがプラットフォームに属することを保証することになる。
【0069】
ステップ218において、プラットフォームデータの有効状態が、(もしあるとすれば)呼び出し側のソフトウェアに戻される。プラットフォームデータが、期待されるプラットフォームデータと一致しない場合には、装置のなんらかの機能が動作不可とされるが、緊急呼び出しなどのいくつかの機能は動作可能な状態が維持される。
【0070】
ステップ220からステップ240は、セキュア・ランタイム・チェッカ202の動作を示したものである。これらのステップは、各ファームウェアのタスクで実行される。ステップ220では、テスト対象となるファームウェアの製造者証明36に格納された製造者の公開鍵(MAN_PUB_KEY)を、図4に示した方法と同様に、認証する。MAN_PUB_KEYを認証することにより、後に行われる認証ステップで、公開鍵と秘密鍵の組み合わせが偽値で置き換えられることを防止する。
【0071】
ステップ222で、製造者の公開鍵認証が不合格であると判定された場合、もし、(ステップ224に進んで判定を行い)テスト対象のファームウェアがシステムブートファームウェアならば、セキュア・ランタイム・チェッカ202の処理は中止され、ステップ210で、装置はリセットされる。もし、テスト対象のファームウェアがシステムブートファームウェアでないならば、ステップ226で処理を終了する。
【0072】
ステップ222において、製造者の公開鍵認証が合格と判断された場合には、ステップ228に進み、テスト対象のファームウェアのファームウェア証明(SIG_CERT)が認証される。ファームウェア証明の認証は、図5で示した方法と同様に行われる。
【0073】
ステップ230において、ファームウェア証明の認証が不合格と判断された場合には、(ステップ224に進んで判定を行ない)テスト対象のファームウェアがシステムブートファームウェアならば、セキュア・ランタイム・チェッカ202の処理は中止され、ステップ210で、装置はリセットされる。もし、テスト対象のファームウェアがシステムブートファームウェアでないならば、ステップ226で処理を終了する。
【0074】
ステップ230において、ファームウェア証明の認証が合格と判断された場合には、ステップ232に進み、発信者の公開鍵(ORIG_PUB_KEY)の認証を行う。ファームウェアの製造者証明のORIG_PUB_KEYの認証は、図6で示した方法と同様に行われる。
【0075】
ステップ234において、発信者の公開鍵の認証が不合格と判定された場合には、(ステップ224に進んで判定を行ない)テスト対象のファームウェアがシステムブートファームウェアならば、セキュア・ランタイム・チェッカ202の処理は中止され、ステップ210で、装置はリセットされる。もし、テスト対象のファームウェアがシステムブートファームウェアでないならば、ステップ226で処理を終了する。
【0076】
ステップ234において、発信者の公開鍵の認証が合格と判定された場合には、ステップ236に進み、ファームウェアの認証が行なわれる。ファームウェアの認証は、図7に示した方法と同様に行なわれる。
【0077】
ステップ238において、ファームウェアの認証が不合格と判定された場合には、(ステップ224に進んで判定を行ない)テスト対象のファームウェアがシステムブートファームウェアならば、セキュア・ランタイム・チェッカ202の処理は中止され、ステップ210で、装置はリセットされる。もし、テスト対象のファームウェアがシステムブートファームウェアでないならば、ステップ226で処理を終了する。
【0078】
全ての認証テストが合格となった場合には、ステップ240において、DieIDの検証が行なわれる。DieIDの検証は、図8に示した方法と同様に行われる。
【0079】
ステップ242において、DieIDの有効状態が、(もしあるとすれば)呼び出し側のソフトウェアに戻される。DIE_IDフィールドが“0”に設定されておらず、製造者証明36のDieIDの値が、eFuseアレイ24に格納されたDIE_ID_FUSEの値と一致しない場合は、装置のなんらかの機能が動作不可とされるが、緊急呼び出しなどのいくつかの機能は動作可能な状態が維持される。
【0080】
チェッカのタスク200および202が完了した後、ファームウェアのテストが合格となった場合には、以前からの処理は、停止位置から再開され、割り込みが再度可能となる状態となる。
【0081】
ファームウェアの動作中に、ファームウェアとプラットフォームのデータ認証を行なうことにより、ファームウェアの起動後にファームウェアの置き換え行為を検知し、それを防止することが可能となる。チェッカのタスク200および202を実行する前後に、プロセッサの状態を管理することにより、システムを再度初期化することなく、これらのタスクの実行が可能とすることができる。
【0082】
図10は、プラットフォーム証明38をアプリケーションファイル32あるいはデータファイル34に関連付けを示した図である。表2は、プラットフォーム証明の一実施例におけるフィールドを列挙したものである。
【表2】
【0083】
プラットフォーム証明38は、eFuseメモリ14に格納されたKEKを利用する。本実施例では、KEKは、製造時にオンチップで生成された乱数であり、KEKの値は、誰にも知られないようになっている。eFuseメモリ14に格納されたKEKは、I/Oポートによっても、あるいはアプリケーションソフトウェアによってもアクセスできないようになっている。各チップのKEKは、他のプログラムによって外部から決定されたり検知されることができないように用いられることが望ましい。KEKはeFuseメモリ14に格納されているため、ヒューズメモリの融解状態を物理的に検出することによりKEKを求めることができるが、このような検出は、チップ自身を破壊することによってのみ可能となる。各チップは個別にKEKを生成するため、一つのチップのKEKが知られたからといって、他のチップのセキュリティを脅かすことにはならない。
【0084】
KEKは、装置の動作中に、ランダムに生成される他のソフトウェア鍵を暗号化するために用いられる。図9に示すように、(ハードウェアあるいはソフトウェアのいずれかの形態で実装することが可能な)乱数発生器250は、必要に応じ、ランダムソフトウェア鍵(SW_KEY)を生成する。このように、各アプリケーションには、異なるソフトウェア鍵を付与することが可能となる。ステップ252において、KEKを用いてSW_KEYは暗号化され、ENC_SW_KEYとしてプラットフォーム証明38に格納される。ENC_SW_KEYは、KEKを用いてのみ暗号解読が可能であり、KEKは秘密であり、チップ内部に格納されているため、ENC_SW_KEYは、KEKにアクセスするアプリケーションによってのみ暗号解読が可能である。従って、ROM中のシステムソフトウェアのみが、KEKにアクセス可能となる。
【0085】
プラットフォーム証明38中の他のセキュリティ値は、SW_KEYを用いて暗号化される。証明の一部ではないが、アプリケーションファイル32あるいはデータファイル34は、暗号化ステップ254および256に示した機密保持要求に応じて、オプションとして、SW_KEYによって暗号化される。アプリケーションファイル32あるいはデータファイル34が暗号化されるか、されないかは、ソフトウェア署名(SW_SIG)あるいは署名証明(SIG_CERT)にも影響を与える。ステップ258において、ソフトウェアファイル32あるいはデータファイルは(暗号化はオプションとなるが)ハッシングされ、ステップ260において、SW_KEYを用いて暗号化される。この値は、SW_SIGとして格納される。ステップ262において、証明フィールドはハッシングされ、ステップ264において、SW_KEYにより暗号化される。この値は、SIG_CERTとして格納される。
【0086】
プラットフォーム証明は、アプリケーションあるいはデータファイルを、それがロードされる装置10に関連付けを行なう。一度関連付けが行なわれると、プラットフォーム証明は無効となり、アプリケーションあるいはデータファイルは、他の装置へは移動することができなくなる。さらに、アプリケーションファイル32あるいはデータファイル34を、特定のプログラムに関連付けるために、APPLI_IDフィールドが用いられる。たとえオーディオあるいはビデオファイルが、様々なアプリケーションで再生可能な標準形式のものであったとしても、例えば、オーディオあるいはビデオファイルのみを、特定のメディア再生アプリケーションに関連付けるために、これが用いられる。
【0087】
図11は、アプリケーションあるいはデータファイルをアプリケーションで実行するために必要となるプラットフォーム証明に対して、アプリケーションあるいはデータファイルの関連付けを解除する処理を示すものである。ステップ270において、eFuseメモリ14に格納されたKEKを用いて、プラットフォーム証明38のENC_SW_KEYから、SW_KEYを求める。SW_KEYを用いて、ステップ272において、プラットフォーム証明38のSIG_CERTフィールドを暗号解読し、ステップ274において、SW_SIGフィールドを暗号解読する。
【0088】
ステップ276において、プラットフォーム証明38のSIG_CERT以外のフィールドをハッシングする。ステップ278において、ハッシングした結果を、暗号解読されたSW_CERTフィールドの値と比較する。同様に、ステップ280において、格納されたアプリケーションあるいはデータファイルをハッシングし、ステップ282において、ステップ274で暗号化されたSW_SIGと比較される。ステップ278での比較、あるいはステップ300での比較のいずれかが不一致となった場合には、ステップ302において、システムエラーが発行される。そうでない場合には、ステップ304および306でオプションとしての暗号解読の後、アプリケーションが実行される(もしくは、データファイルがアプリケーションで利用される)。
【0089】
プラットフォーム証明は、従来例に対して、大きな利点をもたらすものである。ソフトウェアあるいはデータファイルを、装置10に関連付けることにより、元のソフトウェアモジュールが変更されたことを明らかにし、ソースプログラムがコピーされ、ほかのプラットフォームで実行されることを防止でき、クローンによる攻撃に対する効果的な保護を提供し、特に、重要なこととして、著作権管理と媒体の保護を可能とする。
【0090】
本方式は、一方向ハッシングおよびバルク暗号化など、プラットフォーム署名と検証に対する強力な暗号化技術に基づいたものであるため、高レベルのセキュリティを提供するものとなる。本方式は、任意のコンピュータ・ハードウェア・プラットフォームに対して、容易に適用することが可能である。KEKと、関連付けの際にランダムに生成されたソフトウェア鍵とを用いることにより、外部メモリ中の暗号化鍵を外部に格納することが可能となる。無制限数の異なるソフトウェア鍵を、アプリケーションおよびデータファイルに用いることができる。さらに、署名の計算のために、対称性のあるバルク暗号化技術を用いることにより、非対称な暗号化技術に比べ、計算機の処理負荷を削減することが可能となる。
【0091】
図12は、セキュリティを保ちながら、外部メモリ中のIMEI(国際携帯機器識別)番号を格納するための、製造者および、あるいはプラットフォーム証明の特別な利用方法を示したものである。IMEI番号は、UMTS(欧州の第3世代移動体通信システム)標準規格、第5版で規定され、電話のクローンと旧規格や不適合の利用者機器に対して、電話の製造者と運用者の両者を保護するためのものである。IMEI番号は、携帯電話のどこかに格納され、要求に応じて供用されるネットワークに送り出される必要がある。(ハードウェア、ソフトウェアあるいは物理的な)何らかの手段による改ざんに対して、IMEI番号を保護することは、モバイル機器に求められるセキュリティレベルを大いに向上させてきた。改ざんを防止するために、多くの製造者は、製造プロセスの最後に、個々の電話に一意となるIMEI番号を、チップに格納してきた。しかし、改ざん防止となるようにチップ上に番号を格納することは、コストのかかるものである。
【0092】
図12に示すように、IMEIは、各電話ごとにカストマイズされた製造者証明(特に、PLATFORM_DATAフィールド)に記された外部メモリ、および、あるいは、プラットフォーム証明に関連付けられた外部メモリに格納されている。ベースバンド処理システム12は、システムブート・ファームウェアの製造者証明36、あるいは、プラットフォーム証明38に関連付けられたメモリ位置のいずれかから、外部メモリ中のIMEIにアクセスする。
【0093】
IMEI番号が、製造者証明36のPLATFORM_DATAフィールドで変更された場合、その変更は、システムブート・ソフトウェアの実行に先立ち、セキュア・リセット・ブート・チェッカにより検出される。もし、システムブート・ソフトウェアがロードされた後で変更された場合には、IMEI番号の変更は、セキュア・ランタイム・プラットフォームデータ・チェッカにより検出される。
【0094】
もし、IMEIが、プラットフォーム証明に関連付けられた外部メモリに格納されている場合には、IMEI番号の変更は、無効なSW_SIGとして検出される。プラットフォーム証明を用いて、IMEIは、外部メモリの任意の位置に格納することができる。
【0095】
装置10をプログラムすることにより、たとえ、IMEIが無効な製造者証明36あるいは無効なプラットフォーム証明38をもたらした場合でも、緊急呼び出しが可能となる。
【0096】
図13は、装置10の動作を制御するために、製造者証明36のフィールドを用いる処理を示すブロック図である。図13に示すように、製造者証明36のDEBUG_REQフィールドを用いて、テストアクセスおよびエミュレーション回路320を制御する。製造者証明36のCONF_PARAMフィールドのパラメータを用いて、ブロック332および324で示すように、ハードウェアあるいはソフトウェアを適切に構成することにより、装置10の動作の様々な状態を制御することができる。
【0097】
システムの動作中は、システムブート・ソフトウェアが、製造者証明中の構成パラメータにアクセスし、ハードウェアおよびソフトウェア資源を構成する。製造者証明36中に構成パラメータを配置することにより、製造者は、柔軟なハードウェアおよび、あるいはソフトウェア構成を有する装置を設計し、安全にセキュリティを確保しながら適切に装置を構成することが可能となる。
【0098】
セキュリティを確保しながら構成パラメータを製造者証明36に格納する第一の利用には、装置10に対して、管理された状況で構成を入力することを可能とすることがあげられるが、ここでは、構成によっては、装置10が攻撃に対して無防備な状況にさらしてしまう場合がある。例えば、テストモードの間、装置10は、通常は隠されたメモリ位置が、読み出しおよび、あるいは書き込みを許すような構成状態に置かれることもある。また、メモリ性能設定、バス速度、処理速度などのハードウェアパラメータが、システム動作を分析するために、テストモードの間に変更が可能とされることもある。
【0099】
セキュリティを確保しながら構成パラメータを製造者証明36に格納する第二の利用では、装置10の性能を制御することがあげられる。計算機産業ではよく知られているように、装置を限界性能まで到達させようとして、装置のハードウェアおよび、あるいはソフトウェアのパラメータを、ユーザ自身が再構成する場合がある。例えば、多くのユーザにより、プロセッサが動作するシステムクロック速度あるいは複数のシステムクロックを変化させ、パソコンのプロセッサ速度の“オーバークロック”を行なう場合がある。さらに、メモリアクセスおよびスループットを向上させるために、メモリ設定を変更することもありうる。確かに、オーバークロックは、計算機装置の性能を向上させることが可能であるが、それにより、ハードウェアをその仕様温度を上回る温度で動作させることにより、ハードウェアの寿命を短くしてしまうこともある。さらに、計算機装置は、オーバークロック設定では、誤動作する可能性もある。このように、オーバークロック設定は、保証とサポートの観点からは、製造者にとってコストのかかる面をもっている。
【0100】
製造者証明36でパラメータを設定することにより、性能設定に対する変更の試みを防止することができる。これは、性能設定は、製造者証明36で定義され、製造者の許可の元でのみ変更が可能となるためである。システムブート・ソフトウェアは、定義されたパラメータにリセットされた後、装置を構成する。証明で許可された設定を変更しようとする試みは、(リセット後の)セキュア・リセット・ブート・チェッカ52あるいはセキュア・ランタイム・チェッカ202によって、検出される。システムファームウェアの外にあるソフトウェアにより、構成パラメータを変更しようとする試みは、セキュア・ランタイム・プラットフォーム・データ・チェッカ200によって、検出される。
【0101】
セキュリティを確保しながら構成パラメータを製造者証明36に格納する第三の利用では、異なる性能および、あるいは異なる機能性に対する設定を有する単一の装置を提供することがあげられる。装置は、製造者証明36に格納された構成設定に基づき販売され、その構成は、ユーザあるいは第三者によって変更できないようにしたものである。装置10は、製造者により、容易にアップグレード可能である。
【0102】
例えば、携帯型の計算機装置プラットフォームは、複数のプロセッサ速度で動作し、無線ネットワーク、オーディオおよびビデオ機能のような、異なるオプションの機能性を有するように設計することが可能となっている。装置は、PCカードやメモリポートの拡張などの高価なハードウェアアップグレードではなく、後日、アップグレード可能となるように、所望の構成を持たせて販売される。
【0103】
図14は、図13の変形であり、構成データは、プラットフォーム証明で保護されたデータファイル34に格納されている。構成パラメータを格納したデータファイル34を変更させようとする試みは、システムファームウェアによって検出される。セキュア・ランタイム・プラットフォーム・データ・チェッカ200は、装置の動作中に、データファイルの内容をチェックするように、変更されている。
【0104】
図15は、テストモードなどのモードで装置10にアクセスするための他の設計を示したものである。この設計では、アクセスコードのハッシュ(H_Test_ID)を格納する。このコードは、eFuseメモリ24に格納されている。テストモードにアクセスするため、第三者は、アクセスコード(Input_Test_ID)を入力する必要がある。ブロック330において、Input_Test_IDはハッシングされ、ブロック332において、H_Test_IDと比較される。ブロック330でハッシングされたアクセスコードが、格納されたハッシングされたアクセスコードと一致した場合には、このモードへのアクセスが可能となる。
【0105】
システムの動作中は、H_Test_IDは、通常は、Input_Test_IDに比べて極めて小さな長さを持つため、アクセスコードを格納するために必要な格納領域を削減することが可能となる。しかし、所望のモードに入るためには、第三者は、より大きな数を必要とする。複数の入力をハッシングして、H_Test_IDに一致させるものを得ることは可能ではあるが、SHA−1あるいはND5などの現在のハッシングアルゴリズムを用いて、不当に入力されたアクセスコードが一致する結果を生み出すことは、統計的な観点からはありえないことである。
【0106】
さらに、図15の設計は、さらにセキュリティ上の利点をもたらすものとなっている。格納されたハッシング結果、H_Test_IDが知られてしまった場合でも、ハッシングすることによりH_Test_IDを得るような入力コードを決定することは、計算機処理の観点からは困難なものとなっている。
【0107】
テストモードへのアクセスについて、ハッシングされたアクセスコードを用いることを説明したが、これは、上述したように、システムパラメータを変更するためのアクセスなど、任意の状況でセキュリティを確保することに適用することが可能である。
【0108】
本発明の詳細な説明を、一例となる実施例に対して行なってきたが、これらの実施例の様々な変形や、他の実施例は、当業者であれば思いつくものである。本発明は、クレームの範囲内であれば、任意の変形や代わりの実施例を包含したものとなっている。
【図面の簡単な説明】
【0109】
【図1】図1は、移動型計算機環境のファームウェア、アプリケーションソフトウェアおよびデータを保護するために用いられる様々な保護機構を示す基本ブロック図である。
【図2】図2は、図1に示した製造者証明のための一実施例を示す図である。
【図3】図3は、セキュア・ブート・ローダおよびセキュア・ブート・チェッカ・プログラムでの、製造者証明の利用を示すフローチャートである。
【図4】図4は、製造者証明に格納された製造者の公開鍵の認証処理を示すフローチャートである。
【図5】図5は、製造者証明の証明署名フィールドの認証処理を示すフローチャートである。
【図6】図6は、製造者証明の発信者の公開鍵フィールドの認証処理を示すフローチャートである。
【図7】図7は、製造者証明に関連付けられたファームウェアの認証処理を示すフローチャートである。
【図8】図8は、製造者証明のDIE識別コードの検証処理を示すフローチャートである。
【図9】図9は、セキュア・ランタイム・プラットフォーム・データ・チェッカとセキュア・ランタイム・チェッカの動作を示すフローチャートである。
【図10】図10は、プラットフォーム証明による、アプリケーションファイルあるいはデータファイルの計算機プラットフォームへの関連付けを示す図である。
【図11】図11は、アプリケーション内でアプリケーションの実行あるいはデータファイルの利用に必要な、アプリケーションあるいはデータファイルのプラットフォーム証明からの関連付けの解除を示す図である。
【図12】図12は、セキュリティを確保してIMEI(内部移動機器識別)番号を外部メモリに格納するための、製造者および、あるいはプラットフォーム証明の特定利用を示す図である。
【図13】図13は、装置の動作を制御するために、製造者証明のフィールドを利用するブロック図である。
【図14】図14は、プラットフォーム証明によって保護されたデータファイル中に構成データを格納した、図13のブロック図の変更例を示す図である。
【図15】図15は、装置10へのアクセスのための他の設計例を示す図である。
【特許請求の範囲】
【請求項1】
計算機装置の資源へのアクセスのセキュリティを確保する方法であって、
計算機装置の既知のメモリ位置に、暗号化されたアクセスコードを格納するステップと、
資源にアクセスするために、パスワードを受取るステップと、
暗号化パスワードを生成するために、パスワードを暗号化するステップと、
暗号化パスワードと、暗号化されたアクセスコードとを比較するステップと、
暗号化されたアクセスコードが暗号化パスワードに一致した場合に、資源へのアクセスを許可するステップとを含む、方法。
【請求項2】
請求項1記載の方法において、暗号化されたアクセスコードを格納するステップは、ハッシュされたアクセスコードを格納するステップを含む、方法。
【請求項3】
請求項2記載の方法において、パスワードを暗号化するステップは、パスワードをハッシュするステップを含む、方法。
【請求項4】
請求項1記載の方法において、暗号化されたアクセスコードは、外部から変更が不可能なメモリに格納される、方法。
【請求項5】
請求項1記載の方法において、アクセスを許可するステップは、暗号化されたアクセスコードが、暗号化パスワードと一致した場合に、資源をテストする処理にアクセスを許可するステップを含む、方法。
【請求項6】
請求項1記載の方法において、アクセスを許可するステップは、暗号化されたアクセスコードが、暗号化パスワードと一致した場合に、システムパラメータの変更を許可するステップを含む、方法。
【請求項7】
処理システムと、
暗号化されたアクセスコードを格納するためのメモリと、
資源にアクセスするためのパスワードを受取るための入力回路とを含む計算機装置であって、
処理回路は、
暗号化パスワードを生成するために、パスワードを暗号化し、
暗号化パスワードと、暗号化されたアクセスコードとを比較し、
暗号化されたアクセスコードが、暗号化パスワードと一致した場合に、資源へのアクセスを許可する、計算機装置。
【請求項8】
請求項7記載の計算機装置において、暗号化されたアクセスコードは、ハッシュされたアクセスコードを含む、計算機装置。
【請求項9】
請求項8記載の計算機装置において、暗号化パスワードは、ハッシュされたパスワードを含む、計算機装置。
【請求項10】
請求項7記載の計算機装置において、暗号化されたアクセスコードは、外部から変更が不可能なメモリに格納される、計算機装置。
【請求項11】
請求項7記載の計算機装置において、暗号化されたアクセスコードが、暗号化パスワードと一致した場合に、処理システムが、資源をテストする処理にアクセスを許可する、計算機装置。
【請求項12】
請求項7記載の計算機装置において、暗号化されたアクセスコードが、暗号化パスワードと一致した場合に、処理システムが、システムパラメータへのアクセスを許可する、計算機装置。
【請求項1】
計算機装置の資源へのアクセスのセキュリティを確保する方法であって、
計算機装置の既知のメモリ位置に、暗号化されたアクセスコードを格納するステップと、
資源にアクセスするために、パスワードを受取るステップと、
暗号化パスワードを生成するために、パスワードを暗号化するステップと、
暗号化パスワードと、暗号化されたアクセスコードとを比較するステップと、
暗号化されたアクセスコードが暗号化パスワードに一致した場合に、資源へのアクセスを許可するステップとを含む、方法。
【請求項2】
請求項1記載の方法において、暗号化されたアクセスコードを格納するステップは、ハッシュされたアクセスコードを格納するステップを含む、方法。
【請求項3】
請求項2記載の方法において、パスワードを暗号化するステップは、パスワードをハッシュするステップを含む、方法。
【請求項4】
請求項1記載の方法において、暗号化されたアクセスコードは、外部から変更が不可能なメモリに格納される、方法。
【請求項5】
請求項1記載の方法において、アクセスを許可するステップは、暗号化されたアクセスコードが、暗号化パスワードと一致した場合に、資源をテストする処理にアクセスを許可するステップを含む、方法。
【請求項6】
請求項1記載の方法において、アクセスを許可するステップは、暗号化されたアクセスコードが、暗号化パスワードと一致した場合に、システムパラメータの変更を許可するステップを含む、方法。
【請求項7】
処理システムと、
暗号化されたアクセスコードを格納するためのメモリと、
資源にアクセスするためのパスワードを受取るための入力回路とを含む計算機装置であって、
処理回路は、
暗号化パスワードを生成するために、パスワードを暗号化し、
暗号化パスワードと、暗号化されたアクセスコードとを比較し、
暗号化されたアクセスコードが、暗号化パスワードと一致した場合に、資源へのアクセスを許可する、計算機装置。
【請求項8】
請求項7記載の計算機装置において、暗号化されたアクセスコードは、ハッシュされたアクセスコードを含む、計算機装置。
【請求項9】
請求項8記載の計算機装置において、暗号化パスワードは、ハッシュされたパスワードを含む、計算機装置。
【請求項10】
請求項7記載の計算機装置において、暗号化されたアクセスコードは、外部から変更が不可能なメモリに格納される、計算機装置。
【請求項11】
請求項7記載の計算機装置において、暗号化されたアクセスコードが、暗号化パスワードと一致した場合に、処理システムが、資源をテストする処理にアクセスを許可する、計算機装置。
【請求項12】
請求項7記載の計算機装置において、暗号化されたアクセスコードが、暗号化パスワードと一致した場合に、処理システムが、システムパラメータへのアクセスを許可する、計算機装置。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【公表番号】特表2007−535015(P2007−535015A)
【公表日】平成19年11月29日(2007.11.29)
【国際特許分類】
【出願番号】特願2006−520365(P2006−520365)
【出願日】平成16年7月14日(2004.7.14)
【国際出願番号】PCT/US2004/022890
【国際公開番号】WO2005/019974
【国際公開日】平成17年3月3日(2005.3.3)
【出願人】(501229528)テキサス インスツルメンツ インコーポレイテッド (111)
【Fターム(参考)】
【公表日】平成19年11月29日(2007.11.29)
【国際特許分類】
【出願日】平成16年7月14日(2004.7.14)
【国際出願番号】PCT/US2004/022890
【国際公開番号】WO2005/019974
【国際公開日】平成17年3月3日(2005.3.3)
【出願人】(501229528)テキサス インスツルメンツ インコーポレイテッド (111)
【Fターム(参考)】
[ Back to top ]