JPH10171648A - アプリケーションを認証する装置 - Google Patents

Abstract

(57)【要約】 【課題】 国際的な暗号フレームワーク内で暗号サービ
スを要求するアプリケーションを与えられたレベルの暗
号の不正使用から保護する。 【解決手段】国際的な暗号フレーム・ワーク内のいろい
ろなサービス要素から暗号サービスを要求するアプリケ
ーションは、認証を介して識別される。暗号ユニット
は、アプリケーション・オブジェクトのためにいくつか
の認証方式を構築する。アプリケーションのコード・イ
メージと発行される認証との間の結合をフレームワーク
要素を使用して確立する。フレームワーク内でアプリケ
ーションは、それがサービスを受けている暗号ユニット
の安全性について保証される。置換えられなかったか、
改変されなかったかをアプリケーションが確認すること
ができるメカニズムが備えられる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、暗号に関し、特
に、アプリケーション・イメージが導入されるときアプ
リケーションと認証(certificate)との結びつきに関し
アプリケーション・イメージを確認するメカニズムおよ
びアプリケーション・イメージがそこに導入されるシス
テム・サービス要素を確認するメカニズムに関する。

【０００２】

【従来の技術】大型のコンピュータ・システムの顧客
は、典型的には、ソリューションに基づいて企業全体に
わたるコンピュータの購入を希望する多国籍企業であ
る。そのような組織は分散的な性質をもっているため、
その組織中にデータを移動させるのに公共の国際通信サ
ービスを使用する必要がある。当然、それら企業は通信
の機密保護に配慮し、プライバシーとデータの完全性を
保証するために現代的な端から端(end-to-end)への暗号
の設備を使用する。

【０００３】通信における暗号の使用は、国の改策（ポ
リシー）によって管理されるが、不幸にして各国の改策
（ポリシー）は、そのような使用に関して相違する。各
国の改策（ポリシー）は、一般に国際性の尊重よりもむ
しろ国内に重きをおいて独自に開発される。国際的な暗
号に適する共通暗号アルゴリズムを開発しようとしてい
る標準化グループがある。しかしながら、国際的な暗号
の標準化の問題は、技術的な問題でなく、むしろ、その
核心に国の主権を含む政治的な問題である。このよう
に、異なる国の暗号改策（ポリシー）が、技術的な標準
化処理によって調整されるのを期待することは、現実的
でない。

【０００４】暗号に対する国の関心事の問題は、世界的
な市場のために開放型標準に基づいた情報技術製品を作
る会社にとって特に関心がある。市場は、これらの製品
が安全であるのを期待する。それでも、これらの製品の
消費者多くは、自分自身が国際的であり、製造業者に世
界的な情報技術の開発を妨げる国際的な暗号の問題を解
決するのを助けてほしいと期待している。国の暗号改策
（ポリシー）における未解決の相違点および輸出制限を
そのままにする事は、安全なオープン・コンピューティ
ング製品のための国際的な市場の成長に悪い影響を持
つ。したがって、各国の暗号改策（ポリシー）の独立し
た開発を考慮しつつ、共通の機密保護要素を特徴とする
グロ―バル情報技術製品を提供する国際的なフレームワ
ークを提供することは、有益なことである。

【０００５】各国が暗号を管理する改策（ポリシー）を
採用することには、理由がある。しばしば、これらの理
由は、法律施行と国の機密保護の問題と関係をもつ。各
国で、これらの改策（ポリシー）の正当性と受容性に関
して、政府と民間との間に討論がありうる。これらの討
論に没頭したり、それらの結果を予測したりするより
も、各国の主権者の権利で、通信の暗号を管理する独立
した改策（ポリシー）を確立することができるようにす
ることがより現実的である。

【０００６】国の暗号を管理する改策（ポリシー）は、
民間と政府の意志を表すだけでなくて、暗号を容易にす
るある種の技術の受け入れも含む。技術の選択は、確か
に、標準化が役割を果たすことのできる１つの領域であ
る。しかしながら、上述したように、これは技術的な問
題だけではなく、共通の暗号技術の選択だけで、国の改
策（ポリシー）の違いを解決することはできない。

【０００７】国旗カード、暗号ユニット、ホスト・シス
テム、及びネットワーク・セキュリティ・サーバを含む
国際的な暗号を支援する４つの部分の技術フレームワー
クは、1995年3月8日に出願されて出願継続中の米国特許
出願第08／401，588号のクレンバ（K. Klemba）とマー
クリング（R. Merckling）による国際暗号フレームワー
クに開示されている。

【０００８】このフレームワークは、独立国の機密保護
改策（ポリシー）の設計、開発、および運用を統一しな
がら、全ての国の改策（ポリシー）の設計、施行、運用
の要素を支援する。したがって、このフレームワーク
は、国の機密保護改策（ポリシー）のサービス要素に対
する標準形を与え、このサービス要素は、ハードウェア
形式要素、通信プロトコル、オンラインやオフラインの
データ定義を含む。

【０００９】図１は、国旗カード12、暗号ユニット14、
ホスト・システム16及びネットワーク・セキュリティ・
サーバ18を含む国際暗号フレームワーク10のブロック図
である。４つのサービス要素のうちの３つは、基本的に
階層的な関連を持つ。国旗カード(NFC,National Flag C
ard)が暗号ユニット(Cryptographic Unit)に導入され、
この暗号ユニットがホストシステム(HS)に導入される。
ホスト・システム上の暗号の機能は、そのサービス供給
を可能にするにはそれ自身が有効な国旗カードの存在を
必要とする暗号ユニットなしで、実行されることができ
ない。４番目のサービス要素であるネットワーク・セキ
ュリティ・サーバ（ＮＳＳ）は、他の３つのサービス要
素の確認を含むある範囲の異なるセキュリティ・サービ
スを提供し、したがって委託された第三者的な働きをす
る。

【００１０】図２は、暗号ユニット14、いくつかの国旗
カード12、ホスト・システム16、及び国のセキュリティ
・サーバ18を含むフレームワークの４つの基本要素を表
示している。以下に、各々のサービス要素を詳細に説明
する。

【００１１】国旗カード（ＮＦＣ）。ＮＦＣ12は、小さ
い切手サイズ（25×15ｍｍ）のＩＳＯ7816‐タイプのス
マート・カード、即ち、不揮発性メモリを備えるワンチ
ップ・コンピュータ26である。ＮＦＣは、堅い基板上に
搭載され、改変防止用のパッケージに封止される。ＮＦ
Ｃは、一般的に、独立して生産され、国の機関（例え
ば、米国郵便局やドイツ郵便協会など）によって配布さ
れる。また、国の機関は、ＮＦＣの生産と配布を民間の
産業に認可することがありえる。

【００１２】ＮＦＣサービス要素の働きは、暗号の使用
を管理する国の改策（ポリシー）を強制することであ
る。ＮＦＣは、マルチチップ・アーキテクチャとしてカ
スタム集積回路を含むように造られた完成したコンピュ
ータである。また、それは、未許可のエントリや重複を
回避する、改変耐性や個別の識別機能を含む。例えば、
そのパッケージを開封することは、集積回路や内部デー
タを破壊することになるというような方法で、ＮＦＣを
封止する。ＮＦＣは、国のセキュリティ・サーバで発行
された暗号化された許可の受取りを必要とする。ＮＦＣ
の全てのサービスは、ＮＦＣと他のサービス要素の間
で、標準ＩＳＯ7816メッセージ交換プロトコルを介し
て、提供される。このフォーマットは、携帯音声サービ
スにおけるＧＳＭを支援するために、ヨーロッパで使用
されるスマート・カードと同一である。

【００１３】暗号ユニット（ＣＵ）。暗号ユニットは、
ＮＦＣの厳しい制御の下で保護されている暗号のサービ
スを提供するために設計された、改変耐性をもつハード
ウェア構成要素である。暗号ユニットは、システム・ベ
ンダと第三者によって、競合して生産され、輸入及び輸
出制限がない。暗号ユニットは、暗号アルゴリズムとキ
ーのようなセキュリティの重要な要素を含むので、顧客
保証のために、（例えば、ＮＩＳＴ、ＮＣＳＣ、または
認証されたＩＴＳＥＣなどの）認証される。本発明の実
施例において、暗号ユニットは、ＮＦＣに依存する以外
は、いかなる管理改策（ポリシー）も含まないことが特
徴である。この構成ユニットは、与えられたホスト・シ
ステムをカスタマイズすることで、パフォーマンスと保
護を好適に設計される。

【００１４】ホスト・システム（ＨＳ）。安全な情報技
術サービスを直接ユーザに届けるハードウェア構成要素
として、ＨＳを定義することができる。ＨＳは、一般的
に、多目的の情報技術装置であり、広域な開放市場で競
争的に生産される。例えば、制御と測定の組込みシステ
ムだけでなく、パーソナル・ディジタル・アシスタント
（personal digital assistants）、パーソナル・コン
ピュータ、ワークステーション、ラップトップ、パーム
トップ、ネットワーク・サーバ、メイン・フレーム、ネ
ットワーク・プリンタ、ビデオ・ディスプレイ装置など
を含む。フレームワークのＨＳサービス要素の機能は、
暗号ユニットサービス要素にアクセスするためのアプリ
ケーション・プログラミング・インターフェース（ＡＰ
Ｉ）を提供することである。暗号ユニットの支援は、Ｈ
Ｓ上のとりうるオプションとして提供されるのが好まし
い。

【００１５】ネットワーク・セキュリティ・サーバ（Ｎ
ＳＳ）。ＮＳＳは、委託された第三者セキュリティ・サ
ービスを提供するために設計され、指定されたネットワ
ーク・ノードである。例えば、ネットワーク34上のモデ
ム30、32を介するような、どのようなネットワーク・ア
クセスでも、ＮＳＳによって承認されなければならな
い。国のセキュリティ環境において、ＮＳＳは、政府機
関によって、開発され、所有され、操作されるのが好ま
しい。ＮＳＳサービス要素によって提供された機能のい
くつかは、サービス要素承認、メッセージ・スタンプ承
認、国の改策（ポリシー）基準、および暗号キー配布を
含む。強い確認が暗号の使用にとってあらかじめ必要な
環境において、ＮＳＳの重要性が非常に増加する。ま
た、ＮＳＳは、複数の異なる国家暗号改策（ポリシー）
の相互運用において、重要な役割を演ずる。

