概要

OpenSSL 3.5 には、将来の量子コンピュータによる攻撃に耐性を持つ複数のアルゴリズムが統合されています。これらは一般に ポスト量子暗号や耐量子計算機暗号(PQC: Post-Quantum Cryptography) と呼ばれ、以下が含まれます。

  • 鍵交換アルゴリズム
  • TLS ハンドシェイク署名アルゴリズム
  • 公開鍵証明書アルゴリズム

大量の TLS 暗号化通信を今のうちに保存し、将来量子コンピューターが十分に高性能になった時点で復号する、という可能性は現実的な問題と考えられており、各国政府や標準化団体は量子安全な暗号への移行を求めています。

MySQL 26.7.0 以降、MySQL では OpenSSL 3.5 以降によって提供される PQC(ポスト量子暗号)対応の TLS アルゴリズムを利用できるようになりました。初期サポートでは TLSv1.3 接続に焦点を当てており、PQC 対応の鍵交換、PQC 対応の TLS ハンドシェイク署名アドバタイズメント(TLSハンドシェイク時にクライアント/サーバー間で使用可能な署名アルゴリズムを提示する機能)、および選定された TLS アルゴリズムのオブザーバビリティ(どのアルゴリズムが実際に採用されたかをログやステータス変数等で確認できる機能)に対応しています。

対象範囲

MySQL が OpenSSL 3.5 以降でビルドされている場合、TLSv1.3 接続では、従来型の手段をデフォルトで有効にしたまま、PQC 対応の鍵交換グループを優先できます。これにより、古いクライアントを損なうことなく、新しいクライアントは PQC 対応鍵交換を決定できます。

この機能は、以下の TLS チャネルに適用されます。

  • クライアント・サーバー接続
  • 管理用接続
  • 非同期レプリケーション
  • グループレプリケーションのリカバリ
  • グループレプリケーションのグループ間チャンネル(MySQL スタックのみ)
  • X Plugin接続

Group Replication の XCom スタックは対象外です。

PQC 対応の TLS ハンドシェイク署名アルゴリズムは、オプトイン機能としてサポートされます。これを有効にしても、MySQL が TLS ハンドシェイク中に何を広告または許可するかを制御するだけであり、PQC 証明書を生成したり、ディスク上に PQC 証明書が必要になったりするわけではありません。

設定

MySQL は、サポートされる各チャネルに対して3つの設定ファミリーを公開します :

設定ファミリー目的デフォルト値
force_pqcPQC 対応の鍵交換グループをネゴシエートしない新しい TLS セッションを拒否するOFF
use_pqc_sign従来のフォールバックアルゴリズムより前に、PQC 対応の TLS ハンドシェイク署名アルゴリズムを提示するOFF
tls_kexTLS 鍵交換グループの正確なコロン区切りの許可リストを構成する空(MySQL の既定順序を使用)

各チャネルには、それぞれ対応する変数とコマンドラインオプションがあります。

例:

  • force_pqc, admin_force_pqc, replication_force_pqc, group_replication_force_pqc, mysqlx_force_pqc
  • use_pqc_sign, admin_use_pqc_sign, replication_use_pqc_sign, group_replication_use_pqc_sign, mysqlx_use_pqc_sign
  • tls_kex, admin_tls_kex, replication_tls_kex, group_replication_tls_kex, mysqlx_tls_kex

クライアントプログラムも --force-pqc--use-pqc-sign--tls-kex をサポートします。対応する C API オプションは MYSQL_OPT_FORCE_PQCMYSQL_OPT_USE_PQC_SIGNMYSQL_OPT_TLS_KEX です。

サポートされる鍵交換グループ

デフォルトの優先順位では、まず イブリッド PQC グループ、その次に純粋な ML-KEM グループ、最後に従来のフォールバックグループです。

アルゴリズム種別
X25519MLKEM768ハイブリッドPQC (X25519 + ML-KEM-768)
secp384r1MLKEM1024ハイブリッドPQC (P-384 + ML-KEM-1024)
secp256r1MLKEM768ハイブリッドPQC (P-256 + ML-KEM-768)
MLKEM512ピュア ML-KEM-512
MLKEM768ピュア ML-KEM-768
X25519従来のフォールバック
secp384r1従来のフォールバック
secp256r1従来のフォールバック
secp521r1従来のフォールバック

