特許 6571890 電子署名システム、証明書発行システム、証明書発行方法及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B1)

(11)【特許番号】6571890

(24)【登録日】2019年8月16日

(45)【発行日】2019年9月4日

(54)【発明の名称】電子署名システム、証明書発行システム、証明書発行方法及びプログラム

(51)【国際特許分類】

   H04L 9/08 20060101AFI20190826BHJP

   G06F 21/33 20130101ALI20190826BHJP

   G06Q 50/10 20120101ALI20190826BHJP

【ＦＩ】

   H04L9/00 601F

   G06F21/33

   G06Q50/10

【請求項の数】4

【全頁数】21

(21)【出願番号】特願2019-7592(P2019-7592)

(22)【出願日】2019年1月21日

【審査請求日】2019年2月1日

【早期審査対象出願】

(73)【特許権者】

【識別番号】504030163

【氏名又は名称】ＧＭＯグローバルサイン株式会社

(74)【代理人】

【識別番号】100085660

【弁理士】

【氏名又は名称】鈴木 均

(74)【代理人】

【識別番号】100149892

【弁理士】

【氏名又は名称】小川 弥生

(74)【代理人】

【識別番号】100185672

【弁理士】

【氏名又は名称】池田 雅人

(72)【発明者】

【氏名】杉本 浩一

【審査官】 青木 重徳

(56)【参考文献】

【文献】 特許第６４６５４２６（ＪＰ，Ｂ２）

【文献】 特開２０１７−１７５２２６（ＪＰ，Ａ）

【文献】 特開２０１８−０９２４４６（ＪＰ，Ａ）

【文献】 特開２００４−２１３２６５（ＪＰ，Ａ）

【文献】 特開２００７−１８１１３９（ＪＰ，Ａ）

【文献】 特表２００５−５０２２１７（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１８／００４８６３８（ＵＳ，Ａ１）

【文献】 平成２８年度サイバーセキュリティ経済基盤構築事業（電子署名・認証業務利用促進事業（電子署名及び認証業，日本，みずほ情報総研株式会社，２０１７年 ３月，pp.15-34，［検索日 平成３０年１１月２７日］、インターネット，ＵＲＬ，<http:www.meti.go.jp/committee/kenkyukai/shoujo/denshishomeihou/pdf/h28_004_02_01.pdf>

【文献】 D. Hardt，The OAuth 2.0 Authrization Framework，Internet Engineering Task Force (IETF) Request for Comments: 6749，［オンライン］，２０１２年１０月，pp.23-42，［検索日 平成３０年１１月２６日］、インターネット，ＵＲＬ，<https://tools.ietf.org/pdf/rfc6749.pdf>

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ ９／０８

Ｇ０６Ｆ ２１／３３

Ｇ０６Ｑ ５０／１０

(57)【特許請求の範囲】

【請求項1】

電子証明書を発行する証明書発行システムと、発行された電子証明書のライフサイクルを管理する証明書管理システムと、秘密鍵を用いて電子署名を生成する鍵管理システムと、利用者が利用する端末装置と、を備え、
電子証明書の新規発行時において、
前記端末装置は、前記鍵管理システムに対して前記利用者の認証を要求し、
前記認証が成功した場合、前記鍵管理システムは、前記端末装置に対して認可コードを送信し、
前記認可コードを取得した前記端末装置は、前記認可コードを前記証明書発行システムに転送し、
前記認可コードを取得した前記証明書発行システムは、前記認可コードを前記鍵管理システムに送信することによりアクセストークンを要求し、
前記鍵管理システムは、前記アクセストークンを前記証明書発行システムに送信し、
前記証明書発行システムは、前記アクセストークンを前記鍵管理システムに提示することによって、前記鍵管理システムから前記利用者の公開鍵を含む証明書発行要求を取得し、前記公開鍵に対して電子証明書を発行し、
前記証明書管理システムは、所定条件の成立に基づく電子証明書の更新時において、前記証明書発行システムに対して証明書更新要求を行い、
前記証明書発行システムは、前記証明書更新要求に基づいて、前記新規発行時に前記鍵管理システムから取得した前記アクセストークンを前記鍵管理システムに提示することによって前記鍵管理システムから前記利用者の公開鍵を含む証明書発行要求を取得し、前記公開鍵に対して電子証明書を発行する、
ことを特徴とする電子署名システム。

【請求項2】

電子証明書を発行する証明書発行システムであって、
電子証明書の新規発行時において、利用者が利用する端末装置が前記利用者の認証を鍵管理システムに要求することによって前記鍵管理システムにより発行された認可コードを取得する認可コード取得手段と、
取得された前記認可コードを用いて前記鍵管理システムにアクセストークンを要求する第１要求手段と、
前記第１要求手段による要求に応じて取得した前記アクセストークンを用いて、前記利用者の公開鍵を含む証明書発行要求を前記鍵管理システムに要求する第２要求手段と、
前記第２要求手段による要求に応じて取得した証明書発行要求に含まれる前記公開鍵に対して電子証明書を発行して前記鍵管理システムに送信する第１発行手段と
所定条件の成立に基づく電子証明書の更新時において電子証明書のライフサイクルを管理する証明書管理システムにより証明書更新要求が行われたとき、前記証明書更新要求に基づいて、前記新規発行時に前記鍵管理システムから取得した前記アクセストークンを用いて前記利用者の公開鍵を含む証明書発行要求を前記鍵管理システムに要求する第３要求手段と、
前記第３要求手段による要求に応じて取得した証明書発行要求に含まれる前記公開鍵に対して電子証明書を発行して前記鍵管理システムに送信する第２発行手段と、
を備えることを特徴とする証明書発行システム。

【請求項3】

認可コード取得手段と、第１要求手段と、第２要求手段と、第３要求手段と、第１発行手段と、第２発行手段と、を備え、電子証明書を発行する証明書発行システムの証明書発行方法であって、
電子証明書の新規発行時において、
前記認可コード取得手段が、利用者が利用する端末装置が前記利用者の認証を鍵管理システムに要求することによって前記鍵管理システムにより発行された認可コードを取得するステップと、
前記第１要求手段が、取得された前記認可コードを用いて前記鍵管理システムにアクセストークンを要求するステップと、
前記第２要求手段が、前記第１要求手段による要求に応じて取得した前記アクセストークンを用いて、前記利用者の公開鍵を含む証明書発行要求を前記鍵管理システムに要求するステップと、
前記第１発行手段が、前記第２要求手段による要求に応じて取得した証明書発行要求に含まれる前記公開鍵に対して電子証明書を発行するステップと、
所定条件の成立に基づく電子証明書の更新時において電子証明書のライフサイクルを管理する証明書管理システムにより証明書更新要求が行われたとき、前記第３要求手段が、前記証明書更新要求に基づいて、前記新規発行時に前記鍵管理システムから取得した前記アクセストークンを用いて前記利用者の公開鍵を含む証明書発行要求を前記鍵管理システムに要求するステップと、
前記第２発行手段が、前記第３要求手段による要求に応じて取得した証明書発行要求に含まれる前記公開鍵に対して電子証明書を発行するステップと、
を含むことを特徴とする証明書発行方法。

【請求項4】

請求項３に記載の証明書発行方法をコンピュータに実行させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、電子署名システム及び電子証明書発行方法に関し、特に、公開鍵基盤で必要とされる電子署名と共に用いられる電子証明書を発行するための方法に関する。

【背景技術】

【0002】

全世界的に電子政府が稼働し始め、従来、紙で行われてきた契約行為も電子的に行われるようになってきた。電子的に行われる契約（電子契約）では、暗号技術や公開鍵基盤を用いた方式が主流である。
公開鍵基盤を用いた電子契約では、公開鍵暗号方式をベースとして、文書の送り側では、本人の私有鍵（秘密鍵）を用いて契約文書（電子データ）に電子署名を付与し、文書の受け取り側では、送り側の公開鍵を用いて契約文書に付与される電子署名を検証することで、なり済ましや、通信経路での改竄の有無を判断することが出来る。後述するが、公開鍵基盤は、公開鍵と、それと対になる私有鍵（秘密鍵）と、を用いて様々なセキュリティシステムを提供することができる。
この方式では、契約文書の検証時に契約書に電子署名を施した相手方（送り側）の公開鍵が必要となる。そして、この公開鍵と対になる私有鍵が送り側の所有に係ること（公開鍵の本人性）を証明するため、公開鍵証明書、いわゆる「電子証明書」が用いられる。

