JP2008511232A - 制御認証のためのパーソナルトークンおよび方法 - Google Patents

Abstract

本発明はネットワーク内の認証のためのパーソナルトークン１０に関し、前記トークンを認証するメッセージを生成することによって遠隔サーバ３０とのＳＳＬ接続を開始する１つのソフトウェアを含み、この１つのソフトウェアは、トークン１０内に事前に記憶される、遠隔サーバ３０に特に関連するデータ１２を用いるようにメッセージの処理を管理し、その結果、メッセージは特定の遠隔サーバ３０によってだけ解釈されることが可能であることを特徴とする。

Description

本発明はインターネットなどの公衆網上のセキュリティ、より一般にはユーザの認証のためにスマートカードなどのパーソナルトークンを用いる際の任意のネットワーク上のセキュリティに関する。

ネットワーク内でスマートカードを維持するユーザを認証するために多くのプロトコルが提案されている。

現在のＳＳＬ（セキュアソケットレイヤ）強力認証はスマートカードおよび証明書に基づき、スマートカードの証明書に署名した認証局に連絡する必要性なしに日常的に認証用に用いられている。

しかし、認証局との連絡がそのように不要なために、かかる方式に１つの問題が生じる。

確かに、スマートカード発行機関は、サービスプロバイダがスマートカードの認証を実行する前に同意を求められることがないようである。すなわち、スマートカードによる認証処理は、スマートカード発行機関と商業的な契約を結んでいない任意のサービスプロバイダを含む、任意のサービスプロバイダにとって利益である。したがって、スマートカード発行機関の競争相手を含む任意の事業体にとって、スマートカードは一般に利益のある認証ツールになる。

これは、公開鍵基盤（Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）（ＰＫＩ）暗号技術を用いる標準ＳＳＬによる場合である。任意のサーバは、スマートカードＰＫＩを用いてクライアントに自らを認証するように要求することができると同時に、スマートカードは秘密鍵と関連する証明書とを含み、任意のサーバはユーザ証明書を受信でき、それによりユーザ署名の妥当性を確認することができる。

本発明の目的は、大抵のサーバ上のソフトウェア内およびハードウェア内で現在利用可能な標準ＳＳＬ構成に依然として依存しながら、スマートカード発行機関がそのスマートカードに関して行われる各認証を管理することを可能にすることである。

この目的は、添付の特許請求の範囲に列挙されるように、パーソナルトークン、典型的にはスマートカードにより実現される。そのようなトークンを含むアセンブリおよび認証方法は、共に同じ主要目的を対象とする特許請求の範囲にも列挙されている。

本発明に関する別の利点、目的および特徴は、添付の図を参照して行われる以下の詳細な説明を通じて議論される。

以下の例で、遠隔ＳＳＬサーバはＩＤＰと呼ばれ、それにより、インターネットＤ．．．プロバイダを指す。

この例は、自らのＰＣ（パーソナルコンピュータ）２０を経由してインターネット上でスマートカード１０を用いるユーザを認証するために用いられるＳＳＬリンクに関する。認証データを含むＵＳＢトークンすなわち大容量メモリトークンのような、ポータブルトークンとも呼ばれる任意のその他の種類のパーソナルトークンが、そのようなスマートカードに取って代わってもよい。

ＳＳＬクライアントのようにスマートカードによる認証は以下のように実行される。

エンドユーザのＰＣは、典型的には、ＩＴサーバ３０を経由して遠隔ベースのウェブサイトにアクセスするためにトリガされるウェブブラウザ２１を埋め込む。スマートカード内に埋め込まれたブラウザは、ウェブサイトにアクセスするために同様に用いられることが可能である。

そのようなウェブサイトは典型的にはログインを必要とし、ユーザすなわちスマートカード１０は典型的にはログインリンクを選択する。

ＰＣ２０は現在、ＩＤＰサーバ専用のプロキシ２２を備える。そのようなプロキシ２２はここではＩＤＰプロキシと呼ばれる。

