JP6765993B2 - クレデンシャル生成システム及び方法 - Google Patents
クレデンシャル生成システム及び方法 Download PDFInfo
- Publication number
- JP6765993B2 JP6765993B2 JP2017038986A JP2017038986A JP6765993B2 JP 6765993 B2 JP6765993 B2 JP 6765993B2 JP 2017038986 A JP2017038986 A JP 2017038986A JP 2017038986 A JP2017038986 A JP 2017038986A JP 6765993 B2 JP6765993 B2 JP 6765993B2
- Authority
- JP
- Japan
- Prior art keywords
- credential
- client terminal
- client
- issuing
- server device
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Description
この発明は、情報通信技術、特にパスワードや証明書等のクレデンシャルを生成する技術に関する。
近年、サーバ装置からクライアントのパスワードや証明書などの情報であるクレデンシャルが漏洩する事件が発生している。例えば2016年には大手オンラインストレージサービスからIDとPWの情報が漏洩する事件が発生した（例えば、非特許文献１参照。）。クレデンシャルを第三者が悪用すると、漏洩元サービスや他のサービスに対して不正アクセスを実行することが可能になる。その結果、第三者によるサービスの不正利用やクライアントのプライバシー情報の閲覧などの事態に繋がるリスクがある。
こうした事件の対策の一つとしてクレデンシャルの発行を第三者機関に行わせる認証システムが考えられる。以下、(A)から(C)の３個の具体例を挙げる。
(A) プライベートCA(Certificate Authority)では、第三者機関を使用して証明証を発行する。プライベートCAサービスのクレデンシャル発行フローではクラアイアントの申請を受け、サービス提供者がCSR（証明書署名要求）を作成し、自身の秘密鍵で署名を付加し、プライベートCAに対して証明書の発行を依頼する。
(B) Apache MILAGRO (incubating)（例えば、非特許文献２参照。）が提案する分散鍵発行局(Distributed Trusted Authority: 以下D-TA)では、第三者機関であるD-TAがクレデンシャルを発行する。D-TAを利用したクレデンシャル発行フローではクライアントの申請を受けて、サービス提供者が複数のD-TAに対してHMACの鍵を使用してメッセージ認証タグを付加し、鍵発行依頼を行う。D-TAは鍵発行依頼が正しければクライアントの鍵を発行する。
(C) 認証連携では、第三者の認証システムを使用する。クライアントは第三者サービスにアクセスし、そこでクライアント認証を行う。認証が正しく行われれば、第三者機関がトークンを発行し、サービス提供者がトークンを検証して正しければ認証が通る。
これらの例では、証明書やクライアントの鍵やトークンの発行依頼がクレデンシャルに当たる。以下、クレデンシャルに使用する秘密鍵やHMACの鍵を発行依頼鍵と呼ぶ。これら既存技術を使用することで、サービス提供者はクライアントのクレデンシャル情報を保有しなくてよい。
The guardian, "Dropbox hack leads to leaking of 68m user passwords on the internet", [online], ［平成 29 年 2 月 22日検索］、インターネット〈URL：https://www.theguardian.com/technology/2016/aug/31/dropbox-hack-passwords-68m-data-breach〉
Apache MILAGRO (incubating), [online], ［平成 29 年 2 月 22日検索］、インターネット〈URL：http://docs.milagro.io/en/〉
Michael Scott, "M-Pin: A Multi-Factor Zero Knowledge Authentication Protocol", [online], ［平成 29 年 2 月 22日検索］、インターネット〈URL：https://www.miracl.com/hubfs/mpin4.pdf〉
不正な鍵発行が行われないようにクレデンシャル発行装置を持つ第三者機関（以下、クレデンシャル発行局）を利用しても、既存のプライベートCAやD-TAのクレデンシャル発行方法では、サービス提供者のサーバ装置が所有する発行依頼鍵が漏洩したり不正に利用をされたりすると、不正なクレデンシャル発行が行われてしまう可能性がある。不正なクレデンシャル発行は攻撃者によるサービスの不正利用に繋がる。具体例としては、オンラインバンキングによる不正送金や写真や動画などのプライバシー情報の侵害等の実被害を引き起こす可能性がある。
この発明は、より安全性が高いクレデンシャルの生成を行うことができるクレデンシャル生成システム及び方法、クライアント端末、サーバ装置、発行依頼装置、クレデンシャル発行装置並びにプログラムを提供することである。
この発明の一態様によるクレデンシャル生成システムは、クライアント端末と、クライアント端末に対してサービスの提供を行うサーバ装置と、発行依頼装置と、クレデンシャル発行装置とを含み、クライアント端末のクレデンシャルを生成するクレデンシャル生成システムにおいて、サーバ装置は、クレデンシャル発行装置にクライアント端末のクレデンシャルの発行を依頼し、発行依頼装置は、クレデンシャル発行装置にクライアント端末のクレデンシャルの発行を依頼し、クレデンシャル発行装置は、サーバ装置からのクレデンシャルの発行依頼に基づいてクライアント端末のクレデンシャルの一部を発行し、発行依頼装置からのクレデンシャルの発行依頼に基づいてクライアント端末のクレデンシャルの他部を発行し、クライアント端末は、発行されたクレデンシャルの一部及びクレデンシャルの他部を用いて、クライアント端末のクレデンシャルを生成する。
より安全性が高いクレデンシャルの生成を行うことができる。
［実施形態］
以下、図面を参照して、この発明の一実施形態について説明する。
以下、図面を参照して、この発明の一実施形態について説明する。
図１に示すように、クレデンシャル生成システムは、クライアント端末１、サーバ装置２、発行依頼措置３及びクレデンシャル発行装置４を例えば備えている。クレデンシャル生成方法は、クレデンシャル生成システムの各部が、図２及び以下に説明するステップＳ１からステップＳ１３の処理を行うことにより例えば実現される。
クライアント端末１は、システムを利用するクライアントが有する、PC、スマートフォン、タブレット端末などの端末装置である。クライアント端末１は、サーバ装置２や発行依頼装置３にアクセスして、クレデンシャルを受け取る。クレデンシャルとは、ＩＤ、パスワード、証明書、鍵などのユーザーの認証に用いられる情報のことである。
サーバ装置２は、サービス提供者が有するサーバ装置である。サービス提供者は、サーバ装置２を用いてクライアントに所定の所定のサービスを提供する。サーバ装置２は、クレデンシャル発行装置４に対してクレデンシャルの発行依頼を行い、クレデンシャル発行装置４が発行したクレデンシャルを受信して、受信したクレデンシャルをクライアント端末１に送信する。この際、後述するように、サーバ装置２は、クレデンシャルを分割配送してもよい。
発行依頼装置３は、発行依頼局が有する、クレデンシャル発行装置４に対してクレデンシャルの発行依頼を行うサーバ装置である。発行依頼装置３は、サーバ装置２と同様に、クレデンシャル発行装置４に対してクレデンシャルの発行依頼が可能である。すなわち、発行依頼装置３は、クレデンシャル発行装置４に対してクレデンシャルの発行依頼を行い、クレデンシャル発行装置４が発行したクレデンシャルを受信して、受信したクレデンシャルをクライアント端末１に送信する。このように、サービス提供者の持つクレデンシャルの発行依頼の権限は、サーバ装置２と発行依頼装置３との分散されている。
クレデンシャル発行装置４は、信頼しうる第三者機関のサーバ装置である。クレデンシャル発行装置４は、サーバ装置２及び発行依頼装置３からの発行依頼を検証し、検証結果が正しければサーバ装置２と発行依頼装置３の数に分割されたクレデンシャルをそれぞれに生成し、サーバ装置２及び発行依頼装置３に送信する。
＜ステップＳ１＞
クライアントは、クライアント端末１を用いて、サービス提供者のサーバ装置２にアクセスし、クライアントの登録を要求する。
クライアントは、クライアント端末１を用いて、サービス提供者のサーバ装置２にアクセスし、クライアントの登録を要求する。
言い換えれば、クライアント端末１がクライアントの登録情報をサーバ装置２に送信する（ステップＳ１）。
＜ステップＳ２＞
サーバ装置２は、クライアントの登録情報から、クレデンシャルの発行に必要なクライアント情報を作成する（ステップＳ２）。
サーバ装置２は、クライアントの登録情報から、クレデンシャルの発行に必要なクライアント情報を作成する（ステップＳ２）。
＜ステップＳ３＞
サーバ装置２は、クライアント情報に対して、作成者を識別できる発行依頼情報を作成し、クライアント情報と発行依頼情報をクレデンシャル発行装置４に送信する。作成者を識別できる発行依頼情報を作成には、例えばHMACや共通鍵暗号や公開鍵暗号などを用いることができる。
サーバ装置２は、クライアント情報に対して、作成者を識別できる発行依頼情報を作成し、クライアント情報と発行依頼情報をクレデンシャル発行装置４に送信する。作成者を識別できる発行依頼情報を作成には、例えばHMACや共通鍵暗号や公開鍵暗号などを用いることができる。
言い換えれば、サーバ装置２は、クレデンシャル発行装置４にクライアント端末１のクレデンシャルの発行を依頼する（ステップＳ３）。
＜ステップＳ４＞
クレデンシャル発行装置４は、受信した依頼を検証し、正しければクライアント情報に対応するクレデンシャルの一部を発行し、サーバ装置２に送信する（ステップＳ４）。
クレデンシャル発行装置４は、受信した依頼を検証し、正しければクライアント情報に対応するクレデンシャルの一部を発行し、サーバ装置２に送信する（ステップＳ４）。
＜ステップＳ５＞
サーバ装置２は、受信したクレデンシャルをクライアント端末１に送信する（ステップＳ５）。
サーバ装置２は、受信したクレデンシャルをクライアント端末１に送信する（ステップＳ５）。
例えば、サーバ装置２は、受信したクレデンシャルをランダムに二分割し、片方をクライアントのみが得られる方法（例えば、メール）で送信し、残りをクライアント端末１に送信する。
＜ステップＳ６＞
クライアント端末１は、例えばクライアントがサーバ装置２から受け取ったクレデンシャルと、クライアント端末１がサーバ装置２から受信したクレデンシャルとを用いて、クレデンシャルの一部を作成する（ステップＳ６）。
クライアント端末１は、例えばクライアントがサーバ装置２から受け取ったクレデンシャルと、クライアント端末１がサーバ装置２から受信したクレデンシャルとを用いて、クレデンシャルの一部を作成する（ステップＳ６）。
このように、ステップＳ４からステップＳ６の処理により、この例では、クレデンシャル発行装置４で発行されたクレデンシャルの一部はサーバ装置２を経由してクライアント端末１に送信される。
＜ステップＳ７＞
クライアントは、クライアント端末１を用いて、発行依頼装置３にアクセスし、クライアントの登録を要求する。
クライアントは、クライアント端末１を用いて、発行依頼装置３にアクセスし、クライアントの登録を要求する。
言い換えれば、クライアント端末１がクライアントの登録情報を発行依頼装置３に送信する（ステップＳ７）。
＜ステップＳ８＞
発行依頼装置３は、クライアントの登録情報から、クレデンシャルの発行に必要なクライアント情報を作成する（ステップＳ８）。
発行依頼装置３は、クライアントの登録情報から、クレデンシャルの発行に必要なクライアント情報を作成する（ステップＳ８）。
＜ステップＳ９＞
発行依頼装置３は、クライアント情報に対して、作成者を識別できる発行依頼情報を作成し、クライアント情報と発行依頼情報をクレデンシャル発行装置４に送信する。作成者を識別できる発行依頼情報を作成には、例えばHMACや共通鍵暗号や公開鍵暗号などを用いることができる。
発行依頼装置３は、クライアント情報に対して、作成者を識別できる発行依頼情報を作成し、クライアント情報と発行依頼情報をクレデンシャル発行装置４に送信する。作成者を識別できる発行依頼情報を作成には、例えばHMACや共通鍵暗号や公開鍵暗号などを用いることができる。
言い換えれば、発行依頼装置３は、クレデンシャル発行装置４にクライアント端末１のクレデンシャルの発行を依頼する（ステップＳ９）。
＜ステップＳ１０＞
クレデンシャル発行装置４は、発行依頼装置３から受信した依頼を検証し、正しければクライアント情報に対応するクレデンシャルの他部を発行し、発行依頼装置３に送信する（ステップＳ１０）。
クレデンシャル発行装置４は、発行依頼装置３から受信した依頼を検証し、正しければクライアント情報に対応するクレデンシャルの他部を発行し、発行依頼装置３に送信する（ステップＳ１０）。
クレデンシャルの他部は、クレデンシャルの他部と、ステップＳ４で発行したクライアント情報に対応するクレデンシャルの一部とを用いれば、クライアント情報に対応するクレデンシャルを生成することができる情報のことである。
＜ステップＳ１１＞
発行依頼装置３は、受信したクレデンシャルをクライアント端末１に送信する（ステップＳ１１）。
発行依頼装置３は、受信したクレデンシャルをクライアント端末１に送信する（ステップＳ１１）。
例えば、発行依頼装置３は、受信したクレデンシャルをランダムに二分割し、片方をクライアントのみが得られる方法（例えば、メール）で送信し、残りをクライアント端末１に送信する。
＜ステップＳ１２＞
クライアント端末１は、例えばクライアントがサーバ装置２から受け取ったクレデンシャルと、クライアント端末１がサーバ装置２から受信したクレデンシャルとを用いて、クレデンシャルの他部を作成する（ステップＳ１２）。
クライアント端末１は、例えばクライアントがサーバ装置２から受け取ったクレデンシャルと、クライアント端末１がサーバ装置２から受信したクレデンシャルとを用いて、クレデンシャルの他部を作成する（ステップＳ１２）。
このように、ステップＳ１０からステップＳ１２の処理により、この例では、クレデンシャル発行装置４で発行されたクレデンシャルの他部は発行依頼装置３を経由してクライアント端末１に送信される。
＜ステップＳ１３＞
クライアント端末１は、ステップＳ６で作成したクレデンシャルの一部と、ステップＳ１２で作成したクレデンシャルの他部とを用いて、クライアント情報に対応するクレデンシャルを作成する。
クライアント端末１は、ステップＳ６で作成したクレデンシャルの一部と、ステップＳ１２で作成したクレデンシャルの他部とを用いて、クライアント情報に対応するクレデンシャルを作成する。
言い換えれば、クライアント端末１は、クレデンシャル発行装置４で発行されたクレデンシャルの一部及びクレデンシャル発行装置４でクレデンシャルの他部を用いて、クライアント端末１のクレデンシャルを生成する（ステップＳ１３）。
以下、上記実施形態の効果を述べる。例えば、仮定として攻撃者は、攻撃するクライアントの情報を知っているとする。また、攻撃者の攻撃成功は攻撃対象のクライアントのクレデンシャルを取得することとする。さらに、攻撃者はクライアントのメールアドレスに届く情報を知ることができない状態であるとする。サービス提供者が攻撃され、サービス提供者の持つ情報が流出もしくは不正利用された場合であっても、攻撃者はサーバ装置２の発行権限しか取得することができず、発行依頼装置３の発行権限を取得することができない。したがって、攻撃者は、クライアントのクレデンシャルを取得することができない。よって、上記実施形態は、既存モデルより高い安全性を有すると言える。
このように、サービス提供者のサーバ装置２が攻撃を受けた際のクレデンシャルの不正発行依頼を防ぐために、新たに発行依頼装置３を準備し、サービス提供者のサーバ装置２と発行依頼装置３の両者が発行依頼を行った場合にクレデンシャルの生成が可能とする。これにより、より安全性が高いクレデンシャルの生成を行うことができる。
［具体例１］
以下、具体例１として、D-TAを使用した認証システムの例を説明する。
以下、具体例１として、D-TAを使用した認証システムの例を説明する。
D-TAを使用した認証システムでは、１個以上のD-TA及び発行依頼局を用いる。発行依頼プロトコルとしては、HMACなどのメッセージ認証子、AESなどの公開鍵暗号、RSAやECCなどの公開鍵暗号等を使用することができる。
以下に説明する認証システムでは、発行依頼局として１個の発行依頼装置３、クレデンシャル発行装置４として２個のD-TAを使用する。２個のD-TAは、D-TA1, D-TA2である。クレデンシャルの発行依頼はHMACを用いることとし、HMACの鍵は、サービス提供者のサーバ装置とD-TA1との間、及び、発行依頼装置３とD-TA2との間で事前に安全に交換しているとする。認証プロトコルについては、M-pinプロトコルを利用する（例えば、非特許文献１参照。）。また、クライアントしか受け取ることができない方法として、サーバ装置２ではクライアントのメールアドレスへのクレデンシャル情報の一部の送付、発行依頼装置３ではクライアントのメールアドレス宛にURLを送信し、所定の時間内にURLにアクセスできた場合のみクレデンシャル情報の一部に送信をする方法で行う。
以下の説明で用いられる表記法や記号について記述する。
qは所定の素数である。G1,G2は、楕円曲線におけるq-torsion pointである。G3は、有限体の位数qの部分群である。e: G1×G2→G3はペアリング関数である。H1:{0,1}→G1は、ハッシュ関数である。P,Qは、それぞれG1,G2の生成元である。mailは、クライアントのメールアドレスである。Pは、クライアントIDであり、mailをハッシュ関数に入れ楕円曲線上の点にマッピングした座標である。sQは、サーバ装置２の秘密鍵である。k1,k2は、HMACの鍵である。サーバ装置２及びD-TA1がk1を保有し、発行依頼装置３及びD-TA2がk2を保有するとする。s1, s2は、マスターシークレットキーである。D-TA1がs1を保有し、D-TA2がs2を保有するとする。
＜ステップＳ１＞
クライアント端末１は、mailをサーバ装置２に送信する。mailが、クライアントの登録情報に対応する。
クライアント端末１は、mailをサーバ装置２に送信する。mailが、クライアントの登録情報に対応する。
＜ステップＳ２＞
P←H1(mail)。すなわち、サーバ装置２は、H1(mail)を計算しPに代入する。Pが、クライアント情報に対応する。
P←H1(mail)。すなわち、サーバ装置２は、H1(mail)を計算しPに代入する。Pが、クライアント情報に対応する。
＜ステップＳ３＞
tag1←HMAC(k1,P)。すなわち、サーバ装置２は、HMAC(k1,P)を計算し、tag1に代入する。
tag1←HMAC(k1,P)。すなわち、サーバ装置２は、HMAC(k1,P)を計算し、tag1に代入する。
そして、サーバ装置２は、P,tag1をクレデンシャル発行装置４のD-TA1に送信する。P,tag1が、発行依頼情報に対応する。
＜ステップＳ４＞
IF tag1=HMAC(k1,P), s1P←s1*P。すなわち、クレデンシャル発行装置４のD-TA1は、受信したPとk1を用いてHMAC(k1,P)を計算し、その計算結果が受信したtag1と一致するかどうかを判定する。一致すると判定された場合には、s1*Pを計算しs1Pに代入する。
IF tag1=HMAC(k1,P), s1P←s1*P。すなわち、クレデンシャル発行装置４のD-TA1は、受信したPとk1を用いてHMAC(k1,P)を計算し、その計算結果が受信したtag1と一致するかどうかを判定する。一致すると判定された場合には、s1*Pを計算しs1Pに代入する。
そして、クレデンシャル発行装置４のD-TA1は、s1Pをサーバ装置２に送信する。
s1Pが、クレデンシャルの一部に対応する。
＜ステップＳ５＞
a∈Zq *, aP←a*P, (s1-a)P←s1P-aP。すなわち、サーバ装置２は、a∈Zq *を選択し、a*Pを計算してaPに代入し、s1P-aPを計算して(s1-a)Pに代入する。
a∈Zq *, aP←a*P, (s1-a)P←s1P-aP。すなわち、サーバ装置２は、a∈Zq *を選択し、a*Pを計算してaPに代入し、s1P-aPを計算して(s1-a)Pに代入する。
そして、サーバ装置２は、P,(s1-a)Pをクライアント端末１に送信する。また、サーバ装置２は、aをメールアドレスmailに送信することより、クライアントにaを伝える。
＜ステップＳ６＞
aP←a*P, s1P←(s1-a)P+aP。すなわち、クライアント端末１は、a*Pを計算してaPに代入し、(s1-a)P+aPを計算してs1Pに代入する。
aP←a*P, s1P←(s1-a)P+aP。すなわち、クライアント端末１は、a*Pを計算してaPに代入し、(s1-a)P+aPを計算してs1Pに代入する。
s1Pが、クレデンシャルの一部に対応する。
＜ステップＳ７＞
クライアント端末１は、mail,Pを発行依頼装置３に送信する。mail,Pが、クライアントの登録情報に対応する。
クライアント端末１は、mail,Pを発行依頼装置３に送信する。mail,Pが、クライアントの登録情報に対応する。
＜ステップＳ８＞
この例では、ステップＳ８の処理は行われない。
この例では、ステップＳ８の処理は行われない。
＜ステップＳ９＞
tag2←HMAC(k2,P)。すなわち、サーバ装置２は、HMAC(k2,P)を計算し、tag2に代入する。
tag2←HMAC(k2,P)。すなわち、サーバ装置２は、HMAC(k2,P)を計算し、tag2に代入する。
そして、サーバ装置２は、P,tag2をクレデンシャル発行装置４のD-TA2に送信する。P,tag2が、発行依頼情報に対応する。
＜ステップＳ１０＞
IF tag2=HMAC(k2,P), s2P←s2*P。すなわち、クレデンシャル発行装置４のD-TA2は、受信したPとk2を用いてHMAC(k2,P)を計算し、その計算結果が受信したtag2と一致するかどうかを判定する。一致すると判定された場合には、s2Pを計算しs2Pに代入する。
IF tag2=HMAC(k2,P), s2P←s2*P。すなわち、クレデンシャル発行装置４のD-TA2は、受信したPとk2を用いてHMAC(k2,P)を計算し、その計算結果が受信したtag2と一致するかどうかを判定する。一致すると判定された場合には、s2Pを計算しs2Pに代入する。
そして、クレデンシャル発行装置４のD-TA2は、s2Pを発行依頼装置３に送信する。
s2Pが、クレデンシャルの他部に対応する。
＜ステップＳ１１＞
b∈Zq *, bP←b*P, (s2-b)P←s2P-bP。すなわち、発行依頼装置３は、b∈Zq *を選択し、b*Pを計算してbPに代入し、s2P-bPを計算して(s2-b)Pに代入する。
b∈Zq *, bP←b*P, (s2-b)P←s2P-bP。すなわち、発行依頼装置３は、b∈Zq *を選択し、b*Pを計算してbPに代入し、s2P-bPを計算して(s2-b)Pに代入する。
そして、発行依頼装置３は、(s1-a)Pをクライアント端末１に送信する。
また、発行依頼装置３は、メールアドレスmailに所定のURLを送信する。クライアントは、受信したURLにアクセスすることにより、発行依頼装置３からbを受信する。このようにして、発行依頼装置３は、クライアントにbを伝える。
＜ステップＳ１２＞
bP←b*P, s2P←(s2-b)P+bP。すなわち、クライアント端末１は、b*Pを計算してbPに代入し、(s2-b)P+bPを計算してs2Pに代入する。
bP←b*P, s2P←(s2-b)P+bP。すなわち、クライアント端末１は、b*Pを計算してbPに代入し、(s2-b)P+bPを計算してs2Pに代入する。
s2Pが、クレデンシャルの他部に対応する。
＜ステップＳ１３＞
sP←s1P+s2P。すなわち、クライアント端末１は、s1P+s2Pを計算してsPに代入する。
sP←s1P+s2P。すなわち、クライアント端末１は、s1P+s2Pを計算してsPに代入する。
sPが、クレデンシャルに対応する。この例では、sPが、以下で説明する認証に用いる鍵となる。
ステップＳ１４からステップＳ１７で、クライアント端末１とサーバ２装置との間で認証処理が行われる。
＜ステップＳ１４＞
x∈Zq *, U←x*P。すなわち、クライアント端末１は、x∈Zq *を選択し、x*Pを計算してUに代入する。
x∈Zq *, U←x*P。すなわち、クライアント端末１は、x∈Zq *を選択し、x*Pを計算してUに代入する。
そして、クライアント端末１は、mai,Uをサーバ装置２に送信する。
＜ステップＳ１５＞
y∈Zq *。すなわち、サーバ装置２は、y∈Zq *を選択する。
y∈Zq *。すなわち、サーバ装置２は、y∈Zq *を選択する。
そして、サーバ装置２は、yをクライアント端末１に送信する。
＜ステップＳ１６＞
V→-(x+y)((s-α)P+αP)。すなわち、クライアント端末１は、-(x+y)((s-α)P+αP)を計算し、Vに代入する。αは、クライアントが設定するpin番号である。また、s=s1+s2である。
V→-(x+y)((s-α)P+αP)。すなわち、クライアント端末１は、-(x+y)((s-α)P+αP)を計算し、Vに代入する。αは、クライアントが設定するpin番号である。また、s=s1+s2である。
そして、クライアント端末１は、yをサーバ装置２に送信する。
＜ステップＳ１７＞
P=H1(mail), g=e(V,Q)・e(U+yP,sQ), IF g≠1, reject the connection。すなわち、サーバ装置２は、H1(mail)を計算してPに代入し、e(V,Q)・e(U+yP,sQ)を計算してgに代入して、g≠1であるか判定する。
P=H1(mail), g=e(V,Q)・e(U+yP,sQ), IF g≠1, reject the connection。すなわち、サーバ装置２は、H1(mail)を計算してPに代入し、e(V,Q)・e(U+yP,sQ)を計算してgに代入して、g≠1であるか判定する。
そして、サーバ装置２は、g≠1であればクライアント端末１の接続を切断し、g≠1でなければクライアント端末１の認証は成功したとする。
［具体例２］
以下、具体例２として、PKIを使用した認証システムの例を説明する。
以下、具体例２として、PKIを使用した認証システムの例を説明する。
PKIを使用した認証システムでは、１個以上のCA及び発行依頼局を用いる。発行依頼プロトコルとしては、HMACなどのメッセージ認証子、AESなどの公開鍵暗号、RSAやECCなどの公開鍵暗号等を使用することができる。
以下に記述する認証システムは、発行依頼局として１個の発行依頼装置３、クレデンシャル発行装置４として１個のCAを使用する。以下では、CAのことをクレデンシャル発行装置４と表記する。また、発行依頼プロトコルとしてRSAの公開鍵暗号を使用する。発行依頼で使用する公開鍵は、サーバ装置２とクレデンシャル発行装置４との間、及び、発行依頼装置３とクレデンシャル発行装置４との間で安全に交換しているとする。認証プロトコルについては、証明書を用いたRSA署名を利用する。また、クライアントしか受け取ることができない方法として、サーバ装置２及び発行依頼装置３ではメールアドレスへの鍵情報の一部の送付を行う。
＜ステップＳ１＞
クライアント端末１は、証明書に必要なIDやメールアドレスであるクライアントの登録情報をサーバ装置２に送信する。
クライアント端末１は、証明書に必要なIDやメールアドレスであるクライアントの登録情報をサーバ装置２に送信する。
＜ステップＳ２＞
サーバ装置２は、クライアントの登録情報から、クレデンシャルの発行に必要なCSRを作成する。
サーバ装置２は、クライアントの登録情報から、クレデンシャルの発行に必要なCSRを作成する。
＜ステップＳ３＞
サーバ装置２は、CSRに対して、自身のRSA秘密鍵で署名を作成し、CSRと署名をクレデンシャル発行装置４に送信する。CSRと署名が、発行依頼情報に対応する。
サーバ装置２は、CSRに対して、自身のRSA秘密鍵で署名を作成し、CSRと署名をクレデンシャル発行装置４に送信する。CSRと署名が、発行依頼情報に対応する。
＜ステップＳ４＞
CAであるクレデンシャル発行装置４は、受信した署名をサーバ装置２の公開鍵で検証し、検証結果が正しければCSRに沿って証明書を作成し、その証明書の署名値をランダムに二分割する。
CAであるクレデンシャル発行装置４は、受信した署名をサーバ装置２の公開鍵で検証し、検証結果が正しければCSRに沿って証明書を作成し、その証明書の署名値をランダムに二分割する。
そして、クレデンシャル発行装置４は、証明証の署名前証明書と署名アルゴリズムと分割した一方の署名値とをサーバ装置２に送信する。分割した一方の署名値が、クレデンシャルの一部に対応する。
＜ステップＳ５＞
サーバ装置２は、受信した証明書の署名値をランダムに二分割し、片方をクライアントのみが得られる方法（メールアドレスに情報を送信するなど）で送信し、残りをクライアント端末１に送信する。
サーバ装置２は、受信した証明書の署名値をランダムに二分割し、片方をクライアントのみが得られる方法（メールアドレスに情報を送信するなど）で送信し、残りをクライアント端末１に送信する。
＜ステップＳ６＞
クライアント端末１は、クライアントがメールで受信した署名値と、クライアント端末１がサーバ装置２から受信した署名値を組み合わせて、署名値の一部を作成する。
クライアント端末１は、クライアントがメールで受信した署名値と、クライアント端末１がサーバ装置２から受信した署名値を組み合わせて、署名値の一部を作成する。
この署名値の一部が、クレデンシャルの一部に対応する。
＜ステップＳ７＞
クライアント端末１は、証明書に必要なIDやメールアドレスであるクライアントの登録情報を発行依頼装置３に送信する。
クライアント端末１は、証明書に必要なIDやメールアドレスであるクライアントの登録情報を発行依頼装置３に送信する。
＜ステップＳ８＞
発行依頼装置３は、クライアントの登録情報から、クレデンシャルの発行に必要なCSRを作成する。
発行依頼装置３は、クライアントの登録情報から、クレデンシャルの発行に必要なCSRを作成する。
＜ステップＳ９＞
発行依頼装置３は、CSRに対して、自身のRSA秘密鍵で署名を作成し、CSRと署名をクレデンシャル発行装置４に送信する。CSRと署名が、発行依頼情報に対応する。
発行依頼装置３は、CSRに対して、自身のRSA秘密鍵で署名を作成し、CSRと署名をクレデンシャル発行装置４に送信する。CSRと署名が、発行依頼情報に対応する。
＜ステップＳ１０＞
CAであるクレデンシャル発行装置４は、受信した署名を発行依頼装置３の公開鍵で検証し、検証結果が正しければ、ステップＳ４で生成された証明書の署名値の残り一部を発行依頼装置３に送信する。
CAであるクレデンシャル発行装置４は、受信した署名を発行依頼装置３の公開鍵で検証し、検証結果が正しければ、ステップＳ４で生成された証明書の署名値の残り一部を発行依頼装置３に送信する。
この署名値の残りの一部が、クレデンシャルの他部に対応する。
＜ステップＳ１１＞
発行依頼装置３は、受信した証明書の署名値をランダムに二分割し、片方をクライアントのみが得られる方法（メールアドレスに情報を送信するなど）で送信し、残りをクライアント端末１に送信する。
発行依頼装置３は、受信した証明書の署名値をランダムに二分割し、片方をクライアントのみが得られる方法（メールアドレスに情報を送信するなど）で送信し、残りをクライアント端末１に送信する。
＜ステップＳ１２＞
クライアント端末１は、クライアントがメールで受信した署名値と、クライアント端末１が発行依頼装置３から受信した署名値を組み合わせて、署名値の一部を作成する。
クライアント端末１は、クライアントがメールで受信した署名値と、クライアント端末１が発行依頼装置３から受信した署名値を組み合わせて、署名値の一部を作成する。
この署名値の一部が、クレデンシャルの他部に対応する。
＜ステップＳ１３＞
クライアント端末１は、ステップＳ６で作成された署名値の一部と、ステップＳ１２で作成された署名値の一部とを足し合わせることにより、完全な証明書を作成する．
こうした認証システムを構成することによって、発行依頼装置３という第三者への証明書発行機能を委託しながら、安全に証明書発行を行うことができる。
クライアント端末１は、ステップＳ６で作成された署名値の一部と、ステップＳ１２で作成された署名値の一部とを足し合わせることにより、完全な証明書を作成する．
こうした認証システムを構成することによって、発行依頼装置３という第三者への証明書発行機能を委託しながら、安全に証明書発行を行うことができる。
［変形例等］
発行依頼装置３及びクレデンシャル発行装置４の数は任意である。１つのクレデンシャル発行装置４にサーバ装置と複数の発行依頼装置３を使用したり、１つのサーバ装置と発行依頼装置３で複数のクレデンシャル発行装置４の発行依頼権限を保有したりしても良い。
発行依頼装置３及びクレデンシャル発行装置４の数は任意である。１つのクレデンシャル発行装置４にサーバ装置と複数の発行依頼装置３を使用したり、１つのサーバ装置と発行依頼装置３で複数のクレデンシャル発行装置４の発行依頼権限を保有したりしても良い。
また、クレデンシャル発行装置４からクライアント端末１までのクレデンシャルの配送方法についても、１つに限定するものではない。クライアントのクレデンシャル全体をサーバ装置２を経由して配送する方式でもよいし。クライアントのクレデンシャル全体をサーバ装置２と発行依頼装置３に分割して、両装置から送信してもよい。
また、サーバ装置２や発行依頼装置３からクライアントにクレデンシャルを配送する際も、メールアドレスなどをクライアントしか受け取れない方法を使用して分割配送してもよい。
その他、この発明の趣旨を逸脱しない範囲で適宜変更が可能であることはいうまでもない。
[プログラム及び記録媒体]
クライアント端末１、サーバ装置２、発行依頼装置３及びクレデンシャル発行装置４における各処理をコンピュータによって実現する場合、これらの端末及び装置が有すべき機能の処理内容はプログラムによって記述される。そして、このプログラムをコンピュータで実行することにより、これらの端末及び装置の処理がコンピュータ上で実現される。
クライアント端末１、サーバ装置２、発行依頼装置３及びクレデンシャル発行装置４における各処理をコンピュータによって実現する場合、これらの端末及び装置が有すべき機能の処理内容はプログラムによって記述される。そして、このプログラムをコンピュータで実行することにより、これらの端末及び装置の処理がコンピュータ上で実現される。
この処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、例えば、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリ等どのようなものでもよい。
また、各処理手段は、コンピュータ上で所定のプログラムを実行させることにより構成することにしてもよいし、これらの処理内容の少なくとも一部をハードウェア的に実現することとしてもよい。
１ クライアント端末
２ サーバ装置
３ 発行依頼措置
４ クレデンシャル発行装置
２ サーバ装置
３ 発行依頼措置
４ クレデンシャル発行装置
Claims (3)
- クライアント端末と、上記クライアント端末に対してサービスの提供を行うサーバ装置と、発行依頼装置と、クレデンシャル発行装置とを含み、上記クライアント端末のクレデンシャルを生成するクレデンシャル生成システムにおいて、
上記サーバ装置は、上記クレデンシャル発行装置に上記クライアント端末のクレデンシャルの発行を依頼し、
上記発行依頼装置は、上記クレデンシャル発行装置に上記クライアント端末のクレデンシャルの発行を依頼し、
上記クレデンシャル発行装置は、上記サーバ装置からのクレデンシャルの発行依頼に基づいて上記クライアント端末のクレデンシャルの一部を発行し、上記発行依頼装置からのクレデンシャルの発行依頼に基づいて上記クライアント端末のクレデンシャルの他部を発行し、
上記クライアント端末は、上記発行されたクレデンシャルの一部及びクレデンシャルの他部を用いて、上記クライアント端末のクレデンシャルを生成する、
クレデンシャル生成システム。 - 請求項１のクレデンシャル生成システムであって、
上記クレデンシャル発行装置は、上記発行したクレデンシャルの一部を上記サーバ装置を経由して上記クライアント端末に送信し、上記発行したクレデンシャルの他部を上記発行依頼装置を経由して上記クライアント端末に送信する、
クレデンシャル生成システム。 - クライアント端末と、上記クライアント端末に対してサービスの提供を行うサーバ装置と、発行依頼装置と、クレデンシャル発行装置により実行され、上記クライアント端末のクレデンシャルを生成するクレデンシャル生成方法において、
上記サーバ装置が、上記クレデンシャル発行装置に上記クライアント端末のクレデンシャルの発行を依頼するステップと、
上記発行依頼装置が、上記クレデンシャル発行装置に上記クライアント端末のクレデンシャルの発行を依頼するステップと、
上記クレデンシャル発行装置が、上記サーバ装置からのクレデンシャルの発行依頼に基づいて上記クライアント端末のクレデンシャルの一部を発行し、上記発行依頼装置からのクレデンシャルの発行依頼に基づいて上記クライアント端末のクレデンシャルの他部を発行するステップと、
上記クライアント端末が、上記発行されたクレデンシャルの一部及びクレデンシャルの他部を用いて、上記クライアント端末のクレデンシャルを生成するステップと、
を含むクレデンシャル生成方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2017038986A JP6765993B2 (ja) | 2017-03-02 | 2017-03-02 | クレデンシャル生成システム及び方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2017038986A JP6765993B2 (ja) | 2017-03-02 | 2017-03-02 | クレデンシャル生成システム及び方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2018148293A JP2018148293A (ja) | 2018-09-20 |
| JP6765993B2 true JP6765993B2 (ja) | 2020-10-07 |
Family
ID=63591594
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2017038986A Active JP6765993B2 (ja) | 2017-03-02 | 2017-03-02 | クレデンシャル生成システム及び方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP6765993B2 (ja) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110837633B (zh) * | 2019-10-16 | 2021-10-08 | 支付宝(杭州)信息技术有限公司 | 智能凭证实现方法、系统及可读存储介质 |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6885747B1 (en) * | 1997-02-13 | 2005-04-26 | Tec.Sec, Inc. | Cryptographic key split combiner |
| JP4194745B2 (ja) * | 2000-09-19 | 2008-12-10 | 株式会社エヌ・ティ・ティ・データ | 電子署名システム及び電子署名方法 |
| JP3983561B2 (ja) * | 2002-02-04 | 2007-09-26 | 株式会社エヌ・ティ・ティ・ドコモ | 秘密分散法による鍵管理システム、検証センタ、通信端末、検証センタ用プログラム、通信端末用プログラム、並びに秘密分散法による鍵管理方法 |
| JP4908941B2 (ja) * | 2006-06-16 | 2012-04-04 | 株式会社三井住友銀行 | 初期パスワード発行処理方法およびシステム |
| JP5167835B2 (ja) * | 2008-01-29 | 2013-03-21 | 大日本印刷株式会社 | 利用者認証システム、および方法、プログラム、媒体 |
| JP6195526B2 (ja) * | 2014-02-13 | 2017-09-13 | 新日鉄住金ソリューションズ株式会社 | 決済システム、決済装置、決済管理方法及びプログラム |
| JP2016053879A (ja) * | 2014-09-04 | 2016-04-14 | キヤノン株式会社 | ファイル管理システム、管理サーバ、ファイル管理方法およびコンピュータプログラム |
-
2017
- 2017-03-02 JP JP2017038986A patent/JP6765993B2/ja active Active
Also Published As
| Publication number | Publication date |
|---|---|
| JP2018148293A (ja) | 2018-09-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11757662B2 (en) | Confidential authentication and provisioning | |
| AU2019240671B2 (en) | Methods for secure cryptogram generation | |
| WO2021114923A1 (zh) | 针对隐私数据的数据存储、数据读取方法及装置 | |
| EP3642997B1 (en) | Secure communications providing forward secrecy | |
| US10637818B2 (en) | System and method for resetting passwords on electronic devices | |
| US9673979B1 (en) | Hierarchical, deterministic, one-time login tokens | |
| JP2019509667A (ja) | データ転送方法、データ使用のコントロール方法、および、暗号デバイス | |
| US11368314B2 (en) | Secure digital signing | |
| CN106992978B (zh) | 网络安全管理方法及服务器 | |
| KR20220030298A (ko) | 참여 엔티티에 대한 네트워크 식별자를 사용하여 블록체인과 연관된 트랜잭션을 용이하게 하는 컴퓨터 구현 시스템 및 방법 | |
| JP6765993B2 (ja) | クレデンシャル生成システム及び方法 | |
| KR101371054B1 (ko) | 일회용 비밀번호와 서명 패스워드를 이용한 비대칭키 전자 서명 및 인증 방법 | |
| JP6093664B2 (ja) | 秘密鍵発行装置、公開鍵暗号システム、電子署名システム、秘密鍵発行方法およびコンピュータプログラム | |
| US20240012933A1 (en) | Integration of identity access management infrastructure with zero-knowledge services | |
| RU2771928C2 (ru) | Безопасный обмен данными, обеспечивающий прямую секретность | |
| Nagasuresh et al. | Defense against Illegal Use of Single Sign on Mechanism for Distributed Network Services |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20190304 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20200131 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20200303 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20200424 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20200915 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20200916 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6765993 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |