JP5175856B2 - セキュアデバイス・システムにおけるフラッシュメモリ・ブロックの保護と方法 - Google Patents

Description

データ秘密性と信憑性が実質滴に必要条件となるコンシューマー向け装置(consumer devices)や器具(appliances)において、フラッシュメモリは世界的に普及するに至った。フラッシュメモリ・デバイス上のデータに対して秘密性と信憑性を提供するために数々の技術が使われている。セキュリティ機構は、そのようなフラッシュメモリ・デバイスドライバに実装されてもよいし、オペレーティング・システムの実装に関連してもよい。

データの暗号化と復号化は、コンピュータのデータ記憶装置に通常よくあることである。データを格納する際に、暗号化技術がしばしば使われる。このような技術を使うことで不正アクセスからセキュリティレベルが確保されるが、異なったコンピュータプラットホームにもかかわらず、データを格納したり、記憶装置からデータを読み込んだりする際には同じ暗号化方法を使っているという現実がある。これらの方法には、以下のものに限定されるわけではないが、データ暗号規格（ＤＥＳ）、新暗号規格（ＡＥＳ）、及びＳＨＡ（セキュア・ハッシュ・アルゴリズム）がある。異なるプラットホームにもかかわらず共通の暗号化方法を用いているため、仮にある者が鍵を入手した場合(access to the key)、１台のコンピュータから記憶装置を取り外し、同じ方法を使う他のコンピュータ上で暗号化されたデータを読み込むことが可能である。セキュリティを十分にするには、鍵はあらゆるプラットホームで共通な鍵であってはいけない。さもなければセキュリティはその単一鍵だけの秘密保持性に依存することになるだろう。

幾つかのアプリケーションでは、メッセージ認証コード（例：ＨＭＡＣｓ）が、メッセージブロックのための認証検証データを提供するのに使用される。データブロックにおいてＭＡＣを格納することは、許容データや読み書き性能オーバーヘッドを生み出さなければならない。１つの望ましい特徴は、フラッシュメモリ・デバイスにおけるビットエラーに対し堅牢な方法を提供することにある。もう１つの望ましい特徴は、複数アプリケーションからのデータが、オペレーティング・システムにおいて互いにプロテクトされるべきであることである。即ち、あるアプリケーションをアクセスに用いて、別のアプリケーションやそのデータを制御したり変更したりできることがあってはならない。

ＵＳＢフラッシュドライブは、フラッシュメモリを使用する一般的な記憶装置であり、その比較的小さなサイズがエンドユーザに対しコンピュータ情報やそこに格納されたデータのポータビリティを容易にする。例えば、エンドユーザは、１台のコンピュータのＵＳＢポートにフラッシュドライブデバイスを装着し、情報をこのデバイスに格納し、デバイスを取り外して別のコンピュータのＵＳＢポートに装着し、格納された情報を読み込むことができる。データが１つのプラットホームによって暗号化されたとしても、鍵がそのプラットホームによってプロテクトされない限りは、共通な暗号化技術を他のプラットホーム上で用いることでそのデータはセキュアだとは言えなくなる。加えて、フラッシュメモリ・デバイスへの読み書きを可能にする様々なデバイスが、消費者にとって入手可能な状態で存在する。このため、フラッシュメモリ・デバイスをセキュリティ違反からプロテクトするような、更なるセキュリティ機構が必要である。

上述したこれら関連技術の例や制限事項は、あくまで説明に役立つものとして例証したものであって排他的ではない。関連技術の他の制限事項は、当該技術者が本願明細書を読み、図面を検討することにより明らかになるであろう。

フラッシュメモリ・デバイスやそれに不可欠なデータブロックに対してセキュリティ対策を提供する技術は、１つのコンピュータプラットホームにインストールされた状態におけるデバイスに特有の情報変数(informational variables)を抜粋して、使用するといったような暗号法の採用を含む。データブロックは、フラッシュメモリ・デバイスにおけるデータのアクセス単位である。フラッシュメモリ・デバイスのデータブロックは、消費者に入手可能な種々のデバイスを使用することで読み書き可能となるため、フラッシュメモリ・デバイスのセキュリティ違反に対してプロテクトする機構が必要である。

１つの具体的な実施形態では、データブロックに書かれたデータは暗号化され、ＭＡＣは認証のために使用される。データブロックから読み込まれたデータは復号化され、ＭＡＣは検証される。その順番は交換可能である。代表的なセキュアデバイスでは、セキュリティカーネルは認証付きで読み込まれ、セキュア・オブジェクトストア(secure object store)や、様々なクライアントに対するAPIインターフェースをサポートする。暗号化/復号化機能、ＭＡＣの計算、及びデータ検証は、セキュリティカーネルで実行されるものである。セキュリティカーネルは、鍵データベースにおける鍵をプロテクトし、鍵のオーナーシップを強化し、機密性を維持する。鍵は、別のＩ／Ｏドライバ、例えばネットワーク・ドライバにアクセスすることはできない。フラッシュデバイス・ドライバに対応する鍵は、セキュリティカーネルにアクセス可能な不揮発性メモリに格納されるか、さもなければ乱数発生器（RNG）を使用して内部的に生成され格納されても良い。セキュリティカーネルは、アプリケーション・プログラミング・インターフェース（API）を介してオペレーティング・システムとのインターフェースを取り、フラッシュ・オペレーティング・システムだけが暗号化/復号化やＭＡＣの計算、及びデータ検証のために鍵を獲得するのを可能にしている。鍵は、API境界を超えて露出(exposed)されることはない。セキュリティカーネルによって発呼者を特定することができ、鍵使用の際のプロテクトを強化することができる。そのようなプロテクトがなければ、他のＩ／Ｏドライバやアプリケーションを使用し、セキュリティAPIにアクセスできる如何なるクライアントのソフトウェアやデータを侵害することで、フラッシュ・オペレーティング・システムのセキュリティが壊される可能性もある。

本発明の実施形態を図面に示す。しかしながら、ここに示した実施形態と図面は、本発明を制限するものというよりむしろ説明するためのものであって、本発明の例を提供するものである。
ここで説明される技術を実施するのに適したコンピュータ・システムを示す図である。 ここで説明される技術を実施するのに適したセキュアシステムの例を示す図である。 フラッシュメモリ・デバイスの例を示す図である。 バージョン管理されたファイルを格納する方法の例のフローチャートである。 バージョン管理されたファイルを読み込む方法の例のフローチャートである。

