Let's Encryptを使って快適ECDSA生活


Let's EncryptからECDSAの署名を出せるということだったので、使ってみることにしました。

ECDSAのメリット

一般的に、SSLで使うサーバ証明書はRSAで署名されていますが、他の方式としてECDSAがあります1

ECDSAを使うことによるメリットは、RSAと比較した場合の安全性と高速性です。一般に、RSAによる署名は2048ビットですが、その強度はAES 128ビット相当にも満たず、同程度の強度を得ようとすれば3072ビットが必要となります。一方、ECDSAの強度は半分の長さのAESと同程度なので、証明書に使われる256ビットでAES 128ビット相当のセキュリティを得られます。

そして、サーバ負荷はRSA 2048ビットと比べてもECDSA 256ビットのほうが圧倒的に軽くなっています。クライアント側の負荷は少し増えますが、トータルすれば処理速度は上がることとなります。

ECDSAのデメリット

RSAと比較して、ECDSAを使う場合のデメリットを並べていきます。

  • 別に暗号鍵を交換する必要がある:ECDSAは楕円曲線デジタル署名アルゴリズム(Elliptic Curve Digital Signature Algorithm)の略であるというように2署名専用なので、通信用の暗号鍵交換は別途のアルゴリズムで行う必要があります。
    • ただし、署名用のRSA鍵で暗号鍵配送も行うと、秘密鍵が漏れた場合に暗号文を解読されてしまうので、RSAでも別途で暗号鍵交換を行って、通信内容の秘匿はRSA鍵に頼らないForward Secrecyが行われるようになっています。
  • 楕円曲線暗号の特許や、演算する楕円曲線の恣意性が気になる
    • 現実問題としてRSA+ECDHEという、RSA署名に楕円曲線での鍵交換を行う方式も普及していますので、それを使うのとさほど問題は変わりません(あまり気にしないことが多いです)。
  • RSA署名にしか対応していない環境がある
    • もっとも、ガラケーなどはRSAでもSHA-2署名に非対応ということもあって、RSA+SHA-2と比較してECDSAが使えないのはWindows XP以前やAndroid 2.3、ゲーム機のブラウザなど、かなり限られます。
  • 出せる証明局が限られる(とりわけ安価な証明書がない)
    • タイトルのとおり、Let's Encryptで出せるようになったので、内輪向けなどで高級な証明書が不要な場面にも適用できるようになりました。

ECDSA証明書を発行する

Qiitaにも先行記事はあるのですが、ACMEプロトコルを実装した別のクライアントであるletsencrypt.shを使うのも便利です(lukas2511/letsencrypt.sh)。詳しくは別サイトに譲りますが、認証方法としてHTTP経由だけでなくDNS経由という方法もありますので、指定のドメインでHTTPサーバを立てづらい状況でも認証を通せます。

CipherSuiteの設定

RSA証明書と合わせるCipherSuiteは山のようにあって、何をどう選べばいいのか迷いますが、ECDSA対応のCipherSuiteは、同じ楕円曲線暗号のECDHEとの組み合わせだけとなっています。

ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA1
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA256
ECDHE-ECDSA-AES128-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA1
ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH     Au=ECDSA Enc=3DES(168) Mac=SHA1
ECDHE-ECDSA-RC4-SHA     SSLv3 Kx=ECDH     Au=ECDSA Enc=RC4(128)  Mac=SHA1
ECDHE-ECDSA-NULL-SHA    SSLv3 Kx=ECDH     Au=ECDSA Enc=None      Mac=SHA1

強度が112ビット分しかない3DES3、安全性が崩壊しているRC4、暗号化しないNULLは当然除外して、残るはAESだけです。

  • ECDHEが256ビットの場合、この鍵交換がAES128ビット相当の強度なので、AES128ビットを優先で強度的にも問題ありません(256ビットかけても過剰性能なだけです)。
  • GCMモードを優先したほうが安全です。

ということで、OpenSSLのCipherSuiteとしては、ECDSA+AESGCM+AES128:ECDSA+AESGCM:ECDSA+AES128:ECDSA+AES:!aRSA:!RC4:!3DES:!NULLというような感じになります。


  1. いちおう、DSAやケルベロス認証、事前鍵共有(PSK)など、他の方式も定義されてはいますが、サーバやブラウザで対応していない、事前の設定が必要で不特定多数との通信には適さない、などの理由で、HTTPSで実用に値するのはほぼRSAとECDSAに限られます。 

  2. いっぽうのRSAは、発明した3人(Rivest、Shamir、Adleman)の頭文字を繋いだもので、アルゴリズムの内容とは関係しません。 

  3. ふつうの設定では、「最後の砦」的にRSA+3DESを入れておくことがありますが、ECDSA対応でAES非対応のクライアントは考えづらいので、この場合は入れなくていいでしょう。