JP4222834B2

JP4222834B2 - 格納された鍵の入手および安全な配信により鍵サーバが認証される暗号鍵を格納する方法および装置

Info

Publication number: JP4222834B2
Application number: JP2002571620A
Authority: JP
Inventors: ロバートアレン，; ロバートエイ．ジャードネック，; ジョンワン，; トムウー，
Original assignee: アルコットシステムズインコーポレイテッド
Priority date: 2001-03-09
Filing date: 2002-03-11
Publication date: 2009-02-12
Anticipated expiration: 2022-03-11
Also published as: EP1374474B1; WO2002073861A2; HK1058270A1; DE60228554D1; WO2002073861A3; US7711122B2; US8290165B2; US20020126850A1; JP2005509305A; AU2002252288A1; EP1374474A4; EP1374474A2; US8904180B2; WO2002073861A9; ATE406726T1; US20100172504A1; US20130046985A1

Description

（関連出願のクロスリファレンス）
本出願は、「ＭＥＴＨＯＤＡＮＤＡＰＰＡＲＡＴＵＳＦＯＲＣＲＹＰＴＯＧＲＡＰＨＩＣＫＥＹＳＴＯＲＡＧＥＵＳＩＮＧＡＶＥＲＩＦＩＥＲＡＮＤＡＣＣＯＭＭＯＤＡＴＩＮＧＫＥＹＵＳＥＲＳＴＨＡＴＯＰＥＲＡＴＥＩＮＤＥＰＥＮＤＥＮＴＬＹＯＦＴＨＥＶＥＲＩＦＩＥＲ」（２００１年３月９日出願）と称される米国仮出願第６０／２７４，４５７号の非仮出願からの優先権を主張し、かつ非仮出願であり、この出願は、参考のため、本明細書中にその全体が援用される。

（発明の分野）
本発明は、概して、暗号システムに関し、より具体的には、鍵によりセキュリティ保護されたデータから離れた鍵ストレージに関する。

（発明の背景）
暗号は、データをセキュリティ保護するために用いられる。複数のシステムにおいて、鍵の知識は、データへのアクセスを可能にし、鍵の知識の欠如は、アクセスに対してデータがセキュリティ保護される。好適には、データをセキュリティ保護するために用いられる鍵は、十分に大きい可能なセットから選択されるので、攻撃者は、大量の計算資源を用いてすら、徹底的な試行錯誤によって鍵を推測することができない。通常、大きいセットから選択される鍵は、人々が記憶するには過度に長く、従って、ユーザの代理として鍵を格納し、かつ鍵が用いられ得る前にパスフレーズを入力することを要求するシステムを採用することが必要である。パスワードまたはＰＩＮ（ＰｅｒｓｏｎａｌＩｄｅｎｔｉｆｉｃａｔｉｏｎＮｕｍｂｅｒ）が記憶され得るパスフレーズは、通常、暗号鍵に直接変換され、かつユーザの格納された鍵を暗号化および復号化するために用いられる。残念ながら、ＰＩＮまたはパスワードは、ユーザが記憶するのに十分な短さである場合、攻撃者が試行錯誤によって推測するのに十分な短さでもあり、これにより、格納された鍵のセキュリティを蝕み、従って、暗号化されたデータのセキュリティを蝕む。

上述の問題に対する１つの解決策は、中央鍵管理を用いることであり、鍵は、それ自体が攻撃者によるアクセスからセキュリティ保護される中央サーバに格納される。セキュリティ保護されたデータをその中に有するシステムにアクセスする攻撃者が、ブルートフォース攻撃を用いて、および各々の考えられる短いパスフレーズを試す場合、中央サーバは、パスフレーズが試される度にシステムから照会を受け取る。一旦中央サーバが異常な数の試みに気付くと、それが中央サーバの設計の一部である場合、中央サーバは、そのシステムからのすべてのさらなる照会を無視し、および／または不正使用管理者（ｆｒａｕｄｍａｎａｇｅｒ）に警告を送るように選択され得る。

データをセキュリティ保護するための中央鍵サーバの使用は公知である。典型的な構成において、鍵によってセキュリティ保護されるデータを保持するシステム（「鍵クライアント」）は、鍵サーバに対してそれ自体を認証し、かつ鍵サーバは、鍵クライアントに対してそれ自体を認証する。相互の認証に続いて、クライアントサーバセッションが確立され、ここで、クライアントは、鍵サーバから鍵をリクエストする。このような構成において、システム全体のセキュリティは、クライアントとサーバとの間の、この初期認証のセキュリティに依存する。

（発明の要旨）
本発明の局面による、鍵管理システムの１実施形態において、セキュリティ保護されたデータは、鍵サーバ上に安全に格納された制御鍵によってセキュリティ保護される第１のシステムに格納される。セキュリティ保護されたデータは、不正使用、改変またはアクセスといった攻撃に対してセキュリティ保護され、ここで、セキュリティ保護されたデータへのアクセスに対する認証は、アクセス鍵ペアのアクセス秘密鍵の知識によって決定される。セキュリティ保護されたデータをセキュリティ保護する例は、制御鍵を用いてデータを暗号化することである。認証されたユーザが、セキュリティ保護されたデータにアクセスするべき場合、第１のシステムは、鍵サーバに対してリクエストを生成し、リクエストは、アクセス秘密鍵を用いて署名され、ここで、このリクエストは、復号制御鍵を求めるものであり、リクエストは、リクエストのための第１のシステムによって生成された鍵ペアのワンタイム公開鍵を含む。復号制御鍵が対称鍵の場合、暗号化制御鍵と同じである。鍵サーバは、アクセス鍵ペアのアクセス公開鍵を用いて署名を検証する。署名が有効である場合、鍵サーバは、復号制御鍵を第１のシステムに送信し、ワンタイム秘密鍵を用いて暗号化される。第１のシステムは、その後、ワンタイム秘密鍵を用いて、応答による復号制御鍵を復号化し得る。第１のシステムは、その後、搬送中、セキュリティ保護された状態である復号制御鍵を用いて、セキュリティ保護されたデータを復号化し得る。

