JP2001216043A

JP2001216043A - サービスの実装に課する制約を決定するための機構

Info

Publication number: JP2001216043A
Application number: JP2000354265A
Authority: JP
Inventors: Sharon S Liu; シャロン・エス・リウ; Jan Luehe; ジャン・ルーヘ
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1999-11-22
Filing date: 2000-11-21
Publication date: 2001-08-10
Also published as: EP1102154A3; IL139327A; EP1102154A2; IL139327A0

Abstract

(57)【要約】（修正有）【解決手段】アプリケーションが特定サービスのための
実装を求めるとき、アプリケーションはフレームワーク
に要求を出す。フレームワークは、この要求を受け取
り、これに対応して、制約が存在する場合は、どの制約
が要求された実装に課す必要のあるものかを決定する。
この制約は、実装を要求しているアプリケーションに与
えられた許可があるか否かを判断することにより決定さ
れ、この許可がある場合、前記実装に課する制約のセッ
トを導くためにこの許可を処理する。この許可は、導か
れる制約のセットが最も小さい制約度合いとなるよう処
理される。【効果】要求された実装の動的な構築により、フレーム
ワークは、必要な制約がアプリケーションに提供される
サービスに課されることを確実なものとする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、コンピュータシス
テムに関し、特に、アプリケーションにより要求された
サービスの実装に課する制約を決定するための機構に関
する。

【０００２】

【従来の技術】長年、米国商務省は、データ暗号化アル
ゴリズムを含むコンピュータプログラムまたはアプリケ
ーションの輸出を規制し、場合によっては禁止してき
た。現在原則として、一定ビット数以上の暗号鍵を用い
る暗号化アルゴリズムを使用しているコンピュータプロ
グラムは輸出できない（指定可能な鍵の長さはアルゴリ
ズム特有）。この規則には例外もある。例外の１つは、
免除機構が採用されている場合で、鍵の長さ、すなわち
プログラムの暗号強度を、場合によっては増加できる。
免除機構の例には、キー・エスクロー(key escrow)、キ
ー・リカバリー(key recovery)およびキー・ウィークニ
ング(key weakening)がある。また、プログラムの種類
によっては鍵の長さを大きくできる。たとえば、現在の
規制は、医療機関および金融機関向けのアプリケーショ
ンが鍵の長さを大きくして、アプリケーションの安全性
を高める（高度の機密データの保護に使用する）ことを
許容している。他のアプリケーションよりも許容範囲の
大きい恵まれたアプリケーションがある一方で、暗号化
アプリケーション全てに輸出規制が必要になる。

【０００３】

【発明が解決しようとする課題】これらの規制は、暗号
化アルゴリズムを直接使用しているプログラムに対して
適用されるだけではなく、暗号化アルゴリズムを直接使
用しているプログラムに対してインターフェイスを持っ
ているプログラムに対しても適用される。プログラムに
は、いろいろなプログラム間の相互作用を円滑に行うた
めのインフラを提供する「フレームワーク」プログラム
が含まれる。フレームワーク自体はどのような暗号化ア
ルゴリズムも実装しないが、暗号化アルゴリズムを実装
している１つまたは複数のプログラムが、フレームワー
クに対してインターフェイスし、又はフレームワークに
「プラグイン」することを許容できる。このようなフレ
ームワークの例の１つがカルフォルニア、パロアルトの
サンマイクロシステムズ社製のJava PlatformのJava Cr
yptography Extensionである。フレームワークが暗号機
構をフレームワークに「プラグイン」することを許容す
る場合には、フレームワーク自体に輸出規制が必要にな
る。このことは、輸出ができるようにするには、フレー
ムワークにブラグインされている暗号実装にかかわら
ず、全ての輸出規制が守られていることをフレームワー
クが保証する必要があることを意味している。この保証
を行うためには、フレームワークがいずれかの機構によ
って暗号実装を制約する必要がある。

【０００４】

【課題を解決するための手段】本発明に従えば、サービ
スに制約を課すカスタム化された実装を動的に構築する
機構が提供される。本発明の目的のために、サービスは
広義に定義され、暗号化/復号化機能などを含む（しか
し、これに限定されない）アプリケーションによって要
求又は該アプリケーションに対して提供される一切の機
能を包含する。本発明の一実施形態において、発明は、
アプリケーション、特定サービスの一般的な実装および
フレームワークを備えるシステム内で実現されている。

【０００５】フレームワークは、アプリケーションから
特定サービスの実装、たとえば特定暗号化アルゴリズム
の実装の要求を受け取る。これに対応して、フレームワ
ークは、制約が存在する場合は、要求された実装に課す
必要のある制約を決定する。一実施形態において、フレ
ームワークは、前記アプリケーションに与えられた許可
があるか否かを判断することにより、この制約を決定
し、もしこの許可がある場合、前記実装に課する制約の
セットを導くためにこの許可を処理する。一実施形態に
おいて、この許可は、導かれる制約のセットが最も小さ
い制約度合いとなるよう処理される。この制約が決定さ
れると、フレームワークは、要求された実装を動的に構
築する。一実施形態において、要求された実装は、それ
が前記サービスの一般的な実装、前記制約、及び前記一
般的な実装に制約を課する施行ロジックを組み込むよう
に構築される。要求された実装は、前記アプリケーショ
ンを対象に構築されるので、そのアプリケーション用に
カスタマイズされたものとなる。従って、この実装は、
カスタム化された実装と呼ばれる。

【０００６】カスタム化された実装が動的に構築された
後、フレームワークは、カスタム化された実装をアプリ
ケーションに提供する。その後、アプリケーションはサ
ービスのためにカスタム化された実装を直接呼び出す。
カスタム化された実装には、制約とそれを課するための
施行ロジックが組み込まれているので、アプリケーショ
ンは更にフレームワークと相互に作用する必要がない。
カスタム化された実装自体がサービスを提供し、確実に
制約が加えられることになる。このようにカスタム化さ
れた実装の動的な構築によって、フレームワークが、ア
プリケーションに対して提供されるサービスに必要な制
約を加えることができる。

【０００７】

【発明の実施の形態】図１に、本発明の実施形態の１つ
が実現されているシステム１００のブロック図を示す。
このシステム１００には、１または複数のアプリケーシ
ョン１０４、１または複数の一般的な実装１０６、指定
された制限のセット１０８および各種のコンポーネント
間の相互作用を円滑に行うためのフレームワーク１０２
が含まれる。アプリケーション１０４が、サービスの実
装をフレームワーク１０２に要求し、受け取る。ここ
で、アプリケーション１０４は、各種のアプリケーショ
ン又はプログラムでよく、Ｊａｖａアプレット、Ｊａｖ
ａアプリケーションおよびネイティブにコンパイルされ
たアプリケーション（これらに限定されない）などを含
む。本発明の目的のために、「サービス」という用語は
広義に定義され、暗号化/復号化機能などを含む（しか
し、これに限定されない）アプリケーションによって要
求又は該アプリケーションに対して提供される一切の機
能を包含する。

【０００８】アプリケーション１０４は、実装をフレー
ムワーク１０２に要求する場合、それが望む実装のため
のサービスの種類を指定する。たとえば、アプリケーシ
ョン１０４は「Blowfish」暗号化アルゴリズムの実装を
要求できる。これに対応して、フレームワーク１０２
は、要求を出しているアプリケーション１０４用にカス
タム化された、要求サービスの実装をアプリケーション
１０４に提供する。フレームワーク１０２によって提供
されるカスタム化された実装には、フレームワークが提
供するサービスの制約が含まれる。後述するように、こ
れらの制約は、指定された制限１０８のセット、及びも
しあれば、要求を出しているアプリケーション１０４に
認められた許可１１０に基づいて決定される。

【０００９】一般的な実装１０６は、フレームワーク１
０２に「プラグイン」されるか、インターフェイスされ
るサービスの実装を表している。一般的な実装１０６の
各々は、特定種類のサービスを実現する。たとえば、１
つの一般的な実装が「Blowfish」暗号化アルゴリズムを
実装し、同時に、もう１つの実装がＤＥＳ暗号化アルゴ
リズムを実装する。一般的な実装１０６の各々は、制約
されない。すなわち、制限１０８、または許可１１０が
存在しても、一般的な実装１０６自体は制約によって妨
げられない。これによって、一般的な実装１０６が暗号
化アルゴリズムの実装の場合、暗号化アルゴリズムを完
全な強度に設定できる。次に説明するように、適当な制
約がアプリケーション１０４に提供されるサービスに加
えられることを保証するのはフレームワーク１０２であ
って、一般的な実装１０６ではない。

【００１０】システム１００において、フレームワーク
１０２は、システム１００の動作全体を調整するコンポ
ーネントである。フレームワーク１０２の一般的な動作
を示す流れ図を、図２に示す。図２に示しているよう
に、フレームワーク１０２は、アプリケーション１０４
から特定種類のサービスの実装（たとえば、Blowfish暗
号化アルゴリズムの実装）の要求を受け取ることによっ
て動作する（２０２）。これに対応して、制約が存在す
る場合に、フレームワーク１０２は要求された実装に必
要な制約を判断する（２０４）。本発明の一実施形態に
おいて、フレームワーク１０２は、指定された制限１０
８を、もしあれば、要求を出しているアプリケーション
１０４に認められた許可１１０と調整することによって
制約を判断する。そして、本発明の一実施形態におい
て、フレームワーク１０２は可能な限り、最低限の制約
を加えようとする。言い換えると、フレームワーク１０
２は、許可１１０と制限１０８を考慮して可能な限り寛
大であるように試みる。

【００１１】制約が決まると、フレームワーク１０２
は、要求された実装を動的に構築する（２０６）。本発
明の一実施形態において、要求された実装は、要求され
たサービスの種類（たとえば、Blowfish暗号化アルゴリ
ズムを実現する一般的な実装１０６）を実装する、関連
する一般的な実装１０６を見つけることによって構成さ
れる。これが見つかると、この関連する一般的な実装１
０６は、前で決定された制約と共に、要求された実装に
組み込まれる。また、施行ロジックのセットもこの要求
された実装に組み込まれる。この施行ロジックは、この
制約が、関連する一般的な実装１０６に課されることを
保証する。従って、関連する一般的な実装１０６自体に
は制約が付いていないにもかかわらず、施行ロジック
が、関連する一般的な実装１０６に適用される適当な制
約となる。関連する一般的な実装、ここに組み込まれた
制約、および施行ロジックを使用して、要求された実装
の構築が完了する。要求された実装が、要求しているア
プリケーション１０４用に特別に構築、すなわち、要求
しているアプリケーション特有の制約を組み込むので、
要求された実装は、要求しているアプリケーション１０
４用にカスタム化された実装として見ることができる。

【００１２】カスタム化された実装が構築されると、要
求しているアプリケーション１０４にこの実装が渡され
る（２０８）。その後、アプリケーション１０４がカス
タム化された実装にサービスを直接要求する。カスタム
化された実装に、制約と制約を課すための施行ロジック
が組み込まれているので、アプリケーション１０４が更
にフレームワーク１０２と相互に作用する必要がなくな
る。カスタム化された実装自体がサービスを提供し、確
実に制約がサービスに加えられるようになる。この方法
のようにカスタム化された実装を動的に構築することに
よって、フレームワーク１０２が、アプリケーション１
０４に提供されるサービスに必要な制約を確実に加え
る。

【００１３】前述の説明は、本発明の一般的な概要を提
供している。図３で、本発明の一実施形態について詳細
に説明する。以下の説明で、本発明は、要求され、提供
されるサービスが暗号サービスであるオブジェクト指向
の実装に関連して説明されている。これが説明の目的の
ためだけに使用されていることに注意されたい。本発明
は説明の範囲に限定されない。適切に言えば、本発明
は、あらゆる種類のプログラミング環境と、制約が加え
られる必要のあるあらゆる種類のサービスに対して、一
般的に適用される。

