[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

JP4629602B2 - 公開鍵暗号通信システム、公開鍵暗号通信方法、クライアント端末およびクライアントプログラム - Google Patents

公開鍵暗号通信システム、公開鍵暗号通信方法、クライアント端末およびクライアントプログラム Download PDF

Info

Publication number
JP4629602B2
JP4629602B2 JP2006083466A JP2006083466A JP4629602B2 JP 4629602 B2 JP4629602 B2 JP 4629602B2 JP 2006083466 A JP2006083466 A JP 2006083466A JP 2006083466 A JP2006083466 A JP 2006083466A JP 4629602 B2 JP4629602 B2 JP 4629602B2
Authority
JP
Japan
Prior art keywords
public key
key
data
secret
receiving
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2006083466A
Other languages
English (en)
Other versions
JP2007259279A (ja
Inventor
和幸 高屋
則宏 三浦
重彦 牛島
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to JP2006083466A priority Critical patent/JP4629602B2/ja
Publication of JP2007259279A publication Critical patent/JP2007259279A/ja
Application granted granted Critical
Publication of JP4629602B2 publication Critical patent/JP4629602B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Description

この発明は、公開鍵暗号通信システム、公開鍵暗号通信方法および公開鍵暗号通信プログラムに関する。
従来より、メール送受信や電子申請など、秘匿性が要求されるネットワークサービスにおいて、公開鍵暗号方式を用いた情報通信が行われている。ここで、公開鍵暗号方式とは、公開鍵および秘密鍵と呼ばれるペアとなる鍵(データ)を用いて、秘匿性が要求されるデータを暗号化または復号する方式である。通常、まず、公開鍵暗号通信を行いたい者(以下、ユーザという)によって公開鍵および秘密鍵の鍵ペアが生成される。そして、公開鍵は、通信相手に利用させることを目的としてネットワーク上で公開(または送信)され、この公開鍵を入手した通信相手によって公開鍵が利用されてデータが暗号化される。一方、秘密鍵は、ユーザによって管理され、公開鍵が利用されて暗号化されたデータを復号するために用いられる。ここで、公開鍵が利用されて暗号化されたデータは、公開鍵とペアで生成された秘密鍵でなければ復号できない点が特色である。
このようなことから、公開鍵暗号通信において重要なことは、秘密鍵が漏洩または紛失されないように、ユーザによっていかに安全に管理されるかという点にある。ところが一方で、スパイウェアによる盗聴、廃棄した記憶媒体からの漏洩、管理パスワードの忘失など、秘密鍵が漏洩または紛失されるリスクは高い。そこで、このようなリスクを回避するために、ユーザによって公開鍵および秘密鍵の鍵ペアが随時更新されることが一般的に行われている。例えば、非特許文献1では、公開鍵および秘密鍵の鍵ペアが、設定された有効期限が切れる前に自動的に更新される方法を推奨している。
エントラストジャパン社"企業のためのPKI導入ガイド"、[online]、[平成18年3月14日検索]、インターネット<http://japan.entrust.com/resources/impact02.html>
ところで、上記した従来の技術では、公開鍵および秘密鍵の鍵ペアが随時更新される場合に、必ずしも公開鍵暗号通信を実現することができないという課題があり、また、秘密鍵の管理が簡易かつ安全でないという課題がある。
すなわち、公開鍵および秘密鍵の鍵ペアが更新される度に、古い世代の公開鍵(更新前の公開鍵)とペアで生成された古い世代の秘密鍵(更新前の秘密鍵)がユーザによって廃棄されていると、ユーザは、古い世代の公開鍵が利用されて暗号化された暗号データを受領しても、この暗号データを復号できる古い世代の秘密鍵が存在しないため、暗号データを復号できず、結果として、必ずしも公開鍵暗号通信を実現することができないという課題がある。
さらに、古い世代の公開鍵とペアで生成された古い世代の秘密鍵がユーザによって廃棄されなかったとしても、秘密鍵の管理がユーザの手作業によって行われていると、公開鍵暗号通信における利便性を維持することができず、また、ユーザによる操作ミスを原因として秘密鍵が漏洩または紛失されるリスクを回避することができず、結果として、秘密鍵の管理が簡易かつ安全でないという課題がある。
そこで、この発明は、上述した従来技術の課題を解決するためになされたものであり、公開鍵および秘密鍵の鍵ペアが随時更新される場合でも、秘密鍵の管理が簡易かつ安全な公開鍵暗号通信を実現することが可能な公開鍵暗号通信システム、公開鍵暗号通信方法および公開鍵暗号通信プログラムを提供することを目的とする。
上述した課題を解決し、目的を達成するため、請求項1に係る発明は、データを公開鍵で暗号化した暗号データを送信する送信端末と、当該暗号データを当該送信端末から受信して前記公開鍵とペアとなる秘密鍵で復号する受信端末と、サーバとを含んで構成される公開鍵暗号通信システムであって、前記受信端末は、前記公開鍵および前記秘密鍵からなる鍵ペアが更新される度に、新たに更新された鍵ペアの公開鍵を前記サーバに送信する公開鍵送信手段と、前記鍵ペアが更新される度に、新たに更新された鍵ペアの公開鍵から公開鍵識別子を生成する受信側識別子生成手段と、前記鍵ペアが更新される度に、新たに更新された鍵ペアの秘密鍵を含む複数の世代にわたる秘密鍵を管理するとともに、当該秘密鍵に対応づけて、前記受信側識別子生成手段によって生成された公開鍵識別子をさらに管理する秘密鍵管理手段と、いずれかの世代の公開鍵によって暗号化された暗号データと、当該公開鍵から生成された公開鍵識別子とを前記送信端末から受信して、前記秘密鍵管理手段によって管理された複数の世代の秘密鍵から当該公開鍵識別子に対応づけられた秘密鍵を取得して当該暗号データを復号するデータ受信復号手段とを備え、前記サーバは、前記受信端末から送信された公開鍵を受信する公開鍵受信手段と、前記公開鍵受信手段によって受信された公開鍵のうち最新の公開鍵のみを管理する公開鍵管理手段と、前記送信端末からの要求に応じて、前記公開鍵管理手段によって管理されている最新の公開鍵を当該送信端末に送信する公開鍵送信手段とを備え、前記送信端末は、データを送信する都度、送信先の受信端末に対応する公開鍵を前記サーバに要求し、当該公開鍵を前記サーバから受信する送信側公開鍵受信手段と、前記送信側公開鍵受信手段によって受信された最新の公開鍵でデータを暗号化するデータ暗号化手段と、前記送信側公開鍵受信手段によって受信された最新の公開鍵から公開鍵識別子を生成する送信側識別子生成手段と、前記データ暗号化手段によって暗号化された暗号データと、前記送信側識別子生成手段によって生成された公開鍵識別子とを当該受信端末に送信するデータ送信手段と、を備えたことを特徴とする。
また、請求項2に係る発明は、上記の発明において、前記秘密鍵管理手段は、前記複数の世代にわたる秘密鍵を当該秘密鍵の更新に係る順番に基づく時系列に管理することを特徴とする。
また、請求項3に係る発明は、上記の発明において、前記秘密鍵管理手段は、ひとつまたは複数個の秘密鍵を新たに管理する場合に、当該秘密鍵の更新に係る順番に基づく時系列で古い方からひとつまたは複数個の既に管理されている秘密鍵と置き換えて管理することを特徴とする。
また、請求項4に係る発明は、データを公開鍵で暗号化した暗号データを送信する送信端末と、当該暗号データを当該送信端末から受信して前記公開鍵とペアとなる秘密鍵で復号する受信端末と、サーバとを含んで構成される公開鍵暗号通信方法であって、前記受信端末は、前記公開鍵および前記秘密鍵からなる鍵ペアが更新される度に、新たに更新された鍵ペアの公開鍵を前記サーバに送信する公開鍵送信工程と、前記鍵ペアが更新される度に、新たに更新された鍵ペアの公開鍵から公開鍵識別子を生成する受信側識別子生成工程と、前記鍵ペアが更新される度に、新たに更新された鍵ペアの秘密鍵を含む複数の世代にわたる秘密鍵を管理するとともに、当該秘密鍵に対応づけて、前記受信側識別子生成工程によって生成された公開鍵識別子をさらに管理する秘密鍵管理工程と、いずれかの世代の公開鍵によって暗号化された暗号データと、当該公開鍵から生成された公開鍵識別子とを前記送信端末から受信して、前記秘密鍵管理工程によって管理された複数の世代の秘密鍵から当該公開鍵識別子に対応づけられた秘密鍵を取得して当該暗号データを復号するデータ受信復号工程とを含み、前記サーバは、前記受信端末から送信された公開鍵を受信する公開鍵受信工程と、前記公開鍵受信工程によって受信された公開鍵のうち最新の公開鍵のみを管理する公開鍵管理工程と、前記送信端末からの要求に応じて、前記公開鍵管理工程によって管理されている最新の公開鍵を当該送信端末に送信する公開鍵送信工程とを含み、前記送信端末は、データを送信する都度、送信先の受信端末に対応する公開鍵を前記サーバに要求し、当該公開鍵を前記サーバから受信する送信側公開鍵受信工程と、前記送信側公開鍵受信工程によって受信された最新の公開鍵でデータを暗号化するデータ暗号化工程と、前記送信側公開鍵受信工程によって受信された最新の公開鍵から公開鍵識別子を生成する送信側識別子生成工程と、前記データ暗号化工程によって暗号化された暗号データと、前記送信側識別子生成工程によって生成された公開鍵識別子とを当該受信端末に送信するデータ暗号化送信工程と、を含んだことを特徴とする。また、請求項5に係る発明は、クライアント端末であって、公開鍵および秘密鍵からなる鍵ペアが更新される度に、新たに更新された鍵ペアの公開鍵を、最新の公開鍵のみを管理するサーバに送信する公開鍵送信手段と、前記鍵ペアが更新される度に、新たに更新された鍵ペアの公開鍵から公開鍵識別子を生成する受信側識別子生成手段と、前記鍵ペアが更新される度に、新たに更新された鍵ペアの秘密鍵を含む複数の世代にわたる秘密鍵を管理するとともに、当該秘密鍵に対応づけて、前記受信側識別子生成手段によって生成された公開鍵識別子をさらに管理する秘密鍵管理手段と、前記サーバから取得された最新の公開鍵で暗号化された暗号データと、当該公開鍵から生成された公開鍵識別子とを他のクライアント端末から受信して、前記秘密鍵管理手段によって管理された複数の世代の秘密鍵から当該公開鍵識別子に対応づけられた秘密鍵を取得して当該暗号データを復号するデータ受信復号手段と、データを送信する都度、送信先の受信端末に対応する公開鍵を前記サーバに要求し、当該公開鍵を前記サーバから受信する公開鍵受信手段と、前記公開鍵受信手段によって受信された最新の公開鍵でデータを暗号化するデータ暗号化手段と、前記公開鍵受信手段によって受信された最新の公開鍵から公開鍵識別子を生成する送信側識別子生成手段と、前記データ暗号化手段によって暗号化された暗号データと、前記送信側識別子生成手段によって生成された公開鍵識別子とを他のクライアント端末に送信するデータ送信手段と、を備えたことを特徴とする。また、請求項6に係る発明は、クライアントプログラムが、請求項5に記載のクライアント端末としてコンピュータを機能させることを特徴とする。
請求項1、4、5または6の発明によれば、データを公開鍵で暗号化した暗号データを送信する送信端末と、暗号データを送信端末から受信して公開鍵とペアとなる秘密鍵で復号する受信端末と、サーバとを含んで構成される公開鍵暗号通信システムであって、受信端末は、公開鍵および秘密鍵からなる鍵ペアが更新される度に、新たに更新された鍵ペアの公開鍵をサーバに送信し、鍵ペアが更新される度に、新たに更新された鍵ペアの公開鍵から公開鍵識別子を生成し、鍵ペアが更新される度に、新たに更新された鍵ペアの秘密鍵を含む複数の世代にわたる秘密鍵を管理するとともに、秘密鍵に対応づけて、生成された公開鍵識別子をさらに管理し、いずれかの世代の公開鍵によって暗号化された暗号データと、公開鍵から生成された公開鍵識別子とを送信端末から受信して、管理された複数の世代の秘密鍵から公開鍵識別子に対応づけられた秘密鍵を取得して暗号データを復号し、サーバは、受信端末から送信された公開鍵を受信し、受信された公開鍵のうち最新の公開鍵のみを管理し、送信端末からの要求に応じて、管理されている最新の公開鍵を送信端末に送信し、送信端末は、データを送信する都度、送信先の受信端末に対応する公開鍵を前記サーバに要求し、当該公開鍵を前記サーバから受信し、受信された最新の公開鍵でデータを暗号化し、受信された最新の公開鍵から公開鍵識別子を生成し、暗号化された暗号データと、生成された公開鍵識別子とを受信端末に送信するので、公開鍵および秘密鍵の鍵ペアが更新される度に、古い世代の公開鍵(更新前の公開鍵)とペアで生成された古い世代の秘密鍵(更新前の秘密鍵)が廃棄されないことから、古い世代の公開鍵が利用されて暗号化された暗号データを復号することができ、さらに、秘密鍵の管理がユーザの手作業によって行われないことから、公開鍵暗号通信における利便性を維持することができ、また、ユーザによる操作ミスを原因として秘密鍵が漏洩または紛失されるリスクを回避することができ、これらの結果、公開鍵および秘密鍵の鍵ペアが随時更新される場合でも、秘密鍵の管理が簡易かつ安全な公開鍵暗号通信を実現することが可能になる。また、公開鍵識別子の比較に基づいて公開鍵と秘密鍵との対応関係を短時間で確実に把握することから、本来不必要な復号(正しい復号結果を得られない復号)を発生させないことができる結果、公開鍵および秘密鍵の鍵ペアが随時更新される場合でも、秘密鍵の管理がより簡易かつ安全な公開鍵暗号通信を実現することが可能になる。
また、本発明によれば、いずれかの世代の秘密鍵とペアとなる公開鍵によって暗号化された暗号データを、複数の世代の秘密鍵から、そのいずれかの世代の秘密鍵を取得して復号することから、正しい復号結果を得ることができる結果、公開鍵および秘密鍵の鍵ペアが随時更新される場合でも、秘密鍵の管理が簡易かつ安全な公開鍵暗号通信を実現することが可能になる。
また、本発明によれば、鍵ペア特定情報の比較に基づいて公開鍵と秘密鍵との対応関係を短時間で確実に把握することから、本来不必要な復号(正しい復号結果を得られない復号)を発生させないことができ、また、鍵ペア特定情報が公開鍵とともに公開されることから、送信端末は鍵ペア特定情報を生成せずに鍵ペア特定情報を利用することができ、これらの結果、公開鍵および秘密鍵の鍵ペアが随時更新される場合でも、秘密鍵の管理がより簡易かつ安全な公開鍵暗号通信を実現することが可能になる。
また、請求項2の発明によれば、受信端末は、複数の世代にわたる秘密鍵を秘密鍵の更新に係る順番に基づく時系列に管理するので、鍵ペアの生成時刻などの順番に基づいて管理することから、鍵ペアの生成時刻などの順番に基づいた処理を行うことができる結果、公開鍵および秘密鍵の鍵ペアが随時更新される場合でも、秘密鍵の管理がより簡易かつ安全な公開鍵暗号通信を実現することが可能になる。
また、請求項3の発明によれば、受信端末は、ひとつまたは複数個の秘密鍵を新たに管理する場合に、秘密鍵の更新に係る順番に基づく時系列で古い方からひとつまたは複数個の既に管理されている秘密鍵と置き換えて管理するので、複数の世代にわたる秘密鍵の新しい方を優先的に管理することから、暗号データを復号できる確率を高めることができる結果、公開鍵および秘密鍵の鍵ペアが随時更新される場合でも、秘密鍵の管理がより簡易かつ安全な公開鍵暗号通信を実現することが可能になる。
以下に添付図面を参照して、この発明に係る公開鍵暗号通信システム、公開鍵暗号通信方法および公開鍵暗号通信プログラムの実施例を詳細に説明する。なお、以下では、実施例で用いる主要な用語、実施例1に係る公開鍵暗号通信システムの概要および特徴、実施例1に係る公開鍵暗号通信システムの構成および処理の流れ、実施例1の効果を順に説明し、次に、他の実施例を説明する。
[用語の説明]
まず最初に、以下の実施例で用いる主要な用語を説明する。以下の実施例で用いる「公開鍵暗号通信システム」とは、公開鍵暗号方式を用いた情報通信を実現するシステムのことである。ここで、公開鍵暗号方式とは、公開鍵および秘密鍵と呼ばれるペアとなる鍵(データ)を用いて、秘匿性が要求されるデータを暗号化または復号する方式である。具体的には、秘匿性が要求される平文データが公開鍵で暗号化されて暗号データとなり、この暗号データを、平文データを暗号化した公開鍵とペアとなる秘密鍵で復号する。
このような公開鍵暗号方式を用いた情報通信は、平文データを公開鍵で暗号化した暗号データを送信する送信端末と、この暗号データを送信端末から受信して公開鍵とペアとなる秘密鍵で復号する受信端末とで構成されるシステムにおいて、送信端末と受信端末とが直接的に公開鍵その他のデータを送受信する方法で実現することが可能であり、また、平文データを公開鍵で暗号化した暗号データを送信する送信クライアント(特許請求の範囲に記載の「送信端末」に対応する)と、この暗号データを送信クライアントから受信して公開鍵とペアとなる秘密鍵で復号する受信クライアント(特許請求の範囲に記載の「受信端末」に対応する)と、公開鍵を公開するサーバとで構成されるシステムにおいて、送信クライアントと受信クライアントとがサーバを経由して間接的に公開鍵その他のデータを送受信する方法で実現することも可能である。
さらに、このような公開鍵暗号方式を用いた情報通信は、受信端末において鍵ペアを生成(および更新)することが一般的ではあるが、必ずしも必須ではなく、別途、鍵ペアを生成(および更新)する機能を有する端末が生成(更新)した鍵ペアを、ICカード等の媒体によって受信端末に入力することで、受信端末が鍵ペアを保有することも可能である。
なお、以下では、公開鍵暗号通信システムの構成として、送信クライアントと、受信クライアントと、サーバとで構成されるシステムを前提とし、また、鍵ペアを生成(および更新)する端末として、受信クライアントを前提とする。
[実施例1に係る公開鍵暗号通信システムの概要および特徴]
続いて、図1を用いて、実施例1に係る公開鍵暗号通信システムの概要および特徴を説明する。図1は、実施例1に係る公開鍵暗号通信システムの概要および特徴を説明するための図である。
実施例1に係る公開鍵暗号通信システムは、上記したように、平文データを公開鍵で暗号した暗号データを送信する送信クライアントと、この暗号データを送信クライアントから受信して公開鍵とペアとなる秘密鍵で復号する受信クライアントとを含んで構成されることを概要とし、公開鍵および秘密鍵の鍵ペアが随時更新される場合でも、秘密鍵の管理が簡易かつ安全な公開鍵暗号通信を実現することを主たる特徴とする。なお、以下では、受信クライアントが鍵ペアを更新して秘密鍵を管理するまでの段階、送信クライアントが平文データを暗号化してサーバに送信するまでの段階、および、受信クライアントがサーバから暗号データを受信して復号するまでの段階の3つの段階に分けて、実施例1に係る公開鍵暗号通信システムの主たる特徴を説明する。
まず、受信クライアントが鍵ペアを更新して秘密鍵を管理するまでの段階について説明すると、図1に示すように、実施例1における受信クライアントは、最初に、公開鍵および秘密鍵の鍵ペアを更新する(図1の(1)を参照)。ここで、実施例1において更新された鍵ペアは、3回目に生成された鍵ペア(第3世代の鍵ペア)であるので、公開鍵を「PubKey_A03」と表し、秘密鍵を「PrvKey_A03」と表すこととする。次に、受信クライアントは、サーバに保管し公開してもらうことを目的として、公開鍵(PubKey_A03)をサーバに送信する(図1の(2)を参照)。すると、サーバは、受信クライアントから公開鍵(PubKey_A03)を受信し、これを保管する(図1の(3)を参照)。
一方、実施例1における受信クライアントは、新たに更新された鍵ペアの秘密鍵を含む複数の世代にわたる秘密鍵を管理する(図1の(4)を参照)。ここで、実施例1における受信クライアントは、複数の世代にわたる秘密鍵を、秘密鍵の更新に係る順番に基づく時系列に管理する。例えば、受信クライアントは、秘密鍵の時系列情報として秘密鍵の生成時刻を利用し、生成時刻の順番に基づいて管理する。図1の(4)に示すように、新たに更新された鍵ペアの秘密鍵(PrvKey_A03)の生成時刻は「2006/01/17 11:29:51」であり、他の2つの秘密鍵の生成時刻よりも新しい時刻であるので、受信クライアントは、第3世代の秘密鍵(PrvKey_A03)を他の2つの秘密鍵に続いて管理する。
続いて、送信クライアントが平文データを暗号化してサーバに送信するまでの段階について説明すると、実施例1における送信クライアントは、最初に、公開鍵を公開するサーバに対して、暗号データを送信したい通信相手が公開している公開鍵を要求する。ここでは、暗号データを送信したい通信相手は「A」であるので、Aの公開鍵を要求する(図1の(5)を参照)。
次に、送信クライアントは、受信クライアントAの第3世代の公開鍵(PubKey_A03)をサーバから受信する(図1の(6)を参照)。そして、送信クライアントは、平文データを第3世代の公開鍵で暗号化し(図1の(7)を参照)、暗号化した暗号データをサーバに送信する(図1の(8)を参照)。すると、サーバは、送信クライアントから送信された暗号データを保管する(図1の(9)を参照)。
続いて、受信クライアントがサーバから暗号データを受信して復号するまでの段階について説明すると、実施例1における受信クライアントは、第3世代の公開鍵によって暗号化された暗号データを、送信クライアントからサーバ経由で受信する(図1の(10)を参照)。なお、サーバ経由で受信するとは、送信クライアントから送信された暗号データをサーバが保管し、サーバが保管する受信クライアント宛の暗号データを受信クライアントが受信することである。
そして、受信クライアントは、管理された複数の世代の秘密鍵から秘密鍵を取得して、受信した暗号データを復号する(図1の(11)を参照)。ここで、実施例1における受信クライアントは、所定の終了命令を受け付けるまで、もしくは、管理された複数の世代の秘密鍵の全てで復号し終えるまで、秘密鍵を順に取得して暗号データを復号する。すなわち、ここでは、管理された複数の世代の秘密鍵の全てで復号し終えるまで秘密鍵を順に取得して暗号データを復号するので、第1世代の秘密鍵(PrvKey_A01)、第2世代の秘密鍵(PrvKey_A02)、および、第3世代の秘密鍵(PrvKey_A03)の全てで復号し終えるまで、第3世代の秘密鍵(PrvKey_A03)、第2世代の秘密鍵(PrvKey_A02)、第1世代の秘密鍵(PrvKey_A01)を順に取得して暗号データを復号する。こうして、第3世代の秘密鍵とペアとなる第3世代の公開鍵によって暗号化された暗号データを、複数の世代の秘密鍵から取得して復号することから、正しい復号結果を得ることができる。
ところで、上記では、第3世代の公開鍵(PubKey_A03)によって暗号化された暗号データを復号する場合を説明したが、例えば、送信クライアントが過去に入手した第1世代の公開鍵(PubKey_A01)もしくは第2世代の公開鍵(PubKey_A02)で平文データを暗号化した場合であっても、同様に、正しい復号結果を得ることができる。すなわち、実施例1に係る受信クライアントは、第1世代の秘密鍵(PrvKey_A01)、第2世代の秘密鍵(PrvKey_A02)、および、第3世代の秘密鍵(PrvKey_A03)の全てで復号し終えるまで、第3世代の秘密鍵(PrvKey_A03)、第2世代の秘密鍵(PrvKey_A02)、第1世代の秘密鍵(PrvKey_A01)を順に取得して暗号データを復号するので、第1世代の公開鍵(PubKey_A01)によって暗号化された暗号データは、取得された第1世代の秘密鍵(PrvKey_A01)で復号することで正しい復号結果を得ることができ、また、第2世代の公開鍵(PubKey_A02)によって暗号化された暗号データは、取得された第2世代の秘密鍵(PrvKey_A02)で復号することで正しい復号結果を得ることができる。
このようなことから、実施例1に係る公開鍵暗号通信システムは、公開鍵および秘密鍵の鍵ペアが随時更新される場合でも、秘密鍵の管理が簡易かつ安全な公開鍵暗号通信を実現することが可能になる。
[実施例1に係る公開鍵暗号通信システムの構成]
続いて、図2〜図6を用いて、実施例1に係る公開鍵暗号通信システムの構成を説明する。図2は、実施例1における受信クライアントおよび送信クライアントの構成を示すブロック図であり、図3は、実施例1における秘密鍵保管部を説明するための図であり、図4は、実施例1におけるサーバの構成を示すブロック図であり、図5は、実施例1における公開鍵保管部を説明するための図であり、図6は、実施例1におけるデータ保管部を説明するための図である。
[クライアントの構成]
まず、図2では、平文データを公開鍵で暗号化した暗号データを送信する送信クライアントと、暗号データを送信クライアントから受信して公開鍵とペアとなる秘密鍵で復号する受信クライアントとを、同じ端末で実現する(ひとつの端末が送信クライアントの機能および受信クライアントの機能の双方を備える)ことを前提とし、このような端末を「クライアント」と呼ぶことにする。図2に示すように、実施例1におけるクライアント100は、秘密鍵管理部110と、データ受信復号部120と、データ暗号化送信部130とから主に構成される。
秘密鍵管理部110は、公開鍵および秘密鍵からなる鍵ペアが更新される度に、新たに更新された鍵ペアの秘密鍵を含む複数の世代にわたる秘密鍵を管理する手段であり、特にこの発明に密接に関連するものとしては、図2に示すように、鍵ペア生成部111と、公開鍵送信部112と、秘密鍵保管部113とを備える。なお、秘密鍵管理部110は、特許請求の範囲に記載の「秘密鍵管理手段」に対応する。
かかる秘密鍵管理部110のなかで、鍵ペア生成部111は、ユーザ(公開鍵暗号通信を行いたい者)の公開鍵および秘密鍵からなる鍵ペアを生成(更新)する手段である。具体的には、鍵ペア生成部111は、ユーザの公開鍵および秘密鍵からなる鍵ペアを生成(更新)し、生成した公開鍵を公開鍵送信部112に送信し、生成した秘密鍵を秘密鍵保管部113に送信する。例えば、実施例1における鍵ペア生成部111は、公開鍵暗号方式としてRSA(Rivest Shamir Adleman)を採用し、鍵ペアの暗号強度として1,024bitを採用して、鍵ペアを生成(更新)する。また、実施例1における鍵ペア生成部111は、複数の世代にわたる秘密鍵が秘密鍵の更新に係る順番に基づく時系列に管理されるための時系列情報として鍵ペアの生成時刻情報を、秘密鍵とともに秘密鍵保管部113に送信する。
なお、実施例1では、公開鍵暗号方式としてRSAを採用する場合を説明したが、この発明はこれに限定されるものではなく、楕円曲線暗号方式を採用する場合や、ElGamal暗号方式を採用する場合など、いずれでもよい。また、実施例1では、鍵ペアの暗号強度として1,024bitを採用する場合を説明したが、他の強度でもよい。また、暗号強度の選択方法としては、プログラムにハードコーディングすることも、鍵ペア生成時に選択することも可能である。また、実施例1では、時系列情報として鍵ペアの生成時刻情報を用いる場合を説明したが、この発明はこれに限定されるものではなく、公開鍵がサーバ200に保管された時刻情報を用いるなど、秘密鍵の更新に係る順番に基づく時系列に管理されるための情報であれば、いずれでもよい。
公開鍵送信部112は、鍵ペアが更新される度に、新たに更新された鍵ペアの公開鍵をサーバ200に送信する手段である。具体的には、公開鍵送信部112は、鍵ペア生成部111で鍵ペアが生成(更新)される度に、新たに更新されて公開鍵送信部112に送信された鍵ペアの公開鍵を、後述するサーバ200の公開鍵受信部211に送信する。例えば、実施例1における公開鍵送信部112は、新たに更新されて公開鍵送信部112に送信された鍵ペアの公開鍵を、ユーザを識別するためのユーザ識別子とともにサーバ200の公開鍵受信部211に送信する。具体的な送信方法について例を挙げると、公開鍵とユーザ識別子とをデリミタ(例えば、CRLFなど)で区切ったデータを、HTTP(HyperText Transfer Protocol)メッセージのボディ部に載せて送信する。なお、公開鍵送信部112は、サーバ200との間の通信プロトコルとして、HTTP/1.1とHTTPS(HyperText Transfer Protocol Security)(SSL(Secure Socket Layer)v3)とを組み合わせて使用する。
秘密鍵保管部113は、鍵ペアが更新される度に、新たに更新された鍵ペアの秘密鍵を含む複数の世代にわたる秘密鍵を保管する手段である。具体的には、秘密鍵保管部113は、鍵ペア生成部111で鍵ペアが生成(更新)される度に、新たに更新されて秘密鍵保管部113に送信された鍵ペアの秘密鍵を含む複数の世代にわたる秘密鍵を保管する。また、実施例1における秘密鍵保管部113は、複数の世代にわたる秘密鍵を、秘密鍵の更新に係る順番に基づく時系列に保管する。さらに、実施例1における秘密鍵保管部113は、ひとつまたは複数個の秘密鍵を新たに管理する場合に、秘密鍵の更新に係る順番に基づく時系列で古い方からひとつまたは複数個の既に管理されている秘密鍵と置き換えて保管する。
例えば、実施例1における秘密鍵保管部113は、鍵ペア生成部111から、秘密鍵を時系列に保管するための時系列情報として鍵ペアの生成時刻情報を、秘密鍵とともに受信し、図3に示すように、この生成時刻情報と秘密鍵とを対応づけて保管する。ここで、図3の「PrvKey_A01」とは、「ユーザAの第1世代の秘密鍵」であることを表している。すなわち、図3において、鍵は「XXXKey_YZZ」の書式で表され、「XXX」は、公開鍵ならば「Pub」で表され、秘密鍵ならば「Prv」で表され、「Y」は、ユーザAなら「A」で表され、「ZZ」は、鍵の世代数が表される。また、図3に示すように、実施例1における秘密鍵保管部113は、第1世代の秘密鍵(PrvKey_A01)、第2世代の秘密鍵(PrvKey_A02)、および、第3世代の秘密鍵(PrvKey_A03)を保管している。なお、秘密鍵保管部113は、鍵ペアが更新される度に、新たに更新された鍵ペアの秘密鍵(例えば、第4世代の秘密鍵など)を含む複数の世代にわたる秘密鍵を保管する。また、実施例1では、秘密鍵をそのまま保管する場合を説明したが、この発明はこれに限定されるものではなく、秘密鍵を暗号化してから保管するなどしてもよい。
ここで、図2に戻ると、データ受信復号部120は、いずれかの世代の公開鍵によって暗号化された暗号データを送信クライアント100から受信して、秘密鍵管理部110によって管理された複数の世代の秘密鍵から秘密鍵を取得して暗号データを復号する手段であり、特にこの発明に密接に関連するものとしては、図2に示すように、データ受信部121と、秘密鍵取得部122と、データ復号部123とを備える。なお、データ受信復号部120は、特許請求の範囲に記載の「データ受信復号手段」に対応する。
かかるデータ受信復号部120のなかで、データ受信部121は、いずれかの世代の公開鍵によって暗号化された暗号データを送信クライアント100から受信する手段である。具体的には、データ受信部121は、後述するサーバ200のデータ保管部222に保管されたいずれかの世代の公開鍵によって暗号化された暗号データを、後述するサーバ200のデータ送信部223経由で送信クライアント100から受信し、データ復号部123に送信する。例えば、実施例1におけるデータ受信部121は、ユーザを識別するためのユーザ識別子(例えば、UserAなど)をサーバ200のデータ送信部223に通知することで、ユーザA宛の暗号データを受信する。なお、データ受信部121は、サーバ200との間の通信プロトコルとして、HTTP/1.1とHTTPS(SSLv3)とを組み合わせて使用する。
秘密鍵取得部122は、複数の世代の秘密鍵から秘密鍵を取得する手段である。具体的には、秘密鍵取得部122は、秘密鍵保管部113によって保管された複数の世代の秘密鍵から秘密鍵を取得して、データ復号部123に送信する。また、実施例1における秘密鍵取得部122は、複数の世代の秘密鍵の全てで復号し終えるまで、秘密鍵を順に取得する。例えば、実施例1における秘密鍵取得部122は、第1世代の秘密鍵(PrvKey_A01)、第2世代の秘密鍵(PrvKey_A02)、および、第3世代の秘密鍵(PrvKey_A03)の全てで復号し終えるまで、第3世代の秘密鍵(PrvKey_A03)、第2世代の秘密鍵(PrvKey_A02)、第1世代の秘密鍵(PrvKey_A01)を生成時刻の新しい順に取得する。なお、実施例1では、生成時刻の新しい順に秘密鍵を取得する場合を説明したが、この発明はこれに限られるものではなく、正しい復号結果が得られる可能性が高い順に秘密鍵を取得する場合など、いずれでもよい。
データ復号部123は、取得された秘密鍵で暗号データを復号する手段である。具体的には、データ復号部123は、秘密鍵取得部122によって取得された秘密鍵で、データ受信部121から送信された暗号データを復号する。また、実施例1におけるデータ復号部123は、複数の世代の秘密鍵の全てで復号し終えるまで、順に取得された秘密鍵で暗号データを復号する。例えば、実施例1におけるデータ復号部123は、第1世代の秘密鍵(PrvKey_A01)、第2世代の秘密鍵(PrvKey_A02)、および、第3世代の秘密鍵(PrvKey_A03)の全てで復号し終えるまで、生成時刻の新しい順に取得された第3世代の秘密鍵(PrvKey_A03)、第2世代の秘密鍵(PrvKey_A02)、第1世代の秘密鍵(PrvKey_A01)で暗号データを復号する。
データ暗号化送信部130は、平文データをいずれかの世代の公開鍵で暗号化した暗号データを受信クライアント100に送信する手段であり、特にこの発明に密接に関連するものとしては、図2に示すように、公開鍵受信部131と、データ暗号化部132と、データ送信部133とを備える。なお、データ暗号化送信部130は、特許請求の範囲に記載の「データ暗号化送信手段」に対応する。
かかるデータ暗号化送信部130のなかで、公開鍵受信部131は、ユーザ(公開鍵暗号通信を行いたい者)の公開鍵をサーバ200に要求してサーバ200から受信する手段である。具体的には、公開鍵受信部131は、ユーザの公開鍵を、後述するサーバ200の公開鍵送信部213に要求して公開鍵送信部213から受信し、データ暗号化部132に送信する。例えば、実施例1における公開鍵受信部131は、ユーザを識別するためのユーザ識別子をサーバ200の公開鍵送信部213に送信して、このユーザ識別子に対応づけられた、いずれかの世代の公開鍵を要求する。なお、公開鍵受信部131は、サーバ200との間の通信プロトコルとしてHTTP/1.1とHTTPS(SSLv3)とを組み合わせて使用する。
データ暗号化部132は、平文データをいずれかの世代の公開鍵で暗号化する手段である。具体的には、データ暗号化部132は、平文データを公開鍵受信部131から受信したいずれかの世代の公開鍵で暗号化し、暗号化した暗号データをデータ送信部133に送信する。
データ送信部133は、いずれかの世代の公開鍵で暗号化された暗号データをサーバ200に送信する手段である。具体的には、データ送信部133は、データ暗号化部132で暗号化された暗号データを受信し、後述するサーバ200のデータ受信部221に送信する。なお、データ送信部133は、サーバ200との間の通信プロトコルとしてHTTP/1.1とHTTPS(SSLv3)とを組み合わせて使用する。
[サーバの構成]
続いて、図4に示すように、実施例1におけるサーバ200は、公開鍵管理部210と、データ送受信部220とから主に構成される。
公開鍵管理部210は、受信クライアント100において公開鍵および秘密鍵からなる鍵ペアが更新される度に、新たに更新された鍵ペアの公開鍵を受信クライアント100から受信して管理する手段であり、特にこの発明に密接に関連するものとしては、図4に示すように、公開鍵受信部211と、公開鍵保管部212と、公開鍵送信部213とを備える。
かかる公開管理部210のなかで、公開鍵受信部211は、受信クライアント100において公開鍵および秘密鍵からなる鍵ペアが更新される度に、新たに更新された鍵ペアの公開鍵を受信クライアント100から受信する手段である。具体的には、公開鍵受信部211は、受信クライアント100において公開鍵および秘密鍵からなる鍵ペアが更新される度に、新たに更新された鍵ペアの公開鍵を受信クライアント100の公開鍵送信部112から受信し、公開鍵保管部212に送信する。例えば、実施例1における公開鍵受信部211は、受信クライアント100の公開鍵送信部112から、公開鍵(例えば、PubKey_A03など)とともにユーザ識別子(例えば、UserAなど)を受信し、公開鍵とともにユーザ識別子を公開鍵保管部212に送信する。なお、公開鍵受信部211は、受信クライアント100との間の通信プロトコルとして、HTTP/1.1とHTTPS(SSLv3)とを組み合わせて使用する。
公開鍵保管部212は、受信クライアント100から受信された公開鍵を保管する手段である。具体的には、公開鍵保管部212は、受信クライアント100から受信された公開鍵を公開鍵受信部211から受信し、保管する。また、公開鍵送信部213において送信クライアント100から公開鍵送信の要求を受け付け、これが公開鍵保管部212に通知されると、公開鍵保管部212は、保管する公開鍵を公開鍵送信部213に送信する。
例えば、実施例1における公開鍵保管部212は、公開鍵受信部211によって受信クライアント100から受信された公開鍵(例えば、PubKey_A03など)とユーザ識別子(例えば、UserAなど)とを公開鍵受信部211から受信し、図5に示すように公開鍵(PubKey_A03)とユーザ識別子(UserA)とを対応づけて保管する。また、公開鍵送信部213において送信クライアント100からユーザ識別子(例えば、UserAなど)を受信して、ユーザAのいずれかの世代の公開鍵送信要求を受け付け、このユーザ識別子(UserA)が公開鍵保管部212に通知されると、公開鍵保管部212は、ユーザ識別子(UserA)をキーにして公開鍵を検索し、ユーザ識別子(UserA)に対応づけられた公開鍵(PubKey_A03)を公開鍵送信部213に送信する。なお、実施例1における公開鍵保管部212は、図5に示すように、公開鍵を公開鍵受信時刻と対応づけて時系列に保管し、1ユーザにつきM個(Mは自然数)まで保管して、最新の公開鍵を公開鍵送信部213に送信するが、この発明はこれに限定されるものではなく、時系列で保管しない場合や、1ユーザにつき1個しか保管しない場合や、最新以外の公開鍵を含めて全ての公開鍵を送信する場合など、いずれでもよい。また、実施例1では、公開鍵をそのまま保管する場合を説明したが、この発明はこれに限定されるものではなく、公開鍵を暗号化してから保管するなどしてもよい。
公開鍵送信部213は、送信クライアント100から、ユーザ(公開鍵暗号通信を行いたい者)の公開鍵送信要求を受け付け、送信クライアント100に送信する手段である。具体的には、公開鍵送信部213は、送信クライアント100の公開鍵受信部131から公開鍵送信要求を受け付け、これを公開鍵保管部212に通知し、公開鍵保管部212から受信する公開鍵を送信クライアント100の公開鍵受信部131に送信する。例えば、実施例1における公開鍵送信部213は、送信クライアント100からユーザ識別子(例えば、UserAなど)を受信して、公開鍵送信の要求を受け付ける。そして、公開鍵送信部213は、ユーザ識別子(UserA)を公開鍵保管部212に通知し、公開鍵保管部212からユーザ識別子(UserA)に対応づけられた公開鍵(PubKey_A03)を受信して、送信クライアント100の公開鍵受信部131に送信する。なお、公開鍵送信部213は、送信クライアント100との間の通信プロトコルとして、HTTP/1.1とHTTPS(SSLv3)とを組み合わせて使用する。
データ送受信部220は、いずれかの世代の公開鍵で暗号化された暗号データを送信クライアント100から受信し、受信クライアント100に送信する手段であり、特にこの発明に密接に関連するものとしては、図4に示すように、データ受信部221と、データ保管部222と、データ送信部223と、暗号データファイル部224とを備える。
かかるデータ送受信部220のなかで、データ受信部221は、平文データがいずれかの世代の公開鍵で暗号化された暗号データを送信クライアント100から受信する手段である。具体的には、データ受信部221は、平文データがいずれかの世代の公開鍵で暗号化された暗号データを送信クライアント100のデータ送信部133から受信し、暗号データに係る情報をデータ保管部222に送信する。例えば、実施例1におけるデータ受信部221は、平文データがユーザ(例えば、ユーザAなど)のいずれかの世代の公開鍵で暗号化された暗号データとともに、ユーザ識別子(UserA)を送信クライアント100のデータ送信部133から受信し、暗号データを暗号データファイル部224に保存する。その際、暗号データのファイル名は、「nnn_yymmdd-hhss.dat」形式で表し、ユーザ名「nnn」と、暗号データ受信時刻「yymmdd-hhss」とを使用することで、サーバ200内部で一意になるようにファイル名を付与する。そして、データ受信部221は、暗号データに係る情報として、この暗号データのファイル名とユーザ識別子とを、データ保管部222に送信する。なお、データ受信部221は、送信クライアント100との間の通信プロトコルとして、HTTP/1.1とHTTPS(SSLv3)とを組み合わせて使用する。
データ保管部222は、送信クライアント100から受信した暗号データに係る情報を保管する手段である。具体的には、データ保管部222は、データ受信部221が送信クライアント100から受信した暗号データに係る情報を保管し、データ送信部223に送信する。例えば、実施例1におけるデータ保管部222は、データ受信部221から暗号データのファイル名とユーザ識別子とを受信し、図6に示すように、ファイル名とユーザ識別子とを対応づけて保管する。そして、データ送信部223から受信したユーザ識別子をキーにしてファイル名を検索し、ユーザ識別子に対応づけられた暗号データのファイル名を取得し、データ送信部223に送信する。なお、実施例1では、データ保管部222に暗号データに係る情報のみを保管する場合を説明したが、この発明はこれに限定されるものではなく、データ保管部222に暗号データ自体を保管する場合など、いずれでもよい。
データ送信部223は、サーバ200において保管される暗号データを、受信クライアント100に送信する手段である。具体的には、データ送信部223は、データ保管部222から受信した暗号データに係る情報に基づいて、暗号データファイル部224に保管する暗号データファイルを、受信クライアント100のデータ受信部121に送信する。例えば、実施例1におけるデータ送信部223は、受信クライアント100のデータ受信部121から受信したユーザ識別子をデータ保管部222に送信し、データ保管部222からユーザ識別子に対応する暗号データファイル名を受信し、暗号データファイル部224からこの暗号データファイル名に対応する暗号データファイルを取得して、受信クライアント100のデータ受信部121に送信する。なお、データ送信部223は、受信クライアント100との間の通信プロトコルとして、HTTP/1.1とHTTPS(SSLv3)とを組み合わせて使用する。
暗号データファイル部224は、送信クライアント100から受信した暗号データを保管する手段である。具体的には、暗号データファイル部224は、データ受信部221から送信された暗号データファイルを保管し、データ送信部223に送信する。
[実施例1に係る公開鍵暗号通信システムによる処理]
次に、図7を用いて、実施例1に係る公開鍵暗号通信システムによる処理を説明する。図7は、実施例1における公開鍵暗号通信処理の流れを示すシーケンス図である。なお、以下では、受信クライアント100が鍵ペアを更新して秘密鍵を管理するまでの段階(図7の(1)〜(4))、送信クライアント100が平文データを暗号化してサーバ200に送信するまでの段階(図7の(5)〜(9))、受信クライアント100がサーバ200から暗号データを受信して復号するまでの段階(図7の(10)〜(11))の3つの段階に分けて、実施例1に係る公開鍵暗号通信システムによる処理を説明する。
まず、受信クライアント100が鍵ペアを更新して秘密鍵を管理するまでの段階について説明すると、図7に示すように、実施例1における受信クライアント100は、鍵ペア生成部111において、ユーザ(公開鍵暗号通信を行いたい者)の公開鍵および秘密鍵からなる鍵ペアを生成(更新)する(図7の(1)を参照)。
次に、受信クライアント100は、公開鍵送信部112において、新たに更新された鍵ペアの公開鍵を、ユーザを識別するためのユーザ識別子とともにサーバ200の公開鍵受信部211に送信し、公開鍵の保管を要求する(図7の(2)を参照)。
すると、サーバ200は、公開鍵受信部211において、受信クライアント100から公開鍵とともにユーザ識別子を受信し、これらを公開鍵保管部212に送信して、公開鍵とユーザ識別子とを対応づけて保管する(図7の(3)を参照)。
続いて、受信クライアント100は、秘密鍵保管部113において、新たに更新された鍵ペアの秘密鍵を含む複数の世代にわたる秘密鍵を保管する(図7の(4)を参照)。
次に、送信クライアント100が平文データを暗号化してサーバ200に送信するまでの段階について説明すると、図7に示すように、実施例1における送信クライアント100は、公開鍵受信部131において、ユーザ(公開鍵暗号通信を行いたい者)の公開鍵を、ユーザ識別子を送信してサーバ200に要求する(図7の(5)を参照)。
そして、サーバ200は、公開鍵送信部213において、送信クライアント100から公開鍵送信要求(ユーザ識別子)を受け付け、これを公開鍵保管部212に通知し、公開鍵保管部212からユーザ識別子に対応づけられた公開鍵を受信して、送信クライアント100の公開鍵受信部131に送信する(図7の(6)を参照)。
続いて、送信クライアント100は、公開鍵受信部131において、ユーザの公開鍵をサーバ200から受信し、データ暗号化部132において、平文データをこの公開鍵で暗号化する(図7の(7)を参照)。
そして、送信クライアント100は、データ送信部133において、データ暗号化部132において暗号化された暗号データを、ユーザ識別子とともにサーバ200のデータ受信部221に送信する(図7の(8)を参照)。
すると、サーバ200は、データ受信部221において、平文データがいずれかの世代の公開鍵で暗号化された暗号データとユーザ識別子とを送信クライアントのデータ送信部133から受信し、暗号データのファイル名とユーザ識別子とをデータ保管部222に送信し、データ保管部222において、暗号データのファイル名とユーザ識別子とを対応づけて保管する(図7の(9)を参照)。
次に、受信クライアント100がサーバ200から暗号データを受信して復号するまでの段階について説明すると、図7に示すように、受信クライアント100は、データ受信部121において、ユーザ識別子をサーバ200のデータ送信部223に通知することで、暗号データを受信する(図7の(10)を参照)。
そして、受信クライアント100は、複数の世代の秘密鍵の全てで復号し終えるまで、秘密鍵取得部122において、秘密鍵保管部113によって保管された複数の世代の秘密鍵から秘密鍵を取得してデータ復号部123に送信し、データ復号部123において、取得された秘密鍵で暗号データを復号する(図7の(11)を参照)。
なお、上記では、サーバ200が公開鍵を保管した後に、受信クライアント100が秘密鍵を管理する場合を説明したが、この発明はこれに限定されるものではなく、受信クライアント100が秘密鍵を管理した後に、サーバ200が公開鍵を保管する場合にも、本発明を同様に適用することができる。また、上記では、サーバ200が新たに更新された公開鍵を保管した後に、送信クライアント100が公開鍵を要求する場合を説明したが、この発明はこれに限定されるものではなく、サーバ200が新たに更新された公開鍵を保管する前に、送信クライアント100が公開鍵を要求する場合にも、本発明を同様に適用することができる。
[実施例1の効果]
上記してきたように、実施例1によれば、平文データを公開鍵で暗号化した暗号データを送信する送信端末と、暗号データを送信端末から受信して公開鍵とペアとなる秘密鍵で復号する受信端末とを含んで構成される公開鍵暗号通信システムであって、受信端末は、公開鍵および秘密鍵からなる鍵ペアが更新される度に、新たに更新された鍵ペアの秘密鍵を含む複数の世代にわたる秘密鍵を管理し、いずれかの世代の公開鍵によって暗号化された暗号データを送信端末から受信して、管理された複数の世代の秘密鍵から秘密鍵を取得して暗号データを復号し、送信端末は、平文データをいずれかの世代の公開鍵で暗号化した暗号データを受信端末に送信するので、公開鍵および秘密鍵の鍵ペアが更新される度に、古い世代の公開鍵(更新前の公開鍵)とペアで生成された古い世代の秘密鍵(更新前の秘密鍵)が廃棄されないことから、古い世代の公開鍵が利用されて暗号化された暗号データを復号することができ、さらに、秘密鍵の管理がユーザの手作業によって行われないことから、公開鍵暗号通信における利便性を維持することができ、また、ユーザによる操作ミスを原因として秘密鍵が漏洩または紛失されるリスクを回避することができ、これらの結果、公開鍵および秘密鍵の鍵ペアが随時更新される場合でも、秘密鍵の管理が簡易かつ安全な公開鍵暗号通信を実現することが可能になる。
また、実施例1によれば、受信端末は、所定の終了命令を受け付けるまで、もしくは、管理された複数の世代の秘密鍵の全てで復号し終えるまで、秘密鍵を順に取得して暗号データを復号するので、いずれかの世代の秘密鍵とペアとなる公開鍵によって暗号化された暗号データを、複数の世代の秘密鍵から、そのいずれかの世代の秘密鍵を取得して復号することから、正しい復号結果を得ることができる結果、公開鍵および秘密鍵の鍵ペアが随時更新される場合でも、秘密鍵の管理が簡易かつ安全な公開鍵暗号通信を実現することが可能になる。
また、実施例1によれば、受信端末は、複数の世代にわたる秘密鍵を秘密鍵の更新に係る順番に基づく時系列に管理するので、鍵ペアの生成時刻などの順番に基づいて管理することから、鍵ペアの生成時刻などの順番に基づいた処理を行うことができる結果、公開鍵および秘密鍵の鍵ペアが随時更新される場合でも、秘密鍵の管理がより簡易かつ安全な公開鍵暗号通信を実現することが可能になる。
また、実施例1によれば、受信端末は、ひとつまたは複数個の秘密鍵を新たに管理する場合に、秘密鍵の更新に係る順番に基づく時系列で古い方からひとつまたは複数個の既に管理されている秘密鍵と置き換えて管理するので、複数の世代にわたる秘密鍵の新しい方を優先的に管理することから、暗号データを復号できる確率を高めることができる結果、公開鍵および秘密鍵の鍵ペアが随時更新される場合でも、秘密鍵の管理がより簡易かつ安全な公開鍵暗号通信を実現することが可能になる。
ところで、上記の実施例1では、受信クライアント100が、管理する複数の世代の秘密鍵の全てで復号し終えるまで、秘密鍵を順に取得して暗号データを復号する場合を説明したが、この発明はこれに限定されるものではなく、秘密鍵とペアとなる公開鍵から生成された公開鍵識別子をさらに管理し、この公開鍵識別子に対応づけられた秘密鍵を取得して暗号データを復号する場合にも、この発明を同様に適用することができる。そこで、以下では、実施例2として、秘密鍵とペアとなる公開鍵から生成された公開鍵識別子をさらに管理し、この公開鍵識別子に対応づけられた秘密鍵を取得して暗号データを復号する場合を説明する。
[実施例2に係る公開鍵暗号通信システムの概要および特徴]
まず最初に、図8を用いて、実施例2に係る公開鍵暗号通信システムの概要および特徴を説明する。図8は、実施例2に係る公開鍵暗号通信システムの概要および特徴を説明するための図である。なお、以下では、受信クライアントが鍵ペアを更新して秘密鍵を管理するまでの段階、送信クライアントが平文データを暗号化してサーバに送信するまでの段階、および、受信クライアントがサーバから暗号データを受信して復号するまでの段階の3つの段階に分けて、実施例2に係る公開鍵暗号通信システムの主たる特徴を説明する。
まず、受信クライアントが鍵ペアを更新して秘密鍵を管理するまでの段階について説明すると、図8に示すように、実施例2における受信クライアントは、最初に、公開鍵および秘密鍵の鍵ペアを更新する(図8の(1)を参照)。ここで、実施例2において更新された鍵ペアは、3回目に生成された鍵ペア(第3世代の鍵ペア)であるので、公開鍵を「PubKey_A03」と表し、秘密鍵を「PrvKey_A03」と表すこととする。次に、受信クライアントは、新たに更新された公開鍵(PubKey_A03)を識別するための公開鍵識別子(H(PubKey_A03))を生成する(図8の(2)を参照)。そして、受信クライアントは、サーバに保管し公開してもらうことを目的として、公開鍵(PubKey_A03)をサーバに送信する(図8の(3)を参照)。すると、サーバは、受信クライアントから公開鍵(PubKey_A03)を受信し、これを保管する(図8の(4)を参照)。
一方、実施例2における受信クライアントは、新たに更新された鍵ペアの秘密鍵を含む複数の世代にわたる秘密鍵を管理するだけでなく、秘密鍵に対応づけて、秘密鍵とペアとなる公開鍵から生成された公開鍵識別子をさらに管理する(図8の(5)を参照)。
続いて、送信クライアントが平文データを暗号化してサーバに送信するまでの段階について説明すると、実施例2における送信クライアントは、最初に、公開鍵を公開するサーバに対して、暗号データを送信したい通信相手が公開している公開鍵を要求する。ここでは、暗号データを送信したい通信相手は「A」であるので、Aの公開鍵を要求する(図8の(6)を参照)。
次に、送信クライアントは、受信クライアントAの第3世代の公開鍵(PubKey_A03)をサーバから受信する(図8の(7)を参照)。そして、送信クライアントは、平文データを第3世代の公開鍵で暗号化する(図8の(8)を参照)。また、送信クライアントは、サーバから受信した公開鍵から公開鍵識別子(H(PubKey_A03))を生成する(図8の(9)を参照)。そして、送信クライアントは、公開鍵で暗号化した暗号データとともに、公開鍵から生成された公開鍵識別子をサーバに送信する(図8の(10)を参照)。すると、サーバは、送信クライアントから送信された暗号データと公開鍵識別子とを保管する(図8の(11)を参照)。
続いて、受信クライアントがサーバから暗号データを受信して復号するまでの段階について説明すると、実施例2における受信クライアントは、第3世代の公開鍵によって暗号化された暗号データとともに、公開鍵から生成された公開鍵識別子(H(PubKey_A03))を、送信クライアントからサーバ経由で受信する(図8の(12)を参照)。なお、サーバ経由で受信するとは、送信クライアントから送信された暗号データおよび公開鍵識別子をサーバが保管し、サーバが保管する受信クライアント宛の暗号データおよび公開識別子を受信クライアントが受信することである。
そして、受信クライアントは、管理された複数の世代の秘密鍵から秘密鍵を取得して、受信した暗号データを復号する(図8の(13)を参照)。ここで、実施例2における受信クライアントは、管理された複数の世代の秘密鍵から、サーバから受信した公開鍵識別子に対応づけられた秘密鍵を取得して暗号データを復号する。すなわち、サーバから受信した公開鍵識別子は「H(PubKey_A03)」であるので、公開鍵識別子(H(PubKey_A03))に対応づけられた秘密鍵(PrvKey_A03)を取得して暗号データを復号する。こうして、第3世代の秘密鍵とペアとなる公開鍵によって暗号化された暗号データを、第3世代の公開鍵から生成された公開鍵識別子に対応づけられた秘密鍵を取得して復号するので、公開鍵識別子の比較に基づいて公開鍵と秘密鍵との対応関係を短時間で確実に把握することから、本来不必要な復号(正しい復号結果を得られない復号)を発生させないことができる。
ところで、上記では、第3世代の公開鍵(PubKey_A03)によって暗号化された暗号データを復号する場合を説明したが、例えば、送信クライアントが過去に入手した第1世代の公開鍵(PubKey_A01)もしくは第2世代の公開鍵(PubKey_A02)で平文データを暗号化した場合であっても、同様に、本来不必要な復号を発生させずに正しい復号結果を得ることができる。すなわち、実施例2に係る受信クライアントは、公開鍵によって暗号化された暗号データとともに、公開鍵から生成された公開鍵識別子をさらに受信して、公開鍵識別子に対応づけられた秘密鍵を取得して暗号データを復号するので、受信クライアントは、第1世代の公開鍵(PubKey_A01)によって暗号化された暗号データとともに、第1世代の公開鍵の公開鍵識別子(H(PubKey_A01))をさらに受信して、公開鍵識別子(H(PubKey_A01))に対応づけられた秘密鍵(PrvKey_A01)を取得して暗号データを復号するので、本来不必要な復号を発生させずに正しい復号結果を得ることができ、また、受信クライアントは、第2世代の公開鍵(PubKey_A02)によって暗号化された暗号データとともに、第2世代の公開鍵の公開鍵識別子(H(PubKey_A02))をさらに受信して、公開鍵識別子(H(PubKey_A02))に対応づけられた秘密鍵(PrvKey_A02)を取得して暗号データを復号するので、本来不必要な復号を発生させずに正しい復号結果を得ることができる。
このようなことから、実施例2に係る公開鍵暗号通信システムは、公開鍵および秘密鍵の鍵ペアが随時更新される場合でも、秘密鍵の管理がより簡易かつ安全な公開鍵暗号通信を実現することが可能になる。
[実施例2に係る公開鍵暗号通信システムの構成]
続いて、図9〜図12を用いて、実施例2に係る公開鍵暗号通信システムの構成を説明する。図9は、実施例1における受信クライアントおよび送信クライアントの構成を示すブロック図であり、図10は、実施例1における秘密鍵保管部を説明するための図であり、図11は、実施例1におけるサーバの構成を示すブロック図であり、図12は、実施例1におけるデータ保管部を説明するための図である。なお、以下では、実施例1に係る公開鍵暗号通信システムと同様に構成される点については、簡単に説明することとする。
[クライアントの構成]
まず、図9に示すように、実施例2におけるクライアント300は、秘密鍵管理部310と、データ受信復号部320と、データ暗号化送信部330とから主に構成される。
秘密鍵管理部310は、公開鍵および秘密鍵からなる鍵ペアが更新される度に、新たに更新された鍵ペアの秘密鍵を含む複数の世代にわたる秘密鍵を管理する手段であり、特にこの発明に密接に関連するものとしては、図9に示すように、鍵ペア生成部311と、公開鍵送信部312と、識別子生成部313と、秘密鍵保管部314とを備える。なお、秘密鍵管理部310は、特許請求の範囲に記載の「秘密鍵管理手段」に対応する。
かかる秘密鍵管理部310のなかで、鍵ペア生成部311は、実施例1における鍵ペア生成部111と同様、ユーザ(公開鍵暗号通信を行いたい者)の公開鍵および秘密鍵からなる鍵ペアを生成(更新)する手段である。また、公開鍵送信部312は、実施例1における公開鍵送信部112と同様、鍵ペアが更新される度に、新たに更新された鍵ペアの公開鍵をサーバ400に送信する手段である。
識別子生成部313は、公開鍵を識別するための公開鍵識別子を、秘密鍵とペアとなる公開鍵から生成する手段である。具体的には、識別子生成部313は、鍵ペア生成部311で鍵ペアが生成(更新)される度に、新たに更新されて識別子生成部313に送信された鍵ペアの公開鍵から、公開鍵識別子を生成し、秘密鍵保管部314に送信する。例えば、実施例2における識別子生成部313は、ハッシュアルゴリズムとしてSHA−1(Secure Hash Algorithm 1)を用いて公開鍵のハッシュ値を計算することによって、公開鍵識別子を生成する。なお、実施例2では、ハッシュアルゴリズムとしてSHA−1(Secure Hash Algorithm 1)を用いる場合を説明したが、この発明はこれに限定されるものではなく、ハッシュアルゴリズムとしてMD5(Message Digest 5)を用いる場合や、SHA−2を用いる場合など、いずれでもよい。
秘密鍵保管部314は、鍵ペアが更新される度に、新たに更新された鍵ペアの秘密鍵を含む複数の世代にわたる秘密鍵を保管するだけでなく、秘密鍵に対応づけて、秘密鍵とペアとなる公開鍵から生成された公開鍵識別子をさらに管理する手段である。具体的には、秘密鍵保管部314は、鍵ペア生成部311で鍵ペアが生成(更新)される度に、新たに更新されて秘密鍵保管部314に送信された鍵ペアの秘密鍵を含む複数の世代にわたる秘密鍵を保管するが、その際に、秘密鍵に対応づけて、識別子生成部313から送信された公開鍵識別子をさらに保管する。例えば、実施例2における秘密鍵保管部314は、鍵ペア生成部311から、秘密鍵を時系列に保管するための時系列情報として鍵ペアの生成時刻情報を、秘密鍵とともに受信し、図10に示すように、この生成時刻情報と秘密鍵と公開鍵識別子とを対応づけて保管する。
ここで、図9に戻ると、データ受信復号部320は、いずれかの世代の公開鍵によって暗号化された暗号データを送信クライアント300から受信して、秘密鍵管理部310によって管理された複数の世代の秘密鍵から秘密鍵を取得して暗号データを復号する手段であり、特にこの発明に密接に関連するものとしては、図9に示すように、データ受信部321と、秘密鍵取得部322と、データ復号部323とを備える。なお、データ受信復号部320は、特許請求の範囲に記載の「データ受信復号手段」に対応する。
かかるデータ受信復号部320のなかで、データ受信部321は、いずれかの世代の公開鍵によって暗号化された暗号データを送信クライアント300から受信するだけでなく、公開鍵によって暗号化された暗号データとともに、公開鍵から生成された公開鍵識別子を送信クライアント300からさらに受信する手段である。具体的には、データ受信部321は、後述するサーバ400のデータ保管部422に保管されたいずれかの世代の公開鍵によって暗号化された暗号データとともに、公開鍵から生成された公開鍵識別子を後述するサーバ400のデータ送信部423経由で送信クライアント300から受信し、暗号データをデータ復号部323に送信し、公開鍵識別子を秘密鍵取得部322に送信する。例えば、実施例2におけるデータ受信部321は、ユーザを識別するためのユーザ識別子(例えば、UserAなど)をサーバ400のデータ送信部423に通知することで、ユーザA宛の暗号データとともに公開鍵識別子(例えば、H(PubKey_A03))を受信し、暗号データをデータ復号部323に送信し、公開鍵識別子(例えば、H(PubKey_A03))を秘密鍵取得部322に送信する。
秘密鍵取得部322は、複数の世代の秘密鍵から公開鍵識別子に対応づけられた秘密鍵を取得する手段である。具体的には、秘密鍵取得部322は、秘密鍵保管部314によって保管された複数の世代の秘密鍵から、データ受信部321から送信された公開鍵識別子(例えば、H(PubKey_A03))に対応づけられた秘密鍵を取得し、データ復号部323に送信する。例えば、実施例2における秘密鍵取得部322は、データ受信部321から公開鍵識別子としてH(PubKey_A03)を受信すると、H(PubKey_A03)をキーにして秘密鍵を検索し、H(PubKey_A03)に対応づけられた秘密鍵(Prvkey_A03)を取得し、データ復号部323に送信する。
データ復号部323は、取得された秘密鍵で暗号データを復号する手段である。具体的には、データ復号部323は、秘密鍵取得部322によって取得された秘密鍵で、データ受信部321から送信された暗号データを復号する。
データ暗号化送信部330は、平文データをいずれかの世代の公開鍵で暗号化した暗号データを受信クライアント300に送信する手段であり、特にこの発明に密接に関連するものとしては、図9に示すように、公開鍵受信部331と、識別子生成部332と、データ暗号化部333と、データ送信部334とを備える。なお、データ暗号化送信部330は、特許請求の範囲に記載の「データ暗号化送信手段」に対応する。
かかるデータ暗号化送信部330のなかで、公開鍵受信部331は、ユーザ(公開鍵暗号通信を行いたい者)の公開鍵をサーバ400に要求してサーバ400から受信する手段である。具体的には、公開鍵受信部331は、ユーザの公開鍵を、後述するサーバ400の公開鍵送信部413に要求して公開鍵送信部から受信し、識別子生成部332およびデータ暗号化部333に送信する。
識別子生成部332は、公開鍵を識別するための公開鍵識別子を、秘密鍵とペアとなる公開鍵から生成する手段である。具体的には、識別子生成部332は、公開鍵受信部331から送信された公開鍵から、公開鍵識別子を生成し、データ送信部334に送信する。
例えば、実施例2における識別子生成部332は、ハッシュアルゴリズムとしてSHA−1(Secure Hash Algorithm 1)を用いて公開鍵のハッシュ値を計算することによって、公開鍵識別子を生成する。なお、実施例2では、ハッシュアルゴリズムとしてSHA−1(Secure Hash Algorithm 1)を用いる場合を説明したが、この発明はこれに限定されるものではなく、ハッシュアルゴリズムとしてMD5(Message Digest 5)を用いる場合や、SHA−2を用いる場合など、いずれでもよい。
データ暗号化部333は、実施例1におけるデータ暗号化部132と同様、平文データをいずれかの世代の公開鍵で暗号化する手段である。また、データ送信部334は、いずれかの世代の公開鍵で暗号化された暗号データをサーバ400に送信する手段である。具体的には、データ送信部334は、データ暗号化部333で暗号化された暗号データを受信し、識別子生成部332から公開鍵識別子を受信し、後述するサーバ400のデータ受信部421に送信する。
[サーバの構成]
続いて、図11に示すように、実施例2におけるサーバ400は、公開鍵管理部410と、データ送受信部420とから主に構成される。
公開鍵管理部410は、受信クライアント300において公開鍵および秘密鍵からなる鍵ペアが更新される度に、新たに更新された鍵ペアの公開鍵を受信クライアント300から受信して管理する手段であり、特にこの発明に密接に関連するものとしては、図11に示すように、公開鍵受信部411と、公開鍵保管部412と、公開鍵送信部413とを備える。
かかる公開鍵管理部410のなかで、公開鍵受信部411は、実施例1における公開鍵受信部211と同様、受信クライアント300において公開鍵および秘密鍵からなる鍵ペアが更新される度に、新たに更新された鍵ペアの公開鍵を受信クライアント300から受信する手段である。
公開鍵保管部412は、実施例1における公開鍵保管部212と同様、受信クライアント300から受信された公開鍵を保管する手段である。また、公開鍵送信部413は、実施例1における公開鍵送信部213と同様、送信クライアント300から、ユーザ(公開鍵暗号通信を行いたい者)の公開鍵送信要求を受け付け、送信クライアント300に送信する手段である。
データ送受信部420は、いずれかの世代の公開鍵で暗号化された暗号データを送信クライアント300から受信し、受信クライアント300に送信する手段であり、特にこの発明に密接に関連するものとしては、図11に示すように、データ受信部421と、データ保管部422と、データ送信部423と、暗号データファイル部424とを備える。
かかるデータ送受信部420のなかで、データ受信部421は、平文データがいずれかの世代の公開鍵で暗号化された暗号データを送信クライアント300から受信する手段である。具体的には、データ受信部421は、平文データがいずれかの世代の公開鍵で暗号化された暗号データおよび公開鍵識別子を送信クライアント300のデータ送信部333から受信し、暗号データに係る情報および公開鍵識別子をデータ保管部422に送信する。
データ保管部422は、送信クライアント300から受信した暗号データに係る情報および公開鍵識別子を保管する手段である。具体的には、データ保管部422は、データ受信部421が送信クライアント300から受信した暗号データに係る情報および公開鍵識別子を保管し、データ送信部423に送信する。例えば、実施例2におけるデータ保管部422は、データ受信部421から暗号データのファイル名とユーザ識別子と公開鍵識別子とを受信し、図12に示すように、ファイル名とユーザ識別子と公開鍵識別子とを対応づけて保管する。そして、データ送信部423から受信したユーザ識別子をキーにしてファイル名を検索し、ユーザ識別子に対応づけられた暗号データのファイル名を取得し、データ送信部423に、ファイル名および公開鍵識別子を送信する。
データ送信部423は、サーバ400において保管される暗号データおよび公開鍵識別子を、受信クライアント300に送信する手段である。具体的には、データ送信部423は、データ保管部422から受信した暗号データに係る情報に基づいて、暗号データファイル部424に保管する暗号データファイルおよび公開鍵識別子を、受信クライアント300のデータ受信部321に送信する。例えば、実施例2におけるデータ送信部423は、受信クライアント300のデータ受信部321から受信したユーザ識別子をデータ保管部422に送信し、データ保管部422からユーザ識別子に対応する暗号データファイル名を受信し、暗号データファイル部424からこの暗号データファイル名に対応する暗号データファイルを取得して、さらに、データ保管部422から送信された公開鍵識別子とともに、受信クライアント300のデータ受信部321に送信する。また、暗号データファイル部424は、実施例1における暗号データファイル部224と同様、送信クライアント300から受信した暗号データを保管する手段である。
[実施例2に係る公開鍵暗号通信システムによる処理]
次に、図13を用いて、実施例2に係る公開鍵暗号通信システムによる処理を説明する。図13は、実施例2における公開鍵暗号通信処理の流れを示すシーケンス図である。なお、以下では、受信クライアント300が鍵ペアを更新して秘密鍵を管理するまでの段階(図13の(1)〜(5))、送信クライアント300が平文データを暗号化してサーバ400に送信するまでの段階(図13の(6)〜(11))、受信クライアント300がサーバ400から暗号データを受信して復号するまでの段階(図13の(12)〜(13))の3つの段階に分けて、実施例2に係る公開鍵暗号通信システムによる処理を説明する。
まず、受信クライアント300が鍵ペアを更新して秘密鍵を管理するまでの段階について説明すると、図13に示すように、実施例2における受信クライアント300は、鍵ペア生成部311において、ユーザ(公開鍵暗号通信を行いたい者)の公開鍵および秘密鍵からなる鍵ペアを生成(更新)する(図13の(1)を参照)。
次に、受信クライアント300は、識別子生成部313において、新たに更新された鍵ペアの公開鍵から公開鍵識別子を生成する(図13の(2)を参照)。
そして、受信クライアント300は、公開鍵送信部312において、新たに更新された鍵ペアの公開鍵を、ユーザを識別するためのユーザ識別子とともにサーバ400の公開鍵受信部411に送信し、公開鍵の保管を要求する(図13の(3)を参照)。
すると、サーバ400は、公開鍵受信部411において、受信クライアント300から公開鍵とともにユーザ識別子を受信し、これらを公開鍵保管部412に送信して、公開鍵とユーザ識別子とを対応づけて保管する(図13の(4)を参照)。
続いて、受信クライアント300は、秘密鍵保管部314において、新たに更新された鍵ペアの秘密鍵を含む複数の世代にわたる秘密鍵を保管するだけでなく、秘密鍵に対応づけて、秘密鍵とペアとなる公開鍵から生成された公開鍵識別子をさらに保管する(図13の(5)を参照)。
次に、送信クライアント300が平文データを暗号化してサーバ400に送信するまでの段階について説明すると、図13に示すように、実施例2における送信クライアント300は、公開鍵受信部331において、ユーザ(公開鍵暗号通信を行いたい者)の公開鍵を、ユーザ識別子を送信してサーバ400に要求する(図13の(6)を参照)。
そして、サーバ400は、公開鍵送信部413において、送信クライアント300から公開鍵送信要求(ユーザ識別子)を受け付け、これを公開鍵保管部412に通知し、公開鍵保管部412からユーザ識別子に対応づけられた公開鍵を受信して、送信クライアント300の公開鍵受信部331に送信する(図13の(7)を参照)。
続いて、送信クライアント300は、公開鍵受信部331において、ユーザの公開鍵をサーバ400から受信し、データ暗号化部333において、平文データをこの公開鍵で暗号化する(図13の(8)を参照)。
次に、送信クライアント300は、識別子生成部332において、サーバ400から受信した公開鍵から公開鍵識別子を生成する(図13の(9)を参照)。
そして、送信クライアント300は、データ送信部334において、データ暗号化部333において暗号化された暗号データを、公開鍵識別子とユーザ識別子とともにサーバ400の受信部421に送信する(図13の(10)を参照)。
すると、サーバ400は、データ受信部421において、平文データがいずれかの世代の公開鍵で暗号化された暗号データと公開鍵識別子とユーザ識別子とを送信クライアントのデータ送信部334から受信し、暗号データのファイル名と公開鍵識別子とユーザ識別子とを対応づけて保管する(図13の(11)を参照)。
次に、受信クライアント300がサーバ400から暗号データを受信して復号するまでの段階について説明すると、図13に示すように、受信クライアント300は、データ受信部321において、ユーザ識別子をサーバ400のデータ送信部423に通知することで、暗号データおよび公開鍵識別子を受信する(図13の(12)を参照)。
そして、受信クライアント300は、秘密鍵取得部322において、複数の世代の秘密鍵から公開鍵識別子に対応づけられた秘密鍵を取得してデータ復号部423に送信し、データ復号部423において、取得された秘密鍵で暗号データを復号する(図13の(13)を参照)。
[実施例2の効果]
上記してきたように、実施例2によれば、平文データを公開鍵で暗号化した暗号データを送信する送信端末と、暗号データを送信端末から受信して公開鍵とペアとなる秘密鍵で復号する受信端末とを含んで構成される公開鍵暗号通信システムであって、受信端末は、公開鍵および秘密鍵からなる鍵ペアが更新される度に、新たに更新された鍵ペアの秘密鍵を含む複数の世代にわたる秘密鍵を管理し、いずれかの世代の公開鍵によって暗号化された暗号データを送信端末から受信して、管理された複数の世代の秘密鍵から秘密鍵を取得して暗号データを復号し、送信端末は、平文データをいずれかの世代の公開鍵で暗号化した暗号データを受信端末に送信するので、公開鍵および秘密鍵の鍵ペアが更新される度に、古い世代の公開鍵(更新前の公開鍵)とペアで生成された古い世代の秘密鍵(更新前の秘密鍵)が廃棄されないことから、古い世代の公開鍵が利用されて暗号化された暗号データを復号することができ、さらに、秘密鍵の管理がユーザの手作業によって行われないことから、公開鍵暗号通信における利便性を維持することができ、また、ユーザによる操作ミスを原因として秘密鍵が漏洩または紛失されるリスクを回避することができ、これらの結果、公開鍵および秘密鍵の鍵ペアが随時更新される場合でも、秘密鍵の管理が簡易かつ安全な公開鍵暗号通信を実現することが可能になる。
また、実施例2によれば、受信端末は、秘密鍵に対応づけて、秘密鍵とペアとなる公開鍵から生成された公開鍵識別子をさらに管理し、公開鍵によって暗号化された暗号データとともに、公開鍵から生成された公開鍵識別子を送信端末からさらに受信して、管理された複数の世代の秘密鍵から公開鍵識別子に対応づけられた秘密鍵を取得して暗号データを復号し、送信端末は、公開鍵で暗号化した暗号データとともに、公開鍵から生成された公開鍵識別子を受信端末にさらに送信するので、公開鍵識別子の比較に基づいて公開鍵と秘密鍵との対応関係を短時間で確実に把握することから、本来不必要な復号(正しい復号結果を得られない復号)を発生させないことができる結果、公開鍵および秘密鍵の鍵ペアが随時更新される場合でも、秘密鍵の管理がより簡易かつ安全な公開鍵暗号通信を実現することが可能になる。
また、実施例2によれば、受信端末は、複数の世代にわたる秘密鍵を秘密鍵の更新に係る順番に基づく時系列に管理するので、鍵ペアの生成時刻などの順番に基づいて管理することから、鍵ペアの生成時刻などの順番に基づいた処理を行うことができる結果、公開鍵および秘密鍵の鍵ペアが随時更新される場合でも、秘密鍵の管理がより簡易かつ安全な公開鍵暗号通信を実現することが可能になる。
また、実施例2によれば、受信端末は、ひとつまたは複数個の秘密鍵を新たに管理する場合に、秘密鍵の更新に係る順番に基づく時系列で古い方からひとつまたは複数個の既に管理されている秘密鍵と置き換えて管理するので、複数の世代にわたる秘密鍵の新しい方を優先的に管理することから、暗号データを復号できる確率を高めることができる結果、公開鍵および秘密鍵の鍵ペアが随時更新される場合でも、秘密鍵の管理がより簡易かつ安全な公開鍵暗号通信を実現することが可能になる。
ところで、上記の実施例1では、受信クライアント100が、管理する複数の世代の秘密鍵の全てで復号し終えるまで、秘密鍵を順に取得して暗号データを復号する場合を説明し、上記の実施例2では、受信クライアント300が、秘密鍵とペアとなる公開鍵から生成された公開鍵識別子をさらに管理し、この公開鍵識別子に対応づけられた秘密鍵を取得して暗号データを復号する場合を説明したが、この発明はこれに限定されるものではなく、所定のアルゴリズムによって生成された鍵ペア特定情報とともに公開鍵を公開し、この鍵ペア特定情報に対応づけられた秘密鍵を取得して暗号データを復号する場合にも、この発明を同様に適用することができる。そこで、以下では、実施例3として、所定のアルゴリズムによって生成された鍵ペア特定情報とともに公開鍵を公開し、この鍵ペア特定情報に対応づけられた秘密鍵を取得して暗号データを復号する場合を説明する。
[実施例3に係る公開鍵暗号通信システムの概要および特徴]
まず最初に、図14を用いて、実施例3に係る公開鍵暗号通信システムの概要および特徴を説明する。図14は、実施例3に係る公開鍵暗号通信システムの概要および特徴を説明するための図である。なお、以下では、なお、受信クライアントが鍵ペアを更新して秘密鍵を管理するまでの段階、送信クライアントが平文データを暗号化してサーバに送信するまでの段階、および、受信クライアントがサーバから暗号データを受信して復号するまでの段階の3つの段階に分けて、実施例3に係る公開鍵暗号通信システムの主たる特徴を説明する。
まず、受信クライアントが鍵ペアを更新して秘密鍵を管理するまでの段階について説明すると、図14に示すように、実施例3における受信クライアントは、最初に、公開鍵および秘密鍵の鍵ペアを更新する(図14の(1)を参照)。ここで、実施例3において更新された鍵ペアは、3回目に生成された鍵ペア(第3世代の鍵ペア)であるので、公開鍵を「PubKey_A03」と表し、秘密鍵を「PrvKey_A03」と表すこととする。また、鍵ペア生成時刻を「T_A03」と表すこととする。次に、受信クライアントは、所定のアルゴリズムによって鍵ペア特定情報(B(PubKey_A03+T_A03))を生成する(図14の(2)を参照)。そして、受信クライアントは、サーバの保管し公開してもらうことを目的として、公開鍵(PubKey_A03)および鍵ペア特定情報(B(PubKey_A03+T_A03))をサーバに送信する(図14の(3)を参照)。すると、サーバは、受信クライアントから公開鍵(PubKey_A03)および鍵ペア特定情報(B(PubKey_A03+T_A03))を受信し、これを保管する(図14の(4)を参照)。
一方、実施例3における受信クライアントは、新たに更新された鍵ペアの秘密鍵を含む複数の世代にわたる秘密鍵を管理するだけでなく、秘密鍵に対応づけて、所定のアルゴリズムによって生成され、秘密鍵とペアとなる公開鍵とともに公開されている鍵ペア特定情報をさらに管理する(図14の(5)を参照)。
続いて、送信クライアントが平文データを暗号化してサーバに送信するまでの段階について説明すると、実施例3における送信クライアントは、最初に、公開鍵を公開するサーバに対して、暗号データを送信した通信相手が公開している公開鍵を要求する。ここで、暗号データを送信したい通信相手は「A」であるので、Aの公開鍵を要求する(図14の(6)を参照)。
次に、送信クライアントは、受信クライアントAの第3世代の公開鍵(PubKey_A03)および鍵ペア特定情報(B(PubKey_A03+T_A03))をサーバから受信する(図14の(7)を参照)。そして、送信クライアントは、平文データを第3世代の公開鍵で暗号化する(図14の(8)を参照)。続いて、送信クライアントは、公開鍵で暗号化した暗号データとともに、鍵ペア特定情報をサーバに送信する(図14の(9))。すると、サーバは、送信クライアントから送信された暗号データと鍵ペア特定情報とを保管する(図14の(10)を参照)。
続いて、受信クライアントがサーバから暗号データを受信して復号するまでの段階について説明すると、実施例3における受信クライアントは、第3世代の公開鍵によって暗号化された暗号データとともに、鍵ペア特定情報(B(PubKey_A03+T_A03))を、送信クライアントからサーバ経由で受信する(図14の(11)を参照)。なお、サーバ経由で受信するとは、送信クライアントから送信された暗号データおよび鍵ペア特定情報をサーバが保管し、サーバが保管する受信クライアント宛の暗号データおよび鍵ペア特定情報を受信クライアントが受信することである。
そして、受信クライアントは、管理された複数の世代の秘密鍵から秘密鍵を取得して、受信した暗号データを復号する(図14の(12)を参照)。ここで、実施例3における受信クライアントは、管理された複数の秘密鍵から、サーバから受信した鍵ペア特定情報に対応づけられた秘密鍵を取得して暗号データを復号する。すなわち、サーバから受信した鍵ペア特定情報は「B(PubKey_A03+T_A03)」であるので、鍵ペア特定情報(B(PubKey_A03+T_A03))に対応づけられた秘密鍵(PrvKey_A03)を取得して暗号データを復号する。こうして、第3世代の秘密鍵とペアとなる公開鍵とともに公開されている鍵ペア特定情報に対応づけられた秘密鍵を取得して復号するので、鍵ペア特定情報の比較に基づいて公開鍵と秘密鍵との対応関係を短時間で確実に把握することから、本来不必要な復号(正しい復号結果を得られない復号)を発生させないことができる。
ところで、上記では、第3世代の公開鍵(PubKey_A03)によって暗号化された暗号データを復号する場合を説明したが、例えば、送信クライアントが過去に入手した第1世代の公開鍵(PubKey_A01)もしくは第2世代の公開鍵(PubKey_A02)で平文データを暗号化した場合であっても、同様に、本来不必要な復号を発生させずに正しい復号結果を得ることができる。すなわち、実施例3に係る受信クライアントは、公開鍵によって暗号化された暗号データとともに、公開鍵とともに公開されている鍵ペア特定情報をさらに受信して、鍵ペア特定情報に対応づけられた秘密鍵を取得して暗号データを復号するので、受信クライアントは、第1世代の公開鍵(PubKey_A01)によって暗号化された暗号データとともに、鍵ペア特定情報(B(PubKey_A01+T_A01))をさらに受信して、鍵ペア特定情報(B(PubKey_A01+T_A01))に対応づけられた秘密鍵(PrvKey_A01)を取得して暗号データを復号するので、本来不必要な復号を発生させずに正しい復号結果を得ることができ、また、受信クライアントは、第2世代の公開鍵(PubKey_A02)によって暗号化された暗号データとともに、鍵ペア特定情報(B(PubKey_A02+T_A02))をさらに受信して、鍵ペア特定情報(B(PubKey_A02+T_A02))に対応づけられた秘密鍵(PrvKey_A02)を取得して暗号データを復号するので、本来不必要な復号を発生させずに正しい復号結果を得ることができる。
このようなことから、実施例3に係る公開鍵暗号通信システムは、公開鍵および秘密鍵の鍵ペアが随時更新される場合でも、秘密鍵の管理がより簡易かつ安全な公開鍵暗号通信を実現することが可能になる。
[実施例3に係る公開鍵暗号通信システムの構成]
続いて、図15〜図19を用いて、実施例3に係る公開鍵暗号通信システムの構成を説明する。図15は、実施例3における受信クライアントおよび送信クライアントの構成を示すブロック図であり、図16は、実施例3における秘密鍵保管部を説明するための図であり、図17は、実施例3におけるサーバの構成を示すブロック図であり、図18は、実施例3における公開鍵保管部を説明するための図であり、図19は、実施理3におけるデータ保管部を説明するための図である。なお、以下では、実施例1に係る公開鍵暗号通信システムと同様に構成される点については、簡単に説明することとする。
[クライアントの構成]
まず、図15に示すように、実施例3におけるクライアント500は、秘密鍵管理部510と、データ受信復号部520と、データ暗号化送信部530とから主に構成される。
秘密鍵管理部510は、公開鍵および公開鍵および秘密鍵からなる鍵ペアが更新される度に、新たに更新された鍵ペアの秘密鍵を含む複数の世代にわたる秘密鍵を管理する手段であり、特にこの発明に密接に関連するものとしては、図15に示すように、鍵ペア生成部511と、公開鍵送信部512と、鍵ペア特定情報生成部513と、秘密鍵保管部514とを備える。なお、秘密鍵管理部510は、特許請求の範囲に記載の「秘密鍵管理手段」に対応する。
かかる秘密鍵管理部510のなかで、鍵ペア生成部511は、ユーザ(公開鍵暗号通信を行いたい者)の公開鍵および秘密鍵からなる鍵ペアを生成(更新)する手段である。具体的には、鍵ペア生成部511は、ユーザの公開鍵および秘密鍵からなる鍵ペアを生成(更新)し、生成した公開鍵を公開鍵送信部512に送信し、生成した秘密鍵を秘密鍵保管部513に送信するが、その際に、鍵ペア特定情報を生成するための鍵ペア属性情報を、鍵ペア特定情報生成部513に送信する。
公開鍵送信部512は、鍵ペアが更新される度に、新たに更新された鍵ペアの公開鍵をサーバ600に送信する手段である。具体的には、公開鍵送信部512は、鍵ペア生成部511で鍵ペアが生成(更新)される度に、新たに更新されて公開鍵送信部512に送信された鍵ペアの公開鍵を、鍵ペア特定情報生成部513で生成された鍵ペア特定情報とともに、後述するサーバ600の公開鍵受信部611に送信する。
鍵ペア特定情報生成部513は、秘密鍵とペアとなる公開鍵とともに公開される鍵ペア特定情報を、所定のアルゴリズムによって生成する手段である。具体的には、鍵ペア特定情報生成部513は、鍵ペア生成部511で鍵ペアが生成(更新)される度に、新たに更新されて鍵ペア特定情報生成部513に送信された鍵ペア属性情報を用いて、鍵ペア特定情報を生成し、秘密鍵保管部514に送信する。例えば、実施例3における鍵ペア特定情報生成部513は、公開鍵と鍵ペアの生成時刻情報とを鍵ペア属性情報として受け取り、公開鍵と生成時刻情報とを連結した情報に対してBase64符号化を行い、鍵ペア特定情報(B(PubKey_A03+T_A03))とする。なお、実施例3では、公開鍵と生成時刻情報とを連結した情報に対してBase64符号化を行って鍵ペア特定情報を生成する場合を説明したが、この発明はこれに限定されるものではなく、秘密鍵の識別子を生成して鍵ペア特定情報とする場合や、鍵ペア作成日時を表す文字列を用いて鍵ペア特定情報を生成する場合や、公開鍵と秘密鍵とを連結した情報に対して非可逆的な演算を施して得られるデータ列などを鍵ペア特定情報として生成する場合など、いずれでもよい。なお、このような鍵ペア特定情報を用いることは、サービスレベルやシステム負荷軽減などの各種の観点に基づき、鍵ペア特定情報の生成アルゴリズムを柔軟に選択できるという利点をもたらす。
秘密鍵保管部514は、鍵ペアが更新される度に、新たに更新された鍵ペアの秘密鍵を含む複数の世代にわたる秘密鍵を保管するだけでなく、秘密鍵に対応づけて、秘密鍵とペアとなる公開鍵とともに公開される鍵ペア特定情報をさらに管理する手段である。具体的には、秘密鍵保管部514は、鍵ペア生成部511で鍵ペアが生成(更新)される度に、新たに更新されて秘密鍵保管部514に送信された鍵ペアの秘密鍵を含む複数の世代にわたる秘密鍵を保管するが、その際に、秘密鍵に対応づけて、鍵ペア特定情報生成部513から送信された鍵ペア特定情報をさらに保管する。例えば、実施例3における秘密鍵保管部514は、鍵ペア生成部511から、秘密鍵を時系列に保管するための時系列情報として鍵ペアの生成時刻情報を、秘密鍵とともに受信し、図16に示すように、この生成時刻情報と秘密鍵と鍵ペア特定情報とを対応づけて保管する。
ここで、図15に戻ると、データ受信復号部520は、いずれかの世代の公開鍵によって暗号化された暗号データを送信クライアント500から受信して、秘密鍵管理部510によって管理された複数の世代の秘密鍵から秘密鍵を取得して暗号データを復号する手段であり、特にこの発明に密接に関連するものとしては、図15に示すように、データ受信部521と、秘密鍵取得部522と、データ復号部523とを備える。なお、データ受信復号部520は、特許請求の範囲に記載の「データ受信復号手段」に対応する。
かかるデータ受信復号部520のなかで、データ受信部521は、いずれかの世代の公開鍵によって暗号化された暗号データを送信クライアント500から受信するだけでなく、公開鍵によって暗号化された暗号データとともに、公開鍵とともに公開された鍵ペア特定情報を送信クライアント500からさらに受信する手段である。具体的には、データ受信部521は、後述するサーバ600のデータ保管部622に保管されたいずれかの世代の公開鍵によって暗号化された暗号データとともに、公開鍵から生成された公開鍵識別子を後述するサーバ600のデータ送信部623経由で送信クライアント500から受信し、暗号データをデータ復号部523に送信し、鍵ペア特定情報を秘密鍵取得部322に送信する。例えば、実施例3におけるデータ受信部521は、ユーザを識別するためのユーザ識別子(例えば、UserAなど)をサーバ600のデータ送信部623に通知することで、ユーザA宛の暗号データとともに鍵ペア特定情報(例えば、B(PubKey_A03+T_A03))を受信し、暗号データをデータ復号部523に送信し、鍵ペア特定情報(例えば、B(PubKey_A03+T_A03))を秘密鍵取得部522に送信する。
秘密鍵取得部522は、複数の世代の秘密鍵から鍵ペア特定情報に対応づけられた秘密鍵を取得する手段である。具体的には、秘密鍵取得部522は、秘密鍵保管部514によって保管された複数の世代の秘密鍵から、データ受信部521から送信された鍵ペア特定情報(例えば、B(PubKey_A03+T_A03))に対応づけられた秘密鍵を取得し、データ復号部523に送信する。例えば、実施例3における秘密鍵取得部522は、データ受信部521から公開鍵識別子としてB(PubKey_A03+T_A03)を受信すると、B(PubKey_A03+T_A03)をキーにして秘密鍵を検索し、B(PubKey_A03+T_A03)に対応づけられた秘密鍵(Prvkey_A03)を取得し、データ復号部523に送信する。
データ復号部523は、取得された秘密鍵で暗号データを復号する手段である。具体的には、データ復号部523は、秘密鍵取得部522によって取得された秘密鍵で、データ受信部521から送信された暗号データを復号する。
データ暗号化送信部530は、平文データをいずれかの世代の公開鍵で暗号化した暗号データを受信クライアント500に送信する手段であり、特にこの発明に密接に関連するものとしては、図15に示すように、公開鍵受信部531と、データ暗号化部532と、データ送信部533とを備える。なお、データ暗号化送信部530は、特許請求の範囲に記載の「データ暗号化送信手段」に対応する。
かかるデータ暗号化送信部530のなかで、公開鍵受信部531は、実施例1における公開鍵受信部131と同様、ユーザ(公開鍵暗号通信を行いたい者)の公開鍵をサーバ600に要求してサーバ600から受信する手段である。また、データ暗号化部532は、実施例1におけるデータ暗号化部132と同様、平文データをいずれかの世代の公開鍵で暗号化する手段である。
データ送信部533は、いずれかの世代の公開鍵で暗号化された暗号データをサーバ600に送信する手段である。具体的には、データ送信部533は、データ暗号化部532で暗号化された暗号データを受信し、公開鍵受信部531から鍵ペア特定情報を受信し、後述するサーバ600のデータ受信部621に送信する。
[サーバの構成]
続いて、図17に示すように、実施例3におけるサーバ600は、公開鍵管理部610と、データ送受信部620とから主に構成される。
公開鍵管理部610は、受信クライアント500において公開鍵および秘密鍵からなる鍵ペアが更新される度に、新たに更新された鍵ペアの公開鍵を受信クライアント500から受信して管理する手段であり、特にこの発明に密接に関連するものとしては、図17に示すように、公開鍵受信部611と、公開鍵保管部612と、公開鍵送信部613とを備える。
かかる公開鍵管理部610のなかで、公開鍵受信部611は、実施例1における公開鍵受信部211と同様、受信クライアント500において公開鍵および秘密鍵からなる鍵ペアが更新される度に、新たに更新された鍵ペアの公開鍵および鍵ペア特定情報を受信クライアント500から受信する手段である。
公開鍵保管部612は、受信クライアント500から受信された公開鍵を保管する手段である。例えば、実施例3における公開鍵保管部612は、公開鍵受信部611によって受信クライアント500から受信された公開鍵(例えば、PubKey_A03など)と鍵ペア特定情報(例えば、B(PubKey_A03+T_A03))とユーザ識別子(例えば、UserAなど)とを公開鍵受信部611から受信し、図18に示すように、公開鍵(PubKey_A03)と鍵ペア特定情報(例えば、B(PubKey_A03+T_A03))とユーザ識別子(UserA)とを対応づけて保管する。また、公開鍵送信部613は、実施例1における公開鍵送信部213と同様、送信クライアント500から、ユーザ(公開鍵暗号通信を行いたい者)の公開鍵送信要求を受け付け、送信クライアント500に送信する手段である。
ここで、図17に戻ると、データ送受信部620は、いずれかの世代の公開鍵で暗号化された暗号データを送信クライアント500から受信し、受信クライアント500に送信する手段であり、特にこの発明に密接に関連するものとしては、図17に示すように、データ受信部621と、データ保管部622と、データ送信部623と、暗号データファイル部624とを備える。
かかるデータ送受信部620のなかで、データ受信部621は、平文データがいずれかの世代の公開鍵で暗号化された暗号データを送信クライアント500から受信する手段である。具体的には、データ受信部621は、平文データがいずれかの世代の公開鍵で暗号化された暗号データおよび鍵ペア特定情報を送信クライアント500のデータ送信部533から受信し、暗号データに係る情報および鍵ペア特定情報をデータ保管部622に送信する。
データ保管部622は、送信クライアント500から受信した暗号データに係る情報および鍵ペア特定情報を保管する手段である。具体的には、データ保管部622は、データ受信部621が送信クライアント500から受信した暗号データに係る情報および鍵ペア特定情報を保管し、データ送信部623に送信する。例えば、実施例3におけるデータ保管部622は、データ受信部621から暗号データのファイル名とユーザ識別子と鍵ペア特定情報とを受信し、図19に示すように、ファイル名とユーザ識別子と鍵ペア特定情報とを対応づけて保管する。そして、データ送信部623から受信したユーザ識別子をキーにしてファイル名を検索し、ユーザ識別子に対応づけられた暗号データのファイル名を取得し、データ送信部623に、ファイル名および鍵ペア特定情報を送信する。
データ送信部623は、サーバ600において保管される暗号データおよび鍵ペア特定情報を、受信クライアント500に送信する手段である。具体的には、データ送信部623は、データ保管部622から受信した暗号データに係る情報に基づいて、暗号データファイル部624に保管する暗号データファイルおよび鍵ペア特定情報を、受信クライアント500のデータ受信部521に送信する。例えば、実施例3におけるデータ送信部623は、受信クライアント500のデータ受信部521から受信したユーザ識別子をデータ保管部622に送信し、データ保管部622からユーザ識別子に対応する暗号データファイル名を受信し、暗号データファイル部624からこの暗号データファイル名に対応する暗号データファイルを取得して、さらに、データ保管部622から送信された鍵ペア特定情報とともに、受信クライアント500のデータ受信部521に送信する。また、暗号データファイル部624は、実施例1における暗号データファイル部224と同様、送信クライアント500から受信した暗号データを保管する手段である。
[実施例3に係る公開鍵暗号通信システムによる処理]
次に、図20を用いて、実施例3に係る公開鍵暗号通信システムによる処理を説明する。図20は、実施例3における公開鍵暗号通信処理の流れを示すシーケンス図である。なお、以下では、受信クライアント500が鍵ペアを更新して秘密鍵を管理するまでの段階(図20の(1)〜(5))、送信クライアント500が平文データを暗号化してサーバ400に送信するまでの段階(図20の(6)〜(10))、受信クライアント500がサーバ600から暗号データを受信して復号するまでの段階(図20の(11)〜(12))の3つの段階に分けて、実施例3に係る公開鍵暗号通信システムによる処理を説明する。
まず、受信クライアント500が鍵ペアを更新して秘密鍵を管理するまでの段階について説明すると、図20に示すように、実施例3における受信クライアント500は、鍵ペア生成部511において、ユーザ(公開鍵暗号通信を行いたい者)の公開鍵および秘密鍵からなる鍵ペアを生成(更新)する(図20の(1)を参照)。
次に、受信クライアント500は、識別子生成部513において、新たに更新された鍵ペアの公開鍵から鍵ペア特定情報を生成する(図20の(2)を参照)。
そして、受信クライアント500は、公開鍵送信部512において、新たに更新された鍵ペアの公開鍵および鍵ペア特定情報を、ユーザを識別するためのユーザ識別子とともにサーバ600の公開鍵受信部611に送信し、公開鍵および鍵ペア特定情報の保管を要求する(図20の(3)を参照)。
すると、サーバ600は、公開鍵受信部611において、受信クライアント500から公開鍵および鍵ペア特定情報とともにユーザ識別子を受信し、これらを公開鍵保管部612に送信して、公開鍵と鍵ペア特定情報とユーザ識別子とを対応づけて保管する(図20の(4)を参照)。
続いて、受信クライアント500は、秘密鍵保管部514において、新たに更新された鍵ペアの秘密鍵を含む複数の世代にわたる秘密鍵を保管するだけでなく、秘密鍵に対応づけて、秘密鍵とペアとなる公開鍵とともに公開される鍵ペア特定情報をさらに保管する(図20の(5)を参照)。
次に、送信クライアント500が平文データを暗号化してサーバ600に送信するまでの段階について説明すると、図20に示すように、実施例3における送信クライアント500は、公開鍵受信部531において、ユーザ(公開鍵暗号通信を行いたい者)の公開鍵を、ユーザ識別子を送信してサーバ600に要求する(図20の(6)を参照)。
そして、サーバ600は、公開鍵送信部613において、送信クライアント500から公開鍵送信要求(ユーザ識別子)を受け付け、これを公開鍵保管部612に通知し、公開鍵保管部612からユーザ識別子に対応づけられた公開鍵および鍵ペア特定情報を受信して、送信クライアント500の公開鍵受信部531に送信する(図20の(7)を参照)。
続いて、送信クライアント500は、公開鍵受信部531において、ユーザの公開鍵および鍵ペア特定情報をサーバ600から受信し、データ暗号化部532において、平文データをこの公開鍵で暗号化する(図20の(8)を参照)。
そして、送信クライアント500は、データ送信部533において、データ暗号化部532において暗号化された暗号データを、鍵ペア特定情報とユーザ識別子とともにサーバ600の受信部621に送信する(図20の(9)を参照)。
すると、サーバ600は、データ受信部621において、平文データがいずれかの世代の公開鍵で暗号化された暗号データと鍵ペア特定情報とユーザ識別子とを送信クライアントのデータ送信部534から受信し、暗号データのファイル名と鍵ペア特定情報とユーザ識別子とを対応づけて保管する(図20の(10)を参照)。
次に、受信クライアント500がサーバ600から暗号データを受信して復号するまでの段階について説明すると、図20に示すように、受信クライアント500は、データ受信部521において、ユーザ識別子をサーバ600のデータ送信部623に通知することで、暗号データおよび鍵ペア特定情報を受信する(図20の(11)を参照)。
そして、受信クライアント500は、秘密鍵取得部522において、複数の世代の秘密鍵から鍵ペア特定情報に対応づけられた秘密鍵を取得してデータ復号部523に送信し、データ復号部523において、取得された秘密鍵で暗号データを復号する(図20の(12)を参照)。
[実施例3の効果]
上記してきたように、実施例3によれば、平文データを公開鍵で暗号化した暗号データを送信する送信端末と、暗号データを送信端末から受信して公開鍵とペアとなる秘密鍵で復号する受信端末とを含んで構成される公開鍵暗号通信システムであって、受信端末は、公開鍵および秘密鍵からなる鍵ペアが更新される度に、新たに更新された鍵ペアの秘密鍵を含む複数の世代にわたる秘密鍵を管理し、いずれかの世代の公開鍵によって暗号化された暗号データを送信端末から受信して、管理された複数の世代の秘密鍵から秘密鍵を取得して暗号データを復号し、送信端末は、平文データをいずれかの世代の公開鍵で暗号化した暗号データを受信端末に送信するので、公開鍵および秘密鍵の鍵ペアが更新される度に、古い世代の公開鍵(更新前の公開鍵)とペアで生成された古い世代の秘密鍵(更新前の秘密鍵)が廃棄されないことから、古い世代の公開鍵が利用されて暗号化された暗号データを復号することができ、さらに、秘密鍵の管理がユーザの手作業によって行われないことから、公開鍵暗号通信における利便性を維持することができ、また、ユーザによる操作ミスを原因として秘密鍵が漏洩または紛失されるリスクを回避することができ、これらの結果、公開鍵および秘密鍵の鍵ペアが随時更新される場合でも、秘密鍵の管理が簡易かつ安全な公開鍵暗号通信を実現することが可能になる。
また、実施例3によれば、公開鍵は、所定のアルゴリズムによって生成された鍵ペア特定情報によって特定され、鍵ペア特定情報とともに公開されるものであって、受信端末は、秘密鍵に対応づけて、秘密鍵とペアとなる公開鍵とともに公開されている鍵ペア特定情報をさらに管理し、公開鍵によって暗号化された暗号データとともに、公開鍵とともに公開されている鍵ペア特定情報を送信端末からさらに受信して、管理された複数の世代の秘密鍵から鍵ペア特定情報に対応づけられた秘密鍵を取得して暗号データを復号し、送信端末は、公開鍵で暗号化した暗号データとともに、公開鍵とともに公開されている鍵ペア特定情報を受信端末にさらに送信するので、鍵ペア特定情報の比較に基づいて公開鍵と秘密鍵との対応関係を短時間で確実に把握することから、本来不必要な復号(正しい復号結果を得られない復号)を発生させないことができ、また、鍵ペア特定情報が公開鍵とともに公開されることから、送信端末は鍵ペア特定情報を生成せずに鍵ペア特定情報を利用することができ、これらの結果、公開鍵および秘密鍵の鍵ペアが随時更新される場合でも、秘密鍵の管理がより簡易かつ安全な公開鍵暗号通信を実現することが可能になる。
また、実施例3によれば、受信端末は、複数の世代にわたる秘密鍵を秘密鍵の更新に係る順番に基づく時系列に管理するので、鍵ペアの生成時刻などの順番に基づいて管理することから、鍵ペアの生成時刻などの順番に基づいた処理を行うことができる結果、公開鍵および秘密鍵の鍵ペアが随時更新される場合でも、秘密鍵の管理がより簡易かつ安全な公開鍵暗号通信を実現することが可能になる。
また、実施例3によれば、受信端末は、ひとつまたは複数個の秘密鍵を新たに管理する場合に、秘密鍵の更新に係る順番に基づく時系列で古い方からひとつまたは複数個の既に管理されている秘密鍵と置き換えて管理するので、複数の世代にわたる秘密鍵の新しい方を優先的に管理することから、暗号データを復号できる確率を高めることができる結果、公開鍵および秘密鍵の鍵ペアが随時更新される場合でも、秘密鍵の管理がより簡易かつ安全な公開鍵暗号通信を実現することが可能になる。
ところで、これまで実施例1〜3に係る公開鍵暗号通信システムについて説明したが、この発明は上記した実施例以外にも種々の異なる形態にて実施されてよいものである。そこで、以下では、実施例4に係る公開鍵暗号通信システムとして、異なる実施例を説明する。
[秘密鍵の管理]
上記の実施例では、複数の世代にわたる秘密鍵を、秘密鍵の更新に係る順番に基づく時系列に管理する場合を説明したが、この発明はこれに限定されるものではなく、秘密鍵を時系列に管理しない場合や、秘密鍵をその他の順番に基づいて管理する場合などにも、この発明を同様に適用することができる。
また、上記の実施例では、ひとつまたは複数個の秘密鍵を新たに管理する場合に、秘密鍵の更新にかかる順番に基づく時系列で古い方からひとつまたは複数個の既に管理されている秘密鍵と置き換えて管理する場合を説明したが、この発明はこれに限定されるものではなく、生成(更新)された秘密鍵を全て管理する場合などにも、この発明を同様に適用することができる。
また、上記の実施例では、秘密鍵保管部としてオリジナルに作成したテーブルで保管する場合を説明したが、この発明はこれに限定されるものではなく、例えば、Java(登録商標)言語でシステムを実装する際には、Java(登録商標)2 KeyStoreのような汎用ライブラリを利用する場合などにも、この発明を同様に適用することができる。
[鍵ペア等生成方法]
また、上記の実施例では、受信クライアントにおいて鍵ペアを生成(更新)する方法を説明したが、この発明はこれに限定されるものではなく、別途、鍵ペアを生成(更新)する機能を有する端末が生成(更新)した鍵ペアを、ICカード等の媒体によって受信クライアントに入力させる方法など、受信クライアントが鍵ペアを保有することができる方法であれば、いずれでもよい。
また、上記の実施例では、送信クライアントにおいて公開鍵識別子を生成する方法を説明したが、この発明はこれに限定されるものではなく、別途、公開鍵識別子を生成する機能を有する端末が生成した公開鍵識別子を、通信等の手段によって送信クライアントに入力させる方法など、送信クライアントが公開鍵識別子を暗号データとともに送信することができる方法であれば、いずれでもよい。
また、上記の実施例では、受信クライアントにおいて鍵ペア特定情報を生成する方法を説明したが、この発明はこれに限定されるものではなく、別途、鍵ペア特定情報を生成する機能を有する端末が生成した鍵ペア特定情報を、通信等の手段によって受信クライアントに入力させる方法など、鍵ペア特定情報が公開鍵とともに公開される方法であれば、いずれでもよい。
[システム構成等]
また、上記の実施例では、公開鍵暗号通信システムの構成として、送信クライアントと、受信クライアントと、サーバとで構成されるシステムを説明したが、この発明はこれに限定されるものではなく、送信端末と受信端末とが直接的に公開鍵その他のデータを送受信するシステムなどにも、この発明を同様に適用することができる。
また、上記の実施例では、送信クライアントと受信クライアントとを同じ端末で実現する(ひとつの端末が送信クライアントの機能および受信クライアントの機能の双方を備える)場合を説明したが、この発明はこれに限定されるものではなく、送信クライアントの機能のみを有する送信クライアントと、受信クライアントの機能のみを有する受信クライアントとで実現する場合にも、この発明を同様に適用することができる。
また、上記の実施例では、クライアントとサーバとの間の通信プロトコルとして、HTTP/1.1とHTTPS(SSLv3)とを組み合わせて使用する場合を説明したが、この発明はこれに限定されるものではなく、HTTP/1.1の代用としてHTTP/1.0を用いる場合や、SSLv3の代用としてTLS(Transport Layer Security)バージョン1.0を用いる場合や、通信路暗号化を行わない場合など、いずれでもよい。
また、上記の実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、CPUおよび当該CPUにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
なお、上記の実施例では、この発明を実現する各装置(例えば、受信クライアント、送信クライアントなど)を機能面から説明したが、各装置の各機能はパーソナルコンピュータやワークステーションなどのコンピュータにプログラムを実行させることによって実現することもできる。すなわち、上記の実施例で説明した各種の処理手順は、あらかじめ用意されたプログラムをコンピュータ上で実行することによって実現することができる。そして、これらのプログラムは、インターネットなどのネットワークを介して配布することができる。さらに、これらのプログラムは、ハードディスク、フレキシブルディスク(FD)、CD−ROM、MO、DVDなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。つまり、例を挙げれば、実施例1〜3に示したような公開鍵暗号通信プログラムを格納したCD−ROM(装置ごとに別個のCD−ROMであってもよい)を配布し、このCD−ROMに格納されたプログラムを各コンピュータが読み出して実行するようにしてもよい。
以上のように、この発明に係る公開鍵暗号通信システム、公開鍵暗号通信方法および公開鍵暗号通信プログラムは、平文データを公開鍵で暗号化した暗号データを送信する送信端末と、当該暗号データを当該送信端末から受信して前記公開鍵とペアとなる秘密鍵で復号する受信端末とを含んで構成される公開鍵暗号通信システムに有用であり、特に、公開鍵および秘密鍵の鍵ペアが随時更新される場合でも、秘密鍵の管理が簡易かつ安全な公開鍵暗号通信を実現することに適する。
実施例1に係る公開鍵暗号通信システムの概要および特徴を説明するための図である。 実施例1における受信クライアントおよび送信クライアントの構成を示すブロック図である。 実施例1における秘密鍵保管部を説明するための図である。 実施例1におけるサーバの構成を示すブロック図である。 実施例1における公開鍵保管部を説明するための図である。 実施例1におけるデータ保管部を説明するための図である。 実施例1における公開鍵暗号通信処理の流れを示すシーケンス図である。 実施例2に係る公開鍵暗号通信システムの概要および特徴を説明するための図である。 実施例2における受信クライアントおよび送信クライアントの構成を示すブロック図である。 実施例2における秘密鍵保管部を説明するための図である。 実施例2におけるサーバの構成を示すブロック図である。 実施例2におけるデータ保管部を説明するための図である。 実施例2における公開鍵暗号通信処理の流れを示すシーケンス図である。 実施例3に係る公開鍵暗号通信システムの概要および特徴を説明するための図である。 実施例3における受信クライアントおよび送信クライアントの構成を示すブロック図である。 実施例3における秘密鍵保管部を説明するための図である。 実施例3におけるサーバの構成を示すブロック図である。 実施例3における公開鍵保管部を説明するための図である。 実施例3におけるデータ保管部を説明するための図である。 実施例3における公開鍵暗号通信処理の流れを示すシーケンス図である。
符号の説明
100 クライアント
110 秘密鍵管理部
111 鍵ペア生成部
112 公開鍵送信部
113 秘密鍵保管部
120 データ受信復号部
121 データ受信部
122 秘密鍵取得部
123 データ復号部
130 データ暗号化部
131 公開鍵受信部
132 データ暗号化部
133 データ送信部
200 サーバ
210 公開鍵管理部
211 公開鍵受信部
212 公開鍵保管部
213 公開鍵送信部
220 データ送受信部
221 データ受信部
222 データ保管部
223 データ送信部
224 暗号データファイル部
300 クライアント
310 秘密鍵管理部
320 データ受信復号部
330 データ暗号化部
400 サーバ
410 公開鍵管理部
420 データ送受信部
500 クライアント
510 秘密鍵管理部
520 データ受信復号部
530 データ暗号化部
600 サーバ
610 公開鍵管理部
620 データ送受信部

Claims (6)

  1. データを公開鍵で暗号化した暗号データを送信する送信端末と、当該暗号データを当該送信端末から受信して前記公開鍵とペアとなる秘密鍵で復号する受信端末と、サーバとを含んで構成される公開鍵暗号通信システムであって、
    前記受信端末は、
    前記公開鍵および前記秘密鍵からなる鍵ペアが更新される度に、新たに更新された鍵ペアの公開鍵を前記サーバに送信する公開鍵送信手段と、
    前記鍵ペアが更新される度に、新たに更新された鍵ペアの公開鍵から公開鍵識別子を生成する受信側識別子生成手段と、
    前記鍵ペアが更新される度に、新たに更新された鍵ペアの秘密鍵を含む複数の世代にわたる秘密鍵を管理するとともに、当該秘密鍵に対応づけて、前記受信側識別子生成手段によって生成された公開鍵識別子をさらに管理する秘密鍵管理手段と、
    いずれかの世代の公開鍵によって暗号化された暗号データと、当該公開鍵から生成された公開鍵識別子とを前記送信端末から受信して、前記秘密鍵管理手段によって管理された複数の世代の秘密鍵から当該公開鍵識別子に対応づけられた秘密鍵を取得して当該暗号データを復号するデータ受信復号手段とを備え、
    前記サーバは、
    前記受信端末から送信された公開鍵を受信する公開鍵受信手段と、
    前記公開鍵受信手段によって受信された公開鍵のうち最新の公開鍵のみを管理する公開鍵管理手段と、
    前記送信端末からの要求に応じて、前記公開鍵管理手段によって管理されている最新の公開鍵を当該送信端末に送信する公開鍵送信手段とを備え、
    前記送信端末は、
    データを送信する都度、送信先の受信端末に対応する公開鍵を前記サーバに要求し、当該公開鍵を前記サーバから受信する送信側公開鍵受信手段と、
    前記送信側公開鍵受信手段によって受信された最新の公開鍵でデータを暗号化するデータ暗号化手段と、
    前記送信側公開鍵受信手段によって受信された最新の公開鍵から公開鍵識別子を生成する送信側識別子生成手段と、
    前記データ暗号化手段によって暗号化された暗号データと、前記送信側識別子生成手段によって生成された公開鍵識別子とを当該受信端末に送信するデータ送信手段と、
    を備えたことを特徴とする公開鍵暗号通信システム。
  2. 前記秘密鍵管理手段は、前記複数の世代にわたる秘密鍵を当該秘密鍵の更新に係る順番に基づく時系列に管理することを特徴とする請求項1に記載の公開鍵暗号通信システム。
  3. 前記秘密鍵管理手段は、ひとつまたは複数個の秘密鍵を新たに管理する場合に、当該秘密鍵の更新に係る順番に基づく時系列で古い方からひとつまたは複数個の既に管理されている秘密鍵と置き換えて管理することを特徴とする請求項1または2に記載の公開鍵暗号通信システム。
  4. データを公開鍵で暗号化した暗号データを送信する送信端末と、当該暗号データを当該送信端末から受信して前記公開鍵とペアとなる秘密鍵で復号する受信端末と、サーバとを含んで構成される公開鍵暗号通信方法であって、
    前記受信端末は、
    前記公開鍵および前記秘密鍵からなる鍵ペアが更新される度に、新たに更新された鍵ペアの公開鍵を前記サーバに送信する公開鍵送信工程と、
    前記鍵ペアが更新される度に、新たに更新された鍵ペアの公開鍵から公開鍵識別子を生成する受信側識別子生成工程と、
    前記鍵ペアが更新される度に、新たに更新された鍵ペアの秘密鍵を含む複数の世代にわたる秘密鍵を管理するとともに、当該秘密鍵に対応づけて、前記受信側識別子生成工程によって生成された公開鍵識別子をさらに管理する秘密鍵管理工程と、
    いずれかの世代の公開鍵によって暗号化された暗号データと、当該公開鍵から生成された公開鍵識別子とを前記送信端末から受信して、前記秘密鍵管理工程によって管理された複数の世代の秘密鍵から当該公開鍵識別子に対応づけられた秘密鍵を取得して当該暗号データを復号するデータ受信復号工程とを含み、
    前記サーバは、
    前記受信端末から送信された公開鍵を受信する公開鍵受信工程と、
    前記公開鍵受信工程によって受信された公開鍵のうち最新の公開鍵のみを管理する公開鍵管理工程と、
    前記送信端末からの要求に応じて、前記公開鍵管理工程によって管理されている最新の公開鍵を当該送信端末に送信する公開鍵送信工程とを含み、
    前記送信端末は、
    データを送信する都度、送信先の受信端末に対応する公開鍵を前記サーバに要求し、当該公開鍵を前記サーバから受信する送信側公開鍵受信工程と、
    前記送信側公開鍵受信工程によって受信された最新の公開鍵でデータを暗号化するデータ暗号化工程と、
    前記送信側公開鍵受信工程によって受信された最新の公開鍵から公開鍵識別子を生成する送信側識別子生成工程と、
    前記データ暗号化工程によって暗号化された暗号データと、前記送信側識別子生成工程によって生成された公開鍵識別子とを当該受信端末に送信するデータ暗号化送信工程と、
    を含んだことを特徴とする公開鍵暗号通信方法。
  5. 公開鍵および秘密鍵からなる鍵ペアが更新される度に、新たに更新された鍵ペアの公開鍵を、最新の公開鍵のみを管理するサーバに送信する公開鍵送信手段と、
    前記鍵ペアが更新される度に、新たに更新された鍵ペアの公開鍵から公開鍵識別子を生成する受信側識別子生成手段と、
    前記鍵ペアが更新される度に、新たに更新された鍵ペアの秘密鍵を含む複数の世代にわたる秘密鍵を管理するとともに、当該秘密鍵に対応づけて、前記受信側識別子生成手段によって生成された公開鍵識別子をさらに管理する秘密鍵管理手段と、
    前記サーバから取得された最新の公開鍵で暗号化された暗号データと、当該公開鍵から生成された公開鍵識別子とを他のクライアント端末から受信して、前記秘密鍵管理手段によって管理された複数の世代の秘密鍵から当該公開鍵識別子に対応づけられた秘密鍵を取得して当該暗号データを復号するデータ受信復号手段と、
    データを送信する都度、送信先の受信端末に対応する公開鍵を前記サーバに要求し、当該公開鍵を前記サーバから受信する公開鍵受信手段と、
    前記公開鍵受信手段によって受信された最新の公開鍵でデータを暗号化するデータ暗号化手段と、
    前記公開鍵受信手段によって受信された最新の公開鍵から公開鍵識別子を生成する送信側識別子生成手段と、
    前記データ暗号化手段によって暗号化された暗号データと、前記送信側識別子生成手段によって生成された公開鍵識別子とを他のクライアント端末に送信するデータ送信手段と、
    を備えたことを特徴とするクライアント端末。
  6. 請求項5に記載のクライアント端末としてコンピュータを機能させることを特徴とするクライアントプログラム。
JP2006083466A 2006-03-24 2006-03-24 公開鍵暗号通信システム、公開鍵暗号通信方法、クライアント端末およびクライアントプログラム Active JP4629602B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2006083466A JP4629602B2 (ja) 2006-03-24 2006-03-24 公開鍵暗号通信システム、公開鍵暗号通信方法、クライアント端末およびクライアントプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2006083466A JP4629602B2 (ja) 2006-03-24 2006-03-24 公開鍵暗号通信システム、公開鍵暗号通信方法、クライアント端末およびクライアントプログラム

Publications (2)

Publication Number Publication Date
JP2007259279A JP2007259279A (ja) 2007-10-04
JP4629602B2 true JP4629602B2 (ja) 2011-02-09

Family

ID=38633027

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006083466A Active JP4629602B2 (ja) 2006-03-24 2006-03-24 公開鍵暗号通信システム、公開鍵暗号通信方法、クライアント端末およびクライアントプログラム

Country Status (1)

Country Link
JP (1) JP4629602B2 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6576699B2 (ja) 2015-06-12 2019-09-18 コニカミノルタ株式会社 暗号化システム、更新方法、および更新プログラム
JP7076218B2 (ja) * 2017-02-07 2022-05-27 セイコーインスツル株式会社 タイム計測システム、第1通信装置のプログラム、および第2通信装置のプログラム

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000115153A (ja) * 1998-09-30 2000-04-21 Fujitsu Ltd セキュリティ方法及びセキュリティ装置
JP2000259748A (ja) * 1999-03-09 2000-09-22 Ntt Data Corp 電子マネーシステム、鍵切替方法及び記録媒体
JP2000349749A (ja) * 1999-06-03 2000-12-15 Mitsubishi Electric Corp 秘密鍵管理装置及びコンピュータ読み取り可能な記録媒体
JP2002217896A (ja) * 2001-01-23 2002-08-02 Matsushita Electric Ind Co Ltd 暗号通信方法およびゲートウエイ装置
JP2005514831A (ja) * 2001-12-21 2005-05-19 クゥアルコム・インコーポレイテッド 簡易音声認証方法および装置
JP2005522937A (ja) * 2002-04-05 2005-07-28 アイパス・インコーポレーテッド コンピュータ・ネットワークでセキュリティ情報を変更する方法とシステム
JP2006173804A (ja) * 2004-12-13 2006-06-29 Ntt Docomo Inc 端末装置、外部補助装置、通信システム及び通信方法
JP2006174519A (ja) * 2006-03-17 2006-06-29 Fujitsu Ltd セキュリティ方法及びセキュリティ装置
JP2006222483A (ja) * 2005-02-08 2006-08-24 Murata Mach Ltd 電子メール通信装置

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5341426A (en) * 1992-12-15 1994-08-23 Motorola, Inc. Cryptographic key management apparatus and method
JPH1020779A (ja) * 1996-07-08 1998-01-23 Hitachi Inf Syst Ltd 公開鍵暗号方式における鍵変更方法
JPH11265349A (ja) * 1998-03-17 1999-09-28 Toshiba Corp コンピュータシステムならびに同システムに適用される機密保護方法、送受信ログ管理方法、相互の確認方法および公開鍵世代管理方法

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000115153A (ja) * 1998-09-30 2000-04-21 Fujitsu Ltd セキュリティ方法及びセキュリティ装置
JP2000259748A (ja) * 1999-03-09 2000-09-22 Ntt Data Corp 電子マネーシステム、鍵切替方法及び記録媒体
JP2000349749A (ja) * 1999-06-03 2000-12-15 Mitsubishi Electric Corp 秘密鍵管理装置及びコンピュータ読み取り可能な記録媒体
JP2002217896A (ja) * 2001-01-23 2002-08-02 Matsushita Electric Ind Co Ltd 暗号通信方法およびゲートウエイ装置
JP2005514831A (ja) * 2001-12-21 2005-05-19 クゥアルコム・インコーポレイテッド 簡易音声認証方法および装置
JP2005522937A (ja) * 2002-04-05 2005-07-28 アイパス・インコーポレーテッド コンピュータ・ネットワークでセキュリティ情報を変更する方法とシステム
JP2006173804A (ja) * 2004-12-13 2006-06-29 Ntt Docomo Inc 端末装置、外部補助装置、通信システム及び通信方法
JP2006222483A (ja) * 2005-02-08 2006-08-24 Murata Mach Ltd 電子メール通信装置
JP2006174519A (ja) * 2006-03-17 2006-06-29 Fujitsu Ltd セキュリティ方法及びセキュリティ装置

Also Published As

Publication number Publication date
JP2007259279A (ja) 2007-10-04

Similar Documents

Publication Publication Date Title
US11647007B2 (en) Systems and methods for smartkey information management
US20220006624A1 (en) User Terminal, Permission Information Management Method, and Permission Information Management Program
RU2718689C2 (ru) Управление конфиденциальной связью
US8649522B2 (en) Electronic data communication system
Callas et al. OpenPGP message format
Housley Cryptographic message syntax
KR100568233B1 (ko) 인증서를 이용한 기기 인증 방법 및 상기 방법을 이용하여기기 인증을 수행하는 디지털 컨텐츠 처리 기기
JP2011097453A (ja) メッセージ送信および受信方法
JPWO2010123122A1 (ja) 暗号システム、暗号通信方法、暗号化装置、鍵生成装置、復号装置、コンテンツサーバ装置、プログラム、記憶媒体
US10116442B2 (en) Data storage apparatus, data updating system, data processing method, and computer readable medium
JP2020532177A (ja) データの高度なセキュリティ、高速暗号化および、伝送のためのコンピュータ実装システムおよび方法
Callas et al. RFC 4880: OpenPGP message format
TW202232913A (zh) 共享金鑰產生技術
JPH11317734A (ja) デ―タの暗号化復号化方法および、それを用いたネットワ―クシステム
CN115913672A (zh) 电子档案加密传输方法、系统、终端设备及计算机介质
CN108200085B (zh) 一种数据分发、转发方法及装置
JP4629602B2 (ja) 公開鍵暗号通信システム、公開鍵暗号通信方法、クライアント端末およびクライアントプログラム
JP3984570B2 (ja) 署名/検証システムにおける鍵管理サーバおよび検証装置を制御するプログラム
Housley RFC2630: Cryptographic Message Syntax
Yasmin et al. Decentralized Entrance Power with Secret Endorsement of Data Stored in Clouds
CN113918971A (zh) 基于区块链的消息传输方法、装置、设备及可读存储介质
JP7043203B2 (ja) 暗号化装置、復号装置、暗号化システム、暗号化方法及び暗号化プログラム
CN108306880B (zh) 一种数据分发、转发方法及装置
JP4104315B2 (ja) 鍵管理システム、鍵管理装置、情報暗号化装置、情報復号化装置、およびプログラムを記憶した記憶媒体
JP2016131271A (ja) サーバ、サービス方法

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100615

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100806

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100824

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20101021

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: 20101109

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20101111

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20131119

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4629602

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

S531 Written request for registration of change of domicile

Free format text: JAPANESE INTERMEDIATE CODE: R313531

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350