本発明の他の特徴および利点は、以下の詳細な説明および好適な実施形態に鑑みて明らかである。

（発明の詳細な説明）
図に示されたシステムは、最初に、「鍵バッグ（ｋｅｙｂａｇ）」内のアプリケーション鍵をセキュリティ保護して、鍵バッグ内のアプリケーション鍵が、リモート鍵サーバに対してリクエストを行うことなしにはアクセスされ得ないという特定の用途を参照して記載される。本発明において用いられるように、「リモート」は、セキュリティの境界線によって分離され、ローカルシステムへのアクセスが、リモートシステムへのアクセスを自動的に授与しないことである。リモートは、物理的分離を必要としないが、物理的分離は、リモート性（ｒｅｍｏｔｅｎｅｓｓ）を提供する１つの方法であることが理解されるべきである。この定義を想定すれば、システムは、ローカルシステムが攻撃者にとってアクセス可能である一方で、リモートシステムはアクセス可能でないように構成され得ることが明らかである。

図１は、本発明が用いられ得る例示の構成１０のブロック図である。ここに示されるように、いくつかの鍵クライアント１２および鍵サーバ１４は、ネットワーク１６を介して結合される。特定のインプリメンテーションにおいて、鍵サーバ１４は、Ａｒｃｏｔ’ｓＷｅｂＦｏｒｔＫｅｙＡｕｔｈｏｒｉｔｙサーバであり得、かつ鍵クライアント１２は、ユーザの代わりにセキュリティ操作を実行する能力を有するエンドユーザブラウジングシステムであり得る。

構成１０の１つの目的は、鍵クライアントが鍵サーバから鍵を比較的容易に取得することを可能にする一方で、セキュリティの突破を困難にすることである。１つの考えられるセキュリティの突破は、侵入する（ｉｎｔｅｒｌｏｐｉｎｇ）鍵クライアント２２が、別の鍵クライアントに属する鍵を鍵サーバから取り出すことができる場合に起こり得る。別の考えられるセキュリティの突破は、侵入する鍵サーバ２４が認証された鍵サーバの代役を務める場合に生じ得る。侵入する鍵クライアント２２が、別の鍵クライアントの鍵を取得することが出来た場合、その侵入する鍵クライアント２２は、暗号化された署名鍵の盗まれたセットを復号し、その後、これらの署名鍵を用いてメッセージに署名すること等によって、別の鍵クライアントの振りをし得る。侵入する鍵サーバ２４は、別の鍵サーバの振りをすることが出来た場合、その侵入する鍵サーバは、鍵クライアントに欠陥のある鍵を提供し、かつそのアクションによって生成された弱点を攻略し得るか、または、認証された鍵サーバが動作するように制御および制約することなく、弱められた鍵クライアントのセキュリティに対する別の攻撃と呼応して作用し得る。

図２は、１つの鍵サーバ１４および１つの鍵クライアント１２をかなり詳細に示すブロック図である。ここに示されるように、鍵サーバ１４は、通信ハンドラ３０、サービスハンドラ３２、不正使用モニタ３４および鍵データベース３６を含む。鍵サーバの他の構成
が代わりに用いられ得ることが理解されるべきである。示される実施例において、通信ハンドラ３０は、鍵クライアント１２に結合され、かつ通信を処理する。通信ハンドラ３０は、ＨＴＴＰサーバ、ＦＴＰサーバ、低次ＴＣＰ／ＩＰパケットハンドラ、または、当該分野にて公知である他のオブジェクトであり得る。鍵サーバ１４と鍵クライアント１２との間の直接接続が示されるが、おそらくセキュリティ保護されていないネットワークが２つの間に挿入されて、認証されないサーバおよびクライアントによる侵入が可能になり得、従って、クライアントサーバ接続の最初に信頼の欠如があることが理解されるべきである。

示されるように、通信ハンドラ３０は、サービスハンドラ３２と結合される。このサービスハンドラは、その後、不正使用モニタ３４および鍵データベース３６と結合される。さらに示されるのは、鍵を無能力にする目的で、不正手段モニタ３４とサービスハンドラ３２との間が接続される。特定の接続が示される一方で、より多くの接続またはより少ない接続が本発明の範囲から逸脱することなく用いられ得ることが理解されるべきである。

通常の動作中に、通信ハンドラ３０は、鍵クライアントから鍵リクエストを受け取り、そのリクエストを、サービスハンドラ３２に転送する。サービスハンドラ３２は、その後、鍵データベース３６からその鍵クライアントの鍵を取得することによって鍵リクエストに応答するか否かを決定し、そのリクエストに応答してその鍵を提供する。あるいは、サービスプロバイダ３２は、リクエストに応答しないことを決定し得、かつそれを不正使用モニタ３４に通知し得る。特定の鍵クライアントからのリクエストの数の特定の所定の閾値が生成されて、その閾値がブルートフォース攻撃を示す場合、このようなアクションが行われ得る。サービスハンドラ３２および鍵データベース３６の特定の動作のさらなる詳細が以下の図に示され、および／または以下に記載される。

鍵クライアント１２に関して、通信ハンドラ４０、セキュリティハンドラ４２、復号器４４および鍵バッグ４６を含むことが示される。通信ハンドラ４０は、鍵クライアント１２から鍵サーバへの通信を処理する。セキュリティハンドラ４２は、種々のデータエレメントを含むことがさらに示されるが、図示されないさらなるデータエレメントもまた含まれ得ることが理解されるべきである。セキュリティハンドラ４２は、証明書５０、アクセス公開鍵５２およびアクセス秘密鍵５４を保持する。アクセス公開鍵５２は、暗号化され得、かつ証明書５０の内部に格納され得る。証明書５０は、証明書の認証によって取得され、かつアクセス鍵ペアと関連付けられる証明書であり得、従って、証明書が有効である場合、アクセス鍵ペアが証明されることが証明書の認証機関を信用するエンティティに保証され得る。

種々のモジュール間を通過するデータおよび制御のための鍵クライアント１２に関する種々の接続が、図２に示される。より多くの接続またはより少ない接続が存在し得ることが理解されるべきである。通信ハンドラ４０とセキュリティハンドラ４２との間の、示される接続の１つのペアにおいて、通信ハンドラ４０は、ワンタイム鍵ペアを生成し、かつワンタイム公開鍵をセキュリティハンドラ４２に送信する。セキュリティハンドラ４２から通信ハンドラ４０に署名されたリクエストを搬送するための、セキュリティハンドラ４２と通信ハンドラ４０との間の別のデータ通信経路が示される。以下においてより詳細に説明されるように、署名されたリクエストは、通信ハンドラ４０に鍵Ｋが提供される鍵サーバに提供される。通信ハンドラ４０と復号器４４との間に存在する通信経路は、復号器４４に鍵Ｋを提供する。復号器４４は、鍵バッグ４６と結合されることが示され、従って、復号器４４は、暗号データを取得し得、鍵Ｋを用いて暗号化され、データム（ｄａｔｕｍ）Ｄを復号化して鍵クライアント１２によって用いられるように利用可能であるデータムＤを生成する。

データムＤは、種々のタイプのデータエレメントのいずれかであり得る。１実施例において、データムＤは、ブラウザまたはＰＫＩアプリケーションによって用いられる署名鍵である。鍵バッグ４６は、暗号データエレメントの大きい、および、おそらく異なった収集の貯蔵所として利用され得ることが考えられる。本明細書中の別の箇所にて、データムＤは、「アクセス制御されたデータム（ａｃｃｅｓｓ−ｃｏｎｔｒｏｌｌｅｄｄａｔｕｍ）」になるように生成される。

特定の実施形態において、アクセス制御されたデータは、従来のブラウザ（例えば、ＮｅｔｓｃａｐｅＣｏｍｍｕｎｉｃａｔｏｒｂｒｏｗｓｅｒ、ＭｉｃｒｏｓｏｆｔＩｎｔｅｒｎｅｔＥｘｐｌｏｒｅｒｂｒｏｗｓｅｒ）またはカスタム公開鍵インフラストラクチャ（ＰＫＩ）アプリケーションといった、「鍵システム」（無意識システム）において用いられ得る従来の秘密鍵である。アクセス制御データムは、ＴｒｉｐｌｅＤＥＳ（３ＤＥＳ）またはＡＥＳといった、制御鍵および標準的対称暗号アルゴリズムを用いて暗号化され得る。

制御鍵が、データムを正確に復号する場合、鍵クライアントは、鍵サーバを正当化するように指示することが保証される。なぜなら、正当な鍵サーバのみが正確なコントロール鍵を伝送し得るからである。正確なデータが復号化されたことを認識する周知の技術がある。例えば、認識できるプレーンテキストが、アクセス制御データムの１部分として含まれ得、正確に復号化されたデータが認識され得ることを確実にし、または鍵付きメッセージ認証コード（ＭＡＣ）がデータムとともに含まれ得る。

図３は、鍵クライアントが鍵サーバから制御鍵を取得するためのプロセスを図示するフローチャートである。とりわけ、すべての必要とされる認証は、一周のメッセージング工程で実行され得、制御鍵は、鍵クライアントによってその一周のメッセージ工程で取得され得る。ここで、図を参照して、鍵クライアント上でアクセス制御データムにアクセスするプロセスが、鍵クライアントがワンタイム鍵ペアＯＴを生成することで開始し得る。鍵クライアントは、その後、リクエストタイプＩＤ、およびワンタイム鍵ペアＯＴの公開鍵部分（ＯＴ_ｐｕｂ）といったデータフィールドを含むリクエストメッセージを含む。鍵クライアントは、その後、鍵クライアントのアクセス秘密鍵を用いて、リクエストデータフィールドに署名する。

アクセス秘密鍵は、暗号偽装を用いて保護され得る。暗号偽装の例は、Ｋａｕｓｉｋによる米国特許第６，１７０，０５８号により詳細に記載される（この開示は、参考のため、本明細書中に援用される。本明細書中では以降「Ｋａｕｓｉｋ」）。アクセス秘密鍵は、その代わりに、スマートカード等のハードウェアデバイスに格納され得る。Ｋａｕｓｉｋ偽装プロセスは、フォーマットおよびデータムのセマンティクスを詳細に知ることを必要とし得るので、本明細書中に記載されたシステムを用いてアクセス制御データムを保護することは、アクセス制御データムを直接的に保護するために暗号偽装を用いるよりも単純である。なぜなら、アクセス制御データムは、標準的対称暗号アルゴリズムを用いて、フォーマットの知識またはデータムのセマンティクスの必要をなくして暗号化され得るからである。

再び図３を参照して、一旦リクエストが、アクセス秘密鍵を用いて署名されると、リクエストが鍵サーバに送信される。鍵クライアントは、用いられるべき鍵サーバ、好適な鍵サーバおよび他の鍵サーバ、あるいはリクエストが向けられる鍵サーバのアドレスを決定する特定の他の構成を参照しながら、データ構造を保持し得る。

一旦リクエストが鍵サーバによって受信されると、この鍵サーバは、鍵クライアントの公開鍵を用いて鍵クライアントの署名を検証する。署名が検証されない場合、鍵サーバは、不正使用検知処理を開始し、これは、メッセージを不正使用モニタに送信するサービスハンドラによって行われ得る。