【００１４】図３及び図４に、フレームワーク１０２の
詳細を示す。図に示されているように、フレームワーク
１０２は、アプリケーション・プログラミング・インタ
ーフェイス（ＡＰＩ）３０２、サービスプロバイダ・イ
ンターフェイス（ＳＰＩ）３０４およびコア３２０を備
える。ＡＰＩ３０２は、アプリケーション１０４が直接
呼び出すことができるリソースを表している。本発明の
一実施形態において、ＡＰＩ３０２はCipherオブジェク
トクラス３０６とExemptionMechanismオブジェクトクラ
ス３０８を備える。他のメソッドに混じって、Cipherオ
ブジェクトクラス３０６はGetInstanceメソッドとInit
メソッドを備える。GetInstanceメソッドは、アプリケ
ーションがサービスの実装を要求する場合に、アプリケ
ーション１０４によって呼び出されるメソッドである。
このメソッド呼び出しに対応して、Cipherオブジェクト
クラス３０６のインスタンスが構築され、呼び出してい
るアプリケーション１０４に返される。返されたCipher
インスタンスは、呼び出しているアプリケーション用に
カスタム化され、制約と、Cipherインスタンスが提供で
きるサービスにこの制約を加えるための施行ロジックを
含んでいる。Cipherインスタンスが返されると、Cipher
インスタンスのメソッドがアプリケーション１０４によ
って直接呼び出される。呼び出しているアプリケーショ
ン１０４によって呼び出される必要のあるメソッドの１
つがInitメソッドである。このメソッドは、Cipherイン
スタンスを初期化し、Cipherインスタンスが動作できる
ようにする。また、InitメソッドはCipherインスタンス
に制約を加えるための施行ロジックとして動作する。Ge
tInstanceメソッドとInitメソッドについては詳細に後
述する。

【００１５】すでに説明したように、１または複数の免
除機構（キー・エスクロー、キー・リカバリーまたはキ
ー・ウィークニング）が実装されている場合、場合によ
っては、暗号強度を強化した（たとえば、鍵長を長くし
た）暗号化アルゴリズムを実現できる。免除機構が実装
されている場合に、ExemptionMechanismオブジェクトク
ラス３０８が動作する。このクラスは、呼び出し可能な
複数のメソッドを提供する。これらのメソッドは、特定
の免除機構の機能を呼び出す（たとえば、免除機構がキ
ー・リカバリーである場合、キー・リカバリーブロック
を生成する）ためと、必要な動作が実行されたかどうか
（たとえば、キー・リカバリーブロックが生成されたか
どうか）を判断するために呼び出される。ＡＰＩ３０２
のオブジェクトクラス３０６、３０８については、後で
詳細に説明する。

【００１６】ＳＰＩ３０４は、サービスプロバイダに必
要なインターフェイスを提供して、サービスプロバイダ
のサービス実装をフレームワーク１０２にプラグインす
る。本発明の一実施形態において、ＳＰＩ３０４は、各
ＡＰＩ３０２オブジェクトクラスに対応するＳＰＩ３０
４オブジェクトクラスを備える。すなわち、ＡＰＩ３０
２のCipherオブジェクトクラス３０６に対して対応する
ＳＰＩ３０４のCipherSpiオブジェクトクラス３１０が
存在する。そして、ＡＰＩ３０２のExemptionMechanism
オブジェクトクラス３０８に対して対応するＳＰＩ３０
４のExemptionMechanismSpiオブジェクトクラス３１２
が存在する。この１対１の対応は、ＡＰＩクラス３０
６、３０８のメソッドをＳＰＩクラス３１０、３１２の
メソッドにマッピングすることを容易にする。この重要
性は詳細に後述される。ＳＰＩオブジェクトクラス３１
０と３１２は抽象オブジェクトクラスであり、クラスに
よって実装されなければならないメソッドを示している
と同時に、オブジェクトクラス自体がこれらのメソッド
の実装を何も提供しないことを意味している。実装の提
供は、サービスプロバイダが担当する。サービスの実装
１０６を提供するには、サービスプロバイダがＳＰＩ３
０４のオブジェクトクラスの１つをサブクラス化し、そ
のサブクラスにＳＰＩクラスの定義されたメソッドの全
てのために実装を用意する。このようにして、図３に示
されている一般的な実装１０６は、ＳＰＩ３０４のオブ
ジェクトクラス３１０と３１２のサブクラスになる。一
般的な実装１０６の各々は、異なった種類のサービスも
実装でき（たとえば、Blowfish暗号化アルゴリズムを実
装し、同時に、ＤＥＳ暗号化アルゴリズムを実装し、そ
して同時に、キー・リカバリー免除機構を実装でき
る）、一般的な実装１０６の各々が何の制約も受けずに
実現できる。これよって、一般的な実装１０６を最大限
の強度の実装（たとえば、暗号鍵の長さを無制限）にす
ることもできる。フレームワーク１０２のコア３２０
は、JCESecurityオブジェクトクラス３１４とJCESecuri
tyManagerオブジェクトクラス３１６を備える。本発明
の一実施形態において、これらのオブジェクトクラス３
１４と３１６はパッケージプライベートであり、アプリ
ケーション１０４が直接アクセスできない。図３に示さ
れているように、JCESecurityクラスはGetImplメソッド
を備え、JCESecurityManagerクラスはGetCryptoPermiss
ionメソッドを備える。これらのメソッドは、Cipherク
ラス３０６のGetInstanceメソッドの呼び出しの結果と
して呼び出され、協働して、カスタム化された実装の動
的な構築に必要な多数の作業を行う。これらの方法によ
って実行される機能は、全システムの内容が分かれば、
よく理解できる。従って、次に、発明の全てを円滑に理
解するために、図５及び図６の流れ図でシステムの全て
の動作を説明する。

【００１７】アプリケーション１０４は、それが特定の
暗号サービスの実装を必要としている場合に、Cipherオ
ブジェクトクラス３０６のGetInstanceメソッドを呼び
出すことよって実装の要求を出す。この呼び出しでは、
アプリケーションが実装を要求しているサービスの種類
を指定する。本発明の一実施形態において、サービスの
種類は、たとえばBlowfishのような暗号化アルゴリズム
名になる。Cipherクラス３０６はこの要求を受け取り
（４０４）、GetInstanceメソッドの機能を呼び出す。
これに対応して、GetInstanceメソッドは、JCESecurity
クラス３１４のGetImplメソッドを呼び出す。GetImplメ
ソッドは、複数の重要な機能を実行する。このメソッド
は、まず、要求された種類のサービスを実装している一
般的な実装１０６が使用可能かどうか判断する（４０
８）。たとえば、一般的な実装１０６のいずれかがBlow
fish暗号化アルゴリズムを実装しているかどうか判断す
る。適当な一般的な実装１０６が見つからなかった場
合、GetInstanceメソッドにエラーメッセージを返し
（４１２）、次に、呼び出しているアプリケーション１
０４にエラーメッセージを返す。逆に、要求されたサー
ビスを実装している一般的な実装１０６が見つかった場
合、GetImplメソッドは、見つかった一般的な実装が認
証されているかどうか続けて判断する（４１６）。この
認証を行う方法については詳細に後述するが、ここで
は、認証が、デジタル署名検証機構を使用して行われ
る、とだけ説明しておく。

【００１８】GetImplメソッドがその一般的な実装が認
証されていないと判断した場合、要求されているサービ
スが行える一般的な実装１０６が他に存在しないかどう
か判断する（４２０）。他に一般的な実装１０６が存在
しない場合、GetImplメソッドはGetInstanceメソッドに
エラーメッセージを返し（４２４）、次に、呼び出して
いるアプリケーション１０４にエラーメッセージを返
す。要求されているサービスが行える一般的な実装１０
６が他に存在する場合、GetImplメソッドは、工程４１
６に戻って、新しい一般的な実装が認証されているかど
うか判断する。この処理が、認証された実装が見つかる
か、要求されたサービスが行える認証された一般的な実
装１０６が存在しないと判断されるまで続く。

【００１９】要求されたサービスの認証された一般的な
実装１０６（この実装は関連する実装と呼ばれることに
なる）が見つかった場合、GetImplメソッドは関連する
実装をインスタンス化して（４２８）実装のインスタン
ス（すなわちCipherＳＰＩインスタンス）を生成する。
その後、GetImplメソッドが何らかの制限を実装のイン
スタンスに加える必要があるかどうか判断する（４３
２）。本発明の一実施形態において、この判断は、フレ
ームワーク１０２が国内的な動作または世界的な動作の
ために設定されているかどうか判断することによって行
われる。フレームワークが国内での使用に限られるよう
に設定されている場合、輸出規制が適用されないので、
制約を加える必要はない。一方、フレームワーク１０２
が世界的な動作を行うように設定されている場合、制限
の可能性が考慮される。

【００２０】実装のインスタンスに加えられる制約を判
断するために（４３６）、GetImplメソッドはJCESecuri
tyManagerクラス３１６のGetCryptoPermissionメソッド
を呼び出す。GetCryptoPermissionメソッドの重要な機
能は、指定された制限１０８と、もしあれば、呼び出し
ているアプリケーション１０４に認められた許可１１０
とを調整し、制約のセットを導くことである。この制約
のセットがGetCryptoPermissionメソッドによってGetIm
plメソッドに返される。そして、本発明の一実施形態に
おいて、この制約のセットには、要求された暗号化アル
ゴリズムの名前、（もし存在するとすれば）課せられる
必要のある免除機構の名前、使用される最大鍵長や暗号
の最大実行繰り返し数（ＲＣ５などのアルゴリズムに必
要）などの幾つかの暗号パラメータが含まれる。GetImp
lメソッドは、この制約を受け取ると、免除機構がこの
制約内で指定されているかどうか判断する（４４０）。
免除機構が制約内で指定されていない場合、GetImplメ
ソッドは、工程４４８に進む。

【００２１】しかし、免除機構が指定されている場合、
GetImplメソッドは指定された免除機構のインスタンス
を続けて生成する。本発明の一実施形態において、これ
は、ExemptionMechanismクラス３０８のGetInstanceメ
ソッドを呼び出し、免除機構の名前を伝えることによっ
て達成される。この呼び出しに対してExemptionMechani
smクラス３０８のGetInstanceメソッドは、JCESecurity
クラス３１４のGetImplメソッドを呼び出す（この呼び
出しは、GetImplメソッドの第２の呼び出しになること
に注意されたい）。これに対応して、GetImplメソッド
は指定された免除機構を実装している有効な一般的な実
装１０６を検索し、その一般的な実装１０６をインスタ
ンス化して（４４４）、ExemptionMechanismSpiインス
タンスを生成する。その後、GetImplメソッドはExempti
onMechanismSpiインスタンスをExemptionMechanismクラ
ス３０８のGetInstanceメソッドに返す（これは、GetIm
plメソッドの第２の呼び出しからの復帰である）。

