JP7113115B2 - シリコンデバイスファームウェア上のロールバック攻撃を防止するセキュリティシステム、および、方法 - Google Patents

Description

本発明は、半導体デバイスに関するものであって、特に、半導体デバイスへの攻撃を防止するシステムと方法に関するものである。

ＩＢＭの特許文献ＵＳ２００８０１７５３８１Ａ１は、セキュリティバージョンデータを保存するヒューズ（fuse）を記述している。この文献は、システム中に用いられて、セキュアデータを暗号化するのに用いられるセキュリティバージョンパラメータを動的にアップデートする方法、および、装置を提供する。ＩＢＭシステムは、装置外部のメモリ中に保存されるデータブロックを暗号化する一装置を有し、この装置は、セキュリティバージョンパラメータを保存する第一固定記憶域素子；マスターキーデータを保存する第二固定記憶域素子；外部メモリ中に保存されるセキュアブロックを暗号化し、暗号化されたセキュアブロック、あるいは、このために生成された整合性チェック値の少なくとも一つが、セキュリティバージョンパラメータにより影響される暗号化エンジン；および、第一固定記憶域素子を修正して、前に修正された第一固定記憶域素子を修正しない場合、セキュリティバージョンパラメータをアップデートするメカニズム、を有する。

単一ＯＴＰ設定におけるファームウェアバージョンのグループ化が、https://developer.trustedfirmware.org/w/tf_m/design/secure_storage_service/rollback_protection/ で記述される。

上述の公開文献は、ＡＲＭプラットフォームセキュリティ機構を記述し、ロールバック防止のガイドライン、および、ロールバックを信頼できる例を提供する。とりわけ、公開文献は、“適当な実施は、各ソフトウェアに一計数を採用する、あるいは、一データベースファイル内にバージョン番号のリストをまとめ、このデータベースファイル自身のバージョンが単一計数を採用する”ことを述べている。

以下のリンク：https://www.mylgphones.com/how-to-identify-qfuse-anti-rollback-version-of-lg-kdz-firmware.htmlは、“あなたのスマホの現在のソフトウェアバージョンはＺＶＡであり、QfuseバージョンはＡＲＢ０１である。ＺＶＡからＺＶ６にダウングレードしたいが、ＺＶ６ファームウェアがQfuseバージョンのＡＲＢ００を有する”ことを述べている。この公開文献はまた“あなたのデバイスの現在のQfuseバージョンより低い抗ロールバック（Qfuse）バージョンのＫＤＺ、あるいは、ＴＯＴファームウェアをフラッシュするな”と主張している。
この技術システムのその他の状態は以下で記述されている：
US20140250290A1/en、
WO2014131652A1/en
US20170308705A1/en
https://www.intel.com/content/dam/www/public/us/en/documents/guides/
bootloader-security-features-programmers-guide.pdf

不揮発性、リセット不能、埋め込みシステムに用いる計数器の実施方法が、オンライン公開文献で示されている：
https://www.maximintegrated.com/en/design/technical-documents/app-notes/5/5042.html.

本明細書中で記述される公開文献、および、特許文献が開示する内容、および、その中で、直接、あるいは、間接的に引用される公開文献と特許文献は、否定や放棄されない限り、参考文献に組み込まれる。組み込まれた内容とここで開示される内容が明らかに不一致である場合、その解釈は、ここで開示される内容が、ある実施形態を記述し、組み込まれた内容は、その他の実施形態を記述することである。組み込まれた内容中の定義は、討論される語彙の一種の可能な定義であると見なされる。

本発明は、ロールバック攻撃を防止するセキュリティシステム、および、方法を提供することを目的とする。

ある実施形態は、シリコンデバイスの寿命を延長させるシステム、および、方法を提供する。

ある実施形態は、ワンタイムプログラマブルメモリに用いられるセキュアロールバック防止方法、および、システムを提供する。

ある実施形態は、寿命延長特徴を提供し、たとえば、ＯＴＰ中で、一般的に、ＯＴＰバージョンビットを保存するバージョン番号デコードプロトコルは、ＯＴＰ中で、従来のバージョン番号デコードスキームに相対する。

ある実施形態は、書込保護されたＮＶＭ中に、ファームウェアの追加複本を提供する。

ある実施形態は、外部メモリ上の二個の複製を用いたバージョン管理を提供する。

ある実施形態によると、安全なロールバック防止システムが提供され、このシステムは、少なくとも二個のうちの各一個の外部不揮発性メモリデバイス上、および、ＯＴＰ上で、データの複数の複製を用いる。

一般的に、一個の内部ＯＴＰ、および、一個の外部ＮＶＭ（たとえば、フラッシュ）がある。一個のＮＶＭ中の一個のファームウェア複製は、読み書きが開放され、よって、アップデート可能であり、第二のＮＶＭ（ＯＴＰではない）中のファームウェアのもう一つの複製は、読み取り／書き込みを開放しない。用語"外部"は、一般的に、ＯＴＰメモリデバイスを含むシリコンデバイス外部の不揮発性メモリデバイスを有する。二個の"外部フラッシュ"は、同じ回路板／回路にあるが、シリコン上に集積される必要はない。

任意で、一部が書込保護される単一の装置を用いてもよい。

ある実施形態は、ロールバック防止を保証することにより、メモリ、たとえば、ＯＴＰの強化されたセキュリティを提供し、ロールバック防止は、コードのバージョン番号の二重複製を、外部不揮発性メモリデバイス中に保存することを含む。

ある実施形態は、ＯＴＰ空間に制限があっても安全なバージョン管理を提供する。

ある実施形態は、ＯＴＰ、および、フラッシュ上に保存される二個のバージョンの複製を用いた安全な階層的バージョン管理を提供する。階層的バージョン管理において、異なるセキュリティレベルを有するメジャー、および、マイナーバージョン番号を含む、二個以上のバージョンタイプがある。メジャーバージョンはＯＴＰ中に保存されるとともに、フラッシュ中で複製され、マイナーバージョンはフラッシュだけにある。ＯＴＰバージョンは降級不可、フラッシュバージョンは可能である。たとえば、３．３は３．２に変更できるが、２．４に変更できない。

ある実施形態は、外部メモリデバイス中のバージョンフィールドの二個の署名された複製を使用し、このバージョンフィールドは、ＯＴＰバージョンフィールドと組み合わせ可能である。外部デバイス中の二個の署名されたバージョン番号は、少なくとも一つが、メインプロセッサによりアクセス不能であり、ソフトウェアブート時に、ＡＳＩＣのＲＯＭコードだけによりアクセス可能な第二ＳＰＩデバイス中に、バージョン番号の複製を保持することにより、単一ＳＰＩデバイス上のソフトウェア攻撃を防止する。

以下の用語は、先行技術文献中に出現する定義と一致する、明細書の記載と一致すると解釈される、あるいは、下記をその個別の範囲に含むと解釈される。
ＦＷ（ファームウェア）イメージ - 暗号化キー（たとえば、ＲＳＡ、あるいは、ＥＣＣ）で署名されるブート可能なＦＷ。
用語"イメージ"は、所定のバージョン番号と関連付けられたファームウェアコードの状態を含むことを意図する。アップグレードにおいて、バージョン番号nと関連付けられた所定の"イメージ"は、バージョン番号n+1と関連する、後にインストールされる"イメージ"により代替される。アップグレードは、現在インストールされているバージョンより以降、ファームウェアイメージをインストールする動作を含む。
ブートアップ（Boot up） -チップの通電（あるいは、リセット）時から、ブートＲＯＭコードが、ファームウェアの実行を許可するまで。
ファームウェアバージョン（ＦＷＶ） -一識別子、一般的に、増分数量計数器（逓増計数）で、特定バージョンのファームウェアに一意に割り当てられ、たとえば、１．０、あるいは、５３．３７で、一般的に、“メジャー番号”と“マイナー番号”を含み、表記法で、一ピリオド、あるいは、点で区別される。
アクティブＮＶＭ -ブートＦＷイメージのメインストレージで、このメモリは、ブート後、読み取り、書き込み可能になる。
リカバリーＮＶＭ -ロールバック攻撃からＦＷを保護するメモリ。このメモリは、ブート後、読み書き不可である。
メジャー番号 -ファームウェアバージョン（別称、メジャーアップデート）、ある実施形態は、ロールバック保護の対象を提供する。一般的に、各ＮＶＭはこのような番号を保存する（“リカバリーメジャー”）。
マイナー番号 -マイナー番号が用いられて、ファームウェアのアップデートに対するセキュリティの敏感度が低いことを示し、弱いロールバック保護の提供には十分である。たとえば、ＯＴＰ番号により記録されない（“マイナーアップデート”）。各ＮＶＭはこのような番号を記録する（“リカバリーマイナー”）。
ヒューズビットアレイ（Fuse Bit Array） -ＯＴＰビットの一アレイ、各ビットは、単一のメジャー番号に対応する。
ＯＴＰ番号 -プログラム化された最高のヒューズアレイビットは、最高メジャー番号に対応する。
ヒューズアレイ：ＯＴＰ内の一領域が、最新のメジャー番号を保存するために保留される。
ファームウェアアップグレードバージョニング -特定バージョン名、あるいは、特定バージョン番号を、アップグレードされるファームウェアの個別特定状態に指定する。番号が用いられるとき、バージョン番号は、一般的に、メジャー、および、マイナー番号を有する。メジャー、および、マイナー番号は、一般的に、それぞれ、逓増順序で割り当てられて、以降のバージョンが、以前のバージョンよりも大きいメジャー番号、および／または、マイナー番号を有する。
不揮発性メモリ（ＮＶＭ）：一旦、プログラム化されると、メモリは、電力を失っても、その値を維持する。
ＯＴＰ：ワンタイムプログラマブルメモリ。一種の不揮発性メモリ（ＮＶＭ）で、データを一度だけ、メモリに書き込むことを許可する。データは一回だけ書き込むことができるので、ＯＴＰデバイスは、悪意のあるソフトウェアアップデートによりハッキングされない。
フラッシュメモリ：一種の消去可能な不揮発ストレージ、あるいは、メモリ（別称、ＮＶＭ）。一般的に、フラッシュメモリは、マイクロプロセッサのプログラムを保存するのに用いられる。フラッシュは消去可能なので、プログラムされたアプリケーションは、除去、および、代替、あるいは、アップデート可能である。これは、装置が再プログラム化可能で、交換の必要がなく、開発コストを減少させることができることを意味する。また、フラッシュメモリは、フィールド内ソフトウェアアップデートをサポートする。
ＳＰＩインターフェース、あるいは、シリアルペリフェラルインターフェース：一インターフェースの非制限範例であり、遅い、あるいは、序列の周辺設備をインターフェースで接続し、簡単には、低コストで、チップ選択ラインを有し、アドレススキームではない。ＳＰＩは、シリアルプロトコルで、各種デバイスと通信することができ、シリアルフラッシュデバイスを有する。ＳＰＩインターフェースは、廉価な組込コントローラー代替品より速くできる（たとえば、１３３MHz）。あるＳＰＩインターフェースは２ビット、および／または、４ビットデータバスをサポートし、シリアルインターフェースだけで達成されるものより高い転送速度を達成する。
ＳＰＩフラッシュ：外部不揮発性メモリを組み立てる費用効果が高い方法は、インターフェースで接続されてＳＰＩをカバーするフラッシュモジュールを有する。低コストで、小さい占有空間なので、ＳＰＩフラッシュモジュールは優れている。たとえば、１個の３２ＭＢのチップは、数ドルしかかからない。
外部：回路板上で実体交換することができる。
チップ選択（ＣＳ）、別称、スレーブ選択（ＳＳ）：デジタル電子装置中の制御線は、単一のコンピュータバスに接続される一組の集積回路（チップ）中から一サブセット（１、あるいは、さらに多く）を選択する。シリアルペリフェラルインターフェースバス（ＳＰＩバス）は、チップ／スレーブ選択線を用いるバスの例である。