しかしながら、署名が検証されない場合、鍵サーバは、リクエストの送信側によって、リクエストにおけるフィールドから、または特定の他の方法によって鍵クライアントを識別する。鍵サーバは、その後、鍵サーバの鍵データベースから識別された鍵クライアントの制御鍵を取得する。鍵サーバは、その後、識別された鍵クライアントの制御鍵を鍵サーバの鍵データベースから取得する。鍵サーバは、その後、リクエストが提供されたワンタイム公開鍵を用いる鍵クライアントの制御鍵を暗号化し、その後、暗号化された制御鍵を鍵クライアントに送信する。鍵クライアントは、ワンタイム鍵ペアを生成するので、鍵クライアントは、ワンタイム秘密鍵を用いて、鍵サーバからの応答を復号することができる。鍵クライアントは、その後、制御鍵を用いて暗号化されるか、または制御鍵を用いて復号することが出来るアクセス制御データムを復号するために制御鍵を用い得る。好適には、制御鍵は、これが、所与のセッションにおいて秘密鍵を操作するために必要とされる限りにおいてのみ鍵クライアント上に保持され得る。

鍵サーバは、制御鍵を求めるリクエストに応答する前に、鍵クライアントを認証するために、１つ以上の種々の認証技術を用い得る。１実施形態において、鍵サーバは、リクエストと共に鍵クライアントによって提供されるデジタル証明書を用いて署名を検証する。

いくつかの場合において、鍵データベースは、暗号化された形態で保持される。このような場合、鍵サーバは、鍵クライアントに応答するためのワンタイム公開鍵を用いて制御鍵を暗号化する前に、鍵クライアントの制御鍵を復号化および識別するために使用できるマスター鍵を保持する。

ここで、図４を参照して、ネットワークシステムがここで示され、アクセス制御データが用いられ得るシステムを図示する。ここで示されるように、鍵クライアント１２は、ブラウザ、セキュリティハンドラ、および場合によっては、他のＰＫＩアプリケーションを動作させるシステムである。インターフェースするブラウザの当該分野において周知のように、ブラウザは、種々のソースから証明書を取得し得、ウェブサーバと安全に、または安全でなく接続する。ブラウザが秘密鍵を必要とする場合、その秘密鍵は、アクセス制御データムＤによって表され得る。セキュリティハンドラ４２が暗号化されない形態のデータムＤをブラウザに提供するようにするために、上述のように、セキュリティハンドラ４２は、場合によっては、Ａｒｃｏｔ鍵認証機関（ＡＫＡ）ゲートウェイ等のゲートウェイを通じて鍵サーバ１４と双方向通信して、アクセス制御データムの復号化を可能にする制御鍵を鍵データベース３６から取得する。

図２および図４に示されるように、鍵クライアント１２は、鍵クライアント１２にデジタルアイデンティティを提供するためにセキュリティハンドラを用いる。別の実施形態において、図５に示されるように、ハードウェハスマートカード１４２は、セキュリティハンドラ４２の代わりに用いられる。このような実施形態において、アクセス制御データムをリクエストする場合、ＰＫＩアプリケーションおよびブラウザは、スマートカードインターフェース１４４と双方向通信する。スマートカードインターフェース１４４は、ゲートウェイまたは鍵サーバと双方向通信するためにまた用いられ得る。典型的な動作において、ハードウェアスマートカード１４２内のセキュリティ保護されるスマートカードプロセッサ１５０は、秘密鍵動作（例えば、復号化、署名）を求めるリクエストを受け取り、内部ストレージ１５２内に格納された秘密鍵を用いてリクエストされた動作を実行することによってリクエストに応答し、その結果を戻す。スマートカードの当該分野にて周知のように、スマートカードプロセッサ１５０は、ストレージ１５２内に格納された秘密アイデンティティ鍵へのアクセスを制御するようにプログラムされ得る。

しかしながら、アクセス鍵はセキュリティ保護されているので、このプロセッサは、デジタルアイデンティティを提供し、そのアクセス鍵を知ることは、システムがアクセス制御データムを復号化することを可能にする。アクセス鍵が損なわれた（ｃｏｍｐｒｏｍｉｓｅｄ）か、または定期的に更新される必要がある場合、あるいは、鍵クライアントが初期化されると、セキュリティハンドラまたはスマートカードに新しいアクセスを安全にロードするために、新しいアクセス鍵およびプロセスが必要とされる。セキュリティハンドラまたはスマートカードが活性化されると、アイデンティティが示されたユーザは、活性化プロセスにおいて、新しいアクセス秘密鍵を鍵サーバに登録する。

活性化プロセスは、ユーザがセキュリティハンドラまたはスマートカード用の新しいデータセットを（ダウンロードその他によって）取得し、その後、新しいデータセットの秘密鍵を活性化することで開始する。活性化プロセスは、鍵クライアントがワンタイム鍵ペアを生成し、鍵クライアントが活性化リクエストメッセージ（「Ｃｒｅａｔｅ−Ｓｅｃｒｅｔ」）を作成して新しい制御鍵をリクエストすることで開始する。活性化リクエストメッセージは、ワンタイム公開鍵を含み、ユーザのアクセス秘密鍵によって署名される。必要ではないが、アクセス秘密鍵は、ユーザによって保持されるすべてのアイデンティティ記録（ＩＲ）に対して同じであり得、ここで、各アイデンティティ記録が鍵サーバの異なったセットと関連付けられる。

鍵クライアントは、活性化リクエストメッセージを鍵サーバに送信する。鍵サーバは、リクエストに対して署名を検証するためか、または、そうでない場合、デジタル証明書をチェックするために認証サーバに照会する。認証サーバは、検証の結果を鍵サーバに戻す。署名の検証が成功した場合、鍵サーバは、リクエストメッセージの署名されたコンテンツを構文解析する。鍵サーバは制御鍵を生成し、これを、リクエストするユーザＩＤのもとに鍵データベース内に安全に格納する。ユーザが制御鍵または他の秘密をすでに有する場合、鍵サーバは第２の秘密を生成する。さらに、鍵サーバが制御鍵を鍵データベース内に安全に格納した場合、鍵サーバは、マスター鍵で制御鍵を暗号化する。

鍵サーバは、その後、少なくとも１つのメッセージタイプおよび制御鍵（または他の機密）を含む鍵クライアントに対する応答メッセージを作成する。応答メッセージは、ワンタイム公開鍵を用いて暗号化され、鍵クライアントに送信される。鍵クライアントは、その後、応答メッセージを復元および復号し、新しい制御鍵を用いてアクセス制御データム（従来の秘密鍵）を暗号化し、ＩＲ内の制御鍵（必要に応じて）を制御した鍵サーバのアドレスを格納する。制御鍵は、次の動作のために、メモリ内に１セッションでキャッシュされ得るが、好適には、そのセッションを越えては格納されない。

マスター鍵は、鍵データベース内に格納される秘密ユーザ専用制御鍵を暗号化および復号化するために、鍵サーバによって用いられる。鍵サーバは、鍵サーバが起動または初期化するとマスター鍵を取得する。マスター鍵は、ハードウェアデバイス内、スマートカード内、またはパスワードによって保護されたファイル内に格納され得る。アドミニストレータは、鍵サーバを起動または初期化する時点にて、パスワードを入力することを適宜必要とされ得る。パスワードは、マスター鍵を復号化するために用いられ、マスター鍵が鍵サーバによって用いられるようにする。マスター鍵がパスワードによって保護されたファイル内に格納される場合、パスワードによって保護されたファイル内に鍵を格納するための複数の標準的技術が利用可能である。これらの技術のうちの１つは、ＰＫＣＳ＃１２規格である。

上述のシステムは、別個の素子である認証サーバおよび鍵サーバに関して記載される一方で、いくつかの実施形態は、１つのサーバとして構築された認証サーバおよび鍵サーバを有し得る。これらの実施形態において、署名を検証するために、メッセージが鍵サーバから認証サーバに送信される必要はない。いくつかの実施形態は、他のタイプのアクセス制御されたデータを、従来の秘密鍵だけよりも安全にし得る。

クライアントソフトウェアは、ブラウザ、ＰＫＩアプリケーション、インターネットプロトコル（ＩＰ）セキュリティのために用いられる秘密鍵を安全に格納することを必要とするＶＰＮ（仮想プライベートネットワーク）クライアントソフトウェアプログラムであり得る。ＰＫＩアプリケーションは、ＵＮＩＸ（Ｒ）、Ｌｉｎｕｘ、または秘密鍵の安全な格納を必要とするＷｉｎｄｏｗｓ（Ｒ）といった特定のオペレーティングシステム用のネットワークログオンプログラムであり得る。ＰＫＩアプリケーションは、むしろ、Ｋｅｒｂｅｒｏｓセキュリティプロトコルのバージョンをインプリメントするプログラム、電子メールプログラム、クライアントによって認証されたＳＳＬ（ＳｅｃｕｒｅＳｏｃｋｅｔｓＬａｙｅｒ）またはＴＬＳ（ＴｒａｎｓｐｏｒｔＬａｙｅｒＳｅｃｕｒｉｔｙ）を用いるプログラム、ワイヤレスまたはモバイルデバイスプログラム、あるいはデータベースクライアントプログラムといった、秘密鍵の安全な格納を必要とするソフトウェアプログラムであり得る。クライアントシステムの特定のインプリメンテーションにおいて、アクセス制御されたデータムは、ブラウザまたはカスタム公開鍵インフラストラクチャ（ＰＫＩ）アプリケーションに使用できる署名鍵である。

鍵断片を用いる特定の実施形態がここで記載される。この実施形態において、ユーザの鍵バッグは、大きいランダム対称鍵を用いて暗号化され、一時的または永久的にユーザのコンピュータシステム（通常、鍵クライアントを実行する機器）に格納され得る。対称鍵の１断片は、本明細書中で鍵認証機関（ＫＡ）と呼ばれるセキュアサーバに格納される。鍵バッグからの鍵を復号化および使用するために、ユーザは、個人識別番号（ＰＩＮ）を入力することによって、または、認可されたユーザが所有するスマートカードを用いることに等によって、ユーザのシステムがＫＡに対してユーザを認証することを可能にする識別子へのアクセスを実証しなければならない。これらの条件が満たされた場合、ＫＡは、ユーザの資格認定の一部として鍵クライアント機器上に格納された第２の断片と組み合わされ得る鍵断片を提供する。この組み合わせは、鍵バッグからの鍵を復号化するために用いられ得る鍵をもたらす。

ユーザクライアントＫＡ双方向通信に関して、ＫＡに対してクライアントを認証するために強力な２ファクタ認証が用いられ得、この認証は、米国特許第６，１７０，０５８号に記載される暗号偽装を用いること等によってソフトウェアにて完全にインプリメントされ得る。このようなシステムは、Ｓ／ＭＩＭＥ、ＦｏｒｍＳｉｇｎｉｎｇ、およびＳＳＬＣｌｉｅｎｔＡｕｔｈｅｎｔｉｃａｔｉｏｎといったＰＫＩアプリケーション、あるいはＰＫＣＳ＃１１モジュールおよび／またはＣＳＰを用いる任意のアプリケーションにてハードウェアスマートカードの代わりとして用いられる。

図６は、このようなユーザシステムをインプリメントするために用いられ得るユーザシステム６００のブロック図である。ここに示されるように、ユーザシステム６００は、ユーザ資格認定６０２（すなわち、鍵のために、ユーザのアイデンティティを表すデータセット）、鍵バッグ６０４、プロセッサ６０６、コンバイナ（ｃｏｍｂｉｎｅｒ）６０８、鍵ストレージ６１０および復号器６１２を備える。ユーザ資格認定６０２は、アクセス秘密鍵（Ａｐｒｉｖ）、Ａｐｒｉｖに対応する暗号化された公開鍵（Ａｐｕｂ）を含む証明書、およびアトリビュートセットを備えることが示される。アトリビュートセットは、認証およびキー入力の目的で、ユーザのアイデンティティの部分をなし、このユーザのＫＡが配置される場所を示すＫＡロケーションフィールド、鍵バッグが配置される場所を示す鍵バッグロケーションフィールドを含む種々のデータフィールド、リモート鍵バッグが許可されるか否かを示すフラグ、およびローカル鍵断片Ｋａを含む。通常、鍵バッグは、ユーザシステムに対してローカルであるが、ローミングを可能にするため、および他の目的で、リモートで格納され得る。いくつかの場合、ユーザシステムは、複数のユーザ資格認定６０２を有し、そうでない場合、ユーザに複数のスマートカードが発行される。

