JP2002501218A

JP2002501218A - 短寿命証明書によるクライアント側公開鍵認証方法とその装置

Info

Publication number: JP2002501218A
Application number: JP2000528045A
Authority: JP
Inventors: ハー，マシユー; メドビンスキー，ゲナデイ; コバラ，ジヨセフ，エヌ．
Original assignee: サイバーセイフコーポレイシヨン
Priority date: 1998-01-09
Filing date: 1999-01-06
Publication date: 2002-01-15
Also published as: AU2452699A; KR20010033972A; EP1042885A1; WO1999035783A1; CA2313328A1

Abstract

(57)【要約】【課題】短寿命証明書を供給するためのシステムを効率的に実行させる能力を持つ認証システムを提供すること。【解決手段】鍵配布センター（ＫＤＣ）は公開-秘密鍵ペアーと証明書テンプレートを生成し格納する。ユーザーはＫＤＣ中に格納されている公開-秘密鍵ペア−を割り当てられる。ＫＤＣに対して認証を求めるユーザーは（たとえば、カーベロスシステムによるパスワードを用いて）、システムに対して短寿命証明書を生成、署名することによってユーザーの公開鍵を再証明することを促す。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】

本発明は公開鍵認証（オーセンティケーション）システム、特にクライアント
側公開鍵の認証の実行を可能とするシステムに関する。

【０００２】

【発明が解決しようとする課題】

初期の情報セキュリティーシステムの１つは、秘密確保のための暗号の開発、
ならびに暗号化と復号化が主な問題であった。最近特に、エレクトロニクス通信
とコンピューターベースの情報システムでは、情報セキュリティーシステムが認
証（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ）（メッセージが真に表記されている発信元
からのものかどうかを確認する）とか権限付与（Ａｕｔｈｏｒｉｚａｔｉｏｎ）
（ハードウエア、ソフトウエア、またはデータへの認可のない使用者のアクセス
の防止）など、秘密確保以外の目的にも使われるようになってきている。

【０００３】本発明は、情報セキュリティーの多くの分野に適用できるであろうし、また、
多くの分野に関連しているが、その最も直接的な応用は、クライアント側の公開
鍵の認証についてである。典型的には、認証が生起した後、認証がアクセス制御
の決定を行うなど、認証はその後の決定についての基礎を形成するものである。

【０００４】多くのセキュリティーシステムは基本的には、データの暗号化システムに関係
している。データを暗号化し、また復号化するシステムが発展してきて、多くの
工夫がこらされた方式が出てきたが、情報のプライバシーと暗号化の間には密接
な関係があることは明らかである。暗号化は、種々のやりかたで身元確認と認証
に関係を持たせることができる。

【０００５】暗号化されたメッセージの受信者が、暗号化に使われた鍵を持っているのは一
人の人だけだということを確信できるなら、復号化が無事行われたということだ
けで身元確認とまたある程度の認証を達成したことになる、という場合が、最も
明瞭な場合である。認証の目的のために暗号化を使えば、資源（リソース）の管
理を、アクセス要求者の認証によって行うことができるので、アクセス制御に役
立つことは明らかである。

【０００６】パスワードにもとづく認証システムでは、パスワードの権限のない者への漏洩
を防ぐのに、（パスワードを送信したり格納したりする前に暗号化したり、対称
鍵に変換したり、また、ユーザー認証用の暗号化ベースのプロトコルに使うなど
して）暗号化を使うことができる。

【０００７】暗号化システムは、それ以外のシステムもあるが、しばしば秘密鍵（「対称鍵
」）のシステムと公開鍵（「非対称鍵」）のシステム（時としてこれらは、公開
鍵プライベート鍵のシステムとも呼ばれる）に分類される。典型的な秘密鍵シス
テムまたは対称鍵システムでは、暗号化と復号化の両方に同じ鍵が使われる。こ
のシステムでは、たとえば、権限を持つ人（複数）だけが鍵の内容を知っている
か、あるいは秘密鍵を分け持つか、などして鍵の秘密を保つことが重要である。

【０００８】したがって、この秘密鍵システムの１つの困難な点は、秘密を保持することで
ある。もうひとつの困難な点は鍵の複製である。もし当事者が２人あるいは２人
以上の人と通信を希望するが、その通信に全ての関係者をアクセスさせることを
必ずしも希望しない場合、一般的には、各１対の当事者間ごとに1種類の鍵を共有することが必要になる。このような鍵を管理し配布することは、大きな組織で
はかさばってしまって扱いにくいものとなる。

【０００９】それについての１つの解決法は信頼できる第三者機関（ＴＴＰ（Ｔｒｕｓｔｅ
ｄＴｈｉｒｄＰａｒｔｙ））を設立することである。ＴＴＰを設立すれば、
各当事者は当事者とＴＴＰとの間の鍵を１個持つだけでよく、ＴＴＰがどのよう
な個別の通信のチャンネルの確立に対しても仲介の役を果たしてくれるものであ
る。このシステムは、多くの目的に有用であるが、ＴＴＰ自体のセキュリティー
を如何にして確保するかということとホストの鍵の秘密を保持する点に困難性が
ある。

【００１０】ある程度の成功を収めたＴＴＰの実施例として、一般的にカーベロスとして知られている以下に詳しく述べるものがある。ここで用いている「カーベロス型
のシステム（kerberos like system）」という語は一般に、カーベロス、すな
わち、ユーザーとサービスとの間で対称鍵を分け持たせる信頼できる第三者機関
のことを指している。カーベロス型システムは多くの状況下で非常に有用である
ことがわかっているが、従来のカーベロス型システムは、典型的には、公開鍵シ
ステムに伴う利点（たとえばディジタル署名のような）を提供するようにはつく
られていないと考えられている。

【００１１】公開鍵（ＰＫ，ＰｕｂｌｉｃＫｅｙ）システムでは、情報を保護するために
２個の相対応する鍵（非対称鍵）が使われる。２個の鍵のうちの１個の鍵で暗号
化された情報はもう１つの鍵でしか復号化することができない。ある公開鍵シス
テムでは、２個の鍵の何れかが暗号化に使われ、もう１つの鍵が復号化に使われ
る。また他のシステムでは、１個の鍵が暗号化にだけ使われ、もう１つの鍵は復
号化にだけ使われる。

【００１２】公開鍵システムの１つの重要な特徴は、２個の鍵のうちの１個の鍵の知識を使
ってもう１つの鍵の内容を計算によって知ることはできないということである。
典型的には公開鍵システムでは、システムの各ユーザーは１（ひと）組の２個の
このような鍵を持っている。１つの鍵は秘密を保っており、もう１つの鍵は自由
に公開されている。もし送信者が受信者の公開鍵でメッセージを暗号化したなら
ば、送信者によって意図された受信者だけがそのメッセージを復号化できる（な
ぜなら、その受信者だけが、公表された公開鍵に対応する秘密鍵を所持している
からである）。

【００１３】もし送信者が上の暗号化の実行に先立ってメッセージの初回の暗号化を送信者
の秘密鍵を用いて実行し、（受信者の秘密鍵を用いて）受信者は初回の復号化を
行い、さらにその結果を（送信者の公開鍵を用いて）復号化したならば、秘匿性
のみならず認証も保証されたことになる；何故ならば、送信者だけが、送信者の
公開鍵で成功裡に複号化できるようなメッセージを暗号化できるからである。

【００１４】ある１つのディジタル署名方式では、１方向ハッシュ関数がまずメッセージに
適用され、メッセージのハッシュが送信者の秘密鍵によって暗号化される。このシナリオでは、受信者がメッセージの発信元について持つ信頼の程度は、
送信者の公開鍵が送信者だけによって保持されている秘密鍵に対応しているはず
だということ対する受信者の信頼の程度に依存している。多くの現行のシステム
においては、一般に、この種の信頼度を提供するために、多くの信頼度の高い証
明機関が設立されてきた。

【００１５】現在最も広く使われているシステムでは、それらの機関が公開鍵の証明書を発
行している。最も広く使われている証明書の標準（国際標準機構（ＩＳＯ，Inte
rnational Standard Organization）と国際電信電話諮問委員会（ＣＣＩＴＴ，C
omite Consuktatif Internationale Telegraphique et Telephonique によって決められた標準Ｘ.５０９）のもとでは、証明書は公開鍵、公開鍵の所持者の名
前あるいは公開鍵に関係する者の名前、その他、例えば有効期間などの情報を含
んでおり、それらが信頼できる関係者によってディジタル的（したがって、暗号
化または他の変形された形で）に署名されている。

【００１６】ディジタル署名は、たとえば、ディジタル署名標準（ＤＳＳ（Digital Signat
ure Standard））（エヌアイエスディ（National Institute of Standard and T
echnology）国家標準技術局）にもとづいて発行される。典型的には、ディジタル署名は１方向ハッシュをかけた後、さらに証明機関の秘密鍵で暗号化するステ
ップを含んでいる。このようなディジタル署名は、信頼できる機関の秘密鍵を用
いて発行され、それはまた、信頼できる関係機関によって署名されたいま１つの
信頼できる関係機関の証明書を用いて認証されというように、信頼できる機関の
多重の階層による証明によって認証されている。