よって、コンピュータ制御システムを提供し、このシステムは、ロールバック攻撃から保護され、これらの攻撃は、システムのファームウェアが変化するとき発生し、よって、ファームウェアのバージョンを定義する。システムは、以下の全部、あるいは、任意の集合を含む：
（ｉ）チップは、（ａ）ＲＯＭコード、および、（ｂ）プログラム可能なヒューズアレイメモリを有する。
（ａ）ＲＯＭコードは、一般的に、チップシリコンに集積されるブートローダー（別称、ブートＲＯＭコード）を有し、ブートＲＯＭコードは、チップがオンになる、あるいは、リセットされるたびに作動する；および／または、
（ｂ）プログラム可能なヒューズアレイメモリ（たとえば、ワンタイムプログラマブル（ＯＴＰ）メモリ）は、メモリ中に、バージョン識別子（たとえば、バージョン番号）を保存する。
（ii）第一（別称、アクティブ）、および／または、第二（別称、リカバリー）不揮発性メモリ（別称、ＮＶＭ）は、メモリ中のブータブルファームウェア（別称、ブート時にロードされるファームウェア）バージョンの第一、および／または、第二複製がそれぞれ保存される；
第一識別子は、一般的に、アクティブＮＶＭ中に保存され、この識別子は、保存時、前記バージョンを一意に識別し、この識別子の第一複製はアクティブＮＶＭ中に保存され、第一識別子は、一般的に、少なくとも一つのアクティブメジャー番号、および／または、アクティブマイナー番号を有し、両者は、一般的に、プライベートキーで署名される；
第二識別子は、たとえば、リカバリーＮＶＭ中に保存され、この識別子は、保存時、通常、前記バージョンを一意に識別し、識別子の第二複製は、一般的に、リカバリーＮＶＭ中に保存され、第二識別子は、一般的に、少なくとも一つのリカバリーメジャー番号、および／または、リカバリーマイナー番号を有し、両者は、プライベートキーで署名されてもよい；および
（iii）ハードウェアデバイスは、一般的に、第一指令にしたがい、第一指令は、ブートＲＯＭコードにより、ブートアップ後提供されて、たとえば、次のシステムリセットまでロックし（別称、少なくとも、書き込みを無効にする、書込保護を提供する）、少なくともリカバリーＮＶＭ（および、任意で、ＯＴＰ）は、少なくともリカバリーＮＶＭ（および、任意で、ＯＴＰ）が書き込み可能ではない（書き込みにアクセス可能ではない）ことを確保することを含み、一般的に、ブートローダーのブートを除外する、および／または、第二指令に従い、第二指令は、ブートＲＯＭコードにより提供され、一般的に、次のシステムリセット時、少なくともリカバリーＮＶＭ（および、任意で、ＯＴＰ）の書き込み保護を解除し、これにより、一般的に、たとえば、新しいバージョンのファームウェアがすでに有効になると、古いバージョンのファームウェアがブートされるのを防止することができるシステムを提供する。

一般的に、両方のバージョン、および／または、両方の識別子と関連するファームウェアイメージは、プライベートキーで署名される。

一般的に、ブートＲＯＭコードが設定されて、少なくとも一つのファームウェアイメージを認証する、および／または、第一と第二識別子の一つ、あるいは、両方を認証する。

以上の各種実施形態、および、その他の実施形態は、次に段落で詳細に記述される。

本明細書に出現する任意の文字、あるいは、図式の商標は、その所有者の財産であり、それらの商標の明細書中での出現は、本発明の実施例を説明するためだけのものである。

特に説明がない限り、以下の説明から明らかなように、たとえば、"処理"，"演算"，"推定"，"選択"，"ランク付け"，"階層分け"，"計算"，"決定"，"生成"，"再評価"，"分類"，"形成"，"製造"，"ステレオマッチング（stereo-matching）"，"登録"，"検出"，"関連"，"重ね合わせ"，"獲得"等の用語を用いるのは、少なくとも一つのコンピュータ、あるいは、演算システム、あるいは、プロセッサや類似の電子計算装置の動作、および／または、プロセスが、演算システムのレジスタ、および／または、メモリ内で、物理（たとえば、電子）量として示されるデータを操作、および／または、その他の演算システムのメモリ、レジスタ、あるいは、その他のこのような情報ストレージ、伝送、あるいは、ディスプレイデバイス内の物理量で表示されるデータに転換することを指すことを理解されたい。用語“コンピュータ”は、幅広く、データ処理能力を有する任意の種類の電子装置をカバーするべきであり、これらに限定されないが、パソコン、サーバ、埋め込みコア、計算システム、通信装置、プロセッサ（たとえば、デジタルシグナルプロセッサ（DSP）、マイクロコントローラー、フィールドプログラマブルゲートアレイ（FPGA）、特定用途向け集積回路（ASIC）等）、および、その他の電子演算装置を有する。

ここでそれぞれリストされる素子は、違った素子である必要はなく、選択的に、同じ構造であってもよい。一素子、あるいは、特徴が存在する陳述は、（a）素子、あるいは、特徴が存在する実施形態；（b）素子、あるいは、特徴が存在しない実施形態；および（c）素子、あるいは、特徴が選択的に存在し、たとえば、ユーザーが、素子、あるいは、特徴が存在するか、存在しないかを設定することができることを含むことを意図する。

本発明により、シリコンデバイスの寿命を延長することができる。

既知のプロセスを説明する簡潔なフローチャートであり、メモリチップのシリアル番号が用いられて、不正事象を検出し、不正事象において、メモリチップは、低い計数値を有するメモリチップで代替される。具体的には、図１は、既知のアルゴリズムを示し、このアルゴリズムは、３２ビットメモリページ内で、計数を逓増させる。 本発明の実施形態により構成されるシステムを説明する簡潔なブロック図である。必要であれば、これらの実施形態のそれぞれの素子は、別の素子、あるいは、任意の実施形態、あるいは、ここで記述、あるいは説明される方法と結合される。説明されるコンポーネンツの全て、あるいは任意の集合が提供される。 本発明の実施形態により構成されるシステムを説明する簡潔なブロック図である。必要であれば、これらの実施形態のそれぞれの素子は、別の素子、あるいは、任意の実施形態、あるいは、ここで記述、あるいは説明される方法と結合される。説明されるコンポーネンツの全て、あるいは任意の集合が提供される。 ある実施形態による初期設定、および、アップデートプロセスを示す図である。 ある実施形態による初期設定、および、アップデートプロセスを示す図である。

本発明の範囲中に含まれる方法、および、システムは、任意の順序（たとえば、図示される順序）で、特に説明される実施で示される機能ブロックの一部（たとえば、任意の適当な集合）、あるいは、すべてを例として含む。

ここで記述、および、図示される演算、機能、および、論理コンポーネンツは、各種形式で実施され、たとえば、ハードウェア回路となり、たとえば、これらに限定されないが、カスタムＶＬＳＩ回路、あるいは、ゲートアレイ、あるいは、プログラム可能なハードウェアデバイス、たとえば、これらに限定されないが、ＦＰＧＡ、あるいは、少なくとも一つの有形、あるいは、無形のコンピュータ可読媒体上に保存されるとともに、少なくとも一つのプロセッサにより実行可能なソフトウェアプログラムコード、あるいは、それらの任意の適当な組み合わせである。特定の機能部品は、ソフトウェアコードの特定順序、あるいは、複数のソフトウェアコードの特定順序により形成され、討論される機能部品にとって、これらのソフトウェアコードの順序は、記述される方式で、集団行動、あるいは、表現される。たとえば、コンポーネンツは、いくつかのコードシーケンスで分布し、たとえば、これらに限定されないが、物件、工程、函数、ルーティン、および、プログラムであると共に、一般的に、相乗的に操作するいくつかのコンピュータファイルによって生じる。

ここで記述される任意の論理機能は、必要に応じて、リアルタイムアプリケーションとして実施され、且つ、論理機能は、任意の適当な構造上のオプション、たとえば、これらに限定されないが、ＡＳＩＣ、あるいは、ＤＳＰ、あるいは、それらの任意の適当な組み合わせを採用する。ここで述べられる任意のハードウェア素子は、事実上、一つ以上のハードウェアデバイス、たとえば、チップを有し、これらのハードウェアデバイスは、共同設置されてもよく、あるいは、離れていてもよい。

