JP2008502251A - プロセスを使用するキーストアを有するコンピュータ装置及びコンピュータ装置を動作させる方法 - Google Patents

Abstract

コンピュータ装置は、キーマネージャを提供される。キーマネージャは、特定の鍵を自由に使用するためにキーマネージャにより許可される各鍵に対して所有するアプリケーションを識別することにより、暗号鍵の許可された使用と無許可の使用とを区別する機構を提供し、且つ信頼されて、鍵が署名動作において使用される時など適切であると考えられる時にユーザからの明示的な確定を要求する。アプリケーション間で鍵の共有を可能にするために、所有するアプリケーションは、信頼されて鍵を使用できる他のアプリケーションのリストを指定できるようにされてもよい。

Description

本発明は、コンピュータ装置のための暗号鍵の安全管理に関し、特に、暗号動作（通常、解読又は署名）のための鍵の使用を可能にする前に認証（通常、ＰＩＮ又はパスフレーズの入力）を要求することにより暗号化鍵の使用を制御することに関する。

本明細書において使用される用語「コンピュータ装置」は、任意の形態の電気コンピュータ装置を含むように広範囲に解釈され、データ記録装置、ハンドヘルドコンピュータ及びパーソナルコンピュータを含む任意の種類又は形態のコンピュータ、並びに、単一装置内で通信、画像の記録と再生との少なくともいずれか、及び演算機能性を組み合わせた移動電話、スマートフォン、通信機及び他の形態の無線／有線情報装置を含む任意の形態の通信装置を含む。

電気的であっても機械的であっても適切な鍵管理があらゆる形態の安全確保（セキュリティ）に不可欠である。例えば、安全な機械装置上のロックは最高水準のロックであるが、ロックに対する鍵又は鍵の組合せが安全でない場所に残されている場合、ロックの水準自体は機械装置の安全性を維持するのに重要でなくなる。

この原理がコンピュータ装置にも適用されることは周知である。また、公開鍵セキュリティシステムに対する攻撃の殆どが暗号アルゴリズムに対するものではなく鍵管理レベルに対するものである可能性が高いと一般に認識されている。このため、キーマネージャの完全性が少なくとも鍵自体の安全性と同じくらい重要であることは周知である。

キーマネージャは、暗号技術をサポートする全ての装置上に存在する。その目的は、鍵の対の一方の要素又は双方の要素の安全な生成、インポート、エクスポート、保守及び格納を容易にすることにより安全な通信を可能にすることである。更に、キーマネージャは、安全な証明書及び関連する信頼階層を、安全に格納して使用することにより、ＰＫＩ（公開鍵インフラストラクチャ）において重要な役割を果たす。

通常、キーマネージャは、一般にキーストアとして知られる安全な場所に、暗号化された形態で鍵を格納する。これは、キーストアに含まれる暗号データの完全性を保護することが意図されたパスフレーズ及び個人識別番号（ＰＩＮ）を使用して、キーストアが有する鍵にアクセスしようとするクライアントの認証に依存する。キーマネージャの既存の実装例において、認証ステップは、実際には２つの目的を実現する。認証ステップにより、キーマネージャ・ソフトウェアは、ソフトウェアの許可されたユーザが実際に存在することを判定でき（ユーザのみがＰＩＮ又はパスフレーズを知っていると想定されるため）、また、ユーザが鍵の使用を要望していることを確認する。例えば、ユーザが要求していないトランザクションに対して署名を行うために、悪意のあるソフトウェア（rogue software）がキーマネージャを呼び出そうとした場合、ユーザに自分の認証を要求するユーザインタフェースを表示し、ユーザの鍵を使用しようとするものが存在することをユーザに警告すべきである。これにより、ユーザは認証を拒否するだろう。

Microsoft Exchangeにおいてキーマネージャは以下のように動作する。非特許文献１において、この種類のキーマネージャが説明されている。同様の機能を提供するキーチェーン等のLinuxパッケージが多く存在する。Ｊａｖａ(登録商標)のKeyStoreクラスは、キーマネージャアプリケーション・プログラミング・インタフェース（ＡＰＩ）が実現されてきた従来の方法のよい例である。Ｊａｖａ(登録商標)のキーストア・クラスは、鍵及び証明書の双方を格納する。そのストアに対するアクセスを制御するＡＰＩは、メソッドsetKeyEntry及びstoreを使用してパスワードを暗号データに関連付け、getkey及びload等のメソッドを使用して暗号データを検索する時に同一のパスワードを要求する。