【0003】

「電子証明書」はインターネット上の身分証とも呼ばれ、信頼できる第三者機関（ＴＴＰ：Trusted Third Party）によって発行される。特に、電子証明書を発行するＴＴＰを認証局と呼ぶ。
従来、電子署名は利用者のＰＣ（Personal Computer）上で行われることが一般的であったが、サーバ上で行うことにより電子署名の利便性を高めた仕組みも知られている。
例えば、特許文献１には、ユーザ端末、電子署名サーバ、認証局と、を備えたシステムが開示されている。
特許文献１においては、認証局が秘密鍵、公開鍵の鍵ペアを生成する。そして、電子署名サーバは、認証局に対して公開鍵に基づく電子証明書の発行を要求する。認証局は、発行した電子証明書と秘密鍵とをＰＫＣＳ＃１２と呼ばれるファイルとして電子署名サーバに供給し、電子署名サーバは、ユーザ端末からの求めに応じて、電子証明書、秘密鍵を用いて電子署名を行う。

【0004】

さらに近年では、「リモート署名」あるいは「クラウド署名」と呼ばれるという仕組みが普及をはじめ、そして、ヨーロッパ諸国のｅＩＤＡＳやＡｄｏｂｅ社をはじめとした標準化団体ＣＳＣ(Cloud Signature Consortium)などで、プロトコルの標準化が推し進められている。
より具体的には、電子署名サイトなどで電子署名が必要な状況になると、OAuth2.0によるＳＳＯ(Single Sign On)の仕組みなどを用いて、利用者が鍵管理システムへリダイレクトされ、鍵管理システムは、ユーザ認証後にトークンを払い出し、そのトークンを取得した電子署名サイトは、トークンを鍵管理システムに対して提示することで、鍵管理システムに署名を行わせる、といった仕組みが「リモート署名」として実装され始めている。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】特開２０１０−２００１４２公報

【発明の概要】

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

【0006】

しかしながら、このような「リモート署名」を行うために、利用者は、鍵管理システムに予めアカウントを作成し、さらに鍵管理システムにて私有鍵（秘密鍵）を生成し、その私有鍵に対して認証局から発行された電子証明書をバインドする、という準備が必要となる。
この準備作業において、利用者は、認証局に電子証明書の発行させるために、鍵管理システムで私有鍵（秘密鍵）とともに生成された公開鍵を鍵管理システムから取得（ダウンロード）し、公開鍵を含む鍵署名要求（証明書署名要求）を認証局に対して行う必要があった。

【0007】

さらに利用者は、発行された電子証明書を鍵管理システムに対して格納しなければならない。
このような作業は利用者にとって煩雑なものであるとともに、技術的な負担を強いるものである。さらにこのような準備作業を利用者に行わせると、鍵管理システムの選択を利用者に委ねることになり、認証局側で鍵管理システムのセキュリティーレベルをコントロールすることが難しいという問題もある。
本発明は上記の問題点を鑑みてなされたものであり、電子署名に必要な電子証明書を発行して鍵管理システムに格納させる処理を、より安全に且つ利用者の負担を軽減しながら実行可能な電子署名システムを提供することを目的とする。

【課題を解決するための手段】

【0008】

上記の課題を解決するために、本発明は、電子証明書を発行する証明書発行システムと、発行された電子証明書のライフサイクルを管理する証明書管理システムと、秘密鍵を用いて電子署名を生成する鍵管理システムと、利用者が利用する端末装置と、を備え、電子証明書の新規発行時において、前記端末装置は、前記鍵管理システムに対して前記利用者の認証を要求し、前記認証が成功した場合、前記鍵管理システムは、前記端末装置に対して認可コードを送信し、前記認可コードを取得した前記端末装置は、前記認可コードを前記証明書発行システムに転送し、前記認可コードを取得した前記証明書発行システムは、前記認可コードを前記鍵管理システムに送信することによりアクセストークンを要求し、前記鍵管理システムは、前記アクセストークンを前記証明書発行システムに送信し、前記証明書発行システムは、前記アクセストークンを前記鍵管理システムに提示することによって、前記鍵管理システムから前記利用者の公開鍵を含む証明書発行要求を取得し、前記公開鍵に対して電子証明書を発行し、前記証明書管理システムは、所定条件の成立に基づく電子証明書の更新時において、前記証明書発行システムに対して証明書更新要求を行い、前記証明書発行システムは、前記証明書更新要求に基づいて、前記新規発行時に前記鍵管理システムから取得した前記アクセストークンを前記鍵管理システムに提示することによって前記鍵管理システムから前記利用者の公開鍵を含む証明書発行要求を取得し、前記公開鍵に対して電子証明書を発行する電子署名システムを特徴とする。

【発明の効果】

【0009】

上記のように構成することにより、本発明によれば、電子署名に必要な電子証明書を発行して鍵管理システムに格納させる処理を、より安全に且つ利用者の負担を軽減しながら実行可能な電子署名システムを実現することが出来る。

【図面の簡単な説明】

【0010】

【図1】OAuth2.0の処理を説明する参考図である。

【図2】本実施形態のシステム構成を説明する図である。

【図3】本実施形態の証明書発行サーバの構成を示す図である。

【図4】本実施形態の鍵管理サーバの構成を示す図である。

【図5】本実施形態のリモート署名システムにおける電子証明書格納処理の流れを説明する図である。

【図6】図５に示した電子証明書格納処理の後の、リモート署名処理の流れを説明する図である。

【図7】本実施形態の証明書管理サーバ４０の構成を示す図である。

【図8】図５に示した電子証明書格納処理の後の、電子証明書更新処理の流れを説明する図である。

【発明を実施するための形態】

【0011】

以下に、図面を参照して本発明の実施の形態を詳細に説明する。
まず、本実施形態の説明に先立って前提となる技術を説明する。
［公開鍵基盤］
公開鍵基盤（ＰＫＩ：Public Key Infrastructure）は、公開鍵暗号方式と呼ばれる暗号方式を用い、暗号化、デジタル署名（電子署名）、認証といったセキュリティ機能を提供する情報セキュリティ基盤である。
公開鍵基盤では、公開鍵暗号方式の特徴を利用し、上述の暗号化、デジタル署名、認証といった機能を提供する。公開鍵暗号方式では、私有鍵と公開鍵の一方向性（私有鍵から公開鍵を計算できるが、公開鍵から私有鍵を計算するのは計算量的に困難であるという特徴）を利用して様々な機能を提供する。利用者は自らの私有鍵を秘密裏に保持し、公開鍵を他者に公開しておく。私有鍵は、秘密に保持するという意味を持たせて秘密鍵とも呼ぶ。
例えば利用者Ｂは、利用者Ａに文書を送信するとき、利用者Ａが公開している公開鍵を入手し、その公開鍵を使って暗号化した文書を利用者Ａに送信する。利用者Ａは受信した暗号化文書を、自身の私有鍵（秘密鍵）を用いて復号化する。
利用者Ａの公開鍵を持っていれば誰もが利用者Ａに対して暗号化文書を送信することが出来る一方で、利用者Ａの公開鍵で暗号化したものは、利用者Ａの私有鍵（秘密鍵）でしか復号できないため、仮に悪意の第三者が利用者Ａの公開鍵を入手したとしても、暗号化文書の内容が漏えいすることはない。

【0012】

