デバイス上の機能を制御するためのシステムおよび方法

专利摘要:
アップグレードまたは有効化／無効化プロセスに関与する実体間の信頼が構築され、これを遠隔かつ安全に促進するために、生産されるシステム内の高耐不正利用信頼点が、使用される。本信頼点は、より効率的流通システムの使用を有効化する。プロビジョニングプロセスを通じて、または後の段階において、すなわち、インストール、製造、アセンブリ、販売等に続いて、修正されるデバイスまたはシステム上の機能コントローラとして具現化される信頼点は、検証されると、全体的機能を有効化または無効化するために、あるいは機能の一部を活性化するために使用される、機能セット（すなわち、アップデートされた機能セット）が、与えられる。
公开号:JP2011508997A
申请号:JP2010537218
申请日:2008-12-11
公开日:2011-03-17
发明作者:デイビッド ウォン，；ダニエル オログリン，；デイビッド；アール． セクイーノ，；マイケル ダスカロポーロス，；アショク バデカー，；ウィリアム ラティン，
申请人:サーティコム コーポレーション；
IPC主号:H04L9-08

专利说明:

[0001] 本発明は、デバイス上の機能の制御に関する。]
背景技術

[0002] 過去２０年にわたって、電子機器製造業者は、数少ない高度に縦型の完全統合会社から、業務委託型事業モデルに依存するモジュラー的価値を伴う、数多くの専門会社へと移行した。半導体製造、操業、および調達の海外への業務委託は、その独自の操業および流通プロセスへの製造業者の可視性を低減させる。その結果、製造業者は、重要となる委託されたプロセスおよび情報の制御を喪失する。本業務委託の結果、これらの製造業者が、最大限の制御および低リクスによって操業を行なう能力に、直接的負の影響を及ぼす。]
[0003] 業務委託は、偽造部品存在のリスク上昇のため、顧客のサプライチェーンにおけるその製品の品質を強化する製造業者の能力を低下させる。真正商品の納品を顧客に保証する製造業者の能力は、益々困難になりつつある。偽造および再利用部品は、元請製造業者に未知の業務委託接点において、随時、委託製造業者によって挿入され得る。偽造部品は、収益の損失だけではなく、製品の返品、負債の増加、およびブランドの弱体化にも影響する。可能性は低いが、偽造は、統合型デバイス製造業者（ＩＤＭ）ならびにファブレス企業にも影響を及ぼし得る。]
[0004] 業務委託によって導入される相互依存性もまた、製造業者が、そのサプライチェーンを最適に管理するのを困難にし、在庫負債およびリスクを増加させる。顧客のジャストインタイム生産戦略を支持するために必要とされる、一貫した期限通りの納品が、損なわれることになる。サプライチェーンの非効率性を補償するために、安全な備蓄レベルが上昇し、その結果、所与の総利益をもたらすために要求される資産の金額が増大する。リスクおよび損失の継続的増加に伴って、業務委託から見込まれる報酬は、それほど魅力的なものではなくなる。]
[0005] 図１は、ＯＥＭが、１、２、および３として識別される３種類のデバイスまたはシステムを生成することを委託製造業者と契約している場合の可能性のあるシナリオを示す。これらのデバイスはそれぞれ、異なる機能または性能の組を実装する。委託製造業者は、各デバイス種の在庫を管理し、例えば、生産ピーク期の間、受注され得るＯＥＭ注文を充足させなければならない。ＩＤＭは、ＯＥＭが、エンド顧客に製品の差別化を提供可能なように、３つの別個の製品ＳＫＵを維持し、委託製造業者に３つの別個のデバイスを提供しなければならない。設計開発、マスクセット、ウエハ加工、試験、およびパッケージ化において繰り返し発生する資本コストが、３つのＩＣデバイスにわたって償却される場合、非常に高くつき得る。さらに、長期間にわたる製造リードタイムおよび短製品寿命を考慮すると、繰り返し発生する資本費用は、デバイス製造業者にとって、さらに負担となる。] 図１
[0006] 複数のデバイス種の在庫を維持することは、デバイス製造業者にリスクを招く。あるシナリオでは、デバイス製造業者は、複数の製品ＳＫＵを在庫として持ち、ＯＥＭを供給することを決定すると、デバイスを過剰備蓄するリスクを増大させ得る。例えば、図１では、委託製造業者は、種類１、２、および３の各デバイスを備蓄し得る。経時的に、デバイス種２のみ、予測数量で売れるとする。過度に楽観的数量予測は、デバイス種１および３の過剰備蓄をもたらし得る。余剰デバイスは、損金処理される、または大幅な割引で販売される必要があり得る。別のシナリオでは、デバイス製造業者は、サプライチェーンに追加時間を投入し、必要に応じて、各デバイス種を製造することによって、楽観的数量予測のリスクを低減させる。デバイスの納品遅延は、完成品の価値を低下させる、またはＯＥＭは、製品投入の時期を逸することになり得る。] 図１
[0007] また、デバイスが、パラメータ試験に基づいて、分割または分類される状況も存在する。一実施例は、コンピュータ中央処理ユニット（ＣＰＵ）チップが、その最高クロック周波数に基づいて差別化される場合に生じる。ＣＰＵのクロック周波数が高いほど、処理性能の向上がもたらされる。したがって、ＣＰＵの価値は、最高クロック周波数にある程度比例して変動する。時として、全体的製造ロットの出来高が、低性能改良型デバイスの市場の数量要件を超え得る場合もある。デバイス製造業者は、低性能グレードデバイスを流通させ、デバイスのクロック周波数を増加させることによって、それらをアップグレードする権限選択肢を提供し得る。デバイス製造業者が、本アップグレードの権限を安全に付与不能である場合、デバイス製造業者の収益増強機構が奪取されることになる。デバイス製造業者にとっての別の収益の潜在的損失は、定格されたＣＰＵデバイスよりも高いクロック周波数にアップグレードされた修正システム内の部品に対する保証クレームによって生じる。本不正アップグレードの結果、デバイスは、仕様外で動作し、その後、熱応力のため損傷を受け、またはタイミング違反によって生じる故障モードのため、予測不能に動作し得る。]
[0008] ワイヤボンディング、レーザヒューズ、およびゼロオーム抵抗に基づく、従来の方法のデバイス特有機能プロビジョニングが存在する。これらの種類の接続は、委託製造業者による製造プロセスにおいて、再販業者による流通の間、またはエンドユーザによる市販後、追加あるいは除去され得る。これらの場合、デバイス製造業者は、典型的には、より価値の高い非認可機能に対して、支払を強制できない。また、これらの従来のプロビジョニング手法は、典型的には、製造環境外では生じ得ない。]
発明が解決しようとする課題

[0009] 製品を差別化する一方、在庫管理に及ぼす差別化の影響を最小限にするとともに、ベンダーまたは他の実体に、特定のデバイス、プラットフォーム、あるいはシステム内に追加もしくは有効化／無効化可能な機能の安全な制御を提供する競合する目的に対処し得る、機能プロビジョニングシステムの必要性が存在する。また、製造環境外における安全なプロビジョニングも有効化可能なシステムは、ＩＤＭおよび／またはＯＥＭに付加的利益をももたらし得る。]
課題を解決するための手段

[0010] 一側面では、システム上の機能を制御するための方法であって、暗号化操作を実行可能なシステム内に少なくとも１つの機能コントローラを提供するステップと、機能コントローラと機能制御サーバとの間の接続を構築するステップと、機能制御サーバから機能セットを受信するステップであって、機能セットは、暗号化処理を受けている、ステップと、受信した機能セットに対し補完的暗号化処理を実行し、システム内における機能セットの実装を許可するステップと、機能セットを実装し、機能のうちの１つ以上を制御するステップとを含む方法が提供される。]
[0011] 別の側面では、システム上の機能を制御するための機能コントローラであって、システムは、機能制御サーバとの接続を構築し、そこから機能セットを受信するために構成され、メモリへのアクセスと、暗号化ユニットであって、システムから機能セットを取得することであって、機能セットは、暗号化処理を受けている、ことと、メモリ内に格納されている情報を使用して、受信した機能セット上の補完的暗号化処理を実行し、システム内における機能セットの実装を許可することを行うように構成されている、暗号化ユニットとを備えている、機能コントローラが提供される。]
[0012] さらに別の側面では、システム上の機能を制御するためのコンピュータで実行可能な命令を含むコンピュータで読み取り可能なトレージ媒体であって、該媒体は、暗号化操作を実行可能なシステム内に少なくとも１つの機能コントローラを提供することと、機能コントローラと機能制御サーバとの間の接続を構築することと、機能制御サーバから機能セットを受信することであって、機能セットは、暗号化処理を受けている、ことと、受信した機能セットに対し補完的暗号化処理を実行し、システム内における機能セットの実装を許可することと、機能セットを実装し、機能のうちの１つ以上を制御することとを行うための命令を含む、コンピュータで読み取り可能なストレージ媒体が提供される。]
図面の簡単な説明

[0013] 次に、本発明の実施形態が、添付の図面を参照して、単なる一例として、記載される。
図１は、別個の在庫流動を有する複数の製品種を伴う、流通チャネルを示す、概略図である。
図２は、単一在庫流動から生じる複数の製品種を伴う、流通チャネルを示す、概略図である。
図３は、システム上の機能を制御するためのシステムの概略図である。
図４は、デバイスまたはシステム上に機能制御を実装する際、講じられるステップを示す、フロー図である。
図５は、機能レジスタを利用する、図３に示される機能コントローラの概略図である。
図６は、図３に示されるシステムおよびサブシステムのためのメモリマップの概略図である。
図７は、機能を有効化および無効化するための許可を含む、デバイス上のメモリ内に格納される禁止および許可マスクを示す、概略図である。
図８は、図３のシステムをアップグレードするための手順を示す、フロー図である。
図９は、製造の間および市販後、機能を有効化および無効化するためのシステムを示す、概略図である。
図１０は、機能の復号化の間のメッセージ認証手順を示す、フロー図である。
図１１は、機能コントローラの別の実施形態の概略図である。
図１２は、図３に示される機能制御サーバ（ＦＣＳ）および機能コントローラ（ＦＣ）の別の実施形態の概略図である。
図１３は、認証を含む、機能制御を実装するための例示的プロトコルを示す、フロー図である。
図１４は、認証および機密性を含む、機能制御を実装するための別の例示的プロトコルを示す、フロー図である。] 図１ 図１０ 図１１ 図１２ 図１３ 図１４ 図２ 図３ 図４ 図５
実施例