【００１６】フレームワークの範囲。フレームワークの
範囲は、主にＮＦＣの範囲によって定義される。ＮＦＣ
の基本範囲は、ドメインの範囲である。ドメインは、世
界的な規模と同様に大きく、そして、ビジネス単位と同
様に小さい。ドメイン・レベルで、そのメンバの個別の
区別はない。このフレームワークが、主に国内や国際的
なドメイン（即ち、フランス、ドイツ、米国、英国、Ｅ
Ｃ、ＮＡＴＯ、北アメリカ、Ｇ７など）に集中する一方
で、他のドメインやサブドメインが考慮される。例え
ば、産業ドメイン（例えば、テレコミュニケーション、
ヘルスケア、投資情報サービス、旅行など）、会社ドメ
イン（例えば、ヒューレット・パッカード社、フォード
・モーター社、シティバンクなど）、協会ドメイン（例
えば、ＩＥＥＥ、ＩＳＯ、Ｘ／Ｏｐｅｎなど）、サービ
ス・ドメイン（例えば、コンプサーブ、アメリカ・オン
ラインなど）、及び製品ドメイン（例えば、ロータス、
マイクロソフト、ゼネラル・モーターズ、プロクター・
アンド・ギャンブルなど）である。

【００１７】ドメインおよびサブドメインを越えて、フ
レームワークの範囲は、ドメイン内でユニーク性を定義
するために選択的に拡張される。この狭い範囲を可能と
するのもＮＦＣである。ユニーク性を提供することは、
購入の時点でまたは最初の承認の際に、転送されるユニ
ークなまたは個人データのＮＦＣへの転送を許可するこ
とを意味する。ドメイン・レベルで取り扱っているとき
には、ＮＦＣは匿名であるとみなされる。ユニークさが
加えられると、ＮＦＣはもはや匿名ではなくなる。

【００１８】フレームワーク要素の相互接続。このフレ
ームワークのサービス要素（例えば、ＮＦＣ、暗号ユニ
ット、ＨＳ、ＮＳＳなど）の相互連結は、標準化アプリ
ケーション・プログラミング・インターフェース（例え
ば、Ｘ／Ｏｐｅｎ、ＯＳＦなど）や産業標準プロトコル
交換（例えば、ＴＣＰ／ＩＰ、ＩＳＯ、ＤＣＥ、Ｘ．50
9など）を採用することによって成り立っている。

【００１９】要素の相互接続は、同期（即ち、オンライ
ン）、非同期（即ち、オフライン）、ローカル（例え
ば、実行時ライブラリ）、リモート（例えば、ＰＣ）、
またはこれらのあらゆる組合せである。例えば、ＮＦＣ
の個性化を含む改策（ポリシー）は、ＮＳＳを介した一
時の許可機能を実行することができ、ＮＦＣが失効する
までＮＳＳでの将来のオンライン確認を不要とすること
ができる。

【００２０】フレームワークのサービス要素の物理的な
相互接続を越えて、要素と、このメッセージ交換を通じ
て提供され要求される実際のサービスとの間にメッセー
ジ交換がある。図３は、ＮＦＣ12と暗号ユニット14間
（パス35）、暗号ユニット14とＨＳ16間（パス36）、及
びＨＳ16とＮＳＳ18間（パス37）の、メッセージ交換パ
スを示す。仮想接続38が、ＮＦＣとＮＳＳの間に存在す
る。

【００２１】ＨＳとパス36に沿った暗号ユニットとの間
のメッセージ・プロトコルは、暗号ＡＰＩ標準化努力
（例えば、ＮＳＡ暗号ＡＰＩ、マイクロソフトの暗号Ａ
ＰＩなど）からとられる。パス35に沿った暗号ユニット
とＮＦＣ間のメッセージ・プロトコルは、２つのグルー
プ、初期化プロトコルと操作プロトコルに分類される。
操作プロトコルが稼動する前に、初期化プロトコルは成
功していなければならない。

【００２２】

【発明が解決しようとする課題】従って、共通の、受け
入れられる暗号フレームワークを提供することは、有用
である。このフレームワークにおいては、独立した技術
と改策（ポリシー）の選択を、これらの改策（ポリシ
ー）と調和した国際的な暗号通信を可能にする態様で行
うことができる。フレームワークの実行にとって重要な
のは、いろいろなサービス要素の生産を可能にする基本
的な技術の提供である。サービス要素のいろいろな実行
が、関連した技術に塾達した者の技術の範囲内である
が、フレームワークの完全なポテンシャルを実現するた
めには、技術水準に対して具体的な改良が必要である。

【００２３】例えば、フレームワーク内にあるアプリケ
ーションを、要求されたサービスのクラスについての許
可をもつ正当なアプリケーションとして確立するシステ
ムを含むことが、有益である。また、サービス要素がア
プリケーション・イメージとサービス要求の正当な受け
側であることを、アプリケーションが確認することも有
益である。少くとも、認証のような改変耐性をもつ転送
メカニズム、および特定の処理の間、連続性を確立し維
持するためのメカニズムを必要とするセキュリティ・パ
ラダイムに従って、そのようなシステムが稼動するなら
ば、それはさらに有益なことである。

【００２４】本発明は、例えば、暗号機能の分配を管理
する国の法律の変化に製造業者が対応することを可能に
する、国際的な暗号フレームワークのような、安全シス
テムにある。特に、そのようなフレームワークは、全て
のタイプの情報処理装置（例えば、プリンタ、パームト
ップなど）において、世界的な暗号機能を出荷すること
を可能にする。フレームワーク内で、暗号ユニットは、
いくつかの暗号方法（例えば、ＤＥＳ、ＲＳＡ、ＭＤ５
など）を含む。

【００２５】フレームワークのサービス要素から暗号サ
ービスを要求するアプリケーションが許可されたレベル
の暗号の誤用に対して保護するためなんらかの形の認証
を介して、識別されることは、フレームワークの基本的
な要求である。フレームワークのコア要素のうちの１つ
である暗号ユニットを、アプリケーション・オブジェク
トに対するいくつかの認証方式を造るために使用するこ
とができる。本発明は、アプリケーション・コード・イ
メージと、発行された認証との間である度合の結合をフ
レームワーク要素を使用して、確立するいろいろな方法
を提供する。

【００２６】フレームワークのもう一つの基本的な要求
は、アプリケーションが、そこからサービスを受け取る
暗号ユニットの完全性を保証されるということである。
本発明は、アプリケーションが暗号ユニットの置換え
や、変更がなかったことを確認することができる、いろ
いろなメカニズムを提供する。

【００２７】

【課題を解決するための手段】この発明の課題は、アプ
リケーションを認証する装置であって、アプリケーショ
ンに少くとも１つのサービスのクラスを与えるセキュリ
ティ・ドメイン権限と、前記セキュリティ・ドメイン権
限によって与えられた前記サービスのクラスを受取るア
プリケーション・ドメイン権限と、前記アプリケーショ
ン・ドメイン権限によって、アプリケーション・ドメイ
ン権限のドメインに属するアプリケーションに発行され
る少くとも１つのアプリケーション認証とを備える装置
を提供することによって解決される。

【００２８】

【発明の実施の形態】国の暗号改策（ポリシー）は、産
業分野、政治的な環境、メッセージ機能によって、たび
たび変化する。このことは、１つの画一的な改策（ポリ
シー）を、常時、全ての産業に適用することを難しくし
ている。従って、国旗カードを取り入れる暗号フレーム
ワークの柔軟性は、非常に魅力的である。したがって、
本発明は、主に、国際的な暗号を取り囲む問題を解決す
ることに向けられる。しかしながら、本発明は、アプリ
ケーションの真正性や特権の確認を必要とする環境、そ
して、許可を受けた安全な暗号プロセッサのサービスを
使用していることをアプリケーションに保証することを
必要とするどんな環境にも容易に適用することができ
る。

【００２９】本発明の実施例は、クレンバとマークリン
グによって1995年3月8日に出願され継続中の米国特許出
願第08／401,588号の国際暗号フレームワークで開示さ
れたようなフレームワーク内のアプリケーション認証に
関係する。フレームワークのサービス要素から暗号サー
ビスを要求するアプリケーションが、与えられたレベル
の暗号の誤用に対して保護するためなんらかの形の認証
を介して識別されることは、フレームワークの基本的な
要求である。

【００３０】フレームワークのコア要素のうちの１つで
ある暗号ユニットは、アプリケーション・オブジェクト
に対するいくつかの認証方式を造るために使用すること
ができる。本発明は、アプリケーションのコード・イメ
ージと、発行される認証との間にある度合の結合をフレ
ームワーク要素を使用して確立するいろいろな方法を提
供する。

【００３１】フレームワークのもう一つの基本的な要求
は、アプリケーションに、サービスを受け取る暗号ユニ
ットの完全性を保証するということである。本発明は、
アプリケーションが暗号ユニットの置換えや、変更がな
かったことを確認することができるいろいろなメカニズ
ムを提供する。

【００３２】上述のように、フレームワークによって、
製造業者は暗号機能の配布を管理している国の法律の変
化に対応できる。特に、そのようなフレームワークは、
全てのタイプの情報処理装置（例えば、プリンタ、パー
ムトップなど）に、世界的な暗号機能を送り出すことを
可能にする。

【００３３】上述したようなフレームワークの４つの基
本要素を以下に概説する。暗号ユニット。暗号ユニット
を含むシステムや装置は、暗号ユニットへの、アプリケ
ーション・プログラミング・インターフェースを支援す
る。また、それは、セキュリティを認識し暗号ユニット
を使用するアプリケーションを支援する。これらのアプ
リケーションやサブシステム層は、認証の使用によっ
て、暗号ユニットにしっかりと結びつけられる。

【００３４】改策（ポリシー）によって起動されるま
で、暗号機能は、活動を停止しており、ホスト・システ
ムによって使用されない。暗号ユニットに含まれる暗号
機能は、本発明を使用するアプリケーションの要求によ
って決定される。暗号ユニットは、そこに記憶されるあ
らゆるキーを保護するための改変耐性をもっている。改
策（ポリシー）との接触を維持することは、暗号ユニッ
トの責務である。そうすることができないことは、暗号
ユニットの崩壊を意味する。

