(57)【要約】【課題】煩雑な処理を行うことなく公開鍵と電子メールを対応付けする。【解決手段】本開示に係る送信装置は、電子署名が添付された電子メールの差出人アドレスに前記電子署名に対応する公開鍵の情報を付加する公開鍵情報付加部と、前記電子メールを送信する送信部と、を備える。この構成により、煩雑な処理を行うことなく公開鍵と電子メールを対応付けすることが可能となる。【選択図】図１２
2014068139.tif 000002
【特許請求の範囲】
【請求項１】
電子署名が添付された電子メールの差出人アドレスに前記電子署名に対応する公開鍵の情報を付加する公開鍵情報付加部と、
前記電子メールを送信する送信部と、
を備える、送信装置。
【請求項２】
前記公開鍵と秘密鍵とをペアで生成する鍵生成部と、
前記電子署名を生成する署名生成部と、
前記電子署名が添付された前記電子メールを作成する電子メール作成部と、
を更に備える、請求項１に記載の送信装置。
【請求項３】
前記電子署名が添付された前記電子メールを他装置から受信する受信部と、
前記電子署名に対応する前記公開鍵の情報を保管する公開鍵情報保管部と、を備え、
前記公開鍵情報付加部は、前記他装置から受信した前記電子メールの差出人アドレスに前記公開鍵情報保管部から抽出した前記公開鍵の情報を付加する、請求項１に記載の送信装置。
【請求項４】
前記電子メールを受信した受信装置から、前記公開鍵の情報に基づいて前記電子署名を検証した結果を受信する検証結果受信部を更に備える、請求項１に記載の送信装置。
【請求項５】
前記電子署名は、ＭＱプロトコルによる電子署名である、請求項１に記載の送信装置。
【請求項６】
電子署名が添付された電子メールを受信する受信部と、
前記電子メールの差出人アドレスに付加された前記電子署名に対応する公開鍵の情報を抽出する公開鍵情報抽出部と、
前記公開鍵の情報に基づいて前記電子署名を検証する検証部と、
を備える、受信装置。
【請求項７】
前記検証部による検証結果を送信する送信部を更に備える、請求項６に記載の受信装置。
【請求項８】
前記送信部は、前記検証結果に応じて、文字又はマークの表示、若しくは表示色を変更させて、前記検証結果を送信先の装置に表示させる、請求項７に記載の受信装置。
【請求項９】
前記電子メールは、メーリングリストから転送された電子メールであり、メーリングリストに投稿した投稿者のメールアドレスに前記公開鍵の情報と同一の情報が含まれる、請求項６に記載の受信装置。
【請求項１０】
前記電子署名は、ＭＱプロトコルによる電子署名である、請求項６に記載の受信装置。
【請求項１１】
電子署名が添付された電子メールの差出人アドレスに前記電子署名に対応する公開鍵の情報を付加することと、
前記電子メールを送信することと、
を備える、送信方法。
【請求項１２】
電子署名が添付された電子メールの差出人アドレスに前記電子署名に対応する公開鍵の情報を付加する手段、
前記電子メールを送信する手段、
としてコンピュータを機能させるためのプログラム。
【請求項１３】
電子署名が添付された電子メールを受信することと、
前記電子メールの差出人アドレスに付加された前記電子署名に対応する公開鍵の情報を抽出することと、
前記公開鍵の情報に基づいて前記電子署名を検証することと、
を備える、受信方法。
【請求項１４】
電子署名が添付された電子メールを受信する手段、
前記電子メールの差出人アドレスに付加された前記電子署名に対応する公開鍵の情報を抽出する手段、
前記公開鍵の情報に基づいて前記電子署名を検証する手段、
としてコンピュータを機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、送信装置、受信装置、送信方法、受信方法及びプログラムに関する。      
【背景技術】
【０００２】
従来、例えば下記の特許文献１には、暗号化メールの送受ごとに、暗号化方式と共通鍵との教示の必要性をなくして、通信トラフィックの増大などの諸問題を解消することのできる暗号化通信システムを提供することを想定した技術が記載されている。特許文献１に記載された技術では、一方の通信端末装置Ｆ１からは所定の暗号化能力問い合わせ電子メールを送信する一方、他方の通信端末装置Ｆ２では、この問い合わせ電子メールを受信した際に、予め準備している暗号化方式、公開鍵などの暗号化能力情報を、電子メールで返信することが記載されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−１４１４６１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、特許文献１に記載された技術では、公開鍵を電子メールで転送した際に、転送された側では公開鍵と電子メールとの対応付けを行って管理する必要がある。このため、公開鍵と電子メールを対応付けするという煩雑な処理が必要となる。
【０００５】
そこで、煩雑な処理を行うことなく公開鍵と電子メールを対応付けすることが求められていた。
【課題を解決するための手段】
【０００６】
本開示によれば、電子署名が添付された電子メールの差出人アドレスに前記電子署名に対応する公開鍵の情報を付加する公開鍵情報付加部と、前記電子メールを送信する送信部と、を備える、送信装置が提供される。
【０００７】
また、前記公開鍵と秘密鍵とをペアで生成する鍵生成部と、前記電子署名を生成する署名生成部と、前記電子署名が添付された前記電子メールを作成する電子メール作成部と、
を更に備えるものであっても良い。
【０００８】
また、前記電子署名が添付された前記電子メールを他装置から受信する受信部と、前記電子署名に対応する前記公開鍵の情報を保管する公開鍵情報保管部と、を備え、前記公開鍵情報付加部は、前記他装置から受信した前記電子メールの差出人アドレスに前記公開鍵情報保管部から抽出した前記公開鍵の情報を付加するものであっても良い。
【０００９】
また、前記電子メールを受信した受信装置から、前記公開鍵の情報に基づいて前記電子署名を検証した結果を受信する検証結果受信部を更に備えるものであっても良い。
【００１０】
また、前記電子署名は、ＭＱプロトコルによる電子署名であっても良い。
【００１１】
また、本開示によれば、電子署名が添付された電子メールを受信する受信部と、前記電子メールの差出人アドレスに付加された前記電子署名に対応する公開鍵の情報を抽出する公開鍵情報抽出部と、前記公開鍵の情報に基づいて前記電子署名を検証する検証部と、を備える、受信装置が提供される。
【００１２】
また、本開示によれば、前記検証部による検証結果を送信する送信部を更に備えるものであっても良い。
【００１３】
また、前記送信部は、前記検証結果に応じて、文字又はマークの表示、若しくは表示色を変更させて、前記検証結果を送信先の装置に表示させるものであっても良い。
【００１４】
また、前記電子メールは、メーリングリストから転送された電子メールであり、メーリングリストに投稿した投稿者のメールアドレスに前記公開鍵の情報と同一の情報が含まれるものであっても良い。
【００１５】
また、前記電子署名は、ＭＱプロトコルによる電子署名であっても良い。
【００１６】
また、本開示によれば、電子署名が添付された電子メールの差出人アドレスに前記電子署名に対応する公開鍵の情報を付加することと、前記電子メールを送信することと、を備える、送信方法が提供される。
【００１７】
また、本開示によれば、電子署名が添付された電子メールの差出人アドレスに前記電子署名に対応する公開鍵の情報を付加する手段、前記電子メールを送信する手段、としてコンピュータを機能させるためのプログラムが提供される。
【００１８】
また、本開示によれば、電子署名が添付された電子メールを受信することと、前記電子メールの差出人アドレスに付加された前記電子署名に対応する公開鍵の情報を抽出することと、前記公開鍵の情報に基づいて前記電子署名を検証することと、を備える、受信方法が提供される。
【００１９】
また、本開示によれば、電子署名が添付された電子メールを受信する手段、前記電子メールの差出人アドレスに付加された前記電子署名に対応する公開鍵の情報を抽出する手段、前記公開鍵の情報に基づいて前記電子署名を検証する手段、としてコンピュータを機能させるためのプログラムが提供される。
【発明の効果】
【００２０】
本開示によれば、煩雑な処理を行うことなく公開鍵と電子メールを対応付けすることが可能となる。
【図面の簡単な説明】
【００２１】
【図１】公開鍵認証方式のアルゴリズムについて概要を説明するための模式図である。
【図２】電子署名方式のアルゴリズムについて概要を説明するための模式図である。
【図３】ｎパスの公開鍵認証方式について説明するための説明図である。
【図４】３パス方式に係る具体的なアルゴリズムの構成について説明するための説明図である。
【図５】図４に示した３パス方式のアルゴリズムを並列化する方法について説明するための模式図である。
【図６】３パスの公開鍵認証方式から電子署名方式への変形を説明するための模式図である。
【図７】本実施形態に係る電子メールアドレスと公開鍵が一体になったメールアドレスを示す模式図である。
【図８】メールアドレスの表示状態の例を示す模式図である。
【図９】表示するマークの具体例として、手書き風サインを表示した例を示す模式図である。
【図１０】本実施形態の処理を示すシーケンス図である。
【図１１】メール送信サーバ２００が公開鍵ｐｋを付加する場合の処理を示すシーケンス図である。
【図１２】本実施形態のシステム構成を示す模式図である。
【図１３】メール送信サーバが自動で公開鍵ｐｋを送信者アドレス付加する例における、メール送信サーバの構成を示す模式図である。
【図１４】情報処理装置のハードウェア構成を示す模式図である。
【発明を実施するための形態】
【００２２】
以下に添付図面を参照しながら、本技術の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【００２３】
［説明の流れについて］
ここで、以下に記載する本技術の実施形態に関する説明の流れについて簡単に述べる。まず、図１を参照しながら、公開鍵認証方式のアルゴリズム構成について説明する。次いで、図２を参照しながら、電子署名方式のアルゴリズム構成について説明する。次いで、図３を参照しながら、ｎパスの公開鍵認証方式について説明する。
【００２４】
次いで、図４〜図６を参照しながら、３パスの公開鍵認証方式に係るアルゴリズムの構成例について説明する。次いで、図７〜図１３を参照しながら、本開示の一実施形態について説明する。次いで、図１４を参照しながら、本技術の実施形態に係る各アルゴリズムを実現することが可能な情報処理装置のハードウェア構成例について説明する。
【００２５】
（説明項目）
１：はじめに
１−１：公開鍵認証方式のアルゴリズム
１−２：電子署名方式のアルゴリズム
１−３：ｎパスの公開鍵認証方式
２：３パスの公開鍵認証方式に係るアルゴリズムの構成
２−１：具体的なアルゴリズムの構成例
２−２：並列化アルゴリズムの構成例
３：電子署名方式への変形
３−１：３パスの公開鍵認証方式から電子署名方式への変形
４：具体的な実施形態
４−１：本開示の一実施形態に係るシステムの概要
４−２：メールアドレスの表示状態の例
４−３：本実施形態のシステムにおける処理について
４−４：送信サーバによる公開鍵の付加
４−５：本実施形態のシステム構成例
４−６：メール転送、メーリングリストへの適用例
４−７：公開鍵部分の指定方法について
５：ハードウェア構成例
【００２６】
＜１：はじめに＞
本実施形態は、多次多変数連立方程式に対する求解問題の困難性に安全性の根拠をおく公開鍵認証方式及び電子署名方式に関する（以下、ＭＱプロトコルとも称する場合がある）。但し、本実施形態は、ＨＦＥ電子署名方式などの従来手法とは異なり、効率的に解く手段（トラップドア）を持たない多次多変数連立方程式を利用する公開鍵認証方式及び電子署名方式に関する。なお、本実施形態に適用可能な認証方式はこれに限定されるものではなく、他の公開鍵認証方式を広く適用することが可能である。まず、公開鍵認証方式のアルゴリズム、電子署名方式のアルゴリズム、及びｎパスの公開鍵認証方式について、その概要を簡単に説明する。
【００２７】
［１−１：公開鍵認証方式のアルゴリズム］
まず、図１を参照しながら、公開鍵認証方式のアルゴリズムについて概要を説明する。図１は、公開鍵認証方式のアルゴリズムについて概要を説明するための説明図である。
【００２８】
公開鍵認証は、ある人（証明者）が、公開鍵ｐｋ及び秘密鍵ｓｋを利用して、他の人（検証者）に本人であることを納得させるために利用される。例えば、証明者Ａの公開鍵ｐｋＡは、検証者Ｂに公開される。一方、証明者Ａの秘密鍵ｓｋＡは、証明者Ａにより秘密に管理される。公開鍵認証の仕組みにおいては、公開鍵ｐｋＡに対応する秘密鍵ｓｋＡを知る者が証明者Ａ本人であるとみなされる。
【００２９】
公開鍵認証の仕組みを利用して証明者Ａが証明者Ａ本人であることを検証者Ｂに証明するには、対話プロトコルを介して、証明者Ａが公開鍵ｐｋＡに対応する秘密鍵ｓｋＡを知っているという証拠を検証者Ｂに提示すればよい。そして、証明者Ａが秘密鍵ｓｋＡを知っているという証拠が検証者Ｂに提示され、その証拠を検証者Ｂが確認し終えた場合、証明者Ａの正当性（本人であること）が証明されたことになる。
【００３０】
但し、公開鍵認証の仕組みには、安全性を担保するために以下の条件が求められる。
【００３１】
１つ目の条件は、「対話プロトコルを実行した際に秘密鍵ｓｋを持たない偽証者により偽証が成立してしまう確率を限りなく小さくする」ことである。この１つ目の条件が成り立つことを「健全性」と呼ぶ。つまり、健全性とは、「秘密鍵ｓｋを持たない偽証者により、対話プロトコルの実行中に無視できない確率で偽証が成立することはないこと」と言い換えられる。２つ目の条件は、「対話プロトコルを実行したとしても、証明者Ａが有する秘密鍵ｓｋＡの情報が検証者Ｂに一切漏れることがない」ことである。この２つ目の条件が成り立つことを「零知識性」と呼ぶ。
【００３２】
安全に公開鍵認証を行うには、健全性及び零知識性を有する対話プロトコルを利用する必要がある。仮に、健全性及び零知識性を有しない対話プロトコルを用いて認証処理を行った場合には、偽証された可能性及び秘密鍵の情報が漏れてしまった可能性が否定できないため、処理自体が成功裡に完了しても証明者の正当性を証明したことにはならない。従って、対話プロトコルの健全性及び零知識性を如何に保証するかが重要になる。
【００３３】
（モデル）
公開鍵認証方式のモデルには、図１に示すように、証明者と検証者という２つのエンティティが存在する。証明者は、鍵生成アルゴリズムＧｅｎを用いて、証明者固有の秘密鍵ｓｋと公開鍵ｐｋの組を生成する。次いで、証明者は、鍵生成アルゴリズムＧｅｎを用いて生成した秘密鍵ｓｋと公開鍵ｐｋの組を利用して検証者と対話プロトコルを実行する。このとき、証明者は、証明者アルゴリズムＰを利用して対話プロトコルを実行する。上記の通り、証明者は、証明者アルゴリズムＰを利用し、対話プロトコルの中で秘密鍵ｓｋを保有している証拠を検証者に提示する。
【００３４】
一方、検証者は、検証者アルゴリズムＶを利用して対話プロトコルを実行し、証明者が公開している公開鍵に対応する秘密鍵を、その証明者が保有しているか否かを検証する。つまり、検証者は、証明者が公開鍵に対応する秘密鍵を保有しているか否かを検証するエンティティである。このように、公開鍵認証方式のモデルは、証明者と検証者という２つのエンティティ、及び、鍵生成アルゴリズムＧｅｎ、証明者アルゴリズムＰ、検証者アルゴリズムＶという３つのアルゴリズムにより構成される。
【００３５】
なお、以下の説明において、「証明者」「検証者」という表現を用いるが、これらの表現はあくまでもエンティティを意味するものである。従って、鍵生成アルゴリズムＧｅｎ、証明者アルゴリズムＰを実行する主体は、「証明者」のエンティティに対応する情報処理装置である。同様に、検証者アルゴリズムＶを実行する主体は、情報処理装置である。これら情報処理装置のハードウェア構成は、例えば、図１４に示した通りである。つまり、鍵生成アルゴリズムＧｅｎ、証明者アルゴリズムＰ、検証者アルゴリズムＶは、ＲＯＭ９０４、ＲＡＭ９０６、記憶部９２０、リムーバブル記録媒体９２８などに記録されたプログラムに基づいてＣＰＵ９０２などにより実行される。
【００３６】
（鍵生成アルゴリズムＧｅｎ）
鍵生成アルゴリズムＧｅｎは、証明者により利用される。鍵生成アルゴリズムＧｅｎは、証明者に固有の秘密鍵ｓｋと公開鍵ｐｋとの組を生成するアルゴリズムである。鍵生成アルゴリズムＧｅｎにより生成された公開鍵ｐｋは公開される。そして、公開された公開鍵ｐｋは、検証者により利用される。一方、鍵生成アルゴリズムＧｅｎにより生成された秘密鍵ｓｋは、証明者が秘密に管理する。そして、証明者により秘密に管理される秘密鍵ｓｋは、公開鍵ｐｋに対応する秘密鍵ｓｋを証明者が保有していることを検証者に対して証明するために利用される。形式的に、鍵生成アルゴリズムＧｅｎは、セキュリティパラメータ１λ（λは０以上の整数）を入力とし、秘密鍵ｓｋと公開鍵ｐｋを出力するアルゴリズムとして、下記の式（１）のように表現される。
【００３７】
【数１】
2014068139.tif 000003
【００３８】
（証明者アルゴリズムＰ）
証明者アルゴリズムＰは、証明者により利用される。証明者アルゴリズムＰは、公開鍵ｐｋに対応する秘密鍵ｓｋを証明者が保有していることを検証者に対して証明するためのアルゴリズムである。つまり、証明者アルゴリズムＰは、秘密鍵ｓｋと公開鍵ｐｋとを入力とし、対話プロトコルを実行するアルゴリズムである。
【００３９】
（検証者アルゴリズムＶ）
検証者アルゴリズムＶは、検証者により利用される。検証者アルゴリズムＶは、対話プロトコルの中で、公開鍵ｐｋに対応する秘密鍵ｓｋを証明者が保有しているか否かを検証するアルゴリズムである。検証者アルゴリズムＶは、公開鍵ｐｋを入力とし、対話プロトコルの実行結果に応じて０又は１（１ｂｉｔ）を出力するアルゴリズムである。なお、検証者は、検証者アルゴリズムＶが０を出力した場合には証明者が不正なものであると判断し、１を出力した場合には証明者が正当なものであると判断する。形式的に、検証者アルゴリズムＶは、下記の式（２）のように表現される。
【００４０】
【数２】
2014068139.tif 000004
【００４１】
上記の通り、意味のある公開鍵認証を実現するには、対話プロトコルが健全性及び零知識性という２つの条件を満たしている必要がある。しかし、証明者が秘密鍵ｓｋを保有していることを証明するためには、証明者が秘密鍵ｓｋに依存した手続きを実行し、その結果を検証者に通知した上で、その通知内容に基づく検証を検証者に実行させる必要がある。秘密鍵ｓｋに依存した手続きを実行するのは、健全性を担保するために必要である。一方で、秘密鍵ｓｋの情報が一切検証者に漏れないようにする必要がある。そのため、これらの要件を満たすように、上記の鍵生成アルゴリズムＧｅｎ、証明者アルゴリズムＰ、検証者アルゴリズムＶを巧妙に設計する必要がある。
【００４２】
以上、公開鍵認証方式のアルゴリズムについて、その概要を説明した。
【００４３】
［１−２：電子署名方式のアルゴリズム］
次に、図２を参照しながら、電子署名方式のアルゴリズムについて概要を説明する。図２は、電子署名方式のアルゴリズムについて概要を説明するための説明図である。
【００４４】
紙文書とは異なり、ある電子化されたデータに対して押印したり署名を記載したりすることはできない。そのため、電子化されたデータの作成者を証明するためには、紙文書に押印したり署名を記載したりするのと同等の効果が得られる電子的な仕組みを必要とする。この仕組みが電子署名である。電子署名とは、データの作成者しか知らない署名データをデータに関連付けて受領者に提供し、その署名データを受領者側で検証する仕組みのことを言う。
【００４５】
（モデル）
電子署名方式のモデルには、図２に示すように、署名者及び検証者という２つのエンティティが存在する。そして、電子署名方式のモデルは、鍵生成アルゴリズムＧｅｎ、署名生成アルゴリズムＳｉｇ、署名検証アルゴリズムＶｅｒという３つのアルゴリズムにより構成される。
【００４６】
署名者は、鍵生成アルゴリズムＧｅｎを利用して署名者固有の署名鍵ｓｋと検証鍵ｐｋとの組を生成する。また、署名者は、署名生成アルゴリズムＳｉｇを利用して文書Ｍに付与する電子署名σを生成する。つまり、署名者は、文書Ｍに電子署名を付与するエンティティである。一方、検証者は、署名検証アルゴリズムＶｅｒを利用して文書Ｍに付与された電子署名σを検証する。つまり、検証者は、文書Ｍの作成者が署名者であるか否かを確認するために、電子署名σを検証するエンティティである。
【００４７】
なお、以下の説明において、「署名者」「検証者」という表現を用いるが、これらの表現はあくまでもエンティティを意味するものである。従って、鍵生成アルゴリズムＧｅｎ、署名生成アルゴリズムＳｉｇを実行する主体は、「署名者」のエンティティに対応する情報処理装置である。同様に、署名検証アルゴリズムＶｅｒを実行する主体は、情報処理装置である。これら情報処理装置のハードウェア構成は、例えば、図１４に示した通りである。つまり、鍵生成アルゴリズムＧｅｎ、署名生成アルゴリズムＳｉｇ、署名検証アルゴリズムＶｅｒは、ＲＯＭ９０４、ＲＡＭ９０６、記憶部９２０、リムーバブル記録媒体９２８などに記録されたプログラムに基づいてＣＰＵ９０２などにより実行される。
【００４８】
（鍵生成アルゴリズムＧｅｎ）
鍵生成アルゴリズムＧｅｎは、署名者により利用される。鍵生成アルゴリズムＧｅｎは、署名者固有の署名鍵ｓｋと検証鍵ｐｋとの組を生成するアルゴリズムである。鍵生成アルゴリズムＧｅｎにより生成された検証鍵ｐｋは公開される。一方、鍵生成アルゴリズムＧｅｎにより生成された署名鍵ｓｋは、署名者により秘密に管理される。そして、署名鍵ｓｋは、文書Ｍに付与される電子署名σの生成に利用される。例えば、鍵生成アルゴリズムＧｅｎは、セキュリティパラメータ１λ（λは０以上の整数）を入力とし、署名鍵ｓｋ及び公開鍵ｐｋを出力する。この場合、鍵生成アルゴリズムＧｅｎは、形式的に、下記の式（３）のように表現することができる。
【００４９】
【数３】
2014068139.tif 000005
【００５０】
（署名生成アルゴリズムＳｉｇ）
署名生成アルゴリズムＳｉｇは、署名者により利用される。署名生成アルゴリズムＳｉｇは、文書Ｍに付与される電子署名σを生成するアルゴリズムである。署名生成アルゴリズムＳｉｇは、署名鍵ｓｋと文書Ｍとを入力とし、電子署名σを出力するアルゴリズムである。この署名生成アルゴリズムＳｉｇは、形式的に、下記の式（４）のように表現することができる。
【００５１】
【数４】
2014068139.tif 000006
【００５２】
（署名検証アルゴリズムＶｅｒ）
署名検証アルゴリズムＶｅｒは、検証者により利用される。署名検証アルゴリズムＶｅｒは、電子署名σが文書Ｍに対する正当な電子署名であるか否かを検証するアルゴリズムである。署名検証アルゴリズムＶｅｒは、署名者の検証鍵ｐｋ、文書Ｍ、電子署名σを入力とし、０又は１（１ｂｉｔ）を出力するアルゴリズムである。この署名検証アルゴリズムＶｅｒは、形式的に、下記の式（５）のように表現することができる。なお、検証者は、署名検証アルゴリズムＶｅｒが０を出力した場合（公開鍵ｐｋが文書Ｍと電子署名σを拒否する場合）に電子署名σが不当であると判断し、１を出力した場合（公開鍵ｐｋが文書Ｍと電子署名σを受理する場合）に電子署名σが正当であると判断する。
【００５３】
【数５】
2014068139.tif 000007
【００５４】
以上、電子署名方式のアルゴリズムについて、その概要を説明した。
【００５５】
［１−３：ｎパスの公開鍵認証方式］
次に、図３を参照しながら、ｎパスの公開鍵認証方式について説明する。図３は、ｎパスの公開鍵認証方式について説明するための説明図である。
【００５６】
上記の通り、公開鍵認証方式は、対話プロトコルの中で、証明者が公開鍵ｐｋに対応する秘密鍵ｓｋを保有していることを検証者に証明する認証方式である。また、対話プロトコルは、健全性及び零知識性という２つの条件を満たす必要がある。そのため、対話プロトコルの中では、図３に示すように、証明者及び検証者の双方がそれぞれ処理を実行しながらｎ回の情報交換を行う。
【００５７】
ｎパスの公開鍵認証方式の場合、証明者アルゴリズムＰを用いて証明者により処理（工程＃１）が実行され、情報Ｔ１が検証者に送信される。次いで、検証者アルゴリズムＶを用いて検証者により処理（工程＃２）が実行され、情報Ｔ２が証明者に送信される。さらに、ｋ＝３〜ｎについて処理の実行及び情報Ｔｋの送信が順次行われ、最後に処理（工程＃ｎ＋１）が実行される。このように、情報がｎ回送受信される方式のことを「ｎパス」の公開鍵認証方式と呼ぶ。
【００５８】
以上、ｎパスの公開鍵認証方式について説明した。
【００５９】
＜２：３パスの公開鍵認証方式に係るアルゴリズムの構成＞
以下、３パスの公開鍵認証方式に係るアルゴリズムについて説明する。なお、以下の説明において、３パスの公開鍵認証方式のことを「３パス方式」と呼ぶ場合がある。
【００６０】
［２−１：具体的なアルゴリズムの構成例（図４）］
まず、図４を参照しながら、３パス方式に係る具体的なアルゴリズムの構成例について紹介する。図４は、３パス方式に係る具体的なアルゴリズムの構成について説明するための説明図である。ここでは、公開鍵ｐｋの一部として２次多項式の組（ｆ１（ｘ），…，ｆｍ（ｘ））を利用する場合について考える。但し、２次多項式ｆｉ（ｘ）は、下記の式（６）のように表現されるものとする。また、ベクトル（ｘ１，…，ｘｎ）をｘと表記し、２次多項式の組（ｆ１（ｘ），…，ｆｍ（ｘ））を多変数多項式Ｆ（ｘ）と表記することにする。
【００６１】
【数６】
2014068139.tif 000008
【００６２】
また、２次多項式の組（ｆ１（ｘ），…，ｆｍ（ｘ））は、下記の式（７）のように表現することができる。また、Ａ１，…，Ａｍは、ｎ×ｎ行列である。さらに、ｂ１，…，ｂｍはそれぞれｎ×１ベクトルである。
【００６３】
【数７】
2014068139.tif 000009
【００６４】
この表現を用いると、多変数多項式Ｆは、下記の式（８）及び式（９）のように表現することができる。この表現が成り立つことは、下記の式（１０）から容易に確認することができる。
【００６５】
【数８】
2014068139.tif 000010
【００６６】
このようにＦ（ｘ＋ｙ）をｘに依存する第１の部分と、ｙに依存する第２の部分と、ｘ及びｙの両方に依存する第３の部分とに分けたとき、第３の部分に対応する項Ｇ（ｘ，ｙ）は、ｘ及びｙについて双線形になる。以下、項Ｇ（ｘ，ｙ）を双線形項と呼ぶ場合がある。この性質を利用すると、効率的なアルゴリズムを構築することが可能になる。
【００６７】
例えば、ベクトルｔ０∈Ｋｎ、ｅ０∈Ｋｍを用いて、多変数多項式Ｆ（ｘ＋ｒ）のマスクに利用する多変数多項式Ｆ１（ｘ）をＦ１（ｘ）＝Ｇ（ｘ，ｔ０）＋ｅ０と表現する。この場合、多変数多項式Ｆ（ｘ＋ｒ０）とＦ１（ｘ）との和は、下記の式（１１）のように表現される。ここで、ｔ１＝ｒ０＋ｔ０、ｅ１＝Ｆ（ｒ０）＋ｅ０とおけば、多変数多項式Ｆ２（ｘ）＝Ｆ（ｘ＋ｒ０）＋Ｆ１（ｘ）は、ベクトルｔ１∈Ｋｎ、ｅ１∈Ｋｍにより表現することができる。そのため、Ｆ１（ｘ）＝Ｇ（ｘ，ｔ０）＋ｅ０に設定すれば、Ｋｎ上のベクトル及びＫｍ上のベクトルを用いてＦ１及びＦ２を表現できるようになり、通信に必要なデータサイズの少ない効率的なアルゴリズムを実現することが可能になる。
【００６８】
【数９】
2014068139.tif 000011
【００６９】
なお、Ｆ２（或いはＦ１）からｒ０に関する情報が一切漏れることはない。例えば、ｅ１及びｔ１（或いはｅ０及びｔ０）を与えられても、ｅ０及びｔ０（或いはｅ１及びｔ１）を知らない限り、ｒ０の情報を一切知ることはできない。従って、零知識性が担保される。以下、上記の論理に基づいて構築された３パス方式のアルゴリズムについて説明する。ここで説明する３パス方式のアルゴリズムは、以下のような鍵生成アルゴリズムＧｅｎ、証明者アルゴリズムＰ、検証者アルゴリズムＶにより構成される。
【００７０】
（鍵生成アルゴリズムＧｅｎ）
鍵生成アルゴリズムＧｅｎは、環Ｋ上で定義されるｍ本の多変数多項式ｆ１（ｘ１，…，ｘｎ），…，ｆｍ（ｘ１，…，ｘｎ）、及びベクトルｓ＝（ｓ１，…，ｓｎ）∈Ｋｎを生成する。次に、鍵生成アルゴリズムＧｅｎは、ｙ＝（ｙ１，…，ｙｍ）←（ｆ１（ｓ），…，ｆｍ（ｓ））を計算する。そして、鍵生成アルゴリズムＧｅｎは、（ｆ１（ｘ１，…，ｘｎ），…，ｆｍ（ｘ１，…，ｘｎ），ｙ）を公開鍵ｐｋに設定し、ｓを秘密鍵に設定する。
【００７１】
（証明者アルゴリズムＰ、検証者アルゴリズムＶ）
以下、図４を参照しながら、対話プロトコルの中で証明者アルゴリズムＰが実行する処理及び検証者アルゴリズムＶが実行する処理について説明する。この対話プロトコルの中で、証明者は、秘密鍵ｓの情報を検証者に一切漏らさずに、「自身がｙ＝Ｆ（ｓ）を満たすｓを知っていること」を検証者に示す。一方、検証者は、証明者がｙ＝Ｆ（ｓ）を満たすｓを知っているか否かを検証する。なお、公開鍵ｐｋは、検証者に公開されているものとする。また、秘密鍵ｓは、証明者により秘密に管理されているものとする。以下、図４に示したフローチャートに沿って説明を進める。
【００７２】
工程＃１：
図４に示すように、まず、証明者アルゴリズムＰは、ランダムにベクトルｒ０，ｔ０∈Ｋｎ及びｅ０∈Ｋｍを生成する。次いで、証明者アルゴリズムＰは、ｒ１←ｓ−ｒ０を計算する。この計算は、秘密鍵ｓをベクトルｒ０によりマスクする操作に相当する。さらに、証明者アルゴリズムＰは、ｔ１←ｒ０−ｔ０を計算する。次いで、証明者アルゴリズムＰは、ｅ１←Ｆ（ｒ０）−ｅ０を計算する。
【００７３】
工程＃１（続き）：
次いで、証明者アルゴリズムＰは、ｃ０←Ｈ（ｒ１，Ｇ（ｔ０，ｒ１）＋ｅ０）を計算する。次いで、証明者アルゴリズムＰは、ｃ１←Ｈ（ｔ０，ｅ０）を計算する。次いで、証明者アルゴリズムＰは、ｃ２←Ｈ（ｔ１，ｅ１）を計算する。工程＃１で生成されたメッセージ（ｃ０，ｃ１，ｃ２）は、検証者アルゴリズムＶに送られる。
【００７４】
工程＃２：
メッセージ（ｃ０，ｃ１，ｃ２）を受け取った検証者アルゴリズムＶは、３つの検証パターンのうち、どの検証パターンを利用するかを選択する。例えば、検証者アルゴリズムＶは、検証パターンの種類を表す３つの数値｛０，１，２｝の中から１つの数値を選択し、選択した数値を要求Ｃｈに設定する。この要求Ｃｈは証明者アルゴリズムＰに送られる。
【００７５】
工程＃３：
要求Ｃｈを受け取った証明者アルゴリズムＰは、受け取った要求Ｃｈに応じて検証者アルゴリズムＶに送る返答Ｒｓｐを生成する。Ｃｈ＝０の場合、証明者アルゴリズムＰは、返答Ｒｓｐ＝（ｒ０，ｔ１，ｅ１）を生成する。Ｃｈ＝１の場合、証明者アルゴリズムＰは、返答Ｒｓｐ＝（ｒ１，ｔ０，ｅ０）を生成する。Ｃｈ＝２の場合、証明者アルゴリズムＰは、返答Ｒｓｐ＝（ｒ１，ｔ１，ｅ１）を生成する。工程＃３で生成された返答Ｒｓｐは、検証者アルゴリズムＶに送られる。
【００７６】
工程＃４：
返答Ｒｓｐを受け取った検証者アルゴリズムＶは、受け取った返答Ｒｓｐを利用して以下の検証処理を実行する。
【００７７】
Ｃｈ＝０の場合、検証者アルゴリズムＶは、ｃ１＝Ｈ（ｒ０−ｔ１，Ｆ（ｒ０）−ｅ１）の等号が成り立つか否かを検証する。さらに、検証者アルゴリズムＶは、ｃ２＝Ｈ（ｔ１，ｅ１）の等号が成り立つか否かを検証する。検証者アルゴリズムＶは、これらの検証が全て成功した場合に認証成功を示す値１を出力し、検証に失敗があった場合に認証失敗を示す値０を出力する。
【００７８】
Ｃｈ＝１の場合、検証者アルゴリズムＶは、ｃ０＝Ｈ（ｒ１，Ｇ（ｔ０，ｒ１）＋ｅ０）の等号が成り立つか否かを検証する。さらに、検証者アルゴリズムＶは、ｃ１＝Ｈ（ｔ０，ｅ０）の等号が成り立つか否かを検証する。検証者アルゴリズムＶは、これらの検証が全て成功した場合に認証成功を示す値１を出力し、検証に失敗があった場合に認証失敗を示す値０を出力する。
【００７９】
Ｃｈ＝２の場合、検証者アルゴリズムＶは、ｃ０＝Ｈ（ｒ１，ｙ−Ｆ（ｒ１）−Ｇ（ｔ１，ｒ１）−ｅ１）の等号が成り立つか否かを検証する。さらに、検証者アルゴリズムＶは、ｃ２＝Ｈ（ｔ１，ｅ１）の等号が成り立つか否かを検証する。検証者アルゴリズムＶは、これらの検証が全て成功した場合に認証成功を示す値１を出力し、検証に失敗があった場合に認証失敗を示す値０を出力する。
【００８０】
以上、３パス方式に係る効率的なアルゴリズムの構成例について説明した。
【００８１】
［２−２：並列化アルゴリズムの構成例（図５）］
次に、図５を参照しながら、図４に示した３パス方式のアルゴリズムを並列化する方法について説明する。なお、鍵生成アルゴリズムＧｅｎの構成については説明を省略する。
【００８２】
さて、上記の対話プロトコルを適用すれば、偽証が成功する確率を２／３以下に抑制することができる。従って、この対話プロトコルを２回実行すれば、偽証が成功する確率を（２／３）２以下に抑制することができる。さらに、この対話プロトコルをＮ回実行すると、偽証が成功する確率は（２／３）Ｎとなり、Ｎを十分に大きい数（例えば、Ｎ＝１４０）にすれば、偽証が成功する確率は無視できる程度に小さくなる。
【００８３】
対話プロトコルを複数回実行する方法としては、例えば、メッセージ、要求、返答のやり取りを逐次的に複数回繰り返す直列的な方法と、１回分のやり取りで複数回分のメッセージ、要求、返答のやり取りを行う並列的な方法とが考えられる。さらに、直列的な方法と並列的な方法とを組み合わせたハイブリッド型の方法も考えられる。ここでは、図５を参照しながら、３パス方式に係る上記の対話プロトコルを並列的に実行するアルゴリズム（以下、並列化アルゴリズム）について説明する。
【００８４】
工程＃１：
図５に示すように、まず、証明者アルゴリズムＰは、ｉ＝１〜Ｎについて以下の処理（１）〜処理（６）を実行する。
処理（１）：証明者アルゴリズムＰは、ランダムにベクトルｒ０ｉ，ｔ０ｉ∈Ｋｎ及びｅ０ｉ∈Ｋｍを生成する。
処理（２）：証明者アルゴリズムＰは、ｒ１ｉ←ｓ−ｒ０ｉを計算する。この計算は、秘密鍵ｓをベクトルｒ０ｉによりマスクする操作に相当する。さらに、証明者アルゴリズムＰは、ｔ１ｉ←ｒ０ｉ−ｔ０ｉを計算する。
処理（３）：証明者アルゴリズムＰは、ｅ１ｉ←Ｆ（ｒ０ｉ）−ｅ０ｉを計算する。
処理（４）：証明者アルゴリズムＰは、ｃ０ｉ←Ｈ（ｒ１ｉ，Ｇ（ｔ０ｉ，ｒ１ｉ）＋ｅ０ｉ）を計算する。
処理（５）：証明者アルゴリズムＰは、ｃ１ｉ←Ｈ（ｔ０ｉ，ｅ０ｉ）を計算する。
処理（６）：証明者アルゴリズムＰは、ｃ２ｉ←Ｈ（ｔ１ｉ，ｅ１ｉ）を計算する。
【００８５】
工程＃１（続き）
ｉ＝１〜Ｎについて上記の処理（１）〜処理（６）を実行した後、証明者アルゴリズムＰは、Ｃｍｔ←Ｈ（ｃ０１，ｃ１１，ｃ２１，…，ｃ０Ｎ，ｃ１Ｎ，ｃ２Ｎ）を計算する。工程＃１で生成されたハッシュ値Ｃｍｔは、検証者アルゴリズムＶに送られる。このように、メッセージ（ｃ０１，ｃ１１，ｃ２１，…，ｃ０Ｎ，ｃ１Ｎ，ｃ２Ｎ）をハッシュ値に変換してから検証者アルゴリズムＶに送ることで、通信量を削減することが可能になる。なお、証明者アルゴリズムＰは、（ｃ０１，ｃ１１，ｃ２１，…，ｃ０Ｎ，ｃ１Ｎ，ｃ２Ｎ）を検証者アルゴリズムＶに送っても良い。
【００８６】
工程＃２：
ハッシュ値Ｃｍｔを受け取った検証者アルゴリズムＶは、ｉ＝１〜Ｎのそれぞれについて、３つの検証パターンのうち、どの検証パターンを利用するかを選択する。例えば、検証者アルゴリズムＶは、ｉ＝１〜Ｎのそれぞれについて、検証パターンの種類を表す３つの数値｛０，１，２｝の中から１つの数値を選択し、選択した数値を要求Ｃｈｉに設定する。要求Ｃｈ１，…，ＣｈＮは、証明者アルゴリズムＰに送られる。
【００８７】
工程＃３：
要求Ｃｈ１，…，ＣｈＮを受け取った証明者アルゴリズムＰは、受け取った要求Ｃｈ１，…，ＣｈＮのそれぞれ応じて検証者アルゴリズムＶに送る返答Ｒｓｐ１，…，ＲｓｐＮを生成する。Ｃｈｉ＝０の場合、証明者アルゴリズムＰは、Ｒｓｐｉ＝（ｒ０ｉ，ｔ１ｉ，ｅ１ｉ，ｃ０ｉ）を生成する。Ｃｈｉ＝１の場合、証明者アルゴリズムＰは、Ｒｓｐｉ＝（ｒ１ｉ，ｔ０ｉ，ｅ０ｉ，ｃ２ｉ）を生成する。Ｃｈｉ＝２の場合、証明者アルゴリズムＰは、Ｒｓｐｉ＝（ｒ１ｉ，ｔ１ｉ，ｅ１ｉ，ｃ１ｉ）を生成する。
【００８８】
工程＃３で生成された返答Ｒｓｐ１，…，ＲｓｐＮは、検証者アルゴリズムＶに送られる。
【００８９】
工程＃４：
返答Ｒｓｐ１，…，ＲｓｐＮを受け取った検証者アルゴリズムＶは、受け取った返答Ｒｓｐ１，…，ＲｓｐＮを利用して以下の処理（１）〜処理（３）をｉ＝１〜Ｎについて実行する。但し、検証者アルゴリズムＶは、Ｃｈｉ＝０の場合に処理（１）を実行し、Ｃｈｉ＝１の場合に処理（２）を実行し、Ｃｈｉ＝２の場合に処理（３）を実行する。
【００９０】
処理（１）：Ｃｈｉ＝０の場合、検証者アルゴリズムＶは、Ｒｓｐｉから（ｒ０ｉ，ｔ１ｉ，ｅ１ｉ，ｃ０ｉ）を取り出す。次いで、検証者アルゴリズムＶは、ｃ１ｉ＝Ｈ（ｒ０ｉ−ｔ１ｉ，Ｆ（ｒ０ｉ）−ｅ１ｉ）を計算する。さらに、検証者アルゴリズムＶは、ｃ２ｉ＝Ｈ（ｔ１ｉ，ｅ１ｉ）を計算する。そして、検証者アルゴリズムＶは、（ｃ０ｉ，ｃ１ｉ，ｃ２ｉ）を保持する。
【００９１】
処理（２）：Ｃｈｉ＝１の場合、検証者アルゴリズムＶは、Ｒｓｐｉから（ｒ１ｉ，ｔ０ｉ，ｅ０ｉ，ｃ２ｉ）を取り出す。次いで、検証者アルゴリズムＶは、ｃ０ｉ＝Ｈ（ｒ１ｉ，Ｇ（ｔ０ｉ，ｒ１ｉ）＋ｅ０ｉ）を計算する。さらに、検証者アルゴリズムＶは、ｃ１ｉ＝Ｈ（ｔ０ｉ，ｅ０ｉ）を計算する。そして、検証者アルゴリズムＶは、（ｃ０ｉ，ｃ１ｉ，ｃ２ｉ）を保持する。
【００９２】
処理（３）：Ｃｈｉ＝２の場合、検証者アルゴリズムＶは、Ｒｓｐｉから（ｒ１ｉ，ｔ１ｉ，ｅ１ｉ，ｃ１ｉ）を取り出す。次いで、検証者アルゴリズムＶは、ｃ０ｉ＝Ｈ（ｒ１ｉ，ｙ−Ｆ（ｒ１ｉ）−Ｇ（ｔ１ｉ，ｒ１ｉ）−ｅ１ｉ）を計算する。さらに、検証者アルゴリズムＶは、ｃ２ｉ＝Ｈ（ｔ１ｉ，ｅ１ｉ）を計算する。そして、検証者アルゴリズムＶは、（ｃ０ｉ，ｃ１ｉ，ｃ２ｉ）を保持する。
【００９３】
処理（１）〜処理（３）をｉ＝１〜Ｎについて実行した後、検証者アルゴリズムＶは、Ｃｍｔ＝Ｈ（ｃ０１，ｃ１１，ｃ２１，…，ｃ０Ｎ，ｃ１Ｎ，ｃ２Ｎ）の等号が成り立つか否かを検証する。検証者アルゴリズムＶは、この検証が成功した場合に認証成功を示す値１を出力し、検証に失敗した場合に認証失敗を示す値０を出力する。
【００９４】
以上、３パス方式に係る効率的な並列化アルゴリズムの構成例について説明した。
【００９５】
＜３：電子署名方式への変形＞
次に、上記の公開鍵認証方式を電子署名方式へと変形する方法を紹介する。
【００９６】
公開鍵認証方式のモデルにおける証明者を電子署名方式における署名者に対応させると、証明者のみが検証者を納得させられるという点において、電子署名方式のモデルと近似していることが容易に理解されよう。こうした考えに基づき、上述した公開鍵認証方式を電子署名方式へと変形する方法について説明する。
【００９７】
［３−１：３パスの公開鍵認証方式から電子署名方式への変形（図６）］
まず、３パスの公開鍵認証方式から電子署名方式への変形について説明する。図６に示すように、３パスの公開鍵認証方式から電子署名方式へ変形したアルゴリズムは、図５で説明した３パス方式のアルゴリズムを並列化したアルゴリズムの一部と同様に構成されている。図５の工程＃１〜工程＃４で表現される公開鍵認証方式のアルゴリズムは、図６に示すような署名生成アルゴリズムＳｉｇ及び署名検証アルゴリズムＶｅｒに変形される。
【００９８】
工程＃１：
図６に示すように、工程＃１は図５の工程＃１と同様である。
【００９９】
工程＃２：
次の工程＃２では、図５で検証者アルゴリズムＶに送ったＣｍｔ←Ｈ（ｃ０１，ｃ１１，ｃ２１，…，ｃ０Ｎ，ｃ１Ｎ，ｃ２Ｎ）を署名検証アルゴリズムＶｅｒには送らずに、署名生成アルゴリズムＳｉｇは、Ｃｍｔと署名を付けたメッセージＭのハッシュ値Ｈ（Ｍ，ｃ０１，ｃ１１，ｃ２１，…，ｃ０Ｎ，ｃ１Ｎ，ｃ２Ｎ）を計算して（Ｃｈ１，・・・，ＣｈＮ）とする。すなわち、署名生成アルゴリズムＳｉｇは、（Ｃｈ１，・・・，ＣｈＮ）←Ｈ（Ｍ，ｃ０１，ｃ１１，ｃ２１，…，ｃ０Ｎ，ｃ１Ｎ，ｃ２Ｎ）を計算する。
【０１００】
工程＃３：
図６に示すように、工程＃３は図５の工程＃３と同様である。署名生成アルゴリズムＳｉｇは、Ｃｈ１，…，ＣｈＮのそれぞれ応じて署名検証アルゴリズムＶｅｒに送るσｉを生成する。Ｃｈｉ＝０の場合、署名生成アルゴリズムＳｉｇは、σｉ＝（ｒ０ｉ，ｔ１ｉ，ｅ１ｉ，ｃ０ｉ）を生成する。Ｃｈｉ＝１の場合、署名生成アルゴリズムＳｉｇは、σｉ＝（ｒ１ｉ，ｔ０ｉ，ｅ０ｉ，ｃ２ｉ）を生成する。Ｃｈｉ＝２の場合、署名生成アルゴリズムＳｉｇは、σｉ＝（ｒ１ｉ，ｔ１ｉ，ｅ１ｉ，ｃ１ｉ）を生成する。
【０１０１】
工程＃３で生成されたＣｈ１，…，ＣｈＮ及びσ１，…，σＮは、署名検証アルゴリズムＶｅｒに送られる。また、同時に、署名を付けたメッセージＭも署名検証アルゴリズムＶｅｒに送られる。
【０１０２】
工程＃４：
図６に示すように、工程＃４は基本的に図５の工程＃４と同様である。返答σ１，…，σＮを受け取った署名検証アルゴリズムＶｅｒは、受け取った返答σ１，…，σＮを利用して以下の処理（１）〜処理（３）をｉ＝１〜Ｎについて実行する。但し、署名検証アルゴリズムＶｅｒは、Ｃｈｉ＝０の場合に処理（１）を実行し、Ｃｈｉ＝１の場合に処理（２）を実行し、Ｃｈｉ＝２の場合に処理（３）を実行する。
【０１０３】
処理（１）：Ｃｈｉ＝０の場合、署名検証アルゴリズムＶｅｒは、σｉから（ｒ０ｉ，ｔ１ｉ，ｅ１ｉ，ｃ０ｉ）を取り出す。次いで、署名検証アルゴリズムＶｅｒは、ｃ１ｉ＝Ｈ（ｒ０ｉ−ｔ１ｉ，Ｆ（ｒ０ｉ）−ｅ１ｉ）を計算する。さらに、署名検証アルゴリズムＶｅｒは、ｃ２ｉ＝Ｈ（ｔ１ｉ，ｅ１ｉ）を計算する。そして、検証者アルゴリズムＶは、（ｃ０ｉ，ｃ１ｉ，ｃ２ｉ）を保持する。
【０１０４】
処理（２）：Ｃｈｉ＝１の場合、署名検証アルゴリズムＶｅｒは、σｉから（ｒ１ｉ，ｔ０ｉ，ｅ０ｉ，ｃ２ｉ）を取り出す。次いで、署名検証アルゴリズムＶｅｒは、ｃ０ｉ＝Ｈ（ｒ１ｉ，Ｇ（ｔ０ｉ，ｒ１ｉ）＋ｅ０ｉ）を計算する。さらに、署名検証アルゴリズムＶｅｒは、ｃ１ｉ＝Ｈ（ｔ０ｉ，ｅ０ｉ）を計算する。そして、署名検証アルゴリズムＶｅｒは、（ｃ０ｉ，ｃ１ｉ，ｃ２ｉ）を保持する。
【０１０５】
処理（３）：Ｃｈｉ＝２の場合、署名検証アルゴリズムＶｅｒは、σｉから（ｒ１ｉ，ｔ１ｉ，ｅ１ｉ，ｃ１ｉ）を取り出す。次いで、署名検証アルゴリズムＶｅｒは、ｃ０ｉ＝Ｈ（ｒ１ｉ，ｙ−Ｆ（ｒ１ｉ）−Ｇ（ｔ１ｉ，ｒ１ｉ）−ｅ１ｉ）を計算する。さらに、署名検証アルゴリズムＶｅｒは、ｃ２ｉ＝Ｈ（ｔ１ｉ，ｅ１ｉ）を計算する。そして、署名検証アルゴリズムＶｅｒは、（ｃ０ｉ，ｃ１ｉ，ｃ２ｉ）を保持する。
【０１０６】
処理（１）〜処理（３）をｉ＝１〜Ｎについて実行した後、署名検証アルゴリズムＶｅｒは、（Ｃｈ１，・・・，ＣｈＮ）＝Ｈ（Ｍ，ｃ０１，ｃ１１，ｃ２１，…，ｃ０Ｎ，ｃ１Ｎ，ｃ２Ｎ）の等号が成り立つか否かを検証する。署名検証アルゴリズムＶｅｒは、この検証が成功した場合に認証成功を示す値１を出力し、検証に失敗した場合に認証失敗を示す値０を出力する。
【０１０７】
以上説明したように、公開鍵認証方式のモデルにおける証明者を電子署名方式における署名者に対応させることで、公開鍵認証方式のアルゴリズムを電子署名方式のアルゴリズムへと変形することが可能になる。
【０１０８】
＜４．具体的な実施形態＞
［４−１：本開示の一実施形態に係るシステムの概要］
上述した電子署名を電子メールに付加することを想定した場合、電子署名は、ある公開鍵に対して有効な署名か否かを検証する技術であり、メールアドレスを検証するものではない。そのため、電子メールに付けられた電子署名の正当性を検証する際には、前述したように電子メールアドレスと公開鍵の対応関係を何らかの方法で別途保証することになる。例えば、電子メールアドレスと公開鍵の対応関係を示すリストをＰＣ内のどこかに格納しておく等の方法により、送信された公開鍵と電子メールアドレスを対応付けすることになる。しかしながら、このような方法では、電子メールアドレスと公開鍵の対応関係を示すリストを別途設ける必要があり、煩雑な処理が必要となる。
【０１０９】
本実施形態は、電子メールアドレスと公開鍵を一体化することにより、電子メールアドレスと公開鍵の対応付けを不要とし、メールアドレスと公開鍵が対応付けされていることの検証を容易に実現するものである。
【０１１０】
このため、本実施形態では、電子メールアドレスと公開鍵が一体になったメールアドレスを利用し、送信者アドレス中の公開鍵を利用して署名検証を行う。図７は、本実施形態に係る電子メールアドレスと公開鍵が一体になったメールアドレスを示す模式図である。図７に示すように、送信者は自身のメールアドレス(sender@example.com)を利用して電子メールを送信する。公開鍵ｐｋをメールアドレスに付加する場合、メールアドレス(sender@example.com)の中に公開鍵ｐｋを付加し、(sender+pk@example.com)としてメール送信する。公開鍵ｐｋは、例えばｂａｓｅ４（６ｂｉｔの情報を一文字で表現する手法）等でエンコードし、メールアドレスと一体化される。このように、本実施形態では、メールアドレス(sender@example.com)の中に公開鍵ｐｋが埋め込まれている。送信側では、メールアドレス(sender@example.com)の中に公開鍵ｐｋが埋め込まれているが、公開鍵ｐｋの部分を無視して電子メールを送信する。
【０１１１】
符号‘＋’は、公開鍵ｐｋが符号‘＋’以降に埋め込まれていることを示している。公開鍵ｐｋは、符号‘＋’と‘＠’との間に埋め込まれた部分である。このことは、送信者側と受信者側とで予め取り決めがされている。
【０１１２】
受信者側では、sender+pk@example.comのメールを受信すると、公開鍵ｐｋを抽出し、メールに付加されたデジタル署名を公開鍵ｐｋで検証した結果（受理又は許可）をユーザに通知する。
【０１１３】
上述したＭＱ方式では、公開鍵ｐｋの長さ（ビット数）を最小限に抑えることができ、１００ビット以下、特に好適には８０ビット（ｂｉｔ）以下で公開鍵ｐｋを構成することができる。従って、特にＭＱ方式による公開鍵ｐｋを用いることで、メールアドレス中への公開鍵ｐｋの埋め込みを容易に行うことができる。一方、ＭＱ方式以外の公開鍵認証プロトコルを用いた場合、公開鍵は１００ビットよりも長いため、メールアドレス中における公開鍵の長さが非常に長くなる。このため、メールアドレスが過度に長いアドレスとなり、メールのアドレスの取扱い、認識等に煩雑な処理、手間が必要となる。従って、特にＭＱ方式による公開鍵ｐｋを用いることで、メールアドレスと公開鍵を一体化した場合であっても、メールアドレスの長さを最小限に抑えることが可能となる。なお、公開鍵の長さを８０ビット以下にできるのは、公開鍵認証方式の中でもＭＱ認証方式のみである。
【０１１４】
このように、本実施形態では、メールアドレスと公開鍵ｐｋが一体となっているため、電子メールの受信者側においては、メールアドレスと公開鍵ｐｋの対応関係を別途保存しておく必要がなく、受信した電子メールの差出人アドレスから公開鍵ｐｋを導き出すことが可能である。従って、電子メールの差出人（送信者）と公開鍵ｐｋとが対応していることを別途検証する必要がなく、電子メールの差出人と公開鍵ｐｋとの対応付けを容易に行うことが可能となる。
【０１１５】
なお、上述の例では、送信時に公開鍵ｐｋをメールアドレスに埋め込むこととしたが、元々メールアドレス中に公開鍵ｐｋが埋め込まれたメールアドレスを取得し、常時に公開鍵ｐｋが埋め込まれたメールアドレス(sender+pk@example.com)を用いるようにしても良い。
【０１１６】
［４−２：メールアドレスの表示状態の例］
図８は、メールアドレスの表示状態の例を示す模式図である。図８においては、送信者が送信する電子メールの宛先がreceiver@example.comであり、送信者の電子メールアドレスが sender@example.comであるものとする。上記と同様に、送信者は自身のメールアドレスsender@example.com)の中に公開鍵ｐｋを付加し、差出人を(sender+pk@example.com)としてメール送信する。このように、送信者側では、差出人メールアドレスをsender+pk@example.comに書き換えて送信できるようなデバイス、サーバを用いる。
【０１１７】
受信側では、差出人が(sender+pk@example.com)である電子メールを受信する。ここで、公開鍵を非表示とすることもできる。公開鍵ｐｋを非表示とする場合、例えば受信者側のデバイス（メール受信側装置４００）では、‘ｐｋ’を‘[+]’に置き換えて差出人を(sender[+]@example.com)としてメールを表示し、‘[+]’をクリックすることにより、公開鍵ｐｋを表示させても良い。
【０１１８】
同じアドレスsender+pk@exapmle.comから届いた２通以上のメールが同一人物から送信されたメールであるか否かを検証することができるため、アドレスが偽装されていないか否かを確実に検証することが可能である。なお、公開鍵基盤（PKI）を利用するわけではないため、公開鍵ｐｋに対応する送信者の身元を検証するものではない。つまり、本実施形態は、送信者のメールアドレスと公開鍵ｐｋを結びつけるものであり、送信者自身と公開鍵ｐｋを結びつけるものではない。
【０１１９】
受信者側では、電子署名σの検証結果を送信者側へ通知する。通知方法としては、一部の表示の色を変える、マークを表示する、などがある。例えば、電子署名σが正規のものであり検証に成功した場合は表示の色を緑色に変更し、検証に失敗した場合は表示の色を赤色に変更して通知を行っても良い。また、検証に成功した場合は「○」のマークを表示し、検証に失敗した場合は「×」のマークを表示しても良い。
【０１２０】
また、表示するマークの具体例として、図９に示すような手書き風サインを表示してもよい。この際、さらに公開鍵によって手書き風サインを変形させることにより、公開鍵の違いをユーザに認識させることもできる。また、公開鍵に応じてフォントを変えるようにしても良い。
【０１２１】
差出人メールアドレス中で公開鍵ｐｋのみが異なる複数の送信者から電子メールが送られてきた場合、それらを同一の送信者とみなすか否かはポリシーにより異なるものとすることができる。但し、このような場合には、送信者アドレスが偽装されている可能性があるため、公開鍵ｐｋのみが異なっており、メールアドレスの他の部分が同一である旨をユーザに通知し、注意喚起を促すことが好適である。
【０１２２】
［４−３：本実施形態のシステムにおける処理について］
次に、本実施形態のシステムにおける処理について説明する。図１０は、本実施形態の処理を示すシーケンス図である。先ず、ステップＳ１０では、メール送信側装置１００が公開鍵ｐｋと秘密鍵ｓｋを生成する。次のステップＳ１２では、メール送信側装置１００が、送信する電子メールについての電子署名σを生成する。
【０１２３】
次のステップＳ１４では、メール送信側装置１００が、元の差出人アドレス(sender@example.com)に公開鍵ｐｋを付加し、差出人アドレスを(sender+pk@example.com)とし、電子署名σを添付して宛先(receiver@example2.com)へ電子メールを送信する。
【０１２４】
次のステップＳ１６では、ステップＳ１４でメール送信側装置１００が送信した電子メールをメール送信サーバ２００が受信する。メール送信サーバは、差出人のアドレスの(sender+pk@example.com)のうち、‘＋’と‘＠’の間の‘ｐｋ’を無視して(sender@example.com)のアカウントからのメールとして処理を行う。これにより、メール送信サーバ２００が、メール送信側装置１００から送信されてきた電子メールがアカウント(sender+pk@example.com)の未知のユーザから送られてきたものと判断することがなく、電子メールが正常に送信されない事態を回避できる。
【０１２５】
次のステップＳ１８では、メール送信サーバ２００が、電子メールをメール受信サーバ３００へ送信する。ステップＳ１８で送信された電子メールは、メールプロトコル(smtp)に従って、(receiver@example2.com)のメール受信サーバ３００が受信する。
【０１２６】
次のステップＳ２０では、メール受信サーバ３００がメール受信側装置４００へ電子メールを送信し、メール受信側装置４００が電子メールを受信する。電子メールを受信したメール受信側装置４００は、ステップＳ２２において、差出人アドレス(sender+pk@example.com)を参照し、‘＋’と‘＠’の間のｐｋを公開鍵とみなし、公開鍵を抽出する。そして、メール受信側装置４００は、添付された電子署名σが電子メールに対する正しい署名であるか否かを、図６で説明した電子署名の認証による検証する。この際、電子メールの文書がメッセージＭに相当するものとすることができる。また、メール送信側装置１００は署名者に対応し、メール受信側装置４００は検証者に対応する。そして、メール受信側装置４００は、検証の結果、電子メールを受理するか、又は拒否するかをメール送信側装置１００へ通知する。
【０１２７】
［４−３：公開鍵に基づく送信者の確認］
以上のように電子メールアドレスと公開鍵ｐｋを一体化する手法によれば、異なるアドレスから送信された電子メールであっても、差出人アドレスに同一の公開鍵ｐｋが含まれていれば、同一の送信者であることが確認できる。
【０１２８】
例えば、異なるアドレスから送信されたメールでも、差出人アドレスに同一の公開鍵が含まれていれば、同一の送信者であることが確認できる。例えば、kuma@gmail.comとpanda@hotmail.comの２つのアドレスから電子メールが送信された場合、２つの送信者が同一か否かを判定することはできない。
【０１２９】
しかしながら、本実施形態によれば、公開鍵と電子メールアドレスが一体化されるため、上記２つのアドレスから送信された電子メールの差出人は、以下の２つとなる。
kuma+pkA@gmail.com
panda+pkA@hotmail.com
【０１３０】
公開鍵pkAで電子署名を付けることができるのは、公開鍵pkAに対応する秘密鍵skAを保有しているユーザのみであるため、送信された２つのメールが同一人物から送信されたメールであることを確認することが可能である。
【０１３１】
［４−４：送信サーバによる公開鍵の付加］
上述した例では、メール送信側装置１００（送信者自身）が公開鍵ｐｋを送信者アドレス(sender@example.com)に付加して送信していた。一方、送信者アドレス(sender@example.com)への公開鍵ｐｋの付加は、メール送信サーバ２００が行っても良い。この場合、送信者自身が送信時に公開鍵ｐｋを付加するのではなく、送信者があらかじめ送信メールサーバ２００に自身の公開鍵ｐｋを登録しておき、送信者が電子署名を付加したメールを送信すると、送信サーバが自動で公開鍵ｐｋを送信者アドレスに付加し、メールを配信する。これにより、送信者が送信者アドレスに自身の公開鍵ｐｋを付加する必要がなく、処理を簡素にすることができる。
【０１３２】
図１１は、メール送信サーバ２００が公開鍵ｐｋを付加する場合の処理を示すシーケンス図である。先ず、ステップＳ２０では、メール送信側装置１００が公開鍵ｐｋと秘密鍵ｓｋを生成する。次のステップＳ２２では、メール送信側装置１００が、メール送信サーバ２００へ公開鍵ｐｋを送信する。ステップＳ２３では、メール送信サーバ２００が公開鍵ｐｋを登録する。このように、メール送信側装置１００は、利用する公開鍵ｐｋを予めメール送信サーバ２００へ登録しておく。メール送信サーバ２００は、送信者アドレス(sender@example.com)と公開鍵ｐｋを対応付けて記憶しておく。
【０１３３】
次のステップＳ２４では、メール送信側装置１００が、送信する電子メールについての電子署名σを生成する。
【０１３４】
次のステップＳ２６では、メール送信側装置１００が、差出人を(sender @example.com)とし、電子署名σを添付して宛先(receiver@example2.com)へ電子メールを送信する。
【０１３５】
次のステップＳ２８では、ステップＳ２６でメール送信側装置１００が送信した電子メールをメール送信サーバ２００が受信する。そして、メール送信サーバ２００は、差出人のアドレス(sender@example.com)に対応する公開鍵ｐｋを差出人のアドレスに付加し、(sender+pk@example.com)と変更する。
【０１３６】
次のステップＳ３０では、メール送信サーバ２００が、電子メールをメール受信サーバ３００へ送信する。ステップＳ３０で送信された電子メールは、メールプロトコル(smtp)に従って、(receiver@example2.com)のメール受信サーバ３００が受信する。
【０１３７】
次のステップＳ３２では、電子メールを受信したメール受信サーバ３００が、メール受信側装置４００へ電子メールを送信する。電子メールを受信したメール受信側装置４００は、差出人アドレス(sender+pk@example.com)を参照し、‘＋’と‘＠’の間のｐｋを公開鍵とみなし、添付された電子署名σが電子メールに対する正しい署名であるか否かを検証する（ステップＳ３４）。そして、メール受信側装置４００は、検証の結果、電子メールを受理するか、又は拒否するかをメール送信側装置１００へ通知する。
【０１３８】
［４−５：本実施形態のシステム構成例］
図１２は、本実施形態のシステムにおいて、メール送信側装置１００、及びメール受信側装置４００の構成を示す模式図である。メール送信側装置１００は、鍵生成部１０２、鍵保管部１０４、電子署名生成部１０６、メール作成部１０８、公開鍵情報付加部１１０、メール送信部１１２、操作入力部１１８を有して構成されている。鍵生成部１０２は、公開鍵ｐｋと暗号鍵ｓｋのペアを生成する。具体的には、鍵生成部１０２は、図６の工程＃１を含む処理を行う。鍵保管部１０４は、鍵生成部１０２が生成した公開鍵ｐｋと秘密鍵ｓｋを保管する記憶部である。なお、公開鍵ｐｋと暗号鍵ｓｋのペアを外部の装置で生成して鍵保管部１０４に保管しても良い。電子署名生成部１０６は、図６の工程＃２，＃３の処理を行い、電子署名σを生成する。メール作成部１０８は、操作入力部１１８に入力された情報等に基づいて、メール受信側装置４００へ送信する電子メールを作成する。メール作成部１０８は、作成した電子メールに電子署名σを添付する。公開鍵情報付加部１１０は、電子メールの差出人アドレスに公開鍵ｐｋを付加する。この際、公開鍵情報付加部１１０は、ｂａｓｅ６４等の手法により公開鍵ｐｋをエンコードして付加することができる。メール送信部１１２は、電子署名σが添付され、差出人アドレスに公開鍵ｐｋが付加された電子メールを送信する。検証結果受信部１１４は、メール受信側装置４００から送信された検証結果を受信する。検証結果表示部１１６は、受信した検証結果に応じた表示を行う。操作入力部１１８は、ユーザが操作を行うことで情報が入力されるタッチセンサ、キーボード等の構成要素である。
【０１３９】
また、メール受信側装置４００は、メール受信部４０２、構造解析部（公開鍵抽出部）４０４、メール表示部４０６、電子署名検証部４０８、検証結果表示部４１２、操作入力部４１０を有して構成されている。メール受信部４０２は、メール送信側装置１００が送信した電子メールを、メール送信サーバ２００、メール受信サーバ３００を介して受信する。構造解析部４０４は、電子メールの差出人アドレスの構造を解析し、差出人アドレスから公開鍵ｐｋを抽出する。具体的には、構造解析部４０４は、差出人メールアドレスの‘＋’と‘＠’の間の文字列を公開鍵ｐｋとして抽出する。また、構造解析部４０４は、ｂａｓｅ６４等の手法によりエンコードされた公開鍵ｐｋをデコードすることができる。公開鍵ｐｋは署名検証部４０８へ送られる。メール表示部４０２は、電子メールの内容を表示する。署名検証部４０８は、図６の工程＃４の処理を行い、電子メールに添付された電子署名σを検証する。検証結果は、検証結果表示部４１２により表示される。操作入力部４１０は、ユーザが操作を行うことで情報が入力されるタッチセンサ、キーボード等の構成要素である。
【０１４０】
図１３は、上述したメール送信サーバ２００が自動で公開鍵ｐｋを送信者アドレス付加する例における、メール送信サーバ２００の構成を示す模式図である。図１３に示すように、メール送信サーバ２００は、メール受信部２０２、公開鍵情報保管部２０４、公開鍵情報付加部２０６、メール送信部２０８を有して構成されている。メール受信部２０２は、メール送信側装置１００のメール作成部１０８が作成した電子メールを受信する。この電子メールには、電子署名σが添付されているが、差出人アドレスに公開鍵ｐｋは付加されていない。公開鍵情報保管部２０４は、公開鍵ｐｋを保管する記憶部であって、電子メールの差出人アドレスと公開鍵ｐｋとを対応付けて記憶している。公開鍵情報付加部２０４は、メール受信部２０２が受信した電子メールの差出人アドレスに対応する公開鍵ｐｋを公開鍵情報保管部２０４から抽出し、抽出した公開鍵ｐｋを電子メールの差出人アドレスに付加する。メール送信部１１２は、電子署名σが添付され、差出人アドレスに公開鍵ｐｋが付加された電子メールをメール受信サーバ３００へ送信する。
【０１４１】
なお、図１２及び図１３に示す各構成要素は、ハードウェア（回路）、またはＣＰＵなどの中央演算処理装置とこれを機能させるためのプログラム（ソフトウェア）によって構成されることができる。この場合に、そのプログラムは、各装置が備えるメモリ、または外部から各装置に接続される外部メモリ等の記録媒体に格納されることができる。
【０１４２】
［４−６：メール転送、メーリングリストへの適用例］
次に、メール転送、メーリングリストの差出人アドレスへの適用について説明する。メール転送時、またはメーリングリストにおいては、メールサーバによって差出人が変更されてメール配信が行われることがある。このような場合、差出人の変更によって真の差出人が不明になってしまうことも想定される。
【０１４３】
このような場合、アドレスに付加された公開鍵はそのままにして、差出人アドレスのみを書き換える、という適用を行う。例えば、メーリングリストに投稿した真の差出人のアドレスを「OriginalAdress+pkA@example.com」とし、メーリングリストから配信される際に表示される差出人アドレスを「MailingListAdress+pkA@example2.com」とする。このように、差出人のアドレスが変更された場合であっても、公開鍵ｐｋＡの部分は変更しないようにする。これにより、差出人アドレスが変更されても、公開鍵の部分さえ一致していれば、電子メールの受信側では、同一人物が送信したメールであることが確認できる
【０１４４】
［４−７：公開鍵部分の指定方法について］
上述した実施形態では、差出人メールアドレス中の公開鍵部分を‘＋’と‘＠’の間として指定したが、その指定方法は特に制限はなく、上述の例に限定されるものではない。例えば、以下のように、アドレスの先頭から‘＋’までを公開鍵ｐｋＡとして指定することができる。
pkA+sender@example.com
【０１４５】
また、以下のように、‘＋’からアドレスの末尾までを公開鍵ｐｋＡとして指定することができる。
sender@example.com+pkA
【０１４６】
また、上記の‘＋’はエスケープシーケンスを意味するものであるが、プラス‘＋’の記号以外の記号を利用することも勿論可能である。公開鍵部分の指定は、メールアドレス中でどの部分が公開鍵ｐｋであるかが判るように指定できれば、どのような方法を用いても構わない。
【０１４７】
＜９：ハードウェア構成例（図１４）＞
上記の各アルゴリズムは、例えば、図１４に示す情報処理装置のハードウェア構成を用いて実行することが可能である。つまり、当該各アルゴリズムの処理は、コンピュータプログラムを用いて図１４に示すハードウェアを制御することにより実現される。なお、このハードウェアの形態は任意であり、例えば、パーソナルコンピュータ、携帯電話、ＰＨＳ、ＰＤＡ等の携帯情報端末、ゲーム機、接触式又は非接触式のＩＣチップ、接触式又は非接触式のＩＣカード、又は種々の情報家電がこれに含まれる。但し、上記のＰＨＳは、Ｐｅｒｓｏｎａｌ  Ｈａｎｄｙ−ｐｈｏｎｅ  Ｓｙｓｔｅｍの略である。また、上記のＰＤＡは、Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔの略である。
【０１４８】
図１４に示すように、このハードウェアは、主に、ＣＰＵ９０２と、ＲＯＭ９０４と、ＲＡＭ９０６と、ホストバス９０８と、ブリッジ９１０と、を有する。さらに、このハードウェアは、外部バス９１２と、インターフェース９１４と、入力部９１６と、出力部９１８と、記憶部９２０と、ドライブ９２２と、接続ポート９２４と、通信部９２６と、を有する。但し、上記のＣＰＵは、Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔの略である。また、上記のＲＯＭは、Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙの略である。そして、上記のＲＡＭは、Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙの略である。
【０１４９】
ＣＰＵ９０２は、例えば、演算処理装置又は制御装置として機能し、ＲＯＭ９０４、ＲＡＭ９０６、記憶部９２０、又はリムーバブル記録媒体９２８に記録された各種プログラムに基づいて各構成要素の動作全般又はその一部を制御する。ＲＯＭ９０４は、ＣＰＵ９０２に読み込まれるプログラムや演算に用いるデータ等を格納する手段である。ＲＡＭ９０６には、例えば、ＣＰＵ９０２に読み込まれるプログラムや、そのプログラムを実行する際に適宜変化する各種パラメータ等が一時的又は永続的に格納される。
【０１５０】
これらの構成要素は、例えば、高速なデータ伝送が可能なホストバス９０８を介して相互に接続される。一方、ホストバス９０８は、例えば、ブリッジ９１０を介して比較的データ伝送速度が低速な外部バス９１２に接続される。また、入力部９１６としては、例えば、マウス、キーボード、タッチパネル、ボタン、スイッチ、及びレバー等が用いられる。さらに、入力部９１６としては、赤外線やその他の電波を利用して制御信号を送信することが可能なリモートコントローラ（以下、リモコン）が用いられることもある。
【０１５１】
出力部９１８としては、例えば、ＣＲＴ、ＬＣＤ、ＰＤＰ、又はＥＬＤ等のディスプレイ装置、スピーカ、ヘッドホン等のオーディオ出力装置、プリンタ、携帯電話、又はファクシミリ等、取得した情報を利用者に対して視覚的又は聴覚的に通知することが可能な装置である。但し、上記のＣＲＴは、Ｃａｔｈｏｄｅ  Ｒａｙ  Ｔｕｂｅの略である。また、上記のＬＣＤは、Ｌｉｑｕｉｄ  Ｃｒｙｓｔａｌ  Ｄｉｓｐｌａｙの略である。そして、上記のＰＤＰは、Ｐｌａｓｍａ  ＤｉｓｐｌａｙＰａｎｅｌの略である。さらに、上記のＥＬＤは、Ｅｌｅｃｔｒｏ−Ｌｕｍｉｎｅｓｃｅｎｃｅ  Ｄｉｓｐｌａｙの略である。
【０１５２】
記憶部９２０は、各種のデータを格納するための装置である。記憶部９２０としては、例えば、ハードディスクドライブ（ＨＤＤ）等の磁気記憶デバイス、半導体記憶デバイス、光記憶デバイス、又は光磁気記憶デバイス等が用いられる。但し、上記のＨＤＤは、Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅの略である。
【０１５３】
ドライブ９２２は、例えば、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリ等のリムーバブル記録媒体９２８に記録された情報を読み出し、又はリムーバブル記録媒体９２８に情報を書き込む装置である。リムーバブル記録媒体９２８は、例えば、ＤＶＤメディア、Ｂｌｕ−ｒａｙメディア、ＨＤ  ＤＶＤメディア、各種の半導体記憶メディア等である。もちろん、リムーバブル記録媒体９２８は、例えば、非接触型ＩＣチップを搭載したＩＣカード、又は電子機器等であってもよい。但し、上記のＩＣは、Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔの略である。
【０１５４】
接続ポート９２４は、例えば、ＵＳＢポート、ＩＥＥＥ１３９４ポート、ＳＣＳＩ、ＲＳ−２３２Ｃポート、又は光オーディオ端子等のような外部接続機器９３０を接続するためのポートである。外部接続機器９３０は、例えば、プリンタ、携帯音楽プレーヤ、デジタルカメラ、デジタルビデオカメラ、又はＩＣレコーダ等である。但し、上記のＵＳＢは、Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓの略である。また、上記のＳＣＳＩは、Ｓｍａｌｌ  Ｃｏｍｐｕｔｅｒ  Ｓｙｓｔｅｍ  Ｉｎｔｅｒｆａｃｅの略である。
【０１５５】
通信部９２６は、ネットワーク９３２に接続するための通信デバイスであり、例えば、有線又は無線ＬＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、又はＷＵＳＢ用の通信カード、光通信用のルータ、ＡＤＳＬ用のルータ、又は接触又は非接触通信用のデバイス等である。また、通信部９２６に接続されるネットワーク９３２は、有線又は無線により接続されたネットワークにより構成され、例えば、インターネット、家庭内ＬＡＮ、赤外線通信、可視光通信、放送、又は衛星通信等である。但し、上記のＬＡＮは、Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋの略である。また、上記のＷＵＳＢは、Ｗｉｒｅｌｅｓｓ  ＵＳＢの略である。そして、上記のＡＤＳＬは、Ａｓｙｍｍｅｔｒｉｃ  Ｄｉｇｉｔａｌ  Ｓｕｂｓｃｒｉｂｅｒ  Ｌｉｎｅの略である。
【０１５６】
以上で述べた技術内容は、例えば、ＰＣ、携帯電話、ゲーム機、情報端末、情報家電、カーナビゲーションシステム等、種々の情報処理装置に対して適用することができる。なお、以下で述べる情報処理装置の機能は、１台の情報処理装置を利用して実現することも可能であるし、複数台の情報処理装置を利用して実現することも可能である。また、以下で述べる情報処理装置が処理を実行する際に用いるデータ記憶手段及び演算処理手段は、当該情報処理装置に設けられたものであってもよいし、ネットワークを介して接続された機器に設けられたものであってもよい。
【０１５７】
以上説明したように本実施形態によれば、電子メールの差出人のメールアドレスと公開鍵ｐｋを一体化したことにより、受信者側でメールアドレスと公開鍵ｐｋを対応付けるための処理が不要となる。従って、公開鍵ｐｋを用いた電子署名σの検証を容易に行うことが可能となる。
【０１５８】
以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。
【０１５９】
なお、以下のような構成も本開示の技術的範囲に属する。
（１）電子署名が添付された電子メールの差出人アドレスに前記電子署名に対応する公開鍵の情報を付加する公開鍵情報付加部と、
前記電子メールを送信する送信部と、
を備える、送信装置。
（２）前記公開鍵と秘密鍵とをペアで生成する鍵生成部と、
前記電子署名を生成する署名生成部と、
前記電子署名が添付された前記電子メールを作成する電子メール作成部と、
を更に備える、前記（１）に記載の送信装置。
（３）前記電子署名が添付された前記電子メールを他装置から受信する受信部と、前記電子署名に対応する前記公開鍵の情報を保管する公開鍵情報保管部と、を備え、前記公開鍵情報付加部は、前記他装置から受信した前記電子メールの差出人アドレスに前記公開鍵情報保管部から抽出した前記公開鍵の情報を付加する、前記（１）に記載の送信装置。
（４）前記電子メールを受信した受信装置から、前記公開鍵の情報に基づいて前記電子署名を検証した結果を受信する検証結果受信部を更に備える、前記（１）〜（３）のいずれかに記載の送信装置。
（５）前記電子署名は、ＭＱプロトコルによる電子署名である、前記（１）〜（４）のいずれかに記載の送信装置。
（６）電子署名が添付された電子メールを受信する受信部と、
前記電子メールの差出人アドレスに付加された前記電子署名に対応する公開鍵の情報を抽出する公開鍵情報抽出部と、
前記公開鍵の情報に基づいて前記電子署名を検証する検証部と、
を備える、受信装置。
（７）前記検証部による検証結果を送信する送信部を更に備える、前記（６）に記載の受信装置。
（８）前記送信部は、前記検証結果に応じて、文字又はマークの表示、若しくは表示色を変更させて、前記検証結果を送信先の装置に表示させる、前記（７）に記載の受信装置。
（９）前記電子メールは、メーリングリストから転送された電子メールであり、メーリングリストに投稿した投稿者のメールアドレスに前記公開鍵の情報と同一の情報が含まれる、前記（６）〜（８）のいずれかに記載の受信装置。
（１０）前記電子署名は、ＭＱプロトコルによる電子署名である、前記（６）〜（９）のいずれかに記載の送信装置。
（１１）電子署名が添付された電子メールの差出人アドレスに前記電子署名に対応する公開鍵の情報を付加することと、
前記電子メールを送信することと、
を備える、送信方法。
（１２）電子署名が添付された電子メールの差出人アドレスに前記電子署名に対応する公開鍵の情報を付加する手段、
前記電子メールを送信する手段、
としてコンピュータを機能させるためのプログラム。
（１３）電子署名が添付された電子メールを受信することと、
前記電子メールの差出人アドレスに付加された前記電子署名に対応する公開鍵の情報を抽出することと、
前記公開鍵の情報に基づいて前記電子署名を検証することと、
を備える、受信方法。
（１４）電子署名が添付された電子メールを受信する手段、
前記電子メールの差出人アドレスに付加された前記電子署名に対応する公開鍵の情報を抽出する手段、
前記公開鍵の情報に基づいて前記電子署名を検証する手段、
としてコンピュータを機能させるためのプログラム。
【符号の説明】
【０１６０】
１００    メール送信側装置
１０２    鍵生成部
１０６    署名生成部
１０８    メール作成部
１１０    公開鍵情報付加部
１１２    メール送信部
１１４    検証結果受信部
２００    メール送信サーバ
２０２    メール受信部
４００    メール受信側装置
４０２    メール受信部
４０４    構造解析部
４０８    署名検証部
４１２    検証結果送信部
【図１】
2014068139.tif 000012
【図２】
2014068139.tif 000013
【図３】
2014068139.tif 000014
【図４】
2014068139.tif 000015
【図５】
2014068139.tif 000016
【図６】
2014068139.tif 000017
【図７】
2014068139.tif 000018
【図８】
2014068139.tif 000019
【図９】
2014068139.tif 000020
【図１０】
2014068139.tif 000021
【図１１】
2014068139.tif 000022
【図１２】
2014068139.tif 000023
【図１３】
2014068139.tif 000024
【図１４】
2014068139.tif 000025