【００２２】次に、ExemptionMechanismクラス３０８の
GetInstanceメソッドは、ExemptionMechanismクラス３
０８のコンストラクタを呼び出し、GetImplメソッドか
ら戻されたExemptionMechanismSpiインスタンスをコン
ストラクタに渡す。呼び出された場合に、コンストラク
タはExemptionMechanismクラス３０８をインスタンス化
して、ExemptionMechanismインスタンスを生成する。次
に、コンストラクタは、ExemptionMechanismSpiインス
タンスをExemptionMechanismインスタンス内にカプセル
化する。その際に、コンストラクタは、ExemptionMecha
nismインスタンスのメソッドをExemptionMechanismSpi
インスタンスの対応するメソッドにマッピングする。本
発明の一実施形態において、ExemptionMechanismインス
タンスのInitメソッドがExemptionMechanismSpiインス
タンスのEngineInitメソッドにマッピングされ、GenExe
mptionBlobメソッドがEngineGenExemptionBlobメソッド
にマッピングされる。このマッピングは、ExemptionMec
hanismインスタンスのメソッドへの呼び出しがExemptio
nMechanismSpiインスタンスの正しいメソッドに送られ
るようにする。ExemptionMechanismSpiインスタンスがE
xemptionMechanismインスタンス内にカプセル化される
と、ExemptionMechanismインスタンスのインスタンス化
が完了する。

【００２３】その後、GetImplメソッドはCipherクラス
３０６のGetInstanceメソッドに返り（これは、GetImpl
メソッドの第１の呼び出しからの復帰である）、GetIns
tanceメソッドに、実装のインスタンス、制約のセッ
ト、および（もしあれば）ExemptionMechanismインスタ
ンスを提供する。次に、Cipherクラス３０６のGetInsta
nceメソッドは、Cipherクラス３０６のコンストラクタ
を呼び出し、コンストラクタにGetImplメソッドから受
け取った実装のインスタンス、制約のセット、および
（もしあれば）ExemptionMechanismインスタンスを渡
す。これに対応して、コンストラクタは、Cipherクラス
３０６をインスタンス化（４４８）して、Cipherインス
タンスを生成する。次に、コンストラクタは、実装のイ
ンスタンス、制約のセット、および（もしあれば）Exem
ptionMechanismインスタンスをCipherインスタンス内に
カプセル化する（４５２）。つまり、Cipherインスタン
スは「ラッパー」オブジェクトとして動作する。実装の
インスタンスをCipherインスタンスにカプセル化する場
合に、コンストラクタはCipherインスタンスのメソッド
を対応する実装のインスタンスメソッドにマッピングす
る。本発明の一実施形態において、Cipherインスタンス
のInitメソッドは、実装のインスタンスのEngineInitメ
ソッドにマッピングされ、Updateメソッドは、EngineUp
dateメソッドにマッピングされ、DoFinalメソッドは、E
ngineDoFinalメソッドにマッピングされる。このマッピ
ングは、Cipherインスタンスのメソッドへの呼び出しが
正しい実装のインスタンスのメソッドに送られるように
する。これらのメソッドの実装が実装のインスタンスに
よって提供されるので、このようになる。カプセル化処
理が完了すると、コンストラクタは、Cipherクラス３０
６のGetInstanceメソッドに戻る。次に、GetInstanceメ
ソッドは呼び出しているアプリケーション１０４に戻
り、アプリケーション１０４に新しく構築されたCipher
インスタンスを提供する（４５６）。その後、呼び出し
ているアプリケーション１０４は、Cipherインスタンス
のメソッドを直接呼び出すことができる。

【００２４】本発明の一実施形態において、呼び出して
いるアプリケーション１０４がCipherインスタンスを呼
び出す必要のある最初のメソッドの１つが、Initメソッ
ドである。この方法は、Cipherインスタンスの初期化を
行い、通常の動作用にInitメソッドを準備する。このメ
ソッドを呼び出しているときに、呼び出しているアプリ
ケーション１０４は、初期化パラメータのセットを提供
する。本発明の一実施形態において、これらのパラメー
タには、暗号化に使用される暗号鍵と、暗号の繰り返し
数などのアルゴリズム固有の属性を規定している任意の
他の暗号パラメータ（特定の暗号化アルゴリズムが必要
とする場合）が含まれる。

【００２５】Initメソッドが呼び出された場合に、Init
メソッドは、呼び出しているアプリケーション１０４に
よって渡された初期化パラメータとCipherインスタンス
内にカプセル化された制約を比較する。初期化パラメー
タが制約のレベルまたはそれ以下の場合、Initメソッド
は初期化パラメータを実装のインスタンスのEngineInit
メソッドに渡して、実装のインスタンスが初期化できる
ようにする。実装のインスタンスが初期化された後、Ci
pherインスタンスが動作可能な状態になる。このよう
に、暗号化/復号化の動作を実行するために、Cipherイ
ンスタンスのUpdateメソッドとDoFinalメソッドを、呼
び出しているアプリケーション１０４よって呼び出すこ
とができる。しかし、Initメソッドが、呼び出している
アプリケーション１０４によって渡される初期化パラメ
ータがカプセル化された制約のレベルを超えたと判断し
た場合には、Initメソッドが初期化パラメータを実装の
インスタンスのEngineInitメソッドに渡されないように
する。それによって、実装のインスタンス、すなわち、
Cipherインスタンスを初期化しないようにする。Cipher
インスタンスが初期化されない場合、Cipherインスタン
スは正常に動作できなくなる。このように、初期化を行
わないことによって、Initメソッドは、効果的にCipher
インスタンスを動作できないようにする。この方法で、
Initメソッドは、カプセル化された制約が実装のインス
タンスに課せられることを確実にする施行ロジックとし
て働く。

【００２６】ExemptionMechanismインスタンスがCipher
インスタンス内にカプセル化される場合に、Cipherクラ
ス３０６のInitメソッドは、追加の機能を実行する。そ
の機能は、ExemptionMechanismインスタンスがアプリケ
ーション１０４によって正しく呼び出され、データの暗
号化を行う前に必要な動作を実行することを確実にす
る。たとえば、免除機構がキー・リカバリーの場合に
は、データの暗号化を行う前に、ExemptionMechanismイ
ンスタンスを呼び出して、キー・リカバリーブロックを
生成し、保存する必要がある。必要な動作がExemptionM
echanismインスタンスによって実行されたことを確実に
するために、Initメソッドは、ExemptionMechanismイン
スタンスのIsCryptoAllowedメソッドを呼び出す。本発
明の一実施形態において、ExemptionMechanismインスタ
ンスは、そのGenExemptionBlobメソッドが呼び出された
かどうかについて情報をその中に保持している（Exempt
ionMechanismインスタンスは、必要な免除機構の動作が
実行される元になっている）。この情報は、IsCryptoAl
lowedメソッドを呼び出してアクセスできる。このIsCry
ptoAllowedメソッドが、必要な動作が実行された（すな
わち、GenExemptionBlobメソッドが呼び出された）こと
を示している場合、Initメソッドは実装のインスタン
ス、すなわち、Cipherインスタンスが初期化できるよう
にする。必要な動作が実行されていない場合は、Initメ
ソッドが初期化ができないようにするので、Cipherイン
スタンスは動作できないようになる。従って、Initメソ
ッドは、実装のインスタンスに制約を加えるだけではな
く、免除機構が適用されることも確実にする。

【００２７】前述したように、それは、Cipherインスタ
ンスによって提供されるサービスに加えられる制約を判
断するJCESecurityManagerクラス３１６のGetCryptoPer
missionメソッドである。これらの制約は、指定された
制限１０８と、もしあれば、呼び出しているアプリケー
ション１０４に認められた許可１１０に基づいて決定さ
れる。GetCryptoPermissionメソッドの一実施形態を次
に説明するが、実施形態を詳細に説明する前に、本発明
の全てを円滑に理解するために、制限１０８と許可１１
０について簡単に説明する。

【００２８】本発明の一実施形態において、制限１０８
はデフォルト設定と免除設定の２セットの制限から構成
される。基本的にデフォルト設定は、免除機構が実装さ
れていない場合に暗号化アルゴリズムに加える必要のあ
る初期制限を指定する。そして、免除設定には、免除機
構が実装されている場合に暗号化アルゴリズムに加える
必要のある制限を指定する。一般的に、免除機構が実装
されている場合には、強固な暗号パラメータが使用でき
る。本発明の一実施形態において、両設定の制限は、適
用される法律と規制に基づく。

【００２９】制限の各設定（デフォルト設定または免除
設定）は、０または１個以上のエントリから構成され
る。各エントリには、特定の暗号化アルゴリズムと、そ
のアルゴリズムに加えられる幾つかの制限を指定する。
制限に関する各設定のエントリは同じ構造をしている。
本発明の一実施形態において、各エントリは、次の情報
を保存するフィールドまたは情報コンテナから構成され
る。（１）暗号化アルゴリズム名または識別子（２）免除機構名または識別子（３）最大鍵長、および（４）実行される暗号の最大繰り返し数などのその他の
アルゴリズム固有の暗号の制限

【００３０】本発明の目的のために、エントリはどのよ
うな望ましい形式も可能である。たとえば、各エントリ
を、その中にカプセル化された必要な情報を持っている
オブジェクトとして実装できるし、各エントリをファイ
ル内のテキストの組み合わせとすることもできる。正し
い情報が提供されている限り、どのような望ましいの形
式も使用できる。

【００３１】図７に制限のデフォルト設定と免除設定の
例を示す。デフォルト設定のエントリでは、免除機構の
どれも指定せず、免除設定のエントリでは必ず免除機構
を指定することに注意する。デフォルト設定は免除機構
が実装されていない場合に加えられる制約を指定し、免
除設定は免除機構が実装されている場合に加えられる制
約を指定するので、このようになる。

【００３２】制限のデフォルト設定の解釈は簡単であ
る。基本的に、各エントリは、特定の暗号化アルゴリズ
ムについての最大暗号パラメータを表している。従っ
て、図７のようにBlowfishアルゴリズムでは、１２８ビ
ットの最大鍵長が使用される。同様に、ＲＣ５アルゴリ
ズムでは、６４ビットの最大鍵長、１０回の暗号の最大
繰り返し数が使用される。免除設定の解釈もほぼ同じよ
うに簡単である。基本的に、免除設定の第１エントリ
は、キー・リカバリー免除機構がBlowfishアルゴリズム
と共に実装されている場合に、最大鍵長を増加させて２
５６ビットにできることを示している。同様に、第２エ
ントリはキー・エスクロー免除機構がBlowfishアルゴリ
ズムと共に実装されている場合に、最大鍵長を増加させ
て２５６ビットにできることを示している。免除設定で
は、同じアルゴリズム名（この場合はBlowfish）を複数
のエントリに記述できることに注意されたい。これらの
エントリに指定する免除機構が異なれば、同じアルゴリ
ズム名を記述できる。

【００３３】指定される制限１０８は、Cipherインスタ
ンスに加えられる制約の決定で考慮される因子の一部に
過ぎない。もう１つの因子は、呼び出しているアプリケ
ーション１０４に認められた許可１１０がもし存在する
とすれば、それらである。以前に説明したように、たと
えば医療機関と金融機関用のアプリケーションのような
種類のアプリケーションは、他のアプリケーションに比
べて強固な暗号法を使用できる。医療機関と金融機関用
のアプリケーションやその他のアプリケーションで、強
固な暗号法を使用する権限は、アプリケーションに認め
られた許可１１０に反映される。本発明の一実施形態に
おいて、許可１１０は複数の形式のうちの１つを取る。
１番目の形式はCryptoAllPermission情報である。アプ
リケーションがCryptoAllPermissionを与えられている
場合、その意味はアプリケーションには可能な全ての許
可が与えられていることになる。言い換えると、アプリ
ケーションは制限されない。これは、認められることの
できる最高の許可を可能にし、従って、極く少数のアプ
リケーションに認められる。

