跳到主要内容

2. 密钥交换算法 (Key Exchange Algorithm)

本文档为 TLS 定义三种新的基于 ECC 的 key exchange algorithm. 它们都使用 Ephemeral ECDH (ECDHE) 来计算 TLS premaster secret, 彼此只在用于 authentication 的机制 (如果有) 上不同. TLS master secret 从 premaster secret 派生的过程, 以及后续 bulk encryption/MAC key 和 initialization vector 的生成, 都独立于 key exchange algorithm, 不受引入 ECC 的影响.

表 1 概述这些新的 key exchange algorithm. 当且仅当生成并使用新的临时密钥且使用后销毁时, 这些 key exchange algorithm 才提供 forward secrecy.

算法 (Algorithm)描述 (Description)
ECDHE_ECDSA带 ECDSA 或 EdDSA signature 的 Ephemeral ECDH.
ECDHE_RSA带 RSA signature 的 Ephemeral ECDH.
ECDH_anonAnonymous ephemeral ECDH, 无 signature.

表 1: ECC Key Exchange Algorithm

这些 key exchange 分别类似于 DHE_DSS、DHE_RSA 和 DH_anon.

使用 ECDHE_RSA 时, server 可以复用其现有 RSA certificate, 并且容易遵守受限 client 的 elliptic curve 偏好 (参见第 4 节). 然而, 与不提供 forward secrecy 的传统 RSA key exchange 相比, ECDHE_RSA 给 server 带来的计算成本更高.

anonymous key exchange algorithm 不提供对 server 或 client 的 authentication. 与其他 anonymous TLS key exchange 一样, 它容易受到 man-in-the-middle attack. 使用 TLS 和该算法的应用 SHOULD 通过其他方式提供 authentication.

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

               * message is not sent under some conditions
               + message is not sent unless client authentication
                 is desired

图 1: 完整 TLS 1.2 Handshake 中的 Message Flow

图 1 展示 TLS key establishment protocol (即 full handshake) 涉及的所有 message. ECC 的加入只直接影响 ClientHello、ServerHello、server 的 Certificate message、ServerKeyExchange、ClientKeyExchange、CertificateRequest、client 的 Certificate message 以及 CertificateVerify. 接下来, 我们从这些 message 的内容和处理角度更详细地描述 ECC key exchange algorithm. 为便于说明, client authentication 及其相关 message (图 1 中以 "+" 标识) 的讨论推迟到第 3 节, 可选的 ECC-specific extension (影响 Hello message) 的讨论推迟到第 4 节.

2.1. ECDHE_ECDSA​

在 ECDHE_ECDSA 中, server 的 certificate MUST 包含可用于 ECDSA 或 EdDSA 的 public key.

server 在 ServerKeyExchange message 中发送其 ephemeral ECDH public key 以及对应曲线的说明. 这些参数 MUST 使用与 server Certificate 中 public key 对应的 private key 通过 ECDSA 或 EdDSA 签名.

client 在与 server 的 ephemeral ECDH key 相同的曲线上生成 ECDH key pair, 并在 ClientKeyExchange message 中发送其 public key.

client 和 server 都执行 ECDH operation (参见第 5.10 节), 并将得到的 shared secret 用作 premaster secret.

2.2. ECDHE_RSA​

该 key exchange algorithm 与 ECDHE_ECDSA 相同, 只是 server 的 certificate MUST 包含被授权用于签名的 RSA public key, 且 ServerKeyExchange message 中的 signature 必须使用对应的 RSA private key 计算.

2.3. ECDH_anon​

注意: 尽管名称以 "ECDH_" 开头 (没有 E), ECDH_anon 中使用的 key 与 ECDHE_RSA 和 ECDHE_ECDSA 中的 key 一样是临时的. 这种命名沿用 DH_anon 的例子, 其中 key 也是临时的, 但名称未反映这一点.

在 ECDH_anon 中, server 的 Certificate、CertificateRequest、client 的 Certificate 和 CertificateVerify message MUST NOT 发送.

server MUST 在 ServerKeyExchange message 中发送 ephemeral ECDH public key 以及对应曲线的说明. 这些参数 MUST NOT 被签名.

client 在与 server 的 ephemeral ECDH key 相同的曲线上生成 ECDH key pair, 并在 ClientKeyExchange message 中发送其 public key.

client 和 server 都执行 ECDH operation, 并将得到的 shared secret 用作 premaster secret. 所有 ECDH 计算均按第 5.10 节规定执行.

2.4. Certificate Chain 中的算法​

本规范不对 certificate chain 中任何位置使用的 signature scheme 施加限制. 本文档的上一版本要求 signature 匹配, 但该限制源自早期 TLS 版本, 此处像 RFC 5246 中一样将其取消.

最后于 更新