以下の説明では、本発明の実施形態の十分な理解を与えるために幾つかの特定の具体的な構成が提示される。しかし、当業者であれば、１つ以上のこれら特定の具体的な構成がなくとも、あるいは他の構成部などとの組み合わせにより、本発明を実施することが可能であることが理解されるであろう。また別の例では、様々な実施形態における本発明の特徴を曖昧にすることを避けるため、周知の具体的構成や動作は、図示または詳細に説明されていない。

図１はここで説明される技術の実施に適するコンピュータ・システム１００を示している。コンピュータ・システム１００は、コンピュータ１０２、I/Oデバイス１０４、及びディスプレイデバイス１０６を含む。コンピュータ１０２は、プロセッサ１０８、通信インターフェース１１０、メモリ１１２、ディスプレイコントローラ１１４、不揮発性記憶装置１１６、及びI/Oコントローラ１１８を含む。コンピュータ１０２は、I/Oデバイス１０４とディスプレイデバイス１０６に接続する形でも、あるいはそれらを含む形でも良い。

コンピュータ１０２は、モデムやネットワークインターフェースを含んでもよい通信インターフェース１１０を介し、外部システムと接続する。通信インターフェース１１０は、コンピュータ・システム１００の一部かコンピュータ１０２の一部として考えることができる。通信インターフェース１１０は、アナログ・モデム、ISDNモデム、ケーブルモデム、トークン・リング・インタフェース、衛星通信インターフェース（例えば、“ダイレクトＰＣ”）、又は１つのコンピュータ・システムを他のコンピュータ・システムに接続する他のインターフェースのいずれでも良い。従来のコンピュータは通常、一種の通信インターフェースを備えるが、インターフェースを含まないコンピュータを作成することで、通信インターフェース１１０を厳密な意味で任意的なものとすることができる。

プロセッサ１０８は、それに限定されない一例として、インテル社のペンティアム（登録商標）マイクロプロセッサやモトローラ社のパワーＰＣマイクロプロセッサなどの従来マイクロプロセッサを具備しても良い。プロセッサ１０８は、総ての従来型コンピュータにとって重要な部品と言えるが、ここで説明した技術を実施するためには、適用可能な如何なる公知の（又は手頃な）プロセッサを使用することも可能である。メモリ１１２は、バス１２０によって、プロセッサ１０８に接続される。メモリ１１２（以下、“主記憶装置(primary memory)”と呼ぶこともある）は、ダイナミック・ランダムアクセス・メモリ（ＤＲＡＭ）を備えたり、またスタティック・ラム（ＳＲＡＭ）を備えたりすることも可能である。バス１２０は、プロセッサ１０８をメモリ１１２に接続したり、又不揮発性記憶装置１１６にも、ディスプレイコントローラ１１４にも、更にI/Oコントローラ１１８にも接続したりすることができる。

I/Oデバイス１０４は、キーボード、ディスクドライブ、プリンタ、スキャナ、及びマウスか他のポインティング・デバイスを含む他の入出力装置を含むことができる。説明のため、これらI/Oデバイスの少なくとも１つを、DVDプレーヤーのようなブロックベースドメディアデバイスと仮定する。ディスプレイコントローラ１１４は、公知の又は手頃な方法で、ディスプレイデバイス１０６上のディスプレイを制御しても良く、ディスプレイデバイス１０６は、例えば、ブラウン管（ＣＲＴ）だったり、液晶ディスプレイ（ＬＣＤ）だったりする。

ディスプレイコントローラ１１４とI/Oコントローラ１１８はデバイスドライバを具備しても良い。デバイスドライバは、ハードウェアデバイスとの相互作用を可能にするべく開発された特定のコンピュータ・ソフトウェアである。通常、これは、デバイスと通信するためのインターフェースを構成し、ハードウェアが接続されるバスや通信サブシステムを介し、デバイスへの命令送信及び／又はデバイスからのデータ受信を実行する一方、必要不可欠なものはOSとソフトウェアアプリケーションと相互作用する。

デバイスドライバは、OS特有でもあるハードウェア依存型コンピュータ・プログラムを含んでもよい。そのコンピュータ・プログラムにより、別のプログラム（通常OS、アプリケーションソフトウェアパッケージ、又はOSカーネル上で動くコンピュータ・プログラム）は、透過的にハードウェアデバイスと相互作用することができ、同コンピュータ・プログラムは通常、ニーズと調和した如何なる必要な非同期・時間依存型ハードウェアにも必要不可欠な割り込み処理を提供する。

往々にして不揮発性記憶装置１１６（以下、“補助記憶装置(secondary memory)”と呼ぶこともある）は、磁気ハードディスクだったり、光ディスクだったり、或いは大量データ用の他の種類の記憶装置だったりする。このデータのいくつかはしばしば、コンピュータ１０２でソフトウェアを実行している間に、ダイレクトメモリアクセスプロセスによってメモリ１１２に書き込まれる。不揮発性記憶装置１１６は、ブロックベースドメディアデバイスを含むものでも良い。“機械可読メディア”や“コンピュータ可読メディア”という用語は、プロセッサ１０８によってアクセス可能であって、データ信号を符号化する搬送波を包含する如何なる公知の（又は手頃な）記憶装置をも含んでいる。

コンピュータ・システム１００は、異なったアーキテクチャを持っている多くの実行可能なコンピュータ・システムの一例である。例えば、インテルマイクロプロセッサをベースとするパーソナルコンピュータは往々にして複数のバスを有し、その１つは周辺機器へのI/Oバスであったり、プロセッサ１０８とメモリ１１２を直接接続するもの（しばしば“メモリバス”と呼ばれる）であったりする。これらのバスは、バスプロトコルが異なることによって必要とされる如何なる変換(translation)を実行できるブリッジコンポーネントを介して接続される。

ネットワーク・コンピュータは、ここで提供した教示に関連して使用可能な別のタイプのコンピュータ・システムである。通常、ネットワーク・コンピュータはハードディスクや他の大容量記憶装置を備えておらず、実行可能プログラムは、プロセッサ４０８による実行のために、ネットワーク接続からメモリ１１２に取り込まれる。当該技術では既知のウェブテレビシステムも又、１つのコンピュータ・システムと考えることもできるが、ある入力や出力装置のように図１に示した特徴の幾つかを欠く可能性がある。通常、一般的なコンピュータ・システムは、少なくともプロセッサ、メモリ、メモリをプロセッサに接続するバスを具備することになる。

