(57)【要約】【課題】名刺やカードなどの表示媒体に表示された公開鍵を人間が直接読み取ることができるようにする。【解決手段】本開示に係る名刺は、公開鍵認証方式の認証に用いる公開鍵が目視で認識できる文字情報として表示されている。この構成により、名刺の持ち主は、名刺を配ることで、名刺を受け取ったユーザに目視で認識可能な公開鍵を通知することが可能となる。これにより、名刺を受け取ったユーザは、名刺に記載された公開鍵１０２に基づいて、任意に取得した他の公開鍵との対比を目視で行うことが可能となる。【選択図】図８
2014087969.tif 000002
【特許請求の範囲】
【請求項１】
公開鍵認証方式の認証に用いる公開鍵が目視で認識できる文字情報として表示された、印刷媒体。
【請求項２】
前記公開鍵認証方式はＭＱ認証方式に対応し、前記公開鍵の文字情報は８０ビット以下の情報が符号化された情報である、請求項１に記載の印刷媒体。
【請求項３】
前記公開鍵の文字情報は複数のチャンクに区切られており、１つのチャンクが４文字以下である、請求項２に記載の印刷媒体。
【請求項４】
前記公開鍵の文字情報は、７以下のチャンクに区切られている、請求項２に記載の印刷媒体。
【請求項５】
前記公開鍵の文字情報は、誤り検出又は誤り訂正に関する情報を含む、請求項１に記載の印刷媒体。
【請求項６】
前記公開鍵の文字情報は、文字情報をデコードする方式に関する情報を含む、請求項１に記載の印刷媒体。
【請求項７】
前記公開鍵の文字情報は、公開鍵認証方式による認証を行う認証装置に入力されるために用いられる、請求項１に記載の印刷媒体。
【請求項８】
前記公開鍵の文字情報は、公開鍵認証方式の認証を行う認証装置に登録された公開鍵との一致を判断するために用いられる、請求項１に記載の印刷媒体。
【請求項９】
前記公開鍵の文字情報は、任意のユーザがネットワークを介して公開している公開鍵との一致を判断するために用いられる、請求項１に記載の印刷媒体。
【請求項１０】
持ち主の氏名に関する情報を含み、名刺として用いられる、請求項１に記載の印刷媒体。
【請求項１１】
名刺に記載される氏名、会社名を含む基本事項を入力することと、
公開鍵認証方式の認証に用いる公開鍵を目視で把握できる文字情報として名刺に記載するために入力することと、
前記基本事項及び前記公開鍵の前記文字情報を含む名刺の印刷を指示することと、
を備える、名刺の作成方法。
【請求項１２】
名刺に記載される氏名、会社名を含む基本事項を入力する手段、
公開鍵認証方式の認証に用いる公開鍵を目視で把握できる文字情報として名刺に記載するために入力する手段、
前記基本事項及び前記公開鍵の前記文字情報を含む名刺の印刷を指示する手段、
としてコンピュータを機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、印刷媒体、名刺の作成方法及びプログラムに関する。
【背景技術】
【０００２】
従来、下記の特許文献１には、公開鍵を記録した磁気記録名刺を利用することが記載されている。また、下記の特許文献２には、名刺に「氏名、住所、メールアドレスなどの個人情報をコード化した第１のＱＲコード」と「公開鍵をコード化した第２のＱＲコード」を記録することが記載されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平９−１１４７１９号公報
【特許文献２】特開２００７−１６８０９９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、上記従来の技術では、名刺に記載された公開鍵を人間が直接読み取ることができないため、公開鍵を読み取るために専用の装置が必要になるという問題がある。例えば、特許文献１では公開鍵を読み取るために磁気的な読み取り装置が必要となり、特許文献２では公開鍵を読み取るためにＱＲコードリーダが必要となる。
【０００５】
そこで、名刺やカードなどの印刷媒体に表示された公開鍵を人間が直接読み取ることができるようにすることが求められていた。
【課題を解決するための手段】
【０００６】
本開示によれば、公開鍵認証方式の認証に用いる公開鍵が目視で認識できる文字情報として表示された、印刷媒体が提供される。
【０００７】
また、前記公開鍵認証方式はＭＱ認証方式に対応し、前記公開鍵の文字情報は８０ビット以下の情報が符号化された情報であっても良い。
【０００８】
また、前記公開鍵の文字情報は複数のチャンクに区切られており、１つのチャンクが４文字以下であっても良い。
【０００９】
また、前記公開鍵の文字情報は、７以下のチャンクに区切られているものであっても良い。
【００１０】
また、前記公開鍵の文字情報は、誤り検出又は誤り訂正に関する情報を含むものであっても良い。
【００１１】
また、前記公開鍵の文字情報は、文字情報をデコードする方式に関する情報を含むものであっても良い。
【００１２】
また、前記公開鍵の文字情報は、公開鍵認証方式による認証を行う認証装置に入力されるために用いられるものであっても良い。
【００１３】
また、前記公開鍵の文字情報は、公開鍵認証方式の認証を行う認証装置に登録された公開鍵との一致を判断するために用いられるものであっても良い。
【００１４】
また、前記公開鍵の文字情報は、任意のユーザがネットワークを介して公開している公開鍵との一致を判断するために用いられるものであっても良い。
【００１５】
また、持ち主の氏名に関する情報を含み、名刺として用いられるものであっても良い。
【００１６】
また、本開示によれば、名刺に記載される氏名、会社名を含む基本事項を入力することと、公開鍵認証方式の認証に用いる公開鍵を目視で把握できる文字情報として名刺に記載するために入力することと、前記基本事項及び前記公開鍵の前記文字情報を含む名刺の印刷を指示することと、を備える、名刺の作成方法が提供される。
【００１７】
また、本開示によれば、名刺に記載される氏名、会社名を含む基本事項を入力する手段、公開鍵認証方式の認証に用いる公開鍵を目視で把握できる文字情報として名刺に記載するために入力する手段、前記基本事項及び前記公開鍵の前記文字情報を含む名刺の印刷を指示する手段、としてコンピュータを機能させるためのプログラムが提供される。
【発明の効果】
【００１８】
本開示によれば、名刺やカードなどの印刷媒体に表示された公開鍵を人間が直接読み取ることが可能となる。
【図面の簡単な説明】
【００１９】
【図１】公開鍵認証方式のアルゴリズムについて概要を説明するための模式図である。
【図２】電子署名方式のアルゴリズムについて概要を説明するための模式図である。
【図３】ｎパスの公開鍵認証方式について説明するための説明図である。
【図４】３パス方式に係る具体的なアルゴリズムの構成について説明するための説明図である。
【図５】図４に示した３パス方式のアルゴリズムを並列化する方法について説明するための模式図である。
【図６】３パスの公開鍵認証方式から電子署名方式への変形を説明するための模式図である。
【図７】本実施形態に係る公開鍵を印刷した名刺と、公開鍵の情報をＱＲコードでコード化して印刷した名刺を示す模式図である。
【図８】８０ビットの公開鍵をｂａｓｅ６４で１４文字にエンコードし、４文字−３文字−３文字−４文字の４チャンクに編集して名刺に印刷した場合を示す模式図である。
【図９】８０ビットの公開鍵をｂａｓｅ６４で１４文字にエンコードし、３文字−３文字−２文字−３文字−３文字の５チャンクに編集して名刺に印刷した場合を示す模式図である。
【図１０】８０ｂｉｔの公開鍵をｂａｓｅ６４で１４文字にエンコードし、５文字−４文字−５文字の３チャンクに編集して名刺に印刷した場合を示す模式図である。
【図１１】１６０ｂｉｔの公開鍵をｂａｓｅ６４で２７文字にエンコードし、４文字−４文字−４文字−４文字−４文字−４文字−３文字の７チャンクに編集して名刺に印刷した場合を示す模式図である。
【図１２】１６０ｂｉｔの公開鍵をｂａｓｅ６４で２７文字にエンコードし、５文字−５文字−４文字−４文字−４文字−５文字の６チャンクに編集して名刺に印刷した場合を示す模式図である。
【図１３】公開鍵をｂａｓｅ６４で１６文字にエンコードし、４文字×４文字の１６文字平方に編集して名刺に記載した例を示す模式図である。
【図１４】公開鍵をｂａｓｅ６４でエンコードし、前半部分と後半部分の２つに分割して表示した場合を示す模式図である。
【図１５】署名の検証処理を行う検証装置が保持する公開鍵と、名刺１００に記載された公開鍵の情報が一致しているか否かを確認する処理を示すフローチャートである。
【図１６】公開鍵を検証装置に入力する処理を示すフローチャートである。
【図１７】本実施形態に係る、検証装置とクライアント端末からなるシステムの構成を示す模式図である。
【図１８】名刺を作成する処理を示すフローチャートである。
【発明を実施するための形態】
【００２０】
以下に添付図面を参照しながら、本技術の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【００２１】
［説明の流れについて］
ここで、以下に記載する本技術の実施形態に関する説明の流れについて簡単に述べる。まず、図１を参照しながら、公開鍵認証方式のアルゴリズム構成について説明する。次いで、図２を参照しながら、電子署名方式のアルゴリズム構成について説明する。次いで、図３を参照しながら、ｎパスの公開鍵認証方式について説明する。
【００２２】
次いで、図４〜図６を参照しながら、３パスの公開鍵認証方式に係るアルゴリズムの構成例について説明する。次いで、図７〜図１８を参照しながら、本開示の一実施形態について説明する。
【００２３】
（説明項目）
１：はじめに
１−１：公開鍵認証方式のアルゴリズム
１−２：電子署名方式のアルゴリズム
１−３：ｎパスの公開鍵認証方式
２：３パスの公開鍵認証方式に係るアルゴリズムの構成
２−１：具体的なアルゴリズムの構成例
２−２：並列化アルゴリズムの構成例
３：電子署名方式への変形
３−１：３パスの公開鍵認証方式から電子署名方式への変形
４：具体的な実施形態
４−１：本開示の一実施形態に係るシステムの概要
４−２：公開鍵の名刺への記載例
４−３：本実施形態に係る名刺が使用される状況
４−４：本実施形態に係るシステムの構成例
４−５：名刺を作成する処理
４−６：公開鍵に誤り検出符号または誤り訂正符号を付加する例
４−７：ｂａｓｅ６４以外の符号化方法
【００２４】
＜１：はじめに＞
本実施形態は、多次多変数連立方程式に対する求解問題の困難性に安全性の根拠をおく公開鍵認証方式及び電子署名方式に関する。但し、本実施形態は、ＨＦＥ電子署名方式などの従来手法とは異なり、効率的に解く手段（トラップドア）を持たない多次多変数連立方程式を利用する公開鍵認証方式及び電子署名方式に関する。まず、公開鍵認証方式のアルゴリズム、電子署名方式のアルゴリズム、及びｎパスの公開鍵認証方式について、その概要を簡単に説明する。
【００２５】
［１−１：公開鍵認証方式のアルゴリズム］
まず、図１を参照しながら、公開鍵認証方式（ＭＱ認証方式）のアルゴリズムについて概要を説明する。図１は、公開鍵認証方式のアルゴリズムについて概要を説明するための説明図である。
【００２６】
公開鍵認証は、ある人（証明者）が、公開鍵ｐｋ及び秘密鍵ｓｋを利用して、他の人（検証者）に本人であることを納得させるために利用される。例えば、証明者Ａの公開鍵ｐｋＡは、検証者Ｂに公開される。一方、証明者Ａの秘密鍵ｓｋＡは、証明者Ａにより秘密に管理される。公開鍵認証の仕組みにおいては、公開鍵ｐｋＡに対応する秘密鍵ｓｋＡを知る者が証明者Ａ本人であるとみなされる。
【００２７】
公開鍵認証の仕組みを利用して証明者Ａが証明者Ａ本人であることを検証者Ｂに証明するには、対話プロトコルを介して、証明者Ａが公開鍵ｐｋＡに対応する秘密鍵ｓｋＡを知っているという証拠を検証者Ｂに提示すればよい。そして、証明者Ａが秘密鍵ｓｋＡを知っているという証拠が検証者Ｂに提示され、その証拠を検証者Ｂが確認し終えた場合、証明者Ａの正当性（本人であること）が証明されたことになる。
【００２８】
但し、公開鍵認証の仕組みには、安全性を担保するために以下の条件が求められる。
【００２９】
１つ目の条件は、「対話プロトコルを実行した際に秘密鍵ｓｋを持たない偽証者により偽証が成立してしまう確率を限りなく小さくする」ことである。この１つ目の条件が成り立つことを「健全性」と呼ぶ。つまり、健全性とは、「秘密鍵ｓｋを持たない偽証者により、対話プロトコルの実行中に無視できない確率で偽証が成立することはないこと」と言い換えられる。２つ目の条件は、「対話プロトコルを実行したとしても、証明者Ａが有する秘密鍵ｓｋＡの情報が検証者Ｂに一切漏れることがない」ことである。この２つ目の条件が成り立つことを「零知識性」と呼ぶ。
【００３０】
安全に公開鍵認証を行うには、健全性及び零知識性を有する対話プロトコルを利用する必要がある。仮に、健全性及び零知識性を有しない対話プロトコルを用いて認証処理を行った場合には、偽証された可能性及び秘密鍵の情報が漏れてしまった可能性が否定できないため、処理自体が成功裡に完了しても証明者の正当性を証明したことにはならない。従って、対話プロトコルの健全性及び零知識性を如何に保証するかが重要になる。
【００３１】
（モデル）
公開鍵認証方式のモデルには、図１に示すように、証明者と検証者という２つのエンティティが存在する。証明者は、鍵生成アルゴリズムＧｅｎを用いて、証明者固有の秘密鍵ｓｋと公開鍵ｐｋの組を生成する。次いで、証明者は、鍵生成アルゴリズムＧｅｎを用いて生成した秘密鍵ｓｋと公開鍵ｐｋの組を利用して検証者と対話プロトコルを実行する。このとき、証明者は、証明者アルゴリズムＰを利用して対話プロトコルを実行する。上記の通り、証明者は、証明者アルゴリズムＰを利用し、対話プロトコルの中で秘密鍵ｓｋを保有している証拠を検証者に提示する。
【００３２】
一方、検証者は、検証者アルゴリズムＶを利用して対話プロトコルを実行し、証明者が公開している公開鍵に対応する秘密鍵を、その証明者が保有しているか否かを検証する。つまり、検証者は、証明者が公開鍵に対応する秘密鍵を保有しているか否かを検証するエンティティである。このように、公開鍵認証方式のモデルは、証明者と検証者という２つのエンティティ、及び、鍵生成アルゴリズムＧｅｎ、証明者アルゴリズムＰ、検証者アルゴリズムＶという３つのアルゴリズムにより構成される。
【００３３】
なお、以下の説明において、「証明者」「検証者」という表現を用いるが、これらの表現はあくまでもエンティティを意味するものである。従って、鍵生成アルゴリズムＧｅｎ、証明者アルゴリズムＰを実行する主体は、「証明者」のエンティティに対応する情報処理装置である。同様に、検証者アルゴリズムＶを実行する主体は、情報処理装置である。これら情報処理装置のハードウェア構成は、例えば、図１４に示した通りである。つまり、鍵生成アルゴリズムＧｅｎ、証明者アルゴリズムＰ、検証者アルゴリズムＶは、ＲＯＭ９０４、ＲＡＭ９０６、記憶部９２０、リムーバブル記録媒体９２８などに記録されたプログラムに基づいてＣＰＵ９０２などにより実行される。
【００３４】
（鍵生成アルゴリズムＧｅｎ）
鍵生成アルゴリズムＧｅｎは、証明者により利用される。鍵生成アルゴリズムＧｅｎは、証明者に固有の秘密鍵ｓｋと公開鍵ｐｋとの組を生成するアルゴリズムである。鍵生成アルゴリズムＧｅｎにより生成された公開鍵ｐｋは公開される。そして、公開された公開鍵ｐｋは、検証者により利用される。一方、鍵生成アルゴリズムＧｅｎにより生成された秘密鍵ｓｋは、証明者が秘密に管理する。そして、証明者により秘密に管理される秘密鍵ｓｋは、公開鍵ｐｋに対応する秘密鍵ｓｋを証明者が保有していることを検証者に対して証明するために利用される。形式的に、鍵生成アルゴリズムＧｅｎは、セキュリティパラメータ１λ（λは０以上の整数）を入力とし、秘密鍵ｓｋと公開鍵ｐｋを出力するアルゴリズムとして、下記の式（１）のように表現される。
【００３５】
【数１】
2014087969.tif 000003
【００３６】
（証明者アルゴリズムＰ）
証明者アルゴリズムＰは、証明者により利用される。証明者アルゴリズムＰは、公開鍵ｐｋに対応する秘密鍵ｓｋを証明者が保有していることを検証者に対して証明するためのアルゴリズムである。つまり、証明者アルゴリズムＰは、秘密鍵ｓｋと公開鍵ｐｋとを入力とし、対話プロトコルを実行するアルゴリズムである。
【００３７】
（検証者アルゴリズムＶ）
検証者アルゴリズムＶは、検証者により利用される。検証者アルゴリズムＶは、対話プロトコルの中で、公開鍵ｐｋに対応する秘密鍵ｓｋを証明者が保有しているか否かを検証するアルゴリズムである。検証者アルゴリズムＶは、公開鍵ｐｋを入力とし、対話プロトコルの実行結果に応じて０又は１（１ｂｉｔ）を出力するアルゴリズムである。なお、検証者は、検証者アルゴリズムＶが０を出力した場合には証明者が不正なものであると判断し、１を出力した場合には証明者が正当なものであると判断する。形式的に、検証者アルゴリズムＶは、下記の式（２）のように表現される。
【００３８】
【数２】
2014087969.tif 000004
【００３９】
上記の通り、意味のある公開鍵認証を実現するには、対話プロトコルが健全性及び零知識性という２つの条件を満たしている必要がある。しかし、証明者が秘密鍵ｓｋを保有していることを証明するためには、証明者が秘密鍵ｓｋに依存した手続きを実行し、その結果を検証者に通知した上で、その通知内容に基づく検証を検証者に実行させる必要がある。秘密鍵ｓｋに依存した手続きを実行するのは、健全性を担保するために必要である。一方で、秘密鍵ｓｋの情報が一切検証者に漏れないようにする必要がある。そのため、これらの要件を満たすように、上記の鍵生成アルゴリズムＧｅｎ、証明者アルゴリズムＰ、検証者アルゴリズムＶを巧妙に設計する必要がある。
【００４０】
以上、公開鍵認証方式のアルゴリズムについて、その概要を説明した。
【００４１】
［１−２：電子署名方式のアルゴリズム］
次に、図２を参照しながら、電子署名方式のアルゴリズムについて概要を説明する。図２は、電子署名方式のアルゴリズムについて概要を説明するための説明図である。
【００４２】
紙文書とは異なり、ある電子化されたデータに対して押印したり署名を記載したりすることはできない。そのため、電子化されたデータの作成者を証明するためには、紙文書に押印したり署名を記載したりするのと同等の効果が得られる電子的な仕組みを必要とする。この仕組みが電子署名である。電子署名とは、データの作成者しか知らない署名データをデータに関連付けて受領者に提供し、その署名データを受領者側で検証する仕組みのことを言う。
【００４３】
（モデル）
電子署名方式のモデルには、図２に示すように、署名者及び検証者という２つのエンティティが存在する。そして、電子署名方式のモデルは、鍵生成アルゴリズムＧｅｎ、署名生成アルゴリズムＳｉｇ、署名検証アルゴリズムＶｅｒという３つのアルゴリズムにより構成される。
【００４４】
署名者は、鍵生成アルゴリズムＧｅｎを利用して署名者固有の署名鍵ｓｋと検証鍵ｐｋとの組を生成する。また、署名者は、署名生成アルゴリズムＳｉｇを利用して文書Ｍに付与する電子署名σを生成する。つまり、署名者は、文書Ｍに電子署名を付与するエンティティである。一方、検証者は、署名検証アルゴリズムＶｅｒを利用して文書Ｍに付与された電子署名σを検証する。つまり、検証者は、文書Ｍの作成者が署名者であるか否かを確認するために、電子署名σを検証するエンティティである。
【００４５】
なお、以下の説明において、「署名者」「検証者」という表現を用いるが、これらの表現はあくまでもエンティティを意味するものである。従って、鍵生成アルゴリズムＧｅｎ、署名生成アルゴリズムＳｉｇを実行する主体は、「署名者」のエンティティに対応する情報処理装置である。同様に、署名検証アルゴリズムＶｅｒを実行する主体は、情報処理装置である。これら情報処理装置のハードウェア構成は、例えば、図１４に示した通りである。つまり、鍵生成アルゴリズムＧｅｎ、署名生成アルゴリズムＳｉｇ、署名検証アルゴリズムＶｅｒは、ＲＯＭ９０４、ＲＡＭ９０６、記憶部９２０、リムーバブル記録媒体９２８などに記録されたプログラムに基づいてＣＰＵ９０２などにより実行される。
【００４６】
（鍵生成アルゴリズムＧｅｎ）
鍵生成アルゴリズムＧｅｎは、署名者により利用される。鍵生成アルゴリズムＧｅｎは、署名者固有の署名鍵ｓｋと検証鍵ｐｋとの組を生成するアルゴリズムである。鍵生成アルゴリズムＧｅｎにより生成された検証鍵ｐｋは公開される。一方、鍵生成アルゴリズムＧｅｎにより生成された署名鍵ｓｋは、署名者により秘密に管理される。そして、署名鍵ｓｋは、文書Ｍに付与される電子署名σの生成に利用される。例えば、鍵生成アルゴリズムＧｅｎは、セキュリティパラメータ１λ（λは０以上の整数）を入力とし、署名鍵ｓｋ及び公開鍵ｐｋを出力する。この場合、鍵生成アルゴリズムＧｅｎは、形式的に、下記の式（３）のように表現することができる。
【００４７】
【数３】
2014087969.tif 000005
【００４８】
（署名生成アルゴリズムＳｉｇ）
署名生成アルゴリズムＳｉｇは、署名者により利用される。署名生成アルゴリズムＳｉｇは、文書Ｍに付与される電子署名σを生成するアルゴリズムである。署名生成アルゴリズムＳｉｇは、署名鍵ｓｋと文書Ｍとを入力とし、電子署名σを出力するアルゴリズムである。この署名生成アルゴリズムＳｉｇは、形式的に、下記の式（４）のように表現することができる。
【００４９】
【数４】
2014087969.tif 000006
【００５０】
（署名検証アルゴリズムＶｅｒ）
署名検証アルゴリズムＶｅｒは、検証者により利用される。署名検証アルゴリズムＶｅｒは、電子署名σが文書Ｍに対する正当な電子署名であるか否かを検証するアルゴリズムである。署名検証アルゴリズムＶｅｒは、署名者の検証鍵ｐｋ、文書Ｍ、電子署名σを入力とし、０又は１（１ｂｉｔ）を出力するアルゴリズムである。この署名検証アルゴリズムＶｅｒは、形式的に、下記の式（５）のように表現することができる。なお、検証者は、署名検証アルゴリズムＶｅｒが０を出力した場合（公開鍵ｐｋが文書Ｍと電子署名σを拒否する場合）に電子署名σが不当であると判断し、１を出力した場合（公開鍵ｐｋが文書Ｍと電子署名σを受理する場合）に電子署名σが正当であると判断する。
【００５１】
【数５】
2014087969.tif 000007
【００５２】
以上、電子署名方式のアルゴリズムについて、その概要を説明した。
【００５３】
［１−３：ｎパスの公開鍵認証方式］
次に、図３を参照しながら、ｎパスの公開鍵認証方式について説明する。図３は、ｎパスの公開鍵認証方式について説明するための説明図である。
【００５４】
上記の通り、公開鍵認証方式は、対話プロトコルの中で、証明者が公開鍵ｐｋに対応する秘密鍵ｓｋを保有していることを検証者に証明する認証方式である。また、対話プロトコルは、健全性及び零知識性という２つの条件を満たす必要がある。そのため、対話プロトコルの中では、図３に示すように、証明者及び検証者の双方がそれぞれ処理を実行しながらｎ回の情報交換を行う。
【００５５】
ｎパスの公開鍵認証方式の場合、証明者アルゴリズムＰを用いて証明者により処理（工程＃１）が実行され、情報Ｔ１が検証者に送信される。次いで、検証者アルゴリズムＶを用いて検証者により処理（工程＃２）が実行され、情報Ｔ２が証明者に送信される。さらに、ｋ＝３〜ｎについて処理の実行及び情報Ｔｋの送信が順次行われ、最後に処理（工程＃ｎ＋１）が実行される。このように、情報がｎ回送受信される方式のことを「ｎパス」の公開鍵認証方式と呼ぶ。
【００５６】
以上、ｎパスの公開鍵認証方式について説明した。
【００５７】
＜２：３パスの公開鍵認証方式に係るアルゴリズムの構成＞
以下、３パスの公開鍵認証方式に係るアルゴリズムについて説明する。なお、以下の説明において、３パスの公開鍵認証方式のことを「３パス方式」と呼ぶ場合がある。
【００５８】
［２−１：具体的なアルゴリズムの構成例（図４）］
まず、図４を参照しながら、３パス方式に係る具体的なアルゴリズムの構成例について紹介する。図４は、３パス方式に係る具体的なアルゴリズムの構成について説明するための説明図である。ここでは、公開鍵ｐｋの一部として２次多項式の組（ｆ１（ｘ），…，ｆｍ（ｘ））を利用する場合について考える。但し、２次多項式ｆｉ（ｘ）は、下記の式（６）のように表現されるものとする。また、ベクトル（ｘ１，…，ｘｎ）をｘと表記し、２次多項式の組（ｆ１（ｘ），…，ｆｍ（ｘ））を多変数多項式Ｆ（ｘ）と表記することにする。
【００５９】
【数６】
2014087969.tif 000008
【００６０】
また、２次多項式の組（ｆ１（ｘ），…，ｆｍ（ｘ））は、下記の式（７）のように表現することができる。また、Ａ１，…，Ａｍは、ｎ×ｎ行列である。さらに、ｂ１，…，ｂｍはそれぞれｎ×１ベクトルである。
【００６１】
【数７】
2014087969.tif 000009
【００６２】
この表現を用いると、多変数多項式Ｆは、下記の式（８）及び式（９）のように表現することができる。この表現が成り立つことは、下記の式（１０）から容易に確認することができる。
【００６３】
【数８】
2014087969.tif 000010
【００６４】
このようにＦ（ｘ＋ｙ）をｘに依存する第１の部分と、ｙに依存する第２の部分と、ｘ及びｙの両方に依存する第３の部分とに分けたとき、第３の部分に対応する項Ｇ（ｘ，ｙ）は、ｘ及びｙについて双線形になる。以下、項Ｇ（ｘ，ｙ）を双線形項と呼ぶ場合がある。この性質を利用すると、効率的なアルゴリズムを構築することが可能になる。
【００６５】
例えば、ベクトルｔ０∈Ｋｎ、ｅ０∈Ｋｍを用いて、多変数多項式Ｆ（ｘ＋ｒ）のマスクに利用する多変数多項式Ｆ１（ｘ）をＦ１（ｘ）＝Ｇ（ｘ，ｔ０）＋ｅ０と表現する。この場合、多変数多項式Ｆ（ｘ＋ｒ０）とＦ１との和は、下記の式（１１）のように表現される。ここで、ｔ１＝ｒ０＋ｔ０、ｅ１＝Ｆ（ｒ０）＋ｅ０とおけば、多変数多項式Ｆ２（ｘ）＝Ｆ（ｘ＋ｒ０）＋Ｆ１（ｘ）は、ベクトルｔ１∈Ｋｎ、ｅ１∈Ｋｍにより表現することができる。そのため、Ｆ１（ｘ）＝Ｇ（ｘ，ｔ０）＋ｅ０に設定すれば、Ｋｎ上のベクトル及びＫｍ上のベクトルを用いてＦ１及びＦ２を表現できるようになり、通信に必要なデータサイズの少ない効率的なアルゴリズムを実現することが可能になる。
【００６６】
【数９】
2014087969.tif 000011
【００６７】
なお、Ｆ２（或いはＦ１）からｒ０に関する情報が一切漏れることはない。例えば、ｅ１及びｔ１（或いはｅ０及びｔ０）を与えられても、ｅ０及びｔ０（或いはｅ１及びｔ１）を知らない限り、ｒ０の情報を一切知ることはできない。従って、零知識性が担保される。以下、上記の論理に基づいて構築された３パス方式のアルゴリズムについて説明する。ここで説明する３パス方式のアルゴリズムは、以下のような鍵生成アルゴリズムＧｅｎ、証明者アルゴリズムＰ、検証者アルゴリズムＶにより構成される。
【００６８】
（鍵生成アルゴリズムＧｅｎ）
鍵生成アルゴリズムＧｅｎは、環Ｋ上で定義されるｍ本の多変数多項式ｆ１（ｘ１，…，ｘｎ），…，ｆｍ（ｘ１，…，ｘｎ）、及びベクトルｓ＝（ｓ１，…，ｓｎ）∈Ｋｎを生成する。次に、鍵生成アルゴリズムＧｅｎは、ｙ＝（ｙ１，…，ｙｍ）←（ｆ１（ｓ），…，ｆｍ（ｓ））を計算する。そして、鍵生成アルゴリズムＧｅｎは、（ｆ１（ｘ１，…，ｘｎ），…，ｆｍ（ｘ１，…，ｘｎ），ｙ）を公開鍵ｐｋに設定し、ｓを秘密鍵に設定する。
【００６９】
（証明者アルゴリズムＰ、検証者アルゴリズムＶ）
以下、図４を参照しながら、対話プロトコルの中で証明者アルゴリズムＰが実行する処理及び検証者アルゴリズムＶが実行する処理について説明する。この対話プロトコルの中で、証明者は、秘密鍵ｓの情報を検証者に一切漏らさずに、「自身がｙ＝Ｆ（ｓ）を満たすｓを知っていること」を検証者に示す。一方、検証者は、証明者がｙ＝Ｆ（ｓ）を満たすｓを知っているか否かを検証する。なお、公開鍵ｐｋは、検証者に公開されているものとする。また、秘密鍵ｓは、証明者により秘密に管理されているものとする。以下、図４に示したフローチャートに沿って説明を進める。
【００７０】
工程＃１：
図４に示すように、まず、証明者アルゴリズムＰは、ランダムにベクトルｒ０，ｔ０∈Ｋｎ及びｅ０∈Ｋｍを生成する。次いで、証明者アルゴリズムＰは、ｒ１←ｓ−ｒ０を計算する。この計算は、秘密鍵ｓをベクトルｒ０によりマスクする操作に相当する。さらに、証明者アルゴリズムＰは、ｔ１←ｒ０−ｔ０を計算する。次いで、証明者アルゴリズムＰは、ｅ１←Ｆ（ｒ０）−ｅ０を計算する。
【００７１】
工程＃１（続き）：
次いで、証明者アルゴリズムＰは、ｃ０←Ｈ（ｒ１，Ｇ（ｔ０，ｒ１）＋ｅ０）を計算する。次いで、証明者アルゴリズムＰは、ｃ１←Ｈ（ｔ０，ｅ０）を計算する。次いで、証明者アルゴリズムＰは、ｃ２←Ｈ（ｔ１，ｅ１）を計算する。工程＃１で生成されたメッセージ（ｃ０，ｃ１，ｃ２）は、検証者アルゴリズムＶに送られる。
【００７２】
工程＃２：
メッセージ（ｃ０，ｃ１，ｃ２）を受け取った検証者アルゴリズムＶは、３つの検証パターンのうち、どの検証パターンを利用するかを選択する。例えば、検証者アルゴリズムＶは、検証パターンの種類を表す３つの数値｛０，１，２｝の中から１つの数値を選択し、選択した数値を要求Ｃｈに設定する。この要求Ｃｈは証明者アルゴリズムＰに送られる。
【００７３】
工程＃３：
要求Ｃｈを受け取った証明者アルゴリズムＰは、受け取った要求Ｃｈに応じて検証者アルゴリズムＶに送る返答Ｒｓｐを生成する。Ｃｈ＝０の場合、証明者アルゴリズムＰは、返答Ｒｓｐ＝（ｒ０，ｔ１，ｅ１）を生成する。Ｃｈ＝１の場合、証明者アルゴリズムＰは、返答Ｒｓｐ＝（ｒ１，ｔ０，ｅ０）を生成する。Ｃｈ＝２の場合、証明者アルゴリズムＰは、返答Ｒｓｐ＝（ｒ１，ｔ１，ｅ１）を生成する。工程＃３で生成された返答Ｒｓｐは、検証者アルゴリズムＶに送られる。
【００７４】
工程＃４：
返答Ｒｓｐを受け取った検証者アルゴリズムＶは、受け取った返答Ｒｓｐを利用して以下の検証処理を実行する。
【００７５】
Ｃｈ＝０の場合、検証者アルゴリズムＶは、ｃ１＝Ｈ（ｒ０−ｔ１，Ｆ（ｒ０）−ｅ１）の等号が成り立つか否かを検証する。さらに、検証者アルゴリズムＶは、ｃ２＝Ｈ（ｔ１，ｅ１）の等号が成り立つか否かを検証する。検証者アルゴリズムＶは、これらの検証が全て成功した場合に認証成功を示す値１を出力し、検証に失敗があった場合に認証失敗を示す値０を出力する。
【００７６】
Ｃｈ＝１の場合、検証者アルゴリズムＶは、ｃ０＝Ｈ（ｒ１，Ｇ（ｔ０，ｒ１）＋ｅ０）の等号が成り立つか否かを検証する。さらに、検証者アルゴリズムＶは、ｃ１＝Ｈ（ｔ０，ｅ０）の等号が成り立つか否かを検証する。検証者アルゴリズムＶは、これらの検証が全て成功した場合に認証成功を示す値１を出力し、検証に失敗があった場合に認証失敗を示す値０を出力する。
【００７７】
Ｃｈ＝２の場合、検証者アルゴリズムＶは、ｃ０＝Ｈ（ｒ１，ｙ−Ｆ（ｒ１）−Ｇ（ｔ１，ｒ１）−ｅ１）の等号が成り立つか否かを検証する。さらに、検証者アルゴリズムＶは、ｃ２＝Ｈ（ｔ１，ｅ１）の等号が成り立つか否かを検証する。検証者アルゴリズムＶは、これらの検証が全て成功した場合に認証成功を示す値１を出力し、検証に失敗があった場合に認証失敗を示す値０を出力する。
【００７８】
以上、３パス方式に係る効率的なアルゴリズムの構成例について説明した。
【００７９】
［２−２：並列化アルゴリズムの構成例（図５）］
次に、図５を参照しながら、図４に示した３パス方式のアルゴリズムを並列化する方法について説明する。なお、鍵生成アルゴリズムＧｅｎの構成については説明を省略する。
【００８０】
さて、上記の対話プロトコルを適用すれば、偽証が成功する確率を２／３以下に抑制することができる。従って、この対話プロトコルを２回実行すれば、偽証が成功する確率を（２／３）２以下に抑制することができる。さらに、この対話プロトコルをＮ回実行すると、偽証が成功する確率は（２／３）Ｎとなり、Ｎを十分に大きい数（例えば、Ｎ＝１４０）にすれば、偽証が成功する確率は無視できる程度に小さくなる。
【００８１】
対話プロトコルを複数回実行する方法としては、例えば、メッセージ、要求、返答のやり取りを逐次的に複数回繰り返す直列的な方法と、１回分のやり取りで複数回分のメッセージ、要求、返答のやり取りを行う並列的な方法とが考えられる。さらに、直列的な方法と並列的な方法とを組み合わせたハイブリッド型の方法も考えられる。ここでは、図５を参照しながら、３パス方式に係る上記の対話プロトコルを並列的に実行するアルゴリズム（以下、並列化アルゴリズム）について説明する。
【００８２】
工程＃１：
図５に示すように、まず、証明者アルゴリズムＰは、ｉ＝１〜Ｎについて以下の処理（１）〜処理（６）を実行する。
処理（１）：証明者アルゴリズムＰは、ランダムにベクトルｒ０ｉ，ｔ０ｉ∈Ｋｎ及びｅ０ｉ∈Ｋｍを生成する。
処理（２）：証明者アルゴリズムＰは、ｒ１ｉ←ｓ−ｒ０ｉを計算する。この計算は、秘密鍵ｓをベクトルｒ０ｉによりマスクする操作に相当する。さらに、証明者アルゴリズムＰは、ｔ１ｉ←ｒ０ｉ＋ｔ０ｉを計算する。
処理（３）：証明者アルゴリズムＰは、ｅ１ｉ←Ｆ（ｒ０ｉ）−ｅ０ｉを計算する。
処理（４）：証明者アルゴリズムＰは、ｃ０ｉ←Ｈ（ｒ１ｉ，Ｇ（ｒ１ｉ，ｔ０ｉ）＋ｅ０ｉ）を計算する。
処理（５）：証明者アルゴリズムＰは、ｃ１ｉ←Ｈ（ｔ０ｉ，ｅ０ｉ）を計算する。
処理（６）：証明者アルゴリズムＰは、ｃ２ｉ←Ｈ（ｔ１ｉ，ｅ１ｉ）を計算する。
【００８３】
工程＃１（続き）
ｉ＝１〜Ｎについて上記の処理（１）〜処理（６）を実行した後、証明者アルゴリズムＰは、Ｃｍｔ←Ｈ（ｃ０１，ｃ１１，ｃ２１，…，ｃ０Ｎ，ｃ１Ｎ，ｃ２Ｎ）を計算する。工程＃１で生成されたハッシュ値Ｃｍｔは、検証者アルゴリズムＶに送られる。このように、メッセージ（ｃ０１，ｃ１１，ｃ２１，…，ｃ０Ｎ，ｃ１Ｎ，ｃ２Ｎ）をハッシュ値に変換してから検証者アルゴリズムＶに送ることで、通信量を削減することが可能になる。なお、証明者アルゴリズムＰは、（ｃ０１，ｃ１１，ｃ２１，…，ｃ０Ｎ，ｃ１Ｎ，ｃ２Ｎ）を検証者アルゴリズムＶに送っても良い。
【００８４】
工程＃２：
ハッシュ値Ｃｍｔを受け取った検証者アルゴリズムＶは、ｉ＝１〜Ｎのそれぞれについて、３つの検証パターンのうち、どの検証パターンを利用するかを選択する。例えば、検証者アルゴリズムＶは、ｉ＝１〜Ｎのそれぞれについて、検証パターンの種類を表す３つの数値｛０，１，２｝の中から１つの数値を選択し、選択した数値を要求Ｃｈｉに設定する。要求Ｃｈ１，…，ＣｈＮは、証明者アルゴリズムＰに送られる。
【００８５】
工程＃３：
要求Ｃｈ１，…，ＣｈＮを受け取った証明者アルゴリズムＰは、受け取った要求Ｃｈ１，…，ＣｈＮのそれぞれ応じて検証者アルゴリズムＶに送る返答Ｒｓｐ１，…，ＲｓｐＮを生成する。Ｃｈｉ＝０の場合、証明者アルゴリズムＰは、Ｒｓｐｉ＝（ｒ０ｉ，ｔ１ｉ，ｅ１ｉ，ｃ０ｉ）を生成する。Ｃｈｉ＝１の場合、証明者アルゴリズムＰは、Ｒｓｐｉ＝（ｒ１ｉ，ｔ０ｉ，ｅ０ｉ，ｃ２ｉ）を生成する。Ｃｈｉ＝２の場合、証明者アルゴリズムＰは、Ｒｓｐｉ＝（ｒ１ｉ，ｔ１ｉ，ｅ１ｉ，ｃ１ｉ）を生成する。
【００８６】
工程＃３で生成された返答Ｒｓｐ１，…，ＲｓｐＮは、検証者アルゴリズムＶに送られる。
【００８７】
工程＃４：
返答Ｒｓｐ１，…，ＲｓｐＮを受け取った検証者アルゴリズムＶは、受け取った返答Ｒｓｐ１，…，ＲｓｐＮを利用して以下の処理（１）〜処理（３）をｉ＝１〜Ｎについて実行する。但し、検証者アルゴリズムＶは、Ｃｈｉ＝０の場合に処理（１）を実行し、Ｃｈｉ＝１の場合に処理（２）を実行し、Ｃｈｉ＝２の場合に処理（３）を実行する。
【００８８】
処理（１）：Ｃｈｉ＝０の場合、検証者アルゴリズムＶは、Ｒｓｐｉから（ｒ０ｉ，ｔ１ｉ，ｅ１ｉ，ｃ０ｉ）を取り出す。次いで、検証者アルゴリズムＶは、ｃ１ｉ＝Ｈ（ｒ０ｉ−ｔ１ｉ，Ｆ（ｒ０ｉ）−ｅ１ｉ）を計算する。さらに、検証者アルゴリズムＶは、ｃ２ｉ＝Ｈ（ｔ１ｉ，ｅ１ｉ）を計算する。そして、検証者アルゴリズムＶは、（ｃ０ｉ，ｃ１ｉ，ｃ２ｉ）を保持する。
【００８９】
処理（２）：Ｃｈｉ＝１の場合、検証者アルゴリズムＶは、Ｒｓｐｉから（ｒ１ｉ，ｔ０ｉ，ｅ０ｉ，ｃ２ｉ）を取り出す。次いで、検証者アルゴリズムＶは、ｃ０ｉ＝Ｈ（ｒ１ｉ，Ｇ（ｔ０ｉ，ｒ１ｉ）＋ｅ０ｉ）を計算する。さらに、検証者アルゴリズムＶは、ｃ１ｉ＝Ｈ（ｔ０ｉ，ｅ０ｉ）を計算する。そして、検証者アルゴリズムＶは、（ｃ０ｉ，ｃ１ｉ，ｃ２ｉ）を保持する。
【００９０】
処理（３）：Ｃｈｉ＝２の場合、検証者アルゴリズムＶは、Ｒｓｐｉから（ｒ１ｉ，ｔ１ｉ，ｅ１ｉ，ｃ１ｉ）を取り出す。次いで、検証者アルゴリズムＶは、ｃ０ｉ＝Ｈ（ｒ１ｉ，ｙ−Ｆ（ｒ１ｉ）−Ｇ（ｔ１ｉ，ｒ１ｉ）−ｅ１ｉ）を計算する。さらに、検証者アルゴリズムＶは、ｃ２ｉ＝Ｈ（ｔ１ｉ，ｅ１ｉ）を計算する。そして、検証者アルゴリズムＶは、（ｃ０ｉ，ｃ１ｉ，ｃ２ｉ）を保持する。
【００９１】
処理（１）〜処理（３）をｉ＝１〜Ｎについて実行した後、検証者アルゴリズムＶは、Ｃｍｔ＝Ｈ（ｃ０１，ｃ１１，ｃ２１，…，ｃ０Ｎ，ｃ１Ｎ，ｃ２Ｎ）の等号が成り立つか否かを検証する。検証者アルゴリズムＶは、この検証が成功した場合に認証成功を示す値１を出力し、検証に失敗した場合に認証失敗を示す値０を出力する。
【００９２】
以上、３パス方式に係る効率的な並列化アルゴリズムの構成例について説明した。
【００９３】
＜３：電子署名方式への変形＞
次に、上記の公開鍵認証方式を電子署名方式へと変形する方法を紹介する。
【００９４】
公開鍵認証方式のモデルにおける証明者を電子署名方式における署名者に対応させると、証明者のみが検証者を納得させられるという点において、電子署名方式のモデルと近似していることが容易に理解されよう。こうした考えに基づき、上述した公開鍵認証方式を電子署名方式へと変形する方法について説明する。
【００９５】
［３−１：３パスの公開鍵認証方式から電子署名方式への変形（図６）］
まず、３パスの公開鍵認証方式から電子署名方式への変形について説明する。図６に示すように、３パスの公開鍵認証方式から電子署名方式へ変形したアルゴリズムは、図５で説明した３パス方式のアルゴリズムを並列化したアルゴリズムの一部と同様に構成されている。図５の工程＃１〜工程＃４で表現される公開鍵認証方式のアルゴリズムは、図６に示すような署名生成アルゴリズムＳｉｇ及び署名検証アルゴリズムＶｅｒに変形される。
【００９６】
工程＃１：
図６に示すように、工程＃１は図５の工程＃１と同様である。
【００９７】
工程＃２：
次の工程＃２では、図５で検証者アルゴリズムＶに送ったＣｍｔ←Ｈ（ｃ０１，ｃ１１，ｃ２１，…，ｃ０Ｎ，ｃ１Ｎ，ｃ２Ｎ）を署名検証アルゴリズムＶｅｒには送らずに、署名生成アルゴリズムＳｉｇは、Ｃｍｔと署名を付けたメッセージＭのハッシュ値Ｈ（Ｍ，ｃ０１，ｃ１１，ｃ２１，…，ｃ０Ｎ，ｃ１Ｎ，ｃ２Ｎ）を計算して（Ｃｈ１，・・・，ＣｈＮ）とする。すなわち、署名生成アルゴリズムＳｉｇは、（Ｃｈ１，・・・，ＣｈＮ）←Ｈ（Ｍ，ｃ０１，ｃ１１，ｃ２１，…，ｃ０Ｎ，ｃ１Ｎ，ｃ２Ｎ）を計算する。
【００９８】
工程＃３：
図６に示すように、工程＃３は図５の工程＃３と同様である。署名生成アルゴリズムＳｉｇは、Ｃｈ１，…，ＣｈＮのそれぞれ応じて署名検証アルゴリズムＶｅｒに送るσｉを生成する。Ｃｈｉ＝０の場合、署名生成アルゴリズムＳｉｇは、σｉ＝（ｒ０ｉ，ｔ１ｉ，ｅ１ｉ，ｃ０ｉ）を生成する。Ｃｈｉ＝１の場合、署名生成アルゴリズムＳｉｇは、σｉ＝（ｒ１ｉ，ｔ０ｉ，ｅ０ｉ，ｃ２ｉ）を生成する。Ｃｈｉ＝２の場合、署名生成アルゴリズムＳｉｇは、σｉ＝（ｒ１ｉ，ｔ１ｉ，ｅ１ｉ，ｃ１ｉ）を生成する。
【００９９】
工程＃３で生成されたＣｈ１，…，ＣｈＮ及びσ１，…，σＮは、署名検証アルゴリズムＶｅｒに送られる。また、同時に、署名を付けたメッセージＭも署名検証アルゴリズムＶｅｒに送られる。
【０１００】
工程＃４：
図６に示すように、工程＃４は基本的に図５の工程＃４と同様である。返答σ１，…，σＮを受け取った署名検証アルゴリズムＶｅｒは、受け取った返答σ１，…，σＮを利用して以下の処理（１）〜処理（３）をｉ＝１〜Ｎについて実行する。但し、署名検証アルゴリズムＶｅｒは、Ｃｈｉ＝０の場合に処理（１）を実行し、Ｃｈｉ＝１の場合に処理（２）を実行し、Ｃｈｉ＝２の場合に処理（３）を実行する。
【０１０１】
処理（１）：Ｃｈｉ＝０の場合、署名検証アルゴリズムＶｅｒは、σｉから（ｒ０ｉ，ｔ１ｉ，ｅ１ｉ，ｃ０ｉ）を取り出す。次いで、署名検証アルゴリズムＶｅｒは、ｃ１ｉ＝Ｈ（ｒ０ｉ−ｔ１ｉ，Ｆ（ｒ０ｉ）−ｅ１ｉ）を計算する。さらに、署名検証アルゴリズムＶｅｒは、ｃ２ｉ＝Ｈ（ｔ１ｉ，ｅ１ｉ）を計算する。そして、検証者アルゴリズムＶは、（ｃ０ｉ，ｃ１ｉ，ｃ２ｉ）を保持する。
【０１０２】
処理（２）：Ｃｈｉ＝１の場合、署名検証アルゴリズムＶｅｒは、σｉから（ｒ１ｉ，ｔ０ｉ，ｅ０ｉ，ｃ２ｉ）を取り出す。次いで、署名検証アルゴリズムＶｅｒは、ｃ０ｉ＝Ｈ（ｒ１ｉ，Ｇ（ｔ０ｉ，ｒ１ｉ）＋ｅ０ｉ）を計算する。さらに、署名検証アルゴリズムＶｅｒは、ｃ１ｉ＝Ｈ（ｔ０ｉ，ｅ０ｉ）を計算する。そして、署名検証アルゴリズムＶｅｒは、（ｃ０ｉ，ｃ１ｉ，ｃ２ｉ）を保持する。
【０１０３】
処理（３）：Ｃｈｉ＝２の場合、署名検証アルゴリズムＶｅｒは、σｉから（ｒ１ｉ，ｔ１ｉ，ｅ１ｉ，ｃ１ｉ）を取り出す。次いで、署名検証アルゴリズムＶｅｒは、ｃ０ｉ＝Ｈ（ｒ１ｉ，ｙ−Ｆ（ｒ１ｉ）−Ｇ（ｔ１ｉ，ｒ１ｉ）−ｅ１ｉ）を計算する。さらに、署名検証アルゴリズムＶｅｒは、ｃ２ｉ＝Ｈ（ｔ１ｉ，ｅ１ｉ）を計算する。そして、署名検証アルゴリズムＶｅｒは、（ｃ０ｉ，ｃ１ｉ，ｃ２ｉ）を保持する。
【０１０４】
処理（１）〜処理（３）をｉ＝１〜Ｎについて実行した後、署名検証アルゴリズムＶｅｒは、（Ｃｈ１，・・・，ＣｈＮ）＝Ｈ（Ｍ，ｃ０１，ｃ１１，ｃ２１，…，ｃ０Ｎ，ｃ１Ｎ，ｃ２Ｎ）の等号が成り立つか否かを検証する。署名検証アルゴリズムＶｅｒは、この検証が成功した場合に認証成功を示す値１を出力し、検証に失敗した場合に認証失敗を示す値０を出力する。
【０１０５】
以上説明したように、公開鍵認証方式のモデルにおける証明者を電子署名方式における署名者に対応させることで、公開鍵認証方式のアルゴリズムを電子署名方式のアルゴリズムへと変形することが可能になる。
【０１０６】
＜４．具体的な実施形態＞
［４−１：本開示の一実施形態に係るシステムの概要］
本実施形態では、上述したような電子署名方式で利用する公開鍵を名刺（ビジネスカード）に記載し、名刺を渡した相手に公開鍵を通知する。公開鍵を名刺に記載する場合、署名の検証者が誤りなく公開鍵を認識することが必要となる。本実施形態では、文字情報として公開鍵を名刺に印刷することで、公開鍵の読み取りのために専用デバイスを使用する必要がなく、署名検証者が誤りなく公開鍵を認識可能とする。なお、本実施形態では、公開鍵を名刺に記載した場合を例示するが、公開鍵はクレジットカードや社員証等の他の携帯可能なカード等に記載することも勿論可能である。
【０１０７】
ＭＱ署名方式の場合、公開鍵の長さを最短で８０ビット（ｂｉｔ）にすることができる。このため、例えば公開鍵をｂａｓｅ６４（６ｂｉｔの情報を１文字で表現する手法)でエンコード（符号化）した場合、最短で１４文字の文字列からなる公開鍵を文字情報として名刺に直接印刷することができる。これにより、付加的なデバイスを使用することなく公開鍵を人間が読み取ることができ、且つ公開鍵の認識誤りを確実に抑えることができる。
【０１０８】
図７（Ａ）は、公開鍵１０２を１４文字の文字情報として名刺１００に記載した例を示す模式図である。このように、本実施形態によれば、通常の名刺１００に公開鍵１０２を印刷して示すことが可能となり、名刺１００を渡すのと同時に公開鍵１０２を通知することが可能となる。
【０１０９】
一方、図７（Ｂ）に示すように、公開鍵の情報をＱＲコード１１０でコード化して記録する手法の場合、公開鍵の情報を受け取った側では、公開鍵の情報を知るためにＱＲコードリーダ等の付加的なデバイスが必要となる。
【０１１０】
従って、本実施形態によれば、文字情報で表現された公開鍵１０２を目で直接認識して、他のデバイスに入力したり、別デバイスに表示されている公開鍵と比較することが可能である。
【０１１１】
［４−２：公開鍵の名刺への記載例］
公開鍵１０２の名刺１００への記載例について具体的に説明する。上述したように、ｂａｓｅ６４等の手法で符号化した場合、ＭＱ署名方式の公開鍵長さは８０ビット程度にすることができる。図７（Ａ）に示すように、１４文字を連続して表示することもできるが、人間の記憶の種類に応じて１４文字を複数の部分に区切って表示することが望ましい。
【０１１２】
一般的に人間の記憶の態様は、感覚記憶、短期記憶、長期記憶の３つに分類される。感覚記憶は映像、文字や音などを最大１〜２秒ほど記憶する記憶であり、短期記憶は短期間(約２０秒ほど)保持される記憶である。また、長期記憶は、忘却しない限り、生涯保持される記憶である。このうち、感覚記憶の容量は４とされており、「感覚される単位」で４つ記憶できる。文字の場合、４文字までは一瞬で見て感覚的に記憶できるが、５文字以上になると一度には記憶できず「視線の移動」が行われ、データは短期記憶の中で編集されることになる。また、短期記憶の容量は７±２とされており、短期記憶では、意味的にまとまって記憶できる単位（以下、チャンクと称する）を７つ記憶することができる。従って、公開鍵１０２を複数に区切って名刺１００に記載する場合、１つのチャンクを４文字以下として、チャンクの総数を７以下にすることが望ましい。
【０１１３】
この観点から、図８は、８０ビットの公開鍵をｂａｓｅ６４で１４文字にエンコードし、４文字−３文字−３文字−４文字の４チャンクに編集して、公開鍵１０２(m6UL-HDR-PpG-c9m1)を名刺１００に印刷した場合を示している。また、図９は、８０ビットの公開鍵をｂａｓｅ６４で１４文字にエンコードし、３文字−３文字−２文字−３文字−３文字の５チャンクに編集して、公開鍵１０２(m6U-LHD-RP-pGc-9m1)を名刺１００に印刷した場合を示している。このように、８０ビットからなる公開鍵１０２は、エンコードにより１４文字の英数字で表すことができる。従って、図８及び図９に示すように、公開鍵１０２の表示範囲は名刺１００の領域に対して十分に小さく、電話番号、住所、メールアドレス等と同様に名刺１００の一部に公開鍵１０２を記載することが可能である。また、１つのチャンクを４文字以下とし、チャンクの総数を７以下にすることで、ユーザがより記憶し易い表示にすることができる。
【０１１４】
一方、図１０は、８０ｂｉｔの公開鍵をｂａｓｅ６４で１４文字にエンコードし、５文字−４文字−５文字の３チャンクに編集して公開鍵１０２(m6ULH-DRPp-Gc9m1)を印刷した場合を示している。この場合、５文字のチャンクが存在するため、５文字のチャンクを認識するためにチャンク内で視線移動が必要となり、図８又は図９の表示と比較すると公開鍵１０２を記憶し難くなる。また、図１１は、１６０ｂｉｔの公開鍵をｂａｓｅ６４で２７文字にエンコードし、４文字−４文字−４文字−４文字−４文字−４文字−３文字の７チャンクに編集して公開鍵１０２(Oyxs-ENDn-gHLR-TgLM-TFh4-FNDx-Dzo)を印刷した場合を示している。この場合、７つのチャンクのうち、現在見ているチャンクがどれかを認識するために視線移動が必要となり、図８又は図９の表示と比較すると記憶がし難くなる。また、図１２は、１６０ｂｉｔの公開鍵をｂａｓｅ６４で２７文字にエンコードし、５文字−５文字−４文字−４文字−４文字−５文字の６チャンクに編集して公開鍵１０２(OyxsE-NDngH-LRTg-LMTF-h4FN-DxDzo)を印刷した場合を示している。この場合も、６つのチャンクのうちで、現在見ているチャンクがどれかを認識するために視線移動が必要となり、且つ、５文字のチャンク内でも文字を認識するために視線移動が必要となる。従って、公開鍵１０２の記憶をより容易にするため、１つのチャンクを４文字以下とし、チャンクの総数を７以下にすることが望ましい。
【０１１５】
本実施形態では、チャンクの総数は７以下とし、特に好適には４（又は５）とする。チャンクの総数を４（又は５）とし、１つのチャンクを４文字とすると、文字で表現できる公開鍵のサイズは９６ビット（又は１２０ビット）となる。後述するが、このサイズの公開鍵を実現できるのはＭＱ署名方式のみであり、ＲＳＡ，ＥＣＤＳＡなどの他の方式では最低でも１６０ビットの公開鍵サイズが必要である。従って、本実施形態によれば、ＭＱ署名方式を用いることで、文字情報として公開鍵１０２を名刺１００に印刷することができ、且つ、４文字からなるチャンクの総数を４（又は５）とすることで、公開鍵１０２の記憶も容易となる。署名検証者が名刺１００の公開鍵１０２を書き移したり、他の公開鍵と比較する際に、４文字ずつに区切ることにより、そのチャンクを視線移動なしで認識できる。また、チャンクの総数を４（又は５）とすることにより、現在書き移している、あるいは比較しているチャンクがどのチャンクであるかを、視線移動なしで認識できる(若しくは短期記憶の範囲内で容易に記憶可能となる)。従って、名刺１００に記載された公開鍵１０２を書き写したり、他の装置へ入力することを容易に行うことが可能となる。
【０１１６】
図１３は、公開鍵１０２をｂａｓｅ６４(または英数３６文字)で１６文字にエンコードし、４文字×４文字の１６文字平方に編集して名刺に記載した例を示している。このように、公開鍵１０２は、通常の文字列として記載する他に、所定の平面領域に記載することもできる。
【０１１７】
図１４は、公開鍵１０２をｂａｓｅ６４(または英数３６文字)でエンコードし、前半部分ＰＫ(first)と後半部分ＰＫ(latter)の２つに分割して表示した場合を示している。このように、公開鍵１０２は複数に分割して名刺１００に記載することもできる。分割して表示することにより、電話番号と変わらないレベルまで視認が容易となる。
【０１１８】
名刺１００は、ビジネスシーン等で頻繁に交換されるものであり、そのデザインは非常に重要である。ここで、通常の名刺のサイズ(普通型４号)は５５ｍｍ×９１ｍｍであり、スペースが限られている。余白を５ｍｍずつとすると、印刷に使える実際の範囲は４５ｍｍ×８１ｍｍ程度である。従って、名刺１００に記載する公開鍵１０２は、そのサイズ（文字数）をより短くしておくと、名刺１００上での配置に制約が生じない。公開鍵１０２を８０ｂｉｔで構成した場合、上述のようにｂａｓｅ６４で符号化すると１４文字となり、図８に示したように４文字を１チャンクとして区切り、間にハイフン（−）を挿入しても１７文字である。従って、限られたサイズの名刺１００であっても、デザイン上の制約を受けることなく公開鍵１０２を表示することができる。このため、ＭＱ署名方式を用いることで、名刺１００のデザインを格段に洗練されたものとすることが可能である。
【０１１９】
一般的に、電子署名技術としては、最低でも８０ｂｉｔ以上の鍵強度が必要とされている。ＲＳＡ方式の場合、８０ｂｉｔの鍵強度を持つには、最低でも１０２４ｂｉｔの鍵サイズが必要となり、これをｂａｓｅ６４で符号化すると１７１文字となる。また、ＥＣＤＳＡ方式の場合、８０ｂｉｔの鍵強度を持つには、最低でも１６０ｂｉｔの鍵サイズが必要となり、これをｂａｓｅ６４で符号化すると２７文字となる。このように、ＲＳＡなどの他の認証方式では、公開鍵のサイズは最低でも１６０ビットであるため、ｂａｓｅ６４で符号化すると２７文字となり、５文字を１チャンクとして区切り、間にハイフン（−）を挿入すると３２文字となる。従って、図１１及び図１２に示したように、名刺１００における公開鍵１０２の印刷範囲が大きくなり、デザイン的にも図８及び図９の名刺１００と比べて見劣りしてしまう。
【０１２０】
一方、ＭＱ署名方式では、８０ｂｉｔの鍵強度を最小で８０ｂｉｔの公開鍵で達成することが可能である。従って、ＭＱ署名方式を用いることで、公開鍵１０２のサイズを最小限に抑えることができ、ｂａｓｅ６４で符号化した場合に１４文字で公開鍵１０２を表現することが可能である。
【０１２１】
［４−３：本実施形態に係る名刺が使用される状況］
次に、本実施形態に係る名刺１００が利用される状況について説明する。公開鍵は一見ランダムに見える情報であり、それ自身だけでは「誰の公開鍵であるか」を確認することはできない。この「誰の公開鍵であるか」を保証するインフラがＰＫＩ(公開鍵基盤)であるが、これを構築または利用するにはコストがかかるのが現状である。本実施形態に係る公開鍵１０２が記載された名刺１００を利用することで、ＰＫＩなどの第三者に「誰の公開鍵であるか」を保証してもらうのではなく、名刺１００の持ち主からその名刺１００を受け取ることにより「誰の公開鍵であるか」を直接的に確認することができる。つまり、本実施形態では、名刺１００の持ち主の公開鍵であることを、名刺１００の受け渡しにより直接的に確認することができる。特に本実施形態では、ＱＲコードリーダなどの付加的なデバイスを使用することなく、直接的に人が名刺に記載１００された公開鍵１０２を文字情報として認識できる。
【０１２２】
このように、名刺１００に記載された公開鍵１０２は、名刺１００に記載された人物と一対一で対応する。このため、本実施形態に係る名刺１００は、ＭＱ認証処理、ＭＱ署名の検証処理を行うデバイスが保持する公開鍵と、名刺１００に記載された公開鍵１０２の情報が一致しているか否かを確認するために用いることができる。なお、以下の説明ではＭＱ電子署名の検証を例に挙げて説明するが、ＭＱ認証についても同様に適用することができる。図１５は、電子署名の検証処理を行う検証装置２００が保持する公開鍵と、名刺１００に記載された公開鍵１０２の情報が一致しているか否かを確認する処理を示すフローチャートである。先ず、ステップＳ１０では、検証装置２００内に鍵ＩＤに紐付けられて登録された公開鍵を、検証装置２００の表示部に表示する。ここで、鍵ＩＤは、検証装置２００が複数の公開鍵を登録している場合に、１の公開鍵を指定するために検証装置２００内で付けられた名称である。鍵ＩＤとしては、公開鍵に対応した数字(鍵番号１，２,…)、公開鍵の所有者の氏名(鈴木太郎)、公開鍵の所有者のメールアドレス等を用いることができる。なお、検証装置２００が１つの公開鍵のみを登録している場合、すなわち、検証装置２００が特定の１つの公開鍵による署名検証のみを行う装置の場合は、鍵ＩＤを設定しなくても良い。
【０１２３】
ここでは、鍵ＩＤとして公開鍵の所有者の氏名(鈴木太郎)を設定している場合について説明する。この場合、ステップＳ１０では、所有者の氏名(鈴木太郎)と、これに対応する公開鍵を検証装置２００に表示する。
【０１２４】
次のステップＳ１２では、名刺１００に記載された公開鍵１０２をユーザが目視で読み取り、検証装置２００に表示された公開鍵と名刺１００に記載された公開鍵１０２が一致するか否かを目視で確認する。そして、検証装置２００に表示された公開鍵と名刺１００に記載された公開鍵１０２が一致する場合はステップＳ１４へ進み、一致しない場合はステップＳ１６へ進む。
【０１２５】
ステップＳ１４へ進んだ場合は、検証装置２００に表示された公開鍵と名刺１００に記載された公開鍵１０２が一致するため、検証装置２００が保持する公開鍵の所有者は、公開鍵１０２が記載された名刺１００の持ち主であると判定できる。
【０１２６】
一方、ステップＳ１６へ進んだ場合は、検証装置２００に表示された公開鍵と名刺１００に記載された公開鍵１０２が一致しないため、検証装置２００が保持する公開鍵の所有者は、公開鍵１０２が記載された名刺１００の持ち主ではないと判定できる。
【０１２７】
このように、名刺１００に記載された公開鍵１０２と、検証装置２００が保持する公開鍵をユーザが目視で比較することにより、検証装置２００が保持する公開鍵の所有者が名刺１００の持ち主であるか否かを容易に判断することができる。
【０１２８】
同様の手法により、例えばソーシャルネットワークサービス等において、任意のユーザが公開鍵をネットワーク上で公開している場合は、ネットワーク上で公開された公開鍵と名刺１００に記載された公開鍵１０２を比較することで、ネットワーク上で公開鍵を公開しているユーザが名刺１００の持ち主であるか否かを容易に判断できる。この場合、ソーシャルネットワークサービスで任意のユーザが公開した公開鍵と名刺１００に記載された公開鍵１０２が一致すれば、そのユーザが名刺１００の持ち主であると判断できる。
【０１２９】
また、本実施形態に係る名刺１００は、名刺１００に記載された公開鍵１０２の情報を、電子署名の検証処理を行う検証装置２００に入力する際に用いることができる。上述したＭＱプロトコルによる電子署名の検証処理を行う場合、検証を行う検証装置２００側で予め公開鍵の情報を取得しておく。この際、名刺１００に記載された公開鍵１０２を検証装置２００にそのまま入力することで、検証装置２００が公開鍵１０２の情報を取得することができる。
【０１３０】
図１６は、公開鍵１０２を検証装置２００に入力する処理を示すフローチャートである。先ず、ステップＳ２０では、ユーザが公開鍵の入力処理を開始する。次のステップＳ２２では、ユーザが名刺１００に記載された公開鍵１０２を目視し、公開鍵１０２の文字をそのまま検証装置２００へ入力する。次のステップＳ２４では、公開鍵１０２と名刺１００に記載された氏名、電話番号、メールアドレス等の情報とを紐付けする。この場合、紐付けた氏名等の情報は、図１５で説明した鍵ＩＤとして使用できる。検証装置２００は、入力された公開鍵１０２をデコードして、電子署名の検証処理に用いる。なお、ステップＳ２４の処理は、特に必要がなければ行わなくても良い。
【０１３１】
以上のように、本実施形態に係る名刺１００によれば、公開鍵１０２を文字列で記載することができるため、名刺１００の持ち主から名刺１００を受け取ったユーザは、文字列の公開鍵１０２を目視で認識することができる。従って、名刺１００を受け取ったユーザは、電子署名の検証を行う検証装置２００が既に保持している公開鍵と名刺１００に記載された公開鍵１０２が一致しているか否かを目視で容易に判定することができる。また、名刺１００を受け取ったユーザは、名刺１００に記載された公開鍵１０２を目視で読み取って検証装置２００へ入力することがでる。検証装置２００は、入力された公開鍵１０２をデコードして、名刺１００の持ち主から電子署名の検証要求があった場合に検証処理に用いることができる。
【０１３２】
［４−４：本実施形態に係るシステムの構成例］
次に、本実施形態に係るシステムの構成例について説明する。図１７は、本実施形態に係る、検証装置２００とクライアント端末３００からなるシステムの構成を示す模式図である。最初に、本実施形態に係る検証装置２００の構成について説明する。検証装置２００は、通信部２０２、検証処理部２０４、公開鍵保持部２０６、公開鍵復号化部２０８、公開鍵符号化部２０９、表示部２１０、操作入力部２１２を有して構成されている。検証装置２００は、電子署名の検証要求を行うクライアント端末３００とネットワーク４００を介して接続されている。
【０１３３】
通信部２０２は、検証要求を行うクライアント端末３００と通信を行い、クライアント端末３００から検証要求を受信する。ここで、クライアント端末３００は、名刺１００の持ち主が保有する端末であっても良い。
【０１３４】
検証処理部２０４は、クライアント端末３００から電子署名σの検証要求があった場合に、公開鍵を用いて電子署名σを検証する。具体的には、検証処理部２０４は、図６の工程＃４を含む処理を行う。
【０１３５】
公開鍵保管部２０６は、公開鍵を保管（記憶）する。操作入力部２１２は、ユーザが操作することによって公開鍵の情報を入力する入力部である。上述したように、ユーザは、名刺１００の持ち主から受け取った名刺１００に記載された公開鍵１０２の文字列を操作入力部２１２から入力することができる。公開鍵復号化部２０８は、操作入力部２１２に入力された公開鍵１０２を復号（デコード）する。操作入力部２１２に入力される公開鍵１０２の情報は公開鍵がエンコードされた文字情報であるため、公開鍵復号化部２０８は、公開鍵１０２の文字情報を復号することによって、公開鍵のバイナリデータを生成する。公開鍵保持部２０６は、公開鍵の情報を記憶する。公開鍵保持部２０６は、文字情報の公開鍵１０２が復号されたバイナリデータを記憶するが、復号される前の公開鍵１０２の文字情報を記憶することもできる。公開鍵保管部２０６が複数の公開鍵を記憶する場合、公開鍵保管部２０６は公開鍵と鍵ＩＤを紐付けして記憶する。
【０１３６】
表示部２１０は、公開鍵保管部２０６に記憶されている公開鍵の情報を表示する。公開鍵符号化部２０６は、公開鍵保管部２０６に保管された公開鍵が符号化されていないデータの場合は、ｂａｓｅ６４を用いて文字情報に符号化（エンコード）する。表示部２１０は、符号化された公開鍵の文字情報を表示する。これにより、ユーザは、名刺１００に記載された公開鍵１０２と、公開鍵保持部２０６が記憶している公開鍵とが一致するか否かを目視で判断することができる。
【０１３７】
次に、クライアント端末３００の構成について説明する。クライアント端末３００は、通信部３０２、鍵生成部３０４、鍵保管部３０６、署名生成部３０８、操作入力部３１０を有して構成されている。鍵生成部３０４は、公開鍵と暗号鍵のペアを生成する。具体的には、鍵生成部３０４は、図６の工程＃１を含む処理を行う。鍵保管部３０６は、鍵生成部３０４が生成した公開鍵と秘密鍵を保管する記憶部である。なお、公開鍵と暗号鍵のペアを外部の装置で生成して鍵保管部３０６に保管しても良い。電子署名生成部３０８は、図６の工程＃２，＃３の処理を行い、電子署名σを生成する。通信部３０２は、電子署名σをネットワーク４００を介して検証装置２００へ送信する。操作入力部３１０は、ユーザが操作を行うことで情報が入力されるタッチセンサ、キーボード等の構成要素である。
【０１３８】
通信部３０２は、クライアント端末２００のユーザ（ここでは、名刺１００の持ち主とする）が電子署名σの検証要求を操作入力部３１０へ入力すると、電子署名σを検証装置２００へ送信する。
【０１３９】
なお、図１７に示す検証装置２００、クライアント端末３００の各構成要素は、ハードウェア（回路）、またはＣＰＵなどの中央演算処理装置とこれを機能させるためのプログラム（ソフトウェア）から構成されることができる。この場合に、そのプログラムは、検証装置２００またはクライアント端末３００が備えるメモリ、または外部から接続されるメモリ等の記憶媒体に格納されることができる。
【０１４０】
［４−５：名刺を作成する処理］
次に、名刺１００を作成するための処理について説明する。図１８は、名刺１００を作成する処理を示すフローチャートであって、パーソナルコンピュータ等のコンピュータで行われる処理を示している。コンピュータは、図１７の処理でユーザが設定した情報をプリンタに送信し、プリンタが名刺を印刷する。また、図１８の処理を実行するためのプログラムは、コンピュータが備えるメモリ等の記憶媒体に格納される。コンピュータは、ＣＰＵなどの中央演算処理装置とこれを機能させるための当該プログラムによって図１８の処理を実行する。
【０１４１】
先ず、ステップＳ３０では、名刺１００を作成するユーザ（ここでは、上述した名刺１００の持ち主とする）が名刺１００に記載する氏名、会社の名称、会社の住所、電話番号、ＦＡＸ番号、メールアドレス、等の基本事項をコンピュータに入力する。次のステップＳ３２では、ユーザの入力に基づいて、ステップＳ３０で入力した基本事項の名刺１００上での位置、大きさを設定する。
【０１４２】
次のステップＳ３４では、ユーザが公開鍵１０２を文字情報として入力する。次のステップＳ３６では、ユーザの入力に基づいて、ステップＳ３４で入力された公開鍵１０２の名刺１００上での位置、大きさを設定する。また、図１３のように公開鍵１０２を４文字×４文字の１６文字平方などに編集して名刺１００に記載する場合、図１４のように公開鍵１０２を分割して名刺１００に記載する場合は、ステップＳ３６で設定を行う。次のステップＳ３８では、ユーザの入力に基づいて、名刺１００の色、フォント等を設定する。
【０１４３】
次のステップＳ４０では、ユーザの入力に基づいて、印刷処理を指示する。これにより、ステップＳ３０〜Ｓ３８で設定した内容がプリンタに送られて、プリンタが名刺１００を印刷する。ステップＳ４０の後は処理を終了する。以上のように、図１８の処理によれば、公開鍵１０２が印刷された名刺１００を作成することが可能となる。
【０１４４】
［４−６：公開鍵に誤り検出符号または誤り訂正符号を付加する例］
次に、公開鍵に誤り検出符号または誤り訂正符号を付加する例について説明する。ユーザが公開鍵１０２を検証装置２００などのデバイスに入力する際、公開鍵１０２の認識誤りの他に、入力誤りをしてしまう場合が想定される。この入力誤りを検知するために、名刺１００に記載する公開鍵１０２を誤り検出符号もしくは誤り訂正符号で符号化し、それをｂａｓｅ６４で表現する。例えば、簡単な誤り検出符号の例として、公開鍵１０２にチェックサムを付けることができる。８ｂｉｔのチェックサムの例では、８０ｂｉｔを１０個の８ｂｉｔ整数とし、その１０個の８ｂｉｔ整数を加算して８ｂｉｔの整数を作り、これをチェックサムとする。但し、名刺１００のスペースには制約があるため、ｂａｓｅ６４で表現した際に１６文字(ないし２０文字)を超える符号化は行わないことが望ましい。
【０１４５】
これにより、ユーザが公開鍵１０２を検証装置２００などのデバイスに入力した際に、誤り検出符号を利用することで、ユーザの入力した公開鍵１０２の誤りを検出することができる。誤り訂正符号を利用した場合は、入力誤りを自動訂正することができる。従って、入力誤りが発生することを確実に抑止することができる。入力誤りの検出、訂正は、検証装置２００の誤り検出・訂正部２１４が行う。
【０１４６】
［４−７：ｂａｓｅ６４以外の符号化方法］
上述した例では、公開鍵をｂａｓｅ６４で符号化する例について説明したが、その他の文字セットを利用して８０ｂｉｔの公開鍵１０２を表現してもよい。例えば、アルファベット２６文字と数字１０文字の合計３６文字のみを利用してもよい。この場合は、以下の例のように、１６文字あれば８０ｂｉｔの情報を十分に表現可能である。
例１）A08G-5JMW-RL2C-98UT
例２)a08g-5jmw-rl2c-98ut
【０１４７】
更に、0(ゼロ)とO(オー)が区別しにくい状況であれば、例えばゼロを除いた３５文字のみを利用してもよい。更に、9とqなど、その他の区別しにくい文字の片方を使わない設定にすることも可能である。この場合においても、３２文字以上の文字セットならば、１６文字で８０ｂｉｔの情報を十分に表現可能である。
【０１４８】
また、例えば常用漢字２１３６字から、悪いイメージの字を除いた文字セットを利用してもよい。２１３６字の文字セットであれば、以下の例のように８文字で８０ｂｉｔの情報を表現可能である．
例３）「楽各次図−屋土索戻」
アラビア文字など、その他の文字セットを利用した場合も同様である。従って、公開鍵は、名刺に記載される氏名、会社名と同じ言語で表示することができる。名刺１００の表面と裏面で表記の言語が異なる場合は、言語に応じて表裏の公開鍵の言語も相違させることができる。
【０１４９】
公開鍵１０２の文字情報は、文字情報をデコードする方式に関する情報を含むことができる。この場合、公開鍵復号化部２０８は、文字情報をデコードする方式に関する情報に基づいて、公開鍵１０２をデコードすることができる。
【０１５０】
以上説明したように本実施形態によれば、名刺１００に目視で認識可能な公開鍵１０２を表示することができる。従って、名刺１００の持ち主は、名刺１００を配ることで、名刺１００を受け取ったユーザに目視で認識可能な公開鍵１０２を通知することが可能となる。これにより、名刺１００を受け取ったユーザは、名刺１００に記載された公開鍵１０２に基づいて、任意に取得した他の公開鍵との対比を目視で行うことが可能となり、検証装置２００などのデバイスに設定されている公開鍵、またはネット上に公開されている公開鍵等が名刺１００の持ち主の公開鍵１０２であるか否かを容易に判断できる。また、名刺１００を受け取ったユーザは、名刺１００に印刷された公開鍵１０２を目視で読み取って検証装置２００などのデバイスに入力することが可能となる。
【０１５１】
以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。
【０１５２】
なお、
（１）公開鍵認証方式の認証に用いる公開鍵が目視で認識できる文字情報として表示された、印刷媒体。
（２）前記公開鍵認証方式はＭＱ認証方式に対応し、前記公開鍵の文字情報は８０ビット以下の情報が符号化された情報である、前記（１）に記載の印刷媒体。
（３）前記公開鍵の文字情報は複数のチャンクに区切られており、１つのチャンクが４文字以下である、前記（２）に記載の印刷媒体。
（４）前記公開鍵の文字情報は、７以下のチャンクに区切られている、前記（２）に記載の印刷媒体。
（５）前記公開鍵の文字情報は、誤り検出又は誤り訂正に関する情報を含む、前記（１）〜（４）のいずれかに記載の印刷媒体。
（６）前記公開鍵の文字情報は、文字情報をデコードする方式に関する情報を含む、前記（１）〜（５）のいずれかに記載の印刷媒体。
（７）前記公開鍵の文字情報は、公開鍵認証方式による認証を行う認証装置に入力されるために用いられる、前記（１）〜（６）のいずれかに記載の印刷媒体。
（８）前記公開鍵の文字情報は、公開鍵認証方式の認証を行う認証装置に登録された公開鍵との一致を判断するために用いられる、前記（１）〜（６）のいずれかに記載の印刷媒体。
（９）前記公開鍵の文字情報は、任意のユーザがネットワークを介して公開している公開鍵との一致を判断するために用いられる、前記（１）〜（６）のいずれかに記載の印刷媒体。
（１０）持ち主の氏名に関する情報を含み、名刺として用いられる、前記（１）〜（９）のいずれかに記載の印刷媒体。
（１１）名刺に記載される氏名、会社名を含む基本事項を入力することと、
公開鍵認証方式の認証に用いる公開鍵を目視で把握できる文字情報として名刺に記載するために入力することと、
前記基本事項及び前記公開鍵の前記文字情報を含む名刺の印刷を指示することと、
を備える、名刺の作成方法。
（１２）名刺に記載される氏名、会社名を含む基本事項を入力する手段、
公開鍵認証方式の認証に用いる公開鍵を目視で把握できる文字情報として名刺に記載するために入力する手段、
前記基本事項及び前記公開鍵の前記文字情報を含む名刺の印刷を指示する手段、
としてコンピュータを機能させるためのプログラム。
【符号の説明】
【０１５３】
１００    名刺
１０２    公開鍵（文字情報）
【図１】
2014087969.tif 000012
【図２】
2014087969.tif 000013
【図３】
2014087969.tif 000014
【図４】
2014087969.tif 000015
【図５】
2014087969.tif 000016
【図６】
2014087969.tif 000017
【図７】
2014087969.tif 000018
【図８】
2014087969.tif 000019
【図９】
2014087969.tif 000020
【図１０】
2014087969.tif 000021
【図１１】
2014087969.tif 000022
【図１２】
2014087969.tif 000023
【図１３】
2014087969.tif 000024
【図１４】
2014087969.tif 000025
【図１５】
2014087969.tif 000026
【図１６】
2014087969.tif 000027
【図１７】
2014087969.tif 000028
【図１８】
2014087969.tif 000029