JP2020014168A - 電子署名システム、証明書発行システム、鍵管理システム及び電子証明書発行方法 - Google Patents
電子署名システム、証明書発行システム、鍵管理システム及び電子証明書発行方法 Download PDFInfo
- Publication number
- JP2020014168A JP2020014168A JP2018136657A JP2018136657A JP2020014168A JP 2020014168 A JP2020014168 A JP 2020014168A JP 2018136657 A JP2018136657 A JP 2018136657A JP 2018136657 A JP2018136657 A JP 2018136657A JP 2020014168 A JP2020014168 A JP 2020014168A
- Authority
- JP
- Japan
- Prior art keywords
- certificate
- key management
- user
- key
- management system
- 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.)
- Granted
Links
Images
Abstract
【課題】利用者の負担を低減できるとともに安全に電子証明書の発行、登録が可能な電子署名システムを提供することを目的とする。【解決手段】端末装置１０は、鍵管理サーバ３０に対して認証要求を行い、認証が成功した場合、鍵管理サーバ３０は、端末装置１０に対して認可コードを送信し、端末装置１０は、認可コードを証明書発行サーバ２０に送付し、証明書発行サーバ２０は、端末装置１０から送付された認可コードを鍵管理サーバ３０に送付し、鍵管理サーバ３０は、認可コードと引き換えにアクセストークンを証明書発行サーバ２０に送付し、証明書発行サーバ２０は、アクセストークンを鍵管理サーバ３０に提示することによって、鍵管理サーバ３０より証明書署名要求を入手し、証明書署名要求に記載されている公開鍵に対して電子証明書を発行する。【選択図】図５
Description
本発明は、電子署名システム及び電子証明書発行方法に関し、特に、公開鍵基盤で必要とされる電子署名と共に用いられる電子証明書を発行するための方法に関する。
全世界的に電子政府が稼働し始め、従来、紙で行われてきた契約行為も電子的に行われるようになってきた。電子的に行われる契約（電子契約）では、暗号技術や公開鍵基盤を用いた方式が主流である。
公開鍵基盤を用いた電子契約では、公開鍵暗号方式をベースとして、文書の送り側では、本人の私有鍵（秘密鍵）を用いて契約文書（電子データ）に電子署名を付与し、文書の受け取り側では、送り側の公開鍵を用いて契約文書に付与される電子署名を検証することで、なり済ましや、通信経路での改竄の有無を判断することが出来る。後述するが、公開鍵基盤は、公開鍵と、それと対になる私有鍵（秘密鍵）と、を用いて様々なセキュリティシステムを提供することができる。
この方式では、契約文書の検証時に契約書に電子署名を施した相手方（送り側）の公開鍵が必要となる。そして、この公開鍵と対になる私有鍵が送り側の所有に係ること（公開鍵の本人性）を証明するため、公開鍵証明書、いわゆる「電子証明書」が用いられる。
公開鍵基盤を用いた電子契約では、公開鍵暗号方式をベースとして、文書の送り側では、本人の私有鍵（秘密鍵）を用いて契約文書（電子データ）に電子署名を付与し、文書の受け取り側では、送り側の公開鍵を用いて契約文書に付与される電子署名を検証することで、なり済ましや、通信経路での改竄の有無を判断することが出来る。後述するが、公開鍵基盤は、公開鍵と、それと対になる私有鍵（秘密鍵）と、を用いて様々なセキュリティシステムを提供することができる。
この方式では、契約文書の検証時に契約書に電子署名を施した相手方（送り側）の公開鍵が必要となる。そして、この公開鍵と対になる私有鍵が送り側の所有に係ること（公開鍵の本人性）を証明するため、公開鍵証明書、いわゆる「電子証明書」が用いられる。
「電子証明書」はインターネット上の身分証とも呼ばれ、信頼できる第三者機関（ＴＴＰ：Trusted Third Party）によって発行される。特に、電子証明書を発行するＴＴＰを認証局と呼ぶ。
従来、電子署名は利用者のＰＣ（Personal Computer）上で行われることが一般的であったが、サーバ上で行うことにより電子署名の利便性を高めた仕組みも知られている。
例えば、特許文献１には、ユーザ端末、電子署名サーバ、認証局と、を備えたシステムが開示されている。
特許文献１においては、認証局が秘密鍵、公開鍵の鍵ペアを生成する。そして、電子署名サーバは、認証局に対して公開鍵に基づく電子証明書の発行を要求する。認証局は、発行した電子証明書と秘密鍵とをＰＫＣＳ＃１２と呼ばれるファイルとして電子署名サーバに供給し、電子署名サーバは、ユーザ端末からの求めに応じて、電子証明書、秘密鍵を用いて電子署名を行う。
従来、電子署名は利用者のＰＣ（Personal Computer）上で行われることが一般的であったが、サーバ上で行うことにより電子署名の利便性を高めた仕組みも知られている。
例えば、特許文献１には、ユーザ端末、電子署名サーバ、認証局と、を備えたシステムが開示されている。
特許文献１においては、認証局が秘密鍵、公開鍵の鍵ペアを生成する。そして、電子署名サーバは、認証局に対して公開鍵に基づく電子証明書の発行を要求する。認証局は、発行した電子証明書と秘密鍵とをＰＫＣＳ＃１２と呼ばれるファイルとして電子署名サーバに供給し、電子署名サーバは、ユーザ端末からの求めに応じて、電子証明書、秘密鍵を用いて電子署名を行う。
さらに近年では、「リモート署名」あるいは「クラウド署名」と呼ばれるという仕組みが普及をはじめ、そして、ヨーロッパ諸国のｅＩＤＡＳやＡｄｏｂｅ社をはじめとした標準化団体ＣＳＣ（Cloud Signature Consortium）などで、プロトコルの標準化が推し進められている。
より具体的には、電子署名サイトなどで電子署名が必要な状況になると、OAuth2.0によるＳＳＯ（Single Sign On）の仕組みなどを用いて、利用者が鍵管理システムへリダイレクトされ、鍵管理システムは、ユーザ認証後にトークンを払い出す。そのトークンを取得した電子署名サイトは、トークンを鍵管理システムに対して提示することで、鍵管理システムに署名を行わせる、といった仕組みが「リモート署名」として実装され始めている。
より具体的には、電子署名サイトなどで電子署名が必要な状況になると、OAuth2.0によるＳＳＯ（Single Sign On）の仕組みなどを用いて、利用者が鍵管理システムへリダイレクトされ、鍵管理システムは、ユーザ認証後にトークンを払い出す。そのトークンを取得した電子署名サイトは、トークンを鍵管理システムに対して提示することで、鍵管理システムに署名を行わせる、といった仕組みが「リモート署名」として実装され始めている。
しかしながら、このような「リモート署名」を行うために、利用者は、鍵管理システムに予めアカウントを作成し、さらに鍵管理システムにて私有鍵（秘密鍵）を生成し、その私有鍵に対して認証局から発行された電子証明書をバインドする、という準備が必要となる。
この準備作業において、利用者は、認証局に電子証明書の発行させるために、鍵管理システムで私有鍵（秘密鍵）とともに生成された公開鍵を鍵管理システムから取得（ダウンロード）し、公開鍵を含む鍵署名要求（証明書署名要求）を認証局に対して行う必要があった。
この準備作業において、利用者は、認証局に電子証明書の発行させるために、鍵管理システムで私有鍵（秘密鍵）とともに生成された公開鍵を鍵管理システムから取得（ダウンロード）し、公開鍵を含む鍵署名要求（証明書署名要求）を認証局に対して行う必要があった。
さらに利用者は、発行された電子証明書を鍵管理システムに対して格納しなければならない。
このような作業は利用者にとって煩雑なものであるとともに、技術的な負担を強いるものである。さらにこのような準備作業を利用者に行わせると、鍵管理システムの選択を利用者に委ねることになり、認証局側で鍵管理システムのセキュリティーレベルをコントロールすることが難しいという問題もある。
本発明は上記の問題点を鑑みてなされたものであり、電子署名に必要な電子証明書を発行して鍵管理システムに格納させる処理を、より安全に且つ利用者の負担を軽減しながら実行可能な電子署名システムを提供することを目的とする。
このような作業は利用者にとって煩雑なものであるとともに、技術的な負担を強いるものである。さらにこのような準備作業を利用者に行わせると、鍵管理システムの選択を利用者に委ねることになり、認証局側で鍵管理システムのセキュリティーレベルをコントロールすることが難しいという問題もある。
本発明は上記の問題点を鑑みてなされたものであり、電子署名に必要な電子証明書を発行して鍵管理システムに格納させる処理を、より安全に且つ利用者の負担を軽減しながら実行可能な電子署名システムを提供することを目的とする。
上記の課題を解決するために、本発明は、電子証明書を発行する証明書発行システムと、利用者の秘密鍵を管理する機能を有し、前記秘密鍵を用いて電子署名を生成する鍵管理システムと、利用者が利用する端末装置と、を備える電子署名システムであって、前記端末装置は、前記鍵管理システムに対して前記利用者の認証を要求し、前記認証が成功した場合、前記鍵管理システムは、前記端末装置に対して認可コードを送信し、前記認可コードを取得した前記端末装置は、前記認可コードを前記証明書発行システムに転送し、前記認可コードを取得した前記証明書発行システムは、前記認可コードを前記鍵管理システムに送信することによりアクセストークンを要求し、前記鍵管理システムは、前記アクセストークンを前記証明書発行システムに送信し、前記証明書発行システムは、前記アクセストークンを前記鍵管理システムに提示することによって、前記鍵管理システムから前記利用者の公開鍵を含む証明書発行要求を取得し、前記公開鍵に対して電子証明書を発行する、ことを特徴とする。
上記のように構成することにより、本発明によれば、電子署名に必要な電子証明書を発行して鍵管理システムに格納させる処理を、より安全に且つ利用者の負担を軽減しながら実行可能な電子署名システムを実現することが出来る。
以下に、図面を参照して本発明の実施の形態を詳細に説明する。
まず、本実施形態の説明に先立って前提となる技術を説明する。
まず、本実施形態の説明に先立って前提となる技術を説明する。
［公開鍵基盤］
公開鍵基盤（ＰＫＩ：Public Key Infrastructure）は、公開鍵暗号方式と呼ばれる暗号方式を用い、暗号化、デジタル署名（電子署名）、認証といったセキュリティ機能を提供する情報セキュリティ基盤である。
公開鍵基盤では、公開鍵暗号方式の特徴を利用し、上述の暗号化、デジタル署名、認証といった機能を提供する。公開鍵暗号方式では、私有鍵と公開鍵の一方向性（私有鍵から公開鍵を計算できるが、公開鍵から私有鍵を計算するのは計算量的に困難であるという特徴）を利用して様々な機能を提供する。利用者は自らの私有鍵を秘密裏に保持し、公開鍵を他者に公開しておく。私有鍵は、秘密に保持するという意味を持たせて秘密鍵とも呼ぶ。
例えば利用者Ｂは、利用者Ａに文書を送信するとき、利用者Ａが公開している公開鍵を入手し、その公開鍵を使って暗号化した文書を利用者Ａに送信する。利用者Ａは受信した暗号化文書を、自身の私有鍵（秘密鍵）を用いて復号化する。
利用者Ａの公開鍵を持っていれば誰もが利用者Ａに対して暗号化文書を送信することが出来る一方で、利用者Ａの公開鍵で暗号化したものは、利用者Ａの私有鍵（秘密鍵）でしか復号できないため、仮に悪意の第三者が利用者Ａの公開鍵を入手したとしても、暗号化文書の内容が漏えいすることはない。
公開鍵基盤（ＰＫＩ：Public Key Infrastructure）は、公開鍵暗号方式と呼ばれる暗号方式を用い、暗号化、デジタル署名（電子署名）、認証といったセキュリティ機能を提供する情報セキュリティ基盤である。
公開鍵基盤では、公開鍵暗号方式の特徴を利用し、上述の暗号化、デジタル署名、認証といった機能を提供する。公開鍵暗号方式では、私有鍵と公開鍵の一方向性（私有鍵から公開鍵を計算できるが、公開鍵から私有鍵を計算するのは計算量的に困難であるという特徴）を利用して様々な機能を提供する。利用者は自らの私有鍵を秘密裏に保持し、公開鍵を他者に公開しておく。私有鍵は、秘密に保持するという意味を持たせて秘密鍵とも呼ぶ。
例えば利用者Ｂは、利用者Ａに文書を送信するとき、利用者Ａが公開している公開鍵を入手し、その公開鍵を使って暗号化した文書を利用者Ａに送信する。利用者Ａは受信した暗号化文書を、自身の私有鍵（秘密鍵）を用いて復号化する。
利用者Ａの公開鍵を持っていれば誰もが利用者Ａに対して暗号化文書を送信することが出来る一方で、利用者Ａの公開鍵で暗号化したものは、利用者Ａの私有鍵（秘密鍵）でしか復号できないため、仮に悪意の第三者が利用者Ａの公開鍵を入手したとしても、暗号化文書の内容が漏えいすることはない。
[電子証明書]
公開鍵暗号方式で通信を行うには、通信相手に公開鍵を送信することになるが、ネットワーク経由での通信では通信相手が見えないため、第三者が通信相手に成りすまして公開鍵を送信する可能性がある。従って、公開鍵が本当に正しい相手から送られてきたものであるかを確認する必要がある。
ＰＫＩでは、例えば、信頼できる第三者機関（ＴＴＰ：Trusted Third Party）が、私有鍵の所有者を保証する。すなわち、ＴＴＰは私有鍵（秘密鍵）の所有者の本人性を確認し、私有鍵（秘密鍵）と対になる公開鍵とその私有鍵（秘密鍵）の所有者とを紐づける電子証明書（公開鍵証明書）を発行する。電子証明書は持ち主の情報を正しく保障する「身分証明書」である。
電子証明書を発行するＴＴＰは、特に認証局あるいは認証機関（ＣＡ：Certification Authority）と呼ばれる。
電子証明書には、公開鍵と、その公開鍵に対応する私有鍵（秘密鍵）の所有者を証明する所有者の名前、所属組織名、メールアドレス等の情報が記載されており、さらに電子証明書自体の改ざんを防ぐためにＴＴＰの電子署名が付与されている。電子証明書を文書に付すことで、なりすましや、改ざんなどのリスクを未然に防ぐことが出来る。また、ＴＴＰに信頼される私有鍵（秘密鍵）の所有者を加入者(Subscriber、サブスクライバー)という。
公開鍵暗号方式で通信を行うには、通信相手に公開鍵を送信することになるが、ネットワーク経由での通信では通信相手が見えないため、第三者が通信相手に成りすまして公開鍵を送信する可能性がある。従って、公開鍵が本当に正しい相手から送られてきたものであるかを確認する必要がある。
ＰＫＩでは、例えば、信頼できる第三者機関（ＴＴＰ：Trusted Third Party）が、私有鍵の所有者を保証する。すなわち、ＴＴＰは私有鍵（秘密鍵）の所有者の本人性を確認し、私有鍵（秘密鍵）と対になる公開鍵とその私有鍵（秘密鍵）の所有者とを紐づける電子証明書（公開鍵証明書）を発行する。電子証明書は持ち主の情報を正しく保障する「身分証明書」である。
電子証明書を発行するＴＴＰは、特に認証局あるいは認証機関（ＣＡ：Certification Authority）と呼ばれる。
電子証明書には、公開鍵と、その公開鍵に対応する私有鍵（秘密鍵）の所有者を証明する所有者の名前、所属組織名、メールアドレス等の情報が記載されており、さらに電子証明書自体の改ざんを防ぐためにＴＴＰの電子署名が付与されている。電子証明書を文書に付すことで、なりすましや、改ざんなどのリスクを未然に防ぐことが出来る。また、ＴＴＰに信頼される私有鍵（秘密鍵）の所有者を加入者(Subscriber、サブスクライバー)という。
[電子署名]
電子証明書はさらに、電子署名を検証する用途に用いられる。通常、電子署名には、電子証明書を添付する。電子署名を受け取った利用者は、電子証明書に記載された公開鍵を使って署名を検証し、データの改ざん検知を行い、電子証明書に記載された内容を使って署名者の特定を行うことが出来る。
電子署名には、文書のハッシュ値を私有鍵（秘密鍵）で暗号化した値が含まれる（実際には、暗号処理と署名処理は異なるが、署名処理のことを広義の暗号化と呼ぶことが多い）。利用者Ａが利用者Ｂに対して電子署名を付した文書ファイルを送る場合、利用者Ａは、送信する文書ファイルをハッシュ関数にかけることによって得たハッシュ値を利用者Ａの私有鍵（秘密鍵）を用いて暗号化し、電子署名を作成して、文書ファイルに添付する。
電子署名付きの文書ファイルを受け取った利用者Ｂは、電子署名に含まれる暗号化された値を利用者Ａの公開鍵を使って復号化することによって得たハッシュ値と、文書ファイルをハッシュ関数にかけることによって得たハッシュ値と、を比較する。比較の結果、双方のハッシュ値が同一であれば、文書が改ざんされていないことが証明される。
電子証明書はさらに、電子署名を検証する用途に用いられる。通常、電子署名には、電子証明書を添付する。電子署名を受け取った利用者は、電子証明書に記載された公開鍵を使って署名を検証し、データの改ざん検知を行い、電子証明書に記載された内容を使って署名者の特定を行うことが出来る。
電子署名には、文書のハッシュ値を私有鍵（秘密鍵）で暗号化した値が含まれる（実際には、暗号処理と署名処理は異なるが、署名処理のことを広義の暗号化と呼ぶことが多い）。利用者Ａが利用者Ｂに対して電子署名を付した文書ファイルを送る場合、利用者Ａは、送信する文書ファイルをハッシュ関数にかけることによって得たハッシュ値を利用者Ａの私有鍵（秘密鍵）を用いて暗号化し、電子署名を作成して、文書ファイルに添付する。
電子署名付きの文書ファイルを受け取った利用者Ｂは、電子署名に含まれる暗号化された値を利用者Ａの公開鍵を使って復号化することによって得たハッシュ値と、文書ファイルをハッシュ関数にかけることによって得たハッシュ値と、を比較する。比較の結果、双方のハッシュ値が同一であれば、文書が改ざんされていないことが証明される。
［リモート署名］
様々なクラウドサービス、オンラインサービスが提供され、クラウド上（サーバ上）で文書を扱うことが多くなっている。それに伴い、文書に対する電子署名を署名者のＰＣ（Personal Computer）上ではなく、サーバ上（クラウド上）で行う「リモート署名（クラウド署名）」と呼ばれる方式の電子署名が普及しつつある。
より詳しくは、リモート署名とは、署名者の電子証明書、私有鍵（秘密鍵）を鍵管理システムで管理し、電子署名が必要なときには、鍵管理システム上で電子証明書、私有鍵（秘密鍵）を用いた電子署名を実行する仕組みである。
様々なクラウドサービス、オンラインサービスが提供され、クラウド上（サーバ上）で文書を扱うことが多くなっている。それに伴い、文書に対する電子署名を署名者のＰＣ（Personal Computer）上ではなく、サーバ上（クラウド上）で行う「リモート署名（クラウド署名）」と呼ばれる方式の電子署名が普及しつつある。
より詳しくは、リモート署名とは、署名者の電子証明書、私有鍵（秘密鍵）を鍵管理システムで管理し、電子署名が必要なときには、鍵管理システム上で電子証明書、私有鍵（秘密鍵）を用いた電子署名を実行する仕組みである。
リモート署名には、署名者が私有鍵（秘密鍵）を自ら管理する必要が無いという利点がある。さらに、ＰＣのみならず、ウェブブラウザやスマートフォンなどのモバイルデバイスによっても文書に電子署名が可能である。従って、私有鍵（秘密鍵）を格納したスマートカードやＵＳＢトークン等を用いたエンドポイントでの電子署名の生成に比べ、格段に利便性が向上する。さらに、鍵管理システムで私有鍵（秘密鍵）が堅牢に保護されるため、セキュリティの観点からも、より望ましい署名方法であると言える。
上記のように、リモート署名のサービスを提供する署名システムでは、署名を行うために署名者の私有鍵（秘密鍵）と、それに紐づけた電子証明書と、が必要である。
下記に説明するが、私有鍵（秘密鍵）と公開鍵の鍵ペアは鍵管理システムで生成するものであるが、電子証明書は、私有鍵（秘密鍵）の所有者の身分を保障する認証局によって発行されるものであり、前述した理由により、鍵管理システムには、発行された電子証明書を適宜インポートする必要がある。
電子証明書のインポートは、署名システムにおいてリモート署名をおこなうための準備作業である。
下記に説明するが、私有鍵（秘密鍵）と公開鍵の鍵ペアは鍵管理システムで生成するものであるが、電子証明書は、私有鍵（秘密鍵）の所有者の身分を保障する認証局によって発行されるものであり、前述した理由により、鍵管理システムには、発行された電子証明書を適宜インポートする必要がある。
電子証明書のインポートは、署名システムにおいてリモート署名をおこなうための準備作業である。
現状、そのような準備作用として、鍵管理システムが生成した公開鍵に基づいて認証局で生成された電子証明書を鍵管理システムにインポート（格納）するには、利用者（署名者）自身による以下のような手順が必要であった。
すなわち、
（１）利用者が自身の端末装置を用いて鍵管理システムにアカウントを作成する。
（２）利用者が自身の端末装置を用いて鍵管理システムにログインし、鍵管理システムで鍵ペアを生成する。
（３）利用者が自身の端末装置を用いて鍵管理システムにログインし、鍵管理システムに証明書署名要求（ＣＳＲ：Certificate Signing Request）を生成させ、ダウンロードする。証明書署名要求は、証明書発行要求ともいう。
（４）利用者が自身の端末装置を用いて、（３）で取得した証明書署名要求（ＣＳＲ）を認証局に送付する。
（５）認証局が上記証明書署名要求（ＣＳＲ）に基づいて電子証明書を発行して利用者に送付する。
（６）利用者が鍵管理システムにログインし、（５）で送付された電子証明書を鍵管理システムにインポートする。
すなわち、
（１）利用者が自身の端末装置を用いて鍵管理システムにアカウントを作成する。
（２）利用者が自身の端末装置を用いて鍵管理システムにログインし、鍵管理システムで鍵ペアを生成する。
（３）利用者が自身の端末装置を用いて鍵管理システムにログインし、鍵管理システムに証明書署名要求（ＣＳＲ：Certificate Signing Request）を生成させ、ダウンロードする。証明書署名要求は、証明書発行要求ともいう。
（４）利用者が自身の端末装置を用いて、（３）で取得した証明書署名要求（ＣＳＲ）を認証局に送付する。
（５）認証局が上記証明書署名要求（ＣＳＲ）に基づいて電子証明書を発行して利用者に送付する。
（６）利用者が鍵管理システムにログインし、（５）で送付された電子証明書を鍵管理システムにインポートする。
このような準備作業では、利用者が自分で行う作業や手順が多く、また、技術的な知識も必要となるため、利用者に負担を強いるという問題があった。
また、認証局側の観点では、準備作業を利用者に行わせた結果、鍵管理システムの選択を利用者に委ねることになり、認証局側が鍵管理システムのセキュリティーレベルをコントロールすることが難しい、という問題があった。
また、認証局側の観点では、準備作業を利用者に行わせた結果、鍵管理システムの選択を利用者に委ねることになり、認証局側が鍵管理システムのセキュリティーレベルをコントロールすることが難しい、という問題があった。
当然、認証局自体は信頼できる第三者機関であるが、鍵管理システムの中には、必ずしも信頼がおけないものがある。鍵管理システムの信頼性とは、私有鍵（秘密鍵）を適切な方法で管理しているか否かである。リモート署名では、私有鍵（秘密鍵）や電子証明書を後述するＨＳＭ（Hardware Security Module）と呼ばれる装置で安全に管理することが要求される。そのような要求を満たしていない鍵管理システムを利用者が選択し、利用することにはセキュリティリスクが伴う。
そこで本実施形態において、認証局は、信頼性を担保出来る鍵管理システムを登録する。そして、後述するOAuth2.0によるＳＳＯ（Single Sign On）の仕組みを用いて、認証局と、信頼された鍵管理システムと、の間で公開鍵と電子証明書のやりとりを行うことで、利用者の負担を軽減しながら、信頼性の高い鍵管理システムを利用者に利用させることが出来る。
ＲＦＣ６７４９で定義されるOAuth2.0は、概略としては、リソースサーバが保有している保護リソース（重要情報や鍵等）をリソースオーナーの許可を得てクライアントが使用することができるようにする仕組みである。
そして、リソースサーバが保有する保護リソースに対するクライアントのアクセス可否を認可サーバがコントロールする。
保護リソースにアクセスするにはアクセストークン（Access token）と呼ばれる情報が必要であり、認可サーバは、アクセスを許可するクライアントに対してアクセストークン（Access token）を発行する。
そして、リソースサーバが保有する保護リソースに対するクライアントのアクセス可否を認可サーバがコントロールする。
保護リソースにアクセスするにはアクセストークン（Access token）と呼ばれる情報が必要であり、認可サーバは、アクセスを許可するクライアントに対してアクセストークン（Access token）を発行する。
また、上記に加えてユーザーエージェント（例えばウェブブラウザ）がアクセスの介在をする場合がある。その場合、認可サーバにおけるリソースオーナーの認証、及び、認可サーバからクライアントへの認可コード（Authorization code）の送付を、ユーザーエージェントが仲介して行う。なお、認可コードは、認可トークンとも呼ぶ。
図１は、ユーザーエージェントが介在するOAuth2.0の処理を説明する参考図である。
なお、図１の参考図は、ＲＦＣ６７４９に開示されている図である。
図１を用いて、本実施形態を構成する、認証局としての証明書発行サーバ、鍵管理システム、端末装置と、OAuth2.0で定義される各エンティティとの対応付けを行うとともに、各エンティティによるOAuth2.0の処理を説明する。
なお、本実施形態の証明書発行システムが上記「クライアント」に対応し、本実施形態の端末装置で実行されるウェブブラウザ（後述）が上記「ユーザーエージェント」に対応する。また、本実施形態の鍵管理システムが上記「認可サーバ」に対応し、端末装置の利用者が上記「リソースオーナー」に対応する。
なお、図１の参考図は、ＲＦＣ６７４９に開示されている図である。
図１を用いて、本実施形態を構成する、認証局としての証明書発行サーバ、鍵管理システム、端末装置と、OAuth2.0で定義される各エンティティとの対応付けを行うとともに、各エンティティによるOAuth2.0の処理を説明する。
なお、本実施形態の証明書発行システムが上記「クライアント」に対応し、本実施形態の端末装置で実行されるウェブブラウザ（後述）が上記「ユーザーエージェント」に対応する。また、本実施形態の鍵管理システムが上記「認可サーバ」に対応し、端末装置の利用者が上記「リソースオーナー」に対応する。
図１の（Ａ）において、クライアント（証明書発行サーバ）は、ユーザーエージェント（端末装置のウェブブラウザ）を経由してクライアントのＩＤ情報を認可サーバ（鍵管理システム）に送り（ＲＦＣ６７４９＃４．１．１．認可要求）、（Ｂ）において、認可サーバ（鍵管理システム）は、ユーザーエージェント（ウェブブラウザ）を経由してリソースオーナー（利用者）に認証・認可を実施する。
（Ｃ）において、認可サーバ（鍵管理システム）がリソースへのアクセスを許可する場合、認可サーバ（鍵管理システム）は、ユーザーエージェント（ウェブブラウザ）を経由してクライアント（証明書発行サーバ）に認可コード（Authorization code）を発行する（ＲＦＣ６７４９＃４．１．２．認可応答）。
（Ｄ）において、クライアント（証明書発行サーバ）は、認可コード（Authorization code）を提示することによって、認可サーバ（鍵管理システム）に対してアクセストークン（Access token）を要求する（ＲＦＣ６７４９＃４．１．３．アクセストークン要求）。
（Ｅ）において、認可サーバ（鍵管理システム）は、提示された認可コード（Authorization code）の検証に成功した場合、アクセストークン（Access token）をクライアント（証明書発行サーバ）に発行する（ＲＦＣ６７４９＃４．１．４．アクセストークン応答）。
（Ｃ）において、認可サーバ（鍵管理システム）がリソースへのアクセスを許可する場合、認可サーバ（鍵管理システム）は、ユーザーエージェント（ウェブブラウザ）を経由してクライアント（証明書発行サーバ）に認可コード（Authorization code）を発行する（ＲＦＣ６７４９＃４．１．２．認可応答）。
（Ｄ）において、クライアント（証明書発行サーバ）は、認可コード（Authorization code）を提示することによって、認可サーバ（鍵管理システム）に対してアクセストークン（Access token）を要求する（ＲＦＣ６７４９＃４．１．３．アクセストークン要求）。
（Ｅ）において、認可サーバ（鍵管理システム）は、提示された認可コード（Authorization code）の検証に成功した場合、アクセストークン（Access token）をクライアント（証明書発行サーバ）に発行する（ＲＦＣ６７４９＃４．１．４．アクセストークン応答）。
本実施形態においては、利用者を認証局（証明書発行システム）の電子証明書発行ページにアクセスさせる。そして、認証局は、予め信頼できると決められている鍵管理システムに利用者を転送して当該の鍵管理システムにログインさせる（図１（Ａ）の認可要求）。
利用者が鍵管理システムに対して行ったログイン認証が成功すると、鍵管理システムの認可コード（Authorization code）が、利用者（端末装置のウェブブラウザ）に送付され、この認可コード（Authorization code）は、認証局（証明書発行システム）に転送される（図１（Ｃ）の認可応答）。
認証局（証明書発行システム）は、この認可コード（Authorization code）を用いて、アクセストークン（Access token）の要求を鍵管理システムに対して行う（図１（Ｄ）のアクセストークン要求）。
認証局（証明書発行システム）は、鍵管理システムからアクセストークン（Access token）を付与される（図１（Ｅ）のアクセストークン応答）。
認証局（証明書発行システム）は、この認可コード（Authorization code）を用いて、アクセストークン（Access token）の要求を鍵管理システムに対して行う（図１（Ｄ）のアクセストークン要求）。
認証局（証明書発行システム）は、鍵管理システムからアクセストークン（Access token）を付与される（図１（Ｅ）のアクセストークン応答）。
さらに、本実施形態の特徴として、認証局（証明書発行システム）は、そのアクセストークン（Access token）を使って鍵管理システムに対して証明書署名要求（ＣＳＲ）の要求を行い、鍵管理システムから証明書署名要求（ＣＳＲ）を受け取ることで電子証明書の発行を行う。
このような本実施形態のシステムによれば、利用者による認証という要件を満たしながら、認証局（証明書発行システム）側で鍵管理システムに対する証明書署名要求（ＣＳＲ）の要求を行うことで、鍵管理システムから証明書署名要求（ＣＳＲ）を直接受け取って、電子証明書を発行して鍵管理システムに送信し、インポートさせることが出来る。
このような本実施形態のシステムによれば、利用者による認証という要件を満たしながら、認証局（証明書発行システム）側で鍵管理システムに対する証明書署名要求（ＣＳＲ）の要求を行うことで、鍵管理システムから証明書署名要求（ＣＳＲ）を直接受け取って、電子証明書を発行して鍵管理システムに送信し、インポートさせることが出来る。
以下に、本実施形態のシステム及びその処理をより詳しく説明する。
図２は、本実施形態のシステム構成を説明する図である。
図２に示すように、本実施形態のリモート署名システム１は、利用者の利用に係る端末装置１０と、ユーザの電子証明書を発行する証明書発行サーバ２０を含む証明書発行システム２と、ユーザの私有鍵（秘密鍵）及び公開鍵のペア、及び証明書発行サーバ２０が発行した電子証明書を管理してリモート署名のサービスを提供するための鍵管理サーバ３０を含む鍵管理システム３と、を備える。
端末装置１、証明書発行システム２、鍵管理システム３は、いずれもインターネットに接続され、互いに通信可能に構成されている。
これらの装置、システム間でやり取りされるデータの類は、おもにＨＴＴＰリクエストやＨＴＴＰレスポンスのパラメータとして（ＨＴＴＰプロトコルを利用して）送受信されるが、セキュリティ確保のため、通信自体は保護されるのが慣例である（例えば、ＨＴＴＰＳを利用する）。
図２は、本実施形態のシステム構成を説明する図である。
図２に示すように、本実施形態のリモート署名システム１は、利用者の利用に係る端末装置１０と、ユーザの電子証明書を発行する証明書発行サーバ２０を含む証明書発行システム２と、ユーザの私有鍵（秘密鍵）及び公開鍵のペア、及び証明書発行サーバ２０が発行した電子証明書を管理してリモート署名のサービスを提供するための鍵管理サーバ３０を含む鍵管理システム３と、を備える。
端末装置１、証明書発行システム２、鍵管理システム３は、いずれもインターネットに接続され、互いに通信可能に構成されている。
これらの装置、システム間でやり取りされるデータの類は、おもにＨＴＴＰリクエストやＨＴＴＰレスポンスのパラメータとして（ＨＴＴＰプロトコルを利用して）送受信されるが、セキュリティ確保のため、通信自体は保護されるのが慣例である（例えば、ＨＴＴＰＳを利用する）。
上記したように、証明書発行システム２が上記ＯＡｕｔｈにおけるクライアントに対応し、
端末装置１０で実行されるウェブブラウザがユーザーエージェントに対応する。また、鍵管理システム３が認可サーバに対応し、端末装置１０の利用者が上記リソースオーナーに対応する。
従って、証明書発行システム２を構成する証明書発行装置２０、鍵管理システム３を構成する鍵管理サーバ３０、端末装置１０のウェブブラウザは、夫々上記に説明したＯＡｕｔｈに準拠した処理を実行可能に構成されている。
端末装置１０で実行されるウェブブラウザがユーザーエージェントに対応する。また、鍵管理システム３が認可サーバに対応し、端末装置１０の利用者が上記リソースオーナーに対応する。
従って、証明書発行システム２を構成する証明書発行装置２０、鍵管理システム３を構成する鍵管理サーバ３０、端末装置１０のウェブブラウザは、夫々上記に説明したＯＡｕｔｈに準拠した処理を実行可能に構成されている。
端末装置１０は、ウェブブラウザ（ユーザーエージェント）を実行可能な一般的なＰＣやスマートフォンである。
端末装置１０のＣＰＵによって実行されるウェブブラウザは、証明書発行システム２０から提供する電子証明書発行ページを要求するページ要求手段、証明書発行サーバ２０から受信した転送ページ等を表示するページ表示手段、認可要求（Authorization request）を鍵管理サーバ３０に送信し、認可コード（Authorization code）を含む認可応答（Authorization response）を受信するＯＡｕｔｈ実行手段、ＫｅｙＡｌｉａｓとＰＩＮの入力を受け付けて鍵管理サーバ３０に送信する鍵情報送信手段、鍵管理サーバ３０から受信した認可コード（Authorization code）の証明書発行サーバ２０への転送等の処理を行う認可コード送信手段等として機能する。
端末装置１０のＣＰＵによって実行されるウェブブラウザは、証明書発行システム２０から提供する電子証明書発行ページを要求するページ要求手段、証明書発行サーバ２０から受信した転送ページ等を表示するページ表示手段、認可要求（Authorization request）を鍵管理サーバ３０に送信し、認可コード（Authorization code）を含む認可応答（Authorization response）を受信するＯＡｕｔｈ実行手段、ＫｅｙＡｌｉａｓとＰＩＮの入力を受け付けて鍵管理サーバ３０に送信する鍵情報送信手段、鍵管理サーバ３０から受信した認可コード（Authorization code）の証明書発行サーバ２０への転送等の処理を行う認可コード送信手段等として機能する。
証明書発行サーバ２０は、電子証明書を発行する認証局に属する。上記したように、認証局は、公開鍵基盤（ＰＫＩ：Public Key Infrastructure）で用いられる私有鍵の所有者を確認するために用いられる電子証明書を発行する機関である。
証明書発行システム２は、上記証明書発行サーバ２０に加え、利用者のウェブブラウザによるリクエストを受け付けて電子証明書発行ページのデータを端末装置１０に供給するウェブサーバをさらに備えてもよい。また、ウェブサーバの機能は、証明書発行サーバ２０自体が備えていてもよい。
証明書発行システム２は、上記証明書発行サーバ２０に加え、利用者のウェブブラウザによるリクエストを受け付けて電子証明書発行ページのデータを端末装置１０に供給するウェブサーバをさらに備えてもよい。また、ウェブサーバの機能は、証明書発行サーバ２０自体が備えていてもよい。
鍵管理システム３は、利用者の私有鍵（秘密鍵）、電子証明書を管理してリモート署名サービスを提供するシステムであり、要求に応じて電子署名を生成し、要求元に供給する。
本実施形態の鍵管理システム３は、例えば、鍵管理サーバ３０と、ハードウェアセキュリティモジュール（ＨＳＭ：Hardware Security Module）１００と、を備えている。
ＨＳＭ１００は、利用者の私有鍵（秘密鍵）と公開鍵のペアを生成し、認証局で発行された利用者の電子証明書をインポートして管理するとともに、私有鍵（秘密鍵）を用いて電子署名を生成する装置である。
本実施形態の鍵管理システム３は、例えば、鍵管理サーバ３０と、ハードウェアセキュリティモジュール（ＨＳＭ：Hardware Security Module）１００と、を備えている。
ＨＳＭ１００は、利用者の私有鍵（秘密鍵）と公開鍵のペアを生成し、認証局で発行された利用者の電子証明書をインポートして管理するとともに、私有鍵（秘密鍵）を用いて電子署名を生成する装置である。
本実施形態のシステムにおいて、ＨＳＭ１００は、例えば、鍵管理サーバ３０の内部バスに接続されるかたちで鍵管理サーバ３０に内蔵される。また、ＨＳＭ１００は、鍵管理サーバの外部バス（ＵＳＢバスなど）に接続されてもよい。
さらに、ＨＳＭ１００はネットワークインターフェイスを備え、ＨＳＭ１００単独でネットワークに接続可能とされてもよい。ＨＳＭ１００は、鍵管理サーバ３０と同一のローカルネットワーク、遠隔のネットワークにおいて、鍵管理サーバ３０と通信可能に接続される。
その場合、鍵管理サーバ３０は、ネットワーク経由で、端末装置１０からの要求に応じてＨＳＭ１００に鍵ペアの生成を命令し、証明書発行サーバ２０（認証局）から送信された電子証明書をＨＳＭ１００にインポートする。
さらに、ＨＳＭ１００はネットワークインターフェイスを備え、ＨＳＭ１００単独でネットワークに接続可能とされてもよい。ＨＳＭ１００は、鍵管理サーバ３０と同一のローカルネットワーク、遠隔のネットワークにおいて、鍵管理サーバ３０と通信可能に接続される。
その場合、鍵管理サーバ３０は、ネットワーク経由で、端末装置１０からの要求に応じてＨＳＭ１００に鍵ペアの生成を命令し、証明書発行サーバ２０（認証局）から送信された電子証明書をＨＳＭ１００にインポートする。
上記のＯＡｕｔｈの説明においても述べたが、図２に示すシステム１において、証明書発行サーバ２０によってリダイレクトされた利用者（端末装置１０で実行されるウェブブラウザ）が鍵管理サーバ３０に対して認証を要求し、認証が成功した際には、鍵管理サーバ３０は、端末装置１０（ウェブブラウザ）に対して認可コード（Authorization code）を送付する。
なお、鍵管理サーバ３０に対して認証の要求を行うか否か、認証が成功しても認可を確立させるか否かは、利用者自身の裁量で決定出来る。リダイレクト画面に示される認証要求の可否を確認するダイアログ画面において、利用者は、認証要求の可否を選択することが出来る。あるいは認証成功後に、認可確立の是非を確認するダイアログ画面において、利用者は、認証確立の是非を選択することが出来る。
なお、鍵管理サーバ３０に対して認証の要求を行うか否か、認証が成功しても認可を確立させるか否かは、利用者自身の裁量で決定出来る。リダイレクト画面に示される認証要求の可否を確認するダイアログ画面において、利用者は、認証要求の可否を選択することが出来る。あるいは認証成功後に、認可確立の是非を確認するダイアログ画面において、利用者は、認証確立の是非を選択することが出来る。
認可コード（Authorization code）を受け取った端末装置１０（ウェブブラウザ）は、その認可コード（Authorization code）を証明書発行サーバ２０に送付（転送）する。
証明書発行サーバ２０は、端末装置１０（ウェブブラウザ）より送付された認可コード（Authorization code）を鍵管理サーバ３０に送付し、鍵管理サーバ３０は、その認可コード（Authorization code）と引き換えにアクセストークン（Access token）を証明書発行サーバ２０に送付する。
証明書発行サーバ２０がアクセストークン（Access token）を鍵管理サーバ３０に提示することで、証明書発行サーバ２０は、鍵管理サーバ３０より証明書署名要求（ＣＳＲ）を入手することが出来る。そして、証明書発行サーバ２０は、証明書署名要求（ＣＳＲ）に記載されている公開鍵に対して電子証明書を発行する。
証明書発行サーバ２０は、端末装置１０（ウェブブラウザ）より送付された認可コード（Authorization code）を鍵管理サーバ３０に送付し、鍵管理サーバ３０は、その認可コード（Authorization code）と引き換えにアクセストークン（Access token）を証明書発行サーバ２０に送付する。
証明書発行サーバ２０がアクセストークン（Access token）を鍵管理サーバ３０に提示することで、証明書発行サーバ２０は、鍵管理サーバ３０より証明書署名要求（ＣＳＲ）を入手することが出来る。そして、証明書発行サーバ２０は、証明書署名要求（ＣＳＲ）に記載されている公開鍵に対して電子証明書を発行する。
なお、利用者が鍵管理サーバ３０に対して認証を要求した際に利用者のアカウントが鍵管理サーバ３０に存在しない場合、鍵管理サーバ３０は、利用者に新規アカウントの作成を促す。利用者が鍵管理サーバ３０に新規アカウントを作成した後、鍵管理サーバ３０は、その利用者（ウェブブラウザ）に対して認可コード（Authorization code）を送付することができる。
図３は、本実施形態の証明書発行サーバの構成を示す図であり、（ａ）は、ハードウェアによる機能構成を示す図、（ｂ）は、ソフトウェアによる機能構成を示す図である。
図３（ａ）に示すように、証明書発行サーバ２０は、装置全体の制御を行う汎用のオペレーティングシステムを実行するとともに、証明書発行サーバ２０の機能を実現するプログラムを実行するＣＰＵ（Central Processing Unit）２１と、ＣＰＵ２１による処理のために各種のプログラムや一時データ、変数が展開されるＲＡＭ（Random Access Memory）２２と、プログラムやデータが格納されるＨＤＤ（Hard Disk Drive）２３や不図示のＲＯＭ（Read Only Memory）と、証明書発行サーバ２０をネットワークに接続するためのネットワークＩ／Ｆ２４と、を備えている。
図３（ａ）に示すように、証明書発行サーバ２０は、装置全体の制御を行う汎用のオペレーティングシステムを実行するとともに、証明書発行サーバ２０の機能を実現するプログラムを実行するＣＰＵ（Central Processing Unit）２１と、ＣＰＵ２１による処理のために各種のプログラムや一時データ、変数が展開されるＲＡＭ（Random Access Memory）２２と、プログラムやデータが格納されるＨＤＤ（Hard Disk Drive）２３や不図示のＲＯＭ（Read Only Memory）と、証明書発行サーバ２０をネットワークに接続するためのネットワークＩ／Ｆ２４と、を備えている。
また、図３（ｂ）に示すように、ＣＰＵ２１は、処理部として、ウェブページ処理部５１と、ＯＡｕｔｈ実行処理部５２と、署名リクエスト要求処理部５３と、電子証明書発行処理部５４と、を実行する。
ウェブページ処理部５１は、所謂ウェブサーバとして機能し、端末装置１０からのＨＴＴＰリクエストに応じて、ＨＤＤ２３に格納されるウェブページ（ＨＴＭＬページ）のデータから電子証明書発行ページのデータを送信する。上記したように、ウェブページ処理部５１は、証明書発行サーバ２０とは異なる独立したサーバ装置（ウェブサーバ）として構成されてもよい。
すなわち、証明書発行サーバ２０は、電子証明書の発行を受け付けるためのウェブページ（電子証明書発行ページ）を供給して端末装置のウェブブラウザで表示させるためのウェブサーバの機能を有する。あるいは、証明書発行システム３は、バックエンドの証明書発行サーバ３０と、ユーザがアクセスするフロントエンドとしてのウェブサーバと、から構成されている。
ウェブページ処理部５１は、所謂ウェブサーバとして機能し、端末装置１０からのＨＴＴＰリクエストに応じて、ＨＤＤ２３に格納されるウェブページ（ＨＴＭＬページ）のデータから電子証明書発行ページのデータを送信する。上記したように、ウェブページ処理部５１は、証明書発行サーバ２０とは異なる独立したサーバ装置（ウェブサーバ）として構成されてもよい。
すなわち、証明書発行サーバ２０は、電子証明書の発行を受け付けるためのウェブページ（電子証明書発行ページ）を供給して端末装置のウェブブラウザで表示させるためのウェブサーバの機能を有する。あるいは、証明書発行システム３は、バックエンドの証明書発行サーバ３０と、ユーザがアクセスするフロントエンドとしてのウェブサーバと、から構成されている。
ＯＡｕｔｈ実行処理部５２は、鍵管理サーバ２０のＯＡｕｔｈ実行処理部６１とともに、所謂ＲＦＣ６７４９に規定されるOAuth2.0の認可処理を制御するための処理部であり、端末装置１０（ウェブブラウザ）から送信された認可コード（Authorization code）を用いて、鍵管理サーバ３０にアクセストークン（Access token）を要求する処理を行う。
署名リクエスト要求処理部５３は、ＯＡｕｔｈ実行処理部５２によって取得されたアクセストークン（Access token）を用いて、証明書署名要求（ＣＳＲ）を鍵管理サーバ２０に要求する処理を行う処理部である。
電子証明書発行処理部５４は、鍵管理サーバ２０から送信された証明書署名要求（ＣＳＲ）に含まれる公開鍵に基づいて電子証明書を発行する処理を行う処理部である。
署名リクエスト要求処理部５３は、ＯＡｕｔｈ実行処理部５２によって取得されたアクセストークン（Access token）を用いて、証明書署名要求（ＣＳＲ）を鍵管理サーバ２０に要求する処理を行う処理部である。
電子証明書発行処理部５４は、鍵管理サーバ２０から送信された証明書署名要求（ＣＳＲ）に含まれる公開鍵に基づいて電子証明書を発行する処理を行う処理部である。
以上のような構成を備えることにより、証明書発行システム２は、リモート署名で求められる電子証明書の発行に際し、信頼された署名サービス（鍵管理システム３）に対する公開鍵を含む証明書署名要求の要求及び電子証明書の発行を、利用者の認証と管理のもと自動的に行うことが出来る。これにより、利用者の負担を軽減しながら電子証明書の発行を安全に行うことが出来る。
図４は、本実施形態の鍵管理サーバの構成を示す図であり、（ａ）は、ハードウェアによる機能構成を示す図、（ｂ）は、ソフトウェアによる機能構成を示す図である。
図４（ａ）に示すように、鍵管理サーバ３０は、装置全体の制御を行う汎用のオペレーティングシステムを実行するとともに、鍵管理サーバ３０の機能を実現するプログラムを実行するＣＰＵ（Central Processing Unit）３１と、ＣＰＵ３１による処理のために各種のプログラムや一時データ、変数が展開されるＲＡＭ（Random Access Memory）３２と、プログラムやデータが格納されるＨＤＤ（Hard Disk Drive）３３や不図示のＲＯＭ（Read Only Memory）と、鍵管理サーバ３０をネットワークに接続するためのネットワークＩ／Ｆ３４と、を備えている。
図４（ａ）に示すように、鍵管理サーバ３０は、装置全体の制御を行う汎用のオペレーティングシステムを実行するとともに、鍵管理サーバ３０の機能を実現するプログラムを実行するＣＰＵ（Central Processing Unit）３１と、ＣＰＵ３１による処理のために各種のプログラムや一時データ、変数が展開されるＲＡＭ（Random Access Memory）３２と、プログラムやデータが格納されるＨＤＤ（Hard Disk Drive）３３や不図示のＲＯＭ（Read Only Memory）と、鍵管理サーバ３０をネットワークに接続するためのネットワークＩ／Ｆ３４と、を備えている。
さらに、鍵管理サーバ３０は、内部バスに接続されたハードウェアセキュリティモジュール（ＨＳＭ：Hardware Security Module）１００を備えている。この場合、鍵管理サーバ３０は、鍵管理システム３と同義である。
なお、上記したように、ＨＳＭ１００は、鍵管理サーバ３０の外部バスに接続されていてもよいし、ネットワークＩ／Ｆを有してネットワーク経由で鍵管理サーバ３０と接続可能されてもよい。この場合、鍵管理サーバ３０と、ネットワーク接続型ＨＳＭ１００と、によって鍵管理システム３が構成される。
なお、上記したように、ＨＳＭ１００は、鍵管理サーバ３０の外部バスに接続されていてもよいし、ネットワークＩ／Ｆを有してネットワーク経由で鍵管理サーバ３０と接続可能されてもよい。この場合、鍵管理サーバ３０と、ネットワーク接続型ＨＳＭ１００と、によって鍵管理システム３が構成される。
また、図４（ｂ）に示すように、ＣＰＵ３１は、処理部として、ＯＡｕｔｈ実行処理部６１と、ユーザ認証処理部６２と、鍵生成処理部６３と、署名要求処理部６４と、証明書格納処理部６５と、を実行する。
ＯＡｕｔｈ実行処理部６１は、証明書発行サーバ３０のＯＡｕｔｈ実行処理部５２とともに、ＲＦＣ６７４９に規定されるOAuth2.0の認可処理を制御するための処理部である。
ＯＡｕｔｈ実行処理部６１は、端末装置１０（ウェブブラウザ）から認可要求（Authorization request）を受信すると、認証画面を端末装置１０に表示させ、ユーザ認証処理部６２による認証が成功した場合に、認可応答（Authorization response）として、認可コード（Authorization code）を端末装置１０に送信する。
さらに、ＯＡｕｔｈ実行処理部６１は、証明書発行サーバ２０から認可コード（Authorization code）とともにアクセストークン（Access token）を要求されると、証明書発行サーバ２０に対してアクセストークン（Access token）を送信する処理を行う。
ＯＡｕｔｈ実行処理部６１は、証明書発行サーバ３０のＯＡｕｔｈ実行処理部５２とともに、ＲＦＣ６７４９に規定されるOAuth2.0の認可処理を制御するための処理部である。
ＯＡｕｔｈ実行処理部６１は、端末装置１０（ウェブブラウザ）から認可要求（Authorization request）を受信すると、認証画面を端末装置１０に表示させ、ユーザ認証処理部６２による認証が成功した場合に、認可応答（Authorization response）として、認可コード（Authorization code）を端末装置１０に送信する。
さらに、ＯＡｕｔｈ実行処理部６１は、証明書発行サーバ２０から認可コード（Authorization code）とともにアクセストークン（Access token）を要求されると、証明書発行サーバ２０に対してアクセストークン（Access token）を送信する処理を行う。
ユーザ認証処理部６２は、端末装置１０に表示された認証画面に入力された認証情報（例えば、ユーザＩＤ及びパスワードの組み合わせ）を認証し、認証されれば上記ＯＡｕｔｈ実行処理部６１に通知する処理を行う処理部である。
鍵生成処理部６３は、ＨＳＭ１００を制御し、私有鍵（秘密鍵）と公開鍵のペアを生成させる鍵生成処理を行う処理部である。私有鍵（秘密鍵）は、例えば、端末装置１０から受信したＫｅｙＡｌｉａｓ、ＰＩＮに基づいて生成される。
署名要求処理部６４は、証明書発行サーバ２０から証明書署名要求（ＣＳＲ）を要求されると、鍵生成処理部６３で生成した公開鍵を含む証明書署名要求（ＣＳＲ）を証明書発行サーバ２０に送信する処理を行う処理部である。
証明書格納処理部６５は、証明書発行サーバ２０から送信された電子証明書を、ＨＳＭ１００に格納（インポート）する処理を行う処理部である。
また、鍵管理サーバ３０のＣＰＵ３１は、電子証明発行要求に応じて、ＨＳＭ１００に電子署名を生成させる処理を行う電子署名生成処理部を実行する。
鍵生成処理部６３は、ＨＳＭ１００を制御し、私有鍵（秘密鍵）と公開鍵のペアを生成させる鍵生成処理を行う処理部である。私有鍵（秘密鍵）は、例えば、端末装置１０から受信したＫｅｙＡｌｉａｓ、ＰＩＮに基づいて生成される。
署名要求処理部６４は、証明書発行サーバ２０から証明書署名要求（ＣＳＲ）を要求されると、鍵生成処理部６３で生成した公開鍵を含む証明書署名要求（ＣＳＲ）を証明書発行サーバ２０に送信する処理を行う処理部である。
証明書格納処理部６５は、証明書発行サーバ２０から送信された電子証明書を、ＨＳＭ１００に格納（インポート）する処理を行う処理部である。
また、鍵管理サーバ３０のＣＰＵ３１は、電子証明発行要求に応じて、ＨＳＭ１００に電子署名を生成させる処理を行う電子署名生成処理部を実行する。
以上のような構成を備えることにより、本実施形態の鍵管理システム３は、リモート署名で求められる電子証明書の発行に際し、利用者の認証と管理のもと、証明書発行システム２に対して公開鍵を含む証明書署名要求を自動で行い、電子証明書の発行を行わせることが出来る。これにより、利用者の負担を軽減しながら電子証明書の発行を安全に行うことが出来る。
図５は、本実施形態のリモート署名システムにおける電子証明書格納処理の流れを説明する図である。
シングルサインオンの技術において、鍵管理システム３（鍵管理サーバ３０）は、認証情報を提供する側であるIdentity Provider（ＩｄＰ）であり、認証局である証明書発行システム２（証明書発行サーバ２０）は、認証情報を利用する側であるService Provider（ＳＰ）である。
シングルサインオンの技術において、鍵管理システム３（鍵管理サーバ３０）は、認証情報を提供する側であるIdentity Provider（ＩｄＰ）であり、認証局である証明書発行システム２（証明書発行サーバ２０）は、認証情報を利用する側であるService Provider（ＳＰ）である。
ステップＳ１において、利用者が使用する端末装置１０（ウェブブラウザ）は、認証局（ＣＡ）の証明書発行サーバ２０にアクセスする。
電子証明書発行ページのリクエストを受けた証明書発行サーバ２０は、ステップＳ２において、利用者を鍵管理サーバ３０にリダイレクトするページを端末装置１０に供給する。
利用者の操作によって、端末装置１０は、ステップＳ３において、鍵管理サーバ３０に対して、認可要求（Authorization request）の送信を行う（ＲＦＣ６７４９＃４．１．１．）。これは、シングルサインオンの仕組みにおいてユーザの認証を要求するための手続である。
電子証明書発行ページのリクエストを受けた証明書発行サーバ２０は、ステップＳ２において、利用者を鍵管理サーバ３０にリダイレクトするページを端末装置１０に供給する。
利用者の操作によって、端末装置１０は、ステップＳ３において、鍵管理サーバ３０に対して、認可要求（Authorization request）の送信を行う（ＲＦＣ６７４９＃４．１．１．）。これは、シングルサインオンの仕組みにおいてユーザの認証を要求するための手続である。
ステップＳ４のユーザ認証処理において、鍵管理サーバ３０は、認証情報（例えば、ユーザＩＤとパスワード）の入力を利用者に要求する。また、当該の利用者のアカウントが未作成の場合には、鍵管理サーバ３０は、当該利用者のためのアカウントを新規に作成する処理を行う。
なお、ステップＳ４のユーザ認証処理において、認証情報の入力はＲＦＣ６７４９（OAuth2.0）で規定される処理とは異なり、鍵管理サーバ３０と端末装置１０との間で別途確立されるセッションにおいて行われる。
認証の方法は、ユーザＩＤ及びパスワードの組み合わせを認証する形式のみならず、ＩＣカードに格納されたトークンが端末装置か１０から鍵管理サーバ３０に送付されることにより認証が行われる場合もある。
ユーザの認証又はアカウントの作成が正常に行われると、鍵管理サーバ３０は、利用者の確認を得たうえで認可を確立し、ステップＳ５において、認可応答（Authorization response）として、認可コード（Authorization code）を端末装置１０に送信する（ＲＦＣ６７４９＃４．１．２．）。
なお、ステップＳ４のユーザ認証処理において、認証情報の入力はＲＦＣ６７４９（OAuth2.0）で規定される処理とは異なり、鍵管理サーバ３０と端末装置１０との間で別途確立されるセッションにおいて行われる。
認証の方法は、ユーザＩＤ及びパスワードの組み合わせを認証する形式のみならず、ＩＣカードに格納されたトークンが端末装置か１０から鍵管理サーバ３０に送付されることにより認証が行われる場合もある。
ユーザの認証又はアカウントの作成が正常に行われると、鍵管理サーバ３０は、利用者の確認を得たうえで認可を確立し、ステップＳ５において、認可応答（Authorization response）として、認可コード（Authorization code）を端末装置１０に送信する（ＲＦＣ６７４９＃４．１．２．）。
なお、例えばこの段階で、ステップＳ６において、端末装置１０（ウェブブラウザ）は、利用者が入力したＫｅｙＡｌｉａｓ（鍵に付す識別用の名前）とＰＩＮを鍵管理サーバ３０に送信する。
それに対して、鍵管理サーバ３０は、ステップＳ７において、利用者が入力したＫｅｙＡｌｉａｓとＰＩＮに基づいて、ＨＳＭ（Hardware Security Module）１００に私有鍵（秘密鍵）と公開鍵のペアを生成させ、ＨＳＭ１００に格納させる。
なお実際には、鍵ペアの生成は、後述する公開鍵を含む証明書署名要求（ＣＳＲ）の送信時までに行われていればよい。
それに対して、鍵管理サーバ３０は、ステップＳ７において、利用者が入力したＫｅｙＡｌｉａｓとＰＩＮに基づいて、ＨＳＭ（Hardware Security Module）１００に私有鍵（秘密鍵）と公開鍵のペアを生成させ、ＨＳＭ１００に格納させる。
なお実際には、鍵ペアの生成は、後述する公開鍵を含む証明書署名要求（ＣＳＲ）の送信時までに行われていればよい。
鍵管理サーバ３０から送信された認可コード（Authorization code）を受信した端末装置１０（ウェブブラウザ）は、ステップＳ８において、認可コード（Authorization code）を証明書発行サーバ２０に転送（Redirect）する。
端末装置１０から転送された認可コード（Authorization code）を取得した証明書発行サーバ２０は、ステップＳ９において、この認可コード（Authorization code）を用いて、Access token request（アクセストークン要求）を鍵管理サーバ３０に対して行う（ＲＦＣ６７４９＃４．１．３．）。
端末装置１０から転送された認可コード（Authorization code）を取得した証明書発行サーバ２０は、ステップＳ９において、この認可コード（Authorization code）を用いて、Access token request（アクセストークン要求）を鍵管理サーバ３０に対して行う（ＲＦＣ６７４９＃４．１．３．）。
Access token request（アクセストークン要求）を受けつけた鍵管理サーバ３０は、ステップＳ１０において、アクセストークン応答（Access token response）を証明書発行サーバ２０に返す。
すなわち、鍵管理サーバ３０は、アクセストークン（Access token）を証明書発行サーバ２０に送信する（ＲＦＣ６７４９＃４．１．４．）。
すなわち、鍵管理サーバ３０は、アクセストークン（Access token）を証明書発行サーバ２０に送信する（ＲＦＣ６７４９＃４．１．４．）。
鍵管理サーバ３０からアクセストークン（Access token）を取得した証明書発行サーバ２０は、ステップＳ１１において、このアクセストークン（Access token）を用いて、鍵管理サーバ３０に対して証明書署名要求（ＣＳＲ）の要求を行う。
証明書署名要求（ＣＳＲ）の要求を受けた鍵管理サーバ３０は、ステップＳ１２において、証明書署名要求（ＣＳＲ）を証明書発行サーバ２０に対して行う。証明書署名要求は、鍵管理サーバ３０が生成した公開鍵を含む。
証明書署名要求を受けた証明書発行サーバ２０は、ステップＳ１３において、電子証明書の発行を行い、ステップＳ１４で、例えば鍵管理サーバ３０に対してポストし、ステップＳ１５で、鍵管理サーバ３０はそれを受け入れる（格納する）。
鍵管理サーバ３０は、ポストされた電子証明書を私有鍵（秘密鍵）、公開鍵とともに管理する。
証明書署名要求（ＣＳＲ）の要求を受けた鍵管理サーバ３０は、ステップＳ１２において、証明書署名要求（ＣＳＲ）を証明書発行サーバ２０に対して行う。証明書署名要求は、鍵管理サーバ３０が生成した公開鍵を含む。
証明書署名要求を受けた証明書発行サーバ２０は、ステップＳ１３において、電子証明書の発行を行い、ステップＳ１４で、例えば鍵管理サーバ３０に対してポストし、ステップＳ１５で、鍵管理サーバ３０はそれを受け入れる（格納する）。
鍵管理サーバ３０は、ポストされた電子証明書を私有鍵（秘密鍵）、公開鍵とともに管理する。
図６は、図５に示した電子証明書格納処理の後の、リモート署名処理の流れを説明する図である。
端末装置１０からの要求に応じて、証明書発行サーバ２０は、ステップＳ２１において、図５の処理で取得したアクセストークン（Access token）を用いて、リモート署名要求を鍵管理サーバ３０に送信する。
なお、このリモート署名要求は、遠隔で電子署名の生成を要求する処理であり、上記した電子証明書格納処理における電子証明書の発行（署名）を要求する証明書署名要求とは異なる処理である。
リモート署名要求送信を受信した鍵管理サーバ３０は、ステップＳ２２において、電子署名を生成し（ＨＳＭ１００に電子署名を生成させ）、ステップＳ２３において、生成された電子署名を証明書発行サーバ２０に送信する。
端末装置１０からの要求に応じて、証明書発行サーバ２０は、ステップＳ２１において、図５の処理で取得したアクセストークン（Access token）を用いて、リモート署名要求を鍵管理サーバ３０に送信する。
なお、このリモート署名要求は、遠隔で電子署名の生成を要求する処理であり、上記した電子証明書格納処理における電子証明書の発行（署名）を要求する証明書署名要求とは異なる処理である。
リモート署名要求送信を受信した鍵管理サーバ３０は、ステップＳ２２において、電子署名を生成し（ＨＳＭ１００に電子署名を生成させ）、ステップＳ２３において、生成された電子署名を証明書発行サーバ２０に送信する。
上記したように、本実施形態の証明書発行サーバ２０は、鍵管理サーバ３０からOAuth2.0の仕組みを用いて、証明書署名要求（ＣＳＲ）を鍵管理サーバ３０に対して要求する為のアクセストークン（Access token）を取得する。
そして、証明書発行サーバ２０は、このアクセストークン（Access token）を、証明書署名要求（ＣＳＲ）の要求のみならず、鍵管理サーバ３０に対するリモート署名の要求にも利用することが出来る。
そして、証明書発行サーバ２０は、このアクセストークン（Access token）を、証明書署名要求（ＣＳＲ）の要求のみならず、鍵管理サーバ３０に対するリモート署名の要求にも利用することが出来る。
以上説明したように、本実施形態のリモート署名システムでは、電子証明書の発行に際して、認証局（証明書発行システム）と信頼された署名サービス（鍵管理サーバ）との間で、公開鍵を含む証明書署名要求及び電子証明書のやりとりが、利用者の認証と管理のもと自動的に行われる。特に、証明書発行サーバは、電子証明書の発行を自動的に行うことが出来る。
これにより、利用者の負担を軽減しながら、電子証明書の発行、鍵管理サーバへの電子証明書の登録が安全に実施可能な電子署名システムを実現し、信頼性の高い署名サービスを利用者に利用させることが出来る。
これにより、利用者の負担を軽減しながら、電子証明書の発行、鍵管理サーバへの電子証明書の登録が安全に実施可能な電子署名システムを実現し、信頼性の高い署名サービスを利用者に利用させることが出来る。
なお、上記では、端末装置１０と、証明書発行システム（証明書発行サーバ２０）と、鍵管理システム３（鍵管理サーバ３０）と、がそれぞれ一つずつ含まれるシステムを説明した。
それに限らず、本実施形態のリモート署名システム１は、複数の端末装置１０、複数の証明書発行システム２０、複数の鍵管理システム３０によって構成されることが出来る。
それに限らず、本実施形態のリモート署名システム１は、複数の端末装置１０、複数の証明書発行システム２０、複数の鍵管理システム３０によって構成されることが出来る。
１または複数の端末装置１０の利用者は、上記に説明した機能を有する複数の証明書発行システム（認証局）の中から、任意の証明書発行システム２０を選択し、その証明書発行ページにアクセスすることが出来る。
また、一の証明書発行システム２０は、上記に説明した機能を有する複数の鍵管理システム３０を信頼し、上記の手順に従って、各鍵管理システムで発行された公開鍵について電子証明書を発行して登録する処理を行う。
各証明書発行システムは、利用者をリダイレクト可能な鍵管理システムが複数ある場合、例えば、証明書発行ページに、利用可能な鍵管理システムのリストを表示し、その中から、利用する鍵管理システムを利用者に選択させることが出来る。
また、一の証明書発行システム２０は、上記に説明した機能を有する複数の鍵管理システム３０を信頼し、上記の手順に従って、各鍵管理システムで発行された公開鍵について電子証明書を発行して登録する処理を行う。
各証明書発行システムは、利用者をリダイレクト可能な鍵管理システムが複数ある場合、例えば、証明書発行ページに、利用可能な鍵管理システムのリストを表示し、その中から、利用する鍵管理システムを利用者に選択させることが出来る。
なお、上記の特許文献１（特開２０１０−２００１４２公報）には、ユーザ端末、電子署名サーバ、認証局と、を備えたシステムが開示されている。
この特許文献１においては、認証局が秘密鍵、公開鍵の鍵ペアを生成する。そして、電子署名サーバは、認証局に対して公開鍵に基づく電子証明書の発行を要求する。認証局は、発行した電子証明書と秘密鍵をＰＫＣＳ＃１２と呼ばれる形式のファイルに格納し、電子署名サーバに供給する。
そして、電子署名サーバは、ユーザ端末からの求めに応じて、電子証明書、秘密鍵を用いて電子署名を行う。
この特許文献１においては、認証局が秘密鍵、公開鍵の鍵ペアを生成する。そして、電子署名サーバは、認証局に対して公開鍵に基づく電子証明書の発行を要求する。認証局は、発行した電子証明書と秘密鍵をＰＫＣＳ＃１２と呼ばれる形式のファイルに格納し、電子署名サーバに供給する。
そして、電子署名サーバは、ユーザ端末からの求めに応じて、電子証明書、秘密鍵を用いて電子署名を行う。
このように、特許文献１では認証局が鍵ペアを生成し、電子署名サーバは、認証局と直接的なやりとりによって証明書署名要求を行い、かつ生成された証明書と秘密鍵も、電子署名サーバと認証局の直接的なやりとりによって行われる。その間の通信において、利用者が介在する余地はない。
それに対し本実施形態では、認証局（証明書発行システム）と、鍵管理サーバとの間に、利用者の端末装置が介在し、OAuth2.0（ＲＦＣ６７４９）の仕組みを用いて利用者が鍵管理サーバに対する認証を行い、その結果払い出されるアクセストークン（Access token）を用いて、認証局（証明書発行システム）と鍵管理サーバとの間で電子証明書の授受が行われる。
本実施形態において、私有鍵（秘密鍵）は、そもそも鍵管理サーバで生成されるものであり、認証局と鍵管理サーバとの間で授受されるものではない。
本実施形態では、利用者による鍵管理サーバに対する認証を契機に証明書署名要求、電子証明書のやり取りが行われるため、従来の方法に比べ、より安全に電子証明書の発行が可能である。また、私有鍵（秘密鍵）は、鍵管理システムで生成された後、他のサーバや端末に送信されることがないため、外部に漏れるリスクが低く、より安全な電子署名システムの運用が可能となる。
本実施形態において、私有鍵（秘密鍵）は、そもそも鍵管理サーバで生成されるものであり、認証局と鍵管理サーバとの間で授受されるものではない。
本実施形態では、利用者による鍵管理サーバに対する認証を契機に証明書署名要求、電子証明書のやり取りが行われるため、従来の方法に比べ、より安全に電子証明書の発行が可能である。また、私有鍵（秘密鍵）は、鍵管理システムで生成された後、他のサーバや端末に送信されることがないため、外部に漏れるリスクが低く、より安全な電子署名システムの運用が可能となる。
［第１の発明］
本実施形態に係る第１の発明は、電子証明書を発行する証明書発行システム２と、利用者の秘密鍵を管理する機能を有し、秘密鍵を用いて電子署名を生成する鍵管理システム３と、利用者が利用する端末装置１０と、を備える電子署名システムであって、端末装置１０は、鍵管理システム３に対して利用者の認証を要求し、認証が成功した場合、鍵管理システム３は、端末装置１０に対して認可コードを送信し、認可コードを取得した端末装置１０は、認可コードを証明書発行システム２に転送し、認可コードを取得した証明書発行システム２は、認可コードを鍵管理システム３に送信することによりアクセストークンを要求し、鍵管理システム３は、アクセストークンを電子証明書発行システム２に送信し、証明書発行システム２は、アクセストークンを鍵管理システム３に提示することによって、鍵管理システム３から利用者の公開鍵を含む証明書発行要求を取得し、公開鍵に対して電子証明書を発行する電子署名システム１を特徴とする。
第１の発明の電子署名システムでは、リモート署名で求められる電子証明書の発行に際し、公開鍵を含む証明書署名要求及び電子証明書の発行が、利用者の認証と管理のもと、認証局（証明書発行システム２）と信頼された署名サービス（鍵管理システム３）との間で自動的に行われる。
これにより、利用者の負担を軽減しながら電子証明書の安全な発行が可能な電子署名システムを実現することが出来る。
本実施形態に係る第１の発明は、電子証明書を発行する証明書発行システム２と、利用者の秘密鍵を管理する機能を有し、秘密鍵を用いて電子署名を生成する鍵管理システム３と、利用者が利用する端末装置１０と、を備える電子署名システムであって、端末装置１０は、鍵管理システム３に対して利用者の認証を要求し、認証が成功した場合、鍵管理システム３は、端末装置１０に対して認可コードを送信し、認可コードを取得した端末装置１０は、認可コードを証明書発行システム２に転送し、認可コードを取得した証明書発行システム２は、認可コードを鍵管理システム３に送信することによりアクセストークンを要求し、鍵管理システム３は、アクセストークンを電子証明書発行システム２に送信し、証明書発行システム２は、アクセストークンを鍵管理システム３に提示することによって、鍵管理システム３から利用者の公開鍵を含む証明書発行要求を取得し、公開鍵に対して電子証明書を発行する電子署名システム１を特徴とする。
第１の発明の電子署名システムでは、リモート署名で求められる電子証明書の発行に際し、公開鍵を含む証明書署名要求及び電子証明書の発行が、利用者の認証と管理のもと、認証局（証明書発行システム２）と信頼された署名サービス（鍵管理システム３）との間で自動的に行われる。
これにより、利用者の負担を軽減しながら電子証明書の安全な発行が可能な電子署名システムを実現することが出来る。
［第２の発明］
本実施形態に係る第２の発明は、電子証明書を発行する証明書発行システムであって、利用者が利用する端末装置が利用者の認証を鍵管理システムに要求することによって鍵管理システムにより発行された認可コードを取得する認可コード取得手段（ＯＡｕｔｈ実行処理部５２）と、取得された認可コードを用いて鍵管理システムにアクセストークンを要求する第１要求手段（ＯＡｕｔｈ実行処理部５２）と、第１要求手段による要求に応じて取得したアクセストークンを用いて、利用者の公開鍵を含む証明書発行要求を鍵管理システムに要求する第２要求手段（署名リクエスト要求処理部５３）と、第１要求手段による要求に応じて取得した証明書発行要求に含まれる公開鍵に対して電子証明書を発行する発行手段（電子証明書発行処理部５４）と、を備える証明書発行システムを特徴とする。
第２の発明の証明書発行システムは、リモート署名で求められる電子証明書の発行に際し、信頼された署名サービス（鍵管理システム３）に対する公開鍵を含む証明書署名要求の要求及び電子証明書の発行を、利用者の認証と管理のもと自動的に行うことが出来る。
これにより、利用者の負担を軽減しながら電子証明書の発行を安全に行うことが出来る。
本実施形態に係る第２の発明は、電子証明書を発行する証明書発行システムであって、利用者が利用する端末装置が利用者の認証を鍵管理システムに要求することによって鍵管理システムにより発行された認可コードを取得する認可コード取得手段（ＯＡｕｔｈ実行処理部５２）と、取得された認可コードを用いて鍵管理システムにアクセストークンを要求する第１要求手段（ＯＡｕｔｈ実行処理部５２）と、第１要求手段による要求に応じて取得したアクセストークンを用いて、利用者の公開鍵を含む証明書発行要求を鍵管理システムに要求する第２要求手段（署名リクエスト要求処理部５３）と、第１要求手段による要求に応じて取得した証明書発行要求に含まれる公開鍵に対して電子証明書を発行する発行手段（電子証明書発行処理部５４）と、を備える証明書発行システムを特徴とする。
第２の発明の証明書発行システムは、リモート署名で求められる電子証明書の発行に際し、信頼された署名サービス（鍵管理システム３）に対する公開鍵を含む証明書署名要求の要求及び電子証明書の発行を、利用者の認証と管理のもと自動的に行うことが出来る。
これにより、利用者の負担を軽減しながら電子証明書の発行を安全に行うことが出来る。
［第３の発明］
本実施形態に係る第３の発明は、利用者の秘密鍵を管理する機能を有し、秘密鍵を用いて電子署名を生成する鍵管理システムであって、利用者の公開鍵を少なくとも生成する鍵生成手段（鍵生成処理部６３）と、端末装置が利用者の認証を要求した場合に利用者の認証を行う認証手段（ユーザ認証処理部６２）と、認証が成功した場合に、認可コードを証明書発行システムに送信する認可コード送信手段（ＯＡｕｔｈ実行処理部６１）と、認可コードを用いてアクセストークンを要求した証明書発行システムに対しアクセストークンを送信するアクセストークン送信手段（ＯＡｕｔｈ実行処理部６１）と、アクセストークンを送信した証明書発行システムに対し、公開鍵を含む証明書発行要求を送信し、証明書発行システムに電子証明書を発行させる署名要求手段（署名要求処理部６４）と、を備える鍵管理システムを特徴とする。
第３の発明の鍵管理システムは、リモート署名で求められる電子証明書の発行に際し、利用者の認証と管理のもと、証明書発行システムに対して公開鍵を含む証明書署名要求を自動で行い、電子証明書の発行を行わせることが出来る。
これにより、利用者の負担を軽減しながら電子証明書の発行を安全に行うことが出来る。
本実施形態に係る第３の発明は、利用者の秘密鍵を管理する機能を有し、秘密鍵を用いて電子署名を生成する鍵管理システムであって、利用者の公開鍵を少なくとも生成する鍵生成手段（鍵生成処理部６３）と、端末装置が利用者の認証を要求した場合に利用者の認証を行う認証手段（ユーザ認証処理部６２）と、認証が成功した場合に、認可コードを証明書発行システムに送信する認可コード送信手段（ＯＡｕｔｈ実行処理部６１）と、認可コードを用いてアクセストークンを要求した証明書発行システムに対しアクセストークンを送信するアクセストークン送信手段（ＯＡｕｔｈ実行処理部６１）と、アクセストークンを送信した証明書発行システムに対し、公開鍵を含む証明書発行要求を送信し、証明書発行システムに電子証明書を発行させる署名要求手段（署名要求処理部６４）と、を備える鍵管理システムを特徴とする。
第３の発明の鍵管理システムは、リモート署名で求められる電子証明書の発行に際し、利用者の認証と管理のもと、証明書発行システムに対して公開鍵を含む証明書署名要求を自動で行い、電子証明書の発行を行わせることが出来る。
これにより、利用者の負担を軽減しながら電子証明書の発行を安全に行うことが出来る。
１ リモート署名システム、１０ 端末装置、２０ 証明書発行サーバ、２１ ＣＰＵ、２２ ＲＡＭ、２３ ＨＤＤ、２４ ネットワークＩ／Ｆ、３０ 鍵管理サーバ、３１ ＣＰＵ、３２ ＲＡＭ、３３ ＨＤＤ、３４ ネットワークＩ／Ｆ、５１ ウェブページ処理部、５２ ＯＡｕｔｈ実行処理部、５３ 署名リクエスト要求処理部、５４ 電子証明書発行処理部、６１ ユーザ認証処理部、６２ ＯＡｕｔｈ実行処理部、６３ 鍵生成処理部、６４ 署名要求処理部、６５ 証明書格納処理部
Claims (5)
- 電子証明書を発行する証明書発行システムと、
利用者の秘密鍵を管理する機能を有し、前記秘密鍵を用いて電子署名を生成する鍵管理システムと、
利用者が利用する端末装置と、を備える電子署名システムであって、
前記端末装置は、前記鍵管理システムに対して前記利用者の認証を要求し、
前記認証が成功した場合、前記鍵管理システムは、前記端末装置に対して認可コードを送信し、
前記認可コードを取得した前記端末装置は、前記認可コードを前記証明書発行システムに転送し、
前記認可コードを取得した前記証明書発行システムは、前記認可コードを前記鍵管理システムに送信することによりアクセストークンを要求し、
前記鍵管理システムは、前記アクセストークンを前記証明書発行システムに送信し、
前記証明書発行システムは、前記アクセストークンを前記鍵管理システムに提示することによって、前記鍵管理システムから前記利用者の公開鍵を含む証明書発行要求を取得し、前記公開鍵に対して電子証明書を発行することを特徴とする電子署名システム。 - 請求項１記載の電子署名システムであって、
前記鍵管理システムは、前記端末装置が要求した認証に係る利用者のアカウントが前記鍵管理システムに存在しない場合、当該利用者にアカウントの作成を促すとともに、当該利用者によってアカウントがされたとき、前記認可コードを前記端末装置に送付することを特徴とする電子署名システム。 - 電子証明書を発行する証明書発行システムであって、
利用者が利用する端末装置が前記利用者の認証を鍵管理システムに要求することによって前記鍵管理システムにより発行された認可コードを取得する認可コード取得手段と、
取得された前記認可コードを用いて前記鍵管理システムにアクセストークンを要求する第１要求手段と、
前記第１要求手段による要求に応じて取得した前記アクセストークンを用いて、前記利用者の公開鍵を含む証明書発行要求を前記鍵管理システムに要求する第２要求手段と、
前記第２要求手段による要求に応じて取得した前記証明書発行要求に含まれる前記公開鍵に対して電子証明書を発行する発行手段と、
を備えることを特徴とする証明書発行システム。 - 利用者の秘密鍵を管理する機能を有し、前記秘密鍵を用いて電子署名を生成する鍵管理システムであって、
利用者の公開鍵を少なくとも生成する鍵生成手段と、
端末装置が利用者の認証を要求した場合に前記利用者の認証を行う認証手段と、
前記認証が成功した場合に、認可コードを証明書発行システムに送信する認可コード送信手段と、
前記認可コードを用いてアクセストークンを要求した前記証明書発行システムに対し前記アクセストークンを送信するアクセストークン送信手段と、
前記アクセストークンを送信した前記証明書発行システムに対し、前記公開鍵を含む証明書発行要求を送信し、前記証明書発行システムに電子証明書を発行させる署名要求手段と、を備えることを特徴とする鍵管理システム。 - 電子証明書を発行する証明書発行システムと、利用者の秘密鍵を管理する機能を有し、前記秘密鍵を用いて電子署名を生成する鍵管理システムと、利用者が利用する端末装置と、を備える電子署名システムの電子証明書発行方法であって、
前記端末装置は、前記鍵管理システムに対して前記利用者の認証を要求し、
前記認証が成功した場合、前記鍵管理システムは、前記端末装置に対して認可コードを送信し、
前記認可コードを取得した前記端末装置は、前記認可コードを前記証明書発行システムに転送し、
前記認可コードを取得した前記証明書発行システムは、前記認可コードを前記鍵管理システムに送信することによりアクセストークンを要求し、
前記鍵管理システムは、前記アクセストークンを前記証明書発行システムに送信し、
前記証明書発行システムは、前記アクセストークンを前記鍵管理システムに提示することによって、前記鍵管理システムから前記利用者の公開鍵を含む証明書発行要求を取得し、前記公開鍵に対して電子証明書を発行することを特徴とする電子証明書発行方法。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2018136657A JP6465426B1 (ja) | 2018-07-20 | 2018-07-20 | 電子署名システム、証明書発行システム、鍵管理システム及び電子証明書発行方法 |
| PCT/JP2019/028492 WO2020017643A1 (ja) | 2018-07-20 | 2019-07-19 | 電子署名システム、証明書発行システム、鍵管理システム、証明書発行方法及びプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2018136657A JP6465426B1 (ja) | 2018-07-20 | 2018-07-20 | 電子署名システム、証明書発行システム、鍵管理システム及び電子証明書発行方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP6465426B1 JP6465426B1 (ja) | 2019-02-06 |
| JP2020014168A true JP2020014168A (ja) | 2020-01-23 |
Family
ID=65270482
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2018136657A Active JP6465426B1 (ja) | 2018-07-20 | 2018-07-20 | 電子署名システム、証明書発行システム、鍵管理システム及び電子証明書発行方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP6465426B1 (ja) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP6571890B1 (ja) * | 2019-01-21 | 2019-09-04 | Ｇｍｏグローバルサイン株式会社 | 電子署名システム、証明書発行システム、証明書発行方法及びプログラム |
| US11743053B2 (en) | 2019-12-03 | 2023-08-29 | Keisuke Kido | Electronic signature system and tamper-resistant device |
| CN112560050B (zh) * | 2020-11-26 | 2023-05-30 | 西安慧博文定信息技术有限公司 | 安全的电子证件颁发方法、装置、终端设备及存储介质 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2005502217A (ja) * | 2000-12-15 | 2005-01-20 | オラクル・インターナショナル・コーポレイション | デジタル署名を署名サーバに委託するための方法と装置 |
| JP2007181139A (ja) * | 2005-12-28 | 2007-07-12 | Brother Ind Ltd | 管理装置及びプログラム |
| US20180048638A1 (en) * | 2016-08-11 | 2018-02-15 | Motorola Solutions, Inc | Method for obtaining vetted certificates by microservices in elastic cloud environments |
-
2018
- 2018-07-20 JP JP2018136657A patent/JP6465426B1/ja active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2005502217A (ja) * | 2000-12-15 | 2005-01-20 | オラクル・インターナショナル・コーポレイション | デジタル署名を署名サーバに委託するための方法と装置 |
| JP2007181139A (ja) * | 2005-12-28 | 2007-07-12 | Brother Ind Ltd | 管理装置及びプログラム |
| US20180048638A1 (en) * | 2016-08-11 | 2018-02-15 | Motorola Solutions, Inc | Method for obtaining vetted certificates by microservices in elastic cloud environments |
Non-Patent Citations (2)
| Title |
|---|
| D. HARDT: "The OAuth 2.0 Authrization Framework", INTERNET ENGINEERING TASK FORCE (IETF) REQUEST FOR COMMENTS: 6749, JPN6018047440, October 2012 (2012-10-01), pages 23 - 42, ISSN: 0003931370 * |
| 平成２８年度サイバーセキュリティ経済基盤構築事業（電子署名・認証業務利用促進事業（電子署名及び認証業, JPN6018047438, March 2017 (2017-03-01), JP, pages 15 - 34, ISSN: 0003931369 * |
Also Published As
| Publication number | Publication date |
|---|---|
| JP6465426B1 (ja) | 2019-02-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109088889B (zh) | 一种ssl加解密方法、系统及计算机可读存储介质 | |
| US8307413B2 (en) | Personal token and a method for controlled authentication | |
| US10567370B2 (en) | Certificate authority | |
| JP4632315B2 (ja) | グリッド・アクセス及びネットワーク・アクセスを提供するシングル・サインオン操作のための方法及びシステム | |
| US8532620B2 (en) | Trusted mobile device based security | |
| US7353383B2 (en) | System and method for single session sign-on with cryptography | |
| US8340283B2 (en) | Method and system for a PKI-based delegation process | |
| EP1714422B1 (en) | Establishing a secure context for communicating messages between computer systems | |
| KR101459802B1 (ko) | 암호화 증명의 재검증에 기반을 둔 인증 위임 | |
| US9137017B2 (en) | Key recovery mechanism | |
| JP6571890B1 (ja) | 電子署名システム、証明書発行システム、証明書発行方法及びプログラム | |
| US11777743B2 (en) | Method for securely providing a personalized electronic identity on a terminal | |
| JP6465426B1 (ja) | 電子署名システム、証明書発行システム、鍵管理システム及び電子証明書発行方法 | |
| JP4332071B2 (ja) | クライアント端末、ゲートウエイ装置、及びこれらを備えたネットワークシステム | |
| JP2010191801A (ja) | 認証システムおよび認証方法 | |
| CN112235276A (zh) | 主从设备交互方法、装置、系统、电子设备和计算机介质 | |
| US20230403164A1 (en) | Certificate issuance support system, certificate issuance support method and program | |
| US9281947B2 (en) | Security mechanism within a local area network | |
| JP2005318269A (ja) | 電子証明書管理システム、電子証明書管理方法、及び、サーバ | |
| WO2020017643A1 (ja) | 電子署名システム、証明書発行システム、鍵管理システム、証明書発行方法及びプログラム | |
| CN115883104B (zh) | 终端设备的安全登录方法及装置、非易失性存储介质 | |
| JP2021040278A (ja) | 鍵管理システム、署名装置、鍵管理方法及びプログラム | |
| Ahn et al. | Towards scalable authentication in health services | |
| JP2023181362A (ja) | 認証情報署名システム、認証情報署名プログラム及び認証情報署名方法 | |
| CN114003892A (zh) | 可信认证方法、安全认证设备及用户终端 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20180829 |
|
| A871 | Explanation of circumstances concerning accelerated examination |
Free format text: JAPANESE INTERMEDIATE CODE: A871 Effective date: 20180829 |
|
| A975 | Report on accelerated examination |
Free format text: JAPANESE INTERMEDIATE CODE: A971005 Effective date: 20181106 |
|
| 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: 20181204 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20181227 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20181227 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6465426 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |