(57)【特許請求の範囲】
【請求項１】
ネットワークを介してサーバと認証信用証明の要求者のコンピューティングデバイスとに接続された装置において、電子トランザクションを実行するのに使用可能な認証信用証明を取得するために実施される方法であって、
（ａ）前記装置のネットワークインターフェースを介して前記サーバにアクセスして、所定の認証信用証明を要求することであり、前記認証信用証明は
（ｉ）前記要求の前に前記サーバに存在し、
（ｉｉ）前記要求者を固有に識別し、
（ｉｉｉ）電子トランザクションの実行に使用するのに好適であり、
（ｂ）前記要求者に関連付けられた所定の応答を請求するチャレンジを、前記サーバから前記ネットワークインターフェースを介して受け取ることと、
（ｃ）前記要求者のコンピューティングデバイスから、前記装置のユーザインターフェースを介して前記チャレンジへの応答を受け取ることと、
（ｄ）前記応答が前記チャレンジを満たすという前記サーバによる決定に応答して、前記サーバから前記認証信用証明を受け取ることとを備え、
前記認証信用証明は、アクセスコードにより暗号化され、前記サーバに予め格納されており、
前記ユーザインターフェースは、前記要求者からの応答としてアクセスコード候補を受け取るように構成され、
前記装置の復号モジュールにより、前記アクセスコード候補が、前記アクセスコードと同じ出力にハッシュ可能な擬似有効応答のファミリに属することを検証し、前記サーバから受け取った認証信用証明を復号するために前記アクセスコード候補を使用することをさらに備え、
前記方法が、複数の要求者位置から、前記要求者によって反復可能なオンデマンド方式で動作可能であることを特徴とする方法。
【請求項２】
前記認証信用証明は、前記要求者の秘密信用証明を含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記秘密信用証明は、秘密鍵であることを特徴とする請求項２に記載の方法。
【請求項４】
（ｅ）前記要求者のコンピューティングデバイスが、前記認証信用証明を使用して、前記電子トランザクションを実行することと、
（ｆ）前記電子トランザクションが終了すると、前記認証信用証明を前記要求者のコンピューティングデバイスから削除することとをさらに含むことを特徴とする請求項１または２に記載の方法。
【請求項５】
前記要求者のコンピューティングデバイスは、Ｗｅｂブラウザを含み、前記ネットワークは、分散型コンピュータネットワークであることを特徴とする請求項２に記載の方法。
【請求項６】
前記要求者のコンピューティングデバイスは、前記認証信用証明をデジタルウォレットとして使用することを特徴とする請求項２に記載の方法。
【請求項７】
前記応答は、前記サーバと前記要求者との間の共有秘密を含むことを特徴とする請求項２に記載の方法。
【請求項８】
前記認証信用証明は、前記要求者の秘密鍵を含むことを特徴とする請求項１に記載の方法。
【請求項９】
前記チャレンジおよび前記応答は、ゼロ知識証明のメンバであることを特徴とする請求項１に記載の方法。
【請求項１０】
前記ステップ（ｂ）および（ｃ）は、暗号カモフラージュ形式のチャレンジ応答プロトコルの一部であることを特徴とする、請求項１に記載の方法。
【請求項１１】
前記サーバから、前記認証信用証明と共にデジタル通貨をダウンロードすることをさらに含むことを特徴とする請求項１に記載の方法。
【請求項１２】
ネットワーク環境で、電子トランザクションを実行するのに使用可能な認証信用証明を取得するための装置であって、
（ａ）（ｉ）ネットワークを介してサーバにアクセスして、所定の認証信用証明を要求することであって、前記認証信用証明は、
（Ａ）前記要求の前に前記サーバに存在し、
（Ｂ）前記認証信用証明の要求者を固有に識別し、
（Ｃ）電子トランザクションの実行に使用するのに好適であり、
（ｉｉ）前記要求者に関連付けられた所定の応答を請求するチャレンジを前記サーバから受け取るように構成されたネットワークインターフェースと、
（ｂ）前記要求者のコンピューティングデバイスから、前記チャレンジへの応答を受け取り、前記認証信用証明を前記要求者のコンピューティングデバイスに格納するように構成されたユーザインターフェースとを備え、
前記ネットワークインターフェースは、前記応答が前記チャレンジを満たすという前記サーバによる決定に応答して、前記認証信用証明を受け取るように構成され、
前記認証信用証明は、アクセスコードにより暗号化され、前記サーバに予め格納されており、
前記ユーザインターフェースは、前記要求者からの応答としてアクセスコード候補を受け取るように構成され、
（ｃ）前記アクセスコード候補が、前記アクセスコードと同じ出力にハッシュ可能な擬似有効応答のファミリに属することを検証し、前記サーバから受け取った認証信用証明を復号するために前記アクセスコード候補を使用する復号モジュールをさらに備え、
前記装置が、複数の要求者位置から、前記要求者によって反復されるオンデマンドアクセスを取得するために前記要求者が使用可能であることを特徴とする装置。
【請求項１３】
前記認証信用証明は、前記要求者の秘密信用証明を含むことを特徴とする請求項１２に記載の装置。
【請求項１４】
前記秘密信用証明は、秘密鍵であることを特徴とする請求項１３に記載の装置。
【請求項１５】
前記要求者のコンピューティングデバイスは、Ｗｅｂブラウザとして使用するために構成され、前記ネットワークが分散型コンピュータネットワークであることを特徴とする請求項１２に記載の装置。
【請求項１６】
前記認証信用証明は、デジタルウォレットとして使用するために構成されることを特徴とする請求項１２に記載の装置。
【請求項１７】
前記認証信用証明は、前記要求者の秘密鍵を含むことを特徴とする請求項１２に記載の装置。
【請求項１８】
前記チャレンジおよび前記所定の応答は、暗号カモフラージュ形式のチャレンジ応答プロトコルの一部であることを特徴とする請求項１２に記載の装置。
【請求項１９】
ネットワーク環境を介して認証信用証明の要求者のコンピューティングデバイスに接続された装置において、電子トランザクションを実行するのに使用可能な認証信用証明を提供するために実施される方法であって、
（ａ）前記装置のネットワークインターフェースを介して、所定の認証信用証明に関する要求を前記要求者のコンピューティングデバイスから受け取ることであり、前記認証信用証明は、
（ｉ）前記要求の前に予め格納されており、
（ｉｉ）前記要求者を固有に識別し、
（ｉｉｉ）電子トランザクションの実行に使用するのに好適であり、
（ｂ）前記要求者に関連付けられた所定の応答を請求するチャレンジを、前記ネットワークインターフェースを介して、前記要求者のコンピューティングデバイスに送信することと、
（ｃ）前記要求者のコンピューティングデバイスから、前記ネットワークインターフェースを介して前記チャレンジへの応答を受け取ることと、
（ｄ）前記認証信用証明は、アクセスコードにより暗号化され、前記装置の復号モジュールにより、前記応答が、前記アクセスコードと同じ出力にハッシュ可能な擬似有効応答のファミリに属することを検証し、前記格納済みの認証信用証明を復号するために前記アクセスコード候補を使用して、前記応答が前記チャレンジを満たしているかどうかを決定することと、
（ｅ）前記ネットワークインターフェースを介して、前記要求者のコンピューティングデバイスに前記認証信用証明を伝送することとを備え、
前記方法が、複数の要求者位置で、前記要求者によって反復されるオンデマンドの認証信用証明要求を処理するように動作可能であることを特徴とする方法。
【請求項２０】
前記認証信用証明は、前記要求者の秘密信用証明を含むことを特徴とする請求項１９に記載の方法。
【請求項２１】
前記秘密信用証明は、秘密鍵であることを特徴とする請求項２０に記載の方法。
【請求項２２】
前記要求者のコンピューティングデバイスは、Ｗｅｂブラウザを含み、前記ネットワークは、分散型コンピュータネットワークであることを特徴とする請求項２０に記載の方法。
【請求項２３】
前記要求者のコンピューティングデバイスは、前記認証信用証明をデジタルウォレットとして使用することを特徴とする請求項２０に記載の方法。
【請求項２４】
前記応答は、前記要求者との間の共有秘密を含むことを特徴とする請求項２０に記載の方法。
【請求項２５】
前記認証信用証明は、前記要求者の秘密鍵を含むことを特徴とする請求項１９に記載の方法。
【請求項２６】
前記ステップ（ｅ）は、前記要求者による暗号カモフラージュ解除のために、前記認証信用証明を暗号カモフラージュ形式で前記要求者のコンピューティングデバイスに送信することを含むことを特徴とする請求項１９に記載の方法。
【請求項２７】
前記認証信用証明と共にデジタル通貨を前記要求者に送ることをさらに含むことを特徴とする請求項１９に記載の方法。
【請求項２８】
ネットワーク環境で、電子トランザクションを実行するのに使用可能な認証信用証明を提供するための装置であって、
（ａ）（ｉ）所定の認証信用証明に関する要求を、ネットワークを介して要求者から受け取るように構成され、前記認証信用証明は、
（Ａ）前記要求の前に予め格納されており、
（Ｂ）前記要求者を固有に識別し、
（Ｃ）電子トランザクションの実行に使用するのに好適であり、
（ｉｉ）前記要求者に関連付けられた所定の応答を請求するチャレンジを、前記要求者のコンピューティングデバイスに送信し、
（ｉｉｉ）前記要求者のコンピューティングデバイスから前記チャレンジへの応答を受け取るように構成されたネットワークインターフェースと、
（ｂ）前記認証信用証明は、アクセスコードの元で暗号化され、前記応答が、前記アクセスコードと同じ出力にハッシュ可能な擬似有効応答のファミリに属することを検証し、前記格納済みの認証信用証明を復号するために前記応答を使用して、前記応答が前記チャレンジを満たすかどうかを決定するする復号モジュールとを備え、
前記ネットワークインターフェースは、前記認証信用証明を前記要求者のコンピューティングデバイスに格納するようにさらに構成され、
前記装置が、複数の要求者位置で、前記要求者によって反復されるオンデマンドの認証信用証明要求を処理するように動作可能であることを特徴とする装置。
【請求項２９】
前記認証信用証明は、前記要求者の秘密信用証明を含むことを特徴とする請求項２８に記載の装置。
【請求項３０】
前記秘密信用証明は、秘密鍵であることを特徴とする請求項２９に記載の装置。
【請求項３１】
前記応答は、前記要求者との間の共有秘密を含むことを特徴とする請求項２９に記載の装置。
【請求項３２】
前記認証信用証明は、前記要求者の秘密鍵を含むことを特徴とする請求項２８に記載の装置。
【請求項３３】
前記ネットワークインターフェースは、前記要求者による暗号カモフラージュ解除のために、前記認証信用証明を暗号カモフラージュ形式で前記要求者のコンピューティングデバイスに送信するように構成されることを特徴とする請求項２８に記載の装置。
【発明の詳細な説明】
【０００１】
（関連出願の相互参照）
本出願は、係属中の米国特許出願第０８／９９６７５８号の一部継続出願である。
【０００２】
（発明の背景）
ネットワーク化されたコンピュータ展開では、クライアントコンピュータのユーザは、電子メール、許可された情報または秘密情報へのアクセス、商品またはサービスの購入、および多くの他の電子商取引トランザクションなどの用途のために、自分自身をサーバコンピュータに認証させる必要がある。関連する情報が比較的価値の低いものである場合には、ユーザは単純なパスワードで自分自身を認証させるだけで十分なことがある。ただし、情報が価値の高いものである場合、またはデータネットワークが安全保護されていない場合には、単純なパスワードではアクセスを効果的に制御するには不十分である。たとえば、インターネットを通ってコンピュータにアクセスしている場合、パスワードは、ネットワークを通るときにパケットをフィルタリングすることによって簡単に取り込まれる。あるいは、パスワードの文字数は６文字またはそれ以下であることが多いため、知能的な試行を繰り返せば推測または「解読」することができる。簡単に言えば、パスワードの便利さがそれ自体を解読しやすいものにしており、ユーザにとって充分に簡単に覚えられるものであれば、ハッカーにとっては充分に推測しやすいものということになる。
【０００３】
パスワードの不安定さを克服するために、これに代わる技術が開発されてきた。このような技術の１つが非対称鍵暗号法である。この技術では、ユーザはそれぞれ２つの鍵、すなわち公開鍵および秘密鍵を有することとなる。ユーザは、デジタル量で自分の秘密鍵を使用して暗号操作（たとえば暗号化またはデジタル署名）を実行し、その結果その量が、ユーザの公開鍵へのアクセスのみを有する検証子（ｖｅｒｉｆｉｅｒ）によって認証される。したがって秘密鍵は、ユーザの認証信用証明としての働きをする。すなわち、検証子はユーザを認証するためにユーザの秘密鍵を知っている必要がない。公開鍵は広く行き渡らせることができるが、秘密鍵は依然として秘密であり、強力な認証には強化セキュリティが備えられる。秘密鍵は一般にユーザが記憶するには複雑で長すぎるものであるため、一般にソフトウェアまたはハードウェアトークン内に格納され、使用前にコンピュータとインターフェースされる。
【０００４】
このようなソフトウェアトークンの１つが、いわゆるソフトウェアウォレット（ｗａｌｌｅｔ）であり、この中で秘密鍵がパスワードまたは他のアクセス制御されたデータによって暗号化される。このようなソフトウェアウォレットでは、侵入者が秘密鍵を回復するまで何度でも徹底的にパスワードを試行するのを阻止できない。これにより、前述の単純なパスワード機構と同類のセキュリティリスクが生じる。さらに、ソフトウェアウォレットはユーザのコンピュータ上に格納されるため、ユーザが自由に場所をローミングする必要がある場合は、不便なことがある。
【０００５】
ソフトウェアウォレットに対して、スマートカードなどのハードウェアトークンの方が安全であり、ユーザがローミングする場合には携帯に便利である。典型的なハードウェアスマートカードでは、秘密鍵はハードウェア内に格納され、ユーザが秘密鍵にアクセスできるようにする監視チップ（ｗａｔｃｈｄｏｇ  ｃｈｉｐ）によって保護されており、正しいパスワードを入力するとスマートカードのロックが解除される。スマートカードは、ハッカーがパスワードを推測しようとした場合、数回連続して試行に失敗するとカードがロックされるように構成することもできる。ハードウェアトークンの欠点は、（１）適切なトークンリーダハードウェアがインストールされた場所へのローミングが制限されること、（２）ハードウェアトークンがソフトウェアトークンに比べて高価であること、（３）ユーザがローミングする場合には必ずハードウェアトークンを物理的に携帯しなければならないこと、および（４）ハードウェアトークンの紛失、置き違え、または盗難が生じやすいことである。
【０００６】
したがって、ハードウェアトークンシステムが提供するセキュリティは向上しているが、ソフトウェアベースのシステムに比べていくつかの欠点がある。したがって、ハードウェアベースとソフトウェアベースの両方のシステムが有する最高の機能を組み合わせたシステムが望まれる。
【０００７】
（発明の概要）
本発明は、ローミング（ｒｏａｍｉｎｇ）中のユーザに認証信用証明（ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ｃｒｅｄｅｎｔｉａｌ）をオンデマンドで送達するための方法および装置を開示するものである。信用証明はソフトウェア内で格納、送達、および伝送され、追加のハードウェアは不要である。システムの基本的な実施形態では、以前に信用証明サーバで供託（ｅｓｃｒｏｗ）した共有秘密（ｓｈａｒｅｄ  ｓｅｃｒｅｔ）形式のアイデンティティ証明を提供することで、ユーザが自分の信用証明を随意に要求することが可能である。共有秘密はユーザが選択することが可能であり、この秘密は、母親の旧姓、３年生の先生など、覚えておきやすいものである。ユーザは、チャレンジ応答プロトコルを介してサーバからのチャレンジに応答し、サーバは、ユーザの信用証明を公開する前にこのような質問に対する正しい回答を要求する。本発明の他の実施形態では、ユーザの認証信用証明を、パスワードなどの単純な共有秘密機構、指紋または網膜像に基づく生物測定学を応用した認証機構、あるいは１対１ハッシュされた（ｏｎｅ−ｔｏ−ｏｎｅ  ｈａｓｈｅｄ）共有秘密によって保護された、サーバ上に格納することができる。本発明の他の実施形態では、ユーザは、暗号方式でカモフラージュされたチャレンジ応答プロトコル（ｃｈａｌｌｅｎｇｅ−ｒｅｓｐｏｎｓｅ  ｐｒｏｔｏｃｏｌ）を介してサーバと対話する。具体的に言えば、ユーザがサーバのチャレンジに正しく応答すると、ユーザは自分の認証信用証明を受け取ることになる。ただし、ハッカーがシステムを破ろうとしているかのようにユーザが不正に応答すると、そのユーザは、形式上は良いものであって正しそうに見えるが、実は無効である信用証明を受け取ることになる。さらに認証信用証明それ自体を、ユーザだけが知っている追加の秘密で暗号化またはカモフラージュすることができる。認証信用証明は、多数の同様の（擬似有効）データ内に埋め込まれた場合に、暗号法でカモフラージュされた形式であるということになる。これらのデータは、ユーザが覚えておける共有秘密を使用して、ユーザが難なく正しいものを見つけだせるものとはまったく異なる。ただしこれらのデータは、侵入者にとってはすべてが等しく正しそうに見えるように、十分に似通ったものでもある。このような暗号法でカモフラージュされた認証信用証明を、信用証明サーバ側またはユーザ側コンピュータのいずれかでカモフラージュ解除を実行することができる、カモフラージュされた形式またはカモフラージュ解除された形式のいずれかの形式で、ユーザに提供することができる。上記で述べた本発明の様々な実施形態が、以下の１つまたは複数の利点を提供する。
【０００８】
展開するために追加のハードウェアが不要である。これは、カードおよびカードリーダが一般に普及した様式で使用される必要がある、スマートカードなどのハードウェアトークンとは対照的である。
（１）ユーザの高い利便性。ローミング中のユーザは、トークンを携帯する必要がなく、必要に応じて要求することができる。
（２）管理オーバヘッドの少なさ。トークンを紛失、置き違え、または忘れたユーザが、管理者の介入を必要としない。
（３）迅速な展開。ローミングアクセスによるソフト信用証明は、直感的に使用され、ユーザ／管理者のトレーニングがほとんど必要ないことから、迅速に展開することができる。
（４）単一要素のみのシステムを介した強化セキュリティ。
【０００９】
（発明の詳細な説明）
ここで、１つまたは複数の遠隔サーバにアクセスするためにＷｅｂブラウザを操作するユーザの例示的コンテキストを使用して、本発明の様々な例示的な実施形態について説明するが、これによりユーザは、自分の認証信用証明にアクセスを続けながら、インターネットの周辺を自由にローミングすることができる。当該分野の技術者であれば、本発明が、データベース、医療クライアントステーション、および金融トレーディングステーションを含むが、これらに限定されることのない、他のクライアントサーバ環境にも適用可能であることを理解されよう。さらに、ネットワーク環境はインターネットである必要はないが、イントラネットまたは実際に任意の分散型コンピュータネットワークであってよい。
【００１０】
ここで図１を参照すると、ブラウザ１４０にいるユーザは、Ｗｅｂサーバ１１０にアクセスして電子トランザクションを実行する。次にＷｅｂサーバ１１０は、アクセス制御サーバ１２０によって防護されており、これによってトランザクションサーバ１３０への未許可のアクセスが防止される。たとえば、Ｗｅｂサーバ１１０は企業のホームページであってよく、アクセス制御サーバ１２０はファイアウォールであってよく、トランザクションサーバ１３０は、ユーザがアクセスしようとする管理会社のデータを所有していてもよい。他の例では、アクセス制御サーバ１２０はメンバシップまたは信用／支払検証システムであってよく、トランザクションサーバ１３０はバックエンド出荷／配送システムであってよい。当分野の技術者であれば、サーバ１１０、１２０、および１３０のうちいずれかまたはすべてを単一のサーバに組み込んでもよいこと、他の特殊な機能を実行する追加のサーバがあってもよいこと、これらのサーバのうちいずれかを同じ場所に配置するかまたは広く分散させてもよいことなどを理解されよう。同様に、電子トランザクションは、安全な電子メール、許可された情報または秘密情報へのアクセス、および電子的または物理的な商品またはサービスの購入を含むが、これらに限定されることはなく、ほとんどどのようなタイプであってもよい。
【００１１】
トランザクションサーバ１３０にアクセスして電子トランザクションを実行する前に、ユーザは第一に自分自身をアクセス制御サーバ１２０に認証させる必要がある。発明の背景で述べたように、ユーザは一般に、アクセス制御サーバ１２０によって送信されたチャレンジで暗号操作を実施するために、自分の秘密鍵を使用することによって、自分自身を認証させる。この暗号操作は、単純な暗号化、暗号化の前のハッシュ（一般にデジタル署名と呼ばれる）、または当分野の技術者に周知の他のプロトコルであってよい。もちろん、セキュリティの低い適用分野では、認証信用証明は単純なパスワードであってよい。秘密鍵、パスワード、および他の認証信用証明は、当分野の技術者によく知られたものであり、ここで詳細に説明する必要はないであろう。読者は詳細について、たとえばＡｐｐｌｉｅｄ  Ｃｒｙｐｔｏｇｒａｐｈｙ（１９９６年に出版されたＢｒｕｃｅ  Ｓｃｈｎｅｉｅｒ、第２版の１０１頁〜１１２頁および５４８頁〜５４９頁）などの、よく知られた標準的なテキストを参照するとよい。
【００１２】
認証信用証明またはプロトコルが何であれ、アクセス制御サーバ１２０がユーザを認証すると、次いでユーザは、トランザクションサーバ１４０にアクセスすることができる。本発明は、多種多彩なブラウザ１４０からサーバ１１０、１２０、および／または１３０にアクセスしようとするユーザ（いわゆる「ローミング中のユーザ」）に、認証信用証明をオンデマンドで提供するための方法および装置を提供するものである。
【００１３】
オンデマンドのローミング機能は、ソフトウェアウォレット１５０を介してブラウザ１４０にいるユーザに認証信用証明（たとえば秘密鍵）のダウンロードを行う信用証明サーバ１６０によって提供される。本明細書で使用される場合、ウォレット１５０は、認証信用証明の基本コンテナとして働くだけでよい。したがって、単に認証信用証明が実施されたデータ構造であるとみなすことができるか、またはデジタル証明または（電子キャッシュまたは仮証券（ｓｃｒｉｐ）を含むがこれらに限定されない）デジタル通貨などの、ユーザが所有するその他のアイテムを処理する機能を有する、より精巧なコンテナである可能性がある。本発明の基本的な実施形態では、信用証明サーバ１６０がＷｅｂサーバとして実施される。ユーザは、自分のブラウザ１４０を信用証明サーバに向かわせ、セットアップ段階で以前にユーザに関連付けられていた共有秘密の形式で、ユーザにチャレンジを送信する。この共有秘密は、以下の例示的な形式のいずれかであってよい。
【００１４】
質問：母親の旧姓は何か。            答え：Ｊｏｎｅｓ
質問：犬の名前は何か。              答え：Ｌｕｃｋｙ
質問：好きなスポーツは何か。        答え：フットボール
質問：ＰＩＮは何か。                答え：ＰＩＮ
【００１５】
実際の質問数は、それぞれの信用証明サーバのセキュリティ方針によって要求されるように、信用証明サーバ間で異なってもよい。ユーザが正しい回答を提供すると、信用証明サーバ１６０は、ウォレットデータベース１７０（信用証明サーバ１６０の一部であっても一部でなくてもよい）からユーザのウォレットを取得し、そのウォレットをブラウザ１４０にいるユーザに提供する。代替の実施形態では、ウォレットまたはその一部が、サーバ１１０、１２０、および１３０のいずれかに直接提供されることがある。
【００１６】
前述のいずれの場合も、ウォレットは、
１）ソフトウェアプログラムのメモリスペース内にインストールし、さらに／あるいはその後、
２）コンピュータのハードドライブまたは他の物理的メモリ上にインストールすることができる。前者のみの場合、認証信用証明は、セッションが終了すると破棄される。後者の場合、認証信用証明は、その特定のコンピュータ上で、複数のセッションにまたがって使用することが可能である。どちらの場合も、ユーザが他のコンピュータにローミングすると、このプロセスが繰り返され、（本発明が、所望であれば物理的トークンと共に使用されることも可能であっても）物理的トークンの要件なしに、必要とされる認証信用証明へのオンデマンドアクセスを提供することができる。
【００１７】
前述の内容は、いわゆる共有秘密の使用法を例示したものであり、これによってユーザおよびサーバの双方が、システムのアクセスに必要な情報のコピーを共有する。もちろん、本発明は、それ自体の性質上、不正なサーバによる悪用の対象となる、こうした単純なプロトコルに限定されるものではない。たとえば、ゼロ知識証明（ｚｅｒｏ  ｋｎｏｗｌｅｄｇｅ  ｐｒｏｏｆ）という、ユーザが自分の母親の旧姓（または他の秘密情報）を知っていることを、実際にその名前をサーバに明らかにせずに、サーバに証明できる方法を使用することもできる。簡単な例として、検証子が秘密鍵を検証するために対応する公開鍵だけを知っていればよい場合には、ユーザの秘密鍵自体をこの様式で使用することができる。ゼロ知識証明の原理および実施は、当分野の技術者によく知られているため、本明細書で説明する必要はないであろう。読者は詳細について、前述のＡｐｐｌｉｅｄ  Ｃｒｙｐｔｏｇｒａｐｈｙなどのよく知られた標準的なテキストを参照するとよい。
【００１８】
本発明の一実施形態では、ウォレットは共有秘密によってそれ自体が保護されることがある。たとえば図２は、ウォレットの例示的な実施形態を示す図であって、秘密鍵はＰＩＮによって保護される。ＰＩＮ（より一般的には共有秘密）は、以前に論じたように、ユーザによって信用証明サーバに伝送される共有秘密の場合があり、ウォレット内の秘密鍵（より一般的には認証信用証明）は、信用証明サーバ１６０によって復号され、ブラウザ１４０にいるユーザに明文で提供される場合がある。あるいは、ユーザがブラウザ１４０でローカルに復号する場合、ウォレット全体（暗号化された形式の認証信用証明を含む）がユーザに提供される場合がある。どちらの方法でも、ＰＩＮで保護された認証信用証明を復号するプロセスは次のとおりである。ユーザがＰＩＮ  ２００（より一般的にはアクセスコード）を入力してウォレットのロックを解除すると、１対１ハッシュ関数２１０を介してＰＩＮが渡される。ハッシュ関数には、当分野の技術者であれば理解されるように、ソルト値（ｓａｌｔ  ｖａｌｕｅ）または他のセキュリティ強化機能が含まれることがある。入力されたＰＩＮのハッシュ値２１５が、正しいＰＩＮのハッシュ値である格納済みハッシュ値２２０と比較される。２つのハッシュ値が一致すると、ＰＩＮは復号モジュール２４０に渡される。（正しいＰＩＮで暗号鍵として）暗号化されフィールドに格納されている秘密鍵２３０が、復号モジュール２４０によって復号化され、これが典型的にはＤＥＳあるいは、たとえばトリプルＤＥＳ、ＩＤＥＡ、またはＢＬＯＷＦＩＳＨなどの何らかの他の暗号関数に該当する。したがって、復号された秘密鍵２５０が使用のために公開される。
【００１９】
ハッシュを計算して格納済みのハッシュを復号する暗号操作は、１つまたは複数の暗号論理（たとえばソフトウェアまたはハードウェア）モジュールを使用して実施することが可能であり、正しいハッシュ値および秘密鍵が、（たとえばＲＯＭ、コンピュータ読取り可能媒体などから読み取られた）保護されたデータフィールドまたは他のメモリ形式に格納される。典型的な鍵ウォレットには、ＰＩＮ候補を受け取り復号された秘密鍵を出力するための入力および出力論理、ならびに鍵および他のデータを管理、表示、コピーおよび処理するための論理が含まれる。
【００２０】
ハッシュ関数の１対１の性質により、正しいＰＩＮおよび正しいＰＩＮのみが鍵ウォレットのロックを確実に解除する。残念なことに、悪意のあるハッカーが、力ずくの検索を介して完全なＰＩＮを推測することもできる。たとえば、単に鍵ウォレット上にある６桁のＰＩＮコードをすべてチェックするだけのプログラムを作成することができる。鍵ウォレットのコピーを取得すると、自分のコンピュータで、まったく気付かれない自動的な方法で、ほぼ数分のうちにこの攻撃を実行することができる。
【００２１】
本発明の他の実施形態では、このＰＩＮハッシュ攻撃に対抗するために、暗号カモフラージュ（ｃｒｙｐｔｏｇｒａｐｈｉｃ  ｃａｍｏｕｆｌａｇｉｎｇ）と呼ばれる技法を使用して、認証信用証明に関連してさらに強力なセキュリティを提供する。暗号カモフラージュについては、図３に関して以下に要約形式で述べるが、詳細について読者は、本明細書に参照により組み込まれた同時係属中の米国特許出願第０８／９９６７５８号を参照するとよい。
【００２２】
ここで図３を参照すると、図２の場合と同様に、認証信用証明（たとえば秘密鍵）がアクセスコードを介して保護される。ただし、１対１ハッシュは、多対１ハッシュ、すなわち多数の入力が同一のハッシュされた出力を生成する（すなわち再生成する）ハッシュに置き換えられる。例示的な実施では、多対１ハッシュ関数３１０が６桁のコードを２桁のハッシュ値にハッシュすることができる。従来の鍵ウォレットの場合と同様に、入力されたＰＩＮ３００のハッシュ値３１５が、正しいＰＩＮのハッシュ値である格納済みのハッシュ値３２０と比較される。２つのハッシュ値が一致すると、鍵ウォレットが開く。秘密鍵は再度暗号化され、正しいＰＩＮを暗号鍵として、鍵ウォレットのフィールド３３０に格納される。正しいＰＩＮが入力されると格納済みの暗号鍵が復号され、正しい秘密鍵３５０が使用のために公開される。ただし、ハッシュ関数は多対１であることから、入力される様々なＰＩＮの中には、鍵ウォレットを開こうとするハッシュチャレンジを満たすようなものが多数ある。（正しいＰＩＮを含み、正しいＰＩＮと同じハッシュ値にハッシュするＰＩＮのことを、本明細書では擬似有効ＰＩＮと呼ぶ。）たとえば、ハッシュ関数が６桁のコードを２桁のハッシュ値にハッシュする場合、可能な６桁のコード合計１，０００，０００のうち、鍵ウォレットを開かせるような６桁の擬似有効ＰＩＮは１０，０００となる。擬似有効ＰＩＮはすべて復号モジュール３４０に渡され、格納済み暗号化鍵を復号して秘密鍵候補を生成する。ただし、これらの秘密鍵候補のうち１つを除くすべてが、格納済み（正しい）秘密鍵の不正な復号である。入力されたＰＩＮが正しいＰＩＮである場合のみ、正しい秘密鍵が回復されることになる。
【００２３】
上記の多対１ハッシュ関数が優れたハッシュとして選択されるはずであることが好ましい。たとえば、また無制限に、ＭＤ５およびＳＨＡはよく知られている優れたハッシュ関数である。優れたハッシュ関数とは、すべての可能なＰＩＮスペース内にほぼ均一に擬似有効ＰＩＮを分散させる手段である。たとえば、６桁のコードから２桁のハッシュ値へのハッシュ関数を考えてみる。１，０００，０００の可能な入力値の中で１０，０００が擬似有効ＰＩＮとなる。ハッシュ関数が優れたハッシュであれば、これらの値はほぼ均一に分散される。具体的には、１００のＰＩＮのうち１つが擬似有効であり、これらが効果的かつランダムに分散される。具体的に言うと、ユーザが正しいＰＩＮを入力する際に誤植した場合に結果として生じるＰＩＮが擬似有効ＰＩＮとなる可能性は、１／１００である。
【００２４】
他の可能な実施形態では、劣ったハッシュ、すなわち擬似有効ＰＩＮのクラスタを発生させるハッシュを使用し、これは、１つの擬似有効ＰＩＮを推測する侵入者であればその他のＰＩＮを簡単に見つけるものである。一連の１桁の誤植をしている正当なユーザは、一連の擬似有効ＰＩＮも取得し、秘密鍵またはそれによって暗号化されたメッセージを受け入れるシステムが、失敗反復時警告または使用不能化機能を有する場合、偶然に正当なユーザを締め出してしまうことがある。したがって、劣ったハッシュは典型的には、優れたハッシュに比べて嫌われる。にもかかわらず、劣ったハッシュが、特殊な応用例に有利な計算上の効率の良さおよび実施の容易さなど、一定の特徴を提供する応用例がいくつかある。
【００２５】
前述の内容では、１対１または多対１のハッシュを使用して、さらにウォレットを保護するための技法について説明した。当分野の技術者であれば、復号プロセス２００〜２５０および３００〜３５０（たとえば暗号カモフラージュ解除）が、ユーザのコンピュータ側または信用証明サーバ１６０側のどちらでも実行できることを理解されよう。前者の場合、ウォレットは復号済み形式でユーザにダウンロードされ、後者の場合、ウォレットはユーザにダウンロードされる前に信用証明サーバ１６０側で復号される。
【００２６】
さらに一般的には、これまでに述べた様々なチャレンジ応答プロトコル（たとえば、単純な共有秘密、指紋認識などの生物測定学を応用した方法、図２の１対１ハッシュされた秘密、および図３の多対１ハッシュされた秘密）が、信用証明サーバ１６０側またはブラウザ側１４０のどちらでも使用可能であること、およびこのような使用法がどのような組み合わせまたは置き換えでも発生可能であることも理解されよう。たとえば、セキュリティレベルが最低限であっても、単純な共有秘密で信用証明サーバ１６０にアクセス可能であり、ウォレットを明文でユーザにダウンロードすることができる。あるいはウォレットは、１対１または多対１で（たとえば暗号カモフラージュされた）ハッシュされた共有秘密によってさらに保護することが可能であり、さらにユーザが適切なチャレンジ応答プロトコルに応答するのに応答して、信用証明サーバ側で復号することが可能である。復号された（すなわち多対１ハッシュの場合、カモフラージュ解除された）ウォレットは、その後、明文でユーザにダウンロードされる。セキュリティレベルが高い場合、ウォレットはカモフラージュ形式でユーザにダウンロードすることが可能であり、ユーザ側のコンピュータでカモフラージュ解除される。さらにセキュリティレベルが高い場合、初期のサーバアクセスで、単純な共有秘密を１対１または多対１のハッシュプロセスに置き換えることができる。次いで一般に、１対１ハッシュまたは多対１ハッシュを初期のサーバアクセス段階で展開し、単純な共有秘密、１対１ハッシュ、多対１ハッシュのうち任意の技法を、後続のウォレットダウンロード段階で使用することができる。したがって、当分野の技術者であればこれらの形態および他の変形形態について理解されるように、本発明の範囲は、本明細書で開示された特定の実施形態に限定されるものではなく、付属の特許請求の範囲に記載されているすべての範囲により判断されるものである。
【図面の簡単な説明】
【図１】  アクセス制御サーバによって保護されたトランザクションサーバにより電子トランザクションを実行するために、ユーザがＷｅｂサーバにアクセスする、本発明の例示的な実施形態を示す図である。
【図２】  秘密鍵がＰＩＮによって保護されたウォレットの例示的な実施形態を示す図である。
【図３】  図２のウォレットが暗号法カモフラージュ形式によって保護された例示的な実施形態を示す図である。
【図１】
0004612951.tif 000002
【図２】
0004612951.tif 000003
【図３】
0004612951.tif 000004