この例では、クライアント側のＳＳＬ接続はＰＣブラウザ２１によってではなく、その独自の内蔵式であるが標準のＳＳＬレイヤを用いてＩＤＰプロキシ２２によって実行される。

したがって、ログインリンクを選択することにより、ＰＣ２０およびそのブラウザ２１は、クライアントＰＣ上のＩＤＰプロキシ２２にリダイレクトされる。

次いで、ＩＰＤプロキシ２２はＩＤＰサーバ３０とのＳＳＬ接続を開放する。このＳＳＬ接続はカード１０によって保護される。

ＳＳＬ接続はカード証明書１１を用いる。カード証明書１１が有効なドングル認証であり、証明書失効リスト（Ｃｅｒｔｉｆｉｃａｔｅ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ）内にない場合、ＳＳＬ接続は成功する。

ＩＤＰプロキシ２２は、知られているプロトコルＭＳ−ＣＡＰＩおよびＰＫＣＳ＃１１から独立していることが好ましいＳＳＬの内蔵式実装を有する。これらの知られているプロトコルは認証証明書１１をカード１０から取り出し、ＰＣ２０のメモリ内に記憶するために用いる。ＰＣ２０内に転送される際にカード証明書１１を用いて強力認証を提供するために用いるインターネットエクスプローラ（登録商標）またはネットスケープ（登録商標）のＳＳＬ内蔵式クライアントの場合も同じことが述べられてよい。

そのような異なるプロトコルを用いることによって、この方法はカード１０の外のレジストリまたはファイル内に証明書を記憶することを防ぎ、それにより、第三者はＰＣ２０への証明書の予備的転送を介してカードを用いて強力認証を実行することができない。

ＳＳＬ接続が成功する場合、ＩＤＰサーバ３０は証明書１１内に含まれるドングルＩＤからエンドユーザの識別性を調べ、次いで、ＩＤＰサーバ３０はＳＡＭＬトークンをＩＤＰプロキシ２２に戻す。

次いで、ＩＤＰプロキシ２２はＳＡＭＬトークンによりブラウザ２１をサービスプロバイダサイトにリダイレクトする。

その後ずっと、ブラウザ２１は戻されたＳＡＭＬトークンにより保護されたサイトにアクセスすることができる。

以下に説明されるように、クライアントのＳＳＬ認証が実行された後で、ＳＳＬ接続が成功する。

以下の構成のおかげで、かかるＳＳＬ接続は特定のＩＤＰサーバ３０と排他的に折衝されることが可能である。

この排他性は、製造工程の間、先のステップ（例えば、スマートカードの個人化ステップ）で、カード１０内に記憶されているＩＤＰサーバ３０の公開鍵を用いることによって、またはカードメモリの無線（Ｏｖｅｒ−Ｔｈｅ−Ａｉｒ）更新によってさえも確実にされる。サーバ公開鍵は、現在、カード証明書１１と同じ方法でカード内に記憶されるサーバ証明書１２内に記憶されている。

以下に説明されるように、ＩＤＰサーバの秘密鍵または任意のその他のサーバ特定情報をカード１０内に記憶することは、任意の第三者サーバがスマートカードにより非合意のＳＳＬ接続を開始する可能性を防ぐことを可能にする。

ＳＳＬ接続がＩＤＰプロキシ２２とＩＤＰサーバ３０との間で開始されるべき段階で、ＳＳＬハンドシェークが生じ、その間、サーバ署名を確認するためにサーバハロー（ｓｅｒｖｅｒ−ｈｅｌｌｏ）メッセージからサーバ証明書１２が用いられる。これは標準ＳＳＬ実装に関係する。

サーバ検証を実施するために、カード１０は指紋すなわち信頼性のある認証符号要素としてサーバ証明書１２を含み、ＩＤＰプロキシは記憶された指紋１２に基づきサーバ証明書を確認するようカードに要求する。