ＥＰＲＯＭエミュレーションモードを含むＥＥＰＲＯＭは、不揮発性、リセット不能計数器の実施に有用である。メモリチップのシリアル番号が用いられて、不正事象を検出する。不正事象中、メモリチップは、もう一つの低い計数値を有するメモリチップにより代替される。図１は、既知のアルゴリズムの範例であり（https://www.maximintegrated.com/en/design/technical-documents/app-notes/5/5042.html）、アルゴリズムは、３２ビットメモリページ内で計数を逓増させる。

コードに損害を与える一般的な攻撃方法は、既に知られているコード弱点と脆弱性を利用する。この種の攻撃を防止するため、コードサプライヤーは、定期的に、それらのコードをメンテナンスし、メンテナンスは、一般的に、ある攻撃に対し脆弱な、シリコン上に現在保存された既知の、あるいは、現在見つかっている古いバージョンのコードを、このような攻撃に対して脆弱ではない新しいバージョンのコードに交換することを含む。

しかし、攻撃者が、すでにメンテナンスした脆弱でない新しいコードバージョンを、古く、且つ、脆弱なコードバージョンに交換する（別称、"ロールバック"）ように仕向けた場合、攻撃者は、その後、古いコードの既知の弱点を利用することができる。この攻撃経路を防止するため、コードバージョン番号は保存され（たとえば、ＯＴＰメモリ上のシリコンデバイス内）て、コードバージョンが、古く脆弱なコードバージョンではなく、最新のものであるように確保する。ＯＴＰ（One Time Programmable）メモリは消去できないので、これにより、ＯＴＰ中のバージョンはロールバックされない。しかし、コードバージョン番号のＯＴＰ空間は制限があるので、所定システムが受け入れられるコードアップデート、あるいは、バージョンの数量を制限する。

ある実施形態は、外部メモリデバイス（ＳＰＩフラッシュ）中のバージョンフィールドの二個の署名された複製を用いることにより、この問題を解決し、バージョンフィールドは、場合により、ＯＴＰバージョンフィールドと結合される。よって、本発明の一実施形態は、二個の署名された外部複製だけを使用し、もう一つの実施形態は、ＯＴＰバージョンフィールドと結合される二個の外部複製を使用する。前の実施形態（二個のフラッシュだけを用いる）によると、一般的に、両フラッシュは、最初に、バージョン１（１，１）を含む。その後、アクティブフラッシュバージョン番号は、２にアップデートされ、アクティブフラッシュのアップデート時に、リカバリーフラッシュは書込保護される（２，１）。次のリセット時、アクティブフラッシュコンテンツの有効性と信頼性がテストされる。アクティブフラッシュバージョンが有効であると認められる場合（３）、（現時点でリカバリーフラッシュにアクセスできる）セキュアコードは、アクティブフラッシュコンテンツを、バージョン番号（２，２）を有するリカバリーフラッシュに複製する。その後、安全でないコードの実行が許可される前、リカバリーフラッシュは書込保護される。

後の実施形態（二個のフラッシュ、および、一個のＯＴＰを用いる）によると、フラッシュ１、２は、それぞれ、メジャー、および、マイナーバージョンを含み、ＯＴＰは、メジャーバージョン１（１.２，１.２，１）だけを有する。アクティブフラッシュバージョン番号が２．０にアップデートされ、アクティブフラッシュのアップデート時、リカバリーフラッシュはまだ書込保護される（２.０，１.２，１）。次のリセット後、アクティブフラッシュコンテンツの有効性と信頼性がテストされる。アクティブフラッシュバージョンが有効であると認められる場合（上記ステップ）、（現時点でリカバリーフラッシュ、および、ＯＴＰにアクセスできる）セキュアコードは、アクティブフラッシュコンテンツを、バージョン番号（２.０，２.０，１）を有するリカバリーフラッシュに複製する。このほか、ＯＴＰバージョンは、メジャーバージョン（２.０，２.０，２）にアップデートされる。その後、安全でないコードの実行が許可される前、リカバリーフラッシュは書込保護されると共に、ＯＴＰがロックされる。

図２に示されるように、ある実施形態は、外部メモリ中に保存されるコードバージョン番号フィールドと、内部ＯＴＰ空間に保存されるバージョンデータを結合する。バージョンフィールドは、二個の複製、一つは外部メモリ#0上の（Flash #0 Ver）、もうひとつは、外部メモリ#1上の（Flash #1 Ver）中に保存される。

外部メモリは、ＳＰＩフラッシュを有してもよい。ファームウェアアップデートは、ランタイム外部メモリ（図２のフラッシュ０）で実行される。
バージョンフィールドは、二個の番号、あるいは、数量により実施され、これらの番号、および、数量は、フラッシュ中でプログラムされる：ＯＴＰバージョン（OTP＿VER）とフラッシュバージョン（FLASH＿VER）中でプログラム化される。

ＯＴＰは、リカバリー／アクティブフラッシュメジャーバージョンをミラー（mirror）することが予期される。そうでない場合、ロールバック攻撃が試みられたと仮定される。

理解できることは、一般的に、アップデート工程期間以外では、前記二個の番号は通常同じであり、アップデート時、アクティブ、および、リカバリー／ＯＴＰバージョン番号は異なる。

リカバリーフラッシュは、一般的に、ロールバック攻撃、あるいは、アップデート試みの失敗時、ランタイム（アクティブ）フラッシュコンテンツをリカバーするのに用いられる。

アクティブ（あるいは、ランタイム）フラッシュは、一般的に、リカバリーフラッシュと構造が物理的に同じであり、多種の用途に用いられ、たとえば、ファームウェア、あるいは、任意の所望のデータの保存を有する。バージョン番号は、通常、ファームウェアイメージ中に固定地点を有する。リカバリーフラッシュは、最後のアップデートの時に、アクティブフラッシュ中に保存される任意のコンテンツのバックアップを保存してもよい。必要であれば、リカバリーフラッシュは、ある形式に設定されて、別のタイプの定数データを保存する；フラッシュは書込保護される。

任意のファームウェアアップデート中、一般的に、ＯＴＰバージョン番号、あるいは、フラッシュバージョン（FLASH＿VER）の一つが、逓増する。任意の工程管理バージョン番号が用いられる。例のアップデートプロセスがここで記述される。

図２において、ＯＴＰバージョン（ＯＴＰ ＶＥＲ）は、一般的に、ＯＴＰ専用バージョンフィールド中、値１にプログラムされる最高ビットを有する。フラッシュにおいて、コード（ファームウェア）＋バージョン番号は、一般的に、たとえば分離できないように、一緒に署名される。

コードバージョン番号を保存するバージョンフィールドは、一般的に、たとえば、ファームウェアのパブリックキーで認証される。コードバージョン番号のＯＴＰ、あるいは、フラッシュバージョンのひとつが逓増するとき、ファームウェアコードの新しいバージョンは、一般的に、まず、Flash #0でアップデートされる。

任意の適当な方法が用いられて、flash #0中のバージョンが確実に行われているか否か判断する。たとえば、アップデートプロセス期間中、新しいファームウェアがデバイス中にロードされる、且つ、デバイスが各種テスト（たとえば、通信、表示）を行って、デバイスが、任意のシステム障害の場合に、リカバーできるように確保する。

一般的に、一旦、flash #0中のバージョンが確実に行われると、ファームウェアアップデートが以下のように継続される：
逓増するバージョン番号がＯＴＰバージョン（OTP＿VER）である場合、ＯＴＰ空間中のバージョンも同様に逓増し、且つ、Flash #1中のバージョンも、それにしたがってアップデートされる。
逓増するバージョン番号がフラッシュバージョン（FLASH＿VER）である場合、Flash #1中のFLASH＿VERだけがアップデートされ、ＯＴＰバージョンはアップデートされない。
このロジックは、このファームウェアアップデートが、任意の適当な位置、たとえば、セキュアコード（たとえば、ＲＯＭコード）中、および、ブートヒエラルキー全体に沿って保存されることを確保する。一般的に、ＲＯＭコードは、ユーザープロセスにおいて、最高のセキュリティレベルにあり、信頼性テストは、最低レベルのセキュリティレベルにある。

新しい製品バージョンがリリースされるとき、たとえば、ここで記述される装置と方法を使用しない標準のＯＴＰバージョンの実施において、ＯＴＰファームウェアバージョンフィールド（図２のＯＴＰバージョン）は、すでに、ＯＴＰメモリ中で、大量のビットを使用しており、よって、後続のＯＴＰバージョンをアップデートできる数量を、ＯＴＰバージョンメモリの残りのビット数に制限する。たとえば、残りが３個のＯＴＰビットしかない場合、三回のアップデートだけが可能である。

新しい製品でこの問題を回避するため、リリースされた（第一）バージョン番号は、ＯＴＰ中の異なるフィールド中（first＿ver＿num）に書き込むことができる。この番号が、"異なる"フィールド中に書き込まれることを確保するロジックは、たとえば、アップデートプロセス中のＲＯＭコード中に存在してもよく、あるいは、フラッシュデバイス内に外部からプログラム化されてもよい。

たとえば、８ビットフィールドは、０～２５５から、任意のバージョン番号を表すことができる。理解できることは、１６進数表現の８ビットに代えて、任意の異なる方法を用いて、現在のファームウェアバージョンを表すことが可能である。たとえば、第一バージョン番号の代わりに、ＯＴＰ中に一領域を有してもよく、この領域において、焼かれた各ビットは１６個の正常なバージョン番号のジャンプを表す。

たとえば、古いデバイスにおいて、ＯＴＰバージョンメモリは、バージョン３３（この時、ＯＴＰ中、３３個のバージョンビットがすでに使用されている）を表す場合がある。しかし、新しい製品において、FIRST＿VER＿NUMフィールドは３３であり、OTP＿VERフィールドは、使用されるビットがない。一ファームウェアアップデートにおいて、新しい、および、古い製品はともに、ＯＴＰ中の一ビットで焼かれ、これらの焼く動作は、ブート時に、たとえば、ＲＯＭ／セキュアコード内に存在するロジックにより管理される。