オペレーティングシステム（OS）でコンピュータ・システム１００を制御しても良い。OSは、全部ではないが殆どのコンピュータ・システムに使用されるソフトウェアプログラムであって、コンピュータのハードウェア及びソフトウェア・リソースを管理している。通常、OSは、メモリを制御して割り当てをしたり、システムの要求に優先順位を付けたり、入出力装置を制御したり、ネットワーキングを補助したり、ファイルを管理するといったような基本タスクを実行するものである。パーソナルコンピュータ用オペレーティングシステムの例としては、マイクロソフト社のウインドウズ（登録商標）やビスタ（登録商標）、リナックス、マックOS（登録商標）などがある。OSとアプリケーション・ソフトウエアとの間の線引きは往々にしてかなり難しい。幸いにも、何らかのリーズナブルな線引きで十分であるため、本願で説明した技術を理解するのにこの線引きは不要である。

通常、OSは、慣例的な階層化ディレクトリと、フラッシュメモリ・デバイスに格納されたデータのファイルベースド組織(file based organization)を提供する。加えて、OSはディレクトリやファイル上における読み（read）、書き(write)、及び承認の実行(execute permissions)に基づく代表的なアクセスコントロールを実行する。それ自体、セキュアデバイス上で認証されたセキュアOSの一部であるオペレーティング・システムを介してフラッシュへのデータアクセスがなされる際に、上記アクセスコントロールが実行される。

最も低いレベルのOSとしては、その（OSの）カーネルであっても良い。通常、カーネルは、システムブートや、スタートアップする際にメモリに取り込まれるソフトウェアの第１の層(first layer)である。カーネルは、他のシステムやアプリケーション・プログラムに対する様々な共通コアサービスへのアクセスを提供する。

ここに使用されたように、コンピュータメモリ中のデータ・ビットにおける操作のアルゴリズム的記述と象徴(symbolic representations)は、当業者に対し最も効果的に技術を伝えるものと思われる。アルゴリズムという用語は、ここで使用するとき、また一般に使用されるとき、所望の結果を導き出す動作(operations)の首尾一貫したシーケンス（self-consistent sequence）と考えられる。この動作は、物理量の物理的な操作(manipulations)を必要とするものである。必ずしも必要ではないが、通常、こうした量は、格納、転送、結合、比較、及び他の操作を行うことができる電気、または磁気の信号の形を取る。時には、主に一般的な使用のために、こうした信号をビット(bits)、値(values)、要素(elements)、記号(symbols)、文字(characters)、項(terms)、数字(numbers)などと呼ぶのが便利であることがわかっている。

しかしながら、これら、及びこれらと同様の用語はすべて、適切な物理量に関連付けられ、単にこうした量に適用される手頃なラベル(labels)にすぎないことを心に留めておくべきである。特に明記しない限り、または下記の記述から明らかであるように、“処理する(processing)”、“演算する(computing)”、“計算する(calculating)”、“決定する(determining)”、“表示する(displaying)”などの用語は、コンピュータ・システムのレジスタおよびメモリ内の物理的な（電子）量として表されるデータを操作し、コンピュータ・システムのメモリまたはレジスタ、または他のこうした情報記憶装置、送信装置またはディスプレイデバイス内の同じように物理（電子）量として表される他のデータに変換するコンピュータの動作および処理(process)を指す。

ここで説明した技術を実施するための装置は、要求された目的のためにそれ専用に構成しても良く、又コンピュータに格納されたコンピュータ・プログラムによって選択的に起動(activated)されたり再構成(reconfigured)されたりする汎用コンピュータから成るものでも良い。そのようなコンピュータ・プログラムは、それらに限定されるものではないが例えば、リードオンリメモリ(ROM)、ランダムアクセスメモリ(RAM)、EPROM、EEPROM、磁気又は光学カード、フレキシブルディスクを含む如何なるタイプのディスク、光ディスク、CD-ROM、DVD、光磁気ディスク、或いは電子的な指示(instructions)を格納するのに適した如何なる公知の（又は手頃な）の媒体のような、コンピュータ可読記憶媒体に格納されても良い。

ここに提示されたアルゴリズムとディスプレイは本来、如何なる特定コンピュータ・アーキテクチャにも関連するものではない。この技術は、高いレベル（例えば、C/C++）であろうと低レベル（例えば、アセンブリ言語）だろうと、又インタープリタ型（例えば、Perl）だろうと、コンパイラ型（例えば、C/C++）だろうと、バイトコード（例えば、Java（登録商標））からコンパイルされるジャストインタイム（JIT）であろうと、如何なる公知の（又は手頃な）プログラミング言語を使用して実施されても良い。どんな公知の（又は手頃な）コンピュータでも、アーキテクチャに関係なく、コンパイルされた機械コードか、さもなければ何らかの言語からコンピュータ・アーキテクチャと互換性がある機械コードへとアセンブルされた機械コードを実行することが可能でなければならない。

図２は、ここに記載した技術を実施するのに適していたセキュアシステム２００の一例を示している。代表的なセキュアシステム５００は、ペイ・パー・ビュー方式の装置(pay-per-view device)、ゲーム機、メディアプレーヤー、埋め込み型(embedded)セキュアデバイス、セキュアプロセッサ付き“従来型”PC、或いはセキュアプロセッサを備える他のコンピュータ・システムを備えても良い。

図２の例においてセキュアシステム２００は、セキュアプロセッサ２０２、OS２０４、フラッシュメモリ・デバイスドライバ２０６、フラッシュメモリ・デバイス２０８、及びプロテクト・メモリ５１０を含む。図５の例ではOS２０４は、鍵ストア２１６、暗号化/復号化エンジン２１６、及びセキュリティAPI２１８を順に含むセキュリティカーネル２１２を有する。別の実施形態では、セキュリティカーネル２１２に乱数発生器（RNG）（図示せず）を設けても良い。上述したこれら部品の１つ又はそれ以上、或いはその一部を、プロテクト・メモリ５１０又はプロテクトされていないメモリ（図示せず）に属させるようにしても良いことを留意すべきである。

さらに留意すべきは、慣例だけによって、セキュリティカーネル２１２が、OS５０４に属するように表現されていることである。実際にOS２０４の一部であってもなくても良く、OSの外側に存在することも、或いはOSを含まないシステム上に存在することも可能である。説明を簡単にする目的で、OS２０４は認証可能であることが前提である。実施形態では、フラッシュメモリ・デバイスドライバ２０６は、OS２０４の一部であっても良い。認証付きのフラッシュメモリ・デバイスドライバ２０６を読み込むこと(loading)が、セキュリティを向上できるという理由で、これは望ましいかもしれない。