そのような汎用キーマネージャに対する問題は、選択プロトコル攻撃に対して無防備であることである。署名動作を行う手段は破壊され、使用しているプロトコルに応じてアイデンティティをアサートするか又は特定の１つのデータに署名する。そのような攻撃の例として、署名されたＳ／ＭＩＭＥメッセージを実際に偽造する間にＳＳＬ（Secure Socket Layer:セキュア・ソケット・レイヤ）ハンドシェイクを行なうと主張する悪意のあるアプリケーションがある。

そのような破壊が可能である理由は、ユーザはパスフレーズ又はＰＩＮを入力するように指示されるという状況から鍵がどのように使用されるかが分かるが、キーマネージャはパスフレーズ又はＰＩＮが提供される目的を知らないからである。すなわち、キーマネージャは、その情報が提供されず、全ての使用要求が全ての目的に対して同等に有効であると仮定する。鍵の使用を監視する責任は、鍵アクセスを要求するアプリケーションに割り当てられるが、これは、アプリケーションが信頼できない場合には全く理想的ではない。

これは、キーマネージャが鍵がどのように使用されるかをユーザに通知できないため、現在の設計ではそのような攻撃が防止されず且つ検出もされないことを意味する。

従って、既存の構成に不足することは、装置への十分なアクセス及びインタフェースの知識を有する者が鍵の盗難、上書き、削除又は取り消しによりキーストアの完全性を損なう能力を有することである。プラットフォーム全体に対する適切なセキュリティモデルがない状態では、悪意のあるアプリケーションが必要とする鍵にアクセスすることを防止することは不可能である。

本発明において、コンピュータ装置のためのセキュア・プラットフォームでは、ユーザを認証する必要性は、特定の目的のための鍵を使用する権原を与える必要性と切り離されるべきであると認識される。

本発明の目的のため、プロセスは、単一のディスクリートメモリ領域を占有し、固有の永続的な名前を有する、装置上で実行する１つ以上のタスクの集合である。従って、プロセスは、装置上の永続的な実行可能アイデンティティの単位としてみなされるべきである。実行のインスタンス間におけるプロセスのアイデンティティの永続性は、本発明の１つの重要な側面であると考えられる。
インターネット〈URL：http://www.msexchange.org/tutorials/Key_Management_Service_In_Exchange_2000_Server.html〉

従って、本発明の目的は、コンピュータ装置における鍵管理の改良された方法を提供することである。

本発明の第１の側面によれば、
暗号動作のためのデータを安全に使用するように構成されるコンピュータ装置であって、
ａ．前記データの各項目をキーストアに保持し、
ｂ．前記キーストアの項目の所有権を各プロセスに割り当て、
ｃ．各プロセスが別のプロセスを各項目のユーザとして割り当てることを可能にし、
ｄ．各プロセスが各項目を削除又は修正することを可能にし、
ｅ．項目を所有せず、項目のユーザとして割り当てられてもいないプロセスによる、前記キーストアの項目に対するアクセスを拒絶する、コンピュータ装置が提供される。

また、本発明の第２の側面によれば、
暗号動作のためのデータを安全に使用するようにコンピュータ装置を動作させる方法であって、
ａ．前記データの各項目をキーストアに保持する工程と、
ｂ．前記キーストアの項目の所有権を各プロセスに割り当る工程と、
ｃ．各プロセスが別のプロセスを各項目のユーザとして割り当てることを可能にする工程と、
ｄ．各プロセスが各項目を削除又は修正することを可能にする工程と、
ｅ．項目を所有せず、項目のユーザとして割り当てられてもいないプロセスによる、前記キーストアの項目に対するアクセスを拒絶する工程と、を備える方法が提供される。

また、本発明の第３の側面によれば、第１の側面によるコンピュータ装置を第２の側面の方法に従って動作させるコンピュータ装置に対するオペレーティングシステムが提供される。

添付の図面を参照し、更なる例として本発明の一実施形態を次に説明する。

本発明は、各鍵の範囲を特定のアプリケーションに限定することにより、上述の従来技術に関連する問題を克服する。これは、鍵の所有者及び鍵のユーザのプロセスを使用する方式を規定することにより達成される。プロセスは生成又はインポートした鍵を「所有」し、所有するプロセスのみがそれら鍵に対して全動作を実行することが許可される。

いくつかのアプリケーションは、複数のプロセスとして実現されてもよく、あるいは密接に接合されてもよい。従って、鍵の「所有者」は、他のアプリケーションが鍵に対して動作の固定サブセットを実行できるようにすることが可能である。これは、個々の鍵の「ユーザ」としてそれらアプリケーションを追加することにより行なわれる。ユーザアプリケーションが実行できる動作のサブセットは、要求された暗号動作に対して鍵の使用を許可するが、鍵の削除又は鍵のユーザのリストへの他のアプリケーションの追加を許可しないように構成される。

本発明は、以下を含むキーストアＡＰＩのユーザ及び所有者に対するデュアルＡＰＩ設計に基づく。
・鍵の生成、削除及び管理を行なうユーザインタフェース（ＵＩ）。
・鍵を実際に使用する「エンジン」。

このデュアルＡＰＩ設計は、鍵の所有者と鍵のユーザとの区別に対応する。

本発明を実現する方式の一実施形態を次に説明する。本実施形態は、LondonのSymbian Software Ltdにより作成された移動電話に対する高性能オペレーティングシステムであるSymbian OS（商標）オペレーティングシステムを参照して説明される。

このキーストア設計の１つの目的は、クライアント・アプリケーションに対する公開鍵の露出を最小限にすることである。従って、これは、全ての秘密鍵の動作がサーバ側で実行されるクライアント／サーバ・アーキテクチャを使用して実現される。しかし、当業者は、他のオペレーティングシステムを使用する装置において使用するためにその設計を容易に適応させられるだろう。本発明の包括的な原理の概要を更に説明する以下の内容は、そのような実現において当業者を助けることを意図する。

本発明の好適な一実施形態において、プロセス・アイデンティティが処理できるキーストアＡＰＩの範囲を判定するため、基礎となるオペレーティングシステムは、プロセスの固有のアイデンティティがチェックされることを保証する安全な方法を提供する。Symbian OS（商標）オペレーティングシステムは、セキュアファイル構成に結合され且つ各プロセスに付加された固有の識別子（ＵＩＤ）を使用して、そのような方法を提供する。この手順は、英国特許出願第０３１２１９０．２号の「保護されたファイルシステムを用いた安全な携帯無線装置（Secure Mobile Wireless Device With Protected File System）」において説明されている。しかし、本発明はその特定の方法に限定されず、任意の同等の方法が使用できる。別のオペレーティングシステムは、デジタル署名に基づく手段等のアプリケーションを識別する他の手段を有することができる。

尚、いかなるプロセス・アイデンティティ方式が使用されても、アプリケーションが装置にインストールされた時期及びアプリケーションがアンインストールされた時期の一意性のみがチェックされ、その固有の識別子は認証リストから除去されるべきである。更に、鍵を所有するアプリケーションのアンインストールは、アプリケーションが所有する全ての鍵を削除することにより達成される。これらのステップにより、「アンインストールされた」アプリケーションにより以前使用されていた鍵を不良アプリケーションが引き継ぐことを防止できる。

しかし、本発明は、プラットフォームがプロセスのアイデンティティをチェックするためのセキュア機構を提供できない場合でも実現される。そのようなプラットフォームの場合の明らかな危険は、別のプロセスのアイデンティティを仮定し且つ鍵を使用してプラットフォームを破壊しようとする悪意のあるアプリケーションの危険である。そのような状況において、プロセス・アイデンティティが偽造されることを防止するために、異なる方法が使用されてもよい。セキュアプロセス識別がないことで自動検証が不可能になるため、手動の検証方法が更に広範に使用される必要がある。鍵を使用するためにプロセスを認証する時間経過パスフレーズ処理方式が非常に適切であり、そのような１つの実装例を以下に説明する。しかし、そのような方法を頻繁に使用することは好ましくなく、セキュアプロセス識別のみに依存できるものより魅力的でないユーザ体験を提供することになる。

