JP4615708B2

JP4615708B2 - Key authentication method

Info

Publication number: JP4615708B2
Application number: JP2000516464A
Authority: JP
Inventors: ビー．ジョンソン，ドナルド
Original assignee: サーティコムコーポレーション
Priority date: 1997-10-14
Filing date: 1998-10-14
Publication date: 2011-01-19
Anticipated expiration: 2018-10-14
Also published as: JP2013042555A; JP2001520483A; JP5205398B2; CA2305896A1; US20010014153A1; CA2305896C; AU9426598A; EP1025672A1; WO1999020020A1; JP2010093860A

Description

【０００１】
【発明の属する技術分野】
本発明は、通信システムのセキュリティ確保（secure）に関するものであり、特に、そのようなシステムにおけるパラメータや鍵の妥当性検証（認証；validate）を行う方式（手順；scheme）に関する。
【０００２】
【従来の技術】
セキュリティ機能を持つ（secure) データ通信システムを用いて、１組の通信者間で情報の送受信が行われる。交換される情報の少なくとも一部は、送信者が所定の数学的演算を行うことによって、暗号化される。そして、受信者は、上記の数学的演算に応じた相補的な数学的演算を行って、その暗号を解読する。公開鍵あるいは対称型鍵システムでは、通信者同士がいくつかのパラメータを予め知っておく必要がある。例えば、これまでにも、様々な方式やプロトコルが考案されており、送信者の公開鍵や身元などの妥当性検証（認証；validate）が行われている。これらのシステムのセキュリティ（security) あるいは妥当性は、署名が妥当なものか否かに依存し、システムパラメータ（もしあれば）が妥当であり、公開鍵が妥当であり、かつ、署名が確認（検証；verify) された場合に限り確保される。さらに、非対称型システムのセキュリティが確保されるのは、システムパラメータ（もしあれば）が妥当であり、暗号化公開鍵が妥当であり、対称型鍵が指定通りにフォーマットされており、かつ、対称型鍵の復号検査（recovery checks ）でフォーマットの妥当性が検査された場合に限られる。
【０００３】
一方、鍵一致プロトコルのセキュリティが確保されるのは、システムパラメータ（もしあれば）が妥当であり、鍵一致公開鍵が妥当であり、かつ、共有秘密および対称型鍵が規格の指定通り生成された場合に限られる。以上の全てにおいては、公開鍵あるいは対称型鍵、即ち共有秘密が、プロトコル方式にて指定された通りに生成され、妥当であるということを前提として考えている。
【０００４】
【発明が解決しようとする課題】
しかしながら、これらのパラメータが偽物である場合や何らかの形で欠陥がある場合には、問題が生じてしまう。
【０００５】
以下の例を用いて、公開鍵暗号システムの１つあるいは複数のパラメータにおける欠陥が、どのようなことを意味するかについて説明する。例えば、ディジタル署名を用いて送信者の正当性（authenticity）を示す場合を考える。受信者Ａが送信者Ｂから証明書付きの公開鍵を受信すると、Ａは証明書を確認する。次に、ＢがＡに署名付きのメッセージを送信すると、Ａは署名を確認し、さらなる通信が可能と判断することができる。しかしながら、この場合、Ｂが公開鍵を故意に改ざんすれば、この妥当でない公開鍵を受信者Ａが識別できなくなる。同様に、参加者Ｃが鍵対を生成し、続いて公開鍵証明書を受信し、その後に、上記参加者Ｃが、証明書に含まれている公開鍵が妥当であると仮定して、証明書とそれに続いて署名付きのメッセージをＢに送信した場合を考える。上記参加者Ｂは、Ｃの鍵情報を決定することができる。上記の両方の場合から分かるように、署名を確認する際に認証されていないパラメータを使用することに起因して問題が生じる可能性がある。
【０００６】
鍵送信プロトコルでは、通信者Ａが誤って違う相手に対称型鍵を送信してしまうことがある。例えば、通信者Ａが証明書付きの公開鍵を送信者Ｂから受信した場合に、Ａは該証明書を確認し、公開鍵により暗号化された対称型鍵および対称型鍵により暗号化されたメッセージをＢに送信する。これにより、Ａが承認される。逆に、通信者の１人であるＣが鍵対を生成し、公開鍵証明書を得た後にそれをＡに送信する。この場合、Ａは公開鍵を用いて対称型鍵およびメッセージを暗号化し、それをＣに返信する。したがって、この場合、Ｃが承認される。
【０００７】
鍵一致プロトコルにおいては、通信者の１人であるＡが、例えば、Ｂから証明書付きの公開鍵を受信し、Ａの証明書付き公開鍵をＢに送信する。ＡおよびＢはそれぞれ相手側の証明書を確認し、互いに一致した対称型鍵を有する。この例では、Ａが２度承認されることになる。
【０００８】
以上の例から分かるように、公開鍵システムのセキュリティが確保されていても、システムのセキュリティは、通信者の一方あるいは両方に大きく依存しており、要求された所定の鍵が実際のところ使用されている特定のアルゴリズムの所定の鍵であることに依存している。典型的には、受信者は、ビット列を受信すると、このビット列が要求される鍵を実際に表すものであるとみなしてしまうが、そのために対称型鍵システムでは特に問題が生じる。即ち、対称型鍵システムでは、典型的にはサイズが正しければどのようなビット列でも鍵であると解釈されてしまう。このビット列の中の１ビットが所定の鍵と異なっていても、別の鍵として解釈されるので、その鍵が誤ったものでない限り、妥当な暗号演算（crypto operation) を行うことができる。
【０００９】
非対称型秘密鍵システムでは、秘密鍵の所有者はその秘密鍵について全て知っているので、それが正しいか否かの妥当性を検証することができる。しかしながら、第３者が上記所有者のシステムに公開鍵を送信した場合、受信した鍵が公開鍵の算術的要件に合致するものか否か、あるいはその要求された公開鍵を用いて演算（operation ）を行った場合に機密性が確保された暗号演算となるか否かについては、疑問が生じる。所有者のシステムが検査を行わなければ確実には分からないので、所有者にしか分からないことになる。
【００１０】
以上のことから分かるように、鍵の確立は安全でない場合がある。Crypto '97で発表されたリン（Lim ）およびリー（Lee ）による論文では、上記問題点が、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ方式において次数（order ）が正しくない偽公開鍵を用いた場合に、相手側の秘密鍵に関する情報を得ることができるという例を用いて指摘された。ＲＳＡあるいはＲａｂｉｎ方式においては、公開鍵および秘密鍵を１組の大きな素数の関数とすることで、そのような大きな数の因数分解の困難性からセキュリティを確保している。これらの鍵は、２つの任意の大きな素数の積から生成している。しかしながら、ｎが素数であって、２つの素数の積でないとすると、ｐｈｉ（ｎ）＝ｎ−１が成り立つので、偽の「公開鍵」（ｎ，ｅ）から誰でもｄを決定することができる。これらは、公開鍵の使用者が、要求された公開鍵についてアルゴリズムの要件に合致する算術的属性の妥当性を検証することができないが為に生じる問題であると言える。
【００１１】
本発明は、セキュリティ機能を持つ通信システムにおいて、改良された妥当性検証を行うことを目的としている。さらに、本発明は、誰でもいつでも公開情報のみを用いてそのような妥当性検証を行えるようにすることを目的としている。
【００１２】
【課題を解決するための手段】
本発明の公開鍵通信システムにおけるディジタル署名の妥当性検証方法によれば、公開鍵の算術的属性がシステムアルゴリズムに合致することを確認する工程と、上記ディジタル署名を確認する工程とを含む。
【００１３】
さらに、システムパラメータを確認する工程が設けられる。
【００１４】
さらに、要求された公開鍵がアルゴリズムと算術的に合致するか否かの妥当性検証が実行されたことを示す情報と、および適切な場合には、さらに、実行された妥当性検証の回数を示す情報とを証明書情報内に含める工程が設けられる。
【００１５】
【発明の実施の形態】
図１に示すように、データ通信システム１０は、１組の通信者を含み、該１組の通信者は、送信者１２および受信者１４であり、互いに通信チャネル１６により接続されている。送信者１２および受信者１４は、通信チャネル１６を介した送受信用に備えてディジタル情報を処理する暗号化ユニット１８および２０をそれぞれ有している。データ通信システム１０は、証明書発行局（ＣＡ；certification authority 、認証機関とも言う）２２をさらに有していてもよい。
【００１６】
以下、本発明の実施の形態として、公開鍵アルゴリズムを用いた場合について説明する。鍵一致は、以下に示す６つのルーチンを有している。即ち、システムパラメータの生成、システムパラメータの妥当性検証、鍵対の生成、公開鍵の妥当性検証、共用機密の導出（derivation）、および対称型鍵の導出である。上記鍵検証工程においては、誰でもいつでも公開情報のみを用いて公開鍵の妥当性を検証することができる。これらのルーチンにより、公開鍵の値域（range ）および次数（order ）が検証される。公開鍵の妥当性が検証されれば、論理的にはそれに対応する秘密鍵が存在する可能性があるが、実際に存在することは証明されない。
【００１７】
楕円曲線ディジタル署名アルゴリズム（ＥＣＤＳＡ）にも、６つのルーチンが含まれる。即ち、システムパラメータの生成、システムパラメータの妥当性検証、鍵対の生成、公開鍵の妥当性検証、署名の生成、および署名の確認（signature verification）である。一方、ＤＳＡの第１のタイプには、４つのルーチン、即ち、システムパラメータの生成、鍵対の生成、署名の生成、および署名の確認が含まれる。より最近のＤＳＡでは、５つのルーチン、即ち、システムパラメータの生成、（非明示の（implicit））システムパラメータの妥当性検証、鍵対の生成、署名の生成、および署名の確認が含まれる。鍵の妥当性検証を行うために、ＤＳＡパラメータであるｐ、ｑ、およびｇは既に妥当性が検証されているものとみなす。秘密鍵をｘ、公開鍵ｙはｙ＝ｇ^x mod ｐである。そして、ｙの値域について、１＜ｙ＜ｐであることを確認することによって妥当性を検証するとともに、ｙの次数について、ｙ^q mod ｐ＝１であることを確認することによって妥当性を検証する。これらの妥当性検証により、ある要求されたＤＳＡ公開鍵が、そのような鍵に対する算術的要件を満たすものであるということが確認される。これらの妥当性検証は、誰もがいつでも公開情報のみを用いて実行することが可能である。
【００１８】
ＲＳＡあるいはＲａｂｉｎ署名アルゴリズムには、一般に３つのルーチン、即ち、鍵対の生成、署名の生成、および署名の確認が含まれる。ＲＳＡ公開鍵（ｎ，ｅ）の検証は以下の３つのステップを含む。即ち、まず最初にｅの妥当性を検証し、次にｎの妥当性を検証し、その次にｅおよびｎが互いに矛盾していないことを検証する。公開指数ｅの妥当性を検証するためには、指数ｅが２≦ｅ≦２^(k-160) （ｋは法(modulus) ｎのビット長（length））であることを利用する。指数ｅの範囲が上記のような特定された範囲であるべきというこの要件は、特に、ここでの検証を実現可能にしている。ｅ＞２であれば、ｅは奇数でなければならない。さらに、閉じたネットワークの場合には、公開指数ｅは他の全ての判定基準を満たすべきであることが知られている。即ち、例えばｅは３か、６５５３７か、あるいは６５５３７より大きな任意の数でなければならないといった判定基準である。これらの検証は、鍵の妥当性をさらに確認するために行ってもよい。これらの検証については、ＲＳＡ公開鍵部分認証ルーチン（public key partial validation routine ）の仕様（specification ）の一部として含まれていてもよい。上記の指数ｅの検証は簡略なもののように見えるが、この検証により、ＲＳＡ／Ｒａｂｉｎアルゴリズムで選択が試みられるｄよりも前にｅが選択されたことが確認できる。なぜなら、この検証により、ｄｅ＝１ｍｏｄ（ｌｃｍ（ｐ−１，ｑ−１) ）であり、法ｎに比べてｅでは桁数を表すゼロが少なくとも１６０個多いことが分かり、これはｄを先に選択すると実現不可能だからである。
【００１９】
法ｎの妥当性を検証するためには、ｎの大きさを求める。ｎは、正確に（１０２４＋１２８ｓ）ビット（ただし、ｓ＝0 ，1 ，2 ，3 ，…等）を含まなければならないことが知られている。このことは、簡単に検証でき、部分鍵認証の一部とすることができる。法ｎは２つの素数の積で、２より大きい全ての素数が奇数であることから、法ｎが奇数であるか否か判断することによって、法ｎに対してさらなる妥当性検証を行ってもよい。したがって、奇数同士の積は奇数であるので、ｎは奇数でなければならない。さらに、Ｒａｂｉｎアルゴリズムでｅ＝２の場合には、ｐ＝３ｍｏｄｎ、およびｑ＝７ｍｏｄ８でなければならないことが分かっている。このことから、ｎ＝ｐｑ＝２１ｍｏｄ８＝５ｍｏｄ８でなければならない。このことは、ｅ＝２のときにｎ＝５ｍｏｄ８であることを確認することで検証できる。さらに、ｎは完全な累乗（perfect power ）であってはならないことが分かっている。このことから、ｎが２つの異なる素因数からなることが確実に分かり、単純な検査により妥当性が検証できる。上記検証については、Menezes 、van Oorschot、およびVanstoneによる"Handbook of Applied Cryptography(応用暗号手法ハンドブック)"に記述されている。
【００２０】
また、ｎは合成数でなければならないことも知られている。したがって、ｎが素数の場合には、容易に逆変換が可能になるため、セキュリティが全く確保されなくなる。ｎが合成数であるか否かの検証は、ｎが合成数であると実際に証明されると予想してＭｉｌｌｅｒ−Ｒａｂｉｎ確率的素数検証(probable prime test）を行うことによって、実現可能である。法ｎの検証を行うためのさらなる検査は、以下のことに基づくものである。即ち、ｎが２つの大きな素数の積であって、因数分解が難しく、したがって単純な方法で因数分解しようとしても成功しないものであることが分かっていることに基づいている。例えば：ｉとして小さな奇数の素数からある程度の大きさまでの全ての素数、例えば最初の５００００（５０Ｋ）個の奇数の素数について、ＧＣＤ（ｎ，ｉ）を計算してみてもよい。
【００２１】
前述の２つの検証により、前者からは少なくとも１つの因子が法のビットの半分以下の大きさでなければならないことが分かり、後者からは各因子が検証した最大素数よりも大きくなければならないことが分かる。さらに、ポテンシャル因子（ｐ，ｑ，ｒ，…）は、上記で検証した最大素数の大きさに依存した限られた数しか存在しなくなる。
【００２２】
以上の複数の検証を組み合わせると、相乗効果が得られる。検証の目的は、敵のとりうる行動の自由度を大幅に小さくすることである。攻撃がほぼ不可能な場合であっても、部分的鍵認証を行うことによって、攻撃をより一層困難にし、望ましくは攻撃を不可能あるいは少なくとも非経済的なものにすることができる。
【００２３】
さらに、ｐおよびｑの値は近くなりすぎてはならないものであるから、法ｎを検証する際には、これらが近接した値であると仮定し、ｎの因数分解を試みる。ｎの平方根をｐおよびｑの初期予想値とする。ｐを減少させる一方、ｑを増加させ、ｎが所定の限度まで因数分解できるか決定する。さらに、ＲＳＡの法のセットでは素数が繰り返してはならないことが分かっているため、ＲＳＡのある法のセットｎ１、ｎ２に対して、ＧＣＤ（ｎｉ，ｎｊ）を計算し、全ての計算結果が１に等しいことを確認することができる。
【００２４】
上述のオフライン検証には限界が存在するが、パラメータの所有者が特定の情報、例えばｎの因数分解を知っているので、これらの検証を拡張することができる。よって、所有者をオンラインオラクル（oracle）として利用してもよい。このオラクルに関してなされる質問に対する回答が不正解であることを識別することで、誰もが公開鍵が無効であると断言できることになる。
【００２５】
Vanstoneらの"Handbook of Applied Cryptography"によれば、所有者は（平方根ｍｏｄｎ）を計算できるが、他者にはできない。検証者は、（任意値ｍｏｄｎ）のヤコビ符号（ヤコビアン；Jacobi Symbol ）を１または−１に決定し、半分は１、他方の半分は−1 に決定する。１の場合には、その数が平方数か否かで、再度半々に分けられる。検証者は、（ある数 mod n）を平方する。平方数のヤコビ符号は、常に１である。
【００２６】
検証者は、既知の平方数ｕおよびヤコビ符号が１である任意の要素ｒのいずれかを選択する。そして、所有者にこの２種類の要素に対して「これは平方数であるか」と質問する。所有者は、イエスかノーかで回答する。ｕが選択された場合、所有者がイエスと答えなければ鍵の法（modulus ）は無効となる。ｒが選択された場合、所有者がイエスと答える回数とノーと答える回数とがそれぞれ約半分でなければ、鍵の法が無効となる。
【００２７】
これを何度も繰り返すことにより、信頼性が高まる。検証者が全て平方数について所有者に質問した場合には、所有者は常にイエスと答えなければならない。検証者が全てヤコビ符号が１である任意の要素について所有者に質問した場合には、所有者はその半分にはイエスと答え、半分にはノーと答えなければならない。偽鍵の所有者は、少なくとも半分の答えがイエスであることを知っているだけである。しかしながら、秘密鍵の所有者であれば、ｎの因数分解を知っており、平方数を知っているので、擬似平方数についてそれらが平方数であると嘘をついて、検証者を騙しさえすればよい。検証者は、既知の擬似平方数を用いて「これは平方数であるか」と質問するだけでよい。通常、法の因数分解を知らなければ、ある数がその法の擬似平方数であると決定することは不可能である。しかしながら、所有者は、上述の質問に対して、ヤコビが１である数のいくつかは擬似平方数であると答えなければならない。検証者は、既知の擬似平方数と（平方数 mod ｎ）とを掛け合わせることによって、任意の既知の擬似平方数を生成することはできる。検証者は、その結果として得られた値については、擬似平方数であると知っている。この３つめのタイプの数ｔ（既知の擬似平方数）について所有者に尋ねると、この場合には、所有者がいくつかの擬似平方数は平方数であると嘘をついても、その嘘が検証者に知られる。
【００２８】
ｅとｎとを共に検証するには、ＧＣＤ（ｅ，ｐ−１）＝１、かつＧＣＤ（ｅ，ｑ−１）＝１でなければならない。ｅが奇数の場合には、整数ｘおよびｐに対してｐがｘｅ＋１の形で表されない数であり、かつ、整数ｙに対してｑがｙｅ＋１の形で表されない数でなければならないことが分かっている。ｐとｑとの両方が不正な場合には、ｎがｘｙｅ² ＋ｘｅ＋ｙｅ＋１の形で表されないものであり、かつｎ≠１ｍｏｄｅが成り立たなければならない。
【００２９】
ｅとｎとを共に検証する別の方法について以下に説明する。ＧＣＤ（ｅ，ｐｈｉ（ｎ））が１でなければならないことが分かっている。ｐｈｉ（ｎ）＝（ｐ−１）（ｑ−１）であることが分かっているので、式が２つで未知数が２つであるから、検証者は、ｎを因数分解することができる。
【００３０】
鍵対に対する他の要件が満たされているとする。ＧＣＤ（ｅ，ｐｈｉ（ｎ））＝１を満たす必要があるのは、ｅを用いた演算を確実に１：１対応（逆変換可能）の関数とするためである。さもなければ、ｅを用いた演算が多数：１になってしまう。ｅを用いた演算が多数：１対応の場合には、ｄ（ｅの逆元（inverse)）が存在しなくなるか、少なくとも通常では導き出せなくなる。所有者はｄが実際に存在するという証拠を提示しなければならない。しかしながら、上記質問は、秘密鍵の所有者の管理の元で行うべきではない。即ち、所有者自身で署名した証明書要求（self-signed certificate request ）では、十分な証拠とはならない。
【００３１】
挑戦者は、承認を要求された所有者にダミーメッセージをいくつか送信して署名させることもできる。秘密鍵の所有者は、それらがダミーメッセージであると確認し、署名し、挑戦者に返信する。これは、ｄが存在するオンライン確率的オラクル検証（online probabilistic oracle test）である。
【００３２】
したがって、誰でもオフライン検証がいつでも実行できる。所有者がオンライン状態にあれば、誰でもオンライン検証を実行できる。所有者は、オフラインおよびオンライン検証を行って、自身の秘密鍵が有効であることを確認することができる。ＣＡは、オンライン検証を行って、公開鍵証明書において何の妥当性がどの程度まで検証されているかを他者に伝える。
【００３３】
ＥＣＤＳＡにおけるシステムパラメータは、フィールドサイズｑ＝ｐまたは２^m である。オプションの種（optional seed ）によって（ａ，ｂ）が生成され、（ａ，ｂ）によって、曲線の次数がｈｎとなるように、Ｆ_q で表される楕円曲線、この曲線上の特異点Ｐ、Ｐの大きな素数の次数（large prime order ）であるｎ、および余因子（cofactor）ｈを定義する。（ａ，ｂ）で定義されるフィールドサイズＥＣおよび点Ｐは主要パラメータである。
【００３４】
ＥＣシステムパラメータだけでなく、ＥＣ公開鍵についても確認することが重要である。例えば、楕円曲線公開鍵Ｑを想定し、ＱがＥ上にあるとする。鍵一致において素数の次数の曲線を使用している場合、Ｑの次数を検査する必要はない。なぜなら、Ｑが曲線上にあれば正確な次数を有していることが確かであるからである。Ｑが曲線上にあることを検査することは重要である。なぜなら、Ｑが曲線上になければ、偽鍵が、ａＱを計算する際に秘密鍵ａを明かしてしまうからである。公開鍵が曲線上にあると確認することは、曲線の式に代入するか、検証を行うことにより可能である。
【００３５】
以上のことから、鍵認証を行うことにより、攻撃にさらされることが抑制され、不慮のエラーの検出が助けられ、ＣＡが行う価値のあるサービスが提供されることになる。当業者ならば理解できるように、上記の技術および方法は、本発明の工程を実行する適切なプロセッサにおいて実現することができる。さらに、上述の様々な方法は、汎用のコンピュータを使用し、ソフトウェアにて選択的に起動あるいは再構成して実行するのが便利がよいが、当業者ならば理解できるように、そのような方法は、必要な各工程を実行するように構成された、ハードウェア、ファームウェア、あるいはより特殊な装置において実現してもよい。
【００３６】
【発明の効果】
本発明によれば、セキュリティ機能を持つ通信システムにおいて、改良された妥当性検証を行うことができる。さらに、本発明によれば、誰でもいつでも公開情報のみを用いてそのような妥当性検証を行うことが可能となる。
【図面の簡単な説明】
【図１】通信システムの概略図である。[0001]
BACKGROUND OF THE INVENTION
The present invention relates to security of a communication system, and more particularly, to a method (procedure) for performing validation (validation) of parameters and keys in such a system.
[0002]
[Prior art]
Information is transmitted / received between a pair of communicators using a secure data communication system. At least some of the information exchanged is encrypted by the sender performing a predetermined mathematical operation. Then, the receiver performs a complementary mathematical operation corresponding to the mathematical operation described above, and decrypts the code. In a public key or symmetric key system, it is necessary for communicators to know some parameters in advance. For example, various schemes and protocols have been devised so far, and validation (authentication) of the sender's public key and identity is performed. The security or validity of these systems depends on whether the signature is valid, the system parameters (if any) are valid, the public key is valid, and the signature is confirmed ( It is ensured only when verified. In addition, the security of an asymmetric system is ensured when the system parameters (if any) are valid, the encrypted public key is valid, the symmetric key is formatted as specified, and symmetric Only when the validity of the format is checked by type key recovery checks.
[0003]
On the other hand, the security of the key agreement protocol is ensured when the system parameters (if any) are valid, the key agreement public key is valid, and the shared secret and symmetric key are generated as specified in the standard. Limited to In all of the above, it is assumed that a public key or a symmetric key, that is, a shared secret, is generated as specified by the protocol method and is valid.
[0004]
[Problems to be solved by the invention]
However, problems arise if these parameters are fake or somehow flawed.
[0005]
The following example explains what a defect in one or more parameters of a public key cryptosystem means. For example, consider the case where a sender's authenticity is indicated using a digital signature. When receiver A receives a public key with a certificate from sender B, A confirms the certificate. Next, when B sends a signed message to A, A can confirm the signature and determine that further communication is possible. However, in this case, if B intentionally falsifies the public key, the recipient A cannot identify this invalid public key. Similarly, participant C generates a key pair and subsequently receives a public key certificate, after which participant C assumes that the public key contained in the certificate is valid, Consider the case where a certificate and subsequent signed message is sent to B. Participant B can determine C's key information. As can be seen from both cases above, problems can arise due to the use of unauthenticated parameters when verifying the signature.
[0006]
In the key transmission protocol, the communicator A may accidentally transmit a symmetric key to a different partner. For example, when communicator A receives a public key with a certificate from sender B, A confirms the certificate and is encrypted with a symmetric key and a symmetric key encrypted with the public key. Send message to B. Thereby, A is approved. Conversely, one of the communicators, C, generates a key pair, obtains a public key certificate, and transmits it to A. In this case, A encrypts the symmetric key and message using the public key and sends it back to C. Therefore, in this case, C is approved.
[0007]
In the key agreement protocol, one of the communicators, for example, receives a public key with a certificate from B and transmits the public key with a certificate of A to B. A and B each confirm the certificate of the other party and have symmetric keys that match each other. In this example, A is approved twice.
[0008]
As can be seen from the above examples, even if the security of the public key system is ensured, the security of the system largely depends on one or both of the communicators, and the requested predetermined key is actually used. Rely on being a predetermined key for a particular algorithm. Typically, when a recipient receives a bit string, he or she assumes that the bit string actually represents the required key, which is particularly problematic in symmetric key systems. That is, in a symmetric key system, typically, any bit string having a correct size is interpreted as a key. Even if one bit in this bit string is different from the predetermined key, it is interpreted as another key, so that an appropriate cryptographic operation can be performed unless the key is wrong.
[0009]
In an asymmetric secret key system, the owner of the secret key knows everything about the secret key and can verify the validity of it. However, when a third party sends a public key to the owner's system, whether the received key meets the arithmetic requirements of the public key or an operation (operation using the requested public key). ) Raises a question as to whether or not the encryption operation will ensure confidentiality. If the owner's system doesn't test, it's definitely not known, so only the owner knows.
[0010]
As can be seen from the above, the establishment of a key may not be secure. According to a paper by Lim and Lee published in Crypto '97, the above problem is that the other party's secret when using a false public key with an incorrect order in the Diffie-Hellman method It was pointed out with an example that information about keys can be obtained. In the RSA or Rabin system, the public key and the secret key are set as a function of a large prime number, thereby ensuring security from the difficulty of factoring such a large number. These keys are generated from the product of two arbitrarily large prime numbers. However, if n is a prime number and not a product of two prime numbers, phi (n) = n−1 holds, so that anyone can determine d from a fake “public key” (n, e). it can. These can be said to be problems caused by the fact that the public key user cannot verify the validity of the arithmetic attributes that match the algorithm requirements for the requested public key.
[0011]
An object of the present invention is to perform improved validity verification in a communication system having a security function. Furthermore, an object of the present invention is to make it possible for anyone to perform such validation at any time using only public information.
[0012]
[Means for Solving the Problems]
According to the digital signature validity verification method in the public key communication system of the present invention, the method includes a step of confirming that the arithmetic attribute of the public key matches the system algorithm, and a step of confirming the digital signature.
[0013]
Furthermore, a step of checking system parameters is provided.
[0014]
In addition, information indicating that the validation of whether the requested public key is arithmetically matched with the algorithm has been performed, and if appropriate, the number of validations performed. And a step of including the information to be included in the certificate information.
[0015]
DETAILED DESCRIPTION OF THE INVENTION
As shown in FIG. 1, the data communication system 10 includes a set of communicators, which are a sender 12 and a receiver 14, and are connected to each other by a communication channel 16. The sender 12 and the receiver 14 have encryption units 18 and 20, respectively, that process digital information in preparation for transmission / reception via the communication channel 16. The data communication system 10 may further include a certificate authority (CA) 22.
[0016]
Hereinafter, a case where a public key algorithm is used will be described as an embodiment of the present invention. The key agreement has the following six routines. That is, system parameter generation, system parameter validation, key pair creation, public key validation, shared secret derivation, and symmetric key derivation. In the key verification step, anyone can verify the validity of the public key at any time using only public information. These routines verify the range and order of the public key. If the validity of the public key is verified, there may be a logically corresponding private key, but it is not proved that it actually exists.
[0017]
The Elliptic Curve Digital Signature Algorithm (ECDSA) also includes six routines. That is, system parameter generation, system parameter validity verification, key pair generation, public key validity verification, signature generation, and signature verification. On the other hand, the first type of DSA includes four routines: system parameter generation, key pair generation, signature generation, and signature verification. More recent DSAs include five routines: system parameter generation, (implicit) system parameter validation, key pair generation, signature generation, and signature verification. In order to perform key validation, it is assumed that the DSA parameters p, q, and g have already been validated. The secret key is x and the public key y is y = g ^x mod p. Then, the validity of the range of y is verified by confirming that 1 <y <p, and the order of y is y ^q Validate by checking that mod p = 1. These validations confirm that a requested DSA public key meets the arithmetic requirements for such a key. These validations can be performed at any time by using only public information.
[0018]
An RSA or Rabin signature algorithm generally includes three routines: key pair generation, signature generation, and signature verification. The verification of the RSA public key (n, e) includes the following three steps. That is, the validity of e is first verified, then the validity of n is verified, and then e and n are verified to be consistent with each other. In order to verify the validity of the public index e, the index e is 2 ≦ e ≦ 2 ^(k-160) (K is the modulus n bit length). This requirement that the range of the index e should be in the specified range as described above in particular makes the verification here feasible. If e> 2, e must be an odd number. Furthermore, it is known that in the case of a closed network, the public index e should satisfy all other criteria. That is, for example, e is a determination criterion that e must be 3, 65537, or any number larger than 65537. These verifications may be performed to further confirm the validity of the key. These verifications may be included as part of the specification of the RSA public key partial validation routine. Although the verification of the above-mentioned index e seems to be simple, it can be confirmed that e is selected before d in which selection is attempted in the RSA / Rabin algorithm. Because this verification shows that de = 1 mod (lcm (p−1, q−1)), and e has at least 160 zeros representing the number of digits compared to modulus n, which This is because it cannot be realized if it is selected first.
[0019]
In order to verify the validity of the modulus n, the magnitude of n is obtained. It is known that n must contain exactly (1024 + 128 s) bits (where s = 0, 1, 2, 3,... etc.). This can be easily verified and can be part of partial key authentication. Since modulus n is the product of two prime numbers and all prime numbers greater than 2 are odd numbers, even if further validity verification is performed on modulus n by determining whether modulus n is odd or not Good. Therefore, since the product of the odd numbers is an odd number, n must be an odd number. Furthermore, it has been found that when e = 2 in the Rabin algorithm, p = 3 mod n and q = 7 mod 8. Therefore, n = pq = 21 mod 8 = 5 mod 8 must be satisfied. This can be verified by confirming that n = 5 mod 8 when e = 2. Furthermore, it has been found that n must not be a perfect power. From this, it is clear that n is composed of two different prime factors, and the validity can be verified by a simple test. The above verification is described in "Handbook of Applied Cryptography" by Menezes, van Oorschot, and Vanstone.
[0020]
It is also known that n must be a composite number. Therefore, when n is a prime number, reverse conversion can be easily performed, and security is not ensured at all. Verification of whether n is a composite number can be realized by performing Miller-Rabin probable prime test assuming that n is actually proved to be a composite number. . Further tests for verifying modulus n are based on: In other words, n is the product of two large prime numbers, and it is difficult to factorize, so it is known that attempts to factor in a simple manner will not succeed. For example: GCD (n, i) may be calculated for all prime numbers from a small odd prime number to a certain size as i, for example, the first 50000 (50K) odd prime numbers.
[0021]
From the above two verifications, it can be seen from the former that at least one factor must be less than half the modulus bits, and from the latter, each factor must be greater than the maximum prime number verified. I understand. Further, there are only a limited number of potential factors (p, q, r,...) Depending on the maximum prime number verified above.
[0022]
Combining the above verification results in a synergistic effect. The purpose of the verification is to greatly reduce the freedom of action that the enemy can take. Even if the attack is nearly impossible, performing partial key authentication can make the attack even more difficult, preferably making the attack impossible or at least uneconomical.
[0023]
Furthermore, since the values of p and q must not be too close, when verifying modulus n, we assume that they are close values and attempt to factor n. Let the square root of n be the initial expected values of p and q. Decrease p while increasing q to determine if n can be factored to a predetermined limit. Further, since it is known that prime numbers should not be repeated in the RSA modulus set, GCD (ni, nj) is calculated for a certain set of RSAs n1 and n2, and all the calculation results are 1 Can be confirmed.
[0024]
Although there are limitations to the offline verification described above, these verifications can be extended because the parameter owner knows certain information, such as factorization of n. Thus, the owner may be used as an online oracle. By identifying that the answer to the question made about this oracle is incorrect, anyone can assert that the public key is invalid.
[0025]
According to Vanstone et al., "Handbook of Applied Cryptography", the owner can calculate (square root mod n), but not others. The verifier determines the Jacobian code (Jacobi Symbol) of (arbitrary value mod n) as 1 or −1, and determines that the half is 1 and the other half is −1. In the case of 1, it is divided again in half depending on whether the number is a square number or not. The verifier squares (a number mod n). The Jacobian code for the square number is always 1.
[0026]
The verifier selects one of the arbitrary elements r whose known square number u and Jacobian code are 1. The owner is then asked the two types of elements, "Is this a square number?" The owner will answer yes or no. If u is selected, the modulus will be invalid if the owner does not answer yes. If r is selected, the key law becomes invalid if the number of times the owner answers yes and no is about half each.
[0027]
By repeating this many times, the reliability increases. If the verifier asks the owner about all squares, the owner must always answer yes. If the verifier asks the owner about any element whose Jacobian code is all 1, the owner must answer yes to half and no to half. The owner of the false key only knows that at least half of the answers are yes. However, if you are the owner of the secret key, you know the factorization of n and know the squares, so if you lie about pseudo-squares that they are squares, just trick the verifier. Good. The verifier need only ask “is this a square number” using a known pseudo-square number? Usually, without knowing the factorization of a law, it is impossible to determine that a number is a pseudosquare number of the law. However, the owner must answer the above question that some of the numbers with Jacobian being 1 are pseudo-square numbers. The verifier can generate any known pseudo-square number by multiplying the known pseudo-square number by (square number mod n). The verifier knows that the resulting value is a pseudosquare number. When you ask the owner about this third type of number t (known pseudosquare number), in this case, if the owner lies that some pseudosquares are square numbers, Known to verifiers.
[0028]
To verify both e and n, GCD (e, p-1) = 1 and GCD (e, q-1) = 1. If e is odd, we know that for integers x and p, p must be a number not represented in the form of xe + 1, and for integer y, q must be a number not represented in the form of ye + 1. ing. If both p and q are invalid, n is xye ² It is not expressed in the form of + xe + ye + 1, and n ≠ 1 mod e must hold.
[0029]
Another method for verifying both e and n is described below. It has been found that GCD (e, phi (n)) must be 1. Since it is known that phi (n) = (p−1) (q−1), since there are two equations and two unknowns, the verifier can factor n.
[0030]
Assume that other requirements for key pairs are met. The reason why GCD (e, phi (n)) = 1 needs to be satisfied is to ensure that the calculation using e is a function corresponding to 1: 1 (reverse conversion possible). Otherwise, the number of operations using e will be 1: 1. If there are many operations using e with a one-to-one correspondence, d (inverse of e) does not exist, or at least normally cannot be derived. The owner must present evidence that d actually exists. However, the above question should not be asked under the control of the private key owner. That is, a certificate request (self-signed certificate request) signed by the owner is not sufficient evidence.
[0031]
The challenger can also send several dummy messages to the owner who has requested approval to sign. The owner of the private key confirms that they are dummy messages, signs them, and sends them back to the challenger. This is an online probabilistic oracle test where d exists.
[0032]
Therefore, anyone can perform offline verification at any time. Anyone can perform online verification if the owner is online. The owner can perform offline and online verification to confirm that his private key is valid. The CA performs on-line verification and tells others what the validity of the public key certificate has been verified.
[0033]
The system parameter in ECDSA is the field size q = p or 2 ^m It is. F _q is generated so that (a, b) is generated by an optional seed and the degree of the curve is hn by (a, b). , A singular point P on the curve, n which is a large prime order of P, and a cofactor h. The field size EC and point P defined by (a, b) are the main parameters.
[0034]
It is important to check not only the EC system parameters but also the EC public key. For example, assuming an elliptic curve public key Q, Q is on E. If a prime order curve is used in key matching, it is not necessary to check the order of Q. This is because if Q is on the curve, it is certain that it has the correct order. It is important to check that Q is on the curve. This is because if Q is not on the curve, the false key reveals the secret key a when calculating aQ. It is possible to confirm that the public key is on the curve by substituting it into the equation of the curve or performing verification.
[0035]
From the above, by performing key authentication, exposure to an attack is suppressed, detection of an unexpected error is helped, and a service worth performing by CA is provided. As will be appreciated by those skilled in the art, the techniques and methods described above can be implemented in any suitable processor that performs the steps of the present invention. In addition, the various methods described above can be conveniently performed using a general-purpose computer and selectively activated or reconfigured by software, as will be appreciated by those skilled in the art. May be implemented in hardware, firmware, or a more specialized device configured to perform each necessary step.
[0036]
【The invention's effect】
According to the present invention, improved validity verification can be performed in a communication system having a security function. Furthermore, according to the present invention, it is possible for anyone to perform such validity verification using only public information at any time.
[Brief description of the drawings]
FIG. 1 is a schematic diagram of a communication system.