図７は、１つ以上のユーザシステム６００と双方向通信し得るＫＡシステムのブロック図である。ここに示されるように、ＫＡ７００は、証明書復号器７０２、鍵データベース７０４、復号器７０６および暗号器７０８を備える。Ｋａは、本明細書中に記載されるアクションを実行するために必要とされる他の要素を含むことが理解されるべきである。

アクセス秘密鍵は、ユーザの安全なデジタルアイデンティティを表し、暗号偽装を用いて保護され得る。鍵バッグ内に格納された鍵は、暗号偽装を気づき得ない複数のＰＫＩアプリケーションによって生成および使用され得る従来の秘密鍵であり得る。鍵バッグからの鍵を復号化するために、ユーザシステムは、ＫＡにリクエストを送信し、ＫＡは、鍵断片を戻す。このプロセスは、次に、図６〜図７を参照して、さらに詳細に記載される。

鍵復号プロセスは、ユーザシステム６００上のアプリケーションが鍵を必要とする場合に開始する。このアプリケーションは、プロセッサ６０６への鍵リクエストを作成し、プロセッサは、その後、このリクエストに応答して鍵を生成するために動作する。プロセッサ６０６は、通常、図６に示される形態でＫＡへのリクエストを形成する。

証明書認証機関は、多くの場合、ユーザのシステム上のブラウザに鍵生成命令とともにウェブページを送信することによって従来の鍵を生成する。この命令は、その後、ユーザのシステムによって実行される。この命令を実行する際に、ブラウザは、プロセッサ６０６を呼び出すか、または、すでに呼び出されたプロセッサ６０６へのリクエストを作成し、このリクエストは、その後、ＰＫＣＳ＃１１モジュールまたはＣＳＰとして機能し得、鍵ペアおよびＰＫＣＳ＃１０証明書リクエストを生成する。

プロセッサ６００は、ユーザの資格認定のＫＡロケーションアトリビュートを調べることによって、どのＫＡを用いるのかを決定する。ＫＡへのリクエストは、リクエストのタイプ（例えば、「ＦＥＴＣＨ」）の表示、ユーザＩＤ、暗号化された形態で公開鍵Ａｐｕｂを含む証明書、ワンタイム公開鍵、および、場合によっては他のフィールドを含む。リクエストは、アクセス秘密鍵Ａｐｒｉｖを用いて署名される。ワンタイム公開鍵は、この特定のリクエストのための、プロセッサ６０６によって生成されるワンタイム公開鍵ペアの鍵である。証明書は、リクエストの部分として署名され得るが、必ずしも署名される必要はない。

ＫＡ７００がリクエストを受信すると、ＫＡは、ＫＡドメイン鍵を用いて署名を検証する。好適には、ＫＡのみが、証明書からのアクセス公開鍵Ａｐｕｂを復号化するために復号器７０２によって用いられるドメイン鍵を有する。ドメイン鍵は、ハードデバイスまたはパスワードによって保護されたファイルに格納され得る。

検証が成功した場合、ＫＡ７００は、鍵データベース７０４から秘密鍵の断片を取得する。特定の鍵断片は、リクエストを作成するユーザと関連付けられた鍵断片である。いくつかの実施形態において、一人のユーザごとに、ただ１つの鍵断片があるが、他の実施形態においては、鍵データベース７０４は、所与のユーザについて複数の鍵断片を保持し得、リクエストは、どの鍵断片がリクエストされているかを特定する。

ユーザシステム６００に対する応答を含む応答データムＲを形成する際に、さらなるセキュリティのために鍵データベース７０４において鍵断片がすべて暗号化されるのにともなって、ＫＡ７００は、マスター鍵Ｍを用いて鍵断片Ｋｓを復号化する。鍵断片は、その後、ワンタイム公開鍵ＯＴｐｕｂを用いて暗号化され、従って、応答データムＲを形成する。

ＫＡマスター鍵Ｍは、鍵データベースに格納されるユーザ専用データを暗号化および復号化するために用いられる。ＫＡは、起動または初期化すると、マスター鍵を取得する。マスター鍵がハードウェアデバイス、スマートカード、またはパスワードによって保護されたファイル内に格納され得る。アドミニストレータは、ＫＡを始動または初期化する時点にてパスワードを入力することを選択的にリクエストされ得る。このパスワードは、マスター鍵を復号化して、これをＫＡが使用できるようにするために用いられ得る。

一旦プロセッサ６０６が応答を受信すると、プロセッサは、ワンタイム秘密鍵を用いてＲを復号化し、その後、アクセス秘密鍵を用いて結果を復号化して、秘密鍵Ｋｓを明らかにする。プロセッサ６０６を、その後、連結することによって、またはその他の方法によってＫｓとＫａとを連結してＫｂを形成することによって結合するコンバイナ６０８にＫｓを提供する。１つの可能な組み合わせ技術は、ＳＨＡ−１またはＭＤ５といったハッシュアルゴリズムの使用である。ハッシュは、単純な連結のために望ましい。なぜなら、ハッシュの組み合わせの結果は、特定の長さになるからである。Ｋｂは、鍵バッグ６０４からの１つ以上の従来の秘密鍵を復号化するために用いられ得る。秘密鍵は、その後、署名等の目的で用いられ得る。Ｋｂは、同じセッションにおいて次の動作のためにメモリ（例えば、ストレージ６１０）に選択的にキャッシュされるが、セッションが完了した後に、リセットまたは消去され得る。