【００３４】アプリケーションに認められるこれよりも
低い許可は、特定の暗号アルゴリズムの暗号強度を強化
し、または無制限に実装するための許可である。本発明
の一実施形態において、この種の許可は、特定のアルゴ
リズム名（たとえば、Blowfish）と任意の最大パラメー
タの組み合わせ（たとえば、最大鍵長）を指定する。最
大パラメータの組み合わせが指定された場合、暗号化ア
ルゴリズムは指定される最大パラメータのレベルで実装
され得る。最大パラメータの組み合わせが指定されなか
った場合、暗号化アルゴリズムは任意のレベルで実装さ
れ得る（すなわち、アルゴリズムが制約されない）。こ
のように、許可で１２８ビットの最大鍵長と共にBlowfi
shが指定されている場合、アプリケーションは１２８ビ
ットの最大鍵長でBlowfish暗号化アルゴリズムを使用で
きる。許可でBlowfishが指定されているだけの場合、ア
プリケーションは鍵の長さに制限されずにBlowfish暗号
化アルゴリズムを使用できる。これまで、最大パラメー
タについては、最大鍵長だけを説明した。最大パラメー
タは、暗号の最大繰り返し数などの別のパラメータを含
むことができることに注意すべきである。このような別
のパラメータは、ＲＣ５などの暗号化アルゴリズムが要
求することもでき、したがって、最大パラメータの中に
含めることもできる。

【００３５】更に、アプリケーションに認められる他の
許可は、特定の暗号化アルゴリズム（たとえば、Blowfi
shを使用したキー・リカバリー）に特定の免除機構を実
装するための許可である。前述したように、免除機構を
実装すると、通常、アプリケーションが強固な暗号パラ
メータ（たとえば、長い鍵長）を使用できるようにな
る。このように、免除機構を実装する許可は、非常に暗
号強度を向上させる。許可が実際に制限１０８の内容に
依存するかしないか、そして、免除機構の実装が使用可
能かどうかが次に説明される。この点で、アプリケーシ
ョンは、複数の許可を認められることも可能であること
に注意しなければならない。たとえば、アプリケーショ
ンが、複数種類の免除機構を実装することもできる。そ
の場合とその他の場合に、１つのアプリケーションが、
複数の許可を認められることができる。

【００３６】次に、このような背景情報を元に、図８の
流れ図によって、JCESecurityManagerクラス３１６のGe
tCryptoPermissionメソッドの動作について説明する。G
etCryptoPermissionメソッドは、それが呼び出された場
合、呼び出しているアプリケーション１０４によって要
求されている暗号化アルゴリズム名（たとえば、Blowfi
sh）を含むパラメータのセットを受け取る。呼び出しに
対応して、GetCryptoPermissionメソッドは、まず、呼
び出しているアプリケーション１０４を決定する（６０
４）。すなわち、GetCryptoPermissionメソッドは、Get
CryptoPermissionメソッドが呼び出される原因になった
GetInstanceメソッドを呼び出したアプリケーション１
０４を決定する。本発明の一実施形態において、GetCry
ptoPermissionメソッドは、この決定をコール・スタッ
クを詳細に検討することによって行う。これは、呼び出
し順序をトレースして、GetCryptoPermissionメソッド
からGetImplメソッドに戻り、次にGetInstanceメソッド
に戻り、次にGetInstanceメソッドを最初に呼び出して
いるアプリケーション１０４に戻ることにより行う。こ
の方法のように、コール・スタックを詳細に検討するこ
とによって、GetCryptoPermissionメソッドが最初の呼
び出しアプリケーション１０４を決定できる。

【００３７】呼び出しているアプリケーション１０４が
決定されると、呼び出しているアプリケーション１０４
が、それに認められた何らかの有効な許可を持っている
かを決定する（６０８）。本発明の一実施形態におい
て、これは何らかの許可がそもそもアプリケーション１
０４に与えられたかどうかまず決定することで行われ
る。本発明の一実施形態において、この決定は、アプリ
ケーション１０４に関係するファイルを確認し、この中
に何らかの許可が含まれているかどうか確認することに
よって行われる。Ｊａｖａプログラミング環境では、ア
プリケーションのファイルはＪＡＲファイルに含まれ、
この環境では、このＪＡＲファイルを許可の確認に使用
する。

【００３８】何らかの許可が見つかった場合、検証処理
が実行され、許可が有効であることが保証される。本発
明の一実施形態において、この検証はデジタル署名を使
用して行われる。具体的には、１または複数の許可を含
む任意のアプリケーション１０４には、デジタル署名さ
れたＪＡＲファイルが存在する。このデジタル署名は、
アプリケーション１０４の出所が信頼されており、アプ
リケーション１０４の内容が変更されていなかったこと
を確実にしている。このデジタル署名が検証される場
合、ＪＡＲファイル内に含まれる許可が有効であること
を意味している。このデジタル署名が検証されない場
合、許可は無効である。GetCryptoPermissionメソッド
は、デジタル署名検証機構を使用してこの検証を行う。
本発明の目的のために、適切で効果的なデジタル署名検
証機構も使用できる。

【００３９】GetCryptoPermissionメソッドが呼び出し
ているアプリケーション１０４が有効な許可を持ってい
ないと判断した場合に、GetCryptoPermissionメソッド
は、制限のデフォルト設定の制限に基づいてCipherイン
スタンスに加えられる制約を決定する（６１２）。具体
的には、GetCryptoPermissionメソッドは、呼び出して
いるアプリケーション１０４によって要求されている暗
号化アルゴリズムと同じアルゴリズム名のエントリの、
デフォルト設定エントリを検索する。そのエントリが見
つかった後に、制約がそのエントリ内に指定される制限
（たとえば、最大鍵長と他の制限）から導かれる。たと
えば、呼び出しているアプリケーション１０４がBlowfi
shアルゴリズムの実装を要求している場合に、図７の例
のように、制約は最大鍵長が１２８ビットのBlowfishと
なるだろう。制約が決まった後、制約がGetCryptoPermi
ssionメソッドによってJCESecurityクラス３１４のGetI
mplメソッドに返される（６１６）。

【００４０】工程６０８に戻って、GetCryptoPermissio
nメソッドが呼び出しているアプリケーション１０４が
１または複数の有効な許可を持っていると判断した場合
に、GetCryptoPermissionメソッドは、これらの許可の
いずれかがCryptoAllPermissionかどうかを決定する
（６２０）。CryptoAllPermissionの場合、アプリケー
ション１０４は制限されない。その場合、GetCryptoPer
missionメソッドは、制約無しの指示をGetImplメソッド
に返す（６２４）。しかし、許可がいずれもCryptoAllP
ermissionではない場合、GetCryptoPermissionメソッド
は工程６２８に進む。

【００４１】工程６２８まで処理すると、アプリケーシ
ョン１０４が１または複数の有効な許可を持っており、
これらの許可がいずれもCryptoAllPermissionでないこ
とが分かる。従って、許可は次の２種類のうちのいずれ
かになることを意味する。（１）加えられるべき免除機構を要求しない種類（すな
わち、特定の暗号化アルゴリズムと随意な最大パラメー
タのセットを指定する種類）、または、（２）加えられ
るべき免除機構を要求する種類（すなわち、特定の暗号
化アルゴリズムと共に免除機構を指定する種類）

【００４２】工程６２８で、GetCryptoPermissionメソ
ッドは、許可のいずれかが、加えられるべき免除機構を
要求しない種類のものであるかどうか決定する。許可の
いずれかがこの種類の場合、それらの許可の各々に対し
て、その許可が適用できるかどうかについて決定する
（６３２）。許可が適用できるのは、許可に指定された
暗号化アルゴリズムが、アプリケーション１０４によっ
て要求されている暗号化アルゴリズムと同じ場合であ
る。たとえば、アプリケーション１０４がBlowfishアル
ゴリズムの実装を要求している場合、許可に指定された
暗号化アルゴリズムがBlowfishアルゴリズムを指定して
いるときに１つの許可が適用になる。本発明の一実施形
態においては、最大１つの許可が適用される。GetCrypt
oPermissionメソッドが許可の１つが適用になることを
決定する場合、GetCryptoPermissionメソッドは、許可
に指定された最大パラメータ（もし存在すれば）に基づ
いてCipherインスタンスに加えられる制約を決定する。
すなわち、最大パラメータのセットが許可に指定された
場合、制約は指定された最大パラメータに基づいて決定
される。最大パラメータの組み合わせが指定されていな
い場合、制約は無制限になり、暗号化アルゴリズムは制
約されない。制約が決定された後、制約がGetCryptoPer
missionメソッドによってJCESecurityクラス３１４のGe
tImplメソッドに返される（６３６）。

【００４３】工程６３２に戻って、GetCryptoPermissio
nメソッドが、加えられるべき免除機構を要求しない許
可のいずれもが適用できないことを決定した場合、工程
６４０に進む。工程６４０で、GetCryptoPermissionメ
ソッドは、アプリケーション１０４に与えられた許可の
いずれかが、加えられるべき免除機構を要求する種類で
あるかどうか決定する。このような許可が見つからなか
った場合、GetCryptoPermissionメソッドは制約のデフ
ォルト設定を使用してCipherインスタンスに加える制約
を決定する（６４４）。制約を決定する方法は、前述の
工程６１２に関連して説明した方法と同じである。制約
が決まった後、制約がGetCryptoPermissionメソッドに
よってGetImplメソッドに返される（６４８）。

【００４４】一方、アプリケーション１０４に認められ
た許可の少なくとも１つが、加えられるべき免除機構を
要求する種類であると、GetCryptoPermissionメソッド
が決定した場合には、工程６５２に進む。工程６５２
で、GetCryptoPermissionメソッドは、加えられるべき
免除機構を要求する許可のいずれかが適用できるかどう
かを決定する。具体的には、GetCryptoPermissionメソ
ッドは、これらの許可のどれが要求されている暗号化ア
ルゴリズムに適用できるか、適用する許可の各々に対し
て、その特定の暗号化アルゴリズム/免除機構のセット
が使用できるか、および指定された免除機構の実装が使
用可能かどうかを、決定する。これらの機能を実行する
際に、GetCryptoPermissionメソッドは、制限の免除設
定を参照する。これらの動作は、例示によってよく理解
できる。

【００４５】要求されている暗号化アルゴリズムがBlow
fishアルゴリズムであり、アプリケーションが、次の２
種類の許可を認められているとする。（１）Blowfishとキー・ウィークニングおよび（２）Bl
owfishとキー・リカバリー

【００４６】さらに図７に示されている制限の免除設定
を仮定する。この例では、許可が共にBlowfishに関連し
ているので、両方の許可が、要求しているアプリケーシ
ョンに適用する。従って、両方の許可は共に処理される
ことになり、第１の許可から処理し始める。第１の許可
は、キー・ウィークニングがBlowfishと共に使用される
ことができるようにする。この許可が使用可能かどうか
を決定するために、GetCryptoPermissionメソッドがこ
の組み合わせを持つエントリの免除設定を検索する。免
除設定にはBlowfishの２つのエントリが存在するが、こ
れらのエントリのどちらも免除機構としてキー・ウィー
クニングを指定していない。従って、制限の免除設定が
使用できるBlowfishとキー・ウィークニングの組み合わ
せが明示されていないないので、この許可を使用または
適用できない。