フラッシュメモリ・デバイス２０８として使用可能なフラッシュメモリ・デバイスの例を、図３を参照して説明する。フラッシュメモリ・デバイスドライバ２０６は、フラッシュメモリ・デバイス２０８にデータを保存すると共に、同デバイスからデータを読み込む。フラッシュメモリ・デバイスドライバ２０６は、自身に関連した独自のプロテクト鍵または秘密鍵を有し、同鍵はセキュリティカーネル２１２の鍵ストア２１４に格納される。これに代えて、プロテクト鍵が、セキュリティカーネル２１２に格納された乱数発生器（RNG）（図示せず）機能を用いて記憶されるようにしても良い。セキュリティカーネル２１２はプロテクト鍵の使用を実行する。一実施形態では、フラッシュメモリ・デバイスドライバ２０６は、セキュリティカーネル２１２にある鍵ストア２１４内に鍵を所有し、同鍵は、例えばネットワーキングのような別のＩ／Ｏドライバによってアクセス不可能になっている。セキュリティカーネル２１２は、セキュリティAPI２１８に対して露出され(is exposed)、フラッシュメモリ・デバイスドライバ２０６は、メッセージ認証コード（ＭＡＣ）や鍵付きハッシュメッセージ認証コード（ＨＭＡＣ）を暗号化したり復号化したり、又は計算したりするために、プロテクト鍵を使用しても良い。

説明の簡略化のために、プロテクト・メモリ２１０は単一メモリとして示される。しかしながら、このプロテクト・メモリ２１０は、プロテクトされた主記憶装置、プロテクトされた補助記憶装置、及び／又は、シークレットメモリを含んでも良い。メモリがプロテクトされるのを確実とするためには、公知の（又は手頃な）メカニズムが適所にあることが前提である。主記憶装置と補助記憶装置との間、及び／又は、揮発性記憶装置と不揮発性記憶装置との間のインタープレイ(interplay)は、公知であるため、様々な種類のメモリと記憶装置の間の区別は図２に関しては示されていない。

一実施形態では、セキュリティカーネル２１２が、起動時点において読み込み(loaded)されてもよい。別の実施形態では、セキュリティカーネル２１２の一部が、起動時点において読み込みされ、残りが後で読み込みされても良い。セキュアな方法（技術的に安全性が保証された方法、in a secure manner）で、セキュリティカーネル２１２を読み込みするべく、如何なる公知の（又は手頃な）技術も使用可能である。

鍵ストア２１４は、フラッシュメモリ・デバイスドライバ２０６のプロテクト鍵のような鍵のための格納場所群からなる。鍵を格納するのに使用されるデータ構造は重要な意味をもつものではないが、鍵ストア２１４は、鍵の一配列と思われても良い。鍵を格納するために、適用可能な如何なる公知の（又は、手頃な）構造も使用可能である。非限定的な実施形態では、鍵ストア２１４は、静的な(static)鍵を以て初期化されるが、可変鍵(variable keys)は初期化されない（或いは、セキュアでない値に初期化される）。例えば、幾つかの鍵ストア位置(key store locations)は、認証されたセキュリティカーネル２１２の読み込み(loading)の一部としての信頼値（例えば信頼ルート鍵）で予備充填(pre-filled)される。不揮発性メモリにおけるプライベートキーは、ここから取り出すことも、また将来の使用に備えて鍵ストアに格納することも可能である。

一実施形態において、暗号化/復号化エンジン２１６は、暗号化と復号化の両方が可能である。例えば、かかる動作において、アプリケーションは、セキュリティAPI２１８に、アプリケーションが暗号化に使用できるというキーハンドルを要求するかもしれない。
暗号化/復号化エンジン２１６を、キーハンドルを使用してデータを暗号化するのに使用しても良い。好都合なことには、セキュリティAPI２１８は、キーハンドルを平文で提供するが、鍵そのものは決してセキュリティカーネル２１２から離れることはない。

セキュリティAPI２１８は、鍵を明らかにすることなく（すなわち、鍵がセキュリティカーネル２１２を離れないか、或いは暗号化される場合にだけに限って鍵がセキュリティカーネル２１２を離れるような状態で）、鍵ストア２１４内の鍵を使用した動作を実行することができる。セキュリティAPI２１８は、鍵ストア２１４で鍵（そして潜在的には、他のセキュリティマテリアル）を作成(create)し、投入(populate)し、使用するためのサービスを含んでも良い。また、一実施形態では、セキュリティAPI２１８は、秘密鍵とデバイス・プライベートキーを含む、内部の秘密と不揮発性データへのアクセスを与える。例えば、フラッシュメモリ・デバイスドライバ２０６のプライベートキーは、鍵ストア２１４に格納されたり、セキュリティAPI２１８に使用されたりするかもしれない。１つのAPI呼び出し(API call)が、（ここで記述した、証明書を作成するためのアルゴリズムを用いて）デバイス証明書を戻すために使用されることも可能である。また復号化のための共用鍵を算出するためにプライベートキーを使用したり、メッセージや証明書に署名するためにプライベートキーを使用したりするために、別のAPI呼び出しが構成されることが可能である。実装の形態によっては、セキュリティAPI２１８は、ハードウェア加速を使用することで暗号化オペレーションをサポートするようにしても良い。

図３は、フラッシュメモリ・デバイス３００の一例を示している。フラッシュメモリ・デバイス３００は、フラッシュヘッダ３０２と、データブロック３０４−１〜３０４−Ｎ（以下、データブロック３０４と総称する）を含む。１つの具体的な実施形態では、フラッシュヘッダ３０２は、後述するフラッシュメモリ・デバイス用グローバルバージョン番号（ＧＶＮ＿ｆ）を含む。

１つ又はそれ以上のデータブロック３０４は、フラッシュメモリ・デバイス３００に格納されたファイルと関連性を持つ。データブロック３０４は、各メタデータ３０６−１〜３０６−Ｎ（以下、メタデータ３０６と総称する）と、格納データ３０８−１〜３０８−Ｎ（以下、格納データ３０８と総称する）とを含む。データブロック３０４における格納データ３０８は、（一例であってこれらに限定されるものではないが）ＤＥＳやＡＥＳのような暗号化関数を使って暗号化されても良い。 以下で説明される具体的な実施形態では、各データブロックは、後述するＭＡＣとファイルバージョン番号（ＶＮ＿ｆ）によってプロテクトされる。

１つの具体的な実施形態で、メタデータ３０６は、フラッシュページの予備エリアに格納される。予備エリアは、物理的に格納データ３０８を含んだデータエリアの前に、データエリアの後に、或いはデータエリアそのものの内部に位置されてもよい。図３の例で、メタデータ３０６が、格納データ３０８の“上方”に記述されているのは、あくまで例証目的で示されたものであって、それに限定した形で構成されるべきではない。