上記の記載は、ユーザシステムが、そのユーザの秘密鍵断片Ｋｓを格納するＫＡとの関係をすでに確立したことを想定する。初期化段階において、ユーザシステムは、「ＦＥＴＣＨ」リクエストの代わりに「ＣＲＥＡＴＥ」リクエストといった異なったリクエストタイプを有するリクエストを送信し得る。ＫＡがＣＲＥＡＴＥリクエストを受信し、そのリクエストの署名が検証されると、ＫＡは、秘密鍵Ｋｓを生成し、これを、鍵データベース内でリクエストするユーザのＵｓｅｒＩＤのもとに安全に格納し、マスター鍵を用いて暗号化される。ＫＡは、その後、秘密鍵Ｋｓを含む応答を送信する。この応答は、リクエスト内に提供されたワンタイム鍵を用いて暗号化される。

一旦プロセッサ６０６が応答を受信すると、プロセッサは、ワンタイム秘密鍵を用いてＲを復号化し、その後、その結果を、アクセス秘密鍵を用いて復号化して、秘密鍵Ｋｓを明らかにする。プロセッサ６０６は、その後、ＫｓとＫａとを組み合わせることによって生成された対称鍵Ｋｂを用いて、鍵バッグ内に格納するための従来の秘密鍵を暗号化するためにＫｓを用い得る。

上述のシステムにおいて、従来の秘密鍵は、ユーザシステムに配置された鍵バッグに格納され、ユーザ資格認定は、ユーザシステムに格納される。他の実施形態において、ユーザ資格認定および／または鍵バッグは、サーバに格納され、サーバは、ユーザが従来の秘密鍵を用いる一方で、ローカルユーザシステムから離れることを可能にする。ローミングユーザ資格認定のホストとして働くＫＡまたは暗号化された鍵バッグは、機密鍵を提供するものとは、別個のＫＡのインスタンスであり得るか、またはこれらのインスタンスは、同じシステムであり得る。ローミングサポートがディセーブルされるべき場合、ユーザアトリビュートの「鍵バッグローミング許可（ＫｅｙＢａｇＲｏａｍｉｎｇＡｌｌｏｗｅｄ）」フラッグが「Ｎｏ」に設定され得る。

ローミングの第１のタイプにおいて、ユーザは、ユーザのローカル機器に関するユーザ資格認定を必要としない。ユーザは、ローミングサービスを行うサーバ（例えば、Ｗｅｂブラウザを有するＷｅｂサーバ）にアクセスし得る。ユーザは、「ペットの名前は（ＮａｍｅｏｆＰｅｔ？）」または「幼年時代の先生の名前は（ＮａｍｅｏｆＣｈｉｌｄｈｏｏｄＴｅａｃｈｅｒ？）」といった所定の質問のセットを用いて、問題を形成するように促される。質問が正確に回答された場合、そのユーザのユーザ資格認定は、ユーザの現在のローカル機器にダウンロードされる。好適には、ユーザ資格認定がローミングサーバにおけるデータベースに格納された場合、少なくともアクセス秘密鍵が、暗号偽装により保護され、Ｋａ鍵断片は、サーバにて個々のユーザのＫａ値が知られることを防止するために、（ソフトウェアまたはハードウェアモジュール暗号を用いて）暗号化された形態で格納され得る。

ローミングの第２のタイプに関して、ユーザは、従来の秘密鍵を格納し、したがって、これらの秘密鍵がローミング中にアクセスされ得る。両方の場合に、ユーザ資格認定の場所および鍵バッグは、ローミングする使用およびローミングしない使用について同じであり得るが、最初の場合、ユーザシステムは、ユーザの現在のローカルシステムのサーバとして機能する。しかしながら、ユーザがローミング中であり、その鍵バッグのローカルコピーを保持しない場合、プロセッサ６００は、署名された「ＦＥＴＣＨ」メッセージをサーバに送信することによって、ユーザの資格認定を用いて暗号化された鍵バッグのホストとして働くサーバと連絡する。暗号化された鍵バッグをダウンロードするためのプロセスおよびメッセージフローは、秘密鍵Ｋｓをダウンロードするために用いられるプロセスと同一または類似であるが、暗号化された鍵バッグが、Ｋｓではなく送信されたデータであることを除く。

上述の実施形態において、ユーザシステムは、その動作を実行する一方で、ネットワークを介してＫＡと接続される。いくつかの場合、ユーザは、秘密鍵を動作させる一方で、ネットワークと接続されない実行を必要とし得る。例えば、ユーザは、航空機内で座っている間、ラップトップ上でＳ／ＭＩＭＥ電子メールに署名または復号することを所望し得る。このような動作を可能にするために、いくつかの実施形態は、上述のオフラインモードおよびオンラインモードを含む。

オフライン動作を可能にするために、ユーザ資格認定が登録された場合、ユーザはオフラインパスワードを選択する。ユーザが「オフラインに進む（ｇｏｏｆｆｌｉｎｅ）」を選定すると、プロセッサ６００は、ユーザ資格認定およびユーザによって入力されたＰＩＮを用いて、ＫＡに対してユーザを認証する。プロセッサは、その後、「オフライン鍵コンテナ」を自動的にダウンロードする。切断されたセッションごとに、オフライン鍵のロックを外すために、ユーザは、プロセッサにオフラインパスワードを提供する必要がある。オフライン鍵コンテナは、設定された時間の経過といった特定の所定の基準が満たされた後、またはユーザが次にオンライン状態になった場合は自動的に消去され得る。ＫＡは、オフライン鍵コンテナを使用する時間制限、ユーザがＫＡと双方向通信することが可能な時間範囲および日付の範囲、ならびに／あるいはユーザがＫＡと双方向通信することが可能なＩＰアドレス範囲といった管理上のポリシー設定を含むように構成され得る。

アプリケーションは、ユーザの代理である計算エージェントを含み得、ここで、計算エージェントは、ソフトウェアおよび／またはハードウェア上で動作し、かつユーザの代わりである。いくつかの実施形態は、制御鍵を求めるリクエストおよび新しい制御鍵を生成するリクエストの他に、他のタイプのリクエストを含み得る。スマートカードが用いられる場合、これらのカードは、ＳＩＭＭカードまたはＧＳＭセルラー電話に適合するスマートカードであり得る。

