密码学基本原理（下）
信息安全（四）
密码学基本原理（下）
大家好，欢迎大家观看STM32信息安全（四）：密码学基本原理（下）——身份认证。
本期主要回顾加解密原理的第三部分，以及如何确定通信对方的身份。
通常我们会使用一个“挑战-质询”的模型，对对方身份进行认证。结合密码学原理，可以用到对称密钥技术，也可以用到非对称密钥技术。使用对称密钥的问题之一是，如何安全的把这个密钥分发出去并进行管理；使用非对称密钥技术也有它的使用痛点。通过证书颁发中心，及其它颁发给通信主体的身份证明，可以很好的解决身份冒用的问题。
实现这些思想和技术的典型算法，这里也会做简单介绍。
身份认证，起源于远程通信的安全要求。如果是面对面，比如，Alice本来就认识Bob，现在她当面把表白信交给Bob，通过Bob的脸，声音，说话习惯，行为方式，Alice就已经对Bob的身份做了认证：em，这人是Bob。但是如果Alice是电话告白，Alice如何确认，在电话另外一头，接电话的号称自己是Bob的人，就真的是Bob呢？
“挑战–应答”模型
在身份认证的过程中，我们通常采用“challenge - response”，即“挑战 – 应答”的模型。有的文献又把“challenge”翻译成“质询”，质问的质，询问的询。
Alice产生一个随机数，就是所谓“挑战”，发送给Bob；Bob通过某种方式对该挑战做处理，得到的的结果就是应答，再发回给Alice。Alice通过检查这个收到的应答，来判断对方到底是不是Bob。当然，为了防止重放攻击，Alice每次发出去的challenge要有随机性，不能简单的重复。
那么这里的 “某种方式”，有很多实现方式。胶片里列了一些。HMAC，和之前的消息认证码类似，会用到双方事先约好的共享密钥，和哈希操作。对称认证，顾名思义，会用到对称加密和解密操作；非对称认证，会使用到私钥签名，公钥验签的技术。可以看出，这三种方式，都一定有密钥参与。其实，身份的认证，和刚才上一节的消息认证，有类似的地方，即通过密钥的归属性来绑定到某个主体，从而确认通信对方就是期望的那个主体。
HMAC
在“challenge - response”/挑战 - 应答的模型中，HMAC是如何运用的呢？
Alice要想确认通信的对方真是Bob，她只需要把一个随机数发给对面的人。让他使用Bob和Alice事先约好的共享密钥，与这个随机数放在一起，做哈希。得到摘要值，再发回给Alice。Alice使用同样的方式也计算出一个摘要值。只要Alice使用的密钥和对方使用的密钥相同，计算出来的摘要结果就相同。那么久认为对方就是如假包换的Bob，因为只有Bob才知道这个和Alice事先约好的共享密钥。
对称加解密技术
基于共享密钥的对称加解密技术，在“challenge - response”模型中的应用就更加简单明了。
Alice发送给对方一个随机数，对方使用Bob和Alice事先约好的对称秘钥对随机数进行加密，然后把值发回给Alice。Alice用同样的密钥对收到的密文解密，得到的随机数和自己发出的随机数相同，则证明对方是如假包换的Bob。
非对称加解密技术
基于公钥私钥的非对称加解密技术，在“challenge - response”模型中的应用，采用了私钥签名-公钥认证的原理。
Alice要确实对方是Bob，她先自己产生一个随机数发给Bob。Bob用自己的私钥对随机数签名，再发回给Alice。因为Bob的公钥是公开的，Alice使用Bob的公钥来验签，得到的结果和自己发出去的随机数相等，就认为对方确实是Bob。一切看上去似乎都很完美，但是在这背后，潜藏了一个巨大的风险。Alice是在公开场所拿到的Bob的公钥，如果这个公钥实际上是Eva的公钥，对，这个坏女人又出现了。或者说Eva到Alice家里，把Bob以前交给Alice的Bob自己的公钥给替换了。那么图中的红色B和绿色B，全都是红色的E和绿色的E，那么通信那头，Eva完全可以冒用Bob之名，来和Alice通信，而Alice还以为是在和Bob说话。
要避免这个风险，Alice要解决一个问题，那就是，如何确定手里的这把公钥真的是Bob的公钥？这就需要证书来帮忙了。
Bob的证书，是由证书中心，即CA颁发给Bob的，证明Bob身份的电子文件。里面有一些典型的信息，比如主题subject栏，表示这个证书是颁给谁的，Bob的证书，自然就是颁发给Bob的咯；发布者Issuer，就是CA自己的名字；Pub key公钥栏里，就是Bob的公钥。如何确保这些信息是真实有效，未被篡改，而且确实是这个CA颁发的呢？需要证书中心用自己的私钥对以上信息进行签名，并且写上使用哪种非对称算法进行的签名，比如ECDSA，比如SHA256RSA。除此之外，证书，一般都有一个有效期，这也是出于安全的考虑。到期需要重新申请证书。
简而言之，数字证书确认了一个在某个名字之下的公钥的所有权。Bob的证书，就是证明，这里面写着的公钥，的的确确就是Bob的。只要这个证书是可信的，或者说是经过Alice考验的，那么Alice就完全可以相信里面的公钥就是Bob的，从而避免刚才Bob的公钥被Eva偷梁换柱的风险。那么如何来考验，或是核实这个公开的，号称是Bob证书的文件的有效性呢？
了解了证书的产生过程，我们就自然明白了。
证书的验证
Bob如何拿到CA证明他身份的证书呢？
首先，Bob自己产生了一对公钥-私钥对。私钥，他自己保管好。然后拿着公钥去找到CA，要求给自己发一个身份证明文件，即证书。CA通过各种方式核实了来人确实是Bob，怎么核实的，我们不管，反正确定了来者就是Bob。那么就把Bob提供的公钥，和Bob的个人信息，比如姓名等放在一起，即紫色框里的内容，然后用CA自己的私钥来对这些信息签名，得到的签名也放在证书里。这样一个证明Bob身份的文件就产生了。Bob就高高兴兴拿回家了。
Alice要和Bob通信，她会先要求Bob把证书发过来。Alice拿到Bob的证书后，因为CA对紫色框内容的签名就在证书里，这里标准signature的那部分，所谓签名就是CA用自己的私钥对紫色框里内容的hash值，进行的加密运算结果。那么Alice使用CA的证书，即里面CA的公钥，对这个signature进行验签运算，得到的值；去和紫色框的Hash运算结果比对。相等就表示该文件是未被篡改过的。于是可以放心使用里面的公钥，它就是Bob的公钥。
讲到这里，可以看出，Alice要能够成功验证Bob的证书 的前提条件就是，Alice手里的CA证书是可信的。大家会不会疑惑，Alice既然不能确保Bob证书的可靠性，要靠CA的证书，那么Alice又如何确保CA证书的可靠性呢？这不成了一个递归了吗？可以理解为一个递归，这个递归的终止条件就是，Alice亲自到CA走一趟，把CA的证书拿回家放好。
类似我们的iot设备，在和各个网站通信前，把CA的证书烧到MCU里面。Bob的证书是CA颁发的，Lilian的证书是CA颁发的，Sunny的证书是CA颁发的，Alice只要去一趟CA的办公室，把正宗CA证书拿回家，之后她和无论是Bob，还是Lilian，还是Sunny通信，都可以使用这个可信的CA证书来核实通信对方的证书啦。
当然，Alice也可以去Bob家一趟，把Bob的证书带回去；再去Lilian家一趟，把Lilian的证书带回去；再去Sunny家，把Sunny的证书带回去。只要Alice能把她生活里所有人的证书都搬回家，就拿到了所有人可信的公钥，自然也没有CA啥事儿。或者根本没有证书啥事儿。她只需要去到Bob家，Lilian加，Sunny家，人肉拿回他们的公钥即可。但是实际生活中，谁也不会这样做。而且，这么多证书，或者这么多人的公钥，你保存还是个问题呢。不如就去一趟CA办公室，把CA的证书拿回去，或者CA的公钥拿回去，这样一来方便保存，一来可以“以一生万物”的去核实所有人的证书啦。
当然以上是把实际生活中的情况给简化了。实际上不可能所有通信主体，都是一个CA颁发的证书，CA自己的证书可能又是上一级CA颁发的，顺着证书链，可以追溯到Root CA。而能够作为Root CA的，并不是很多。就像我们电脑，操作系统里就已经预装了一些Root CA的证书，那么但凡这些Root CA开启的证书链的证书，都可以被电脑核实。用来安全上网，或者驱动安装时的验证等等。
通信主体认证
那么理解了证书的验证，就明白了依靠证书，Alice如何对号称Bob的通信主体进行认证了。
Alice想好一个随机数，作为challenge发给Bob。Bob是有私钥对随机数签名，作为应答，返回给Alice。Alice使用CA的证书，先来核实Bob的证书，通过，就从Bob的证书里取出公钥，用Bob的公钥对返回的应答值做验签运算，得到的结果和随机数进行比对。通过了，就说明对方确实是Bob。
回顾本期的内容：
对通信对方身份的验证，是通过“挑战 – 应答”，也叫“质询 – 应答”来完成的。类似对消息的认证，它要结合密钥，使用秘钥的归属性来定位都人身上。使用非对称加解密技术时，如何确保手里对方的公钥真是可靠，就需要对方证书的帮忙。对方证书的有效性是通过CA，甚至Root CA来保证的。
以上，就是今天我们对密码学基本原理的回顾。如何保证通信的机密性，confidentiality；如何确保消息的完整性，以及认证消息的来源，所谓信息的Integrity；如何对通信对方主体进行身份认证，authentication。
这些技术，我们生活中天天都在用。接下来，我们以一个大家每天都在使用的应用，或者说，现在你正在使用的应用，来分析刚才的技术是如何运用在这个应用中的。
请大家关注下一期内容。谢谢观看。