オペレーティング・システムまたはセキュリティカーネルは、フラッシュメモリ・デバイスドライバの使用を介して、慣例的な階層化ディレクトリやフラッシュメモリ・デバイス３００に格納されるファイル構造を提供しても良い。更に、オペレーティング・システムまたはセキュリティカーネルは、フラッシュメモリ・デバイス３００に格納されたファイル上における読み（read）、書き(write)、及び承認の実行(execute permissions)に基づく代表的なアクセスコントロールを実施してもよい。このアクセスコントロールは、格納データ３０８へのアクセス要求がセキュアデバイスによってなされた時に実行されるようにしても良い。フラッシュメモリ・デバイス３００を取り外したり、セキュアデバイス外のデバイスを異なるデバイス上で読み込んだり、再プログラミングしたりすることでセキュアデバイスのプロテクションを避けるといったようなセキュリティ違反に対して、上述したアクセスコントールが、単独でデバイスをプロテクトするものではない。顧客によっては、フラッシュメモリ・デバイス３００を読み込み可能にするだけでなく、書き込み可能にするような種々の公知の（又は手頃な）デバイスを使用する可能性もある。このようなことに対処するべく、更なるセキュリティ機構が求められるかも知れない。

１つの具体的な実施形態では、データブロック３０４に対しセキュリティを提供するために、各データブロック３０４に格納されたデータ３０８が暗号化され、算出されたＭＡＣが、ブロックと共に格納される。逆に、各データブロック３０４から読み出された格納データ３０８は復号化され、算出されたＭＡＣが検証される。この順番については取り換え可能である。

ＭＡＣの演算
ＭＡＣを計算するために、多くの変数が強制的にフラッシュメモリ・データブロックに含められる場合がある。１つの具体的な実施形態では、ＭＡＣ計算の一部として、有益なデータ(informative data)の包含が、セキュリティカーネル内の信頼できるソフトウェア(trusted software)によって実行される。この実施形態の特定の実施態様において、この信頼できるソフトウェアとフラッシュデバイス・ドライバは、フラッシュメモリにアクセスする唯一の手段であって、言い換えればハードウェア及びソフトウェア機構によって実行されてもよい。これは、仮にフラッシュメモリ・デバイスが改竄された場合、各データブロックにある格納データが使用不可能になるのを潜在的に確実にしている。

適当なＨＭＡＣを計算するために、特定の信頼できるデバイスドライバのみが関連する鍵や有益なデータへのアクセスが許される。セキュリティカーネルにより、オペレーティング・システムの他の部分や信頼されていないソフトウェアによってフラッシュデバイス上に有効な(usable)又は検証可能なデータを作成することが防止される。この処理は、セキュリティカーネルが、セキュリティAPIの発呼者(caller)を特定するために、特別に許可されたデータ(privileged data)を使用することで実行される。例えば、このデータとしては、プロセスＩＤ(process ID)、スレッドＩＤ(thread ID)、ユーザＩＤ(user ID)、及びオーナーシップスペースを分離するその他の技術を含むかもしれない。

ＭＡＣの計算に含められることができる１つの値(one value)は、各ファイルに割り当てられかつ従来のファイルメタデータとしてフラッシュヘッダに格納される独自の数値(unique value)である。ＭＡＣの計算に含められることができる別の値は、各フラッシュメモリ・データブロックの論理ブロックインデックスを示し、かつ予備エリアに格納される数値である。 ＭＡＣの計算に含められることができる他の変数は、物理的なブロック番号、所有者ＩＤ、アプリケーション又はコンピュータ・システムいずれかの変数、或いはアプリケーションＩＤ変数を含む。加えて、アプリケーションは、ＩＤに対し、アプリケーションによって管理されるファイルに書き込まれるデータにタグ付けを要求することができる。このタグ付きＩＤは、ＭＡＣの計算に含められることができる。このようにしてアプリケーションにより、２つの管理ファイルのデータブロック同士の他方からのプロテクトを管理することができる。

認証コード作成方法の１つの具体的な実施形態では、データが配列であることを条件として、数値ＨＭＡＣｈ＝ＨＭＡＣ（データ）の関係を作るかもしれない。そのような実施形態では、ユーザがデータ配列を供給するかもしれないし、セキュリティカーネルが幾つかの強制的な数値(mandatory values)を付加するかもしれない。例えば、ｈ＝ＨＭＡＣ（データ、ファイル名、ブロック番号、物理アドレス）で表される。場合によっては、アプリケーションは、タグ付きＩＤの追加を要求するかもしれない。例えば、APIへのインプットとして、ユーザはデータ配列とタグ付きＩＤを供給してもよく、セキュリティカーネルは、以下のように計算してもよい。ｈ＝ＨＭＡＣ（データ、ファイル名、ブロック番号、物理アドレス、タグ付きＩＤ）

カーネルにおける検証のために同じ固定次数(fixed order)が使用される限り、これらの量の配置（location）とシーケンスは固定的でなく、実際には変えることができる。重要な点は、これらの量のこのタグ付けは、発呼者によってこのデバイス上で削除したり制御したり任意に処置することが不可能であるということである。信頼できるカーネルは、データのブロックに認証情報を追加するために必要なルールを施行するであろう。

データのバージョン管理(Versioning the Data)
使用目的によっては、旧バージョンへの逆行を回避するべく、フラッシュメモリ・デバイス内において現行又は最新バージョンのファイルやデータを維持することが望ましい。ユーザがフラッシュメモリ・デバイスを置き換え、フラッシュメモリ・データブロック内の格納データを操作するのを防止するため、これはクライアントのためのプロテクトを提供することになる。仮に、使用データや消費情報、やペイ・パー・ビュー方式の情報がフラッシュメモリ・デバイスに格納されるならば、このようなことは特に好ましいこととなる。これは又、情報が最新バージョン番号に更新されたり維持されたりすべきものである、サーバの有効性や取消しリストのようなセキュリティ情報を格納することに有益であるかもしれない。強制的なセキュリティ更新を含み、ソフトウェア・パッチング及び更新機構は、セキュアなバージョン管理を実行する上でこの特徴を利用することもできる。

１つの具体的な実施形態では、セキュリティカーネルは、バージョン番号の正確な増加を実行する。セキュリティカーネルは、セキュアな不揮発性メモリにＧＶＮ＿ｎを格納してもよい。この番号は、何らかのバージョン管理されたファイル(versioned file)が更新された際に更新され、例えば、キュリティカーネルに対してAPI呼び出しをすることによるオペレーティング・システムによって、アクセス可能であり、また更新可能でもある。

フラッシュメモリ・デバイスのフラッシュヘッダには、ＧＶＮ＿ｎ値と同期し得るＧＶＮ＿ｆ値を含むファイルシステム・メタデータを含ませることも可能である。本実施形態では、このメタデータはそれ自体、如何なる必要な（又は望ましい）有益な値を使って作成されたＭＡＣによってプロテクトされている。フラッシュヘッダは、バージョン番号、フラッシュメモリ・デバイスに格納された各ファイルに夫々関連したＶＮ＿ｆも含んでも良い。