[0014] 以下は、製造業者が、その事業の操業および流通機能を業務委託することによるプロセスの制御および情報損失を取り戻すための方法を記載する。制御を回復する結果、その製品の製造および流通サイクルにおけるリスクが低減し、コストが削減される一方、より高い品質が保証される。加えて、本方法は、部品の販売および流通を超えて、製造業者による製品の制御を拡張し、エンドユーザ会社および個人が、製造業者から直接アップグレード機能を購入可能となる市販後の収益機会を可能にする。]
[0015] システムが使用され得る方法の一実施例は、デジタルテレビシステムオンチップデバイスにおけるものであって、単位当たりのロイヤルティの支払目的のために計上され、監査可能となる必要がある多くの異なる固有の知的財産機能例である。デジタルテレビシステムオンチップのある顧客は、そのデジタルテレビのチップ内において、特定の知的財産を有効化し、付随するロイヤルティを支払うことを所望する一方、他の顧客は、本コストを負担することを所望しない場合がある。さらに、当該知的財産の所有者は、契約上の理由から、デジタルテレビシステムオンチップ製造業者による本知的財産の使用の終了を所望する場合がある。そのような場合、システムオンチップ製造業者が、チップモデルに基づいて、知的財産を活性化または不活性化可能である一方、知的財産所有者の知的財産の使用上の権利主張能力および監査能力を両立させるシステムは、特に、有用であり得る。]
[0016] 本明細書に記載のシステムは、デバイスの製造および流通の間ならびにその後、随時、遠隔かつ安全に、集積回路デバイスまたは信頼できるデバイスを識別、監査、およびプロビジョニングするための方法を提供する。本方法は、個々の半導体チップまたはデバイスの識別を生成、格納、および認証するための安全かつ機密性のある方法を提供し、権限が付与されて有効化されない限り、デバイスの操作を防止することによって、偽造を防止するために使用可能である。また、本概念は、プラットフォームの生産および流通の間ならびにその後、随時、製造業者によってのみ安全に提供され得る、共通デバイスまたはシステムプラットフォームを可能にする。]
[0017] 安全なプロビジョニングは、チップ、デバイス、またはプラットフォームの寿命の間、随時、製造業者によって利用され、単一プラットフォームに基づいて、固有の製品を安全に供給およびアップグレード可能である。単一プラットフォームは、維持、追跡、および保管される必要がある、最小在庫管理単位（ＳＫＵ）数を減少させる。単一プラットフォームを生産および流通させるコストは、本安全なプロビジョニングプロセスから生じる複数の製品にわたって償却され得る。加えて、本プロビジョニングは、プラットフォームが出荷される間際に実行され、したがって、特定のＳＫＵのジャストインタイム製造に対応可能である。本発明によって提供されるこれらの性能は、在庫管理の多くの側面を根本的に簡素化し、業務委託事業モデルにおけるより効率的サプライチェーンを可能にする。]
[0018] 以下の方法において最も重要なことは、安全性である。機密性および認証機構は、偽造を防止し、機能有効化／無効化の安全な制御を提供するために使用可能である。加えて、製造および流通の間ならびにその後、随時、安全かつ一意のデバイス識別子を通じて、各デバイスの監査証跡を作成する能力は、偽造検出を提供する。安全なプロビジョニングによって提供される付加的柔軟性は、「低性能」デバイスから「高性能」デバイスへの不正アップグレードの可能性を防止する。本方法の安全特性は、業務委託環境における半導体デバイスまたはシステムプラットフォームの識別、知的財産、および価値の制御を再構築し、その所有権を行使するために、製造業者によって使用され得る。]
[0019] 上述のような柔軟なデバイスプラットフォームを使用することによって、製造業者またはベンダーは、製品ＳＫＵを削減し、在庫を減少させ、製造コストを最小限にすることが可能である。異なる数の機能が、同一デバイスプラットフォーム上に提供され得るが、デバイス製造業者の知的財産および各機能に付随する対応する収益金を保護する根底にある必要性が存在する。デバイス機能の不正有効化を防止する一方、同時に、複数の製品に単一デバイスプラットフォームを提供する能力は、デバイス製造業者にとって望ましい。]
[0020] （例えば、異なるグレードまたは精巧度の）別個の製品を最終的に生産する単一在庫流動を有する柔軟性を提供し、有効化、無効化（部分的または完全に）、または再有効化する能力を提供するために、アップグレードまたは有効化／無効化プロセスに関与する実体間の信頼を構築する必要があることが認識されている。これを遠隔かつ安全に促進するために、生産されるシステム内に高い耐不正利用信頼点が、存在することを必要とする。その結果、信頼点が、数字１２によって示される、図２に示されるより効率的流通システムが使用され得る。プロビジョニングプロセスを通じて、または後の段階において、すなわち、インストール、製造、アセンブリ、販売等に続いて、以降、機能コントローラ（ＦＣ）１２と称される信頼点が、検証されると、全体的機能を有効化または無効化するために、あるいは機能の一部を活性化する（例えば、５０％電力または速度）ために使用される機能セット（すなわち、アップデートされた機能セット）に提供される。以降、用語「機能セット」とは、無効化、有効化、活性化、不活性化、アップグレード、デグレード、部分的活性化、部分的不活性化、一時的制御等のための任意のデータ、情報、または命令セットを指す。この場合、「部分的」とは、機能が、その完全性能への／からのアップグレード／ダウングレードされることを意味する。] 図２
[0021] 次に、図３を参照すると、ＦＣ１２を使用する機能の制御を促進する際に関与し得るいくつかの実体を含む、機能制御システム１０が提供される。図３に示されるように、ＦＣ１２は、サブシステム１３も含む、システム１１の一部である。したがって、ＦＣ１２は、任意の構成および任意の場所における任意のシステムまたはシステムの階層に対応得る。システム１１内に示されるが、ＦＣ１２は、別個の部品または機能であり得、制御される機能１４とともに常駐する必要はない。システム１１は、任意のデバイス、部品、製品、モジュール、またはハードウェア、ソフトウェア、および他の部品を組み合わせた真正システムを指すことを理解されたい。示される実施例では、システム１１は、機能Ｎまでの機能１、２、および３を含み、機能Ｎ−１は、サブシステム１３内に常駐する。実際には、システム１１は、同一基板上の補助機能であるが、メインプロセッサによって制御されるか、またはそれと協働するサブシステムを伴う、メインプロセッサであり得る。機能１−Ｎの制御（例えば、どの機能を活性化するか）は、どの１つ以上の機能が、アップグレード／デグレード（完全または部分的に）、活性化／不活性化されるべきか等を示す情報を含む、機能セット（ＦＥＡＴ）４０によって指示される。] 図３
[0022] ＦＣ１２は、システム１１およびサブシステム１３（該当する場合）と機能制御サーバ（ＦＣＳ）１６との間の信頼点である。ＦＣＳ１６は、典型的には、ＦＣ１２から遠隔であって、製造または試験施設、システム１１の販売および／またはサービス点、あるいは機能セットＦＥＡＴ４０を生成および送信することによって、機能を活性化または不活性化するための許可を計測する責任を担うとみなされる任意のベンダーに配置され得る。ＦＣＳ１６は、機密情報の配信およびデバイスへの投入を制御可能な任意のシステムであり得る。特に好適な種類のシステムは、２００６年６月１２日出願の同時係属米国特許出願第１１／４５０，４１８号（その内容は、参照することによって、本明細書に組み込まれる）に記載のようなキー投入システムである。そのようなキー投入システムは、デバイス登録を遠隔から監視し、デバイスへの固有かつ不変の情報の投入を計測するために使用可能である。また、ＦＣＳ１６は、キー生成、キー一致、署名生成、署名照合、暗号化、復号化等の任意の必要暗号化操作を実行するように構成される、暗号化ユニットまたはプロセッサを含む。]
[0023] 図３に示されるような１つのＦＣＳ１６、またはＦＣ１２へのコマンドがそれを通って流れるＦＣＳユニット１６の階層が存在し得る。図３に示されるように、ＦＣＳ１６は、中間システム１８、例えば、試験台、製造ライン、小売業者、ウェブサイト、売店、無線システム等を通じて、ＦＣ１２と通信および接続し得る。ＦＣＳ１６は、一意の識別子（ＵＩＤ）、ならびに暗号化キーおよび機能１４を制御するためにＦＣ１２によって使用されるメッセージまたはコードのコピー等、各システム１１に関連する情報を格納する、バックエンドデータベース２２と通信する。また、バックエンドデータベース２２は、多くのシステム１１をプロビジョニングまたはアップグレードすることを所望する正規ベンダーに対するクレジットを計測するために、ＦＣＳ１６によって使用される情報を含み得る。] 図３
[0024] バックエンドデータベース２２は、示されるような別個の実体であり得、または代わりに、ＦＣＳ１６と統合され得、オンライン、オフライン、または両方の組み合わせで動作し得る。また、課金システム２４は、典型的には、異なるベンダーおよびユーザに、アップグレードを購入させ、あるいは必要に応じて、ある機能を不活性化またはデグレードさせるために存在し、また、オンライン、オフライン、または両方の組み合わせであり得る。そのようなアップグレードおよびアップグレードは、機能１４のオン／オフを起動させること、機能の性能の割合を変更すること、性能の一部を追加または除去すること等が可能である。各メッセージまたはコードは、絶対的である、または例えば、試用期間、繁閑期等、一時的であり得る。課金システム２４によって、ベンダーまたはＯＥＭは、活性化および不活性化から収益を収集可能となり、ユーザまたは他のベンダーは、必要に応じて、システム１１を購入、アップグレード、およびカスタマイズ可能となる。ＦＣ１２によって提供される信頼点は、料金またはクレジットと引き換えに機能制御を促進する。また、図３には、ユーザ２６も示される。システム１１（および、サブシステム１３）を所有、操作、または責任を担う、ユーザ２６は、システム１１内にＦＣ１２を有することによって、アップグレードを事後購入可能であって、任意に、課金システム２４を通じて、アップグレードの代価を支払うことが可能である。バックエンドインフラストラクチャ、特に、バックエンドデータベース２２は、典型的には、スキーム内での使用のためのデジタル証明書を発行する信頼できるＣＡ１０１と通信するか、またはそれを有する。] 図３
[0025] ユーザ２６による市販後購入は、例えば、課金システム２４、ＦＣＳ１６、バックエンドデータベース２２、またはこれらの実体の任意の組み合わせを通じて、ユーザインターフェース（ＵＩ）２５からバックエンドシステムへと行なわれ得る。ＵＩ２５は、ウェブベース、電話回線ベースであり得、さらに、売店または第三者ベンダーを利用し得る。ほとんどの用途に対して好まれるウェブベースＵＩ２５は、ユーザ２６がアップグレードを所望するデバイスまたはシステム１１の製造業者、あるいは製造業者の代わりに行なう別の実体によって、ホスティングされ得る。]
[0026] 必要に応じて、特に、複数の製造段階が使用される場合、あるベンダーが、その責任を担う段階において、どの機能を（および、いつ）プログラムするかを規定可能であるように、実体間に他のユーザインターフェースが存在し得る。例えば、ＦＣＳユニット１６の階層が使用され、その場合、独立ホストが、ＣＡ１０１、バックエンドデータベース２２、および課金システム２４をホスティングする。ファブレス半導体ベンダーは、ＦＣＳユニット１６のうちの１つおよび必要とされる任意の試験機器を有するであろう。本ベンダーは、独立ホストに、特定の機能メッセージを作成し、支払と引き換えに、ベンダーにそれを送信するための命令を提供可能である。これは、ベンダーが、命令および支払を発行し、独立ホストが、支払を処理し、ベンダーのＦＣＳ１６に機能を作成および発行するための方法を提供する。バックエンドシステム（ＦＣＳ１６、データベース２２、課金システム２４、およびＵＩ２５）は、独立ホストまたはサービスによってホスティングされるか、あるいは生産チェーン内のベンダーのうちの１つによって、業務委託もしくは集合的に運営され得ることを理解されたい。]
[0027] ＦＣ１２は、システム１１内における信頼点を提供するため、システム１１内へのＦＣ１２の組み込みは、プロビジョニング、アップグレード、デグレード、活性化、不活性化、ログレポート、一時的活性化等を可能にする。信頼点を構築するために、ＦＣ１２およびＦＣＳ１６は、暗号化的に安全な交信をする。いくつかの実施形態では、ＦＣ１２が、システム１１内から内部キー生成を実行可能であって、これらの種類の操作は、遠隔から、生産／製造後に、安全に行なわれ得る。これによって、ベンダー、小売業者、およびユーザは、料金と引き換えに、システム１２への付加価値を促進および実行するか、または無料サービスを提供することが可能となる。また、これによって、購読型サービスまたは一時的ベースのアップグレードが制御可能となることに留意されたい。これは、試用期間、単回支払、または別の所定の取り決めを供給するために使用され得る。図４は、機能または機能セットのバックエンド処理が生じた後のＦＣＳ１６とＦＣ１２との間の基本的交信におけるステップを表す、フローチャートを示す。そのようなバックエンド処理は、機能コマンドの作成、署名、および／または暗号化、ならびに図４に示されるステップを促進するために必要とされる任意の他の処理を含み得る。] 図４
[0028] ステップ５０では、接続が、ＦＣ１２とＦＣＳ１６との間に構築される。製造の間は、これは、試験のための機構、例えば、シリコンまたはシステムあるいは用途特定のカスタムハードウェアのためのハードウェア試験機を通じて行なわれ得る。システム１１の販売後は、これは、事実上、任意の場所において、任意の通信機構を使用して、例えば、インターネットを通じて、売店または小売業者において行なわれ得る。好ましくは、ステップ５１において実行される、ある形態の暗号化処理が存在する。本暗号化処理は、キー一致、機密性のための暗号化、メッセージ認証コード、および認証のための署名生成プロセスを含み得る。例えば、対称キーまたは非対称キー等、どの種類の暗号化処理を実行するかの選択は、用途に依存する。]
[0029] ステップ５２では、機能または機能セットＦＥＡＴ４０は、暗号化的に処理されると、次いで、ＦＣＳ１６からＦＣ１２へと送信される。後述のように、これは、ＦＣＳ１６およびＦＣ１２が、任意に、互いに照合され、任意のキーが、復号化を許可するために構築された後等に行なわれるであろう。次いで、ＦＣ１２では、復号化、メッセージ認証、署名照合、および他の関連操作のために、さらなる暗号化処理が、ステップ５３において、要求される。交信が照合され、機能セットが取得されると、機能セットは、ステップ５４において、実装される。これは、典型的には、機能を設定すること、機能をオフにすること、機能をオンにすること、または新時限を構築すること、あるいはある機能を活性化するためのクレジットを使用することを伴う。任意に、ステップ５５では、機能セットの実装の成功を確認するためのレポートが、ＦＣＳ１６に送信され、監査、入金、および他の目的のために、ＦＣＳ１６によって記録され得る（所望に応じて）。]
[0030] 本明細書に記載される好ましい実施形態それぞれに対して、実施形態の実際の実装は、非動作状態にある場合、ＦＣ１２を探査し得る試験回路または方法によって、ＦＣ１２内に格納される秘密データへの不正アクセスを防止するように設計されるべきであることに留意されたい。この場合の例は、ＦＣダイが、走査チェーンを使用して、初期試験を受けている場合であるだろう。これらの走査チェーンは、ＦＣ１２の安全なメモリ領域にアクセスするために使用可能である。本明細書に記載される好ましい実施形態はそれぞれ、秘密データとともにプログラミングされると、安全なメモリへのアクセスを防止するための特定の論理回路およびプログラミング状態を含むべきである。]
[0031] 機能セットＦＥＡＴ４０を実装するステップ、すなわち、図４に示されるステップ５４は、多くの方法で行なわれ得る。一実施例は、図５に示される。次に、図５を参照すると、ＦＣＳ１６から取得された機能セットＦＥＡＴ４０は、ＲＡＭ、ハードディスク等のＦＣ１２のメモリＭｘ１４２の任意の部分内に格納され得る。ＦＣ１２は、機能セットが実装されるべき場合、Ｍｘ１４２からＦＥＡＴ４０を取得し、別のメモリＭｘ２４４からの任意の必要とされる暗号化データ４２にアクセスし得る。次いで、暗号化処理５３は、ＦＥＡＴ４０に適用され、機能セットを回復および／または認証し得る。機能セットは、本実施例では、レジスタ４６に書き込み、活性化、不活性化、あるいはどれくらい機能を有効化または無効化するかを決定することによって実装される。本レジスタ４６は、任意に、ＦＣ１２の一部でなくてもよい。単純な例では、機能は、単に、オンまたはオフにされ、レジスタは、対応する機能１４を活性化および不活性化するためにトグルされる、図５に示されるようなビット配列または列４８を含み得る。システム１１が使用されると、レジスタ４６から特定の機能１４への制御ラインは、レジスタ４６内の対応する要素に書き込まれたものを有する機能１４を活性化するであろう。代替として、システム１１のＣＰＵは、レジスタ４６を読み出し、どの機能を活性化または不活性化するかを決定し得る。] 図４ 図５
[0032] 機能セットＦＥＡＴ４０を実装するための別の方法は、メモリマップ１６４に従って、機能セットマスクを実行することによるものである。]
[0033] 次に、図６を参照すると、システム１１内のメモリマップ１６４が、示される。本メモリマップ１６４は、単一連続メモリを記述する表現であり得、あるいは統一かつ論理的に表現される、システム内（例えば、チップ内および／またはチップパッケージ内）の異なる物理的および／または論理的場所における異なる種類のメモリの集塊の表現であり得る。図６では、任意のメモリ部分Ｍ１、Ｍ２、Ｍ３、およびＭ４が、例証目的のためだけに示される。実施例内のメモリマップ１６４は、任意の物理的種類のメモリであり得る。これは、読み出し専用メモリ（ＲＯＭ）、１回限りプログラム可能メモリ（ＯＴＰ）、不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）、または揮発性ランダムアクセスメモリ（ＲＡＭ）を含み得るが、これらに制限されない。例えば、図６では、特定の実施例は、第１の種類（Ｍ１）であるＯＴＰ、第２の種類（Ｍ２およびＭ３）であるＮＶＲＡＭ、および第３の種類（Ｍ４）であるＲＡＭを伴う、３種類のメモリを含み得る。しかしながら、実際には、最低、１種類のメモリ、最大、当該チップ１１２内に適合する任意の用途によって必要とされる数が存在し得る。] 図６
[0034] メモリマップ１６４は、ＦＣ１２によって、アクセスされる。ＦＣ１２は、メモリマップ１６４からの読み出しおよび／またはそこへの書き込みとともに、システム１１の製造および使用における各関与者の要件に従って、かつチェーン内の上流および／または下流点からの階層的要件に関して、メモリマップ１６４のコンテンツを解釈可能である。また、ＦＣ１２は、メモリおよび論理ＢＩＳＴ試験モード、ＪＴＡＧ境界走査試験モード、ＡＴＰＧ走査チェーン試験、クロッキング、およびリセット機構等を含むが、それらに制限されない、デバイス内外の動作および試験モードを通じて、他の論理関数によって、メモリマッププログラミングへのアクセスを制御するであろう。また、ＦＣ１２は、乱数発生、ハッシング、対称および非対称暗号化、デジタル署名および照合、ならびにメッセージ認証等、任意の暗号化関数を実行し得る。]
[0035] メモリマップ１６４のコンテンツは、以下の要素のうちの１つ以上を含み得る。メモリマップのコンテンツの処理方法（明示的に、または含まれる情報の構造を通じて）に関するコントローラのための情報、システム１１の製造プロセスおよび／または使用中の異なる点において実行される、挿入時あるいはその後のアップデート操作時、特定の操作を許可もしくは禁止するかどうかを示す、図７に示されるような機能セット「マスク」情報、ならびに暗号化および認証情報。プログラミング後、メモリマップ情報は、ＦＣ１２によって、読み出しおよび解釈され、デバイスがブートされる度、デバイス内に含まれる禁止および許可マスクを解釈可能である。ＦＣ１２は、デバイスが、既存メモリマップ１６４によって許可される動作状態に置かれ、必要な時に必要な場所において、アップデートを促進するように、これを行なう。
次に、図７を参照すると、機能セットマスクの使用が示される。図７内の各ボックスは、特定のマスクがシステム１１本体上に格納されるメモリ空間を表す。許可マスク２０４および禁止マスク２０２は、機能有効化および／または無効化のための要件に基づいて、生成され得る。メモリブロックＭ１の場合、許可マスク２１２は、オンにされ得る機能を含み、禁止マスク２０６は、オンにされ得ない機能を含むことが分かる。図７に示される実施例では、Ｍ２／Ｍ３は、許可マスク２１４および禁止マスク２０８を有し、Ｍ４は、許可マスク２１６および禁止マスク２１０を有する。許可マスク２１２、２１４、２１６の場合、コンテンツは、機能に対応する論理の関数ブロックに対する有効化ビットを制御するような単純な単一バイナリビットであるか、または機能に対応する論理の関数ブロックに読み出される数的オフセットに対応するより複雑な形式の２進数であるか、あるいは許可される機能に対応する論理の関数ブロックのファームウェアまたは論理構成のように複雑であり得る。禁止マスク２０６、２０８、２１０の場合、コンテンツは、機能に対応する論理の関数ブロックに対する無効化ビットを制御するような単純な単一バイナリビットであるか、または機能に対応する論理の関数ブロックに読み出される数的オフセットに対応するより複雑な形式の２進数であるか、あるいは許可される機能に対応する論理の関数ブロックのファームウェアまたは論理構成のように複雑であり得る。] 図７
[0036] システム１１内の各ＦＣ１２に対する禁止マスクおよび許可マスクの優先順位は、各機能に対する禁止または許可が優先されるべきであるかどうかに関して論理的に優先順位を付けるような、許可および／または禁止マスク内の一連の情報であるべきである。情報が、許可マスクまたは禁止マスクの一部に付加されるかどうか、異なるメモリブロックが、他のメモリブロックよりも優先され得るかどうか（例えば、Ｍ２は、Ｍ１よりも優先される、またはＭ１は、他のすべてよりも優先される）に関する特定の選択は、ＦＣ１２の各実装に対して特定のままであり得るが、システム内のＦＣ１２を扱う全部品によって、一貫して認識されるべきである。さらに、制御情報は、禁止および許可機能の両方が、任意の特定の機能または複数の機能に関係する場合、許可マスク２０４および禁止マスク２０２が、ブール論理および／またはブール演算方式において、互いに調和されるように、論理的文脈の情報を含み、最初に、Ｍ１によって許可され、その後、他のメモリブロックの任意の選択内において許可されるように、所与のメモリブロック内ならびに他のメモリブロックに対して、優先順位を提供し得る。]
[0037] 一典型的実施例では、メモリブロックＭ１は、ＯＴＰメモリ（すなわち、「１回限り」プログラム可能）であって、本マスクは、製造時に設定されるであろうが、実際には、Ｍ１は、システム１１（および、該当する場合、サブシステム１３）を製造する実体の要件に特定の任意の種類のメモリであるだろう。メモリブロックＭ１に関連するＦＣ１２は、特定のＦＣ１２の所有者の制御下に保有されるため、Ｍ１は、禁止マスクまたは許可マスクに付加される制御ビットに基づいて、他に対して優先制御を保有するように設定され得る。Ｍ２およびＭ３は、ＮＶメモリである場合、許可マスク２１４は、ベンダーのドメイン外で有効化され得る機能を指定し、禁止マスク２０８は、ベンダーのドメイン外で有効化され得ない機能を指定し、その制御は、各メモリブロック内に付加された制御情報によって、定義される。同様に、Ｍ４が、ＲＡＭである場合、許可マスク２１６は、ユーザが有効化可能な機能を指定し、禁止マスク２１０は、ユーザが有効化不可能な機能を指定するであろう。機能セットは、許可マスクと禁止マスクとの論理的共通部分である（概念的には、許可マスクの和−禁止マスクの和）。本構成によって、各メモリ種に付随する関与者は、どの機能が、生産プロセスのどの段階において、オンまたはオフ（あるいは、部分的オンもしくは部分的オフ）され得るかを定義するマスクを提供することが可能となる。]
[0038] ＦＣ１２によって提供される信頼点は、製造時の機能のプロビジョニングならびに、例えば、ユーザ２６が、アップグレードを購入する場合、または特定の時間の間、無料試用が購入され、次いで、その後、不活性化される場合等、市販後の機能の活性化および不活性化の両方を可能にすることが分かる。次に、図８を参照すると、市販後購入を示す実施例が、提供される。] 図８
[0039] 図３に示される全体的システム１０によって、ユーザ２６は、そのシステム１１のアップグレードを有効化する新しい機能セットＦＥＡＴ４０を要求し、その代価を支払い、取得可能となる。例示的シナリオは、図８に示される。ステップ１８０では、ユーザ２６は、システム１１をユーザ２６に販売した実体であり得る、ベンダー３と通信することによって、デバイスＩＤＱの任意の機能ＡＢＣの活性化を要求する。デバイスＩＤＱは、アップデートが要求される、実際のデバイスまたはシステム１１を識別する。上述のように、Ｑは、一意の識別子（ＵＩＤ）として、バックエンドデータベース２２内に格納されるであろう。本要求の受信の後、ベンダー３は、ステップ１８２において、ＡＢＣのコストを＄Ｘとすることを決定するであろう。これは、ユーザ２６に通信される。ユーザ２６が、本価格を受諾する場合、ステップ１８４において、機能ＡＢＣの活性化に対して、ベンダー３に＄Ｘを支払うことに合意する。ユーザ１４４が、＄Ｘを支払うであろうという確信の後（または、ユーザ１４４からの＄Ｘの受領の後）、ベンダー３は、ステップ１８６において、機能ＡＢＣを提供することに合意する。次いで、ベンダー３は、ステップ１８８において、本実施例では、バックエンドデータベース２２およびＦＣＳ１６を制御またはホスティングする、ベンダー１からデバイスＱのＡＢＣを要求する。したがってベンダー３は、ＦＣＳ１６を通じて、機能ＡＢＣを取得する目的のために、ベンダー１と通信するであろう。図８の破線によって示されるように、ベンダー１が、機能セットＦＥＡＴ４０をユーザ２６に直接提供する代わりに、ベンダー３が、ユーザ２６のために行動し得ることを理解されたい。] 図３ 図８
[0040] 次いで、ベンダー１は、ステップ１９０において、典型的には、＄Ｘよりも低いある固定価格である＄Ｙに対して、機能ＡＢＣの活性化を提供することに合意するであろう。次いで、この時点で、ベンダー１は、ステップ１９２において、課金システムを使用して、またはステップ１９４において、ベンダー３から直接支払を取得することによって、ベンダー３が、＄Ｙを支払うであろう保証を得ることになり、その時点で、ＡＢＣのためのＦＥＡＴ４０が、提供されるであろう。これが、未だ手配されていない場合、ベンダー３は、ステップ１９６において、ユーザ２６から＄Ｘを取得し、次いで、ユーザ２６に機能コードを送信する。上述のように、ＦＥＡＴ４０は、代わりに、ベンダー１によって、ユーザ２６に直接送信され、課金が、後に分割され得る。]
[0041] ステップ１９８では、ユーザ４４は、機能コードを受信し、ステップ２００では、ユーザのシステム１１（および、該当する場合、サブシステム１３）内のＦＣ１２が、上述のように、活性化される。図８に示されるものと類似する交信は、任意の段階における生産プロセスの間、当事者のいずれかとの間で実行され得るが、市販後の活性化／不活性化のみに制限されるものとみなされるべきではないことを理解されたい。また、機能の不活性化は、以下の２つの場合において、デバイス内で促進され得る。１）（ユーザではなく）アクチベータの裁量によって、不活性化が、他の機能と連動してのみ生じる場合、および、２）上流の実体が、下流のアップグレードを防止する場合。] 図８
[0042] 図３に示されるシステム１０の特定の実装は、図９に提供され、別のデバイスまたはデバイスの階層内に内蔵されるシリコンチップ上の機能の有効化／無効化を示す。また、システム１００は、対称または非対称キー暗号化を使用するように構成され得ることを理解されたい。] 図３ 図９
[0043] 次に、図９を参照すると、本実施例における全体的システムが、数字１００によって表される。システム１００によって、設計／製造／アセンブリプロセス（以降、集合的に、生産プロセス１１１と称する）に関与する任意の実体は、部品、デバイス、またはシステム、本実施例では、チップ１１２上の機能の有効化および無効化を制御ならびに保護可能となる。また、システム１００によって、ユーザ２６は、例えば、デバイス１１８を販売するベンダーによって提供される、ＵＩ２５またはインターフェースハードウェア１２６を通じて、市販後の有効化／無効化を実行可能となる。本実施例では、ＦＣ１２が、チップ１１２内に含まれることが分かる。] 図９
[0044] 例示的生産プロセス１１１では、シリコンのウエハ１１４が製造され、ウエハ１１４のそれぞれが、いくつかのチップ１１２を生産する。ウエハ１１４は、１つの実体またはベンダーにおいて生産され、同一施設において、チップ１１２を切断するか、またはウエハ１１４を別のベンダーに納品し、次いで、ウエハ１１４を個々のチップ１１２に切断し得る。生産チャネル１１１内の段階のいずれかは、類似／共通実体またはベンダーにおいて実行可能であって、本明細書に示される実施例は、例証目的のためだけのものであることを理解されたい。]
[0045] 次いで、本実施例におけるチップ１１２は、集積回路パッケージ内にパッケージ化され、その後、基板１１６上に搭載され、本実施例では、次いで、パーソナルコンピュータまたは他の電子デバイス等、より大型のデバイス１１８内に搭載される。チップ１１２は、生産プロセス１１１の間の任意の１つ以上の段階において、ある機能を有効化および／または無効化させるようにプログラム可能である。数例の実施例が、図９に示される。チップ１１２は、生産されると、試験プロセスを受け、その時点にいて、典型的には、試験機１２０に接続される。この時点におけるチップ１１２との試験機の接続性は、プロセスに対する制御を有する実体と知的財産および機能に付随する潜在的収益の所有権との間の関係に依存して、機能を活性化または不活性化するために利用され得る。同様に、別の段階では、チップ１１２が、基板１１６内に搭載されると、さらなる試験が、生じてもよい。試験機または他のインターフェースハードウェア１２２は、チップ１１２が実装されると、基板のある機能を試験または評価するために使用され得る。本ハードウェア１２２は、例えば、Ｅｔｈｅｒｎｅｔ（登録商標）、ＵＳＢ、ＩＥＥＥ１３９４、Ｂｌｕｅｔｏｏｔｈ等と互換性があるポート１２４を通じて、基板に接続され得る。いくつかの製造プロセスでは、最小数の「タッチ」、すなわち、基板１１６との接触が、望ましいか、または必須である場合があることに留意されたい。そのような状況では、ハードウェア１２２と基板１１６との間の接続のために、Ｂｌｕｅｔｏｏｔｈ等の非接触接続が、理想的であるだろう。] 図９
[0046] 生産におけるさらに別の段階では、基板１１６は、より大型かつより高度なデバイス１１８内に搭載される。実施例は、エンドユーザのパーソナルコンピュータ（デバイス１１８）内に含まれるプロセッサ（チップ１１２）を利用する、グラフィックまたはマルチメディアカード（基板１１６）であるだろう。本実施例では、デバイス１１８は、その独自のポート１２８を有し、順に、ポート１２４または基板１１６上の他の接続部に接続し、専用ハードウェア機器１２６に、ＦＣ１２と接続させ、それを通じて、チップ１１２上の機能を有効化／無効化するか、または図９に示されるように、ＦＣＳ１６に、デバイス１１８と直接通信させる。] 図９
[0047] 試験機１２０、ハードウェア１２２、および機器１２６は、機能が有効されるべきデバイス、製品、またはシステム（例えば、チップ１１２）に接続し、通信可能な任意のハードウェアまたはソフトウェアが、プロセス１１１内の任意の段階において、使用可能であることを例証するためだけに示される。このように、関係ベンダーは、任意の段階またはさらに複数の段階において、プロセスに関与し、活性化／不活性化を制御可能である。例えば、関係ベンダーは、ある特定の生産段階において、基板１１６の操作に付随するチップ１１２上の機能を有効化することのみ所望し、次いで、別の段階におい、エンドベンダーに付随する、またはそれによって支払われる機能を有効化し、製品あるいはデバイス１１８の不正クローニングもしくは偽造を防止し得る。]
[0048] デバイス１１８が、アセンブルされ、必要機能が有効化および／または無効化されると、デバイス１１８は、ユーザ２６に販売され得る。上述のように、システム１００によって、ユーザ２６は、付加的機能（図８参照）を購入し、システム１００にそれらを活性化させることによって、そのデバイス１１８を後にアップグレード可能となる。機器１２０、１２２、および１２６のうちの任意の１つ以上によって提供される接続性は、ＦＣＳ１６またはＦＣＳユニット１６の階層（図示せず）を使用して、関係ベンダーによって、最終的に制御される。] 図８
[0049] 図３に示される実施例と同様に、ＦＣＳ１６は、本実施例では、制御され得るデバイスに対応するか、または事前にプログラムされている、デバイスＩＤ１３６（ＵＩＤ等）のリスト、類似デバイスのグループ全体を活性化または不活性化するために使用可能なグループＩＤ１３８のリスト、ステップ５１および５３において、暗号化操作を実行するためのキーまたは他の暗号化情報１４０のリポジトリ、ならびに上述のように、対応する機能セットＦＥＡＴ４０にバンドルされる機能１４２を格納する、バックエンドデータベース２２を使用する。また、ＦＣＳ１６は、所望の機能セットＦＥＡＴ４０と引き換えに支払を確保するために使用される、課金システム２４と通信するか、またはそれを含む。また、ＦＣＳ１６は、例えば、ＵＩ２５を通じて、ユーザ２６によって起動される、上述の機能アップグレードのために、ユーザ２６と直接通信し得る。] 図３
[0050] 上述のように、暗号化処理ステップ５１および５３は、用途に好適な任意の暗号化操作を含み得る。一実施形態では、対称キー暗号化および認証スキームが使用可能であって、機能セットＦＥＡＴ４０は、ＦＣＳ１６によって、暗号化および認証され、次いで、ＦＣ１２によって、復号化、認証、ならびに実装される。ＦＣＳユニット１６の階層が使用される場合、バックエンドインフラストラクチャに付随するＦＣＳ１６は、典型的には、暗号化処理を実行し、次いで、システム１００の実際の構成によって要求されるように、結果として得られる暗号化されたデータを遠隔ＦＣＳユニット１６に送信するであろうことに留意されたい。また、非対称キー実施形態は、認証および機密性を提供するために使用され得る。次に、そのような実施形態の実施例が、記載される。以下の実施例では、添字ｉは、特定のＦＣ１２（すなわち、ＦＣｉ）を指し、添字ｊは、特定のＦＣＳ１６（すなわち、ＦＣＳｊ）を指す。]
[0051] ＦＣＳ１６は、それぞれ、機能を有効化および無効化するための活性化ならびに不活性化コードの配信を制御し、本実施例では、ＦＣＳｊである。対称キー実装では、機能セットは、対称キーＫＥＹｉ１４０によって暗号化されており、ここでも、ｉは、特定のＦＣ、すなわち、ＦＣｉを指す。対称キー暗号化スキームでは、ＦＣｉに対する機能セットＦＥＡＴ４０は、暗号化され、したがって、ＥＮＣ（ＦＥＡＴｎ）、すなわち、ｎ番目の機能セットＦＥＡＴによって表される。図３および９に示される一般的実施例と同様に、ＦＣＳｊ１６は、本実施例では、対応する機能セットにバンドルされ、ＥＮＣ（ＦＥＡＴｎ）を提供するように暗号化された機能１４２を暗号化するために、デバイスＩＤ１３６（ＵＩＤ等）、グループＩＤ１３８のリスト（必要に応じて）、および暗号ストレージ部１４０内の対称キーＫＥＹｉのリポジトリを格納する、バックエンドデータベース２２を使用する。暗号化された機能セットＥＮＣ（ＦＥＡＴｎ）は、ＦＣＳ１６によってＦＣ１２内に投入された対称キーＫＥＹｉのそのコピーを使用して、例えば、チップ１１２内のＦＣｉ１２によって、デバイス上で最終的に復号化され得る。] 図３
[0052] ＦＣ１２は、対称キー実装では、図１０に詳細に示される、すなわち、ＦＣｉ１２である。本実施例では、ＦＣｉ１２は、ＥＮＣ（ＦＥＡＴｎ）を復号化し、受信した復号化された機能セットＦＥＡＴｎのメッセージ認証を実行するように構成される。メッセージ認証は、暗号化された機能メッセージが、（故意または偶発的に）改変されていないことを保証するために重要である。具体的には、本実施例では、ＦＣｉ１２は、暗号化された機能セットＥＮＣ（ＦＥＡＴｎ）を受信し、メモリからその復号化キーＫＥＹｉを取得する。これらは、プレーンテキストバージョンのＦＥＡＴｎを取得するために、復号化関数２２０に入力される。次いで、本復号化された機能セットＦＥＡＴｎは、メッセージ認証のために、メッセージ認証モジュール２２４に入力され、メッセージ認証コード（ＭＡＣ’）２２６を生成し得る。ＭＡＣアルゴリズムの実施例は、暗号ベースのメッセージ認証コード（ＣＭＡＣ）認証スキームを備えているＡＥＳであろう。別個のキー（ＫＥＹｊ’）は、実装に応じて、本計算のために使用され得る。次いで、ＭＡＣ’２２６は、受信した機能セットＦＥＡＴｎ内に格納されるか、または保持されるＭＡＣ２２８と比較される。一致する場合、ＦＣｉ１２によって回復されたプレーンテキスト機能セットＦＥＡＴｎが、照合される。] 図１０
[0053] メッセージ認証プロセスは、典型的には、制限されるわけではないが、３つの方法のうちの１つにおいて、実行される。一実装では、ＦＥＡＴｎは、ＭＡＣ２２８とともに、プレーンテキストで送信される。データグラムは、ＭＡＣによって決定される認証強度を伴う、プレーンテキストメッセージのＭＡＣに連結される公開可読プレーンテキストメッセージを含むように構築されるであろう。回復プロセスでは、ＭＡＣ２２８は、検証され、検証結果に依存して、有効化され、プレーンテキストメッセージ（すなわち、ＦＥＡＴｎ）は、デバイス内で使用されるか、または破棄されるであろう。]
[0054] 第２の実装では、機能セットは、ＭＡＣ２２８とともに、暗号テキストＥＮＣ（ＦＥＡＴｎ）として送信される。データグラムは、プレーンテキストメッセージのＭＡＣとプレーンテキストメッセージの暗号化との連結を使用して、またはプレーンテキストメッセージのＭＡＣとプレーンテキストメッセージとの連結を暗号化することによって、あるいはプレーンテキストメッセージの暗号化のＭＡＣとプレーンテキストメッセージの暗号化とを連結することによって、構築されるであろう。本第２の実装のすべての場合において、プレーンテキストは、その対応する暗号テキストを生成することによって、平面ビュー上では非表示となるべきである。認証メッセージは、メッセージの長さと同等の強度を有する。プレーンテキストメッセージは、全暗号テキストの復号化操作およびその後のＭＡＣ２２８の検証を使用して、回復され、復号化およびＭＡＣ検証結果に依存して、プレーンテキストメッセージ（すなわち、ＦＥＡＴｎ）は、使用または破棄されるであろう。]
[0055] 第３の実装では、暗号テキストのみが使用され、データグラムは、メッセージと任意の冗長性との連結の暗号化を使用して、構築される。プレーンテキストメッセージは、データグラムの復号化操作を使用して回復され、次いで、それが期待値と一致するような冗長性についての検証が実行されるであろう。これによって、付随プレーンテキストメッセージ（すなわち、ＦＥＡＴｎ）は、検証結果に依存して、使用または破棄されるであろう。]
[0056] 図１１に示されるように、そのような対称キー実施形態の場合、機能１４のうちの任意の１つ以上（図１１に示される任意の機能Ｘ）は、図１０においてＦＣｉ１２が取得するのと同一の機能セットＥＮＣ（ＦＥＡＴｎ）を取得し、上述のように、対称キーＫＥＹｉ１４０を使用して、ＥＮＣ（ＦＥＡＴｎ）からＦＥＡＴｎを復号化する、その独自のＦＣｉｘ１２を含み得る。機能Ｘの状態／実装（例えば、機能Ｘをオンまたはオフにするか）は、復号化された機能セットＦＥＡＴｎから決定され得る。このように、チップ１１２の供給業者のみではなく、機能の供給業者は、機能有効化または無効化（あるいは、部分的有効化もしくは無効化）を制御する。] 図１０ 図１１
[0057] また、図１１に示される構成は、非対称キー実施形態において使用可能であって、非対称暗号化を使用して、ＦＥＡＴｎの完全性を保護し、代替として、キー管理機能を実行し、ＦＥＡＴｎが、ＦＣＳ１６からＦＣ１２に送信されると、暗号化され得るように、ＦＣＳ１６ｊとＦＣ１２ｉとの間の共有キーを構築することを理解されたい。次いで、ＦＣ１２は、機能を機能Ｘに転送し、それを復号化するであろう。機能セットを暗号化するための対称暗号化の使用は、効率性のため、好ましいが、非対称暗号化もまた、用途に対して好ましいかまたはより好適である場合に使用可能であることを理解されたい。] 図１１
[0058] 非対称キー実施形態のためのＦＣＳ１６およびＦＣ１２は、図１２にさらに詳細に示される。任意のＦＣｉおよびＦＣＳｊが、示される。ＦＣＳｊ１６は、キー生成、キー承諾、署名生成、署名照合、暗号化、復号化等の任意の必要暗号化操作を実行するように構成される、暗号化ユニット３０を含む。また、ＦＣＳｊ１６は、認証機関（ＣＡ）１０１として作用するか、またはそれと通信し得る。また、ＦＣＳｊ１６は、ＦＣ１２と通信の際に使用される情報およびデータを格納するためのメモリ３６を含む。示されるように、ＦＣＳｊ１６は、証明書ＣＥＲＴ（ＦＣＳｊ）を格納する。また、ＦＣＳｊは、その独自のＦＣｉ１２を有し、したがって、信頼点を含む、各システムｉに対応する証明書（すなわち、ＣＥＲＴ（ＦＣｉ））を格納し得る。また、メモリ３６は、バックエンドデータベース２２が現場にある場合、バックエンドデータベース２２またはその一部を含み得る。ＦＣＳｊ１６は、安全、非安全、有線、無線、ローカルエリア、ＦＣＳｊ１６とＦＣｉ１２との間のデータの転送を可能にする任意の他の種類の通信リンクであり得る通信チャネル２０を介して、ＦＣｉ１２と通信する。] 図１２
[0059] ＦＣｉ１２は、システム１１側において、アップグレード／デグレード手順の必要暗号化操作を実行するように構成される、暗号化ユニット３０を有する。例えば、ユニット３０は、乱数発生器（ＲＮＧ）３２だけではなく、ＣＰＵ、楕円曲線（ＥＣ）算術演算ユニット、米国新暗号化規格（ＡＥＳ）コア、ＲＯＭ、ＳＲＡＭ、および他の種類のメモリユニットを含み得る。後述の一実施例では、ユニット３０は、ＥＣＤＳＡ、ＥＣＭＱＶプロトコル、または両方を実行可能なＥＣＣモジュールである。また、ＦＣｉ１２は、データおよび情報を格納するためのメモリ３４を有する。ＦＣｉ１２は、実際のシステム１１を、類似種類、ブランド、またはバージョンの他のシステムと区別する、対応するＵＩＤｉを格納する。本ＵＩＤｉは、ＦＣｉ１２内でローカルに生成されるか、またはＦＣＳｊ１６等の外部機器を使用して挿入される、一意または統計的に一意の数であり得る。また、ＦＣｉ１２は、以下に記述および例示されるように、典型的には、製造時に生成され、通常、ＵＩＤｉにリンクされる、持続的、すなわち、「静的」秘密キーｄＦＣｉｓおよび公開キーＱＦＣｉｓを格納する。具体的には、ＱＦＣｉｓまたはその一部は、ＵＩＤｉとして使用され得る。また、ＦＣｉ１２は、ＣＡ１０１の公開キーＱＣＡを格納する。メモリ３４は、任意の種類または種類の組み合わせであって、意図されるように、ＦＣ１２が動作することを許可するために必要な任意の情報を格納するように構成され得ることを理解されたい。]
[0060] 非対称実施形態において、ＦＣｉ１２に送信される機能セットは、認証を含み、偽変造、リプレーアタック、および置換等の攻撃から保護されるべきである。認証を提供するための一例示的プロトコルは、図１３に示される。「プログラミングを開始」するためのＦＣＳｊからＦＣｉへの初期コマンドが、最初に生成され得る。ＦＣｉのためのＵＩＤｉは、典型的には、製造プロセスの間等のある早期の時点である、ステップ６０において、ＦＣｉによって生成されるか、またはＦＣＳｊによって投入される。これは、ＦＣｉに、ＵＩＤｉを生成させるためのＦＣＳｊからＦＣｉへのコマンドを含み得る。典型的には、ＵＩＤｉは、ＦＣｉの寿命の間、変更されないであろう。ステップ６１では、ＦＣｉが、新しい機能セットを取得するために、ＦＣＳｊと通信することを所望する場合、ノンスＮｉ’が、最初に生成される（「’」は、セッション毎の値を示す）。次いで、機能プログラミングコマンド毎に一意である、本ノンスＮｉ’は、例えば、連結によって、ＵＩＤｉと組み合わせられ（Ｎｉ’｜｜ＵＩＤｉ）、ＦＣＳｊに送信される。次いで、ＦＣＳｊは、ステップ６３における（Ｎｉ’｜｜ＵＩＤｉ）の受信の後、プログラミングメッセージＭｎ（すなわち、ｎ番目のメッセージＭ）の準備を開始し、そのために、要求された機能または機能セットＦＥＡＴｎ、あるいは適切な機能または機能セットＦＥＡＴｎと、ＦＣＳｊのための証明書、すなわち、ＣＥＲＴ（ＦＣＳｉ）を読み出す。] 図１３
[0061] 次いで、ステップ６４では、ＦＣＳ１６は、ＦＣｉによって提供される情報および機能セットを使用して、署名、例えば、ＳＩＧＦＣＳｊ（Ｎｉ’｜｜ＵＩＤｉ｜｜ＦＥＡＴｎ）を生成する。好ましくは、署名は、本スキーム内の使用のためのデジタル証明書を発行するバックエンドインフラストラクチャのＣＡ１０１によって証明されたＥＣＣキー対を使用する、ＥＣＤＳＡ、ＥＣＮＲ、またはＥＣＰＶＳ署名であるが、それらに制限されない。次いで、プログラミングメッセージは、ステップ６５において、ＦＣｊの署名、機能セット、および証明書を使用して、アセンブルされ得る。例えば、以下となる。]
[0062] Ｍｎ＝［ＦＥＡＴｎ｜｜ＳＩＧＦＣＳｊ（Ｎｉ’｜｜ＵＩＤｉ｜｜ＦＥＡＴｎ）｜｜ＣＥＲＴ（ＦＣＳｊ）］。]
[0063] 対称キー（ＫＥＹｉ）が、事前に投入されており、上述のように利用可能である場合、ＦＥＡＴｎは、機密メッセージのために暗号化され得る。本メッセージＭｎから、ＦＣｉは、暗号化されたＦＥＡＴｎ（本選択肢が使用される場合）を復号化し、機能セット、署名（それを照合するために）、および証明書を抽出可能であることが分かる。次いで、メッセージＭｎは、ＦＣｉに送信される。]
[0064] Ｍｎの受信の後、ステップ６６において、ＦＣｉは、例えば、不揮発性にプログラムされ、ＦＣｉ１２にアクセス可能なバックエンドインフラストラクチャのＣＡ１０１の公開キーを使用して、証明書ＣＥＲＴ（ＦＣＳｊ）を検証する。また、不揮発性にプログラムされ、また、本ステップにおいて、チェックされ得る顧客ＩＤが存在し得る。次いで、本実施例では、ＦＣｉは、ＳＩＧＦＣＳｊを照合し、その際、ＮｉおよびＵＩＤｉが、その独自の値と一致すかどうか照合する。チェックのいずれかが、ステップ６６において失敗する場合、ＦＣｉは、操作を中断するであろう。]
[0065] ステップ６６におけるチェックが、有効である場合、ＦＣｉは、ステップ６８において、機能セットＦＥＡＴｎ内に含まれる機能または複数の機能を実装する。ＦＥＡＴｎを実装後、ステップ６９において、ＦＣｉは、成功または失敗メッセージを含むことによって、レポートまたは確認通知を準備するはずである。次いで、本確認通知またはフィードバックは、ＦＣＳｊに送信される。フィードバックメッセージが、実際には成功しているにもかかわらず、システム１１がプログラムを失敗したと、ＦＣＳｊに信じ込ませるようにリプレーされる、リプレーアタックを回避するために、応答は、暗号的に安全であるべきであることに留意されたい。次いで、ステップ７０では、フィードバックの受信の後、ＦＣＳｊは、グレーマーケットの監査またはエラー追跡等の後の分析のために、フィードバックの記録を開始し得る。任意の追加プログラミングが要求される場合、ＦＣｉは、新しいノンスを生成し、図６のステップ７１として集合的に示される、上述のステップが繰り返され得る。] 図６
[0066] 本例示的プロトコルは、コマンドを特定のＦＣ１２にリンクさせ、コマンドが、実施される。悪意のある製造業者が、ＦＣを傍受する他のシステム１１を有する場合、コマンドが単一ＦＣ１２にリンクされるため、受信したコマンドで作動しないであろう。これは、特定の標的との通信をロックまたは固定するためのＵＩＤｉおよびＮｉの使用を通じて達成される。また、ＦＣＳ１６からＦＣ１２（例えば、ＦＣＳｊおよびＦＣｉ）へのコマンドは、完全性が保護され、認証され、リプレーアタックおよびなりすましから保護される。コマンドは、特定のＵＩＤｉにリンクされるため、ＦＣＳｊは、特定のＵＩＤｉがプログラムされていること、およびプログラムされた場所を示す監査ログを維持可能である。本ログは、図３のインフラストラクチャ（または、ある他のインフラストラクチャ）を通じて、元の製造業者に報告され得る。これらのログファイルのレビューにおいて、同一ＵＩＤｉの複数のインスタンスが検出される場合、クローニング／偽造状況が発見されるであろう。] 図３
[0067] 別のより暗号的に安全な実施形態では、認証および機密性の両方を提供するプロトコルが、図１４に示されるように、使用され得る。本プロトコルは、データを復号化するために、ＦＣｉ内に投入される秘密対称キーを必要としない。上述と同様に、「プログラミングを開始」するためのＦＣＳｊからＦＣｉへの初期コマンドが、最初に生成され得る。本プロトコルの場合、次いで、ＦＣｉは、ステップ８０において、静的キー対（ｄＦＣｓ、ＱＦＣｓ）、好ましくは、静的ＥＣＣキー対を生成し、ＱＦＣｓは、ステップ８１において、ＵＩＤｉを生成するために使用される。ＥＣＣ実装では、静的公開キーＱＦＣｓの座標のうちの１つ（好ましくは、ｘ座標）は、必要に応じて、切り捨てを伴って、ＵＩＤｉとして使用され得る。キー対は、好ましくは、製造時であるが、用途に基づいて、別の時に、作成および格納される。静的キー対およびＵＩＤは、プログラムされると、改変不可能であるように、作成および格納されるべきであることに留意されたい。] 図１４
[0068] ＦＣｉプログラミングが、ＦＣＳｊによって開始されると、ＦＣｉは、ステップ８２において、最初に、一時的キー対（ｄＦＣｉｅ、ＱＦＣｉｅ）、好ましくは、ＥＣＣキー対を生成し、ＦＣＳｊとのキー承諾、例えば、ＥＣＣ実装の場合、ＥＣＭＱＶキー承諾に関与する。本プロセスの一部として、ＦＣｉが、その静的キーのための証明書、すなわち、ＣＥＲＴ（ＦＣｉ）を有する場合、これをＦＣＳｊに送信するであろう。また、ステップ８３では、ＦＣＳ１６は、一時的キー対（ｄＦＣＳｊｅ、ＱＦＣＳｊｅ）を生成するであろう。キー承諾の一部として、ＦＣＳｊは、一時的公開キーＱＦＣＳｊｅおよび証明書ＣＥＲＴ（ＦＣＳｊ）をＦＣｉに送信する。ＣＥＲＴ（ＦＣｉ）が存在する場合、証明書検証も、ＦＣＳｊによって、実行されなければならない。ステップ８４では、ＦＣｉは、証明書ＣＥＲＴ（ＦＣＳｊ）を検証し、キー承諾の結果は、ステップ８５および８６における、ＦＣＳｊとＦＣｉとの間の共有キーＫＥＹｉｊ’である。上述のように、顧客ＩＤが、マスクプログラムされる場合、その値は、ＦＣｉによって、チェックされる。チェックのいずれかが失敗する場合、ＦＣｉは、操作を中断するであろう。本値が使用される場合、本値は、ＦＣｉがプログラムされるべき照合のために、ＦＣｉによって、ＦＣＳｊに送信される。]
[0069] 次いで、ＦＣＳｊは、プログラミングメッセージＭｎの準備を開始し、そのために、ステップ８７において、要求された機能または機能セットＦＥＡＴｎ、あるいは適切な機能または機能セットＦＥＡＴｎを読み出す。次いで、ステップ８８では、ＦＣＳｊは、キー承諾の間にＦＣｉによって提供される情報および機能セットを使用して、署名、例えば、ＳＩＧＦＣＳｊ（ＱＦＣｉｅ｜｜ＵＩＤｉ｜｜ＦＥＡＴｎ）を生成する。好ましくは、署名は、ＥＣＤＳＡ、ＥＣＮＲ、またはＥＣＰＶＳ等のＥＣＣキー対を使用するＥＣＣ署名である。署名では、ＱＦＣｉｅは、所望に応じて切り捨てられてもよい。次いで、機能または機能セットＦＥＡＴｎは、ステップ８９において暗号化され、対称暗号およびキー承諾の間に構築されるキーＫＥＹｉｊ’を使用して、機密性を提供する。]
[0070] 次いで、プログラミングメッセージＭｎは、ステップ９０において、署名および暗号化された機能セットを使用して、アセンブルされ得る。例えば、以下となる。]
[0071] Ｍｎ＝［ＥＮＣ（ＦＥＡＴｎ）｜｜ＳＩＧＦＣＳｊ（ＱＦＣｉｅ｜｜ＵＩＤｉ｜｜ＦＥＡＴｎ）］。]
[0072] 次いで、メッセージＭｎは、ＦＣｉに送信される。Ｍｎの受信の後、ステップ９１では、ＦＣｉは、ＫＥＹｉｊ’を使用して、機能セットＦＥＡＴｎを復号化し、署名を照合する。署名検証の一部として、ＦＣｉは、ＱＦＣｉｅおよびＵＩＤｉが、その独自の値と一致するかどうかを検証する。ステップ９１において、チェックのいずれかが失敗する場合、ＦＣｉは、操作を中断するであろう。]
[0073] ステップ９１において、チェックが有効である場合、ＦＣｉは、ステップ９３において、機能セットＦＥＡＴｎ内に含まれる機能または複数の機能を実装する。ＦＥＡＴｎに付随するアクションを実行後、ＦＣｉは、成功または失敗メッセージをＦＣＳｊに返す。本メッセージは、暗号化された確認通知メッセージ、例えば、ステップ９４において生成されるＭＳＴＡＴｎ＝ＥＮＣ（ＡＣＫｎ）であり得る。ＡＣＫｎは、成功または失敗を示す、２つの非常に冗長なメッセージのうちの１つである。冗長性は、メッセージの完全性が存在しない場合、要求されるであろう。また、本メッセージは、リプレーアタックから保護される必要があり、任意の好適なソリューションを使用して、行なわれ得る。次いで、メッセージＭＳＴＡＴｎは、ＦＣＳｊに送信される。任意のさらなるプログラミングが要求される場合、ステップ９５において、ＦＣＳｊは、例えば、ステップ９５において、メッセージＭＣＭＤｎを生成することによって、コマンドＣＭＤｎに署名し得る。例えば、以下となる。]
[0074] ＭＣＭＤｎ＝［ＥＮＣ（ＣＭＤｎ）｜｜ＳＩＧＦＣＳｊ（ＱＦＣｉｅ｜｜ＵＩＤｉ｜｜ＣＭＤｎ）］。本メッセージは、リプレーアタックから保護されるべきである。]
[0075] さらなるプログラミングが、ＦＣｉがオフにされた後、生じる場合、および／または一時的キーが削除されている場合、ＦＣｉは、新しい一時的キー対を生成し、図１４に示されるプロセスを繰り返し得る。メッセージＭＣＭＤｎは、ＦＣｉに送信され、ステップ９６において、メッセージＭＣＭＤｎが、復号化され、署名が、照合され、メッセージＭＣＭＤｎ内に含まれる追加プログラミングが、実行される。] 図１４
[0076] 図１４に示されるプロトコルは、図１３におけるプロトコルの利点を含むが、また、特定のＦＣ１２および特定のＦＣＳ１６にリンクされる、暗号化されたトンネルを提供する。したがって、他のＦＣ１２は、本プロトコルに関与不可能であるか、または暗号化されたプログラミングセッションの間に送信されたコマンドを復号化することが不可能であるだろう。また、プレーンテキストＦＣプログラミングコマンドを発見することは不可能であり、ＦＣ１２への攻撃をより複雑にするであろう。] 図１３ 図１４
[0077] 図１３および１４から分かるように、ＦＣＳ１６とＦＣ１２との間の２つのバージョンの交信が、例示される（すなわち、認証のみのバージョン（任意に、機密性のために投入される秘密対称キーを使用し得る）と、機密性および認証の両方を利用し、秘密対称キーの投入を必要としないバージョン）。バージョンの選択は、用途に依存する。例えば、認証のみのバージョンは、チップコストおよび／または試験時間を最小限にするために、ゲートを節約するか、またはプログラミング機能回数を改善するために、使用され得る。] 図１３
[0078] したがって、図３に示される機能制御システム１０は、それが提供する機能を通じて、製品またはサービスの差別化を可能にする、任意の種類のシステム１１に適合され得ることが分かる。図９に例示されるように、システムまたはシステムの階層内にＦＣ１２を含めることを通じて構築される信頼点は、シリコンチップ製造環境における在庫流動の数を減少させるために、特に好適であり得る。さらに、システム１１（例えば、デバイス１１８）は、ある機能セットとともにプロビジョニングされるだけではなく、後のアップグレード、ダウングレード、時間ベースの試用、および本明細書に記載されるような機能制御に対する暗号化制御を有さない場合、そうでなければ不可能である（または、少なくとも、信頼されない）多くの他の下流性能も可能にする。] 図３ 図９
[0079] システム１０、１００は、付加的性能を含み得る。例えば、ＦＣ１２は、攻撃者が、ＦＣ１２内にハッキングしようと試みているかどうかを判断するように構成可能である。その場合、ＦＣ１２は、本体を遮断し、可能性として、それに付随するチップ１１２またはシステム１１も停止させ得る。別の実施例は、システム１１を遮断するように遠隔から命令可能であるように、ＦＣ１２を構成するものである。別の実施例として、製造業者が、暗号化されたプログラムをシステム１１のメモリ内に格納し、次いで、ＦＣ１２が、キー（機能として）を受信し、それを復号化するまで、プログラムが実行不可能であるように、後に、ＦＣＳ１６からＦＣ１２にメモリ復号化キーをダウンロードするものを含む。]
[0080] ＦＣ１２は、システム１１内の信頼される操作点として作用することを理解されたい。デバイスまたはシステムが、類似信頼操作を提供可能なデバイスを既に有する場合、バックエンドシステムおよびＦＣＳ１６操作ならびにプロトコルは、ＦＣ１２のこれらの他のバージョンを使用して、本書に記載される機能制御機能を提供するように修正され得る。そのような信頼される操作デバイスの実施例として、Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐ（ＴＣＧ）の信頼プラットフォームモジュール（ＴＰＭ）、およびＴＣＧのストレージ仕様に準拠して構築されるストレージデバイスを含むが、これらに制限されない。]
[0081] また、ＦＣ１２、ＦＣＳ１６、または中間システム１８は、介入者攻撃を防止する補助となるようにプロビジョニングされ得る。そのような方法の一実施例は、ＦＣ１２、ＦＣＳ１６、および中間システム１８のうちの１つ以上の組み合わせを伴い、実際の測定された交信待ち時間に対して、ＦＣ１２、ＦＣＳ１６、および中間システム１８の特定の実装における情報の交信に付随する待ち時間の決定論的評価に基づいて、時間測定値の比較を行なう。ＦＣ１２、ＦＣＳ１６、および中間システム１８のうちの１つ以上は、既知または有界遅延特性を伴う、抵抗容量ネットワークあるいはリング発振器等の物理的に内蔵されたアナログ遅延を有するか、もしくは介入者攻撃防止によって、不正使用が発生しているかを判断するための精密安全時間参照サーバを参照し得る。そのような攻撃は、ＦＣ１２、ＦＣＳ１６、または中間システム１８の要素間の不正仲介業者を使用して、もしくはＦＣ１２、ＦＣＳ１６、または中間システム１８へのデジタル入力クロックあるいはデジタル入力クロックのデューティサイクルを減速することによって、実施され得る。]
[0082] 本発明は、ある特有の実施形態を参照して記載されたが、その種々の修正例は、本明細書に付属の請求項に概略される本発明の精神および範囲から逸脱することなく、当業者には明白となるであろう。]

