TLS 1.3では、ハンドシェイクメッセージの受け渡しが TLS 1.2から大きく変わり、これは性能へ影響します。このブログシリーズではwolfSSLのTLS 1.2とTLS 1.3の間に見られる性能の違いと、その利点をアプリケーションへ最大限に取り入れる方法について説明しています。今回はその5回目で、証明書ベースのクライアント/サーバー認証におけるTLS 1.3での変更が、性能にどう影響するかを書きます。
下の図は、 証明書を使ったクライアント/サーバー認証を実行するTLS 1.2のフルハンドシェイクです。
TLS 1.3のフルハンドシェイク（HelloRetryRequestなし）では、証明書によるクライアント/サーバーの認証は次のようになります。
TLS 1.2と比較してTLS 1.3では、アプリケーションデータが送信されるまでのハンドシェイクの往復が1つ少なくなっていることがわかります。これにより待ち時間の長いネットワークでの性能は向上しますが、1つ欠点があります。この図ではハンドシェイクメッセージがいつ送信されるかは明確ですが、いつどのように処理されるかがわかりません。
次の図はメッセージの処理と主要な暗号操作を含む TLS 1.2のハンドシェイクを示しています。レイテンシから見て、同じタイミングで実行される操作は同じ行に書かれています。
サーバーはKeyShareを生成し、ServerHelloを送信して、EncryptedExtensions、CertificateRequest、およびCertificateメッセージをすばやく送信します。 時間のかかるCertificateVerifyを実行したら、すぐにFinishedメッセージを返します。クライアントでは時間のかかるKeyShareを実行した後、EncryptedExtensionsおよびCertificateRequestメッセージをすばやく処理し、証明書チェーンの検証を長時間かけて実行します。
通常、CertificateVerifyはチェーンの検証中に到着し、クライアントは残りのメッセージを同期して処理します。その結果、オーバーラップはほとんどありません。
このことから、VerifyがSignに対して非常に高速であるRSAでは、TLS 1.2ハンドシェイクは、Key Gen2回、Secret Gen2回、 Sign1回、および Verify2回の時間に依存することがわかります。VerifyがKey Gen plus Signよりも遅いECDSAの場合、Secret Gen1回と Verify3回の時間に依存することになります。
下の図は、メッセージの処理と主要な暗号操作を含むTLS 1.3ハンドシェイクを表しています。
これから、RSA証明書を使用するTLS 1.3ハンドシェイクは、
Key Gen2回、Sercret Gen1回、 Sign2回に依存することがわかります。
つまりTLS 1.2のSecret Gen1回とVerify2回はSign1回に置き換えられます。
ECDSAを使用すると、ハンドシェイクは Key Gen2回、 Secret Gen1 回、Verify4 回の時間に依存することになります。つまりTLS 1.2のSecret Gen1回とSign1回が、 Verify2回に置き換えられます。
これは低レイテンシのネットワークでは、TLS 1.3がTLS 1.2よりもわずかに遅くなるか、ほぼ同じくらいになることを意味しています。 ECC証明書の唯一の現実的な負荷軽減策は、チェーンの検証で実行される処理量を最小限に抑えることです。サーバー証明書をクライアントまたはクライアント証明書に格納しておくことで、TLS 1.3の性能は向上しますが、セキュリティは低下するリスクがあります。 次のブログでは、TLS 1.2と1.3のスループットの違いについて書きます。
TLS 1.3の性能 その1 – セッション再開
TLS 1.3の性能 その2 – フルハンドシェイク
TLS 1.3の性能 その3 – 事前共有鍵（Pre-Shared Key: PSK）
TLS 1.3の性能 その4 – サーバーでの鍵ペアの事前生成
さらに詳しい情報は弊社問い合わせ窓口info@wolfssl.jpまでお問い合わせください。
原文: https://www.wolfssl.com/tls-1-3-performance-part-5-client-server-authentication/
wolfSSLホーム：www.wolfssl.jp (English：www.wolfssl.com)