Claims

In a method for verifying the validity of a public key transmitted to a communication partner in a data communication system, wherein the communication partner has an encryption unit,
a) The communication partner is generated from a corresponding secret key according to an elliptic curve encryption method according to a predetermined arithmetic algorithm and a defined system parameter including an elliptic curve E defined on a finite field. Obtaining an elliptic curve public key Q;
b) confirming that the public key is a point located on the elliptic curve E using the encryption unit;
c) performing an encryption operation using the public key in the encryption unit.

The confirmation that the point is on the elliptic curve E is that the encryption unit substitutes the coordinates of the point into the definition equation of the elliptic curve E and confirms that the coordinates satisfy the definition equation. The method of claim 1, wherein the method is performed by:

3. The method according to claim 1, wherein the elliptic curve E is a prime order elliptic curve.

4. A method according to any one of claims 1 to 3, wherein the encryption operation is performed as part of a key agreement protocol.

The elliptic curve encryption method is an elliptic curve digital signature algorithm (ECDSA), and the encryption operation is confirmation of a signature generated according to an elliptic curve digital signature algorithm (ECDSA). 4. The method according to any one of items 3 to 3.

4. The method according to claim 1, wherein the communication partner is a certification authority.

The authentication authority, the public key is further seen contains a step to include in the certificate an indication that it is a confirmed, in claim 6 said indicator, characterized in that it is indicative of the verification of the validity The method described.