【００４７】この場合、GetCryptoPermissionメソッド
は、Blowfishと共に使用されるキー・リカバリーを許可
する次の許可の処理に進む。この許可は最初と同じ方法
すなわち、免除設定のエントリを検索して処理される。
今回は、Blowfishとキー・リカバリーが指定された組み
合わせを使用できるエントリが見つかる。結果として、
この許可が使用又は適用可能になる。しかし、問い合わ
せはそこで終わらない。GetCryptoPermissionメソッド
は、この許可の使用を認める前に、指定された免除機構
（この例ではキー・リカバリー）の有効な実装が使用可
能かどうか決定する。そして、実装が使用可能でない場
合、この許可を適用しない。この決定を行う際に、GetC
ryptoPermissionメソッドは指定された免除機構を実装
する有効な一般的な実装１０６（図４）を検索する。こ
の処理の終了（６５２）までに、GetCryptoPermission
メソッドは認められた許可のいずれかを適用できるかど
うかが分かることになる。

【００４８】許可が適用できることをGetCryptoPermiss
ionメソッドが決定する場合に、GetCryptoPermissionメ
ソッドは、制限のデフォルト設定ではなく免除設定を使
用し、Cipherインスタンスに加えられる制約を決定する
（６５６）。具体的には、GetCryptoPermissionメソッ
ドは、この許可と同じアルゴリズム名と免除機構を持っ
ている免除設定のエントリから制約を導く。対象の例で
このエントリは、免除設定の最初のエントリであり、そ
の制約は最大鍵長が２５６ビットのキー・リカバリーを
備えたBlowfishである。これらの制約が決まった後、制
約がGetCryptoPermissionメソッドによってJCESecurity
クラス３１４のGetImplメソッドに返される（６６
０）。前述したように、免除設定のエントリは、通常、
デフォルト設定よりも強固な暗号パラメータが使用でき
るようにする。従って、免除設定の制約を導くことで、
GetCryptoPermissionメソッドは、Cipherインスタンス
の暗号強度を向上させる。

【００４９】工程６５２に戻って、いずれの許可も適用
できない場合、GetCryptoPermissionメソッドは制限の
デフォルト設定を使用して、Cipherインスタンスに加え
られる制約を決定する（６４４）。制約を決定する方法
は、工程６１２に関連して上記で説明した方法と同じで
ある。従って、アプリケーション１０４は、アプリケー
ションがまったく許可を与えられていない場合と同じよ
うに取り扱われる。制約が決まった後に、制約がGetCry
ptoPermissionメソッドによってGetImplメソッドに返さ
れる（６４８）。説明した方法のように、GetCryptoPer
missionメソッドはCipherインスタンスに加えられる制
約を決定する。最初に許可を適用しようとし、次に、い
ずれの許可も適用しない場合に初期制限を使用すること
によって、GetCryptoPermissionメソッドは、Cipherイ
ンスタンスに、与えられる限りの制限で最大の暗号強度
を与えようとする。言い換えると、GetCryptoPermissio
nメソッドは最低レベルの制約を加えようとする。

【００５０】前述したように、制限１０８の全セット
（図１）を含む制限のデフォルト設定と免除設定は、適
用可能な法律と規制に基づいている。本発明の一実施形
態において、それらは少なくとも次の２つの法律と規制
に基づいて導かれる。（１）米国輸出法、および（２）現地法（フレームワー
ク１０２が輸入される国または地域の法律）

【００５１】これらの法律のセットは、ほとんどの場
合、異なるので、両方の法律のセットと一致する１つの
制限のセットを導くために、調整処理が実行される。本
発明の一実施形態において、この調整はマージ処理を使
用して行われる。具体的には、２つの法律のセットはマ
ージされて制限１０８の結果セットを生成し、マージ
は、その得られた制限１０８が２つの法律のセットの最
も制約された制限を含むような方法で実行される。最も
制約された制限を選択することで、マージ処理は得られ
た制限１０８が両方の法律のセットに従っていることを
保証する。

【００５２】図９はマージ処理の概要を表している。図
に示されているように、米国輸出法７０２は、デフォル
トコンポーネント７０６と免除コンポーネント７０８か
ら構成される。同様に、現地法７０４は、デフォルトコ
ンポーネント７１０と免除コンポーネント７１２から構
成される。デフォルトコンポーネント７０６と７１０
は、免除機構が実装されていない場合に暗号化アルゴリ
ズムに適用されるデフォルトの制限を指定する。そし
て、免除コンポーネント７０８と７１２は、免除機構が
実装されている場合の制限を指定する。本発明の一実施
形態において、デフォルトコンポーネント７０６、７１
０と免除コンポーネント７０８、７１２は前に、図７と
関連して説明した制限のデフォルト設定７１４と免除設
定７１６と同じ形式をしている。すなわち、各コンポー
ネント７０６、７１０、７０８、７１２は、０またはそ
れ以上のエントリから構成される。各エントリは、以下
を保存するためのフィールドまたはコンテナを備える。（１）暗号化アルゴリズム名または識別子（２）免除機構名または識別子（３）最大鍵長および（４）他の暗号制限

【００５３】得られた制限１０８を導くには、デフォル
トコンポーネント７０６と７１０をエントリごとにマー
ジして、得られる制限１０８のデフォルト設定７１４を
生成する。また、免除コンポーネント７０８と７１２を
エントリごとにマージして、得られる制限１０８の免除
設定７１６を生成する。この制限が導かれた後、得られ
た制限１０８はJCESecurityManagerクラス３１６のGetC
ryptoPermissionメソッドによって使用されて、Cipher
インスタンスに加えられる制約を決定する。

【００５４】次に、図１０及び図１１のフローチャート
に沿って、マージ処理の一実施形態を説明する。次の説
明では、政策Ａ、ＢおよびＣを使用して説明する。政策
ＡとＢは、マージの情報源（たとえば、米国輸出法と現
地法）を指す。また、政策Ｃはマージ結果を指す（たと
えば、得られた制限１０８）。図９に示したように、デ
フォルトコンポーネント７０６、７１０と免除コンポー
ネント７０８、７１２は別個のマージ操作を使用して別
々にマージされる。しかし、両方のマージで同じマージ
処理が使用されることに注意されたい。

【００５５】さて、図１０のように、マージ処理は政策
Ａの次のエントリ（この場合は最初のエントリ）の選択
（８０４）から始まる。選択したエントリと政策Ｂのエ
ントリとを比較して、対応するエントリが政策Ｂに存在
するかどうかを決定する（８０８）。本発明の一実施形
態において、この決定は、選択されたエントリのアルゴ
リズム名および免除機構名と、政策Ｂのエントリのアル
ゴリズム名および免除機構名とを比較して行われる。政
策Ｂのエントリに同じ名前のアルゴリズムと免除機構の
組み合わせが存在すると、そのエントリが対応するエン
トリになる。この場合に、２つの対応するエントリの制
限が比較されて、最も制約された制限を決定する（８２
０）。

【００５６】この方法の例として、政策ＡとＢの両方の
アルゴリズム名がＲＣ５で、免除機構が存在しないエン
トリを考える。また、政策Ａのエントリの最大鍵長が６
４ビット、最大繰り返し数が１２、政策Ｂのエントリの
最大鍵長が１２８ビット、最大繰り返し数が１０とす
る。この場合に、最も制約された制限は最大鍵長が６４
ビット、最大繰り返し数が１０になる。この例に示した
ように制限ごとに最も制約された制限が決定される。

【００５７】最も制約された制限が決まった後、新しい
エントリが政策Ｃに生成される（８２４）。この新しい
エントリには、２つの対応するエントリと同じアルゴリ
ズム名と免除機構名が存在する。また、この新しいエン
トリには、その制限として、工程８２０で決定された最
も制約された制限が存在する。新しいエントリが政策Ｃ
に生成されると、現在選択しているエントリの処理が終
了する。そして、政策Ａにこれ以上エントリが存在する
かどうかの判断がなされる（８２８）。エントリが存在
する場合には、処理を工程８０４に戻して、政策Ａの次
のエントリを選択し、処理する。エントリが存在しない
場合には、処理を工程８３２に進める。

【００５８】工程８０８に戻って、政策Ａで選択したエ
ントリに対応するエントリが政策Ｂに存在しないと判断
された場合、政策Ｂにワイルドカードのエントリが存在
しないかどうかの判断がなされる（８１２）。このワイ
ルドカードは、政策Ｂに明示して示されていない全ての
アルゴリズム名/免除機構の組み合わせのための容器と
して動作する。ワイルドカードが政策Ｂに見つからなか
った場合、選択されたエントリの処理が終了する。政策
Ｃには、新しいエントリが生成されず、処理は、政策Ａ
の次のエントリを検索するために工程８２８へ進む。

【００５９】一方、政策Ｂにワイルドカードのエントリ
が存在すると判断された場合、選択されたエントリの制
限とワイルトカードのエントリの制限を比較して、最も
制約された制限を決定する（８１６）。この決定は、工
程８２０について前述した説明と同じ方法で行われる。
最も制約された制限が決まった後、新しいエントリが政
策Ｃに生成される（８２４）。この新しいエントリに
は、選択したエントリと同じアルゴリズム名と免除機構
名が存在する。また、この新しいエントリには、その制
限として、工程８１６で決まった最も制約された制限が
存在する。新しいエントリが政策Ｃに生成されると、現
在選択しているエントリの処理が終了する。そして、更
にエントリが政策Ａに存在するかどうかの判断がなされ
る（８２８）。エントリが存在する場合には、処理を工
程８０４に戻して、政策Ａの次のエントリを選択し、処
理する。この処理は、政策Ａの全エントリが処理される
まで続く。

【００６０】政策Ａの全エントリが処理された後、政策
Ａのエントリに対応しない政策Ｂの全エントリを処理す
る番になる。しかし、これを行う前に、政策Ａにワイル
ドカードのエントリが存在するかどうかを判断する（８
３２）。政策Ａがワイルドカードのエントリを持ってい
ない場合、政策Ｂの追加のエントリは、それらが政策Ｃ
に作成される追加のエントリになることはないので、こ
れ以上処理される必要はない。このようにして、政策Ａ
にワイルドカードのエントリが存在しない場合、政策Ｃ
の構築が終了する（８３６）。

【００６１】一方、政策Ａにワイルドカードのエントリ
が存在する場合、政策Ｂの処理は、政策Ｂの次のエント
リ（この場合は最初のエントリ）の選択から始まる（８
４０）。選択したエントリと政策Ｃのエントリとを比較
して、対応するエントリが政策Ｃに存在するかどうかを
判断する（８４４）。本発明の一実施形態において、こ
の決定は、選択されたエントリのアルゴリズム名および
免除機構名、ならびに政策Ｃのエントリのアルゴリズム
名および免除機構名とを比較することによって行われ
る。対応するエントリが政策Ｃに見つかった場合、選択
されたエントリは、政策Ａのエントリの処理の一部とし
てすでに処理されたことを意味している。この場合に、
選択しているエントリの処理を必要としない。結果とし
て、処理が工程８５６に進んで政策Ｂの次のエントリを
検索する。

【００６２】一方、選択されたエントリが政策Ｃのいず
れのエントリにも対応していない場合、選択されたエン
トリの制限と政策Ａのワイルトカードのエントリの制限
を比較して最も制約された制限を決定する（８４８）。
この決定は、工程８２０について前述した説明と同じ方
法で行われる。最も制約された制限が決定された後、新
しいエントリが政策Ｃに生成される（８５２）。この新
しいエントリには、選択されたエントリと同じアルゴリ
ズム名と免除機構名が存在することになる。また、この
新しいエントリには、その制限として工程８４８で決定
した最も制約された制限が存在することになる。新しい
エントリが政策Ｃに生成された後に、現在選択されたエ
ントリの処理が終了する。そして、政策Ｂに更にエント
リが存在するかどうかを決定する（８５６）。エントリ
が存在する場合、処理を工程８４０に戻して政策Ｂの次
のエントリを選択し、処理する。この処理は、政策Ｂの
全エントリが処理されるまで続く。全エントリが処理さ
れると、政策Ｃの構築が終了する（８６０）。