[電子証明書]
公開鍵暗号方式で通信を行うには、通信相手に公開鍵を送信することになるが、ネットワーク経由での通信では通信相手が見えないため、第三者が通信相手に成りすまして公開鍵を送信する可能性がある。従って、公開鍵が本当に正しい相手から送られてきたものであるかを確認する必要がある。
ＰＫＩでは、例えば、信頼できる第三者機関(ＴＴＰ： Trusted Third Party)が、私有鍵の所有者を保証する。すなわち、ＴＴＰは私有鍵（秘密鍵）の所有者の本人性を確認し、私有鍵（秘密鍵）と対になる公開鍵とその私有鍵（秘密鍵）の所有者とを紐づける電子証明書（公開鍵証明書）を発行する。電子証明書は持ち主の情報を正しく保障する「身分証明書」である。
電子証明書を発行するＴＴＰは、特に認証局あるいは認証機関（ＣＡ：Certification Authority）と呼ばれる。
電子証明書には、公開鍵と、その公開鍵に対応する私有鍵（秘密鍵）の所有者を証明する所有者の名前、所属組織名、メールアドレス等の情報が記載されており、さらに電子証明書自体の改ざんを防ぐためにＴＴＰの電子署名が付与されている。電子証明書を文書に付すことで、なりすましや、改ざんなどのリスクを未然に防ぐことが出来る。また、ＴＴＰに信頼される私有鍵（秘密鍵）の所有者を加入者(Subscriber、サブスクライバー)という。

【0013】

[電子署名]
電子証明書はさらに、電子署名を検証する用途に用いられる。通常、電子署名には、電子証明書を添付する。電子署名を受け取った利用者は、電子証明書に記載された公開鍵を使って署名を検証し、データの改ざん検知を行い、電子証明書に記載された内容を使って署名者の特定を行うことが出来る。
電子署名には、文書のハッシュ値を私有鍵（秘密鍵）で暗号化した値が含まれる（実際には、暗号処理と署名処理は異なるが、署名処理のことを広義の暗号化と呼ぶことが多い）。利用者Ａが利用者Ｂに対して電子署名を付した文書ファイルを送る場合、利用者Ａは、送信する文書ファイルをハッシュ関数にかけることによって得たハッシュ値を利用者Ａの私有鍵（秘密鍵）を用いて暗号化し、電子署名を作成して、文書ファイルに添付する。
電子署名付きの文書ファイルを受け取った利用者Ｂは、電子署名に含まれる暗号化された値を利用者Ａの公開鍵を使って復号化することによって得たハッシュ値と、文書ファイルをハッシュ関数にかけることによって得たハッシュ値と、を比較する。比較の結果、双方のハッシュ値が同一であれば、文書が改ざんされていないことが証明される。

【0014】

［リモート署名］
様々なクラウドサービス、オンラインサービスが提供され、クラウド上（サーバ上）で文書を扱うことが多くなっている。それに伴い、文書に対する電子署名を署名者のＰＣ（Personal Computer）上ではなく、サーバ上（クラウド上）で行う「リモート署名（クラウド署名）」と呼ばれる方式の電子署名が普及しつつある。
より詳しくは、リモート署名とは、署名者の電子証明書、私有鍵（秘密鍵）を鍵管理システムで管理し、電子署名が必要なときには、鍵管理システム上で電子証明書、私有鍵（秘密鍵）を用いた電子署名を実行する仕組みである。

【0015】

リモート署名には、署名者が私有鍵（秘密鍵）を自ら管理する必要が無いという利点がある。さらに、ＰＣのみならず、ウェブブラウザやスマートフォンなどのモバイルデバイスによっても文書に電子署名が可能である。従って、私有鍵（秘密鍵）を格納したスマートカードやＵＳＢトークン等を用いたエンドポイントでの電子署名の生成に比べ、格段に利便性が向上する。さらに、鍵管理システムで私有鍵（秘密鍵）が堅牢に保護されるため、セキュリティの観点からも、より望ましい署名方法であると言える。

【0016】

上記のように、リモート署名のサービスを提供する署名システムでは、署名を行うために署名者の私有鍵（秘密鍵）と、それに紐づけた電子証明書と、が必要である。
下記に説明するが、私有鍵（秘密鍵）と公開鍵の鍵ペアは鍵管理システムで生成するものであるが、電子証明書は、私有鍵（秘密鍵）の所有者の身分を保障する認証局によって発行されるものであり、前述した理由により、鍵管理システムには、発行された電子証明書を適宜インポートする必要がある。
電子証明書のインポートは、署名システムにおいてリモート署名をおこなうための準備作業である。

【0017】

現状、そのような準備作用として、鍵管理システムが生成した公開鍵に基づいて認証局で生成された電子証明書を鍵管理システムにインポート（格納）するには、利用者（署名者）自身による以下のような手順が必要であった。
すなわち、
（１）利用者が自身の端末装置を用いて鍵管理システムにアカウントを作成する。
（２）利用者が自身の端末装置を用いて鍵管理システムにログインし、鍵管理システムで鍵ペアを生成する。
（３）利用者が自身の端末装置を用いて鍵管理システムにログインし、鍵管理システムに証明書署名要求（ＣＳＲ：Certificate Signing Request）を生成させ、ダウンロードする。証明書署名要求は、証明書発行要求ともいう。
（４）利用者が自身の端末装置を用いて、（３）で取得した証明書署名要求（ＣＳＲ）を認証局に送付する。
（５）認証局が上記証明書署名要求（ＣＳＲ）に基づいて電子証明書を発行して利用者に送付する。
（６）利用者が鍵管理システムにログインし、（５）で送付された電子証明書を鍵管理システムにインポートする。

【0018】

このような準備作業では、利用者が自分で行う作業や手順が多く、また、技術的な知識も必要となるため、利用者に負担を強いるという問題があった。
また、認証局側の観点では、準備作業を利用者に行わせた結果、鍵管理システムの選択を利用者に委ねることになり、認証局側が鍵管理システムのセキュリティーレベルをコントロールすることが難しい、という問題があった。

【0019】

当然、認証局自体は信頼できる第三者機関であるが、鍵管理システムの中には、必ずしも信頼がおけないものがある。鍵管理システムの信頼性とは、私有鍵（秘密鍵）を適切な方法で管理しているか否かである。リモート署名では、私有鍵（秘密鍵）や電子証明書を後述するＨＳＭ（Hardware Security Module）と呼ばれる装置で安全に管理することが要求される。そのような要求を満たしていない鍵管理システムを利用者が選択し、利用することにはセキュリティリスクが伴う。

【0020】

そこで本実施形態において、認証局は、信頼性を担保出来る鍵管理システムを登録する。そして、後述するOAuth2.0によるＳＳＯ（Single Sign On）の仕組みを用いて、認証局と、信頼された鍵管理システムと、の間で公開鍵と電子証明書のやりとりを行うことで、利用者の負担を軽減しながら、信頼性の高い鍵管理システムを利用者に利用させることが出来る。

【0021】

ＲＦＣ６７４９で定義されるOAuth2.0は、概略としては、リソースサーバが保有している保護リソース（重要情報や鍵等）をリソースオーナーの許可を得てクライアントが使用することができるようにする仕組みである。
そして、リソースサーバが保有する保護リソースに対するクライアントのアクセス可否を認可サーバがコントロールする。
保護リソースにアクセスするにはアクセストークン（Access token）と呼ばれる情報が必要であり、認可サーバは、アクセスを許可するクライアントに対してアクセストークン（Access token）を発行する。

【0022】

また、上記に加えてユーザーエージェント（例えばウェブブラウザ）がアクセスの介在をする場合がある。その場合、認可サーバにおけるリソースオーナーの認証、及び、認可サーバからクライアントへの認可コード（Authorization code）の送付を、ユーザーエージェントが仲介して行う。なお、認可コードは、認可トークンとも呼ぶ。

【0023】

図１は、ユーザーエージェントが介在するOAuth2.0の処理を説明する参考図である。
なお、図１の参考図は、ＲＦＣ６７４９に開示されている図である。
図１を用いて、本実施形態を構成する、認証局としての証明書発行サーバ、鍵管理システム、端末装置と、OAuth2.0で定義される各エンティティとの対応付けを行うとともに、各エンティティによるOAuth2.0の処理を説明する。
なお、本実施形態の証明書発行システムが上記「クライアント」に対応し、本実施形態の端末装置で実行されるウェブブラウザ（後述）が上記「ユーザーエージェント」に対応する。また、本実施形態の鍵管理システムが上記「認可サーバ」に対応し、端末装置の利用者が上記「リソースオーナー」に対応する。