鍵が現在のアプリケーションにより使用可能であってもなくても、装置上の全ての鍵をその所有者と共に一覧表示することは可能であるが、装置上の利用可能な鍵を一覧表示しようとするアプリケーションは、信頼する特定のプロセスにより所有される鍵のみを一覧表示することを可能にする機能を使用すべきである。これにより、悪意のあるアプリケーションによりシステムに追加された可能性のある安全でない鍵を認識し且つ使用する危険が回避される。

本発明は、鍵による暗号技術を使用してネットワーク通信を安全にするためにＳＳＬ（セキュア・ソケット・レイヤ）等のプロトコルを使用するＪ２ＭＥ等のＪａｖａ(登録商標)実現例に対しても動作する。Ｊａｖａ(登録商標)仮想マシン（ＪＶＭ：Java Virtual Machine）は、実行しているアプリケーションのクラスを認識しており、鍵をアプリケーションにより所有される鍵に制限することができる。ウェブブラウザ内で実行するアプレットはブラウザプロセスと同一の鍵を使用できるが、ＭＩＤＩｅｔに対しては異なる鍵のセットが使用される。

本発明は、鍵をプロセスにマッピングする別の方法も可能にする。例えば、安全性は、移動電話の形態のコンピュータ装置で実行されるトランザクションにとって不可欠なものである。それら装置に対する１つの標準規格は、セッションをセキュリティ保護し且つ規定された目的のために使用される鍵を格納するハードウェアＷＩＭ（Wireless Identity Module）を使用することを指定する。特に、クライアント認証はＷＴＬＳ（Wireless Transport Layer Security：無線トランスポート層セキュリティ）プロトコルにより処理され、デジタル署名はＷＭＬＳｃｒｉｐｔ（Wireless Markup Language Script：無線マークアップ言語スクリプト）ＳｉｇｎＴｅｘｔプロトコルに準拠する。

従って、ＷＩＭを含む装置に対するオペレーティングシステムは、本発明により要求される所有者及びユーザモデルに容易に適応可能である。最も単純な方法は、各種類の鍵に対して所有者及びユーザの静的な集合を仮定することである。この方法では柔軟性がなさすぎる場合、動的なコントロールパネルが実現され、鍵の使用方法が規定できる。これを達成する２つの方法の例は以下の通りである：
・秘密鍵を使用する単一のアプリケーション毎に個別の鍵管理ＵＩを実現する。鍵管理ＵＩは、アプリケーションの全ての鍵を所有し、鍵の他のユーザとして任意の関連するプロセスを割り当てる。これは、中央のキーマネージャＵＩではないことを示す。
・全ての鍵を所有し且つアプリケーションをユーザとして適切に割り当てる中央のキーマネージャＵＩを実現する。

尚、これら２つの方法の違いは、ユーザインタフェース（ＵＩ）レベルにおいてのみである。

パスフレーズ処理は、正確なパスフレーズ又はＰＩＮを提供することにより、キーストアに対するある特定の動作を手動で許可するように装置のユーザに要求する。上述のように、この方式又は同等の方式は、プロセスの安全な識別が不可能なプラットフォームにおける全てのキーストアアクセスに対して必須となるだろう。しかし、セキュアプラットフォームにおいても、完全に自動化されたプロセスが装置自体の盗難に対してセキュリティを提供しないため、少なくとも多少の手動認証は必要である。

いくつかの動作が迅速に連続して実行される時にユーザの煩わしさを回避するために、パスフレーズがある期間キャッシュされることは周知である。本発明において、キャッシュの妥当性を管理するタイムアウトは、英国特許出願第０３２９８３５．３号の「コンピュータ装置の安全動作のための方法（A Method for Secure Operation of a Computing Device）」において説明されているように、プロセス毎に（すなわち、所有者毎に）設定されるのが好ましい。

本発明によるパスフレーズ処理は、認証オブジェクトＡＰＩを使用する。簡単に説明すると、暗号トークン・オブジェクトは、そのトークンにおいて認証オブジェクトを一覧表示するＡＰＩを提供し、各認証オブジェクトは、パスフレーズを変更し且つパスフレーズ・キャッシュ・タイムアウトを設定するメソッドを提供する。安全性上の理由から、パスフレーズは、クライアント・アプリケーションに見えない。しかし、パスフレーズ変更ＡＰＩは、新しいパスワードを入力して確定するようにユーザに要求するダイアログをトリガし、そのプロセス全体はクライアントに見えない。これには２つの利点がある。パスフレーズがＡＰＩ上に現れないため、鍵のユーザは信頼されて鍵パスフレーズを有する必要はなく、バイオメトリクス（生体認証）を使用する等、他の認証オブジェクトを使用してキーマネージャを実現したいユーザは既存のＡＰＩ内で実現できる。

キーストアに対して、パスフレーズが１つのみ存在するため、認証オブジェクトは１つのみ存在する。「パスフレーズ変更」メソッドは、ストア全体に対してパスフレーズを変更させる。しかし、「タイムアウト設定」メソッドは、呼出しプロセスにより所有される鍵に対してタイムアウトを設定するのみであり、他の鍵の所有者により設定されるタイムアウトに影響を与えない。

パスフレーズは、キーマネージャによりキャッシュされ（キャッシングはプロセス毎であるため）、鍵の所有者であるプロセスの識別は、各パスフレーズと共に格納される（キャッシングは所有者毎であるため）。鍵の有効なユーザに対する動作を実行する時、キーマネージャは、まず所有するプロセスのアイデンティティを判定し、キャッシュされた所有者に対してパスフレーズを有するかをチェックする。パスフレーズを有さない場合、ユーザはパスフレーズの入力を指示される。

キャッシュされたパスフレーズは、タイマを使用して無効にされる。パスフレーズがキャッシュされた時にタイマは開始され、タイマが終了した時にキャッシュされたパスフレーズは除去される。パスフレーズがキャッシュされないこと、又は、キャッシュされたパスフレーズがタイムアウトしないことを指定することも可能である。

本発明による安全なキーストアの設計は、以下のように実現されてもよい。この例において、Symbian OS（商標）オペレーティングシステムは、上記キーストア技術のサンプル例として使用される。当業者は、Symbian OS（商標）オペレーティングシステムのプログラミング用語をよく知っており、本明細書において開示される技術を他のオペレーティングシステム環境に容易に適応させられると仮定する。

本発明のこの例において、複数のストリームを格納する容易で効率的な方法であるという理由のため、各鍵は個別のストリームとして格納され、全ての鍵は永続的なストリームストアに格納される。永続的なストアのコミット／リバート機能は、そのストアが常に一貫していることを保証するために使用される。

暗号化は、セキュア・ストリーム・クラスを介して実現される。それらクラスは、パスフレーズから鍵を取得するための標準規格であるＰＫＣＳ＃５鍵生成アルゴリズムを使用する。辞書を使用する攻撃から保護するために、この標準規格は、基本的なアルゴリズムを多く繰り返して使用し（１０００回を推奨）、相対的にゆっくりと各鍵を取得するプロセスを作成する。この時間は、１つの鍵を取得する時には許容されるが、鍵の全体の辞書を取得しようとする時には許容されないと考えられる。例えば、辞書中の各単語に対応する解読鍵を生成するために分散的な努力を組織化することにより、取得された再利用可能な辞書を構築することを防止するために、鍵はソルト（暗号化されたオブジェクトと共に平文で格納されるランダムな文字列）とマージされてもよい。

暗号化は、ＡＥＳアルゴリズムを使用して実行される。パスフレーズではなく復号鍵がキャッシュされるように、同一のパスフレーズを使用して暗号化された全ての鍵はソルトを共有する。これはセキュリティ上より安全であり且つ効率化により繰り返し数を多くすることができるが、これは主に効率化のために行なわれる。パスフレーズが変更された時、ソルトは変更される。

ストアのルートストリームは、全ての鍵の指標を含む。これは、ストアのグローバルデータと各鍵に関する情報を含むストリームのＩＤのリストとを含む。それらストリームは、各鍵に対応する暗号化されたＰＫＣＳ＃８オブジェクトを含む別のストリームに対するポインタを含む。これを図１に示す。

キーストアＡＰＩは、キーストアを含むトークンに対してインタフェースを供給する。これを図２に示す。

MCTKeyStoreインタフェースは、キーストアに対する「ユーザ」の動作をサポートする。すなわち、鍵の一覧表示、公開鍵のエクスポート及び署名／解読／同意動作に対する鍵の公開をサポートする。

CCTKeyInfoオブジェクトは、鍵を記述するために使用され、機能仕様において説明される全ての属性を含む。

鍵に対する暗号動作は、要求された動作に対して鍵を「公開」することにより実行される。これにより、動作を実行するのに使用されるオブジェクトが生成される。MRSASigner及びMDSASignerインタフェースを実現するオブジェクトは、ＲＳＡ及びＤＳＡ署名に対して生成される。解読に対して単一のインタフェースMCTDecryptorが存在し、Diffie-Hellman鍵共有に対して１つのインタフェースＭＣＴＤＨが存在する。

MCTKeyStoreManagerインタフェースは、MCTKeyStoreインタフェースを拡張し、鍵に対する「所有者」の動作をサポートする。すなわち、鍵の生成、インポート及びエクスポート、鍵の削除、鍵のユーザの設定、パスフレーズタイムアウトの設定、並びにストアの再ロックをサポートする。しかし、この例において、キーストアＡＰＩは暗号化及び検証動作をサポートしない。それら動作に対しては、クライアント・アプリケーションは、適切な公開鍵を検索し、動作自体を実行する必要がある。

ソフトウェア・キーストアは、クライアント／サーバ・アーキテクチャを使用して実現される。クライアントは、適切な暗号トークン・インタフェースを実現し、要求をサーバに転送する。秘密鍵の露出を減少するために、全ての暗号動作はサーバ内で実行される。

ソフトウェア・キーストアは、ファイル・トークン要素の一部である。これは、暗号トークンのソフトウェア（すなわち、ファイルを使用する）実現例に対して共通のフレームワークを提供する。また、これは、証明書アプリケーションストアに含まれる。

キーストア・クライアントは、暗号トークン・フレームワークを使用し、直接又はＥＣＯＭプラグインを介してインスタンス化されてもよい。クライアントは、ソフトウェア・キーストアである単一のトークンを含む暗号トークンの種類を実現する。直接インスタンス化することを除いて、クライアントとの全ての対話は暗号トークン及びキーストアＡＰＩを介する。

ソフトウェア・キーストアは、１つのトークンの種類（ソフトウェア・キーストア）を有し、それは、１つのトークン、すなわちソフトウェア・キーストア自体をサポートする。図３は、主な暗号トークン・フレームワークＡＰＩのキーストアの実現例を示す。

CCTTokenTypeクラスは、複数のトークンの種類に対するベースクラスであり、暗号トークンモジュールの一部である。

CFSTokenTypeClientは、トークンの種類に対する１つの実現例を提供する汎用ファイル・トークン・クラスである。そのコンストラクタは、所望のトークンの種類のＵＩＤをパラメータとして取得する。この場合、ＵＩＤは、ソフトウェア・キーストア・トークンの種類のＵＩＤである。これにより、ファイル・トークン・サーバと通信するためのRFileStoreClientSessionオブジェクトが生成される。MCTTokenTypeインタフェースにより規定されるように、そのオブジェクトは、利用可能なトークンを一覧表示するメソッド及び利用可能なトークンを公開するメソッドを有する。ここで、利用可能なトークンは、ソフトウェア・キーストア・トークンの１つのみ存在する。

CFSTokenClientは、トークンを表す別の汎用ファイル・トークン・クラスである。コンストラクタ・パラメータは、そのクラスが表すストアを示す。それは、CFSTokenTypeClientのOpenTokenメソッドにより生成される。また、CFSTokenClientは、トークンの種類及びサーバと通信するのに使用されるセッション・オブジェクトに対する参照を有する。CFSTokenClientは、インタフェースを公開するメソッドを有するMCTTokenインタフェースをサポートする。

キーストア・トークンは、MCTKeyStore及びMCTKeyStoreManagerにより表される２つのインタフェース、「ユーザ」インタフェース及び「所有者」インタフェースをサポートする。それらは、キーストア自体を表すCFSKeyStoreClientクラスにより実現される。CFSKeyStoreClientクラスは、適切なインタフェースによるGetInterface呼出しに応答してCFSTokenClientにより生成され、それは、セッション・オブジェクトに対する参照を有する。クライアントが「ユーザ」インタフェースを要求するか又は「所有者」インタフェースを要求するかに関わらず同一のオブジェクトが生成される。これは、クライアントがユーザインタフェースを要求し、所有者インタフェースを取得するためにポインタをキャスト（cast）できることを意味する。しかし、許可が動作毎にサーバにおいてチェックされるため、セキュリティ上の危険はない。その他のキーストアＡＰＩの実現例を図４に示す。

