(57)【要約】【課題】証明書が、パスワードを知るユーザの制御下においてユーザ装置によって生成されたことをも保証する解決方法を提供する。【解決手段】装置（１１０、１２０）は、ユーザからパスワードを受信し（Ｓ２０２）、装置に関する暗号アルゴリズムについての公開鍵を取得し（Ｓ２０４）、一方向性関数を、ユニーク識別子とパスワードと公開鍵との結合に適用することによって、パスワードベリファイアを取得し（Ｓ２０６）、ユニーク識別子、公開鍵、およびパスワードベリファイアを備える証明書を生成し（Ｓ２０８）、公開鍵に対応する秘密鍵を使用して証明書に署名し、それによって自己署名された証明書を取得し（Ｓ２１０）、自己署名された証明書を出力する。また、その装置が提供される。【選択図】図２
2015149722.tif 000002
【特許請求の範囲】
【請求項１】
証明書を生成する装置であって、
ユーザデータを受信する手段と、
前記装置について暗号アルゴリズムに関する公開鍵を取得する手段と、
前記公開鍵と前記ユーザデータに基づく値との結合に関数を適用することによって、ベリファイアを取得する手段と、
前記公開鍵および前記ベリファイアを備える前記証明書を生成する手段と、
前記証明書上の署名を取得して、それにより署名済みの証明書を取得する手段と、
前記署名済みの証明書を出力する手段と、
を備える、前記装置。
【請求項２】
前記取得する手段は、ユニーク識別子と、前記ユーザデータに基づく前記値と、前記公開鍵との結合に前記関数を適用することによって前記ベリファイアを取得し、前記ユニーク識別子を前記証明書中に含めるように構成された、請求項１に記載の装置。
【請求項３】
前記ユニーク識別子は、少なくとも１つの装置または少なくとも１つのリソースに関するユニーク識別子である、請求項２に記載の装置。
【請求項４】
前記関数は、一方向性関数または暗号化関数である、請求項１に記載の装置。
【請求項５】
前記ユーザデータは、パスワードである、請求項１に記載の装置。
【請求項６】
前記ユーザデータに基づく前記値は、前記ユーザデータと同一である、請求項１に記載の装置。
【請求項７】
前記暗号アルゴリズムはＲＳＡであり、前記公開鍵はモジュラス（modulus）を備える、請求項１に記載の装置。
【請求項８】
前記暗号アルゴリズムは、楕円曲線暗号（elliptic curve cryptography）アルゴリズムであり、前記公開鍵は、ジェネレータおよび第１のモジュラス（modulus）を備える、請求項１に記載の装置。
【請求項９】
前記署名を取得する手段は、前記公開鍵に対応する秘密鍵を使用して前記証明書に署名するように構成された、請求項１に記載の装置。
【請求項１０】
証明書を生成する方法であって、装置のプロセッサにおける、
ユーザデータを受信するステップと、
前記装置について暗号アルゴリズムに関する公開鍵を取得するステップと、
前記公開鍵と前記ユーザデータに基づく値との結合に関数を適用することによって、ベリファイアを取得するステップと、
前記公開鍵および前記ベリファイアを備える前記証明書を生成するステップと、
前記証明書上の署名を取得して、それにより署名済みの証明書を取得するステップと、
前記署名済みの証明書を出力するステップと、
を含む、前記方法。
【請求項１１】
前記ユーザデータに基づく前記値は、前記ユーザデータと同一である、請求項１０に記載の方法。
【請求項１２】
前記生成するステップは、ユニーク識別子と、前記ユーザデータに基づく前記値と、前記公開鍵との結合に関数を適用することによって前記ベリファイアを取得すること、および前記ユニーク識別子を前記証明書に含めることを含む、請求項１０に記載の方法。
【請求項１３】
前記ユニーク識別子は、少なくとも１つの装置または少なくとも１つのリソースに関するユニーク識別子である、請求項１０に記載の方法。
【請求項１４】
前記関数は、一方向性関数または暗号関数である、請求項１０に記載の方法。
【請求項１５】
前記ユーザデータは、パスワードである、請求項１０に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、概して、コンピュータネットワークセキュリティに関し、特に、そのようなネットワーク中の装置の認証に関する。
【背景技術】
【０００２】
このセクションは、本技術の様々な態様を読み手に紹介することが意図されており、これらの態様は、以下に記載され、および／または、請求された本開示の様々な態様に関連する。この考察は、読み手に背景情報を提供して本開示の様々な態様のより深い理解を促進するのに役立つと信じられる。従って、これらの記述は、この観点から読まれるべきものであり、先行技術の自認として読まれるべきものではないことを理解されたい。
【０００３】
２つの装置がデータを取り交わすために相互作用する必要のある多くのシナリオが存在する。単独のユーザが、装置、例えば、ラップトップおよび無線アクセスポイントを制御するときに、一般的なケースが発生する。この場合、通信は、比較的盗聴が容易である無線通信チャネル上を通る。よって、特に、機密データが送信されることになるときは、このチャネルが安全であることを保証することは重要である。無線チャネルは例として用いられるであろうが、これは、しばしばというほどではないにしても、有線接続にも当てはまることを理解されたい。
【０００４】
これらの場合において、先行のトラスト基盤（trust infrastructure）が存在しないことは一般的である。これは、いわゆる中間者攻撃（man-in-the-middle attack）に対してドアを開いている。この攻撃の軽減には、装置登録処理（device enrolment process）において、ある程度のレベルのユーザの関与を必要とする。先行技術の解決策は、ボタンプロトコル（button protocols）および視覚チャネル（visual channel）の使用のような異なる方法を含む（例えば、第１の装置は、ユーザが第２の装置でスキャンするバーコードを有することが可能であり、その情報がセッション鍵を生成するために使用される）。そのような方法は、ユーザを、無線チャネル上で通信する装置と相互作用することに関わらせる。これは、アドホックネットワーク中の装置間におけるセキュア接続（secure connection）を形成する基礎となる。
【０００５】
今日、ほとんどのアプリケーションは、セキュア接続を提供するために、ＴＬＳ（Transport Layer Security）プロトコルを採用する。ユーザを認証するために利用可能な従来のオプションは、事前共有鍵（pre-shared key）、パスワード、または公開鍵証明書を含む。しかしながら、ユーザ認証のためにクライアント側の公開鍵証明書を採用するアプリケーションはほとんど存在しない。実際に、証明書の展開（deployment）および管理は主たる問題となって現れている。
【０００６】
ユーザを認証するためのパスワードと証明書とを結合する解決方法が存在する。これらの方法は、概して、以下のように働く。ユーザが、証明書および秘密鍵を提供されるとき、ユーザはパスワードを入力するよう指示される。パスワードは、秘密鍵のセキュアストレージに対して使用され、証明書が失われる、または盗まれるリスクを最小化することを可能にする。そして、ＴＬＳセッションの間、ユーザは、デジタル証明書使用に際し“ロック解除”するために、パスワードを再度入力することを要求される。パスワードは、デジタル証明書と関連付けられた秘密鍵の所有の証拠として与えられる。
【０００７】
ＭＩＴＭ（中間者：Man-In-The-Middle）攻撃またはなりすましは、攻撃者が２つの装置との独立した接続を作成し、それらの間でメッセージを中継する、相互認証プロトコルへの攻撃のタイプである。ＭＩＴＭ攻撃における攻撃者は、通常、目に見えず、セキュア接続上で直接互いに通信していると信じる装置になりすます。しかしながら、攻撃者は、全体の通信を制御する。ＭＩＴＭ攻撃は破壊的である場合がある。もしユーザがＭＩＴＭに対して自身を認証すれば、自身の証明書を漏洩し、攻撃者はそれらを悪用してユーザを騙すことができる。
【０００８】
多くの認証の仕組みは、ＭＩＴＭまたはなりすまし攻撃に対する十分な保護を提供することに失敗している。これには主に２つの理由が存在する。
【０００９】
１．使用されるユーザ認証の仕組みは、通常、脆弱である。これは、ユーザがＭＩＴＭと会話し、それにより自身のパスワードを漏洩する状況につながる。
【００１０】
２．ＴＬＳセッション確立は、通常、ユーザ認証とは切り離されている。例えば、もし共有秘密鍵が漏れると、ネットワーク中のあらゆる装置を騙すことに再利用されうる。
【００１１】
その結果、ＭＩＴＭ攻撃に対する任意の効果的な対抗策は、ユーザ認証をＴＬＳ証明書ベースの認証と結合するセキュア認証の仕組みを実施することによって、これらの問題に対応しなくてはならない。
【００１２】
ＲＦＣ２９４５、「ＳＲＰ認証および鍵交換システム」（The SRP Authentication and Key Exchange System）は、パスワードに基づく認証の設定を可能とするＳＲＰ（Secure Remote Password）アルゴリズムを記載している。クライアントは、パスワードまたはＰＩＮコードを有し、サーバは、検証データ（例えば、パスワードのソルテッドハッシュ（salted hash）を有する。ＳＲＰは、強力な相互認証を提供する。しかしながら、ＳＲＰは、常に、サポートされて利用可能であるわけではない。ＤＴＬＳ（Datagram TLS）は、ＵＤＰ上でデータを保護するための参考であるが、ＳＲＰ認証をサポートせず、証明書ベースおよび事前共有鍵認証のみ、現在はサポートされている。
【００１３】
先行技術における第１の問題は、パスワード検証が装置に対してローカルであるときには、脆弱な可能性のあるセキュリティ強制機構が原因となり、それが信頼できないことである。これは、システム基盤に対して有害である可能性がある。その理由は、そのような場合には、攻撃者は、脆弱な装置上にてパスワード強制を回避し、そして、重要なリソースにアクセスすることが可能となるからである。従って、リモート装置（すなわち、検証者）が、ユーザが秘密鍵を所有するだけでなく、正しいパスワードを知っていることをも検証する解決方法に対する需要が存在することが分かるであろう。
【００１４】
先行技術の方法における第２の問題は、ＰＫＩ基盤を設定することの集中化された特性と複雑さである。そのようなシステム内における拡張性（新たな装置の追加）は、署名のための管理サービスおよび新しい証明書の配信を必要とする。これは、費用がかかり、特に、セキュリティ知識を何ら持たないユーザにとっては、設定または使用するのは容易ではない。多くの場合、特にアドホックネットワークについては、自己署名された証明書を生成する中央機関、または管理サーバおよび装置は、存在しない。そして、任意の装置が証明書を生成することが可能であるため、そのような証明書を信頼することは難しい。我々は、ユニークなパスワードの知識に基づく、セキュアな、および分散化されたＰＫＩシステムを提案することによって、この問題に対処する。これは、証明書のデプロイメントおよび管理を、ユーザにとって完全に透過的なものとする。ユーザは、パスワードを覚えることのみ必要である。
【００１５】
従って、証明書がリモートパスワード検証を可能にするだけでなく、証明書が、パスワードを知るユーザの制御下においてユーザ装置によって生成されたことをも保証する解決方法のニーズがあることが、理解されるであろう。
【発明の概要】
【００１６】
第１の態様において、本開示は、証明書を生成する装置を対象とする。装置は、ユーザデータを受信する手段、および装置について暗号アルゴリズムに関する公開鍵を取得する手段と、ユーザデータに基づく値と公開鍵との結合に関数を適用することによって、ベリファイアを取得する手段と、公開鍵およびベリファイアを備える証明書を生成する手段と、証明書上の署名を取得して、それにより署名済みの証明書を取得する手段と、署名済みの証明書を出力する手段と、を備える。
【００１７】
第１の実施形態において、ベリファイアを取得する手段は、ユニーク識別子とユーザデータに基づく値と公開鍵との結合に関数を適用すること、およびユニーク識別子を証明書に含めること、から構成される。ユニーク識別子は、少なくとも１つの装置または少なくとも１つのリソースに関するユニーク識別子であることが有益である。
【００１８】
第２の実施形態において、関数は、一方向性関数または暗号化関数である。
【００１９】
第３の実施形態において、ユーザデータは、パスワードである。
【００２０】
第４の実施形態において、ユーザデータに基づく値は、ユーザデータと同一である。
【００２１】
第５の実施形態において、暗号アルゴリズムはＲＳＡであり、公開鍵はモジュラス（modulus）を備える。
【００２２】
第６の実施形態において、暗号アルゴリズムは、楕円曲線暗号（elliptic curve cryptography）アルゴリズムであり、公開鍵は、ジェネレータおよび第１のモジュラスを備える。
【００２３】
第７の実施形態において、署名を取得する手段は、公開鍵に対応する秘密鍵を使用して証明書に署名するように構成される。
【００２４】
第２の態様において、本開示は、証明書を生成する方法を対象とする。装置のプロセッサは、ユーザデータを受信し、装置について暗号アルゴリズムに関する公開鍵を取得し、ユーザデータに基づく値と公開鍵との結合に関数を適用することによってベリファイアを取得し、公開鍵およびベリファイアを備える証明書を生成し、証明書上の署名を取得して、それにより署名済みの証明書を取得し、署名済みの証明書を出力する。
【００２５】
第１の実施形態において、ユーザデータに基づく値は、ユーザデータと同一である。
【００２６】
第２の実施形態において、前記生成することは、ユニーク識別子とユーザデータに基づく値と公開鍵との結合に関数を適用することによって、ベリファイアを取得することと、ユニーク識別子を証明書に含むことと、を含む。
【００２７】
第３の実施形態において、ユニーク識別子は、少なくとも１つの装置または少なくとも１つのリソースに関するユニーク識別子である。
【００２８】
第４の実施形態において、関数は、一方向性関数または暗号化関数である。
【００２９】
第５の実施形態において、ユーザデータは、パスワードである。
【図面の簡単な説明】
【００３０】
本開示の有益な特徴は、非限定的例として、以下の図を参照しながら記載されるであろう。
【図１】本開示が実施された代表的なシステムを説明する図である。
【図２】本開示の有益な実施形態に係る証明書生成を説明する図である。
【図３】本開示の第１の有益な実施形態に係る相互装置認証を説明する図である。
【発明を実施するための形態】
【００３１】
図１は、本開示が実施された代表的なシステム１００を図説する。システム１００は、第１のコンピューティング装置（“第１の装置”）１１０と、第２のコンピューティング装置（“第２の装置”）１２０とを備える。第１および第２の装置１１０、１２０は、標準のパーソナルコンピュータ（ＰＣ）、ワークステーション、スマートフォン、およびタブレットなどの、計算を実行することが可能な任意の種類の適当なコンピュータまたは装置であってよい。第１および第２の装置１１０、１２０は、それぞれ、好ましくは、少なくとも１つのプロセッサ１１１、１２１、内部または外部メモリ１１２、１２２、ユーザと相互作用するためのユーザインタフェース１１３、１２３、および接続１３０上で他の装置と相互作用するための第２のインタフェース１１４、１２４を備える。第１および第２の装置１１０、１２０は、それぞれ、好ましくは、プロセッサによって実行される時に、この後に記載される方法のいずれかを実行する命令を記憶するデジタルデータサポート１４０からソフトウェアプログラムを読み出すためのインタフェース（図示しない）をも備える。図説された装置は明確化のために非常に簡潔化されていること、および、実際の装置はさらに電源および永続的記憶装置などの機能を備えているであろうことは、当業者であれば理解できるであろう。
【００３２】
簡潔に述べると、本開示の顕著な着想は、信頼のアンカー（anchor：支え, よりどころ）が、（例えば、外部の信頼された認証機関の代わりに）ユーザデータに基づく、証明書を生成する装置の能力にある点である。ユーザデータは、例えば、パスワード（これ以降、非限定的例として使用される）、パスフレーズ、または生体データであることができる。
【００３３】
ユーザが新しい装置をユーザの装置の群（クラスタ：cluster）（すなわち、接続されたときに、アドホックネットワークの一部となる装置群）に登録することを望むとき、その新しい装置について証明書を生成することが必要である。登録処理は、第１の装置のインストール前にユーザが選択するパスワードの知識に基づく。そして、それぞれの新しい装置について、再度パスワードが必要とされ、装置の登録の間に生成されてそれぞれの装置に記憶されたパスワードベリファイアに対して検証される。パスワードの使用は認証されていない装置の登録を回避することが理解されるであろう。パスワードベリファイアに加えて、それぞれの登録された装置は、公開鍵および関連付けられた秘密鍵について自己署名された証明書を生成する。公開鍵は、任意の適当な方法によって取得されうる。公開鍵は、その装置によって生成され、またはさらなる装置から受信されうる。そして、公開鍵は、必要とされるとき、またはメモリから読みだされるとき、生成され、または受信されうる。
【００３４】
しかしながら、セキュリティを提供するために、正しいパスワードが提供されなければ、正当な自己署名がなされた証明書を生成することはできないであろう。この目的のために、証明書は、証明書の公開鍵とパスワードとを安全に紐付け、そして、その結果として生じる“紐付け”は、証明書に挿入されて、パスワードベリファイアとして使用される。そして、証明書は、さらなる装置、または内部もしくは外部メモリに出力されることができる。
【００３５】
好ましくは、紐付けは、パスワードと公開鍵との結合、好都合には連結に、または、装置もしくはリソースについての少なくとも１つのユニーク識別子（ｕｉｄ）とパスワードと公開鍵との連結に作用する、好ましくは一方向性の、関数Ｆを使用して行われる。
【００３６】
パスワードベリファイア＝Ｆ（パスワード｜公開鍵）またはＦ（ｕｉｄ｜パスワード｜公開鍵）
ユニーク識別子は、１つまたは複数の装置に記憶されたファイルのグループに関する、またはユーザがアクセスすることができる装置のグループに関するものであることが可能である。例えば、これは、“ルート”および“ユーザ”のような２つの権限レベルを有することを可能とすることができ、前者は完全なアクセス権を有し、ユーザは制限されたアクセス（すなわち、少なくとも１つのユニーク識別子によって定義された装置またはリソースに対するアクセス）を有する。
【００３７】
関数Ｆは、任意の適当なもの、好適には暗号法の、本技術における一方向性関数、例えば、ＳＨＡ−１およびＳＨＡ−３などのハッシュ関数または暗号化関数であることが可能である。
【００３８】
ＲＳＡの場合、公開鍵は、公開指数（public exponent）ｅおよびモジュラスＮによって表され、パスワードベリファイアは、好ましくは、以下の方法の１つにおいて計算される。
【００３９】
・パスワードベリファイア＝Ｆ（パスワード｜（Ｎ，ｅ））またはＦ（ｕｉｄ｜パスワード｜（Ｎ，ｅ））
・パスワードベリファイア＝Ｆ（パスワード｜Ｎ）またはＦ（ｕｉｄ｜パスワード｜（Ｎ，ｅ））
ＤＳＡ（Digital Signature Algorithm）および楕円曲線暗号の場合、公開鍵は、公開パラメータ（すなわち、２つのモジュラス（moduli）ｐ，ｑおよびジェネレータｇx）をも含み、パスワードベリファイアは、好ましくは、以下の方法のうちの１つにおいて計算される。
【００４０】
・パスワードベリファイア＝Ｆ（パスワード｜（ｇx，ｐ，ｑ））またはＦ（ｕｉｄ｜パスワード｜（ｇx，ｐ，ｑ））
・パスワードベリファイア＝Ｆ（パスワード｜（ｇx，ｐ））またはＦ（ｕｉｄ｜パスワード｜（ｇx，ｐ））
パスワードベリファイアは、公開とされうるため、自己署名される前に証明書に追加されることが可能である。
【００４１】
図２は、本開示の有益な実施形態に従って証明書生成を図説する。証明書は、識別名（Distinguished Name）（ＤＮ）、暗号化公開鍵、およびパスワードベリファイアＰＶを含む。証明書のＤＮフィールドは、（シリアル番号、ＭＡＣアドレス、または一意のリソース識別子のような）ユニーク識別子に設定されることができる。
【００４２】
ステップの多くは、異なる順番で実行されることが可能であることは理解されるであろう。例として、本方法は第１の装置１１０上で実行される。
【００４３】
１．第１の装置１１０は、通常はユーザ入力を介して、パスワードを取得する（Ｓ２０２）。
【００４４】
２．第１の装置１１０は、公開／秘密鍵のペアおよびユニーク識別子（ｕｉｄ）を取得する（Ｓ２０４）。これらは、好ましくは、装置自身によって生成されるが、ユーザまたは他の装置から提供されることも可能である。
【００４５】
３．第１の装置１１０は、関数Ｆをユニーク識別子、パスワード、および公開鍵に適用して、パスワードベリファイアを取得する（Ｓ２０６）。
【００４６】
４．第１の装置１１０は、ユニーク識別子、公開鍵、およびパスワードベリファイアを備える証明書を生成する（Ｓ２０８）。
【００４７】
５．第１の装置１１０は、公開鍵を使用して証明書に自己署名する（Ｓ２１０）。
【００４８】
装置が、他の装置に、通常は他の装置の秘密鍵を使用してデータへの署名を生成することを要求することも可能である。
【００４９】
図３は、本開示の第１の有益な実施形態に係る装置認証を図説する。この図説の例においては、２つの装置がアドホックネットワークにおいてペアに（すなわち接続）されている。
【００５０】
１．ユーザは、第１の装置１１０上でそのパスワードを入力する（Ｓ３０２）。
【００５１】
２．第１の装置１１０は、証明書、すなわち図２に図説されるように証明書１を生成する（Ｓ３０４）。
【００５２】
３．第１の装置１１０は、証明書１を第２の装置１２０に送信する（Ｓ３０６）。
【００５３】
４．第２の装置１２０は、証明書１上の署名を、その中の公開鍵を使用して検証する（Ｓ３０８）。もし署名検証が失敗すれば、第２の装置１２０は認証を中止する（さらに好ましくはユーザに通知する）。
【００５４】
５．第２の装置１２０は、ユーザからのパスワードを要求する（Ｓ３１０）。
【００５５】
６．第２の装置１２０は、ユーザからパスワードを受信する（Ｓ３１２）。
【００５６】
７．第２の装置１２０は、一方向性関数をユニーク識別子、公開鍵、およびパスワードに適用することによって、検証値（verification value）を生成し（すなわち、第１の装置１１０が証明書中のパスワードベリファイアを生成するために行ったのと同じ方法）、検証値が、証明書１から取り出されたパスワードベリファイアと合致するかチェックする（Ｓ３１４）。もし合致すれば、ユーザ認証は成功であり、証明書１は信頼された証明書として第２の装置１２０によって記憶される。不一致の場合は、認証は失敗となる。
【００５７】
ここまでは、第２の装置１２０が第１の装置１１０を認証したが、まだ逆についてはなされていない。これを可能にするために、本方法は以下のように進行しうる。
【００５８】
８．第２の装置１２０は、基本的には図２に図説されるように証明書を生成する（Ｓ３１６）が、第２の装置は、第１の装置１１０の認証のためにユーザから受信されたパスワードを再利用することができることに留意されたい。
【００５９】
９．第２の装置１２０は、証明書２を第１の装置に送信する（Ｓ３１８）。
【００６０】
１０．第１の装置１１０は、証明書２上の署名を、その中の公開鍵を使用して検証する（Ｓ３２０）。もし署名検証が失敗すれば、第１の装置１１０は認証を中止する（さらに好ましくはユーザに通知する）。
【００６１】
１１．第１の装置１１０は、一方向性関数をユニーク識別子、証明書２の公開鍵、およびパスワードに適用することによって、検証値を生成し（すなわち、第２の装置１２０が証明書２中のパスワードベリファイアを生成するために行ったのと同じ方法）、検証値が、パスワードベリファイアと合致するかチェックする（Ｓ３２２）。もし合致すれば、ユーザ認証は成功であり、証明書２は信頼された証明書として第１の装置１１０によって記憶される。不一致の場合は、認証は失敗となる。第１の装置１１０は、ユーザからのパスワードを要求することも、証明書１を生成するために受信されたパスワードを再利用することもできることに留意されたい。しかしながら、装置がパスワードを消去する前に記憶している時間については、比較的短い時間制限があることが有益である。
【００６２】
一旦、両方の装置上で認証が成功すると、証明書ベースのＴＬＳ認証が行われうる。証明書１および証明書２（すなわち、図３に図説された認証の間に取り交わされた証明書）を使用して、装置間でＴＬＳ相互認証の処理のみが行われうる。もし他の鍵または証明書が提出されれば、認証は失敗する。
【００６３】
変形形態において、ユーザはパスワードを１つの装置上のみで入力する（すなわち、パスワードは第１の装置１１０上のみで入力される。）
１．第１のパスワード検証の強制が、第１の装置１１０上で証明書１を使用して行われる。すなわち、第１の装置１１０がユーザからパスワードを受信し、それを使用して、パスワードベリファイアと比較される認証値を生成する。もし失敗すれば、処理は中止される。
【００６４】
２．ＴＬＳ認証は第１の装置１１０と第２の装置１２０との間で行われる。
【００６５】
３．成功のＴＬＳ認証において、
ａ）第２のパスワードの強制が、第１の装置１１０上にて、（ＴＳＬ認証の間に受信された）証明書２からのパスワードベリファイアを使用して行われる。または、
ｂ）第２のパスワードの強制が、第２の装置１２０上にて、（例えば、ＴＬＳ認証から生じるセキュア通信チャネル内の第１の装置１１０から送信された）第１の装置１１０のパスワードベリファイアを使用して行われる。
【００６６】
いくつかのシステムにおいては、セキュアチャネルは、一旦、設定されると、ユーザ認証に使用されることはできない。この場合、ユーザ認証は、セキュアチャネルの外側で、パスワードスニッフィング（password sniffing）にかかりやすいパスワードを作成して行われなければならない。この問題を解決するために、ＲＦＣ２０６９／ＲＦＣ２６１７または（ＴＬＳ−ＳＲＰに実施されている）拡張ＰＫＡＳ（augmented Password-Authenticated Key Agreement）プロトコルに明記されているように、ダイジェストアクセス認証（Digest Access Authentication）プロトコルを使用することが可能である。そこではネットワークをスニッフィングしている攻撃者は、ユーザとしてログインするため、またはパスワードを推測するためでさえ、十分な情報を取得することはない。以下の変形形態は、Ｓｅｃｕｒｅ  Ｒｅｍｏｔｅ  Ｐａｓｓｗｏｒｄ（ＳＲＰプロトコル、さらなる詳細はＲＦＣ２９４５を参照）を実装する。
【００６７】
この変形形態では、以下のパラメータが証明書に、自己署名される前に追加される。
【００６８】
・Ｎ’＝２ｑ＋１，安全素数である（ｑも素数）、
・ｇ（ジェネレータ）  ｍｏｄ  Ｎ’、および
・Ａ  ＳＲＰベリファイアｖ＝ｇpassword  ｍｏｄ  Ｎ’
パスワードは秘密のままであるが、ＳＲＰパスワードベリファイアは、公開とされうる。加えて、パスワードベリファイアは、２つの部分に分けられ、ｇpasswordはパスワードに対応する派生パスワード（derivate password）である。
【００６９】
・ＰＶ＿１＝Ｆ（パスワード｜（Ｎ，ｅ））またはＦ（ｕｉｄ｜パスワード｜（Ｎ，ｅ））
・ＰＶ＿２＝Ｆ（（ｇパスワード，Ｎ’，ｑ）｜（Ｎ，ｅ））またはＦ（ｕｉｄ｜（ｇパスワード，Ｎ’，ｑ）｜（Ｎ，ｅ））
装置が新しい証明書を受信するとき、証明書がパスワードを知る誰かによって生成されたものであることをチェックしなければならない。これは、システムが使用される前に、行われる。
【００７０】
１．第１の装置１１０は、Ａ＝ｇa（ａはランダム）を第２の装置１２０に送信する。
【００７１】
２．第２の装置１２０は、第１の装置１１０にその公開鍵ｒ＝ＳＨＡ−１（Ｎ’，ｇ）およびＢ＝ｒｖ＋ｇb（ｂはランダム）を送信する。
【００７２】
３．２つの装置は、Ｓ＝ＳＨＡ−１（Ａ，Ｂ）を計算する。
【００７３】
４．第１の装置１１０は、ユーザからのパスワードを要求する。
【００７４】
５．ユーザは、第１の装置１１０上にてパスワードを入力する。
【００７５】
６．第１の装置１１０は、パスワードベリファイア＝ＳＨＡ−１（パスワード｜公開鍵）を計算し、ｒ＝ＳＨＡ−１（Ｎ’，ｇ）をチェックし、そして、Ｋ１＝（Ｂ−ｒｖ）(a+s・パスワード)＝（ｇb）(a+s・パスワード)を生成する。Ｋ１は、第２の装置１２０に送信される。
【００７６】
７．第２の装置１２０は、Ｋ２＝（Ａ・Ｖs）b＝（ｇa・Ｖs）b＝（ｇ{a+s・パスワード}）b＝（ｇb）{a+s・password}を計算する。Ｋ２は、第１の装置１１０に送信される。
【００７７】
８．２つの装置は、Ｋ１＝Ｋ２であることをチェックする。
【００７８】
一旦、装置がＫ１およびＫ２を計算してＫ１＝Ｋ２であることをチェックすると、それぞれの装置上の検証モジュールは、検証値の第２の部分のみを生成して（すなわち、装置が証明書に挿入されるパスワードベリファイアＰＶ＿２を生成するのと同じ方法）、それがＰＶ＿２と等しいことをチェックする。成功であれば、それぞれの装置は、パスワードを知る誰かによって、認証の間に平文のパスワードへのアクセスを有さずに、他の装置の証明書が生成されたことを保証される。
【００７９】
一方で、チェックされたパスワードが装置に対してローカルであるとき、ＳＲＰプロトコルは必ずしも使用されない。その場合には、検証モジュールは、平文のパスワードを入手することができる。よって、検証モジュールは、以下のチェックを行う。
【００８０】
１．パスワード検証値の第１の部分を生成し（すなわち、装置がパスワードベリファイアＰＶ＿１を生成したのと同じ方法）、それがＰＶ＿１と等しいことをチェックする。
【００８１】
２．ｇ、Ｎ’、および平文のパスワードからＳＲＰ検証値を生成し（すなわち、初めに生成されたのと同じ方法）、それがｖと等しいことをチェックする。
【００８２】
３．検証値の第２の部分を生成し、それがＰＶ＿２と等しいことをチェックする。
【００８３】
このように、本開示は、トラステッドなＣＡ無しに、特に、アドホックネットワークにおいて、認証を実行する装置に関する方法を提供することが可能であることが、理解されるであろう。
【００８４】
本明細書および（適正であれば）クレーム並びに図面に開示された各機能は、独立して、または任意の適当な組み合わせによって、提供されうる。ハードウェアにて実施されるように記載された機能は、ソフトウェアにても実施されうるし、その逆もありうる。クレームに出現する参照符号は、例示のためのみのものであり、請求の範囲に制限する効力を何ら有するべきではない。
【図１】
2015149722.tif 000003
【図２】
2015149722.tif 000004
【図３】
2015149722.tif 000005
【外国語明細書】
2015149722000001.pdf