【0024】

図１の（Ａ）において、クライアント（証明書発行サーバ）は、ユーザーエージェント（端末装置のウェブブラウザ）を経由してクライアントのＩＤ情報を認可サーバ（鍵管理システム）に送り（ＲＦＣ６７４９＃４．１．１． 認可要求）、（Ｂ）において、認可サーバ（鍵管理システム）は、ユーザーエージェント（ウェブブラウザ）を経由してリソースオーナー（利用者）に認証・認可を実施する。
（Ｃ）において、認可サーバ（鍵管理システム）がリソースへのアクセスを許可する場合、認可サーバ（鍵管理システム）は、ユーザーエージェント（ウェブブラウザ）を経由してクライアント（証明書発行サーバ）に認可コード（Authorization code）を発行する（ＲＦＣ６７４９＃４．１．２． 認可応答）。
（Ｄ）において、クライアント（証明書発行サーバ）は、認可コード（Authorization code）を提示することによって、認可サーバ（鍵管理システム）に対してアクセストークン（Access token）を要求する（ＲＦＣ６７４９＃４．１．３． アクセストークン要求）。
（Ｅ）において、認可サーバ（鍵管理システム）は、提示された認可コード（Authorization code）の検証に成功した場合、アクセストークン（Access token）をクライアント（証明書発行サーバ）に発行する（ＲＦＣ６７４９＃４．１．４． アクセストークン応答）。

【0025】

本実施形態においては、利用者を認証局（証明書発行システム）の電子証明書発行ページにアクセスさせる。そして、認証局は、予め信頼できると決められている鍵管理システムに利用者を転送して当該の鍵管理システムにログインさせる（図１（Ａ）の認可要求）。

【0026】

利用者が鍵管理システムに対して行ったログイン認証が成功すると、鍵管理システムの認可コード（Authorization code）が、利用者（端末装置のウェブブラウザ）に送付され、この認可コード（Authorization code）は、認証局（証明書発行システム）に転送される（図１（Ｃ）の認可応答）。
認証局（証明書発行システム）は、この認可コード（Authorization code）を用いて、アクセストークン（Access token）の要求を鍵管理システムに対して行う（図１（Ｄ）のアクセストークン要求）。
認証局（証明書発行システム）は、鍵管理システムからアクセストークン（Access token）を付与される（図１（Ｅ）のアクセストークン応答）。

【0027】

さらに、本実施形態の特徴として、認証局（証明書発行システム）は、そのアクセストークン（Access token）を使って鍵管理システムに対して証明書署名要求（ＣＳＲ）の要求を行い、鍵管理システムから証明書署名要求（ＣＳＲ）を受け取ることで電子証明書の発行を行う。
このような本実施形態のシステムによれば、利用者による認証という要件を満たしながら、認証局（証明書発行システム）側で鍵管理システムに対する証明書署名要求（ＣＳＲ）の要求を行うことで、鍵管理システムから証明書署名要求（ＣＳＲ）を直接受け取って、電子証明書を発行して鍵管理システムに送信し、インポートさせることが出来る。

【0028】

以下に、本実施形態のシステム及びその処理をより詳しく説明する。
図２は、本実施形態のシステム構成を説明する図である。
図２に示すように、本実施形態のリモート署名システム１は、利用者の利用に係る端末装置１０と、ユーザの電子証明書を発行する証明書発行サーバ２０を含む証明書発行システム２と、ユーザの私有鍵（秘密鍵）及び公開鍵のペア、及び証明書発行サーバ２０が発行した電子証明書を管理してリモート署名のサービスを提供するための鍵管理サーバ３０を含む鍵管理システム３と、証明書発行サーバ２０で発行されて鍵管理サーバ３０で管理されている電子証明書の期限管理等を行う証明書管理システム４と、を備える。

【0029】

端末装置１０、証明書発行システム２、鍵管理システム３、証明書管理システム４は、いずれもインターネットに接続され、互いに通信可能に構成されている。
これらの装置、システム間でやり取りされるデータの類は、おもにＨＴＴＰリクエストやＨＴＴＰレスポンスのパラメータとして（ＨＴＴＰプロトコルを利用して）送受信されるが、セキュリティ確保のため、通信自体は保護されるのが慣例である（例えば、ＨＴＴＰＳを利用する）。

【0030】

上記したように、証明書発行システム２が上記OAuthにおけるクライアントに対応し、
端末装置１０で実行されるウェブブラウザがユーザーエージェントに対応する。また、鍵管理システム３が認可サーバに対応し、端末装置１０の利用者が上記リソースオーナーに対応する。
従って、証明書発行システム２を構成する証明書発行装置２０、鍵管理システム３を構成する鍵管理サーバ３０、端末装置１０のウェブブラウザは、夫々上記に説明したOAuthに準拠した処理を実行可能に構成されている。

【0031】

端末装置１０は、ウェブブラウザ（ユーザーエージェント）を実行可能な一般的なＰＣやスマートフォンである。
端末装置１０のＣＰＵによって実行されるウェブブラウザは、証明書発行システム２０から提供する電子証明書発行ページを要求するページ要求手段、証明書発行サーバ２０から受信した転送ページ等を表示するページ表示手段、認可要求（Authorization request）を鍵管理サーバ３０に送信し、認可コード（Authorization code）を含む認可応答（Authorization response）を受信するＯＡｕｔｈ実行手段、KeyAliasとPINの入力を受け付けて鍵管理サーバ３０に送信する鍵情報送信手段、鍵管理サーバ３０から受信した認可コード（Authorization code）の証明書発行サーバ２０への転送等の処理を行う認可コード送信手段等として機能する。

【0032】

証明書発行サーバ２０は、電子証明書を発行する認証局に属する。上記したように、認証局は、公開鍵基盤（ＰＫＩ：Public Key Infrastructure）で用いられる私有鍵の所有者を確認するために用いられる電子証明書を発行する機関である。
証明書発行システム２は、上記証明書発行サーバ２０に加え、利用者のウェブブラウザによるリクエストを受け付けて電子証明書発行ページのデータを端末装置１０に供給するウェブサーバをさらに備えてもよい。また、ウェブサーバの機能は、証明書発行サーバ２０自体が備えていてもよい。

【0033】

鍵管理システム３は、利用者の私有鍵（秘密鍵）、電子証明書を管理してリモート署名サービスを提供するシステムであり、要求に応じて電子署名を生成し、要求元に供給する。
本実施形態の鍵管理システム３は、例えば、鍵管理サーバ３０と、ハードウェアセキュリティモジュール（ＨＳＭ：Hardware Security Module）１００と、を備えている。
ＨＳＭ１００は、利用者の私有鍵（秘密鍵）と公開鍵のペアを生成し、認証局で発行された利用者の電子証明書をインポートして管理するとともに、私有鍵（秘密鍵）を用いて電子署名を生成する装置である。

【0034】

本実施形態のシステムにおいて、ＨＳＭ１００は、例えば、鍵管理サーバ３０の内部バスに接続されるかたちで鍵管理サーバ３０に内蔵される。また、ＨＳＭ１００は、鍵管理サーバの外部バス（ＵＳＢバスなど）に接続されてもよい。
さらに、ＨＳＭ１００はネットワークインターフェイスを備え、ＨＳＭ１００単独でネットワークに接続可能とされてもよい。ＨＳＭ１００は、鍵管理サーバ３０と同一のローカルネットワーク、遠隔のネットワークにおいて、鍵管理サーバ３０と通信可能に接続される。
その場合、鍵管理サーバ３０は、ネットワーク経由で、端末装置１０からの要求に応じてＨＳＭ１００に鍵ペアの生成を命令し、証明書発行サーバ２０（認証局）から送信された電子証明書をＨＳＭ１００にインポートする。

【0035】