理解できることは、一般的に、古いデバイスは古いファームウェアバージョンから、すでに多くのＯＴＰビットを使用していることである。新しいデバイスは、これらのファームウェアバージョンを用いず、よって、これらのＯＴＰビットを焼かない。古い製品中ではなく、新しい製品中に提供されるOTP＿VERフィールドは、使用されるビットを有さないという事実のおかげで、新しい製品は、古い製品と比べて、さらに多くのファームウェアリリースを受けることができ、古い製品と比較して、新しい製品の寿命を効果的に延長することができる。

理解できることは、古いデバイスにとって、全バージョンのＯＴＰビットが焼かれる場合、フラッシュが代わりに用いられて、ＯＴＰバージョンを表すことである。これは、ロールバック攻撃防止能力を低下させる。フラッシュメモリ中、ＯＴＰのバージョン番号は拡張される。

理解できることは、flash #1、および、ＯＴＰ中の任意のバージョンアップデートは、セキュアコードにより実行され、このコードは、ファームウェア層０（ＲＯＭコード後の第一層）中に存在、並びに、作動する、あるいは、別に保護されるプロセッサで作動する、あるいは、任意のその他の安全なハードウェアにより作動される。

ある実施形態は、安全なバージョン管理システムを提供し、このシステムは、不揮発性（ＮＶ）ストレージデバイス（たとえば、これらに限定されないが、ディスク、ＳＰＩフラッシュデバイス、あるいは、任意のその他のＮＶメモリ）中に保存される埋め込みファームウェア（ＦＷ）のロールバック攻撃を防止する。このシステムは、新しいファームウェアバージョンがすでにアップデートされ、且つ、有効になると、古いバージョンのファームウェアをブートアップすることにより、システムをロールバック攻撃から効果的に保護する。このシステムは、たとえば、古いファームウェアバージョンの弱点が発見される場所で、ファームウェアの安全なアップデートを促進する。一般的に、各ブート工程で、デバイス内のコードが起動する前、セキュアコードは、ＯＴＰとフラッシュバージョン番号が一致するか比較する。比較結果が一致しない場合、ブートは失敗で、中止される。たとえば、図３は、ロールバック防止システム（ＲＰＳ）を説明する簡潔なブロック図である。ロールバック防止システム（ＲＰＳ）は以下のコンポーネンツの全て、あるいは、任意の集合を有する：
ａ.チップが通電するとき作動するブートローダーＲＯＭコードを有する埋め込みチップ
ｂ.ブート時、ファームウェアを保存する二個の不揮発性メモリ（ＮＶＭ）デバイス
ｃ.チップに集積されて、バージョン番号ヒューズを保存するワンタイムプログラマブル（ＯＴＰ）、あるいは、“ヒューズ”メモリ
ｄ.ＮＶＭの一つの読み書きを無効にするハードウェア（ＨＷ）デバイス、あるいは、方法

実施形態は、以下のものを含むが、以下のものに限定されない。
第１実施形態：ロールバック攻撃から保護するコンピュータ制御システムで、ロールバック攻撃は、システムのファームウェアが変化するとき発生し、これにより、ファームウェアのバージョンを定義し、本システムは、以下の全て、あるいは、任意の集合を有する：
（ｉ）チップは、（ａ）ＲＯＭコード、および、（ｂ）プログラム可能なヒューズアレイメモリを有する。
（ａ）ＲＯＭコードは、一般的に、チップシリコンに集積されるブートローダー（別称、ブートＲＯＭコード）を有し、ブートＲＯＭコードは、チップがオンになる、あるいは、リセットされるときはいつでも作動する；および、
（ｂ）プログラム可能なヒューズアレイメモリ（たとえば、ワンタイムプログラマブル（ＯＴＰ）メモリ）は、メモリ中に、バージョン識別子（たとえば、バージョン番号）を保存する；
（ii）第一（別称、アクティブ）、および／または、第二（別称、リカバリー）不揮発性メモリ（別称、ＮＶＭ）は、メモリ中のブータブルファームウェア（別称、ブート時にロードされるファームウェア）バージョンの第一および第二複製をそれぞれ保存する；
第一識別子は、アクティブＮＶＭ中に保存され、この識別子は、保存時、前記バージョンを一意に識別し、この識別子の第一複製はアクティブＮＶＭ中に保存され、第一識別子は、少なくとも一つのアクティブメジャー番号およびアクティブマイナー番号を有し、両者は、プライベートキーで署名される；
第二識別子は、リカバリーＮＶＭ中に保存され、識別子は、保存時、前記バージョンを一意に識別し、識別子の第二複製は、リカバリーＮＶＭ中に保存され、第二識別子は、少なくとも一つのリカバリーメジャー番号およびリカバリーマイナー番号を有し、両者は、プライベートキーで署名される；および
（iii）ハードウェアデバイスは、一般的に、第一指令にしたがい、第一指令は、ブートＲＯＭコードにより、ブートアップ後提供されて、次のシステムリセットまでロックし（別称、少なくとも、書き込みを無効にする、書込保護を提供する）、少なくともリカバリーＮＶＭ（および、任意で、ＯＴＰ）は、少なくともリカバリーＮＶＭ（および、任意で、ＯＴＰ）が書き込み可能ではない（書き込みにアクセス可能ではない）ことを確保することを含み、一般的に、ブートローダーを除外し、および、第二指令に従い、第二指令は、ブートＲＯＭコードにより提供され、次のシステムリセット時、少なくともリカバリーＮＶＭ（および、任意で、ＯＴＰ）の書き込み保護を解除し、これにより、新しいバージョンのファームウェアが有効になると、古いバージョンのファームウェアがブートされるのを防止することができるシステムを提供する。
ファームウェアイメージは、両バージョンと関連し、且つ、
両識別子はプライベートキーで署名され、且つ、
ブートＲＯＭコードが設定されて、少なくとも一つのファームウェアイメージを認証する、および／または、第一、および／または、第二識別子を認証する。

ブートＲＯＭコードは、たとえば、リカバリーＮＶＭ、および、アクティブＮＶＭ両方中で、メジャー、および、マイナー番号両方を認証する。

理解できることは、ファームウェアコード自身は、一般的に、ブート前は、ＮＶＭだけにあり、ブート後、コードは、一般的に、デバイスＲＡＭにも保存されることである。

ある実施形態によると、外部コードが実行可能でないブート段階中、且つ、ブート段階の終了時であるが、任意の外部コードが作動できる前、書込保護は元に回復し、これにより、ロールバック攻撃を効果的に防止する。

ファームウェアのイメージは、フラッシュ中に保存されてもよい。

各ファームウェアバージョン番号は、一般的に、特定のファームウェアイメージに関連し、且つ、一緒に署名される。

通常、両ＮＶＭ中のファームウェアイメージは同じである。しかし、ブート時、ＲＯＭコードが設定されて、アクティブイメージ中のマイナーバージョン番号が、リカバリーイメージ中のマイナーバージョン番号と同じか、それより高い場合のみブートを許可する、および／または、ＲＯＭコードが設定されて、アクティブイメージ中のメジャーバージョン番号が、ＯＴＰ中のバージョン番号と同じか、高い場合のみ、ブートを許可する。

ここで、"リセット"という用語が用いられて、複数の事象を含み、チップはこの事象後、あるいは、この事件の結果、新たに通電される。

一般的に、プライベートキーホルダーの所有者は、システム製造者であり、且つ、ファームウェアイメージを署名することが認証されたエンティティだけが、このキーにアクセスするので（よって、認証されたエンティティだけが、このキーを用いて、ファームウェアイメージを署名することができる）、プライベートキーはシークレットである。

一般的に、パブリックキーは、シリコンデバイス内部の書込保護されたメモリ（たとえば、上述のＲＯＭコード、あるいは、書込保護されたＯＴＰ、あるいは、書込保護された埋め込みフラッシュ）中に保存される。

一般的に、パブリックキーは、未認証コードにより修正可能であってはならず、修正されたパブリック/プライベートキーペアの使用を防止する。ＲＯＭコードは一ヘッダーを検証し、ヘッダーは、第二キーを有し、第二キーが用いられて、ファームウェア自身を認証する；第二キーは有効であるので、これは有効である。

第２実施形態： ロールバック攻撃からシステムを保護する方法であって、ロールバック攻撃は、システム中のファームウェアが変化するとき発生し、よって、バージョンを定義する。本方法は：
（ｉ）第１実施形態の全て、あるいは、任意の集合を有するシステムを提供する；
（ii）第一バージョンのブータブルファームウェア（別称、第一ファームウェアイメージ）の複製を、アクティブ、および、リカバリーＮＶＭ中に保存する；
少なくとも一つの第一バージョンのメジャー番号の第一、および、第二複製を、それぞれ、第一、および、第二不揮発性メモリデバイス中に保存する；および
ＯＴＰメモリ中の少なくとも一つのビットをプログラム化して、メジャー番号と等しく（適合）する；
（iii）少なくとも一回、ファームウェアのマイナーアップデートを実行し、アクティブＮＶＭ中に保存されるブータブルファームウェアのバージョンを、ブータブルファームウェア新しい"マイナー"バージョンで代替すること、および、アクティブＮＶＭ中に保存される識別子を、高いマイナー番号を有する新しい識別子で代替することを有する；および
（iv）ブートを必要とする少なくとも一つのリセット後、
ａ.ブートローダーに命令する：
すくなくとも、アクティブＮＶＭのコンテンツが有効であるか、アクティブＮＶＭ中の識別子が、ＯＴＰ番号より大きいか判断する；および
アクティブＮＶＭ中のメジャー番号がＯＴＰ番号より低い場合、ブートを中止する、および、
ｂ.アクティブＮＶＭ中の識別子（別称、アクティブマイナー）が、リカバリーＮＶＭ中の識別子（別称、リカバリーマイナー）より大きい場合のみ、それぞれ、下記からなる操作ｂ１、ｂ２を実行する：
操作ｂ１. ブータブルファームウェアの新しいバージョンが、リカバリーＮＶＭ中に現在書き込まれるブータブルファームウェアのバージョンに書き込まれる；および
操作ｂ２. リカバリーＮＶＭ中の識別子がアップデートされ、アクティブＮＶＭ中の識別子の値に等しくなる。