权利要求:

請求項1
システム上の機能を制御するための方法であって、暗号化操作を実行可能な該システム内に少なくとも１つの機能コントローラを提供するステップと、該機能コントローラと機能制御サーバとの間の接続を構築するステップと、該機能制御サーバから機能セットを受信するステップであって、該機能セットは、暗号化処理を受けている、ステップと、該受信した機能セットに対し補完的暗号化処理を実行し、該システム内における該機能セットの実装を許可するステップと、該機能セットを実装し、該機能のうちの１つ以上を制御するステップとを含む方法。
請求項2
前記機能セットは、活性化または不活性化されるべき前記システム内の１つ以上の機能を識別し、前記機能セットを実装するステップは、該１つ以上の機能を活性化することまたは不活性化することを含む、請求項１に記載の方法。
請求項3
前記１つ以上の機能は、ビット配列のうちの選択されたビットを設定することによって、活性化または不活性化され、各ビットは、該機能のうちの１つに対応する、請求項２に記載の方法。
請求項4
前記１つ以上の機能は、前記機能コントローラをメモリマップにアクセスさせることによって、活性化される、請求項２に記載の方法。
請求項5
前記メモリマップは、前記機能を制御するための操作に関係する１つ以上の許可マスクおよび１つ以上の禁止マスクを備えている、請求項４に記載の方法。
請求項6
前記システムは、複数の機能を制御するための１つの機能コントローラを備えている、請求項１に記載の方法。
請求項7
前記システムは、複数のそれぞれの機能を制御するための複数の機能コントローラを備えている、請求項１に記載の方法。
請求項8
前記補完的暗号化処理は、前記機能コントローラによってアクセスされる対称キーを利用することを含み、該対称キーは、前記暗号化処理を実行する際、前記機能セットを暗号化するために使用されており、該補完的暗号化処理は、該機能セットを復号化することを含む、請求項１に記載の方法。
請求項9
前記補完的暗号化処理は、前記機能セットの復号化されたバージョンを使用して、メッセージ認証コード（ＭＡＣ）を生成し、前記機能セットの実装に先立って、該ＭＡＣを使用して該機能セットを照合することをさらに含む、請求項８に記載の方法。
請求項10
前記暗号化処理は、前記機能コントローラに対して一意の識別子を使用して、前記機能セットに署名することを含み、前記補完的暗号化処理は、該機能セット上の署名を照合し、該署名の照合の後、該機能セットを実装することを含む、請求項１に記載の方法。
請求項11
前記補完的暗号化処理は、前記機能制御サーバによって提供される証明書を検証するステップをさらに含む、請求項１０に記載の方法。
請求項12
前記機能コントローラと前記機能制御サーバとの間の前記接続を構築するステップは、ノンスを生成することと、該ノンスを前記一意の識別子と組み合わせることと、前記署名を生成する際に使用するために、該機能制御サーバに前記組み合わせを提供することとを含む、請求項１０に記載の方法。
請求項13
前記補完的暗号化処理は、前記機能制御サーバによって構築されるセッションキーを利用して、前記機能セットの暗号化されたバージョンを復号化することを含み、該暗号化されたバージョンは、前記暗号化処理の間に、該機能制御サーバによって生成されており、該補完的暗号化処理は、該機能セット上の署名を照合することをさらに含み、該署名は、前記機能コントローラの公開キーを使用して生成されている、請求項１に記載の方法。
請求項14
前記公開キーは、一時的公開キーであって、前記署名もまた、前記機能コントローラによって生成される一意の識別子を用いて生成されており、該一意の識別子は、該機能コントローラの静的公開キーを使用して生成され、該一時的公開キーおよび該一意の識別子は、キー一致プロトコルの間、前記機能制御サーバに提供される、請求項１３に記載の方法。
請求項15
前記署名の照合の後、前記機能コントローラは、前記セッションキーを用いて前記機能制御サーバによって暗号化されたさらなるコマンドまたはプログラミング命令を受信する、請求項１３に記載の方法。
請求項16
前記セッションキーは、Ｍｅｎｅｚｅｓ−Ｑｕ−Ｖａｎｓｔｏｎｅ（ＭＱＶ）キー一致プロトコルを使用して構築される、請求項１３に記載の方法。
請求項17
前記機能セットの実装の後、前記機能制御サーバにフィードバックを提供することをさらに含む、請求項１に記載の方法。
請求項18
システム上の機能を制御するための機能コントローラであって、該システムは、機能制御サーバとの接続を構築し、該機能制御サーバから機能セットを受信するように構成され、該機能コントローラは、メモリへのアクセスと、暗号化ユニットであって、該システムから該機能セットを取得することであって、該機能セットは、暗号化処理を受けている、ことと、該メモリ内に格納されている情報を用いて、該受信した機能セットに対し補完的暗号化処理を実行し、該システム内における該機能セットの実装を許可することとを行うように構成されている、暗号化ユニットとを備えている、機能コントローラ。
請求項19
システム上の機能を制御するためのコンピュータで実行可能な命令を含むコンピュータ読み取り可能なストレージ媒体であって、該媒体は、暗号化操作を実行可能な該システム内に少なくとも１つの機能コントローラを提供することと、該機能コントローラと機能制御サーバとの間の接続を構築することと、該機能制御サーバから機能セットを受信することであって、該機能セットは、暗号化処理を受けている、ことと、該受信した機能セットに対し補完的暗号化処理を実行し、該システム内における該機能セットの実装を許可することと、該機能セットを実装し、該機能のうちの１つ以上を制御することとを行うための命令を含む、コンピュータ読み取り可能なストレージ媒体。