JP4071474B2 - 失効確認装置及び方法 - Google Patents
失効確認装置及び方法 Download PDFInfo
- Publication number
- JP4071474B2 JP4071474B2 JP2001335444A JP2001335444A JP4071474B2 JP 4071474 B2 JP4071474 B2 JP 4071474B2 JP 2001335444 A JP2001335444 A JP 2001335444A JP 2001335444 A JP2001335444 A JP 2001335444A JP 4071474 B2 JP4071474 B2 JP 4071474B2
- Authority
- JP
- Japan
- Prior art keywords
- signature
- revocation
- public key
- certificate
- key
- 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
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Storage Device Security (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、電子署名において、正当に作成された署名を不当なものとしたり、不当に作成された署名を正当なものとしたりしない失効確認装置及び方法に関するものである。
【０００２】
【従来の技術】
インターネットなどにおいて、安全にデータを送受信する仕組みとして、広く普及しているのがＰＫＩ（Public Key Infrastructure）である。ＰＫＩとしてよく知られているのが、ＩＳＯ／ＩＥＣ／ＩＴＵの勧告Ｘ．５０９である。通常、インターネットなどでデータを送受信する場合には、広く一般に公開しても問題ない公開鍵と、他人には公開しない秘密鍵の２つを利用する。公開鍵で暗号化した場合には秘密鍵で、逆に秘密鍵で暗号化した場合には公開鍵で復号化しなければならない。このような方式を公開鍵方式といい、ＰＫＩはこの公開鍵暗号の特性を用いた認証方式である。
【０００３】
実際の一般的な商取引では、お互いが信用できる者であることを示すために何らかの身分証を示すことがある。あるいは、契約を結ぶ際、書類等に捺印し、さらに、捺印した書類に当該印鑑の印鑑証明を添付することがある。この身分証や印鑑証明のような取引相手の信用を客観的に保証する第３者が電子商取引でも必要である。
【０００４】
インターネット上などでの電子商取引で、このような信用を保証する第３者に、例えば、ＣＡ（Certification Authority）がある。ＰＫＩにおいて利用される公開鍵には、ＣＡと呼ばれる第３者機関により当該鍵の証明書が発行される。ＣＡでは、ハッシュ関数を用いるなどしてメッセージダイジェストを作成し、当該メッセージダイジェストに対し、ＣＡの秘密鍵で暗号化して署名を作成する。証明書には、上述したメッセージダイジェストを取得した方法が記載される。相手の正当性やデータの正当性を検証（Verify）する場合には、証明書に記載された方法で取得したメッセージダイジェストと、公開鍵に付随する署名をＣＡの公開鍵で復号化して取得したメッセージダイジェストとを比較する。比較した結果、同一であれば、その公開鍵はＣＡの認証を受けた鍵であることがわかる。
【０００５】
このようなＰＫＩにおいて、鍵の紛失や他人への漏洩が発生した場合、秘密鍵、当該秘密鍵と対になる公開鍵、当該公開鍵の公開鍵証明書等を無効にする必要がある。これを失効（Revocation）という。ＰＫＩにおいて、公開鍵証明書は本人やデータの正当性を検証するために使用されるものであり、公開鍵証明書が失効されているか否かを知ることは重要なことである。現在、証明書の失効を知る方法がいくつか提案されている。
【０００６】
第１の方法として、ＣＲＬ（Certificate Revocation List、証明書失効リスト）という失効した証明書のリストを作成し、ＣＡなどの信頼できる機関が当該ＣＲＬを検証者に配布する方法がある。
【０００７】
また、第２の方法として、ＯＣＳＰ（Online Certificate Status Protocol）というプロトコルを利用する方法がある。この方法は、上述したＣＲＬのようなリストを信頼できる機関が所有し、検証者が電子署名の検証を行なう度に、当該機関へ証明書が有効であるかどうか問い合わせる方法である。この方法は、上述した第１の方法より、失効に関する情報を送信する通信コストが少なくて済む。。
【０００８】
ところが、上述したような方法には、いくつか問題点がある。例えば、上述第１の方法では、ＣＲＬには、すべての失効した証明書が記載されているため、そのデータ量は膨大なものとなる。従って、ＣＲＬを各検証者に送信すると、ネットワークに負荷をかけ、また、ＣＲＬが頻繁に更新された場合、ネットワーク輻輳をまねくおそれがある。また、検証者が失効を認識できるタイミングはＣＲＬを受信したときである。従って、図５に一例を示すように、時間Ｔ1で証明書を失効し、時間Ｔ3でＣＲＬを受信する間の時間Ｔ2で当該証明書の検証をした場合、本来はその証明書は無効なものであるにも係わらず、有効なものとしてしまうという問題があった。
【０００９】
また、上述した第２の方法では、検証者が失効を認識できるタイミングは、信頼できる機関に問い合わせた時である。従って、図６に一例を示すように、時間Ｔ2で証明書を失効し、時間Ｔ4で当該証明書を検証する場合、時間Ｔ3に署名された証明書を検証したのであれば、当該証明書は無効であると判断される。しかし、時間Ｔ1に署名された証明書を検証したのであれば、本来、当該証明書は有効なものであるにもかかわらず、無効であると判断するおそれがある。
【００１０】
このような問題を回避するために提案された方法がある。この方法は、Bonehらにより提案された方法であり、上述した第２の方法のように、失効に関する情報を送信する通信コストが少なくて済む。ここでは、この方法を第３の方法という。
【００１１】
この第３の方法では、証明書が有効であること（失効していないこと）を証明してもらいたい署名作成者が、信頼できる機関（以下、失効確認センタＳＥＭという）に、証明書を渡す。失効確認センタＳＥＭは、所有するＣＲＬのようなリストを参照し、当該証明書が失効していないか確認する。証明書が有効であれば署名をし、署名と証明書とを署名作成者に渡す。署名作成者は、渡された署名に自身の署名を加算し、最終的な署名を完成させるものである。
【００１２】
【発明が解決しようとする課題】
しかし、上述した第３の方法にも問題がある。例えば、図７に一例を示すように、時間Ｔ2で失効確認センタＳＥＭが署名し、時間Ｔ4で署名作成者が署名をしたものとする。この場合、時間Ｔ1で失効した場合、失効確認センタＳＥＭが証明書は無効だと認識するので、証明書には署名されない。
【００１３】
しかし、時間Ｔ3で失効（失効した証明書がＣＲＬのようなリストに記載される時）した場合、失効確認センタＳＥＭにより署名され、有効であることが証明されているので、実際は失効しているにも係わらず、当該証明書は有効なものであると認識される。
【００１４】
このように取得した署名を用いることで、証明書の正当性を検証する検証者に有効と判断される署名を取得することが可能となる。従って、本来の秘密鍵の所有者とは異なる他人が、本来の秘密鍵所有者になりすますことが可能となり、データの信頼性の低下を招くことになる。
【００１５】
また、上述した方法において、署名作成のタイミングと、失効のタイミングとのずれを検証するのにタイムスタンプを使用するという方法もあるが、各々の装置の時計は必ずしも一致しているわけではなく、従って、各装置のタイムスタンプは同一の時間を示す時計に基づいていないので、必ずしもタイムスタンプを信用することはできない。
本発明はこのような事情に鑑みてなされたもので、電子署名において、正当に作成された署名を不当なものとしたり、不当に作成された署名を正当なものとしたりしない失効確認装置及び方法を提供することを目的とする。
【００１６】
【課題を解決するための手段】
本願発明は上記の目的を解決するためになされたもので、署名作成装置の鍵に対し発行された証明書が失効しているかどうか確認する失効確認装置であって、失効した証明書に関する情報を記載した失効リストと前記失効確認装置の秘密鍵と、前記失効確認装置の公開鍵とを記憶する記憶手段と、メッセージと、該メッセージを前記署名作成装置の秘密鍵で暗号化した電子署名と、前記署名作成装置の公開鍵と、前記署名作成装置の公開鍵証明書とを、前記署名作成装置から受信する受信手段と、前記受信した公開鍵証明書と、前記記憶している失効リストとを照合する照合手段と、前記照合の結果、一致しなかった場合には前記電子署名を前記失効確認装置の秘密鍵で暗号化した署名を作成する署名作成手段と、前記電子署名を前記失効確認装置の秘密鍵で暗号化した署名を前記署名作成装置に送信する送信手段とを備えることを特徴とする。
【００１７】
また、本発明は、署名作成装置の鍵に対し発行された証明書が失効しているかどうか確認する失効確認装置であって、失効した証明書に関する情報を記載した失効リストと、前記失効確認装置の秘密鍵と、前記失効確認装置の公開鍵とを記憶する記憶手段と、メッセージに該メッセージを前記署名作成装置の秘密鍵で暗号化した電子署名を追加したものに対するハッシュ値と、前記署名作成装置の公開鍵と、前記署名作成装置の公開鍵証明書とを前記署名作成装置から受信する受信手段と、前記受信した公開鍵証明書と、前記記憶している失効リストとを照合する照合手段と、前記照合の結果、一致しなかった場合に前記ハッシュ値を前記失効確認装置の秘密鍵により暗号化した電子署名を作成する署名作成手段と、前記電子署名を前記署名作成装置に送信する送信手段とを備えることを特徴とする。
【００１８】
また、本発明は、署名作成装置の鍵に対し発行された証明書が失効しているかどうか確認する失効確認方法であって、失効した証明書に関する情報を記載した失効リストと前記失効確認装置の秘密鍵と、前記失効確認装置の公開鍵とを記憶する過程と、メッセージと、該メッセージを前記署名作成装置の秘密鍵で暗号化した電子署名と、前記署名作成装置の公開鍵と、前記署名作成装置の公開鍵証明書とを、前記署名作成装置から受信する過程と、前記受信した公開鍵証明書と、前記記憶している失効リストとを照合する過程と、前記照合の結果、一致しなかった場合には前記電子署名を前記失効確認装置の秘密鍵で暗号化した署名を作成する過程と、前記電子署名を前記失効確認装置の秘密鍵で暗号化した署名を前記署名作成装置に送信する送信手段とを有することを特徴とする。
【００１９】
【発明の実施の形態】
以下、図面を参照し、本発明の一実施形態について説明する。
まず、Bonehらによる公開鍵証明方法（上述した第３の方法）について図８を参照して説明する。
【００２０】
ここでは、署名作成者をＳ、失効確認センタをＳＥＭ、署名検証者をＶとして説明する。なお、署名作成者Ｓとは、例えば、インターネット上にウェブサイトを提供する管理者の装置等のことである。また、失効確認センタＳＥＭとは、例えば、ＣＡなどの信頼できる機関の装置等のことである。また、署名検証者Ｖとは、例えば、署名作成者Ｓの提供するウェブサイトにアクセスし、データを送信するユーザの装置等のことである。
【００２１】
署名作成者Ｓは、メッセージｍ、部分秘密鍵ＳｋＳ1、部分秘密鍵ＳｋＳ1を構成要素とする秘密鍵ＳｋＳに対応する公開鍵ＰｋＳ、この公開鍵ＰｋＳの公開鍵証明書等を記憶している。ここでは、秘密鍵ＳｋＳは、ＳｋＳ＝ＳｋＳ1＋ＳｋＳ2というように取得される。ＳｋＳ1とは、署名作成者Ｓの所有する部分秘密鍵のことであり、ＳｋＳ2とは、失効確認センタＳＥＭの所有する部分秘密鍵のことである。このような秘密鍵ＳｋＳの分割は、例えばＣＡのような信頼できる第３者機関により実施される。署名作成者Ｓは、公開鍵証明書に記載されている方法に従って、メッセージｍのハッシュ値ｈ（ｍ）を取得する。次に、公開鍵証明書のＩＤと、取得したメッセージｍのハッシュ値ｈ（ｍ）とを、失効確認センタＳＥＭに送信する（１）。
【００２２】
失効確認センタＳＥＭでは、署名作成者Ｓに対応する失効センタＳＥＭが所有する部分秘密鍵ＳｋＳ2、秘密鍵ＳｋＳに対応する公開鍵ＰｋＳ、公開鍵ＰｋＳの公開鍵証明書、ＳＥＭ自身の秘密鍵ＳｋＳＥＭ、ＳＥＭ自身の公開鍵ＰｋＳＥＭ等を所有している。また、失効確認センタＳＥＭでは、失効した鍵の証明書のＩＤを記載したリストを所有している。ここでは、このリストを失効リストという。
【００２３】
失効確認センタＳＥＭは、公開鍵証明書のＩＤと、メッセージｍのハッシュ値ｈ（ｍ）とを受信すると、受信した公開鍵証明書のＩＤと、失効リストとを比較し、受信した公開鍵証明書のＩＤが有効かどうか確認する（２）。有効であると確認された場合、メッセージｍのハッシュ値ｈ（ｍ）を、失効管理センタＳＥＭの所有する部分秘密鍵ＳｋＳ2により暗号化して、署名Ｓｉｇ1＝Ｅｎｃ＜ＳｋＳ2＞｛ｈ（ｍ）｝を作成し、作成した署名Ｓｉｇ1を署名作成者Ｓに送信する（３）。
【００２４】
署名作成者Ｓでは、上述と同様に、メッセージｍのハッシュ値ｈ（ｍ）を取得し、当該ハッシュ値ｈ（ｍ）を、署名作成者の部分秘密鍵ＳｋＳ1で暗号化した署名Ｓｉｇ2＝Ｅｎｃ＜ＳｋＳ1＞｛ｈ（ｍ）｝を作成する（４）。さらに、署名作成者Ｓは、失効確認センタＳＥＭから送信された署名Ｓｉｇ1に、自身が作成した署名Ｓｉｇ2を付加する（単純に足し算する）ことで、署名Ｓｉｇ＝Ｓｉｇ1＋Ｓｉｇ2を取得する（５）。このように取得した署名Ｓｉｇが検証に用いられる。
【００２５】
署名作成者Ｓは、署名Ｓｉｇ、メッセージｍ、公開鍵ＰｋＳ、公開鍵ＰｋＳの公開鍵証明書等を署名検証者Ｖに送信する（６）。署名検証者Ｖは、予め、失効確認センタＳＥＭの秘密鍵ＳｋＳＥＭに対応する公開鍵ＰｋＳＥＭを所有している。署名検証者Ｖは、公開鍵ＰｋＳの公開鍵証明書に記載されている方法に従って、メッセージｍのハッシュ値ｈ（ｍ）を取得する。次に、署名作成者Ｓの公開鍵ＰｋＳを利用して、署名Ｓｉｇを復号化し、暗号化されていたメッセージｍのハッシュ値ｈ（ｍ）を取得する。メッセージｍから取得したハッシュ値ｈ（ｍ）と、復号化することにより取得したハッシュ値ｈ（ｍ）とを比較し、一致すれば、署名作成者Ｓの公開鍵ＰｋＳは正当であると認識する。一致しなかった場合、署名作成者Ｓの公開鍵ＰｋＳは正当でないと認識する（７）。
【００２６】
以上が、Bonehらによる公開鍵証明方法である。本実施形態は、上述したBonehらによる公開鍵証明方法において生じるタイムラグをなくすためのものである。まず、本実施形態のシステム構成を図１を参照して説明する。図１において、１は失効確認装置であり、上述した失効確認センタＳＥＭと同等である。２は署名作成装置であり、上述した署名作成者Ｓと同等である。３は署名検証装置であり、上述した署名検証者と同等である。失効確認装置１、署名作成装置２、署名検証装置３は、各々インターネット等の通信ネットワーク（図示略）に接続され、通信ネットワークを介して互いにデータの送受信をすることができる。
【００２７】
図２に失効確認装置１の構成を示すブロック図である。この図において、１１はメモリであり、失効した証明書のリスト（以下、失効リストとする）等を格納している。１２は通信インターフェースである。１３は照合部である。１４は署名作成部である。
【００２８】
図３に、メモリ１１に格納されている失効リストの一例を示す。この図に示すように、失効リストには、失効した公開鍵証明書を一意に識別するＩＤ等が記載されている。この失効リストは、失効の申請がある度に更新され、常に最新の情報が格納されている。また、メモリ１１には、失効確認装置１（失効確認センタＳＥＭ）の秘密鍵ＰｋＳＥＭ、当該秘密鍵に対応する公開鍵ＳｋＳＥＭ、当該公開鍵の公開鍵証明書ＣｅｒｔSEM等が格納されている。
【００２９】
図４を参照して動作を説明する。あらかじめ、署名作成装置２（署名作成者Ｓ）は、署名作成者Ｓの秘密鍵ＳｋＳ、当該秘密鍵に対応する公開鍵ＰｋＳ、当該公開鍵の公開鍵証明書ＣｅｒｔS、メッセージｍ、失効確認センタＳＥＭの公開鍵ＰｋＳＥＭをメモリ等に格納している。
署名作成装置２は、メッセージｍを、署名作装置２の秘密鍵ＳｋＳで暗号化し、署名Ｓｉｇ1＝Ｅｎｃ＜ＳｋＳ＞｛ｈ（ｍ）｝を作成する（図４におけるステップＳ１０）。次に、メッセージｍ、作成した署名Ｓｉｇ1、公開鍵証明書ＣｅｒｔS、公開鍵ＰｋＳを、失効確認装置１（失効確認センタＳＥＭ）に送信する（図４におけるステップＳ１１）。
【００３０】
ここで、失効確認装置１に送信するメッセージｍ、署名Ｓｉｇ1のかわりに、ハッシュ値ｈ（ｍ‖Ｓｉｇ1）でもよい。なお、（ｍ‖Ｓｉｇ1）とは、メッセージｍに署名Ｓｉｇ1を追加（単純に結合）したものであり、ハッシュ値ｈ（ｍ‖Ｓｉｇ1）とは、メッセージｍに署名Ｓｉｇ1を追加したものに対するハッシュ値を示す。このハッシュ値は、公開鍵証明書ＣｅｒｔSに記載されている手順で取得されるものとする。
【００３１】
失効確認装置１の照合部１３は、受信した公開鍵証明書ＣｅｒｔSのＩＤを、メモリ１１に格納している失効リストと照合し（図４におけるステップＳ１２）、当該公開鍵証明書ＣｅｒｔSが失効しているかどうか確認する。照合の結果、受信した公開鍵証明書ＣｅｒｔSのＩＤと同じＩＤが失効リストに記載されていれば、署名作成装置１にエラーを返す（図４におけるステップＳ１３、ステップＳ１４）。照合の結果、受信した公開鍵証明書ＣｅｒｔSのＩＤと同じＩＤが失効リストに記載されていなければ、署名作成部１４に署名作成を指示する。
【００３２】
署名作成部１４は、署名作成装置２から送信された署名Ｓｉｇ1＝Ｅｎｃ＜ＳｋＳ＞｛ｈ（ｍ）｝を、失効確認装置１（失効確認センタＳＥＭ）の秘密鍵ＳｋＳＥＭで暗号化し、署名Ｓｉｇ2＝Ｅｎｃ＜ＳｋＳＥＭ＞｛Ｓｉｇ1｝を作成する（図４におけるステップＳ１５）。次に、作成した署名Ｓｉｇ2を、署名作成装置２に送信する。
【００３３】
なお、ここで、署名作成装置２から送信されたデータが、ハッシュ値ｈ（ｍ‖Ｓｉｇ1）、公開鍵証明書ＣｅｒｔS、公開鍵ＰｋＳであった場合、署名作成部１４は、署名Ｓｉｇ2＝Ｅｎｃ＜ＳｋＳＥＭ＞｛ｈ（ｍ‖Ｓｉｇ1）｝を作成し、署名作成装置２に送信する。
【００３４】
署名作成装置２は、署名Ｓｉｇ2を受信すると、当該署名を検証（Ｖｒｆ＜ＰｋＳＥＭ＞｛Ｓｉｇ2｝）する（図４におけるステップＳ１７）。そのために、まず、メモリ等に格納している失効確認センタＳＥＭの公開鍵ＰｋＳＥＭを用いて、受信した署名Ｓｉｇ2を復号化する。受信した署名Ｓｉｇ2が正当なものであれば、Ｓｉｇ1が取得できる。次に、メッセージｍから取得したハッシュ値ｈ（ｍ）を自身の秘密鍵ＳｋＳで暗号化した署名Ｓｉｇ1と、署名Ｓｉｇ2を復号化することにより取得した値とを比較する。
【００３５】
比較の結果、一致しなければ、その署名Ｓｉｇ2は不当なものと判断され、エラーとなる（図４におけるステップＳ１８、ステップＳ１９）。比較の結果、一致すれば、当該署名Ｓｉｇ2は正当なものだと認証される。署名Ｓｉｇ2の正当性が認証されると、署名作成装置２は、最終的な署名Ｓｉｇ＝Ｓｉｇ1‖Ｓｉｇ2（Ｓｉｇ1とＳｉｇ2とを単純に結合する）を作成する（図４におけるステップＳ２０）。
署名作成装置２は、署名検証装置３（署名検証者Ｖ）から要求をうけた場合、署名Ｓｉｇ、公開鍵ＰｋＳ、メッセージｍ、公開鍵証明書ＣｅｒｔS等を送信する（図４におけるステップＳ２１）。
【００３６】
署名検証装置３は、予め、失効確認装置１（失効確認センタＳＥＭ）の公開鍵ＰｋＳＥＭをメモリ等に記憶している。署名検証装置３は公開鍵証明書ＣｅｒｔSを検証するために（図４におけるステップＳ２１）、受信した署名Ｓｉｇ＝Ｓｉｇ1‖Ｓｉｇ2からＳｉｇ2を取り出す。次に、取り出した署名Ｓｉｇ2を、メモリ等に記憶している失効確認装置１の公開鍵ＰｋＳＥＭにより復号化する。署名Ｓｉｇが正しいものであれば、署名Ｓｉｇ2は署名Ｓｉｇ1を失効確認装置１の秘密鍵ＳｋＳＥＭで暗号化したもの（署名Ｓｉｇ2＝Ｅｎｃ＜ＳｋＳＥＭ＞｛Ｓｉｇ1｝）であるので、署名Ｓｉｇ1＝Ｅｎｃ＜ＳｋＳ＞｛ｈ（ｍ）｝を取得できる。
【００３７】
次に、署名検証装置３は、受信した署名Ｓｉｇ＝Ｓｉｇ1‖Ｓｉｇ2からＳｉｇ1を取り出す。署名Ｓｉｇ1が正しいものであれば、署名Ｓｉｇ1はメッセージｍのハッシュ値ｈ（Ｍ）を署名作成装置２（署名作成者Ｓ）の秘密鍵ＳｋＳで暗号化したもの（署名Ｓｉｇ1＝Ｅｎｃ＜ＳｋＳ＞｛ｈ（ｍ）｝）を取得できる。
署名検証者３は、署名Ｓｉｇ2を復号化することにより取得した値と、署名Ｓｉｇ1とを比較する。一致すれば、署名Ｓｉｇは、失効確認装置１（失効確認センタＳＥＭ）の認証をうけた署名であると認識する。一致しなければ、当該署名は、失効確認装置１の認証を受けた署名でないと認識し、エラーを返すなどする。また、署名Ｓｉｇ2は、署名Ｓｉｇ1を用いて作成するものなので、署名検証装置３は、署名Ｓｉｇ2と署名Ｓｉｇ1とが一致した場合、署名Ｓｉｇ2が署名Ｓｉｇ1より後に作成されたことが認識できる。
【００３８】
なお、署名Ｓｉｇ2を復号化することにより取得した値と、署名Ｓｉｇ1とを、署名作成装置２の公開鍵ＰｋＳにより各々復号化して取得した値を比較することにより、当該署名が失効確認装置１の認証を受けた署名であるかどうか判断してもよい。
【００３９】
なお、署名Ｓｉｇを構成する署名Ｓｉｇ2が署名Ｓｉｇ2＝Ｅｎｃ＜ＳｋＳＥＭ＞｛ｈ（ｍ‖Ｓｉｇ1）｝である場合、署名検証者３は、取り出した署名Ｓｉｇ2を、まず、失効確認装置１の公開鍵ＰｋＳＥＭにより復号化する。また、メッセージｍに署名Ｓｉｇ1を追加（単純に結合）してｍ‖Ｓｉｇ1を取得した値から、署名作成装置２の公開鍵証明書ＣｅｒｔSに記載された手段に従ってハッシュ値ｈ（ｍ‖Ｓｉｇ1）を取得する。署名Ｓｉｇ2を公開鍵ＰｋＳＥＭにより復号するこよにより取得した値と、公開鍵証明書ＣｅｒｔSに記載された手段に従って取得したハッシュ値ｈ（ｍ‖Ｓｉｇ1）とを比較し、一致すれば、署名Ｓｉｇは、失効確認装置１（失効確認センタＳＥＭ）の認証をうけた署名であると認識する。
【００４０】
なお、メモリ１１は、ハードディスク装置や光磁気ディスク装置、フラッシュメモリ等の不揮発性のメモリや、ＣＤ−ＲＯＭ等の読み出しのみが可能な記憶媒体、ＲＡＭ（Random Access Memory）のような揮発性のメモリ、あるいはこれらの組み合わせにより構成されるもとのする。
【００４１】
なお、図２に示す各部は専用のハードウェアにより実現されるものであってもよく、また、この各部はメモリおよびＣＰＵ（中央演算装置）により構成され、各部の機能を実現するためのプログラムをメモリにロードして実行することによりその機能を実現させるものであってもよい。
【００４２】
また、図２における各部の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより実現させてもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。
また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
【００４３】
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。
以上、この発明の実施形態を図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計変更等も含まれる。
【００４４】
【発明の効果】
以上説明したように、本発明による署名作成装置によれば、公開鍵証明書の失効に関する情報を配布する通信コストが少ないという従来の方式の利点を保ちながら、失効と署名作成とのタイミングの関係を正しく認識できるＰＫＩを構築することができる。従来の方法では、不正に作成された署名が付随するデータを正しいものと認識したり、正当に作成された署名が付随するデータを不正なものと拒否する可能性があり、不正が発生するたびに、システムを停止し、不正発生の原因を探る必要がある。本発明により、このようにシステムを停止する必要が無くなり、システム運用のコストを低減することができ、また、ＰＫＩに基づくデータの信頼性を高めることができる。
【図面の簡単な説明】
【図１】 本発明の一実施形態において、システム構成を示す図である。
【図２】 同実施形態において、失効確認装置の構成を示すブロック図である。
【図３】 同実施形態において、メモリに格納されている失効リストの一例である。
【図４】 同実施形態において、動作を説明する図である。
【図５】 従来技術を説明する図である。
【図６】 従来技術を説明する図である。
【図７】 従来技術を説明する図である。
【図８】 従来技術を説明する図である。
【符号の説明】
１：失効確認装置、２：署名作成装置、３：署名検証装置、１１：メモリ、１２：通信インターフェース、１３：照合部、１４：署名作成部
【発明の属する技術分野】
本発明は、電子署名において、正当に作成された署名を不当なものとしたり、不当に作成された署名を正当なものとしたりしない失効確認装置及び方法に関するものである。
【０００２】
【従来の技術】
インターネットなどにおいて、安全にデータを送受信する仕組みとして、広く普及しているのがＰＫＩ（Public Key Infrastructure）である。ＰＫＩとしてよく知られているのが、ＩＳＯ／ＩＥＣ／ＩＴＵの勧告Ｘ．５０９である。通常、インターネットなどでデータを送受信する場合には、広く一般に公開しても問題ない公開鍵と、他人には公開しない秘密鍵の２つを利用する。公開鍵で暗号化した場合には秘密鍵で、逆に秘密鍵で暗号化した場合には公開鍵で復号化しなければならない。このような方式を公開鍵方式といい、ＰＫＩはこの公開鍵暗号の特性を用いた認証方式である。
【０００３】
実際の一般的な商取引では、お互いが信用できる者であることを示すために何らかの身分証を示すことがある。あるいは、契約を結ぶ際、書類等に捺印し、さらに、捺印した書類に当該印鑑の印鑑証明を添付することがある。この身分証や印鑑証明のような取引相手の信用を客観的に保証する第３者が電子商取引でも必要である。
【０００４】
インターネット上などでの電子商取引で、このような信用を保証する第３者に、例えば、ＣＡ（Certification Authority）がある。ＰＫＩにおいて利用される公開鍵には、ＣＡと呼ばれる第３者機関により当該鍵の証明書が発行される。ＣＡでは、ハッシュ関数を用いるなどしてメッセージダイジェストを作成し、当該メッセージダイジェストに対し、ＣＡの秘密鍵で暗号化して署名を作成する。証明書には、上述したメッセージダイジェストを取得した方法が記載される。相手の正当性やデータの正当性を検証（Verify）する場合には、証明書に記載された方法で取得したメッセージダイジェストと、公開鍵に付随する署名をＣＡの公開鍵で復号化して取得したメッセージダイジェストとを比較する。比較した結果、同一であれば、その公開鍵はＣＡの認証を受けた鍵であることがわかる。
【０００５】
このようなＰＫＩにおいて、鍵の紛失や他人への漏洩が発生した場合、秘密鍵、当該秘密鍵と対になる公開鍵、当該公開鍵の公開鍵証明書等を無効にする必要がある。これを失効（Revocation）という。ＰＫＩにおいて、公開鍵証明書は本人やデータの正当性を検証するために使用されるものであり、公開鍵証明書が失効されているか否かを知ることは重要なことである。現在、証明書の失効を知る方法がいくつか提案されている。
【０００６】
第１の方法として、ＣＲＬ（Certificate Revocation List、証明書失効リスト）という失効した証明書のリストを作成し、ＣＡなどの信頼できる機関が当該ＣＲＬを検証者に配布する方法がある。
【０００７】
また、第２の方法として、ＯＣＳＰ（Online Certificate Status Protocol）というプロトコルを利用する方法がある。この方法は、上述したＣＲＬのようなリストを信頼できる機関が所有し、検証者が電子署名の検証を行なう度に、当該機関へ証明書が有効であるかどうか問い合わせる方法である。この方法は、上述した第１の方法より、失効に関する情報を送信する通信コストが少なくて済む。。
【０００８】
ところが、上述したような方法には、いくつか問題点がある。例えば、上述第１の方法では、ＣＲＬには、すべての失効した証明書が記載されているため、そのデータ量は膨大なものとなる。従って、ＣＲＬを各検証者に送信すると、ネットワークに負荷をかけ、また、ＣＲＬが頻繁に更新された場合、ネットワーク輻輳をまねくおそれがある。また、検証者が失効を認識できるタイミングはＣＲＬを受信したときである。従って、図５に一例を示すように、時間Ｔ1で証明書を失効し、時間Ｔ3でＣＲＬを受信する間の時間Ｔ2で当該証明書の検証をした場合、本来はその証明書は無効なものであるにも係わらず、有効なものとしてしまうという問題があった。
【０００９】
また、上述した第２の方法では、検証者が失効を認識できるタイミングは、信頼できる機関に問い合わせた時である。従って、図６に一例を示すように、時間Ｔ2で証明書を失効し、時間Ｔ4で当該証明書を検証する場合、時間Ｔ3に署名された証明書を検証したのであれば、当該証明書は無効であると判断される。しかし、時間Ｔ1に署名された証明書を検証したのであれば、本来、当該証明書は有効なものであるにもかかわらず、無効であると判断するおそれがある。
【００１０】
このような問題を回避するために提案された方法がある。この方法は、Bonehらにより提案された方法であり、上述した第２の方法のように、失効に関する情報を送信する通信コストが少なくて済む。ここでは、この方法を第３の方法という。
【００１１】
この第３の方法では、証明書が有効であること（失効していないこと）を証明してもらいたい署名作成者が、信頼できる機関（以下、失効確認センタＳＥＭという）に、証明書を渡す。失効確認センタＳＥＭは、所有するＣＲＬのようなリストを参照し、当該証明書が失効していないか確認する。証明書が有効であれば署名をし、署名と証明書とを署名作成者に渡す。署名作成者は、渡された署名に自身の署名を加算し、最終的な署名を完成させるものである。
【００１２】
【発明が解決しようとする課題】
しかし、上述した第３の方法にも問題がある。例えば、図７に一例を示すように、時間Ｔ2で失効確認センタＳＥＭが署名し、時間Ｔ4で署名作成者が署名をしたものとする。この場合、時間Ｔ1で失効した場合、失効確認センタＳＥＭが証明書は無効だと認識するので、証明書には署名されない。
【００１３】
しかし、時間Ｔ3で失効（失効した証明書がＣＲＬのようなリストに記載される時）した場合、失効確認センタＳＥＭにより署名され、有効であることが証明されているので、実際は失効しているにも係わらず、当該証明書は有効なものであると認識される。
【００１４】
このように取得した署名を用いることで、証明書の正当性を検証する検証者に有効と判断される署名を取得することが可能となる。従って、本来の秘密鍵の所有者とは異なる他人が、本来の秘密鍵所有者になりすますことが可能となり、データの信頼性の低下を招くことになる。
【００１５】
また、上述した方法において、署名作成のタイミングと、失効のタイミングとのずれを検証するのにタイムスタンプを使用するという方法もあるが、各々の装置の時計は必ずしも一致しているわけではなく、従って、各装置のタイムスタンプは同一の時間を示す時計に基づいていないので、必ずしもタイムスタンプを信用することはできない。
本発明はこのような事情に鑑みてなされたもので、電子署名において、正当に作成された署名を不当なものとしたり、不当に作成された署名を正当なものとしたりしない失効確認装置及び方法を提供することを目的とする。
【００１６】
【課題を解決するための手段】
本願発明は上記の目的を解決するためになされたもので、署名作成装置の鍵に対し発行された証明書が失効しているかどうか確認する失効確認装置であって、失効した証明書に関する情報を記載した失効リストと前記失効確認装置の秘密鍵と、前記失効確認装置の公開鍵とを記憶する記憶手段と、メッセージと、該メッセージを前記署名作成装置の秘密鍵で暗号化した電子署名と、前記署名作成装置の公開鍵と、前記署名作成装置の公開鍵証明書とを、前記署名作成装置から受信する受信手段と、前記受信した公開鍵証明書と、前記記憶している失効リストとを照合する照合手段と、前記照合の結果、一致しなかった場合には前記電子署名を前記失効確認装置の秘密鍵で暗号化した署名を作成する署名作成手段と、前記電子署名を前記失効確認装置の秘密鍵で暗号化した署名を前記署名作成装置に送信する送信手段とを備えることを特徴とする。
【００１７】
また、本発明は、署名作成装置の鍵に対し発行された証明書が失効しているかどうか確認する失効確認装置であって、失効した証明書に関する情報を記載した失効リストと、前記失効確認装置の秘密鍵と、前記失効確認装置の公開鍵とを記憶する記憶手段と、メッセージに該メッセージを前記署名作成装置の秘密鍵で暗号化した電子署名を追加したものに対するハッシュ値と、前記署名作成装置の公開鍵と、前記署名作成装置の公開鍵証明書とを前記署名作成装置から受信する受信手段と、前記受信した公開鍵証明書と、前記記憶している失効リストとを照合する照合手段と、前記照合の結果、一致しなかった場合に前記ハッシュ値を前記失効確認装置の秘密鍵により暗号化した電子署名を作成する署名作成手段と、前記電子署名を前記署名作成装置に送信する送信手段とを備えることを特徴とする。
【００１８】
また、本発明は、署名作成装置の鍵に対し発行された証明書が失効しているかどうか確認する失効確認方法であって、失効した証明書に関する情報を記載した失効リストと前記失効確認装置の秘密鍵と、前記失効確認装置の公開鍵とを記憶する過程と、メッセージと、該メッセージを前記署名作成装置の秘密鍵で暗号化した電子署名と、前記署名作成装置の公開鍵と、前記署名作成装置の公開鍵証明書とを、前記署名作成装置から受信する過程と、前記受信した公開鍵証明書と、前記記憶している失効リストとを照合する過程と、前記照合の結果、一致しなかった場合には前記電子署名を前記失効確認装置の秘密鍵で暗号化した署名を作成する過程と、前記電子署名を前記失効確認装置の秘密鍵で暗号化した署名を前記署名作成装置に送信する送信手段とを有することを特徴とする。
【００１９】
【発明の実施の形態】
以下、図面を参照し、本発明の一実施形態について説明する。
まず、Bonehらによる公開鍵証明方法（上述した第３の方法）について図８を参照して説明する。
【００２０】
ここでは、署名作成者をＳ、失効確認センタをＳＥＭ、署名検証者をＶとして説明する。なお、署名作成者Ｓとは、例えば、インターネット上にウェブサイトを提供する管理者の装置等のことである。また、失効確認センタＳＥＭとは、例えば、ＣＡなどの信頼できる機関の装置等のことである。また、署名検証者Ｖとは、例えば、署名作成者Ｓの提供するウェブサイトにアクセスし、データを送信するユーザの装置等のことである。
【００２１】
署名作成者Ｓは、メッセージｍ、部分秘密鍵ＳｋＳ1、部分秘密鍵ＳｋＳ1を構成要素とする秘密鍵ＳｋＳに対応する公開鍵ＰｋＳ、この公開鍵ＰｋＳの公開鍵証明書等を記憶している。ここでは、秘密鍵ＳｋＳは、ＳｋＳ＝ＳｋＳ1＋ＳｋＳ2というように取得される。ＳｋＳ1とは、署名作成者Ｓの所有する部分秘密鍵のことであり、ＳｋＳ2とは、失効確認センタＳＥＭの所有する部分秘密鍵のことである。このような秘密鍵ＳｋＳの分割は、例えばＣＡのような信頼できる第３者機関により実施される。署名作成者Ｓは、公開鍵証明書に記載されている方法に従って、メッセージｍのハッシュ値ｈ（ｍ）を取得する。次に、公開鍵証明書のＩＤと、取得したメッセージｍのハッシュ値ｈ（ｍ）とを、失効確認センタＳＥＭに送信する（１）。
【００２２】
失効確認センタＳＥＭでは、署名作成者Ｓに対応する失効センタＳＥＭが所有する部分秘密鍵ＳｋＳ2、秘密鍵ＳｋＳに対応する公開鍵ＰｋＳ、公開鍵ＰｋＳの公開鍵証明書、ＳＥＭ自身の秘密鍵ＳｋＳＥＭ、ＳＥＭ自身の公開鍵ＰｋＳＥＭ等を所有している。また、失効確認センタＳＥＭでは、失効した鍵の証明書のＩＤを記載したリストを所有している。ここでは、このリストを失効リストという。
【００２３】
失効確認センタＳＥＭは、公開鍵証明書のＩＤと、メッセージｍのハッシュ値ｈ（ｍ）とを受信すると、受信した公開鍵証明書のＩＤと、失効リストとを比較し、受信した公開鍵証明書のＩＤが有効かどうか確認する（２）。有効であると確認された場合、メッセージｍのハッシュ値ｈ（ｍ）を、失効管理センタＳＥＭの所有する部分秘密鍵ＳｋＳ2により暗号化して、署名Ｓｉｇ1＝Ｅｎｃ＜ＳｋＳ2＞｛ｈ（ｍ）｝を作成し、作成した署名Ｓｉｇ1を署名作成者Ｓに送信する（３）。
【００２４】
署名作成者Ｓでは、上述と同様に、メッセージｍのハッシュ値ｈ（ｍ）を取得し、当該ハッシュ値ｈ（ｍ）を、署名作成者の部分秘密鍵ＳｋＳ1で暗号化した署名Ｓｉｇ2＝Ｅｎｃ＜ＳｋＳ1＞｛ｈ（ｍ）｝を作成する（４）。さらに、署名作成者Ｓは、失効確認センタＳＥＭから送信された署名Ｓｉｇ1に、自身が作成した署名Ｓｉｇ2を付加する（単純に足し算する）ことで、署名Ｓｉｇ＝Ｓｉｇ1＋Ｓｉｇ2を取得する（５）。このように取得した署名Ｓｉｇが検証に用いられる。
【００２５】
署名作成者Ｓは、署名Ｓｉｇ、メッセージｍ、公開鍵ＰｋＳ、公開鍵ＰｋＳの公開鍵証明書等を署名検証者Ｖに送信する（６）。署名検証者Ｖは、予め、失効確認センタＳＥＭの秘密鍵ＳｋＳＥＭに対応する公開鍵ＰｋＳＥＭを所有している。署名検証者Ｖは、公開鍵ＰｋＳの公開鍵証明書に記載されている方法に従って、メッセージｍのハッシュ値ｈ（ｍ）を取得する。次に、署名作成者Ｓの公開鍵ＰｋＳを利用して、署名Ｓｉｇを復号化し、暗号化されていたメッセージｍのハッシュ値ｈ（ｍ）を取得する。メッセージｍから取得したハッシュ値ｈ（ｍ）と、復号化することにより取得したハッシュ値ｈ（ｍ）とを比較し、一致すれば、署名作成者Ｓの公開鍵ＰｋＳは正当であると認識する。一致しなかった場合、署名作成者Ｓの公開鍵ＰｋＳは正当でないと認識する（７）。
【００２６】
以上が、Bonehらによる公開鍵証明方法である。本実施形態は、上述したBonehらによる公開鍵証明方法において生じるタイムラグをなくすためのものである。まず、本実施形態のシステム構成を図１を参照して説明する。図１において、１は失効確認装置であり、上述した失効確認センタＳＥＭと同等である。２は署名作成装置であり、上述した署名作成者Ｓと同等である。３は署名検証装置であり、上述した署名検証者と同等である。失効確認装置１、署名作成装置２、署名検証装置３は、各々インターネット等の通信ネットワーク（図示略）に接続され、通信ネットワークを介して互いにデータの送受信をすることができる。
【００２７】
図２に失効確認装置１の構成を示すブロック図である。この図において、１１はメモリであり、失効した証明書のリスト（以下、失効リストとする）等を格納している。１２は通信インターフェースである。１３は照合部である。１４は署名作成部である。
【００２８】
図３に、メモリ１１に格納されている失効リストの一例を示す。この図に示すように、失効リストには、失効した公開鍵証明書を一意に識別するＩＤ等が記載されている。この失効リストは、失効の申請がある度に更新され、常に最新の情報が格納されている。また、メモリ１１には、失効確認装置１（失効確認センタＳＥＭ）の秘密鍵ＰｋＳＥＭ、当該秘密鍵に対応する公開鍵ＳｋＳＥＭ、当該公開鍵の公開鍵証明書ＣｅｒｔSEM等が格納されている。
【００２９】
図４を参照して動作を説明する。あらかじめ、署名作成装置２（署名作成者Ｓ）は、署名作成者Ｓの秘密鍵ＳｋＳ、当該秘密鍵に対応する公開鍵ＰｋＳ、当該公開鍵の公開鍵証明書ＣｅｒｔS、メッセージｍ、失効確認センタＳＥＭの公開鍵ＰｋＳＥＭをメモリ等に格納している。
署名作成装置２は、メッセージｍを、署名作装置２の秘密鍵ＳｋＳで暗号化し、署名Ｓｉｇ1＝Ｅｎｃ＜ＳｋＳ＞｛ｈ（ｍ）｝を作成する（図４におけるステップＳ１０）。次に、メッセージｍ、作成した署名Ｓｉｇ1、公開鍵証明書ＣｅｒｔS、公開鍵ＰｋＳを、失効確認装置１（失効確認センタＳＥＭ）に送信する（図４におけるステップＳ１１）。
【００３０】
ここで、失効確認装置１に送信するメッセージｍ、署名Ｓｉｇ1のかわりに、ハッシュ値ｈ（ｍ‖Ｓｉｇ1）でもよい。なお、（ｍ‖Ｓｉｇ1）とは、メッセージｍに署名Ｓｉｇ1を追加（単純に結合）したものであり、ハッシュ値ｈ（ｍ‖Ｓｉｇ1）とは、メッセージｍに署名Ｓｉｇ1を追加したものに対するハッシュ値を示す。このハッシュ値は、公開鍵証明書ＣｅｒｔSに記載されている手順で取得されるものとする。
【００３１】
失効確認装置１の照合部１３は、受信した公開鍵証明書ＣｅｒｔSのＩＤを、メモリ１１に格納している失効リストと照合し（図４におけるステップＳ１２）、当該公開鍵証明書ＣｅｒｔSが失効しているかどうか確認する。照合の結果、受信した公開鍵証明書ＣｅｒｔSのＩＤと同じＩＤが失効リストに記載されていれば、署名作成装置１にエラーを返す（図４におけるステップＳ１３、ステップＳ１４）。照合の結果、受信した公開鍵証明書ＣｅｒｔSのＩＤと同じＩＤが失効リストに記載されていなければ、署名作成部１４に署名作成を指示する。
【００３２】
署名作成部１４は、署名作成装置２から送信された署名Ｓｉｇ1＝Ｅｎｃ＜ＳｋＳ＞｛ｈ（ｍ）｝を、失効確認装置１（失効確認センタＳＥＭ）の秘密鍵ＳｋＳＥＭで暗号化し、署名Ｓｉｇ2＝Ｅｎｃ＜ＳｋＳＥＭ＞｛Ｓｉｇ1｝を作成する（図４におけるステップＳ１５）。次に、作成した署名Ｓｉｇ2を、署名作成装置２に送信する。
【００３３】
なお、ここで、署名作成装置２から送信されたデータが、ハッシュ値ｈ（ｍ‖Ｓｉｇ1）、公開鍵証明書ＣｅｒｔS、公開鍵ＰｋＳであった場合、署名作成部１４は、署名Ｓｉｇ2＝Ｅｎｃ＜ＳｋＳＥＭ＞｛ｈ（ｍ‖Ｓｉｇ1）｝を作成し、署名作成装置２に送信する。
【００３４】
署名作成装置２は、署名Ｓｉｇ2を受信すると、当該署名を検証（Ｖｒｆ＜ＰｋＳＥＭ＞｛Ｓｉｇ2｝）する（図４におけるステップＳ１７）。そのために、まず、メモリ等に格納している失効確認センタＳＥＭの公開鍵ＰｋＳＥＭを用いて、受信した署名Ｓｉｇ2を復号化する。受信した署名Ｓｉｇ2が正当なものであれば、Ｓｉｇ1が取得できる。次に、メッセージｍから取得したハッシュ値ｈ（ｍ）を自身の秘密鍵ＳｋＳで暗号化した署名Ｓｉｇ1と、署名Ｓｉｇ2を復号化することにより取得した値とを比較する。
【００３５】
比較の結果、一致しなければ、その署名Ｓｉｇ2は不当なものと判断され、エラーとなる（図４におけるステップＳ１８、ステップＳ１９）。比較の結果、一致すれば、当該署名Ｓｉｇ2は正当なものだと認証される。署名Ｓｉｇ2の正当性が認証されると、署名作成装置２は、最終的な署名Ｓｉｇ＝Ｓｉｇ1‖Ｓｉｇ2（Ｓｉｇ1とＳｉｇ2とを単純に結合する）を作成する（図４におけるステップＳ２０）。
署名作成装置２は、署名検証装置３（署名検証者Ｖ）から要求をうけた場合、署名Ｓｉｇ、公開鍵ＰｋＳ、メッセージｍ、公開鍵証明書ＣｅｒｔS等を送信する（図４におけるステップＳ２１）。
【００３６】
署名検証装置３は、予め、失効確認装置１（失効確認センタＳＥＭ）の公開鍵ＰｋＳＥＭをメモリ等に記憶している。署名検証装置３は公開鍵証明書ＣｅｒｔSを検証するために（図４におけるステップＳ２１）、受信した署名Ｓｉｇ＝Ｓｉｇ1‖Ｓｉｇ2からＳｉｇ2を取り出す。次に、取り出した署名Ｓｉｇ2を、メモリ等に記憶している失効確認装置１の公開鍵ＰｋＳＥＭにより復号化する。署名Ｓｉｇが正しいものであれば、署名Ｓｉｇ2は署名Ｓｉｇ1を失効確認装置１の秘密鍵ＳｋＳＥＭで暗号化したもの（署名Ｓｉｇ2＝Ｅｎｃ＜ＳｋＳＥＭ＞｛Ｓｉｇ1｝）であるので、署名Ｓｉｇ1＝Ｅｎｃ＜ＳｋＳ＞｛ｈ（ｍ）｝を取得できる。
【００３７】
次に、署名検証装置３は、受信した署名Ｓｉｇ＝Ｓｉｇ1‖Ｓｉｇ2からＳｉｇ1を取り出す。署名Ｓｉｇ1が正しいものであれば、署名Ｓｉｇ1はメッセージｍのハッシュ値ｈ（Ｍ）を署名作成装置２（署名作成者Ｓ）の秘密鍵ＳｋＳで暗号化したもの（署名Ｓｉｇ1＝Ｅｎｃ＜ＳｋＳ＞｛ｈ（ｍ）｝）を取得できる。
署名検証者３は、署名Ｓｉｇ2を復号化することにより取得した値と、署名Ｓｉｇ1とを比較する。一致すれば、署名Ｓｉｇは、失効確認装置１（失効確認センタＳＥＭ）の認証をうけた署名であると認識する。一致しなければ、当該署名は、失効確認装置１の認証を受けた署名でないと認識し、エラーを返すなどする。また、署名Ｓｉｇ2は、署名Ｓｉｇ1を用いて作成するものなので、署名検証装置３は、署名Ｓｉｇ2と署名Ｓｉｇ1とが一致した場合、署名Ｓｉｇ2が署名Ｓｉｇ1より後に作成されたことが認識できる。
【００３８】
なお、署名Ｓｉｇ2を復号化することにより取得した値と、署名Ｓｉｇ1とを、署名作成装置２の公開鍵ＰｋＳにより各々復号化して取得した値を比較することにより、当該署名が失効確認装置１の認証を受けた署名であるかどうか判断してもよい。
【００３９】
なお、署名Ｓｉｇを構成する署名Ｓｉｇ2が署名Ｓｉｇ2＝Ｅｎｃ＜ＳｋＳＥＭ＞｛ｈ（ｍ‖Ｓｉｇ1）｝である場合、署名検証者３は、取り出した署名Ｓｉｇ2を、まず、失効確認装置１の公開鍵ＰｋＳＥＭにより復号化する。また、メッセージｍに署名Ｓｉｇ1を追加（単純に結合）してｍ‖Ｓｉｇ1を取得した値から、署名作成装置２の公開鍵証明書ＣｅｒｔSに記載された手段に従ってハッシュ値ｈ（ｍ‖Ｓｉｇ1）を取得する。署名Ｓｉｇ2を公開鍵ＰｋＳＥＭにより復号するこよにより取得した値と、公開鍵証明書ＣｅｒｔSに記載された手段に従って取得したハッシュ値ｈ（ｍ‖Ｓｉｇ1）とを比較し、一致すれば、署名Ｓｉｇは、失効確認装置１（失効確認センタＳＥＭ）の認証をうけた署名であると認識する。
【００４０】
なお、メモリ１１は、ハードディスク装置や光磁気ディスク装置、フラッシュメモリ等の不揮発性のメモリや、ＣＤ−ＲＯＭ等の読み出しのみが可能な記憶媒体、ＲＡＭ（Random Access Memory）のような揮発性のメモリ、あるいはこれらの組み合わせにより構成されるもとのする。
【００４１】
なお、図２に示す各部は専用のハードウェアにより実現されるものであってもよく、また、この各部はメモリおよびＣＰＵ（中央演算装置）により構成され、各部の機能を実現するためのプログラムをメモリにロードして実行することによりその機能を実現させるものであってもよい。
【００４２】
また、図２における各部の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより実現させてもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。
また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
【００４３】
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。
以上、この発明の実施形態を図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計変更等も含まれる。
【００４４】
【発明の効果】
以上説明したように、本発明による署名作成装置によれば、公開鍵証明書の失効に関する情報を配布する通信コストが少ないという従来の方式の利点を保ちながら、失効と署名作成とのタイミングの関係を正しく認識できるＰＫＩを構築することができる。従来の方法では、不正に作成された署名が付随するデータを正しいものと認識したり、正当に作成された署名が付随するデータを不正なものと拒否する可能性があり、不正が発生するたびに、システムを停止し、不正発生の原因を探る必要がある。本発明により、このようにシステムを停止する必要が無くなり、システム運用のコストを低減することができ、また、ＰＫＩに基づくデータの信頼性を高めることができる。
【図面の簡単な説明】
【図１】 本発明の一実施形態において、システム構成を示す図である。
【図２】 同実施形態において、失効確認装置の構成を示すブロック図である。
【図３】 同実施形態において、メモリに格納されている失効リストの一例である。
【図４】 同実施形態において、動作を説明する図である。
【図５】 従来技術を説明する図である。
【図６】 従来技術を説明する図である。
【図７】 従来技術を説明する図である。
【図８】 従来技術を説明する図である。
【符号の説明】
１：失効確認装置、２：署名作成装置、３：署名検証装置、１１：メモリ、１２：通信インターフェース、１３：照合部、１４：署名作成部
Claims (3)
- 署名作成装置の鍵に対し発行された証明書が失効しているかどうか確認する失効確認装置であって、
失効した証明書に関する情報を記載した失効リストと前記失効確認装置の秘密鍵と、前記失効確認装置の公開鍵とを記憶する記憶手段と、
メッセージと、該メッセージを前記署名作成装置の秘密鍵で暗号化した電子署名と、前記署名作成装置の公開鍵と、前記署名作成装置の公開鍵証明書とを、前記署名作成装置から受信する受信手段と、
前記受信した公開鍵証明書と、前記記憶している失効リストとを照合する照合手段と、
前記照合の結果、一致しなかった場合には前記電子署名を前記失効確認装置の秘密鍵で暗号化した署名を作成する署名作成手段と、
前記電子署名を前記失効確認装置の秘密鍵で暗号化した署名を前記署名作成装置に送信する送信手段と
を備えることを特徴とする失効確認装置。 - 署名作成装置の鍵に対し発行された証明書が失効しているかどうか確認する失効確認装置であって、
失効した証明書に関する情報を記載した失効リストと、前記失効確認装置の秘密鍵と、前記失効確認装置の公開鍵とを記憶する記憶手段と、
メッセージに該メッセージを前記署名作成装置の秘密鍵で暗号化した電子署名を追加したものに対するハッシュ値と、前記署名作成装置の公開鍵と、前記署名作成装置の公開鍵証明書とを前記署名作成装置から受信する受信手段と、
前記受信した公開鍵証明書と、前記記憶している失効リストとを照合する照合手段と、
前記照合の結果、一致しなかった場合に前記ハッシュ値を前記失効確認装置の秘密鍵により暗号化した電子署名を作成する署名作成手段と、
前記電子署名を前記署名作成装置に送信する送信手段と
を備えることを特徴とする失効確認装置。 - 署名作成装置の鍵に対し発行された証明書が失効しているかどうか確認する失効確認方法であって、
失効した証明書に関する情報を記載した失効リストと前記失効確認装置の秘密鍵と、前記失効確認装置の公開鍵とを記憶する過程と、
メッセージと、該メッセージを前記署名作成装置の秘密鍵で暗号化した電子署名と、前記署名作成装置の公開鍵と、前記署名作成装置の公開鍵証明書とを、前記署名作成装置から受信する過程と、
前記受信した公開鍵証明書と、前記記憶している失効リストとを照合する過程と、
前記照合の結果、一致しなかった場合には前記電子署名を前記失効確認装置の秘密鍵で暗号化した署名を作成する過程と、
前記電子署名を前記失効確認装置の秘密鍵で暗号化した署名を前記署名作成装置に送信する送信手段と
を有することを特徴とする失効確認方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001335444A JP4071474B2 (ja) | 2001-10-31 | 2001-10-31 | 失効確認装置及び方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001335444A JP4071474B2 (ja) | 2001-10-31 | 2001-10-31 | 失効確認装置及び方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003143137A JP2003143137A (ja) | 2003-05-16 |
| JP4071474B2 true JP4071474B2 (ja) | 2008-04-02 |
Family
ID=19150432
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001335444A Expired - Lifetime JP4071474B2 (ja) | 2001-10-31 | 2001-10-31 | 失効確認装置及び方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4071474B2 (ja) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006165881A (ja) * | 2004-12-06 | 2006-06-22 | Mitsubishi Electric Corp | 署名データ作成システム及び署名データ作成端末及び署名検証端末及び証明書検証サーバ |
| EP2153557A4 (en) | 2007-04-23 | 2013-07-03 | Lg Electronics Inc | METHOD OF USE OF CONTENT, METHOD FOR THE COMMON USE OF CONTENT AND DEVICE BASED ON THE SECURITY LEVEL |
| CN101682505B (zh) | 2007-05-07 | 2013-10-23 | Lg电子株式会社 | 用于安全通信的方法和系统 |
-
2001
- 2001-10-31 JP JP2001335444A patent/JP4071474B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003143137A (ja) | 2003-05-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7689828B2 (en) | System and method for implementing digital signature using one time private keys | |
| KR101054970B1 (ko) | 개인 정보를 포함하는 전자 증명서를 이용하여 통신 상대를 인증하기 위한 시스템, 장치, 방법, 및 컴퓨터 판독 가능한 기록 매체 | |
| EP1714422B1 (en) | Establishing a secure context for communicating messages between computer systems | |
| CN101212293B (zh) | 一种身份认证方法及系统 | |
| US20060004662A1 (en) | Method and system for a PKI-based delegation process | |
| KR101452708B1 (ko) | Ｃｅ 장치 관리 서버, ｃｅ 장치 관리 서버를 이용한ｄｒｍ 키 발급 방법, 및 그 방법을 실행하기 위한프로그램 기록매체 | |
| US20020073310A1 (en) | Method and system for a secure binding of a revoked X.509 certificate to its corresponding certificate revocation list | |
| CN101395624A (zh) | 电子签名的验证 | |
| KR20050037244A (ko) | 인증서를 이용한 기기 인증 방법 및 상기 방법을 이용하여기기 인증을 수행하는 디지털 컨텐츠 처리 기기 | |
| JP2005520364A (ja) | デジタル署名された証明書を更新しかつ拡張するシステムおよび方法 | |
| JPH10336172A (ja) | 電子認証用公開鍵の管理方法 | |
| JP2004248220A (ja) | 公開鍵証明書発行装置、公開鍵証明書記録媒体、認証端末装置、公開鍵証明書発行方法、及びプログラム | |
| JP2008234143A (ja) | バイオメトリクスを使用した本人限定メール開封システムおよびその方法ならびにそのためのプログラム | |
| JP2005512395A (ja) | 電子証明書を認証する方法およびシステム | |
| JP4541740B2 (ja) | 認証用鍵の更新システム、および認証用鍵の更新方法 | |
| JP4071474B2 (ja) | 失効確認装置及び方法 | |
| EP1185024B1 (en) | System, method, and program for managing a user key used to sign a message for a data processing system | |
| JP4599812B2 (ja) | サービス提供システム、サービス提供サーバ、機器認証プログラム、記憶媒体、端末機器、機器認証サーバ、および公開鍵確認情報更新プログラム | |
| JP2005318399A (ja) | データ通信制御システム及び通信管理サーバ並びに通信制御サーバ | |
| WO2005055516A1 (en) | Method and apparatus for data certification by a plurality of users using a single key pair | |
| JP2002132144A (ja) | 認証方式 | |
| Basin et al. | Certificates and Public Key Cryptography | |
| KR20030002376A (ko) | 공개키 기반 인증을 위한 키관리 시스템 | |
| JP2003309546A (ja) | 情報授受方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20041224 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050118 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050316 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20050419 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050608 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20050628 |
|
| A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20061006 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080117 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 4071474 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: 20110125 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110125 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120125 Year of fee payment: 4 |
|
| 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: 20120125 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130125 Year of fee payment: 5 |
|
| 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: 20130125 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140125 Year of fee payment: 6 |
|
| 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 |