メモリカードコントローラファームウェアのハードウェアドライバ完全性チェック
【課題】カード上で常時実行するファームウェアの完全性および信頼性の両方を確実にする。
【解決手段】メモリシステム１０のフラッシュメモリ２０内に前記メモリシステム１０のファームウェアを設け、前記ファームウェアを前記メモリシステム１０のハードウェアで実施される暗号化エンジン４０に通し、前記ファームウェアについてのハッシュ値を前記ハードウェアで実施される暗号化エンジン４０で計算し、計算されたハッシュ値を記憶されたハッシュ値と比較し、前記計算されたハッシュ値が前記記憶されたハッシュ値と一致する場合に、前記ファームウェアを実行する。
【解決手段】メモリシステム１０のフラッシュメモリ２０内に前記メモリシステム１０のファームウェアを設け、前記ファームウェアを前記メモリシステム１０のハードウェアで実施される暗号化エンジン４０に通し、前記ファームウェアについてのハッシュ値を前記ハードウェアで実施される暗号化エンジン４０で計算し、計算されたハッシュ値を記憶されたハッシュ値と比較し、前記計算されたハッシュ値が前記記憶されたハッシュ値と一致する場合に、前記ファームウェアを実行する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的には、安全なコンテンツを有するメモリカードおよび当該コンテンツの暗号化に関し、特に、安全なメモリカードを実行するファームウェアの完全性(integrity) をベリファイすることに関する。
【背景技術】
【０００２】
商用のメモリカードの機能を工場から出荷する前にベリファイし、工場から出荷されてもハッカーから保護されていることを確実にすることは、極めて重要である。デジタル権利管理の出現と、音楽および映画などの保護されたコンテンツの普及とに伴い、カードのコンテンツが自由にコピーできないことを確実にする必要がある。ハッカーがこれを行おうと試みるやり方の１つとして、カード内のコンテンツを無断使用することができるようにするために、メモリカードを実行するファームウェアを変更または取り替えさえするということがある。よって、カード上で常時実行するファームウェアの完全性および信頼性の両方を確実にするシステムを提供することが不可欠である。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】米国特許出願第１１／０５３，２７３号
【非特許文献】
【０００４】
【非特許文献１】シーラ・フランケルによる「ＲＦＣ３５６６−ＡＥＳ−ＸＣＢＣ−ＭＡＣ−９６アルゴリズムおよびＩＰｓｅｃを伴うその使用」
【非特許文献２】ジャナカ・ディーパクマラ、ハワード・Ｍ・ヘイズおよびＲ・ベンカテザンによる「インターネットプロトコルセキュリティ（ＩＰＳＥＣ）のためのメッセージ認証コード（ＭＡＣ）アルゴリズムの性能比較」
【非特許文献３】ネバダ大学のジョン・ブラック、カリフォルニア大学デービス校のフィリップ・ロガウェイによる「ＡＥＳ動作モードに関するＮＩＳＴに対するコメント：ＣＢＣ ＭＡＣを使用する任意長メッセージのハンドリングについての提言」
【発明の概要】
【０００５】
ファームウェアの完全性をベリファイすることは、安全かつ信頼性のあるメモリカードを実行するのに重要な態様の１つである。本発明は、メモリカード、ユニバーサル・シリアル・バス（ＵＳＢ）フラッシュドライブ、または他のメモリシステムを実行するファームウェアの完全性をベリファイする。ファームウェアの完全性は、実行される前にベリファイされる。これにより、工場のファームウェアではないファームウェアの実行が防止される。このことが特に重要なのは、コンテンツが自由にコピーされないように保護することを意図した暗号化アルゴリズムを含むセキュリティ機構を、工場のファームウェアが備えているからである。本発明は、メモリカードにおいて実施される場合に、工場以外のファームウェア、または安全なコンテンツのコピーを許可するような変更された工場のファームウェアをカードが実行することを防止する。よって、ハッカーは、カードを「騙して(trick) 」間違ったファームウェアを実行させるようにすることができなくなる。ベリファイ処理は、任意の記憶データの完全性をベリファイするためにも使用することができる。
【０００６】
本発明の一態様は、メモリ記憶装置の動作を開始するための方法に関し、装置の大容量記憶ユニット内にファームウェアを提供するステップと、ファームウェアを暗号化エンジンに通すステップと、ファームウェアについてのハッシュ値を前記暗号化エンジンで計算するステップと、計算されたハッシュ値を記憶されたハッシュ値と比較するステップと、計算されたハッシュ値が記憶されたハッシュ値と一致する場合に、ファームウェアを実行するステップと、を含む。
【０００７】
本発明の他の態様は、大容量記憶装置に関し、フラッシュメモリと、読み出し専用メモリと、フラッシュメモリに記憶された、大容量記憶装置のデータ記憶動作を制御する第１の命令セットと、第１の命令セットをフラッシュから実行可能なランダムアクセスメモリへのシャドウイングする、読み出し専用メモリ内に常駐する第２の命令セットと、を備える。暗号化エンジンが、大容量記憶装置のハードウェア回路において実施され、フラッシュメモリに記憶されるおよびそこから読み出されるデータを暗号化および復号化することができる。暗号化エンジンは、第１の命令セットの完全性をベリファイするように動作可能である。
【０００８】
本発明のさらに他の態様は、メモリ記憶装置の動作を開始するための他の方法に関する。この方法は、装置の大容量記憶ユニット内にファームウェアを提供するステップと、ファームウェアを大容量記憶ユニットからランダムアクセスメモリへコピーする、読み出し専用メモリ内の第１の命令セットを実行するステップと、を含む。また、この方法は、暗号化エンジンを使用してブートファームウェアの完全性をベリファイするステップと、完全性がベリファイされた後に、ランダムアクセスメモリからファームウェアをマイクロプロセッサで実行するステップと、を含む。
【０００９】
本発明のさらなる態様、利点、および特徴は、以下の例示の例の説明に含まれ、その説明は、添付の図面と共に解釈されるべきであり、同様の参照番号は、特に指示のない限り、全ての図を通じて同一の特徴を説明するために使用される。本願明細書において援用されているすべての特許、特許出願、記事、および他の出版物は、あらゆる目的のためにその全体が本願明細書において参照により援用されている。
【図面の簡単な説明】
【００１０】
【図１Ａ】本発明の一実施形態によるシステム１０の概略図である。
【図１Ｂ】本発明の他の実施形態によるシステム１０の概略図である。
【図２】図１に示すフラッシュメモリのメモリ図である。
【図３】ブートローダ２００ａの概略図である。
【図４】ファームウェアのハードウェアベースの完全性チェックを含むブート処理の部分のフローチャートである。
【図５】図４の完全性ベリファイ処理４１０のフローチャートである。
【図６】ブート中のハードウェアループのフローチャートである。
【図７】ブート中のファームウェアループのフローチャートである。
【発明を実施するための形態】
【００１１】
メッセージ認証コード（ＭＡＣ）は、何らかのコンテンツ（または、メッセージ）から計算されるコンテンツの完全性を証明するために使用される数である。その目的は、コンテンツが変更されたかどうかを検出することである。メッセージ認証コードは、メッセージおよび何らかの秘密データから計算されるハッシュである。秘密データを知らなければ、偽造することは困難である。ＭＡＣは、秘密鍵を使用するＤＥＳまたはＡＥＳ暗号に基づくアルゴリズムを使用して計算される。その後、ＭＡＣは、メッセージと共に記憶または送られる。受信者は、同一のアルゴリズムおよび秘密鍵を使用してＭＡＣを再計算し、それを記憶または送られたものと比較する。それらが同一であれば、コンテンツまたはメッセージは改変されていないものとされる。
【００１２】
ＤＥＳ（データ暗号化標準）は、５６ビットキーを使用するＮＩＳＴ標準の暗号化暗号である。ＮＩＳＴによって１９７７年に採用されたが、２００１年にはＡＥＳが公式標準として取って代わった。ＤＥＳは、４つの異なる動作モードにおける６４ビットのブロックを処理する対称ブロック暗号であって、電子コードブック（ＥＣＢ）が最も一般的である。
【００１３】
トリプルＤＥＳは、いくつかの複数パス方法を追加することによって安全性を増強した。例えば、１つの鍵で暗号化し、その結果を第２の鍵で復号化し、それを再び第３の鍵で暗号化する。しかし、追加のパスは、多大な計算時間を処理に追加する。ＤＥＳは、最強のセキュリティを必要としないアプリケーションにおいて今でも使用されている。
【００１４】
改良形暗号化標準（Advanced Encryption Standard（「ＡＥＳ」））は、ＮＩＳＴ標準の暗号化暗号であって、１２８ビットのブロック長と、１２８，１９２，または２５６ビットのキー長とを使用する。２００１年にトリプルＤＥＳ方法に公式に取って代わったＡＥＳは、ベルギーのヨアン・ダーメン (Joan Daemen)およびビンセント・ライメン (Vincent Rijmen) によって開発されたラインダールアルゴリズムを使用する。ＡＥＳは、３つに変わって１つのパスで暗号化でき、そのキーサイズは、トリプルＤＥＳの１６８ビットより大きい。
【００１５】
セキュアハッシュアルゴリズム（ＳＨＡ−１）は、２０バイトの出力を生じさせる。ＮＩＳＴおよびＮＳＡは、これをデジタル署名標準と共に使用するように設計し、現在幅広く使用されている。ＭＤ５は、本発明と共に使用されるような他のハッシュ関数である。前述した標準および様々な他のアルゴリズムは、本発明と共に使用されるようなハッシュ関数および値の例示的な例である。今日利用可能かつ将来開発される他の形のハッシュ関数および値も、本発明と共に使用できる。
【００１６】
前述した規格および様々な他のアルゴリズムおよび／または標準は、暗号化技術における当業者に周知であるが、以下の出版物は有益であり、その全体が本願明細書において参照により援用されている。これら出版物とは、シーラ・フランケル (Sheila Frankel) による「ＲＦＣ３５６６−ＡＥＳ−ＸＣＢＣ−ＭＡＣ−９６アルゴリズムおよびＩＰｓｅｃを伴うその使用 (RFC3566-The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec) 」，アメリカ合衆国、メリーランド、２０８９９、ゲイザースブルグ、８２０ ウエスト・ダイアモンド・アベニュー、ルーム ６７７にあるＮＩＳＴ−国立標準技術研究所 (National Institute of Standards and Technology), (http://www.faqs.org/rfcs/rfc3566.html において利用可能）（非特許文献１）、ジャナカ・ディーパクマラ (Janaka Deepakumara) 、ハワード・Ｍ・ヘイズ (Howard M. Heys) およびＲ・ベンカテザン (R. Venkatesan)による「インターネットプロトコルセキュリティ（ＩＰＳＥＣ）のためのメッセージ認証コード（ＭＡＣ）アルゴリズムの性能比較 (Performance Comparison of Message Authentication Code (MAC) Algorithms for the Internet Protocol Security (IPSEC))」，電気およびコンピュータエンジニアリング(Electrical and Computer Engineering) ，ニューファンドランドのメモリアル大学（カナダ、Ａ１Ｂ３Ｓ７、ニューファンドランド、セント・ジョンズ）, http://www.engr.mun.ca/~howard/PAPERS/necec_2003b.pdf （非特許文献２）、およびリノにあるネバダ大学のジョン・ブラック (John Black) 、カリフォルニア大学デービス校のフィリップ・ロガウェイ (Philip Rogaway) による「ＡＥＳ動作モードに関するＮＩＳＴに対するコメント：ＣＢＣ ＭＡＣを使用する任意長メッセージのハンドリングについての提言 (Comments to NIST concerning AES Modes of Operations: A Suggestion for Handling Arbitrary-Length Messages with the CBC Mac)」，(http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/xcbc-mac/xcbc-mac-spec.pdfにおいて利用可能）（非特許文献３）である。
【００１７】
メモリシステムアーキテクチャ
本発明の様々な態様が実施されるようなメモリシステム例を、図１Ａのブロック図に示す。図１Ａに示すように、メモリシステム１０は、中央処理装置（ＣＰＵ）または「コントローラ」１２と、バッファ管理ユニット（ＢＭＵ）１４と、ホストインターフェイスモジュール（ＨＩＭ）１６と、フラッシュインターフェイスモジュール（ＦＩＭ）１８と、フラッシュメモリ２０と、周辺アクセスモジュール２２とを含む。メモリシステム１０は、ホストインターフェイスバス２６およびポート２６ａとを通じてホスト装置２４と通信する。フラッシュメモリ２０は、ＮＡＮＤ形であってもよく、ホスト装置２４に対してデータ記憶を提供する。ＣＰＵ１２のためのソフトウェアコードも、フラッシュメモリ２０に記憶されてもよい。ＦＩＭ１８は、フラッシュインターフェイスバス２８を通じて、および、場合によってはフラッシュメモリ２０が着脱可能な要素であるときには図に示さないポートとを通じて、フラッシュメモリ２０に接続する。ＨＩＭ１６は、デジタルカメラ、パーソナルコンピュータ、個人用携帯情報端末（ＰＤＡ）、ＭＰ−３プレーヤ、携帯電話、または他のデジタル装置のようなホストシステムに対する接続に適している。周辺アクセスモジュール２２は、ＣＰＵ１２と通信するために、ＦＩＭ、ＨＩＭ、およびＢＭＵなどの適切なコンローラモジュールを選択する。一実施形態において、点線のボックス内のシステム１０のすべての要素が、メモリカードなどの単一のユニット、好ましくはカード内に密封されていてもよい。
【００１８】
バッファ管理ユニット１４は、ホスト直接メモリアクセスユニット（ＨＤＭＡ）３２と、フラッシュ直接メモリアクセスユニット（ＦＤＭＡ）３４と、アービタ３６と、ＣＰＵバスアービタ３５と、レジスタ３３と、ファームウェア完全性回路（ＦＷＩＣ）３１と、バッファランダムアクセスメモリ（ＢＲＡＭ）３８と、暗号化エンジン(encryption engine) とも称される暗号エンジン(crypto engine) ４０とを備える。アービタ３６は、１つのマスタまたはイニシエータ（ＨＤＭＡ３２、ＦＤＭＡ３４、またはＣＰＵ１２であってもよい）だけが任意のときにアクティブであることができ、かつ、スレーブまたはターゲットはＢＲＡＭ３８であるような共有バスアービタである。アービタは、適切なイニシエータの要求をＢＲＡＭ３８へ振り向ける役割を担う。ＨＤＭＡ３２およびＦＤＭＡ３４は、ＨＩＭ１６、ＦＩＭ１８、およびＢＲＡＭ３８またはＲＡＭ１１間で搬送されるデータを担当する。ＣＰＵバスアービタ３５は、例えば暗号エンジンを迂回したい場合のような所定の状況において使用されるシステムバス１５を通じた暗号エンジン４０およびフラッシュＤＭＡ３４からＲＡＭ１１への直接データ搬送を可能にする。ＨＤＭＡ３２の動作およびＦＤＭＡ３４の動作は従来どおりであり、本願明細書において詳述する必要はない。ＢＲＡＭ３８は、ホスト装置２４およびフラッシュメモリ２０間を通るデータを記憶するために使用される。ＨＤＭＡ３２およびＦＤＭＡ３４は、ＨＩＭ１６／ＦＩＭ１８およびＢＲＡＭ３８またはＣＰＵ ＲＡＭ１２ａ間のデータの転送と、セクタ完了の指摘という役割を担う。
【００１９】
フラッシュメモリ２０からのデータがホスト装置２４によって読み出されると、メモリ２０内の暗号化されたデータは、バス２８、ＦＩＭ１８、ＦＤＭＡ３４、および暗号エンジン４０を通じてフェッチされ、暗号化されたデータは、ＢＲＡＭ３８において復号化および記憶される。その後、復号化されたデータは、ＢＲＡＭ３８からＨＤＭＡ３２、ＨＩＭ１６、およびバス２６を通じてホスト装置２４へ送られる。ＢＲＡＭ３８からフェッチされたデータは、ＨＤＭＡ３２へ渡される前に、暗号エンジン４０によって暗号化されてもよく、ホスト装置２４へ送られるデータは、メモリ２０に記憶されたデータを暗号化したものと比べて異なるキーおよび／またはアルゴリズムによって再び暗号化される。前述した処理において復号化されたデータをＢＲＡＭ３８に記憶すると、権限のないアクセスに対してデータが脆弱となりうるが、その代わりに、ＢＲＡＭ３８へ送る前に、メモリ２０からのデータを復号化して、暗号エンジン４０によって再び暗号化してもよい。その後、ＢＲＡＭ３８内の暗号化されたデータは、以前のようにホスト装置２４へ送られる。これは、読み出し処理中のデータストリームを示すものである。
【００２０】
データがホスト装置２４によってメモリ２０に書き込まれると、データストリームの方向が逆となる。例えば、暗号化されていないデータがホスト装置によってバス２６、ＨＩＭ１６、ＨＤＭＡ３２を介して暗号エンジン４０へ送られると、そのようなデータは、ＢＲＡＭ３８に記憶される前に、エンジン４０によって暗号化されてもよい。代わりに、暗号化されていないデータは、ＢＲＡＭ３８に記憶されてもよい。その後、データは、メモリ２０へ向かう途中でＦＤＭＡ３４へ送られる前に暗号化される。
【００２１】
図１Ｂは、システム１０の他の実施形態を示す。この好ましい実施形態において、暗号化エンジン４０およびファームウェア完全性回路３１は、コントローラ１２の一部として示されている。これらの要素は、コントローラの一部であるのが好ましいが、ある実施形態において、コントローラのパッケージ内に統合されていなくてもよい。前述したように、ＲＡＭ１１、フラッシュメモリ２０、およびコントローラ１２は、すべてシステムバス１５に接続されている。ホストインターフェイスバス２６は、ホスト装置２４（図示せず）と通信する。
【００２２】
ファームウェアの完全性ベリファイ
図２は、システム１０を実行するファームウェア２００を含むフラッシュメモリのメモリ空間の図である。システムファームウェア２００は、フラッシュメモリ２０内に常駐して変更不可能なのが好ましいブートローダ（ＢＬＲ）部２００ａと、フラッシュメモリ２０内に常駐して必要に応じて変更可能なシステムファームウェア２００ｂとを備える。ある実施形態において、直接またはシャドウイングされたコピーから実行される場合にＢＬＲ部２００ａをポイントする追加のファームウェアがＲＯＭ１３内にあってもよい。システムファームウェア２００のサイズは、実行元であるＲＡＭモジュールよりも大きいので、システムファームウェアは、オーバーレイと称されるより小さい部分に分割される。好ましい実施形態におけるＢＬＲの完全性ベリファイは、固有のその場の(on the fly)計算を使用し、当該計算において、期待値がデータ自身に記憶され、コピーがフラッシュメモリ２０以外のメモリ内のレジスタに一時的に記憶される。しかし、ある実施形態において、ＢＬＲの完全性をベリファイするために使用される手法は、システムファームウェア２００ｂの完全性をベリファイするためにも使用可能である。前述したように、任意のハッシュ値およびハッシュ手法を使用可能であるが、ＭＡＣまたはＳＨＡ−１の値が現時点においては好ましく、簡素化のために、好ましい一実施形態において、一方または他方の使用について説明する。通常、ＳＨＡ−１のダイジェストをＭＡＣ値の代わりに使用してもよく、その逆であってもよい。ＭＡＣ値を使用する利点として、ＭＡＣ値が、ハードウェアと、ＭＡＣを作成したハードウェアのキーとに関連していることが挙げられる。ＳＨＡ−１値は、単にデータ自体に基づいて所定のデータセットのために作成可能だが、ＭＡＣ値は、キーなしでは再作成することは不可能であり、したがって、より強固なセキュリティを提供する。特定的には、ＭＡＣ値を作成するには、暗号化エンジン４０の不揮発性メモリに記憶されたキー９９を使用しなければならないが、ＭＡＣ値を再作成するには、他のプロセッサを使用することができない。例えば、ハッカーは、ファームウェアおよび関連するＭＡＣ値を複製するために、システム外部から他のプロセッサを使用することはできない。
【００２３】
同じくフラッシュメモリに記憶されるのは、様々なユーザデータファイル２０４である。図に示していない様々な他のプログラムおよびデータがフラッシュメモリ（図示せず）内に記憶されてもよい。これらのファイルは、暗号化されてもよく、その完全性は、同様または他のやり方でベリファイされてもよい。
【００２４】
図３は、完全性チェックモードの場合のシステム１０によって使用されるいつかのデータセクタの構造を示す。特に、ＢＬＲは、この構造を使用するのが好ましい。ＢＬＲコード３０７自体は、他のデータ間に挟まれるようにしてＢＬＲ２０１ａを構成している。ＢＬＲコード３０７がロードされる前に、いくつかの構成情報がロードされる。構成情報は、ファイル識別（ＦＩＤ）セクタ１および７に含まれている。ＢＬＲコード３０７に続いて、メッセージ認証コードセクタ３０９がある。ＭＡＣセクタ３０９内には、ＢＬＲコード３０７の対応する部分についてのＭＡＣ値がある。これが、より詳細に以下に説明する、図５において計算された値と比較されるＭＡＣ値である。ＭＡＣセクタは、様々な長さのデータを収容するためにゼロで埋められて、セクタの最終１２８ビットをＭＡＣが常に占めるようにする。ＢＬＲコード３０７は、ＢＬＲ部分２００ａ内のフラッシュメモリ２０に記憶され、構成情報もフラッシュメモリ２０に記憶されてもよい。
【００２５】
図４は、ＢＬＲコードおよびファームウェアの完全性をベリファイすることを含む、システム１０をブートおよび実行する処理を示す。特に、図４は、ファームウェア２００のＢＬＲ部分２００ａに関するような完全性ベリファイ処理の概観を含む。好ましい一実施形態において、システムファームウェア２００ｂおよびアプリケーションファームウェアのベリファイは、ＢＬＲのベリファイとは別個のものであり、かつ、当該ベリファイの後に生じる。注目すべきなのは、ファームウェアは、ＢＬＲによって一度に全てロードされるわけではないということである。ＢＬＲは、いつかのモジュールのみ（ＲＡＭ常駐ファームウェア）をロードし、他のモジュール（オーバーレイ）は、必要に応じてロードされ、ＲＡＭ内の（複数の）同じ位置へスワップされる。
【００２６】
システム１０が起動すると、ステップ４０４に示すように、完全性チェックモードで起動することになる。一般的に、このモードにおいて、暗号エンジン４０は、前述した説明および図５に詳細に示すように、すべての入力データのＭＡＣ値を計算している。この処理は、入力データが可変長であり得、かつ、ＮＡＮＤフラッシュメモリ２０内の任意の位置に記憶されうることを保証するものである。好ましい実施形態において、データは、書き込まれたのと同一の順序で読み出され、最終のブロックの読み出しにはＭＡＣが含まれることになる。ＭＡＣ比較の結果は、ファームウェアがいつでもチェックするのに利用可能である。ここで、図４に示す個々のステップを説明する。
【００２７】
ステップ４１０において、システムは、同じく図５のフローチャートに詳しく見受けられる処理に従って、ＢＬＲの完全性をチェックする。これは、（システムが完全性チェックモードにある際に）フラッシュメモリ２０からの他のデータがベリファイされたのと同じやり方でＢＬＲが暗号エンジン４０を通ることで行われる。ステップ４２０において、システムは、ステップ４１０において行われた完全性チェックの結果をチェックする。これは、図５に見受けられる処理２００の完全性チェックのステップ２７０で記憶された、問題があるかないかを示す結果（フラグまたは他の指標）をチェックすることによって行われる。ＢＬＲがＯＫでない場合、システムは、ステップ４３０に見受けられるようなホストコマンドを待って、返品許可（ＲＭＡ）状態として知られる障害分析状態へシステムを送ることになる。この動作状態および他の動作状態またはモードについてのさらなる詳細については、ホルツマンら(Holtzman et al.) の同時継続中の米国特許出願第１１／０５３，２７３号「ライフサイクルフェーズを有するセキュアメモリカード (SECURE MEMORY CARD WITH LIFE CYCLE PHASES)」（特許文献１）を参照されたい。この特許出願は、その全体が本願明細書において参照により援用されている。しかし、ＢＬＲがＯＫの場合、システムは、ステップ４４０において、ＢＬＲを実行することになる。ブートが完了すると、システムは、図４のステップ４４０に見受けられるように、ＢＬＲ自身に含まれる命令に基づいて、完全性チェックモードを去ることになる。ＢＬＲは、数多くの命令または「ステップ」を含む。そのうちの１つは、ステップ４４０ａであって、ＢＬＲは、暗号エンジン４０を通常モードに再構築し、言い換えれば、完全性チェックモードから暗号エンジン４０を抜け出させる。ＢＬＲは、ステップ４４０ｂに示すように、システムにシステムファームウェア２００ｂの完全性をチェックさせる命令も含む。
【００２８】
図５は、図４に関して説明したような完全性ベリファイ処理４１０のフローチャートである。これは、システムが完全性チェックモードにある場合に、フラッシュメモリ２０に記憶されたデータを読み出しおよびハッシュする一般的な処理を示す。ＮＡＮＤ形フラッシュメモリの読み出しを例示の目的のために説明するものであるが、本発明は、大容量記憶の目的のために使用される任意の種類のメモリまたは媒体と共に使用することができる。繰り返すが、ＭＡＣ値の使用を例示し、かつ説明するが、他のハッシュ値を使用してもよい。図２Ｂの表は、一般的に、対応する開始バイトと、バイト数とをエントリ毎に含むことになる（図示せず）。一般的に、好ましい実施形態において、処理全体は、ＮＡＮＤの完全性をページ毎ベースでベリファイするために使用される。この処理は、ＮＡＮＤに記憶された任意のデータの完全性をベリファイすることになる。データがたまたまファームウェアの場合には、ファームウェアの完全性をベリファイする。このようなページ毎の比較が好ましいが、より小さな単位またはより大きな単位での比較を行ってもよい。
【００２９】
好ましい一実施形態における完全性ベリファイ処理は、図５に示すような固有の計算と制御ループとを使用する。ループは、連続する計算および比較動作を伴う。典型的には、ベリファイ手法において、何らかの種類の「正しい(correct) 」値または期待値が予め記憶され、計算された値と比較される。図５に示す処理を有する好ましい一実施形態において、「正しい」値または期待値が、「被テストデータ(data under test) 」内に記憶される。それは、特定的には、前述した好ましい実施形態において、データブロックの最終１２８ビット内にある。読み出し中のセクタの最終１２８ビットは、実際上の目的のためには、正しいセクタが読み出された際に、記憶されたＭＡＣ（または他のハッシュ値）といったん対応するだけとなる。（誤った肯定(false positive)）一致が最終以外のページで生じるであろう確率は非常に小さいので、これは実際上の目的では無視できる。
【００３０】
ステップ２１０において、ＮＡＮＤブロック（ｉ）が読み出される。次に、ステップ２１５において、ブロックがチェックされて、必要があれば、ＥＣＣ回路でオプションで訂正される。ＥＣＣは周知であり、データ内の物理的な誤りを訂正するために使用できる。完全性ベリファイ処理と共にＥＣＣを使用することが好ましいが、これは必須ではなく、完全性は、ステップ２１５を含んでも含まなくてもベリファイされる。ステップ２２０において、ハッシュ値が計算され、好ましい一実施形態において、ＭＡＣ値が好ましい。ブロック（ｉ）についてのＭＡＣが計算されるが、完全性ベリファイ処理４１０において、結果生じたＭＡＣは、ブロック０から（ｉ）までを対象として含み、数学的には以下のように表現できる。
ＭＡＣ［０．．．（ｉ）］＝ＭＡＣ［ＭＡＣ［０．．．（ｉ−１）］，
ｂｌｏｃｋ（ｉ）］
【００３１】
ステップ２２０での計算後、ステップ２６０において比較が行われる。ステップ２６０において、コントローラのハードウェア、特にＦＷＩＣ３１が、ブロック（ｉ）の最終１２８ビットを以前記憶されたＭＡＣ、すなわちＭＡＣ［０．．．（ｉ−１）］と比較する。ステップ２７０において、比較結果がシステムのメモリに記憶される。ステップ２６０の比較が最初に行われる際には、ＭＡＣレジスタに「記憶された」値は、実際には、適切な記憶済みＭＡＣ値ではないことになるが、どんな値であれたまたまレジスタ内にあることになり、よって、ランダムであると考えられる。その後、ステップ２７０において、比較結果は記憶されることになる。第１のブロックについて、比較はチェックされないことになる。ステップ２３０において、ステップ２２０において計算されたＭＡＣ値は、コントローラのレジスタ内、好ましくはＦＷＩＣ３１のレジスタ内に記憶されることになる。次に、ステップ２３５において、（ｉ）の値が１増分されるようにカウンタが増分され、次のブロックがまたステップ２１０で読み出されることになる。ループは、ブロック（ｉ）が読み出されるまで継続することになる。最終ブロックが読み出されて暗号化エンジンによって処理されると、ステップ２３０で記憶されたＭＡＣと最終１２８ビットが一致すれば、比較は一致を生じさせて、ステップ２７０において記憶された結果は、完全性がハードウェアによってベリファイされたことを反映することになる。ＢＬＲの最終ページが読み出された場合にのみ、完全性がベリファイされたことを示すために一致が使用されることになる。これまでのすべての一致（誤った真の値(false true value)）は、無視されることになる。値が異なる場合には、データの完全性に問題があることを示すこととなる。逆に、値が同一の場合には、データの完全性が確実となる。
【００３２】
一致が生じた後に、ステップ２３０において、ＭＡＣ値は再び更新されることになるが、これは影響を及ぼさない、ループの冗長動作である。この連続計算処理によって、ハードウェアは、不確定なコンテンツのサイズをベリファイすることができる。言い換えれば、ＭＡＣ値を適切に計算することができ、ブロックからなるファイルのブロック数またはサイズをまず確認する必要なく、完全性をハードウェアによってベリファイすることができる。
【００３３】
前述した処理は、メモリカードのフラッシュメモリ２０内に常駐する任意のデータについて、ある動作状態またはモード、特に完全性チェックモードにおいて使用される。本発明によるメモリカードの好ましい一実施形態において、当該データのいくらかは、実行されるとメモリカードを実行するファームウェアである。特に、システム１０の電源投入の際に、システムがその通常の動作状態またはテスト状態である場合に、暗号エンジン４０は、任意の入力データの完全性をベリファイするために、（完全性チェックモードにおいて開始することによって）暗号エンジン４０自体を初期化する。データがたまたまファームウェアである場合には、ＢＭＵ１４および特に暗号エンジン４０を通る際にファームウェアの完全性がベリファイされる。記憶された結果（完全性自体ではない）は、一実施形態において、ＲＯＭ１３に記憶されたコード内の命令を伴うソフトウェアによってチェックできる。注意すべきなのは、ＲＯＭ１３に記憶されたコードは結果をチェックするものの、データのフローを開始してもよく、これはフラッシュメモリ内のファームウェアの完全性をベリファイする際には含まれないということである。言い換えれば、コードは、ベリファイするためにファームウェアの数値計算もデータ操作も行う役割はない。ファームウェアの完全性をベリファイするのは、コントローラ１２またはＢＭＵ１４、ＦＷＩＣ３１、および暗号エンジン４０のハードウェアであり、これには、ブートローダ（ＢＬＲ）部分と、ある実施形態において、ファームウェアの他の部分も含まれる。
【００３４】
図５で説明した処理は、ハードウェア（ＨＷ）とファームウェア（ＦＷ）との両方が関与する。前述したように、ハードウェアが完全性チェックを行うのに対して、ファームウェアは、ＨＷ完全性チェックの末尾のフラグセットを単にチェックするだけである。ＨＷおよびＳＷの機能または「ループ」を、それぞれ図６および図７にさらに詳細に示す。
【００３５】
図６を参照すると、ステップ３２０において、システムに電源が投入される。ステップ３２２において、コントローラのハードウェアが、ＦＷ完全性モードを開始する。これは、２つの中心的な行為を備える。第１は、図１のＦＷＩＣ３１を作動させることである。いったん作動されたＦＷＩＣ３１は、図６の残りのステップをうまくまとめあげ、これによって、暗号エンジン４０と共に、ファームウェアのＢＬＲ部分の完全性をチェックする。第２の行為には、暗号エンジン４０によって使用される暗号アルゴリズムを選択することが含まれる。前述したように、暗号エンジン４０のハードウェアは、様々な互いに異なるアルゴリズムでデータを暗号化および復号化するように構成されている。
【００３６】
ステップ３２８において、コントローラのハードウェアは、入力ブロックのダイジェストを計算する。この計算は、暗号エンジン４０によって行われる。次に、ステップ３３０において、ステップ３２８において計算されたダイジェストを、以前のダイジェストの値と比較する。前述したように、値を保持するレジスタがチェックされて、ループの反復毎に比較されるが、最初の反復の際には、レジスタ内の値はランダムである。その後、完全性を示すフラグが、ステップ３３２において設定される。ＨＷがファームウェアのＢＬＲ部分の完全性をベリファイしたかを確認するために、このフラグがシステムのファームウェアによってチェックされることになる。
【００３７】
図７は、図６においてＨＷが完全性をチェックする一方で生じるファームウェアのループを示す。ステップ３２０においてシステムに電源が投入された後に、ステップ３４０においてＣＰＵが初期化される。その後、ステップ３４２において、構成データ（好ましい一実施形態において、図３のＦＩＤ１）が最初の有効ページに読み出される。次に、ステップ３４４において、システムは、ＢＬＲ ２０１Ａの開始および終了ページを抽出する。これがいったんわかると、ＢＬＲページのすべてが読み出される。各ページが読み出されるにつれて、誤り訂正符号（ＥＣＣ）が生成される。前述したように、ＥＣＣ回路動作は周知であり、データ内の物理的な誤りをある一定の限界まで訂正するために使用することができる。完全性ベリファイ処理と共にＥＣＣを使用することが好ましいが、これは必須ではなく、完全性は、ＥＣＣを使用してもしなくてもベリファイされる。ページが読み出された後に、ステップ３４８においてＥＣＣ回路でチェックされ、ＯＫでない場合には、ページはＥＣＣ訂正機構で訂正されるか、またはステップ３５２において代替のページが取り出されることになる。訂正または新規のページがＯＫであるとステップ３５４において判断されると、システムは、ステップ３５０において、読み出されるべきページがさらにあるかどうかをチェックする。そうである場合には、システムはステップ３４６へ戻り、他のページを読み出す。ステップ３５４において訂正されたまたは代替コピーがＯＫではないとステップ３５４が示す場合には、失敗状態がステップ３５６において示されることになる。ステップ３５０においてこれ以上ページがないと判断されると、失敗は示されず、システムは、完全性フラグ（図６に示すようにハードウェアによって設定されている）をステップ３６０においてチェックすることになる。ステップ３６０において、ＢＬＲがＯＫであるとフラグが示す場合には、ＨＷによってベリファイされたので、ステップ３６２においてＢＬＲが実行されることになる。この実行は、図４のステップ４４０において示したのと同じである。
【００３８】
この完全性チェックは、ファームウェアの一部分、すなわちＢＬＲについてのみ行われるが、ファームウェアのすべてもこのようにチェックすることができ、また、この説明はファームウェアのブートスラップを使用する好ましい実施形態に関することが理解されるべきである。加えて、本願において使用されるようなメモリカードという用語は、ＵＳＢフラッシュドライブの形式要因をも含んでいるつもりである。
【００３９】
本発明の様々な態様についてそれらの例示の実施形態に関して説明してきたが、本発明が、添付の特許請求の範囲の全範囲内においてその権利が保護されるべきであることが理解できよう。
【技術分野】
【０００１】
本発明は、一般的には、安全なコンテンツを有するメモリカードおよび当該コンテンツの暗号化に関し、特に、安全なメモリカードを実行するファームウェアの完全性(integrity) をベリファイすることに関する。
【背景技術】
【０００２】
商用のメモリカードの機能を工場から出荷する前にベリファイし、工場から出荷されてもハッカーから保護されていることを確実にすることは、極めて重要である。デジタル権利管理の出現と、音楽および映画などの保護されたコンテンツの普及とに伴い、カードのコンテンツが自由にコピーできないことを確実にする必要がある。ハッカーがこれを行おうと試みるやり方の１つとして、カード内のコンテンツを無断使用することができるようにするために、メモリカードを実行するファームウェアを変更または取り替えさえするということがある。よって、カード上で常時実行するファームウェアの完全性および信頼性の両方を確実にするシステムを提供することが不可欠である。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】米国特許出願第１１／０５３，２７３号
【非特許文献】
【０００４】
【非特許文献１】シーラ・フランケルによる「ＲＦＣ３５６６−ＡＥＳ−ＸＣＢＣ−ＭＡＣ−９６アルゴリズムおよびＩＰｓｅｃを伴うその使用」
【非特許文献２】ジャナカ・ディーパクマラ、ハワード・Ｍ・ヘイズおよびＲ・ベンカテザンによる「インターネットプロトコルセキュリティ（ＩＰＳＥＣ）のためのメッセージ認証コード（ＭＡＣ）アルゴリズムの性能比較」
【非特許文献３】ネバダ大学のジョン・ブラック、カリフォルニア大学デービス校のフィリップ・ロガウェイによる「ＡＥＳ動作モードに関するＮＩＳＴに対するコメント：ＣＢＣ ＭＡＣを使用する任意長メッセージのハンドリングについての提言」
【発明の概要】
【０００５】
ファームウェアの完全性をベリファイすることは、安全かつ信頼性のあるメモリカードを実行するのに重要な態様の１つである。本発明は、メモリカード、ユニバーサル・シリアル・バス（ＵＳＢ）フラッシュドライブ、または他のメモリシステムを実行するファームウェアの完全性をベリファイする。ファームウェアの完全性は、実行される前にベリファイされる。これにより、工場のファームウェアではないファームウェアの実行が防止される。このことが特に重要なのは、コンテンツが自由にコピーされないように保護することを意図した暗号化アルゴリズムを含むセキュリティ機構を、工場のファームウェアが備えているからである。本発明は、メモリカードにおいて実施される場合に、工場以外のファームウェア、または安全なコンテンツのコピーを許可するような変更された工場のファームウェアをカードが実行することを防止する。よって、ハッカーは、カードを「騙して(trick) 」間違ったファームウェアを実行させるようにすることができなくなる。ベリファイ処理は、任意の記憶データの完全性をベリファイするためにも使用することができる。
【０００６】
本発明の一態様は、メモリ記憶装置の動作を開始するための方法に関し、装置の大容量記憶ユニット内にファームウェアを提供するステップと、ファームウェアを暗号化エンジンに通すステップと、ファームウェアについてのハッシュ値を前記暗号化エンジンで計算するステップと、計算されたハッシュ値を記憶されたハッシュ値と比較するステップと、計算されたハッシュ値が記憶されたハッシュ値と一致する場合に、ファームウェアを実行するステップと、を含む。
【０００７】
本発明の他の態様は、大容量記憶装置に関し、フラッシュメモリと、読み出し専用メモリと、フラッシュメモリに記憶された、大容量記憶装置のデータ記憶動作を制御する第１の命令セットと、第１の命令セットをフラッシュから実行可能なランダムアクセスメモリへのシャドウイングする、読み出し専用メモリ内に常駐する第２の命令セットと、を備える。暗号化エンジンが、大容量記憶装置のハードウェア回路において実施され、フラッシュメモリに記憶されるおよびそこから読み出されるデータを暗号化および復号化することができる。暗号化エンジンは、第１の命令セットの完全性をベリファイするように動作可能である。
【０００８】
本発明のさらに他の態様は、メモリ記憶装置の動作を開始するための他の方法に関する。この方法は、装置の大容量記憶ユニット内にファームウェアを提供するステップと、ファームウェアを大容量記憶ユニットからランダムアクセスメモリへコピーする、読み出し専用メモリ内の第１の命令セットを実行するステップと、を含む。また、この方法は、暗号化エンジンを使用してブートファームウェアの完全性をベリファイするステップと、完全性がベリファイされた後に、ランダムアクセスメモリからファームウェアをマイクロプロセッサで実行するステップと、を含む。
【０００９】
本発明のさらなる態様、利点、および特徴は、以下の例示の例の説明に含まれ、その説明は、添付の図面と共に解釈されるべきであり、同様の参照番号は、特に指示のない限り、全ての図を通じて同一の特徴を説明するために使用される。本願明細書において援用されているすべての特許、特許出願、記事、および他の出版物は、あらゆる目的のためにその全体が本願明細書において参照により援用されている。
【図面の簡単な説明】
【００１０】
【図１Ａ】本発明の一実施形態によるシステム１０の概略図である。
【図１Ｂ】本発明の他の実施形態によるシステム１０の概略図である。
【図２】図１に示すフラッシュメモリのメモリ図である。
【図３】ブートローダ２００ａの概略図である。
【図４】ファームウェアのハードウェアベースの完全性チェックを含むブート処理の部分のフローチャートである。
【図５】図４の完全性ベリファイ処理４１０のフローチャートである。
【図６】ブート中のハードウェアループのフローチャートである。
【図７】ブート中のファームウェアループのフローチャートである。
【発明を実施するための形態】
【００１１】
メッセージ認証コード（ＭＡＣ）は、何らかのコンテンツ（または、メッセージ）から計算されるコンテンツの完全性を証明するために使用される数である。その目的は、コンテンツが変更されたかどうかを検出することである。メッセージ認証コードは、メッセージおよび何らかの秘密データから計算されるハッシュである。秘密データを知らなければ、偽造することは困難である。ＭＡＣは、秘密鍵を使用するＤＥＳまたはＡＥＳ暗号に基づくアルゴリズムを使用して計算される。その後、ＭＡＣは、メッセージと共に記憶または送られる。受信者は、同一のアルゴリズムおよび秘密鍵を使用してＭＡＣを再計算し、それを記憶または送られたものと比較する。それらが同一であれば、コンテンツまたはメッセージは改変されていないものとされる。
【００１２】
ＤＥＳ（データ暗号化標準）は、５６ビットキーを使用するＮＩＳＴ標準の暗号化暗号である。ＮＩＳＴによって１９７７年に採用されたが、２００１年にはＡＥＳが公式標準として取って代わった。ＤＥＳは、４つの異なる動作モードにおける６４ビットのブロックを処理する対称ブロック暗号であって、電子コードブック（ＥＣＢ）が最も一般的である。
【００１３】
トリプルＤＥＳは、いくつかの複数パス方法を追加することによって安全性を増強した。例えば、１つの鍵で暗号化し、その結果を第２の鍵で復号化し、それを再び第３の鍵で暗号化する。しかし、追加のパスは、多大な計算時間を処理に追加する。ＤＥＳは、最強のセキュリティを必要としないアプリケーションにおいて今でも使用されている。
【００１４】
改良形暗号化標準（Advanced Encryption Standard（「ＡＥＳ」））は、ＮＩＳＴ標準の暗号化暗号であって、１２８ビットのブロック長と、１２８，１９２，または２５６ビットのキー長とを使用する。２００１年にトリプルＤＥＳ方法に公式に取って代わったＡＥＳは、ベルギーのヨアン・ダーメン (Joan Daemen)およびビンセント・ライメン (Vincent Rijmen) によって開発されたラインダールアルゴリズムを使用する。ＡＥＳは、３つに変わって１つのパスで暗号化でき、そのキーサイズは、トリプルＤＥＳの１６８ビットより大きい。
【００１５】
セキュアハッシュアルゴリズム（ＳＨＡ−１）は、２０バイトの出力を生じさせる。ＮＩＳＴおよびＮＳＡは、これをデジタル署名標準と共に使用するように設計し、現在幅広く使用されている。ＭＤ５は、本発明と共に使用されるような他のハッシュ関数である。前述した標準および様々な他のアルゴリズムは、本発明と共に使用されるようなハッシュ関数および値の例示的な例である。今日利用可能かつ将来開発される他の形のハッシュ関数および値も、本発明と共に使用できる。
【００１６】
前述した規格および様々な他のアルゴリズムおよび／または標準は、暗号化技術における当業者に周知であるが、以下の出版物は有益であり、その全体が本願明細書において参照により援用されている。これら出版物とは、シーラ・フランケル (Sheila Frankel) による「ＲＦＣ３５６６−ＡＥＳ−ＸＣＢＣ−ＭＡＣ−９６アルゴリズムおよびＩＰｓｅｃを伴うその使用 (RFC3566-The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec) 」，アメリカ合衆国、メリーランド、２０８９９、ゲイザースブルグ、８２０ ウエスト・ダイアモンド・アベニュー、ルーム ６７７にあるＮＩＳＴ−国立標準技術研究所 (National Institute of Standards and Technology), (http://www.faqs.org/rfcs/rfc3566.html において利用可能）（非特許文献１）、ジャナカ・ディーパクマラ (Janaka Deepakumara) 、ハワード・Ｍ・ヘイズ (Howard M. Heys) およびＲ・ベンカテザン (R. Venkatesan)による「インターネットプロトコルセキュリティ（ＩＰＳＥＣ）のためのメッセージ認証コード（ＭＡＣ）アルゴリズムの性能比較 (Performance Comparison of Message Authentication Code (MAC) Algorithms for the Internet Protocol Security (IPSEC))」，電気およびコンピュータエンジニアリング(Electrical and Computer Engineering) ，ニューファンドランドのメモリアル大学（カナダ、Ａ１Ｂ３Ｓ７、ニューファンドランド、セント・ジョンズ）, http://www.engr.mun.ca/~howard/PAPERS/necec_2003b.pdf （非特許文献２）、およびリノにあるネバダ大学のジョン・ブラック (John Black) 、カリフォルニア大学デービス校のフィリップ・ロガウェイ (Philip Rogaway) による「ＡＥＳ動作モードに関するＮＩＳＴに対するコメント：ＣＢＣ ＭＡＣを使用する任意長メッセージのハンドリングについての提言 (Comments to NIST concerning AES Modes of Operations: A Suggestion for Handling Arbitrary-Length Messages with the CBC Mac)」，(http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/xcbc-mac/xcbc-mac-spec.pdfにおいて利用可能）（非特許文献３）である。
【００１７】
メモリシステムアーキテクチャ
本発明の様々な態様が実施されるようなメモリシステム例を、図１Ａのブロック図に示す。図１Ａに示すように、メモリシステム１０は、中央処理装置（ＣＰＵ）または「コントローラ」１２と、バッファ管理ユニット（ＢＭＵ）１４と、ホストインターフェイスモジュール（ＨＩＭ）１６と、フラッシュインターフェイスモジュール（ＦＩＭ）１８と、フラッシュメモリ２０と、周辺アクセスモジュール２２とを含む。メモリシステム１０は、ホストインターフェイスバス２６およびポート２６ａとを通じてホスト装置２４と通信する。フラッシュメモリ２０は、ＮＡＮＤ形であってもよく、ホスト装置２４に対してデータ記憶を提供する。ＣＰＵ１２のためのソフトウェアコードも、フラッシュメモリ２０に記憶されてもよい。ＦＩＭ１８は、フラッシュインターフェイスバス２８を通じて、および、場合によってはフラッシュメモリ２０が着脱可能な要素であるときには図に示さないポートとを通じて、フラッシュメモリ２０に接続する。ＨＩＭ１６は、デジタルカメラ、パーソナルコンピュータ、個人用携帯情報端末（ＰＤＡ）、ＭＰ−３プレーヤ、携帯電話、または他のデジタル装置のようなホストシステムに対する接続に適している。周辺アクセスモジュール２２は、ＣＰＵ１２と通信するために、ＦＩＭ、ＨＩＭ、およびＢＭＵなどの適切なコンローラモジュールを選択する。一実施形態において、点線のボックス内のシステム１０のすべての要素が、メモリカードなどの単一のユニット、好ましくはカード内に密封されていてもよい。
【００１８】
バッファ管理ユニット１４は、ホスト直接メモリアクセスユニット（ＨＤＭＡ）３２と、フラッシュ直接メモリアクセスユニット（ＦＤＭＡ）３４と、アービタ３６と、ＣＰＵバスアービタ３５と、レジスタ３３と、ファームウェア完全性回路（ＦＷＩＣ）３１と、バッファランダムアクセスメモリ（ＢＲＡＭ）３８と、暗号化エンジン(encryption engine) とも称される暗号エンジン(crypto engine) ４０とを備える。アービタ３６は、１つのマスタまたはイニシエータ（ＨＤＭＡ３２、ＦＤＭＡ３４、またはＣＰＵ１２であってもよい）だけが任意のときにアクティブであることができ、かつ、スレーブまたはターゲットはＢＲＡＭ３８であるような共有バスアービタである。アービタは、適切なイニシエータの要求をＢＲＡＭ３８へ振り向ける役割を担う。ＨＤＭＡ３２およびＦＤＭＡ３４は、ＨＩＭ１６、ＦＩＭ１８、およびＢＲＡＭ３８またはＲＡＭ１１間で搬送されるデータを担当する。ＣＰＵバスアービタ３５は、例えば暗号エンジンを迂回したい場合のような所定の状況において使用されるシステムバス１５を通じた暗号エンジン４０およびフラッシュＤＭＡ３４からＲＡＭ１１への直接データ搬送を可能にする。ＨＤＭＡ３２の動作およびＦＤＭＡ３４の動作は従来どおりであり、本願明細書において詳述する必要はない。ＢＲＡＭ３８は、ホスト装置２４およびフラッシュメモリ２０間を通るデータを記憶するために使用される。ＨＤＭＡ３２およびＦＤＭＡ３４は、ＨＩＭ１６／ＦＩＭ１８およびＢＲＡＭ３８またはＣＰＵ ＲＡＭ１２ａ間のデータの転送と、セクタ完了の指摘という役割を担う。
【００１９】
フラッシュメモリ２０からのデータがホスト装置２４によって読み出されると、メモリ２０内の暗号化されたデータは、バス２８、ＦＩＭ１８、ＦＤＭＡ３４、および暗号エンジン４０を通じてフェッチされ、暗号化されたデータは、ＢＲＡＭ３８において復号化および記憶される。その後、復号化されたデータは、ＢＲＡＭ３８からＨＤＭＡ３２、ＨＩＭ１６、およびバス２６を通じてホスト装置２４へ送られる。ＢＲＡＭ３８からフェッチされたデータは、ＨＤＭＡ３２へ渡される前に、暗号エンジン４０によって暗号化されてもよく、ホスト装置２４へ送られるデータは、メモリ２０に記憶されたデータを暗号化したものと比べて異なるキーおよび／またはアルゴリズムによって再び暗号化される。前述した処理において復号化されたデータをＢＲＡＭ３８に記憶すると、権限のないアクセスに対してデータが脆弱となりうるが、その代わりに、ＢＲＡＭ３８へ送る前に、メモリ２０からのデータを復号化して、暗号エンジン４０によって再び暗号化してもよい。その後、ＢＲＡＭ３８内の暗号化されたデータは、以前のようにホスト装置２４へ送られる。これは、読み出し処理中のデータストリームを示すものである。
【００２０】
データがホスト装置２４によってメモリ２０に書き込まれると、データストリームの方向が逆となる。例えば、暗号化されていないデータがホスト装置によってバス２６、ＨＩＭ１６、ＨＤＭＡ３２を介して暗号エンジン４０へ送られると、そのようなデータは、ＢＲＡＭ３８に記憶される前に、エンジン４０によって暗号化されてもよい。代わりに、暗号化されていないデータは、ＢＲＡＭ３８に記憶されてもよい。その後、データは、メモリ２０へ向かう途中でＦＤＭＡ３４へ送られる前に暗号化される。
【００２１】
図１Ｂは、システム１０の他の実施形態を示す。この好ましい実施形態において、暗号化エンジン４０およびファームウェア完全性回路３１は、コントローラ１２の一部として示されている。これらの要素は、コントローラの一部であるのが好ましいが、ある実施形態において、コントローラのパッケージ内に統合されていなくてもよい。前述したように、ＲＡＭ１１、フラッシュメモリ２０、およびコントローラ１２は、すべてシステムバス１５に接続されている。ホストインターフェイスバス２６は、ホスト装置２４（図示せず）と通信する。
【００２２】
ファームウェアの完全性ベリファイ
図２は、システム１０を実行するファームウェア２００を含むフラッシュメモリのメモリ空間の図である。システムファームウェア２００は、フラッシュメモリ２０内に常駐して変更不可能なのが好ましいブートローダ（ＢＬＲ）部２００ａと、フラッシュメモリ２０内に常駐して必要に応じて変更可能なシステムファームウェア２００ｂとを備える。ある実施形態において、直接またはシャドウイングされたコピーから実行される場合にＢＬＲ部２００ａをポイントする追加のファームウェアがＲＯＭ１３内にあってもよい。システムファームウェア２００のサイズは、実行元であるＲＡＭモジュールよりも大きいので、システムファームウェアは、オーバーレイと称されるより小さい部分に分割される。好ましい実施形態におけるＢＬＲの完全性ベリファイは、固有のその場の(on the fly)計算を使用し、当該計算において、期待値がデータ自身に記憶され、コピーがフラッシュメモリ２０以外のメモリ内のレジスタに一時的に記憶される。しかし、ある実施形態において、ＢＬＲの完全性をベリファイするために使用される手法は、システムファームウェア２００ｂの完全性をベリファイするためにも使用可能である。前述したように、任意のハッシュ値およびハッシュ手法を使用可能であるが、ＭＡＣまたはＳＨＡ−１の値が現時点においては好ましく、簡素化のために、好ましい一実施形態において、一方または他方の使用について説明する。通常、ＳＨＡ−１のダイジェストをＭＡＣ値の代わりに使用してもよく、その逆であってもよい。ＭＡＣ値を使用する利点として、ＭＡＣ値が、ハードウェアと、ＭＡＣを作成したハードウェアのキーとに関連していることが挙げられる。ＳＨＡ−１値は、単にデータ自体に基づいて所定のデータセットのために作成可能だが、ＭＡＣ値は、キーなしでは再作成することは不可能であり、したがって、より強固なセキュリティを提供する。特定的には、ＭＡＣ値を作成するには、暗号化エンジン４０の不揮発性メモリに記憶されたキー９９を使用しなければならないが、ＭＡＣ値を再作成するには、他のプロセッサを使用することができない。例えば、ハッカーは、ファームウェアおよび関連するＭＡＣ値を複製するために、システム外部から他のプロセッサを使用することはできない。
【００２３】
同じくフラッシュメモリに記憶されるのは、様々なユーザデータファイル２０４である。図に示していない様々な他のプログラムおよびデータがフラッシュメモリ（図示せず）内に記憶されてもよい。これらのファイルは、暗号化されてもよく、その完全性は、同様または他のやり方でベリファイされてもよい。
【００２４】
図３は、完全性チェックモードの場合のシステム１０によって使用されるいつかのデータセクタの構造を示す。特に、ＢＬＲは、この構造を使用するのが好ましい。ＢＬＲコード３０７自体は、他のデータ間に挟まれるようにしてＢＬＲ２０１ａを構成している。ＢＬＲコード３０７がロードされる前に、いくつかの構成情報がロードされる。構成情報は、ファイル識別（ＦＩＤ）セクタ１および７に含まれている。ＢＬＲコード３０７に続いて、メッセージ認証コードセクタ３０９がある。ＭＡＣセクタ３０９内には、ＢＬＲコード３０７の対応する部分についてのＭＡＣ値がある。これが、より詳細に以下に説明する、図５において計算された値と比較されるＭＡＣ値である。ＭＡＣセクタは、様々な長さのデータを収容するためにゼロで埋められて、セクタの最終１２８ビットをＭＡＣが常に占めるようにする。ＢＬＲコード３０７は、ＢＬＲ部分２００ａ内のフラッシュメモリ２０に記憶され、構成情報もフラッシュメモリ２０に記憶されてもよい。
【００２５】
図４は、ＢＬＲコードおよびファームウェアの完全性をベリファイすることを含む、システム１０をブートおよび実行する処理を示す。特に、図４は、ファームウェア２００のＢＬＲ部分２００ａに関するような完全性ベリファイ処理の概観を含む。好ましい一実施形態において、システムファームウェア２００ｂおよびアプリケーションファームウェアのベリファイは、ＢＬＲのベリファイとは別個のものであり、かつ、当該ベリファイの後に生じる。注目すべきなのは、ファームウェアは、ＢＬＲによって一度に全てロードされるわけではないということである。ＢＬＲは、いつかのモジュールのみ（ＲＡＭ常駐ファームウェア）をロードし、他のモジュール（オーバーレイ）は、必要に応じてロードされ、ＲＡＭ内の（複数の）同じ位置へスワップされる。
【００２６】
システム１０が起動すると、ステップ４０４に示すように、完全性チェックモードで起動することになる。一般的に、このモードにおいて、暗号エンジン４０は、前述した説明および図５に詳細に示すように、すべての入力データのＭＡＣ値を計算している。この処理は、入力データが可変長であり得、かつ、ＮＡＮＤフラッシュメモリ２０内の任意の位置に記憶されうることを保証するものである。好ましい実施形態において、データは、書き込まれたのと同一の順序で読み出され、最終のブロックの読み出しにはＭＡＣが含まれることになる。ＭＡＣ比較の結果は、ファームウェアがいつでもチェックするのに利用可能である。ここで、図４に示す個々のステップを説明する。
【００２７】
ステップ４１０において、システムは、同じく図５のフローチャートに詳しく見受けられる処理に従って、ＢＬＲの完全性をチェックする。これは、（システムが完全性チェックモードにある際に）フラッシュメモリ２０からの他のデータがベリファイされたのと同じやり方でＢＬＲが暗号エンジン４０を通ることで行われる。ステップ４２０において、システムは、ステップ４１０において行われた完全性チェックの結果をチェックする。これは、図５に見受けられる処理２００の完全性チェックのステップ２７０で記憶された、問題があるかないかを示す結果（フラグまたは他の指標）をチェックすることによって行われる。ＢＬＲがＯＫでない場合、システムは、ステップ４３０に見受けられるようなホストコマンドを待って、返品許可（ＲＭＡ）状態として知られる障害分析状態へシステムを送ることになる。この動作状態および他の動作状態またはモードについてのさらなる詳細については、ホルツマンら(Holtzman et al.) の同時継続中の米国特許出願第１１／０５３，２７３号「ライフサイクルフェーズを有するセキュアメモリカード (SECURE MEMORY CARD WITH LIFE CYCLE PHASES)」（特許文献１）を参照されたい。この特許出願は、その全体が本願明細書において参照により援用されている。しかし、ＢＬＲがＯＫの場合、システムは、ステップ４４０において、ＢＬＲを実行することになる。ブートが完了すると、システムは、図４のステップ４４０に見受けられるように、ＢＬＲ自身に含まれる命令に基づいて、完全性チェックモードを去ることになる。ＢＬＲは、数多くの命令または「ステップ」を含む。そのうちの１つは、ステップ４４０ａであって、ＢＬＲは、暗号エンジン４０を通常モードに再構築し、言い換えれば、完全性チェックモードから暗号エンジン４０を抜け出させる。ＢＬＲは、ステップ４４０ｂに示すように、システムにシステムファームウェア２００ｂの完全性をチェックさせる命令も含む。
【００２８】
図５は、図４に関して説明したような完全性ベリファイ処理４１０のフローチャートである。これは、システムが完全性チェックモードにある場合に、フラッシュメモリ２０に記憶されたデータを読み出しおよびハッシュする一般的な処理を示す。ＮＡＮＤ形フラッシュメモリの読み出しを例示の目的のために説明するものであるが、本発明は、大容量記憶の目的のために使用される任意の種類のメモリまたは媒体と共に使用することができる。繰り返すが、ＭＡＣ値の使用を例示し、かつ説明するが、他のハッシュ値を使用してもよい。図２Ｂの表は、一般的に、対応する開始バイトと、バイト数とをエントリ毎に含むことになる（図示せず）。一般的に、好ましい実施形態において、処理全体は、ＮＡＮＤの完全性をページ毎ベースでベリファイするために使用される。この処理は、ＮＡＮＤに記憶された任意のデータの完全性をベリファイすることになる。データがたまたまファームウェアの場合には、ファームウェアの完全性をベリファイする。このようなページ毎の比較が好ましいが、より小さな単位またはより大きな単位での比較を行ってもよい。
【００２９】
好ましい一実施形態における完全性ベリファイ処理は、図５に示すような固有の計算と制御ループとを使用する。ループは、連続する計算および比較動作を伴う。典型的には、ベリファイ手法において、何らかの種類の「正しい(correct) 」値または期待値が予め記憶され、計算された値と比較される。図５に示す処理を有する好ましい一実施形態において、「正しい」値または期待値が、「被テストデータ(data under test) 」内に記憶される。それは、特定的には、前述した好ましい実施形態において、データブロックの最終１２８ビット内にある。読み出し中のセクタの最終１２８ビットは、実際上の目的のためには、正しいセクタが読み出された際に、記憶されたＭＡＣ（または他のハッシュ値）といったん対応するだけとなる。（誤った肯定(false positive)）一致が最終以外のページで生じるであろう確率は非常に小さいので、これは実際上の目的では無視できる。
【００３０】
ステップ２１０において、ＮＡＮＤブロック（ｉ）が読み出される。次に、ステップ２１５において、ブロックがチェックされて、必要があれば、ＥＣＣ回路でオプションで訂正される。ＥＣＣは周知であり、データ内の物理的な誤りを訂正するために使用できる。完全性ベリファイ処理と共にＥＣＣを使用することが好ましいが、これは必須ではなく、完全性は、ステップ２１５を含んでも含まなくてもベリファイされる。ステップ２２０において、ハッシュ値が計算され、好ましい一実施形態において、ＭＡＣ値が好ましい。ブロック（ｉ）についてのＭＡＣが計算されるが、完全性ベリファイ処理４１０において、結果生じたＭＡＣは、ブロック０から（ｉ）までを対象として含み、数学的には以下のように表現できる。
ＭＡＣ［０．．．（ｉ）］＝ＭＡＣ［ＭＡＣ［０．．．（ｉ−１）］，
ｂｌｏｃｋ（ｉ）］
【００３１】
ステップ２２０での計算後、ステップ２６０において比較が行われる。ステップ２６０において、コントローラのハードウェア、特にＦＷＩＣ３１が、ブロック（ｉ）の最終１２８ビットを以前記憶されたＭＡＣ、すなわちＭＡＣ［０．．．（ｉ−１）］と比較する。ステップ２７０において、比較結果がシステムのメモリに記憶される。ステップ２６０の比較が最初に行われる際には、ＭＡＣレジスタに「記憶された」値は、実際には、適切な記憶済みＭＡＣ値ではないことになるが、どんな値であれたまたまレジスタ内にあることになり、よって、ランダムであると考えられる。その後、ステップ２７０において、比較結果は記憶されることになる。第１のブロックについて、比較はチェックされないことになる。ステップ２３０において、ステップ２２０において計算されたＭＡＣ値は、コントローラのレジスタ内、好ましくはＦＷＩＣ３１のレジスタ内に記憶されることになる。次に、ステップ２３５において、（ｉ）の値が１増分されるようにカウンタが増分され、次のブロックがまたステップ２１０で読み出されることになる。ループは、ブロック（ｉ）が読み出されるまで継続することになる。最終ブロックが読み出されて暗号化エンジンによって処理されると、ステップ２３０で記憶されたＭＡＣと最終１２８ビットが一致すれば、比較は一致を生じさせて、ステップ２７０において記憶された結果は、完全性がハードウェアによってベリファイされたことを反映することになる。ＢＬＲの最終ページが読み出された場合にのみ、完全性がベリファイされたことを示すために一致が使用されることになる。これまでのすべての一致（誤った真の値(false true value)）は、無視されることになる。値が異なる場合には、データの完全性に問題があることを示すこととなる。逆に、値が同一の場合には、データの完全性が確実となる。
【００３２】
一致が生じた後に、ステップ２３０において、ＭＡＣ値は再び更新されることになるが、これは影響を及ぼさない、ループの冗長動作である。この連続計算処理によって、ハードウェアは、不確定なコンテンツのサイズをベリファイすることができる。言い換えれば、ＭＡＣ値を適切に計算することができ、ブロックからなるファイルのブロック数またはサイズをまず確認する必要なく、完全性をハードウェアによってベリファイすることができる。
【００３３】
前述した処理は、メモリカードのフラッシュメモリ２０内に常駐する任意のデータについて、ある動作状態またはモード、特に完全性チェックモードにおいて使用される。本発明によるメモリカードの好ましい一実施形態において、当該データのいくらかは、実行されるとメモリカードを実行するファームウェアである。特に、システム１０の電源投入の際に、システムがその通常の動作状態またはテスト状態である場合に、暗号エンジン４０は、任意の入力データの完全性をベリファイするために、（完全性チェックモードにおいて開始することによって）暗号エンジン４０自体を初期化する。データがたまたまファームウェアである場合には、ＢＭＵ１４および特に暗号エンジン４０を通る際にファームウェアの完全性がベリファイされる。記憶された結果（完全性自体ではない）は、一実施形態において、ＲＯＭ１３に記憶されたコード内の命令を伴うソフトウェアによってチェックできる。注意すべきなのは、ＲＯＭ１３に記憶されたコードは結果をチェックするものの、データのフローを開始してもよく、これはフラッシュメモリ内のファームウェアの完全性をベリファイする際には含まれないということである。言い換えれば、コードは、ベリファイするためにファームウェアの数値計算もデータ操作も行う役割はない。ファームウェアの完全性をベリファイするのは、コントローラ１２またはＢＭＵ１４、ＦＷＩＣ３１、および暗号エンジン４０のハードウェアであり、これには、ブートローダ（ＢＬＲ）部分と、ある実施形態において、ファームウェアの他の部分も含まれる。
【００３４】
図５で説明した処理は、ハードウェア（ＨＷ）とファームウェア（ＦＷ）との両方が関与する。前述したように、ハードウェアが完全性チェックを行うのに対して、ファームウェアは、ＨＷ完全性チェックの末尾のフラグセットを単にチェックするだけである。ＨＷおよびＳＷの機能または「ループ」を、それぞれ図６および図７にさらに詳細に示す。
【００３５】
図６を参照すると、ステップ３２０において、システムに電源が投入される。ステップ３２２において、コントローラのハードウェアが、ＦＷ完全性モードを開始する。これは、２つの中心的な行為を備える。第１は、図１のＦＷＩＣ３１を作動させることである。いったん作動されたＦＷＩＣ３１は、図６の残りのステップをうまくまとめあげ、これによって、暗号エンジン４０と共に、ファームウェアのＢＬＲ部分の完全性をチェックする。第２の行為には、暗号エンジン４０によって使用される暗号アルゴリズムを選択することが含まれる。前述したように、暗号エンジン４０のハードウェアは、様々な互いに異なるアルゴリズムでデータを暗号化および復号化するように構成されている。
【００３６】
ステップ３２８において、コントローラのハードウェアは、入力ブロックのダイジェストを計算する。この計算は、暗号エンジン４０によって行われる。次に、ステップ３３０において、ステップ３２８において計算されたダイジェストを、以前のダイジェストの値と比較する。前述したように、値を保持するレジスタがチェックされて、ループの反復毎に比較されるが、最初の反復の際には、レジスタ内の値はランダムである。その後、完全性を示すフラグが、ステップ３３２において設定される。ＨＷがファームウェアのＢＬＲ部分の完全性をベリファイしたかを確認するために、このフラグがシステムのファームウェアによってチェックされることになる。
【００３７】
図７は、図６においてＨＷが完全性をチェックする一方で生じるファームウェアのループを示す。ステップ３２０においてシステムに電源が投入された後に、ステップ３４０においてＣＰＵが初期化される。その後、ステップ３４２において、構成データ（好ましい一実施形態において、図３のＦＩＤ１）が最初の有効ページに読み出される。次に、ステップ３４４において、システムは、ＢＬＲ ２０１Ａの開始および終了ページを抽出する。これがいったんわかると、ＢＬＲページのすべてが読み出される。各ページが読み出されるにつれて、誤り訂正符号（ＥＣＣ）が生成される。前述したように、ＥＣＣ回路動作は周知であり、データ内の物理的な誤りをある一定の限界まで訂正するために使用することができる。完全性ベリファイ処理と共にＥＣＣを使用することが好ましいが、これは必須ではなく、完全性は、ＥＣＣを使用してもしなくてもベリファイされる。ページが読み出された後に、ステップ３４８においてＥＣＣ回路でチェックされ、ＯＫでない場合には、ページはＥＣＣ訂正機構で訂正されるか、またはステップ３５２において代替のページが取り出されることになる。訂正または新規のページがＯＫであるとステップ３５４において判断されると、システムは、ステップ３５０において、読み出されるべきページがさらにあるかどうかをチェックする。そうである場合には、システムはステップ３４６へ戻り、他のページを読み出す。ステップ３５４において訂正されたまたは代替コピーがＯＫではないとステップ３５４が示す場合には、失敗状態がステップ３５６において示されることになる。ステップ３５０においてこれ以上ページがないと判断されると、失敗は示されず、システムは、完全性フラグ（図６に示すようにハードウェアによって設定されている）をステップ３６０においてチェックすることになる。ステップ３６０において、ＢＬＲがＯＫであるとフラグが示す場合には、ＨＷによってベリファイされたので、ステップ３６２においてＢＬＲが実行されることになる。この実行は、図４のステップ４４０において示したのと同じである。
【００３８】
この完全性チェックは、ファームウェアの一部分、すなわちＢＬＲについてのみ行われるが、ファームウェアのすべてもこのようにチェックすることができ、また、この説明はファームウェアのブートスラップを使用する好ましい実施形態に関することが理解されるべきである。加えて、本願において使用されるようなメモリカードという用語は、ＵＳＢフラッシュドライブの形式要因をも含んでいるつもりである。
【００３９】
本発明の様々な態様についてそれらの例示の実施形態に関して説明してきたが、本発明が、添付の特許請求の範囲の全範囲内においてその権利が保護されるべきであることが理解できよう。
【特許請求の範囲】
【請求項１】
動作を開始するとともにメモリ記憶装置を動作するための方法であって、
前記メモリ記憶装置の大容量記憶ユニット内に前記メモリ記憶装置のファームウェアを設けるステップと、
前記ファームウェアを前記メモリ記憶装置のハードウェアで実施される暗号化エンジンに通すステップと、
前記ファームウェアについてのハッシュ値を前記ハードウェアで実施される暗号化エンジンで計算するステップと、
計算されたハッシュ値を記憶されたハッシュ値と比較するステップと、
前記計算されたハッシュ値が前記記憶されたハッシュ値と一致する場合に、前記ファームウェアを実行するステップと、
を含む方法。
【請求項２】
メモリ記憶装置の動作を開始するための方法であって、
前記メモリ記憶装置の大容量記憶ユニット内に、前記メモリ記憶装置の動作を制御するファームウェアを設けるステップと、
前記ファームウェアを前記メモリ記憶装置の大容量記憶ユニットから前記メモリ記憶装置のランダムアクセスメモリへコピーする、読み出し専用メモリ内の第１の命令セットを実行するステップと、
前記ファームウェアを前記大容量記憶ユニットから前記メモリ記憶装置のメモリコントローラ内のハードウェアで実施される暗号化エンジンに通すときに、ファームウェアの完全性をベリファイするステップと、
完全性がベリファイされた後に、ランダムアクセスメモリからファームウェアをマイクロプロセッサで実行するステップと、
を含む方法。
【請求項３】
請求項２記載の方法において、
前記ファームウェアは、前記大容量記憶ユニットからさらなるファームウェアをフェッチするための命令を含む方法。
【請求項４】
請求項３記載の方法において、
さらなるファームウェアを実行するステップをさらに含む方法。
【請求項５】
請求項１記載の方法において、
前記ファームウェアを設けるステップは、複数のファームウェアオーバーレイを設けることを含む方法。
【請求項６】
請求項５記載の方法において、
複数のファームウェアオーバーレイのそれぞれのオーバーレイ内に、ハッシュを備えるオーバーレイを含む多数のファームウェアの計算されたハッシュ値に等しいことを期待されたハッシュ値を記憶するステップをさらに含む方法。
【請求項７】
請求項６記載の方法において、
読み出される多数のファームウェアの計算されたハッシュ値は、期待されたハッシュ値を含むセクタが読み出されたときに、期待されたハッシュ値だけに対応し得る方法。
【請求項８】
請求項６記載の方法において、
前記期待されたハッシュ値を含むセクタブロックまたはページ以外のセクタブロックまたはページ上の誤った肯定一致を無視するステップをさらに含む方法。
【請求項９】
請求項１記載の方法において、
前記ハッシュ値を計算するステップは、ＭＡＣ［０．．．（ｉ）］＝ＭＡＣ［ＭＡＣ［０．．．（ｉ−１）］，ｂｌｏｃｋ（ｉ）］でブロック（ｉ）についてのＭＡＣ値が計算されることを含むが、結果生じたＭＡＣ値はブロック０から（ｉ）までを対象として含む方法。
【請求項１０】
請求項９記載の方法において、
前記メモリ記憶装置のメモリコントローラの、前記大容量記憶ユニット内にはないレジスタ内にブロック（ｉ）についての計算されたＭＡＣ値を記憶するステップをさらに含む方法。
【請求項１１】
請求項９記載の方法において、
結果生じたＭＡＣ値がブロック０から（ｉ）までを対象として含むＭＡＣ［０．．．（ｉ）］＝ＭＡＣ［ＭＡＣ［０．．．（ｉ−１）］，ｂｌｏｃｋ（ｉ）］で前記ブロック（ｉ）についてのハッシュ値を計算するステップは、前記ファームウェアのブートローダに対して行われる方法。
【請求項１２】
請求項９記載の方法において、
結果生じたＭＡＣ値がブロック０から（ｉ）までを対象として含むＭＡＣ［０．．．（ｉ）］＝ＭＡＣ［ＭＡＣ［０．．．（ｉ−１）］，ｂｌｏｃｋ（ｉ）］で前記ブロック（ｉ）についてのハッシュ値を計算するステップは、前記ファームウェアのブートローダに対して行われるが、前記ファームウェア全体に対しては行われない方法。
【請求項１３】
請求項９記載の方法において、
結果生じたＭＡＣ値がブロック０から（ｉ）までを対象として含むＭＡＣ［０．．．（ｉ）］＝ＭＡＣ［ＭＡＣ［０．．．（ｉ−１）］，ｂｌｏｃｋ（ｉ）］で前記ブロック（ｉ）についてのハッシュ値を計算するステップは、前記ファームウェア全体に対して行われる方法。
【請求項１】
動作を開始するとともにメモリ記憶装置を動作するための方法であって、
前記メモリ記憶装置の大容量記憶ユニット内に前記メモリ記憶装置のファームウェアを設けるステップと、
前記ファームウェアを前記メモリ記憶装置のハードウェアで実施される暗号化エンジンに通すステップと、
前記ファームウェアについてのハッシュ値を前記ハードウェアで実施される暗号化エンジンで計算するステップと、
計算されたハッシュ値を記憶されたハッシュ値と比較するステップと、
前記計算されたハッシュ値が前記記憶されたハッシュ値と一致する場合に、前記ファームウェアを実行するステップと、
を含む方法。
【請求項２】
メモリ記憶装置の動作を開始するための方法であって、
前記メモリ記憶装置の大容量記憶ユニット内に、前記メモリ記憶装置の動作を制御するファームウェアを設けるステップと、
前記ファームウェアを前記メモリ記憶装置の大容量記憶ユニットから前記メモリ記憶装置のランダムアクセスメモリへコピーする、読み出し専用メモリ内の第１の命令セットを実行するステップと、
前記ファームウェアを前記大容量記憶ユニットから前記メモリ記憶装置のメモリコントローラ内のハードウェアで実施される暗号化エンジンに通すときに、ファームウェアの完全性をベリファイするステップと、
完全性がベリファイされた後に、ランダムアクセスメモリからファームウェアをマイクロプロセッサで実行するステップと、
を含む方法。
【請求項３】
請求項２記載の方法において、
前記ファームウェアは、前記大容量記憶ユニットからさらなるファームウェアをフェッチするための命令を含む方法。
【請求項４】
請求項３記載の方法において、
さらなるファームウェアを実行するステップをさらに含む方法。
【請求項５】
請求項１記載の方法において、
前記ファームウェアを設けるステップは、複数のファームウェアオーバーレイを設けることを含む方法。
【請求項６】
請求項５記載の方法において、
複数のファームウェアオーバーレイのそれぞれのオーバーレイ内に、ハッシュを備えるオーバーレイを含む多数のファームウェアの計算されたハッシュ値に等しいことを期待されたハッシュ値を記憶するステップをさらに含む方法。
【請求項７】
請求項６記載の方法において、
読み出される多数のファームウェアの計算されたハッシュ値は、期待されたハッシュ値を含むセクタが読み出されたときに、期待されたハッシュ値だけに対応し得る方法。
【請求項８】
請求項６記載の方法において、
前記期待されたハッシュ値を含むセクタブロックまたはページ以外のセクタブロックまたはページ上の誤った肯定一致を無視するステップをさらに含む方法。
【請求項９】
請求項１記載の方法において、
前記ハッシュ値を計算するステップは、ＭＡＣ［０．．．（ｉ）］＝ＭＡＣ［ＭＡＣ［０．．．（ｉ−１）］，ｂｌｏｃｋ（ｉ）］でブロック（ｉ）についてのＭＡＣ値が計算されることを含むが、結果生じたＭＡＣ値はブロック０から（ｉ）までを対象として含む方法。
【請求項１０】
請求項９記載の方法において、
前記メモリ記憶装置のメモリコントローラの、前記大容量記憶ユニット内にはないレジスタ内にブロック（ｉ）についての計算されたＭＡＣ値を記憶するステップをさらに含む方法。
【請求項１１】
請求項９記載の方法において、
結果生じたＭＡＣ値がブロック０から（ｉ）までを対象として含むＭＡＣ［０．．．（ｉ）］＝ＭＡＣ［ＭＡＣ［０．．．（ｉ−１）］，ｂｌｏｃｋ（ｉ）］で前記ブロック（ｉ）についてのハッシュ値を計算するステップは、前記ファームウェアのブートローダに対して行われる方法。
【請求項１２】
請求項９記載の方法において、
結果生じたＭＡＣ値がブロック０から（ｉ）までを対象として含むＭＡＣ［０．．．（ｉ）］＝ＭＡＣ［ＭＡＣ［０．．．（ｉ−１）］，ｂｌｏｃｋ（ｉ）］で前記ブロック（ｉ）についてのハッシュ値を計算するステップは、前記ファームウェアのブートローダに対して行われるが、前記ファームウェア全体に対しては行われない方法。
【請求項１３】
請求項９記載の方法において、
結果生じたＭＡＣ値がブロック０から（ｉ）までを対象として含むＭＡＣ［０．．．（ｉ）］＝ＭＡＣ［ＭＡＣ［０．．．（ｉ−１）］，ｂｌｏｃｋ（ｉ）］で前記ブロック（ｉ）についてのハッシュ値を計算するステップは、前記ファームウェア全体に対して行われる方法。
【図１Ａ】
【図１Ｂ】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図１Ｂ】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２０１１−２１０２７８（Ｐ２０１１−２１０２７８Ａ）
【公開日】平成２３年１０月２０日（２０１１．１０．２０）
【国際特許分類】
【出願番号】特願２０１１−１３７４１６（Ｐ２０１１−１３７４１６）
【出願日】平成２３年６月２１日（２０１１．６．２１）
【分割の表示】特願２００８−５３１３２４（Ｐ２００８−５３１３２４）の分割
【原出願日】平成１８年９月１３日（２００６．９．１３）
【出願人】（５０６１９７９０１）サンディスク コーポレイション (175)
【Ｆターム（参考）】
【公開日】平成２３年１０月２０日（２０１１．１０．２０）
【国際特許分類】
【出願日】平成２３年６月２１日（２０１１．６．２１）
【分割の表示】特願２００８−５３１３２４（Ｐ２００８−５３１３２４）の分割
【原出願日】平成１８年９月１３日（２００６．９．１３）
【出願人】（５０６１９７９０１）サンディスク コーポレイション (175)
【Ｆターム（参考）】
[ Back to top ]