使用する鍵を公開することにより、適切なオブジェクトが生成される。すなわち、MRSASigner、MDSASigner、MCTDecryptor又はMCTDHのいずれか１つが生成される。これらは全て、動作を実行するためにキーストア・クライアント・オブジェクトに対する参照を保持するベースクラスCOpenedKeyから派生する。これらは、ＡＰＩにおいて規定される適切なインタフェースを実現する。

キーストア・サーバの構成を図５に示す。

サーバが開始されると、CTokenServerのインスタンスが生成される。これは、メインサーバクラスであり、クライアントがサーバに接続する時にサーバ側のセッション・オブジェクトを生成する役割を果たす。これは、キーストアに特有のことではなく、汎用ファイル・トークン・サーバの一部である。

CTokenServerインスタンスは、キーストア・サーバ自体を表すCFSKeyStoreServerクラスの単一のインスタンスを生成する。これにより、鍵のリストをストアに書き込み且つメモリに維持する役割を果たすCFileKeyDataManagerオブジェクトが生成される。

キーストア・クライアントがサーバに接続する時、クライアント・セッションを表すためにCKeyStoreSessionのインスタンスが生成される。このインスタンスは、セッション別情報を保持するために使用され、パスフレーズ・キャッシングを実現する。また、このインスタンスは、クライアントから要求を受信し、引数をアンマーシャリングし、それらをCFSKeyStoreServerインスタンスに転送する。その後、戻りデータをマーシャリングし、クライアントに再び送信する。

本発明は、周知のキーマネージャ・システムを介していくつかの利点を提供すると考えられる：
・鍵の使用による鍵所有の機能分離により、セキュリティ上より安全な動作環境が可能になる。
・上記機能分離により、信頼されて暗号鍵を有することができるアプリケーションは、その信頼をユーザアプリケーションに選択的に拡張できるようになる。
・上記機能分離により、許可なく暗号情報にアクセスする信頼されないプログラムを防止する。
・上記機能分離により、浸透したキーストア・セキュリティを有する装置上の悪意のあるプロセスが暗号情報を乱用することを防止する。
・上記機能分離により、他のプロセスになりすますプロセスからの「フィッシング（Phishing）」の脅威が成功する確率を減少する。
・上記機能分離により、未使用の鍵を安全に除去することを保証する。
・上記機能分離により、暗号技術を伴うセキュアアプリケーションに対して、より理解し易くより好ましいユーザインタフェースの実現を可能にする。

本質的には、本発明によるキーマネージャは、特定の鍵を自由に使用するためにキーマネージャにより許可される各鍵に対して所有するアプリケーションを識別することにより、鍵の許可された使用と無許可の使用とを区別する機構を提供する。また、本発明によるキーマネージャは信頼されて、鍵が署名動作において使用される時など適切であると考えられる時にユーザからの明示的な確定を要求する。アプリケーション間で鍵の共有を可能にするために、所有するアプリケーションは、信頼されて鍵を使用できる他のアプリケーションのリストを指定できるようにされてもよい。

本発明は、特定の実施形態を参照して説明されたが、添付の請求の範囲により規定されるように、本発明の範囲から逸脱せずに変更が行なわれてもよいことが理解されるだろう。

キーストアにおけるルートストリームの一例を示す図である。 キーストアＡＰＩの一例を示す図である。 暗号トークンフレームワークＡＰＩのキーストアの実現例を示す図である。 キーストアＡＰＩの実現例を示す図である。 キーストア・サーバの構成の一例を示す図である。

Claims (23)