【００１７】公開鍵システムは、インターネット上のブラウジングを含む多くの状況下で使
われているが、その経験によれば、公開鍵システムは、それ自身多くの問題点を
持っていることがわかってきた。ある程度受け入れ可能な程度のセキュリティー
を提供しようとすると、ユーザーが秘密を保持している鍵を記憶することはでき
なくなる（典型的には、１０２４ビットの２進数のような大きな数である）。そ
こで、実際には、それをどこかにしまわなければならず、そうすると、それは壊
れやすいものであり、セキュリティーに対しても防備が薄くり、また、多くのシ
ステムでは、特殊なハードウエアを必要とすることになる（たとえば、スマート
カードとか、場合によっては、特別のコンピューターが必要となる）。

【００１８】従来システムの１つでは、スマートカードが認証システムの一部をなしている
。多くのスマートカードシステムと用法は既知である。たとえば、セキュア・ソ
ケット・レイヤー（ＳＳＬ:Secure Socket Layer）プロトコルはクライアントに
適用する際、あるサービスとの通信を確立するのにディジタル署名を要求する。
ある種の環境下では、スマートカードがこのようなディジタル署名に使われる情
報を持っており、それによってユーザーは、これに適するスマートカードを持っ
ておれば（例えば、鍵を覚えていなくても）、このような資源にアクセスするこ
とができる。公開鍵と秘密鍵の対を使うところの、これ以外のスマートカード認
証の手順も既知である。

【００１９】現在用いられているプリンシプル・スマートカード・インターフェースはＰＫＣ＃１１（公開鍵暗号標準、ＲＳＡデータセキュリティー・インク）とＰＣ/ＳＣ（パーソナルコンピューター/スマートカード）である。

【００２０】上に述べたような証明書は典型的には、有効期間つきで提供されている。この
ような有効期間は、現在のシステムでは、通常、発行から１年または１年以上の
単位で、比較的その寿命が長い。公開鍵システムが魅力的であると考えられてい
る特徴の１つはその使用が容易なことであるから、もしユーザーが頻繁に鍵のペ
アーを受け取って、新しい公開鍵をその都度公示しなけらばならないとすれば、
このような特徴は大いに損なわれることになる。しかし、場合によっては、以前
に発行された証明書を取り消すことが必要となる。

【００２１】たとえば、会社の高度な情報への従業員のアクセスを制御するのに使われる一
対の公開鍵は、その従業員がその会社を退職したとき取り消されなければならな
い。したがって、従来の公開鍵システムの信頼度は、普通、証明書取り消しリス
ト（ＣＲＬ, Certificate Revocation List）に対して証明書をチェックすることに頼っていることになる。Ｘ.５０９標準はＣＲＬ表示の１つの例を示している。しかし、不幸なことには、このことは、例えば、イントラネットあるいは
インターネットの広がりの配布を必要とし、さらに付加的なチェックまたは比較
のステップを必要とする。これらは、比較的大きな企業とかネットワークでは大
きな負担となり、システムが維持できなくなる。

【００２２】公開鍵システムに伴うもうひとつの難点は秘密鍵の配布と管理である。例えば
、ある会社が新しく従業員（複数）を雇用したとする。そのある従業員（複数）
には公開鍵-秘密鍵のペア−を配布しようとするが、このようなやり方で秘密鍵を配布することは、秘密鍵が部外者に漏らされることを防止する上で問題がある
。秘密鍵が目的通りに使われていれば従業員の秘密鍵の秘密は守られるだろうが
、それらの秘密鍵に会社が直接アクセスすることを必要とするかも知れない状況
（たとえば、現在退職してしまっている従業員によって過去に暗号化された会社
所有の情報を得ようとする場合のように、）が起こることがある。

【００２３】しかし、従業員の鍵を、例えば、未交付捺印証書（エスクロウ；従業員の鍵を
予め第三者に託しておき、従業員が退職したときに鍵の引渡しを受けるもの）と
して保管するのも、典型的には、大きな管理努力と費用を伴うだろう。

【００２４】したがって、公開鍵の技術が使えて、たとえば、ＣＲＬチェックシステムの荷
重（負担）を軽減または除去しながら、セキュリティーに関して妥協を許さずに
（たとえば、従来のシステム下で証明書を取り消されるところの退職者などのリ
ストを作成するなどして）、同時にコンピューターネットワークのセキュリティ
ーが維持できるシステムが提供できるならば、その価値は非常に大きい。

【００２５】また、秘密鍵の配布と管理に伴う努力と出費を軽減または除去できるシステム
を提供することも有用である。また、従来のシステムに付随していたハードウエ
ア依存性、および/または、セキュリティー・リスクを軽減または除去しつつ、秘密鍵保管の目標が達成できるような公開鍵システムを提供することも有用であ
る。

【００２６】それに加えて、現用のシステムの持つ特徴の利点を生かして、そのような特徴
を実行するための現行システムに対する開発、プログラミングおよび変更の総量
を最小にしながら、そのような改良された公開鍵システムを提供することは有用
なことである。

【００２７】

【発明の概要、課題を解決する手段、発明の効果】

本発明は短寿命の、すなわち、有効期間が１ヶ月以内、好ましくは、１週間以
内、より好ましくは１日以内、さらに好ましくは、１２時間以内、例えば、セッ
ションごとの認証または認定のごときセキュリティー目的のため公開鍵証明書（
ＰＫＣ, ＰｕｂｌｉｃＫｅｙＣｅｒｔｉｆｉｃａｔｅ）を自動的に生成するシステムを提供する。

【００２８】１つの実施例では、ユーザーが初回の認証システムを用いて認証を請求するご
とに（例えば、ユーザーがログオンして、自分自身の認証を行うごとに）、新規
の、しかし短寿命のＰＫＣが生成され、ユーザーに配送される。典型的には、公
開鍵は比較的頻繁に（たとえば、８時間ごと、１勤務日ごと、などなど）再発行
されるが、公開-秘密鍵ペアー自体には変更がなく、比較的長寿命（例えば、約１年あるいはそれ以上）である。そこで、上に述べた新規生成されたＰＫＣを、
ウエブページその他のような資源へのアクセスを制御してきたシステムを含む従
来システムでＰＫＣが使われていたのと同じやり方で、使うことができる。

【００２９】１つの実施例では、システムは短寿命ＰＫＣを配送するだけでなく、ＰＫＣの
公開鍵に対応する鍵も配送する。このことはユーザーを公開鍵保管の責任から解
放してくれるし、（希望とあれば、このようなハードウエア・ベースのシステム
を用いてもよいが）秘密鍵をしまっておく特別のハードウエアを使用しなければ
ならないという制約からユーザーを開放してくれる。

【００３０】ＰＫＣは短寿命なので、ＣＲＬ処理を必要とせずに（あるいはＣＲＬ処理の必
要性を減らしながら）比較的高い信頼性を達成することができる。

【００３１】例えば、退社した従業員の場合には、システムは、そのような従業員に対して
もはや（短寿命の）証明書の発行をも拒否するように構成されており、、それ以
前に有効であった既発行の証明書は期限切れとなるので、ＣＲＬについてのチェ
ックは不必要となる。

【００３２】１つの実施例では、秘密鍵と公開鍵の両方がアクセスを要求している人のコン
ピューターに返され、もし希望ならばアクセスを要求している人のコンピュータ
ー内でローカルにしまわれている秘密鍵と公開鍵が物理的なスマートカードの存
在をシミュレートするのに使われるという模擬スマートカードを実行することも
可能である。例えばＰＫＣＳ＃11（ＰＫＣＳ,ＰｕｂｌｉｃＫｅｙＣｒｙｐｔｏｇｒａｐｈｙＳｔａｎｄａｒｄ＃１１）インターフェースでは、シミュレーションは、たとえばＣ−ＳＩＧＮ、Ｃ−ＶＥＲＩＦＹのようなスマートＡＰＩ（
アプリケーションプログラミングインターフェース）コールを満たすような形を
とることができる。

【００３３】このようにして、本発明は、スマートカードのための比較的完成度の高いアプ
リケーションプログラミングインターフェース（ＡＰＩ）の利点を利用すること
ができ、それによって、公開鍵ベースのクライアント側認証を、実際のスマート
カードというハードウエアを必要とせずに（実際のスマートカードを取得して、
それを持ち歩くなどのことなく）、実行することができる。

【００３４】１つの実施例では、例えば、カーベロスシステムに似たＴＴＰシステムが短寿
命証明書生成システムとして使うように利用することができる。このようなシス
テムでは、パスワードベースで、（公開鍵を用いたインフラストラクチャーまた
はシステムを通して防御されている資源へのアクセスを容易にするような）公開
鍵システムの利点を用いて、種々のコンピューターからログオンするユーザー（
「移動ユーザー」）にも対応し、一方、公開鍵に伴う秘密鍵の配布ならびに保管
、ＣＲＬの維持、利用、秘密鍵の比較的低セキュリティー又は不便なやり方での
保管、などの前述の困難な点を回避しつつ、カーベロス型システムのもつ幾つか
の利点が組み合わされて使われている。

【００３５】

【発明の実施の形態、好適実施例の説明】

本発明の実施例の特徴を述べる前に、従来システムの特徴を最初に述べる。図
１は、カーべロスシステムに用いられている認証手順を図示している。カーべロ
スシステムは認証にパスワードを用いているけれども、そのシステムでは、暗号
化の有無にかかわらず、パスワードを決してネットワーク上に送信しないので、
特別に安全なシステムである。図示の実施例では、システムは有効期間付き証明
書発行サービス（下に説明する）その他の、ユーザーにが必要とする種々のサー
ビスを含む多くのサービスを提供することができる。

【００３６】ここに示した実施例では、特定の資源またはサービス１１２（それは、たとえ
ば、特定のアプリケーションプログラムのようなソフトウエアサービスであるこ
ともあろうし、データであることもあろうし、特定のハードウエア資源であるか
またはそれらの組み合わさったものであるかもしれない）を使おうとする人は、
そのシステムにログオンしようとして、認証を受けている人にしか知られていな
いパスワードを（通常は、あるプロンプトに応じて）入力する。

【００３７】好ましくは、普通のユーザーのセッションについて、１つのセッション（通常
の長さは、例えば、８−１０時間）の間にユーザーがパスワードを必要とするの
はこの時だけである（もし必要であれば、例えばセキュリティーシステムについ
ての管理タスクのような、ある特定のタスクを実行するのにパスワードの再入力
を要求するようにシステムを構成することもできるが）。

【００３８】その人は、たとえば、ローカルエリアネットワーク（ＬＡＮ）または他の通信
システムを通して鍵配布センター（ＫＤＣ，ＫｅｙＤｉｓｔｒｉｂｕｔｉｏｎ
Ｃｅｎｔｅｒ）１１６に接続されているクライアントコンピューター１１４を用
いてログオンを試みる。それに応じて、クライアント１１４はリクエストメッセ
ージ（ＡＳ−ＲＥＱ）１１８を鍵配布センター（ＫＤＣ）１１６に送る。

【００３９】リクエスト１１８は、サービスをリクエストした人の名前を表しているが、パ
スワードを含んではいない。ＫＤＣ１１６は、暗号化された（ＴＧＴ）"ＴｉｃｋｅｔＧｒａｎｔｉｎｇＴｉｃｋｅｔ"「チケット発行チケット」（ＡＳ−ＲＥＰ）（以下、有効期間付き証明書と呼ぶ）を含む１２２を返信する。

【００４０】有効期間付き証明書は２つの主要な構成部分を含んでいる。それらはクライア
ントに対して証明書発行サービスに使うチケット（セッション鍵を含むその大部
分はチケット発行サービスの鍵で暗号化されている）、及び、クライアント鍵で
暗号化されたクライアント用ならびにチケット発行サービス用のセッション鍵で
ある。ユーザーがある特定のサービス１１２を使うことをはじめようとすると、
ＫＤＣとのいま１つの新しいトランザクションが必要となる。クライアントコン
ピューター１１４はチケットのリクエスト１２４（ＴＧＳ−ＲＥＱ）をＫＤＣ１
１６に送信する。

【００４１】このリクエストは、クライアントがサービスのために使うセッション鍵（その
セッション鍵はＴＧＴ内に封印されている）で暗号化された（クライアントで生
成された）オーセンテイケイター、その大部分がチケット発行サービスの鍵で暗
号化されているチケット発行サービスにクライアントが使うためのチケット（こ
れらの両方とも有効期間付き証明書１２２に含まれていた）、ならびにサービス
１１２の名前、などの多くの構成要素を含んでいる。

【００４２】これに応じて、鍵配布センター１１６はクライアントに、クライアントがサー
バーを使うためのチケットを含む少なくとも部分的にはサーバーの鍵で暗号化さ
れたチケット１２６（ＴＧＳ−ＲＥＰ）（その大部分は暗号化されている）、な
らびに、クライアントとチケット発行サーバーとの間で共有されているセッショ
ン鍵で暗号化されたセッション鍵のコピー、などを送信する。

【００４３】この点で、クライアントはサービス１１２に対するアクセスを得るのに必要と
なる十分な事項を持っていることになる。このことはクライアントからサービス
１１２へ証明書とチケットを含むメッセージを送信することによって達成される
。これに応じて、サービスは所望されたサーバーの応答をクライアントに提供す
る。ＫＤＣとサービス１１２だけがチケットの暗号化に使われた秘密鍵を共有し
ていることから、サービス１１２はこのチケットを本物（オーセンティックなも
の）として扱うことができる。

【００４４】図２に示すように、公開鍵システムはまったく違った形で動作している。典型
的には、ユーザーは公開-秘密鍵ペアー２０２を生成する。ユーザーは秘密鍵２０４を、たとえば、クライアントコンピューターのファイル中か、またはスマー
トカード上にしまうなど、多くのやり方のいずれか１つを用いて格納する。従来
のシステムにおけるこのような格納は困難を引き起こすと考えられている。特定
のコンピューター上のファイルへの格納は、ユーザーは秘密鍵を格納している特
定のコンピューター上の秘密鍵の使用やアクセスだけが可能であるに過ぎないと
いうことから、「移動ユーザー」にとって不利になるからである。

【００４５】すなわち、そのようなシステムは、複数の相異なるコンピューターのいずれか
（例えば、ローカルエリアネットワークその他のネットワーク内の複数のノード
のいずれか）へのログオンの資格を必要とすか希望するユーザーにとっては使い
勝手の悪いものであるか、または使用不可能になってしまう、がそれでもなお公
開鍵システムで制御された資源の使用は可能であるということになる。さらに、
コンピューター上のファイルに秘密鍵をしまうことは、たとえそれが暗号化その
他の方法で保護されているとしても、そのシステムのセキュリティーの脆弱さを
表すものと考えられている。

【００４６】スマートカード上に秘密鍵をしまうことは、少なくとも理論的には移動ユーザ
ーと両立するものであるが、多くの状況下で、スマートカードリーダーを備えた
り、各種のユーザーにスマートカードの配布を行う複数の装置を備えることに伴
うコストと管理上のオーバーヘッドを考えると、それは実行不可能になってしま
う。

【００４７】ユーザーは、認証機関（ＣＡ, ＣｅｒｔｉｆｉｃａｔｅＡｕｔｈｏｒｉｔｙ
）のような信頼できる存在（ｅｎｔｉｔｙ）へ、たとえばＰＫＣＳ＃１０などを
通して、公開鍵を送信する。請求者の本人性（アイデンティティ）（別の通信チ
ャンネルで（ｏｕｔｏｆｂａｎｄ））を証明する際に、ＣＡはＸ.５０９証明を発行してユーザーの公開鍵２１２を証明する。

【００４８】次に、この証明はユーザーに送り返され、ここで、典型的には、当該分野技術
に精通した人々によく知られているＸ.５００またはＬＤＡＰ（ＬｉｇｈｔｗｅｉｇｈｔＤｉｒｅｃｔｏｒｙＡｃｃｅｓｓＰｒｏｔｏｃｏｌ）ディレクトリのようなディレクトリに公開することによって、一般的に利用可能となる。ＣＡ
はまた、上に述べたように、証明書取り消しリスト（ＣＲＬ）２１４を周期的に
発行する。ＣＲＬ配布のための１つの機構はＬＤＡＰを通ずるものである。

【００４９】従来のシステムのあるものでは、資源にアクセスしようとするユーザーは秘密
鍵２１８を（典型的には、自動的なやりかたで）取り出そうとする（ステップ２
１８）。公開鍵システムに基づく認証についての技術において既に知られている
多くのシステムのいずれかを使って、資源制御装置が、例えば（ＣＡによって証
明された）公開鍵を使って、ユーザーが適正に正しく身元確認されていることを
証明する（ステップ２２２）。

【００５０】以前のシステムでは、証明書が長寿命であるが故に、資源制御装置は証明書が
すでに失効しているかどうかを判断するため、次にＣＲＬとの比較を実行する（
ステップ２２４）。上に述べたように、上記比較ステップ２２４は、制御アクセ
スのプロセスに新たなステップの追加を必要とする。その上、特に、直近に取り
消された証明書をも検出できるほど十分頻繁にＣＲＬを公表しようとすると、Ｃ
ＲＬの作成、配布、格納や、そうでなければ代わりの追跡などの管理コストが発
生する。

【００５１】従来システムにおけるこれらおよびその他の問題に対処するために、１つの実
施例では、図３に示すような証明書生成システムが使われている。本件の開示説
明を理解した後では、当該分野技術に精通する何人（なんびと）にも明らかなよ
うに、多くの種々のシステムが証明書の生成に使えるが、１つの実施例では、カ
ーベロス型システムが使われている。図３に示した実施例では、変形カーベロス
型システムの１つの構成要素が鍵配布センター（ＫＤＣ）４１６である（図４）
。

