密码学原理的应用 - TLS
信息安全（五）
密码学原理的应用 - TLS
大家好，欢迎大家观看 STM32 信息安全（五）：密码学原理在TLS协议中的应用。
TLS，传输层安全协议。TLS想必人人都知道，它是架构在TCP之上，应用层之下，提供安全网络传输的一个协议。有了它，我们才有https。TLS协议包含两部分，首先是握手阶段，即确认对方身份，协商后续会话的对称秘钥。前几期已经讲过，大数据量实时加解密，使用的是对称加解密技术。然后是应用阶段。
我们就分析一下握手阶段，来体会之前讲的那些密码学原理，算法是如何运用的。
这是TLS在握手阶段的通信双方（比如这里的iot设备和远端服务器）的所有的交互报文：
现在我们来一一进行分析。
首先，通信之前，iot设备端有自己的公钥和私钥；公钥是放在设备证书里的；除此之外还有CA的证书，自然里面包含的是CA的公钥。服务器端也一样，有自己的公钥-私钥对，公钥也是放在服务器证书里的；同样，也安装了CA的证书。
iot设备作为client，要和服务通信了，先由iot设备发送一条hello报文给到服务器。这个hello报文里包含了如下信息：iot设备支持的TLS协议版本，支持的加密、哈希、认证等多个操作的算法集合，还有一个重要的东西，就是iot设备产生的一个随机数。
服务器收到这条报文后，从iot设备支持的各种算法的集合中，选出一套它后面要采用的加密、哈希、认证算法，回复给iot设备；并且同样重要的，也回复给设备一个它产生的随机数，即这里的服务器的hello报文。
至此，双方就约定好了后面的握手阶段要用到的加密-哈希-认证，等算法。算法本身是公开的，敏感的是每次算法运行时用的密钥。至此，双方还都拥有了一个自己产生的随机数，和对方传过来的随机数。
我们把已经完成的报文，有绿色粗体表示。iot设备端和服务器分别发出的hello报文，刚才已经解释过了。接下来，服务器用自己的私钥对iot设备发过来的随机数签名，然后把这个随机数、对应的签名、还有自己的证书发给iot设备.
iot设备拿到服务器的证书，先使用CA证书，即CA的公钥，对服务器证书进行验证（因为证书的内容是CA的私钥签名的，可以通过CA的公钥来验签）。如果验证通过，说明这个证书确实是服务器的证书，于是取出里面的公钥，它确实是服务器的公钥。这个公钥拿来干嘛呢？就是验证和证书一起发过来的被服务器私钥签过名的随机数。如果验证通过，说明对方确实是这个证书号称的拥有方。因为基于收到的服务器证书的可靠性（这是CA证书保证的），而对方又拥有这个公钥对应的私钥。那么从而确定了对方服务器的身份，就是证书里写的那个主体。
这三个回合的报文完成后，iot设备，就核实了通信对方，即这个网站的身份了。身份认证就是使用前面第三小节里的使用挑战-应答的模型，在证书的帮助下来实现的。
至此，iot设备端，收到的来自服务器的信息有，服务器产生的随机数，和服务器的证书。
接下来，服务器会继续三连发，连续发三个报文。
先是要求设备端提供证书，很好理解，服务器提供了自己的证书供对方认证，它也需要对方提供证书，它也要验证对方的身份。这种情况还是挺多的，比如这个服务器提供的service，只针对它认证过的客户端。就像网上银行，它要处理你从电脑上发出的交易请求时，会要你插上U盾，这里面就是装载着你的个人证书。这个证书就是你去银行网点开通网银的时候给你创建的。然后以U盾的形式手把手交给你。
然后，服务器生成一个临时的ECC公钥-私钥对。大家还记得ECC椭圆曲线的公钥和私钥吗？私钥是一个随机数，在1到n之间，n是椭圆曲线的阶数；公钥是一个点，P，由参考点G，做点乘得到的。然后对这个临时椭圆曲线的公钥签名后，和临时生成的公钥发给iot设备。iot设备使用上一阶段已经验证过的服务器证书，核实这个报文的完整性。验证通过，说明传递过程中内容未被破坏，把服务器的临时ECC公钥记录下来。这个报文叫做server key exchange。就是server把临时ECC公钥，安全地给到iot设备。
最后，服务器再发一个hello done的报文。表示自己这边在握手阶段的事情，就做完了。接下来看iot设备端的了。
在服务器端结束了自己在握手阶段的所有动作后，盘点一下双方现在都交换了一些什么东西？服务器，有iot设备产生的随机数；自己产生的临时ECC私钥；iot设备端有，服务器产生的随机数、服务器的证书、服务器的临时ECC公钥。
接下来是iot设备端，响应刚才服务器关于证书的请求。它以同样的方式，把服务器的随机数签名，然后伙同随机数本身，还有自己的证书发给服务器。
服务器使用同样的方式来认证iot设备，核实它的身份。这个过程会用到CA的证书，用于核实iot设备发过来的证书；再用iot设备证书里的公钥，去对随机数签名做验签。验证通过，就说明对方确实是这个证书里号称的那个主体。
最后，双方发送change cipher spec报文，和Finish报文，表示握手阶段结束，双方已经拥有了后续安全通信所需的所有参数；后面的数据通信开始使用对称加密算法和消息认证算法做安全的信息交换啦。
以上就是TLS协议中最复杂也是最精密的握手部分中的完整握手流程。还有会话恢复流程，不在此展开。并且这里所述的都是原理性讲解，很多细节也没有展开。大家有兴趣的可以自己去查看TLS协议， RFC编号5246。
iot设备端也会发一个client key exchange报文，来把临时生成的设备端ECC公钥，完整无误的，发给服务器。
certificate verify 这条报文，是可选的。iot设备端把之前所有来来回回的握手消息进行签名，发给服务器，证明客户端持有对应证书的私钥，即，是证书里宣称的那个主体。这条报文不是必须的，因为前面iot设备把服务器随机数签名后，和自己证书一起发过去，服务器对随机数验签，就能够确定iot设备了。
这里重要的是，双方拿到了对方的ECC临时公钥。那么通过ECDH密钥协商算法，使用自己私有的一部分信息，就是这里红色的，各自的ECC临时私钥；结合公开的，对方发过来的信息，就是这里绿色的，对方的ECC临时公钥。就能计算出共享密钥。
最后，双方发送change cipher spec报文，和Finish报文，表示握手阶段结束，双方已经拥有了后续安全通信所需的所有参数；后面的数据通信开始使用对称加密算法和消息认证算法做安全的信息交换啦。
以上就是TLS协议中最复杂也是最精密的握手部分中的完整握手流程。还有会话恢复流程，不在此展开。并且这里所述的都是原理性讲解，很多细节也没有展开。大家有兴趣的可以自己去查看TLS协议， RFC编号5246。
至此，密码学原理和应用的回顾就到此结束。后面开始讲解STM32的软硬件安全特性，而且大家会在重点介绍的STM32安全包 SBSFU中再次体会密码学的运用。敬请大家关注下期内容。谢谢观看。