上記のOAuthの説明においても述べたが、図２に示すシステム１において、証明書発行サーバ２０によってリダイレクトされた利用者（端末装置１０で実行されるウェブブラウザ）が鍵管理サーバ３０に対して認証を要求し、認証が成功した際には、鍵管理サーバ３０は、端末装置１０（ウェブブラウザ）に対して認可コード（Authorization code）を送付する。
なお、鍵管理サーバ３０に対して認証の要求を行うか否か、認証が成功しても認可を確立させるか否かは、利用者自身の裁量で決定出来る。リダイレクト画面に示される認証要求の可否を確認するダイアログ画面において、利用者は、認証要求の可否を選択することが出来る。あるいは認証成功後に、認可確立の是非を確認するダイアログ画面において、利用者は、認証確立の是非を選択することが出来る。

【0036】

認可コード（Authorization code）を受け取った端末装置１０（ウェブブラウザ）は、その認可コード（Authorization code）を証明書発行サーバ２０に送付（転送）する。
証明書発行サーバ２０は、端末装置１０（ウェブブラウザ）より送付された認可コード（Authorization code）を鍵管理サーバ３０に送付し、鍵管理サーバ３０は、その認可コード（Authorization code）と引き換えにアクセストークン（Access token）を証明書発行サーバ２０に送付する。
証明書発行サーバ２０がアクセストークン（Access token）を鍵管理サーバ３０に提示することで、証明書発行サーバ２０は、鍵管理サーバ３０より証明書署名要求（ＣＳＲ）を入手することが出来る。そして、証明書発行サーバ２０は、証明書署名要求（ＣＳＲ）に記載されている公開鍵に対して電子証明書を発行する。

【0037】

なお、利用者が鍵管理サーバ３０に対して認証を要求した際に利用者のアカウントが鍵管理サーバ３０に存在しない場合、鍵管理サーバ３０は、利用者に新規アカウントの作成を促す。利用者が鍵管理サーバ３０に新規アカウントを作成した後、鍵管理サーバ３０は、その利用者（ウェブブラウザ）に対して認可コード（Authorization code）を送付することができる。

【0038】

証明書管理システム４は、例えば、証明書管理サーバ４０を備えている。
証明書発行サーバ２０で発行された電子証明書には、１年間や数年間などの有効期限があり、電子証明書はその失効後、望ましくは失効前に更新される必要がある。
証明書管理サーバ４０は、証明書発行サーバ２０で発行された電子証明書の有効期限の管理を行い、失効が近い電子証明書、あるいは任意の電子証明書を更新するための指示を証明書発行サーバ２０に対して行うことが出来る。
また証明書管理サーバ４０は、端末装置１０の管理を行う管理装置からの要求に応じて、電子証明書を更新する指示を証明書発行サーバ２０に対して行うことが出来る。

【0039】

証明書管理システム４（証明書管理サーバ４０）が関連する電子証明書の更新処理については後に詳述する。
なお証明書管理サーバ４０は、上記のように証明書発行システム２とは独立した証明書管理システム４に含まれてもよく、証明書発行システム２に含まれていてもよい。

【0040】

図３は、本実施形態の証明書発行サーバの構成を示す図であり、（ａ）は、ハードウェアによる機能構成を示す図、（ｂ）は、ソフトウェアによる機能構成を示す図である。
図３（ａ）に示すように、証明書発行サーバ２０は、装置全体の制御を行う汎用のオペレーティングシステムを実行するとともに、証明書発行サーバ２０の機能を実現するプログラムを実行するＣＰＵ（Central Processing Unit）２１と、ＣＰＵ２１による処理のために各種のプログラムや一時データ、変数が展開されるＲＡＭ（Random Access Memory）２２と、プログラムやデータが格納されるＨＤＤ（Hard Disk Drive）２３や不図示のＲＯＭ（Read Only Memory）と、証明書発行サーバ２０をネットワークに接続するためのネットワークＩ／Ｆ２４と、を備えている。

【0041】

また、図３（ｂ）に示すように、ＣＰＵ２１は、ウェブページ処理部５１と、ＯＡｕｔｈ実行処理部５２と、署名リクエスト要求処理部５３と、電子証明書発行処理部５４と、を実行する。
ウェブページ処理部５１は、所謂ウェブサーバとして機能し、端末装置１０からのＨＴＴＰリクエストに応じて、ＨＤＤ２３に格納されるウェブページ（ＨＴＭＬページ）のデータから電子証明書発行ページのデータを送信する。上記したように、ウェブページ処理部５１は、証明書発行サーバ２０とは異なる独立したサーバ装置（ウェブサーバ）として構成されてもよい。
すなわち、証明書発行サーバ２０は、電子証明書の発行を受け付けるためのウェブページ（電子証明書発行ページ）を供給して端末装置のウェブブラウザで表示させるためのウェブサーバの機能を有する。あるいは、証明書発行システム３は、バックエンドの証明書発行サーバ３０と、ユーザがアクセスするフロントエンドとしてのウェブサーバと、から構成されている。

【0042】

ＯＡｕｔｈ実行処理部５２は、鍵管理サーバ２０のＯＡｕｔｈ実行処理部６１とともに、所謂ＲＦＣ６７４９に規定されるOAuth2.0の認可処理を制御するための処理部であり、端末装置１０（ウェブブラウザ）から送信された認可コード（Authorization code）を用いて、鍵管理サーバ３０にアクセストークン（Access token）を要求する処理を行う。
署名リクエスト要求処理部５３は、ＯＡｕｔｈ実行処理部５２によって取得されたアクセストークン（Access token）を用いて、証明書署名要求（ＣＳＲ）を鍵管理サーバ２０に要求する処理を行う処理部である。
電子証明書発行処理部５４は、鍵管理サーバ２０から送信された証明書署名要求（ＣＳＲ）に含まれる公開鍵に基づいて電子証明書を発行する処理を行う処理部である。

【0043】

以上のような構成を備えることにより、証明書発行システム２は、リモート署名で求められる電子証明書の発行に際し、信頼された署名サービス（鍵管理システム３）に対する公開鍵を含む証明書署名要求の要求及び電子証明書の発行を、利用者の認証と管理のもと自動的に行うことが出来る。これにより、利用者の負担を軽減しながら電子証明書の発行を安全に行うことが出来る。

【0044】

図４は、本実施形態の鍵管理サーバの構成を示す図であり、（ａ）は、ハードウェアによる機能構成を示す図、（ｂ）は、ソフトウェアによる機能構成を示す図である。
図４（ａ）に示すように、鍵管理サーバ３０は、装置全体の制御を行う汎用のオペレーティングシステムを実行するとともに、鍵管理サーバ３０の機能を実現するプログラムを実行するＣＰＵ（Central Processing Unit）３１と、ＣＰＵ３１による処理のために各種のプログラムや一時データ、変数が展開されるＲＡＭ（Random Access Memory）３２と、プログラムやデータが格納されるＨＤＤ（Hard Disk Drive）３３や不図示のＲＯＭ（Read Only Memory）と、鍵管理サーバ３０をネットワークに接続するためのネットワークＩ／Ｆ３４と、を備えている。

【0045】

さらに、鍵管理サーバ３０は、内部バスに接続されたハードウェアセキュリティモジュール（ＨＳＭ：Hardware Security Module）１００を備えている。この場合、鍵管理サーバ３０は、鍵管理システム３と同義である。
なお、上記したように、ＨＳＭ１００は、鍵管理サーバ３０の外部バスに接続されていてもよいし、ネットワークＩ／Ｆを有してネットワーク経由で鍵管理サーバ３０と接続可能されてもよい。この場合、鍵管理サーバ３０と、ネットワーク接続型ＨＳＭ１００と、によって鍵管理システム３が構成される。

【0046】

また、図４（ｂ）に示すように、ＣＰＵ３１は、ＯＡｕｔｈ実行処理部６１と、ユーザ認証処理部６２と、鍵生成処理部６３と、署名要求処理部６４と、証明書格納処理部６５と、を実行する。
ＯＡｕｔｈ実行処理部６１は、証明書発行サーバ３０のＯＡｕｔｈ実行処理部５２とともに、ＲＦＣ６７４９に規定されるOAuth2.0の認可処理を制御するための処理部である。
ＯＡｕｔｈ実行処理部６１は、端末装置１０（ウェブブラウザ）から認可要求（Authorization request）を受信すると、認証画面を端末装置１０に表示させ、ユーザ認証処理部６２による認証が成功した場合に、認可応答（Authorization response）として、認可コード（Authorization code）を端末装置１０に送信する。
さらに、ＯＡｕｔｈ実行処理部６１は、証明書発行サーバ２０から認可コード（Authorization code）とともにアクセストークン（Access token）を要求されると、証明書発行サーバ２０に対してアクセストークン（Access token）を送信する処理を行う。

