楕円曲線DSA(だえんきょくせんDSA、Elliptic Curve Digital Signature Algorithm、Elliptic Curve DSA、楕円DSA、ECDSA)は、Digital Signature Algorithm (DSA) について楕円曲線暗号を用いるようにした変種である。
楕円曲線暗号で一般的に言われるように、ECDSAにおいて必要とされる公開鍵のサイズはセキュリティビット数のおよそ2倍であると考えられている。例えば、80ビットのセキュリティビット数(攻撃者が秘密鍵を取得するために 回の計算を必要とする)を得るために、DSAでは最低でも1024ビットの公開鍵が必要であるが、ECDSAでは160ビットの公開鍵で十分である。一方、署名のサイズはDSAでもECDSAでも同じであり、必要とするビット安全性の4倍のビット長を要する(80ビットのビット安全性を保つためには320ビットの長さの署名が必要)。
(注)「」は楕円曲線上での掛け算 (scalar multiplication) を意味する。
アリスが署名したメッセージをボブに送る場合を考える。最初に、使用する楕円曲線のパラメータ を決めておく必要がある。
アリスは の範囲からランダムに選択された秘密鍵 と、公開鍵 から成る鍵ペアを生成する。 と の対応は1対1であり、 から を計算することは比較的容易だが、 から を計算することは実質的に不可能(離散対数問題)である。つまり と の対応は一方向性関数になっている。
アリスがメッセージ に署名する場合、以下の計算を行う。
- を計算する。ここで H はSHA-1のような暗号学的ハッシュ関数を指す。
- を、 の最上位側の ビットとする。ここで は位数 のビット長とする。
- の範囲から整数 を任意に選択する。
- 曲線上の点 を計算する。
- を計算する。 となる場合には の選択に戻る。
- を計算する(は有限体におけるの逆元である)。 となる場合には の選択に戻る。
- が に対する署名となる。
を計算する際に、 から得られる は整数に変換される。 は より「大きい」ことは許されるが、「長い」ことは許されない[1]。
DSAと同様に、署名ごとに異なる を選択することは極めて重要である。さもないと、ステップ6の式から秘密鍵 を得ることが可能となってしまう。メッセージ および に対して、未知だが同じ から得られた2つの署名 および がある場合、攻撃者は および を計算することが可能であり、 であることから、 が得られる。 であるから、攻撃者は秘密鍵 を得ることができる。このように単一の を用いることは不適切な実装であり、PlayStation 3のソフトウェア署名鍵が漏洩したのはこれが原因であった[2]。
ボブがアリスの署名を検証するためには、アリスの公開鍵 が必要である。公開鍵 が正当なものであるかの検証は以下のとおりである。
- が でないことを確認する。
- が曲線上にあることを確認する。
- であることを確認する。
メッセージ と署名 の検証は以下のように行われる。
- および がいずれも の範囲にある整数であることを確認する。これを満たさない場合には署名は不正なものである。
- を計算する。ここで H は署名生成に用いられたハッシュ関数と同一のものである。
- を、 の最上位側の ビットとする。
- を計算する。
- および を計算する。
- 曲線上の点 を計算する。
- であれば署名は正当なものである。
Straus's algorithm(Shamir's trickとも)を用いることで、2つの楕円曲線上での掛け算の和 を、2つの楕円曲線上での掛け算よりも速く計算することができる[3]。
ここで は署名検証のステップ6で得られた点とする。
公開鍵が と定義されることより
楕円曲線上での掛け算より
署名検証のステップ4より および の定義を拡張すると
を外に出して
署名のステップ6より の定義を拡張すると
逆数の逆数は元と同じであることと、逆数と元の積は であることから
の定義より、これは署名検証のステップ6と等しい。
これは正しく署名されたメッセージは正しく検証されることのみを示しており、セキュアな署名アルゴリズムであるための他の要素については考慮していない。
2010年12月、fail0verflowと名乗るグループが、ソニーがPlayStation 3のソフトウェア署名に用いていたECDSA秘密鍵の回復に成功したと発表した。しかし、これは をランダムではなく固定値としていたソニーの不適切な実装によるものであり、アルゴリズム自体の脆弱性ではない。署名生成のセクションで述べたように、 を固定値で用いることは秘密鍵 を計算可能とし、アルゴリズムを破綻させるものである[4]。
2011年3月29日、2人の研究者による論文がIACR(英語版)に発表された。この論文では、サイドチャネル攻撃の一つであるタイミング攻撃によって、ECDSAを認証に利用し、OpenSSLを用いたサーバのTLS秘密鍵を入手可能であることが示された[5]。この脆弱性はOpenSSL 1.0.0eで修正された[6]。
2013年8月、Java class SecureRandomのいくつかの実装において、 のコリジョンが発生することがあるバグが明らかとなった。前述のように、これにより秘密鍵を得ることが可能であり、Javaを利用しECDSAを認証に用いていたAndroidアプリからBitcoinが盗まれる危険性があった[7]。この問題は、RFC 6979にあるように、秘密鍵とメッセージハッシュから決定論的に を導くことで回避できる。
このアルゴリズムは楕円曲線をパラメータとして必要とするが、多くの場合NISTによって定められた楕円曲線(P-256、P-384、P-521など)[8]が用いられる。これらの曲線は特定のシード値からSHA-1を基盤としたアルゴリズムを用いて算出されている[8]が、シード値の根拠が不明であること[9][10]、また同じく固定の楕円曲線を用いたアルゴリズムであるDual_EC_DRBG(英語版)にNSAがバックドアを仕込んだ上でRSAセキュリティ社のセキュリティ製品に採用させたと報道されたこと[11]から、疑いの目で見られることがある[12][13]。
ECDSAをサポートしているライブラリは以下の通りである。
Maxwell, Gregory (2013年9月8日). “[tor-talk NIST approved crypto in Tor?]”. 2015年7月11日閲覧。
- Accredited Standards Committee X9, American National Standard X9.62-2005, Public Key Cryptography for the Financial Services Industry, The Elliptic Curve Digital Signature Algorithm (ECDSA), November 16, 2005.
- Certicom Research, Standards for efficient cryptography, SEC 1: Elliptic Curve Cryptography, Version 2.0, May 21, 2009.
- López, J. and Dahab, R. An Overview of Elliptic Curve Cryptography, Technical Report IC-00-10, State University of Campinas, 2000.
- Daniel J. Bernstein, Pippenger's exponentiation algorithm, 2002.
- Daniel R. L. Brown, Generic Groups, Collision Resistance, and ECDSA, Designs, Codes and Cryptography, 35, 119–152, 2005. ePrint version
- Ian F. Blake, Gadiel Seroussi, and Nigel P. Smart, editors, Advances in Elliptic Curve Cryptography, London Mathematical Society Lecture Note Series 317, Cambridge University Press, 2005.
- . (2004). doi:10.1007/b97644.