カード１０内でＩＤＰサーバ３０の識別性が確認されると、クライアント鍵交換（ＣｌｉｅｎｔＫｅｙＥｘｃｈａｎｇｅ）メッセージがカード内で生成される。

好ましい例として、ＩＤＰサーバのＩＤＰ公開鍵はカード１０内に記憶され、クライアント鍵交換メッセージを生成するために用いられる。

このために、カード１０は、ＩＤＰ依存データに基づくデータの署名処理（すなわち、この例ではサーバ３０の公開鍵）によりデータの通常のハッシュ処理手続きを完了する。

それにより、特に所与のＩＤＰサーバ３０専用の強力認証は、カード内にサーバの公開鍵を事前に記憶することによって、かつＩＤＰサーバの事前記憶された公開鍵によりカード内でＳＳＬハッシュ暗号化の最終段階を実行することによって確実にされる。

しかし、サーバ特定署名を実行するそのような最終段階は、クライアント署名（証明書検証（ＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙ）メッセージ）を実行する前に行われることが好ましい。

ＩＤＰ依存データによるクライアント鍵交換メッセージの署名は、２つの主な利点をもたらす。

ＳＳＬ接続は、クライアント鍵交換メッセージの内容を解釈するためにサーバ３０内にそのようなＩＤＰサーバ依存データが必要である限り、やはりそれらのデータを含む特定ＩＤＰサーバ３０とだけ成功することが可能である。

したがって、カードの公開鍵は特定ＩＤＰサーバとのＳＳＬ接続を実行する以外の任意のその他の目的で用いられることはできない。

メッセージの署名を実行する場合、カード１０は、所望のＩＤＰサーバ専用であり、サーバ公開鍵に関連するＳＳＬプロトコルの一部を実現する。これは、カード署名は所望のサーバ３０に関しては有効であることになるが、正しいサーバ秘密鍵を所有しないその他のサーバに関しては有効でないことを意味する。したがって、そのようなカード１０は無許可の環境では用いられることができない。

あるいは、用いられたＩＤＰ依存データはメッセージの一部またはメッセージを解釈するために知る必要のあるメッセージの暗号化ツールを構成する。

サーバ３０の公開鍵は、ＳＳＬ鍵素材（ｋｅｙ ｍａｔｅｒｉａｌｓ）をサーバ３０に運ぶことになる固有鍵であることが好ましい。

実際には、ＩＤＰサーバは、ＳＳＬ接続の間にカード証明書１２を受信するとすぐ、ＣＲＬ（証明書失効リスト）内の証明書の妥当性を検証し、そのような証明書１２内に含まれるカードｉｄから識別性調査を実行する。

証明書１２が有効である場合、先に説明されたように、ＳＳＬ接続はＳＡＭＬトークンをＩＤＰプロキシに返送するために用いられることが可能であり、次いで、ＩＤＰプロキシはブラウザ２１をサービスプロバイダサイトにリダイレクトし、それにより、ＳＡＭＬトークンによりサービスプロバイダ４０に接続するようＰＣブラウザ２１に求める。

サービスプロバイダのサイトはＩＤＰサーバ３０によりＳＡＭＬトークンの妥当性をアサートし、成功する場合、サービスプロバイダは、クライアント証明書なしに、ＰＣのブラウザによりＳＳＬ接続を開始する。

サービスプロバイダ４０はプロキシ２１に接続された同じＩＤＰサーバ３０内でホストされてよく、または別の遠隔サーバ内でホストされてもよい。

強力認証は許可されたＳＳＬサーバとだけ実行されることが可能であるが、認証は依然として主に標準ＳＳＬ認証である。

サーバ公開鍵は、カード１０内に記憶される鍵であり、ＳＳＬサーバハローメッセージの間（すなわち、認証処理の開始前）にサーバ３０によって伝送されることが可能な鍵でないことが好ましい。これは第三者サーバがＩＤＰプロキシによりＳＳＬ接続を開始し、カードを用いて強力認証を実行するのを防ぐ。