【００３５】改策（ポリシー）（「国旗カード」および
「改策（ポリシー）・カード」に参照される）。改策
（ポリシー）は、暗号使用改策（ポリシー）を含むシス
テムまたは装置である。特に、フレームワークのこの要
素は、特定の暗号ユニットで暗号の使用を管理するパラ
メータを含む。さらに、この要素は、暗号ユニットの鼓
動チャレンジに応答することに責任がある。

【００３６】ネットワーク・セキュリティ・サーバ。ネ
ットワーク・セキュリティ・サーバは、ホスト・システ
ム、暗号ユニット、及び改策（ポリシー）に、ネットワ
ーク・サービスを提供する信頼のおける第三者の働きを
するシステムあるいは装置である。これらのサービス
は、例えば、改策（ポリシー）拡張機能、装置確認、許
可の調整、及びキー・マネジメント・サービスを含む。

【００３７】フレームワーク・アーキテクチャは、コア
要素についての以下の基本的な前提条件に基づいてい
る。 ・暗号ユニットは、改策（ポリシー）と接触せずにはホ
スト・システムに暗号機能を提供することができない。 ・改策（ポリシー）は、暗号ユニットで処理されるユー
ザ・データにアクセスしない。 ・与えられた改策（ポリシー）によって制御される暗号
ユニットは、決定性、即ち、あらゆるイベントや働きで
あり、暗号ユニットの決定は、改策（ポリシー）の独立
した経歴の必然的な結果である。 ・暗号ユニットまたは改策（ポリシー）は、国のセキュ
リティ・サーバのサービスを要求することができる。

【００３８】フレームワークの１つのキー要素は、暗号
ユニットである。以下のように、暗号ユニットの実行
は、ホスト・システムに一組のサービスを提供する。 ・暗号機能。暗号ユニットの主な目的は、暗号機能を提
供することである。装置は、定義された暗号アルゴリズ
ムを実行するハードウェアとソフトウェアのホストとな
る。また、ある種の暗号改策（ポリシー）を実施するハ
ードウェアとソフトウェアのホストとなる。

【００３９】・安全な記憶装置（Secure storage）。安
全な記憶装置は、安全な方法で暗号ユニット内に情報を
記憶できる。この機能は、主に、キー材料を暗号ユニッ
ト内に記憶するために使用される。また、オーバ・タイ
ム、アプリケーション及びサブシステム層は、暗号ユニ
ット内に他の非セキュリティ関連材料を記憶することに
よって、この機能を役立てることがある。

【００４０】・安全な実行（Secure execution）。暗号
ユニットは、その装置の安全装置と改変耐性環境におけ
る、コードの実行を許可する。アプリケーションとサブ
システム層は、この安全な環境において、セキュリティ
・プロトコル・ハンドラのような、それらの機能の一部
分を実行する機能に有効に働くことがある。

【００４１】図４は、暗号ユニットアーキテクチャのブ
ロック図である。この図は、特定の物理的な実行に言及
するものではなく、本発明の実施例として、この要素を
実行する暗号ユニット内に要求された主な要素を示す。

【００４２】暗号ユニット14を形成するいくつかの構成
装置を以下に示す。 ・中央処理装置（ＣＰＵ）。ＣＰＵ47は、全ての情報の
流れを制御する。安全な実行のためにダウンロードされ
たモジュールは、ＣＰＵによって実行される。

【００４３】・記憶素子。暗号ユニットは、いくつかの
記憶素子を必要とする。 −フラッシュ・メモリ48は、暗号ユニットに記憶される
プログラムと不揮発性データを記憶する。 −ＲＯＭ記憶装置49は、暗号ユニットのリセットで実行
するブートストラップ・コードのホストである。 −ＲＡＭ記憶装置50は、暗号ユニットの揮発性のデータ
を持つ。

【００４４】・暗号ＡＳＩＣ52と乱数ジェネレータ51。
これらの２つの要素は、暗号ユニットによって提供され
た暗号機能の基本オペレーションを実行する。例えば、
フレームワーク・タッチ・ポイント論理は、改策（ポリ
シー）カードの存在でそれらの機能を使用可能にする要
素中に見出される。

【００４５】・バス論理。バス論理53は、ホスト・シス
テム16に、いろいろなインターフェースで装置を結びつ
ける。２つのメイン・チャネルは、ホスト・システム側
へ出ている。制御チャネル42は、呼出システムと暗号ユ
ニットの間で、コマンドとステータス・メッセージのた
めに使用される。データ・チャネル44は、実際のデータ
転送を実行する。

【００４６】フレームワーク・ソフトウエア・アーキテ
クチャは、与えられたホスト・システム上でフレームワ
ーク要素を実行するために必要とされるライブラリおよ
びシステム・エレメントの層を説明する。図５は、主な
ソフトウエア・アーキテクチャ要素の概要を示す。

【００４７】アプリケーション。アプリケーション層55
は、暗号サービスを必要とするユーザ書込アプリケーシ
ョンとライブラリの領域である。アプリケーションは、
これらのサービスを認識している場合としていない場合
がある。認識している場合、下のサブシステム層56は、
アプリケーションに一組のプログラミング・インターフ
ェースを提供する。暗号を認識していないアプリケーシ
ョンは、自分自身で呼出しを発行せず、基本的なサブシ
ステムが、アプリケーションに代わってこれらの呼出し
を実行する。

【００４８】サブシステム・ライブラリ及びインターフ
ェース。認識のあるまた認識のないアプリケーションに
暗号機能を支援するサブシステム56は、アプリケーショ
ンにＡＰＩを提供する。

【００４９】大部分の有名なＡＰＩは、マイクロソフト
ＣＡＰＩ、Ｕｎｉｘ版Ｘ／ＯｐｅｎＧＳＳ‐ＡＰＩ、お
よびＧＣＳ‐ＡＰＩを含む。サブシステム・ライブラリ
は、一般的に、アプリケーション・プログラミング・イ
ンターフェースと、オペレーティングシステム57を介し
て保護される暗号サービス・プロバイダ・モジュールと
で構成される。

【００５０】また、サブシステム・ライブラリは、セキ
ュリティＡＰＩをアプリケーションから完全に隠す場合
がある。これによって、既存のアプリケーションが、修
正されることなくソリューションを利用することができ
る。その一例は、トランスポート・レベルのソフトウェ
ア・サブシステムへのセキュリティ機能の統合である。

【００５１】この層の他の要素は、暗号ユニットの安全
な記憶と実行機能にアクセスするＡＰＩを提供する。例
えば、ＯＤＢＣインターフェースのようなデータベース
ＡＰＩは、改変耐性データ・ベースを提供する暗号ユニ
ット内のデータ・マネージャ・モジュールに沿って、提
供される。

【００５２】オペレーティング・システムとドライバ。
オペレーティング・システム57は、２つの重要なタスク
を実行する。１つのタスクは、サブシステム・プログラ
ミング・インターフェースを暗号サービス・プロバイダ
から分離するものである。他のタスクは、ハードウェア
・ドライバの形で暗号ハードウェアとのインターフェー
スになる一組のドライバを介して、必要なハードウェア
制御を提供するものである。

【００５３】暗号ユニットサブシステム。この層59は、
暗号機能のハードウェア実行とファームウェア要素を含
む。ハードウェアは、異なるハードウェア・プラットホ
ームとパフォーマンス要求に適応するために、一般的
に、ＰＣＩカードやＰＣＭＣＩＡカードのような、いく
つかの形状的な要素で得られる。ファームウェアは、特
有のアプリケーション・プログラミング・インターフェ
ースによって要求される、ユーザがダウンロード可能な
ソフトウェア・モジュールのみならず、マイクロカーネ
ル、例えば、実行時間と、フレームワーク機能を実行す
る一組のライブラリである。

【００５４】管理。管理要素54は、全てのソリューショ
ンに対して管理フレームワークを提供する。これは、例
えば、証明管理、アプリケーション・サービス・クラス
管理、アプリケーション特有の拡張機能を暗号ユニット
にダウンロードするような管理上の機能のミドルウェア
構成装置を含む。

【００５５】フレームワークは、改策で営まれる暗号の
概念を導入する。アプリケーション・プログラミング・
インターフェースは、アプリケーション認証に基づいて
所望のサービスの選択を可能する。これは、現在有効な
暗号プログラミング・インターフェースと対照的であ
る。大部分の現在有効な暗号ＡＰＩは、暗号のコンテキ
ストの概念のまわりに造られる。アプリケーションが暗
号サービスを使用する前に、アプリケーションはこのコ
ンテキストを確立する。例えば、マイクロソフトＣＡＰ
Ｉは、暗号サービス・プロバイダ（ＣＳＰ）タイプの選
択を許可し、ソフトウェア・モジュールをシステムへロ
ードするプログラミング・インターフェースを提供す
る。アプリケーションは、ＣＳＰへの呼出しを作成する
ことができ、その場からそのサービスを使用することが
できる。しかしながら、アプリケーションが行っている
ことに基づいて暗号機能を識別する方法がない。

【００５６】本発明は、認証がアプリケーションの識別
を証明し、そのアプリケーションに割り当てられた利用
可能なサービスのクラスを判断するときに、それによっ
てアプリケーションが識別される方法を実行する。暗号
ユニットに認証を利用可能にするいくつかの方法があ
る。

【００５７】・それぞれの呼出しで渡される認証。認証
は、各々の呼出しでＣＳＰに渡される。この方式は、複
数の認証を渡すことのできるアプリケーションが、完了
すべきタスクに適当な認証を渡すことを可能にする。例
えば、アプリケーションが金融トランザクションのため
に強い暗号を使用し、それと同時に、電子メール機能の
ために弱い暗号を使用することが許可されているなら
ば、そのアプリケーションは、対応する認証を渡すこと
によって、動的に暗号のレベルを選択することができ
る。

【００５８】・初期化時に渡される認証。ＣＳＰとのリ
ンクが確立されるときも、認証は渡される。複数の認証
を使用するアプリケーションは、それぞれの認証に１つ
ずつ複数のコンテキストを確立することができ、暗号機
能呼出しにおいて適当なものを使用することができる。

