(57)【特許請求の範囲】
【請求項１】
暗号化機能をコンピュータ・ソフトウェア・アプリケーションに確実に与えるためのシステムであって、
前記コンピュータ・ソフトウェア・アプリケーションを実行するためのホストシステムと、
暗号化ユニットと、
前記暗号化ユニットを前記コンピュータ・ソフトウェア・アプリケーションに対して起動するためのポリシー起動トークンとからなり、前記暗号化ユニットが、前記コンピュータ・ソフトウェア・アプリケーションのコード画像の部分をランダムに要求することにより、前記コンピュータ・ソフトウェア・アプリケーションとの相互作用を確実にする、システム。
【請求項２】
前記暗号化ユニットは、前記コンピュータ・ソフトウェア・アプリケーションと前記暗号化ユニットとの間の各連絡要求とともに受け渡される一連の厳密に単調増加するシーケンス番号を使用して、前記コンピュータ・ソフトウェア・アプリケーションとの相互作用をさらに確実にし、前記コンピュータ・ソフトウェア・アプリケーションと前記暗号化ユニットのうちのいずれかが前記単調増加するシーケンス番号のシーケンスから外れた番号を検出した場合、連絡の失敗を推定する、請求項１に記載のシステム。
【請求項３】
前記暗号化ユニットは、前記コンピュータ・ソフトウェア・アプリケーションと前記暗号化ユニットとの間の各連絡要求とともに受け渡されるチャレンジトークンを使用して、前記コンピュータ・ソフトウェア・アプリケーションとの相互作用をさらに確実にし、前記チャレンジトークンが、前記コンピュータ・ソフトウェア・アプリケーションと前記暗号化ユニットの両方による演算を必要とし、該演算が、シーケンス故障を検出できるよう前回の値に依る、請求項１に記載のシステム。
【請求項４】
前記暗号化ユニットは、前記コンピュータ・ソフトウェア・アプリケーションからの操作を維持しなければならない所定のサービス時間限界を決定するタイマを前記暗号化ユニットに使用して、前記コンピュータ・ソフトウェア・アプリケーションとの相互作用をさらに確実にする、請求項１に記載のシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は暗号に関し、より詳細には国際的暗号体系のホストシステム要素に関する。
【０００２】
【従来技術の説明】
大型コンピュータシステムの顧客は、典型的には組織体全体にわたってコンピュータに基づく解決策を購入したいと望んでいる多国籍企業である。このような企業の組織は分散しているため、このような組織全体にデータを送るのに、彼等は公共の国際通信サービスを利用する必要がある。当然彼等は、彼等の通信の機密保護に気を配り、また近代的な端末暗号機構を利用してプライバシーとデータのセキュリティを確保しようとする。
【０００３】
通信における暗号の使用は国家の政策に左右され、且つ不幸にも国家政策は、このような暗号の使用に関しては種々異なっている。各国家政策は、一般には国際的配慮よりはむしろ国家に重点が置かれ、自主的に展開されている。国際的暗号に適する共通の暗号アルゴリズムを開発しようとしている標準化団体がある。しかし、国際的暗号の標準化の問題点は、技術的な問題ではなくて、むしろそれがその深部に国家的権力が絡む、政治的問題にある。このようなわけで、異なった国家間の暗号手法政策が、技術的標準化プロセスによって一線に並ぶと期待するのは現実的ではない。
【０００４】
暗号における国家的利害関係の問題点は、世界市場に向けた開放基準に基づく（open-standards-based）情報技術製品を製造している会社に固有の問題である。市場は、これらの製品が保護されることを期待している。しかしこれらの製品の多くの消費者は、ますます彼等自身多国籍化し、そして彼らは、彼等の全世界的情報技術開発を抑制する国際的暗号の諸問題の解決を支援するようそのメーカに対して期待を寄せるのである。国家的暗号政策における未解決の差異と貿易規制が永続することは、保全開放されたコンピュータ製品の国際的市場の成長に悪影響を及ぼす。したがって、国家的暗号政策の自主的開発に介入しないで、共通のセキュリティ要素を特徴とする地球的情報技術製品をもたらす国際的体系を実現することは有用である。
【０００５】
国家が暗号を統制する政策を採用するのは理由がある。これらの理由は、法律の実施及び国家的セキュリティの問題としばしば関連付けられる。各国内には、これらの政策の権利と容認に関して政府と国民との間に論争が起こることがある。これらの論争に関与するか又はそれらの結末を予測しようとするよりも、各国家の主権者の主権を受け容れて、通信における暗号書手法を支配する自主的政策を構築した方がはるかに実用的である。
【０００６】
国家的暗号手法を支配する諸政策は、その国民と政府の意思を表すのみならず、暗号手法を容易にする一定の技術をも包含する。技術の選択は、確かに、標準化が主軸を演ずるところの一領域である。しかし先に示したように、これは単なる技術的問題ではなく、そのため共通の暗号技術の選択だけでは国家的政策の差異を解決することはできない。したがって、これらの政策に準じた国際的暗号通信を従来通り可能にするように、独立した技術と政策の選択を実行し得る共通の容認された暗号体系を実現することが有用である。
【０００７】
国旗カード、暗号化ユニット、ホストシステム及びネットワークセキュリティサーバを含む国際的な暗号手法を支援する四部門の技術体系は、1997年７月22日提出の米国特許第5,651,068号におけるK.Klemba、R.Mercklingの"International Cryptography Framework"に開示されている。これら４つのサービス要素のうちの３つは、基本的階層関係にある。国旗カード（NFC）は、暗号化ユニット（CU）にインストールされ、このユニットが、今度はホストシステム（HS）にインストールされる。ホストシステムに基づく暗号化機能は、暗号化ユニット無しでは達成できず、そのユニット自体は有効な国旗カードの存在を必要とし、それがあって初めてそのサービスが使用可能となる。四番目のサービス要素、ネットワークセキュリティサーバ（NSS）は、他の３つのサービス要素の検証を含む個々のセキュリティサービスの範囲を設定し得るものである。
【０００８】
その体系は、任意のかつ全ての国家政策の企画、実施及び運営要素を支援する一方、独立した国家セキュリティポリシーの企画、開発及び運営を統合するものである。したがってその体系は、国家のセキュリティポリシーのサービス要素に標準書式を付与するもので、この場合このようなサービス要素には、ハードウェア書式因子、通信プロトコル及びオンラインとオフラインのデータ定義等が含まれる。
【０００９】
【発明が解決しようとする課題】
この体系の実施に当たって重要なことは、様々なサービス要素の生成を可能にする基本的技術を準備することである。サービス要素の種々の実施法は、熟練した当業者の技術範囲内であるが、体系のもつ全面的な可能性を実現しようとする場合は、当面の技術水準に特定の改良を施す必要がある。
【００１０】
特にアプリケーション、ポリシー及び前述の体系内で実行するオペレーティングシステムに対する支援サービス、例えば暗号化ユニットの暗号化サービスへのアクセスを可能にするべくアプリケーションプログラムインタフェース（API）を含むであろうアプリケーションに対する支援、を実施することは、このような体系のホストシステム要素にとって望ましい。さらにホストシステム要素と暗号化ユニット間の信頼関係を構築する際に、暗号化ユニットに対する支援を実施できることも前述のホストシステム要素に望まれる。
【００１１】
【課題を解決するための手段】
暗号化機能の流通を統制する種々の国内法に製造者達が従うことのできる、国際暗号体系（ICF）が提供される。特にこのような体系は、あらゆる方式の情報処理装置（例えばプリンタ、パームトップ）の全世界的な暗号化機能の転送を可能にするものである。ICFは、アプリケーションにポリシー制御の下で暗号機能を実行させる一組のサービス要素を含む。ICF構成の４つのコア要素、即ちホストシステム、暗号化ユニット、ポリシーカード及びネットワークセキュリティサーバは、アプリケーションに対して暗号サービスを提供する基盤を含む。ICF内で種々のサービス要素から暗号サービスを要求するアプリケーションは、認可された暗号レベルの誤使用を防ぐため証明書によって識別される。ポリシーは、アプリケーション証明書（Application Certificate）に含まれた属性を考慮に入れる。
【００１２】
ホストシステムは、アプリケーションに実行環境を与える一組のシステムプログラム及びサービスから成る。ICF内のホストシステムの役割は２通りある。第一にホストシステムは、暗号化ユニットによって提供される機能にアクセスできるようにプログラムインタフェースの形でアプリケーションにサービスを与える。第二にホストシステムは、暗号プログラムインタフェース、オペレーティングシステムドライバ及びメモリ管理サブシステムのような、ホストシステム要素との信頼関係を構築する際に暗号化ユニットに対して支援を与える。
【発明の詳細な説明】
【００１３】
しばしば国家の暗号政策は、産業区分、政治情勢及び／又はメッセージ機能によって変化する。このため、全時間、全ての産業にわたって１つの一様な政策を割当てることは困難である。したがって国旗カード、別名ポリシー起動トークン（policy activation token：PAT）を組み込んでいる暗号体系の柔軟性は極めて魅力的である。それ故本発明は、国際的暗号手法を包含する諸問題の解決法を扱う。本発明は、好ましくは暗号化機能の流通を統制する種々の国内法に製造者達が従うことのできる国際暗号体系（ICF）に属する。特にこのような体系は、あらゆる方式の情報処理装置（例えばプリンタ、パームトップ）の全世界的な暗号化機能の転送を可能にするものである。
【００１４】
ICF要素
本発明は、好ましくは４つのサービス要素を有する国際暗号体系に属するもので、そのそれぞれが異種のサービスを提供するものである。図１は、ポリシー起動トークン12、暗号化ユニット14、ホストシステム16及びネットワークセキュリティサーバ18を含む国際暗号体系（ICF）のブロック図である。これら４つのサービス要素のうちの３つは基本的階層関係にある。ポリシー起動トークン（PAT）は、暗号化ユニット（CU）にインストールされ、このユニットが、今度はホストシステム（HS）にインストールされている。ホストシステムは、暗号サービスを要求するアプリケーションを実行する。ホストシステムに基づく暗号化機能は、暗号化ユニット無しでは達成できず、そのユニット自体は有効なポリシー起動トークンの存在を必要とし、それがあって初めてそのサービスが、例えばホストシステムを介してアプリケーションに対して使用可能となる。ここでの議論の目的で、またポリシー起動トークンは、国家の暗号政策を出す規律をもたらすという理由から、ポリシーカードとも呼ばれる。
【００１５】
四番目のサービス要素、ネットワークセキュリティサーバ（NSS）は、他の３つのサービス要素の検証を含む個々のセキュリティサービスの範囲を設定し、したがって信頼される第三者の働きをする。提案された体系を利用して暗号化されたメッセージは、メッセージが暗号化されたその下で国家の暗号政策を識別する電子スタンプを保持している。またネットワークセキュリティサーバも、メッセージ処理システムのためのスタンプ検証サービスを提供する。
【００１６】
上述のように、ICF構成の４つの基本的要素は、ホストシステム、暗号化ユニット、ポリシー起動トークン及びネットワークセキュリティサーバである。ここでの議論の目的で、これらのICF要素は、次のように定義される。
【００１７】
ホストシステム（HS）
HSは、暗号化ユニット（CU）を包含するシステム又はユニットである。このICF要素は、CUに対するアプリケーションプログラムインタフェースを支援する。またセキュリティ認識がありかつCUを利用するアプリケーションを支援する。これらのアプリケーションは、実行時においてCUに緊密に結合される。
【００１８】
暗号化ユニット（CU）
CUは、暗号化機能を包含するシステム又はユニットである。これらの機能は活動休止状態にあって、PATによって起動されるまではHSで使用されない。CUに含まれる暗号化機能は、典型的には業務要求（business demand）によって決められる。CUは、そこに格納されることがあるキーはどれも保護できるように、改ざんに対して耐性がある。全てのPATの保守活動に関与することは、CUの責務である。それをし損なうと、CUの機能性が活動休止状態に戻ることになる。
【００１９】
ポリシー起動トークン（PAT）
PATは、暗号用法ポリシーを包含するトークンである。特にこのICF要素は、特定のCUにおける暗号の使用を支配するパラメータを含む。ポリシー起動トークンは、物理的形式、仮想形式及び固定形式とすることが可能である。物理的PATは、暗号用法ポリシーを含む、スマートカードのような物理的トークンであり；仮想PATは、ネットワーク中の目的のCUへ送られ得る暗号用法ポリシーを含むソフトウェア要素であり；さらに固定PATは、単一のアプリケーションに結合されかつそれらのアプリケーションに対する暗号用法ポリシーを含む。
【００２０】
ネットワークセキュリティサーバ（NSS）
NSSは、HS群及びCU群にネットワークサービスを提供すべく信頼された第三者として作用するシステム又はユニットである。これらのサービスには、例えばポリシー拡張、ユニット検証、認可に合う調整及びキー管理サービスが含まれる。
【００２１】
ICF構成の一要素として、ホストシステムは幾つかの特異的な特性を有する。本明細書においては、本発明は、ICFのホストシステムに関するこれらの特性に焦点を合わせている。
【００２２】
オペレーティングシステム支援要素
ICF実行時環境
ICFホストシステムソフトウェア構成は、与えられたホストシステムでICF要素を実行するのに必要とされるライブラリ及びシステム要素のレイヤを記述する。一般に３つの重要な層、即ちアプリケーション、オペレーティングシステム及び暗号サービスプロバイダがある。図２は、ソフトウェア構成要素に関する概観を示す。
【００２３】
アプリケーション
アプリケーションレイヤ20は、暗号サービスを必要とするユーザ書込みアプリケーション及びライブラリの領域である。アプリケーションは、これらのサービスを認識していてもよいし又はしていなくてもよい。それらが認識されている場合、その下のサブシステムレイヤ21は、一組のプログラムインタフェースをそのアプリケーションに提供する。暗号手法的に認識していないアプリケーションは、それら自体何らの呼出し（call）も出さず、その下にあるサブシステムが、アプリケーションに代わってこれらの呼出しを実行する。
【００２４】
サブシステムライブラリ及びインタフェース 21
認識及び未認識アプリケーションの暗号化機能を支援するサブシステムである。またこれらのサブシステムは、アプリケーションにアプリケーションプログラミングインタフェース（API）を提供する。ほとんどの著名なAPIは、MicrosoftアプリケーションにはMicrosoft CAPIを、またUnixアプリケーションにはX/Open GSS-APIとGCS-APIを含んでいる。サブシステムライブラリは、典型的にはそれら自体をアプリケーションプログラムインタフェースに編成し、また作動システムによって遮蔽して、暗号サービスプロバイダモジュールに編成する。
【００２５】
またサブシステムライブラリは、セキュリティAPIをアプリケーションから完全に隠すこともできる。これによって現行アプリケーションは、変更することなくその解法を利用することが可能となる。一例としては、移送レベルのソフトウェアサブシステムへの保全構造特徴（security features）の統合を挙げることができる。
【００２６】
このレイヤの他の要素によって、CUセキュリティ記憶と実行機能にアクセスするAPIを与える。例えば改ざんに耐性のあるデータベースを形成するためにODBCインタフェースのようなデータベースAPIをCU内のデータ管理モジュールと共に提供することができよう。
【００２７】
オペレーティングシステムとドライバ
オペレーティングシステム22は、２つの基本タスクを実行する。一方のタスクは、サブシステムプログラムインタフェースを暗号サービスプロバイダから分離することである。もう一方のタスクは、ハードウェアドライバの形で暗号ハードウェアと結びつく一組のドライバ23を通して必要なハードウェア制御を実施することである。
【００２８】
暗号化ユニットサブシステム24
このレイヤは、暗号化機能のハードウェア処理系及びファームウェア要素を含む。典型的にはハードウェアは、PCIカード又はPCMCIAカードのような、幾つかの形式因子に入り、個別のハードウェアプラットフォーム及び性能要件に適応する。ファームウェアは、（マイクロカーネルに類似している）実行時間、ICF機能性、及び特定アプリケーションプログラムインタフェースに要するユーザのダウンロード可能型ソフトウェアモジュールを実行する一組のライブラリである。
【００２９】
管理
管理（Administration）25の要素は、解法全体の管理体系を提供する責務がある。これには、例えば証明書管理、アプリケーションサービスクラスの管理及びCUへのアプリケーション特定拡張のダウンロードのような諸管理機能のミドルウェア（中間）構成要素が含まれる。
【００３０】
ICF管理体系
図３は、本発明によるICF管理要素を示すブロック図である。ICFのコア要素の周辺は、暗号化装置30の生成（Manufacture）と、体系全体のポリシーの定義及び施行を実行する領域権限（Authority）32/34がある。管理体系内には４つの基本的要素がある。これらは、セキュリティ領域権限（Security Domain Authority）34、アプリケーション領域権限（Application Domain Authority）32、ホストシステム要素16及びネットワークセキュリティサーバ18である。
【００３１】
セキュリティ領域権限
セキュリティ領域権限（SDA）は、セキュリティポリシーを定義する規則である。セキュリティポリシーは、サービスクラスを介して他の体系要素に呈示される。製造上の情報を知ることによって、システムが決定性CUセット（deterministic set of CU）に目標設定されたサービスクラスを生成することが可能となる。
【００３２】
アプリケーション領域権限
アプリケーション領域権限（ADA）は、アプリケーションに対して証明書を出す権限として作用する。その証明書は、それらがSDAによって認可される際に、アプリケーションに対する認可サービスクラスを包含する。
【００３３】
ネットワークセキュリティサーバ
ネットワークセキュリティサーバ（NSS）は、与えられたCUに対するポリシー起動を管理する信頼されたオンライン権限として作用する。
【００３４】
ホストシステム／アプリケーション／CU
そこにアプリケーションが組み込まれ、かつそこでCUサービスが用いられているホストシステムは、その体系で制御される実行要素を形成する。
【００３５】
セキュリティ領域権限（SDA）は、アプリケーション領域権限に一組のサービスクラス（COS）35を認可する責任を持つ。またSDAは、COS情報とCUに対するタッチポイント（Touch Point）データとを含んでいるポリシーカードを発行する責任も持つ。SDAは、CUをホストシステムに実装しているサイトから要求があるとこの情報を作る。
【００３６】
アプリケーション領域権限（ADA）は、SDAによって認可されたCOS要素を受ける。これは、その領域に属するアプリケーションにアプリケーション証明書36を発行する責任を持つ。アプリケーション証明書は、アプリケーションIDと、ADAによって認可されたCOSを包含している。
【００３７】
アプリケーションは、ADAから証明書を受け、それをCUに提示して所望のCOSレベルを得なければならない。要求を受けると、CUはその証明書を使って、要求された暗号化機能にアプリケーションがアクセスする権利があるかどうかを決定する。アプリケーション証明書を介して要求されたCOSが、SDAによってADAに付与され、そしてポリシーカードに記憶されたCOSと整合するなら、その要求は処理され、そうでなければ処理されない。
【００３８】
ネットワークセキュリティサーバ（NSS）18は、ポリシー折衝のためのオンライン装置として機能し、ポリシーカードに記憶されたポリシー情報に合わせて変化する。例えばサービスクラスをサービスセットに付加するには、通常変更された情報を含んでいる新しいポリシーカードの発行が必要である。代替的にはNSSは、SDAに代わってポリシーカードの更新を行う。またNSSは、仮想ポリシーカードの起動システム37の主軸を演ずる。
【００３９】
基本的ICFホストシステムの仮定
ICF構成は、以下に挙げるように、コア要素に関する少数の極めて基本的な仮定に基づいている。
【００４０】
検証
全てのソフトウェア要素は、それらがCU内に実装されたファームウェア成分であろうと又はCUによって出されるサービスを使うアプリケーションであろうと、それらに関連した信頼レベルを有する。ソフトウェアにおける信頼を全ICFに伝えるのに用いられる方法は検証である。全ての信頼化操作、例えばファームウェアモジュールのダウンロード又は一定のサービスレベルに対するアプリケーションはどれも、関連証明書の有効化に関するものである。
【００４１】
暗号化機能の形成
CUは、PATに占有されている状態以外でHSに何らかの暗号化機能を与えることはない。
【００４２】
分離
CU内で処理されるユーザデータは、PATのフォーマットに関係なく、どのような状況下でもポリシー要素によってアクセスできない。同様に、どのような状況下でもホストシステムは、ポリシーのタッチポイントデータ情報へのアクセスがあってはならない。
【００４３】
アプリケーションとCUサービス間の信頼関係
アプリケーションはICFにおける要求要素である。典型的にはそれらは、ホストシステムで実行されて、CUからのサービスを要求する。
【００４４】
ICF構成の肝要な部分は、サービスを要求するアプリケーションとこのサービスを配るサービスプロバイダとの間の両方向の信頼関係である。何れも参考として本明細書に引用されている、米国特許出願第08/748,085号（Dynamic Classes of Service for An International Framework）；第08/770,747号（Software Level Touch Points for an International Cryptography Framework）；第08/702,331号（Application Certification for an International Cryptography Framework）；第08/702,304号（Method and Apparatus for Enforcing the Use of Cryptography in an International Cryptography Framework）；第08/702,332号（Method and Apparatus for Trusted Processing）；及び第08/685,076号（Cryptographic Unit Touch Point Logic）に記述されているように、アプリケーションと、CU以外の信頼要素を想定しない暗号化ユニットと、アプリケーションコード画像への信頼された直接経路とから成るシステムを構築することができる。CUは、所望のサービスを与える以前にコード画像に基づくアプリケーションの同一性を確認する。
【００４５】
図４は、アプリケーション10とCU 14との間の信頼関係を図解するものである。CUからホストシステムのメモリ空間へのこの種のアクセスを実行しないシステムでは、チャレンジ（challenge）は、２つの連絡している要素間の信頼関係を強調する１つ以上の機構を確立することになる。これには２つの基本的戦略がある。一方は、CUからアプリケーションまで信頼要素のラインを構成することであり、もう一方のアプローチは、アタック（attack）検出時間を変える、多くの確認チェックによってCU/アプリケーションの相互作用を監視することである。
【００４６】
本発明の一局面は、CUからアプリケーションまで信頼要素のラインを構成するものである。例えば一連の信頼要素の底部にあるCUについては、CUは、要求をCUへ渡すのに要するOSドライバを有効化することができる。次いで、有効化ドライバは信頼機構を実行して、例えばそれ自体有効化スキームを実行することができる、ドライバ呼出しモジュールを有効化することができる。信頼は、アプリケーションの方へ拡張される。OSドライバの有効化、即ち信頼の連鎖の開始点、についての仮定は、ホストシステムカーネルのアクセス制御と認証機構とに組み込まれた十分な信頼が存在する、ということである。
【００４７】
本発明は、アプリケーション/CUの相互作用に一連の有効化とチェックを実行する。このアプローチでは、CUからアプリケーションの方へ信頼のラインを構成することよりも、CUとアプリケーション間の相互作用に幾つかのメカニズムと有効化チェックが実行される。これらのメカニズムの各々は、アタックに耐えられるほど強力でなくても、これらのメカニズムの組合せにより、アタッカー（attacker）にとってはアタックが十分困難になるものである。
【００４８】
これらのメカニズムの幾つかを以下に説明する。
【００４９】
厳密に単調増加するシーケンス番号
このスキームでは、両パーティ（当事者）は、要求と共に厳密に単調増加する番号を受け渡しする。もしどちらかのパーティが予期せぬ番号を検出する場合は、連絡上の障害、おそらくはアタックが想定される。
【００５０】
要求に加えてチャレンジトークンの受け渡し
両パーティは、両側での演算に関わるチャレンジを前後に受け渡しすることができる。各パーティでの演算は、シーケンス故障を検出できるよう前回の値に依る。
【００５１】
タイマアプローチの使用
操作が一定の時間限界の範囲内にあることが分かっている場合、処理中の異常を検出して潜在的にアタックをそれとなく知らせるのにこの情報を使うことができる。
【００５２】
コード画像のランダム選択部分をCUパーティに受け渡しするようにアプリケーションパーティへの要求
このスキームでは、CUは、要求が悪意のアプリケーションによって出し得ないことを確実にするため、アプリケーションのランダム選択メモリ部分を求める。連鎖ハッシュ方式（chained hash scheme）を用いているため、このようなメモリ部分のランダム選択によって、アタッカーがメモリ位置を推測することがさらに困難となり、かつシステムがそのような介入を検出することがより容易になる。
【００５３】
これらのアプローチの全ては、共通してそれらだけでは要求アプリケーションの確実性を保証し得ないことが経験される。これらのアプローチの全てに対する基本的チャレンジは、非信頼環境であり、ここでは人はこの環境におけるパーティを識別するのに確実な記憶又は確実な計算を実行できない。提案されたスキームの全ては、アタックされ易い弱点を抱えている。しかし幾分弱い基礎レベルのスキームを組合せることにより、検出することなく迂回することが極めて困難であることが証明される。
【００５４】
上述のようなアプリケーションとCU間の信頼関係を強化するためのアプローチは全て、アプリケーションがオペレーションを要求し、かつそのオペレーションがCUの信頼境界内で実施されるという事実において不利である。アプリケーションは、その他の方法でサービスを自由に得ることができ、それによってCUを完全に迂回する。CU自体は、アプリケーションの同一性を確認する手段が極めて限定されており、したがって例えばホスト環境に依らざるを得ない。
アプリケーションとCUの間の別々の責任分担によってその情況はかなり改善される。例えばアプリケーション部分がCUの信頼境界内で実行されるのであれば、ホストシステムでのアプリケーションは不完全となり、さらにこのアプリケーションを入れ換えるか又は不明部分を補足することがより困難になる。
【００５５】
信頼境界内のアプリケーション機能の比較的大きいブロックによっても、サービスをCUのより高いレベルからエクスポートさせることによりこの情況が改善され、それによってもうエクスポートされることのないCUの低めの機能性を誤用するというリスクが軽減される。
【００５６】
アプリケーション支援要素
アプリケーションの認証
ICFアプリケーションは検証することができる。証明書には、アプリケーションの識別属性、例えばアプリケーションID、アプリケーションコード画像のハッシュ和（hash sum）及びこのアプリケーションに割り当てられたサービスクラスが含まれる。この情報はディジタルシグネチャによって認証される。CUはこの情報を使って、アプリケーションを正確に識別し、かつ許容し得るアクセスの種類を決定する。
【００５７】
シグネチャプロセスは、込み入ってはいないが、ある種の管理上の努力と管理基盤を必要とする。アプリケーションコード画像中のほんの１ビットを変更するだけでも、システムはシグネチャを生成する全プロセスを遂行しなければならない。検証基盤に依存して、アプリケーションの開発者は、その仕事を別の実体へ付託してそれを署名してもらう必要があり、このことはアプリケーションの配布に深刻な制約を課すことになる。
【００５８】
アプリケーションの１つのバージョンを次のバージョンで置き換えるには、信頼及び制御レベルを必要とする。アプリケーション認証メカニズムは、それが使われる前にアプリケーションのプログラム原点（origin）を確認するのに用いられる。アプリケーション更新プロセスで制御オプションを特定することは、受動システムにとって望ましいことである。例えばホストシステムは、ロードされたアプリケーションの新しいバージョンを自動的に受け容れないと決める。
【００５９】
図５は、本発明によるアプリケーションの組み込みと更新を示すブロック図である。アプリケーションＡ'を組み込むことは、それが前のアプリケーションＡに関して有している従属性によって特色付けることができる。
【００６０】
従属性無し
Ａ'はＡに関係しない。符号化識別が同じものでないことがある。これは最も一般的なケースである。アプリケーションは同一名で呼ばれる。通常符号権限は同じものを持続する。
【００６１】
シグネチャ従属性
Ａ'は、符号化識別が現在分かっているモジュールを符号化するのに用いたものと同じ場合にのみ受け容れられる。これは最も典型的なケースである。アプリケーションが受け容れられ、さらにシグネチャが信頼されたアプリケーションの製作者を識別する場合に以前に取り込まれたアプリケーションを入れ換える。
【００６２】
後方従属性
Ａ'は、Ａ'がＡに関する情報とそのシグネチャを含んでいる場合にのみ受け容れられる。直接後方従属性だけがＡ'の即時先行点（immediate predecessor）を受け容れ、間接後方従属性は、以前のＡの連鎖における任意のモジュールを受け容れる。このスキームは、システムが取り込むアプリケーションについて有している制御をかなり強化する。
【００６３】
前方従属性
アプリケーションは、後続バージョンＡ'の受け容れに影響を及ぼすオプションを特定することができる。
【００６４】
コードの同値性
コードの同値性は、証明されたアプリケーションへの変更がロードされている間ホストシステムが維持する基本的性質である。コードの同値性についての最初の問題は、最初のコードの正確さと計算可能性を立証することの周知の困難さに関わる。本発明の好ましい実施例では、開発プロセスと手続き、並びに有効化チェックポイントの適当な組合せによって２つの基準が達成される。
【００６５】
下記ステップは特定の基準がどのように達成されるかを説明するものである。提案されるヒューリスティック（heuristic）は次の３つの部分から構築される。
【００６６】
・図６の影を付けた矩形で表された実行可能成分 50；
・図６の丸みを付けた矩形で表されたチェックポイント成分 51；及び
・図６の単純な矩形で表された変換成分 52。
【００６７】
ここでの議論の目的で、単語"成分"を用いる時、実行されるべきコードもしくは付加されたデータ構造の間に技術用語上の区別はない。
【００６８】
成分を説明する前に、状態変数を導入する必要がある。以下は、その状態変数がどのように使われるかを説明するものである。十分機能的な、よく制御されたサブシステムは、全システムの部分であるか又は全システムそのものであるかの何れかであり、一組の特徴（Feature）によって特色付けられる。一組の特徴が初期状態にある時、それはベース（Base）と呼ばれる。与えられた状態でのベースは、そのベースが正確さの基準を満たすのであれば、一組の特徴ｆであると言えよう。ベースをアップグレイドする時は、新しい特徴、例えばｆ１又は状態ｓをもって実際に増加させる。アップグレイドは、実際にはｓからｓ＋１への状態の変化を意味する。よってベースとエディション（Edition）のバージョンは、それらが同じ状態に属するという理由で、互換できる状態に維持される。懸案の本実施例に関しては、実行可能成分について２つのカテゴリを導入することは容易である。
【００６９】
実行可能成分
実行可能成分の第一カテゴリはベースであり、第二カテゴリは特徴であり、それはベースの現在の特徴を新しい特徴と入れ換えるか又はベースを増加させる。ベースに対する新しい付加は新しいベースを発生する。新しいベースは、記号ｓ＋１で表される状態変数値の変化によって、旧ベースとは区別される。図６では、状態の変化は黒矢印53で表されている。図解したように、状態の変化は、ベースと新しい複合ベース（Compound Base）のシグネチャが確認されると以下のステップを踏む：
１. 変換ハッシュは、状態ｓのハッシュ値に加えて新しい特徴を組み込むのに実施されるべき変換機能連鎖に属する；
２. もしそのハッシュがハッシュ参照連鎖（hashed reference chain）及び状態ｓと釣り合うなら、特徴ｆは正しく、したがって組み込むことができる；
３. 変換連鎖、例えばダイナミックリンク、ロード又はリゾルブ（resolve）を使ってその特徴が組み込まれる；
４. 新しいベースの状態をｓ＋１に更新する。
【００７０】
チェックポイント成分
チェックポイントはプロセス段階を確認するのに用いられる。"変換ｆのハッシュ"と呼ばれる中間チェックポイントは、変換関数Ｔによる特徴ｆの変換に該当する。
【００７１】
変換成分
ベースは、コンパイルされ、ロードされかつライブラリ及びデータ構造とリンクされる時だけ実行することができる。一度ロードされると、記号の分解と再配置が解決されてしまい、さらに今度は複合特徴の組が実行可能バイナリとなる。変換関数は、コンパイル、ローディング及びリンキングを含む全ての複合メカニズムを表す。メカニズムの連鎖のハッシュに合う参照は、参照変換Ｔである。
【００７２】
アプリケーションレベルリソースマップ
図７は、本発明によるソフトウェアアプリケーションモジュールのダウンロード及び実行を示すブロック図である。クライアントサーバ構成に見られる典型的環境は、アプリケーションが実行される閉環境を構成する。この戦略例は、Java仮想計算機環境70である。この例では、アプレット（applet）と呼ばれる、アプリケーション71がクライアントシステムにダウンロードされる。シグネチャ有効化プロセスがアプレットに適用されて、アプレットの供給者のような信頼される実体によってアプレットが署名され終わったことを検証することができる。さらに幾つかの完全性チェックの後、そのアプレットを仮想計算機環境内で実行させることができる。
【００７３】
しかしアプレットの認証と完全性を有効化することは、ホストシステムの保全要件の唯一の局面である。典型的にアプレットは、ホストシステムのリソースと相互作用をする必要がある。これは、アプレットがホストシステムのリソースに対して実行する閉環境からのゲートウェイをシステムに設けさせるものである。絶対的な（all or nothing）戦略を実施する現在のモジュールは、アプレットの設計者の要求を満足させるには不十分である。
【００７４】
ICF構成は、アプリケーションリソースマップの信頼された記述と見なすことができるサービスクラスの概念を与える。COS識別子はリソースを標識し、COS属性は、ホストシステムのリソースに関してアプリケーションが能力のあることを表す。ICF領域権限によって発行されかつ署名されると、アプリケーション割当て能力を越えてリソースへアクセスするのにリソースマップCOSを操作することはできない。強要要素（enforcing element）としてのCUそのものは、アプリケーションリソース要件の評価が行われる信頼された位置（location）である。米国特許第5,651,068号に記述された、アプリケーションレベルタッチポイントのようなICF構成の諸要素、及びCUは保全位置でアプリケーション方法を実行できるという事実は、実行しているアプレットの有効化をさらに強化する。
【００７５】
アプリケーション固定ポリシー起動トークン
固定PATと呼ばれるアプリケーション固定ポリシー起動トークンは、特定アプリケーションに対する暗号化ユニットの起動を目標としたトークンである。これは、特定暗号化ユニットの起動を目標としている物理的又は仮想PATとは異なるものである。
【００７６】
固定PATに対するモチベーション（motivation）は、CUによって与えられる暗号サービスをアプリケーションに消費させるのに必要な、アプリケーションからポリシー起動トークンまでの全てを含む配布のユニットを設定することである。
【００７７】
図８は、本発明による固定ポリシー起動トークンを示すブロック図である。図８に示される例において：
・アプリケーション80は、特異的な識別、例えば一連の番号（serial number）を有する；
・COSの制約がアプリケーションの一連の番号をCOSに結び付ける；
・この場合に関するCOSテストレベルがある。
【００７８】
アプリケーション及びサービスクラス
サービスクラスは、例えば番号であるCOS識別子と、関連した方法の識別子及びその方法へのアクセスが認容される前に評価されなければならない拘束とを含む記述部分とから成る。記述部分は、その認証と同一性を保証するために権限によって署名される。
【００７９】
COS識別子は、記述部分とは異なるチャンネルを通して配布させることができる。例えば、COSが暗号化方法と結び付けられる場合は、COS識別子がアプリケーション領域権限へ伝えられ、次にはアプリケーション領域権限がそれらをCUからのサービスを要求するアプリケーションへ配布する。COS記述部分、即ち対応するCOS識別子を伝える要求を評価するのに必要な内容をCUに与える部分は、NSS基盤を介して配布される。COSが非暗号方法を表す場合は、この分離は必要ではない。
【００８０】
非干渉化（decoupling）の原理
ICF構成は、要素アプリケーション、リソース及び管理領域の明確な責任を定義する。ICFの下で、アプリケーションは、要求の暗号属性をその記述のハンドルとして標識するサービスクラスの識別子を使って、暗号化ユニットからのリソースを要求する。暗号化機能の他に、その他の任意の操作をこのメカニズムによって標識することも可能である。
【００８１】
サービスクラスは、体系の管理機能によってアプリケーションと結ばれる。アプリケーションは、別のCOSを使って要求を発行できるが、そのCOSに包含された属性を修正するか又は生成する方法を有さない。CU自体は、アプリケーションが認められた領域権限によってそれに割り当てられたCOSを使用中であることを確認するメカニズムを形成する。
【００８２】
サービスクラスの属性、即ちリソースによって実施されるべき操作を記述するCOSの内容は、領域権限に役立つ管理機能によって決定されかつ制御される。アプリケーション開発者がCOSの内容に影響を及ぼす方法はない。アプリケーションの開発者及びアプリケーションのユーザからのこの管理機能の非干渉性は、ICF構成の主要な原理である。図９はこの原理の図式表示を示すものである。
【００８３】
アプリケーションは、ますます企業の重要なデータ及び消費者の個人的データを扱うようになっているので、アプリケーション生成者の基本的リソースを取扱うことからの分離は、主要な要件になってきている。少数の財務上のアプリケーション及びおそらくは項目別アプリケーションに存在したに過ぎないこの要件は、今やその上に電子通商を扱うその他のアプリケーションの範疇へ食い込みつつある。
【００８４】
PAT支援要素
サービスクラスマッピング
アプリケーションは、それらの要求を実行できるよう暗号化ユニットへ連絡する。各要求は、この要求に対してサービスクラスを暗号化ユニットに駆動させる情報を含んでいなければならない。ICFは、要求をCOS IDにマッピングすることについて２つの主要なアプローチを規定する：
・アプリケーションは、COS識別番号をその要求と共に伝えることができる。例えば、アプリケーションに対して発行されたアプリケーション証明書は、認可されたサービスクラス識別子を含む；
・アプリケーションは要求を出すことができる。その要求の属性を解析しかつその要求を満足する最近接サービスクラスを決定することは、CUの責任である。
【００８５】
図10は、本発明によるサービスクラスマッピングを示すブロック図である。アプリケーションは、サービスクラスもしくは所望操作の属性をCOSエンジンへ伝えることができる。例えば暗号操作は、アルゴリズムの種類又はキーの長さに関する属性を有することができよう。マッピング機能90は、要求91の属性を解析し、さらに属性リストに記述された諸制約を満足するCOSを決定する。最小可能COSが選択される。もしCOSが適切でなければ、その要求を拒絶するか、又は要求の属性を前方のネットワークセキュリティサーバへ伝えて適切なCOSを選択する。
【００８６】
同様のCOSマッピング方式を認可エンジン92の実行に用いてもよい。典型的な認可エンジンでは、発信者は、認可規則にしたがう一組の特典属性と対照される一組の要求属性を伝える。その結果が正なら、発信者は先へ進むことが許され、そうでなければ進めない。マッピングCOSが見付けられ得るという事実は、正の認可と見てよい。
【００８７】
サービスクラス識別子
COS識別子は、幾つかの範疇に分類することができる。それらは、定義済み（predefined）COS識別子、折衝もしくは割当てCOS識別子及びランダムCOS識別子と標識される。全てのCOS識別子は、別々のカテゴリへの割当て範囲が規定された番号空間を形成する。図11は、ネーム空間と、SDA、ADA及びアプリケーションに対するその関係を示す。
【００８８】
COS識別子ネーム空間
定義済みCOS識別子。図12は、本発明による定義済みサービスクラス識別子を示すブロック図である。定義済みCOS識別子は、SDA全てにわたって特異的である。それらは、ICF管理操作を管理しかつ制御するのに要するICF基盤のサービスクラス用として確保（reserve）される。定義済みサービスクラスは、常にICF領域権限によって証明され、その識別子は記述部分と別に伝えられる。
【００８９】
折衝COS識別子。図13は、本発明による折衝サービスクラス識別子を示すブロック図である。折衝識別子は、ADA 32とSDA 34の間の相互作用の結果である。典型例は、ADAがその領域内で容認したいある一組の暗号操作に対するサービスクラスの識別子の生成である。サービスクラスの使用を権限に求めるADAは、所望のCOSのCOS識別子へ戻される。COSは、そのような要求を受けた時に、必ずしも生成される必要はない。例えばADAは、規定された全てのサービスクラスを含んでいる公開辞書を走査（browse）し、そして適当なものについて認証を要求してよい。戻されたCOS識別子は、この要求で構築されたADA/SDAの関係に特異的である。
【００９０】
折衝COS識別子は、セキュリティ権限領域内では常に特異的である。しかし１つ以上のSDAがこれらの領域にわたって同じものであるCOS識別子と折合うことは確かに起こり得ることである。ある意味では、それは定義済みCOS識別子となる。しかし、同じCOS識別子の選択は、定義済みCOS識別子の場合のように定義によるのではなく、協定によって実行される。
【００９１】
２つ以上の領域間の協定もCOSマッピングの概念によって達成することができる。同じCOSの記述に対して同じCOS識別子を有することは、ICF構成の要件ではない。２つの記述、即ちCOSの属性と制約は、同じことがあり、しかも同じ領域内であっても異なった識別子で表されることがある。
【００９２】
ランダムCOS識別子。図14は、本発明によるランダムサービスクラス識別子を示すブロック図である。ランダムCOS識別子は、アプリケーション実行中に特別に生成される操作についてCOSに動的に要求するアプリケーション要求（application's need）を受け入れるようCOS概念を拡大する。
【００９３】
SDAとADAは、必要ならランダムCOSを生成可能であるが、ランダムCOS識別子は、典型的にはアプリケーションによって使用される。ランダムCOS識別子は、別の領域には何ら意味をなさない。
【００９４】
ランダムCOS識別子は、COSに対するプライバシについて新しい意味を付加する。それらは、他の誰にも必ずしも見える必要のない２つのパーティによって合意された方法を表すCOSを識別するのに使うことができる。ランダムCOSは、一回の操作、例えば財務上の取引データを記述するのに使用される。それらは、ADA/SDAの相互作用によるのではなくて、アプリケーション/NSSの相互作用によって作り出される。ランダムCOSを作り出すべくそれらによってCOSが与えられた複数のADA又はアプリケーションは、それらを単一の取引データのために、例えばクレジットカードの取引データを認可する商業サーバ用に作り出すことができる。
【００９５】
ランダムCOS使用シナリオは、以下を含む：
シナリオ１：会社は、COSと関連させたアプリケーションコードの幾つかを付してアプリケーションを転送する。このコードは、CUにダウンロードされそしてCUの周辺の範囲内で実行される。COS、そのコードを監視しているランダムCOSは、アプリケーションの製造者によって作り出されるもので、アプリケーションの実行の認可トークンと見ることができる。使用番号又は満了時間のような、COS属性は、支払い基盤を構築するのに用いられる。
【００９６】
シナリオ２：エージェント技術は、受動システムへ送られそしてそれらの又はそれらのオーナのために実行するコード、エージェントの可動ユニットを作り出す。チャレンジは、受入れクライアントシステムに対してエージェントが実行すべき分離境界を確定することである。今までに提案された解法は、クライアントシステムリソースへのアクセスを与えない、砂箱モデルか、クライアントシステムをあらゆる形のアタックにさらす無制限か、訪問エージェントに対するきめの粗い一組のアクセスルールの何れかを提案した。
【００９７】
COSを伴ったエージェントは、エージェント、その同一性及びエージェントの実行を提起する抑制を記述するのにより強固なメカニズムをもたらす。COSシグネチャ構造により、エージェントの同一性が確実に決定可能であり、その抑制は改ざんされないことを保証される。CU、クライアントシステム上の改ざん耐性場所は、確かにCOS属性を解析しかつエージェントの実行を始動する。
【００９８】
シナリオ３：認可プロセッサにおけるランダムCOSの使用。典型的に認可プロセッサは、その認可を記述する固定ルールにしたがって、一組の特典属性を使って、アプリケーション要求属性、コールされた処置属性を評価する決定システムを実行する。このようなシステムのチャレンジは、常に特典属性を確実に記憶しかつ認可プロセッサそのものに対して強固なかつ改ざん耐性評価環境をもたらすことであった。典型的な設計は、認可を要求するクライアントシステムがそれに対して確実なチャンネルを確立しかつそれが処置属性をそこへ送付する集中認可サービスを履行した。次いで、送り返された解答がアプリケーションによって使用される。
【００９９】
ランダムCOSは、特典属性をクライアントに伝えるための及び認可評価をクライアントシステムのCU中へ入れるための安全な方法である。最終結果は、必要な安全性のレベルを維持しながら、意志決定の場所での署名履行である。
【０１００】
上記のシナリオが示すように、ランダムCOS識別子は、それらによって操作を標識しかつ特別なベースに基づいて属性をそれらに関連させるような強力な方法でICF基盤を拡大する。属性の評価と強調は、暗号化ユニットとICF領域権限によって確定された信頼の土台に基礎を置いている。
【０１０１】
COS識別子の比較
下表１は、種々のCOS識別子の種類とそれらの特性を要約したものである。
【０１０２】
0003753885.tif 000002
【０１０３】
可変及び不変COS属性
図15は、本発明による可変及び不変サービスクラス属性を示すブロック図である。サービスクラスは、セキュリティ領域権限によって規定されかつ生成される。COS 190は、識別子191と、COSによって表された操作及びその操作に関する制約を記述する一組の属性192とからなる。COSは、それがICF配布基盤を通して受け渡される際にその認証を証明しかつその完全性を保証するべくセキュリティ領域権限によって署名される。
【０１０４】
COSの受領者、即ち特定のCUのPATを作る責任を持つ実体は、与えられたCOSに対して追加制約を付加したいことがある。CIFは、この要求をアドレスする方法を画定する。変化するCOS属性は実際の属性値を画定しない。その代わりそれらは、その体系の他の管理要素によって規定し得る属性の有効範囲を画定する。
【０１０５】
COSは、COS属性の不変193及び可変194部分を有する。不変部分は、一度COSがSDAによって生成されかつ署名されると、変更もしくは取消すことができないCOS属性値を画定する。COS属性の可変部分は、有効値の範囲がその属性に対して画定された属性とデフォルトによって指定される属性値とを画定する。属性の数と種類は、作成時に画定され、その後の時点では変更できない。属性はCOSに付加することも除去することもできず、不変属性は可変にすることもその逆とすることもできない。
【０１０６】
可変属性195の属性値の範囲は、一範囲の又は一組の値として表すことができる。例えば数値属性は、下限及び上限の数値で特色付けられる範囲を特定することができる。列挙属性（enumeration attributes）は、許容値を値のリストとして顕在的に特定することができる。
【０１０７】
本発明は、本明細書において好ましい実施例を参照して記述されているが、その他の応用も本願発明の精神と範囲から逸脱することなくここで説明された事柄と置換できることは、熟練した当業者には容易に理解されよう。したがって本発明は、専ら添付の特許請求の範囲によってのみ限定されるものである。
【０１０８】
以下においては、本発明の種々の構成要件の組み合わせからなる例示的な実施態様を示す。
【０１０９】
１．国際暗号体系の要素によって設定される信頼レベルを拡大することにより１つ以上のアプリケーション及び／又はオペレーションシステム(10)の中で１つ以上の信頼度をもたらす信頼関係を確立する装置であって、前記国際暗号体系が暗号化ユニットから成り、前記装置が：
前記１つ以上のアプリケーション又はオペレーションシステムの実行を支える実行環境を与えるホストシステム(16)と；さらに
前記１つ以上のアプリケーション又はオペレーションシステムの前記暗号化ユニットへのアクセスを実施できる暗号サービスプロバイダ(18)と
を含むことを特徴とする装置。
【０１１０】
２．前記信頼関係が、
前記暗号化ユニット(14)から前記１つ以上のアプリケーション及び／又はオペレーションシステム(10)までの信頼要素の何れかの系列と；さらに
個々には強固ではないが、組み合わされると検出を免れて迂回するのが困難である幾つかのスキームの組合せを設けることにより、前記１つ以上のアプリケーション及び／又はオペレーションシステム(10)と前記暗号化ユニット(14)との間の相互作用を監視する複数の確認チェックと
によって確立されることを特徴とする１項記載の装置。
【０１１１】
３．前記確認チェックが：
前記１つ以上のアプリケーション及び／又はオペレーションシステムと前記暗号化ユニットとの間の通信に対する各要求と共に厳密に単調増加する一連のシーケンス番号と、該一連のシーケンス番号は、前記１つ以上のアプリケーション及び／又はオペレーションシステム又は前記暗号サービスプロバイダの何れかが予期せぬ番号を検出すると、通信上の障害が仮定され；
前記１つ以上のアプリケーション及び／又はオペレーションシステムと前記暗号サービスプロバイダとの間の通信に対する各要求と共に受け渡され、前記１つ以上のアプリケーション及び／又はオペレーションシステムと前記暗号サービスプロバイダの両方による計算を要求し、かつ前記計算がシーケンスの障害を検出できるよう以前の値に依るチャレンジトークンと；
処理又は事象における異常を検出するために予め画定したサービス時間限界を決定するタイマと；
前記１つ以上のアプリケーション及び／又はオペレーションシステムが、ランダムに選択されたコード画像部分を前記暗号サービスプロバイダへ受け渡すメカニズムと；
前記暗号サービスプロバイダへの要求が悪意のアプリケーションによって出されることができないことを保証するため、前記暗号化ユニットがランダムに選択されたコード画像部分を要求するメカニズムと；
前記暗号化ユニットにおける前記１つ以上のアプリケーションが、アタッカーによる推測をより困難にしかつ前記アタックの検出を自明にするべく連鎖ハッシュメカニズムを使って、ランダムに選択されたコード画像部分を要求するメカニズムのいずれかを包含することを特徴とする１項又は２項記載の装置。
【０１１２】
４．前記１つ以上のアプリケーション及び／又はオペレーションシステムが、前記暗号化ユニットの信頼境界内で実行されることを特徴とする１〜３項の何れか１項記載の装置。
【０１１３】
５．前記１つ以上のアプリケーション及び／又はオペレーションシステムが、１つ以上のアプリケーション及び／又はオペレーションシステムの同一性とそれらに割り当てられたそれらのサービスクラスを含んでいて、前記暗号化ユニットによって使われて前記１つ以上のアプリケーション及び／又はオペレーションシステムを識別しかつそれに許容される暗号サービスへのアクセスレベルを決定する証明書(36)によって証明され；
かつ前記１つ以上のアプリケーション及び／又はオペレーションシステムの同一性が、前記１つ以上のアプリケーション及び／又はオペレーションシステムのハッシュ和にわたるシグネチャによって任意に認証されることを特徴とする１〜４項の何れか１項記載の装置。
【０１１４】
６．前記１つ以上のアプリケーション及び／又はオペレーションシステムの現在のバージョンをその次のバージョンで置き換えるには、前記次のバージョンのプログラム原点をそれが使われる以前に確認できるよう前記暗号化ユニットに対する認証メカニズムが要求されることを特徴とする１〜５項の何れか１項記載の装置。
【０１１５】
７．さらに：
シグネチャ妥当性検査メカニズムが、信頼された実体によって署名されていることを証明するようにモジュールに対して適用され、該モジュールが、仮想装置の規定環境内で実行されることを包含することを特徴とする１〜６項の何れか１項記載の装置。
【０１１６】
８．さらに：
特定のアプリケーション及び／又はオペレーティングシステムに対する暗号化ユニット(14)を起動する固定ポリシー起動トークン(37)を包含し；
前記１つ以上のアプリケーション及び／又はオペレーションシステムが特異的識別子を有し；
サービスクラスの制約により前記特異的識別子が前記サービスクラスに結び付けられ；さらに
サービスクラスが、サービスクラス識別子(35)と、関連した方法の識別子及び前記方法へのアクセスが認容される以前に評価されなければならない制約を含む記述部分とから成ることを特徴とする１〜７項の何れか１項記載の装置。
【０１１７】
９．さらに：
発信者が、認証ルールにしたがう一組の特典属性に比較される一組の要求属性を受け渡しする認証エンジンを含み、前記発信者が、前記結果が正なら前進することができ、そうでなければ前進できないことを特徴とする１〜８項の何れか１項記載の装置。
【０１１８】
１０．さらに：
１つ以上のセキュリティ領域権限(34)と；
１つ以上のアプリケーション領域権限(32)と；さらに
前記アプリケーション領域権限と前記セキュリティ領域権限の間の相互作用の結果である折衝サービスクラス識別子と
を包含することを特徴とする１〜９項の何れか１項記載の装置。
【０１１９】
【発明の効果】
製造者達に暗号化機能の流通を統制する種々の国内法に従わせる、国際暗号体系（ICF）が提供される。特にこのような体系は、あらゆる方式の情報処理装置（例えばプリンタ、パームトップ類）の全世界的な暗号化機能を出荷することを可能にするものである。ICFは、アプリケーションにポリシー制御の下で暗号機能を実行させる一組のサービス要素を含む。ICF構成の４つのコア要素、即ちホストシステム、暗号化ユニット、ポリシー起動トークン及びネットワークセキュリティサーバは、アプリケーションに対して暗号サービスを提供する基盤を含む。ICF内で種々のサービス要素から暗号サービスを要求するアプリケーションは、認可された暗号レベルの誤使用を防ぐため証明書によって識別される。ホストシステムは、アプリケーションに実行環境を与える一組のシステムプログラム及びサービスから成る。ICF内のホストシステムの役割は２通りある。第一に、ホストシステムは、暗号化ユニットによって提供される機能にアクセスできるようにプログラムインタフェースの形でアプリケーションにサービスを与える。第二にホストシステムは、暗号プログラムインタフェース、オペレーティングシステムドライバ及びメモリ管理サブシステムのような、ホストシステム要素との信頼関係を構築する際に暗号化ユニットに対して支援を与える。
【図面の簡単な説明】
【図１】本発明による、国旗カード（ここでは、ポリシー起動トークンとも呼ぶ）、暗号化ユニット、ホストシステム及びネットワークセキュリティサーバを含む、国際的暗号体系のブロック図でる。
【図２】本発明によるソフトウェア構成の概観を示すブロック図である。
【図３】本発明によるICF管理要素を示すブロック図である。
【図４】本発明によるアプリケーションと暗号化ユニットの間の信頼関係を示すブロック図である。
【図５】本発明によるアプリケーションの組み込みと更新を示すブロック図である。
【図６】本発明による署名権限で承認された変換Ｔに関してベース（Base）Ｂを変換させるプロセスの複合表示を示すブロック図である。
【図７】本発明によるアプレットのダウンロードと実行を示すブロック図である。
【図８】本発明による固定ポリシー起動トークンを示すブロック図である。
【図９】本発明による非干渉化（decoupling）の原理の図解である。
【図１０】本発明によるサービスクラスマッピングを示すブロック図である。
【図１１】本発明によるCOS識別子のネーム空間の図解である。
【図１２】本発明による定義済みサービスクラス識別子を示すブロック図である。
【図１３】本発明による折衝サービスクラス識別子を示すブロック図である。
【図１４】本発明によるランダムサービスクラス識別子を示すブロック図である。
【図１５】本発明による可変及び不変のサービスクラス属性を示すブロック図である。
【符号の説明】
10     アプリケーション
12     ポリシー起動トークン
14     暗号化ユニット
16     ホストシステム
18     ネットワークセキュリティサーバ
【図１】
0003753885.tif 000003
【図２】
0003753885.tif 000004
【図３】
0003753885.tif 000005
【図４】
0003753885.tif 000006
【図５】
0003753885.tif 000007
【図６】
0003753885.tif 000008
【図７】
0003753885.tif 000009
【図８】
0003753885.tif 000010
【図９】
0003753885.tif 000011
【図１０】
0003753885.tif 000012
【図１１】
0003753885.tif 000013
【図１２】
0003753885.tif 000014
【図１３】
0003753885.tif 000015
【図１４】
0003753885.tif 000016
【図１５】
0003753885.tif 000017