【００５２】鍵配布センター４１６は図１に関連して述べられたものと同じものであっても
よいが、以下に述べる手順に合わせて変形（例えば、別のソフトウエアを備える
）されている。このシステムならびに図３のやり方では、最初（例えば、インス
トレーションのとき）、ＫＤＣ４１６は公開-秘密鍵ペアー３１２を生成する。

【００５３】このシステムはまた証明書のテンプレート（例えば、Ｘ.５０９証明書）も生成する（ステップ３１４）。ＫＤＣ４１６は、次に、ＫＤＣ秘密鍵を使ってテン
プレートに署名する。これらのステップ３１２、３１４、３１６は、従来システ
ムのルート証明機関による手続きとほぼ同じである（しかし典型的にはネットワ
ークサーバーまたはＫＤＣによってではない）。

【００５４】ユーザーの登録に際して、クライアント管理者はその特定のユーザーに関する
長寿命の公開-秘密鍵ペアーを生成し、ユーザーの標識に関係する鍵ペア−をＫＤＣ４１６にしまう（ステップ３１８）。ユーザーが、例えば、ネットワークへ
のログオンによってセッションをはじめると、ユーザーはパスワードを入力し、
図１に関して先に述べたように、クライアント１１４にＡＳ−ＲＥＱメッセージ
１１８をＫＤＣ４１６に送信指せる（ステップ３２２）。

【００５５】図３と図４の実施例では、ＡＳ−ＲＥＱ１１８に応じて、システムはユーザー
の公開鍵を再証明する。詳しく言えば、システムはユーザー３２４に対してＸ. ５０９証明書を生成し署名する。したがって、従来の公開鍵システムでは、ＣＡ
は、図３と図４に従って（最初の発行の際に）一度だけ証明書を生成し公開する
が、一方、本システムでは、典型的には、ユーザーがシステムにログオンするご
とに、ユーザーの公開鍵を含む証明書を、長い期間、何度でも、このユーザーに
対して証明書のシーケンスとして生成する。

【００５６】本発明のシステムと従来の普通の公開鍵システムとの間のいま１つの違いは、
その証明書が短寿命、すなわち、従来の公開鍵システムにおける１年から２年（
あるいはもっと長い）の有効期間よりかなり短く、証明書の発行後、好ましくは
６ヶ月より短い有効期間、１ヶ月より短い有効期間、さらに好ましくは、１週間
以下、なお、さらに好ましくは、２４時間以下、なおも、さらに好ましくは、１
２時間以下、そして好ましくは発行交付から約８〜１０時間の有効時間/有効日数（失効までの時間／日）を含んでいることである。

【００５７】このような短寿命の証明書の失効日は、このようなシステムを導入している会
社またはその他の事業所の必要に応じて変わるだろうし、好ましくは、証明書に
対する１つかまたはそれ以上の種類の通常またはあらかじめ設定された寿命を、
例えば、（適正な認証に従って）システム管理者によって設定することが可能で
ある。

【００５８】証明書寿命の設定の方針としては、全体を通じてのセキュリティーの程度を大
きく低下させず、ＣＲＬに対するチェックの頻度を下げたり、それをなくしてし
まったりできるくらいの十分短い寿命で証明書の提供ができる程度になるだろう
ことが予想される。

【００５９】従って、システムが、ユーザーに対して証明書（すなわち、ユーザーの公開鍵
を含む証明書）を生成（または再署名）するごとに、証明書は違った有効期間を
持つことになる。新しい証明書は、（同一の公開鍵のもとでは）それ以外のプロ
トコルを使ってもよいが、典型的には、その前の証明書が失効して、はじめて生
成される。

【００６０】その結果、本システムでは、どのあるユーザーについても、（典型的には、日
ごと、あるいは、就業日ベースで）一連の証明書が発行されるが、このユーザー
に対する（複数の）証明書は完全に同じものではなく、その失効の日付けや時間
などの点で一つ一つ異なっている（しかし、ある一つのユーザーの公開鍵（複数
）は同一であろう）。

【００６１】このことは、一旦ある証明書が発行されると、その後、同じ公開鍵に対して証
明書が異ったフォームあるいは異った情報をもって（特に、違った失効時間/日付をもって）再発行されるということが決してなかったところの以前の公開鍵シ
ステムとは対照的である。

【００６２】１つの実施例では、あるユーザーに対する一連の短寿命証明書に他のデータが
付け付け加えられたり変形されたりする。たとえば、あるユーザーがどの資源に
対して使用権限が与えられているかのデータ（あるいは他の権限データ）を短寿
命証明書の中に含めることができる。このような権限（オーソライゼーションイ
ンフォーメーション）の情報の１例は、ユーザーが属している１つかまたはそれ
以上のユーザーグループの情報、たとえば、そのメンバーがある資源に対して使
用権限を持つかどうかを示す情報である。

【００６３】典型的には比較的短時間の単位（たとえば、数日とか数週間）で変わるこのよ
うな権限情報は、従来の（長寿命の）証明書に含ませるには適していないと考え
られているが、本発明の実施例による短寿命の証明書に含ませることは可能であ
る。

【００６４】証明書の生成の後、システムはクライアント１４４（ｓｉｃ正しくは１１４）
に対して証明書４２２を送信または配送する（ステップ３２６）。１つの可能な
実施例では、その配送は、図１に関連して述べたのと同様、（変形された）ＡＳ
−ＲＥＰレスポンスの一部としてなされる。

【００６５】ユーザーがログオンして、証明書４２２を受け取った後なら、そのユーザーが
公開鍵制御資源を含んである資源に対しての認証を受けようと希望すれば、その
証明書の有効期間内であるかぎり、典型的には、ユーザーは、もう１度パスワー
ドを入れ直すことなく、何時でも証明書を使うだけで、認証を受けることができ
る。

【００６６】短寿命証明書の失効の後は、そのユーザーが資源に対するさらなる認証を受け
るためには、そのユーザーは、次の短寿命証明書を得るためには上述の手続き、
すなわち、典型的には、パスワードの再投入の繰り返しが必要となる。

【００６７】好ましくは、システムは証明書だけでなく、ユーザー３２８の秘密鍵も配送し
、さらに好ましくは、カーベロス型システムによって生成されたセッション鍵の
ような共有された秘密によって保護されたユーザーの秘密鍵（すなわち、証明書
が基礎としている公開鍵に対応して）も配送する。このようにして、ユーザーは
図２にあるような用途に対して秘密鍵を取り出すことができる（ステップ２１８
）が、しかし秘密鍵をクライアントコンピューター１１４上のファイル（そこは
、前にも注意したように比較的壊れやすい）にしまう必要はない。

【００６８】その上、ユーザーの秘密鍵をしまうために、集中的位置選定を用意することに
よって、秘密鍵の集中的管理（および鍵ポリシーの実行）が可能となり、それは
秘密鍵が広く配布されている形式（すなわち、個々のユーザーによって個々に保
管されている）に基礎を置く従来のＰＫシステムとは対照的になっている。

【００６９】さらに、本システムによれば、ユーザーはシステムにログオンするのに、自分
自身のパスワードを使って複数台のコンピューターのいずれをも使うことができ
る。すなわち、このシステムは移動ユーザーも使うことができ、しかも、物理的
なスマートカードを必要としない。秘密鍵と証明書の両方を持っているクライア
ントコンピューター１１４は公開鍵で制御された資源にアクセスすることができ
る４２４。

【００７０】公開鍵-秘密鍵ペア−は多くの資源に対する認証に関連して使われる。一例として、アクセス制御の決定は、たとえば、ＰＫＣＳ＃１１アプリケーションプロ
グラミングインターフェース５１２（図５と６）のようなスマートカードインタ
ーフェース５１８と関連してハードウエアスマートカード５１６を使うように、
スマートカードの使用を含む認証プロセスにもとづいてなされる。

【００７１】しかし、本発明はそれ以外の付加的な方法も与えることができる。図５に全体
的に示した実施例によれば、ハードウエアスマートカード５１６とインターフェ
ース５１８の代わりにか、図示してあるように、それらに加えて、模擬スマート
カード・スマートカードインターフェースを使うことも可能である.。

【００７２】アプリケーション５１４（例えば、ブラウザー５１７のような）及びＡＰＩ５
１２から見れば、模擬スマートカード／スマートカードインターフェース５２２
とハードウエアスマートカード・インターフェース５１６５１８との間に何の違いもないであろう。ユーザーがカード（例えば、ＰＫＣＳ＃１１ＡＰＩでＣ−Ｌ
ＯＧＩＮコールを用いて）ログインすると、ユーザーのパスワードは、ＫＤＣ４
１６に対して認証し秘密鍵と新しく生成されたＸ．５０９証明書を取り出す、の
に使われる（ステップ４２２）。

【００７３】これらの証明は次にローカルに（あるいは離れて）しまわれる（ステップ５２
４）。キャッシュ５２４からの証明は、スマートカードＡＰＩコール（たとえば
、Ｃ−ＳＩＧＮ，Ｃ−ＶＥＲＩＦＹ）を満たすのに使うことができる。図５と６
のプロセスは、比較的成熟した技術であるＡＰＩを用いながら、ハードウエアス
マートカードに伴う管理上のオーバーヘッドとコストの増大をまねくことなく、
ＰＫＣＳ＃１１ＡＰＩを通して、アプリケーション５１４へのトランスペアレン
トなアクセスを可能にしている.。