バージョン管理可能なファイルのバージョン番号が変わった時は、ファイルに関連したＶＮ＿ｆが更新され、ＧＶＮ＿ｆやＧＶＮ＿ｎも続いて更新され、ＭＡＣは再計算され、結果として得られたＭＡＣが格納されることになる。即ち、ファイルのバージョン番号における変化は、そのファイルに関連したデータブロック・セットのＭＡＣに影響する。この実施形態におけるＧＶＮ＿ｎは、チップ内部の不揮発メモリの一部を成しており、セキュリティカーネルにアクセス可能であり、とりわけセキュリティカーネルの改竄に対する抵抗力を強くしている。これによりフレキシブルな機構が提供され、結果としてセキュアなチップ上でのハードウェア・セキュリティが拡大され、フラッシュメモリ・デバイス条におけるセキュアなバージョン管理が実行され、そのバージョン管理(versioning)を使用するファイルにのみ該バージョン管理が適用される。この後者の方法は、不揮発性メモリへの書き込み回数が節約されるべきものである場合に有効な方法となる。この総合技術は、耐タンパ型オンチップ書換え可能メモリのプロテクトを拡大し、フラッシュメモリ・データブロックに格納されるデータのセキュアなバージョン管理を維持するものである。エンドユーザによって所望される場合、セキュアなバージョン管理は、フラッシュメモリ・デバイス上の総てのファイルやフラッシュデータ・ブロックを含むように命じられることができる。

バージョン管理されたファイルの格納
図４は、バージョン管理されたファイルを格納する方法の例のフローチャートである。フローチャートは、モジュール４０２で始まり、ＶＮ＿ｆを読み込みする。フローチャートは、モジュール４０４に進み、フラッシュメモリ・デバイス上でファイルデータを格納する。フローチャートは、モジュール４０６に進み、ＧＶＮ＿ｆとＧＶＮ＿ｎを夫々更新する。フローチャートは、モジュール４０８に進み、新しいＭＡＣを生成する。フローチャートは、モジュール４１０に進み、フラッシュメモリ・デバイスのフラッシュヘッダと、ファイルデータが保存されるフラッシュメモリ・ブロックの予備エリアとに新しいＭＡＣを格納する。フローチャートは、モジュール４１２に進み、フラッシュヘッダと予備エリアに、更新されたＧＶＮ＿ｆを格納する。フローチャートは、モジュール４１４に進み、セキュリティカーネルに対して呼び出しをすることによって、更新されたＧＶＮ＿ｎを格納する。フローチャートは、モジュール４１６に進み、パラメータとしてＶＮ＿ｆを用いてファイルデータブロックのために新ＭＡＣを生成する。フローチャートは、モジュール４１８に進み、ファイルデータに関連する予備エリアにＭＡＣを格納する。その後、フローチャートが終了する。

バージョン管理されたファイルの読み込み
図５は、バージョン管理されたファイルを読み込むための方法の例のフローチャート５００である。フローチャートは、モジュール５０２で始まり、セキュリティカーネルに対する呼び出しを行い、ＧＶＮ＿ｎを読み込む。フローチャートは、モジュール５０４に進み、ＧＶＮ＿ｆとフラッシュヘッダに格納されたＭＡＣを読み込む。フローチャートは、モジュール５０６に進み、ＭＡＣを生成し、このＭＡＣとフラッシュヘッダにあるＭＡＣとを比較する。フローチャートは、決定ポイント５０８に進み、２つの値が一致しているかを見るために、ＧＶＮ＿ｎに対しＧＶＮ＿ｆがチェックされる。ＧＶＮ＿ｆとＧＶＮ＿ｎが一致していない場合、フローチャートは、モジュール５２０に進み、読み込みが拒絶され、フローチャートが終了する。これに対しＧＶＮ＿ｆとＧＶＮ＿ｎが一致している場合、フローチャートは、モジュール５１０に進み、ファイルにあるＶＮ＿ｆを読み込む。続いてフローチャートは、モジュール５１２に進み、ここではＮＶＭに格納された鍵とＶＮ＿ｆを用いて、ＭＡＣが算出される。フローチャートは、モジュール５１４に進み、各データブロックに格納されたＭＡＣを読み込んで、算出されたＭＡＣと比較する。フローチャートは、決定ポイント５１６に進み、算出されたＭＡＣが各データブロックのＭＡＣと比較される。算出されたＭＡＣと各データブロックのＭＡＣが一致していない場合、フローチャートは、モジュール５２０に進み、読み込みが拒絶され、フローチャートが終了する。算出されたＭＡＣと各データブロックＭＡＣが一致している場合、フローチャートは、モジュール５１８に進み、ここでバージョン管理されたファイルを読み込む。その後、フローチャートが終了する。

好都合なことに、誰かが先のバージョンからデータブロックを置き換えた場合、ＨＭＡＣは、自動的に先のバージョン番号を含ませることとなり、結果として、検証されたメタデータにある正しい番号で演算されたＨＭＡＣと一致しないことになる。

ＭＡＣの格納
１つの具体的な実施形態で、ＭＡＣは、２０バイト長であり、ファイルのフラッシュヘッダ３０２、各メタデータ、予備エリア３０６に格納される。ファイルのブロックヘッダは、ビットエラー情報（ＥＣＣ）やステータス情報とともに、データブロックの予備エリアを利用してもよい。予備エリアにこの情報を格納する利点は、それがさらなるオーバーヘッドなしでデータと共に読み込まれることであり、予備エリアは、データブロック３０４上に格納されたデータ３０８を伴ってＭＡＣを含むというよりもむしろこの付加的ＭＡＣ情報を収容するのに利用される。

記憶装置の別の特徴としては、フラッシュ上にあるシングルビットエラーとダブルビットエラーに対して堅牢性(robustness)があるということである。ＭＡＣの２つのコピーは、予備エリアに格納されることが可能である。これら２つのＭＡＣの各々がセキュリティカーネル１０８によって算出されたＭＡＣと照合した場合、格納データ３０８に格納された情報は有効であると考えられる。また、２つのＭＡＣの内の１つのみが照合した場合、照合しなかったＭＡＣにはシングルビットエラーがあると推測される。そのブロックは別のデータブロック３０４へとコピーされ、新しいＭＡＣの組み合わせが新しいブロックに書き込まれ、古いブロックは解放された(freed)ものと見なされる。どちらのＭＡＣも照合しない場合、データは改竄されたものと推測されるか、又はマルチビットエラーがあると推測される。ブロックアクセスしても失敗（failure）を返すこととなり、データブロック３０４の格納データ３０８は読み込まれない。