1. 暗号動作のためのデータを安全に使用するように構成されるコンピュータ装置であって、
   ａ．前記データの各項目をキーストアに保持し、
   ｂ．前記キーストアの項目の所有権を各プロセスに割り当て、
   ｃ．各プロセスが別のプロセスを各項目のユーザとして割り当てることを可能にし、
   ｄ．各プロセスが各項目を削除又は修正することを可能にし、
   ｅ．項目を所有せず、項目のユーザとして割り当てられてもいないプロセスによる、前記キーストアの項目に対するアクセスを拒絶する、コンピュータ装置。
2. 前記キーストアの項目に対するアクセスは、単一のキーストア・プロセスにより制御される、請求項１記載の装置。
3. 前記キーストア・プロセスはサーバを備える、請求項１又は２記載の装置。
4. 前記キーストア・サーバは、別の装置に保持される暗号データに対するアクセスを制御するように構成される、請求項３記載の装置。
5. 前記キーストアに保持される前記項目には、暗号鍵と、セキュリティ証明書との少なくともいずれかを含まれる、請求項１から４のいずれか１項に記載の装置。
6. 前記キーストアの項目に対するアクセスは、前記装置のユーザからのアイデンティティの認証に対する要件により更に制限される、請求項１から５のいずれか１項に記載の装置。
7. ユーザ認証は、
   ａ．パスフレーズ又はＰＩＮの手入力と、
   ｂ．生体データの検証と、
   の少なくともいずれかの手段により行なわれる、請求項６記載の装置。
8. ユーザ認証は、制限された時間の間に有効である、請求項６又は７記載の装置。
9. ユーザ識別が有効である前記時間は、異なるプロセス間で変化する、請求項８記載の装置。
10. 個別のキーストア・プロセス、又は、中央のキーストア・プロセスにより制御されるアクセスを各々が有してもよい複数のキーストアを備える、請求項１から９のいずれか１項に記載の装置。
11. 前記装置からのプロセスの削除又は除去は、当該プロセスにより所有される全ての項目の削除又は除去が伴われる、請求項１から１０のいずれか１項に記載の装置。
12. 暗号動作のためのデータを安全に使用するようにコンピュータ装置を動作させる方法であって、
    ａ．前記データの各項目をキーストアに保持する工程と、
    ｂ．前記キーストアの項目の所有権を各プロセスに割り当る工程と、
    ｃ．各プロセスが別のプロセスを各項目のユーザとして割り当てることを可能にする工程と、
    ｄ．各プロセスが各項目を削除又は修正することを可能にする工程と、
    ｅ．項目を所有せず、項目のユーザとして割り当てられてもいないプロセスによる、前記キーストアの項目に対するアクセスを拒絶する工程と、を備える方法。
13. 前記キーストアの項目に対するアクセスは、単一のキーストア・プロセスにより制御される、請求項１２記載の方法。
14. 前記キーストア・プロセスはサーバを備える、請求項１２又は１３記載の方法。
15. 前記キーストア・サーバは、別の装置に保持される暗号データに対するアクセスを制御するように構成される、請求項１４記載の方法。
16. 前記キーストアに保持される前記項目には、暗号鍵と、セキュリティ証明書との少なくともいずれかを含まれる、請求項１２から１５のいずれか１項に記載の方法。
17. 前記キーストアの項目に対するアクセスは、前記装置のユーザからのアイデンティティの認証に対する要件により更に制限される、請求項１２から１６のいずれか１項に記載の方法。
18. ユーザ認証は、
    ａ．パスフレーズ又はＰＩＮの手入力と、
    ｂ．生体データの検証と、
    の少なくともいずれかの手段により行なわれる、請求項１７記載の方法。
19. ユーザ認証は、制限された時間の間に有効であるように構成される、請求項１７又は１８記載の方法。
20. ユーザ識別が有効である前記時間は、異なるプロセス間で変化する、請求項１９記載の方法。
21. 個別のキーストア・プロセス、又は、中央のキーストア・プロセスにより制御されるアクセスを各々が有する複数のキーストアを用いる工程を備える、請求項１２から２０のいずれか１項に記載の方法。
22. 前記装置からのプロセスの削除又は除去は、当該プロセスにより所有される全ての項目の削除又は除去が伴われる、請求項１２から２１のいずれか１項に記載の方法。
23. 請求項１から１１のいずれか１項に記載のコンピュータ装置を、請求項１２から２２のいずれか１項に記載の方法に従って動作させる、コンピュータ装置のためのオペレーティングシステム。

Images