摘要
本文档介绍了基于传输层安全（TLS）协议的椭圆曲线密码术（ECC）的新密钥交换算法。
特别地，它规定了在TLS握手中使用椭圆曲线Diffie-Hellman（ECDH）密钥协商，
并使用椭圆曲线数字签名算法（ECDSA）作为新的认证机制。
1.介绍
椭圆曲线密码学（ECC）正在成为有吸引力的公钥密码系统，特别是对于移动（即无线）环境。
与目前流行的密码系统（如RSA）相比，ECC具有密钥较小的等效安全性。
这在下表中给出，基于[18]，其基于用于攻击它们的最知名的算法给出对称和非对称密钥密码系统的近似可比的密钥大小。
Symmetric | ECC | DH/DSA/RSA
------------+---------+-------------
80 | 163 | 1024
112 | 233 | 2048
128 | 283 | 3072
192 | 409 | 7680
256 | 571 | 15360
Table 1: Comparable Key Sizes (in bits)
更小的密钥大小可以节省功率，内存，带宽和计算成本，使得ECC对受限的环境特别有吸引力。
本文档介绍了TLS的补充，以支持ECC，适用于TLS版本1.0 [2]和TLS版本1.1 [3]。特别地，它定义
o使用具有长期或短暂密钥的椭圆曲线Diffie-Hellman（ECDH）密钥协商方案来建立TLS预制密钥，以及
o使用固定ECDH证书和ECDSA来验证TLS对等体。
本文档的其余部分组织如下。
第2节概述了基于ECC的TLS密钥交换算法。
第3节描述了使用ECC证书进行客户端身份验证。
第4节描述了允许客户端协商使用特定曲线和点格式的TLS扩展。
第5节规定了基于ECC的握手所需的各种数据结构，其在TLS消息中的编码以及这些消息的处理。
第6节定义了新的基于ECC的密码套件，并根据本规范的所有实现来推荐使用这些套件。
第7节讨论安全考虑。
第8节描述了本文档创建的名称空间的IANA注意事项。
第9节为致谢。
其次是本文件引用的规范和参考资料，作者的联系信息以及知识产权和版权声明。
本规范的实现需要熟悉TLS [2] [3]，TLS扩展[4]和ECC [5] [6] [7] [11] [17]。
本文档中的关键词“必须”，“必须”，“必需”，“应该”，“不应该”，“应该”，“不应该”，“推荐”，“可能”和“可选”如RFC 2119 [1]所述。
2.密钥交换算法
本文介绍了TLS的五种新的基于ECC的密钥交换算法。
所有这些都使用ECDH来计算TLS预主保密，并且它们仅在ECDH密钥（长期或短暂）的生命周期以及用于认证它们的机制（如果有的话）中有所不同。
从主机秘密推导TLS主密钥，随后生成批量加密/ MAC密钥和初始化向量与密钥交换算法无关，不受引入ECC的影响。
（译注：这里应该表达的是主秘钥导出、生成密码块、生成iv三类使用的方法和秘钥交换无关，即不受ecc的影响)
下表总结了分别模仿DH_DSS，DHE_DSS，DH_RSA，DHE_RSA和DH_anon的新的密钥交换算法（参见[2]和[3]）。
Key
Exchange
Algorithm Description
--------- -----------
ECDH_ECDSA Fixed ECDH with ECDSA-signed certificates.
ECDHE_ECDSA Ephemeral ECDH with ECDSA signatures.
ECDH_RSA Fixed ECDH with RSA-signed certificates.
ECDHE_RSA Ephemeral ECDH with RSA signatures.
ECDH_anon Anonymous ECDH, no signatures.
Table 2: ECC Key Exchange Algorithms
ECDHE_ECDSA和ECDHE_RSA密钥交换机制提供了前瞻性的保密。
使用ECDHE_RSA，服务器可以重用其现有的RSA证书，并且很容易符合约束客户端的椭圆曲线偏好（参见第4节）。
然而，对于ECDHE_RSA而言，服务器所产生的计算成本比传统的RSA密钥交换更高，这(传统的RSA密钥交换)不提供前向保密。
ECDH_RSA机制要求服务器获取ECC证书，但证书颁发者仍然可以使用现有的RSA密钥进行签名。
这样就不需要更新TLS客户端接受的可信认证机构的密钥。
ECDH_ECDSA机制需要服务器和证书颁发机构的ECC密钥，最适合于无法支持RSA的受限设备。
匿名密钥交换算法不提供服务器或客户端的认证。
像其他匿名TLS密钥交换一样，它受到中间人攻击。
该算法的实现应该通过其他方式提供认证。
请注意，ECDH和ECDSA密钥之间没有结构上的差异。
证书颁发者可以使用X.509 v3 keyUsage和extendedKeyUsage扩展来限制使用ECC公钥进行某些计算[15]。
本文件将ECC秘钥作为ECDH功能，如果允许使用ECDH的话。类似地定义了ECDSA能力。
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
Figure 1: Message flow in a full TLS handshake
图1显示了TLS密钥建立协议（也称为完全握手）中涉及的所有消息。
ECC的添加只对ClientHello，ServerHello，服务器的证书消息，ServerKeyExchange，ClientKeyExchange，
CertificateRequest，客户端的证书消息和CertificateVerify有直接影响。
接下来，我们在这些消息的内容和处理方面更详细地描述每个ECC密钥交换算法。
为了便于说明，我们推迟讨论客户端认证和相关消息（在图1中用+标识），直到第3节和可选的ECC特定扩展（影响Hello消息）直到第4节。
2.1. ECDH_ECDSA
在ECDH_ECDSA中，服务器的证书必须包含一个ECDH能力的公共密钥，并使用ECDSA进行签名。
不能发送ServerKeyExchange（(译注：因为）服务器的证书包含客户端到达前端密码所需的所有必需的密钥信息）。
客户端在与服务器的长期公钥相同的曲线上生成一个ECDH密钥对，并将其公钥发送到ClientKeyExchange消息中
（除了使用客户端认证算法ECDSA_fixed_ECDH或RSA_fixed_ECDH，在这种情况下，第3.2节或第3.3节 应用）。
客户端和服务器都执行ECDH操作，并使用最终的共享密钥作为预。 所有ECDH计算都按第5.10节所述进行。
2.2. ECDHE_ECDSA
在ECDHE_ECDSA中，服务器的证书必须包含具有ECDSA能力的公共密钥，并使用ECDSA进行签名。
服务器在ServerKeyExchange消息中发送其临时ECDH公钥和相应曲线的规范。
必须使用ECDSA使用服务器证书中的公钥对应的私钥对这些参数进行签名。
客户端在与服务器的短暂ECDH密钥相同的曲线上生成ECDH密钥对，并将其公钥发送到ClientKeyExchange消息中。
客户端和服务器都执行ECDH操作（第5.10节），并使用最终的共享密钥作为预主秘钥。
2.3。 ECDH_RSA
该密钥交换算法与ECDH_ECDSA相同，只是服务器的证书必须使用RSA而不是ECDSA进行签名。
2.4。 ECDHE_RSA
该密钥交换算法与ECDHE_ECDSA相同，只是服务器的证书必须包含授权签名的RSA公钥，并且必须使用相应的RSA私钥计算ServerKeyExchange消息中的签名。服务器证书必须使用RSA进行签名。
2.5。 ECDH_anon
在ECDH_anon中，不得发送服务器的证书，CertificateRequest，客户端证书和CertificateVerify消息。
服务器必须在ServerKeyExchange消息中发送临时的ECDH公钥和相应曲线的规范。这些参数不得签名。
客户端在与服务器的临时ECDH密钥相同的曲线上生成ECDH密钥对，并将其公钥发送到ClientKeyExchange消息中。
客户端和服务器都执行ECDH操作，并使用最终的共享密钥作为预主秘钥。所有ECDH计算都按第5.10节所述进行。
请注意，虽然ECDH_ECDSA，ECDHE_ECDSA，ECDH_RSA和ECDHE_RSA密钥交换算法要求服务器的证书使用特定的签名方案进行签名，
但本规范（遵循[2]和[3]中的DH_DSS，DHE_DSS，DH_RSA和DHE_RSA的类似情况）不对证书链中其他地方使用的签名方案施加限制。
（通常这种限制将是有用的，并且被期望在认证机构的签名实践中将考虑到这一点。
但是这些限制并不是一般性的要求：即使超出客户完全验证的能力给定的链，
客户端可能能够通过受信任的证书颁发机构来验证服务器的证书，这个证书颁发机构的证书作为证书链中的中间证书之。
3.客户端验证
本文档定义了三个新的客户端认证机制，每个机制都以涉及到的客户端证书的类型命名：
ECDSA_sign，ECDSA_fixed_ECDH和RSA_fixed_ECDH。
ECDSA_sign机制可用于第2节中描述的任何非匿名ECC密钥交换算法以及TLS [2] [3]中定义的其他非匿名（非ECC）密钥交换算法。
ECDSA_fixed_ECDH和RSA_fixed_ECDH机制可用于ECDH_ECDSA和ECDH_RSA。
禁止使用ECDHE_ECDSA和ECDHE_RSA，因为使用长期的ECDH客户端密钥将危及这些算法的前向保密性。
服务器可以通过在其CertificateRequest消息中包含一个或多个这些证书类型来请求基于ECC的客户端认证。
服务器不得包含所协商的密钥交换算法所禁止的任何证书类型。
客户端必须检查它是否具有适合于服务器建议的任何方法的证书，并且愿意将其用于认证。
如果不满足这些条件，客户端应发送不包含证书的客户端证书消息。
在这种情况下，ClientKeyExchange应按照第2节的说明进行发送，并且不应发送CertificateVerify。
如果服务器需要客户端身份验证，则可能会发生致命的握手失败警报。
如果客户具有适当的证书并愿意将其用于认证，则必须将该证书发送到客户端的证书消息（根据第5.6节），
并证明拥有与认证密钥相对应的私钥。确定适当的证书和证明所有权的过程对于每个认证机制是不同的，
并且在下面描述。
注意：服务器允许请求（和客户端发送）与服务器证书不同类型的客户端证书。
3.1。 ECDSA_sign
要使用此认证机制，客户端必须拥有包含ECDSA能力的公钥的证书，并使用ECDSA签名。
客户端通过在5.8节所述的CertificateVerify消息中包含签名证明拥有与认证密钥相对应的私钥。
3.2。 ECDSA_fixed_ECDH
要使用此认证机制，客户端必须拥有一个包含ECDH能力的公钥的证书，该证书必须用ECDSA签名。
此外，客户端的ECDH密钥必须与服务器的长期（认证）ECDH密钥位于相同的椭圆曲线上。
这可能会将此机制限制在封闭环境中。在客户端具有不同曲线上的ECC密钥的情况下，它将必须使用ECDSA_sign或非ECC机制（例如RSA）进行身份验证。
对于服务器和客户端，使用固定ECDH在计算上比提供前向保密性的机制更有效率。
当使用此认证机制时，客户端必须按照第5.7节所述发送一个空的ClientKeyExchange，并且不得发送CertificateVerify消息。
ClientKeyExchange为空，因为计算预主秘钥的所需的ECDH公钥包含在客户机的证书中。
客户端与服务器达成相同的前提秘密的能力（通过成功交换完成的消息进行演示）证明拥有与认证公钥相对应的私钥，并且CertificateVerify消息是不必要的。
3.3。 RSA_fixed_ECDH
此认证机制与ECDSA_fixed_ECDH相同，但客户端的证书必须使用RSA签名。
请注意，虽然ECDSA_sign，ECDSA_fixed_ECDH和RSA_fixed_ECDH客户端认证机制要求客户端的证书使用特定的签名方案进行签名，
但是本规范并不对证书链中其他地方使用的签名方案施加限制。
（通常这种限制将是有用的，并且预计在认证机构的签名实践中将考虑到这一点，
但是这样的限制并不是一般的严格要求：即使超出服务器完全验证的能力 一个给定的链，
服务器可能能够通过依赖一个作为链中的中间证书之一的信任锚来验证客户端证书。）
ECC的TLS扩展
本规范中定义了两个新的TLS扩展：（i）支持的椭圆曲线扩展，以及（ii）支持点格式扩展。
这些允许在握手开始新会话期间协商使用特定曲线和点格式（例如，分别压缩与未压缩）。
这些扩展与只能支持有限数量的曲线或点格式的约束客户端特别相关。
他们遵循[4]中概述的一般方法;消息详细信息在第5节中指定。
客户端通过在其ClientHello消息中包含相应的扩展名来枚举其支持的曲线和可解析的点格式。
服务器类似地列出它可以通过在其ServerHello消息中包含扩展名来解析的点格式。
在ClientHello消息中提出ECC密码套件的TLS客户端应该包括这些扩展。
实施ECC密码套件的服务器必须支持这些扩展，当客户端使用这些扩展时，
服务器不得协商ECC密码套件的使用，除非他们可以在尊重客户端指定的曲线和压缩技术的选择时完成握手。
这消除了由于客户端无法处理服务器的EC密钥而导致协商的ECC握手随后中止的可能性。
如果客户端不提供任何ECC密码套件，客户端不得将这些扩展包含在ClientHello消息中。提出ECC密码套件的客户端可以选择不包括这些扩展。在这种情况下，服务器可以自由地选择第5节中列出的任何椭圆曲线或点格式。该部分更详细地描述了这些扩展的结构和处理。
在会话恢复的情况下，服务器简单地忽略当前ClientHello消息中出现的支持的椭圆曲线扩展和支持的点格式扩展。这些扩展只能在握手谈判新会话期间发挥作用。
阅读(3106) | 评论(0) | 转发(0) |