ＭＡＣを格納するにあたり予備エリアを使うことは、以下の例に示されるように正当化される。ここでは仮に、１２８ＭＢのフラッシュ部が論理ブロック内に組織化され、それぞれのブロックは８つの２Ｋバイトページを含むものとする。各ページの予備エリアは、１ページあたり１ステータスバイト(one status byte)、および５１２バイト毎に３ＥＣＣバイトを含む。ＭＡＣの２つのコピーが方程式に組み込まれと、結果として、予備エリアの（（２＊２０）＋８＋（３＊４＊８））＝１４４バイトが使用されることになる。モデルは、各ブロックに付き５１２バイトの予備エリアを有することとなり、予備エリアにはＥＣＣ情報と共に２つのＭＡＣ値を具備するのに十分なスペースが存在することになる。

ここで使用されたように、用語“実施形態”は、それに限定されない一例として説明を行うための実施例を意味している。

当業者であれば前述した実施例と実施形態は、代表的なものであり、本発明の範囲を限定するものでないことが理解されるであろう。当業者が明細書を考慮し、図面を検討したときに自明な置き換え、増強、均等物やそれらへの改良が、本発明の要旨と範囲に含まれることを意図している。したがって、添付された特許請求の範囲は、本発明の要旨と範囲内にあるこのような総ての変更、置き換え、均等物を含むことを意図している。

１００ コンピュータ・システム
１０２ コンピュータ
１０４ I/Oデバイス
１０６ ディスプレイデバイス
１０８ プロセッサ
１１０ 通信インターフェース
１１２ メモリ
１１４ ディスプレイコントローラ
１１６ 不揮発性記憶装置
１１８ I/Oコントローラ
１２０ バス
２００ セキュアシステム
２０２ セキュアプロセッサ
２０４ OS
２０６ フラッシュメモリ・デバイスドライバ
２０８ フラッシュメモリ・デバイス
２１０ プロテクト・メモリ
２１２ セキュリティカーネル
２１４ 鍵ストア
２１６ 暗号化/復号化エンジン
２１８ セキュリティＡＰＩ
３００ フラッシュメモリ・デバイス
３０２ フラッシュヘッダ
３０４ データブロック
３０６ メタデータ
３０８ 格納データ
４００、５００ フローチャート

Claims (21)

1. データを暗号化し、
   前記暗号化されたデータを、フラッシュメモリ・デバイスのフラッシュメモリ・ブロックに格納し、
   前記データ、及びオペレーティング・システム・ソフトウェアによって生成されるか又はオペレーティング・システム・ソフトウェアにアクセス可能な情報変数であって、その変数のうち少なくとも幾つかはフラッシュデバイスに格納されていないような情報変数、の双方をカバーする暗号化されたメッセージ認証コード（ＭＡＣ）を生成し、
   前記ＭＡＣを、前記フラッシュメモリ・ブロックに格納し、
   前記フラッシュメモリ・ブロックから、前記暗号化されたデータと前記ＭＡＣを取り出し、
   前記ＭＡＣを用いて、取り出した前記データの有効性チェックを実行し、
   取り出した前記データが前記有効性チェックで不合格となった場合、取り出した前記データを拒絶し、
   取り出した前記データが前記有効性チェックで合格となった場合、
   取り出した前記データを受け入れ、
   取り出した前記データを復号化する方法であって、
   前記ＭＡＣを格納することは、予備エリアに前記ＭＡＣのコピーを格納することを含むことを特徴とする方法。
2. データを暗号化し、
   前記暗号化されたデータを、フラッシュメモリ・デバイスのフラッシュメモリ・ブロックに格納し、
   前記データ、及びオペレーティング・システム・ソフトウェアによって生成されるか又はオペレーティング・システム・ソフトウェアにアクセス可能な情報変数であって、その変数のうち少なくとも幾つかはフラッシュデバイスに格納されていないような情報変数、の双方をカバーする暗号化されたメッセージ認証コード（ＭＡＣ）を生成し、
   前記ＭＡＣを、前記フラッシュメモリ・ブロックに格納し、
   前記フラッシュメモリ・ブロックから、前記暗号化されたデータと前記ＭＡＣを取り出し、
   前記ＭＡＣを用いて、取り出した前記データの有効性チェックを実行し、
   取り出した前記データが前記有効性チェックで不合格となった場合、取り出した前記データを拒絶し、
   取り出した前記データが前記有効性チェックで合格となった場合、
   取り出した前記データを受け入れ、
   取り出した前記データを復号化するする方法であって、
   前記オペレーティング・システム・ソフトウェアにアクセス可能な複数の前記変数は、アプリケーション変数を含み、前記アプリケーション変数は、アプリケーションＩＤパラメータ、前記メッセージ認証コードによってカバーされる前記データの一部として使用するためのセキュリティカーネルへの入力、及び前記フラッシュメモリ・ブロックにおける前記データのバージョン番号から成るグループの中から選択された１つ又はそれ以上の値を含むことを特徴とする方法。
3. 更に、データを暗号化したり復号化したりするために、ＤＥＳ又はＡＥＳ方法を使用することを特徴とする請求項１または２に記載の方法。
4. 更に、前記フラッシュメモリ・ブロックの予備エリアに、前記ＭＡＣを格納することを特徴とする請求項１または２に記載の方法。
5. 前記ＭＡＣは、ＨＭＡＣ技術を用いて生成されることを特徴とする請求項１または２に記載の方法。
6. 前記オペレーティング・システム・ソフトウェアにアクセス可能な複数の前記変数は、ランタイム中にオペレーティング・システムのソフトウェア手段によって決定された値、ファイルに割り当てられかつファイル特有のメタデータと共に格納される独自の番号、論理ブロックインデックスを示す値、前記フラッシュメモリ・ブロックの物理的なブロック番号、及びアプリケーションに関連する変数から成るグループの中から、１つ又はそれ以上選択されることを特徴とする請求項１に記載の方法。
7. 少なくとも１つのフラッシュメモリ・ブロックを含むフラッシュメモリ・デバイスと、
   コンピュータ可読メディアに具現化されたフラッシュメモリ・デバイスドライバと、
   コンピュータ可読メディアに具現化されたセキュリティカーネルとを備え、
   動作において、前記セキュリティカーネルは、オペレーティング・システム・ソフトウェアにアクセス可能な複数の変数を使ってＭＡＣを生成し、前記フラッシュメモリ・デバイスドライバは、前記ＭＡＣを前記フラッシュメモリ・ブロックに格納するため前記フラッシュメモリ・デバイスに送るのを容易ならしめ、
   動作において、前記フラッシュメモリ・デバイスドライバは、前記フラッシュメモリ・ブロックからの前記ＭＡＣの受け取りを容易ならしめ、前記セキュリティカーネルは、前記ＭＡＣを使用して有効性チェックを実行し、
   前記フラッシュメモリ・デバイスドライバに関連するプロテクト鍵は、前記セキュリティカーネルを介してシークレット不揮発性メモリに格納されることを特徴とするシステム。
