消息认证码与数字签名的理解-灵析社区

消息认证码

消息认证码可以实现”认证“和”检测篡改“这两个功能。秘文的内容在传输过程中可能会被篡改，这会导致解密后的内容发生变化，从而产生误会。消息认证码就是可以预防这种情况发生的机制。

消息篡改图解

正常情况

假设，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生成了一个用于制作消息认证码的密钥，然后使用安全的方法将密钥发送给了B。
接下来A使用密文和密钥生成一个值，此处生成的是7f05。这个由「密钥和密文生成的值就是消息认证码」，以下简称MAC。
A将MAC(7f05)和密文发送给B。
和A一样，B也需要使用密文和密钥来生成MAC。经过对比，B可以确认自己计算出来的7f05和A发来的7f05一致。
接下来，B只需使用密钥对密文进行解密即可，最终B成功取得了A发送过来的商品编号abc。

验证消息认证码

接下来，我们验证下使用消息消息认证码之后，X监听数据的情况，此时我们回到A正要向B发送密文的时候。

假设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可以验证数字签名的正确性，但无法生成数字签名。

数字签名生成图解

数字签名的生成使用的是「公开密钥加密」。

首先，A准备好需要发送的信息、私有密钥和公开密钥。由消息的发送着来准备这两个密钥，这一点与公开密钥加密有所不同。
A将公开密钥发送给B
A使用私有密钥加密消息，加密后的消息就是数字签名。
A将消息和签名都发送给了B
B使用公开密钥对密文（签名）进行解密。
B对解密后的消息进行确认，看他是否和收到的消息一致。流程到此结束。

缺陷

公开密钥加密的加密和解密都比较耗时，为了节约运算时间，实际上不会对消息直接进行加密，而是求得消息的哈希值，再对哈希值进行加密，然后将其作为签名来使用。使用数字签名后B会相信消息的发送者就是A，但实际上也有可能是X冒充了A。其根本原因在于使用公开密钥加密无法确定公开密钥的制作者是谁，收到的公开密钥上也没有任何制作者的信息。因此，公开密钥有可能是由某个冒充A的人生成的。

解决方案

数字证书可以解决这一问题，数字证书的文章将在后面发出，欢迎各位感兴趣的开发者持续关注。

消息认证码与数字签名的理解-灵析社区