【００６３】本発明の一実施形態において、説明された
マージ処理はJCESecurityクラス３１４のイニシャライ
ザによって実行される。JCESecurityクラス３１４が呼
び出されるとすぐに、このイニシャライザは呼び出され
る。イニシャライザが呼び出された場合、イニシャライ
ザは、イニシャライザに提供された法律の２つ以上のセ
ットをマージして、制限の全セット１０８を生成する。
生成されるのはこの制限の全セット１０８（デフォルト
設定と免除設定を備える）であり、これは、Cipherイン
スタンスに加えられる制約を決定するGetCryptoPermiss
ionメソッドによってその後に使用される。

【００６４】前述したように、JCESecurityクラス３１
４のGetImplメソッドが、関連する一般的な実装１０６
のインスタンス化を担当して、実装のインスタンスを生
成する。インスタンス化処理の一部として、GetImplメ
ソッドは認証処理を実行する。本発明の一実施形態にお
いて、この認証処理は、GetImplメソッドが、関連する
一般的な実装１０６を認証し、関連する一般的な実装１
０６がフレームワーク１０２を認証するという相互認証
の形式になる。本発明の一実施形態において、この相互
認証が生じることを可能にするには、（１）関連する一
般的な実装１０６のＪＡＲファイルがデシタル署名さ
れ、（２）フレームワーク１０２のＪＡＲファイルがデ
シタル署名され、（３）JCESecurityクラス３１４が、
関連する一般的な実装のＪＡＲファイルの署名の検証に
使用できる不明瞭な信頼公開鍵(obfuscated trusted pu
blic keys)のセットを埋め込んであり、（４）関連する
一般的な実装１０６は、フレームワークのＪＡＲファイ
ルの署名の検証に使用する信頼公開鍵のセットを埋め込
んである。

【００６５】この前提を与えられて、相互認証が次のよ
うに実行される。まず、JCESecurityクラス３１４に埋
め込まれた不明瞭な信頼公開鍵を使用して、GetImplメ
ソッドが関連する一般的な実装のＪＡＲファイルのデジ
タル署名を検証する。このデジタル署名が検証される場
合に、GetImplメソッドは、関連する一般的な実装１０
６をインスタンス化し、この関連する一般的な実装のコ
ンストラクタが呼び出されるようにする。コンストラク
タが呼び出された場合、コンストラクタは、関連する一
般的な実装１０６に埋め込まれた信頼公開鍵を使用し
て、フレームワークのＪＡＲファイルのデジタル署名を
検証する。フレームワークのＪＡＲファイルのデジタル
署名が正しいことをコンストラクタが決定する場合、コ
ンストラクタは要求された実装のインスタンスを構築す
ることになる。デジタル署名が正しくない場合、コンス
トラクタはエラーを返す。この説明に示されているよう
に、関連する一般的な実装１０６とフレームワーク１０
２の両方が正しい場合だけ、実装のインスタンスが構築
されることになる。

【００６６】この検証処理の実行で、GetImplメソッド
は外部のデジタル署名検証機構を信頼する。すなわち、
本発明の一実施形態において、GetImplメソッドは署名
の検証そのものは実行しない。逆に、GetImplメソッド
は、関連する一般的な実装１０６のデジタル署名と不明
瞭な信頼公開鍵を外部のデジタル署名検証機構に提示し
て検証を受ける。本発明の一実施形態において、外部の
デジタル署名検証機構はJava Runtimeの署名機構(Signa
ture Mechanism)になる。この署名機構は全Ｊａｖａ環
境の一部であり、フレームワーク１０２の一部ではな
い。従って、フレームワーク１０２から見ると、この署
名機構は「信頼された」コンポーネントではない。結果
として、署名機構が正しく信頼可能な結果を提供すると
信頼する前に、署名機構自体が適法である（すなわち、
正しい検証機能を実行している）ことを保証するために
検証される。

【００６７】それが署名機構を検証できるようにするた
めに、JCESecurityクラス３１４には少なくとも２つの
デジタル署名をその中に埋め込んである。１つは、不明
瞭な信頼公開鍵を使用して検証できることが分かってお
り、もう１つは不明瞭な信頼公開鍵を使用して検証でき
ないことが分かっている。これらの署名は、署名機構に
予測できない順序で提示されて、その適法性を試験す
る。署名機構を試験する処理の可能な１つの実施形態
が、図１２に示されている。

【００６８】図１２に示されているように、検証処理
は、署名機構に提示するデジタル署名（検証可能また
は、検証不可能なデジタル署名）の決定（９０４）から
始まる。この決定は、署名機構とって予測不能な方法で
行われ、本発明の一実施形態においては、ランダム処理
を使用して行われる。たとえば、ランダムな数が生成さ
れ、ランダムな数がある範囲（たとえば、０に一致）の
場合、署名の１つが選択されることになる。ランダムな
数が別の範囲（たとえば、１に一致）の場合、別の署名
が選択されることになる。本発明の一実施形態におい
て、工程９０４の決定は、以前に選択された署名を考慮
しても行われる。以前に選択された署名が全て同じ署名
の場合、工程９０４によって他の署名が選択される。こ
れは、２つの署名の各々が少なくとも１つ選択され、署
名機構の適法性を完全に試験することを保証する。

【００６９】署名の１つが選択された後、選択された署
名と不明瞭な信頼公開鍵が検証のために署名機構に提示
される（９０８）。次に、署名機構は署名が検証された
か、検証されなかったかのどちらかを示す応答を提供す
る。この応答が受け取られ（９１２）、正確性が確認さ
れる（９１６）。具体的には、署名機構に提示された署
名が検証可能であった場合、その応答が、署名が検証さ
れたことを示す指標により確認される。署名機構に提示
された署名が検証不可能であった場合、その応答が、署
名が検証されていないことを示す指標により確認され
る。提示された署名に対して受け取った応答が正しくな
い場合、署名機構が適法でないことが決まる（９２
０）。この場合に、検証処理が終了する（９２４）。

【００７０】一方、提示された署名に対して受け取った
応答が正しい場合、検証処理がｎ回実行されたかどうか
に関しての決定を行う（９２８）。ここで、ｎは任意の
望ましい数（たとえば、５）である。ｎ回実行されてい
ない場合、処理を工程９０４に戻してもう１度署名を署
名機構に提示し、応答を試験する。処理をｎ回実行した
場合、処理を工程９３２に進める。工程９３２まで処理
すると、署名機構が正しい応答をそれぞれずべての提示
された署名に対して提供したことが分かる（応答が正し
くない場合、処理が工程９３２まで至らずに、工程９２
４で終了することになる）。このようにして、署名機構
が適法であることが決まる（９３２）。この場合に、署
名機構は、関連する一般的な実装１０６を認証するGetI
mplメソッドによって信頼されてよい。署名機構が適法
であることが検証されると、検証処理が終了する（９３
６）。

【００７１】上記の処理の成果は、検証可能なデジタル
署名と検証不可能なデジタル署名が署名機構に予測不可
能な順序で提示されることである。この提示順序を予測
不可能にすることにより、検証処理は、不正な署名機構
が、正しい応答の「偽造」をすることは、仮にそれが不
可能でないとしても、極めて困難である。従って、この
検証処理は、外部の署名機構の適法性を試験する効率的
な方法を提供する。

【００７２】これまで検証処理は、デジタル署名検証機
構に関連させて説明してきた。しかし、処理はデジタル
署名検証機構に限定されないことに注意しなければなら
ない。逆に、検証処理は一般的に適用されて、任意の信
頼されていない機構の適法性を試験する。分かっている
正しい応答について少なくとも２つの異なった情報設定
が存在する限り、処理は、信頼されていない機構の適法
性を試験するために適用される。検証処理が任意の信頼
されていない機構に一般的に適用される方法を、図１３
の流れ図に示す。

【００７３】図１３に示されているように、検証処理は
少なくとも２つの情報設定のいずれかを信頼されていな
い機構に提示する決定から始まる（１００４）。この決
定の工程１００４は信頼されていない機構にとって予測
できない方法で行われ、本発明の一実施形態において
は、ランダム処理を使用して行われる。たとえば、ラン
ダムな数が生成され、ランダムな数がある範囲内（たと
えば、０に一致）の場合、最初の情報設定が選択される
ことになる。また、ランダムな数が他の範囲内（たとえ
ば、１に一致）の場合、もう一つの情報設定が選択され
ることになる。本発明の一実施形態において、決定の工
程１００４は以前に選択された情報設定も考慮する。以
前に選択された選択が全て同じ情報設定であった場合、
工程１００４により他の情報設定が選択される。これ
は、情報設定の各々が少なくとも１度選択され、信頼さ
れていない機構の適法性を完全に試験することを保証し
ている。

【００７４】情報設定の１つが選択された後、選択され
た情報設定を信頼されていない機構に提示する（１００
８）。次に、信頼されていない機構は、提示された情報
設定に対する応答を提供する。この応答を受け取って
（１０１２）、正確性の確認を行う（１０１６）。具体
的には、各情報設定の正しい応答が分かるようになる。
受け取った応答が提示された情報設定の正しい応答でな
い場合、信頼されていない機構が適法でないことが決定
される（１０２０）。この場合に、検証処理が終了する
（１０２４）。

【００７５】一方、受け取った応答が提示された情報設
定の正しい応答の場合、検証処理がｎ回実行されたかど
うかに関しての決定を行う（１０２８）。ここで、ｎは
任意の望ましい数（たとえば、５）である。ｎ回実行さ
れていない場合、処理を工程１００４に戻して、もう１
度情報設定を信頼されていない機構に提示し、応答を試
験する。処理がｎ回実行されている場合、処理は工程１
０３２に進む。工程１０３２まで処理すると、信頼され
ていない機構が正しい応答をそれぞれ全ての提示された
情報設定に対して提供したことが分かる（応答が正しく
ない場合は、処理が工程１０３２には至らずに工程１０
２４で終了することになる）。このようにして、信頼さ
れていない機構が適法であることが決定される（１０３
２）。信頼されていない機構が適法であることが検証さ
れると、検証処理が終了する（１０３６）。

【００７６】上記の処理の成果は、２つの情報設定が信
頼されていない機構に予測不可能な順序で提示されるこ
とである。この提示順序を予測不可能にすることによ
り、検証処理は、不正な信頼されていない機構が、正し
い応答の「偽造」をすることは、仮にそれが不可能でな
いとしても、極めて困難である。従って、この検証処理
は、任意の信頼されていない機構の適法性を試験するた
めの効率的な方法を提供する。

【００７７】[ハードウェアの概要]本発明の一実施形態
において、本発明は、１または複数のプロセッサが実行
可能な命令セットとして実装される。本発明は、カルフ
ォルニア州マウンテンビューのSun Microsystems, Inc.
社製のＪａｖａ（登録商標）プログラミングシステムを
含む、これに限定されないオブジェクト指向プログラミ
ングシステムの一部として実装し得る。図１４に、発明
の実施形態が実装されているコンピュータシステム１１
００のハードウェアのブロック図を示す。コンピュータ
システム１１００は、情報の通信に使用するバス１１０
２もしくは他の通信機構、ならびにバス１１０２に接続
されて情報を処理するプロセッサ１１０４を含む。コン
ピュータシステム１１００には、ランダムアクセスメモ
リ（RAM）または他の動的記憶装置などの主記憶装置１
１０６も組み込まれており、バス１１０２に接続されて
プロセッサ１１０４が実行する情報と命令を保存する。
また、主記憶装置１１０６は、プロセッサ１１０４が命
令の実行中に使用する一時的変数または他の中間情報を
保存する場合にも使用される。また、コンピュータシス
テム１１００は、バス１１０２に接続されてプロセッサ
１１０４が使用する静的な情報と命令を保存する読み出
し専用メモリ（ROM）１１０８または他の静的記憶装置
を含む。磁気ディスクまたは光ディスクなどの記憶装置
１１１０は、バス１１０２に接続されて情報と命令の保
存に使用される。