【0047】

ユーザ認証処理部６２は、端末装置１０に表示された認証画面に入力された認証情報（例えば、ユーザＩＤ及びパスワードの組み合わせ）を認証し、認証されれば上記ＯＡｕｔｈ実行処理部６１に通知する処理を行う処理部である。
鍵生成処理部６３は、ＨＳＭ１００を制御し、私有鍵（秘密鍵）と公開鍵のペアを生成させる鍵生成処理を行う処理部である。私有鍵（秘密鍵）は、例えば、端末装置１０から受信したKeyAlias、PINに基づいて生成される。
署名要求処理部６４は、証明書発行サーバ２０から証明書署名要求（ＣＳＲ）を要求されると、鍵生成処理部６３で生成した公開鍵を含む証明書署名要求（ＣＳＲ）を証明書発行サーバ２０に送信する処理を行う処理部である。
証明書格納処理部６５は、証明書発行サーバ２０から送信された電子証明書を、ＨＳＭ１００に格納（インポート）する処理を行う処理部である。
また、鍵管理サーバ３０のＣＰＵ３１は、電子証明発行要求に応じて、ＨＳＭ１００に電子署名を生成させる処理を行う電子署名生成処理部を実行する。

【0048】

以上のような構成を備えることにより、本実施形態の鍵管理システム３は、リモート署名で求められる電子証明書の発行に際し、利用者の認証と管理のもと、証明書発行システム２に対して公開鍵を含む証明書署名要求を自動で行い、電子証明書の発行を行わせることが出来る。これにより、利用者の負担を軽減しながら電子証明書の発行を安全に行うことが出来る。

【0049】

図５は、本実施形態のリモート署名システムにおける電子証明書格納処理の流れを説明する図である。
シングルサインオンの技術において、鍵管理システム３（鍵管理サーバ３０）は、認証情報を提供する側であるIdentity Provider（ＩｄＰ）であり、認証局である証明書発行システム２（証明書発行サーバ２０）は、認証情報を利用する側であるService Provider（ＳＰ）である。

【0050】

ステップＳ１において、利用者が使用する端末装置１０（ウェブブラウザ）は、認証局（ＣＡ）の証明書発行サーバ２０にアクセスする。
電子証明書発行ページのリクエストを受けた証明書発行サーバ２０は、ステップＳ２において、利用者を鍵管理サーバ３０にリダイレクトするページを端末装置１０に供給する。
利用者の操作によって、端末装置１０は、ステップＳ３において、鍵管理サーバ３０に対して、認可要求（Authorization request）の送信を行う（ＲＦＣ６７４９＃４．１．１．）。これは、シングルサインオンの仕組みにおいてユーザの認証を要求するための手続である。

【0051】

ステップＳ４のユーザ認証処理において、鍵管理サーバ３０は、認証情報（例えば、ユーザＩＤとパスワード）の入力を利用者に要求する。また、当該の利用者のアカウントが未作成の場合には、鍵管理サーバ３０は、当該利用者のためのアカウントを新規に作成する処理を行う。
なお、ステップＳ４のユーザ認証処理において、認証情報の入力はＲＦＣ６７４９（ＯＡｕｔｈ２．０）で規定される処理とは異なり、鍵管理サーバ３０と端末装置１０との間で別途確立されるセッションにおいて行われる。
認証の方法は、ユーザＩＤ及びパスワードの組み合わせを認証する形式のみならず、ＩＣカードに格納されたトークンが端末装置か１０から鍵管理サーバ３０に送付されることにより認証が行われる場合もある。
ユーザの認証又はアカウントの作成が正常に行われると、鍵管理サーバ３０は、利用者の確認を得たうえで認可を確立し、ステップＳ５において、認可応答（Authorization response）として、認可コード（Authorization code）を端末装置１０に送信する（ＲＦＣ６７４９＃４．１．２．）。

【0052】

なお、例えばこの段階で、ステップＳ６において、端末装置１０（ウェブブラウザ）は、利用者が入力したKeyAlias（鍵に付す識別用の名前）とＰＩＮを鍵管理サーバ３０に送信する。
それに対して、鍵管理サーバ３０は、ステップＳ７において、利用者が入力したKeyAliasとＰＩＮに基づいて、ＨＳＭ（Hardware Security Module）１００に私有鍵（秘密鍵）と公開鍵のペアを生成させ、ＨＳＭ１００に格納させる。
なお実際には、鍵ペアの生成は、後述する公開鍵を含む証明書署名要求（ＣＳＲ）の送信時までに行われていればよい。

【0053】

鍵管理サーバ３０から送信された認可コード（Authorization code）を受信した端末装置１０（ウェブブラウザ）は、ステップＳ８において、認可コード（Authorization code）を証明書発行サーバ２０に転送（Redirect）する。
端末装置１０から転送された認可コード（Authorization code）を取得した証明書発行サーバ２０は、ステップＳ９において、この認可コード（Authorization code）を用いて、Access token request（アクセストークン要求）を鍵管理サーバ３０に対して行う（ＲＦＣ６７４９＃４．１．３．）。

【0054】

Access token request（アクセストークン要求）を受けつけた鍵管理サーバ３０は、ステップＳ１０において、アクセストークン応答（Access token response）を証明書発行サーバ２０に返す。
すなわち、鍵管理サーバ３０は、アクセストークン（Access token）を証明書発行サーバ２０に送信する（ＲＦＣ６７４９＃４．１．４．）。

【0055】

鍵管理サーバ３０からアクセストークン（Access token）を取得した証明書発行サーバ２０は、ステップＳ１１において、このアクセストークン（Access token）を用いて、鍵管理サーバ３０に対して証明書署名要求（ＣＳＲ）の要求を行う。
証明書署名要求（ＣＳＲ）の要求を受けた鍵管理サーバ３０は、ステップＳ１２において、証明書署名要求（ＣＳＲ）を証明書発行サーバ２０に対して行う。証明書署名要求は、鍵管理サーバ３０が生成した公開鍵を含む。
証明書署名要求を受けた証明書発行サーバ２０は、ステップＳ１３において、電子証明書の発行を行い、ステップＳ１４で、例えば鍵管理サーバ３０に対してポストし、ステップＳ１５で、鍵管理サーバ３０はそれを受け入れる（ＨＳＭ１００に格納する）。
鍵管理サーバ３０は、ポストされた電子証明書を私有鍵（秘密鍵）、公開鍵とともに管理する。

【0056】

図６は、図５に示した電子証明書格納処理の後の、リモート署名処理の流れを説明する図である。
端末装置１０からの要求に応じて、証明書発行サーバ２０は、ステップＳ２１において、図５の処理で取得したアクセストークン（Access token）を用いて、リモート署名要求を鍵管理サーバ３０に送信する。
なお、このリモート署名要求は、遠隔で電子署名の生成を要求する処理であり、上記した電子証明書格納処理における電子証明書の発行（署名）を要求する証明書署名要求とは異なる処理である。
リモート署名要求送信を受信した鍵管理サーバ３０は、ステップＳ２２において、電子署名を生成し（ＨＳＭ１００に電子署名を生成させ）、ステップＳ２３において、生成された電子署名を証明書発行サーバ２０に送信する。

【0057】

上記したように、本実施形態の証明書発行サーバ２０は、鍵管理サーバ３０からOAuth2.0の仕組みを用いて、証明書署名要求（ＣＳＲ）を鍵管理サーバ３０に対して要求する為のアクセストークン（Access token）を取得する。
そして、証明書発行サーバ２０は、このアクセストークン（Access token）を、証明書署名要求（ＣＳＲ）の要求のみならず、鍵管理サーバ３０に対するリモート署名の要求にも利用することが出来る。

