メインコンテンツまでスキップ

2. 鍵交換アルゴリズム

本文書は、TLS のための3つの新しい ECC ベースの鍵交換アルゴリズムを定義する。これらはすべて、TLS プリマスターシークレットを計算するために Ephemeral ECDH (ECDHE) を使用し、それらを認証するために使用されるメカニズム（もしあれば）のみが異なる。プリマスターシークレットからの TLS マスターシークレットの導出、およびその後のバルク暗号化/MAC 鍵と初期化ベクトルの生成は、鍵交換アルゴリズムとは独立しており、ECC の導入による影響を受けない。

表1に新しい鍵交換アルゴリズムをまとめる。これらの鍵交換アルゴリズムはすべて、新鮮な一時鍵が生成・使用され、使用後に破棄される場合に限り、前方秘匿性 (forward secrecy) を提供する。

アルゴリズム説明
ECDHE_ECDSAECDSA または EdDSA 署名付きの一時 ECDH。
ECDHE_RSARSA 署名付きの一時 ECDH。
ECDH_anon匿名の一時 ECDH、署名なし。

表 1: ECC 鍵交換アルゴリズム

これらの鍵交換は、それぞれ DHE_DSS、DHE_RSA、および DH_anon に類似している。

ECDHE_RSA を使用すると、サーバは既存の RSA 証明書を再利用でき、制約のあるクライアントの楕円波線の好みに容易に準拠できる（セクション4を参照）。ただし、サーバが ECDHE_RSA で負担する計算コストは、前方秘匿性を提供しない従来の RSA 鍵交換よりも高くなる。

匿名鍵交換アルゴリズムは、サーバまたはクライアントの認証を提供しない。他の匿名 TLS 鍵交換と同様に、中間者攻撃に対して脆弱である。このアルゴリズムを使用する TLS アプリケーションは、他の手段によって認証を提供すべきである (SHOULD)。

          Client                                        Server
          ------                                        ------
          ClientHello          -------->
                                                   ServerHello
                                                  Certificate*
                                            ServerKeyExchange*
                                          CertificateRequest*+
                               <--------       ServerHelloDone
          Certificate*+
          ClientKeyExchange
          CertificateVerify*+
          [ChangeCipherSpec]
          Finished             -------->
                                            [ChangeCipherSpec]
                               <--------              Finished
          Application Data     <------->      Application Data

               * 条件によっては送信されないメッセージ
               + クライアント認証が望まれる場合を除き送信されないメッセージ

図 1: 完全な TLS 1.2 ハンドシェイクにおけるメッセージフロー

図1は、TLS 鍵確立プロトコル（別名：フルハンドシェイク）に関与するすべてのメッセージを示している。ECC の追加は、ClientHello、ServerHello、サーバの Certificate メッセージ、ServerKeyExchange、ClientKeyExchange、CertificateRequest、クライアントの Certificate メッセージ、および CertificateVerify にのみ直接的な影響を与える。次に、これらのメッセージの内容と処理の観点から、ECC 鍵交換アルゴリズムについてより詳細に説明する。説明を容易にするため、クライアント認証と関連メッセージ（図1で '+' で識別）の議論はセクション3まで、オプションの ECC 固有の拡張（Hello メッセージに影響を与える）の議論はセクション4まで延期する。

2.1. ECDHE_ECDSA​

ECDHE_ECDSA では、サーバの証明書は ECDSA または EdDSA 能力を持つ公開鍵を含まなければならない (MUST)。

サーバは、ServerKeyExchange メッセージで一時 ECDH 公開鍵と対応する曲線の仕様を送信する。これらのパラメータは、サーバの証明書に含まれる公開鍵に対応する秘密鍵を使用して、ECDSA または EdDSA で署名されなければならない (MUST)。

クライアントは、サーバの一時 ECDH 鍵と同じ曲線上で ECDH 鍵ペアを生成し、ClientKeyExchange メッセージでその公開鍵を送信する。

クライアントとサーバの両方が ECDH 演算（セクション5.10を参照）を実行し、結果として得られた共有シークレットをプリマスターシークレットとして使用する。

2.2. ECDHE_RSA​

この鍵交換アルゴリズムは、サーバの証明書が署名用に認可された RSA 公開鍵を含まなければならず (MUST)、ServerKeyExchange メッセージ内の署名が対応する RSA 秘密鍵で計算されなければならない点を除き、ECDHE_ECDSA と同じである。

2.3. ECDH_anon​

注：名前が "ECDH_" で始まっている（Eがない）にもかかわらず、ECDH_anon で使用される鍵は、ECDHE_RSA や ECDHE_ECDSA の鍵と同様に一時的 (ephemeral) である。この命名は DH_anon の例に倣ったものであり、そこでも鍵は一時的であるが、名前には反映されていない。

ECDH_anon では、サーバの Certificate、CertificateRequest、クライアントの Certificate、および CertificateVerify メッセージを送信してはならない (MUST NOT)。

サーバは、ServerKeyExchange メッセージで一時 ECDH 公開鍵と対応する曲線の仕様を送信しなければならない (MUST)。これらのパラメータは署名されてはならない (MUST NOT)。

クライアントは、サーバの一時 ECDH 鍵と同じ曲線上で ECDH 鍵ペアを生成し、ClientKeyExchange メッセージでその公開鍵を送信する。

クライアントとサーバの両方が ECDH 演算を実行し、結果として得られた共有シークレットをプリマスターシークレットとして使用する。すべての ECDH 計算は、セクション5.10で規定されているように実行される。

2.4. 証明書チェーン内のアルゴリズム​

本仕様は、証明書チェーンのどこかで使用される署名スキームに制限を設けない。本文書の以前のバージョンでは署名が一致することを要求していたが、以前の TLS バージョンに由来するこの制限は、RFC 5246 と同様にここでは解除されている。

に最終更新