【００５９】・暗示的に得られる認証。認証は、暗号層
に透過的に得られる。例えば、アプリケーションが、こ
れがそのアプリケーションに対する認証を含むレジスト
リに名前を渡し、インデックス付けするのに使用され
る。

【００６０】本発明は、アプリケーションが、アプリケ
ーションで許された暗号のレベルを最終的に定義するサ
ービスのクラスを要求する改策（ポリシー）方式を実行
する。この処理のキー要素は、アプリケーション認証、
サービスのクラス、及びそれらを管理するドメイン権限
を含む。

【００６１】図６は、これらの要素の高レベルの構成を
示す。図において、２つのドメイン権限がある。セキュ
リティ・ドメイン権限（Security Domain Authority,Ｓ
ＤＡ）62は、アプリケーション・ドメイン権限60に一組
のサービスのクラス（Classof Service,ＣＯＳ）63を許
可する責任がある。また、ＳＤＡは、ＣＯＳ情報および
暗号ユニット14に対するタッチポイント・データを含む
改策（ポリシー）カード12を発行する責任がある。ＳＤ
Ａは、ホスト・システム16に暗号ユニットを導入するサ
イトから請求があれば、この情報を作成する。

【００６２】アプリケーション・ドメイン権限（Applic
ation Domain Authority,ＡＤＡ）60は、ＳＤＡによっ
て与えられたＣＯＳ要素を受取る。ＡＤＡは、そのドメ
インに属しているアプリケーション65に、アプリケーシ
ョン認証64を発行する責務を有する。アプリケーション
認証は、アプリケーションＩＤ67とＡＤＡによって与え
られたＣＯＳ68を含む。

【００６３】アプリケーションは、所望のＣＯＳレベル
を得るために暗号ユニット14に提示する必要がある認証
をＡＤＡから受け取る。要求を受け取ると、暗号ユニッ
トは、その認証を使用してアプリケーションが要求する
暗号機能にアクセスする権利を持つかどうかを判断す
る。アプリケーション認証を介して要求されたＣＯＳ
は、ＳＤＡによってＡＤＡに与えられ、改策（ポリシ
ー）カードに記憶されているＣＯＳと一致するならば、
その要求は処理され、そうでなければ、処理されない。

【００６４】タッチポイント・データ69は、定義された
サービスのクラスに対して暗号ハードウェアを使用可能
にする改策（ポリシー）カードに記憶された情報であ
る。定期的に、この情報は、暗号ユニットによって再計
算され、改策（ポリシー）・カードによって確認される
必要がある。どのような不一致も、暗号ユニットの暗号
機能を停止させる。

【００６５】ネットワーク・セキュリティ・サーバ（Ｎ
ＳＳ）18は、改策（ポリシー）折衝および改策（ポリシ
ー）・カードに記憶されている改策（ポリシー）情報の
変更のためのオンライン装置としての働きをする。。例
えば、サービス・セットにサービスのクラスを追加する
ならば、通常、変更された情報で新しい改策（ポリシ
ー）・カードを発行する必要がある。代わりにＮＳＳは
ＳＤＡに代わって改策（ポリシー）カードの更新を実行
することができる。悪意のあるアプリケーションが許可
されていない方法で認証を使用するのを防止するため
に、アプリケーションは、それらの認証にしっかりと結
合される必要があることに注意することが重要である。

【００６６】本発明は、有効なサービスのクラスを含む
認証の形で、アプリケーション・ドメイン権限によって
与えられた、ある一定のレベルの暗号を、アプリケーシ
ョンが正しく実行することを確認する方法を提供する。
したがって、この認証とアプリケーションの強固な結合
は、本発明の鍵となる。この信頼性を確立する処理は、
本明細書中では、アプリケーション認証として参照され
る。

【００６７】図７は、本発明に従う、フレームワークの
認証要求を示すブロック図である。アプリケーション認
証は、アプリケーション65と暗号ユニット14の間で信頼
性を確立する２つの主な要素、即ち、アプリケーション
が有効なアプリケーションであるか（72）と、暗号ユニ
ットが有効な暗号ユニットであるか（74）を説明する。

【００６８】第１の部分は、改変をされなかったかどう
かを判断するため一部のデータを分析する処理を行う。

【００６９】一般に、２つの主なオブジェクト・クラス
が重要である。 ・第１のクラスは、プログラム・イメージ認証の主題を
扱う。 ・第２のクラスは、処理を一般化し、概念をいろいろな
データ・オブジェクトに適用する。

【００７０】暗号ユニット、即ち、改変耐性機能ユニッ
トの属性は、任意のデータ・オブジェクトの一般的な認
証方法の構築を可能にする。

【００７１】第２の部分は、アプリケーション全体から
フレームワークを見る、即ち、アプリケーションは、暗
号ユニットのアイデンティティを保証されなければなら
ない。この種類の信頼性を確立する処理は、ここで、暗
号ユニット確認(validation)として参照される。暗号ユ
ニット確認は、暗号ユニットがにせの暗号ユニットで置
き換えられるなどむやみに改変をされなかったことをア
プリケーションに保証する処理を行う。暗号ユニット確
認の処理の後、アプリケーションは、正しい暗号ユニッ
トが要求された暗号サービスを実行しているとみなすこ
とができる。

【００７２】重要なアプリケーションに対して、長い
間、アプリケーションがむやみに改変されなかったこと
を確認する必要があった。この確認の実行には、通常、
委託されたロード・サブシステムを含むことになる。委
託されたロード・サブシステムは、プログラム・イメー
ジをシステム・メモリ空間へロードする責任があるオペ
レーティング・システムの部分であり、そのようなロー
ドをする間にアプリケーションが改変されなかったこと
を確認する。

【００７３】プログラム・イメージにわたるチェックサ
ムのようなメカニズムは、この目的のためにたびたび使
用される。チェックサムが、アプリケーション導入時に
ローダ・サブシステムによって記憶されたチェックサム
と一致しないならば、ロードは失敗し、プログラム・イ
メージはロードされない。

【００７４】委託されたローダ・サブシステムは、オペ
レーティング・システムとの関係から独立して存在する
ことができない。ローダにアプリケーションが改変され
なかったことの確認を委託することは、オペレーティン
グ・システムがローダを信頼することを意味する。通常
ハードウェアの一部によって、システム・ブート時に確
認される委託されたカーネルは、アプリケーションがそ
の上を走る信託階層のコアを造る。

【００７５】認証の正しい使用を判断するコード・イメ
ージを確認することは、認証によって管理されるいかな
るオブジェクトも確認するように一般化される。例え
ば、ＪＡＶＡプログラミング言語を介してワールド・ワ
イド・ウェッブ・アプリケーションに対して提供される
ような、インターネット・アプレット(applet)は、ここ
で記述された方式を利用することができる。したがっ
て、使用され、またはアクセスされるオブジェクトに
は、認証が付随している。確認ステップは、委託された
ロード・サブシステムによってコード・イメージに対し
て実行されたステップに、非常に似ている。

【００７６】暗号ユニット確認は、暗号サービスを要求
するアプリケーションが、暗号ユニットのアイデンティ
ティについて保証される処理を説明する。このタスクを
達成することができるいくつかの方法がある。

【００７７】・暗号ユニットに挑戦する。この方法で
は、アプリケーションは、暗号ユニットに、暗号ユニッ
トだけが解決することができるパズルを発する。暗号ユ
ニットがこのパズルを解くことができれば、暗号ユニッ
トのアイデンティティの証明になる。

【００７８】・暗号ユニットは、アプリケーションが作
用するよう準備を行う。この方法において、アプリケー
ションは、ターゲット・システムにスクランブルされた
形式で送られる。例えば、２進イメージを暗号化するこ
とができる。正しい解読キーを持つ暗号ユニットのみ
が、アプリケーションを元に戻すことができて、それゆ
えに、これが有効な暗号ユニットになる。

【００７９】この第２の方法は、ソフトウェア著作権の
方式に付加的に適用できる。暗号化した形式でアプリケ
ーションをターゲット・サイドに送出し、暗号ユニット
にプログラムを解読させることは、暗号ユニットが有効
な暗号ユニットであることを明らかにするだけでなく、
ソフトウェア製作者がその特有の暗号ユニット、即ちホ
スト・システムに合うように調整されたアプリケーショ
ンを送り出すことを可能にする。残念なことに、一度解
読されるとアプリケーション・イメージはクリアな形で
得られ、それをほんの僅かの労力または全く労力を要さ
ずに他のシステムにコピーすることができる。

【００８０】本発明は、ここでソフトウェア・レベル・
タッチポイントとして参照される、著作権保護の方式だ
けでなく暗号ユニット確認の面からの両方でアドレスす
る方法を含む。ソフトウェア・レベル・タッチポイント
の概念を、以下に詳細に説明する。

【００８１】アプリケーション認証は、アプリケーショ
ン・イメージと、アプリケーション・ドメイン権限によ
って発行されたアプリケーション認証の間を強固に結合
することを確実に行う処理である。アプリケーション認
証の処理は、２つの別個のステージで示すことができ
る。それらは、導入ステージと実行ステージである。以
下に、これらのステージの概要を示す。

【００８２】・導入ステージ。導入ステージは、アプリ
ケーションと付随する認証を、暗号ユニットに導入する
ために必要なステップを示す。

【００８３】・実行ステージ。確認ステージは、確認要
求とともに渡された認証に基づいて、アプリケーション
のアイデンティティを確認するために与えられたステッ
プを示す。確認の完了後、アプリケーションは実行ステ
ージを入力する。このステージの間いつでも、暗号ユニ
ットは、アプリケーションの要求を再確認するために、
確認要求を発することができる。

【００８４】図８は、アプリケーションが本発明による
暗号ユニットにそれ自体を導入することを示す。認証さ
れたアプリケーションは、アプリケーション導入ステー
ジでホスト・システムに導入される。認証されたアプリ
ケーションは、アプリケーション・イメージ、すなわち
コード・ファイル65と、アプリケーション・ドメイン権
限60によって発行された認証64とから成る。導入ステー
ジの結果は、アプリケーション、暗号ユニット、及び有
効なサービスのクラスを特異に示すアプリケーション信
任状90である。この結果は、ここでアプリケーション信
任状として参照される。

【００８５】導入処理の目的は、暗号ユニットにアプリ
ケーションを導入することである。特別なユーティリテ
ィ・プログラム、即ち導入プログラムが、必要なワーク
を実行するために呼出される。このユーティリティが実
行するメイン・タスクは、プログラム・イメージとアプ
リケーション認証に対する照合を、暗号ユニットに渡
す。

【００８６】導入の要求を受取った上で、暗号ユニット
は、プログラム・イメージからハッシュ値を計算するた
めに、ホスト・システム・メモリ・アクセス機能を使用
する。アプリケーション認証は、他の情報の中で、この
アプリケーションに対して定義されたサービスのクラス
を含む。情報のこれらの２つの要素を使用して、暗号ユ
ニットは、例えば、名前、アプリケーション・イメージ
のハッシュ値(hash value)、及びアプリケーションに対
して定義されたサービスのクラスなどを介して、アプリ
ケーションを識別する信任状を生成する。

【００８７】それから、その信任状は暗号ユニットによ
って署名され、暗号ユニット内のローカル不揮発性メモ
リに記憶される。場合によっては、信任状は外部の記憶
領域に出される。それらの信任状が、それらを生成した
暗号ユニットのみに有用なだけなので、暗号ユニットの
境界外では、その信任状が改変されないことを確保する
ことが必要とされるだけである。

【００８８】実行ステージにおいて、アプリケーション
は、オペレーティング・システムによってメモリ・シス
テムへロードされ、実行が開始される。アプリケーショ
ンの実行におけるいくつかのポイントで、アプリケーシ
ョンは、暗号サービスを要求する。一般的に、第１のス
テップは、暗号ユニットでコンテキストを確立すること
である。それが論理的な関係、例えば、暗号コンテキス
トを確立するとき、アプリケーションは、ＡＤＡによっ
て発行されたアプリケーション認証を暗号ユニットに渡
す。

【００８９】図９は、本発明の実行ステージの実行ステ
ップを示す。関係を確立する要求を受取ると、暗号ユニ
ット14は、渡された認証に基づいて、アプリケーション
のアイデンティティを確認する必要がある。オペレーテ
ィング・システム構成要素を介して、暗号ユニットは、
アプリケーション・イメージにアクセスして、アプリケ
ーションの署名を算出することができる。例えば、ＤＭ
Ａ機能とメモリ・システム内のアプリケーションのメモ
リ・アドレス範囲についての知識を使用して、暗号ユニ
ットは、ハッシュ値を算出することができる。

【００９０】認証の正当性を確認した後、暗号ユニット
は、その認証に対応するアプリケーション信任状の場所
を見つけるために、その認証を使用する。その信任状
は、とりわけ上述の導入処理から算出されたアプリケー
ション・イメージの署名を含む。もし値が一致するなら
ば、２つの重要な事実を導き出すことができる。 ・第１に、このイメージ上の算出された署名が導入時に
算出された署名と一致するので、アプリケーションのア
イデンティティが確立される。 ・第２に、アプリケーションは導入ステージから改変さ
れていない。

【００９１】この最初の確認ステップの後、アプリケー
ションは、暗号オペレーションを要求している暗号ユニ
ットに、呼出しを発行することができる。その後に、暗
号ユニットは、再び確認処理の実行を決定することがあ
りえる。そのオプションは、定期的に確認することか
ら、各要求ごとに確認することまである。

【００９２】オペレーティング・システムの見通しから
は、この方式を実行するためにローダおよびオペレーテ
ィングへの変更は必要ない。必要とされる唯一の要求
は、オブジェクトのメモリ・イメージにアクセスする機
能である。しかしながら、実行は、確認ステップを実行
するために、アプリケーション・ロード時に、暗号ユニ
ットを起動することを決定する場合がある。

【００９３】上述した方式は、コード・イメージだけで
なく、概説した確認方法を使用することができるどんな
種類のデータ・オブジェクトもカバーするように、容易
に拡張することができる。例えば、そのオペレーティン
グ・システム自体、サブシステム・ライブラリ、及び静
的構成情報は、ここで説明した方式を使用することによ
って、未許可の修正や置換から保護することができる。

【００９４】ソフトウェア・タッチポイントは、前処理
されるまでは、ホスト・システム環境にとって使用する
ことのできないデータの領域である。ソフトウェア・タ
ッチポイントの１つの例は、ホスト・システムの命令フ
ェッチ・ユニットがうまくそれらをデコードすることが
できないような形態に変形されたコード・イメージにお
ける命令シーケンスを含む。同様に、オリジナル・デー
タがアクセスできないような形態に変更されたデータ領
域もありうる。

【００９５】図１０は、本発明のソフトウェア・タッチ
ポイントの概要を示す。ソフトウェア・タッチポイント
100は、オブジェクトのアドレス範囲とタッチポイント
の長さの範囲内の開始アドレス101によって特徴づけら
れる。ソフトウェア・タッチポイントには、いくつかの
クラスがある。 ・データ・レベル・タッチポイントは、データ・オブジ
ェクトの内側に領域を記述する。タッチポイントに関す
るこれ以上の情報は、このタッチポイントについてのデ
ータ・オブジェクトには記録されない。別の領域は、デ
ータ・オブジェクトの外側に、これらのタッチポイント
を記述する。 ・命令レベル・タッチポイントは、命令ストリームの内
側に、タッチポイントを記述する。

【００９６】２つのサブ・クラスがある。 −第１のサブクラスは、それらのデータ・レベルの対応
物に類似する命令レベル・タッチポイントを記述する。
この場合、命令ストリームのある領域は、タッチポイン
ト情報によって置き換えられる。 −第２のサブクラスは、構造を有する命令レベル・タッ
チポイントを記述する。構造化タッチポイントは、タッ
チポイント領域103の境界を定める特殊命令で開始し、
終了する。

【００９７】これらのタイプのタッチポイントの全て
を、以下に詳述する。２つのタイプの命令レベル・タッ
チポイント。 ・命令レベル・タッチポイントの第１のタイプは、スク
ランブルされたバージョンによって置き換えられる命令
ストリームのデータ領域として、命令レベル・タッチポ
イントを実行する。これ以上の情報は、そのロケーショ
ン自体で、タッチポイントについて得られない。 ・命令レベル・タッチポイントの第２のタイプは、開始
時には別個の命令でタッチポイントを実行し、タッチポ
イント領域の終わりには命令を実行する。２つのタッチ
ポイント領域を区別するために、タッチポイントの第１
のタイプが構造化されていないタッチポイントとして参
照され、タッチポイントの第２のタイプが、構造化され
たタッチポイントとして参照される。

【００９８】図１０は、本発明のソフトウェア・タッチ
ポイントの概要を示す。タッチポイント103は、アドレ
ス範囲スタート101とアドレス範囲エンド102を有してい
るソフトウェア・オブジェクト100の範囲内にある。

【００９９】図１１は、本発明の構造化されていない、
および構造化された命令レベル・ソフトウェア・タッチ
ポイントを示す。例えば、ｔｐ＿ｓｔａｒｔ110とｔｐ
＿ｅｎｄ111の命令は、タッチポイント領域103の境界を
定めることができる。両者間の情報は、オリジナル命令
シーケンスに変換されるタッチポイント・データであ
る。命令レベル・タッチポイントの場合、両者間のデー
タは、命令を含む。境界命令は、暗号ユニットにトラッ
プをかけ、タッチポイント領域を解かせ、命令シーケン
スが実行されたあと、再びそれを元の場所に戻させるこ
とができる。境界を定められた領域内の命令のシーケン
スは、原子的に実行される命令のシーケンスである。こ
れによって、オペレーティング・システム例外を除い
て、タッチポイント領域103にアクセスする他のいかな
るコードも、実行されないことを確保する。

【０１００】代わりに、このタッチポイントは、ＣＰＵ
の命令取出しユニット内のデコーディング機能として実
行されることがある。改策（ポリシー）・レジスタは、
コンテキスト・スイッチに、このアプリケーションに必
要なデコーディング・キーを記憶する。この方法の利点
は、他のシステムでそのコードが使用できないようにす
る利点と組み合わせられる、タッチポイントの透過性を
含む。

【０１０１】構造化されていない命令レベル・タッチポ
イントと同様に、どんな種類の定数データも、この方式
によって保護される。

【０１０２】暗号ユニット確認処理。アプリケーション
は、暗号ユニットの正しさについて保証される必要があ
る。その目的は、アプリケーション要求が異なる暗号機
能に向け直されるというシナリオを避けることにある。
暗号ユニット確認処理は、暗号ユニットのアイデンティ
ティについて、アプリケーションを保証するために取ら
れるステップを記述する。以下に記述される確認処理
は、ここで記載したソフトウェア・レベル・タッチポイ
ントを使用する。

【０１０３】暗号ユニット確認は、３つの別個のステー
ジを進む。 ・作成ステージ。作成ステージは、そこに含まれるソフ
トウェア・レベル・タッチポイント情報を有しているア
プリケーションを生成するために、アプリケーション作
成サイドで取られる必要があるステップを記述する。

【０１０４】・導入ステージ。導入ステージは、アプリ
ケーションおよびこれに付随する認証を暗号ユニットに
導入するために必要なステップを記述する。導入のタイ
プに従って、ソフトウェア・レベル・タッチポイント
は、このステージで削除されるか、または実行時に、分
析されたアプリケーション・イメージ内でそのままにさ
れる。

【０１０５】・確認ステージ。確認ステージは、確認要
求とともに渡された認証に基づいたアプリケーションア
イデンティティを確認するために取られたステップを記
述する。確認の完了後、アプリケーションは、（上述し
た）実行ステージを入力する。このステージの間いつで
も、暗号ユニットは、アプリケーションの要求を再確認
するために確認要求を発することができる。これらのア
プリケーション認証ステップに加えて、アプリケーショ
ンに導入されたソフトウェア・レベル・タッチポイント
は、それらがホスト・システム・プロセッサに遭遇する
ときに、削除されるか、動的に変換される必要がある。
これは、それらが導入ステージの間に削除されなかった
場合だけである。