【0058】

以上説明したように、本実施形態のリモート署名システムでは、電子証明書の発行に際して、認証局（証明書発行システム）と信頼された署名サービス（鍵管理サーバ）との間で、公開鍵を含む証明書署名要求及び電子証明書のやりとりが、利用者の認証と管理のもと自動的に行われる。特に、証明書発行サーバは、電子証明書の発行を自動的に行うことが出来る。
これにより、利用者の負担を軽減しながら、電子証明書の発行、鍵管理サーバへの電子証明書の登録が安全に実施可能な電子署名システムを実現し、信頼性の高い署名サービスを利用者に利用させることが出来る。

【0059】

ところで、上記したように電子証明書には有効期限があり、定期的に再発行（更新）する必要がある。
基本的には、端末装置１０の利用者が認証局（ＣＡ）の証明書発行サーバ２０にアクセスする操作を行うことを契機として、図５に示したステップＳ１〜ステップＳ１５（鍵ペアの生成に係るステップＳ６、ステップＳ７は除いてもよい）の処理が再び行われることで、新たな電子証明書が鍵管理サーバ３０（ＨＳＭ１００）に格納され、電子証明書の更新を行うことが出来る。
しかしながら、端末装置１０の利用者自身が、電子証明書の有効期限を管理し、定期的に電子証明書の更新に係る操作を行うことは非常に煩雑であり、且つ不便である。
鍵管理サーバ３０に格納された電子証明書の有効期限を端末装置１０の利用者が意識する必要がなく、電子証明書が自動的に更新されていく仕組みが望ましい。

【0060】

しかも、端末装置１０を管理する管理装置の利用者（管理者）による操作ではなく、端末装置１０の利用者自身の認証と管理のもとで行われることが望ましい。この原則は、図５で説明した電子証明書の鍵管理サーバ３０への初回の格納時と変わらない。
その点に鑑みて、証明書発行サーバ２０は、初回格納時に端末装置１０の利用者自身の認証と管理のもと発行されたアクセストークン（Access token）を用いて電子証明書の更新処理を行う。
そして、証明書発行サーバ２０に電子証明書の更新処理を行わせる命令自体は管理装置等が行うことができるので、端末装置１０の利用者は電子証明書の更新処理自体を意識することがなく、その負荷を最大限に抑制することが出来る。

【0061】

下記に詳述する。図２で説明したように、本実施形態のリモート署名システム１は、証明書発行システム２で発行されて鍵管理システム３（鍵管理サーバ３０）に格納された電子証明書を管理する証明書管理システム４を備えている。
証明書管理システム４が含む証明書管理サーバ４０は、端末装置１０の管理を行う管理装置からの要求を受けて、証明書発行サーバ２０に対する電子証明書の更新（再発行）要求を行う。

【0062】

図７は、本実施形態の証明書管理サーバ４０の構成を示す図であり、（ａ）は、ハードウェアによる機能構成を示す図、（ｂ）は、ソフトウェアによる機能構成を示す図である。
図７（ａ）に示すように、証明書管理サーバ４０は、装置全体の制御を行う汎用のオペレーティングシステムを実行するとともに、証明書発行サーバ２０の機能を実現するプログラムを実行するＣＰＵ（Central Processing Unit）４１と、ＣＰＵ４１による処理のために各種のプログラムや一時データ、変数が展開されるＲＡＭ（Random Access Memory）４２と、プログラムやデータが格納されるＨＤＤ（Hard Disk Drive）４３や不図示のＲＯＭ（Read Only Memory）と、証明書管理サーバ４０をネットワークに接続するためのネットワークＩ／Ｆ４４と、を備えている。

【0063】

また、図７（ｂ）に示すように、ＣＰＵ４１は、更新要求処理部７１と、証明書管理処理部７２と、を実行する。
また、ＨＤＤ４３等から構成される記憶部には、証明書発行サーバ２０によって発行された電子証明書の状態（有効または失効済み）と有効期限とを管理する証明書管理データベース（ＤＢ）８１が格納されている。
証明書管理ＤＢ８１は特定の外部装置（管理装置等）に対して公開されて、電子証明書の有効期限を確認可能であることが望ましい。その場合、証明書管理サーバ４０は、外部装置に対して情報を公開するためのフロントエンドとしてのウェブページ処理部（所謂ウェブサーバ）を備えることが望ましい。

【0064】

更新要求処理部７１は、主に上記の管理装置からの要求を受けて、特定の電子証明書の更新要求を証明書発行サーバ２０に対して行う処理部である。
証明書管理処理部７２は、証明書発行サーバ２０によって発行された電子証明書の状態（有効、失効済み）と有効期限を証明書管理ＤＢ８１に書き込み、またはデータベースの情報の参照を行うデータベース管理処理部である。

【0065】

図８は、図５に示した電子証明書格納処理の後の、電子証明書更新処理の流れを説明する図である。
管理装置等からの要求を受けた証明書管理サーバ４０は、ステップＳ３１において、証明書発行サーバ２０に対して、特定の電子証明書の更新要求を行う。更新要求は、一つの電子証明書に対して行われてもよいし、失効が近い複数の電子証明書について一括して行われてもよい。

【0066】

ステップＳ３２において、証明書発行サーバ２０は、アクセストークン（Access token）を用いて、鍵管理サーバ３０に対して証明書署名要求（ＣＳＲ）の要求を行う。
証明書署名要求（ＣＳＲ）の要求を受けた鍵管理サーバ３０は、ステップＳ３３において、証明書署名要求（ＣＳＲ）を証明書発行サーバ２０に対して行う。
証明書署名要求を受けた証明書発行サーバ２０は、ステップＳ３４において、電子証明書の発行を行い、ステップＳ３５で、例えば鍵管理サーバ３０に対してポストし、ステップＳ３６で、鍵管理サーバ３０はそれを受け入れる（ＨＳＭ１００に格納する）。
鍵管理サーバ３０は、ポストされた電子証明書を私有鍵（秘密鍵）、公開鍵とともに管理する。

【0067】

ステップＳ３２で用いられるアクセストークン（Access token）は、図５で説明した初回の電子証明書格納処理のステップＳ１０において、鍵管理サーバ３０から取得されたものである。
鍵管理サーバ３０から取得されたアクセストークン（Access token）を利用することで、電子証明書の更新にあたり端末装置１０による認可操作（図５のステップＳ１〜Ｓ５）を繰り返す必要がなくなり、利用者の作業負担は著しく低減される。
また、上記のように、鍵管理サーバ３０から取得されたアクセストークン（Access token）は、端末装置１０の利用者自身の認証と管理のもとで発行されたものであり、適正な処理であること保証される。
図６について説明したように、証明書格納処理のステップＳ１０において鍵管理サーバ３０から取得されたアクセストークン（Access token）は、リモート署名要求を鍵管理サーバ３０に送信する際に用いられるものであるが、これは電子証明書の更新時にも用いることが出来るということである。

【0068】

なお、通常アクセストークン（Access token）には有効期限があり、それは電子証明書の有効期限よりも短いものである。電子証明書の更新時には、アクセストークン（Access token）の有効期限が過ぎている可能性が高い。
それに対し、特定の条件下で、例えば電子証明書の更新用途に限ってアクセストークン（Access token）の有効期限を長く設定するなどすることで電子証明書の更新を確実に行うことが出来る。
以上のように構成したことで、本実施形態のリモート署名システム１では、利用者は、初回の格納処理で認可操作（ステップＳ１における電子証明書発行ページへのアクセス、ステップＳＳ４における鍵管理サーバに対するログイン認証）を行った後は、電子証明書の鍵管理サーバ３０への格納と、格納された電子証明書の更新を、ほぼ完全に自動で行うことが出来る。

【0069】