8. 少なくとも１つのフラッシュメモリ・ブロックを含むフラッシュメモリ・デバイスと、
   コンピュータ可読メディアに具現化されたフラッシュメモリ・デバイスドライバと、
   コンピュータ可読メディアに具現化されたセキュリティカーネルとを備え、
   動作において、前記セキュリティカーネルは、オペレーティング・システム・ソフトウェアにアクセス可能な複数の変数を使ってＭＡＣを生成し、前記フラッシュメモリ・デバイスドライバは、前記ＭＡＣを前記フラッシュメモリ・ブロックに格納するため前記フラッシュメモリ・デバイスに送るのを容易ならしめ、
   動作において、前記フラッシュメモリ・デバイスドライバは、前記フラッシュメモリ・ブロックからの前記ＭＡＣの受け取りを容易ならしめ、前記セキュリティカーネルは、前記ＭＡＣを使用して有効性チェックを実行し、
   前記フラッシュメモリ・ブロックへの格納または前記フラッシュメモリ・ブロックからの読み込みのために、データを暗号化したり復号化したりするため、コンピュータ可読メディアに具現化された暗号化/復号化エンジンを更に備えることを特徴とするシステム。
9. 前記ＭＡＣは、前記フラッシュメモリ・ブロックの予備エリアに格納されることを特徴とする請求項７または８に記載のシステム。
10. バージョン管理可能なファイルに関連するファイルバージョン番号を読み込み、
    ファイルデータを、フラッシュメモリ・デバイスの1つ又はそれ以上のフラッシュメモリ・ブロックに格納し、
    前記フラッシュメモリ・デバイス上のグローバルバージョン番号のコピーを更新し、前記グローバルバージョン番号は、少なくとも一部が前記フラッシュメモリ・デバイス上に格納された総てのバージョン管理されたファイルに関連し、
    セキュリティカーネルの不揮発性メモリにおける前記グローバルバージョン番号を更新し、
    前記グローバルバージョン番号をプロテクトするため、オペレーティング・システム・ソフトウェアにアクセス可能な複数の変数を用いてＭＡＣを生成し、
    前記ＭＡＣを、前記フラッシュメモリ・デバイスの１つ又はそれ以上のフラッシュメモリ・ブロックに格納し、
    更新された前記グローバルバージョン番号のコピーを、前記フラッシュメモリ・デバイスの前記１つ又はそれ以上のフラッシュメモリ・ブロックに格納し、
    前記グローバルバージョン番号を、前記セキュリティカーネルの不揮発性メモリに格納することを特徴とする方法。
11. 更に、前記1つ又はそれ以上のフラッシュメモリ・ブロックの予備エリアに、前記ＭＡＣを確保することを特徴とする請求項１０に記載の方法。
12. 前記ＭＡＣは、ＨＭＡＣ技術を使用して生成されることを特徴とする請求項１０に記載の方法。
13. 前記オペレーティング・システム・ソフトウェアにアクセス可能な複数の前記変数は、ランタイム中にオペレーティング・システムのソフトウェア手段によって決定された値、ファイルに割り当てられかつファイル特有のメタデータと共に格納される独自の番号、論理ブロックインデックスを示す値、前記フラッシュメモリ・ブロックの物理的なブロック番号、前記セキュリティカーネルに関連するコンピュータ・システムのオーナーＩＤ、及びアプリケーションに関連する変数から成るグループの中から選択された１つ又はそれ以上の変数を含むことを特徴とする請求項１０に記載の方法。
14. アプリケーションに関連する前記変数は、アプリケーションＩＤパラメータ、前記アプリケーションによってタグ付けされかつ前記フラッシュメモリ・デバイスに書き込まれたＩＤパラメータ、及び前記フラッシュメモリ・ブロックにおけるデータのバージョン番号から成るグループから選択された値を含むことを特徴とする請求項１３に記載の方法。
15. 前記ＭＡＣを格納することは、前記フラッシュメモリ・ブロックの予備エリアに前記ＭＡＣを格納することを含むことを特徴とする請求項１０に記載の方法。
16. 前記ＭＡＣを格納することは、前記ＭＡＣのコピーを格納することを含むことを特徴とする請求項１０に記載の方法。
17. 前記ＭＡＣのコピーを保存することは、前記フラッシュメモリ・ブロックの予備エリアにＭＡＣを格納することを含むことを特徴とする請求項１６に記載の方法。
18. 更に、前記デバイス上に格納されない、少なくとも幾つかのパラメータを用いて、前記グローバルバージョン番号を含むブロックに署名することを特徴とする請求項１０に記載の方法。
19. 前記ブロックにおいてバージョン管理された各ファイルに関連するファイル特有のバージョン番号を含むことを特徴とする請求項１８に記載の方法。
20. 更に、バージョン管理された前記ファイルのデータブロックをプロテクトする前記ＭＡＣを算出する際、変数として前記ファイル特有のバージョン番号を使用することを特徴とする請求項１９に記載の方法。
21. セキュリティカーネルの不揮発性メモリに格納された第１のグローバルバージョン番号を読み込み、
    複数のフラッシュメモリ・ブロックを含むフラッシュメモリ・デバイスのヘッダに格納された第２のグローバルバージョン番号を読み込み、
    前記第１グローバルバージョン番号を、前記第２グローバルバージョン番号に対して検証し、
    前記フラッシュメモリ・デバイスの前記ヘッダに格納された第１のＭＡＣを読み込み、
    第２のＭＡＣを生成し、
    前記第２のＭＡＣを、前記第１のＭＡＣと検証し、
    前記フラッシュメモリの前記ヘッダから、前記複数のフラッシュメモリ・ブロックの１フラッシュメモリ・ブロックに格納されたデータを有するバージョン管理されたファイルのファイルバージョン番号を読み込み、
    前記フラッシュメモリ・ブロックに格納された第３のＭＡＣを読み込み、
    前記セキュリティカーネルの不揮発性メモリに格納された鍵と、前記ファイルバージョン番号とをパラメータに用いて第４のＭＡＣを生成し、
    前記第４のＭＡＣを、前記第３のＭＡＣと検証し、
    バージョン管理された前記ファイルに関連するデータを受け取ることを特徴とする方法。

Images