【０１０６】以下に概説する暗号ユニット確認処理は、
暗号ユニット確認の主目的を超える付加的な利点を可能
にする。ソフトウェア製作者の立場から、著作権保護
は、ますますネットワークの世界で重要になっている。
したがって、ソフトウェア製作者は、顧客に送られたソ
フトウェアが他のシステムにコピーされないことを保証
されたいと願う。

【０１０７】ソフトウェアが有効なグループの権限のあ
るシステムだけにロードされることを確保することか
ら、正確に１つのシステムのみでソフトウェアをカスタ
マイズすることまでの範囲が要求される。

【０１０８】図１２は、本発明による、製作ステージの
間に実行されるステップを示す。製作ステージにおい
て、アプリケーション65は、アプリケーション製作者12
0によって作成される。この目的は、特有のグループの
ターゲット・システムか単一ターゲット・システムに合
うように調整されるアプリケーションを造ることであ
る。ターゲット・システムは、そこに導入された暗号ユ
ニットによって識別される。

【０１０９】第１のアプリケーション製作者が先ずアプ
リケーションを開発する。これは、ターゲット・ホスト
・システム・プラットホームのためのアプリケーション
の実行可能なバージョンである。アプリケーションがタ
ーゲット・ホスト・システムに送られる前に、カスタマ
イズ・ステップ122は、ソフトウェア・レベルのタッチ
ポイントを導入する。導入の後、アプリケーション165
が出荷される。上述の図で表示されたカスタマイズ構成
要素は、タッチポイントをアプリケーション・イメージ
に導入する責任がある。

【０１１０】ＡＤＡは、アプリケーション製作者が常駐
するドメイン権限である。ＡＤＡ60は、タッチポイント
をアプリケーション・イメージに導入するために使用さ
れた機能を規定するサービス・クラス123をＳＤＡ62か
ら与えられる。

【０１１１】タッチポイント導入の一部分は、ロケーシ
ョンのリストと、コード・イメージ内のタッチポイント
領域の長さを生成するためのものである。構造化されて
いない命令レベル・タッチポイントの場合、この情報
は、タッチポイントの場所を見つけるために必要とされ
る。構造化された命令レベル・タッチポイントにとっ
て、この情報は、厳密には必要でない。また、どこにタ
ッチポイントが置かれ、シーケンスの長さがどれくらい
かを正確に考慮する必要がある。構造化されていないタ
ッチポイントでは、それらが正確に、コード・イメージ
のどこに置かれるかという問題は、さほど重要なことで
はない。

【０１１２】技術的に、タッチポイントを、イメージの
どんな領域にでも置くことができる。構造化されたタッ
チポイントには、より多くの制約がある。例えば、タッ
チポイントが、プロシージャ境界を横切らない、または
命令の複数の基本ブロックを上書きしないといった制約
がある。その制約は、構造化されたタッチポイントのハ
ードウェア・レベル・サポートの本質に依存する。これ
らのいくつかは、ソフトウェア・レベル・タッチポイン
トのハードウェア・サポートと関連して以下に記述され
る。

【０１１３】製作ステージの終わりは、ソフトウェア・
レベルのタッチポイントで増やされたアプリケーション
・イメージがある。ＳＤＡによってアプリケーション製
作者のＡＤＡに与えられた権利に従ってカスタマイズさ
れた構成要素によって、ＣＯＳが暗号ユニットのために
イネーブルされたので、タッチポイントは、正しい方法
で、イメージに入れられる。この処理は、この時点で、
ターゲット・システムに関する情報を含まない。タッチ
ポイント情報導入処理を逆に行うことができる導入は、
ワーキング・アプリケーションを導出することができ
る。ターゲット・システムに合うように更に調整するこ
とは、このシステムについての更なる知識を必要とす
る。これが製作者とターゲットの受け側の間のより強固
な依存関係を導くので、より高度の労力が管理面で必要
となる。

【０１１４】以下の説明で、製作者とターゲット・シス
テムの間の一定レベルの独立性についてのより一般的な
場合を、最初に紹介する。その後に、この強固な結合に
ついて、より詳細に記述する。

【０１１５】導入ステージは、このシステム上でアプリ
ケーションの使用を準備するために必要なターゲット・
サイト、即ち特定の暗号ユニットをもつホスト・システ
ムで取られるステップを記述する。また更に、いくつか
の目的がある。

【０１１６】第１の目的は、アプリケーションが暗号ユ
ニットの完全性について保証されることを確保すること
である。アプリケーション・イメージを処理するために
必要なＣＯＳを許可される暗号ユニットだけが、うまく
このイメージを有益なものに変換することができるとい
うことによって、この保証は達成される。

【０１１７】第２の目的は、アプリケーションが一度タ
ーゲット・システムに導入されたならば、それはこのシ
ステムによってのみ使用可能であり、他のシステムにコ
ピーされることができないことを確保することである。

【０１１８】図１３は、本発明によって、導入ステージ
の間、実行されるステップを示す。インストーラ構成要
素130は、アプリケーションをターゲット・システムに
導入する責務がある。導入処理の一部分として、ＣＯＳ
を記述するアプリケーションの信任状132が作られる。
この処理の詳細は、アプリケーション認証と関連して上
記で説明した。導入処理の他の部分はこれが有効な暗号
ユニットであるということを証明し、導入処理によって
使用された暗号ユニットの組み合わせ以外のものを使用
することができないアプリケーション・イメージを造る
ために必要なステップを実行する。

【０１１９】ＳＤＡ(Security Domain Authority)62
は、ＡＤＡ60にＣＯＳ123のセットを与える。ＡＤＡ
は、一組のＣＯＳにアプリケーションの権利を与える。
改策（ポリシー）12は、ＡＤＡの有効なＣＯＳと、アプ
リケーション製作者のＡＤＡに許可されたようなインス
トーラのＣＯＳとを含む。

【０１２０】したがって、そうするようにＣＯＳを許可
するならば、導入構成要素130は、アプリケーション・
イメージのタッチポイントを処理するだけである。

【０１２１】タッチポイントは、理論的に、導入ステー
ジで削除される。しかしながら、このステージでアプリ
ケーション・イメージからそれらを削除することは、２
つの結果を導く。第１に、アプリケーションは、導入時
に、その暗号ユニットが有効な暗号ユニットであるとい
う一時の保証だけを有する。タッチポイントの削除後、
アプリケーションが暗号サービスを要求するとき、他の
暗号ユニットは、他の改策（ポリシー）・カードで導入
されるか、または無視される。第２に、タッチポイント
がなければ、アプリケーションは、クリアであり、コピ
ーできて、どんな他のシステムでも実行できる。このよ
うな事態を防止するために、タッチポイントは、実行サ
イクルで、できるだけ遅く削除される。

【０１２２】実行ステージにおいて、アプリケーション
は、ホスト・システムで実行される。オペレーティング
・システム・ローダは、アプリケーション・ファイルイ
メージを実行可能なメモリ・イメージに変換する。処理
の一部分は、アプリケーションが導入時から変更されて
おらず、一定のサービスのクラスを正当に要求している
ことを確認する要求を処理する。このことを確保するた
めに取られたステップは、アプリケーション認証と関連
して上述した。暗号ユニット確認部分に対して、追加の
ステップが必要となる。

【０１２３】図１４は、本発明によって、実行ステージ
の間、実行されるステップを示す。（ローダ・ユーティ
リティ140と演算処理装置142を介する）アプリケーショ
ン・ロード時に、２つの主目標がアドレスされる必要が
ある。暗号ユニットを確認する第１の目標。このタスク
は、アプリケーションからソフトウェア・タッチポイン
トを解くことができる暗号ユニット14によって達成され
る。例えば、暗号ユニットがタッチポイントのないアプ
リケーションのオリジナル・署名を算出することができ
るならば、このオペレーションを実行するためにＣＯＳ
が与えられるので、暗号ユニットは、うまくそれらを削
除することができ、したがって、それが有効な暗号ユニ
ットであるということが確認される。第２の目標は、タ
ッチポイントを解くすることである。タッチポイントを
含むアプリケーション部分が実行される前に、暗号ユニ
ットは、タッチポイントを削除する責任がある。

【０１２４】最も単純な場合は、暗号ユニットがアプリ
ケーション・コード・イメージからタッチポイントを削
除することである。他のシステムにコピーされるなら
ば、プログラムのファイル・イメージは、まだタッチポ
イントを含み、役に立たない状態となっている。しかし
ながら、メモリ部分はクリアであり、悪意があるユーザ
がメモリ・イメージからファイル・イメージを造るコピ
ー・プログラムを書けば、コピーされうる。そのような
タスクは、いくつかの技術と基本となるオペレーティン
グ・システムについての知識を必要とするが、不可能な
ことではない。

【０１２５】他の方法は、タッチポイントをそのままに
しておき、それらと遭遇するときに解くことである。こ
の方法は、タッチポイントを見つけるために、いくつか
のハードウェア支援に依存する。この種類のタッチポイ
ント解法に対するシナリオは、ソフトウェア・レベルの
タッチポイントのハードウェア支援と関連して上述し
た。

【０１２６】個別の暗号ユニットに合わせる調整。今ま
でに記述した処理は、ソフトウェア製作者のソフトウェ
ア構成要素と、それが導入される暗号ユニットによって
識別されるターゲット・システムの間に、密接した関係
を確立しない。むしろルーズな結合の利点として、製作
者は、アプリケーション内に導入されたタッチポイント
を処理する機能を有するシステムに導入されるアプリケ
ーションを作成することができる。ターゲット・システ
ムについてのこれ以上の知識は、必要でない。

【０１２７】より強固な結合を要求するならば、アプリ
ケーション製作者は、ターゲット・システム暗号ユニッ
トにアプリケーション構成要素が合うように調整する必
要がある。例えば、これは、製作者のＡＤＡとＳＤＡの
間で共有される固有のＣＯＳを生成することによってな
される。ターゲット・システム暗号ユニットのためにカ
スタマイズされるとき、ＳＤＡは、固有のＣＯＳを改策
（ポリシー）・カードに導入し、そのＣＯＳをアプリケ
ーション製作者のＡＤＡと共有する。その固有のＣＯＳ
を与えられたターゲット・システム上の導入ユーティリ
ティだけが、ソフトウェアをターゲット・システム上
に、うまく導入することができる。