なお、証明書発行サーバ２０による、初回格納時のアクセストークン（Access token）を使った電子証明書の更新処理は、必ずしも管理装置の要求に従った証明書管理サーバ４０による電子証明書の更新要求を契機に行われずともよい。
例えば、図６に示すリモート署名処理において、端末装置１０からの要求に応じて、証明書発行サーバ２０は、ステップＳ２１において、図５の処理で取得したアクセストークン（Access token）を用いて、リモート署名要求を鍵管理サーバ３０に送信する。
リモート署名要求送信を受信した鍵管理サーバ３０は、ステップＳ２２において、電子署名を生成し、ステップＳ２３において、生成された電子署名を証明書発行サーバ２０に送信する。
このとき、鍵管理サーバ３０は、ＨＳＭ１００に格納されているリモート署名要求に対応する電子証明書の失効が近い場合、電子署名とともに、ＣＳＲを証明書発行サーバ２０に送信してもよい。この方法によっても、端末装置１０の利用者に負担をかけることなく、電子証明書の更新を行うことが出来る。

【0070】

なお、上記では、端末装置１０と、証明書発行システム（証明書発行サーバ２０）と、鍵管理システム３（鍵管理サーバ３０）と、がそれぞれ一つずつ含まれるシステムを説明した。
それに限らず、本実施形態のリモート署名システム１は、複数の端末装置１０、複数の証明書発行システム２０、複数の鍵管理システム３０によって構成されることが出来る。

【0071】

１または複数の端末装置１０の利用者は、上記に説明した機能を有する複数の証明書発行システム（認証局）の中から、任意の証明書発行システム２０を選択し、その証明書発行ページにアクセスすることが出来る。
また、一の証明書発行システム２０は、上記に説明した機能を有する複数の鍵管理システム３０を信頼し、上記の手順に従って、各鍵管理システムで発行された公開鍵について電子証明書を発行して登録する処理を行う。
各証明書発行システムは、利用者をリダイレクト可能な鍵管理システムが複数ある場合、例えば、証明書発行ページに、利用可能な鍵管理システムのリストを表示し、その中から、利用する鍵管理システムを利用者に選択させることが出来る。

【0072】

なお、上記の特許文献１（特開２０１０−２００１４２公報）には、ユーザ端末、電子署名サーバ、認証局と、を備えたシステムが開示されている。
この特許文献１においては、認証局が秘密鍵、公開鍵の鍵ペアを生成する。そして、電子署名サーバは、認証局に対して公開鍵に基づく電子証明書の発行を要求する。認証局は、発行した電子証明書と秘密鍵をＰＫＣＳ＃１２と呼ばれる形式のファイルに格納し、電子署名サーバに供給する。
そして、電子署名サーバは、ユーザ端末からの求めに応じて、電子証明書、秘密鍵を用いて電子署名を行う。

【0073】

このように、特許文献１では認証局が鍵ペアを生成し、電子署名サーバは、認証局と直接的なやりとりによって証明書署名要求を行い、かつ生成された証明書と秘密鍵も、電子署名サーバと認証局の直接的なやりとりによって行われる。その間の通信において、利用者が介在する余地はない。

【0074】

それに対し本実施形態では、認証局（証明書発行システム）と、鍵管理サーバとの間に、利用者の端末装置が介在し、OAuth2.0（ＲＦＣ６７４９）の仕組みを用いて利用者が鍵管理サーバに対する認証を行い、その結果払い出されるアクセストークン（Access token）を用いて、認証局（証明書発行システム）と鍵管理サーバとの間で電子証明書の授受が行われる。
本実施形態において、私有鍵（秘密鍵）は、そもそも鍵管理サーバで生成されるものであり、認証局と鍵管理サーバとの間で授受されるものではない。
本実施形態では、利用者による鍵管理サーバに対する認証を契機に証明書署名要求、電子証明書のやり取りが行われるため、従来の方法に比べ、より安全に電子証明書の発行が可能である。また、私有鍵（秘密鍵）は、鍵管理システムで生成された後、他のサーバや端末に送信されることがないため、外部に漏れるリスクが低く、より安全な電子署名システムの運用が可能となる。

【0075】

［第１の発明］
本実施形態に係る第１の発明は、電子証明書を発行する証明書発行システム２と、利用者の秘密鍵を管理する機能を有し、秘密鍵を用いて電子署名を生成する鍵管理システム３と、を備える電子署名システムであって、鍵管理システム３は、アクセストークンを電子証明書発行システム２に送信し、証明書発行システム２は、アクセストークンを鍵管理システム３に提示することによって、鍵管理システム３から利用者の公開鍵を含む証明書発行要求を取得し、公開鍵に対して電子証明書を発行する電子署名システム１を特徴とする。
第１の発明の電子署名システムでは、リモート署名で求められる電子証明書の発行に際し、公開鍵を含む証明書署名要求及び電子証明書の発行が、アクセストークンを介して、認証局（証明書発行システム２）と信頼された署名サービス（鍵管理システム３）との間で自動的に行われる。
これにより、利用者の負担を軽減しながら電子証明書の安全な発行が可能な電子署名システムを実現することが出来る。

【0076】

［第２の発明］
本実施形態に係る第２の発明は、電子証明書を発行する証明書発行システムであって、所定のアクセストークンを用いて、利用者の公開鍵を含む証明書発行要求を鍵管理システムに要求する要求手段（署名リクエスト要求処理部５３）と、要求手段による要求に応じて取得した証明書発行要求に含まれる公開鍵に対して電子証明書を発行する発行手段（電子証明書発行処理部５４）と、を備える証明書発行システムを特徴とする。
第２の発明の証明書発行システムは、リモート署名で求められる電子証明書の発行に際し、信頼された署名サービス（鍵管理システム３）に対する公開鍵を含む証明書署名要求の要求及び電子証明書の発行を、アクセストークンを介して自動的に行うことが出来る。これにより、利用者の負担を軽減しながら電子証明書の発行を安全に行うことが出来る。

【0077】

［第３の発明］
本実施形態に係る第３の発明は、利用者の秘密鍵を管理する機能を有し、秘密鍵を用いて電子署名を生成する鍵管理システムであって、利用者の公開鍵を少なくとも生成する鍵生成手段（鍵生成処理部６３）と、アクセストークンを送信した証明書発行システムに対し、公開鍵を含む証明書発行要求を送信し、証明書発行システムに電子証明書を発行させる署名要求手段（署名要求処理部６４）と、を備える鍵管理システムを特徴とする。
第３の発明の鍵管理システムは、リモート署名で求められる電子証明書の発行に際し、証明書発行システムに対して公開鍵を含む証明書署名要求を、アクセストークンを介して自動で行い、電子証明書の発行を行わせることが出来る。
これにより、利用者の負担を軽減しながら電子証明書の発行を安全に行うことが出来る。

【符号の説明】

【0078】

１ リモート署名システム、１０ 端末装置、２０ 証明書発行サーバ、２１ ＣＰＵ、２２ ＲＡＭ、２３ ＨＤＤ、２４ ネットワークＩ／Ｆ、３０ 鍵管理サーバ、３１ ＣＰＵ、３２ ＲＡＭ、３３ ＨＤＤ、３４ ネットワークＩ／Ｆ、５１ ウェブページ処理部、５２ ＯＡｕｔｈ実行処理部、５３ 署名リクエスト要求処理部、５４ 電子証明書発行処理部、６１ ユーザ認証処理部、６２ ＯＡｕｔｈ実行処理部、６３ 鍵生成処理部、６４ 署名要求処理部、６５ 証明書格納処理部

【要約】

【課題】利用者の負担を低減できるとともに安全に電子証明書の発行、登録が可能な電子署名システムを提供することを目的とする。
【解決手段】端末装置１０は、鍵管理サーバ３０に対して認証要求を行い、認証が成功した場合、鍵管理サーバ３０は、端末装置１０に対して認可コードを送信し、端末装置１０は、認可コードを証明書発行サーバ２０に送付し、証明書発行サーバ２０は、端末装置１０から送付された認可コードを鍵管理サーバ３０に送付し、鍵管理サーバ３０は、認可コードと引き換えにアクセストークンを証明書発行サーバ２０に送付し、証明書発行サーバ２０は、アクセストークンを鍵管理サーバ３０に提示することによって、鍵管理サーバ３０より証明書署名要求を入手し、証明書署名要求に記載されている公開鍵に対して電子証明書を発行する。
【選択図】図５

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】