【００７４】図７に示すように、１つの実施例では、模擬スマートカードにログインするた
めのプロセスは、スマートカードへのユーザーのログオンを開始すべく、クライ
アントアプリケーション５１４がＰＫＣＳ＃１１、ＭＳ、ＣＡＰＩ，ＣＤＳＡな
どのような標準のＡＰＩを使うときに、はじめることができる。

【００７５】本発明のプロセスは、プロセスの間に、クライアントアプリケーションによっ
て送信され、また、受信されるメッセージ、および/または、データは、クライアントアプリケーション５１４が、図７に示されているように模擬されたスマー
トカードにログオンしているか、あるいは、物理的なスマートカードにログオン
するかに関わらず同じである、という意味で、クライアントアプリケーション５
１４に対してトランスペアレントであることが好ましい。

【００７６】使われる特定のインターフェース５１２は、典型的には、何のクライアントア
プリケーション５１４がログインを実行するか（たとえば、マイクロソフトなら
ＭＳ−ＣＡＰＩを使おうとするだろうし、他のブラウザ−あるいはアプリケーシ
ョンならＰＫＣＳ＃１１または他のインターフェース７１２を使うだろう）に依
存している。

【００７７】図示の実施例では、模擬スマートカードクライアント７１４（典型的には、ク
ライアント側コンピューターに常駐しているソフトウエアーで実行される）は、
セキュリティーサーバー７１８に、典型的には、カーベロス型の認証サービスの
ような認証サービスを請求７１６する。

【００７８】典型的には、模擬スマートカードクライアント７１４は、認証リクエスト７１
６を形成し、送出する前にユーザーからパスワード、および/または、ログインネームを要求する。セキュリティーサーバー７１８は模擬スマートカードクライ
アント７１４に認証証明書を送出７２２することによって応答する。送出された
認証証明書７２２は本発明の実施例、および/または、従来システムと関連して上に述べてきたものを含むことができる。

【００７９】しかし、送出７２２された情報は模擬スマートカードクライアント７１４が模
擬スマートカードサーバー７２６に対して認証するに十分なメッセージ７２４を
送るべく十分なものであるのが好ましい。

【００８０】典型的には、模擬スマートカードクライアント７１４に送られた情報７２２は
、スマートカードサービス用の（先に一般的に説明したような）チケットを含ん
でいる。認証請求７２４の受信に応じて、模擬スマートカードサーバー７２６は
スマートカードイメージ７２８を（好ましくは、暗号化して）返送する。

【００８１】ここで使われたように、「スマートカードイメージ」は、物理的なスマートカ
ードがシステムで、物理的なスマートカード上にしまわれたり、そこから取り出
されたりする少なくとも幾つかの情報を含むものである。例としては、公開鍵、
秘密鍵、対称鍵、証明書その他が含まれる。

【００８２】１つの実施例では、スマートカードイメージは、たとえば、秘密鍵で暗号化さ
れる。次に、模擬スマートカードクライアント７１４がスマートカードクライア
ントイメージを復号化する。

【００８３】復号化されたイメージは、例えば、公開鍵、秘密鍵、対称鍵、証明書および同
様の情報を含むことができる。それらの情報のいくつかあるいは全部（秘密鍵の
ように特に敏感な情報含んでいることが好ましい）は、最終ユーザーだけが知っ
ているパスワードで暗号化することができる。

【００８４】一般的に、図７から図８において、その下にクライアントアプリケーションと
書かれているブロック５１４は、クライアント側の項目、すなわち、それは、典
型的には、最終ユーザーによって使われているパソコンまたはその他のコンピュ
ーター上に常駐するソフトウエアーを使っているか、または、それらから成り立
っているものであり、一方、図の右側の項目はサーバー側の項目、すなわち、そ
れは、遠隔地のネットワークネットサーバーのように遠隔地に常駐するソフトウ
エア−を使っているか、または、それらから成り立っているものである。

【００８５】図７に示された実施例では、セキュリティーサーバー７１８と模擬スマートカ
ードサーバー７２６は別々のブロックとして示されているが、１つかまたはそれ
以上の別々のブロックとして示されている１つかまたはそれ以上の構成要素を、
実際は、１台のサーバーコンピューター上にあるようにシステムを構成すること
も可能であり、例えば、セキュリティーサーバー７１８とスマートカードサーバ
ー７２６が１台のサーバーコンピューター上にあるようにシステムを構成するこ
とも可能である。

【００８６】このような状況であれば、ステップ２、３と４を組み合わせて、模擬スマート
カードクライアント７１４が認証リクエスト７１６をセキュリティーサーバー／
模擬スマートカードサーバーに送り、また、それはスマートカードイメージ７２
８を（好ましくは、暗号化して）スマートカードクライアント７１４に送り返す
ことによって応答する、というようにすることもできる。

【００８７】スマートカードイメージを受信すると、スマートカードクライアント７１４は
、そこで、（暗号化された）スマートカードイメージ上の期限切れ公開鍵をチェ
ックする。もし期限切れの証明書が見つかれば、模擬スマートカードクライアン
ト７１４は、サーバー側の証明書発行期間７３４に再認証のリクエストを送る。
典型的には、模擬スマートカードクライアント７１４に送り返されてくる証明は
、上に述べてきたように、一般に短寿命の証明書である。

【００８８】模擬スマートカードクライアント７１４は、そこで、スマートカードイメージ
上のオブジェクトを用いて、物理的なスマートカードシステムが使われていたな
らば起こったであろう応答と同じやり方でクライアントアプリケーション５１４
に応答し７３６、暗号化ＡＰＩ５１２によって提供される暗号化動作を行う。

【００８９】図７に示すように、模擬スマートカードのログインの後は、クライアントアプ
リケーション５１４を実行する際に、スマートカードの動作がさらに続けられる
。図８Ａと図８Ｂは、このような（多くの）動作のうちの２つの有り得る例を示
している。図５Ａの例では、スマートカードイメージ８１２のログインとダウン
ロード（一般的に図７に関連して先に述べたように行われる）に続いて、クライ
アントアプリケーション５１４が、例えば、公開鍵証明書８１４を生成または格
納する（典型的には、標準的な暗号化ＡＰＩ５１２を用いて）。

【００９０】このような公開鍵証明書（クレデンシャル）は、図８Ａの実施例で、クライア
ントアプリケーション５１４にとってトランスペアレントなやり方で扱われる。
図示の実施例では、模擬スマートカードクライアント７１４はメッセージ８１６
を模擬スマートカードサーバー７２６に送り、サーバー側の模擬スマートカード
イメージを更新する。これは、本発明のシステムにおける第三者の証明（クレデ
ンシャル）を組みこむやり方、したがって、第三者認証機関（サーティフィケイ
ションオーソリティ）について支援提供方法を説明している。

【００９１】図８Ｂは他の１例を示している。図５Ａの実施例において、クライアントアプ
リケーション５１４は、クライアントのコンピューターにも本セキュリティーシ
ステムのサーバー上にもない第三者認証機関８２４との通信８２２を行う。たと
えば、クライアントアプリケーション５１４が証明書を得るために第三者認証機
関とコンタクトすることができる。

【００９２】しかし、このような通信８２２の後、クライアント５１４がメッセージ８１４
'を格納するためにそのメッセージ送る時、本システムは、図８Ａに関連して先に述べたのと同じやり方で、模擬スマートカードサーバー７２６に格納するため
の情報８１６'を送ることで、模擬スマートカードの格納に備えている。

【００９３】図９は、本発明の１つの実施例によって、模擬スマートカードシステムに新し
いユーザーが登録を行うために本システムをどのように使うかを示している。図
９の実施例では、管理者、たとえば、管理者サーバー９１２を用いて、証明書の
テンプレート（好ましくは、このようなテンプレートを生成するためのソフトウ
エアーのたすけをかりて）を準備し、それを模擬スマートカードサーバー７２６
（または、それに結合された格納装置９１６）上に格納すべく９１４に送出され
る。

【００９４】テンプレートは少なくとも証明書の内容の一部をシステム中での用途に指定し
ている。典型的には、テンプレートはユーザーの特徴ある名前、発行者の特徴あ
る名前、その他を含んでいる。

【００９５】新しいユーザーのために最初のパスワードが生成され、好ましくは、このパス
ワード７２２を、ユーザーが最初のログオンを実行した後などで、そのパスワー
ドは期限切れ状態であるものとして、そのパスワードにフラグが立てられるよう
にして、リセットし（したがって、、ユーザーにパスワードの変更を強制して）
、セキュリティーサーバー７１８（または、それに結合された格納装置）上に格
納される。

