TLS 1.3では、性能を重視し大幅な変更がTLS 1.2から加えられています。このブログシリーズではwolfSSLのTLS 1.2とTLS 1.3の間に見られる性能の違いと、その利点をアプリケーションへ最大限に取り入れる方法について説明します。今回はその4回目で、ハンドシェイクが始まる前に鍵ペアをサーバーで生成しておく方法について説明します。
このシリーズの最初のブログで触れましたが、TLS 1.3の鍵交換にかかる負荷は軽減する方法があります。どの鍵交換アルゴリズムが使用されるかをサーバーが知っている場合、wolfSSL_UseKeyShare（）を呼び出しておくことで、TCP / IP接続を受け入れた後サーバーで鍵ペアを先に生成しておくことが可能です。両方のエンドポイントが同じ当事者によって管理される場合は、鍵交換アルゴリズムのようなセキュリティパラメータの選択は前もって行われ、その事実を利用することができるのです。
サーバーに直接接続する場合、通常、クライアントはTCP / IP接続が確立されてからClientHelloの作成を開始します。サーバーは接続を受け入れ、クライアントが共有鍵を生成してClientHelloメッセージを送信するのを待ちます。この間に、サーバーも鍵ペアを生成することが可能なのです。
鍵交換にDHを使用する場合、鍵生成の処理が重いため、この方法は大幅な負荷軽減になります。 たとえば、サーバー認証にRSAを使用し同じコンピュータ上でクライアントとサーバーの両方を実行する場合、接続は約20％高速になります。サーバー認証にセッション再利用またはPSKを使用する場合は、約30％高速です。サーバー認証にECDHとECDSAを使用する接続の場合は約4％だけ速くなり、サーバー認証にセッション再利用またはPSKを使用する場合で約7％速くなります。 楕円曲線鍵生成は、最適化された実装では非常に高速であり、負荷軽減の効果はそれほどでません。
サーバーは現在、複数の接続間で一時的鍵ペア(Ephemeral Key Pair)を再利用しています。 1日に1回から1時間に1回までの間隔で、鍵ペアを再生成するのが一般的です。この方法は、サーバーでの事前鍵生成の代わりに使用できますが、サーバーの完全前方秘匿性を犠牲にしています。
もし許容できるアーキテクチャならば、接続を受け入れた後に鍵ペアを生成するようサーバーを実装すべきです。DH系ではこれは十分に価値があります。ECDHの場合でも、わずかな 性能の向上が、1秒あたりの接続数を増やすことにつながります。
次のブログでは、クライアント/サーバー認証を実行するハンドシェイクの性能の問題について書きます。
TLS 1.3の性能 その1 – セッション再開
TLS 1.3の性能 その2 – フルハンドシェイク
TLS 1.3の性能 その3 – 事前共有鍵（Pre-Shared Key: PSK）
さらに詳しい情報は弊社問い合わせ窓口info@wolfssl.jpまでお問い合わせください。
原文: https://www.wolfssl.com/tls-1-3-performance-part-4-server-pre-generation/
wolfSSLホーム：www.wolfssl.jp (English：www.wolfssl.com)