【００７８】コンピュータシステム１１００は、バス１
１０２を経由して陰極線管（ＣＲＴ）などのディスプレ
イ１１１２に接続され、コンピュータユーザーに情報を
表示する。英数字キーおよび他のキーをはじめとする入
力装置１１１４はバス１１０２に接続されて、情報とコ
マンドの選択をプロセッサ１１０４に送る。キーとは異
なるユーザー入力装置にマウス、トラックボール、また
はカーソル方向キーなどのカーソル制御１１１６があ
り、方向情報とコマンドの選択をプロセッサ１１０４に
送り、ディスプレイ１１１２のカーソルの動きを制御す
る。この入力装置は、通常第１軸（たとえば、ｘ）と第
２軸（たとえば、ｙ）の２軸の２度の自由度を持ってお
り、平面内の位置を指定できる。

【００７９】一実施形態に従って、本発明の機能は、主
記憶装置１１０６に格納された１または複数の命令の１
または複数のシーケンスを実行するプロセッサ１１０４
に応じてコンピュータシステム１１００が提供する。こ
のような命令は、記憶装置１１１０などのコンピュータ
が読み込み可能な主記憶装置以外の媒体から主記憶装置
１１０６に読み込まれる。主記憶装置１１０６に格納さ
れた命令シーケンスを元に、プロセッサ１１０４がここ
で説明された処理ステップを実行する。別の実施形態と
して、ハードワイヤード回路を、発明を実装するソフト
ウェア命令に代えて使用することもできる。また、ハー
ドワイヤード回路を、発明を実装するソフトウェア命令
と組み合わせて使用することもできる。このように、発
明の実施形態はハードウェア回路とソフトウェアの任意
の組み合わせに限定されない。

【００８０】ここで使用されている「コンピュータが読
み取り可能な媒体」という用語は、実行に使用するプロ
セッサ１１０４に命令を提供することに関係する任意の
媒体を示す。このような媒体は、不揮発性媒体、揮発性
媒体および伝送媒体に限定されないが、それらを含む多
数の形式がある。たとえば、不揮発性媒体には、記憶装
置１１１０などの光ディスクまたは磁気ディスクがあ
る。揮発性媒体には、主記憶装置１１０６などの動的記
憶装置がある。伝送媒体には、バス１１０２を構成する
配線をはじめとする同軸ケーブル、銅線、および光ファ
イバーがある。また、伝送媒体は、音波または電磁波、
たとえば電波、赤外線、および光データ通信中に生成さ
れる波などの形式にもなる。

【００８１】たとえば、コンピュータが読み取り可能な
媒体の一般的な形式には、フロッピー（登録商標）ディ
スク、フレキシブルディスク、ハードディスク、磁気テ
ープもしくはその他の磁気媒体、ＣＤ−ＲＯＭ、その他
の光媒体、パンチカード、紙テープ、その他のせん孔式
の物理的媒体、ＲＡＭ、ＰＲＯＭおよびＥＰＲＯＭ、Ｆ
ＬＡＳＨ−ＥＰＲＯＭ、その他のメモリーチップもしく
はカートリッジ、後述する搬送波、またはその他のコン
ピュータが読み込める媒体がある。

【００８２】コンピュータが読み取り可能な媒体のいろ
いろな種類には、１または複数の命令の１または複数の
シーケンスを、命令を実行するプロセッサ１１０４に運
ぶことも含まれる。たとえば、命令は最初にリモートコ
ンピュータ上の磁気ディスクに運ばれる。リモートコン
ピュータは、命令をその動的記憶装置にロードし、モデ
ムを使用して電話線上に命令を送信する。コンピュータ
システム１１００に対してローカルなモデムは電話線で
データを受信し、赤外線トランスミッタを使用してデー
タを赤外線信号に変換する。赤外線検出器は赤外線信号
のデータを受信し、適当な回路がデータをバス１１０２
上に配置する。バス１１０２は、データを主記憶装置１
１０６に運ぶ。そして、プロセッサ１１０４が命令を取
り出し実行する。主記憶装置１１０６が受け取った命令
は、プロセッサ１１０４が実行する前か後のどちらかに
随意で記憶装置１１１０に保存される。

【００８３】コンピュータシステム１１００は、また、
バス１１０２に接続された通信インターフェイス１１１
８を含む。通信インターフェイス１１１８は２方向のデ
ータ通信が可能であり、ローカルネットワーク１１２２
に接続するためのネットワークリンク１１２０とも繋が
っている。たとえば、通信インターフェイス１１１８
は、デジタル総合サービス網（ＩＳＤＮ）カードまたは
データ通信接続を対応する種類の電話線に提供するモデ
ムとすることもできる。また、その他の例として、通信
インターフェイス１１１８は、データ通信接続を互換LA
Nに提供するローカルエリアネットワーク（ＬＡＮ）カ
ードとすることもできる。無線リンクも実装できる。こ
のような実装で、通信インターフェイス１１１８は、い
ろいろな種類の情報であるデジタルデータの流れを運搬
する電気、電磁気または光信号を送受信する。

【００８４】ネットワークリンク１１２０は、通常、１
または複数のネットワークを使用して他のデータ装置に
対するデータ通信を可能とする。たとえば、ネットワー
クリンク１１２０は、ローカルネットワーク１１２２を
使用してホストコンピュータ１１２４またはインターネ
ットサービスプロバイダ（ＩＳＰ）１１２６によって運
営されているデータ装置に対して接続を提供する。次
に、ＩＳＰ１１２６は一般に「インターネット」１１２
８と呼ばれている世界的なパケットデータ通信ネットワ
ークを使用してデータ通信サービスを提供する。ローカ
ルネットワーク１１２２とインターネット１１２８は、
共にデジタルデータの流れを運搬する電気信号、電磁気
信号または光信号を使用する。いろいろなネットワーク
を使用する信号ならびにネットワークリンク１１２０上
の信号および通信インターフェイス１１１８を使用する
信号は、情報を運ぶ典型的な搬送波の形をしている。こ
れらの信号は、デジタルデータを、コンピュータシステ
ム１１００に運搬し、コンピュータシステム１１００か
ら運搬する。

【００８５】コンピュータシステム１１００は、ネット
ワーク、ネットワークリンク１１２０および通信インタ
ーフェイス１１１８を使用してメッセージを送信でき、
プログラムコードをはじめとするデータを受信できる。
インターネットでは、アプリケーションプログラムのコ
ードが要求されたとき、サーバー１１３０がそれをイン
ターネット１１２８、ＩＳＰ１１２６、ローカルネット
ワーク１１２２および通信インターフェイス１１１８を
使用して送信できる場合がある。受信したコードは、コ
ードを受け取った際にプロセッサ１１０４で実行した
り、或いは、記憶装置１１１０または他の不揮発性記憶
装置に保存して後で実行したりできる。この方法で、コ
ンピュータシステム１１００は搬送波の形式でアプリケ
ーションコードを取得できる。

【００８６】現時点で、発明は特別の実施形態に基づい
て説明されているが、それに限定されない。発明の精神
から逸脱することなく、この開示の利益を使用して当業
者により種々の変更が行える。従って、本発明は、本発
明を記述するために使用されている特定の実施形態に制
限されるものではなく、特許の請求範囲に基づいてのみ
限定される。

【００８７】

【発明の効果】以上の如く本発明によれば、要求された
実装の動的な構築により、フレームワークは、必要な制
約がアプリケーションに提供されるサービスに課される
ことを確実なものとする。

【図面の簡単な説明】

【図１】本発明の一実施形態に係るシステム全体を示す
ブロック図である。

【図２】図１のシステム全体の一般的な動作を示す流れ
図である。

【図３】本発明の一実施形態を示す詳細なブロック図で
ある。

【図４】本発明の一実施形態を示す詳細なブロック図で
ある。

【図５】図３及び図４の実施形態の動作を示す流れ図で
ある。

【図６】図３及び図４の実施形態の動作を示す流れ図で
ある。

【図７】デフォルト設定と免除設定をはじめとする制限
の組み合わせの例を表した図である。

【図８】JCESecurityManagerオブジェクトクラスのGetC
ryptoPermissionメソッドの一実施形態の動作を示す流
れ図である。

【図９】規則の複数のセットを制限の１つのセットにマ
ージする処理の概要を示す本発明の一実施形態の流れ図
である。

【図１０】規則の複数のセットを制限の一つのセットに
マージする方法を示す本発明の一実施形態の流れ図であ
る。

【図１１】規則の複数のセットを制限の一つのセットに
マージする方法を示す本発明の一実施形態の流れ図であ
る。

【図１２】信頼されていないデジタル署名検証機構の適
法性を試験する方法を示す本発明の一実施形態の流れ図
である。

【図１３】任意の信頼されていない機構の適法性を試験
する方法を示す本発明の一実施形態の流れ図である。

【図１４】本発明が実装するコンピュータシステムのハ
ードウェアブロック図である。

───────────────────────────────────────────────────── フロントページの続き (72)発明者ジャン・ルーヘアメリカ合衆国 94108 カリフォルニア州サンフランシスコストックトンストリートナンバー９ 540

Claims

【特許請求の範囲】