一般的に、ファームウェア、および、バージョン番号は、一緒に署名されて、バージョン番号と実際のブータブルファームウェアが連結されなければならない。攻撃者が、ファームウェアコンテンツの交換を試み、バージョン番号をそのままにする、あるいは、逆の場合、署名認証は失敗する。よって、署名は、バージョン番号に安全性の意義を提供する。

リカバリーＮＶＭにおいて、署名が用いられて、自動リカバリー事象（たとえば、ここで記述される自動リカバリー事象）中のアクティブＮＶＭの同等の複製となる。

一般的に、ＯＴＰビットがプログラムされて、両ＮＶＭ中にも保存されるそのバージョンのメジャー番号と適合する。

理解できることは、リカバリーＮＶＭは、ブート後、ユーザーにアクセスできない（書き込みがロックされる）ことである。ブートローダーだけがリカバリーＮＶＭに書き込める。

理解できることは、ＯＴＰ中の各ビットは二進数の１にプログラムされるか、そうでなければ、二進数０である。ＯＴＰ中に保存されるヒューズアレイにおいて、一アレイ（たとえば、ビット０～６４を含む）中の一ビットのインデックスは、ＯＴＰ番号に対応する。たとえば：アレイのプログラムビット１７が、１の最高ビットにプログラムされる場合、この状況は、ＯＴＰ番号１７であると解釈される。インデックス１９のビットがその後、１にプログラムされる場合、この動作は、ＯＴＰ番号を１９に変化させる。この動作は、上昇するＯＴＰインデックスが尽きない限り実行することができ、よって、アレイが６４ビットである場合、その後、保存可能な最高ＯＴＰ番号は６４である。

第３実施形態： 第１実施形態に基づいた、あるいは、前述の任意の実施形態に基づくシステムにおいて、ＯＴＰメモリは複数のヒューズを有し、これらのヒューズの状態は、バージョン番号を表す。

第４実施形態： 第１実施形態に基づいた、あるいは、前述の任意の実施形態に基づくシステムにおいて、ＯＴＰ中の複数のビット（別称、ＯＴＰビット）が用いられて、番号を表し、
OTP-Number（OTP番号）= Starting-Number（開始番号） + Counter（計数），
複数のビットは、ｎビットの一アレイを有し、これにより、それぞれ、ｎビットに関連するｎビットインデックスを定義し、ｎビットは、値 "０"を有するビットの（"第一"）集合、および、１にヒューズされたビットの（"第二"）集合を有し、計数は、１にヒューズされたｎビットの（"第二"）集合に関連する数個のビットインデックス中から、最高インデックスとして決定される。

すでに符号化された開始番号は、一般的に、保護される不揮発性内部メモリ中、たとえば、（あるいは、別の）ＯＴＰ、埋め込みフラッシュ、あるいは、ＲＯＭコード中に存在する。

上記の特徴は、オフセット特徴（offset feature）とも称され、開始番号は“オフセット”とも称される。

開始番号（オフセット）は、たとえば、一般の二進数に符号化される。あるいは、別の方法を用いて、単純な番号（たとえば、１、４５、あるいは、１００）を保存するかわりに、開始番号を保存し、この方法は、少ないＯＴＰヒューズを用い、これにより、ＯＴＰヒューズを節約すると同時に、製品の寿命を延長する。たとえば、５個のヒューズを有するフィールド中、プログラムされた各ヒューズは、それぞれ、５０の開始番号逓増に対応し、開始番号１５０を意味する：

たとえば、ここで一アレイが示され、アレイは、第三ビットだけがヒューズされる可能性がある（通常は、第一から第三ビットがヒューズされても、この状態は可能である。よって、最新の有効メジャー番号は３である。

このアレイ中、第七ビットもヒューズされる（通常、第一～第七ビット、あるいは、少なくとも第三～第七ビットであっても、ヒューズされる）。よって、最新の有効メジャー番号は７である。

比較すると、別の領域（たとえば、ビット）が、符号化された番号（開始番号）をＯＴＰに保存する場合、この番号の解釈はオフセットであり、たとえが、以下の例で示される：
例えば、値"７５"（二進数、あるいは、十進数として、あるいは、その他の任意の効果的な方法を使用）が、ＯＴＰ中の開始番号領域中に保存される：

その後、第三ビットだけがヒューズされる一アレイを与える場合、最新の有効メジャー番号は、３＋７５＝７８であり、３ではない。

同様に、第七ビットもヒューズされる一アレイを与える場合、最新の有効メジャー番号は、７＋７５＝８２であり、７ではない。

理解できることは、この実施形態は、開始番号が提供されないシステムと比較して、製品の寿命を延長することができる。

第５実施形態： 第１実施形態に基づいた、あるいは、前述の任意の実施形態に基づいたシステムにおいて、ハードウェアデバイスは、アクティブＮＶＭの読み書きを無効にせず、よって、アクティブＮＶＭは、ブート後、読み書き可能である。

第６実施形態： 第４実施形態に基づいた、あるいは、前述の任意の実施形態に基づくシステムにおいて、第一ファームウェアイメージが、アクティブ、および、リカバリーＮＶＭ中に保存されるとき、ＯＴＰ番号は、両ＮＶＭ中に保存されるメジャー番号と等しい。

第７実施形態： 第２実施形態に基づいた、あるいは、前述の任意の実施形態に基づく方法において、ハードウェアデバイスによるリカバリーＮＶＭのロックは、さらに、リカバリーＮＶＭからの読み取りを無効にすることを有し、リカバリーＮＶＭが読み取り可能ではないことを確保することを含む。

第８実施形態： 第２実施形態に基づいた、あるいは、前述の任意の実施形態に基づく方法において、リカバリーＮＶＭのロックは、リカバリーＮＶＭを切断することを有する。

第９実施形態： 第２実施形態に基づいた、あるいは、前述の任意の実施形態に基づく方法において、ハードウェアデバイスによるＯＴＰのロックは、さらに、リカバリーＮＶＭからの読み取りを無効にすることを有し、ＯＴＰが読み取り可能ではないことを確保することを含む。

第１０実施形態： 第２実施形態に基づく、あるいは、前述の任意の実施形態に基づく方法において、アクティブ、および、リカバリーＮＶＭ中にそれぞれ保存されるブータブルファームウェアの第一バージョンおよび少なくともメジャー番号が、パブリックキーで一緒に署名され、これにより、署名（signature）を生成する。

理解できることは、この実施形態は、すでに署名されたコードに対して有用であり、未署名コードに対しては、同じバージョンが任意のコードと関連付けられてもよい。

一般的に、パブリックキーとプライベートキーは関連付けられ、プライベートキー（だけ）は、認証されたファームウェアパブリッシャーにより所有される。

ファームウェアを有する（パブリック）キーが用いられて、高レベルのファームウェアを認証する。

第１１実施形態： 第１０実施形態に基づいた、あるいは、前述の任意の実施形態に基づく方法において、ブートローダーのアクティブＮＶＭコンテンツに対する有効性のテストは、アクティブＮＶＭのコンテンツと署名の暗号化認証（cryptographic authentication）を有する。

第１２実施形態： 第１１実施形態に基づいた、あるいは、前述の任意の実施形態に基づく方法において、認証は、プライベートキーとペアのパブリックキーを使用し、且つ、パブリックキー（プライベートキーではない）がＯＴＰ中に保存される。

プライベートキーは、一般的に、認証署名者（だけ）により保存される。

第１３実施形態： 第２実施形態に基づいた、あるいは、前述の任意の実施形態に基づく方法、且つ、ブートローダーのアクティブＮＶＭコンテンツに対する有効性のテストは、アクティブＮＶＭ中のメジャー番号が、リカバリーＮＶＭ中のメジャー番号に等しいか、それより高いことを確保することを有する。

第１４実施形態： 第２実施形態に基づいた、あるいは、前述の任意の実施形態に基づく方法、且つ、ブートローダーのアクティブＮＶＭの内容に対する有効性テストは、少なくとも一つのシステムレベルテストから指示を提供して、少なくとも一つの所定基準を確保することを有する。

第１５実施形態： 第１４実施形態に基づいた、あるいは、前述の任意の実施形態に基づく方法、且つ、基準は、新しいバージョンのブータブルファームウェアが、安定してブートされるという判定を有する。

前の成功したブートは、新しいバージョンのブータブルファームウェアが安定してブートされるという判定基準の一例である。

第１６実施形態： 第２実施形態に基づいた、あるいは、前述の任意の実施形態に基づく方法において、アクティブＮＶＭ中のメジャー番号がＯＴＰ番号に等しいときかつその時に限り、ブートローダーがブートをうまく完了する；および、
たとえば、ブートローダーによりテストし、アクティブＮＶＭ中の有効な内容を解明する。

第１７実施形態： 第２実施形態に基づいた、あるいは、前述の任意の実施形態に基づく方法において、トラストのチェーン（chain of trust）が少なくとも一回、繰り返して実施され、トラストチェーンは、認証済みコードを用いて、余分なコードレベルを認証し、このコードレベルは、追加メジャー、および／または、マイナーバージョン番号を有し、バージョン番号は、さらに別のコードレベルを認証することができる。
認証後、認証コードは、ＮＶＭからＲＡＭにロードされる。

第１８実施形態： 第１実施形態に基づいた、あるいは、前述の任意の実施形態に基づくシステムにおいて、アクティブ、および、リカバリーＮＶＭは、二個の別々のメモリデバイスを有する。

第１９実施形態： 第１実施形態に基づいた、あるいは、前述の任意の実施形態に基づくシステムにおいて、アクティブ、および、リカバリーＮＶＭは、単一フラッシュデバイス上に二個のメモリ範囲を有する。

第２０実施形態： 第４実施形態に基づいた、あるいは、前述の任意の実施形態に基づくシステムにおいて、開始番号は書込保護である。

第２１実施形態： 第２実施形態に基づいた、あるいは、前述の任意の実施形態に基づく方法は、さらに、ブートローダーに命令して、アクティブＮＶＭコンテンツの有効性をテストするとともに、アクティブＮＶＭのコンテンツが有効でない場合、ブートを中止し、これにより、ブートが失敗することを有する。

