安全算法（三）消息验证码、数字签名和数字证书
主要介绍了消息验证码、数字签名和数字证书三种加密方式。
消息认证码
消息认证码可以实现“认证”和“检测篡改”这两个功能。密文的内容在传输过程中可能会被篡改，这会导致解密后的内容发生变化，从而产生误会。消息认证码就是可以预防这种情况发生的机制。
假设 A 在 B 处购买商品，需要将商品编号 abc 告诉 B。此处，假设 A 使用共享密钥加密对消息进行加密。A通过安全的方法将密钥发送给了 B。
A 使用双方共有的密钥对消息进行加密。A把密文发送给B，B 收到后对密文进行解密，最终得到了原本的商品编号 abc。
**可能出现的问题：**假设 A 发送给 B 的密文在通信过程中被 X 恶意篡改了，而 B 收到密文后没有意识到这个问题。
B 对被篡改的密文进行解密，得到消息 xyz。B 以为 A 订购的是编号为 xyz 的商品，于是将错误的商品发送给了 A。
如果使用消息认证码，就能检测出消息已被篡改。
A 生成了一个用于制作消息认证码的密钥，然后使用安全的方法将密钥发送给了 B。
接下来，A 使用密文和密钥生成一个值。此处生成的是 7f05。这个由密钥和密文生成的值就是消息认证码，以下简称为 MAC（Message Authentication Code）。
A 将 MAC（7f05）和密文发送给 B。和 A 一样，B 也需要使用密文和密钥来生成 MAC。经过对比，B 可以确认自己计算出来的 7f05 和 A 发来的 7f05 一致。
*我们可以把 MAC 想象成是由密钥和密文组成的字符串的“哈希值”。
计算 MAC 的算法有 HMAC、OMAC、CMAC等。目前，HMAC 的应用最为广泛。
①Hash-based MAC 的缩写。 ②One-key MAC 的缩写。 ③Cipher-based MAC 的缩写。
X 在通信过程中对密文进行了篡改是怎样一种情况呢？假设在 A 向 B 发送密文和 MAC 时，X 对密文进行了篡改。B 使用该密文计算 MAC，得到的值是 b85c，发现和收到的 MAC 不一致。由此，B 意识到密文或者 MAC，甚至两者都可能遭到了篡改。于是 B 废弃了收到的密文和 MAC，向 A 提出再次发送的请求。
缺点：在使用消息认证码的过程中，AB 双方都可以对消息进行加密并且算出 MAC。也就是说，我们无法证明原本的消息是 A 生成的还是 B 生成的。
因此，假如 A 是坏人，他就可以在自己发出消息后声称“这条消息是 B 捏造的”， 而否认自己的行为。如果 B 是坏人，他也可以自己准备一条消息，然后声称“这是 A 发给我的消息”。
使用 MAC 时，生成的一方和检测的一方持有同样的密钥，所以不能确定 MAC 由哪方生成。这个问题可以用以下将会讲到的“数字签名”来解决。
数字签名
数字签名不仅可以实现消息认证码的认证和检测篡改功能，还可以预防事后否认问题的发生。
由于在消息认证码中使用的是共享密钥加密，所以持有密钥的收信人也有可能是消息的发 送者，这样是无法预防事后否认行为的。而数字签名是只有发信人才能生成的，因此使用它就 可以确定谁是消息的发送者了。
假设A要向B发送消息。在发送前 A 给消息加上数字签名。数字签名只能由 A 生成。只要发送的消息上有 A 的数字签名，就能确定消息的发送者就是 A。B 可以验证数字签名的正确性，但无法生成数字签名。
数字签名的生成使用的是公开密钥加密：安全算法（二）：共享密钥加密、公开密钥加密、混合加密和迪菲-赫尔曼密钥交换-CSDN博客
公开密钥加密中，加密使用的是公开密钥 P ，解密使用的是私有密钥 S 。任何人都可以 使用公开密钥对数据进行 加密，但只有持有私有密钥的人才能解密数据。然而，数字签名却是恰恰相反的。
首先由A准备好需要发送的消息、私有密钥和公开密钥。由消息的发送者来准备这两个密钥，这一点与公开密钥加密有所不同。
A 使用私有密钥加密消息。加密后的消息就是数字签名。
A 将消息和签名都发送给了 B。B 使用公开密钥对密文（签名）进行解密。B 对解密后的消息进行确认，看它是否和收到的消息一致。流程到此结束。
公开密钥加密的加密和解密都比较耗时。为了节约运算时间，实际上不会对消息直接进行加密，而是先求得消息的哈希值，再对哈希值进行加密，然后将其作为签名来使用（请参考下图）
缺点：
虽然数字签名可以实现“认证”“ 检测篡改”“ 预防事后否认”三个功能，但它也有一个缺陷。
那就是，虽然使用数字签名后 B 会相信消息的发送者就是 A，但实际上也有可能是 X 冒充了 A。
其根本原因在于使用公开密钥加密无法确定公开密钥的制作者是谁。收到的公开密钥上也没有任何制作者的信息。因此，公开密钥有可能是由某个冒充 A 的人生成的。
使用以下将要讲到的“数字证书”就能解决这个问题。
数字证书
“公开密钥加密”和“数字签名”无法保证公开密钥确实来自信息的发送者。因此，就算公开密钥被第三者恶意替换，接收方也不会注意到。不过，如果使用本节讲解的数字证书，就能保证公开密钥的正确性。
A持有公开密钥PA和私有密钥SA，现在想要将公开密钥 PA 发送给 B。A首先需要向认证中心 （Certification Authority， CA）申请发行证书，证明公开密钥PA 确实由自己生成。认证中心里保管着他们自己准备的公开密钥 PC和私有密钥 SC 。A将公开密钥PA 和包含邮箱信息的个人资料发送给认证中心。
A将公开密钥PA 和包含邮箱信息的个人资料发送给认证中心。
认证中心对收到的资料进行确认，判断其是否为 A 本人的资料。确认完毕后，认证中心使用自己的私有密钥 SC，根据 A 的资料生成数字签名。
认证中心将生成的数字签名和资料放进同一个文件中。
然后，把这个文件发送给 A。这个文件就是 A 的数字证书。
A 将作为公开密钥的数字证书发送给了 B。B 收到数字证书后，确认证书里的邮件地址确实是 A 的地址。接着，B 获取了认证中心的公开密钥。
B 对证书内的签名进行验证，判断它是否为认证中心给出的签名。证书中的签名只能用认证中心的公开密钥 PC 进行验证。如果验证结果没有异常，就能说明这份证书的确由认证中心发行。
确认了证书是由认证中心发行的，且邮件地址就是A的之后，B从证书中取出A的公开密钥PA。这样，公开密钥便从 A 传到了 B。
假设交付过程中存在X。
X 冒充 A，准备向 B 发送公开密钥 PX。但是，B 没有必要信任以非证书形式收到的公开密钥。
假设 X 为了假冒 A，准备在认证中心登记自己的公开密钥。然而 X 无法使用 A 的邮箱地址，因此无法获得 A 的证书。
此处疑问：B 得到的公开密钥 PC 真的来自认证中心吗？
实际上，认证中心的公开密钥 PC 是以数字证书的形式交付的，会有更高级别的认证中心对这个认证中心署名。
假设存在一个被社会广泛认可的认证中心 A。此时出现了一个刚成立的公司 B，虽然 B 想要开展认证中心的业务，但它无法得到社会的认可。
于是 B 向 A 申请发行数字证书。当然 A 会对 B 能否开展认证中心业务进行适当的检测。只要 A 发行了证书，公司 B 就可以向社会表示自己获得了公司 A 的信任。于是， 通过大型组织对小组织的信赖担保，树结构就建立了起来。
最顶端的认证中心被称为“根认证中心”（root CA），其自身的正当性由自己证明。对根认证中心自身进行证明的证书为“根证书”。如果根认证中心不被信任，整个组织就无法运转。因此根认证中心多为大型企业，或者与政府关联且已经取得了社会信赖的组织。
文章来源：https://www.toymoban.com/news/detail-815331.html
参考资料：我的第一本算法书 (石田保辉 宮崎修一)文章来源地址https://www.toymoban.com/news/detail-815331.html
到了这里，关于安全算法（三）消息验证码、数字签名和数字证书的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
![[Android Studio] Android Studio生成数字证书，为应用签名](https://imgs.yssmx.com/Uploads/2024/02/829580-1.gif)