アクセス制御されるデータを管理するための新しい種類の技術がこれまで提示された。本発明は、ここで、好適な実施形態を参照して記載された。代替および置換は、ここで、当業者に明らかである。従って、上掲の請求項によって提供される場合を除いて、本発明を限定することは意図されない。

図１は、種々の認証された鍵サーバおよび認証された鍵クライアントがネットワークと結合され、不正サーバおよびクライアントもネットワークと結合され得るネットワークシステムのブロック図である。図２は、１つの鍵サーバおよび１つの鍵クライアントのブロック図である。図３は、鍵サーバに格納された鍵を用いる鍵クライアント上の鍵を復号化するためのプロセスのフローチャートである。図４は、鍵クライアントの１実施形態をより詳細に示すブロック図である。図５は、鍵クライアントの別の実施形態をより詳細に示すブロック図であり、ここで、鍵クライアントは、鍵クライアントによって用いられる認証データをセキュリティ保護するスマートカードを用いる。図６は、ユーザのシステムのブロック図である。図７は、鍵認証機関サーバのブロック図である。

Claims

暗号化されたデータにアクセスする方法であって、該暗号化されたデータは、第１のセキュリティ保護されたシステムに格納され、該暗号化されたデータを復号化するために使用可能なコントロール鍵は、第２のセキュリティ保護されたシステムに格納され、該第１のセキュリティ保護されたシステムは、第１のセキュリティ保護されたシステム鍵ペアの秘密鍵を保持し、該方法は、
該第１のセキュリティ保護されたシステムが、ワンタイム鍵ペアを取得することと、
該第１のセキュリティ保護されたシステムが、該コントロール鍵を求めるリクエストを生成することであって、該リクエストは、少なくとも該ワンタイム鍵ペアの公開鍵を含む、ことと、
該第１のセキュリティ保護されたシステムが、該第１のセキュリティ保護されたシステム鍵ペアの該秘密鍵を用いて該リクエストに署名することと、
該第１のセキュリティ保護されたシステムが、該第２のセキュリティ保護されたシステムに該署名されたリクエストを送信することと、
該第２のセキュリティ保護されたシステムが、該第１のセキュリティ保護されたシステム鍵ペアの公開鍵に基づいて、該リクエストに署名した該第１のセキュリティ保護されたシステムを認証することと、
該第２のセキュリティ保護されたシステムが、該第１のセキュリティ保護されたシステムが認証された場合に、該署名されたリクエストに対する応答を生成および送信することであって、該応答は、少なくとも、該第１のセキュリティ保護されたシステムによってリクエストされたコントロール鍵であって、該リクエストに提供された該ワンタイム鍵ペアの公開鍵を用いて暗号化されるコントロール鍵を含む、ことと、
該第１のセキュリティ保護されたシステムが、該ワンタイム鍵ペアの秘密鍵を用いて該応答の少なくとも一部分を復号化して、該コントロール鍵を取得することと、
該第１のセキュリティ保護されたシステムが、該応答の部分として提供される該コントロール鍵を少なくとも用いて、該暗号化されたデータを復号化することと
を包含する、方法。
前記第１のセキュリティ保護されたシステムは鍵サーバクライアントであり、前記第２のセキュリティ保護されたシステムは鍵サーバである、請求項１に記載の方法。
前記第２のセキュリティ保護されたシステムは、複数の第１のセキュリティ保護されたシステムにサービスを提供する鍵サーバである、請求項１に記載の方法。
前記第１のセキュリティ保護されたシステムが、前記ワンタイム鍵ペアを取得することは、該第１のセキュリティ保護されたシステムが、ワンタイム鍵ペアを生成することを包含する、請求項１に記載の方法。
前記暗号化されたデータは、複数の秘密鍵を含む、請求項１に記載の方法。
セキュリティ保護されたシステムであって、該セキュリティ保護されたシステムでは、暗号化されたデータが保持され、該暗号化されたデータがリモートシステムに格納されたコントロール鍵を用いて復号化され得、該セキュリティ保護されたシステムは、
セキュリティ保護されたシステム鍵ペアの秘密鍵のためのストレージと、
通信ハンドラであって、
ワンタイム鍵ペアを生成または取得すること
を実行する通信ハンドラと、
セキュリティハンドラであって、
該コントロール鍵を求めるリクエストを生成することであって、該リクエストは、少なくとも該ワンタイム鍵ペアの公開鍵を含む、ことと、
該セキュリティ保護されたシステム鍵ペアの該秘密鍵を用いて該リクエストに署名することであって、該通信ハンドラは、該署名されたリクエストを該リモートシステムに送信する、ことと、
該リモートシステムからの該署名されたリクエストに対する応答を処理することと、
該ワンタイム鍵ペアの該秘密鍵を用いて該署名されたリクエストから該コントロール鍵を取得することと
を実行するセキュリティハンドラと、
該暗号化されたデータを、該リモートシステムによって提供される該コントロール鍵を用いて復号化する復号器と
を備え、
これにより、該リモートシステムは、該リモートシステムによって提供された該コントロール鍵が、該暗号化されたデータを正確に復号化するか否かに基づいて認証される、セキュリティ保護されたシステム。
セキュリティ保護された鍵サーバであって、複数の鍵クライアントの鍵が保持され、該セキュリティ保護された鍵サーバと該複数の鍵クライアントとはネットワークを介して結合されており、該セキュリティ保護された鍵サーバは、
鍵のデータベースであって、各鍵は鍵クライアントと関連付けられる、データベースと、
ワンタイム公開鍵を含む鍵リクエストであって、鍵クライアントによって署名される鍵リクエストを受け取る通信ハンドラと、
サービスハンドラであって、
該鍵クライアントの公開鍵に基づいて、該鍵リクエストに署名した該鍵クライアントを認証することと、
該認証されたクライアントへの応答であって、該リクエストされた鍵を含み、該ワンタイム公開鍵を用いて暗号化される応答を暗号化することであって、該認証されたクライアントへの応答は、該通信ハンドラによって送信される、ことと
を実行するサービスハンドラと
を備える、セキュリティ保護された鍵サーバ。