第２２実施形態： 第２１実施形態に基づいた、あるいは、前述の任意の実施形態に基づく方法、且つ、ブートローダーが、アクティブＮＶＭ中の識別子が、ＯＴＰ番号より大きいか否か、あるいは、ＮＶＭ、あるいは、アクティブＮＶＭ内容が有効かを判断する前、ブートローダーが、アクティブＮＶＭのコンテンツの有効性をテストする。

第２３実施形態： 第２実施形態に基づいた、あるいは、前述の任意の実施形態に基づく方法において、操作ｂ１、ｂ２は、認証コードにより実行される。

一般的に、認証コードは、ＮＶＭ、あるいは、ＲＯＭ中のＲＯＭコードブートブロック、あるいは、一／そのＯＴＰ中、あるいは、保護される埋め込みフラッシュ、あるいは、ＲＡＭ中の認証コード中に存在する。

第２４実施形態： 第２実施形態に基づく、あるいは、前述の任意の実施形態に基づく方法において、操作ｂ１、ｂ２は、ブートローダーにより実行される。

第２５実施形態： 第２実施形態に基づく、あるいは、前述の任意の実施形態に基づく方法において、本方法はさらに、
少なくとも一度、ファームウェアのメジャーアップデートを実行し、アクティブＮＶＭ中に保存されるブータブルファームウェアのバージョンを、ブータブルファームウェアの新しい"メジャー"バージョンで代替する、および、アクティブＮＶＭ中に保存される識別子を、高いメジャー番号を有する新しい識別子で代替すること；および
（ｖｉ）ブートが必要な少なくとも一つのリセット後、
ａ.ブートローダーに命令し：
アクティブＮＶＭ中のコンテンツの有効性をテストして、
アクティブＮＶＭのコンテンツが有効でない場合、ブートを中止し、よって、ブートの失敗を生じ、
少なくとも、アクティブＮＶＭのコンテンツが有効である場合、アクティブＮＶＭ中の識別子が、ＯＴＰ番号より大きいか否か判断する；および、
アクティブＮＶＭ中のメジャー番号がＯＴＰ番号より小さい場合、ブートを中止し、および、
ｂ.アクティブＮＶＭ中の識別子がＯＴＰ番号より大きい場合だけ、それぞれ、下記からなる操作ｂ４、ｂ５、ｂ６を実行する：
操作ｂ４. ブータブルファームウェアの新しいバージョンが、リカバリーＮＶＭ中に現在保存されるブータブルファームウェアのバージョンに書き込まれる；
操作ｂ５. リカバリーＮＶＭ中の識別子がアップデートされ、アクティブＮＶＭ中の識別子の値に等しくなる；および
操作ｂ６. ヒューズアレイ中のフリービットが、アクティブＮＶＭ中の識別子の値にプログラムされて、ＯＴＰ番号がアクティブＮＶＭ中の識別子に等しく、さらに、リカバリーＮＶＭの識別子に等しくなるように確保する、工程を有する。

理解できることは、ここで記述される操作の順序は、制限されることを意図していないことである。たとえば、操作ｂ４がまず実行され、次に、操作ｂ５、そして、操作ｂ６の順序である必要はない。その他の順序を用いることもできる。

第２６実施形態： 第２５実施形態に基づく、あるいは、前述の任意の実施形態に基づく方法において、操作ｂ４、ｂ５、ｂ６は、認証コードにより実行される。

一般的に、認証コードは、ＮＶＭ中に存在する。

第２７実施形態： 第２５実施形態に基づく、あるいは、前述の任意の実施形態に基づく方法において、操作ｂ４、ｂ５、ｂ６は、ブートローダーにより実行される。

第２８実施形態： 第４実施形態、あるいは、前述の任意の実施形態に基づくシステムにおいて、ＯＴＰ番号は、アクティブメジャーとリカバリーメジャー番号のそれぞれへの比較参照として用いられる。

第２９実施形態： 第１１実施形態に基づく、あるいは、前述の任意の実施形態に基づく方法において、認証は、プライベートキーとペアであるパブリックキーを使用し、パブリックキー（プライベートキーではない）がＲＯＭ中に保存される。

初期設定、および、アップデート段階は、それぞれ、図４と図５に示すように、独立、あるいは、分離、あるいは、組み合わせて、以下に記述あるいは説明される実施形態と関連して提供される。具体的には以下に示す。

図４は、ある実施形態による高いメジャー番号（“メジャーアップデート”）を有する新しいファームウェアイメージをロードする方法を説明する簡潔なフローチャートである。図４の方法は、一般的に、以下の操作の全て、あるいは、任意の集合を有し、例えば下記のように適当な順序で実行される。
工程４０１：第一ファームウェアイメージは、アクティブ、および、リカバリーＮＶＭ両方に、完全に同じように保存される。
ＯＴＰ番号は、両ＮＶＭ中に保存されるメジャー番号（アクティブバージョン番号=１.２，リカバリーバージョン番号=１.２，ＯＴＰ番号=１）に適合する。
工程４０２：新しいファームウェアイメージはアクティブＮＶＭ（高いメジャー番号を有する、（２.０，１.２，１））にロードされる。
工程４０３：リセット後、ブートローダーは、アクティブＮＶＭ内容の有効性と信頼性を認証、および、テストする（ファームウェアが有効でない場合、ブートローダーは中止）。
工程４０４：ブートローダーが、アクティブメジャーがＯＴＰ番号より大きいと判断すると、新しいファームウェアイメージは、リカバリーＮＶＭ中の古いファームウェアイメージ上に書き込まれる。（２.０，２.０，１）。
工程４０５：ヒューズアレイ中の別のビットがプログラムされ、この時、ＯＴＰ番号は、アクティブメジャー、および、リカバリーメジャー（２.０，２.０，２）と適合する。
工程４０６：リカバリーＮＶＭ、および、ヒューズアレイは、次のシステムリセットまでロックされる。メジャーアップデートが完了する。

図５は、ある実施形態による高いマイナー番号（“マイナーアップデート”）を有する新しいファームウェアイメージをロードする方法を説明する簡潔なフローチャートである。図５の方法は、一般的に、以下の操作の全て、あるいは、任意の集合を有し、例えば下記のように適当な順序で実行される。
工程５０１：第一ファームウェアイメージは、アクティブ、および、リカバリーＮＶＭ両方に、完全に同じように保存される。
工程５０２：ＯＴＰ番号は、両ＮＶＭ中に保存されるメジャー番号（アクティブバージョン番号=１.２，リカバリーバージョン番号=１．２，ＯＴＰ番号=１）と適合する。
工程５０３：新しいファームウェアイメージは、アクティブＮＶＭ（高いマイナー番号を有する，（１．３，１．２，１））にロードされる。
工程５０４：リセット後、ブートローダーは、アクティブＮＶＭ内容の有効性と信頼性を認証、および、テストする（ファームウェアが有効でない場合、ブートローダーは中止）。
工程５０５：ブートローダーが、アクティブマイナーが、リカバリーマイナーより大きいと判断すると、新しいファームウェアイメージは、リカバリーＮＶＭ中の古いファームウェアイメージに書き込まれる。（１．３，１．３，１）。この場合、ＯＴＰ番号は変化しない。
工程５０６：リカバリーＮＶＭ、および、ヒューズアレイは、次のシステムリセットまでロックされる。マイナーアップデートが完了する。

ＯＴＰ番号オフセットフィールド（たとえば、ここで記述される）を利用する寿命延長特徴は、ここで記述、あるいは、説明される任意の実施形態と同時に設けられてもよい。ＯＴＰ空間は制限される。ＯＴＰメモリの不可逆の、あるいは、破壊的な特徴は、新しいシリコンデバイスが、進化型ファームウェアバージョンでロードされることを意味する（多くのヒューズアレイビットが“焼かれる（burnt）”）。この状況は、ＯＴＰバージョンアップデートの寿命をさらに制限する。この状況を処理するために、ヒューズアレイ以外に、別の（“ＯＴＰ番号オフセット”）フィールドが、ＯＴＰ中で実施される。この実施は、ＯＴＰ番号が前進する番号から開始することを許し、新しいデバイスの寿命を延長する。

ある実施形態の長所は以下を含む。
外部メモリデバイス中の二個のバージョンフィールドの提供は、古いファームウェアのロールバック攻撃を防止する。攻撃者はファームウェアイメージを改ざんすることができないので、たとえば、ファームウェアイメージに対する任意の変化は、ＲＳＡ署名有効性を破壊するので、記述される抗ロールバックソリューションは特に優越している。リカバリーＮＶＭ上の（たとえば、ファームウェアの）保護は、アクティブＮＶＭファームウェアイメージ上の任意の非実体攻撃を防止する。攻撃者が、古いサイン済みのファームウェアイメージで、ファームウェアイメージを完全に上書きしたくても、リカバリーＮＶＭファームウェアイメージ、および、その大きいバージョン番号は、ブートローダーに、これが確実に、ロールバック攻撃であることを告知する。攻撃者が、古いファームウェアイメージ（元よりも低いバージョン番号を含む）で、物理的に、両ＮＶＭ（アクティブ、および、リカバリー）を代替する事象において、ＯＴＰ番号は、ブートローダーに、これが確実に、ロールバック攻撃であることを告知する。マイナーアップデートだけが実行された場合、上記のような両ＮＶＭの物理的代替は、たとえば、脅威を避けることができない。よって、ＯＴＰフィールドの提供は、（少なくとも）別の脅威を防止することができ、たとえば、新しいデバイス両方中、古いバージョンファームウェアにより、二個の外部メモリを代替することにより、二十のロールバック攻撃を実行する。

もう一つの長所は、バージョンデータが暗号化されておらず、よって、バージョン（一般的に、暗号化されていない形式で保存される）はアップデート可能であることである。

ある実施形態は、安全なバージョン管理を提供し、ＯＴＰ空間に制限があっても、最新のシステムにおいて、所定のシステムが受信できるアップデートの数量や回数を制限する。

ここで記述される寿命延長特徴は、以下の例により示されるように、十分に優れている。寿命が１５年の製品を考慮すると、この製品は、毎年、四回のメジャーアップデートを有し、製品が６４個のヒューズアレイビットを有する仮定する。新しいバッチが十年後に製造される場合、ここで記述される方法（寿命延長特徴を含む）は、新しいバッチの寿命を十年延長することができる。寿命延長特徴がない場合、ビット中の三分の二が、初期ファームウェアイメージ設定中で、直ちに“浪費”されるので、新しいバッチは、五年しか存続しない。“古い”デバイスは１５年の期限切れ後（あるいは、最大メジャーアップデート）は退役する必要がある。

