JP2021040278A - 鍵管理システム、署名装置、鍵管理方法及びプログラム - Google Patents
鍵管理システム、署名装置、鍵管理方法及びプログラム Download PDFInfo
- Publication number
- JP2021040278A JP2021040278A JP2019161938A JP2019161938A JP2021040278A JP 2021040278 A JP2021040278 A JP 2021040278A JP 2019161938 A JP2019161938 A JP 2019161938A JP 2019161938 A JP2019161938 A JP 2019161938A JP 2021040278 A JP2021040278 A JP 2021040278A
- Authority
- JP
- Japan
- Prior art keywords
- key
- information
- processing unit
- activation
- signature
- 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.)
- Pending
Links
Images
Abstract
【課題】リモート署名に用いる利用者の私有鍵（秘密鍵）を、利用者の意思に基づいて簡便に実行可能な、鍵管理システムを実現する。【解決手段】秘密鍵を記憶する鍵記憶部１０１と、外部装置が提示したトークン情報を受け付ける受付処理部６６と、受付処理部が受け付けたトークン情報に対応する活性化情報を用いて、活性化情報に対応する秘密鍵を活性化する鍵活性化処理部６４と、活性化された前記秘密鍵を用いて電子署名を生成する署名生成制御処理部６０と、を備えた。【選択図】図３
Description
本発明は、公開鍵基盤で必要とされる電子署名を生成するための鍵管理システム、及び署名装置に関する。
全世界的に電子政府が稼働し始め、従来、紙で行われてきた契約行為も電子的に行われるようになってきた。電子的に行われる契約（電子契約）では、暗号技術や公開鍵基盤を用いた方式が主流である。
公開鍵基盤を用いた電子契約では、公開鍵暗号方式をベースとして、文書の送り側では、本人の私有鍵（秘密鍵）を用いて契約文書（電子データ）に電子署名を付与し、文書の受け取り側では、送り側の公開鍵を用いて契約文書に付与される電子署名を検証することで、なり済ましや、通信経路での改竄の有無を判断することができる。後述するが、公開鍵基盤は、公開鍵と、それと対になる私有鍵（秘密鍵）と、を用いて様々なセキュリティシステムを提供することができる。
この方式では、契約文書の検証時に契約書に電子署名を施した相手方（送り側）の公開鍵が必要となる。そして、この公開鍵と対になる私有鍵が送り側の所有に係ること（公開鍵の本人性）を証明するため、公開鍵証明書、いわゆる「電子証明書」が用いられる。
「電子証明書」はインターネット上の身分証とも呼ばれ、信頼できる第三者機関（ＴＴＰ：Trusted Third Party）によって発行される。特に、電子証明書を発行するＴＴＰを認証局と呼ぶ。
従来、電子署名は利用者のＰＣ（Personal Computer）上で行われることが一般的であったが、サーバ上で行うことにより電子署名の利便性を高めた仕組みも知られている。
公開鍵基盤を用いた電子契約では、公開鍵暗号方式をベースとして、文書の送り側では、本人の私有鍵（秘密鍵）を用いて契約文書（電子データ）に電子署名を付与し、文書の受け取り側では、送り側の公開鍵を用いて契約文書に付与される電子署名を検証することで、なり済ましや、通信経路での改竄の有無を判断することができる。後述するが、公開鍵基盤は、公開鍵と、それと対になる私有鍵（秘密鍵）と、を用いて様々なセキュリティシステムを提供することができる。
この方式では、契約文書の検証時に契約書に電子署名を施した相手方（送り側）の公開鍵が必要となる。そして、この公開鍵と対になる私有鍵が送り側の所有に係ること（公開鍵の本人性）を証明するため、公開鍵証明書、いわゆる「電子証明書」が用いられる。
「電子証明書」はインターネット上の身分証とも呼ばれ、信頼できる第三者機関（ＴＴＰ：Trusted Third Party）によって発行される。特に、電子証明書を発行するＴＴＰを認証局と呼ぶ。
従来、電子署名は利用者のＰＣ（Personal Computer）上で行われることが一般的であったが、サーバ上で行うことにより電子署名の利便性を高めた仕組みも知られている。
例えば、特許文献１には、ユーザ端末、電子署名サーバ、認証局と、を備えたシステムが開示されている。
特許文献１においては、認証局が秘密鍵、公開鍵の鍵ペアを生成する。そして、電子署名サーバは、認証局に対して公開鍵に基づく電子証明書の発行を要求する。認証局は、発行した電子証明書と秘密鍵とをＰＫＣＳ＃１２と呼ばれるファイルとして電子署名サーバに供給し、電子署名サーバは、ユーザ端末からの求めに応じて、電子証明書、秘密鍵を用いて電子署名を行う。
特許文献１においては、認証局が秘密鍵、公開鍵の鍵ペアを生成する。そして、電子署名サーバは、認証局に対して公開鍵に基づく電子証明書の発行を要求する。認証局は、発行した電子証明書と秘密鍵とをＰＫＣＳ＃１２と呼ばれるファイルとして電子署名サーバに供給し、電子署名サーバは、ユーザ端末からの求めに応じて、電子証明書、秘密鍵を用いて電子署名を行う。
さらに近年では、「リモート署名」あるいは「クラウド署名」と呼ばれるという仕組みが普及をはじめ、そして、ヨーロッパ諸国のｅＩＤＡＳやＡｄｏｂｅ社をはじめとした標準化団体ＣＳＣ(Cloud Signature Consortium)などで、プロトコルの標準化が推し進められている。
より具体的には、電子署名サイトなどで電子署名が必要な状況になると、OAuth2.0によるＳＳＯ(Single Sign On)の仕組みなどを用いて、利用者が鍵管理システムへリダイレクトされ、鍵管理システムは、ユーザ認証後にトークンを払い出し、そのトークンを取得した電子署名サイトは、トークンを鍵管理システムに対して提示することで、鍵管理システムに署名を行わせる、といった仕組みが「リモート署名」として実装され始めている。
より具体的には、電子署名サイトなどで電子署名が必要な状況になると、OAuth2.0によるＳＳＯ(Single Sign On)の仕組みなどを用いて、利用者が鍵管理システムへリダイレクトされ、鍵管理システムは、ユーザ認証後にトークンを払い出し、そのトークンを取得した電子署名サイトは、トークンを鍵管理システムに対して提示することで、鍵管理システムに署名を行わせる、といった仕組みが「リモート署名」として実装され始めている。
「リモート署名」では、署名用の私有鍵を管理するために、ＨＳＭ(Hardware Security Module)と呼ばれる暗号装置を用いるのが一般的である。ＨＳＭは私有鍵を外界から保護するために、物理的セキュリティ機能と論理的セキュリティ機能を兼ね備える。
物理的セキュリティ機能は、例えば物理的にＨＳＭを破壊などして取り出そうとしたときに、ＨＳＭ内に格納された私有鍵を消去するなどの仕組みである。
一方、論理的セキュリティ機能は、ＨＳＭ内に格納された私有鍵を利用する際に、ＰＩＮ（Personal Identification Number）などのクレデンシャル情報を要求し、要求されるクレデンシャルが提供されない場合、私有鍵へのアクセスを遮断する仕組みである。
物理的セキュリティ機能は、例えば物理的にＨＳＭを破壊などして取り出そうとしたときに、ＨＳＭ内に格納された私有鍵を消去するなどの仕組みである。
一方、論理的セキュリティ機能は、ＨＳＭ内に格納された私有鍵を利用する際に、ＰＩＮ（Personal Identification Number）などのクレデンシャル情報を要求し、要求されるクレデンシャルが提供されない場合、私有鍵へのアクセスを遮断する仕組みである。
ＨＳＭにおける論理的セキュリティのクレデンシャル情報の具体例として、パーティションＩＤとパーティションパスワード、及びユーザＩＤとユーザパスワードがある。
パーティションとは、ＨＳＭ内の保護領域に対し、複数の対象が利用できるようにするために分割された保護領域のことである。この分割された保護領域にアクセスするためのクレデンシャルが、パーティションＩＤ及びパーティションパスワードである。一方、パーティション内の私有鍵などの保護リソースの保有者がユーザである。この保護リソースにアクセスするためには、当該ユーザのユーザＩＤとユーザパスワードが求められる。
つまり、ＨＳＭに格納される私有鍵にアクセスするためのクレデンシャルとして、パーティションＩＤとパーティションパスワード、及びユーザＩＤとユーザパスワードが必要である。
このような、ＨＳＭ内の保護リソースにアクセスするためのクレデンシャルは、ＨＳＭを外部システムから利用するために定義された標準インターフェースであるＰＫＣＳ＃１１の中に実装されている。つまり、標準的なＨＳＭでは、保護リソースにアクセスするために、パーティションＩＤとパーティションパスワード、及び、ユーザＩＤとユーザパスワードといったクレデンシャルが必要となる。
パーティションとは、ＨＳＭ内の保護領域に対し、複数の対象が利用できるようにするために分割された保護領域のことである。この分割された保護領域にアクセスするためのクレデンシャルが、パーティションＩＤ及びパーティションパスワードである。一方、パーティション内の私有鍵などの保護リソースの保有者がユーザである。この保護リソースにアクセスするためには、当該ユーザのユーザＩＤとユーザパスワードが求められる。
つまり、ＨＳＭに格納される私有鍵にアクセスするためのクレデンシャルとして、パーティションＩＤとパーティションパスワード、及びユーザＩＤとユーザパスワードが必要である。
このような、ＨＳＭ内の保護リソースにアクセスするためのクレデンシャルは、ＨＳＭを外部システムから利用するために定義された標準インターフェースであるＰＫＣＳ＃１１の中に実装されている。つまり、標準的なＨＳＭでは、保護リソースにアクセスするために、パーティションＩＤとパーティションパスワード、及び、ユーザＩＤとユーザパスワードといったクレデンシャルが必要となる。
従来知られるＨＳＭを用いた「リモート署名」の仕組みにおいては、電子署名サイトでは、電子署名を行う都度、ＨＳＭが要求するクレデンシャル、つまりパーティションＩＤとパーティションパスワード、及びユーザＩＤとユーザパスワードを利用者に入力させる必要がある。これは利用者にとって煩雑であり、ユーサビリティを損なうという問題がある。
本発明はそのような問題を解決するためになされたものであり、「リモート署名」に用いる利用者の私有鍵（秘密鍵）を、簡便且つ安全に利用可能な、鍵管理システム、及びそれを構成する署名装置を実現することを目的とする。
本発明はそのような問題を解決するためになされたものであり、「リモート署名」に用いる利用者の私有鍵（秘密鍵）を、簡便且つ安全に利用可能な、鍵管理システム、及びそれを構成する署名装置を実現することを目的とする。
上記の課題を解決するために、本発明は、秘密鍵を記憶する鍵記憶部と、前記秘密鍵を用いて電子署名を生成する署名処理部と、外部装置が提示したトークン情報を受け付ける受付処理部と、前記署名処理部による電子署名の生成前に、前記受付処理部が受け付けた前記トークン情報に対応する活性化情報を用いて、当該活性化情報に対応する秘密鍵を活性化する活性化処理部と、を備えた鍵管理システムを特徴とする。
上記のように構成することにより、本発明によれば「リモート署名」に用いる利用者の私有鍵（秘密鍵）の活性化を、簡便且つ安全に実行可能な鍵管理システム、署名装置を実現することができる。
以下に、図面を参照して本発明の実施の形態を詳細に説明する。
まず、本実施形態の説明に先立って前提となる技術を説明する。
［公開鍵基盤］
公開鍵基盤（ＰＫＩ：Public Key Infrastructure）は、公開鍵暗号方式と呼ばれる暗号方式を用い、暗号化、デジタル署名（電子署名）、認証といったセキュリティ機能を提供する情報セキュリティ基盤である。
公開鍵基盤では、公開鍵暗号方式の特徴を利用し、上述の暗号化、デジタル署名、認証といった機能を提供する。公開鍵暗号方式では、私有鍵と公開鍵の一方向性（私有鍵から公開鍵を計算できるが、公開鍵から私有鍵を計算するのは計算量的に困難であるという特徴）を利用して様々な機能を提供する。利用者は自らの私有鍵を秘密裏に保持し、公開鍵を他者に公開しておく。私有鍵は、秘密に保持するという意味を持たせて秘密鍵とも呼ぶ。
例えば利用者Ｂは、利用者Ａに文書を送信するとき、利用者Ａが公開している公開鍵を入手し、その公開鍵を使って暗号化した文書を利用者Ａに送信する。利用者Ａは受信した暗号化文書を、自身の私有鍵（秘密鍵）を用いて復号化する。
利用者Ａの公開鍵を持っていれば誰もが利用者Ａに対して暗号化文書を送信することができる一方で、利用者Ａの公開鍵で暗号化したものは、利用者Ａの私有鍵（秘密鍵）でしか復号できないため、仮に悪意の第三者が利用者Ａの公開鍵を入手したとしても、暗号化文書の内容が漏えいすることはない。
まず、本実施形態の説明に先立って前提となる技術を説明する。
［公開鍵基盤］
公開鍵基盤（ＰＫＩ：Public Key Infrastructure）は、公開鍵暗号方式と呼ばれる暗号方式を用い、暗号化、デジタル署名（電子署名）、認証といったセキュリティ機能を提供する情報セキュリティ基盤である。
公開鍵基盤では、公開鍵暗号方式の特徴を利用し、上述の暗号化、デジタル署名、認証といった機能を提供する。公開鍵暗号方式では、私有鍵と公開鍵の一方向性（私有鍵から公開鍵を計算できるが、公開鍵から私有鍵を計算するのは計算量的に困難であるという特徴）を利用して様々な機能を提供する。利用者は自らの私有鍵を秘密裏に保持し、公開鍵を他者に公開しておく。私有鍵は、秘密に保持するという意味を持たせて秘密鍵とも呼ぶ。
例えば利用者Ｂは、利用者Ａに文書を送信するとき、利用者Ａが公開している公開鍵を入手し、その公開鍵を使って暗号化した文書を利用者Ａに送信する。利用者Ａは受信した暗号化文書を、自身の私有鍵（秘密鍵）を用いて復号化する。
利用者Ａの公開鍵を持っていれば誰もが利用者Ａに対して暗号化文書を送信することができる一方で、利用者Ａの公開鍵で暗号化したものは、利用者Ａの私有鍵（秘密鍵）でしか復号できないため、仮に悪意の第三者が利用者Ａの公開鍵を入手したとしても、暗号化文書の内容が漏えいすることはない。
[電子証明書]
公開鍵暗号方式で通信を行うには、通信相手に公開鍵を送信することになるが、ネットワーク経由での通信では通信相手が見えないため、第三者が通信相手に成りすまして公開鍵を送信する可能性がある。従って、公開鍵が本当に正しい相手から送られてきたものであるかを確認する必要がある。
ＰＫＩでは、例えば、信頼できる第三者機関(ＴＴＰ： Trusted Third Party)が、私有鍵の所有者を保証する。すなわち、ＴＴＰは私有鍵（秘密鍵）の所有者の本人性を確認し、私有鍵（秘密鍵）と対になる公開鍵とその私有鍵（秘密鍵）の所有者とを紐づける電子証明書（公開鍵証明書）を発行する。電子証明書は持ち主の情報を正しく保障する「身分証明書」である。
電子証明書を発行するＴＴＰは、特に認証局あるいは認証機関（ＣＡ：Certification Authority）と呼ばれる。
電子証明書には、公開鍵と、その公開鍵に対応する私有鍵（秘密鍵）の所有者を証明する所有者の名前、所属組織名、メールアドレス等の情報が記載されており、さらに電子証明書自体の改ざんを防ぐためにＴＴＰの電子署名が付与されている。電子証明書を文書に付すことで、なりすましや、改ざんなどのリスクを未然に防ぐことができる。また、ＴＴＰに信頼される私有鍵（秘密鍵）の所有者を加入者(Subscriber、サブスクライバー)という。
公開鍵暗号方式で通信を行うには、通信相手に公開鍵を送信することになるが、ネットワーク経由での通信では通信相手が見えないため、第三者が通信相手に成りすまして公開鍵を送信する可能性がある。従って、公開鍵が本当に正しい相手から送られてきたものであるかを確認する必要がある。
ＰＫＩでは、例えば、信頼できる第三者機関(ＴＴＰ： Trusted Third Party)が、私有鍵の所有者を保証する。すなわち、ＴＴＰは私有鍵（秘密鍵）の所有者の本人性を確認し、私有鍵（秘密鍵）と対になる公開鍵とその私有鍵（秘密鍵）の所有者とを紐づける電子証明書（公開鍵証明書）を発行する。電子証明書は持ち主の情報を正しく保障する「身分証明書」である。
電子証明書を発行するＴＴＰは、特に認証局あるいは認証機関（ＣＡ：Certification Authority）と呼ばれる。
電子証明書には、公開鍵と、その公開鍵に対応する私有鍵（秘密鍵）の所有者を証明する所有者の名前、所属組織名、メールアドレス等の情報が記載されており、さらに電子証明書自体の改ざんを防ぐためにＴＴＰの電子署名が付与されている。電子証明書を文書に付すことで、なりすましや、改ざんなどのリスクを未然に防ぐことができる。また、ＴＴＰに信頼される私有鍵（秘密鍵）の所有者を加入者(Subscriber、サブスクライバー)という。
[電子署名]
電子証明書はさらに、電子署名を検証する用途に用いられる。通常、電子署名には、電子証明書を添付する。電子署名を受け取った利用者は、電子証明書に記載された公開鍵を使って署名を検証し、データの改ざん検知を行い、電子証明書に記載された内容を使って署名者の特定を行うことができる。
電子署名には、文書のハッシュ値を私有鍵（秘密鍵）で暗号化した値が含まれる（実際には、暗号処理と署名処理は異なるが、署名処理のことを広義の暗号化と呼ぶことが多い）。利用者Ａが利用者Ｂに対して電子署名を付した文書ファイルを送る場合、利用者Ａは、送信する文書ファイルをハッシュ関数にかけることによって得たハッシュ値を利用者Ａの私有鍵（秘密鍵）を用いて暗号化し、電子署名を作成して、文書ファイルに添付する。
電子署名付きの文書ファイルを受け取った利用者Ｂは、電子署名に含まれる暗号化された値を利用者Ａの公開鍵を使って復号化することによって得たハッシュ値と、文書ファイルをハッシュ関数にかけることによって得たハッシュ値と、を比較する。比較の結果、双方のハッシュ値が同一であれば、文書が改ざんされていないことが証明される。
電子証明書はさらに、電子署名を検証する用途に用いられる。通常、電子署名には、電子証明書を添付する。電子署名を受け取った利用者は、電子証明書に記載された公開鍵を使って署名を検証し、データの改ざん検知を行い、電子証明書に記載された内容を使って署名者の特定を行うことができる。
電子署名には、文書のハッシュ値を私有鍵（秘密鍵）で暗号化した値が含まれる（実際には、暗号処理と署名処理は異なるが、署名処理のことを広義の暗号化と呼ぶことが多い）。利用者Ａが利用者Ｂに対して電子署名を付した文書ファイルを送る場合、利用者Ａは、送信する文書ファイルをハッシュ関数にかけることによって得たハッシュ値を利用者Ａの私有鍵（秘密鍵）を用いて暗号化し、電子署名を作成して、文書ファイルに添付する。
電子署名付きの文書ファイルを受け取った利用者Ｂは、電子署名に含まれる暗号化された値を利用者Ａの公開鍵を使って復号化することによって得たハッシュ値と、文書ファイルをハッシュ関数にかけることによって得たハッシュ値と、を比較する。比較の結果、双方のハッシュ値が同一であれば、文書が改ざんされていないことが証明される。
［リモート署名］
様々なクラウドサービス、オンラインサービスが提供され、クラウド上（サーバ上）で文書を扱うことが多くなっている。それに伴い、文書に対する電子署名を署名者のＰＣ（Personal Computer）上ではなく、サーバ上（クラウド上）で行う「リモート署名（クラウド署名）」と呼ばれる方式の電子署名が普及しつつある。
より詳しくは、リモート署名とは、署名者の電子証明書、私有鍵（秘密鍵）を鍵管理システムで管理し、電子署名が必要なときには、鍵管理システム上で電子証明書、私有鍵（秘密鍵）を用いた電子署名を実行する仕組みである。
様々なクラウドサービス、オンラインサービスが提供され、クラウド上（サーバ上）で文書を扱うことが多くなっている。それに伴い、文書に対する電子署名を署名者のＰＣ（Personal Computer）上ではなく、サーバ上（クラウド上）で行う「リモート署名（クラウド署名）」と呼ばれる方式の電子署名が普及しつつある。
より詳しくは、リモート署名とは、署名者の電子証明書、私有鍵（秘密鍵）を鍵管理システムで管理し、電子署名が必要なときには、鍵管理システム上で電子証明書、私有鍵（秘密鍵）を用いた電子署名を実行する仕組みである。
リモート署名には、署名者が私有鍵（秘密鍵）を自ら管理する必要が無いという利点がある。さらに、ＰＣのみならず、ウェブブラウザやスマートフォンなどのモバイルデバイスによっても文書に電子署名が可能である。従って、私有鍵（秘密鍵）を格納したスマートカードやＵＳＢトークン等を用いたエンドポイントでの電子署名の生成に比べ、格段に利便性が向上する。さらに、鍵管理システムで私有鍵（秘密鍵）が堅牢に保護されるため、セキュリティの観点からも、より望ましい署名方法であると言える。
ＲＦＣ６７４９で定義されるＯＡｕｔｈ２．０は、概略としては、リソースサーバが保有している保護リソース（重要情報や鍵等）をリソースオーナーの許可を得てクライアントが使用することができるようにする仕組みである。
そして、リソースサーバが保有する保護リソースに対するクライアントのアクセス可否を認可サーバがコントロールする。
保護リソースにアクセスするにはアクセストークン（Access token）と呼ばれる情報が必要であり、認可サーバは、アクセスを許可するクライアントに対してアクセストークン（Access token）を発行する。
そして、リソースサーバが保有する保護リソースに対するクライアントのアクセス可否を認可サーバがコントロールする。
保護リソースにアクセスするにはアクセストークン（Access token）と呼ばれる情報が必要であり、認可サーバは、アクセスを許可するクライアントに対してアクセストークン（Access token）を発行する。
また、上記に加えてユーザーエージェント（例えばウェブブラウザ）がアクセスの介在をする場合がある。その場合、認可サーバにおけるリソースオーナーの認証、及び、認可サーバからクライアントへの認可コード（Authorization code）の送付を、ユーザーエージェントが仲介して行う。なお、認可コードは、認可トークンとも呼ぶ。
以下に、本実施形態のシステム及びその処理をより詳しく説明する。
図１は、本実施形態のシステム構成を説明する図である。
図１に示すように、本実施形態のリモート署名システム１は、端末装置１０と、署名提供サーバ２０を含む署名提供システム２と、鍵管理サーバ３０を含む鍵管理システム３と、を備える。
図１は、本実施形態のシステム構成を説明する図である。
図１に示すように、本実施形態のリモート署名システム１は、端末装置１０と、署名提供サーバ２０を含む署名提供システム２と、鍵管理サーバ３０を含む鍵管理システム３と、を備える。
端末装置１０、署名提供システム２、鍵管理システム３は、いずれもインターネットに接続され、互いに通信可能に構成されている。
これらの装置、システム間でやり取りされるデータの類は、おもにＨＴＴＰリクエストやＨＴＴＰレスポンスのパラメータとして（ＨＴＴＰプロトコルを利用して）送受信される。ただし、セキュリティ確保が必要な部分においては、通信自体を、ＨＴＴＰＳやＶＰＮを利用するなどして保護する。
これらの装置、システム間でやり取りされるデータの類は、おもにＨＴＴＰリクエストやＨＴＴＰレスポンスのパラメータとして（ＨＴＴＰプロトコルを利用して）送受信される。ただし、セキュリティ確保が必要な部分においては、通信自体を、ＨＴＴＰＳやＶＰＮを利用するなどして保護する。
端末装置１０は、利用者の利用に係る一般的なＰＣやスマートフォンである。
端末装置１０のＣＰＵによって実行されるウェブブラウザは、署名提供システム２が提供する電子署名サイトのウェブページを要求するページ要求手段、署名提供システム２の署名提供サーバ２０から受信した転送ページ等を表示するページ表示手段、認可要求（Authorization request）を鍵管理システム３の鍵管理サーバ３０に送信し、認可コード（Authorization code）を含む認可応答（Authorization response）を受信するＯＡｕｔｈ実行手段、ＫｅｙＡｌｉａｓとＰＩＮの入力を受け付けて鍵管理サーバ３０に送信する鍵情報送信手段、鍵管理サーバ３０から受信した認可コード（Authorization code）の署名提供サーバ２０への転送等の処理を行う認可コード送信手段等として機能する。
署名提供システム２は、署名プロバイダーとして電子署名サイトを提供する。
署名提供システム２は、電子署名サイトを介した利用者による署名対象データへの署名要求を受け付け、鍵管理システム３に対してリモート署名要求を行い、生成された電子署名を鍵管理システム３から取得する。
端末装置１０のＣＰＵによって実行されるウェブブラウザは、署名提供システム２が提供する電子署名サイトのウェブページを要求するページ要求手段、署名提供システム２の署名提供サーバ２０から受信した転送ページ等を表示するページ表示手段、認可要求（Authorization request）を鍵管理システム３の鍵管理サーバ３０に送信し、認可コード（Authorization code）を含む認可応答（Authorization response）を受信するＯＡｕｔｈ実行手段、ＫｅｙＡｌｉａｓとＰＩＮの入力を受け付けて鍵管理サーバ３０に送信する鍵情報送信手段、鍵管理サーバ３０から受信した認可コード（Authorization code）の署名提供サーバ２０への転送等の処理を行う認可コード送信手段等として機能する。
署名提供システム２は、署名プロバイダーとして電子署名サイトを提供する。
署名提供システム２は、電子署名サイトを介した利用者による署名対象データへの署名要求を受け付け、鍵管理システム３に対してリモート署名要求を行い、生成された電子署名を鍵管理システム３から取得する。
鍵管理システム３は、利用者の私有鍵（秘密鍵）、電子証明書を管理してリモート署名サービスを提供するシステムであり、例えば署名提供システム２（署名プロバイダー）からの要求に応じて電子署名を生成し、要求元に供給する。
本実施形態の鍵管理システム３は、例えば、鍵管理サーバ３０と、ハードウェアセキュリティモジュール（ＨＳＭ：Hardware Security Module）１００と、を備えている。
ＨＳＭ１００は、利用者の私有鍵（秘密鍵）と公開鍵のペアを生成し、認証局で発行された利用者の電子証明書をインポートして管理するとともに、私有鍵（秘密鍵）を用いて電子署名を生成する装置である。
本実施形態の鍵管理システム３は、例えば、鍵管理サーバ３０と、ハードウェアセキュリティモジュール（ＨＳＭ：Hardware Security Module）１００と、を備えている。
ＨＳＭ１００は、利用者の私有鍵（秘密鍵）と公開鍵のペアを生成し、認証局で発行された利用者の電子証明書をインポートして管理するとともに、私有鍵（秘密鍵）を用いて電子署名を生成する装置である。
本実施形態のシステムにおいて、ＨＳＭ１００は、例えば、鍵管理サーバ３０の内部バスに接続されるかたちで鍵管理サーバ３０に内蔵される。また、ＨＳＭ１００は、鍵管理サーバの外部バス（ＵＳＢバスなど）に接続されてもよい。
さらに、ＨＳＭ１００はネットワークインターフェイスを備え、ＨＳＭ１００単独でネットワークに接続可能とされてもよい。ＨＳＭ１００は、鍵管理サーバ３０と同一のローカルネットワーク、遠隔のネットワークにおいて、鍵管理サーバ３０と通信可能に接続される。
さらに、ＨＳＭ１００はネットワークインターフェイスを備え、ＨＳＭ１００単独でネットワークに接続可能とされてもよい。ＨＳＭ１００は、鍵管理サーバ３０と同一のローカルネットワーク、遠隔のネットワークにおいて、鍵管理サーバ３０と通信可能に接続される。
ＨＳＭの基本的な特徴を説明するとともに、標準的なＨＳＭを用いたリモート署名システムが有する問題点を説明する。
リモート署名を提供する鍵管理システムでは、利用者の署名用の私有鍵を管理するための暗号装置としてＨＳＭが一般的に用いられる。
ＨＳＭは、私有鍵を外界から保護するために、物理的セキュリティ機能と論理的セキュリティ機能とを兼ね備えている。
物理的セキュリティ機能は、例えば物理的にＨＳＭを破壊して私有鍵を取り出そうとしたときに、ＨＳＭ内に格納された私有鍵を消去するなどの仕組みである。
一方、論理的セキュリティ機能は、ＨＳＭ内に格納された私有鍵を利用する際に、ＰＩＮ（Personal Identification Number）などのクレデンシャル情報を要求し、要求されるクレデンシャルが提供されない場合、私有鍵へのアクセスを遮断する仕組みである。
リモート署名を提供する鍵管理システムでは、利用者の署名用の私有鍵を管理するための暗号装置としてＨＳＭが一般的に用いられる。
ＨＳＭは、私有鍵を外界から保護するために、物理的セキュリティ機能と論理的セキュリティ機能とを兼ね備えている。
物理的セキュリティ機能は、例えば物理的にＨＳＭを破壊して私有鍵を取り出そうとしたときに、ＨＳＭ内に格納された私有鍵を消去するなどの仕組みである。
一方、論理的セキュリティ機能は、ＨＳＭ内に格納された私有鍵を利用する際に、ＰＩＮ（Personal Identification Number）などのクレデンシャル情報を要求し、要求されるクレデンシャルが提供されない場合、私有鍵へのアクセスを遮断する仕組みである。
ＨＳＭ１００における論理的セキュリティのクレデンシャル情報の具体例として、パーティションＩＤとパーティションパスワード、及び利用者のユーザＩＤとユーザパスワードがある。パーティションとは、ＨＳＭ内の保護領域に対し、複数の対象が利用できるようにするために、分割された保護領域のことである。
この分割された保護領域にアクセスするためのクレデンシャルが、パーティションＩＤ及びパーティションパスワードである。一方、パーティション内の私有鍵などの保護リソースの保有者は、利用者である。
ＨＳＭは、この保護リソースにアクセスするためにはユーザＩＤとユーザパスワードを必要とする。つまり私有鍵にアクセスするためのクレデンシャルとして、パーティションＩＤとパーティションパスワード、及び、ユーザＩＤとユーザパスワードが必要である。
この分割された保護領域にアクセスするためのクレデンシャルが、パーティションＩＤ及びパーティションパスワードである。一方、パーティション内の私有鍵などの保護リソースの保有者は、利用者である。
ＨＳＭは、この保護リソースにアクセスするためにはユーザＩＤとユーザパスワードを必要とする。つまり私有鍵にアクセスするためのクレデンシャルとして、パーティションＩＤとパーティションパスワード、及び、ユーザＩＤとユーザパスワードが必要である。
このような、ＨＳＭ内の保護リソースにアクセスするためのクレデンシャルは、ＨＳＭ１００を外部システムから利用するために定義された標準インターフェースであるＰＫＣＳ＃１１の中に実装されている。
つまり、標準的なＨＳＭでは、保護リソースにアクセスするために、パーティションＩＤとパーティションパスワード、及び、ユーザＩＤとユーザパスワードといったクレデンシャルが必要となる。
鍵管理システム３このような標準的なＨＳＭを利用する場合、署名提供システム２は、利用者の求めに応じて電子署名を鍵管理システム３に要求する都度、クレデンシャルの入力を利用者に求める必要があり、これは利用者にとって煩雑でありユーザビリティを損なう。
つまり、標準的なＨＳＭでは、保護リソースにアクセスするために、パーティションＩＤとパーティションパスワード、及び、ユーザＩＤとユーザパスワードといったクレデンシャルが必要となる。
鍵管理システム３このような標準的なＨＳＭを利用する場合、署名提供システム２は、利用者の求めに応じて電子署名を鍵管理システム３に要求する都度、クレデンシャルの入力を利用者に求める必要があり、これは利用者にとって煩雑でありユーザビリティを損なう。
それに対し本実施形態のリモート署名システム１において、鍵管理システム３は、パーティションＩＤとパーティションパスワード、及び、ユーザＩＤとユーザパスワードといったクレデンシャルを電子署名サイト（署名提供システム２）、あるいは利用者に求めることがない。これは基本的には以下のような構成による。
図１に示すリモート署名システム１において、リダイレクトされた利用者（端末装置１０で実行されるウェブブラウザ）が鍵管理サーバ３０に対して、ユーザＩＤとユーザパスワードと用いた認証を要求し、認証が成功した際には、鍵管理サーバ３０は、端末装置１０（ウェブブラウザ）に対して認可コード（Authorization code）を送付する。
認可コード（Authorization code）を受け取った端末装置１０（ウェブブラウザ）は、その認可コード（Authorization code）を署名提供サーバ２０に送付（転送）する。
署名提供サーバ２０は、端末装置１０（ウェブブラウザ）より送付された認可コード（Authorization code）を鍵管理サーバ３０に送付し、鍵管理サーバ３０は、その認可コード（Authorization code）と引き換えにセキュリティトークンとしてのアクセストークン（Access token）を署名提供サーバ２０に送付する。
署名提供サーバ２０は、端末装置１０（ウェブブラウザ）より送付された認可コード（Authorization code）を鍵管理サーバ３０に送付し、鍵管理サーバ３０は、その認可コード（Authorization code）と引き換えにセキュリティトークンとしてのアクセストークン（Access token）を署名提供サーバ２０に送付する。
アクセストークン（Access token）の発行以後は、署名提供サーバ２０は、利用者の署名要求に応じて、アクセストークン（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）と、署名提供サーバ２０をネットワークに接続するためのネットワークＩ／Ｆ２４と、を備えている。
また、図２（ｂ）に示すように、ＣＰＵ２１は、制御部２０Ａとして、ウェブページ処理部５１、ＯＡｕｔｈ実行処理部５２、署名要求処理部５３を実行する。
ウェブページ処理部５１は、所謂ウェブサーバとして機能し、端末装置１０からのＨＴＴＰリクエストに応じて、記憶部２０Ｂを構成するＨＤＤ２３に格納されるウェブページ（ＨＴＭＬページ）のデータから電子署名サイトのウェブページのデータを送信する。ウェブページ処理部５１は、署名提供サーバ２０とは異なる独立したサーバ装置（ウェブサーバ）として構成されてもよい。
すなわち、署名提供サーバ２０は、電子署名の発行を受け付ける電子署名サイトのウェブページを供給して端末装置のウェブブラウザで表示させるためのウェブサーバの機能を有する。あるいは、署名提供システム２は、バックエンドの署名提供サーバ２０と、ユーザがアクセスするフロントエンドとしてのウェブサーバと、から構成されている。
ウェブページ処理部５１は、所謂ウェブサーバとして機能し、端末装置１０からのＨＴＴＰリクエストに応じて、記憶部２０Ｂを構成するＨＤＤ２３に格納されるウェブページ（ＨＴＭＬページ）のデータから電子署名サイトのウェブページのデータを送信する。ウェブページ処理部５１は、署名提供サーバ２０とは異なる独立したサーバ装置（ウェブサーバ）として構成されてもよい。
すなわち、署名提供サーバ２０は、電子署名の発行を受け付ける電子署名サイトのウェブページを供給して端末装置のウェブブラウザで表示させるためのウェブサーバの機能を有する。あるいは、署名提供システム２は、バックエンドの署名提供サーバ２０と、ユーザがアクセスするフロントエンドとしてのウェブサーバと、から構成されている。
ＯＡｕｔｈ実行処理部５２は、鍵管理サーバ３０のＯＡｕｔｈ実行処理部６１とともに、所謂ＲＦＣ６７４９に規定されるＯＡｕｔｈ２．０の認可処理を制御するための処理部であり、端末装置１０（ウェブブラウザ）から送信された認可コード（Authorization code）を用いて、鍵管理サーバ３０にセキュリティトークンとしてのアクセストークン（Access token）を要求する処理を行う。
署名要求処理部５３は、後に詳述するように、端末装置１０からの要求に応じて、ＯＡｕｔｈ実行処理部５２によって取得されたアクセストークン（Access token）を用いて、鍵管理サーバ３０に対して電子署名（署名値）の要求を行う。
鍵管理サーバ３０は、署名要求処理部５３が行ったアクセストークン（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）と、鍵管理サーバ３０をネットワークに接続するためのネットワークＩ／Ｆ３４と、を備えている。
ＣＰＵ３１は、鍵管理サーバ３０が備えて制御部を実現する制御回路の一例であり、制御回路としては、その他にマルチコアＣＰＵ、ＦＰＧＡ（Field Programmable Gate Array）、ＰＬＤ（Programmable Logic Device）などのプロセッサを適用することが出来る。
ＨＤＤ３３は、内蔵するハードディスク（Hard Disk）を駆動するドライブ装置であり、ＨＤＤ３３は記憶媒体としてのハードディスクに格納されたプログラムやデータを読み出し、またハードディスクにデータを書き込む。
ＨＤＤ３３は、内蔵するハードディスク（Hard Disk）を駆動するドライブ装置であり、ＨＤＤ３３は記憶媒体としてのハードディスクに格納されたプログラムやデータを読み出し、またハードディスクにデータを書き込む。
また、鍵管理サーバ３０は、ＦＤ（Floppy Disk）、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）、ＢＤ（Blu-ray（登録商標） Disk）などの光学ディスク、フラッシュメモリなどの着脱可能な記憶媒体２００に対してプログラムやデータを読み書きする読書装置３５を備えてもよい。
読書装置３５は、ＦＤＤ（Floppy Disk Drive）、ＣＤＤ（Compact Disc Drive）、ＤＶＤＤ（Digital Versatile Disc Drive）、ＢＤＤ（Blu-ray（登録商標） Disk Drive）、ＵＳＢ（Universal Serial Bus）などである。
ＣＰＵ３１、ＲＡＭ３２、ＨＤＤ３３、ネットワークＩ／Ｆ３４、読書装置３５は例えば内部バスを介して接続されている。
読書装置３５は、ＦＤＤ（Floppy Disk Drive）、ＣＤＤ（Compact Disc Drive）、ＤＶＤＤ（Digital Versatile Disc Drive）、ＢＤＤ（Blu-ray（登録商標） Disk Drive）、ＵＳＢ（Universal Serial Bus）などである。
ＣＰＵ３１、ＲＡＭ３２、ＨＤＤ３３、ネットワークＩ／Ｆ３４、読書装置３５は例えば内部バスを介して接続されている。
さらに、鍵管理サーバ３０は、内部バスに接続されたハードウェアセキュリティモジュール（ＨＳＭ：Hardware Security Module）１００を備えている。この場合、鍵管理サーバ３０は、鍵管理システム３と同義である。
上記したように、ＨＳＭ１００は、鍵管理サーバ３０の外部バスに接続されていてもよいし、ネットワークＩ／Ｆを有してネットワーク経由で鍵管理サーバ３０と接続可能されてもよい。この場合、鍵管理サーバ３０と、ネットワーク接続型ＨＳＭ１００と、によって鍵管理システム３が構成される。
上記したように、ＨＳＭ１００は、鍵管理サーバ３０の外部バスに接続されていてもよいし、ネットワークＩ／Ｆを有してネットワーク経由で鍵管理サーバ３０と接続可能されてもよい。この場合、鍵管理サーバ３０と、ネットワーク接続型ＨＳＭ１００と、によって鍵管理システム３が構成される。
ＨＳＭ１００は、記憶領域１０１を備え、記憶領域１０１に私有鍵（秘密鍵）を格納する。
ＨＳＭ１００は、鍵管理サーバ３０の要求に応じて私有鍵（秘密鍵）を用いて電子署名を生成する署名処理部（回路）１０２を有する。
またＨＳＭ１００は、鍵ペアを生成する鍵生成処理部（回路）１０３を有する。署名処理部１０２、鍵生成処理部１０３は、ＨＳＭ１００が備えるＭＰＵによって実現されてもよい。
ＨＳＭ１００は、鍵管理サーバ３０の要求に応じて私有鍵（秘密鍵）を用いて電子署名を生成する署名処理部（回路）１０２を有する。
またＨＳＭ１００は、鍵ペアを生成する鍵生成処理部（回路）１０３を有する。署名処理部１０２、鍵生成処理部１０３は、ＨＳＭ１００が備えるＭＰＵによって実現されてもよい。
また、図３（ｂ）に示すように、ＣＰＵ３１は、制御部３０Ａとして、署名生成制御処理部６０と、ＯＡｕｔｈ実行処理部６１と、ユーザ認証処理部６２と、鍵生成制御処理部６３と、鍵活性化処理部６４と、鍵活性化情報処理部６５と、受付処理部６６と、を実行する。
これらの処理部は、鍵管理サーバ３０の制御部３０Ａの機能を実現するプログラムであり、当該プログラムは、ＨＤＤ３３に含まれるハードディスクや記憶媒体２００に格納され得る。プログラムは、ＨＤＤ３３や読書装置３５によってハードディスクや記憶媒体２００からＲＡＭ３２に読み出されてＣＰＵ３１によって実行される。
署名生成制御処理部６０は、署名提供サーバ２０からの電子署名発行要求に応じて、ＨＳＭ１００に電子署名を生成させる処理を行う。
ＯＡｕｔｈ実行処理部６１は、署名提供サーバ２０のＯＡｕｔｈ実行処理部５２とともに、ＲＦＣ６７４９に規定されるＯＡｕｔｈ２．０の認可処理を制御するための処理部である。
これらの処理部は、鍵管理サーバ３０の制御部３０Ａの機能を実現するプログラムであり、当該プログラムは、ＨＤＤ３３に含まれるハードディスクや記憶媒体２００に格納され得る。プログラムは、ＨＤＤ３３や読書装置３５によってハードディスクや記憶媒体２００からＲＡＭ３２に読み出されてＣＰＵ３１によって実行される。
署名生成制御処理部６０は、署名提供サーバ２０からの電子署名発行要求に応じて、ＨＳＭ１００に電子署名を生成させる処理を行う。
ＯＡｕｔｈ実行処理部６１は、署名提供サーバ２０のＯＡｕｔｈ実行処理部５２とともに、ＲＦＣ６７４９に規定されるＯＡｕｔｈ２．０の認可処理を制御するための処理部である。
ＯＡｕｔｈ実行処理部６１は、端末装置１０（ウェブブラウザ）から認可要求（Authorization request）を受信すると、認証画面を端末装置１０に表示させ、ユーザ認証処理部６２による認証が成功した場合に、認可応答（Authorization response）として、認可コード（Authorization code）を端末装置１０に送信する。
さらに、ＯＡｕｔｈ実行処理部６１は、署名提供サーバ２０から認可コード（Authorization code）とともにセキュリティトークンとしてのアクセストークン（Access token）を要求されると、署名提供サーバ２０に対してアクセストークン（Access token）を送信する処理を行う。
さらに、ＯＡｕｔｈ実行処理部６１は、署名提供サーバ２０から認可コード（Authorization code）とともにセキュリティトークンとしてのアクセストークン（Access token）を要求されると、署名提供サーバ２０に対してアクセストークン（Access token）を送信する処理を行う。
ユーザ認証処理部６２は、端末装置１０に表示された認証画面に入力された認証情報（例えば、ユーザＩＤ及びユーザパスワードの組み合わせ）を認証し、認証されれば上記ＯＡｕｔｈ実行処理部６１に通知する処理を行う処理部である。
鍵生成制御処理部６３は、ＨＳＭ１００を制御し、私有鍵（秘密鍵）と公開鍵のペアを生成させる鍵生成処理を行う処理部である。私有鍵（秘密鍵）は、例えば、端末装置１０から受信したＫｅｙＡｌｉａｓ、ＰＩＮに基づいて生成される。
鍵生成制御処理部６３は、ＨＳＭ１００を制御し、私有鍵（秘密鍵）と公開鍵のペアを生成させる鍵生成処理を行う処理部である。私有鍵（秘密鍵）は、例えば、端末装置１０から受信したＫｅｙＡｌｉａｓ、ＰＩＮに基づいて生成される。
ＨＳＭ１００が備える記憶領域１０１は、複数のパーティションに分割されている。各パーティションはユーザ毎に割り当てられており、鍵生成制御処理部６３が生成した私有鍵（秘密鍵）が夫々格納される。
各パーティションには、例えば、Ｐａｒｔ．１、Ｐａｒｔ．２、Ｐａｒｔ．３、Ｐａｒｔ．４・・・など夫々のパーティションを特定するためのパーティションＩＤとしての名前（Partition Name）が付けられており、アクセス制限用のパーティションパスワード（Partition Password）が設定される。
鍵生成制御処理部６３またはＨＳＭ１００は、鍵生成処理の際に、鍵を格納するためのパーティションを設定し、パーティションパスワードを設定する。
各パーティションには、例えば、Ｐａｒｔ．１、Ｐａｒｔ．２、Ｐａｒｔ．３、Ｐａｒｔ．４・・・など夫々のパーティションを特定するためのパーティションＩＤとしての名前（Partition Name）が付けられており、アクセス制限用のパーティションパスワード（Partition Password）が設定される。
鍵生成制御処理部６３またはＨＳＭ１００は、鍵生成処理の際に、鍵を格納するためのパーティションを設定し、パーティションパスワードを設定する。
鍵管理サーバ３０は、ＲＡＭ３２またはＨＤＤ３３から構成される記憶部３０Ｂに、活性化情報記憶部９１を備えている。
上記したが、「リモート署名」を行うためにＨＳＭ１００に格納された私有鍵（秘密鍵）は、活性化と呼ばれる処理を行わない限りは電子署名の生成に用いることができない。そして、私有鍵（秘密鍵）の活性化に必要な情報が、鍵生成処理の際に用いられたＫｅｙＡｌｉａｓ、ＰＩＮ、そして秘密鍵を格納したＨＳＭ１００のパーティションを特定するパーティションＩＤとしての名前（Partition Name）及びパーティションパスワード（Partition Password）からなるクレデンシャルである。
上記したが、「リモート署名」を行うためにＨＳＭ１００に格納された私有鍵（秘密鍵）は、活性化と呼ばれる処理を行わない限りは電子署名の生成に用いることができない。そして、私有鍵（秘密鍵）の活性化に必要な情報が、鍵生成処理の際に用いられたＫｅｙＡｌｉａｓ、ＰＩＮ、そして秘密鍵を格納したＨＳＭ１００のパーティションを特定するパーティションＩＤとしての名前（Partition Name）及びパーティションパスワード（Partition Password）からなるクレデンシャルである。
本実施形態は、鍵管理システム３における私有鍵（秘密鍵）の活性化方法に特徴を有する。
活性化情報記憶部９１には、下記に詳しく説明するように、各パーティションに格納される私有鍵（秘密鍵）を活性化するための活性化情報が格納されている。
私有鍵（秘密鍵）を活性化するための活性化情報は、後述の鍵活性化処理部６４によって用いられる。
活性化情報記憶部９１には、下記に詳しく説明するように、各パーティションに格納される私有鍵（秘密鍵）を活性化するための活性化情報が格納されている。
私有鍵（秘密鍵）を活性化するための活性化情報は、後述の鍵活性化処理部６４によって用いられる。
鍵活性化処理部６４は、署名提供サーバ２０により所定のトークン情報を付した署名要求が行われたとき、上記トークン情報と活性化情報記憶部９１内の活性化情報を用いて、パーティション内の私有鍵（秘密鍵）を活性化する。そして、鍵活性化処理部６４は、活性化した私有鍵（秘密鍵）を用いて電子署名の生成を行う。
換言すると、鍵活性化処理部６４は、署名提供サーバ２０よりの署名要求に応じて電子署名の生成を行うのに先立って、活性化情報を用いて、電子署名の生成に用いる私有鍵（秘密鍵）の活性化を行う。
私有鍵（秘密鍵）の活性化はリモート署名の都度行われてもよい（署名後に鍵は非活性化される）し、初回のリモート署名時にのみ行われてもよい。
換言すると、鍵活性化処理部６４は、署名提供サーバ２０よりの署名要求に応じて電子署名の生成を行うのに先立って、活性化情報を用いて、電子署名の生成に用いる私有鍵（秘密鍵）の活性化を行う。
私有鍵（秘密鍵）の活性化はリモート署名の都度行われてもよい（署名後に鍵は非活性化される）し、初回のリモート署名時にのみ行われてもよい。
鍵活性化情報処理部６５は、鍵生成制御処理部６３が鍵生成処理を行ったときに用いたＫｅｙＡｌｉａｓ、ＰＩＮ、及び生成した鍵を格納したＨＳＭ１００内のパーティションのＰａｒｔｉｔｉｏｎ Ｎａｍｅ、Ｐａｒｔｉｔｉｏｎ Ｐａｓｓｗｏｒｄを、アクセストークンに紐付けた活性化情報として、活性化情報記憶部９１に格納する処理を行う。
受付処理部６６は、署名提供サーバ２０から行われるリモート署名の要求の受付処理を行う。
シングルサインオンの技術において、鍵管理システム３（鍵管理サーバ３０）は、認証情報を提供する側であるＩｄｅｎｔｉｔｙ Ｐｒｏｖｉｄｅｒ（ＩｄＰ）であり、署名提供システム２（署名提供サーバ２０）は、認証情報を利用する側であるＳｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ（ＳＰ）である。
受付処理部６６は、署名提供サーバ２０から行われるリモート署名の要求の受付処理を行う。
シングルサインオンの技術において、鍵管理システム３（鍵管理サーバ３０）は、認証情報を提供する側であるＩｄｅｎｔｉｔｙ Ｐｒｏｖｉｄｅｒ（ＩｄＰ）であり、署名提供システム２（署名提供サーバ２０）は、認証情報を利用する側であるＳｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ（ＳＰ）である。
図４は、本実施形態のリモート署名システムにおけるアクセストークン発行処理の流れを説明する図である。
ステップＳ１において、利用者が使用する端末装置１０（ウェブブラウザ）は、電子署名を要求するために署名提供サーバ２０にアクセスする。
電子署名の要求を受けた署名提供サーバ２０は、ステップＳ２において、利用者を鍵管理サーバ３０にリダイレクトするページを端末装置１０に供給する。
利用者の操作によって、端末装置１０は、ステップＳ３において、鍵管理サーバ３０に対して、認可要求（Authorization request）の送信を行う（ＲＦＣ６７４９＃４．１．１．）。これは、シングルサインオンの仕組みにおいて利用者の認証を要求するための手続である。
ステップＳ１において、利用者が使用する端末装置１０（ウェブブラウザ）は、電子署名を要求するために署名提供サーバ２０にアクセスする。
電子署名の要求を受けた署名提供サーバ２０は、ステップＳ２において、利用者を鍵管理サーバ３０にリダイレクトするページを端末装置１０に供給する。
利用者の操作によって、端末装置１０は、ステップＳ３において、鍵管理サーバ３０に対して、認可要求（Authorization request）の送信を行う（ＲＦＣ６７４９＃４．１．１．）。これは、シングルサインオンの仕組みにおいて利用者の認証を要求するための手続である。
ステップＳ４のユーザ認証処理において、鍵管理サーバ３０は、認証情報（例えば、ユーザＩＤとユーザパスワード）の入力を利用者に要求する。また、当該の利用者のアカウントが未作成の場合には、鍵管理サーバ３０は、当該利用者のためのアカウントを新規に作成する処理を行う。
なお、ステップＳ４のユーザ認証処理において、認証情報の入力はＲＦＣ６７４９（ＯＡｕｔｈ２．０）で規定される処理とは異なり、鍵管理サーバ３０と端末装置１０との間で別途確立されるセッションにおいて行われる。
認証の方法は、ユーザＩＤ及びユーザパスワードの組み合わせを認証する形式のみならず、ＩＣカードに格納されたトークンが端末装置か１０から鍵管理サーバ３０に送付されることにより認証が行われる場合もある。
利用者の認証又はアカウントの作成が正常に行われると、鍵管理サーバ３０は、利用者の確認を得たうえで認可を確立し、ステップＳ５において、認可応答（Authorization response）として、認可コード（Authorization code）を端末装置１０に送信する（ＲＦＣ６７４９＃４．１．２．）。
なお、ステップＳ４のユーザ認証処理において、認証情報の入力はＲＦＣ６７４９（ＯＡｕｔｈ２．０）で規定される処理とは異なり、鍵管理サーバ３０と端末装置１０との間で別途確立されるセッションにおいて行われる。
認証の方法は、ユーザＩＤ及びユーザパスワードの組み合わせを認証する形式のみならず、ＩＣカードに格納されたトークンが端末装置か１０から鍵管理サーバ３０に送付されることにより認証が行われる場合もある。
利用者の認証又はアカウントの作成が正常に行われると、鍵管理サーバ３０は、利用者の確認を得たうえで認可を確立し、ステップＳ５において、認可応答（Authorization response）として、認可コード（Authorization code）を端末装置１０に送信する（ＲＦＣ６７４９＃４．１．２．）。
鍵管理サーバ３０から送信された認可コード（Authorization code）を受信した端末装置１０（ウェブブラウザ）は、ステップＳ８において、認可コード（Authorization code）を署名提供サーバ２０に転送（Redirect）する。
端末装置１０から転送された認可コード（Authorization code）を取得した署名提供サーバ２０は、ステップＳ９において、この認可コード（Authorization code）を用いて、Ａｃｃｅｓｓ ｔｏｋｅｎ ｒｅｑｕｅｓｔ（アクセストークン要求）を鍵管理サーバ３０に対して行う（ＲＦＣ６７４９＃４．１．３．）。
Ａｃｃｅｓｓ ｔｏｋｅｎ ｒｅｑｕｅｓｔ（アクセストークン要求）を受けつけた鍵管理サーバ３０は、ステップＳ１０において、アクセストークン応答（Access token response）を署名提供サーバ２０に返す。
すなわち鍵管理サーバ３０は、セキュリティトークンとしてのアクセストークン（Access token）を署名提供サーバ２０に送信する（ＲＦＣ６７４９＃４．１．４．）。
端末装置１０から転送された認可コード（Authorization code）を取得した署名提供サーバ２０は、ステップＳ９において、この認可コード（Authorization code）を用いて、Ａｃｃｅｓｓ ｔｏｋｅｎ ｒｅｑｕｅｓｔ（アクセストークン要求）を鍵管理サーバ３０に対して行う（ＲＦＣ６７４９＃４．１．３．）。
Ａｃｃｅｓｓ ｔｏｋｅｎ ｒｅｑｕｅｓｔ（アクセストークン要求）を受けつけた鍵管理サーバ３０は、ステップＳ１０において、アクセストークン応答（Access token response）を署名提供サーバ２０に返す。
すなわち鍵管理サーバ３０は、セキュリティトークンとしてのアクセストークン（Access token）を署名提供サーバ２０に送信する（ＲＦＣ６７４９＃４．１．４．）。
図５は、図４に示したトークン発行処理後のリモート署名処理の流れを説明する図である。
端末装置１０からの要求に応じて、署名提供サーバ２０は、ステップＳ２１において、図４の処理で取得したアクセストークン（Access token）を用いて、リモート署名要求を鍵管理サーバ３０に送信する。
リモート署名要求送信を受信した鍵管理サーバ３０は、ステップＳ２２において、電子署名を生成し（ＨＳＭ１００に電子署名を生成させ）、ステップＳ２３において、生成された電子署名を署名提供サーバ２０に送信する。
端末装置１０からの要求に応じて、署名提供サーバ２０は、ステップＳ２１において、図４の処理で取得したアクセストークン（Access token）を用いて、リモート署名要求を鍵管理サーバ３０に送信する。
リモート署名要求送信を受信した鍵管理サーバ３０は、ステップＳ２２において、電子署名を生成し（ＨＳＭ１００に電子署名を生成させ）、ステップＳ２３において、生成された電子署名を署名提供サーバ２０に送信する。
上記したように、ＨＳＭ１００上の各パーティションに格納されている私有鍵（秘密鍵）は、活性化されることによって電子署名に用いることができる。
以下、本実施形態の特徴的な構成であるＨＳＭ１００が有する私有鍵（秘密鍵）を活性化するための処理手順について説明する。
図６は、ＨＳＭに格納されている私有鍵（秘密鍵）を活性化するための第１の構成を説明する図である。
ＨＳＭ１００が備える記憶領域１０１は、複数のパーティション（Partition）に分割されている。
各パーティションはユーザ毎に割り当てられており、鍵生成制御処理部６３が生成した私有鍵（秘密鍵）を夫々格納される。
各パーティションには、Ｐａｒｔ．１、Ｐａｒｔ．２、Ｐａｒｔ．３、Ｐａｒｔ．４・・・など夫々を特定するパーティションＩＤとしての名前（Partition Name）が付けられており、アクセス用のパーティションパスワード（Partition Password）が設定される。
以下、本実施形態の特徴的な構成であるＨＳＭ１００が有する私有鍵（秘密鍵）を活性化するための処理手順について説明する。
図６は、ＨＳＭに格納されている私有鍵（秘密鍵）を活性化するための第１の構成を説明する図である。
ＨＳＭ１００が備える記憶領域１０１は、複数のパーティション（Partition）に分割されている。
各パーティションはユーザ毎に割り当てられており、鍵生成制御処理部６３が生成した私有鍵（秘密鍵）を夫々格納される。
各パーティションには、Ｐａｒｔ．１、Ｐａｒｔ．２、Ｐａｒｔ．３、Ｐａｒｔ．４・・・など夫々を特定するパーティションＩＤとしての名前（Partition Name）が付けられており、アクセス用のパーティションパスワード（Partition Password）が設定される。
ＨＳＭ１００に接続された、あるいはＨＳＭ１００を内蔵した鍵管理サーバ３０は、例えば、記憶部３０Ｂに、活性化情報記憶部９１を備えている。
鍵活性化情報処理部６５は、ステップＳ４１において、鍵生成制御処理部６３より活性化情報を取得する。
そして、ステップＳ４２において、鍵活性化情報処理部６５は、利用者を特定するトークン情報（アクセストークン）に紐付けて鍵活性化情報を鍵活性化情報記憶部９１に格納する。
鍵活性化情報記憶部９１には、各パーティションに格納される私有鍵（秘密鍵）を活性化するための鍵活性化情報が格納されている。上記のように鍵活性化情報は、Ｐａｒｔｉｔｉｏｎ Ｎａｍｅ、Ｐａｒｔｉｔｉｏｎ Ｐａｓｓｗｏｒｄ、Ｋｅｙ Ａｌｉａｓ、ＰＩＮである。
鍵活性化情報処理部６５は、ステップＳ４１において、鍵生成制御処理部６３より活性化情報を取得する。
そして、ステップＳ４２において、鍵活性化情報処理部６５は、利用者を特定するトークン情報（アクセストークン）に紐付けて鍵活性化情報を鍵活性化情報記憶部９１に格納する。
鍵活性化情報記憶部９１には、各パーティションに格納される私有鍵（秘密鍵）を活性化するための鍵活性化情報が格納されている。上記のように鍵活性化情報は、Ｐａｒｔｉｔｉｏｎ Ｎａｍｅ、Ｐａｒｔｉｔｉｏｎ Ｐａｓｓｗｏｒｄ、Ｋｅｙ Ａｌｉａｓ、ＰＩＮである。
ステップ５１において、受付処理部６６が署名提供サーバ２０からの所定のトークン情報を付した署名要求または私有鍵（秘密鍵）の活性化要求を受け付けると、鍵活性化処理部６４は、トークン情報と鍵活性化情報記憶部９１内の鍵活性化情報を用いて、トークン情報に対応するパーティション内の私有鍵（秘密鍵）を活性化する。
すなわち、ステップＳ５２において、鍵活性化処理部６４は、トークン情報（アクセストークン）に対応した鍵活性化情報を鍵活性化情報記憶部９１から取得する。
そして、ステップＳ５３において、鍵活性化処理部６４は、取得した鍵活性化情報を用いてＨＳＭ１００上の秘密鍵を活性化する。
すなわち、ステップＳ５２において、鍵活性化処理部６４は、トークン情報（アクセストークン）に対応した鍵活性化情報を鍵活性化情報記憶部９１から取得する。
そして、ステップＳ５３において、鍵活性化処理部６４は、取得した鍵活性化情報を用いてＨＳＭ１００上の秘密鍵を活性化する。
取得された鍵活性化情報のうち、Ｐａｒｔｉｔｉｏｎ Ｎａｍｅによって活性化すべき秘密鍵があるパーティションが特定可能であり、Ｐａｒｔｉｔｉｏｎ Ｐａｓｓｗｏｒｄによって当該パーティションへのアクセスが可能となる。
そして、署名生成制御処理部６０は、ＨＳＭ１００を制御し、活性化された私有鍵（秘密鍵）を用いた電子署名の生成を行うのである。
そして、署名生成制御処理部６０は、ＨＳＭ１００を制御し、活性化された私有鍵（秘密鍵）を用いた電子署名の生成を行うのである。
上記のように構成することにより、署名提供サーバ２０から送られてくる秘密鍵の利用者を特定可能なトークン情報によって、それに対応する鍵活性化情報を取得して秘密鍵の活性化を行うことができるので、簡便かつ安全に私有鍵（秘密鍵）を活性化して高セキュリティなリモート署名を行うことができる。
図７は、本実施形態の第２の例に係る鍵管理サーバの構成を示す図であり、（ａ）は、ハードウェアによる機能構成を示す図、（ｂ）は、ソフトウェアによる機能構成を示す図である。
図７に示す鍵管理サーバは、図３で説明した鍵管理サーバと一部が異なる構成であり、図３と異なる部分のみを説明する。
図７（ａ）に示すハードウェア構成は、図３（ａ）と共通しているため説明を行わない。
図７（ｂ）に示す制御部３０Ａは、署名生成制御処理部６０、ＯＡｕｔｈ実行処理部６１、ユーザ認証処理部６２と、鍵生成制御処理部６３と、鍵活性化処理部６４と、受付処理部６６と、を備え、図３の鍵活性化情報処理部６５を備えず、スクランブル情報処理部６７を備える。
また、ＲＡＭ３２またはＨＤＤ３３から構成される記憶部３０Ｂには、鍵活性化情報記憶部９１を備えず、スクランブル情報記憶部９２、システム鍵記憶部９３を備えている。
スクランブル情報記憶部９２には、下記に詳しく説明するように、各パーティションに格納される私有鍵（秘密鍵）を活性化するための鍵活性化情報Ｘを算出するためのスクランブル情報Ｓが格納されている。
システム鍵記憶部９３には、各パーティションに格納される私有鍵（秘密鍵）を活性化するための鍵活性化情報Ｘを算出するためのシステム鍵Ｋが格納されている。
スクランブル情報、システム鍵は、後述の鍵活性化処理部６４によって用いられる。
図７に示す鍵管理サーバは、図３で説明した鍵管理サーバと一部が異なる構成であり、図３と異なる部分のみを説明する。
図７（ａ）に示すハードウェア構成は、図３（ａ）と共通しているため説明を行わない。
図７（ｂ）に示す制御部３０Ａは、署名生成制御処理部６０、ＯＡｕｔｈ実行処理部６１、ユーザ認証処理部６２と、鍵生成制御処理部６３と、鍵活性化処理部６４と、受付処理部６６と、を備え、図３の鍵活性化情報処理部６５を備えず、スクランブル情報処理部６７を備える。
また、ＲＡＭ３２またはＨＤＤ３３から構成される記憶部３０Ｂには、鍵活性化情報記憶部９１を備えず、スクランブル情報記憶部９２、システム鍵記憶部９３を備えている。
スクランブル情報記憶部９２には、下記に詳しく説明するように、各パーティションに格納される私有鍵（秘密鍵）を活性化するための鍵活性化情報Ｘを算出するためのスクランブル情報Ｓが格納されている。
システム鍵記憶部９３には、各パーティションに格納される私有鍵（秘密鍵）を活性化するための鍵活性化情報Ｘを算出するためのシステム鍵Ｋが格納されている。
スクランブル情報、システム鍵は、後述の鍵活性化処理部６４によって用いられる。
鍵活性化処理部６４は、署名提供サーバ２０により所定のトークン情報を付した署名要求が行われたとき、上記トークン情報（アクセストークン）と、鍵活性化情報記憶部９１内のスクランブル情報Ｓ、システム鍵記憶部９３内のシステム鍵Ｋを用いて、パーティション内の私有鍵（秘密鍵）を活性化するための鍵活性化情報Ｘを算出し、秘密鍵を活性化する。
そして、署名生成制御処理部６０は、ＨＳＭ１００を制御し、活性化された私有鍵（秘密鍵）を用いて電子署名の生成を行う。
換言すると、鍵活性化処理部６４は、署名生成制御処理部６０が署名提供サーバ２０よりの署名要求に応じた電子署名の生成を行うのに先立って、トークン情報Ｔ（アクセストークン）、スクランブル情報Ｓ、システム鍵Ｋ用いて鍵活性化情報Ｘを算出し、電子署名の生成に用いる私有鍵（秘密鍵）の活性化を行う。
そして、署名生成制御処理部６０は、ＨＳＭ１００を制御し、活性化された私有鍵（秘密鍵）を用いて電子署名の生成を行う。
換言すると、鍵活性化処理部６４は、署名生成制御処理部６０が署名提供サーバ２０よりの署名要求に応じた電子署名の生成を行うのに先立って、トークン情報Ｔ（アクセストークン）、スクランブル情報Ｓ、システム鍵Ｋ用いて鍵活性化情報Ｘを算出し、電子署名の生成に用いる私有鍵（秘密鍵）の活性化を行う。
スクランブル情報処理部６７は、鍵生成制御処理部６３が鍵生成処理を行ったときに用いたＫｅｙＡｌｉａｓ、ＰＩＮ、及び生成した鍵を格納したＨＳＭ１００内のパーティションのＰａｒｔｉｔｉｏｎ Ｎａｍｅ、Ｐａｒｔｉｔｉｏｎ Ｐａｓｓｗｏｒｄよりなる鍵活性化情報Ｘと、トークン情報Ｔ（アクセストークン）と、システム鍵記憶部９３に格納されているシステム鍵Ｋと、を用いて、スクランブル情報Ｓを生成し、スクランブル情報記憶部９２に格納する処理を行う。
スクランブル情報を生成する際に用いるトークン情報Ｔ（アクセストークン）は、上記のようにＯＡｕｔｈ実行処理部６１が署名提供サーバ２０に送信するアクセストークン（Access token）である。別の手段で新たに生成されたトークンであってもよい。
スクランブル情報を生成する際に用いるトークン情報Ｔ（アクセストークン）は、上記のようにＯＡｕｔｈ実行処理部６１が署名提供サーバ２０に送信するアクセストークン（Access token）である。別の手段で新たに生成されたトークンであってもよい。
図８は、ＨＳＭに格納された鍵を活性化するための第２の構成を説明する図である。
スクランブル情報処理部６７は、ステップＳ６１において、鍵生成制御処理部６３より鍵活性化情報Ｘを取得する。本例では、鍵活性化情報Ｘは、Ｐａｒｔｉｔｉｏｎ Ｎａｍｅ、Ｐａｒｔｉｔｉｏｎ Ｐａｓｓｗｏｒｄ、Ｋｅｙ Ａｌｉａｓ、ＰＩＮである。
ステップＳ６２において、スクランブル情報処理部６７は、Ｐａｒｔｉｔｉｏｎ Ｎａｍｅ、Ｐａｒｔｉｔｉｏｎ Ｐａｓｓｗｏｒｄ、Ｋｅｙ Ａｌｉａｓ、ＰＩＮからなる鍵活性化情報Ｘと、システム鍵Ｋと、トークン情報Ｔ（アクセストークン）を用い、スクランブル情報Ｓを算出する。あるいは、スクランブル情報Ｓを生成し、鍵活性化情報Ｘと、システム鍵Ｋとを用いて、トークン情報Ｔを算出する。
すなわち、本発明の第２の構成では、鍵活性化情報Ｘ、システム鍵Ｋ、トークン情報Ｔ、スクランブル情報Ｓの関係は、以下の式によって与えられる。
Ｘ＝ＦＫ（Ｔ，Ｓ）
スクランブル情報処理部６７は、ステップＳ６１において、鍵生成制御処理部６３より鍵活性化情報Ｘを取得する。本例では、鍵活性化情報Ｘは、Ｐａｒｔｉｔｉｏｎ Ｎａｍｅ、Ｐａｒｔｉｔｉｏｎ Ｐａｓｓｗｏｒｄ、Ｋｅｙ Ａｌｉａｓ、ＰＩＮである。
ステップＳ６２において、スクランブル情報処理部６７は、Ｐａｒｔｉｔｉｏｎ Ｎａｍｅ、Ｐａｒｔｉｔｉｏｎ Ｐａｓｓｗｏｒｄ、Ｋｅｙ Ａｌｉａｓ、ＰＩＮからなる鍵活性化情報Ｘと、システム鍵Ｋと、トークン情報Ｔ（アクセストークン）を用い、スクランブル情報Ｓを算出する。あるいは、スクランブル情報Ｓを生成し、鍵活性化情報Ｘと、システム鍵Ｋとを用いて、トークン情報Ｔを算出する。
すなわち、本発明の第２の構成では、鍵活性化情報Ｘ、システム鍵Ｋ、トークン情報Ｔ、スクランブル情報Ｓの関係は、以下の式によって与えられる。
Ｘ＝ＦＫ（Ｔ，Ｓ）
ここで、関数Ｆは、鍵活性化情報Ｘ、システム鍵Ｋが与えられたときにトークン情報Ｔ、スクランブル情報Ｓを容易に算出可能であって、さらに新たな鍵活性化情報Ｘ’が与えられたときに、Ｘ’＝ＦＫ（Ｔ，Ｓ’）を満たすＳ’を容易に算出できるものを用いる。
以下では、このような関数Ｆを具体的に実現する一例を示し、本発明においてどのように機能するかを説明する。
非常に簡単な一例では、上記の条件を満たす関数Ｆは、
Ｘ＝ＦＫ（Ｔ，Ｓ）＝Ｋ＋Ｔ＋Ｓ
とできる。ここで、「＋」はビット毎に排他的論理和をとる演算である。
よって、スクランブル情報処理部６７は、上式より、
Ｓ＝Ｘ＋Ｋ＋Ｔ
すなわち、鍵活性化情報Ｘとシステム鍵Ｋとトークン情報Ｔを互いにビット毎の排他的論理和演算を実施することによってスクランブル情報Ｓを生成することができる。
ステップＳ６３において、スクランブル情報処理部６７は、算出したスクランブル情報Ｓを鍵管理サーバ３０のスクランブル情報記憶部９２に格納する。
トークン情報Ｔは、前もって署名提供サーバ２０に付与されていてもよいし、生成したスクランブル情報Ｓから算出してもよい。上記のようにＯＡｕｔｈ実行処理部６１が署名提供サーバ２０に送信するアクセストークン（Access token）であってもよいし、別の手段で生成されるトークンであってもよい。
以下では、このような関数Ｆを具体的に実現する一例を示し、本発明においてどのように機能するかを説明する。
非常に簡単な一例では、上記の条件を満たす関数Ｆは、
Ｘ＝ＦＫ（Ｔ，Ｓ）＝Ｋ＋Ｔ＋Ｓ
とできる。ここで、「＋」はビット毎に排他的論理和をとる演算である。
よって、スクランブル情報処理部６７は、上式より、
Ｓ＝Ｘ＋Ｋ＋Ｔ
すなわち、鍵活性化情報Ｘとシステム鍵Ｋとトークン情報Ｔを互いにビット毎の排他的論理和演算を実施することによってスクランブル情報Ｓを生成することができる。
ステップＳ６３において、スクランブル情報処理部６７は、算出したスクランブル情報Ｓを鍵管理サーバ３０のスクランブル情報記憶部９２に格納する。
トークン情報Ｔは、前もって署名提供サーバ２０に付与されていてもよいし、生成したスクランブル情報Ｓから算出してもよい。上記のようにＯＡｕｔｈ実行処理部６１が署名提供サーバ２０に送信するアクセストークン（Access token）であってもよいし、別の手段で生成されるトークンであってもよい。
ステップＳ７１において、受付処理部６６が署名提供サーバ２０からの所定のトークン情報を付した署名要求または私有鍵（秘密鍵）の活性化要求を受け付けると、鍵活性化処理部６４は、トークン情報Ｔ（アクセストークン）と、システム鍵記憶部９３に記憶されるシステム鍵Ｋと、スクランブル情報記憶部９２内のスクランブル情報Ｓと、を用いて鍵活性化情報Ｘを算出し、対応するパーティション内の私有鍵（秘密鍵）を活性化する。
すなわち、ステップＳ７３において、鍵活性化処理部６４は、トークン情報（アクセストークン）に対応した鍵活性化情報Ｘを、システム鍵Ｋと、トークン情報Ｔと、スクランブル情報記憶部９２から取得したスクランブル情報Ｓとを用いて算出する。
そして、ステップＳ７４において、鍵活性化処理部６４は、算出した鍵活性化情報Ｘを用いてＨＳＭ１００上の秘密鍵を活性化する。
すなわち、ステップＳ７３において、鍵活性化処理部６４は、トークン情報（アクセストークン）に対応した鍵活性化情報Ｘを、システム鍵Ｋと、トークン情報Ｔと、スクランブル情報記憶部９２から取得したスクランブル情報Ｓとを用いて算出する。
そして、ステップＳ７４において、鍵活性化処理部６４は、算出した鍵活性化情報Ｘを用いてＨＳＭ１００上の秘密鍵を活性化する。
より具体的には、ステップＳ７３において、鍵活性化処理部６４は、スクランブル情報Ｓと、システム鍵Ｋと、トークン情報Ｔ（アクセストークン）を用いて、下式によって鍵活性化情報Ｘを算出する。
鍵活性化情報Ｘ＝スクランブル情報Ｓ＋システム鍵Ｋ＋トークン情報Ｔ
（但し、“＋”は、ＢｉｔｗｉｓｅＸＯＲ／ビット単位の排他的論理和演算）
ステップＳ７４において、鍵活性化処理部６４は、算出した鍵活性化情報Ｘによって、ＨＳＭ１００上の秘密鍵を活性化する。
鍵活性化情報のうち、Ｐａｒｔｉｔｉｏｎ Ｎａｍｅによって秘密鍵があるＨＳＭ１００上のパーティションが特定され、Ｐａｒｔｉｔｉｏｎ Ｐａｓｓｗｏｒｄによって当該パーティションへのアクセスが可能となる。
そして、鍵活性化処理部６４は、活性化した私有鍵（秘密鍵）を用いて電子署名の生成を行うのである。
鍵活性化情報Ｘ＝スクランブル情報Ｓ＋システム鍵Ｋ＋トークン情報Ｔ
（但し、“＋”は、ＢｉｔｗｉｓｅＸＯＲ／ビット単位の排他的論理和演算）
ステップＳ７４において、鍵活性化処理部６４は、算出した鍵活性化情報Ｘによって、ＨＳＭ１００上の秘密鍵を活性化する。
鍵活性化情報のうち、Ｐａｒｔｉｔｉｏｎ Ｎａｍｅによって秘密鍵があるＨＳＭ１００上のパーティションが特定され、Ｐａｒｔｉｔｉｏｎ Ｐａｓｓｗｏｒｄによって当該パーティションへのアクセスが可能となる。
そして、鍵活性化処理部６４は、活性化した私有鍵（秘密鍵）を用いて電子署名の生成を行うのである。
ところで、Partition Passwordが変更されるなどによって、対応する私有鍵（秘密鍵）鍵活性化情報の値が後から変更される場合がありうる。その場合、鍵活性化情報を含むスクランブル情報も変更が必要となる。以下、その仕組みを説明する。
変更前の鍵活性化情報をＸ０、変更後の鍵活性化情報をＸ１とする。また、変更前のスクランブル情報をＳ０、変更後のスクランブル情報をＳ１とする。
スクランブル情報処理部６７は、トークン情報Ｔ（アクセストークン）、変更後の鍵活性化情報Ｘ１、変更前の鍵活性化情報Ｘ０、元のスクランブル情報Ｓ０によって、新たなスクランブル情報Ｓ１を下式によって算出しなおし、スクランブル情報Ｓ０に替えてスクランブル情報記憶部９２に格納する。
新たなスクランブル情報Ｓ１＝新たな鍵活性化情報Ｘ１＋元の鍵活性化情報Ｘ０＋スクランブル情報Ｓ０
このように、新しいスクランブル情報を算出すると、利用者（署名提供サーバ２０）に交付したトークン情報Ｔ（アクセストークン）は、再発行または再交付する必要がない。
変更前の鍵活性化情報をＸ０、変更後の鍵活性化情報をＸ１とする。また、変更前のスクランブル情報をＳ０、変更後のスクランブル情報をＳ１とする。
スクランブル情報処理部６７は、トークン情報Ｔ（アクセストークン）、変更後の鍵活性化情報Ｘ１、変更前の鍵活性化情報Ｘ０、元のスクランブル情報Ｓ０によって、新たなスクランブル情報Ｓ１を下式によって算出しなおし、スクランブル情報Ｓ０に替えてスクランブル情報記憶部９２に格納する。
新たなスクランブル情報Ｓ１＝新たな鍵活性化情報Ｘ１＋元の鍵活性化情報Ｘ０＋スクランブル情報Ｓ０
このように、新しいスクランブル情報を算出すると、利用者（署名提供サーバ２０）に交付したトークン情報Ｔ（アクセストークン）は、再発行または再交付する必要がない。
鍵活性化情報の変更後、署名提供サーバ２０によりトークン情報Ｔ（アクセストークン）を提示した署名要求が行われたときには、鍵活性化処理部６４は、トークン情報Ｔ、スクランブル情報Ｓ１、システム鍵Ｋを用いて鍵活性化情報Ｘ１を算出し、それを用いて秘密鍵を活性化することができる。
すなわち、鍵活性化情報Ｘが変更されても、引き続き同一のトークン情報Ｔを用いて秘密鍵を活性化することができる。
すなわち、鍵活性化情報Ｘが変更されても、引き続き同一のトークン情報Ｔを用いて秘密鍵を活性化することができる。
上記のように構成することにより、署名提供サーバ２０から送られてくる秘密鍵の利用者を特定可能なトークン情報によって、それに対応する鍵活性化情報を算出して秘密鍵の活性化を行うことができるので、簡便かつ安全に秘密鍵を活性化して高セキュリティなリモート署名を行うことができる。
さらに、鍵活性化情報をスクランブル化した情報だけを、鍵管理サーバ３０に格納するため、生の鍵活性化情報を直接格納する第１の構成と比較してもセキュリティ上の大きな利点がある。
且つ、鍵ペアの生成後に鍵活性化情報が変更されたとしても従来のトークン情報を引き続き利用できることにはユーザビリティ上の利点がある。
さらに、鍵活性化情報をスクランブル化した情報だけを、鍵管理サーバ３０に格納するため、生の鍵活性化情報を直接格納する第１の構成と比較してもセキュリティ上の大きな利点がある。
且つ、鍵ペアの生成後に鍵活性化情報が変更されたとしても従来のトークン情報を引き続き利用できることにはユーザビリティ上の利点がある。
なお、上記の２つの例では、鍵管理サーバ３０が、署名提供サーバ２０から取得したトークン情報Ｔを用いて、鍵活性化情報Ｘを取得し、あるいはスクランブル情報Ｓから鍵活性化情報Ｘを算出してＨＳＭ１００内の秘密鍵を活性化していた。
それとは異なり、ＨＳＭ１００が内部的に鍵活性化情報を取得、あるいは算出し、秘密鍵を活性化するようにしてもよい。
図９は、内部的処理で秘密鍵を活性化する場合のＨＳＭの機能構成を示す図である。
第１の例に関連して、鍵管理サーバ３０が保持していた鍵活性化情報としてのＰａｒｔｉｔｉｏｎ Ｎａｍｅ、Ｐａｒｔｉｔｉｏｎ Ｐａｓｓｗｏｒｄ、Ｋｅｙ Ａｌｉａｓ、ＰＩＮをＨＳＭ１００が保持する。
すなわち、図９（ａ）に示す様に、ＨＳＭ１００は、秘密鍵を格納する秘密鍵格納領域（各パーティション）を有する記憶領域１０１とは別に、あるいは記憶領域１０１内に、鍵活性化情報記憶部９１を有する。
またＨＳＭ１００は、署名処理部１０２、鍵生成処理部１０３に加えて、鍵活性化情報処理部６５、鍵活性化処理部６４を備える。
鍵活性化情報処理部６５は、鍵生成制御処理部６３から取得した鍵活性化情報を、トークン情報と関連付けて鍵活性化情報記憶部９１に格納する。
ＨＳＭ１００の鍵活性化処理部６４は、鍵管理サーバ３０の鍵活性化処理部６４からトークン情報を受け取ると、鍵活性化情報記憶部９１内のトークン情報Ｔに対応する鍵活性化情報を特定する。鍵活性化処理部６４は、特定した鍵活性化情報内のＰａｒｔｉｔｉｏｎ Ｎａｍｅによってパーティションを特定し、Ｐａｒｔｉｔｉｏｎ Ｐａｓｓｗｏｒｄを用いてパーティションにアクセスし、Ｋｅｙ Ａｌｉａｓ、ＰＩＮによって秘密鍵を活性化する。
図９は、内部的処理で秘密鍵を活性化する場合のＨＳＭの機能構成を示す図である。
第１の例に関連して、鍵管理サーバ３０が保持していた鍵活性化情報としてのＰａｒｔｉｔｉｏｎ Ｎａｍｅ、Ｐａｒｔｉｔｉｏｎ Ｐａｓｓｗｏｒｄ、Ｋｅｙ Ａｌｉａｓ、ＰＩＮをＨＳＭ１００が保持する。
すなわち、図９（ａ）に示す様に、ＨＳＭ１００は、秘密鍵を格納する秘密鍵格納領域（各パーティション）を有する記憶領域１０１とは別に、あるいは記憶領域１０１内に、鍵活性化情報記憶部９１を有する。
またＨＳＭ１００は、署名処理部１０２、鍵生成処理部１０３に加えて、鍵活性化情報処理部６５、鍵活性化処理部６４を備える。
鍵活性化情報処理部６５は、鍵生成制御処理部６３から取得した鍵活性化情報を、トークン情報と関連付けて鍵活性化情報記憶部９１に格納する。
ＨＳＭ１００の鍵活性化処理部６４は、鍵管理サーバ３０の鍵活性化処理部６４からトークン情報を受け取ると、鍵活性化情報記憶部９１内のトークン情報Ｔに対応する鍵活性化情報を特定する。鍵活性化処理部６４は、特定した鍵活性化情報内のＰａｒｔｉｔｉｏｎ Ｎａｍｅによってパーティションを特定し、Ｐａｒｔｉｔｉｏｎ Ｐａｓｓｗｏｒｄを用いてパーティションにアクセスし、Ｋｅｙ Ａｌｉａｓ、ＰＩＮによって秘密鍵を活性化する。
第２の例に関連して、鍵管理サーバ３０が保持していたスクランブル情報をＨＳＭ１００が保持する。
すなわち、図９（ｂ）に示すように、ＨＳＭ１００は、秘密鍵を格納する秘密鍵格納領域（各パーティション）を有する記憶領域１０１とは別に、あるいは記憶領域１０１内に、スクランブル情報記憶部９２と、システム鍵を記憶するシステム鍵記憶部９３と、を有する。
またＨＳＭ１００は、署名処理部１０２、鍵生成処理部１０３に加えて、スクランブル情報処理部６７、鍵活性化情報処理部６５と、を備える。
例えば、スクランブル情報処理部６７は、鍵管理サーバ３０の鍵生成制御処理部６３から取得した鍵活性化情報Ｘとシステム鍵記憶部９３に格納されるシステム鍵Ｋとを用いてスクランブル情報を生成して、スクランブル情報記憶部９２に格納する。
その後、鍵活性化情報処理部６５は、鍵管理サーバ３０の鍵活性化処理部６４からトークン情報Ｔを受け取ると、受け取ったトークン情報Ｔ、システム鍵Ｋ、スクランブル情報Ｓを用いて鍵活性化情報Ｘを算出し、対応するパーティション内の秘密鍵を活性化する。
ＨＳＭ１００がスクランブル情報処理部６７を有さず、鍵管理サーバ３０で生成したスクランブル情報を、スクランブル情報記憶部９２に格納してもよい。
また、第２の例において、鍵活性化情報Ｘを算出する関数Ｆについて、スクランブル情報Ｓとシステム鍵ＫとセキュリティトークンＴのビット毎の排他的論理和のみで算出できる例を示したが、これに限定されることなく、Ｘ＝ＦＫ（Ｔ，Ｓ）とあらわすことができ、鍵活性化情報Ｘ、システム鍵Ｋが与えられたときにトークン情報Ｔ、スクランブル情報Ｓを容易に算出可能であって、さらに新たな鍵活性化情報Ｘ’が与えられたときに、Ｘ’＝ＦＫ（Ｔ，Ｓ’）を満たすＳ’を容易に算出できるものであればどのようなものであってもよい。
すなわち、図９（ｂ）に示すように、ＨＳＭ１００は、秘密鍵を格納する秘密鍵格納領域（各パーティション）を有する記憶領域１０１とは別に、あるいは記憶領域１０１内に、スクランブル情報記憶部９２と、システム鍵を記憶するシステム鍵記憶部９３と、を有する。
またＨＳＭ１００は、署名処理部１０２、鍵生成処理部１０３に加えて、スクランブル情報処理部６７、鍵活性化情報処理部６５と、を備える。
例えば、スクランブル情報処理部６７は、鍵管理サーバ３０の鍵生成制御処理部６３から取得した鍵活性化情報Ｘとシステム鍵記憶部９３に格納されるシステム鍵Ｋとを用いてスクランブル情報を生成して、スクランブル情報記憶部９２に格納する。
その後、鍵活性化情報処理部６５は、鍵管理サーバ３０の鍵活性化処理部６４からトークン情報Ｔを受け取ると、受け取ったトークン情報Ｔ、システム鍵Ｋ、スクランブル情報Ｓを用いて鍵活性化情報Ｘを算出し、対応するパーティション内の秘密鍵を活性化する。
ＨＳＭ１００がスクランブル情報処理部６７を有さず、鍵管理サーバ３０で生成したスクランブル情報を、スクランブル情報記憶部９２に格納してもよい。
また、第２の例において、鍵活性化情報Ｘを算出する関数Ｆについて、スクランブル情報Ｓとシステム鍵ＫとセキュリティトークンＴのビット毎の排他的論理和のみで算出できる例を示したが、これに限定されることなく、Ｘ＝ＦＫ（Ｔ，Ｓ）とあらわすことができ、鍵活性化情報Ｘ、システム鍵Ｋが与えられたときにトークン情報Ｔ、スクランブル情報Ｓを容易に算出可能であって、さらに新たな鍵活性化情報Ｘ’が与えられたときに、Ｘ’＝ＦＫ（Ｔ，Ｓ’）を満たすＳ’を容易に算出できるものであればどのようなものであってもよい。
以上のように構成することで、ＨＳＭ１００内で処理が完結するため、鍵活性化情報が外に出ることなく、非常にセキュアに秘密鍵を活性化してリモート署名を行うことができる。
［第１の態様］
第１の態様は、秘密鍵を記憶する鍵記憶部１０１と、秘密鍵を用いて電子署名を生成する署名処理部１０２と、外部装置が提示したトークン情報を受け付ける受付処理部６６と、署名処理部１０２による電子署名の生成前に、受付処理部６６が受け付けたトークン情報に対応する活性化情報を用いて、その活性化情報に対応する秘密鍵を活性化する鍵活性化処理部６４と、を備えた鍵管理システム３である。
第１の態様によれば、署名提供サーバ２０から送られてくる秘密鍵の利用者を特定可能なトークン情報に応じた活性化情報によって秘密鍵の活性化を行うことができるので、簡便かつ安全に秘密鍵を活性化して高セキュリティなリモート署名を行うことができる。
第１の態様は、秘密鍵を記憶する鍵記憶部１０１と、秘密鍵を用いて電子署名を生成する署名処理部１０２と、外部装置が提示したトークン情報を受け付ける受付処理部６６と、署名処理部１０２による電子署名の生成前に、受付処理部６６が受け付けたトークン情報に対応する活性化情報を用いて、その活性化情報に対応する秘密鍵を活性化する鍵活性化処理部６４と、を備えた鍵管理システム３である。
第１の態様によれば、署名提供サーバ２０から送られてくる秘密鍵の利用者を特定可能なトークン情報に応じた活性化情報によって秘密鍵の活性化を行うことができるので、簡便かつ安全に秘密鍵を活性化して高セキュリティなリモート署名を行うことができる。
［第２の態様］
第２の態様は、第１の態様において、活性化情報をトークン情報に関連づけて記憶する活性化情報記憶部９１を備え、鍵活性化処理部６４は、受付処理部６６が受け付けたトークン情報に対応する活性化情報を活性化情報記憶部９１から選択し、該選択した活性化情報に基づいて、当該活性化情報に対応する秘密鍵を活性化する鍵管理システム３である。
第２の態様によれば、署名提供サーバ２０から送られてくる秘密鍵の利用者を特定可能なトークン情報によって、それに対応する活性化情報を取得して秘密鍵の活性化を行うことができるので、簡便かつ安全に秘密鍵を活性化して高セキュリティなリモート署名を行うことができる。
第２の態様は、第１の態様において、活性化情報をトークン情報に関連づけて記憶する活性化情報記憶部９１を備え、鍵活性化処理部６４は、受付処理部６６が受け付けたトークン情報に対応する活性化情報を活性化情報記憶部９１から選択し、該選択した活性化情報に基づいて、当該活性化情報に対応する秘密鍵を活性化する鍵管理システム３である。
第２の態様によれば、署名提供サーバ２０から送られてくる秘密鍵の利用者を特定可能なトークン情報によって、それに対応する活性化情報を取得して秘密鍵の活性化を行うことができるので、簡便かつ安全に秘密鍵を活性化して高セキュリティなリモート署名を行うことができる。
［第３の態様］
第３の態様は、第２の態様において、署名装置１００と、署名装置１００を制御して電子署名を生成させる鍵管理サーバ３０と、を備え、署名装置１００は、鍵記憶部１０１と、署名処理部１０２と、活性化情報記憶部９１と、鍵活性化処理部６４と、を備え、鍵管理サーバ３０は、受付処理部６６を備え、署名装置１００は、鍵管理サーバ３０が受け付けたトークン情報に対応する活性化情報を用いて、当該活性化情報に対応する秘密鍵を活性化する鍵管理システム３である。
第３の態様によれば、署名提供サーバ２０から送られてくる秘密鍵の利用者を特定可能なトークン情報によって、それに対応する活性化情報を取得して秘密鍵の活性化を行うことができるので、簡便かつ安全に秘密鍵を活性化して高セキュリティなリモート署名を行うことができる。
さらに、活性化情報を署名装置１００内に格納して、安全に秘密鍵の活性化を行うことができる。
第３の態様は、第２の態様において、署名装置１００と、署名装置１００を制御して電子署名を生成させる鍵管理サーバ３０と、を備え、署名装置１００は、鍵記憶部１０１と、署名処理部１０２と、活性化情報記憶部９１と、鍵活性化処理部６４と、を備え、鍵管理サーバ３０は、受付処理部６６を備え、署名装置１００は、鍵管理サーバ３０が受け付けたトークン情報に対応する活性化情報を用いて、当該活性化情報に対応する秘密鍵を活性化する鍵管理システム３である。
第３の態様によれば、署名提供サーバ２０から送られてくる秘密鍵の利用者を特定可能なトークン情報によって、それに対応する活性化情報を取得して秘密鍵の活性化を行うことができるので、簡便かつ安全に秘密鍵を活性化して高セキュリティなリモート署名を行うことができる。
さらに、活性化情報を署名装置１００内に格納して、安全に秘密鍵の活性化を行うことができる。
［第４の態様］
第４の態様は、第１の態様において、活性化情報と、トークン情報と、に基づいて算出されたスクランブル情報をトークン情報に関連付けて記憶するスクランブル情報記憶部９２と、を備え、鍵活性化処理部６４は、受付処理部６６が受け付けたトークン情報と、スクランブル情報と、に基づいて活性化情報を算出し、算出した活性化情報に基づいて、その活性化情報に対応する秘密鍵を活性化する鍵管理システム３である。
第４の態様によれば、署名提供サーバ２０から送られてくる秘密鍵の利用者を特定可能なトークン情報を用いて算出した活性化情報によって秘密鍵の活性化するので、生の活性化情報を保持する必要がなく、より安全に秘密鍵を活性化して高セキュリティなリモート署名を行うことができる。
第４の態様は、第１の態様において、活性化情報と、トークン情報と、に基づいて算出されたスクランブル情報をトークン情報に関連付けて記憶するスクランブル情報記憶部９２と、を備え、鍵活性化処理部６４は、受付処理部６６が受け付けたトークン情報と、スクランブル情報と、に基づいて活性化情報を算出し、算出した活性化情報に基づいて、その活性化情報に対応する秘密鍵を活性化する鍵管理システム３である。
第４の態様によれば、署名提供サーバ２０から送られてくる秘密鍵の利用者を特定可能なトークン情報を用いて算出した活性化情報によって秘密鍵の活性化するので、生の活性化情報を保持する必要がなく、より安全に秘密鍵を活性化して高セキュリティなリモート署名を行うことができる。
［第５の態様］
第５の態様は、第４の態様において、署名装置１００と、署名装置１００を制御して電子署名を生成させる鍵管理サーバ３０と、を備え、署名装置１００は、鍵記憶部１０１と、署名処理部１０２と、スクランブル情報記憶部９２と、鍵活性化処理部６４と、を備え、鍵管理サーバ３０は、受付処理部６６を備え、署名装置１００は、鍵管理サーバ３０が受け付けたトークン情報と、スクランブル情報と、に基づいて活性化情報を算出し、該算出した活性化情報に基づいて、当該活性化情報に対応する秘密鍵を活性化する鍵管理システム３である。
第４の態様によれば、署名提供サーバ２０から送られてくる秘密鍵の利用者を特定可能なトークン情報を用いて算出した活性化情報によって秘密鍵の活性化するので、生の活性化情報を保持する必要がなく、より安全に秘密鍵を活性化して高セキュリティなリモート署名を行うことができる。
さらに、活性化情報の算出を署名装置内で行うため、活性化情報が流出する懸念がなく、より安全に秘密鍵を活性化することができる。
第５の態様は、第４の態様において、署名装置１００と、署名装置１００を制御して電子署名を生成させる鍵管理サーバ３０と、を備え、署名装置１００は、鍵記憶部１０１と、署名処理部１０２と、スクランブル情報記憶部９２と、鍵活性化処理部６４と、を備え、鍵管理サーバ３０は、受付処理部６６を備え、署名装置１００は、鍵管理サーバ３０が受け付けたトークン情報と、スクランブル情報と、に基づいて活性化情報を算出し、該算出した活性化情報に基づいて、当該活性化情報に対応する秘密鍵を活性化する鍵管理システム３である。
第４の態様によれば、署名提供サーバ２０から送られてくる秘密鍵の利用者を特定可能なトークン情報を用いて算出した活性化情報によって秘密鍵の活性化するので、生の活性化情報を保持する必要がなく、より安全に秘密鍵を活性化して高セキュリティなリモート署名を行うことができる。
さらに、活性化情報の算出を署名装置内で行うため、活性化情報が流出する懸念がなく、より安全に秘密鍵を活性化することができる。
［第６の態様］
第６の態様は、秘密鍵を記憶する鍵記憶部１０１と、秘密鍵を用いて電子署名を生成する署名処理部１０２と、外部装置が提示したトークン情報に対応する活性化情報を用いて、当該活性化情報に対応する秘密鍵を活性化する鍵活性化処理部６４と、を備えた署名装置１００である。
第６の態様によれば、署名提供サーバ２０から送られてくる秘密鍵の利用者を特定可能なトークン情報に応じた活性化情報によって秘密鍵の活性化を行うことができるので、簡便かつ安全に秘密鍵を活性化して高セキュリティなリモート署名を行うことができる。
第６の態様は、秘密鍵を記憶する鍵記憶部１０１と、秘密鍵を用いて電子署名を生成する署名処理部１０２と、外部装置が提示したトークン情報に対応する活性化情報を用いて、当該活性化情報に対応する秘密鍵を活性化する鍵活性化処理部６４と、を備えた署名装置１００である。
第６の態様によれば、署名提供サーバ２０から送られてくる秘密鍵の利用者を特定可能なトークン情報に応じた活性化情報によって秘密鍵の活性化を行うことができるので、簡便かつ安全に秘密鍵を活性化して高セキュリティなリモート署名を行うことができる。
［第７の態様］
第７の態様は、第６の態様において、活性化情報を記憶する活性化情報記憶部９１を備え、鍵活性化処理部６４は、外部装置から提示されたトークン情報に対応する活性化情報を用いて、当該活性化情報に対応する秘密鍵を活性化する署名装置１００である。
第６の態様によれば、署名提供サーバ２０から送られてくる秘密鍵の利用者を特定可能なトークン情報によって、それに対応する活性化情報を取得して秘密鍵の活性化を行うことができるので、簡便かつ安全に秘密鍵を活性化して高セキュリティなリモート署名を行うことができる。
第７の態様は、第６の態様において、活性化情報を記憶する活性化情報記憶部９１を備え、鍵活性化処理部６４は、外部装置から提示されたトークン情報に対応する活性化情報を用いて、当該活性化情報に対応する秘密鍵を活性化する署名装置１００である。
第６の態様によれば、署名提供サーバ２０から送られてくる秘密鍵の利用者を特定可能なトークン情報によって、それに対応する活性化情報を取得して秘密鍵の活性化を行うことができるので、簡便かつ安全に秘密鍵を活性化して高セキュリティなリモート署名を行うことができる。
［第８の態様］
第８の態様は、第６の態様において、活性化情報と、トークン情報と、に基づいて算出されたスクランブル情報をトークン情報に関連付けて記憶するスクランブル情報記憶部９２を備え、鍵活性化処理部６４は、外部装置が提示したトークン情報と、当該トークン情報に対応するスクランブル情報と、に基づいて活性化情報を算出し、該算出した活性化情報に基づいて、当該活性化情報に対応する秘密鍵を活性化する署名装置１００である。
第６の態様によれば、署名提供サーバ２０から送られてくる秘密鍵の利用者を特定可能なトークン情報を用いて算出した活性化情報によって秘密鍵の活性化するので、生の活性化情報を保持する必要がなく、より安全に秘密鍵を活性化して高セキュリティなリモート署名を行うことができる。
第８の態様は、第６の態様において、活性化情報と、トークン情報と、に基づいて算出されたスクランブル情報をトークン情報に関連付けて記憶するスクランブル情報記憶部９２を備え、鍵活性化処理部６４は、外部装置が提示したトークン情報と、当該トークン情報に対応するスクランブル情報と、に基づいて活性化情報を算出し、該算出した活性化情報に基づいて、当該活性化情報に対応する秘密鍵を活性化する署名装置１００である。
第６の態様によれば、署名提供サーバ２０から送られてくる秘密鍵の利用者を特定可能なトークン情報を用いて算出した活性化情報によって秘密鍵の活性化するので、生の活性化情報を保持する必要がなく、より安全に秘密鍵を活性化して高セキュリティなリモート署名を行うことができる。
１ リモート署名システム、２ 署名提供システム、３ 鍵管理システム、１０ 端末装置、２０ 署名提供サーバ、２１ ＣＰＵ、２３ ＨＤＤ、２４ ネットワークＩ／Ｆ、３０ 鍵管理サーバ、３１ ＣＰＵ、３２ ＲＡＭ、３３ ＨＤＤ、３４ ネットワークＩ／Ｆ、５１ ウェブページ処理部、５２ ＯＡｕｔｈ実行処理部、５３ 署名要求処理部、５５ ＨＴＭＬページ記憶部、６０ 署名生成制御処理部、６１ ＯＡｕｔｈ実行処理部、６２ ユーザ認証処理部、６３ 鍵生成制御処理部、６４ 鍵活性化処理部、６５ 鍵活性化情報処理部、６６ 受付処理部、６７ スクランブル情報処理部、９１ 鍵活性化情報記憶部、９２ スクランブル情報記憶部、９３ システム鍵記憶部、１００ ＨＳＭ、１０１ 記憶領域、１０２ 署名処理部、１０３ 鍵生成処理部
Claims (10)
- 秘密鍵を記憶する鍵記憶部と、
前記秘密鍵を用いて電子署名を生成する署名処理部と、
外部装置が提示したトークン情報を受け付ける受付処理部と、
前記署名処理部による電子署名の生成前に、前記受付処理部が受け付けた前記トークン情報に対応する活性化情報を用いて、当該活性化情報に対応する秘密鍵を活性化する鍵活性化処理部と、
を備えたことを特徴とする鍵管理システム。 - 請求項１に記載の鍵管理システムにおいて、
前記活性化情報を前記トークン情報に関連づけて記憶する活性化情報記憶部を備え、
前記鍵活性化処理部は、
前記受付処理部が受け付けた前記トークン情報に対応する活性化情報を前記活性化情報記憶部から選択し、該選択した活性化情報に基づいて、当該活性化情報に対応する秘密鍵を活性化することを特徴とする鍵管理システム。 - 請求項２に記載の鍵管理システムにおいて、
署名装置と、該署名装置を制御して前記電子署名を生成させる鍵管理サーバと、を備え、
前記署名装置は、前記鍵記憶部と、前記署名処理部と、前記活性化情報記憶部と、前記鍵活性化処理部と、を備え、
前記鍵管理サーバは、前記受付処理部を備え、
前記署名装置は、
前記鍵管理サーバが受け付けた前記トークン情報に対応する活性化情報を用いて、当該活性化情報に対応する秘密鍵を活性化することを特徴とする鍵管理システム。 - 請求項１に記載の鍵管理システムにおいて、
前記活性化情報と前記トークン情報とに基づいて算出されたスクランブル情報を前記トークン情報に関連付けて記憶するスクランブル情報記憶部を備え、
前記鍵活性化処理部は、
前記受付処理部が受け付けた前記トークン情報と、当該トークン情報に対応する前記スクランブル情報と、に基づいて前記活性化情報を算出し、該算出した活性化情報に基づいて、当該活性化情報に対応する秘密鍵を活性化することを特徴とする鍵管理システム。 - 請求項４に記載の鍵管理システムにおいて、
署名装置と、該署名装置を制御して前記電子署名を生成させる鍵管理サーバと、を備え、
前記署名装置は、前記鍵記憶部と、前記署名処理部と、前記スクランブル情報記憶部と、前記鍵活性化処理部と、を備え、
前記鍵管理サーバは、前記受付処理部を備え、
前記署名装置は、前記鍵管理サーバが受け付けた前記トークン情報と、当該トークン情報に対応する前記スクランブル情報と、に基づいて前記活性化情報を算出し、該算出した活性化情報に基づいて、当該活性化情報に対応する秘密鍵を活性化することを特徴とする鍵管理システム。 - 秘密鍵を記憶する鍵記憶部と、
前記秘密鍵を用いて電子署名を生成する署名処理部と、
外部装置が提示したトークン情報に対応する活性化情報を用いて、当該活性化情報に対応する秘密鍵を活性化する鍵活性化処理部と、
を備えたことを特徴とする署名装置。 - 請求項６に記載の署名装置において、
前記活性化情報を記憶する前記活性化情報記憶部と、を備え、
前記鍵活性化処理部は、外部装置から提示された前記トークン情報に対応する活性化情報を用いて、当該活性化情報に対応する秘密鍵を活性化することを特徴とする署名装置。 - 請求項６に記載の署名装置において、
前記活性化情報と、前記トークン情報と、に基づいて算出されたスクランブル情報を前記トークン情報に関連付けて記憶するスクランブル情報記憶部を備え、
前記鍵活性化処理部は、外部装置が提示した前記トークン情報と、当該トークン情報に対応する前記スクランブル情報と、に基づいて前記活性化情報を算出し、該算出した活性化情報に基づいて、当該活性化情報に対応する秘密鍵を活性化することを特徴とする署名装置。 - 秘密鍵を記憶する鍵記憶部と、前記秘密鍵を用いて電子署名を生成する署名処理部と、受付処理部と、鍵活性化処理部と、を備えた鍵管理システムの鍵管理方法であって、
前記受付処理部が、外部装置が提示したトークン情報を受け付けるステップと、
前記鍵活性化処理部が、前記受付処理部が受け付けた前記トークン情報に対応する活性化情報を用いて、当該活性化情報に対応する秘密鍵を活性化するステップと、
を備えたことを特徴とする鍵管理方法。 - 請求項９に記載の鍵管理方法をコンピュータに実行させるプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2019161938A JP2021040278A (ja) | 2019-09-05 | 2019-09-05 | 鍵管理システム、署名装置、鍵管理方法及びプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2019161938A JP2021040278A (ja) | 2019-09-05 | 2019-09-05 | 鍵管理システム、署名装置、鍵管理方法及びプログラム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2021040278A true JP2021040278A (ja) | 2021-03-11 |
Family
ID=74847531
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2019161938A Pending JP2021040278A (ja) | 2019-09-05 | 2019-09-05 | 鍵管理システム、署名装置、鍵管理方法及びプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2021040278A (ja) |
-
2019
- 2019-09-05 JP JP2019161938A patent/JP2021040278A/ja active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109088889B (zh) | 一种ssl加解密方法、系统及计算机可读存储介质 | |
| US9467430B2 (en) | Device, method, and system for secure trust anchor provisioning and protection using tamper-resistant hardware | |
| US10567370B2 (en) | Certificate authority | |
| US8532620B2 (en) | Trusted mobile device based security | |
| TWI715537B (zh) | 基於雲環境的加密機金鑰注入系統、方法及裝置 | |
| US8719952B1 (en) | Systems and methods using passwords for secure storage of private keys on mobile devices | |
| RU2297037C2 (ru) | Управление защищенной линией связи в динамических сетях | |
| US9137017B2 (en) | Key recovery mechanism | |
| CN109639427B (zh) | 一种数据发送的方法及设备 | |
| US20100042848A1 (en) | Personalized I/O Device as Trusted Data Source | |
| CN106713279B (zh) | 一种视频终端身份认证系统 | |
| US20030145237A1 (en) | Multiple secure socket layer keyfiles for client login support | |
| JP6571890B1 (ja) | 電子署名システム、証明書発行システム、証明書発行方法及びプログラム | |
| JP5992535B2 (ja) | 無線ｉｄプロビジョニングを実行するための装置及び方法 | |
| ES2665887T3 (es) | Sistema de datos seguro | |
| US20210392004A1 (en) | Apparatus and method for authenticating device based on certificate using physical unclonable function | |
| JP4332071B2 (ja) | クライアント端末、ゲートウエイ装置、及びこれらを備えたネットワークシステム | |
| JP6465426B1 (ja) | 電子署名システム、証明書発行システム、鍵管理システム及び電子証明書発行方法 | |
| JP2001134534A (ja) | 認証代行方法、認証代行サービスシステム、認証代行サーバ装置及びクライアント装置 | |
| TW202118271A (zh) | 使用參與實體之網絡識別符促進與區塊鏈關聯之交易的電腦實施系統及方法 | |
| Alsaid et al. | Preventing phishing attacks using trusted computing technology | |
| JP4499575B2 (ja) | ネットワークセキュリティ方法およびネットワークセキュリティシステム | |
| JP2005175992A (ja) | 証明書配布システムおよび証明書配布方法 | |
| JP2010028689A (ja) | 公開パラメータ提供サーバ、公開パラメータ提供方法、公開パラメータ提供プログラム、暗号化処理実行装置、暗号化処理実行方法、暗号化処理実行プログラム、署名処理実行装置、署名処理実行方法及び署名処理実行プログラム | |
| TWI698113B (zh) | 電子裝置之認證方法及系統 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20190917 |