名前は大文字と小文字が区別されます。MySQL は tls_kex の許可リストに対して、ドキュメントに記載された名前のみを受け入れます。

例:

[mysqld]
tls_kex=X25519MLKEM768:secp384r1MLKEM1024:X25519

メインのクライアントチャネルで PQC 対応鍵交換 を必須にするには、次のように設定します。

[mysqld]
tls_version=TLSv1.3
force_pqc=ON

厳格な PQC を有効にするのは、必要なすべてのクライアントとサーバーで検証を終えてからにしてください。古いクライアント、TLSv1.2 のみの相手先、または必要な PQC グループを持たない TLS ライブラリを使う相手先は、厳格な PQC チャネルには接続できません。

PQC ハンドシェイク署名

MySQL が PQC 対応の TLS ハンドシェイク署名アルゴリズムを提示(アドバタイズ)できるようにするには、以下の設定を使用します:

[mysqld]
use_pqc_sign=ON

この設定を有効にすると、MySQL は従来方式のフォールバックアルゴリズムより前に ML-DSA-44、ML-DSA-65、ML-DSA-87 を提示できるようになります。ただし、最終的にネゴシエート(決定)される署名アルゴリズムは、接続相手(ピア)、TLS ライブラリ、プロバイダ設定、および利用可能な証明書によって決まります。

可観測観測性

ネゴシエートされた TLS アルゴリズムを確認するためのセッションステータス変数が追加されています :

SHOW SESSION STATUS LIKE 'Tls_key_exchange_algorithm';
SHOW SESSION STATUS LIKE 'Tls_sign_algorithm';

既存の暗号スイート用ステータス変数も引き続き使用可能です:

SHOW SESSION STATUS LIKE 'Ssl_cipher';

メイン接続および管理用(admin)接続チャンネルの場合、performance_schema.tls_channel_status テーブルから以下のような現在の PQC 関連チャンネル設定を確認できます:

  • Force_pqc
  • Use_pqc_sign
  • Tls_kex

X Plugin については、以下の有効なステータス変数を使用します:

SHOW GLOBAL STATUS LIKE 'Mysqlx_force_pqc';
SHOW GLOBAL STATUS LIKE 'Mysqlx_tls_kex';
SHOW GLOBAL STATUS LIKE 'Mysqlx_use_pqc_sign';

なお、接続が TLS を使用していない場合、TLS セッションが再開(再利用)された場合、またはリンクされている TLS ライブラリが必要な情報を開示・提供していない場合は、ネゴシエーションされたアルゴリズムの値が空(Empty)になることがあります。

導入ガイダンス

ほとんどの導入環境では、まずデフォルトの動作から始めることを推奨します。つまり、従来のフォールバック方式を維持したまま、MySQL が PQC 対応の鍵交換を優先的に使用できるように設定します。

より厳しい制限設定(セキュリティ強化)を行う場合は、以下の段階を踏んで適用してください:

  • MySQL が OpenSSL 3.5 以降でビルド・リンクされていることを確認する
  • 該当するチャンネルで TLSv1.3 が許可されていることを確認する
  • 互換性の検証中は force_pqc を OFF のままにしておく
  • 新しく追加されたステータス変数を使用して、実際にネゴシエートされたアルゴリズムを確認する
  • プロバイダ、証明書、およびパフォーマンスへの影響を評価したうえで、 use_pqc_sign を有効にする
  • 接続を必要とするすべてのピア(クライアントや対向ノード)が PQC 対応の TLSv1.3 鍵交換を行えることを確認できたチャンネルにのみ、force_pqc を有効にする

各オプションの詳細な説明、チャンネルごとの固有の動作、およびトラブルシューティングの手段については、MySQL の公式ドキュメントを参照してください。

まとめ

MySQL の PQC TLS サポートにより、データベース管理者は実践的な移行アプローチをとることが可能になります。デフォルトでは量子安全な鍵交換を優先しつつ、必要な箇所では既存システムとの互換性を保持し、環境の準備が整った段階で厳格な PQC ポリシーを適用していくことができます。

MySQL をご愛用いただき、ありがとうございます!