上述の実施形態は、多くのバリエーションが可能である。たとえば、理解できることは、示される実施形態は、名称ではなく、バージョン番号を使用し、これらのバージョン番号は、メジャーとマイナーコンポーネンツを有し、メジャーとマイナーコンポーネンツはそれぞれ、逓増順序で割り当てられる。しかし、上述の実施形態中のこれらの特性は、排他性があることを意図しない。また、ある実施形態によると、ここで、二層保護を提供し、この保護において、メジャーファームウェアバージョンは、強い抗ロールバック保護を獲得し、マイナーファームウェアバージョンは、ロールバック攻撃に対し、弱い保護を獲得する。ここで記述されるＯＴＰ番号オフセットフィールド（たとえば、ここで記述されるメカニズム）を採用する寿命延長特徴は、提供される、あるいは、提供されなくてもよい。その他の実施形態によると、ここで、一層保護が提供され、この保護中、メジャーファームウェアバージョンに対してだけロールバック保護を実行し、ＯＴＰ番号オフセットフィールド（たとえば、ここで記述されるメカニズム）を採用する寿命延長特徴と組み合わされる。理解できることは、実施形態の適用性は、ＯＴＰ、および、二個のデバイスを含む任意のシステムに拡張させることができ、二個のデバイスの少なくとも一つは書込保護されるとともに、デバイスのファームウェアコードを保存する。

任意の一層の実施形態は、全非実体ロールバック攻撃を防止し、これらの攻撃は、アクティブＮＶＭの重ね書きを有するが、実体のロールバック攻撃から保護せず、これらの攻撃は、同時に、二個のＮＶＭを、古いファームウェアを含むＮＶＭに置き換える。後者の保護は、リカバリーＮＶＭは書き込みロックされるので、実体の存在を提供する二層の実施形態中で可能である。

理解できることは、書込保護されるＮＶＭは、最新バージョンの全体の複本を保存してもよく、あるいは、バージョン番号だけを保存してもよい。

ある実施形態を実施するのに用いられる場合、ファームウェアは、不揮発性メモリ（たとえば、フラッシュ、あるいは、ＲＯＭ）中に保存されてもよい。

あるいは、ここで記述されるある実施形態は、部分的、あるいは、全部（すなわち、ファームウェアなし）が、ハードウェア中で実施され、これらの実施形態中、ここで記載される変数、パラメータ、順次操作と演算の一部、あるいは、すべては、ハードウェア中にあってもよい。

理解できることは、たとえば、"強制（mandatory）"，"必要（required）"，"需要（need）"および"必須（must）"の専門用語は、実施の選択のことを指し、この選択は、特定の実施、あるいは、応用のコンテンツ範囲にあり、説明を簡潔にするため、ここで記述され、且つ、別の実施において、同じ素子は、強制でない、および、必要でないとして定義される、あるいは、完全に除去されるので、これらの語彙は、排他性を有することを意図しない。

別々の実施形態のコンテンツ中で記述される操作を含む本発明の特徴は、一つの実施形態中で組み合わせて提供することもできる。たとえば、システムの実施形態は、対応するプロセスの実施形態を含むことを意図し、逆もまた同様である。特徴は、従来の技術の特徴、および（特に、これに限定されないが）、従来の技術で記述される一節、あるいは、一節内で記述される公開文献中の特徴と組み合わされてもよい。反対に、簡潔にするために、単一の実施形態のコンテンツ中で記述される、あるいは、特定の順序で表わされる本発明の特徴（操作を含む）は、別々に提供される、あるいは、任意の適当な副結合で提供され、これらの副結合は、従来の技術の特徴（特に、これに限定されないが、従来の技術の一節で記述される、あるいは、そこで提示される公開文献中の特徴）を有してもよく、あるいは、異なる順序で示されてもよい。"たとえば（e.g）"が用いられて、排他性を有することを意図しない一個の範例を示す。各方法は、説明、あるいは、記述される操作の一部、あるいは、すべてを有し、たとえば、ここで記述される順序のような、適当な順序で実行されてもよい。

ここで記述される各素子（たとえば、操作）は、説明される全特徴を有する、あるいは、その他の実施形態に基づいて、ここで記述される特徴の任意の集合を有してもよい。

理解できることは、特に説明がない限り、二個以上の図面中で説明される素子、および／または、書かれた記述中の素子は単一の実施形態で結合することができる。理解できることは、本明細書、あるいは、当業者が特に示さない限り、ここで記述される任意の特徴、特性、ロジック、モジュール、ブロック、操作、あるいは、機能性は、単一の実施形態中で組み合わせて提供することができる。ここで記述される任意のシステムが用いられて、ここで記述される任意の操作や方法を実行する、あるいは、組み合わされてもよい。

Claims (28)

1. ロールバック攻撃を防止するコンピュータ制御システムであって、前記攻撃は、前記システムのファームウェアが変化するとき発生し、よって、前記ファームウェアのバージョンを定義し、前記システムは、（i）チップ、（ii）第一、および、第二不揮発性メモリ、および、（iii）ハードウェアデバイス、を有し、
   （ｉ）前記チップは、
   ａ.前記チップに集積されるブートローダー（別称、ブートＲＯＭコード）を有し、前記ブートＲＯＭコードは、前記チップがオンになるときはいつでも作動するＲＯＭコード、および、
   ｂ.バージョン識別子（たとえば、バージョン番号）を保存するプログラム可能なヒューズアレイメモリ（たとえば、ワンタイムプログラマブル（ＯＴＰ）メモリ）、を有し、
   （ii）前記第一（別称、アクティブ）、および、第二（別称、リカバリー）不揮発性メモリ（別称、ＮＶＭ）は、それぞれ、ブータブルファームウェア（別称、ブート上でロードされるファームウェア）のバージョンの第一、および、第二複製を保存し、
   第一識別子は前記アクティブＮＶＭ中に保存され、且つ、保存時に、前記バージョンを一意に識別し、前記バージョンの第一複製は前記アクティブＮＶＭ中に保存され、前記第一識別子は、少なくとも一つのアクティブメジャー番号およびアクティブマイナー番号を有し、共に、プライベートキーで署名され、
   第二識別子は前記リカバリーＮＶＭ中に保存され、且つ、保存時に、前記バージョンを一意に識別し、前記バージョンの前記第二複製は前記リカバリーＮＶＭ中に保存され、前記第二識別子は、少なくとも一つのリカバリーメジャー番号およびリカバリーマイナー番号を有し、共に、前記プライベートキーで署名され、
   （iii）前記ハードウェアデバイスは、ブートアップ後（ブートローダー完了時）、前記ブートＲＯＭコードにより提供される第一指令にしたがって、次のシステムリセットまで、少なくとも前記リカバリーＮＶＭをロックし（少なくとも書き込みを無効にする、書込保護を提供する）、前記リカバリーＮＶＭのロックは、前記ブートローダー以外の少なくとも前記リカバリーＮＶＭが書き込み可能ではない（書き込みにアクセス可能ではない）ことを確保するとともに、次のシステムリセット時、前記ブートＲＯＭコードにより提供される第二指令に従い、少なくとも前記リカバリーＮＶＭの書き込み保護を解除し、
   これにより、前記ファームウェアの新しいバージョンがすでに有効になると、前記ファームウェアの古いバージョンがブートされるのを防止し、
   前記の新しいバージョンと古いバージョンに関連するファームウェアイメージ、および、前記第一、第二識別子を、前記プライベートキーで署名し、
   前記ブートＲＯＭコードが設定されて、少なくとも一つのファームウェアイメージを認証するとともに、前記第一、および、前記第二識別子を認証することを特徴とするロールバック攻撃からシステムを保護する方法。
