そろそろECDSAサーバ証明書を導入してもいいかもしれない
改訂されたTLS暗号設定ガイドラインを読んでいたところ、サーバ証明書の鍵長の要件が変わっていることに気づきました。そこで新しい要件について簡単に整理しています。
TLS暗号設定ガイドライン Ver3.1.0
2024年6月17日にCRYPTERECからTLS暗号設定ガイドラインの Ver3.1.0が公開されました。 このガイドラインで規定されているTLS設定が日本でのデファクトスタンダードになっており、RFPや業界別ガイドラインでもこのガイドラインに適合するよう求められることがあります。
3.1.0では前のバージョンから以下項目が更新されています。
- CRYPTREC暗号リストを2013年発行版から2023年発行版に変更
- 安全性評価尺度の基準を「鍵長」から「ビットセキュリティ」に変更
- 「セキュリティ例外型」の利用停止（「推奨セキュリティ型への移行完了」）を勧告
- 2023年11月時点での情報にアップデート
(TLS設定ガイドライン P4)
安全性評価尺度基準がビットセキュリティになったことで、RSAとECDSAなど異なるアルゴリズムでも同じ尺度で評価できるようになっています。
TLS要求設定について
このガイドラインでは具体的にどんな設定（TLSバージョンや鍵長など）を利用すべきか、求められるセキュリティレベルに応じて以下の3段階提示されています。
| 設定基準 | 概要 |
|---|---|
| 高セキュリティ型 | 情報が漏えいした際、組織の運営や資産、個人の資産やプライバシー等に悪影響を及ぼすと予想される情報を、安全性を優先してTLS通信を行うような場合に採用する設定基準 |
| 推奨セキュリティ型 | 情報が漏えいした際、組織の運営や資産、個人の資産やプライバシー等に悪影響を及ぼすと予想される情報を、安全性確保と利便性（相互接続性）の実現をバランスさせてTLS通信を行うための標準的な設定基準 |
| セキュリティ例外型 | 脆弱なプロトコルバージョンや暗号が使われるリスクを受容したうえで、安全性よりも相互接続性に対する要求をやむなく優先させてTLS通信を行う場合に採用する設定 |
名前の通り、特に理由がなければ「推奨セキュリティ型」を使うべき、とされています。一方で業界によっては業界内ガイドラインで「高セキュリティ型」を要求していることがあります。例えば医療系システム向けの「医療情報システムの安全管理に関するガイドライン第6.0版」では「高セキュリティ型」準拠を要求しています。
高セキュリティ型に追加された要求
高セキュリティ型と推奨セキュリティ型ではサーバ証明書の鍵長について、以下を要求されています。
112ビットセキュリティ*以上を満たす鍵長の RSA、もしくは128ビットセキュリティ以上を満たす曲線の楕円曲線暗号
* 高セキュリティ型の場合には、可能であれば、128ビットセキュリティ以上を満たす鍵長（3072ビット以上）とすること
112ビットセキュリティ、128ビットセキュリティとは具体的には以下の鍵長になります。
| ビットセキュリティ | RSA | ECDSA（楕円曲線暗号） |
|---|---|---|
| 112ビットセキュリティ | 2048bit | 224bit |
| 128ビットセキュリティ | 3072bit | 256bit |
したがって、高セキュリティ型であれば、ECDSAなら256bit以上、RSAなら最低2048bit、可能なら3072bit以上の鍵長が求められます。
したがって、ECDSA 256bit, RSA 3072bitの証明書が利用できるなら積極的に利用していきたいところです。
AWS Certificate Manager(ACM)はRSA 3072bitをサポートしない
AWSでサービスを提供している場合、ACMで証明書を発行することも多いと思います。ACMで発行できる証明書はRSA 2048, ECDSA P256, ECDSA P384の3タイプで、今のところRSA 3072は発行できません。そのため、高セキュリティ型要件の「可能であれば」を満たすためにはECDSA証明書を使わざるを得ません。
Let's Encrypt, ZeroSSLなどRSA3072に対応した他のACME対応CAを使う手もありますが、そのために自動化のシステムを構築するのも面倒です。ACME未対応のCAなら定期的な作業が発生し、しかも対応漏れがあると速障害につながるためなおさらです。
ECDSAの互換性は問題ないのか?
RSAからECDSAに変更するとブラウザの互換性が懸念されますが、これは気にしなくてもよいでしょう。というのも、高セキュリティ型はTLS1.3を、推奨セキュリティ型はTLS1.2を必須としています。ECDSAはTLS1.2よりも実は歴史が長く、TLS1.2を要件としている以上それより歴史が長いECDSAに未対応のクライアントも想定しづらいです。
WikipediaやGlobalSignのサポートページに対応状況が記載されていますが、TLS1.2対応かつECDSA未対応のブラウザはNitendo 3DSやWindowsXP上のChrome48以下など古いものだけなので、ほとんどのケースにおいて問題にはならないでしょう。TLS1.3ならなおさらです。
また、ALBやnginxなど複数の証明書をインストールできる場合は、RSAとECDSA2種類の証明書を利用すれば、万が一TLS1.2対応かつECDSA未対応のクライアントが来ても対応できます。残念ながらCloudFrontは複数証明書をインストールできないので、CloudFrontを使う場合はこの手法が使えません。（CloudFrontが複数証明書に対応してくれるとありがたいのですが）
まとめ（個人的な考え）
今のバージョンでは高セキュリティ型であっても128ビットセキュリティの証明書は義務ではありませんが、将来的に義務になることが予想されます。（112ビットセキュリティは2030年までに128以上に移行すべきとされています）少なくとも「高セキュリティ型」が要求される新規サービスではECDSA P-256を第一選択肢とし、ECDSA未対応ならRSA 3072を選択、それもなければRSA 2048を使うのが妥当かと考えています。既存サービスはアクセスログのUserAgentを分析し、bot以外に未対応クライアントがなければ移行するのがよいかと考えています。
RSA 2048にしか対応しないCAを使っている場合はRSA 2048を使うしかありませんが、なかなか対応しないなら別のCAに引っ越しすることを考えてもよいでしょう。
Discussion