TLS暗号設定ガイドライン Ver. 3.1.0でECDHEに関する変更部分が気になったので調べた

執筆開始時はVer.3.1.0が最新でしたが、2025年4月25日にVer.3.1.1（主に誤記の修正）が発行されました。

TLS暗号設定ガイドラインについて

TLS暗号設定ガイドラインとは、IPAによって公開されているTLSサーバの構築者や運営者が適切なセキュリティを考慮した暗号設定ができるようにするためのガイドラインです。
セキュリティとユーザビリティとのトレードオフを考慮した以下の3つの設定基準があり、設定確認のためのExcel形式のチェックリストも用意されています。

• 高セキュリティ型
• 推奨セキュリティ型
• セキュリティ例外型

先週受験したR7春の情報処理安全確保支援士試験の午後問題で「推奨セキュリティ型」に関する出題がありました。また、TLSハンドシェイクのシーケンスの穴埋め問題も出題されたので次回挑む際には本ドキュメントが必読となるかもしれません。

高セキュリティ型のECDHEの遵守事項が変わった

ECDHEとは？

楕円曲線ディフィー・ヘルマン鍵共有（ECDH）の公開鍵を一時的（ephemeral）にしたものをECDHEと略記します。
DHについて詳しくは、以下の動画が図解もあってわかりやすかったです。

どこが変わった？

チェックリストの中のECDHEに関する遵守事項が以下のように変更されました。

Version	チェック項目
Ver.3.0.1	ECDHEの鍵長を256ビット以上にしたか
Ver.3.1.0	ECDHEを128ビットセキュリティ以上の曲線にしたか（P-256やCurve25519など）

鍵長とビットセキュリティとは、それぞれ以下の通りです。

鍵長

• 暗号アルゴリズムで使用される鍵の長さ

ビットセキュリティ

• 暗号を破るために必要な計算量
• 異なる技術分類の暗号アルゴリズムの安全性の目安にすることが可能

そもそも調べたきっかけ

CloudFrontのセキュリティポリシーの設定

業務でチェックリストの項目を確認する必要があり、セキュリティ要件上は当時最新だったVer3.0.1を参照していました。(Ver.3.1.0が発行されたのは2024年6月17日)
確認対象のシステムではAmazon CloudFrontを使用しており、CloudFrontではセキュリティポリシーを設定することで、通信許可する暗号スイートを選択します。
詳しくは以下の公式ドキュメントを参照してください。

2025年5月現在ではもっとも強固な「TLSv1.2_2021」を採用していました。

鍵長の確認

公式ドキュメントには鍵長についての情報がなかったためサポートに問い合わせたところ、testssl.shを使用して確認するようご返信をいただきました。

以下が実行結果の一部分となります。

 Running client simulations (HTTP) via sockets

 Browser                      Protocol  Cipher Suite Name (OpenSSL)       Forward Secrecy
------------------------------------------------------------------------------------------------
 Android 6.0                  TLSv1.2   ECDHE-ECDSA-AES128-GCM-SHA256     256 bit ECDH (P-256)
 Android 7.0 (native)         TLSv1.2   ECDHE-ECDSA-AES128-GCM-SHA256     256 bit ECDH (P-256)
 Android 8.1 (native)         TLSv1.2   ECDHE-ECDSA-AES128-GCM-SHA256     253 bit ECDH (X25519)
 Android 9.0 (native)         TLSv1.3   TLS_AES_128_GCM_SHA256            253 bit ECDH (X25519)
 Android 10.0 (native)        TLSv1.3   TLS_AES_128_GCM_SHA256            253 bit ECDH (X25519)
 Android 11 (native)          TLSv1.3   TLS_AES_128_GCM_SHA256            253 bit ECDH (X25519)
 Android 12 (native)          TLSv1.3   TLS_AES_128_GCM_SHA256            253 bit ECDH (X25519)
 Chrome 79 (Win 10)           TLSv1.3   TLS_AES_128_GCM_SHA256            253 bit ECDH (X25519)
 Chrome 101 (Win 10)          TLSv1.3   TLS_AES_128_GCM_SHA256            253 bit ECDH (X25519)
 Firefox 66 (Win 8.1/10)      TLSv1.3   TLS_AES_128_GCM_SHA256            253 bit ECDH (X25519)
 Firefox 100 (Win 10)         TLSv1.3   TLS_AES_128_GCM_SHA256            253 bit ECDH (X25519)
 IE 6 XP                      No connection
 IE 8 Win 7                   No connection
 IE 8 XP                      No connection
 IE 11 Win 7                  TLSv1.2   ECDHE-ECDSA-AES128-GCM-SHA256     256 bit ECDH (P-256)
 IE 11 Win 8.1                TLSv1.2   ECDHE-ECDSA-AES128-GCM-SHA256     256 bit ECDH (P-256)
 ・
 ・
 ・

Forward Secrecyの欄に「253bit ECDH (X25519)」の記述があります。当時はこの記述を見て鍵長が253bitであると理解していましたが、改めて調べたところ自信が無くなったのでご存じの方がいたら教えてください m(_ _)m

最新バージョンが出てることに気づく

X25519が遵守していない（と理解していた）ことから、少し焦りつつ改めてTLS暗号設定ガイドラインを確認しに行きました。公式サイトから改めてチェックリストを確認したところ最新バージョンがすでに出ており、上記の変更点に気づくことができました。
X25519は128ビットセキュリティを提供しているため、最新のガイドラインに遵守しているというわけです。

変更理由

TLS暗号設定ガイドラインの修正履歴に以下の記述がありました。

安全性評価尺度の基準を「鍵長」から「ビットセキュリティ」に変更

鍵長は長ければ長いほど安全性を高めることができますが、同時に処理時間や消費リソース等が課題にかかるようになり、実用性を損なうことがあります。
それに対し、ビットセキュリティは特定のアルゴリズムがどれだけの計算力を必要とするかを具体的に示すことができます。
そのため、暗号アルゴリズムの安全性の指標として採用されたと考えられます。

余談ですがX25519はVer.3.1.0のチェック項目に明示的に記載のあったCurve25519を使用したアルゴリズムです。

最後に

ちょっとした疑問から理解を深めようと調べ始めたことが本記事執筆のきっかけですが、暗号分野の歴史や今後の展望についても知ることができ、さらに興味を持ちました。支援士試験にもTLSに関する出題がいくつかあったので、今後もさらに勉強していきます。