フレキシブル認証ルールの修正
【課題】複雑な認証ルールの中からルール要因を一つ、信頼性のある環境によって安全に変更可能とするコンピューティング技術を提供する。
【解決手段】耐タンパ性のセキュリティＬＳＩは、不揮発性メモリと揮発性メモリと単調カウンタ領域とプラットフォーム状態に関する蓄積情報を記憶する構成レジスタと暗号化部を持ち、外部から受信したオブジェクトに含まれるルールを修正するためのオブジェクトルール修正チケット発行部を備え、受信したオブジェクトが、記憶されている暗号化ハッシュと等しい暗号化ハッシュを含んでいる場合にのみ前記チケット発行部を有効にする。このためルールの変更は、その変更の起源を十分に監査できるような方法で行われる。
【解決手段】耐タンパ性のセキュリティＬＳＩは、不揮発性メモリと揮発性メモリと単調カウンタ領域とプラットフォーム状態に関する蓄積情報を記憶する構成レジスタと暗号化部を持ち、外部から受信したオブジェクトに含まれるルールを修正するためのオブジェクトルール修正チケット発行部を備え、受信したオブジェクトが、記憶されている暗号化ハッシュと等しい暗号化ハッシュを含んでいる場合にのみ前記チケット発行部を有効にする。このためルールの変更は、その変更の起源を十分に監査できるような方法で行われる。
【発明の詳細な説明】
【背景技術】
【０００１】
オープン性および柔軟性を維持しながらパソコンや携帯電話などの電子機器を保護するため、Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐ（ＴＣＧ）は作られた。Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐは、全体的なセキュリティ解決策の重要な側面である規格策定に重点的に取り組んでおり、特に、ＩＳＯ／ＩＥＣ１１８８９としても公開されている「ＴＰＭ Ｍａｉｎ Ｐａｒｔ １ Ｄｅｓｉｇｎ Ｐｒｉｎｃｉｐａｌｓ， Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｖｅｒｓｉｏｎ １．２， Ｒｅｖｉｓｉｏｎ １０３」に記載されているようなトラステッドプラットフォームモジュール（ＴＰＭ）と呼ばれるハードウェアコンピュータチップに取り組んでいる。このトラステッドプラットフォームモジュールは、特に、暗号化による情報のセキュアな格納、セキュアな環境で実行される一連の暗号化処理、および、一連の完全性メトリクスを提供するハードウェア装置である。
【０００２】
このＴＰＭの特徴の１つは、コマンドの多くが認証を必要とすることである。この認証は、秘密を保持する必要があるただ１つの要因として定義され、この値を生成する一般的な方法は、この値を、ユーザが入力したパスワードのハッシュとすることである。
【０００３】
ＴＰＭの機能性については、Ｔａｌｈａ Ｔａｒｉｑによる論文「Ｅｘｔｅｎｄｉｎｇ Ｓｅｃｕｒｅ Ｅｘｅｃｕｔｉｏｎ Ｅｎｖｉｒｏｎｍｅｎｔｓ ｂｅｙｏｎｄ ｔｈｅ ＴＰＭ」などで、様々な改良案が提案されている。この論文では、上述したただ１つの認証値を、ユーザパスワード、ＴＰＭ状態、第三者証明機関などの複数の認証ルール要因を表す累積ハッシュ値で置き換える方法として、スマートカードと連動したフレキシブル認証が提案されている。このハッシュ値は、ＴＰＭとペアになったスマートカード内で生成されると述べられており、当業者であれば、別の形態において、このフレキシブル認証ルールの処理を、機能を強化したＴＰＭまたは信頼性のある処理環境内に移動させても構わないと分かるであろう。この処理環境は、信頼性のある処理領域内に実装されたソフトウェアＴＰＭを有するシステム内のＣＰＵによって提供される。
【０００４】
また、当業者であれば、これらのフレキシブル認証ルール要因を編集可能にする必要があると分かるであろう。認証データの署名に用いられるキーは変化する可能性がある。当然、ユーザパスワードは変わる方がよい。装置状態への依存度が変わるかもしれない。
【０００５】
既存のＴＰＭ仕様書には、キーの所有者がその認証値を変更できる、ＴＰＭ＿ＣｈａｎｇｅＡｕｔｈというＡＰＩが存在する。しかしながら、フレキシブル認証を用いると、多数の課題が生じる。例えば、ＴＰＭ＿ＣｈａｎｇｅＡｕｔｈでは、認証値を変更する前に、オブジェクトへのアクセス権限があるという証明が必要なので、第三者証明機関のキーが失われたり、無効になれば、そのオブジェクトへのアクセス権限を取得することができず、変更は決して許可されない。既存の仕様書には、認証をなくした場合の課題をどのように回避するのか何も記載されていない。さらに、ＴＰＭ＿ＣｈａｎｇｅＡｕｔｈがフレキシブル認証において動作した場合、認証ルールを全面的に変更する性能は、ＴＰＭ所有者側からすると好ましくないかもしれない。例えば、ＴＰＭ所有者とオブジェクト所有者とが共に、そのオブジェクトに関連付けられた認証ルール要因を有しているとすれば、フレキシブル認証値は、どの特定ルール要因が変更されたかという証拠がない曖昧なハッシュ値であるため、オブジェクト所有者は、ＴＰＭ所有者のルール要因を無意識または意図的に上書きすることができるであろう。Ｔａｒｉｑの論文には、これらの課題をどのように解決するかについて何も記載されていない。
【０００６】
Ｐｒｏｕｄｌｅｒによる米国特許出願公開第２０１０／１１５６２５号明細書には、外部の者がＴＰＭ操作および他のＴＰＭへのデータ移行をどのように認証できるのか説明する、ＴＰＭのさらなる強化について記載されている。しかしながら、クライアント装置が、それ自身のルールをどのように変更するのか、他のＴＰＭに移行する前にルールをどのように変更するのかについて何も記載されていない。
【０００７】
Ｓｃｈｎｅｃｋらによる米国特許第５９３３４９８号明細書では、サーバがルール一覧の原本を保持して、そのコピーを複数のクライアント装置に配信すると規定することによって、認証ルールを更新する課題に対処しようとしている。また、クライアント装置は、それら自身のルールを追加したルールをさらに配信することができるが、自身のルールをどのように変更するのか、他の装置へさらに配信する前にルールをどのように変更するのかについては何も記載されていない。また、個々のルールそれぞれは独立したものであるが、完成したルールが個々のルール全てを合わせた曖昧なものである場合をどのように扱うのか記載されていない。
【０００８】
Ｍｏｒｉｃｏｎｉらによる米国特許第７３６３６５０号明細書でも、ポリシーの変更のデルタリストをどのように保持するのか、そして、そのデルタをクライアント装置にどのように適用するのかを規定することによって、認証ルールを更新する課題に対処しようとしているが、クライアント装置が、それ自身のルールをどのように変更するのか、他の装置へさらに配信する前にルールをどのように変更するのかについては何も記載されていない。また、ここでも、個々のルールそれぞれは独立したものであるが、完成したルールが個々のルール全てを合わせた曖昧なものである場合をどのように扱うのか記載されていない。
【０００９】
Ｓａｒｍｅｎｔａらによる論文「Ｖｉｒｔｕａｌ Ｍｏｎｏｔｏｎｉｃ Ｃｏｕｎｔｅｒｓ ａｎｄ Ｃｏｕｎｔ−Ｌｉｍｉｔｅｄ Ｏｂｊｅｃｔｓ ｕｓｉｎｇ ａ ＴＰＭ ｗｉｔｈｏｕｔ ａ Ｔｒｕｓｔｅｄ ＯＳ」では、Ｍｅｒｋｌｅハッシュ木において情報をどのように表し、信頼性のある環境内で、どのように変化を木の葉に適用して木の根まで伝えるのかを規定することによって、累積ハッシュ値を更新する課題に対処している。しかしながら、特定の葉の変更をどのように認証するのかについては記載されておらず、その木内にある仮想単調カウンタ以外のデータをどのように表すのかも教示されていない。
【００１０】
また、信頼性のあるシステムでは、データの起源を監査できることが重要である。例えば、曖昧な値で表された複雑なルール内のルール要因を１つ変更する場合には、その変更、および、その変更のみが実際に行われたという証拠が必要である。したがって、フレキシブル認証ルール内のルール要因を表す１つの値に対する認証済み変更要求に基づき、フレキシブル認証ルールを表す曖昧な値を安全かつ確実に更新する方法が必要である。
【００１１】
ゆえに、フレキシブル認証ルールを表す合成ハッシュ内の個々のルール要因を表す要因を１つ更新する信頼できる更新を実装する方法、システム、およびコンピュータプログラム製品を本願では提案する。
【発明の概要】
【００１２】
大まかに言うと、本発明は、セキュアなコンピューティングの技術分野に関するものである。
【００１３】
本発明のある態様では、変化および変化のみが生じたことを確実に立証できるよう、複雑な認証ルールの中からルール要因を１つ、信頼性のある環境によって安全に変更可能とする技術を提供する。これにより、認証ルールの起源を保証できる。
【００１４】
本発明のその他の態様および効果は、本発明の原理を例として説明する図面とともに、以下の詳細な説明から明らかになるであろう。
【図面の簡単な説明】
【００１５】
後述の好ましい実施形態の詳細な説明を以下の図面と共に考察することで、本発明のよりよい理解が得られる。
【図１】図１は、ディスクリートチップとしてＴＰＭを実装した、先行技術に係るＴＰＭ ｖ１．２搭載システムである。
【図２】図２は、プロセッサから提示された信頼性のある実行環境内にＴＰＭを実装した、先行技術に係るＴＰＭ ｖ１．２搭載システムである。
【図３】図３は、図１の先行技術に基づいた、本発明に係る、フレキシブル認証に対応したシステムである。
【図４】図４は、図２の先行技術に基づいた、本発明に係る、フレキシブル認証に対応したシステムである。
【図５】図５は、本発明に係る、フレキシブル認証ルールの例である。
【図６】図６は、本発明に係る、フレキシブル認証ルールを算出するイベントフローの例である。
【図７】図７は、先行技術に係る、キーの構造体を示す。
【図８】図８は、本発明に係る、フレキシブル認証に対応したキーの構造体を示す。
【図９】図９は、本発明に係るルール要因修正許可チケットを示す。
【図１０Ａ】図１０Ａは、本発明に係る、スマートカードリーダを特徴としたｅＴＰＭ ｖ１．２搭載システムである。
【図１０Ｂ】図１０Ｂは、本発明に係る、ルール要因修正許可部のチケット発行方法を示す。
【図１１】図１１は、本発明に係る、ルール要因修正許可部のその他の好ましい実施形態を示す。
【図１２】図１２は、本発明に係る、ルール修正チケットを発行するフローチャートを示す。
【図１３】図１３は、本発明に係る、ルール要因修正許可チケットからルール修正チケットを生成するイベントフローを示す。
【図１４】図１４は、本発明に係る、ルール修正チケットを用いてキーを修正するイベントフローを示す。
【発明を実施するための形態】
【００１６】
以下に、本発明の好ましい実施形態を説明する。
【００１７】
図１は、ＴＰＭをディスクリートチップとして実装した、先行技術に係るＴＰＭ ｖ１．２搭載システムである。ＴＰＭ ｖ１．２搭載システム１００は、中央処理装置ＣＰＵ１０２と、Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐが定義したトラステッドプラットフォームモジュールＴＰＭ１０４を含む。次に、ＲＡＭ、ＲＯＭ、ハードディスクなどの一般的なハードウェアリソース１１６があり、ベーシック入出力システムＢＩＯＳ１０６がある。そして、その上位にはオペレーティングシステム１０８が存在する。ＴＰＭ１０４へのインターフェースとして、Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐが定義したトラステッドソフトウェアスタックＴＳＳ１１０がある。このシステム上では、ＴＰＭ１０４と情報のやり取りを行うＴＳＳ１１０を介して相互作用する、ＴＰＭを意識した１以上のアプリケーション１１２が実行されてもよい。また、ＴＳＳ１１０を使用しない他のアプリケーション１１４は、実行されてもされなくてもどちらでもよい。
【００１８】
図２は、プロセッサから提示された信頼性のある実行環境内にＴＰＭを実装した、先行技術に係るＴＰＭ ｖ１．２搭載システムである。ＴＰＭ ｖ１．２搭載システム２００は、ＡＲＭのＴｒｕｓｔＺｏｎｅといった信頼性のある実行環境に対応した中央処理装置ＣＰＵ２０２を含む。これにより、ＣＰＵは、左側が通常モードで右側がセキュアモードの、間に境界２０６が存在する、異なる２つのモードを確立することができる。この境界により、片方のモードで実行中の処理は、もう片方のモードの処理やメモリに直接アクセスすることができない。まず、セキュアモードはセキュアなハードウェアリソース２０８を提供する。このハードウェアリソースは、好ましい形態では、ＳｏＣ（システムオンチップ）ソリューションが提供するものである。次に、セキュアなベーシック入出力システムＢＩＯＳ２１０があり、その上位に、セキュアなオペレーションシステム２１２が存在する。このセキュアなＯＳ内では、セキュアなＯＳによって保護されているソフトウェア（ＳＷ）ＴＰＭ２０４が実行される。また、その他のセキュアなアプリケーション２１４は、実行されてもされなくてもどちらでもよい。好ましい形態において、セキュアモードはいずれのデバッグ機能も無効にする。これは、セキュアなＯＳ上で実行しているソフトウェアは、装置外部からの未認証アクセスから保護されていることを意味する。また、セキュアモード内の１以上のリソースを、通常モード内のリソースから動的にロードしてもかまわない。これらのリソースは、通常モードに格納されているときは暗号化され、セキュアモードにロードするときは復号化されることが好ましい。
【００１９】
通常モードは、図１のシステムと類似している。まず、ＲＡＭ、ＲＯＭ、ハードディスクなどの一般的なハードウェアリソース１１６があり、ベーシック入出力システムＢＩＯＳ１０６がある。そして、その上位にはオペレーティングシステム１０８が存在する。ＴＰＭ２０４へのインターフェースとして、Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐが定義したトラステッドソフトウェアスタックＴＳＳ１１０がある。このシステム上では、ＴＰＭ２０４と情報のやり取りを行うＴＳＳ１１０を介して相互作用する、ＴＰＭを意識した１以上のアプリケーション１１２が実行されてもよい。また、ＴＳＳ１１０を使用しない他のアプリケーション１１４は、実行されてもされなくてもどちらでもよい。
【００２０】
図３は、ｅＴＰＭであり、先頭の「ｅ」は拡張（ｆｏｒ ｅｘｔｅｎｄｅｄ）を表している。このｅＴＰＭは、本発明に係るフレキシブル認証に対応しており、図１の先行技術に基づく。ＴＰＭ１０４内には、長期間にわたるデータを記憶する不揮発性ＲＡＭ、ＮＶＲＡＭ３００と、短期間のデータを記憶する揮発性ＲＡＭ、ＶＲＡＭ３０２と、インクリメントされるだけで決してデクリメントされない特別なカウンタ値を記憶する単調カウンタ３０４と、ＰＣＲ３１２、プラットフォーム構成レジスタと、プラットフォームの構成情報を保持する特別なＶＲＡＭ記憶部とがある。次に、コアＴＰＭ機能３０８と、本発明に係る、追加されたフレキシブル認証ルール評価および管理機能３１０とが存在する。フレキシブル認証ルール評価および管理機能には、個々のルール要因それぞれの項を検証かつ評価する方法と、合成ハッシュ拡張部３２０を用いて、評価された項全てを累積した途中結果を保持して、個々のルール要因と今までの途中結果とを組み合わせる方法とが含まれる。好ましい形態では、拡張部３２０は、ＴＣＧによって説明されている合成ハッシュ拡張技術を利用する。さらに、フレキシブル認証ルール評価および管理機能３１０用の追加サポートコンポーネントが２つある。１つは、チケット発行部３２２であり、キーのフレキシブル認証ルールの修正をキーに許可するチケットを生成する。もう１つは、チケット検証部３２４であり、個々のフレキシブル認証ルール要因の変更を許可するチケットのフォーマットと署名を検証する。最後に、暗号化アルゴリズムＳＨＡ−１ ３１４、ＲＳＡ ３１６およびＨＭＡＣ ３１８がある。これらの暗号化アルゴリズムは、現在、ＴＰＭが必要とするものだけであるが、ＳＨＡ２５６、ＳＨＡ３８４およびＳＨＡ５１２またはＥＣＣなどの別のアルゴリズムを、本発明を逸脱することなく、代わりに用いてもかまわない。また、当業者であれば、ＲＯＭ３０６は、当該技術分野で周知の技術を用いて、権限を満たしている者により再プログラムされてもよいと分かるであろう。
【００２１】
図４は、ｅＴＰＭであり、先頭の「ｅ」は拡張（ｆｏｒ ｅｃｔｅｎｄｅｄ）を表している。このｅＴＰＭは、本発明に係るフレキシブル認証に対応しており、図２の先行技術に基づく。ＳＷ ＴＰＭ２０４内には、長期間にわたるデータを記憶する不揮発性ＲＡＭ、ＮＶＲＡＭ３００と、短期間のデータを記憶する揮発性ＲＡＭ、ＶＲＡＭ３０２と、インクリメントされるだけで決してデクリメントされない特別なカウンタ値を記憶する単調カウンタ３０４と、ＰＣＲ３１２、プラットフォーム構成レジスタと、プラットフォームの構成情報を保持する特別なＶＲＡＭ記憶部とがある。次に、コード記憶領域４００が存在し、コアＴＰＭ機能３０８と、本発明に係る、追加されたフレキシブル認証ルール評価および管理機能３１０とを実現するソフトウェアを記憶する。フレキシブル認証ルール評価および管理機能には、個々のルール要因それぞれの項を検証かつ評価する方法と、合成ハッシュ拡張部３２０を用いて、評価された項全てを累積した途中結果を保持して、個々のルール要因と今までの途中結果とを組み合わせる方法とが含まれる。好ましい形態では、拡張部３２０は、ＴＣＧによって説明されている合成ハッシュ拡張技術を利用する。さらに、フレキシブル認証ルール評価および管理機能３１０用の追加サポートコンポーネントが２つある。１つは、チケット発行部３２２であり、キーのフレキシブル認証ルールの修正をキーに許可するチケットを生成する。もう１つは、チケット検証部３２４であり、個々のフレキシブル認証ルール要因の変更を許可するチケットのフォーマットと署名を検証する。最後に、暗号化アルゴリズムＳＨＡ−１ ３１４、ＲＳＡ ３１６およびＨＭＡＣ ３１８がある。これらの暗号化アルゴリズムは、現在、ＴＰＭが必要とするものだけであるが、ＳＨＡ２５６、ＳＨＡ３８４およびＳＨＡ５１２またはＥＣＣなどの別のアルゴリズムを、本発明を逸脱することなく、代わりに用いてもかまわない。また、当業者であれば、コード記憶部４００は、ＲＯＭ内に置かれている場合や適切な技術を用いて外部の記憶部からコードをロードさせる場合など様々な方法で実現されてもよいと分かるであろう。
【００２２】
図５は、本発明に係る、フレキシブル認証ルールのデータ表示例である。フレキシブル認証ルール５００は、個々のルール要因それぞれが特定の値を有する、個々のルール要因５０４、５０８、５１２の木とみなすことができる。予想されたＰＣＲ状態は０ｘ３４…５６ ５０６、予想された署名付き状態は０ｘ５６…７８ ５１０、そして、予想されたＮＶ ＲＡＭは０ｘ７８…９Ａ ５１４である。好ましい形態では、予測された署名付き状態ルール要因５０８は、指紋読み取り部によって生成される。これらのルール要因に加え、ＩＤカードから取得した予測ＩＤや予測パスワードなど、他のルール要因を追加してもかまわない。
【００２３】
さらに、フレキシブル認証ルールそのものは０ｘ１２…３４ ５０２という値をもち、この値は個々のルール要因を全て組み合わせたものを表している。当該図面の矢印は、１番下のルール要因５１２を最初に算出してフレキシブル認証ルールの初期値、つまり、０ｘ００…０００内に拡張し、そして、第２のルール要因５０８を評価して今までの要因内に拡張し、そして、第３のルール要因５０４を評価して今までの結果内に拡張することを示している。そして、最終結果がフレキシブル認証ルール５００の値５０２となる。図８で後述するように、この最終値をＴＰＭキーと関連付けて、フレキシブル認証ルールを検証する必要があるとｅＴＰＭに知らせてからこの関連キーへのアクセスを許可してもよい。好ましい形態では、これらの値はＳＨＡ−１ハッシュを用いて算出される。しかしながら、当業者であれば、この代わりに他のハッシュアルゴリズムを利用してもかまわないと分かるであろう。ルール要因は、ＴＰＭ内の予測されたプラットフォーム構成レジスタ、つまり予測ＰＣＲ値５０４、または、第三者からの署名付き予測値５０８、または、ＮＶＲＡＭ内の予測値５１２を表してもよい。
【００２４】
図６は、本発明に係るフレキシブル認証ルールを算出するイベントフローの例を示したものである。ルールを算出するためには、３つの主要要素が必要である。まず、ルールを評価するアプリケーションからの要求を処理するＴＳＳ１１０、次に、ＴＰＭ内のフレキシブル認証ルール機能３１０、最後に、ＴＰＭ上のＶＲＡＭ３０２内に置かれているルールハッシュ値記憶部６００がある。単純化のため、ＴＳＳ１１０からフレキシブル認証ルール機能３１０へのＴＰＭインターフェースを介したコマンドルーチンは図示していない。このルールハッシュは、検証されたルール要因を全て累積した現在の合成ハッシュを記録するフレキシブル認証ルールセッションに対して可変なセッションである。まず最初に、ＴＳＳは、ＴＰＭＥｘ＿ＳｔａｒｔＲｕｌｅＳｅｓｓｉｏｎ ＡＰＩで新たなフレキシブル認証ルールセッションの開始を要求する６０２。これにより、ルールハッシュ値は０ｘ００…００ ６０６に初期化される６０４。次に、図５の木の１番下に位置する第１ルール要因は、Ｃｅｌｌ＿１というＮＶＲＡＭ ３００のメモリ位置の値が１０より小さいことの検証を要求するＴＰＭＥｘ＿ＲｕｌｅＴｅｓｔＮＶ ＡＰＩを呼び出す６０８ことによって実行される。ＴＰＭ内のフレキシブル認証ルール評価部３１０は、まず、Ｃｅｌｌ＿１に記憶された値が実際に１０より小さいことを検証し６１０、そして、１０より小さいとみなすと、ＴＰＭＥｘ＿ＲｕｌｅＴｅｓｔＮＶ ＡＰＩの引数のＳＨＡ−１ハッシュの値を求める６１２ことによってルール要因を代表する値を形成する。ＳＨＡ−１ハッシュは、この例では０ｘ７８…９Ａという値が示されており、図５の５１４に記載された予測値と一致している。そして、この値をルールハッシュ内に拡張する６１２。値をハッシュ内に拡張するという動作はＴＰＭ仕様書に記載されている処理であり、それによると、現在のハッシュと拡張する値とを連結したハッシュを算出し、そして、その結果を新たなハッシュとして用いることにより、ハッシュを更新する。図示するために、拡張後の新たなルールハッシュは０ｘＦＥ…ＤＣ ６１６となる。
【００２５】
次に、図５の木の真ん中に位置する第２ルール要因は、１つの特定データに有効な署名が添付されていることの検証を要求するＴＰＭＥｘ＿ＲｕｌｅＴｅｓｔＳｉｇｎ ＡＰＩを呼び出す６１８ことによって実行される。ＴＰＭ内のフレキシブル認証ルール評価部は、まず、データが実際に正しく署名されていることを検証し６２０、そして、正しく署名されているとみなすと、ＴＰＭＥｘ＿ＲｕｌｅＴｅｓｔＳｉｇｎ ＡＰＩの引数のＳＨＡ−１ハッシュの値を求める６２２ことによってルール要因を代表する値を形成する。ＳＨＡ−１ハッシュは、この例では０ｘ５６…７８という値が示されており、図５の５１０に記載された予測値と一致している。そして、この値をルールハッシュ内に拡張する６２４。図示するために、拡張後の新たなルールハッシュは０ｘＤＣ…ＢＡ ６２６となる。
【００２６】
次に、図５の木の一番上に位置する第３ルール要因は、ＰＣＲ値の現在のサブセットと渡された値とが一致することの検証を要求するＴＰＭＥｘ＿ＲｕｌｅＴｅｓｔＰＣＲ ＡＰＩを呼び出す６２８ことによって実行される。ＴＰＭ内フレキシブル認証ルール評価部は、まず、現在のＰＣＲ値と渡された値とが実際に等しいことを検証し６３０、そして、等しいとみなすと、ＴＰＭＥｘ＿ＲｕｌｅＴｅｓｔＰＣＲ ＡＰＩの引数のＳＨＡ−１ハッシュの値を求める６３２ことによってルール要因を代表する値を形成する。ＳＨＡ−１ハッシュは、この例では０ｘ３４…５６という値が示されており、図５の５０６に記載された予測値と一致している。そして、この値をルールハッシュ内に拡張する６３４。図示するために、拡張後の新たなルールハッシュは０ｘ１２…３４ ６３６となる。図５のフレキシブル認証ルール５００を確認すると、そこも０ｘ１２…３４ ５０２となっている。したがって、フレキシブル認証ルールをこの値に設定したオブジェクトであればＴＰＭ内ですぐ利用してもかまわない。
【００２７】
図７は、ＴＰＭ仕様書に記載されている先行技術に係るキーの構造体を示す。ＴＰＭキー構造体７００には多くのフィールドがある。まず、１．１．０．０．の値をもつバージョン番号ラベルｖｅｒ ７０２があり、その次は、キーをどのように利用できるかを示す値、ｋｅｙＵｓａｇｅ ７０４がある。ｋｅｙＦｌａｇｓ ７０６は、キーごとに設定可能な制御選択肢を示し、ａｕｔｈＵｓａｇｅＤａｔａ ７０８は、キーに対する認証データをどのように用いるかを示す。ａｌｇｏｒｉｔｈｍＰａｒｍｓ ７１０は、このキーで、どの暗号化アルゴリズムとどの署名アルゴリズムを利用できるかを示す構造であり、ｐｃｒＩｎｆｏＳｉｚｅ ７１２とｐｃｒＩｎｆｏ ７１４は共に、キーの利用前になければならないＰＣＲ値セットを定義している。ｐｕｂＫｅｙ ７１６はキーの公開部分を保持している。最後に、ｅｎｃＤａｔａＳｉｚｅ ７１８とｅｎｃＤａｔａ ７２０は共に、キーの秘密部分を表している。
【００２８】
図８は、本発明に係る、フレキシブル認証に対応したキーの構造体を示している。ＴＰＭフレキシブル認証キー構造体８００には多くのフィールドがあり、それらの大部分は図７で示したものと同じである。まず、１．３．０．０．の値をもつバージョン番号ラベルｖｅｒ ７０２がある。なお、キーの構造体が先行技術で説明されたものと異なるたびに、バージョン番号はインクリメントされてきている。その次は、キーをどのように利用できるかを示す値、ｋｅｙＵｓａｇｅ ７０４である。ｋｅｙＦｌａｇｓ ７０６は、キーごとに設定可能な制御選択肢を示し、ａｕｔｈＵｓａｇｅＤａｔａ ７０８は、キーに対する認証データをどのように用いるかを示す。ここには、ｆａＲｕｌｅＤａｔａ ８０２を用いるかどうかを示す追加フラグと、ｆａＲｕｌｅＤａｔａ ８０２を修正できるかどうかを示す他の追加フラグとがある。その次に、ａｌｇｏｒｉｔｈｍＰａｒｍｓ ７１０は、このキーで、どの暗号化アルゴリズムとどの署名アルゴリズムが利用可能なのかを示す構造であり、ｐｃｒＩｎｆｏＳｉｚｅ ７１２とｐｃｒＩｎｆｏ ７１４は共に、キーの利用前になければならないＰＣＲ値セットを定義している。ｆａＲｕｌｅＤａｔａ ８０２は、キーの利用前になければならないフレキシブル認証ルールハッシュを定義している。ｐｕｂＫｅｙ ７１６はキーの公開部分を保持している。最後に、ｅｎｃＤａｔａＳｉｚｅ ７１８とｅｎｃＤａｔａ ７２０は共に、キーの秘密部分を表している。
【００２９】
ＴＰＭフレキシブル認証キー構造体８００をＴＰＭにロードするためには、まず、図６と類似のイベントシーケンスを実行してＴＰＭに記憶されたルールハッシュ６００を生成しなければならない。次に、ＴＰＭを意識したアプリケーション１１２からの命令でＴＳＳ１１０は、既存のＴＰＭ＿ＬｏａｄＫｅｙ２ ＡＰＩを呼び出す。先行技術に係るこのコマンドの動作はＴＰＭ仕様書において詳述されている。さらに、ｆａＲｕｌｅＤａｔａ ８０２をチェックする必要があると示すフラグセットがａｕｔｈＵｓａｇｅＤａｔａ ７０８にある場合、渡されたキーのｆａＲｕｌｅＤａｔａ ８０２とルールハッシュ６００に記憶されている値とをＴＰＭは比較し、一致しなければ、キーをロードできないことを示す適切なエラーコードをＴＰＭ＿ＬｏａｄＫｅｙ２ ＡＰＩは返さなければならない。
【００３０】
上記にて、フレキシブル認証ルールを有するキーはどのように定義かつロードされるのかを詳述した。次に、フレキシブル認証ルールを変更する方法について詳述する。
【００３１】
図９は、本発明に係るルール要因修正許可チケットを示す。フレキシブル認証ルール内の要因を１つ修正するためには、修正されていないルール要因と、修正されたルール要因と、修正するためのキーハンドルと、変更するルール要因のタイプを表すＩＤとを含んだ要求にルール要因修正許可部が署名して、ＴＰＭルール要因修正チケット９００を生成しなければならない。この構造体のフィールドは以下のとおりである。まず、ＳＨＡ−１ハッシュは、置き換えの必要があるフレキシブル認証内の古いルール要因９０２を表している。この要因は、図５の５０６、５１０、または５１４に対応する。次に、別のＳＨＡ−１は、古い要因９０２を置き替えることになるフレキシブル認証内の新たなルール要因９０４を表している。そして、置き替え対象の要因タイプ９０６を表すＩＤと、図８で示したようなＴＰＭ要因認証キー構造体９０８と、今までのフィールドの暗号化ダイジェスト９１０と、そのダイジェストに署名した署名キー９１２とがある。好ましい形態では、この署名キーには、このような種類のチケットへの署名が許可された署名キーであることを示すＴＰＭ＿ＫＥＹ＿ＦＡＣＨＡＮＧＥの値に設定されたｋｅｙＵｓａｇｅフィールド７０４がある。後述するように、古いルール要因９０２とＴＰＭ要因認証キー９０８の両方またはどちらか一方は、チケットを利用する場合、古いルール要因９０２とＴＰＭ要因認証キー９０８の両方またはどちらか一方に制限がないことを示すＮＵＬＬでもかまわない。
【００３２】
図１０Ａは、ＴＰＭをディスクリートチップとして実装し、かつ、ルール要因修正許可部がスマートカード上に常駐している、本発明に係るｅＴＰＭ搭載システムを示している。このｅＴＰＭ搭載システム１００は、中央処理装置ＣＰＵ１０２と、Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐが定義したトラステッドプラットフォームモジュールＴＰＭ１０４を含む。次に、ＲＡＭ、ＲＯＭ、ハードディスクなどの一般的なハードウェアリソース１１６があり、ベーシック入出力システムＢＩＯＳ１０６がある。そして、その上位にはオペレーティングシステム１０８が存在する。ＴＰＭ１０４へのインターフェースとして、Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐが定義したトラステッドソフトウェアスタックＴＳＳ１１０がある。このシステム上では、ＴＰＭ１０４と情報のやり取りを行うＴＳＳ１１０を介して相互作用する、ＴＰＭを意識した１以上のアプリケーション１１２が実行されてもよい。また、ＴＳＳ１１０を使用しない他のアプリケーション１１４は、実行されてもされなくてもどちらでもよい。さらに、ＵＳＢなどのインターフェースや当該技術分野において周知の他の接続方法を介してシステム１００に取り付けられたスマートカードリーダ１００４がある。スマートカードリーダ１００４内にはスマートカード１００２があり、そのスマートカード１００２上にはルール要因修正許可アプリケーション１０００がある。好ましい形態において、スマートカード１００２およびルール要因修正許可アプリケーション１０００は、ＯｒａｃｌｅのＪａｖａ Ｃａｒｄ ３．０仕様書で定義されている規格に準拠している。当業者であれば、ルール要因修正許可アプリケーション１０００を、様々な技術を介して実装しても、リモートサーバ上に実装しても、システムが対応しているのであれば、システム１００上の信頼性のある実行環境内に実装してもかまわないと分かるであろう。
【００３３】
図１０Ｂは、本発明に係るルール要因修正許可部のチケット発行方法を示す。ルール要因修正許可チケットを生成するためには、３つの要素がやりとりする必要がある。まず、ＴＳＳ１１０はルール要因修正許可部１０００に対して要求を行い、そして、ルール要因修正許可部はＴＰＭ１０４を用いてその許可権に署名をする。好ましい形態において、ルール要因修正許可部１０００は、システム１００に接続されたスマートカード１００２上に置かれている。まず、ＴＳＳ１１０は、ルール要因を更新したいキーとそのルール要因の現在の値を検索する１０５２。好ましい形態では、キーごとに個々のルール要因を表すキーに関連した一覧が存在する。その他の好ましい形態では、ＴＳＳ１１０を呼び出すＴＰＭを意識したアプリケーション１１２が、事前に算出したルール要因を引数として渡す。次に、ＴＳＳは新たなルール要因を算出する１０５４。この値はＴＳＳ自身によって算出されてもよい。あるいは、その他の好ましい形態では、ＴＳＳ１１０を呼び出すＴＰＭを意識したアプリケーション１１２が、事前に算出した新たなルール要因を引数として渡す。ここで、古いルール要因と新しいルール要因とルール要因タイプと対象キーとが準備されると、ＴＳＳ１１０は、ルール要因修正許可部に変更の承認を要求する１０５６。まず、ルール要因修正許可部１０００は、ｋｅｙＵｓａｇｅ ７０４フィールドが適切な値だと確認することによって、渡されたキーによりそのフレキシブル認証ルールを変更できることを検証し１０５８、そして、そのルール要因タイプが変更許可されたものであることを確認する１０６０。例えば、ローカルのルール要因修正許可部は、ＮＶＲＡＭチェック要因の変更用チケットを発行許可するだけでもよいが、リモートルール要因修正許可部は、どんな要因タイプも変更できるチケットを発行してもよい。次に、さらなる確認が行われる１０６２。好ましい形態では、署名キーのみがローカルのルール要因修正許可部によって変更されてもかまわない。これらの確認が全て成功すれば、ルール要因修正許可部１０００は、その修正許可キーをＴＰＭ１０４にロードする１０６４。なお、このローディングそのものが、図６のように適用されるフレキシブル認証ルールを要求してもかまわない。キーが成功裏にロードされれば、ルール要因修正許可部は、チケット構造体を作成し１０６６、その構造体の署名付きダイジェストを生成するようＴＰＭに要求する１０６８。そして、さらなる処理のため、ＴＳＳにチケットを返す１０７０。
【００３４】
図１１は、本発明に係る、ルール要因修正許可部のその他の好ましい実施形態を示す。図１０Ｂと同様に、ルール要因修正許可チケットを生成するためには、３つの要素がやりとりする必要がある。まず、ＴＳＳ１１０はルール要因修正許可部１０００に対して要求を行い、そして、ルール要因修正許可部はＴＰＭ１０４を用いてその許可権に署名をする。好ましい形態において、ルール要因修正許可部１０００は、システム１００に接続されたスマートカード１００２上に置かれている。まず、ＴＳＳ１１０は、ルール要因を更新したいキーと、変更を要求したいルール要因の現在のパラメータおよび新しいパラメータとを検索する１１０２。好ましい形態では、キーごとに個々のルール要因を表すキーと関連付けた一覧が存在する。その他の好ましい形態では、ＴＳＳ１１０を呼び出すＴＰＭを意識したアプリケーション１１２が、ルール要因パラメータを引数として渡す。次に、ＴＳＳ１１０は、１１０２で検索された古いルール要因パラメータと新しいルール要因パラメータとを渡すことによって、ルール要因修正許可部に変更の承認を要求する１１０４。この図では、修正対象のルール要因は図５のルール要因５０８なので、古いデータと新しいデータと署名に用いられたキーとが渡される。まず、ルール要因修正許可部１０００は、渡されたパラメータに基づいて、古いルール要因と新しいルール要因とを算出する１１０６。図１０Ｂと同様、ルール要因修正許可部１０００は、次に、ｋｅｙＵｓａｇｅ ７０４フィールドが適切な値だと確認することによって、渡されたキーによりそのフレキシブル認証ルールを変更できることを検証し１１０８、そして、そのルール要因タイプが変更許可されたものであることを確認する１１１０。例えば、ローカルのルール要因修正許可部は、ＮＶＲＡＭチェック要因の変更用チケットを発行許可するだけでもよいが、リモートルール要因修正許可部は、どんな要因タイプも変更できるチケットを発行してもよい。次に、さらなる確認が行われる１１１２。図１０Ｂのステップ１０６２と比較すると、古いルール要因および新しいルール要因のハッシュ値ではなくそれらの個々の要素が渡されるので、さらなる確認１１１２はより詳細なものとなる。例えば、古いキーＡを検証してそれが無効になったことを確認してもよいし、新たなキーＢを検証してそれが無効になっていないことを確認してもよい。または、メッセージＡおよびメッセージＢを検証してそれらが同じであり、単に修正中のキーであることを確認してもよい。キーＡおよびキーＢは、署名を検証するルール要因修正許可部１０００によって利用されるだけなので、好ましい実施形態では、これらのキーをＸ．５０９証明書で表す。その他の好ましい実施形態では、これらのキーはＴＰＭ内に置かれる。これらの確認が全て成功すれば、ルール要因修正許可部１０００は、その修正許可キーをＴＰＭ１０４にロードする１１１４。なお、このローディングそのものが、図６のように適用されるフレキシブル認証ルールを要求してもかまわない。キーが成功裏にロードされれば、ルール要因修正許可部は、チケット構造体を作成し１１１６、その構造体の署名付きダイジェストを生成するようＴＰＭに要求する１１１８。そして、さらなる処理のため、ＴＳＳにチケットを返す１１２０。
【００３５】
図１２は、本発明に係るルール修正チケットを示す。完成したフレキシブル認証ルールに対する修正を認証するためには、ＴＰＭルール要因修正チケット９００がキーの変更を許可されていることは検証済みであると明言できるチケットをＴＰＭは発行しなければならない。このルール修正チケットの構造体１２００におけるフィールドは以下のとおりである。まず、ＳＨＡ−１ハッシュは、置き換えの必要がある、古いフレキシブル認証ルール値１２０２を含んでいる。この要因は、図５の５０２に対応する。次に、別のＳＨＡ−１は、古いルール値１２０２を置き替えることになる新しいフレキシブル認証ルール値１２０４を含んでいる。そして、１２０２の値から１２０４の値に変更されたフレキシブル認証ルール値をもつことになる図８で示したようなＴＰＭ要因認証キー構造体１２０６と、最後に、その構造体の上記フィールドのＨＭＡＣダイジェスト１２０８がある。このＨＭＡＣは、ＴＰＭが定義したＴＰＭ＿ＰＥＲＭＡＮＥＮＴ＿ＤＡＴＡ中のｔｐｍＰｒｏｏｆ値など、適切な秘密キーを用いてＲＦＣ２１０４に従い算出される。
【００３６】
図１３は、本発明に係る、ルール要因修正許可チケットからルール修正チケットを生成するイベントフローを示す。ルールを検証するためには、３つの主要要素が必要である。まず、ルールを検証するアプリケーションからの要求を処理するＴＳＳ１１０、次に、ＴＰＭ内のフレキシブル認証（ＦＡ）ルール機能３１０、最後に、ＴＰＭ上のＶＲＡＭ３０２内に置かれているルールハッシュのペア値記憶部１３００がある。このイベントシーケンスは、図６で示したようなフレキシブル認証ルールを算出するものと類似している。しかしながら、１つのルールハッシュ６００ではなく、このチケットを生成する場合には、古いルールハッシュと新しいルールハッシュの両方を算出するため、ルールハッシュのペア１３００が必要となる。まず、ＴＰＭＥｘ＿ＳｔａｒｔＲｕｌｅＶｅｒｉｆｉｃａｔｉｏｎＳｅｓｓｉｏｎ ＡＰＩを呼び出して１３０２、両方のルールハッシュを０ｘ００…００の値１３０６に初期化する１３０４。次に、図５に示したようなルール要因の並びを適用する。図６ではハッシュ内に拡張する前に各ルール要因を検証しているが、ここでキーポイントとなる違いは、ルール要因を検証しないということである。ＴＰＭＥｘ＿ＲｕｌｅＶｅｒｉｆｙＮＶ ＡＰＩを呼び出し１３０８、規定のＮＶＲＡＭ位置を調べることなく、フレキシブル認証（ＦＡ）ルール評価部３１０は、ＴＰＭＥｘ＿ＲｕｌｅＶｅｒｉｆｙＮＶ ＡＰＩの引数のＳＨＡ−１ハッシュの値を求める１３１０ことによってルール要因を代表する値を形成する。ＳＨＡ−１ハッシュは、この例では０ｘ７８…９Ａという値が示されており、図５の５１４に記載された予測値と一致している。そして、この値をルールハッシュペアの両方に拡張する１３１２。値をハッシュ内に拡張するという動作はＴＰＭ仕様書に記載されている処理であり、それによると、現在のハッシュと拡張する値とを連結したハッシュを算出し、そして、その結果を新たなハッシュとして用いることにより、ハッシュを更新する。図示するために、拡張後の新たなルールハッシュペアは０ｘＦＥ…ＤＣ ６１６となる。
【００３７】
次に、図５の木の真ん中に位置する第２ルール要因は、ＴＰＭＥｘ＿ＲｕｌｅＶｅｒｉｆｙＳｉｇｎ ＡＰＩを呼び出す１３１６ことによって実行される。これは、図１０Ａに従ってルール要因修正許可チケットを発行させたルール要因なので、このチケットは、フレキシブル認証（ＦＡ）ルール評価部３１０にも渡される。この評価部は、まず、ルール要因修正許可チケットが正しく署名されていることと、ｆａｃｔｏｒＩＤが現在のルール要因タイプ用を示していることを検証し１３１８、そして、引数のＳＨＡ−１ハッシュの値を求める１３２０。このＳＨＡ−１ハッシュは、この例では０ｘ５６…７８という値が示されており、図５の５１０に記載された予測値と一致している。次に、この算出したハッシュを、ルール要因修正許可チケットのｏｌｄＦａｃｔｏｒフィールドに格納されているハッシュと比較する１３２２。等しければ、チケットはこの項を修正するのに有効なチケットであるため、このチケットのｏｌｄＦａｃｔｏｒ９０２とｎｅｗＦａｃｔｏｒ９０４をそれぞれ、ルールハッシュペア内の各フィールドへ拡張する１３２４。図示するために、拡張後の新たなルールハッシュペアは０ｘＤＣ…ＢＡ（古い値）および０ｘＣＤ…ＢＡ（新しい値）１３２６となる。なお、もし、ルール要因修正許可チケットのｏｌｄＦａｃｔｏｒの値９０２がＮＵＬＬであれば、１３２２における古い値の検証は省略され、ｆａｃｔｏｒＩＤ９０６がＮＵＬＬであれば、１３１８におけるＩＤの検証は省略される。
【００３８】
次に、図５の木の一番上に位置する第３ルール要因は、ＴＰＭＥｘ＿ＲｕｌｅＶｅｒｉｆｙＰＣＲ ＡＰＩを呼び出し１３２８、規定のＰＣＲを調べることなく、フレキシブル認証（ＦＡ）ルール評価部３１０は、ＴＰＭＥｘ＿ＲｕｌｅＶｅｒｉｆｙＰＣＲ ＡＰＩの引数のＳＨＡ−１ハッシュの値を求めることによってルール要因を代表する値を形成する。ＳＨＡ−１ハッシュは、この例では０ｘ３４…５６という値が示されており、図５の５０６に記載された予測値と一致している。そして、この値をルールハッシュのペア内に拡張する１３３２。図示するために、拡張後のルールハッシュペアは０ｘ１２…３４の古いハッシュ値と０ｘ２１…４３の新しいハッシュ値１３３４になる。
【００３９】
この時点で、古いフレキシブル認証ルール値と新しいフレキシブル認証ルール値とが算出されたので、ここで初めて、クライアントＴＳＳは、ＴＰＭＥｘ＿ＲｅｑｕｅｓｔＲｕｌｅＭｏｄｉｆｉｃａｔｉｏｎＴｉｃｋｅｔ ＡＰＩを用い、かつ、チケットを作成するキーとルール要因修正許可チケットとを渡すことによって、ルール修正チケットの作成を要求できる１３３６。渡されたキーのｆａＲｕｌｅＤａｔａフィールド８０２がルールハッシュペア１３００の古い値と等しければ、ルール要因修正許可チケットは正しく署名されており、ルール要因修正許可チケットのｋｅｙフィールド９０８が渡されたキーと等しければ１３３８、ルール修正チケットは発行され１３４０、ＴＳＳ１１０にそのチケットを返す。
【００４０】
図１４は、本発明に係る、ルール修正チケットを用いてキーを修正するイベントフローを示す。修正を実行するためには、２つの主要要素が必要である。まず、キーを修正するアプリケーションからの要求を処理するＴＳＳ１１０、そして、構造体への実際の変更を処理するＴＰＭ内のフレキシブル認証（ＦＡ）ルール機能３１０がある。ＴＰＭ内のキーはそれらの親キーによって暗号化されているため、まず最初に、親キーを用いてＯＳＡＰセッションを確立し１４００、対象である子キーのデータを復号する権限を取得する必要がある。ＴＰＭコア３０８内に実装されている先行技術に従ってセッションが確立された時点で、データの実際の変更を行うことが可能になる。ＴＳＳは、対象キーと、ＯＳＡＰセッションハンドルと、図１３に示すように生成されたルール修正チケットとを渡すことによって、フレキシブル認証を変更する要求を行う１４０２。まず、フレキシブル認証（ＦＡ）ルール評価部は、先行技術で説明されているように、ＯＳＡＰセッションを検証する１４０４。そして、キー構造体のフォーマット１４０６およびルール修正チケットの署名１４０８を検証し、ルール修正チケットのｋｅｙフィールド１２０６と渡されたキー８００との一致をバイトごとに比較して確認し、ｏｌｄＦＡＲｕｌｅ１２０４がキーのｆａＲｕｌｅＤａｔａ８０２と等しいことを確認することにより、渡されたキーに対してこのルール修正チケットが有効なこと１４１０を検証する。これらの２つが一致すれば、ｅｎｃＤａｔａ７２０内に格納されている秘密キーデータを親キーで復号し１４１０、その結果得られた構造体を検証して、この構造体が、先行技術で説明されているような、有効なＴＰＭ＿ＳＴＯＲＥ＿ＡＳＹＭＫＥＹまたはＴＰＭ＿ＭＩＧＲＡＴＥ＿ＡＳＹＭＫＥＹであることを保証する。渡されたキー内のｆａＲｕｌｅＤａｔａ８０２をルール修正チケット１２０８のｎｅｗＦＡＲｕｌｅフィールド１２０４に設定する１４１４。そして、復号されたｅｎｃＤａｔａ ７２０のｐｕｂＤａｔａＤｉｇｅｓｔ内に格納されているハッシュ値を再計算して、フレキシブル認証ルールの変更を反映する。最後に、ｅｎｃＤａｔａ ７２０を親キーで再び暗号化し１４１８、処理が成功したことを呼び出し側に返す１４２０。
【００４１】
キーを移動するたびにキーのポリシーの変更がキーに許可されるキー移動に対して、当業者であれば、図１４の技術をＴＰＭ仕様書内に記載されている技術と組み合わせてもかまわないと分かるであろう。
【００４２】
本発明は上記の実施形態に基づいて述べられているが、本発明は明らかにそのような実施形態に限定されるものではない。下記のケースもまた本発明に含まれる。
【００４３】
（１）上記の各装置は、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ、ハードディスクユニット、ディスプレイユニット、キーボード、マウスなどから構成されるコンピュータシステムである。ＲＡＭまたはハードディスクユニットには、コンピュータプログラムが記憶されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、各装置は、その機能を達成する。ここでコンピュータプログラムは、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。
【００４４】
（２）上記の各装置を構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどを含んで構成されるコンピュータシステムである。ＲＡＭには、コンピュータプログラムが記憶されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、システムＬＳＩは、その機能を達成する。
【００４５】
さらに、各装置を構成する構成部品の各ユニットは、別個の個別チップとして、または、一部もしくは全てを含む単一のチップとして作られてもよい。
【００４６】
さらに、ここでは、ＬＳＩが述べられているが、集積化の程度の違いにより、指定ＩＣ、ＬＳＩ、スーパＬＳＩ、ウルトラＬＳＩが使用される場合もある。
【００４７】
さらに、回路の集積化の手段は、ＬＳＩに限定されるものではなく、専用回路、もしくは汎用プロセッサによる実装も利用できる。さらに、ＬＳＩが製造された後にプログラム可能なフィールドプログラムゲートアレイ（ＦＰＧＡ）を使用することもまた可能であり、またＬＳＩ内で回路セルの接続および設定を再構成可能なリコンフィギュアラブルプロセッサも使用可能である。
【００４８】
さらに、もしＬＳＩに置き換わる集積回路技術が半導体技術もしくは他の派生する技術の進歩を通じて現われるのであれば、その技術は当然に構成要素の集積化を実現するために使用することができる。バイオ技術の適用が予想される。
【００４９】
（３）上記の各装置を構成する構成要素の一部または全部は、各装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしてもよい。ＩＣカードまたはモジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどから構成されるコンピュータシステムである。ＩＣカードまたはモジュールは、上記の超多機能ＬＳＩに含まれるとしてもよい。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、ＩＣカードまたはモジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。
【００５０】
（４）本発明は、上記に示す方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、コンピュータプログラムなどのデジタル信号であるとしてもよい。
【００５１】
また、本発明は、コンピュータプログラムまたはデジタル信号をコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＢＤ（Ｂｌｕ−ｒａｙ Ｄｉｓｃ）、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されているデジタル信号であるとしてもよい。
【００５２】
また、本発明は、コンピュータプログラムまたはデジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。
【００５３】
また、本発明は、マイクロプロセッサとメモリを備えたコンピュータシステムであって、メモリは、上記コンピュータプログラムを記憶しており、マイクロプロセッサは、コンピュータプログラムにしたがって動作するとしてもよい。
【００５４】
また、プログラムまたはデジタル信号を記録媒体に記録して移送することにより、またはプログラムまたはデジタル信号を、ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。
【００５５】
（５）本技術分野の当業者にとっては、説明した実施形態の、本発明固有の教示および利点から原理的に離れることのない多くの変形がありえることを容易に理解することができるだろう。また、上記変更および実施形態の任意の組み合わせは、本発明の範囲内に含まれる。
【背景技術】
【０００１】
オープン性および柔軟性を維持しながらパソコンや携帯電話などの電子機器を保護するため、Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐ（ＴＣＧ）は作られた。Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐは、全体的なセキュリティ解決策の重要な側面である規格策定に重点的に取り組んでおり、特に、ＩＳＯ／ＩＥＣ１１８８９としても公開されている「ＴＰＭ Ｍａｉｎ Ｐａｒｔ １ Ｄｅｓｉｇｎ Ｐｒｉｎｃｉｐａｌｓ， Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｖｅｒｓｉｏｎ １．２， Ｒｅｖｉｓｉｏｎ １０３」に記載されているようなトラステッドプラットフォームモジュール（ＴＰＭ）と呼ばれるハードウェアコンピュータチップに取り組んでいる。このトラステッドプラットフォームモジュールは、特に、暗号化による情報のセキュアな格納、セキュアな環境で実行される一連の暗号化処理、および、一連の完全性メトリクスを提供するハードウェア装置である。
【０００２】
このＴＰＭの特徴の１つは、コマンドの多くが認証を必要とすることである。この認証は、秘密を保持する必要があるただ１つの要因として定義され、この値を生成する一般的な方法は、この値を、ユーザが入力したパスワードのハッシュとすることである。
【０００３】
ＴＰＭの機能性については、Ｔａｌｈａ Ｔａｒｉｑによる論文「Ｅｘｔｅｎｄｉｎｇ Ｓｅｃｕｒｅ Ｅｘｅｃｕｔｉｏｎ Ｅｎｖｉｒｏｎｍｅｎｔｓ ｂｅｙｏｎｄ ｔｈｅ ＴＰＭ」などで、様々な改良案が提案されている。この論文では、上述したただ１つの認証値を、ユーザパスワード、ＴＰＭ状態、第三者証明機関などの複数の認証ルール要因を表す累積ハッシュ値で置き換える方法として、スマートカードと連動したフレキシブル認証が提案されている。このハッシュ値は、ＴＰＭとペアになったスマートカード内で生成されると述べられており、当業者であれば、別の形態において、このフレキシブル認証ルールの処理を、機能を強化したＴＰＭまたは信頼性のある処理環境内に移動させても構わないと分かるであろう。この処理環境は、信頼性のある処理領域内に実装されたソフトウェアＴＰＭを有するシステム内のＣＰＵによって提供される。
【０００４】
また、当業者であれば、これらのフレキシブル認証ルール要因を編集可能にする必要があると分かるであろう。認証データの署名に用いられるキーは変化する可能性がある。当然、ユーザパスワードは変わる方がよい。装置状態への依存度が変わるかもしれない。
【０００５】
既存のＴＰＭ仕様書には、キーの所有者がその認証値を変更できる、ＴＰＭ＿ＣｈａｎｇｅＡｕｔｈというＡＰＩが存在する。しかしながら、フレキシブル認証を用いると、多数の課題が生じる。例えば、ＴＰＭ＿ＣｈａｎｇｅＡｕｔｈでは、認証値を変更する前に、オブジェクトへのアクセス権限があるという証明が必要なので、第三者証明機関のキーが失われたり、無効になれば、そのオブジェクトへのアクセス権限を取得することができず、変更は決して許可されない。既存の仕様書には、認証をなくした場合の課題をどのように回避するのか何も記載されていない。さらに、ＴＰＭ＿ＣｈａｎｇｅＡｕｔｈがフレキシブル認証において動作した場合、認証ルールを全面的に変更する性能は、ＴＰＭ所有者側からすると好ましくないかもしれない。例えば、ＴＰＭ所有者とオブジェクト所有者とが共に、そのオブジェクトに関連付けられた認証ルール要因を有しているとすれば、フレキシブル認証値は、どの特定ルール要因が変更されたかという証拠がない曖昧なハッシュ値であるため、オブジェクト所有者は、ＴＰＭ所有者のルール要因を無意識または意図的に上書きすることができるであろう。Ｔａｒｉｑの論文には、これらの課題をどのように解決するかについて何も記載されていない。
【０００６】
Ｐｒｏｕｄｌｅｒによる米国特許出願公開第２０１０／１１５６２５号明細書には、外部の者がＴＰＭ操作および他のＴＰＭへのデータ移行をどのように認証できるのか説明する、ＴＰＭのさらなる強化について記載されている。しかしながら、クライアント装置が、それ自身のルールをどのように変更するのか、他のＴＰＭに移行する前にルールをどのように変更するのかについて何も記載されていない。
【０００７】
Ｓｃｈｎｅｃｋらによる米国特許第５９３３４９８号明細書では、サーバがルール一覧の原本を保持して、そのコピーを複数のクライアント装置に配信すると規定することによって、認証ルールを更新する課題に対処しようとしている。また、クライアント装置は、それら自身のルールを追加したルールをさらに配信することができるが、自身のルールをどのように変更するのか、他の装置へさらに配信する前にルールをどのように変更するのかについては何も記載されていない。また、個々のルールそれぞれは独立したものであるが、完成したルールが個々のルール全てを合わせた曖昧なものである場合をどのように扱うのか記載されていない。
【０００８】
Ｍｏｒｉｃｏｎｉらによる米国特許第７３６３６５０号明細書でも、ポリシーの変更のデルタリストをどのように保持するのか、そして、そのデルタをクライアント装置にどのように適用するのかを規定することによって、認証ルールを更新する課題に対処しようとしているが、クライアント装置が、それ自身のルールをどのように変更するのか、他の装置へさらに配信する前にルールをどのように変更するのかについては何も記載されていない。また、ここでも、個々のルールそれぞれは独立したものであるが、完成したルールが個々のルール全てを合わせた曖昧なものである場合をどのように扱うのか記載されていない。
【０００９】
Ｓａｒｍｅｎｔａらによる論文「Ｖｉｒｔｕａｌ Ｍｏｎｏｔｏｎｉｃ Ｃｏｕｎｔｅｒｓ ａｎｄ Ｃｏｕｎｔ−Ｌｉｍｉｔｅｄ Ｏｂｊｅｃｔｓ ｕｓｉｎｇ ａ ＴＰＭ ｗｉｔｈｏｕｔ ａ Ｔｒｕｓｔｅｄ ＯＳ」では、Ｍｅｒｋｌｅハッシュ木において情報をどのように表し、信頼性のある環境内で、どのように変化を木の葉に適用して木の根まで伝えるのかを規定することによって、累積ハッシュ値を更新する課題に対処している。しかしながら、特定の葉の変更をどのように認証するのかについては記載されておらず、その木内にある仮想単調カウンタ以外のデータをどのように表すのかも教示されていない。
【００１０】
また、信頼性のあるシステムでは、データの起源を監査できることが重要である。例えば、曖昧な値で表された複雑なルール内のルール要因を１つ変更する場合には、その変更、および、その変更のみが実際に行われたという証拠が必要である。したがって、フレキシブル認証ルール内のルール要因を表す１つの値に対する認証済み変更要求に基づき、フレキシブル認証ルールを表す曖昧な値を安全かつ確実に更新する方法が必要である。
【００１１】
ゆえに、フレキシブル認証ルールを表す合成ハッシュ内の個々のルール要因を表す要因を１つ更新する信頼できる更新を実装する方法、システム、およびコンピュータプログラム製品を本願では提案する。
【発明の概要】
【００１２】
大まかに言うと、本発明は、セキュアなコンピューティングの技術分野に関するものである。
【００１３】
本発明のある態様では、変化および変化のみが生じたことを確実に立証できるよう、複雑な認証ルールの中からルール要因を１つ、信頼性のある環境によって安全に変更可能とする技術を提供する。これにより、認証ルールの起源を保証できる。
【００１４】
本発明のその他の態様および効果は、本発明の原理を例として説明する図面とともに、以下の詳細な説明から明らかになるであろう。
【図面の簡単な説明】
【００１５】
後述の好ましい実施形態の詳細な説明を以下の図面と共に考察することで、本発明のよりよい理解が得られる。
【図１】図１は、ディスクリートチップとしてＴＰＭを実装した、先行技術に係るＴＰＭ ｖ１．２搭載システムである。
【図２】図２は、プロセッサから提示された信頼性のある実行環境内にＴＰＭを実装した、先行技術に係るＴＰＭ ｖ１．２搭載システムである。
【図３】図３は、図１の先行技術に基づいた、本発明に係る、フレキシブル認証に対応したシステムである。
【図４】図４は、図２の先行技術に基づいた、本発明に係る、フレキシブル認証に対応したシステムである。
【図５】図５は、本発明に係る、フレキシブル認証ルールの例である。
【図６】図６は、本発明に係る、フレキシブル認証ルールを算出するイベントフローの例である。
【図７】図７は、先行技術に係る、キーの構造体を示す。
【図８】図８は、本発明に係る、フレキシブル認証に対応したキーの構造体を示す。
【図９】図９は、本発明に係るルール要因修正許可チケットを示す。
【図１０Ａ】図１０Ａは、本発明に係る、スマートカードリーダを特徴としたｅＴＰＭ ｖ１．２搭載システムである。
【図１０Ｂ】図１０Ｂは、本発明に係る、ルール要因修正許可部のチケット発行方法を示す。
【図１１】図１１は、本発明に係る、ルール要因修正許可部のその他の好ましい実施形態を示す。
【図１２】図１２は、本発明に係る、ルール修正チケットを発行するフローチャートを示す。
【図１３】図１３は、本発明に係る、ルール要因修正許可チケットからルール修正チケットを生成するイベントフローを示す。
【図１４】図１４は、本発明に係る、ルール修正チケットを用いてキーを修正するイベントフローを示す。
【発明を実施するための形態】
【００１６】
以下に、本発明の好ましい実施形態を説明する。
【００１７】
図１は、ＴＰＭをディスクリートチップとして実装した、先行技術に係るＴＰＭ ｖ１．２搭載システムである。ＴＰＭ ｖ１．２搭載システム１００は、中央処理装置ＣＰＵ１０２と、Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐが定義したトラステッドプラットフォームモジュールＴＰＭ１０４を含む。次に、ＲＡＭ、ＲＯＭ、ハードディスクなどの一般的なハードウェアリソース１１６があり、ベーシック入出力システムＢＩＯＳ１０６がある。そして、その上位にはオペレーティングシステム１０８が存在する。ＴＰＭ１０４へのインターフェースとして、Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐが定義したトラステッドソフトウェアスタックＴＳＳ１１０がある。このシステム上では、ＴＰＭ１０４と情報のやり取りを行うＴＳＳ１１０を介して相互作用する、ＴＰＭを意識した１以上のアプリケーション１１２が実行されてもよい。また、ＴＳＳ１１０を使用しない他のアプリケーション１１４は、実行されてもされなくてもどちらでもよい。
【００１８】
図２は、プロセッサから提示された信頼性のある実行環境内にＴＰＭを実装した、先行技術に係るＴＰＭ ｖ１．２搭載システムである。ＴＰＭ ｖ１．２搭載システム２００は、ＡＲＭのＴｒｕｓｔＺｏｎｅといった信頼性のある実行環境に対応した中央処理装置ＣＰＵ２０２を含む。これにより、ＣＰＵは、左側が通常モードで右側がセキュアモードの、間に境界２０６が存在する、異なる２つのモードを確立することができる。この境界により、片方のモードで実行中の処理は、もう片方のモードの処理やメモリに直接アクセスすることができない。まず、セキュアモードはセキュアなハードウェアリソース２０８を提供する。このハードウェアリソースは、好ましい形態では、ＳｏＣ（システムオンチップ）ソリューションが提供するものである。次に、セキュアなベーシック入出力システムＢＩＯＳ２１０があり、その上位に、セキュアなオペレーションシステム２１２が存在する。このセキュアなＯＳ内では、セキュアなＯＳによって保護されているソフトウェア（ＳＷ）ＴＰＭ２０４が実行される。また、その他のセキュアなアプリケーション２１４は、実行されてもされなくてもどちらでもよい。好ましい形態において、セキュアモードはいずれのデバッグ機能も無効にする。これは、セキュアなＯＳ上で実行しているソフトウェアは、装置外部からの未認証アクセスから保護されていることを意味する。また、セキュアモード内の１以上のリソースを、通常モード内のリソースから動的にロードしてもかまわない。これらのリソースは、通常モードに格納されているときは暗号化され、セキュアモードにロードするときは復号化されることが好ましい。
【００１９】
通常モードは、図１のシステムと類似している。まず、ＲＡＭ、ＲＯＭ、ハードディスクなどの一般的なハードウェアリソース１１６があり、ベーシック入出力システムＢＩＯＳ１０６がある。そして、その上位にはオペレーティングシステム１０８が存在する。ＴＰＭ２０４へのインターフェースとして、Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐが定義したトラステッドソフトウェアスタックＴＳＳ１１０がある。このシステム上では、ＴＰＭ２０４と情報のやり取りを行うＴＳＳ１１０を介して相互作用する、ＴＰＭを意識した１以上のアプリケーション１１２が実行されてもよい。また、ＴＳＳ１１０を使用しない他のアプリケーション１１４は、実行されてもされなくてもどちらでもよい。
【００２０】
図３は、ｅＴＰＭであり、先頭の「ｅ」は拡張（ｆｏｒ ｅｘｔｅｎｄｅｄ）を表している。このｅＴＰＭは、本発明に係るフレキシブル認証に対応しており、図１の先行技術に基づく。ＴＰＭ１０４内には、長期間にわたるデータを記憶する不揮発性ＲＡＭ、ＮＶＲＡＭ３００と、短期間のデータを記憶する揮発性ＲＡＭ、ＶＲＡＭ３０２と、インクリメントされるだけで決してデクリメントされない特別なカウンタ値を記憶する単調カウンタ３０４と、ＰＣＲ３１２、プラットフォーム構成レジスタと、プラットフォームの構成情報を保持する特別なＶＲＡＭ記憶部とがある。次に、コアＴＰＭ機能３０８と、本発明に係る、追加されたフレキシブル認証ルール評価および管理機能３１０とが存在する。フレキシブル認証ルール評価および管理機能には、個々のルール要因それぞれの項を検証かつ評価する方法と、合成ハッシュ拡張部３２０を用いて、評価された項全てを累積した途中結果を保持して、個々のルール要因と今までの途中結果とを組み合わせる方法とが含まれる。好ましい形態では、拡張部３２０は、ＴＣＧによって説明されている合成ハッシュ拡張技術を利用する。さらに、フレキシブル認証ルール評価および管理機能３１０用の追加サポートコンポーネントが２つある。１つは、チケット発行部３２２であり、キーのフレキシブル認証ルールの修正をキーに許可するチケットを生成する。もう１つは、チケット検証部３２４であり、個々のフレキシブル認証ルール要因の変更を許可するチケットのフォーマットと署名を検証する。最後に、暗号化アルゴリズムＳＨＡ−１ ３１４、ＲＳＡ ３１６およびＨＭＡＣ ３１８がある。これらの暗号化アルゴリズムは、現在、ＴＰＭが必要とするものだけであるが、ＳＨＡ２５６、ＳＨＡ３８４およびＳＨＡ５１２またはＥＣＣなどの別のアルゴリズムを、本発明を逸脱することなく、代わりに用いてもかまわない。また、当業者であれば、ＲＯＭ３０６は、当該技術分野で周知の技術を用いて、権限を満たしている者により再プログラムされてもよいと分かるであろう。
【００２１】
図４は、ｅＴＰＭであり、先頭の「ｅ」は拡張（ｆｏｒ ｅｃｔｅｎｄｅｄ）を表している。このｅＴＰＭは、本発明に係るフレキシブル認証に対応しており、図２の先行技術に基づく。ＳＷ ＴＰＭ２０４内には、長期間にわたるデータを記憶する不揮発性ＲＡＭ、ＮＶＲＡＭ３００と、短期間のデータを記憶する揮発性ＲＡＭ、ＶＲＡＭ３０２と、インクリメントされるだけで決してデクリメントされない特別なカウンタ値を記憶する単調カウンタ３０４と、ＰＣＲ３１２、プラットフォーム構成レジスタと、プラットフォームの構成情報を保持する特別なＶＲＡＭ記憶部とがある。次に、コード記憶領域４００が存在し、コアＴＰＭ機能３０８と、本発明に係る、追加されたフレキシブル認証ルール評価および管理機能３１０とを実現するソフトウェアを記憶する。フレキシブル認証ルール評価および管理機能には、個々のルール要因それぞれの項を検証かつ評価する方法と、合成ハッシュ拡張部３２０を用いて、評価された項全てを累積した途中結果を保持して、個々のルール要因と今までの途中結果とを組み合わせる方法とが含まれる。好ましい形態では、拡張部３２０は、ＴＣＧによって説明されている合成ハッシュ拡張技術を利用する。さらに、フレキシブル認証ルール評価および管理機能３１０用の追加サポートコンポーネントが２つある。１つは、チケット発行部３２２であり、キーのフレキシブル認証ルールの修正をキーに許可するチケットを生成する。もう１つは、チケット検証部３２４であり、個々のフレキシブル認証ルール要因の変更を許可するチケットのフォーマットと署名を検証する。最後に、暗号化アルゴリズムＳＨＡ−１ ３１４、ＲＳＡ ３１６およびＨＭＡＣ ３１８がある。これらの暗号化アルゴリズムは、現在、ＴＰＭが必要とするものだけであるが、ＳＨＡ２５６、ＳＨＡ３８４およびＳＨＡ５１２またはＥＣＣなどの別のアルゴリズムを、本発明を逸脱することなく、代わりに用いてもかまわない。また、当業者であれば、コード記憶部４００は、ＲＯＭ内に置かれている場合や適切な技術を用いて外部の記憶部からコードをロードさせる場合など様々な方法で実現されてもよいと分かるであろう。
【００２２】
図５は、本発明に係る、フレキシブル認証ルールのデータ表示例である。フレキシブル認証ルール５００は、個々のルール要因それぞれが特定の値を有する、個々のルール要因５０４、５０８、５１２の木とみなすことができる。予想されたＰＣＲ状態は０ｘ３４…５６ ５０６、予想された署名付き状態は０ｘ５６…７８ ５１０、そして、予想されたＮＶ ＲＡＭは０ｘ７８…９Ａ ５１４である。好ましい形態では、予測された署名付き状態ルール要因５０８は、指紋読み取り部によって生成される。これらのルール要因に加え、ＩＤカードから取得した予測ＩＤや予測パスワードなど、他のルール要因を追加してもかまわない。
【００２３】
さらに、フレキシブル認証ルールそのものは０ｘ１２…３４ ５０２という値をもち、この値は個々のルール要因を全て組み合わせたものを表している。当該図面の矢印は、１番下のルール要因５１２を最初に算出してフレキシブル認証ルールの初期値、つまり、０ｘ００…０００内に拡張し、そして、第２のルール要因５０８を評価して今までの要因内に拡張し、そして、第３のルール要因５０４を評価して今までの結果内に拡張することを示している。そして、最終結果がフレキシブル認証ルール５００の値５０２となる。図８で後述するように、この最終値をＴＰＭキーと関連付けて、フレキシブル認証ルールを検証する必要があるとｅＴＰＭに知らせてからこの関連キーへのアクセスを許可してもよい。好ましい形態では、これらの値はＳＨＡ−１ハッシュを用いて算出される。しかしながら、当業者であれば、この代わりに他のハッシュアルゴリズムを利用してもかまわないと分かるであろう。ルール要因は、ＴＰＭ内の予測されたプラットフォーム構成レジスタ、つまり予測ＰＣＲ値５０４、または、第三者からの署名付き予測値５０８、または、ＮＶＲＡＭ内の予測値５１２を表してもよい。
【００２４】
図６は、本発明に係るフレキシブル認証ルールを算出するイベントフローの例を示したものである。ルールを算出するためには、３つの主要要素が必要である。まず、ルールを評価するアプリケーションからの要求を処理するＴＳＳ１１０、次に、ＴＰＭ内のフレキシブル認証ルール機能３１０、最後に、ＴＰＭ上のＶＲＡＭ３０２内に置かれているルールハッシュ値記憶部６００がある。単純化のため、ＴＳＳ１１０からフレキシブル認証ルール機能３１０へのＴＰＭインターフェースを介したコマンドルーチンは図示していない。このルールハッシュは、検証されたルール要因を全て累積した現在の合成ハッシュを記録するフレキシブル認証ルールセッションに対して可変なセッションである。まず最初に、ＴＳＳは、ＴＰＭＥｘ＿ＳｔａｒｔＲｕｌｅＳｅｓｓｉｏｎ ＡＰＩで新たなフレキシブル認証ルールセッションの開始を要求する６０２。これにより、ルールハッシュ値は０ｘ００…００ ６０６に初期化される６０４。次に、図５の木の１番下に位置する第１ルール要因は、Ｃｅｌｌ＿１というＮＶＲＡＭ ３００のメモリ位置の値が１０より小さいことの検証を要求するＴＰＭＥｘ＿ＲｕｌｅＴｅｓｔＮＶ ＡＰＩを呼び出す６０８ことによって実行される。ＴＰＭ内のフレキシブル認証ルール評価部３１０は、まず、Ｃｅｌｌ＿１に記憶された値が実際に１０より小さいことを検証し６１０、そして、１０より小さいとみなすと、ＴＰＭＥｘ＿ＲｕｌｅＴｅｓｔＮＶ ＡＰＩの引数のＳＨＡ−１ハッシュの値を求める６１２ことによってルール要因を代表する値を形成する。ＳＨＡ−１ハッシュは、この例では０ｘ７８…９Ａという値が示されており、図５の５１４に記載された予測値と一致している。そして、この値をルールハッシュ内に拡張する６１２。値をハッシュ内に拡張するという動作はＴＰＭ仕様書に記載されている処理であり、それによると、現在のハッシュと拡張する値とを連結したハッシュを算出し、そして、その結果を新たなハッシュとして用いることにより、ハッシュを更新する。図示するために、拡張後の新たなルールハッシュは０ｘＦＥ…ＤＣ ６１６となる。
【００２５】
次に、図５の木の真ん中に位置する第２ルール要因は、１つの特定データに有効な署名が添付されていることの検証を要求するＴＰＭＥｘ＿ＲｕｌｅＴｅｓｔＳｉｇｎ ＡＰＩを呼び出す６１８ことによって実行される。ＴＰＭ内のフレキシブル認証ルール評価部は、まず、データが実際に正しく署名されていることを検証し６２０、そして、正しく署名されているとみなすと、ＴＰＭＥｘ＿ＲｕｌｅＴｅｓｔＳｉｇｎ ＡＰＩの引数のＳＨＡ−１ハッシュの値を求める６２２ことによってルール要因を代表する値を形成する。ＳＨＡ−１ハッシュは、この例では０ｘ５６…７８という値が示されており、図５の５１０に記載された予測値と一致している。そして、この値をルールハッシュ内に拡張する６２４。図示するために、拡張後の新たなルールハッシュは０ｘＤＣ…ＢＡ ６２６となる。
【００２６】
次に、図５の木の一番上に位置する第３ルール要因は、ＰＣＲ値の現在のサブセットと渡された値とが一致することの検証を要求するＴＰＭＥｘ＿ＲｕｌｅＴｅｓｔＰＣＲ ＡＰＩを呼び出す６２８ことによって実行される。ＴＰＭ内フレキシブル認証ルール評価部は、まず、現在のＰＣＲ値と渡された値とが実際に等しいことを検証し６３０、そして、等しいとみなすと、ＴＰＭＥｘ＿ＲｕｌｅＴｅｓｔＰＣＲ ＡＰＩの引数のＳＨＡ−１ハッシュの値を求める６３２ことによってルール要因を代表する値を形成する。ＳＨＡ−１ハッシュは、この例では０ｘ３４…５６という値が示されており、図５の５０６に記載された予測値と一致している。そして、この値をルールハッシュ内に拡張する６３４。図示するために、拡張後の新たなルールハッシュは０ｘ１２…３４ ６３６となる。図５のフレキシブル認証ルール５００を確認すると、そこも０ｘ１２…３４ ５０２となっている。したがって、フレキシブル認証ルールをこの値に設定したオブジェクトであればＴＰＭ内ですぐ利用してもかまわない。
【００２７】
図７は、ＴＰＭ仕様書に記載されている先行技術に係るキーの構造体を示す。ＴＰＭキー構造体７００には多くのフィールドがある。まず、１．１．０．０．の値をもつバージョン番号ラベルｖｅｒ ７０２があり、その次は、キーをどのように利用できるかを示す値、ｋｅｙＵｓａｇｅ ７０４がある。ｋｅｙＦｌａｇｓ ７０６は、キーごとに設定可能な制御選択肢を示し、ａｕｔｈＵｓａｇｅＤａｔａ ７０８は、キーに対する認証データをどのように用いるかを示す。ａｌｇｏｒｉｔｈｍＰａｒｍｓ ７１０は、このキーで、どの暗号化アルゴリズムとどの署名アルゴリズムを利用できるかを示す構造であり、ｐｃｒＩｎｆｏＳｉｚｅ ７１２とｐｃｒＩｎｆｏ ７１４は共に、キーの利用前になければならないＰＣＲ値セットを定義している。ｐｕｂＫｅｙ ７１６はキーの公開部分を保持している。最後に、ｅｎｃＤａｔａＳｉｚｅ ７１８とｅｎｃＤａｔａ ７２０は共に、キーの秘密部分を表している。
【００２８】
図８は、本発明に係る、フレキシブル認証に対応したキーの構造体を示している。ＴＰＭフレキシブル認証キー構造体８００には多くのフィールドがあり、それらの大部分は図７で示したものと同じである。まず、１．３．０．０．の値をもつバージョン番号ラベルｖｅｒ ７０２がある。なお、キーの構造体が先行技術で説明されたものと異なるたびに、バージョン番号はインクリメントされてきている。その次は、キーをどのように利用できるかを示す値、ｋｅｙＵｓａｇｅ ７０４である。ｋｅｙＦｌａｇｓ ７０６は、キーごとに設定可能な制御選択肢を示し、ａｕｔｈＵｓａｇｅＤａｔａ ７０８は、キーに対する認証データをどのように用いるかを示す。ここには、ｆａＲｕｌｅＤａｔａ ８０２を用いるかどうかを示す追加フラグと、ｆａＲｕｌｅＤａｔａ ８０２を修正できるかどうかを示す他の追加フラグとがある。その次に、ａｌｇｏｒｉｔｈｍＰａｒｍｓ ７１０は、このキーで、どの暗号化アルゴリズムとどの署名アルゴリズムが利用可能なのかを示す構造であり、ｐｃｒＩｎｆｏＳｉｚｅ ７１２とｐｃｒＩｎｆｏ ７１４は共に、キーの利用前になければならないＰＣＲ値セットを定義している。ｆａＲｕｌｅＤａｔａ ８０２は、キーの利用前になければならないフレキシブル認証ルールハッシュを定義している。ｐｕｂＫｅｙ ７１６はキーの公開部分を保持している。最後に、ｅｎｃＤａｔａＳｉｚｅ ７１８とｅｎｃＤａｔａ ７２０は共に、キーの秘密部分を表している。
【００２９】
ＴＰＭフレキシブル認証キー構造体８００をＴＰＭにロードするためには、まず、図６と類似のイベントシーケンスを実行してＴＰＭに記憶されたルールハッシュ６００を生成しなければならない。次に、ＴＰＭを意識したアプリケーション１１２からの命令でＴＳＳ１１０は、既存のＴＰＭ＿ＬｏａｄＫｅｙ２ ＡＰＩを呼び出す。先行技術に係るこのコマンドの動作はＴＰＭ仕様書において詳述されている。さらに、ｆａＲｕｌｅＤａｔａ ８０２をチェックする必要があると示すフラグセットがａｕｔｈＵｓａｇｅＤａｔａ ７０８にある場合、渡されたキーのｆａＲｕｌｅＤａｔａ ８０２とルールハッシュ６００に記憶されている値とをＴＰＭは比較し、一致しなければ、キーをロードできないことを示す適切なエラーコードをＴＰＭ＿ＬｏａｄＫｅｙ２ ＡＰＩは返さなければならない。
【００３０】
上記にて、フレキシブル認証ルールを有するキーはどのように定義かつロードされるのかを詳述した。次に、フレキシブル認証ルールを変更する方法について詳述する。
【００３１】
図９は、本発明に係るルール要因修正許可チケットを示す。フレキシブル認証ルール内の要因を１つ修正するためには、修正されていないルール要因と、修正されたルール要因と、修正するためのキーハンドルと、変更するルール要因のタイプを表すＩＤとを含んだ要求にルール要因修正許可部が署名して、ＴＰＭルール要因修正チケット９００を生成しなければならない。この構造体のフィールドは以下のとおりである。まず、ＳＨＡ−１ハッシュは、置き換えの必要があるフレキシブル認証内の古いルール要因９０２を表している。この要因は、図５の５０６、５１０、または５１４に対応する。次に、別のＳＨＡ−１は、古い要因９０２を置き替えることになるフレキシブル認証内の新たなルール要因９０４を表している。そして、置き替え対象の要因タイプ９０６を表すＩＤと、図８で示したようなＴＰＭ要因認証キー構造体９０８と、今までのフィールドの暗号化ダイジェスト９１０と、そのダイジェストに署名した署名キー９１２とがある。好ましい形態では、この署名キーには、このような種類のチケットへの署名が許可された署名キーであることを示すＴＰＭ＿ＫＥＹ＿ＦＡＣＨＡＮＧＥの値に設定されたｋｅｙＵｓａｇｅフィールド７０４がある。後述するように、古いルール要因９０２とＴＰＭ要因認証キー９０８の両方またはどちらか一方は、チケットを利用する場合、古いルール要因９０２とＴＰＭ要因認証キー９０８の両方またはどちらか一方に制限がないことを示すＮＵＬＬでもかまわない。
【００３２】
図１０Ａは、ＴＰＭをディスクリートチップとして実装し、かつ、ルール要因修正許可部がスマートカード上に常駐している、本発明に係るｅＴＰＭ搭載システムを示している。このｅＴＰＭ搭載システム１００は、中央処理装置ＣＰＵ１０２と、Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐが定義したトラステッドプラットフォームモジュールＴＰＭ１０４を含む。次に、ＲＡＭ、ＲＯＭ、ハードディスクなどの一般的なハードウェアリソース１１６があり、ベーシック入出力システムＢＩＯＳ１０６がある。そして、その上位にはオペレーティングシステム１０８が存在する。ＴＰＭ１０４へのインターフェースとして、Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐが定義したトラステッドソフトウェアスタックＴＳＳ１１０がある。このシステム上では、ＴＰＭ１０４と情報のやり取りを行うＴＳＳ１１０を介して相互作用する、ＴＰＭを意識した１以上のアプリケーション１１２が実行されてもよい。また、ＴＳＳ１１０を使用しない他のアプリケーション１１４は、実行されてもされなくてもどちらでもよい。さらに、ＵＳＢなどのインターフェースや当該技術分野において周知の他の接続方法を介してシステム１００に取り付けられたスマートカードリーダ１００４がある。スマートカードリーダ１００４内にはスマートカード１００２があり、そのスマートカード１００２上にはルール要因修正許可アプリケーション１０００がある。好ましい形態において、スマートカード１００２およびルール要因修正許可アプリケーション１０００は、ＯｒａｃｌｅのＪａｖａ Ｃａｒｄ ３．０仕様書で定義されている規格に準拠している。当業者であれば、ルール要因修正許可アプリケーション１０００を、様々な技術を介して実装しても、リモートサーバ上に実装しても、システムが対応しているのであれば、システム１００上の信頼性のある実行環境内に実装してもかまわないと分かるであろう。
【００３３】
図１０Ｂは、本発明に係るルール要因修正許可部のチケット発行方法を示す。ルール要因修正許可チケットを生成するためには、３つの要素がやりとりする必要がある。まず、ＴＳＳ１１０はルール要因修正許可部１０００に対して要求を行い、そして、ルール要因修正許可部はＴＰＭ１０４を用いてその許可権に署名をする。好ましい形態において、ルール要因修正許可部１０００は、システム１００に接続されたスマートカード１００２上に置かれている。まず、ＴＳＳ１１０は、ルール要因を更新したいキーとそのルール要因の現在の値を検索する１０５２。好ましい形態では、キーごとに個々のルール要因を表すキーに関連した一覧が存在する。その他の好ましい形態では、ＴＳＳ１１０を呼び出すＴＰＭを意識したアプリケーション１１２が、事前に算出したルール要因を引数として渡す。次に、ＴＳＳは新たなルール要因を算出する１０５４。この値はＴＳＳ自身によって算出されてもよい。あるいは、その他の好ましい形態では、ＴＳＳ１１０を呼び出すＴＰＭを意識したアプリケーション１１２が、事前に算出した新たなルール要因を引数として渡す。ここで、古いルール要因と新しいルール要因とルール要因タイプと対象キーとが準備されると、ＴＳＳ１１０は、ルール要因修正許可部に変更の承認を要求する１０５６。まず、ルール要因修正許可部１０００は、ｋｅｙＵｓａｇｅ ７０４フィールドが適切な値だと確認することによって、渡されたキーによりそのフレキシブル認証ルールを変更できることを検証し１０５８、そして、そのルール要因タイプが変更許可されたものであることを確認する１０６０。例えば、ローカルのルール要因修正許可部は、ＮＶＲＡＭチェック要因の変更用チケットを発行許可するだけでもよいが、リモートルール要因修正許可部は、どんな要因タイプも変更できるチケットを発行してもよい。次に、さらなる確認が行われる１０６２。好ましい形態では、署名キーのみがローカルのルール要因修正許可部によって変更されてもかまわない。これらの確認が全て成功すれば、ルール要因修正許可部１０００は、その修正許可キーをＴＰＭ１０４にロードする１０６４。なお、このローディングそのものが、図６のように適用されるフレキシブル認証ルールを要求してもかまわない。キーが成功裏にロードされれば、ルール要因修正許可部は、チケット構造体を作成し１０６６、その構造体の署名付きダイジェストを生成するようＴＰＭに要求する１０６８。そして、さらなる処理のため、ＴＳＳにチケットを返す１０７０。
【００３４】
図１１は、本発明に係る、ルール要因修正許可部のその他の好ましい実施形態を示す。図１０Ｂと同様に、ルール要因修正許可チケットを生成するためには、３つの要素がやりとりする必要がある。まず、ＴＳＳ１１０はルール要因修正許可部１０００に対して要求を行い、そして、ルール要因修正許可部はＴＰＭ１０４を用いてその許可権に署名をする。好ましい形態において、ルール要因修正許可部１０００は、システム１００に接続されたスマートカード１００２上に置かれている。まず、ＴＳＳ１１０は、ルール要因を更新したいキーと、変更を要求したいルール要因の現在のパラメータおよび新しいパラメータとを検索する１１０２。好ましい形態では、キーごとに個々のルール要因を表すキーと関連付けた一覧が存在する。その他の好ましい形態では、ＴＳＳ１１０を呼び出すＴＰＭを意識したアプリケーション１１２が、ルール要因パラメータを引数として渡す。次に、ＴＳＳ１１０は、１１０２で検索された古いルール要因パラメータと新しいルール要因パラメータとを渡すことによって、ルール要因修正許可部に変更の承認を要求する１１０４。この図では、修正対象のルール要因は図５のルール要因５０８なので、古いデータと新しいデータと署名に用いられたキーとが渡される。まず、ルール要因修正許可部１０００は、渡されたパラメータに基づいて、古いルール要因と新しいルール要因とを算出する１１０６。図１０Ｂと同様、ルール要因修正許可部１０００は、次に、ｋｅｙＵｓａｇｅ ７０４フィールドが適切な値だと確認することによって、渡されたキーによりそのフレキシブル認証ルールを変更できることを検証し１１０８、そして、そのルール要因タイプが変更許可されたものであることを確認する１１１０。例えば、ローカルのルール要因修正許可部は、ＮＶＲＡＭチェック要因の変更用チケットを発行許可するだけでもよいが、リモートルール要因修正許可部は、どんな要因タイプも変更できるチケットを発行してもよい。次に、さらなる確認が行われる１１１２。図１０Ｂのステップ１０６２と比較すると、古いルール要因および新しいルール要因のハッシュ値ではなくそれらの個々の要素が渡されるので、さらなる確認１１１２はより詳細なものとなる。例えば、古いキーＡを検証してそれが無効になったことを確認してもよいし、新たなキーＢを検証してそれが無効になっていないことを確認してもよい。または、メッセージＡおよびメッセージＢを検証してそれらが同じであり、単に修正中のキーであることを確認してもよい。キーＡおよびキーＢは、署名を検証するルール要因修正許可部１０００によって利用されるだけなので、好ましい実施形態では、これらのキーをＸ．５０９証明書で表す。その他の好ましい実施形態では、これらのキーはＴＰＭ内に置かれる。これらの確認が全て成功すれば、ルール要因修正許可部１０００は、その修正許可キーをＴＰＭ１０４にロードする１１１４。なお、このローディングそのものが、図６のように適用されるフレキシブル認証ルールを要求してもかまわない。キーが成功裏にロードされれば、ルール要因修正許可部は、チケット構造体を作成し１１１６、その構造体の署名付きダイジェストを生成するようＴＰＭに要求する１１１８。そして、さらなる処理のため、ＴＳＳにチケットを返す１１２０。
【００３５】
図１２は、本発明に係るルール修正チケットを示す。完成したフレキシブル認証ルールに対する修正を認証するためには、ＴＰＭルール要因修正チケット９００がキーの変更を許可されていることは検証済みであると明言できるチケットをＴＰＭは発行しなければならない。このルール修正チケットの構造体１２００におけるフィールドは以下のとおりである。まず、ＳＨＡ−１ハッシュは、置き換えの必要がある、古いフレキシブル認証ルール値１２０２を含んでいる。この要因は、図５の５０２に対応する。次に、別のＳＨＡ−１は、古いルール値１２０２を置き替えることになる新しいフレキシブル認証ルール値１２０４を含んでいる。そして、１２０２の値から１２０４の値に変更されたフレキシブル認証ルール値をもつことになる図８で示したようなＴＰＭ要因認証キー構造体１２０６と、最後に、その構造体の上記フィールドのＨＭＡＣダイジェスト１２０８がある。このＨＭＡＣは、ＴＰＭが定義したＴＰＭ＿ＰＥＲＭＡＮＥＮＴ＿ＤＡＴＡ中のｔｐｍＰｒｏｏｆ値など、適切な秘密キーを用いてＲＦＣ２１０４に従い算出される。
【００３６】
図１３は、本発明に係る、ルール要因修正許可チケットからルール修正チケットを生成するイベントフローを示す。ルールを検証するためには、３つの主要要素が必要である。まず、ルールを検証するアプリケーションからの要求を処理するＴＳＳ１１０、次に、ＴＰＭ内のフレキシブル認証（ＦＡ）ルール機能３１０、最後に、ＴＰＭ上のＶＲＡＭ３０２内に置かれているルールハッシュのペア値記憶部１３００がある。このイベントシーケンスは、図６で示したようなフレキシブル認証ルールを算出するものと類似している。しかしながら、１つのルールハッシュ６００ではなく、このチケットを生成する場合には、古いルールハッシュと新しいルールハッシュの両方を算出するため、ルールハッシュのペア１３００が必要となる。まず、ＴＰＭＥｘ＿ＳｔａｒｔＲｕｌｅＶｅｒｉｆｉｃａｔｉｏｎＳｅｓｓｉｏｎ ＡＰＩを呼び出して１３０２、両方のルールハッシュを０ｘ００…００の値１３０６に初期化する１３０４。次に、図５に示したようなルール要因の並びを適用する。図６ではハッシュ内に拡張する前に各ルール要因を検証しているが、ここでキーポイントとなる違いは、ルール要因を検証しないということである。ＴＰＭＥｘ＿ＲｕｌｅＶｅｒｉｆｙＮＶ ＡＰＩを呼び出し１３０８、規定のＮＶＲＡＭ位置を調べることなく、フレキシブル認証（ＦＡ）ルール評価部３１０は、ＴＰＭＥｘ＿ＲｕｌｅＶｅｒｉｆｙＮＶ ＡＰＩの引数のＳＨＡ−１ハッシュの値を求める１３１０ことによってルール要因を代表する値を形成する。ＳＨＡ−１ハッシュは、この例では０ｘ７８…９Ａという値が示されており、図５の５１４に記載された予測値と一致している。そして、この値をルールハッシュペアの両方に拡張する１３１２。値をハッシュ内に拡張するという動作はＴＰＭ仕様書に記載されている処理であり、それによると、現在のハッシュと拡張する値とを連結したハッシュを算出し、そして、その結果を新たなハッシュとして用いることにより、ハッシュを更新する。図示するために、拡張後の新たなルールハッシュペアは０ｘＦＥ…ＤＣ ６１６となる。
【００３７】
次に、図５の木の真ん中に位置する第２ルール要因は、ＴＰＭＥｘ＿ＲｕｌｅＶｅｒｉｆｙＳｉｇｎ ＡＰＩを呼び出す１３１６ことによって実行される。これは、図１０Ａに従ってルール要因修正許可チケットを発行させたルール要因なので、このチケットは、フレキシブル認証（ＦＡ）ルール評価部３１０にも渡される。この評価部は、まず、ルール要因修正許可チケットが正しく署名されていることと、ｆａｃｔｏｒＩＤが現在のルール要因タイプ用を示していることを検証し１３１８、そして、引数のＳＨＡ−１ハッシュの値を求める１３２０。このＳＨＡ−１ハッシュは、この例では０ｘ５６…７８という値が示されており、図５の５１０に記載された予測値と一致している。次に、この算出したハッシュを、ルール要因修正許可チケットのｏｌｄＦａｃｔｏｒフィールドに格納されているハッシュと比較する１３２２。等しければ、チケットはこの項を修正するのに有効なチケットであるため、このチケットのｏｌｄＦａｃｔｏｒ９０２とｎｅｗＦａｃｔｏｒ９０４をそれぞれ、ルールハッシュペア内の各フィールドへ拡張する１３２４。図示するために、拡張後の新たなルールハッシュペアは０ｘＤＣ…ＢＡ（古い値）および０ｘＣＤ…ＢＡ（新しい値）１３２６となる。なお、もし、ルール要因修正許可チケットのｏｌｄＦａｃｔｏｒの値９０２がＮＵＬＬであれば、１３２２における古い値の検証は省略され、ｆａｃｔｏｒＩＤ９０６がＮＵＬＬであれば、１３１８におけるＩＤの検証は省略される。
【００３８】
次に、図５の木の一番上に位置する第３ルール要因は、ＴＰＭＥｘ＿ＲｕｌｅＶｅｒｉｆｙＰＣＲ ＡＰＩを呼び出し１３２８、規定のＰＣＲを調べることなく、フレキシブル認証（ＦＡ）ルール評価部３１０は、ＴＰＭＥｘ＿ＲｕｌｅＶｅｒｉｆｙＰＣＲ ＡＰＩの引数のＳＨＡ−１ハッシュの値を求めることによってルール要因を代表する値を形成する。ＳＨＡ−１ハッシュは、この例では０ｘ３４…５６という値が示されており、図５の５０６に記載された予測値と一致している。そして、この値をルールハッシュのペア内に拡張する１３３２。図示するために、拡張後のルールハッシュペアは０ｘ１２…３４の古いハッシュ値と０ｘ２１…４３の新しいハッシュ値１３３４になる。
【００３９】
この時点で、古いフレキシブル認証ルール値と新しいフレキシブル認証ルール値とが算出されたので、ここで初めて、クライアントＴＳＳは、ＴＰＭＥｘ＿ＲｅｑｕｅｓｔＲｕｌｅＭｏｄｉｆｉｃａｔｉｏｎＴｉｃｋｅｔ ＡＰＩを用い、かつ、チケットを作成するキーとルール要因修正許可チケットとを渡すことによって、ルール修正チケットの作成を要求できる１３３６。渡されたキーのｆａＲｕｌｅＤａｔａフィールド８０２がルールハッシュペア１３００の古い値と等しければ、ルール要因修正許可チケットは正しく署名されており、ルール要因修正許可チケットのｋｅｙフィールド９０８が渡されたキーと等しければ１３３８、ルール修正チケットは発行され１３４０、ＴＳＳ１１０にそのチケットを返す。
【００４０】
図１４は、本発明に係る、ルール修正チケットを用いてキーを修正するイベントフローを示す。修正を実行するためには、２つの主要要素が必要である。まず、キーを修正するアプリケーションからの要求を処理するＴＳＳ１１０、そして、構造体への実際の変更を処理するＴＰＭ内のフレキシブル認証（ＦＡ）ルール機能３１０がある。ＴＰＭ内のキーはそれらの親キーによって暗号化されているため、まず最初に、親キーを用いてＯＳＡＰセッションを確立し１４００、対象である子キーのデータを復号する権限を取得する必要がある。ＴＰＭコア３０８内に実装されている先行技術に従ってセッションが確立された時点で、データの実際の変更を行うことが可能になる。ＴＳＳは、対象キーと、ＯＳＡＰセッションハンドルと、図１３に示すように生成されたルール修正チケットとを渡すことによって、フレキシブル認証を変更する要求を行う１４０２。まず、フレキシブル認証（ＦＡ）ルール評価部は、先行技術で説明されているように、ＯＳＡＰセッションを検証する１４０４。そして、キー構造体のフォーマット１４０６およびルール修正チケットの署名１４０８を検証し、ルール修正チケットのｋｅｙフィールド１２０６と渡されたキー８００との一致をバイトごとに比較して確認し、ｏｌｄＦＡＲｕｌｅ１２０４がキーのｆａＲｕｌｅＤａｔａ８０２と等しいことを確認することにより、渡されたキーに対してこのルール修正チケットが有効なこと１４１０を検証する。これらの２つが一致すれば、ｅｎｃＤａｔａ７２０内に格納されている秘密キーデータを親キーで復号し１４１０、その結果得られた構造体を検証して、この構造体が、先行技術で説明されているような、有効なＴＰＭ＿ＳＴＯＲＥ＿ＡＳＹＭＫＥＹまたはＴＰＭ＿ＭＩＧＲＡＴＥ＿ＡＳＹＭＫＥＹであることを保証する。渡されたキー内のｆａＲｕｌｅＤａｔａ８０２をルール修正チケット１２０８のｎｅｗＦＡＲｕｌｅフィールド１２０４に設定する１４１４。そして、復号されたｅｎｃＤａｔａ ７２０のｐｕｂＤａｔａＤｉｇｅｓｔ内に格納されているハッシュ値を再計算して、フレキシブル認証ルールの変更を反映する。最後に、ｅｎｃＤａｔａ ７２０を親キーで再び暗号化し１４１８、処理が成功したことを呼び出し側に返す１４２０。
【００４１】
キーを移動するたびにキーのポリシーの変更がキーに許可されるキー移動に対して、当業者であれば、図１４の技術をＴＰＭ仕様書内に記載されている技術と組み合わせてもかまわないと分かるであろう。
【００４２】
本発明は上記の実施形態に基づいて述べられているが、本発明は明らかにそのような実施形態に限定されるものではない。下記のケースもまた本発明に含まれる。
【００４３】
（１）上記の各装置は、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ、ハードディスクユニット、ディスプレイユニット、キーボード、マウスなどから構成されるコンピュータシステムである。ＲＡＭまたはハードディスクユニットには、コンピュータプログラムが記憶されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、各装置は、その機能を達成する。ここでコンピュータプログラムは、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。
【００４４】
（２）上記の各装置を構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどを含んで構成されるコンピュータシステムである。ＲＡＭには、コンピュータプログラムが記憶されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、システムＬＳＩは、その機能を達成する。
【００４５】
さらに、各装置を構成する構成部品の各ユニットは、別個の個別チップとして、または、一部もしくは全てを含む単一のチップとして作られてもよい。
【００４６】
さらに、ここでは、ＬＳＩが述べられているが、集積化の程度の違いにより、指定ＩＣ、ＬＳＩ、スーパＬＳＩ、ウルトラＬＳＩが使用される場合もある。
【００４７】
さらに、回路の集積化の手段は、ＬＳＩに限定されるものではなく、専用回路、もしくは汎用プロセッサによる実装も利用できる。さらに、ＬＳＩが製造された後にプログラム可能なフィールドプログラムゲートアレイ（ＦＰＧＡ）を使用することもまた可能であり、またＬＳＩ内で回路セルの接続および設定を再構成可能なリコンフィギュアラブルプロセッサも使用可能である。
【００４８】
さらに、もしＬＳＩに置き換わる集積回路技術が半導体技術もしくは他の派生する技術の進歩を通じて現われるのであれば、その技術は当然に構成要素の集積化を実現するために使用することができる。バイオ技術の適用が予想される。
【００４９】
（３）上記の各装置を構成する構成要素の一部または全部は、各装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしてもよい。ＩＣカードまたはモジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどから構成されるコンピュータシステムである。ＩＣカードまたはモジュールは、上記の超多機能ＬＳＩに含まれるとしてもよい。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、ＩＣカードまたはモジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。
【００５０】
（４）本発明は、上記に示す方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、コンピュータプログラムなどのデジタル信号であるとしてもよい。
【００５１】
また、本発明は、コンピュータプログラムまたはデジタル信号をコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＢＤ（Ｂｌｕ−ｒａｙ Ｄｉｓｃ）、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されているデジタル信号であるとしてもよい。
【００５２】
また、本発明は、コンピュータプログラムまたはデジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。
【００５３】
また、本発明は、マイクロプロセッサとメモリを備えたコンピュータシステムであって、メモリは、上記コンピュータプログラムを記憶しており、マイクロプロセッサは、コンピュータプログラムにしたがって動作するとしてもよい。
【００５４】
また、プログラムまたはデジタル信号を記録媒体に記録して移送することにより、またはプログラムまたはデジタル信号を、ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。
【００５５】
（５）本技術分野の当業者にとっては、説明した実施形態の、本発明固有の教示および利点から原理的に離れることのない多くの変形がありえることを容易に理解することができるだろう。また、上記変更および実施形態の任意の組み合わせは、本発明の範囲内に含まれる。
【特許請求の範囲】
【請求項１】
耐タンパ性のセキュリティＬＳＩを備える情報処理装置であって、
前記ＬＳＩは、
前記ＬＳＩのリブート後でも利用できる必要があるデータを記憶する不揮発性メモリ領域と、
前記ＬＳＩの１ブートサイクル中にのみ必要なデータを記憶する揮発性メモリ領域と、
インクリメントのみ可能な複数の不揮発性カウンタを記憶する単調カウンタ領域と、
プラットフォーム状態に関する蓄積情報を記憶するプラットフォーム構成レジスタ（ＰＣＲ）領域と、
複数の暗号化キーを生成し、データを暗号化し、データを復号し、複数の暗号化署名を生成し、複数の暗号化署名を検証する暗号化部と、
前記ＬＳＩの外部に情報を送信し、前記ＬＳＩの外部から情報を受信する外部インターフェースと、
第１暗号化ハッシュを記憶する前記揮発性メモリ領域内の第１記憶領域と、
第２暗号化ハッシュを記憶する前記揮発性メモリ領域内の第２記憶領域と、
前記外部インターフェースを介して受信したオブジェクトの代表値と、前記第１暗号化ハッシュと、前記第２暗号化ハッシュと、前記代表値および２つの暗号化ハッシュの暗号化ダイジェストとを含んだ、受信した前記オブジェクトに含まれているルールを修正するためのオブジェクトルール修正チケットを発行するオブジェクトルール修正チケット発行部と、
受信した前記オブジェクトが、前記第１記憶領域に記憶されている第１暗号化ハッシュと等しい暗号化ハッシュを含んでいる場合にのみ、前記チケット発行部を有効にするオブジェクトルール修正チケット発行制御部と
を備える情報処理装置。
【請求項２】
前記ＬＳＩは、さらに、
第１の値で前記第１記憶領域を拡張し、第２の値で前記第２記憶領域を拡張する暗号化ハッシュ拡張部と、
前記外部インターフェースを介して受信したデータを代表する値を前記第１記憶領域内と前記第２記憶領域内とに拡張するよう前記暗号化ハッシュ拡張部に要求することによってルール要因を適用する第１ルール要因適用部と、
前記外部インターフェースを介して受信したデータを代表する第１の値を前記第１記憶領域内に拡張し、かつ、前記外部インターフェースを介して受信したルール要因修正チケットに記載されている第２の値を前記第２記憶領域内に拡張するよう前記暗号化ハッシュ拡張部に要求することによって２つのルール要因を適用する第２ルール要因適用部とを備え、
前記ルール要因修正チケットは、前記第２記憶領域内に拡張する置換用の第２の値と、前記ルール要因修正チケット内のデータの暗号化ダイジェストとを含む、
請求項１記載の情報処理装置。
【請求項３】
前記ルール要因修正チケットは、さらに、
予測された第１の値を含み、
前記第２ルール要因適用部は、さらに、前記予測された第１の値が、前記外部インターフェースを介して受信したデータを代表する前記第１の値と一致することを確認し、
一致しない場合には、前記第１の値を拡張するという前記暗号化ハッシュ拡張部への要求を行わない
請求項２記載の情報処理装置。
【請求項４】
前記ルール要因修正チケットは、さらに、
前記オブジェクトの予測代表値を含み、
前記第２ルール要因適用部は、さらに、前記オブジェクトの予測代表値が、前記外部インターフェースを介して受信したオブジェクトの代表値と一致することを確認し、
一致しない場合には、前記第１の値を拡張するという前記暗号化ハッシュ拡張部への要求を行わない
請求項２記載の情報処理装置。
【請求項５】
前記ルール要因修正チケットは、さらに、
予測されたルール要因タイプを含み、
前記第２ルール要因適用部は、さらに、前記予測されたルール要因タイプが、前記外部インターフェースを介して受信したルール要因タイプと一致することを確認し、
一致しない場合には、前記第１の値を拡張するという前記暗号化ハッシュ拡張部への要求を行わない
請求項２記載の情報処理装置。
【請求項６】
耐タンパ性のセキュアなアプリケーション実行環境を有したＣＰＵを備える情報処理装置であって、
前記セキュアなアプリケーション実行環境は、
前記セキュアなアプリケーション実行環境内のアプリケーションにサービスを提供するセキュアなオペレーティングシステムと、
前記ＣＰＵのリブート後でも利用できる必要があるデータを記憶する不揮発性メモリ領域と、
前記ＣＰＵの１ブートサイクル中にのみ必要なデータを記憶する揮発性メモリ領域と、
インクリメントのみ可能な複数の不揮発性カウンタを記憶する単調カウンタ領域と、
プラットフォーム状態に関する蓄積情報を記憶するプラットフォーム構成レジスタ（ＰＣＲ）領域と、
複数の暗号化キーを生成し、データを暗号化し、データを復号し、複数の暗号化署名を生成し、複数の暗号化署名を検証する暗号化部と、
前記セキュアなアプリケーション実行環境の外部に情報を送信し、前記セキュアなアプリケーション実行環境の外部から情報を受信する外部インターフェースと、
第１暗号化ハッシュを記憶する前記揮発性メモリ領域内の第１記憶領域と、
第２暗号化ハッシュを記憶する前記揮発性メモリ領域内の第２記憶領域と、
前記外部インターフェースを介して受信したオブジェクトの代表値と、前記第１暗号化ハッシュと、前記第２暗号化ハッシュと、前記代表値および２つの暗号化ハッシュの暗号化ダイジェストとを含んだ、受信した前記オブジェクトに含まれているルールを修正するためのオブジェクトルール修正チケットを発行するオブジェクトルール修正チケット発行部と、
受信した前記オブジェクトが、前記第１記憶領域に記憶されている第１暗号化ハッシュと等しい暗号化ハッシュを含んでいる場合にのみ、前記チケット発行部を有効にするオブジェクトルール修正チケット発行制御部と
を備える情報処理装置。
【請求項７】
前記セキュアなアプリケーション実行環境は、さらに、
第１の値で前記第１記憶領域を拡張し、第２の値で前記第２記憶領域を拡張する暗号化ハッシュ拡張部と、
前記外部インターフェースを介して受信したデータを代表する値を前記第１記憶領域内と前記第２記憶領域内とに拡張するよう前記暗号化ハッシュ拡張部に要求することによってルール要因を適用する第１ルール要因適用部と、
前記外部インターフェースを介して受信したデータを代表する第１の値を前記第１記憶領域内に拡張し、かつ、前記外部インターフェースを介して受信したルール要因修正チケットに記載されている第２の値を前記第２記憶領域内に拡張するよう前記暗号化ハッシュ拡張部に要求することによって２つのルール要因を適用する第２ルール要因適用部とを備え、
前記ルール要因修正チケットは、前記第２記憶領域内に拡張する置換用の第２の値と、前記ルール要因修正チケット内のデータの暗号化ダイジェストとを含む
請求項６記載の情報処理装置。
【請求項８】
前記ルール要因修正チケットは、さらに、
予測された第１の値を含み、
前記第２ルール要因適用部は、さらに、前記予測された第１の値が、前記外部インターフェースを介して受信したデータを代表する前記第１の値と一致することを確認し、
一致しない場合には、前記第１の値を拡張するという前記暗号化ハッシュ拡張部への要求を行わない
請求項７記載の情報処理装置。
【請求項９】
前記ルール要因修正チケットは、さらに、
前記オブジェクトの予測代表値を含み、
前記第２ルール要因適用部は、さらに、前記オブジェクトの予測代表値が、前記外部インターフェースを介して受信したオブジェクトの代表値と一致することを確認し、
一致しない場合には、前記第１の値を拡張するという前記暗号化ハッシュ拡張部への要求を行わない
請求項７記載の情報処理装置。
【請求項１０】
前記ルール要因修正チケットは、さらに、
予測されたルール要因タイプを含み、
前記第２ルール要因適用部は、さらに、前記予測されたルール要因タイプが、前記外部インターフェースを介して受信したルール要因タイプと一致することを確認し、
一致しない場合には、前記第１の値を拡張するという前記暗号化ハッシュ拡張部への要求を行わない
請求項７記載の情報処理装置。
【請求項１１】
オブジェクトルール修正チケット発行方法であって、
現在のオブジェクトルール値を表す第１暗号化ハッシュを提供し、
新しいオブジェクトルール値を表す第２暗号化ハッシュを提供し、
オブジェクトルール値を含むオブジェクトを提供し、
ルール要因タイプを提供し、
前記オブジェクトルール値が前記第１暗号化ハッシュ値と等しいことを検証し、そして、
これらの値が等しければ、前記オブジェクトの代表値と前記第１暗号化ハッシュと前記第２暗号化ハッシュとの暗号化ダイジェストを生成することによって、オブジェクトルール修正チケットを発行する
オブジェクトルール修正チケット発行方法。
【請求項１２】
前記方法は、さらに、
ルール要因を表すデータセットを提供し、
置換用の暗号化ハッシュ値と、ルール要因修正チケット内のデータの暗号化ダイジェストとを含むルール要因修正チケットを提供し、
前記ルール要因修正チケットに関連付けられた前記暗号化ダイジェストが正しいことを検証し、
前記検証が成功すれば、ルール要因を表す前記データセットを代表する値を前記第１暗号化ハッシュ内に拡張し、置換用の暗号化ハッシュを前記第２暗号化ハッシュ内に拡張する
請求項１１記載の方法。
【請求項１３】
前記方法は、さらに、
前記ルール要因修正チケットが、予測された第１の値をさらに含み、
前記予測された第１の値が、ルール要因を表すデータセットを代表する値と一致することをさらに検証し、
一致しなければ、前記第１暗号化ハッシュ内への拡張と前記第２暗号化ハッシュ内への拡張とを行わない
請求項１２記載の方法。
【請求項１４】
前記方法は、さらに、
前記ルール要因修正チケットが、前記オブジェクトの予測された代表値をさらに含み、
前記オブジェクトの予測された代表値が前記オブジェクトの代表値と一致することをさらに検証し、
一致しなければ、前記第１暗号化ハッシュ内への拡張と前記第２暗号化ハッシュ内への拡張とを行わない
請求項１２記載の方法。
【請求項１５】
前記方法は、さらに、
前記ルール要因修正チケットが、予測されたルール要因タイプをさらに含み、
前記予測されたルール要因タイプが前記ルール要因タイプと一致することをさらに検証し、
一致しなければ、前記第１暗号化ハッシュ内への拡張と前記第２暗号化ハッシュ内への拡張とを行わない
請求項１２記載の方法。
【請求項１】
耐タンパ性のセキュリティＬＳＩを備える情報処理装置であって、
前記ＬＳＩは、
前記ＬＳＩのリブート後でも利用できる必要があるデータを記憶する不揮発性メモリ領域と、
前記ＬＳＩの１ブートサイクル中にのみ必要なデータを記憶する揮発性メモリ領域と、
インクリメントのみ可能な複数の不揮発性カウンタを記憶する単調カウンタ領域と、
プラットフォーム状態に関する蓄積情報を記憶するプラットフォーム構成レジスタ（ＰＣＲ）領域と、
複数の暗号化キーを生成し、データを暗号化し、データを復号し、複数の暗号化署名を生成し、複数の暗号化署名を検証する暗号化部と、
前記ＬＳＩの外部に情報を送信し、前記ＬＳＩの外部から情報を受信する外部インターフェースと、
第１暗号化ハッシュを記憶する前記揮発性メモリ領域内の第１記憶領域と、
第２暗号化ハッシュを記憶する前記揮発性メモリ領域内の第２記憶領域と、
前記外部インターフェースを介して受信したオブジェクトの代表値と、前記第１暗号化ハッシュと、前記第２暗号化ハッシュと、前記代表値および２つの暗号化ハッシュの暗号化ダイジェストとを含んだ、受信した前記オブジェクトに含まれているルールを修正するためのオブジェクトルール修正チケットを発行するオブジェクトルール修正チケット発行部と、
受信した前記オブジェクトが、前記第１記憶領域に記憶されている第１暗号化ハッシュと等しい暗号化ハッシュを含んでいる場合にのみ、前記チケット発行部を有効にするオブジェクトルール修正チケット発行制御部と
を備える情報処理装置。
【請求項２】
前記ＬＳＩは、さらに、
第１の値で前記第１記憶領域を拡張し、第２の値で前記第２記憶領域を拡張する暗号化ハッシュ拡張部と、
前記外部インターフェースを介して受信したデータを代表する値を前記第１記憶領域内と前記第２記憶領域内とに拡張するよう前記暗号化ハッシュ拡張部に要求することによってルール要因を適用する第１ルール要因適用部と、
前記外部インターフェースを介して受信したデータを代表する第１の値を前記第１記憶領域内に拡張し、かつ、前記外部インターフェースを介して受信したルール要因修正チケットに記載されている第２の値を前記第２記憶領域内に拡張するよう前記暗号化ハッシュ拡張部に要求することによって２つのルール要因を適用する第２ルール要因適用部とを備え、
前記ルール要因修正チケットは、前記第２記憶領域内に拡張する置換用の第２の値と、前記ルール要因修正チケット内のデータの暗号化ダイジェストとを含む、
請求項１記載の情報処理装置。
【請求項３】
前記ルール要因修正チケットは、さらに、
予測された第１の値を含み、
前記第２ルール要因適用部は、さらに、前記予測された第１の値が、前記外部インターフェースを介して受信したデータを代表する前記第１の値と一致することを確認し、
一致しない場合には、前記第１の値を拡張するという前記暗号化ハッシュ拡張部への要求を行わない
請求項２記載の情報処理装置。
【請求項４】
前記ルール要因修正チケットは、さらに、
前記オブジェクトの予測代表値を含み、
前記第２ルール要因適用部は、さらに、前記オブジェクトの予測代表値が、前記外部インターフェースを介して受信したオブジェクトの代表値と一致することを確認し、
一致しない場合には、前記第１の値を拡張するという前記暗号化ハッシュ拡張部への要求を行わない
請求項２記載の情報処理装置。
【請求項５】
前記ルール要因修正チケットは、さらに、
予測されたルール要因タイプを含み、
前記第２ルール要因適用部は、さらに、前記予測されたルール要因タイプが、前記外部インターフェースを介して受信したルール要因タイプと一致することを確認し、
一致しない場合には、前記第１の値を拡張するという前記暗号化ハッシュ拡張部への要求を行わない
請求項２記載の情報処理装置。
【請求項６】
耐タンパ性のセキュアなアプリケーション実行環境を有したＣＰＵを備える情報処理装置であって、
前記セキュアなアプリケーション実行環境は、
前記セキュアなアプリケーション実行環境内のアプリケーションにサービスを提供するセキュアなオペレーティングシステムと、
前記ＣＰＵのリブート後でも利用できる必要があるデータを記憶する不揮発性メモリ領域と、
前記ＣＰＵの１ブートサイクル中にのみ必要なデータを記憶する揮発性メモリ領域と、
インクリメントのみ可能な複数の不揮発性カウンタを記憶する単調カウンタ領域と、
プラットフォーム状態に関する蓄積情報を記憶するプラットフォーム構成レジスタ（ＰＣＲ）領域と、
複数の暗号化キーを生成し、データを暗号化し、データを復号し、複数の暗号化署名を生成し、複数の暗号化署名を検証する暗号化部と、
前記セキュアなアプリケーション実行環境の外部に情報を送信し、前記セキュアなアプリケーション実行環境の外部から情報を受信する外部インターフェースと、
第１暗号化ハッシュを記憶する前記揮発性メモリ領域内の第１記憶領域と、
第２暗号化ハッシュを記憶する前記揮発性メモリ領域内の第２記憶領域と、
前記外部インターフェースを介して受信したオブジェクトの代表値と、前記第１暗号化ハッシュと、前記第２暗号化ハッシュと、前記代表値および２つの暗号化ハッシュの暗号化ダイジェストとを含んだ、受信した前記オブジェクトに含まれているルールを修正するためのオブジェクトルール修正チケットを発行するオブジェクトルール修正チケット発行部と、
受信した前記オブジェクトが、前記第１記憶領域に記憶されている第１暗号化ハッシュと等しい暗号化ハッシュを含んでいる場合にのみ、前記チケット発行部を有効にするオブジェクトルール修正チケット発行制御部と
を備える情報処理装置。
【請求項７】
前記セキュアなアプリケーション実行環境は、さらに、
第１の値で前記第１記憶領域を拡張し、第２の値で前記第２記憶領域を拡張する暗号化ハッシュ拡張部と、
前記外部インターフェースを介して受信したデータを代表する値を前記第１記憶領域内と前記第２記憶領域内とに拡張するよう前記暗号化ハッシュ拡張部に要求することによってルール要因を適用する第１ルール要因適用部と、
前記外部インターフェースを介して受信したデータを代表する第１の値を前記第１記憶領域内に拡張し、かつ、前記外部インターフェースを介して受信したルール要因修正チケットに記載されている第２の値を前記第２記憶領域内に拡張するよう前記暗号化ハッシュ拡張部に要求することによって２つのルール要因を適用する第２ルール要因適用部とを備え、
前記ルール要因修正チケットは、前記第２記憶領域内に拡張する置換用の第２の値と、前記ルール要因修正チケット内のデータの暗号化ダイジェストとを含む
請求項６記載の情報処理装置。
【請求項８】
前記ルール要因修正チケットは、さらに、
予測された第１の値を含み、
前記第２ルール要因適用部は、さらに、前記予測された第１の値が、前記外部インターフェースを介して受信したデータを代表する前記第１の値と一致することを確認し、
一致しない場合には、前記第１の値を拡張するという前記暗号化ハッシュ拡張部への要求を行わない
請求項７記載の情報処理装置。
【請求項９】
前記ルール要因修正チケットは、さらに、
前記オブジェクトの予測代表値を含み、
前記第２ルール要因適用部は、さらに、前記オブジェクトの予測代表値が、前記外部インターフェースを介して受信したオブジェクトの代表値と一致することを確認し、
一致しない場合には、前記第１の値を拡張するという前記暗号化ハッシュ拡張部への要求を行わない
請求項７記載の情報処理装置。
【請求項１０】
前記ルール要因修正チケットは、さらに、
予測されたルール要因タイプを含み、
前記第２ルール要因適用部は、さらに、前記予測されたルール要因タイプが、前記外部インターフェースを介して受信したルール要因タイプと一致することを確認し、
一致しない場合には、前記第１の値を拡張するという前記暗号化ハッシュ拡張部への要求を行わない
請求項７記載の情報処理装置。
【請求項１１】
オブジェクトルール修正チケット発行方法であって、
現在のオブジェクトルール値を表す第１暗号化ハッシュを提供し、
新しいオブジェクトルール値を表す第２暗号化ハッシュを提供し、
オブジェクトルール値を含むオブジェクトを提供し、
ルール要因タイプを提供し、
前記オブジェクトルール値が前記第１暗号化ハッシュ値と等しいことを検証し、そして、
これらの値が等しければ、前記オブジェクトの代表値と前記第１暗号化ハッシュと前記第２暗号化ハッシュとの暗号化ダイジェストを生成することによって、オブジェクトルール修正チケットを発行する
オブジェクトルール修正チケット発行方法。
【請求項１２】
前記方法は、さらに、
ルール要因を表すデータセットを提供し、
置換用の暗号化ハッシュ値と、ルール要因修正チケット内のデータの暗号化ダイジェストとを含むルール要因修正チケットを提供し、
前記ルール要因修正チケットに関連付けられた前記暗号化ダイジェストが正しいことを検証し、
前記検証が成功すれば、ルール要因を表す前記データセットを代表する値を前記第１暗号化ハッシュ内に拡張し、置換用の暗号化ハッシュを前記第２暗号化ハッシュ内に拡張する
請求項１１記載の方法。
【請求項１３】
前記方法は、さらに、
前記ルール要因修正チケットが、予測された第１の値をさらに含み、
前記予測された第１の値が、ルール要因を表すデータセットを代表する値と一致することをさらに検証し、
一致しなければ、前記第１暗号化ハッシュ内への拡張と前記第２暗号化ハッシュ内への拡張とを行わない
請求項１２記載の方法。
【請求項１４】
前記方法は、さらに、
前記ルール要因修正チケットが、前記オブジェクトの予測された代表値をさらに含み、
前記オブジェクトの予測された代表値が前記オブジェクトの代表値と一致することをさらに検証し、
一致しなければ、前記第１暗号化ハッシュ内への拡張と前記第２暗号化ハッシュ内への拡張とを行わない
請求項１２記載の方法。
【請求項１５】
前記方法は、さらに、
前記ルール要因修正チケットが、予測されたルール要因タイプをさらに含み、
前記予測されたルール要因タイプが前記ルール要因タイプと一致することをさらに検証し、
一致しなければ、前記第１暗号化ハッシュ内への拡張と前記第２暗号化ハッシュ内への拡張とを行わない
請求項１２記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０Ａ】
【図１０Ｂ】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０Ａ】
【図１０Ｂ】
【図１１】
【図１２】
【図１３】
【図１４】
【公開番号】特開２０１２−３９３９０（Ｐ２０１２−３９３９０Ａ）
【公開日】平成２４年２月２３日（２０１２．２．２３）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１０−１７７８１９（Ｐ２０１０−１７７８１９）
【出願日】平成２２年８月６日（２０１０．８．６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕ−ｒａｙ Ｄｉｓｃ
２．ＪＡＶＡ
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
【公開日】平成２４年２月２３日（２０１２．２．２３）
【国際特許分類】
【出願番号】特願２０１０−１７７８１９（Ｐ２０１０−１７７８１９）
【出願日】平成２２年８月６日（２０１０．８．６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕ−ｒａｙ Ｄｉｓｃ
２．ＪＡＶＡ
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
[ Back to top ]