さらに、この特定の実施例では、ソフトウェアまたはハードウェアのサーバ側に重要な手続きを必要としない標準ＳＳＬプロトコルが用いられているという事実により、ＳＳＬクライアントはクライアント証明書およびサーバ証明書により標準ＳＳＬプロトコルを実現し、大抵のサーバのソフトウェアおよびハードウェアの構成要素によって主にシェルフ（ｓｈｅｌｆ）上で支援される。

この説明はスマートカードに関して行われている。しかし本発明は、ＵＳＢスティックまたは大容量メモリカードなど、個人認証のための別の種類のポータブルトークンにも関係する。

本発明による認証構成のアーキテクチャを示す図である。 本発明による認証処理を示す図である。

Claims (9)

1. トークンを遠隔サーバ（３０）に認証するメッセージを生成することによってＳＳＬ接続を開始する１つのソフトウェアを含む、ネットワーク内の認証のためのパーソナルトークン（１０）であって、この１つのソフトウェアが、トークン（１０）内に事前に記憶される、遠隔サーバ（３０）に特に関連するデータ（１２）を用いるようにメッセージの処理を管理し、その結果、メッセージが特定の遠隔サーバ（３０）によってだけ解釈されることが可能であることを特徴とする、パーソナルトークン（１０）。
2. アセンブリがトークン（１０）の遠隔サーバ（３０）への認証メッセージを生成することによってＳＳＬ接続を開始する１つのソフトウェアを含む、パーソナルトークン（１０）および前記パーソナルトークン（１０）をホストする電気通信端末（２０）を含むアセンブリであって、トークン（１０）が遠隔サーバ（３０）に特に関連するデータ（１２）を記憶し、１つのソフトウェアが前記データ（１２）により前記メッセージの署名を処理し、その結果、特定の遠隔サーバ（３０）だけが認証メッセージを解釈できることを特徴とする、アセンブリ。
3. サーバに特に関連するデータがサーバ（３０）の公開鍵であることを特徴とする、請求項２に記載のアセンブリ。
4. １つのソフトウェアがトークン（１０）内に埋め込まれることを特徴とする、請求項２に記載のアセンブリ。
5. ホスティング端末（２０）がプロキシ（２２）を含むことを特徴とする、請求項２に記載のアセンブリ。
6. アセンブリがプロキシ（２２）と遠隔サーバ（３０）との間にＳＳＬ接続を設定する１つのソフトウェアを含むことを特徴とする、請求項５に記載のアセンブリ。
7. パーソナルトークンを用いるネットワーク内の認証方法であって、
   ａ）パーソナルトークン（１０）を遠隔サーバ（３０）に認証するメッセージを生成することによってＳＳＬ接続を開始するために１つのソフトウェアを埋め込む前記トークン（１０）を提供するステップと、
   ｂ）トークン（１０）内に事前に記憶される、遠隔サーバ（３０）に特に関連するデータを用いるために前記１つのソフトウェアによりメッセージの処理を管理し、それにより、特定の遠隔サーバ（３０）によってだけ解釈されることが可能なメッセージを生成するステップ
   とを含む、方法。
8. 前記方法が、前記パーソナルトークン（１０）のためにホスティング端末（２０）を用い、ホスティング端末（２０）がプロキシ（２２）を含み、トークン（１０）によって生成された認証メッセージを用いることによってプロキシ（２２）と遠隔サーバ（３０）との間にＳＳＬ接続を設定するステップを含むことを特徴とする、請求項７に記載の方法。
9. ＳＳＬ接続がプロキシ（２２）と遠隔サーバ（３０）との間に設定されると、通信接続をブラウザ（２１）とサービス遠隔サーバ（３０）との間に設定するステップを含むことを特徴とする、請求項８に記載の方法。

Images