JP3919700B2 - 暗号システム及びその暗号文処理方法 - Google Patents
暗号システム及びその暗号文処理方法 Download PDFInfo
- Publication number
- JP3919700B2 JP3919700B2 JP2003162813A JP2003162813A JP3919700B2 JP 3919700 B2 JP3919700 B2 JP 3919700B2 JP 2003162813 A JP2003162813 A JP 2003162813A JP 2003162813 A JP2003162813 A JP 2003162813A JP 3919700 B2 JP3919700 B2 JP 3919700B2
- Authority
- JP
- Japan
- Prior art keywords
- ciphertext
- user
- key
- decryption
- identification information
- 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.)
- Expired - Lifetime
Links
Images
Description
【０００１】
【発明の属する技術分野】
本発明は、暗号システム及びその暗号文処理方法に関する。
【０００２】
【従来の技術】
従来の一般的な暗号技術としては、共通鍵暗号方式と呼ばれる技術がある。共通鍵暗号方式では、データを暗号化する際、並びに、この暗号化されたデータ（暗号文）を復号して平文にする際に、同一の（共通の）鍵、すなわち共通鍵を用いる。このため、データの送受信者は、鍵を第三者に知られないようにする必要がある。この方式は、暗号化に要する処理量が少ないため、大きなデータを暗号化するのに適している。しかし、複数の相手に同一の共通鍵を用いるわけにはいかないため、送信相手毎に異なる共通鍵を生成し、管理する必要がある。このため、送信先が多くなるほど鍵の管理が大変となる。また、共通鍵暗号方式は、不特定多数を相手にする場合には適さないという欠点もある。
【０００３】
このような共通鍵暗号方式における問題を解決するための技術としては、公開鍵暗号方式と呼ばれる技術がある。公開鍵暗号方式では、暗号化用と復号用に異なる鍵を生成し、一方を公開鍵、他方を秘密鍵として使用する。公開鍵暗号方式の場合の暗号化アルゴリズムでは、一方の鍵で暗号化した暗号文は、対となっている他方の鍵でしか復号できない。公開鍵暗号方式では、送信者は受信者の公開鍵で平文を暗号化し、受信者は自己の秘密鍵で暗号文を平文に復号する。
【０００４】
また、公開鍵暗号方式では、暗号文は公開鍵で復号できないのはもちろんのこと、公開鍵から秘密鍵を生成できないようになっている。また、送信相手毎に鍵を生成する必要はなく、利用者は一対の鍵（公開鍵と秘密鍵）を準備すればよく、不特定多数の相手を対象にする場合に適しているといえる。しかし、非対称鍵のビット長や暗号化の対象となるデータが大きくなると暗号化や復号に時間がかかるため、共通鍵暗号方式と比べると、大量のデータの暗号化には適していないといえる。
【０００５】
このような公開鍵暗号方式における問題を解決するための技術としては、ハイブリッド暗号方式と呼ばれるものがある。ハイブリッド暗号方式は、共通鍵暗号方式と公開鍵暗号方式の長所を生かすとともに、それぞれの欠点を補うために、これら２つの暗号方式を組み合わせて暗号化する技術である。すなわち、ハイブリッド暗号方式においては、データを送信者が生成した共通鍵で暗号文とし、この暗号文に、該共通鍵を受信者の公開鍵で暗号化したものを添付して送信する。受信者は、送信された共通鍵を受信者の秘密鍵で復号し、さらに、この復号した共通鍵で暗号文を復号する。ハイブリッド暗号方式の代表的な技術としては、ＰＧＰやＳ／ＭＩＭＥ等がある。
【０００６】
しかしながら、ハイブリッド暗号方式においては、利用者が自己の秘密鍵を喪失してしまうと、元の公開鍵で暗号化した暗号文を復号することができなくなるという問題がある。すなわち、秘密鍵を喪失した場合に新しい秘密鍵及び公開鍵（鍵ペア）を生成したとしても、この新しい鍵ペアでは、元の公開鍵で暗号化した暗号文は復号することができないこととなる。
【０００７】
このようなハイブリッド暗号方式における問題に鑑み、利用者が自己の鍵を喪失したとしても、大きな問題が生じないようにできる暗号システムが考えられている（例えば、特許文献１参照）。
【０００８】
以下、図１４乃至図１７を参照して、この暗号システムについて説明する。
【０００９】
この暗号システムは、図１４に示すように、ネットワークを介して相互に接続される管理サーバ１００と利用者側操作端末１０１とを備えて構成されている。
【００１０】
この暗号システムでは、各利用者は、先ず、自己のＩＤと公開鍵を管理サーバ１０１に登録する。すなわち、例えば利用者Ａが登録を行うには、先ず、秘密鍵（Ａ）及び公開鍵（Ａ）の鍵ペアを生成し、このうち公開鍵（Ａ）を図１４に示すようにＩＤ（Ａ）とともに管理サーバ１００に送信する。
【００１１】
すると、管理サーバ１００は、公開鍵（Ａ）と対応する固有鍵（Ａ）を生成する。ここで、固有鍵（Ａ）は共通鍵である。
【００１２】
この固有鍵（Ａ）に対しては、他の固有鍵に対して所望の対応付けがなされる。すなわち、図１５に示すように、固有鍵（Ａ）に対しては、例えば、利用者Ｂの公開鍵（Ｂ）と対応する固有鍵（Ｂ）、利用者Ｃの公開鍵（Ｃ）と対応する固有鍵（Ｃ）、・・・等が、また、固有鍵（Ｂ）に対しては、例えば、固有鍵（Ａ）、固有鍵（Ｃ）、・・・等が、それぞれ一義的に対応付けられた状態で、管理サーバ１００が備える鍵管理データベース１００ａに登録される。
【００１３】
なお、別の種類の対応付けを要する場合には、利用者Ａは、新たな鍵ベア（秘密鍵（Ａ´）及び公開鍵（Ａ´））を生成し、このうち公開鍵（Ａ´）を管理サーバ１００に登録する必要がある。このため、例えば、図１６に示すように、利用者側操作端末（Ａ）１０１では、複数の鍵ペア（秘密鍵（Ａ）及び公開鍵（Ａ）、秘密鍵（Ａ´）及び公開鍵（Ａ´）、・・・）を保持する必要がある。
【００１４】
また、利用者Ａの登録がなされると、図１４に示すように、公開鍵（Ａ）で暗号化されたサーバの公開鍵（Ｓ）及び認証用の秘密データが、登録者である利用者Ａの利用者側操作端末（Ａ）に送信される。
【００１５】
次に、図１７を参照して、利用者からの復号要求について説明する。
【００１６】
ここでは、例えば、利用者Ａが暗号化した暗号文を、利用者Ｂが復号要求する例を説明する。
【００１７】
先ず、利用者Ａによる暗号化を説明する。この暗号化を行うには、先ず、利用者Ａは公開鍵（Ｓ）で秘密データを暗号化したものにＩＤ（Ａ）を付して管理サーバ１００に送信する。管理サーバ１００では、公開鍵（Ｓ）と対をなす秘密鍵（Ｓ）を用いて復号することにより秘密データを取り出し、この取り出した秘密データを管理サーバ１００側で保持している秘密データと照合することにより認証を行う。認証された場合は、ＩＤ（Ａ）と対応する（公開鍵（Ａ）と対応する）鍵（固有鍵（Ａ）、固有鍵（Ｂ）、固有鍵（Ｃ）、・・・）を公開鍵（Ａ）で暗号化したものを利用者側操作端末（Ａ）に返送する。これにより利用者Ａは暗号化に用いる固有鍵（Ａ）を取得する。
【００１８】
次に、利用者Ａは、セッションキーを生成し、このセッションキーでデータを暗号化することにより暗号文１１０を生成し、更に、このセッションキーを固有鍵（Ａ）で暗号化することにより暗号部１１１を生成し、これら両暗号文１１０，１１１を利用者Ｂに送信する。
【００１９】
次に、利用者Ｂは、公開鍵（Ｓ）で秘密データを暗号化したものにＩＤ（Ｂ）を付して管理サーバ１００に送信する。管理サーバ１００では、秘密鍵（Ｓ）を用いて復号することにより秘密データを取り出し、この取り出した秘密データを管理サーバ１００側で保持している秘密データと照合することにより認証を行う。認証された場合は、ＩＤ（Ｂ）と対応する（公開鍵（Ｂ）と対応する）鍵（固有鍵（Ｂ）、固有鍵（Ａ）、固有鍵（Ｃ）、・・・）を公開鍵（Ｂ）で暗号化したものを利用者側操作端末（Ｂ）に返送する。これにより利用者Ｂは暗号文１１１の復号に用いる固有鍵（Ａ）を取得する。
【００２０】
よって、利用者Ｂは、固有鍵（Ａ）を用いて暗号文１１１を復号することによりセッションキーを取り出すことができ、このセッションキーを用いて暗号文１１０を復号することによりデータを取り出すことができる。
【００２１】
また、この暗号システムにおいては、各固有鍵を管理サーバで管理しておくので、利用者側で秘密鍵を喪失した場合にも救済措置をとることができる。つまり、秘密鍵を喪失した場合には、新たに登録を行い、該登録により新規に生成される固有鍵と、元々の秘密鍵（と対をなす公開鍵）と対応する固有鍵とを対応付けることにより、元々の秘密鍵の使用時に暗号化した暗号文も復号することができるようになる。
【００２２】
【特許文献１】
特開２００２−３１４５２７号公報
【００２３】
【発明が解決しようとする課題】
しかしながら、上記の特許文献１の技術では、管理サーバ１００が保有する固有鍵で暗号化鍵（セッションキー）を暗号化するようにしているため、以下のような問題点がある。
【００２４】
先ず、利用者は、データの暗号化の際に管理サーバ１００との間で通信を行って、固有鍵を取得する必要があるため、暗号化が面倒である。
【００２５】
しかも、取得した多くの鍵（鍵束）の中から所望の固有鍵を使い分ける必要があるという問題もある。
【００２６】
加えて、別の種類の対応付けを要する場合には、利用者は、複数の鍵ペア（例えば、秘密鍵（Ａ）及び公開鍵（Ａ）、秘密鍵（Ａ´）及び公開鍵（Ａ´）、・・・等）を保持する必要があり、しかも、このうち適当な鍵を使用する必要がある。つまり、例えば、会社組織などにおいて、固有鍵間の対応付けを組織毎に別個に施すような場合に、複数の組織に亘って役職を兼務するような利用者は、多くの鍵ペアを保持する必要があり不便となる。
【００２７】
本発明は、上記のような問題点を解決するためになされたもので、従来のハイブリッド暗号方式の欠点を解消しながらも、暗号化及び鍵管理を容易になし得、しかも、利用者は、１つの鍵ペアを保持するだけで足りる暗号システム及びその暗号文処理方法を提供することを目的とする。
【００２８】
【課題を解決するための手段】
上記課題を解決するため、本発明の暗号システムは、利用者からの復号要求に基づき暗号文を復号することが可能な管理装置を備える暗号システムであって、前記管理装置は、利用者として登録された複数人分の公開鍵を管理する鍵管理データベースと、前記鍵管理データベース内の公開鍵を用いた復号及び暗号化が実行可能な制御部と、を備え、前記制御部は、利用者からの復号要求として、他者の秘密鍵により暗号化された第１暗号文を当該利用者の秘密鍵で更に暗号化することにより生成された第２暗号文が該利用者から送信された場合に、前記第２暗号文を前記鍵管理データベース内の当該利用者の公開鍵を用いて復号することにより前記第１暗号文を取り出す第１暗号文取出工程と、前記第１暗号文取出工程により取り出した第１暗号文を前記鍵管理データベース内の前記他者の公開鍵を用いて復号する他者鍵使用復号工程と、前記他者鍵使用復号工程による復号結果を、当該利用者の公開鍵を用いて暗号化することにより第３暗号文を生成する第３暗号文生成工程と、をこの順に実行し、更に、前記第３暗号文生成工程により生成された第３暗号文を、前記復号要求を行った利用者に送信するように構成されていることを特徴としている。
【００２９】
本発明の暗号システムにおいては、前記鍵管理データベースは、各公開鍵を非公開に管理することが好ましい。
【００３０】
本発明の暗号システムにおいては、前記鍵管理データベースは、複数の利用者の公開鍵の各々を、各利用者の識別情報と対応付けて管理するものとし、利用者は、復号要求の際に、当該利用者の識別情報を前記第２暗号文に付して送信するものとし、前記制御部は、利用者からの復号要求がなされた場合に、該利用者より送信された識別情報と対応する公開鍵を、前記鍵管理データベースより取得して前記第１暗号文取出工程での復号に用いることが好ましい。
【００３１】
この場合、前記制御部は、前記第１暗号文取出工程にて復号を実行できるか否かにより利用者の認証を行うことが好ましい。
【００３２】
本発明の暗号システムにおいては、利用者は、復号要求の前に、予め前記第１暗号文及び前記他者の識別情報を取得しておくものとし、かつ、前記第２暗号文の生成は、当該利用者の秘密鍵により前記第１暗号文及び前記他者の識別情報をまとめて暗号化することで行うものとし、前記制御部は、前記第１暗号文取出工程にて前記第１暗号文及び前記他者の識別情報を取り出し、該取り出した識別情報と対応する公開鍵を前記鍵管理データベースより取得して前記他者鍵使用復号工程での復号に用いることが好ましい。
【００３３】
本発明の暗号システムにおいては、前記識別情報には、最終復号要求日時の記録が付されるようになっているとともに、前記管理装置は、各利用者の最終復号要求日時を管理するように構成され、前記制御部は、復号要求があった場合に、送信された識別情報に付された最終復号要求日時と、管理装置で管理している該当する最終復号要求日時と、の照合を行い、これらの日時が相違している場合には、復号要求を行った利用者に対し、該相違している旨の通知を行うことが好ましい。
【００３４】
本発明の暗号システムにおいては、前記管理装置は、復号に関する権限を利用者毎に設定可能に構成され、前記制御部は、復号要求があった場合に、前記第３暗号文を生成して利用者に送信するか否かの判断を、設定された権限に応じて行うことが好ましい。
【００３５】
この場合、前記管理装置は、復号に関する前記権限と各利用者との対応付けを管理する権限管理データベースを更に備えることが好ましい。
【００３６】
本発明の暗号システムにおいては、前記管理装置は、前記権限と各利用者との対応付けとして、複数種類の対応付けを設定可能であり、前記制御部は、復号要求の種類に応じて、何れかの対応付けに従って、前記第３暗号文を生成して利用者に送信するか否かの判断を行うことが好ましい。
【００３７】
この場合、前記複数種類の対応付けには、少なくとも、組織に応じた対応付けと、機密度に応じた対応付けと、が含まれていることが好ましい。
【００３８】
本発明の暗号システムにおいては、復号に関する権限の有効期限を設定可能であることが好ましい。
【００３９】
本発明の暗号システムにおいては、当該暗号システムの使用ポリシーを問答形式で作成可能であることが好ましい。
【００４０】
この場合、作成した使用ポリシーを出力可能或いは各利用者に送信可能であることが好ましい。
【００４１】
また、本発明の暗号文処理方法は、本発明の暗号システムを用いた暗号文処理方法であって、前記他者である第１利用者は、自己の秘密鍵を用いて前記第１暗号文を生成し、該生成した第１暗号文を前記利用者である第２利用者に取得可能な状態とさせ、続いて、前記第２利用者は、前記取得可能な状態とされた第１暗号文を取得し、該第１暗号文を自己の秘密鍵により更に暗号化して第２暗号文を生成し、該生成した第２暗号文を前記管理装置に送信し、続いて、前記制御部は、前記第１暗号文取出工程、前記他者鍵使用復号工程及び前記第３暗号文生成工程をこの順に実行し、更に、第３暗号文生成工程により生成された第３暗号文を、前記第２利用者により取得可能な状態とさせ、続いて、前記第２利用者は、前記第３暗号文を取得し、該第３暗号文を自己の秘密鍵により復号することにより、該復号結果を得ることを特徴としている。
【００４２】
また、本発明の暗号文処理方法は、本発明の暗号システムを用いた暗号文処理方法であって、前記他者である第１利用者は、自己の秘密鍵を用いて前記第１暗号文を生成し、該生成した第１暗号文を前記利用者である第２利用者に取得可能な状態とさせ、続いて、前記第２利用者は、前記取得可能な状態とされた第１暗号文を取得し、該第１暗号文を自己の秘密鍵により更に暗号化して第２暗号文を生成し、該生成した第２暗号文に自己の識別情報を付して前記管理装置に送信し、続いて、前記制御部は、前記第２利用者より送信された識別情報と対応する公開鍵を前記鍵管理データベースより取得し、該取得した公開鍵を用いて前記第２暗号文を復号することで前記第１暗号文取出工程を実行した後で、前記他者鍵使用復号工程及び前記第３暗号文生成工程をこの順に実行し、更に、第３暗号文生成工程により生成された第３暗号文を、前記第２利用者により取得可能な状態とさせ、続いて、前記第２利用者は、前記第３暗号文を取得し、該第３暗号文を自己の秘密鍵により復号することにより、該復号結果を得ることを特徴としている。
【００４３】
この場合、前記第１利用者は、前記第１暗号文及び自己の識別情報を第２利用者に取得可能な状態とさせ、前記第２利用者は、取得した前記第１暗号文及び前記第１利用者の識別情報を自己の秘密鍵によりまとめて暗号化することにより前記第２暗号文を生成し、前記制御部は、前記第１暗号文取出工程にて前記第１暗号文及び前記他者の識別情報を取り出し、該取り出した識別情報と対応する公開鍵を前記鍵管理データベースより取得して前記他者鍵使用復号工程での復号に用いることが好ましい。
【００４４】
また、本発明の暗号文処理方法においては、前記第１利用者は、使い捨て鍵を生成し、この使い捨て鍵によりデータを暗号化することで暗号化データを生成する一方で、自己の秘密鍵を用いて前記使い捨て鍵を暗号化することにより前記第１暗号文を生成し、これら生成した第１暗号文及び暗号化データを前記第２利用者に取得可能な状態とさせ、続いて、前記第２利用者は、前記取得可能な状態とされた第１暗号文及び暗号化データを取得し、このうち第１暗号文を自己の秘密鍵により更に暗号化して第２暗号文を生成し、該生成した第２暗号文を前記管理装置に送信し、続いて、前記制御部は、前記第１暗号文取出工程及び前記他者鍵使用復号工程をこの順に実行することにより前記使い捨て鍵を取り出し、この取り出した使い捨て鍵を、前記第３暗号文生成工程にて暗号化することで前記第３暗号文を生成し、この第３暗号文を、前記第２利用者により取得可能な状態とさせ、続いて、前記第２利用者は、前記第３暗号文を取得し、該第３暗号文を自己の秘密鍵により復号することにより前記使い捨て鍵を取り出し、この使い捨て鍵を用いて前記暗号化データを復号することにより、前記データを取り出すことが好ましい。
【００４５】
【発明の実施の形態】
以下、図面を参照して、本発明に係る実施の形態について説明する。
【００４６】
〔第１の実施形態〕
図１に示すように、第１の実施形態に係る暗号システム１は、利用者からの復号要求に基づき暗号文を復号することが可能な管理サーバ（管理装置）２と、各利用者（利用者Ａ、利用者Ｂ、利用者Ｃ、・・・）に割り当てられた利用者側操作端末３とを備えて構成され、これら利用者側操作端末３と管理サーバ２とはネットワーク４を介して相互に接続可能となっている。
【００４７】
図２に示すように、管理サーバ２は、各種処理を実行する制御部５と、各利用者の公開鍵を管理する鍵管理データベース６と、を備えている。
【００４８】
このうち、制御部５は、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）及びＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）を備えて構成されている。このうちＲＯＭには、当該暗号システム１における管理サーバ２用のプログラム（ソフトウェア）が記憶されている。また、ＣＰＵは、このＲＯＭに記憶されている各プログラムを実行することにより、各種処理を行う。また、ＲＡＭは、ＣＰＵの作業領域の他、各種データの一時的な記憶領域を備える。
【００４９】
なお、制御部５では、予め管理サーバ２の公開鍵（Ｓ）及び秘密鍵（Ｓ）の鍵ペアを生成し保存しておく。
【００５０】
他方、鍵管理データベース６は、図３に示すように、各利用者の公開鍵を、各利用者（利用者Ａ、利用者Ｂ、利用者Ｃ、・・・）のＩＤ（識別情報）と１対１で対応付けた状態で、非公開に保存（管理）する。つまり、各利用者は、各自で生成した公開鍵を、管理サーバ２に対してのみ公開し、その他（他の利用者）に対しては非公開とする。
【００５１】
また、各利用者側操作端末３は、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）及びＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）を備えて構成されている。このうちＲＯＭには、当該暗号システム１における利用者側操作端末３用のプログラム（ソフトウェア）が記憶されている。また、ＣＰＵは、このＲＯＭに記憶されている各プログラムを実行することにより、各種処理を行う。また、ＲＡＭは、ＣＰＵの作業領域の他、各種データの一時的な記憶領域を備える。
【００５２】
また、図４に示すように、各利用者側操作端末３には、例えば、予め管理サーバ２の公開鍵（Ｓ）が与えられ、記憶されているものとする。
【００５３】
次に、図５を参照して、利用者の（公開鍵の）登録について説明する。
【００５４】
利用者（例えば利用者Ａ）が登録を行う際には、先ず、利用者Ａの利用者側操作端末（Ａ）３にて、公開鍵（Ａ）及び秘密鍵（Ａ）の鍵ペアを生成し保存する（図４）。そして、このうち公開鍵（Ａ）は、そのコピーを管理サーバ２に登録する。この登録の際には、図５に示すように、管理サーバ２の公開鍵（Ｓ）で、利用者ＡのＩＤ（Ａ）及び公開鍵（Ａ）をまとめて暗号化した暗号文１１を、利用者側操作端末（Ａ）３より管理サーバ２に送信する。
【００５５】
すると、この暗号文１１の送信を、管理サーバ２の制御部５では登録要求として受け付け、暗号文１１を管理サーバ２の秘密鍵（Ｓ）で復号することによりＩＤ（Ａ）及び公開鍵（Ａ）を取り出し（平文にし）、この取り出したＩＤ（Ａ）と公開鍵（Ａ）とを、図３のように１対１で対応付けた状態で鍵管理データベース６に保存（登録）する。
【００５６】
つまり、同様の登録作業を各利用者が行うことにより、次第に鍵管理データベース６には利用者の公開鍵が蓄積される。
【００５７】
次に、図６乃至１２を参照して、利用者からの復号要求について説明する。
【００５８】
ここでは、例えば、利用者Ａ（第１利用者、他者）が自己の秘密鍵（Ａ）で暗号化した暗号文を、利用者Ｂ（第２利用者、利用者）が復号要求する例を説明する。
【００５９】
この場合の動作は概略的には図６に示すように、利用者側操作端末（Ａ）３での利用者Ａの作業（ステップＳ１）→利用者側操作端末（Ｂ）３での利用者Ｂの作業（ステップＳ２）→管理サーバ２（の制御部５）による処理（ステップＳ３）→利用者側操作端末（Ｂ）３での利用者Ｂの作業（ステップＳ４）の順に進行する。なお、このうちステップＳ１は、利用者Ａの作業に応じた利用者側操作端末（Ａ）３の処理であるとも言える。同様に、ステップＳ２、Ｓ４は、利用者Ｂの作業に応じた利用者側操作端末（Ｂ）３の処理であるともいえる。
【００６０】
次に、上記ステップＳ１〜Ｓ４について、それぞれ詳細に説明する。
【００６１】
先ず、ステップＳ１は、利用者Ａ（第１利用者）がデータを暗号化する工程である。
【００６２】
このステップＳ１では、図７に示すように、先ず、ステップＳ１１にて、セッションキー１０（使い捨て鍵）を生成する。なお、このセッションキー１０は、データを暗号化する都度、別個に生成する。
【００６３】
ステップＳ１１に続くステップＳ１２では、ステップＳ１１にて生成したセッションキー１０を用いてデータを暗号化することによって、暗号化データ１２を生成する。
【００６４】
ステップＳ１２に続くステップＳ１３では、先のステップＳ１１にて生成したセッションキー１０を、利用者Ａの秘密鍵（Ａ）で暗号化することによって、第１暗号文１３を生成する。なお、利用者側操作端末（Ａ）では、第１暗号文１３と暗号化データ１２とをひとまとめにして保持しておく。
【００６５】
ここで、このように暗号化を行う結果として得られる第１暗号文１３と暗号化データ１２は、公開鍵（Ａ）を用いることにより、順次、復号することができる。すなわち、公開鍵（Ａ）で第１暗号文１３を復号することによりセッションキー１０を取り出すことができ、このセッションキー１０を用いて暗号化データ１２を復号することによりデータ１６を取り出すことができる。つまり、ここでの暗号化鍵は、利用者Ａの秘密鍵（Ａ）であるといえる。
【００６６】
また、このように第１暗号文１３及び暗号化データ１２を生成する際には、利用者側操作端末（Ａ）と管理サーバ２との間で通信を行う必要がない。つまり、本実施形態の場合、暗号化の際には利用者が管理サーバ２と通信する必要がない。
【００６７】
ステップＳ１３に続くステップＳ１４では、ステップＳ１３にて生成した第１暗号文１３と、ステップＳ１２にて生成した暗号化データ１２と、利用者ＡのＩＤ（Ａ）と、を利用者Ｂの利用者側操作端末（Ｂ）３に対し、例えばメールで送信する。
【００６８】
次に、ステップＳ２では、図８に示すように、先ず、ステップＳ２１にて、利用者側操作端末（Ｂ）が、第１暗号文１３、暗号化データ１２及びＩＤ（Ａ）を受信（取得）する。
【００６９】
なお、ここでは、第１暗号文１３、暗号化データ１２及びＩＤ（Ａ）をメール送信により利用者側操作端末（Ａ）から利用者側操作端末（Ｂ）に移動させる例を説明するが、メール送信以外でも、例えば、一旦管理サーバ２に登録（アップ）したものを、利用者側操作端末（Ａ）で取得するようにしても良い。
【００７０】
ステップＳ２１に続くステップＳ２２では、第１暗号文１３、暗号化データ１２及びＩＤ（Ａ）のうち、第１暗号文１３とＩＤ（Ａ）を、まとめて秘密鍵（Ｂ）で暗号化する。これにより、第２暗号文１４を生成する。ここで、セッションキー１０は、秘密鍵（Ａ）と秘密鍵（Ｂ）とで２重に暗号化されていることになる。
【００７１】
ステップＳ２２に続くステップＳ２３では、ステップＳ２１にて生成した第２暗号文１４に利用者ＢのＩＤ（Ｂ）を付して管理サーバ２に送信する。なお、本実施形態の場合、このように第２暗号文１４に自己のＩＤ（Ｂ）を付して管理サーバ２に送信することを「復号要求」ということとする。
【００７２】
次に、ステップＳ３では、図９に示すように、先ず、ステップＳ３１にて、管理サーバ２が、第２暗号文１４及びＩＤ（Ｂ）を受信し、該受信することで復号要求を受け付ける。
【００７３】
ステップＳ３１に続くステップＳ３２では、制御部５はＩＤ（Ｂ）と対応する鍵、すなわち公開鍵（Ｂ）を鍵管理データベース６内より取得する。
【００７４】
ステップＳ３２に続くステップＳ３３では、制御部５はステップＳ３２にて取得した公開鍵（Ｂ）で第２暗号文１４を復号することにより、第１暗号文１３とＩＤ（Ａ）を取り出す（第１暗号文取出工程）。ここで、制御部５は、この第１暗号文取出工程にて復号を実行できるか否かにより利用者の認証を行う。また、復号を実行できたか否かの判定は、復号の前後でデータが変化したか否かを判定することにより行う。
【００７５】
ステップＳ３３に続くステップＳ３４では、制御部５は取り出したＩＤすなわちＩＤ（Ａ）と対応する鍵、つまり公開鍵（Ａ）を鍵管理データベース６内より取得する。
【００７６】
ステップＳ３４に続くステップＳ３５では、制御部５はステップＳ３４にて取得した公開鍵（Ａ）で第１暗号文１３を復号することにより、セッションキー１０を取り出す（他者鍵使用復号工程）。つまり、公開鍵（Ｂ）による復号と、公開鍵（Ａ）による復号とを順に行うことにより、秘密鍵（Ａ）と秘密鍵（Ｂ）とで２重に暗号化されたセッションキー１０を取り出すことができる。
【００７７】
ステップＳ３５に続くステップＳ３６では、制御部５はステップＳ３５にて取り出したセッションキー１０を、復号要求者である利用者Ｂの公開鍵（Ｂ）で暗号化することにより第３暗号文１５を生成する（第３暗号文生成工程）。
【００７８】
ステップＳ３６に続くステップＳ３７では、制御部５はステップＳ３６にて生成した第３暗号文１５を、復号要求者である利用者Ｂの利用者側操作端末（Ｂ）３に送信する。
【００７９】
次に、ステップＳ４では、図１０に示すように、先ず、ステップＳ４１にて、利用者側操作端末（Ｂ）が第３暗号文１５を受信する。
【００８０】
ステップＳ４１に続くステップＳ４２では、第３暗号文１５を秘密鍵（Ｂ）で復号することにより、セッションキー１０を取り出す。
【００８１】
ステップＳ４２に続くステップＳ４３では、ステップＳ４２にて取り出したセッションキー１０で、先のステップＳ２１にて受信した暗号化データ１２を復号することにより、データ１６を取り出すことができる。
【００８２】
以上のような第１の実施形態によれば、暗号化鍵に利用者の秘密鍵を用いるとともに、管理サーバ２側で利用者の公開鍵を管理しているので、利用者が秘密鍵を喪失したとしても、管理サーバ２側では復号することが可能である。従って、利用者が新たな鍵ペア（秘密鍵及び公開鍵）を生成し、登録すれば、鍵の喪失前に暗号化した暗号文も問題なく取り出すことができる。つまり、従来のハイブリッド暗号方式の欠点を解消することができる。
【００８３】
また、従来技術におけるような固有鍵を用いる必要が無いため、図１７に示すような複雑な手順を経る必要がなく、図６に示すような簡略な手順で暗号化及び復号化を行うことができる。特に、暗号化の際には、管理サーバ２と通信を行う必要がない。しかも、利用者は自己の秘密鍵を１つだけ持っていれば良い。
【００８４】
なお、本実施形態の暗号システムは、例えば、企業における情報管理に適用することができる。この場合、利用者は個々の社員に該当する。
【００８５】
〔第２の実施形態〕
次に、本発明に係る第２の実施形態を説明する。
【００８６】
第２の実施形態では、管理サーバ２は、復号に関する権限を利用者毎に設定可能に構成され、制御部５は、復号要求があった場合に、第３暗号文１５を生成して利用者（復号要求者）に送信するか否かの判断を、設定された権限に応じて行う。
【００８７】
また、本実施形態の場合、復号に関する権限と各利用者との対応付けを管理するために、管理サーバ２は、図１１に示すように、権限管理データベース７を更に備える。すなわち、権限管理データベース７には、復号に関する権限と各利用者との対応付けを記憶保持している。
【００８８】
また、管理サーバ２は、復号に関する権限と各利用者との対応付けとして、複数種類の対応付けを設定可能であり、制御部５は、復号要求の種類に応じて、何れかの対応付けに従って、第３暗号文１５を生成して利用者に送信するか否かの判断を行う。
【００８９】
ここで、本実施形態の場合、復号に関する権限と各利用者との複数種類の対応付けには、組織に応じた対応付けと、機密度に応じた対応付けと、が含まれている。ここで、機密度とは、例えば、極秘、○○部外秘、社外秘或いは○○プロジェクト外秘などのように、守秘程度或いは守秘範囲に応じた機密度を意味する。すなわち、権限管理データベース７は、例えば、図１２に示すように、各機密度に対して各利用者（各ＩＤで管理している）の復号権限の有無を確認できるように、対応付けを保持している。
【００９０】
このように機密度に応じた対応付けを施す場合には、例えば、暗号化の際に、機密度を特定するための情報（ラベル）を、例えばセッションキー１０に付しておく。従って、制御部５では、復号要求があった際に、セッションキー１０に付されたラベルに基づき権限管理データベース７に保持された対応付けを参照することにより、復号要求者が復号権限を有する者であるか否かを判定する。
【００９１】
具体的には、例えば、○○プロジェクト外の利用者が復号要求を行った場合に、セッションキー１０に付されたラベルが○○プロジェクト外秘であった際には、制御部５は、第３暗号文１５を生成して利用者（復号要求者）に送信する処理は実行せず、利用者（の利用者側操作端末３）に対し、例えば、「あなたは今回要求した復号の権限を持っていません」との通知を行う。
【００９２】
このように、第２の実施形態では、鍵の管理（鍵管理データベース６が関連する）と、復号権限の管理（権限管理データベース７が関連する）を分離して行う。
【００９３】
また、例えば、人事異動などにより組織の所属が変わったり、或いは、所属は変わらないでも、新規のプロジェクトのメンバーに選任された場合など、復号に関する権限と各利用者との対応付けが変化したら、その都度、暗号システム１の管理者が権限管理データベース７の記憶内容を更新だけで（設定変更を行う）と良く、利用者が新たな鍵ペアを生成したりする必要はない。
【００９４】
さらに、本実施形態では、例えば、復号に関する権限の有効期限を設定可能となっている。つまり、管理者による設定時に、有効期限を例えば６ヶ月とした場合には、設定時から６ヶ月経過したときに、管理者が設定変更を行うことなく、制御部５の制御により自動的に設定内容を更新して権限を無効とさせる。
【００９５】
また、例えば、退職などの場合には、退職者の公開鍵は鍵管理データベース６に引き続き保存したままで、退職者の権限を無効とするだけで良い。なお、無効とするためには、例えば、権限管理データベース７における該当する利用者の欄に無効の旨を示すビットを立てると良い。この場合、制御部５は、復号要求があった際に、無効のビットが立っているか否かの判定を行うことにより、第３暗号文１５を生成して利用者に送信するか否かの判断を行う。つまり、例えば、無効のビットが立っていれば、第３暗号文１５を生成して利用者に送信する処理は実行しない。
【００９６】
また、復号権限だけでなく、暗号権限についても、同様に管理することが好ましい。このように暗号権限も管理することにより、権限規定に基づかないで各利用者が勝手に暗号化を実行してしまうことを防止できる。
【００９７】
ここで、本実施形態の暗号システムにおいては、管理者による設定（復号権限、暗号権限など）自体が、当該暗号システムの使用ポリシーとなる。そこで、図１３に示すように、管理サーバ２は、設定された仕様ポリシー８を、所定のフォーマットで出力（プリントアウト）、或いは、各利用者側操作端末３に送信（配布）することが可能となっている。
【００９８】
また、仕様ポリシーの設定は、少なくとも一部の項目については、問答形式で実行することが可能に構成されていることが好ましい。具体的には、例えば、モード選択画面にて設定ボタンを選択操作するとウィザードが起動して設定可能モードに移行する。この設定可能モードでは、例えば、「Ｑ．どの組織に適用しますか？」、「Ｑ．責任者は誰ですか？」、「Ｑ．極秘とはどのような意味ですか？」或いは「Ｑ．○○プロジェクト外秘とはどのような意味ですか？」との管理サーバ２からの問いに対し、管理者は、対応する入力箇所に必要な入力事項を入力することで、該当する項目の設定（仕様ポリシーの設定）を行うことができる。
【００９９】
ここで、管理者（管理者は利用者でもある）の秘密鍵は、例えば、一般の利用者の秘密鍵とは異なり、管理サーバ２を直接操作することが可能であるか、或いは、管理者の利用者側操作端末３より管理サーバ２に接続して該管理サーバ２内の設定操作を行うことが可能な管理者鍵として機能するようになっている。
【０１００】
さらに、このように、管理者の秘密鍵を管理者鍵として利用する場合に、いわゆるダブルロック方式を適用すれば、セキュリティー性を高めることができる。
【０１０１】
また、例えば、不正に利用者の秘密鍵及びＩＤを入手した者が、復号要求を行った場合には、そのことを正規の利用者に通知できるような構成とすることも好ましい。この構成を実現するためには、ＩＤには、最終復号要求日時（最終ログイン日時）の記録が付されるようになっているとともに、管理サーバ２は、各利用者の最終復号要求日時を管理（保存）するように構成されていれば良い。つまり、復号要求があった場合には、制御部５は受信したＩＤの最終復号要求日時を更新する。そして、第３暗号文１５を復号要求者に送信する際には、最終復号要求日時が更新済みのＩＤを該第３暗号文１５に添付する。さらに、利用者側操作端末３では、自己で保持していた既存のＩＤを、管理サーバ２より送信された新規のＩＤに更新する。また、制御部５は、復号要求があった場合に、送信されたＩＤに付された最終復号要求日時と、管理サーバ２で管理している該当する最終復号要求日時と、の照合を行い、これらの日時が相違している場合には、復号要求を行った利用者に対し、該相違している旨の通知を行うように構成されている。なお、この通知としては、例えば「サーバに記録された最終時刻とＩＤファイルに記載された最終時刻が異なります。不正に使用された可能性があるので管理者に報告してください。」との通知を行う。
【０１０２】
なお、本実施形態に係る暗号システム１は、企業内における情報管理だけでなく、例えば、電子政府、電子自治体或いは金融機関等にも好適に適用することができる。
【０１０３】
また、利用者側操作端末３は、例えば、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）からなることを好ましい例とするが、これに限らず、例えば、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）等の携帯情報端末からなることとしても良い。
【０１０４】
さらに、管理サーバ２の鍵管理データベース６或いは権限管理データベース７は、管理サーバ２に組み付けの記憶媒体により構成されているのであっても良いが、管理サーバ２に対し着脱自在な記憶媒体により構成することも好ましく、このように着脱自在に構成することにより、例えば、データベースを取り外して金庫内に保管したりすることもでき、セキュリティー管理を一層厳格に行うことができる。
【０１０５】
【発明の効果】
本発明によれば、暗号化鍵に利用者の秘密鍵を用いるとともに、管理サーバ側で利用者の公開鍵を管理しているので、利用者が秘密鍵を喪失したとしても、管理サーバ側では復号することが可能である。つまり、従来のハイブリッド暗号方式の欠点を解消することができる。また、暗号化の際には、管理サーバと通信を行う必要がない。しかも、利用者は自己の秘密鍵を１つだけ持っていれば良い。
【図面の簡単な説明】
【図１】本発明の実施形態に係る暗号システムを示すブロック図である。
【図２】管理サーバ（管理装置）を示すブロック図である。
【図３】鍵管理データベースを示す図である。
【図４】利用者側操作端末を示す図である。
【図５】利用者の登録時の動作を説明するためのブロック図である。
【図６】復号要求の流れを説明するためのブロック図である。
【図７】復号要求の流れを説明するためのフローチャートである。
【図８】復号要求の流れを説明するためのフローチャートである。
【図９】復号要求の流れを説明するためのフローチャートである。
【図１０】復号要求の流れを説明するためのフローチャートである。
【図１１】管理サーバ（管理装置）の別の態様を示すブロック図である。
【図１２】権限管理データベースを示す図である。
【図１３】仕様ポリシーの出力及び配布を説明するためのブロック図である。
【図１４】従来の技術を説明するためのブロック図である。
【図１５】従来技術の鍵管理データベースを説明するための図である。
【図１６】従来技術の利用者側操作端末を説明するための図である。
【図１７】従来技術における復号要求の流れを説明するためのブロック図である。
【符号の説明】
１ 暗号システム
２ 管理サーバ（管理装置）
５ 制御部
６ 鍵管理データベース
１３ 第１暗号文
１４ 第２暗号文
１５ 第３暗号文
Ｓ３３ 第１暗号文取出工程
Ｓ３５ 他者鍵使用復号工程
Ｓ３６ 第３暗号文生成工程
７ 権限管理データベース
１０ セッションキー（使い捨て鍵）
【発明の属する技術分野】
本発明は、暗号システム及びその暗号文処理方法に関する。
【０００２】
【従来の技術】
従来の一般的な暗号技術としては、共通鍵暗号方式と呼ばれる技術がある。共通鍵暗号方式では、データを暗号化する際、並びに、この暗号化されたデータ（暗号文）を復号して平文にする際に、同一の（共通の）鍵、すなわち共通鍵を用いる。このため、データの送受信者は、鍵を第三者に知られないようにする必要がある。この方式は、暗号化に要する処理量が少ないため、大きなデータを暗号化するのに適している。しかし、複数の相手に同一の共通鍵を用いるわけにはいかないため、送信相手毎に異なる共通鍵を生成し、管理する必要がある。このため、送信先が多くなるほど鍵の管理が大変となる。また、共通鍵暗号方式は、不特定多数を相手にする場合には適さないという欠点もある。
【０００３】
このような共通鍵暗号方式における問題を解決するための技術としては、公開鍵暗号方式と呼ばれる技術がある。公開鍵暗号方式では、暗号化用と復号用に異なる鍵を生成し、一方を公開鍵、他方を秘密鍵として使用する。公開鍵暗号方式の場合の暗号化アルゴリズムでは、一方の鍵で暗号化した暗号文は、対となっている他方の鍵でしか復号できない。公開鍵暗号方式では、送信者は受信者の公開鍵で平文を暗号化し、受信者は自己の秘密鍵で暗号文を平文に復号する。
【０００４】
また、公開鍵暗号方式では、暗号文は公開鍵で復号できないのはもちろんのこと、公開鍵から秘密鍵を生成できないようになっている。また、送信相手毎に鍵を生成する必要はなく、利用者は一対の鍵（公開鍵と秘密鍵）を準備すればよく、不特定多数の相手を対象にする場合に適しているといえる。しかし、非対称鍵のビット長や暗号化の対象となるデータが大きくなると暗号化や復号に時間がかかるため、共通鍵暗号方式と比べると、大量のデータの暗号化には適していないといえる。
【０００５】
このような公開鍵暗号方式における問題を解決するための技術としては、ハイブリッド暗号方式と呼ばれるものがある。ハイブリッド暗号方式は、共通鍵暗号方式と公開鍵暗号方式の長所を生かすとともに、それぞれの欠点を補うために、これら２つの暗号方式を組み合わせて暗号化する技術である。すなわち、ハイブリッド暗号方式においては、データを送信者が生成した共通鍵で暗号文とし、この暗号文に、該共通鍵を受信者の公開鍵で暗号化したものを添付して送信する。受信者は、送信された共通鍵を受信者の秘密鍵で復号し、さらに、この復号した共通鍵で暗号文を復号する。ハイブリッド暗号方式の代表的な技術としては、ＰＧＰやＳ／ＭＩＭＥ等がある。
【０００６】
しかしながら、ハイブリッド暗号方式においては、利用者が自己の秘密鍵を喪失してしまうと、元の公開鍵で暗号化した暗号文を復号することができなくなるという問題がある。すなわち、秘密鍵を喪失した場合に新しい秘密鍵及び公開鍵（鍵ペア）を生成したとしても、この新しい鍵ペアでは、元の公開鍵で暗号化した暗号文は復号することができないこととなる。
【０００７】
このようなハイブリッド暗号方式における問題に鑑み、利用者が自己の鍵を喪失したとしても、大きな問題が生じないようにできる暗号システムが考えられている（例えば、特許文献１参照）。
【０００８】
以下、図１４乃至図１７を参照して、この暗号システムについて説明する。
【０００９】
この暗号システムは、図１４に示すように、ネットワークを介して相互に接続される管理サーバ１００と利用者側操作端末１０１とを備えて構成されている。
【００１０】
この暗号システムでは、各利用者は、先ず、自己のＩＤと公開鍵を管理サーバ１０１に登録する。すなわち、例えば利用者Ａが登録を行うには、先ず、秘密鍵（Ａ）及び公開鍵（Ａ）の鍵ペアを生成し、このうち公開鍵（Ａ）を図１４に示すようにＩＤ（Ａ）とともに管理サーバ１００に送信する。
【００１１】
すると、管理サーバ１００は、公開鍵（Ａ）と対応する固有鍵（Ａ）を生成する。ここで、固有鍵（Ａ）は共通鍵である。
【００１２】
この固有鍵（Ａ）に対しては、他の固有鍵に対して所望の対応付けがなされる。すなわち、図１５に示すように、固有鍵（Ａ）に対しては、例えば、利用者Ｂの公開鍵（Ｂ）と対応する固有鍵（Ｂ）、利用者Ｃの公開鍵（Ｃ）と対応する固有鍵（Ｃ）、・・・等が、また、固有鍵（Ｂ）に対しては、例えば、固有鍵（Ａ）、固有鍵（Ｃ）、・・・等が、それぞれ一義的に対応付けられた状態で、管理サーバ１００が備える鍵管理データベース１００ａに登録される。
【００１３】
なお、別の種類の対応付けを要する場合には、利用者Ａは、新たな鍵ベア（秘密鍵（Ａ´）及び公開鍵（Ａ´））を生成し、このうち公開鍵（Ａ´）を管理サーバ１００に登録する必要がある。このため、例えば、図１６に示すように、利用者側操作端末（Ａ）１０１では、複数の鍵ペア（秘密鍵（Ａ）及び公開鍵（Ａ）、秘密鍵（Ａ´）及び公開鍵（Ａ´）、・・・）を保持する必要がある。
【００１４】
また、利用者Ａの登録がなされると、図１４に示すように、公開鍵（Ａ）で暗号化されたサーバの公開鍵（Ｓ）及び認証用の秘密データが、登録者である利用者Ａの利用者側操作端末（Ａ）に送信される。
【００１５】
次に、図１７を参照して、利用者からの復号要求について説明する。
【００１６】
ここでは、例えば、利用者Ａが暗号化した暗号文を、利用者Ｂが復号要求する例を説明する。
【００１７】
先ず、利用者Ａによる暗号化を説明する。この暗号化を行うには、先ず、利用者Ａは公開鍵（Ｓ）で秘密データを暗号化したものにＩＤ（Ａ）を付して管理サーバ１００に送信する。管理サーバ１００では、公開鍵（Ｓ）と対をなす秘密鍵（Ｓ）を用いて復号することにより秘密データを取り出し、この取り出した秘密データを管理サーバ１００側で保持している秘密データと照合することにより認証を行う。認証された場合は、ＩＤ（Ａ）と対応する（公開鍵（Ａ）と対応する）鍵（固有鍵（Ａ）、固有鍵（Ｂ）、固有鍵（Ｃ）、・・・）を公開鍵（Ａ）で暗号化したものを利用者側操作端末（Ａ）に返送する。これにより利用者Ａは暗号化に用いる固有鍵（Ａ）を取得する。
【００１８】
次に、利用者Ａは、セッションキーを生成し、このセッションキーでデータを暗号化することにより暗号文１１０を生成し、更に、このセッションキーを固有鍵（Ａ）で暗号化することにより暗号部１１１を生成し、これら両暗号文１１０，１１１を利用者Ｂに送信する。
【００１９】
次に、利用者Ｂは、公開鍵（Ｓ）で秘密データを暗号化したものにＩＤ（Ｂ）を付して管理サーバ１００に送信する。管理サーバ１００では、秘密鍵（Ｓ）を用いて復号することにより秘密データを取り出し、この取り出した秘密データを管理サーバ１００側で保持している秘密データと照合することにより認証を行う。認証された場合は、ＩＤ（Ｂ）と対応する（公開鍵（Ｂ）と対応する）鍵（固有鍵（Ｂ）、固有鍵（Ａ）、固有鍵（Ｃ）、・・・）を公開鍵（Ｂ）で暗号化したものを利用者側操作端末（Ｂ）に返送する。これにより利用者Ｂは暗号文１１１の復号に用いる固有鍵（Ａ）を取得する。
【００２０】
よって、利用者Ｂは、固有鍵（Ａ）を用いて暗号文１１１を復号することによりセッションキーを取り出すことができ、このセッションキーを用いて暗号文１１０を復号することによりデータを取り出すことができる。
【００２１】
また、この暗号システムにおいては、各固有鍵を管理サーバで管理しておくので、利用者側で秘密鍵を喪失した場合にも救済措置をとることができる。つまり、秘密鍵を喪失した場合には、新たに登録を行い、該登録により新規に生成される固有鍵と、元々の秘密鍵（と対をなす公開鍵）と対応する固有鍵とを対応付けることにより、元々の秘密鍵の使用時に暗号化した暗号文も復号することができるようになる。
【００２２】
【特許文献１】
特開２００２−３１４５２７号公報
【００２３】
【発明が解決しようとする課題】
しかしながら、上記の特許文献１の技術では、管理サーバ１００が保有する固有鍵で暗号化鍵（セッションキー）を暗号化するようにしているため、以下のような問題点がある。
【００２４】
先ず、利用者は、データの暗号化の際に管理サーバ１００との間で通信を行って、固有鍵を取得する必要があるため、暗号化が面倒である。
【００２５】
しかも、取得した多くの鍵（鍵束）の中から所望の固有鍵を使い分ける必要があるという問題もある。
【００２６】
加えて、別の種類の対応付けを要する場合には、利用者は、複数の鍵ペア（例えば、秘密鍵（Ａ）及び公開鍵（Ａ）、秘密鍵（Ａ´）及び公開鍵（Ａ´）、・・・等）を保持する必要があり、しかも、このうち適当な鍵を使用する必要がある。つまり、例えば、会社組織などにおいて、固有鍵間の対応付けを組織毎に別個に施すような場合に、複数の組織に亘って役職を兼務するような利用者は、多くの鍵ペアを保持する必要があり不便となる。
【００２７】
本発明は、上記のような問題点を解決するためになされたもので、従来のハイブリッド暗号方式の欠点を解消しながらも、暗号化及び鍵管理を容易になし得、しかも、利用者は、１つの鍵ペアを保持するだけで足りる暗号システム及びその暗号文処理方法を提供することを目的とする。
【００２８】
【課題を解決するための手段】
上記課題を解決するため、本発明の暗号システムは、利用者からの復号要求に基づき暗号文を復号することが可能な管理装置を備える暗号システムであって、前記管理装置は、利用者として登録された複数人分の公開鍵を管理する鍵管理データベースと、前記鍵管理データベース内の公開鍵を用いた復号及び暗号化が実行可能な制御部と、を備え、前記制御部は、利用者からの復号要求として、他者の秘密鍵により暗号化された第１暗号文を当該利用者の秘密鍵で更に暗号化することにより生成された第２暗号文が該利用者から送信された場合に、前記第２暗号文を前記鍵管理データベース内の当該利用者の公開鍵を用いて復号することにより前記第１暗号文を取り出す第１暗号文取出工程と、前記第１暗号文取出工程により取り出した第１暗号文を前記鍵管理データベース内の前記他者の公開鍵を用いて復号する他者鍵使用復号工程と、前記他者鍵使用復号工程による復号結果を、当該利用者の公開鍵を用いて暗号化することにより第３暗号文を生成する第３暗号文生成工程と、をこの順に実行し、更に、前記第３暗号文生成工程により生成された第３暗号文を、前記復号要求を行った利用者に送信するように構成されていることを特徴としている。
【００２９】
本発明の暗号システムにおいては、前記鍵管理データベースは、各公開鍵を非公開に管理することが好ましい。
【００３０】
本発明の暗号システムにおいては、前記鍵管理データベースは、複数の利用者の公開鍵の各々を、各利用者の識別情報と対応付けて管理するものとし、利用者は、復号要求の際に、当該利用者の識別情報を前記第２暗号文に付して送信するものとし、前記制御部は、利用者からの復号要求がなされた場合に、該利用者より送信された識別情報と対応する公開鍵を、前記鍵管理データベースより取得して前記第１暗号文取出工程での復号に用いることが好ましい。
【００３１】
この場合、前記制御部は、前記第１暗号文取出工程にて復号を実行できるか否かにより利用者の認証を行うことが好ましい。
【００３２】
本発明の暗号システムにおいては、利用者は、復号要求の前に、予め前記第１暗号文及び前記他者の識別情報を取得しておくものとし、かつ、前記第２暗号文の生成は、当該利用者の秘密鍵により前記第１暗号文及び前記他者の識別情報をまとめて暗号化することで行うものとし、前記制御部は、前記第１暗号文取出工程にて前記第１暗号文及び前記他者の識別情報を取り出し、該取り出した識別情報と対応する公開鍵を前記鍵管理データベースより取得して前記他者鍵使用復号工程での復号に用いることが好ましい。
【００３３】
本発明の暗号システムにおいては、前記識別情報には、最終復号要求日時の記録が付されるようになっているとともに、前記管理装置は、各利用者の最終復号要求日時を管理するように構成され、前記制御部は、復号要求があった場合に、送信された識別情報に付された最終復号要求日時と、管理装置で管理している該当する最終復号要求日時と、の照合を行い、これらの日時が相違している場合には、復号要求を行った利用者に対し、該相違している旨の通知を行うことが好ましい。
【００３４】
本発明の暗号システムにおいては、前記管理装置は、復号に関する権限を利用者毎に設定可能に構成され、前記制御部は、復号要求があった場合に、前記第３暗号文を生成して利用者に送信するか否かの判断を、設定された権限に応じて行うことが好ましい。
【００３５】
この場合、前記管理装置は、復号に関する前記権限と各利用者との対応付けを管理する権限管理データベースを更に備えることが好ましい。
【００３６】
本発明の暗号システムにおいては、前記管理装置は、前記権限と各利用者との対応付けとして、複数種類の対応付けを設定可能であり、前記制御部は、復号要求の種類に応じて、何れかの対応付けに従って、前記第３暗号文を生成して利用者に送信するか否かの判断を行うことが好ましい。
【００３７】
この場合、前記複数種類の対応付けには、少なくとも、組織に応じた対応付けと、機密度に応じた対応付けと、が含まれていることが好ましい。
【００３８】
本発明の暗号システムにおいては、復号に関する権限の有効期限を設定可能であることが好ましい。
【００３９】
本発明の暗号システムにおいては、当該暗号システムの使用ポリシーを問答形式で作成可能であることが好ましい。
【００４０】
この場合、作成した使用ポリシーを出力可能或いは各利用者に送信可能であることが好ましい。
【００４１】
また、本発明の暗号文処理方法は、本発明の暗号システムを用いた暗号文処理方法であって、前記他者である第１利用者は、自己の秘密鍵を用いて前記第１暗号文を生成し、該生成した第１暗号文を前記利用者である第２利用者に取得可能な状態とさせ、続いて、前記第２利用者は、前記取得可能な状態とされた第１暗号文を取得し、該第１暗号文を自己の秘密鍵により更に暗号化して第２暗号文を生成し、該生成した第２暗号文を前記管理装置に送信し、続いて、前記制御部は、前記第１暗号文取出工程、前記他者鍵使用復号工程及び前記第３暗号文生成工程をこの順に実行し、更に、第３暗号文生成工程により生成された第３暗号文を、前記第２利用者により取得可能な状態とさせ、続いて、前記第２利用者は、前記第３暗号文を取得し、該第３暗号文を自己の秘密鍵により復号することにより、該復号結果を得ることを特徴としている。
【００４２】
また、本発明の暗号文処理方法は、本発明の暗号システムを用いた暗号文処理方法であって、前記他者である第１利用者は、自己の秘密鍵を用いて前記第１暗号文を生成し、該生成した第１暗号文を前記利用者である第２利用者に取得可能な状態とさせ、続いて、前記第２利用者は、前記取得可能な状態とされた第１暗号文を取得し、該第１暗号文を自己の秘密鍵により更に暗号化して第２暗号文を生成し、該生成した第２暗号文に自己の識別情報を付して前記管理装置に送信し、続いて、前記制御部は、前記第２利用者より送信された識別情報と対応する公開鍵を前記鍵管理データベースより取得し、該取得した公開鍵を用いて前記第２暗号文を復号することで前記第１暗号文取出工程を実行した後で、前記他者鍵使用復号工程及び前記第３暗号文生成工程をこの順に実行し、更に、第３暗号文生成工程により生成された第３暗号文を、前記第２利用者により取得可能な状態とさせ、続いて、前記第２利用者は、前記第３暗号文を取得し、該第３暗号文を自己の秘密鍵により復号することにより、該復号結果を得ることを特徴としている。
【００４３】
この場合、前記第１利用者は、前記第１暗号文及び自己の識別情報を第２利用者に取得可能な状態とさせ、前記第２利用者は、取得した前記第１暗号文及び前記第１利用者の識別情報を自己の秘密鍵によりまとめて暗号化することにより前記第２暗号文を生成し、前記制御部は、前記第１暗号文取出工程にて前記第１暗号文及び前記他者の識別情報を取り出し、該取り出した識別情報と対応する公開鍵を前記鍵管理データベースより取得して前記他者鍵使用復号工程での復号に用いることが好ましい。
【００４４】
また、本発明の暗号文処理方法においては、前記第１利用者は、使い捨て鍵を生成し、この使い捨て鍵によりデータを暗号化することで暗号化データを生成する一方で、自己の秘密鍵を用いて前記使い捨て鍵を暗号化することにより前記第１暗号文を生成し、これら生成した第１暗号文及び暗号化データを前記第２利用者に取得可能な状態とさせ、続いて、前記第２利用者は、前記取得可能な状態とされた第１暗号文及び暗号化データを取得し、このうち第１暗号文を自己の秘密鍵により更に暗号化して第２暗号文を生成し、該生成した第２暗号文を前記管理装置に送信し、続いて、前記制御部は、前記第１暗号文取出工程及び前記他者鍵使用復号工程をこの順に実行することにより前記使い捨て鍵を取り出し、この取り出した使い捨て鍵を、前記第３暗号文生成工程にて暗号化することで前記第３暗号文を生成し、この第３暗号文を、前記第２利用者により取得可能な状態とさせ、続いて、前記第２利用者は、前記第３暗号文を取得し、該第３暗号文を自己の秘密鍵により復号することにより前記使い捨て鍵を取り出し、この使い捨て鍵を用いて前記暗号化データを復号することにより、前記データを取り出すことが好ましい。
【００４５】
【発明の実施の形態】
以下、図面を参照して、本発明に係る実施の形態について説明する。
【００４６】
〔第１の実施形態〕
図１に示すように、第１の実施形態に係る暗号システム１は、利用者からの復号要求に基づき暗号文を復号することが可能な管理サーバ（管理装置）２と、各利用者（利用者Ａ、利用者Ｂ、利用者Ｃ、・・・）に割り当てられた利用者側操作端末３とを備えて構成され、これら利用者側操作端末３と管理サーバ２とはネットワーク４を介して相互に接続可能となっている。
【００４７】
図２に示すように、管理サーバ２は、各種処理を実行する制御部５と、各利用者の公開鍵を管理する鍵管理データベース６と、を備えている。
【００４８】
このうち、制御部５は、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）及びＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）を備えて構成されている。このうちＲＯＭには、当該暗号システム１における管理サーバ２用のプログラム（ソフトウェア）が記憶されている。また、ＣＰＵは、このＲＯＭに記憶されている各プログラムを実行することにより、各種処理を行う。また、ＲＡＭは、ＣＰＵの作業領域の他、各種データの一時的な記憶領域を備える。
【００４９】
なお、制御部５では、予め管理サーバ２の公開鍵（Ｓ）及び秘密鍵（Ｓ）の鍵ペアを生成し保存しておく。
【００５０】
他方、鍵管理データベース６は、図３に示すように、各利用者の公開鍵を、各利用者（利用者Ａ、利用者Ｂ、利用者Ｃ、・・・）のＩＤ（識別情報）と１対１で対応付けた状態で、非公開に保存（管理）する。つまり、各利用者は、各自で生成した公開鍵を、管理サーバ２に対してのみ公開し、その他（他の利用者）に対しては非公開とする。
【００５１】
また、各利用者側操作端末３は、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）及びＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）を備えて構成されている。このうちＲＯＭには、当該暗号システム１における利用者側操作端末３用のプログラム（ソフトウェア）が記憶されている。また、ＣＰＵは、このＲＯＭに記憶されている各プログラムを実行することにより、各種処理を行う。また、ＲＡＭは、ＣＰＵの作業領域の他、各種データの一時的な記憶領域を備える。
【００５２】
また、図４に示すように、各利用者側操作端末３には、例えば、予め管理サーバ２の公開鍵（Ｓ）が与えられ、記憶されているものとする。
【００５３】
次に、図５を参照して、利用者の（公開鍵の）登録について説明する。
【００５４】
利用者（例えば利用者Ａ）が登録を行う際には、先ず、利用者Ａの利用者側操作端末（Ａ）３にて、公開鍵（Ａ）及び秘密鍵（Ａ）の鍵ペアを生成し保存する（図４）。そして、このうち公開鍵（Ａ）は、そのコピーを管理サーバ２に登録する。この登録の際には、図５に示すように、管理サーバ２の公開鍵（Ｓ）で、利用者ＡのＩＤ（Ａ）及び公開鍵（Ａ）をまとめて暗号化した暗号文１１を、利用者側操作端末（Ａ）３より管理サーバ２に送信する。
【００５５】
すると、この暗号文１１の送信を、管理サーバ２の制御部５では登録要求として受け付け、暗号文１１を管理サーバ２の秘密鍵（Ｓ）で復号することによりＩＤ（Ａ）及び公開鍵（Ａ）を取り出し（平文にし）、この取り出したＩＤ（Ａ）と公開鍵（Ａ）とを、図３のように１対１で対応付けた状態で鍵管理データベース６に保存（登録）する。
【００５６】
つまり、同様の登録作業を各利用者が行うことにより、次第に鍵管理データベース６には利用者の公開鍵が蓄積される。
【００５７】
次に、図６乃至１２を参照して、利用者からの復号要求について説明する。
【００５８】
ここでは、例えば、利用者Ａ（第１利用者、他者）が自己の秘密鍵（Ａ）で暗号化した暗号文を、利用者Ｂ（第２利用者、利用者）が復号要求する例を説明する。
【００５９】
この場合の動作は概略的には図６に示すように、利用者側操作端末（Ａ）３での利用者Ａの作業（ステップＳ１）→利用者側操作端末（Ｂ）３での利用者Ｂの作業（ステップＳ２）→管理サーバ２（の制御部５）による処理（ステップＳ３）→利用者側操作端末（Ｂ）３での利用者Ｂの作業（ステップＳ４）の順に進行する。なお、このうちステップＳ１は、利用者Ａの作業に応じた利用者側操作端末（Ａ）３の処理であるとも言える。同様に、ステップＳ２、Ｓ４は、利用者Ｂの作業に応じた利用者側操作端末（Ｂ）３の処理であるともいえる。
【００６０】
次に、上記ステップＳ１〜Ｓ４について、それぞれ詳細に説明する。
【００６１】
先ず、ステップＳ１は、利用者Ａ（第１利用者）がデータを暗号化する工程である。
【００６２】
このステップＳ１では、図７に示すように、先ず、ステップＳ１１にて、セッションキー１０（使い捨て鍵）を生成する。なお、このセッションキー１０は、データを暗号化する都度、別個に生成する。
【００６３】
ステップＳ１１に続くステップＳ１２では、ステップＳ１１にて生成したセッションキー１０を用いてデータを暗号化することによって、暗号化データ１２を生成する。
【００６４】
ステップＳ１２に続くステップＳ１３では、先のステップＳ１１にて生成したセッションキー１０を、利用者Ａの秘密鍵（Ａ）で暗号化することによって、第１暗号文１３を生成する。なお、利用者側操作端末（Ａ）では、第１暗号文１３と暗号化データ１２とをひとまとめにして保持しておく。
【００６５】
ここで、このように暗号化を行う結果として得られる第１暗号文１３と暗号化データ１２は、公開鍵（Ａ）を用いることにより、順次、復号することができる。すなわち、公開鍵（Ａ）で第１暗号文１３を復号することによりセッションキー１０を取り出すことができ、このセッションキー１０を用いて暗号化データ１２を復号することによりデータ１６を取り出すことができる。つまり、ここでの暗号化鍵は、利用者Ａの秘密鍵（Ａ）であるといえる。
【００６６】
また、このように第１暗号文１３及び暗号化データ１２を生成する際には、利用者側操作端末（Ａ）と管理サーバ２との間で通信を行う必要がない。つまり、本実施形態の場合、暗号化の際には利用者が管理サーバ２と通信する必要がない。
【００６７】
ステップＳ１３に続くステップＳ１４では、ステップＳ１３にて生成した第１暗号文１３と、ステップＳ１２にて生成した暗号化データ１２と、利用者ＡのＩＤ（Ａ）と、を利用者Ｂの利用者側操作端末（Ｂ）３に対し、例えばメールで送信する。
【００６８】
次に、ステップＳ２では、図８に示すように、先ず、ステップＳ２１にて、利用者側操作端末（Ｂ）が、第１暗号文１３、暗号化データ１２及びＩＤ（Ａ）を受信（取得）する。
【００６９】
なお、ここでは、第１暗号文１３、暗号化データ１２及びＩＤ（Ａ）をメール送信により利用者側操作端末（Ａ）から利用者側操作端末（Ｂ）に移動させる例を説明するが、メール送信以外でも、例えば、一旦管理サーバ２に登録（アップ）したものを、利用者側操作端末（Ａ）で取得するようにしても良い。
【００７０】
ステップＳ２１に続くステップＳ２２では、第１暗号文１３、暗号化データ１２及びＩＤ（Ａ）のうち、第１暗号文１３とＩＤ（Ａ）を、まとめて秘密鍵（Ｂ）で暗号化する。これにより、第２暗号文１４を生成する。ここで、セッションキー１０は、秘密鍵（Ａ）と秘密鍵（Ｂ）とで２重に暗号化されていることになる。
【００７１】
ステップＳ２２に続くステップＳ２３では、ステップＳ２１にて生成した第２暗号文１４に利用者ＢのＩＤ（Ｂ）を付して管理サーバ２に送信する。なお、本実施形態の場合、このように第２暗号文１４に自己のＩＤ（Ｂ）を付して管理サーバ２に送信することを「復号要求」ということとする。
【００７２】
次に、ステップＳ３では、図９に示すように、先ず、ステップＳ３１にて、管理サーバ２が、第２暗号文１４及びＩＤ（Ｂ）を受信し、該受信することで復号要求を受け付ける。
【００７３】
ステップＳ３１に続くステップＳ３２では、制御部５はＩＤ（Ｂ）と対応する鍵、すなわち公開鍵（Ｂ）を鍵管理データベース６内より取得する。
【００７４】
ステップＳ３２に続くステップＳ３３では、制御部５はステップＳ３２にて取得した公開鍵（Ｂ）で第２暗号文１４を復号することにより、第１暗号文１３とＩＤ（Ａ）を取り出す（第１暗号文取出工程）。ここで、制御部５は、この第１暗号文取出工程にて復号を実行できるか否かにより利用者の認証を行う。また、復号を実行できたか否かの判定は、復号の前後でデータが変化したか否かを判定することにより行う。
【００７５】
ステップＳ３３に続くステップＳ３４では、制御部５は取り出したＩＤすなわちＩＤ（Ａ）と対応する鍵、つまり公開鍵（Ａ）を鍵管理データベース６内より取得する。
【００７６】
ステップＳ３４に続くステップＳ３５では、制御部５はステップＳ３４にて取得した公開鍵（Ａ）で第１暗号文１３を復号することにより、セッションキー１０を取り出す（他者鍵使用復号工程）。つまり、公開鍵（Ｂ）による復号と、公開鍵（Ａ）による復号とを順に行うことにより、秘密鍵（Ａ）と秘密鍵（Ｂ）とで２重に暗号化されたセッションキー１０を取り出すことができる。
【００７７】
ステップＳ３５に続くステップＳ３６では、制御部５はステップＳ３５にて取り出したセッションキー１０を、復号要求者である利用者Ｂの公開鍵（Ｂ）で暗号化することにより第３暗号文１５を生成する（第３暗号文生成工程）。
【００７８】
ステップＳ３６に続くステップＳ３７では、制御部５はステップＳ３６にて生成した第３暗号文１５を、復号要求者である利用者Ｂの利用者側操作端末（Ｂ）３に送信する。
【００７９】
次に、ステップＳ４では、図１０に示すように、先ず、ステップＳ４１にて、利用者側操作端末（Ｂ）が第３暗号文１５を受信する。
【００８０】
ステップＳ４１に続くステップＳ４２では、第３暗号文１５を秘密鍵（Ｂ）で復号することにより、セッションキー１０を取り出す。
【００８１】
ステップＳ４２に続くステップＳ４３では、ステップＳ４２にて取り出したセッションキー１０で、先のステップＳ２１にて受信した暗号化データ１２を復号することにより、データ１６を取り出すことができる。
【００８２】
以上のような第１の実施形態によれば、暗号化鍵に利用者の秘密鍵を用いるとともに、管理サーバ２側で利用者の公開鍵を管理しているので、利用者が秘密鍵を喪失したとしても、管理サーバ２側では復号することが可能である。従って、利用者が新たな鍵ペア（秘密鍵及び公開鍵）を生成し、登録すれば、鍵の喪失前に暗号化した暗号文も問題なく取り出すことができる。つまり、従来のハイブリッド暗号方式の欠点を解消することができる。
【００８３】
また、従来技術におけるような固有鍵を用いる必要が無いため、図１７に示すような複雑な手順を経る必要がなく、図６に示すような簡略な手順で暗号化及び復号化を行うことができる。特に、暗号化の際には、管理サーバ２と通信を行う必要がない。しかも、利用者は自己の秘密鍵を１つだけ持っていれば良い。
【００８４】
なお、本実施形態の暗号システムは、例えば、企業における情報管理に適用することができる。この場合、利用者は個々の社員に該当する。
【００８５】
〔第２の実施形態〕
次に、本発明に係る第２の実施形態を説明する。
【００８６】
第２の実施形態では、管理サーバ２は、復号に関する権限を利用者毎に設定可能に構成され、制御部５は、復号要求があった場合に、第３暗号文１５を生成して利用者（復号要求者）に送信するか否かの判断を、設定された権限に応じて行う。
【００８７】
また、本実施形態の場合、復号に関する権限と各利用者との対応付けを管理するために、管理サーバ２は、図１１に示すように、権限管理データベース７を更に備える。すなわち、権限管理データベース７には、復号に関する権限と各利用者との対応付けを記憶保持している。
【００８８】
また、管理サーバ２は、復号に関する権限と各利用者との対応付けとして、複数種類の対応付けを設定可能であり、制御部５は、復号要求の種類に応じて、何れかの対応付けに従って、第３暗号文１５を生成して利用者に送信するか否かの判断を行う。
【００８９】
ここで、本実施形態の場合、復号に関する権限と各利用者との複数種類の対応付けには、組織に応じた対応付けと、機密度に応じた対応付けと、が含まれている。ここで、機密度とは、例えば、極秘、○○部外秘、社外秘或いは○○プロジェクト外秘などのように、守秘程度或いは守秘範囲に応じた機密度を意味する。すなわち、権限管理データベース７は、例えば、図１２に示すように、各機密度に対して各利用者（各ＩＤで管理している）の復号権限の有無を確認できるように、対応付けを保持している。
【００９０】
このように機密度に応じた対応付けを施す場合には、例えば、暗号化の際に、機密度を特定するための情報（ラベル）を、例えばセッションキー１０に付しておく。従って、制御部５では、復号要求があった際に、セッションキー１０に付されたラベルに基づき権限管理データベース７に保持された対応付けを参照することにより、復号要求者が復号権限を有する者であるか否かを判定する。
【００９１】
具体的には、例えば、○○プロジェクト外の利用者が復号要求を行った場合に、セッションキー１０に付されたラベルが○○プロジェクト外秘であった際には、制御部５は、第３暗号文１５を生成して利用者（復号要求者）に送信する処理は実行せず、利用者（の利用者側操作端末３）に対し、例えば、「あなたは今回要求した復号の権限を持っていません」との通知を行う。
【００９２】
このように、第２の実施形態では、鍵の管理（鍵管理データベース６が関連する）と、復号権限の管理（権限管理データベース７が関連する）を分離して行う。
【００９３】
また、例えば、人事異動などにより組織の所属が変わったり、或いは、所属は変わらないでも、新規のプロジェクトのメンバーに選任された場合など、復号に関する権限と各利用者との対応付けが変化したら、その都度、暗号システム１の管理者が権限管理データベース７の記憶内容を更新だけで（設定変更を行う）と良く、利用者が新たな鍵ペアを生成したりする必要はない。
【００９４】
さらに、本実施形態では、例えば、復号に関する権限の有効期限を設定可能となっている。つまり、管理者による設定時に、有効期限を例えば６ヶ月とした場合には、設定時から６ヶ月経過したときに、管理者が設定変更を行うことなく、制御部５の制御により自動的に設定内容を更新して権限を無効とさせる。
【００９５】
また、例えば、退職などの場合には、退職者の公開鍵は鍵管理データベース６に引き続き保存したままで、退職者の権限を無効とするだけで良い。なお、無効とするためには、例えば、権限管理データベース７における該当する利用者の欄に無効の旨を示すビットを立てると良い。この場合、制御部５は、復号要求があった際に、無効のビットが立っているか否かの判定を行うことにより、第３暗号文１５を生成して利用者に送信するか否かの判断を行う。つまり、例えば、無効のビットが立っていれば、第３暗号文１５を生成して利用者に送信する処理は実行しない。
【００９６】
また、復号権限だけでなく、暗号権限についても、同様に管理することが好ましい。このように暗号権限も管理することにより、権限規定に基づかないで各利用者が勝手に暗号化を実行してしまうことを防止できる。
【００９７】
ここで、本実施形態の暗号システムにおいては、管理者による設定（復号権限、暗号権限など）自体が、当該暗号システムの使用ポリシーとなる。そこで、図１３に示すように、管理サーバ２は、設定された仕様ポリシー８を、所定のフォーマットで出力（プリントアウト）、或いは、各利用者側操作端末３に送信（配布）することが可能となっている。
【００９８】
また、仕様ポリシーの設定は、少なくとも一部の項目については、問答形式で実行することが可能に構成されていることが好ましい。具体的には、例えば、モード選択画面にて設定ボタンを選択操作するとウィザードが起動して設定可能モードに移行する。この設定可能モードでは、例えば、「Ｑ．どの組織に適用しますか？」、「Ｑ．責任者は誰ですか？」、「Ｑ．極秘とはどのような意味ですか？」或いは「Ｑ．○○プロジェクト外秘とはどのような意味ですか？」との管理サーバ２からの問いに対し、管理者は、対応する入力箇所に必要な入力事項を入力することで、該当する項目の設定（仕様ポリシーの設定）を行うことができる。
【００９９】
ここで、管理者（管理者は利用者でもある）の秘密鍵は、例えば、一般の利用者の秘密鍵とは異なり、管理サーバ２を直接操作することが可能であるか、或いは、管理者の利用者側操作端末３より管理サーバ２に接続して該管理サーバ２内の設定操作を行うことが可能な管理者鍵として機能するようになっている。
【０１００】
さらに、このように、管理者の秘密鍵を管理者鍵として利用する場合に、いわゆるダブルロック方式を適用すれば、セキュリティー性を高めることができる。
【０１０１】
また、例えば、不正に利用者の秘密鍵及びＩＤを入手した者が、復号要求を行った場合には、そのことを正規の利用者に通知できるような構成とすることも好ましい。この構成を実現するためには、ＩＤには、最終復号要求日時（最終ログイン日時）の記録が付されるようになっているとともに、管理サーバ２は、各利用者の最終復号要求日時を管理（保存）するように構成されていれば良い。つまり、復号要求があった場合には、制御部５は受信したＩＤの最終復号要求日時を更新する。そして、第３暗号文１５を復号要求者に送信する際には、最終復号要求日時が更新済みのＩＤを該第３暗号文１５に添付する。さらに、利用者側操作端末３では、自己で保持していた既存のＩＤを、管理サーバ２より送信された新規のＩＤに更新する。また、制御部５は、復号要求があった場合に、送信されたＩＤに付された最終復号要求日時と、管理サーバ２で管理している該当する最終復号要求日時と、の照合を行い、これらの日時が相違している場合には、復号要求を行った利用者に対し、該相違している旨の通知を行うように構成されている。なお、この通知としては、例えば「サーバに記録された最終時刻とＩＤファイルに記載された最終時刻が異なります。不正に使用された可能性があるので管理者に報告してください。」との通知を行う。
【０１０２】
なお、本実施形態に係る暗号システム１は、企業内における情報管理だけでなく、例えば、電子政府、電子自治体或いは金融機関等にも好適に適用することができる。
【０１０３】
また、利用者側操作端末３は、例えば、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）からなることを好ましい例とするが、これに限らず、例えば、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）等の携帯情報端末からなることとしても良い。
【０１０４】
さらに、管理サーバ２の鍵管理データベース６或いは権限管理データベース７は、管理サーバ２に組み付けの記憶媒体により構成されているのであっても良いが、管理サーバ２に対し着脱自在な記憶媒体により構成することも好ましく、このように着脱自在に構成することにより、例えば、データベースを取り外して金庫内に保管したりすることもでき、セキュリティー管理を一層厳格に行うことができる。
【０１０５】
【発明の効果】
本発明によれば、暗号化鍵に利用者の秘密鍵を用いるとともに、管理サーバ側で利用者の公開鍵を管理しているので、利用者が秘密鍵を喪失したとしても、管理サーバ側では復号することが可能である。つまり、従来のハイブリッド暗号方式の欠点を解消することができる。また、暗号化の際には、管理サーバと通信を行う必要がない。しかも、利用者は自己の秘密鍵を１つだけ持っていれば良い。
【図面の簡単な説明】
【図１】本発明の実施形態に係る暗号システムを示すブロック図である。
【図２】管理サーバ（管理装置）を示すブロック図である。
【図３】鍵管理データベースを示す図である。
【図４】利用者側操作端末を示す図である。
【図５】利用者の登録時の動作を説明するためのブロック図である。
【図６】復号要求の流れを説明するためのブロック図である。
【図７】復号要求の流れを説明するためのフローチャートである。
【図８】復号要求の流れを説明するためのフローチャートである。
【図９】復号要求の流れを説明するためのフローチャートである。
【図１０】復号要求の流れを説明するためのフローチャートである。
【図１１】管理サーバ（管理装置）の別の態様を示すブロック図である。
【図１２】権限管理データベースを示す図である。
【図１３】仕様ポリシーの出力及び配布を説明するためのブロック図である。
【図１４】従来の技術を説明するためのブロック図である。
【図１５】従来技術の鍵管理データベースを説明するための図である。
【図１６】従来技術の利用者側操作端末を説明するための図である。
【図１７】従来技術における復号要求の流れを説明するためのブロック図である。
【符号の説明】
１ 暗号システム
２ 管理サーバ（管理装置）
５ 制御部
６ 鍵管理データベース
１３ 第１暗号文
１４ 第２暗号文
１５ 第３暗号文
Ｓ３３ 第１暗号文取出工程
Ｓ３５ 他者鍵使用復号工程
Ｓ３６ 第３暗号文生成工程
７ 権限管理データベース
１０ セッションキー（使い捨て鍵）
Claims (17)
- 利用者からの復号要求に基づき暗号文を復号することが可能な管理装置を備える暗号システムであって、
前記管理装置は、
利用者として登録された複数人分の公開鍵を管理する鍵管理データベースと、
前記鍵管理データベース内の公開鍵を用いた復号及び暗号化が実行可能な制御部と、
を備え、
前記制御部は、
利用者からの復号要求として、他者の秘密鍵により暗号化された第１暗号文を当該利用者の秘密鍵で更に暗号化することにより生成された第２暗号文が該利用者から送信された場合に、
前記第２暗号文を前記鍵管理データベース内の当該利用者の公開鍵を用いて復号することにより前記第１暗号文を取り出す第１暗号文取出工程と、
前記第１暗号文取出工程により取り出した第１暗号文を前記鍵管理データベース内の前記他者の公開鍵を用いて復号する他者鍵使用復号工程と、
前記他者鍵使用復号工程による復号結果を、当該利用者の公開鍵を用いて暗号化することにより第３暗号文を生成する第３暗号文生成工程と、
をこの順に実行し、
更に、前記第３暗号文生成工程により生成された第３暗号文を、前記復号要求を行った利用者に送信するように構成されていることを特徴とする暗号システム。 - 前記鍵管理データベースは、各公開鍵を非公開に管理することを特徴とする請求項１に記載の暗号システム。
- 前記鍵管理データベースは、複数の利用者の公開鍵の各々を、各利用者の識別情報と対応付けて管理するものとし、
利用者は、復号要求の際に、当該利用者の識別情報を前記第２暗号文に付して送信するものとし、
前記制御部は、
利用者からの復号要求がなされた場合に、該利用者より送信された識別情報と対応する公開鍵を、前記鍵管理データベースより取得して前記第１暗号文取出工程での復号に用いることを特徴とする請求項１又は２に記載の暗号システム。 - 前記制御部は、前記第１暗号文取出工程にて復号を実行できるか否かにより利用者の認証を行うことを特徴とする請求項３に記載の暗号システム。
- 利用者は、復号要求の前に、予め前記第１暗号文及び前記他者の識別情報を取得しておくものとし、かつ、前記第２暗号文の生成は、当該利用者の秘密鍵により前記第１暗号文及び前記他者の識別情報をまとめて暗号化することで行うものとし、
前記制御部は、
前記第１暗号文取出工程にて前記第１暗号文及び前記他者の識別情報を取り出し、該取り出した識別情報と対応する公開鍵を前記鍵管理データベースより取得して前記他者鍵使用復号工程での復号に用いることを特徴とする請求項３又は４に記載の暗号システム。 - 前記識別情報には、最終復号要求日時の記録が付されるようになっているとともに、
前記管理装置は、各利用者の最終復号要求日時を管理するように構成され、
前記制御部は、復号要求があった場合に、送信された識別情報に付された最終復号要求日時と、管理装置で管理している該当する最終復号要求日時と、の照合を行い、これらの日時が相違している場合には、復号要求を行った利用者に対し、該相違している旨の通知を行うことを特徴とする請求項３乃至５のいずれか一項に記載の暗号システム。 - 前記管理装置は、復号に関する権限を利用者毎に設定可能に構成され、
前記制御部は、復号要求があった場合に、前記第３暗号文を生成して利用者に送信するか否かの判断を、設定された権限に応じて行うことを特徴とする請求項１乃至６のいずれか一項に記載の暗号システム。 - 前記管理装置は、復号に関する前記権限と各利用者との対応付けを管理する権限管理データベースを更に備えることを特徴とする請求項７に記載の暗号システム。
- 前記管理装置は、前記権限と各利用者との対応付けとして、複数種類の対応付けを設定可能であり、
前記制御部は、復号要求の種類に応じて、何れかの対応付けに従って、前記第３暗号文を生成して利用者に送信するか否かの判断を行うことを特徴とする請求項７又は８に記載の暗号システム。 - 前記複数種類の対応付けには、少なくとも、組織に応じた対応付けと、機密度に応じた対応付けと、が含まれていることを特徴とする請求項９に記載の暗号システム。
- 復号に関する権限の有効期限を設定可能であることを特徴とする請求項７乃至１０のいずれか一項に記載の暗号システム。
- 当該暗号システムの使用ポリシーを問答形式で作成可能であることを特徴とする請求項１乃至１１のいずれか一項に記載の暗号システム。
- 作成した使用ポリシーを出力可能或いは各利用者に送信可能であることを特徴とする請求項１２に記載の暗号システム。
- 請求項１乃至１３のいずれか一項に記載の暗号システムを用いた暗号文処理方法であって、
前記他者である第１利用者は、自己の秘密鍵を用いて前記第１暗号文を生成し、該生成した第１暗号文を前記利用者である第２利用者に取得可能な状態とさせ、
続いて、前記第２利用者は、前記取得可能な状態とされた第１暗号文を取得し、該第１暗号文を自己の秘密鍵により更に暗号化して第２暗号文を生成し、該生成した第２暗号文を前記管理装置に送信し、
続いて、前記制御部は、前記第１暗号文取出工程、前記他者鍵使用復号工程及び前記第３暗号文生成工程をこの順に実行し、更に、第３暗号文生成工程により生成された第３暗号文を、前記第２利用者により取得可能な状態とさせ、
続いて、前記第２利用者は、前記第３暗号文を取得し、該第３暗号文を自己の秘密鍵により復号することにより、該復号結果を得ることを特徴とする暗号文処理方法。 - 請求項３乃至６のいずれか一項に記載の暗号システムを用いた暗号文処理方法であって、
前記他者である第１利用者は、自己の秘密鍵を用いて前記第１暗号文を生成し、該生成した第１暗号文を前記利用者である第２利用者に取得可能な状態とさせ、
続いて、前記第２利用者は、前記取得可能な状態とされた第１暗号文を取得し、該第１暗号文を自己の秘密鍵により更に暗号化して第２暗号文を生成し、該生成した第２暗号文に自己の識別情報を付して前記管理装置に送信し、
続いて、前記制御部は、前記第２利用者より送信された識別情報と対応する公開鍵を前記鍵管理データベースより取得し、該取得した公開鍵を用いて前記第２暗号文を復号することで前記第１暗号文取出工程を実行した後で、
前記他者鍵使用復号工程及び前記第３暗号文生成工程をこの順に実行し、更に、第３暗号文生成工程により生成された第３暗号文を、前記第２利用者により取得可能な状態とさせ、
続いて、前記第２利用者は、前記第３暗号文を取得し、該第３暗号文を自己の秘密鍵により復号することにより、該復号結果を得ることを特徴とする暗号文処理方法。 - 前記第１利用者は、前記第１暗号文及び自己の識別情報を第２利用者に取得可能な状態とさせ、
前記第２利用者は、取得した前記第１暗号文及び前記第１利用者の識別情報を自己の秘密鍵によりまとめて暗号化することにより前記第２暗号文を生成し、
前記制御部は、前記第１暗号文取出工程にて前記第１暗号文及び前記他者の識別情報を取り出し、該取り出した識別情報と対応する公開鍵を前記鍵管理データベースより取得して前記他者鍵使用復号工程での復号に用いることを特徴とする請求項１５に記載の暗号文処理方法。 - 前記第１利用者は、使い捨て鍵を生成し、この使い捨て鍵によりデータを暗号化することで暗号化データを生成する一方で、自己の秘密鍵を用いて前記使い捨て鍵を暗号化することにより前記第１暗号文を生成し、これら生成した第１暗号文及び暗号化データを前記第２利用者に取得可能な状態とさせ、
続いて、前記第２利用者は、前記取得可能な状態とされた第１暗号文及び暗号化データを取得し、このうち第１暗号文を自己の秘密鍵により更に暗号化して第２暗号文を生成し、該生成した第２暗号文を前記管理装置に送信し、
続いて、前記制御部は、前記第１暗号文取出工程及び前記他者鍵使用復号工程をこの順に実行することにより前記使い捨て鍵を取り出し、この取り出した使い捨て鍵を、前記第３暗号文生成工程にて暗号化することで前記第３暗号文を生成し、この第３暗号文を、前記第２利用者により取得可能な状態とさせ、
続いて、前記第２利用者は、前記第３暗号文を取得し、該第３暗号文を自己の秘密鍵により復号することにより前記使い捨て鍵を取り出し、この使い捨て鍵を用いて前記暗号化データを復号することにより、前記データを取り出すことを特徴とする請求項１４乃至１６のいずれか一項に記載の暗号文処理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003162813A JP3919700B2 (ja) | 2003-06-06 | 2003-06-06 | 暗号システム及びその暗号文処理方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003162813A JP3919700B2 (ja) | 2003-06-06 | 2003-06-06 | 暗号システム及びその暗号文処理方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004364188A JP2004364188A (ja) | 2004-12-24 |
| JP3919700B2 true JP3919700B2 (ja) | 2007-05-30 |
Family
ID=34054852
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003162813A Expired - Lifetime JP3919700B2 (ja) | 2003-06-06 | 2003-06-06 | 暗号システム及びその暗号文処理方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3919700B2 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9407440B2 (en) | 2013-06-20 | 2016-08-02 | Amazon Technologies, Inc. | Multiple authority data security and access |
| US11159497B2 (en) * | 2020-01-29 | 2021-10-26 | Citrix Systems, Inc. | Secure message passing using semi-trusted intermediaries |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH06152587A (ja) * | 1992-11-05 | 1994-05-31 | Nippon Telegr & Teleph Corp <Ntt> | ディジタル通信方法及びその装置 |
| JPH06276188A (ja) * | 1993-03-22 | 1994-09-30 | Toshiba Corp | 電子通信装置 |
| JP3684266B2 (ja) * | 1996-04-26 | 2005-08-17 | 株式会社日立製作所 | 暗号化された共有データのアクセス制御方法及びシステム |
| TW396308B (en) * | 1997-04-01 | 2000-07-01 | Tumbleweed Software Corp | Document delivery system |
| JPH11203431A (ja) * | 1998-01-08 | 1999-07-30 | Tamura Electric Works Ltd | Ｉｃカードシステム |
| JPH11346210A (ja) * | 1998-06-02 | 1999-12-14 | Nippon Telegr & Teleph Corp <Ntt> | 暗号化方法及び装置、復号化方法及び装置、暗号化プログラムを記録した記録媒体、復号化プログラムを記録した記録媒体、電子署名方法、並びに電子署名検証方法 |
| WO2002087146A1 (fr) * | 2001-04-18 | 2002-10-31 | Pumpkin House Incorporated | Systeme de chiffrement et procede de commande dudit systeme |
| JP3993989B2 (ja) * | 2001-04-18 | 2007-10-17 | 株式会社パンプキンハウス | 暗号システムおよびその制御方法，暗号システムにおいて用いられる鍵管理サーバおよびクライアント，ならびにこれらの制御方法 |
| JP3885882B2 (ja) * | 2002-11-18 | 2007-02-28 | 京セラミタ株式会社 | 画像形成装置および画像形成システム |
| JP3984570B2 (ja) * | 2003-02-12 | 2007-10-03 | 株式会社パンプキンハウス | 署名／検証システムにおける鍵管理サーバおよび検証装置を制御するプログラム |
-
2003
- 2003-06-06 JP JP2003162813A patent/JP3919700B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004364188A (ja) | 2004-12-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7624421B2 (en) | Method and apparatus for managing and displaying contact authentication in a peer-to-peer collaboration system | |
| JP5265744B2 (ja) | 導出鍵を用いたセキュアメッセージングシステム | |
| US7139399B1 (en) | Cryptographic system with methods for user-controlled message recovery | |
| US8813247B1 (en) | Providing cryptographic security for objective-oriented programming files | |
| CN105122265B (zh) | 数据安全服务系统 | |
| US20090041249A1 (en) | Method and system for managing a key for encryption or decryption of data | |
| EP1825632B1 (en) | Secure interface for versatile key derivation function support | |
| US20050193199A1 (en) | Accessing protected data on network storage from multiple devices | |
| CN105103488A (zh) | 借助相关联的数据的策略施行 | |
| US8281380B2 (en) | Information processing system and computer-readable recording medium | |
| JP2004304304A (ja) | 電子署名生成方法，電子署名検証方法，電子署名生成依頼プログラム，及び電子署名検証依頼プログラム | |
| JP2009100462A (ja) | 暗号管理装置、復号管理装置、およびプログラム | |
| JP6049914B2 (ja) | 暗号システム、鍵生成装置及び再暗号化装置 | |
| KR101701304B1 (ko) | 클라우드 환경에서 속성기반 암호를 이용한 의료 데이터 관리 방법 및 시스템 | |
| MXPA02008919A (es) | Sistema automatico de proteccion de identidad con verificacion remota de terceras partes. | |
| JPH09321748A (ja) | 共有暗号鍵による通信システム、同システム用サーバ装置、同システム用クライアント装置、及び通信システムにおける暗号鍵の共有方法 | |
| Sujithra et al. | ID based adaptive-key signcryption for data security in cloud environment | |
| JP2006279269A (ja) | 情報管理装置、情報管理システム、ネットワークシステム、ユーザ端末、及びこれらのプログラム | |
| JP4657706B2 (ja) | 権限管理システム、認証サーバ、権限管理方法および権限管理プログラム | |
| JP3919700B2 (ja) | 暗号システム及びその暗号文処理方法 | |
| JP3984570B2 (ja) | 署名／検証システムにおける鍵管理サーバおよび検証装置を制御するプログラム | |
| JP2002077134A (ja) | サーバ・クライアント・システム、データサーバ、データクライアント及びデータ提供・利用方法並びに記録媒体 | |
| JP2001285286A (ja) | 認証方法、記録媒体、認証システム、端末装置、及び認証用記録媒体作成装置 | |
| JP4324951B2 (ja) | パスワードシステム | |
| JP2003501878A (ja) | 公開鍵−秘密鍵のペアを安全に生成する方法及びその装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041203 |
|
| A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A711 Effective date: 20060203 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20060203 |
|
| 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: 20070115 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070213 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 3919700 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100223 Year of fee payment: 3 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100223 Year of fee payment: 3 |
|
| R371 | Transfer withdrawn |
Free format text: JAPANESE INTERMEDIATE CODE: R371 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100223 Year of fee payment: 3 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100223 Year of fee payment: 3 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130223 Year of fee payment: 6 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130223 Year of fee payment: 6 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130223 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140223 Year of fee payment: 7 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |