TLS キーのサイズが大きいほど良いとは言えない理由 | Fastly

トランスポートレイヤーセキュリティ (TLS) の設定には、複雑な選択を伴うことがあります。サーバー証明書で使用される暗号化キーのサイズ (ビット数) もそのひとつです。一般的な2048ビットではなく、4096ビットの RSA キーを選択することは、今日暗号化された情報を今後何年にもわたって保護する必要がある場合は特に、堅実な方法であるように思えるかもしれません。実はこの選択肢がそれほど単純ではない理由を説明するには、TLS 証明書の機能と TLS による暗号化処理について理解する必要があります。それでは詳しく見ていきましょう。

TLS プロトコルのすべてのバージョンにおいて、証明書は非常に特殊な役割を担います。Webサイトのホスト名を検証する際に使用され、トランジット中のデータを保護するセッションキーの作成を容易にします。つまりデータ保護において、セッションキーの強度は少なくとも証明書のキーと同等の重要性があるということです。

セッションキーの強度は、TLS 接続を確立する際にブラウザと Web サーバー間で合意される「暗号スイート」により決まります。暗号スイートは、セッションキーの確立に使用されるメソッドも定義します。前方秘匿性 (FS) は証明書の秘密鍵がセッションキーの回復に使用されないことを保証する、最新のキー合意メカニズムの特性です。FS を提供するキー合意メカニズムが使用されている場合、証明書が提示する漏洩したキーを使って古いセッションキーを再作成することはできません。暗号化された TLS データが長期間保存されている場合でも、証明書のキーの解読によってデータが漏洩することはありません。つまり、Web サーバーが侵害されても、それ以前に送信された TLS トラフィックを攻撃者が解読することはできないのです。 

デフォルトでは、Fastly CDN は、ブラウザで FS がサポートされている場合に FS を使用するよう設定されています。FS 暗号スイートのみを許可する最新バージョンのプロトコルである TLS 1.3 を使用して接続するよう要求するか、または TSL のカスタム設定を要求することで FS を確保できます。

アメリカ国立標準技術研究所 (NIST) は定期的に暗号化アルゴリズムの使用に関する推奨事項を公開しています。NIST はさまざまな種類のアルゴリズムが提供する保護レベルを「セキュリティビット数」で定義しています。NIST は、2030年まではデータの保護に最低112ビットのセキュリティ強度を持つキーを使い、その後は128ビットのセキュリティ強度を使用することを推奨しています。2048ビットの RSA キーのセキュリティビット数は112ビットです。TLS 証明書が最大1年間有効であることを考えると、2048ビットの RSA キーの長さは2020年代後半まで NIST の推奨を満たします。また、PCI DSS では「強度の高い暗号化」の使用が要求されており、これは現在 RSA では2048ビット、また ECC では224ビット (あるいはそれ以上) の鍵長を持つ暗号化キーとして定義されています。

サイズの大きい4096ビットの RSA キーは必要ないとしても、使用することにデメリットはあるのでしょうか。その答えはパフォーマンスへの影響です。長いキーは、サーバーとクライアントの双方においてより長い計算時間を必要とします。Fastly のサーバーでは、最近、2048ビットの検証処理が4096ビットの RSA キーの検証と比較して4倍速く完了したことが測定されました。この影響に加え、4096ビットの RSA サーバーと中間証明書を使用する際にクライアントに送信する必要のある追加データのことを考えると、パフォーマンスに対してわずかながらも実際に影響が及ぶことが分かります。毎年証明書を更新する際に、より小さいキーを選択することで、強度がさらに高いキーを使用する時期が訪れるまで優れたパフォーマンスを維持することができます。

この問題へのさらに効果的な対策としては、RSA キーから ECDSA キーへの切り替えが挙げられます。ECDSA は RSA と異なる数学的構造を使用しているので、RSA よりも短い鍵長で強力なレベルの保護を可能にします。256ビットの ECDSA キーは、128ビットのセキュリティ (3072ビットの RSA キーと同等の強度) を提供します。Fastly は現在 ECDSA 証明書をサポートしているので、4096ビットの RSA キーを使用する証明書により得られるセキュリティの向上とパフォーマンスをトレードオフする必要がなくなりました。比較的新しい暗号化アルゴリズムである (1990年代に生まれた) ECDSA に移行することに懸念がある方は、最近の業界の動向を確認してみてください。例えば最近 Google.com にアクセスしたところ、ECDSA 証明書が返されました。

まとめると、Web サーバーの設定は、現在および将来にわたって、TLS を介して送受信するデータを保護する上で重要な役割を担います。これには、セキュリティと、TLS 1.3 をサポートしていない古いクライアントにおける互換性との間の、潜在的なトレードオフが含まれます。Mozilla はこうしたトレードオフを考慮した推奨設定を公開しています。TLS のサーバー証明書において、現在セキュリティとパフォーマンスの両方において最適なのは2048ビットの RSA キーまたは 256ビットの ECDSA キーです。より大きなキーを選択する前に、証明書の役割やパフォーマンスへの影響を検討しましょう。