【００９６】ユーザーに対する新しい公開-秘密鍵ペアーの生成はクライアント側コンピューターでもサーバー側（たとえば、９１２）でも実行できる。クライアント側鍵
生成はサーバーコンピューターの計算負荷を軽減するのが望ましいとき使われる
だろう。しかし、特に、多くのユーザーが一時に加わった状況下では、多くの新しいユーザーを収容するようシステムを立ち上げやすくするよう、サーバー側
９１２での新しいペア−を生成するのが有用であろう。上で述べたパスワードは
多くのユーザーに配布される。

【００９７】好ましくは、この配布は、アウトオブバンド（別の通信チャンネル）で（パス
ワードをコンピューターネットワークを通して伝送せず、各個人に会うか電話ま
たはそれに類似の手段などで配布することで）行われるのが望ましい。それぞれ
の新しいユーザーが初回にシステムにログオン９２２するとき、ユーザーは、（
上に述べた）彼又は彼女のパスワードの変更を要求されることが好ましい。もし
鍵ペア−がそれ以前にサーバー側で生成されていなかったならば、模擬スマート
カードクライアント７１４が鍵ペア−を生成する。

【００９８】そこで、スマートカードイメージは、例えば、上に述べたのと同様な手続き８
１２を用いてクライアントにダウンロードされる。次に鍵が生成され、サーバー
側で、例えば図８Ａに関連して述べられたのと同様の手続き８１６でスマートカ
ードイメージに書きもどされる。

【００９９】以上の説明によって、本発明の多くの利点を見ることができる。本発明は公開
鍵認証（オーセンティケーション）を実行可能とするターンキーソリューション
を提供している。１つの実施例では、本発明は対称鍵認証を採用して、対称鍵シ
ステムによって保護することのできるアプリケーションの使用を可能にしている
。本発明はクライアント側公開鍵認証の実行を秘密鍵管理と証明書取り消し問題
を解決することによって実際的なものにしている。

【０１００】本発明は、ＣＲＬを必要とせず（または、ＣＲＬの必要性を少なくして）、ま
た/あるいは、クライアント側での格納またはスマートカード秘密鍵を必要としない公開鍵認証法を提供している。本発明は、計算的にコスト高となる頻繁な新
しい鍵ペア−の生成を必要とせずに、比較的頻繁な（例えば、勤務日ごとの）公
開鍵証明書の発行法を提供している。

【０１０１】本発明は、変形カーベロス、、および/あるいは、ＰＫＣＳ＃１１またはＣＤＳＡのような、ある種の以前のシステム、あるいは、以前の標準を用いて実行す
ることができ、それによって、ある種の比較的成熟度の高い発展したシステムの
利点を生かし、同時に、以前はこのようなシステムでは避けられないと考えられ
ていた欠点を回避しながら、実行することが可能である。

【０１０２】本発明は公開鍵システムとカーベロスシステムの両方の形のユーザーを取り扱
うことができるように、それら両方の中央管理を実行する機会を提供している。
本発明は、公開鍵システムの使用または実行と認証機関としての動作の両方が可
能な単一のシステムを提供している。

【０１０３】本発明の種々の変化と変形を使うことも可能である。図で示し、また、説明を
加えてきた実施例は、短寿命証明書を生成し配送するのにカーベロス型システム
のようなＴＴＰシステムを採用しているが、その他のシステムもまた短寿命証明
書を生成し配送するのに使うことができる。

【０１０４】違った設備が証明書を生成し配送するのに使われているごときシステムを提供
することが可能である。短寿命証明書の配送が必ずしも秘密鍵またはカーベロス
チケットの配送を伴うとは限らないシステムを提供することは可能である。

【０１０５】一般に、本発明の幾つかの特徴を、その他の特徴を使うことなく、使うことは
可能である。例えば、模擬スマートカードシステムを使うことなく、短寿命証明
書を生成するシステムを提供すること、または、その逆のシステムを提供するこ
とが可能である。

【０１０６】短寿命証明書は認証と関連して使われることを予想しているが、短寿命証明書
を他のセキュリティー対策、権限付与、暗号化、または、たの秘匿対策およびそ
の他と関連して使うことも可能である。短寿命証明書は主として、セッション指
向なアプリケーション（インターネットサイト、ブラウザ−、または公開鍵シス
テムで管理されたサーバー）と関連して使われることを予想しているが、短寿命
証明書をデータの格納とか送信（例えば、安全な電子メール）のような他の用途
に関連して用いることも、少なくとも理論的には可能である。

【０１０７】１つの例を、インターネットまたはインターネットブラウザ−アクセスの用法
を説明することによって示したが、スマートカードまたは模擬スマートカードは
を電子メール（「eメール」）のような他の項目に関連して用いることもできる。短寿命証明書を生成するためのＫＤＣ、または他のシステムの使用が述べられ
たが、中程度の寿命または（標準的な）長寿命の証明書を発行するようにシステ
ムを構成することも可能である。

【０１０８】証明書、および／または、秘密鍵の配送がカーベロスＡＳ−ＲＥＰメッセージ
の１部として発生するとして述べられているが、配送をＡＳ−ＲＥＰメッセージ
から切り離して行うことも可能である。

【０１０９】もし必要とあれば、秘密鍵と証明書だけをクライアントに配送するように（つ
まり、有効期限付き証明書、またはその他のチケットを配送せずに）システムを
構成することができるし、あるいは、公開鍵の証明書とカーベロスチケットの両
方の配送が必要とされ、または、要求されているのか、そうして／または、証明
書と秘密鍵が必要とされ、または、要求されているのか、のいずれかをユーザー
に指定させるようにシステムを構成することもできる。

【０１１０】本発明は、好適実施例とそれらのある程度の変化と変形との形で述べられてい
るが、その他の変化と変形もまた用いることができるものであり、以下の請求項
によって本発明は定義される。

【図面の簡単な説明】

【図１】従来の手順に従うカーベロス型システムのブロック図

【図２】従来のシステムによる公開鍵/スマートカード認証システムカのフローチャート

【図３】本発明の１実施例による証明書生成とその使用を図示するフローチャート

【図４】本図３の手順の使用を説明するシステムのある構成部分のブロック図

【図５】本発明の１実施例による模擬スマートカードおよび/またはハードウエアスマートカードとともに用いるためのシステムのブロック図

【図６】本発明の１実施例による模擬スマートカードおよび/またはハードウエアスマートカードとともに用いいるためのシステムのブロック図

【図７】本発明の１実施例による模擬スマートカードにログインするためのシステムを
説明するブロック図

【図８】図８Ａ及び図８Ｂは本発明によるシステムがどのように第三者機関公開鍵インフラストラクチャー
（ＰＫＩ, ＰｕｂｌｉｃＫｅｙＩｎｆｒａｓｔｒｕｃｔｕｒｅ）に対する支援を提供できるかの例を説明するブロック図

【図９】本発明の１実施例による模擬スマートカードシステムに関係するユーザー登録
を説明するブロック図

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ) ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＷ (72)発明者コバラ，ジヨセフ，エヌ．アメリカ合衆国，ワシントン州，イサクワ，ピー．オー．ボツクス 1027 Ｆターム(参考） 5J104 AA07 AA16 EA01 EA05 EA16 KA01 KA05 MA05 NA02 NA03 NA05 NA35 NA37 PA07

Claims

【特許請求の範囲】

【請求項１】チケットプロトコルに従ってチケットを出力するように構成
された少なくとも第１の鍵配布コンピューターにネットワークによって結合され
た、少なくとも第１のクライアントコンピューターを含む、前記ネットワーク内
のユーザーに対して公開鍵証明書を発行するためのコンピューターを用いた方法
であって、その方法は：前記鍵配布コンピューターにアクセスできるメモリーに、少なくとも、前記ユ
ーザーの公開鍵を格納すること、前記クライアントコンピューター中で、少なくとも前記ユーザーの初回のパス
ワードを受信すること、前記クライアントコンピューター中で前記パスワードの有効性を検証すること
、前記クライアントコンピューターから前記ネットワークを通して前記鍵配布コ
ンピューターに、少なくとも前記ユーザーの身元確認の標識を含む初回のメッセ
ージを発信すること、及び初回に、前記初回のメッセージに応答して、前記鍵配布コンピューターからネ
ットワークを通して前記クライアントコンピューターに前記チケットプロトコル
によるチケットと前記ユーザーの前記公開鍵を含む短寿命の公開鍵証明書の両方
を発信すること、を具備する、公開鍵証明書を発行するためのコンピューターを用いた方法。
【請求項２】前記チケットプロトコルがカーベロスプロトコルである請求
項１で請求されたコンピューターを用いた方法。
【請求項３】前記初回のメッセージに応答して前記鍵配布センターからネ
ットワークを通して前記クライアントコンピューターに、前記ユーザーの前記公
開鍵に対応する前記ユーザーの秘密鍵を発信することを、さらに含む請求項１で
請求されたコンピューターを用いた方法。
【請求項４】前記短寿命の公開鍵証明書が前記初回の後約１週間以下の有
効期間を持つ請求項１で請求されたコンピューターを用いた方法。
【請求項５】前記短寿命の公開鍵証明書が前記初回の後約１２時間以下の
有効期間を持つ請求項１で請求されたコンピューターを用いた方法。
【請求項６】前記ユーザーの認証を提供する前記短寿命の公開鍵証明書を
用いることをさらに含む請求項１で請求されたコンピューターを用いた方法。
【請求項７】公開鍵システムによって制御される資源を前記ユーザーが使
用する権限を与える前記短寿命公開鍵証明書の使用をさらに含む請求項１で請求
されたコンピューターを用いた方法。
【請求項８】前記公開鍵証明書がＸ.５０９証明書である請求項１で請求されたコンピューターを用いた方法。
【請求項９】チケットプロトコルに従ってチケットを出力するように構成
された少なくとも第１の鍵配布コンピューターにネットワークによって結合され
た、少なくとも第１のクライアントコンピューターを含む、前記ネットワーク内
のユーザーに対して公開鍵証明書を発行するするための装置であって、その装置
は、前記鍵配布コンピューターにアクセスできる、少なくとも前記ユーザーの鍵を
格納するためのメモリー、前記クライアントコンピューター中で少なくとも前記ユーザーの初回のパスワ
ードを受信し、前記クライアントコンピューター中で前記パスワードの有効性を
検証し、前記クライアントコンピューターから前記ネットワークを通して前記鍵
配布センターに、少なくとも前記ユーザーの身元確認の標識を含む初回のメッセ
ージを発信し、初回に、前記初回のメッセージに応答して、前記鍵配布センターからネットワ
ークを通して前記クライアントコンピューターに前記チケットプロトコルによる
チケットと前記ユーザーの前記公開鍵を含む短寿命の公開鍵証明書の両方を発信
するよう、プログラムされた前記クライアントコンピューターと前記鍵配布コンピュータ
ー、を具備する、公開鍵証明書を発行するための装置。
【請求項１０】前記チケットプロトコルがカーベロスプロトコルである請
求項９で請求された装置。
【請求項１１】前記初回のメッセージに応答して前記鍵配布センターから
ネットワークを通して前記クライアントコンピューターに、前記ユーザーの前記
公開鍵に対応する前記ユーザーの秘密鍵をさらに発信する請求項９で請求された
装置。
【請求項１２】前記短寿命の公開鍵証明書が前記初回の後約１週間以下の
有効期間を持つ請求項９で請求された装置。
【請求項１３】前記短寿命の公開鍵証明書が前記初回の後約１２時間以下
の有効期間を持つ請求項９で請求された装置。
【請求項１４】前記ユーザーの認証を提供する前記短寿命の公開鍵証明書
を用いることを、さらに具備する請求項９で請求された装置。
【請求項１５】公開鍵システムによって制御される資源を前記ユーザーが
使用する権限を与える前記短寿命公開鍵証明書の使用をさらに具備する請求項９
で請求された装置。
【請求項１６】前記公開鍵証明書がＸ.５０９証明書である請求項９で請求された装置。
【請求項１７】前記ネットワークによって、チケットプロトコルに従って
チケットを出力するように構成された少なくとも第１の鍵配布コンピューターに
結合された、少なくとも第１のクライアントコンピューターを含む前記ネットワ
ーク内のユーザーのための公開鍵証明書を発行するするための装置であって、そ
の装置は、前記鍵配布コンピューターにアクセスできる、少なくとも前記ユーザー鍵を格
納するためのメモリー手段、前記クライアントコンピューターに結合し、少なくとも前記ユーザーの初回パ
スワードを受信するための手段、前記クライアントコンピューター中で前記パスワードの有効性を検証するため
の手段、前記クライアントコンピューターに結合し、前記クライアントコンピューター
から前記ネットワークを通して前記鍵配布センターに、少なくとも前記ユーザー
の身元確認の標識を含む初回のメッセージを発信するための手段、前記鍵配布コンピューター中で、初回に、初回のメッセージに応答して、前記
鍵配布コンピューターからネットワークを通して前記クライアントコンピュータ
ーに前記チケットプロトコルによるチケットと前記ユーザーの前記公開鍵を含む
短寿命の公開鍵証明書の両方を生成し、発信するための手段、を具備する、公開鍵証明書を発行するための装置。
【請求項１８】前記初回のメッセージに応答して前記鍵配布センターから
ネットワークを通して前記クライアントコンピューターに、前記ユーザーの前記
公開鍵に対応する前記ユーザーの秘密鍵を発信するための手段をさらに具備する
請求項１７で請求された装置。
【請求項１９】前記短寿命の公開鍵証明書が前記初回の後、約１週間以下
の有効期間を持つ請求項１７で請求された装置。
【請求項２０】前記短寿命の公開鍵証明書が前記初回の後、約１２時間以
下の有効期間を持つ請求項１７で請求された装置。
【請求項２１】前記ユーザーの認証を提供する前記短寿命の公開鍵証明書
を用いることを、さらに具備する請求項１７で請求された装置。
【請求項２２】公開鍵システムによって制御される資源を前記ユーザーが
使用する権限を与える前記短寿命公開鍵証明書の使用をさらに具備する請求項で
請求された装置。
【請求項２３】前記公開鍵証明書がＸ.５０９証明書である請求項１７で請求された装置。
【請求項２４】ユーザーに対して公開鍵証明書を発行するするためのコン
ピューターを用いた方法であって、その方法は、前記ユーザーに関連する公開鍵を含む複数の公開鍵を、前記コンピューターに
結合したメモリーに格納すること、前記ユーザーの身元確認を含むメッセージを、複数の任意の時間に、前記コン
ピューターで受信すること、少なくとも初回の複数の前記各メッセージに応答して、前記ユーザーに関連し
た前記公開鍵の標識と前記証明書に対する有効期間の標識を含み、同一の公開鍵
の標識と異なった一連の有効期間を持つ一連の公開鍵証明書が出力される、前記
ユーザーに対する公開鍵証明書を、出力すること、を具備する、ユーザーのための公開鍵証明書を発行するためのコンピューター
を用いた方法。
【請求項２５】前記ユーザーの前記公開鍵に対応する前記ユーザーの秘密
鍵が前記公開鍵が出力されるときはほぼ常に出力される請求項２４で請求された
コンピューターを用いた方法。
【請求項２６】前記シーケンス中の各公開鍵証明書は、ほぼ前記証明書が
発行されてから前記証明書の失効時期までの有効期間を持っており、前記シーケ
ンスにおける各公開鍵証明書は、約１週間よりも短い有効期間を持っていて、従
って、公開鍵証明書の前記シーケンスが短寿命証明書のシーケンスとなるような
請求項２４で請求されたコンピューターを用いた方法。
【請求項２７】前記シーケンス中の前記各公開鍵証明書が約１日以下の有
効期間を持つ請求項２４で請求されたコンピューターを用いた方法。
【請求項２８】前記シーケンス中の前記各公開鍵証明書が約１２時間以下
の有効期間を持つ請求項２４で請求されたコンピューターを用いた方法。
【請求項２９】ユーザーのための公開鍵証明書を発行するための装置であ
って、その装置は、前記ユーザーに関連した公開鍵を含む複数の公開鍵を格納するためのコンピュ
ーターに結合されたメモリー、前記ユーザーの身元確認を含むメッセージを複数の任意の時間に受信する能力
を持つようにプログラムされたコンピューター、少なくとも初回の複数の前記各メッセージに応答して、前記ユーザーに関連し
た前記公開鍵の標識と前記証明書に対する有効期間の標識を含み、同一の公開鍵
の標識と異なった有効期間のシーケンスを持つ公開鍵証明書のシーケンスが出力
される前記ユーザーに対する公開鍵証明書を出力するようプログラムされた前記
コンピューター、を具備する、ユーザーのための公開鍵証明書を発行するための装置。
【請求項３０】前記コンピューターが、前記ユーザーの前記公開鍵に対応
する前記ユーザーの秘密鍵が前記公開鍵が出力されるときは、ほぼ常に出力され
るようプログラムされている請求項２９で請求された装置。
【請求項３１】前記シーケンス中の各公開鍵証明書が、ほぼ前記証明書が
発行されてから前記証明書の有効期間までの有効期間を持っており、前記シーケ
ンスにおける各公開鍵証明書が約１週間よりも短い有効期間を持っていて、従っ
て、公開鍵証明書の前記シーケンスが短寿命証明書のシーケンスであるような請
求項２９で請求された装置。
【請求項３２】前記シーケンス中の前記各公開鍵証明書が約１日以下の有
効期間を持つ請求項２９で請求された装置。
【請求項３３】前記シーケンス中の前記各公開鍵証明書が約１２時間以下
の有効期間を持つ請求項２９で請求されたコンピューターを用いた方法。
【請求項３４】ユーザーのための公開鍵証明書を発行するための装置であ
って、その装置は、前記ユーザーに関連した公開鍵を含む複数の公開鍵を格納するためのコンピュ
ーターに結合されたメモリー手段、前記ユーザーの身元確認を含むメッセージを複数の任意の時間に受信するよう
にプログラムされたコンピューター、少なくとも初回の複数の前記各メッセージに応答して、前記ユーザーに関連し
た前記公開鍵の標識と前記証明書に対する有効期間の標識を含み、同一の公開鍵
の標識と異なった有効期間のシーケンスを持つ公開鍵証明書のシーケンスが出力
される前記ユーザーに対する公開鍵証明書を出力するようプログラムされた前記
コンピューター、を具備する、公開鍵証明書を発行するための装置。
【請求項３５】前記公開鍵が出力されるときは、前記ユーザーの前記公開
鍵に対応する前記ユーザーの秘密鍵をほぼ常に出力するための手段をさらに具備
する請求項３４で請求された装置。
【請求項３６】前記シーケンス中の各公開鍵証明書が、ほぼ前記証明書が
発行されてから前記証明書の失効時期までの有効期間を持っており、前記シーケ
ンスにおける各公開鍵証明書が約１週間よりも短い有効期間を持っていて、従っ
て、公開鍵証明書の前記シーケンスが短寿命証明書のシーケンスであるような請
求項３４で請求された装置。
【請求項３７】前記シーケンス中の前記公開鍵証明書が約１日よりも短い
有効期間を持っている請求項３６で請求されたコンピューターを用いた方法。
【請求項３８】前記シーケンス中の前記公開鍵証明書が約１２時間よりも
短い有効期間を持っている請求項３６で請求されたコンピューターを用いた方法
。
【請求項３９】ユーザーに対する公開鍵証明書を発行するためのコンピュ
ーターを用いた方法であって、その方法が、前記コンピューター中で前記ユーザーの身元確認を含むメッセージを受信し、前記受信ステップに応じて、短寿命公開鍵証明書を出力する、ことを具備する方法。
【請求項４０】ユーザーに対する公開鍵証明書を発行するための装置であ
って、その装置は、前記ユーザーの身元確認を含むメッセージを受信し、前記メッセージに応じて
短寿命公開鍵証明書を出力するようにプログラムされたコンピューターを具備す
る装置。
【請求項４１】ユーザーに対する公開鍵証明書を発行するための装置であ
って、その装置は、前記ユーザーの身元確認を含むメッセージを受信するためのコンピューターを
用いた手段、ユーザーに対する公開鍵証明書を発行するための装置であって、その装置は、前記メッセージの受信に応じて短寿命公開鍵証明書を出力するするためのコン
ピューターを用いた手段、を具備する装置。
【請求項４２】最初のスマートカードプロトコルに従ってユーザーを認証
するよう構成したコンピューターを用いた認証システムであって、資源に対する
認証のための方法が、最初のユーザーの公開−秘密鍵ペアーを供給すること、及び、前記鍵ペア−を用いて、前記スマートカードプロトコルに従ってスマートカー
ドが生成するレスポンスを模擬すること、を具備する方法。
【請求項４３】前記公開-秘密鍵ペアー公開鍵が前記ユーザーの短寿命公開鍵証明書によって証明される請求項４２で請求された方法。
【請求項４４】コンピューターを用いた公開鍵証明法であって、その方法
は、公開鍵と秘密鍵のペア−を取得し、前記公開鍵に対する一連の公開鍵証明書を、年当たり少なくとも２通の公開鍵
証明書生成の頻度で生成する、ことを具備する方法。
【請求項４５】前記頻度が年当たり少なくとも約１２通の公開鍵証明書で
ある請求項４４で請求された方法。
【請求項４６】前記頻度が週当たり少なくとも約５通の公開鍵証明書であ
る請求項４４で請求された方法。
【請求項４７】前記公開鍵証明書が約６ヶ月以下の証明書寿命を決める有
効期間を具備する請求項４４で請求された方法。
【請求項４８】前記公開鍵証明書が約１週間以下の証明書寿命を決める有
効期間を具備する請求項４４で請求された方法。
【請求項４９】前記公開鍵-秘密鍵ペアーが少なくとも約１年の公開鍵-秘
密鍵ペアー寿命を決める有効期間を持つ請求項４４で請求された方法。
【請求項５０】前記公開鍵-秘密鍵ペアーが約１年以下の公開鍵-秘密鍵ペ
アー寿命を決める有効期間を持つ請求項４４で請求された方法。れた方法。
【請求項５１】前記公開鍵証明書が約１日以下の証明書寿命を決める有効
期間を具備する請求項５０で請求された方法。
【請求項５２】通信リンクによって結合された少なくとも１台のクライア
ントコンピューターと少なくとも１台のサーバーコンピューターを持つコンピュ
ーターシステムにおいて用いるための方法であって、その方法は、前記コンピューターシステムに結合されたメモリー中に、通常スマートカード
上にしまわれたタイプの少なくともある量のデータを表す初回の情報を格納する
こと、ユーザーのパスワードベースの認証に対するカーベロス型システムを用いるこ
と、及び、前記パスワードベースの認証に続いて前記最初の情報を取り出すこと、を具備する方法。
【請求項５３】前記初回の情報を用いてハードウエアスマートカードの使
用を模擬することををさらに具備する請求項５２で請求された方法。
【請求項５４】前記初回の情報が、対称鍵、非対称鍵ペア−および鍵証明
書の少なくとも１つを具備する請求項５２で請求された方法。
【請求項５５】前記公開鍵証明書がさらに権限付与情報を含んでいる請求
項４４で請求された方法。
【請求項５６】前記権限付与情報がグループ帰属情報を具備する請求項５
５で請求された方法。
【請求項５７】前記権限付与情報を資源権限付与システムにおいて用いる
ことをさらに具備する請求項５５で請求された方法。
【請求項５８】ユーザー認証のための装置であって、その装置は、ハードウエアスマートカードを受信し、受信した前記ハードウエアスマートカ
ードを用いてユーザーを認証する手段、および、ハードウエアスマートカードを受信し、受信した前記ハードウエアスマートカ
ードを用いてユーザーを認証する手段、を具備する装置。
【請求項５９】物理的なスマートカードにログインすることを模擬するた
めのコンピューターを用いた方法であって、その方法は、クライアントコンピューターを用いて、クライアントアプリケーションログイ
ンリクエストにこたえてユーザーからのパスワード入力を促すこと、前記パスワードの前記サーバーコンピューターへの送出がない場合には、少な
くとも、ユーザーを身元確認するリクエストを持っている最初のサーバーコンピ
ューターにメッセージを送ること、前記サーバーコンピューターから前記クライアントコンピューターに、少なく
とも部分的に暗号化してスマートカードイメージを送ること、及び、前記スマートカードイメージからの少なくとも一部を用いて前記クライアント
コンピューターにメッセージを送ることによって、、物理的スマートカードから
の応答を模擬すること、を具備する方法。
【請求項６０】前記スマートカードイメージが公開鍵証明書を含む請求項
５９で請求された方法であって、その方法は、前記公開鍵証明書が失効しているか否かを判断すること、前記の公開鍵証明書が失効している場合には、サーバーコンピューターに対し
て証明書の請求を送ること、を具備する方法。
【請求項６１】前記スマートカードイメージを更新するために、前記クラ
イアントコンピューターからの情報を前記第１のサーバーコンピューターに送る
ことをさらに具備する請求項５９で請求された方法.
【請求項６２】物理的なスマートカードにログインすることを模擬するた
めの装置であって、その装置は、クライアントコンピューターを用いて、クライ
アントアプリケーションログイン請求にこたえてユーザーからのパスワード入力
を促す手段、クライアントコンピューターを用いて、クライアントアプリケーションログイ
ン請求にこたえてユーザーからのパスワード入力を促す手段、前記パスワードの前記サーバーコンピューターへの送出がない場合には、少な
くとも、ユーザーを身元確認するリクエストを持っている最初のサーバーコンピ
ューターにメッセージを送るための手段、前記サーバーコンピューターから前記クライアントコンピューターに、少なく
とも部分的に暗号化してスマートカードイメージを送る手段、また、前記スマートカードイメージからの少なくとも一部を用いて前記クライアント
コンピューターにメッセージを送ることによって、物理的スマートカードからの
応答を模擬する手段、を具備する装置。
【請求項６３】ネットワークによって、少なくとも第１のサーバーコンピ
ューターに結合された第１のクライアントコンピューターを含むそのネットワー
ク中の物理的なスマートカードにログインすることを模擬するための装置であっ
て、それは、少なくとも第１のスマートカードイメージを表す情報を格納するための、前記
サーバーコンピューターにアクセスできるメモリーを具備し、前記のクライアントコンピューター及びサーバーコンピューターは：前記クライアントコンピューターを用いて、クライアントアプリケーションロ
グイン請求にこたえてユーザーからのパスワード入力を促し、前記パスワードの前記サーバーコンピューターへの送出がない場合には、ユーザーを身元確認するリクエストを具えた少なくとも前記第１のサーバーコンピュ
ーターにメッセージを送り、前記サーバーコンピューターから前記クライアントコンピューターに、少なくとも部分的に暗号化したスマートカードイメージを送り、且つ、前記スマートカードイメージからの情報の少なくとも一部を用いて前記クライ
アントコンピューターにメッセージを送り、それによって、物理的スマートカー
ドからの応答を模擬する、ようにプログラムされている、ものである装置。