【０１２８】認証および暗号ユニット確認のためのホス
ト・システム・ハードウェア支援。ソフトウェア・レベ
ルのタッチポイントは、ホスト・システムＣＰＵからの
ハードウェア支援の利点となる。図１５は、本発明によ
って、ソフトウェア・タッチポイント解法に関するメモ
リ階層を示す。ホスト・システム16は、トラスト境界15
2によってメモリ・サブシステム153とディスク・サブシ
ステム154から分離されるプロセッサ・レジスタ・ファ
イルとキャッシュ・サブシステム151を有する。ここで
表示されたシステム・アーキテクチャが、実施例の目的
に提供され、本発明が容易に他のシステム・アーキテク
チャに適用できることがわかる。

【０１２９】以下に、実行を支援するために必要とされ
たホスト・システム・プロセッサ・メカニズムを記述す
る。主な概念は、ホスト・システム・プロセッサ実行要
素により近いタッチポイントの分解処理を適用すること
である。プロセッサの近く、例えばキャッシュ・サブシ
ステムに、分解処理を移動することによって、クリアな
タッチポイント領域は、メイン・メモリ・システムやメ
モリ階層の下位レベルの記憶素子に存在しなくなる。

【０１３０】ソフトウェア・レベル・タッチポイントを
扱う２つの主な方法がある。 ・第１の方法において、ホスト・プロセッサはソフトウ
ェア・タッチポイントを解く暗号ユニットを起動するソ
フトウェア・タッチポイントの検出に、例外を生成す
る。 ・第２の方法は第１の方法と同様であるが、実際のオペ
レーションで、ホスト・システム演算処理装置を使用す
る。さらに、両方の方法は、ソフトウェア・タッチポイ
ントが構造化されているか、または構造化されていない
かに従って、再分割できる。

【０１３１】構造化された命令レベル・タッチポイント
の暗号ユニット方法のトラップ。暗号ユニット方法のト
ラップにおいて、タッチポイント・スタート命令に出会
うと、ホスト・システム・プロセッサは、例外を発生す
る。例外ハンドラは、タッチポイントを削除して、実行
可能命令でタッチポイント・データを置き換えるために
暗号ユニット構成要素を起動する。それから、ホスト・
システム・プロセッサは、アプリケーションの実行を続
ける。タッチポイント・エンド命令を見つけると、ホス
ト・システム・プロセッサは、再びトラップをかけ、暗
号ユニットは、メモリ・イメージをタッチポイント状態
に再び戻すように変換する。

【０１３２】図１６は、本発明によって、ソフトウェア
・タッチポイント分解に関してメモリ階層を示す。ホス
ト・システム・プロセッサ161は、暗号ユニット14が起
動されるようになる例外を発生するためにｔｐ＿ｓｔａ
ｒｔ命令を使用する。そして、暗号ユニットは、タッチ
ポイント103のメモリ・アドレス範囲とメモリ領域につ
いての知識を与えられ、タッチポイント本体をホスト・
システム・プロセッサによって実行される命令シーケン
スに変換する。それから、制御は、ホスト・システム・
プロセッサに戻される。

【０１３３】タッチポイントがこの様式で変換される
と、他のアプリケーション・インスタンスは、潜在的に
タッチポイント領域にアクセスすることができる。した
がって、この領域内に許可されたアプリケーション・コ
ンテキスト・スイッチングがないという重要な領域とし
て、タッチポイントを実行することは重要である。タッ
チポイント命令シーケンスの終了で、ｔｐ＿ｅｎｄ命令
は、暗号ユニットがタッチポイント・データを元の状態
に戻すことができるように、暗号ユニットにトラップを
発生する。

【０１３４】構造化された命令レベル・タッチポイント
のホスト・システム・プロセッサ構成要素の使用。この
方法において、ホスト・システム・プロセッサが、命令
取出しの間、デコードをタッチポイントに変換すること
を許可する論理構成要素を組み込むと仮定する。タッチ
ポイント・スタート命令に出会うと、ホスト・システム
・プロセッサは、プロセッサ・キャッシュ内でタッチポ
イント・データを変換し、実行を継続する。メモリ・イ
メージには変化が起きない。タッチポイント・エンド命
令に出会うと、キャッシュ・ラインは、フラッシュされ
るか、将来の使用のために残される。この方式を支援す
るために、タッチポイントは、キャッシュ境界上に配列
され、キャッシュ・ライン・サイズの倍数である必要が
ある。

【０１３５】図１７は、本発明によって、ホスト・シス
テム・プロセッサ内の命令レベル・タッチポイント支援
を示す。ホスト・システム・プロセッサ命令取出しユニ
ット171、ホスト・システム第１取出し、及び変換によ
って、ｔｐ＿ｓｔａｒｔ命令を見つけると、１又は複数
のキャッシュ・ラインは、ホスト・システム処理装置制
御レジスタ172に記憶されるキーを使用するタッチポイ
ント領域を含む。各々のアプリケーションは、タッチポ
イント領域を分解するために異なるｔｐ＿ｒｅｇ値を有
する。ｔｐ＿ｒｅｇ値は、アプリケーションをホスト・
システムに導入するために使用されるＣＯＳ＿ＴＰの一
部分である。コンテキスト・スイッチでのｔｐ＿ｒｅｇ
制御レジスタのロードは、情報のキーパとして暗号ユニ
ットを含む。また、コンテキスト・スイッチの間、ｋｅ
ｙ＿ｒｅｇ値を暗号ユニットを起動することなくロード
することができるように、ｋｅｙ＿ｒｅｇ値は、アプリ
ケーション・コンテキスト状態の一部分である。

【０１３６】構造化されていない命令レベル・タッチポ
イントとデータ・レベル・タッチポイントのための方
法。構造化されていない命令レベル・タッチポイントと
データ・レベル・タッチポイントは両方とも、タッチポ
イント領域で、タッチポイントについてのメタ情報の欠
如によって特徴づけられる。このクラスのソフトウェア
・タッチポイントの方法は、２つのステップに再分割で
きる。 ・第１のステップは、これらのタッチポイントの検出を
含む。 ・第２のステップは、ホスト・システム・プロセッサが
その領域にアクセスする前に、タッチポイントを解くす
ることを含む。

【０１３７】タッチポイント領域を見つけるために、メ
カニズムは、ホスト・システム演算処理装置にタッチポ
イントの領域に関する情報を伝播するためのソフトウェ
ア環境とハードウェアの両方に、位置するようにならな
ければならない。例えば、タッチポイント領域のデータ
の塊が、ホスト・システムの仮想記憶システムのページ
サイズ上にあるように選ばれるならば、タッチポイント
領域に関する情報は、ページ・テーブルと変換ルック・
アサイド・バッファを介して、ホスト・システム・プロ
セッサに伝達される。

【０１３８】アドレス変換の間、ホスト・プロセッサ
は、変換されたアドレス範囲がソフトウェア・タッチポ
イントを含むかどうかを検出することができる。ホスト
・システム・プロセッサによる実行か、またはタッチポ
イント・ページからのアクセスのために、キャッシュ・
ラインをロードしているとき、タッチポイント領域は、
（上述したように）キャッシュ・サブシステム内で解か
れる。同様の技術は、解かれたタッチポイント領域がキ
ャッシュ・ラインの中で維持され、それらを含むオブジ
ェクトのメイン・メモリやディスク・イメージにアクセ
スできないように適用する。それらがもはや必要とされ
ないときはいつでも、読取り専用キャッシュ・ライン
は、フラッシュされる。それらがメイン・メモリ・シス
テムへ書き戻される前に、修正されたキャッシュ・ライ
ンは、元に戻すように変換される必要がある。

【０１３９】本発明は例として次の実施態様を含む。 （１）アプリケーションを認証する装置であって、アプ
リケーションに少くとも１つのサービスのクラスを与え
るセキュリティ・ドメイン権限と、前記セキュリティ・
ドメイン権限によって許可された前記サービスのクラス
を受取るアプリケーション・ドメイン権限と、前記アプ
リケーション・ドメイン権限によって、アプリケーショ
ン・ドメイン権限のドメインに属するアプリケーション
に発行された少くとも１つのアプリケーション認証と、
を備える前記装置。 （２）前記アプリケーション認証は、アプリケーション
ＩＤと、前記与えられたサービスのクラスとを含む
（１）記載の装置。 （３）さらに、前記アプリケーションが要求された機能
にアクセスする権利を有するかどうか判断するために前
記アプリケーション認証を受取る演算処理装置を含む、
（１）記載の装置。 （４）さらに、前記許可されたサービスのクラスのため
に前記演算処理装置を使用可能にする改策（ポリシー）
を有し、前記改策（ポリシー）と前記演算処理装置とに
不一致があると、、前記演算処理装置を無効にすること
を特徴とする（３）記載の装置。

【０１４０】（５）アプリケーション・ドメイン権限に
よって与えられた、あるレベルの機能をアプリケーショ
ンが正当に実行することを確認する方法であって、有効
なサービスのクラスを含む認証を発行するステップと、
前記アプリケーションとターゲット・プロセッサの間の
信頼関係を確立するため前記アプリケーションを前記認
証にしっかりと結合するステップと、を有する前記方
法。 （６）処理サービスが演算処理装置のアイデンティティ
について保証されることを要求するアプリケーションに
おける、前記演算処理装置の確認方法であって、前記演
算処理装置にチャレンジするステップと、前記演算処理
装置に、前記演算処理装置のみが解くことができるパズ
ルを発行するステップと、を有し、前記パズルを解く前
記演算処理装置の能力は、前記演算処理装置のアイデン
ティティの証拠であることを特徴とする、前記方法。 （７）処理サービスが演算処理装置の識別について保証
されることを要求するアプリケーションにおける、前記
演算処理装置の確認方法であって、ターゲット・システ
ムにスクランブルされた形式で前記アプリケーションを
送るステップと、機能的に前記アプリケーションを準備
するために、前記演算処理装置を使用するステップと、
を有し、正しいキーを有する演算処理装置だけが、前記
アプリケーションを元に戻すことができ、それによっ
て、その前記演算処理装置を有効な演算処理装置に確立
することを特徴とする前記方法。