2. ロールバック攻撃からシステムを保護する方法であって、前記攻撃は、前記システム中のファームウェアが変化するとき発生し、よって、バージョンを定義し、本方法は、以下の（Ｉ）～（ＩＶ）の工程を有し、
   （Ｉ）システムを提供する工程：
   （ｉ）チップはａとｂを有し、
   a.ＲＯＭコード：前記チップに集積されるブートローダー（別称、ブートＲＯＭコード）を有し、前記ブートＲＯＭコードは、前記チップがオンになるときはいつでも作動する；および、
   b.プログラム可能なヒューズアレイメモリ（たとえば、ワンタイムプログラマブル（ＯＴＰ）メモリ）：バージョン識別子（たとえば、バージョン番号）を保存する；
   （ii）第一（別称、アクティブ）、および、第二（別称、リカバリー）不揮発性メモリ（別称、ＮＶＭ）：ブータブルファームウェア（別称、ブート時ロードされるファームウェア）のバージョンの第一、および、第二複製がそれぞれ保存される；
   第一識別子は前記アクティブＮＶＭ中に保存され、且つ、保存時に、前記バージョンを一意に識別し、前記バージョンの前記第一複製は前記アクティブＮＶＭ中に保存され、前記第一識別子は、少なくとも一つのアクティブメジャー番号およびアクティブマイナー番号を有し、両者は、プライベートキーで署名され、
   第二識別子は前記リカバリーＮＶＭ中に保存され、且つ、保存時に、前記バージョンを一意に識別し、前記バージョンの前記第二複製は前記リカバリーＮＶＭ中に保存され、前記第二識別子は、少なくとも一つのリカバリーメジャー番号およびリカバリーマイナー番号を有し、両者は、前記プライベートキーで署名され、
   （iii）ハードウェアデバイスは、ブートアップ後（ブートローダー完了時）、前記ブートＲＯＭコードにより提供される第一指令にしたがって、少なくとも前記リカバリーＮＶＭを次のシステムリセットまでロックし（別称、少なくとも、書き込みを無効にする、書込保護を提供する）、前記リカバリーＮＶＭのロックは、前記ブートローダー以外の少なくとも前記リカバリーＮＶＭが書き込み可能ではない（書き込みにアクセス可能ではない）ことを確保するとともに、前記ブートローダー以外に、前記ブートＲＯＭコードにより提供される第二指令は、次のシステムリセット時、少なくとも前記リカバリーＮＶＭの書き込み保護を解除し、これにより、前記新しいバージョンの前記ファームウェアがすでに有効になると、古いバージョンの前記ファームウェアがブートされるのを防止することができ、
   （ＩＩ）第一バージョンのブータブルファームウェアの複製（別称、第一ファームウェアイメージ）を、前記アクティブ、および、リカバリーＮＶＭ中に保存する工程：
   前記第一バージョンの少なくとも一つのメジャー番号の第一、および、第二複製を、それぞれ、前記第一、および、第二不揮発性メモリデバイス中に保存し；および
   前記ＯＴＰメモリの少なくとも一つのビットを前記メジャー番号に等しくなるように（適合するように）プログラムし；
   （ＩＩＩ）少なくとも一度、前記ファームウェアのマイナーアップデートを実行し、前記アクティブＮＶＭ中に保存されるブータブルファームウェアの前記バージョンを、前記ブータブルファームウェアの新しい"マイナー"バージョンで代替し、前記アクティブＮＶＭ中に保存される前記識別子を、高いマイナー番号を有する新しい識別子で代替する工程；および、
   （ＩＶ）ブートが必要な少なくとも一つのリセット後、以下を実行する工程：
   ａ.前記ブートローダーに命令し：
   少なくとも、前記アクティブＮＶＭのコンテンツが有効である場合、前記アクティブＮＶＭ中の前記識別子が、前記ＯＴＰ番号より大きいか否か判断し；および
   アクティブＮＶＭ中のメジャー番号が、前記ＯＴＰ番号より低い場合、ブートを中止し、
   ｂ．前記アクティブＮＶＭ（別称、アクティブマイナー）中の前記識別子が、前記リカバリーＮＶＭ（別称、リカバリーマイナー）中の前記識別子より大きい場合のみ、それぞれ、操作ｂ１、ｂ２を実行する：
   操作ｂ１. 前記ブータブルファームウェアの前記新しいバージョンが、現在前記リカバリーＮＶＭ中に保存される前記ブータブルファームウェアの前記バージョンに書き込まれ；
   操作ｂ２. 前記リカバリーＮＶＭ中の前記識別子がアップデートされて、前記アクティブＮＶＭ中の前記識別子の値に等しくなる
   ことを特徴とする方法。
3. 前記ＯＴＰメモリは複数のヒューズを有し、これらのヒューズは、バージョン番号を表示することを特徴とする請求項１に記載のシステム。
4. 前記ＯＴＰ（別称、ＯＴＰビット）中の複数のビットが用いられて、ＯＴＰ番号を表し、
   ＯＴＰ番号 = 開始番号 + 計数、
   前記複数のビットは一個のｎビットのアレイを有し、これにより、ｎビットインデックスを定義し、それぞれ、前記ｎビットと関連し、前記ｎビットは、値"０"を有するビットの（"第一"）集合、および、１にヒューズされたビットの（"第二"）集合を有し、前記計数は、１にヒューズされた前記ｎビットの（"第二"）集合に関連する数個のビットインデックス中から、最高インデックスとして決定されることを特徴とする請求項１に記載のシステム。
5. 前記ハードウェアデバイスは、前記アクティブＮＶＭの読み書きを無効にしないので、前記アクティブＮＶＭはブート後、読み書き可能であることを特徴とする請求項１に記載のシステム。
6. 前記第一ファームウェアイメージが、前記アクティブ、および、リカバリーＮＶＭ中に保存されるとき、前記ＯＴＰ番号は、両ＮＶＭ中に保存される前記メジャー番号と等しいことを特徴とする請求項２に記載のシステム。
7. 前記ハードウェアデバイスによる前記リカバリーＮＶＭのロックは、さらに、前記リカバリーＮＶＭからの読み取りを無効にすることを有し、前記リカバリーＮＶＭが読み取り可能ではないことを確保することを有することを特徴とする請求項２に記載の方法。
8. 前記リカバリーＮＶＭのロックは、前記リカバリーＮＶＭを切断する工程を有することを特徴とする請求項２に記載の方法。
9. 前記ハードウェアデバイスによる前記ＯＴＰのロックは、さらに、前記リカバリーＮＶＭからの読み取りを無効にする工程を有し、前記ＯＴＰが可読でないことを確保する工程を有することを特徴とする請求項２に記載の方法。
10. 前記ブートローダーの前記アクティブＮＶＭのコンテンツに対する有効性のテストは、前記アクティブＮＶＭのコンテンツと前記署名された暗号化認証（cryptographic authentication）を有することを特徴とする請求項２に記載の方法。
11. 前記認証は、前記プライベートキーとペアであるパブリックキーを使用し、前記プライベートキーではなく、前記パブリックキーが前記ＯＴＰ中に保存されることを特徴とする請求項１０に記載の方法。
12. 前記ブートローダーの前記アクティブＮＶＭのコンテンツに対する有効性のテストは、アクティブＮＶＭ中のメジャー番号が、前記リカバリーＮＶＭ中の前記メジャー番号に等しいか、それより高くなるように確保することを有することを特徴とする請求項２に記載の方法。
13. 前記ブートローダーの前記アクティブＮＶＭのコンテンツに対する有効性のテストは、少なくとも一つのシステムレベルテストから指示を提供して、少なくとも一つの所定基準を確保することを有することを特徴とする請求項２に記載の方法。
14. 前記基準は、前記新しいバージョンの前記ブータブルファームウェアが安定してブートされるという判定を有することを特徴とする請求項１３に記載のシステム。
15. 前記アクティブＮＶＭ中のメジャー番号が前記ＯＴＰ番号に等しい；且つ、
    前記ブートローダーにより、前記アクティブＮＶＭ中の有効な内容を検証する時かつその時に限り、
    前記ブートローダーのブートが成功することを特徴とする請求項２に記載の方法。
16. トラストチェーン（chain of trust）が、認証コードを用いて、少なくとも一回、繰り返して実行されて、追加メジャー、および／または、マイナーバージョン番号を有する追加コードレベルを認証し、さらに別のコードレベルを認証することができることを特徴とする請求項２に記載の方法。
17. 前記アクティブ、および、リカバリーＮＶＭは、二個の別々のメモリデバイスを有することを特徴とする請求項１に記載のシステム。
18. 前記アクティブ、および、リカバリーＮＶＭは、単一フラッシュデバイス上で、二個のメモリ範囲を有することを特徴とする請求項１に記載のシステム。
19. 前記開始番号は書き込み保護されることを特徴とする請求項４に記載のシステム。
20. さらに、前記アクティブＮＶＭのコンテンツが有効でない場合、前記ブートローダーに、前記アクティブＮＶＭのコンテンツの有効性をテストするように命令するとともに中止させ、これにより、前記ブートの失敗を生じることを有することを特徴とする請求項２に記載の方法。
21. 前記ブートローダーが、前記アクティブＮＶＭ中の前記識別子が前記ＯＴＰ番号より大きいか否か、あるいは、前記アクティブＮＶＭ内容が有効であるかを判断する前、前記ブートローダーは、前記アクティブＮＶＭのコンテンツの有効性をテストすることを特徴とする請求項２０に記載の方法。
22. 前記操作ｂ１、ｂ２は、認証コードにより実行されることを特徴とする請求項２に記載の方法。
23. 前記操作ｂ１、ｂ２は、前記ブートローダーにより実行されることを特徴とする請求項２に記載の方法。
24. 前記方法は、さらに、少なくとも一回、前記ファームウェアのメジャーアップデートを実行する工程を有し、前記アクティブＮＶＭ中に保存されるブータブルファームウェアの前記バージョンを、前記ブータブルファームウェアの新しい"メジャー"バージョンで代替するとともに、前記アクティブＮＶＭ中に保存される前記識別子を、高いメジャー番号を有する新しい識別子で代替することを有し；
    （ｖｉ）ブートが必要な少なくとも一つのリセット後、
    ａ.前記ブートローダーに命令し：
    前記アクティブＮＶＭのコンテンツの有効性をテストして、
    前記アクティブＮＶＭのコンテンツが有効でない場合、ブートを中止し、これにより、ブートの失敗を生じ、
    少なくとも、前記アクティブＮＶＭのコンテンツが有効である場合、前記アクティブＮＶＭ中の識別子が、前記ＯＴＰ番号より大きいか否か判断する；および、
    前記アクティブＮＶＭ中のメジャー番号が前記ＯＴＰ番号より小さい場合、ブートを中止し、および、
    ｂ.前記アクティブＮＶＭ中の識別子が前記ＯＴＰ番号より大きい場合だけ、それぞれ、下記からなる操作ｂ４、ｂ５、ｂ６を実行する：
    操作ｂ４. 前記ブータブルファームウェアの新しいバージョンが、前記リカバリーＮＶＭ中に現在保存されるブータブルファームウェアのバージョンに書き込まれる；
    操作ｂ５. 前記リカバリーＮＶＭ中の前記第二識別子がアップデートされ、前記アクティブＮＶＭ中の識別子の値に等しくなる；および
    操作ｂ６. 前記ヒューズアレイ中のフリービットが、前記アクティブＮＶＭ中の識別子の値にプログラムされて、前記ＯＴＰ番号が前記アクティブＮＶＭ中の識別子に等しく、さらに、前記リカバリーＮＶＭの識別子に等しくなるように確保する、工程を有することを特徴とする請求項２に記載の方法。
25. 前記操作ｂ４、ｂ５、ｂ６は、認証コードにより実行されることを特徴とする請求項２４に記載の方法。
26. 前記操作ｂ４、ｂ５、ｂ６は、前記ブートローダーにより実行されることを特徴とする請求項２４に記載の方法。
27. 前記ＯＴＰ番号は、前記アクティブメジャー番号、および、前記リカバリーメジャー番号のそれぞれに、比較参照として用いられることを特徴とする請求項４に記載の方法。
28. 前記認証は、前記プライベートキーと一対のパブリックキーを使用し、前記プライベートキーではなく、前記パブリックキーが、ＲＯＭ中に保存されることを特徴とする請求項１０に記載の方法。

Images