【請求項１】アプリケーションにより特定サービスの
実装が要求されるシステムにおける、前記実装に課す制
約を決定する方法であって、前記実装を要求する前記アプリケーションに与えられて
いる許可があるか否かを判断し、前記アプリケーションに与えられている少なくとも１つ
の許可があるとの判断に応じて、前記実装に課す制約の
セットを導くために、前記許可を処理することを備えた
方法。
【請求項２】前記許可は、前記制約のセットが最も小
さい制約度合いとなるよう処理されるものである請求項
１に記載の方法。
【請求項３】前記アプリケーションに与えられている
許可がないとの判断に応じて、初期制限のセットにアク
セスし、前記初期制限に基づいて、前記制約を導くことを更に備
えた請求項１に記載の方法。
【請求項４】前記初期制限が、複数の法政策をマージ
し、そこから最も制約的な制限を抽出することにより、
導かれるものである請求項３に記載の方法。
【請求項５】前記許可の前記処理が、前記許可が、全てを包含する許可であるか否かを判断
し、前記許可が全てを包含する許可であるとの判断に応じ
て、前記実装が制限のないものであることの指標を用意
することを備えた請求項１に記載の方法。
【請求項６】前記許可の前記処理が、前記許可が、免除機構が実装されることを必要とするか
否かを判断し、前記許可が免除機構が実装されることを必要としないと
の判断に応じて、前記許可に基づき前記制約のセットを
導くことを備えた請求項１に記載の方法。
【請求項７】前記制約を導くことが、前記許可がパラメータのセットを規定しているか否かを
判断し、前記許可がパラメータのセットを規定しているとの判断
に応じて、前記パラメータに基づき前記制約のセットを
導くことを備えた請求項６に記載の方法。
【請求項８】前記制約を導くことが、前記許可がパラメータのセットを規定しているか否かを
判断し、前記許可がパラメータのセットを規定していないとの判
断に応じて、前記実装が制限のないものであることの指
標を用意することを備えた請求項６に記載の方法。
【請求項９】前記許可の前記処理が、前記許可が、特定の免除機構が実装されることを必要と
するか否かを判断し、前記許可が特定の免除機構が実装されることを必要とす
るとの判断に応じて、免除制限のセットをアクセスし、前記制約を導くために、前記許可と前記免除制限とを調
整することを備えた請求項１に記載の方法。
【請求項１０】前記許可と前記免除制限との前記調整
が、前記免除制限が、前記実装に前記特定の免除機構が実装
されることを許可するか否かを判断し、前記免除制限が、前記実装に前記特定の免除機構が実装
されることを許可するとの判断に応じて、前記免除制限
に基づいて前記制約を導くことを備えた請求項９に記載
の方法。
【請求項１１】前記許可と前記免除制限との前記調整
が、前記免除制限が、前記実装に前記特定の免除機構が実装
されることを許可するか否かを判断し、前記免除制限が、前記実装に前記特定の免除機構が実装
されることを許可しないとの判断に応じて、初期制限の
セットにアクセスし、前記初期制限に基づいて前記制約を導くことを備えた請
求項９に記載の方法。
【請求項１２】前記免除制限が、複数の法政策をマー
ジし、そこから最も制約的な制限を抽出することによ
り、導かれるものである請求項９に記載の方法。
【請求項１３】前記アプリケーションに与えられてい
る許可があるか否かの前記判断が、前記実装を要求した
アプリケーションが何れであるかを判断するためにコー
ル・スタックを精査することを備えた請求項１に記載の
方法。
【請求項１４】前記アプリケーションに与えられてい
る許可があるか否かの前記判断が、前記アプリケーショ
ンを認証することを更に備えた請求項１３に記載の方
法。
【請求項１５】アプリケーションにより特定サービス
の実装が要求されるシステムにおける、前記実装に課す
制約を決定する装置であって、前記実装を要求する前記アプリケーションに与えられて
いる許可があるか否かを判断する機構と、前記アプリケーションに与えられている少なくとも１つ
の許可があるとの判断に応じて、前記実装に課す制約の
セットを導くために、前記許可を処理する機構と、を備
えた装置。
【請求項１６】前記許可は、前記制約のセットが最も
小さい制約度合いとなるよう処理されるものである請求
項１５に記載の装置。
【請求項１７】前記アプリケーションに与えられてい
る許可がないとの判断に応じて、初期制限のセットにア
クセスする機構と、前記初期制限に基づいて、前記制約を導くする機構と、
を更に備えた請求項１５に記載の装置。
【請求項１８】前記初期制限が、複数の法政策をマー
ジし、そこから最も制約的な制限を抽出することによ
り、導かれるものである請求項１７に記載の装置。
【請求項１９】前記許可を処理する前記機構が、前記許可が、全てを包含する許可であるか否かを判断す
る機構と、前記許可が全てを包含する許可であるとの判断に応じ
て、前記実装が制限のないものであることの指標を用意
する機構と、を備えた請求項１５に記載の装置。
【請求項２０】前記許可を処理する前記機構が、前記許可が、免除機構が実装されることを必要とするか
否かを判断する機構と、前記許可が免除機構が実装されることを必要としないと
の判断に応じて、前記許可に基づき前記制約のセットを
導く機構と、を備えた請求項１５に記載の装置。
【請求項２１】前記制約を導く前記機構が、前記許可がパラメータのセットを規定しているか否かを
判断する機構と、前記許可がパラメータのセットを規定しているとの判断
に応じて、前記パラメータに基づき前記制約のセットを
導く機構と、を備えた請求項２０に記載の装置。
【請求項２２】前記制約を導く前記機構が、前記許可がパラメータのセットを規定しているか否かを
判断する機構と、前記許可がパラメータのセットを規定していないとの判
断に応じて、前記実装が制限のないものであることの指
標を用意する機構と、を備えた請求項２０に記載の装
置。
【請求項２３】前記許可を処理する前記機構が、前記許可が、特定の免除機構が実装されることを必要と
するか否かを判断する機構と、前記許可が特定の免除機構が実装されることを必要とす
るとの判断に応じて、免除制限のセットをアクセスする
機構と、前記制約を導くために、前記許可と前記免除制限とを調
整する機構と、を備えた請求項１５に記載の装置。
【請求項２４】前記許可と前記免除制限とを調整する
前記機構が、前記免除制限が、前記実装に前記特定の免除機構が実装
されることを許可するか否かを判断する機構と、前記免除制限が、前記実装に前記特定の免除機構が実装
されることを許可するとの判断に応じて、前記免除制限
に基づいて前記制約を導く機構と、を備えた請求項２３
に記載の装置。
【請求項２５】前記許可と前記免除制限とを調整する
前記機構が、前記免除制限が、前記実装に前記特定の免除機構が実装
されることを許可するか否かを判断する機構と、前記免除制限が、前記実装に前記特定の免除機構が実装
されることを許可しないとの判断に応じて、初期制限の
セットにアクセスする機構と、前記初期制限に基づいて前記制約を導く機構と、を備え
た請求項２３に記載の装置。
【請求項２６】前記免除制限が、複数の法政策をマー
ジし、そこから最も制約的な制限を抽出することによ
り、導かれるものである請求項２３に記載の装置。
【請求項２７】前記アプリケーションに与えられてい
る許可があるか否かを判断する前記機構が、前記実装を
要求したアプリケーションが何れであるかを判断するた
めにコール・スタックを精査する機構を備えた請求項１
５に記載の装置。
【請求項２８】前記アプリケーションに与えられてい
る許可があるか否かを判断する前記機構が、前記アプリ
ケーションを認証する機構を更に備えた請求項２７に記
載の装置。
【請求項２９】命令を格納したコンピュータ読み取り
可能な媒体であって、前記命令が、１又は複数のプロセ
ッサにより実行されたときに、該１又は複数のプロセッ
サを、アプリケーションにより要求された特定サービス
の実装に課す制約を決定するように動作させるものにお
いて、前記コンピュータ読み取り可能な媒体が、前記実装を要求する前記アプリケーションに与えられて
いる許可があるか否かを判断するよう、１又は複数のプ
ロセッサを動作させる命令と、前記アプリケーションに与えられている少なくとも１つ
の許可があるとの判断に応じて、前記実装に課す制約の
セットを導くために、前記許可を処理するよう、１又は
複数のプロセッサを動作させる命令と、を備えたコンピ
ュータ読み取り可能な媒体。
【請求項３０】前記許可は、前記制約のセットが最も
小さい制約度合いとなるよう処理されるものである請求
項２９に記載のコンピュータ読み取り可能な媒体。
【請求項３１】前記アプリケーションに与えられてい
る許可がないとの判断に応じて、初期制限のセットにア
クセスするよう、１又は複数のプロセッサを動作させる
命令と、前記初期制限に基づいて、前記制約を導くするよう、１
又は複数のプロセッサを動作させる命令と、を更に備え
た請求項２９に記載のコンピュータ読み取り可能な媒
体。
【請求項３２】前記初期制限が、複数の法政策をマー
ジし、そこから最も制約的な制限を抽出することによ
り、導かれるものである請求項３１に記載のコンピュー
タ読み取り可能な媒体。
【請求項３３】前記許可を処理するよう、１又は複数
のプロセッサを動作させる前記命令が、前記許可が、全てを包含する許可であるか否かを判断す
るよう、１又は複数のプロセッサを動作させる命令と、前記許可が全てを包含する許可であるとの判断に応じ
て、前記実装が制限のないものであることの指標を用意
するよう、１又は複数のプロセッサを動作させる命令
と、を備えた請求項２９に記載のコンピュータ読み取り
可能な媒体。
【請求項３４】前記許可を処理するよう、１又は複数
のプロセッサを動作させる前記命令が、前記許可が、免除機構が実装されることを必要とするか
否かを判断するよう、１又は複数のプロセッサを動作さ
せる命令と、前記許可が免除機構が実装されることを必要としないと
の判断に応じて、前記許可に基づき前記制約のセットを
導くよう、１又は複数のプロセッサを動作させる命令
と、を備えた請求項２９に記載のコンピュータ読み取り
可能な媒体。
【請求項３５】前記制約を導くよう、１又は複数のプ
ロセッサを動作させる前記命令が、前記許可がパラメータのセットを規定しているか否かを
判断するよう、１又は複数のプロセッサを動作させる命
令と、前記許可がパラメータのセットを規定しているとの判断
に応じて、前記パラメータに基づき前記制約のセットを
導くよう、１又は複数のプロセッサを動作させる命令
と、を備えた請求項３４に記載のコンピュータ読み取り
可能な媒体。
【請求項３６】前記制約を導くよう、１又は複数のプ
ロセッサを動作させる前記命令が、前記許可がパラメータのセットを規定しているか否かを
判断するよう、１又は複数のプロセッサを動作させる命
令と、前記許可がパラメータのセットを規定していないとの判
断に応じて、前記実装が制限のないものであることの指
標を用意するよう、１又は複数のプロセッサを動作させ
る命令と、を備えた請求項３４に記載のコンピュータ読
み取り可能な媒体。
【請求項３７】前記許可を処理するよう、１又は複数
のプロセッサを動作させる前記命令が、前記許可が、特定の免除機構が実装されることを必要と
するか否かを判断するよう、１又は複数のプロセッサを
動作させる命令と、前記許可が特定の免除機構が実装されることを必要とす
るとの判断に応じて、免除制限のセットをアクセスする
よう、１又は複数のプロセッサを動作させる命令と、前記制約を導くために、前記許可と前記免除制限とを調
整するよう、１又は複数のプロセッサを動作させる命令
と、を備えた請求項２９に記載のコンピュータ読み取り
可能な媒体。
【請求項３８】前記許可と前記免除制限とを調整する
よう、１又は複数のプロセッサを動作させる前記命令
が、前記免除制限が、前記実装に前記特定の免除機構が実装
されることを許可するか否かを判断するよう、１又は複
数のプロセッサを動作させる命令と、前記免除制限が、前記実装に前記特定の免除機構が実装
されることを許可するとの判断に応じて、前記免除制限
に基づいて前記制約を導くよう、１又は複数のプロセッ
サを動作させる命令と、を備えた請求項３７に記載のコ
ンピュータ読み取り可能な媒体。
【請求項３９】前記許可と前記免除制限とを調整する
よう、１又は複数のプロセッサを動作させる前記命令
が、前記免除制限が、前記実装に前記特定の免除機構が実装
されることを許可するか否かを判断するよう、１又は複
数のプロセッサを動作させる命令と、前記免除制限が、前記実装に前記特定の免除機構が実装
されることを許可しないとの判断に応じて、初期制限の
セットにアクセスするよう、１又は複数のプロセッサを
動作させる命令と、前記初期制限に基づいて前記制約を導くよう、１又は複
数のプロセッサを動作させる命令と、を備えた請求項３
７に記載のコンピュータ読み取り可能な媒体。
【請求項４０】前記免除制限が、複数の法政策をマー
ジし、そこから最も制約的な制限を抽出することによ
り、導かれるものである請求項３７に記載のコンピュー
タ読み取り可能な媒体。
【請求項４１】前記アプリケーションに与えられてい
る許可があるか否かを判断するよう、１又は複数のプロ
セッサを動作させる前記命令が、前記実装を要求したア
プリケーションが何れであるかを判断するためにコール
・スタックを精査するよう、１又は複数のプロセッサを
動作させる命令を備えた請求項２９に記載のコンピュー
タ読み取り可能な媒体。
【請求項４２】前記アプリケーションに与えられてい
る許可があるか否かを判断するよう、１又は複数のプロ
セッサを動作させる前記命令が、前記アプリケーション
を認証するよう、１又は複数のプロセッサを動作させる
命令を更に備えた請求項４１に記載のコンピュータ読み
取り可能な媒体。