【０１４１】（８）アプリケーション・イメージと、ア
プリケーション・ドメイン権限によって発行されたアプ
リケーション認証とを強固に結合する認定されたアプリ
ケーションを生産する方法であって、前記アプリケーシ
ョンを導入して、付随する証明をターゲット演算処理装
置に届ける導入ステージを実行するステップと、確認要
求による前記認証の受渡しに基づいて、前記アプリケー
ションのアイデンティティを確認する確認ステージを実
行するステップと、確認の完了後、前記演算処理装置が
前記アプリケーションを再確認するために確認要求を発
行することができる間に、実行ステージを入力するステ
ップと、を有する前記方法。 （９）さらに、前記導入ステージで、前記ターゲット・
プロセッサに認められたアプリケーションを導入するス
テップを含む、（８）記載の方法。 （１０）前記認定されたアプリケーションは、前記アプ
リケーション・イメージと、アプリケーション・ドメイ
ン権限によって発行された前記認証と、を含む（８）記
載の方法。 （１１）前記導入ステージは、前記アプリケーション、
前記ターゲット・プロセッサ、及び前記アプリケーショ
ンの有効なサービス・クラスを個別に示すアプリケーシ
ョン信任状を生成することを特徴とする（８）記載の方
法。 （１２）要求を導入で受取るステップと、ハッシュ値を
前記アプリケーション・イメージから前記ターゲット・
プロセッサで算出するステップと、前記ハッシュ値と、
前記アプリケーション認証に対して定義されたサービス
のクラスを使用して前記アプリケーションを識別する信
任状を生成するステップと、を含む（８）記載の方法。 （１３）前記ターゲット・プロセッサで前記信任状に署
名するステップと、ローカル・メモリに前記信任状を記
憶するステップと、を含む（１２）記載の方法。

【０１４２】（１４）アプリケーションを認証する装置
であって、アプリケーション・ドメイン権限のドメイン
に属している少くとも１つのアプリケーションに、アプ
リケーション・ドメインの権限によって発行された少く
とも１つのアプリケーション認証と、前記アプリケーシ
ョン、ターゲット・プロセッサ、前記アプリケーション
の有効なサービス・クラスを個別に示す前記アプリケー
ション認証と、前記アプリケーション認証を受取り前記
アプリケーションが要求された機能にアクセスする権利
を有するかどうかを判断するターゲット・プロセッサ
と、を備える前記装置。 （１５）前記アプリケーション証明は、アプリケーショ
ンＩＤと、前記有効なサービス・クラスの認可を含む、
（１４）記載の装置。 （１６）アプリケーションに少くとも１つのサービス・
クラスを与えるセキュリティ・ドメイン権限を有する
（１４）記載の装置。 （１７）セキュリティ・ドメイン権限によって与えられ
たサービス・クラスを受取るアプリケーション・ドメイ
ン権限を有する（１４）記載の装置。 （１８）与えられたサービス・クラスに対して前記ター
ゲット・プロセッサを使用可能にする改策（ポリシー）
を有し、前記改策（ポリシー）と前記ターゲット・プロ
セッサと間の不一致があると、前記ターゲット・プロセ
ッサを無効にすることを特徴とする（１４）記載の装
置。

【０１４３】（１９）変換されない限り、ホスト・シス
テム環境によって有効にされないソフトウェア・タッチ
ポイントを含む（１４）記載の装置。 （２０）前記ソフトウェア・タッチポイントは、前記ホ
スト・システムの命令取出しユニットがうまくそれらを
デコードすることができないような方法で変換されたコ
ード・イメージの命令シーケンスを含む（１９）記載の
装置。 （２１）前記ソフトウェア・タッチポイントは、オリジ
ナル・データをアクセスできない方法で変更されたデー
タ領域を含む（１９）記載の装置。 （２２）前記ソフトウェア・タッチポイントは、データ
・オブジェクト内に領域を記述するデータ・レベル・タ
ッチポイントを含む（１９）記載の装置。 （２３）前記ソフトウェア・タッチポイントは、命令ス
トリーム内にタッチポイントを記述する命令レベル・タ
ッチポイントを含み、ここで、命令ストリーム中の領域
が、前記タッチポイントによって置き換えられるか、あ
るいは、前記タッチポイントが、タッチポイント領域の
境界を定める特殊な命令で、スタートとエンドを構成さ
れるかのどちらかであることを特徴とする（１９）記載
の装置。

【０１４４】（２４）前記ターゲット・プロセッサは、
前記改策（ポリシー）がない場合、いかなる暗号機能も
提供しない暗号ユニットである、（１８）記載の装置。 （２５）前記ソフトウェア・タッチポイントは、アプリ
ケーション・イメージを他のシステムにコピーすること
から防止するソフトウェア・レベル・タッチポイントを
含む（１９）記載の装置。 （２６）ターゲット・プロセッサによって識別された特
有のホスト・システム上でアプリケーションの導入を許
可する導入トークンとなるサービス・クラスのトークン
を有する、（１４）記載の装置。 （２７）特定のサービス・クラスを有するターゲット・
プロセッサの指定されたクラスだけが許可されることを
確保するために、前記セキュリティ・ドメイン権限によ
って発行されるサービス・クラスのトークンを有する
（１６）記載の装置。 （２８）前記ソフトウェア・タッチポイントは、ターゲ
ット・プロセッサによって識別されるホスト・システム
上のみで、アプリケーションの導入を許可するために使
用されることを特徴とする（１９）記載の装置。 （２９）前記ソフトウェア・タッチポイントは、ホスト
演算処理装置の中で解かれることを特徴とする（１９）
記載の装置。

【０１４５】（３０）前記ソフトウェア・タッチポイン
トは、キャッシュ・レベルで、ホスト・プロセッシング
・システム・メモリ階層の中で解かれることを特徴とす
る（１９）記載の装置。 （３１）改策（ポリシー）制御要素と、前記ソフトウェ
ア・タッチポイントの分解要素と、を有し、前記分解要
素は、前記改策（ポリシー）制御要素から分離されるこ
とを特徴とする（１９）記載の装置。 （３２）命令ストリームから前記ターゲット・プロセッ
サの起動をトリガーするトラップ・メカニズムを有する
（１４）記載の装置。 （３３）前記ソフトウェア・タッチポイントは、スター
ト／停止命令対によって識別された構造化されたソフト
ウェア・レベル・タッチポイントを含む（１９）記載の
装置。 （３４）スタート／停止命令対によって識別された前記
構造化されたソフトウェア・レベル・タッチポイント
は、オペレーションの原子シーケンスとして実行される
ことを特徴とする（３３）記載の装置。

【０１４６】（３５）処理サービスが演算処理装置の識
別について保証されることを要求するアプリケーション
における、前記演算処理装置の確認装置であって、前記
演算処理装置にチャレンジする手段と、前記演算処理装
置に、前記演算処理装置のみが解くことができるパズル
を発行する手段と、を備え、前記パズルを解く前記演算
処理装置の能力は、前記演算処理装置のアイデンティテ
ィの証拠であることを特徴とする、前記装置。

【０１４７】

【発明の効果】この発明によると全体的な暗号フレーム
ワーク内の暗号サービスを利用するアプリケーションが
暗号の不正使用から保護される。

【図面の簡単な説明】

【図１】国旗カード、暗号ユニット、ホスト・システ
ム、及びネットワーク・セキュリティ・サーバを含む国
際的な暗号フレームワークのブロック図である。

【図２】暗号ユニット、いくつかの国旗カードを含むフ
レームワーク、ホスト・システム、及び国のセキュリテ
ィ・サーバの４つの基本要素を示す図である。

【図３】ＮＦＣとＣＵ間、ＣＵとＨＳ間、及び、ＨＳと
ＮＳＳ間のメッセージ交換パスを示す図である。

【図４】本発明の暗号ユニットの構成図である。

【図５】本発明のフレームワークのメイン・ソフトウエ
ア・アーキテクチャ要素の概要を示す図である。

【図６】本発明のアプリケーションで許可される暗号レ
ベルを最終的に定義するサービス・クラスのようなサー
ビス・クラスを、アプリケーション・ドメイン権限によ
って許可するアプリケーションにおける改策（ポリシ
ー）方式のキー要素のブロック図である。

【図７】本発明のフレームワークの証明要求を示すブロ
ック図である。

【図８】本発明の暗号ユニットにそれ自体を導入するア
プリケーションによるイベントの流れを示す図である。

【図９】本発明の、実行ステージの間に実行されるステ
ップを示す図である。

【図１０】本発明のソフトウェア・タッチポイントの概
要を示す図である。

【図１１】本発明の構造化されていない、及び構造化さ
れた命令レベル・ソフトウェア・タッチポイントを示す
図である。

【図１２】本発明の、作成ステージの間に実行されるス
テップを示す図である。

【図１３】本発明の、導入ステージの間に実行されるス
テップを示す図である。

【図１４】本発明の、実行ステージの間に実行されるス
テップを示す図である。

【図１５】本発明のソフトウェア・タッチポイント分解
に関するメモリ階層を示す図である。

【図１６】本発明のソフトウェア・タッチポイント分解
に関するメモリ階層を示す図である。

【図１７】本発明のホスト・システム・プロセッサ内の
命令レベル・タッチポイント・サポートを示す図であ
る。

【符号の説明】

１２ 改策（ポリシー）カード １４ 暗号ユニット １６ アプリケーション証明 １８ ネットワーク・セキュリティ・サーバ ６０ アプリケーション・ドメイン権限 ６２ セキュリティ・ドメイン権限 ６５ アプリケーション ６７ アプリケーションＩＤ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 キース・クレンバ アメリカ合衆国94303カリフォルニア州パ ロ・アルト、バーノン・テラス 3319

Claims (1)

【特許請求の範囲】
1. 【請求項１】アプリケーションを認証する装置であっ
   て、 アプリケーションに少くとも１つのサービスのクラスを
   与えるセキュリティ・ドメイン権限と、 前記セキュリティ・ドメイン権限によって与えられた前
   記サービスのクラスを受取るアプリケーション・ドメイ
   ン権限と、 前記アプリケーション・ドメイン権限によって、アプリ
   ケーション・ドメイン権限のドメインに属するアプリケ
   ーションに発行される少くとも１つのアプリケーション
   認証と、 を備える前記装置。