侧边栏壁纸
博主头像
神奇的程序员

今天的努力只为未来

  • 累计撰写 170 篇文章
  • 累计创建 27 个标签
  • 累计收到 226 条评论

目 录CONTENT

文章目录

消息认证码与数字签名的理解

神奇的程序员
2020-05-13 / 0 评论 / 3 点赞 / 640 阅读 / 1,923 字 正在检测是否收录...

消息认证码

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

消息篡改图解

正常情况

假设,A在B处购买商品,需要将商品编号abc告诉B。 7f8717da6a394f1aab05a52aa1751663

  • 此处A使用共享密钥加密对消息进行加密。A通过安全的方法将密钥发送给了B。 9c9102e6bd9d364bf90d7ea322770536
  • A使用双方共有的密钥对消息进行加密。 0ddbb481b876e263e5fe806edb15b78b
  • A把密文发送给B,B收到后对密文进行解密,最终得到了原本的商品编号abc。 0ff7a05efbfd70dab02d416a6467636e

消息被监听

以上是没有出现问题时的流程,然后在这个过程中可能会发生下面的情况。 c514ae902920abaf2edcfd0a8367eb29

  • 假设A发送给B的密文在通信过程中被X恶意篡改了,而B收到密文后没意识到这个问题。 23c5ad90a4dbe18ed105e1b5febce8c5
  • B对被篡改的密文进行解密,得到消息xyz。 458f789c02f584714dc0adad0d6ddc27
  • B以为A订购的是标号为xyz的商品,于是将错误的商品发送给了A。 52778f9dde14ce4e01997598a136aadc

解决监听问题

如果使用消息认证码,就能检测出消息已经被篡改。接下来我们回到A正要向B发送密文的时候。 e5ef0297f80a9e8bbd65a0a371419658

  • A生成了一个用于制作消息认证码的密钥,然后使用安全的方法将密钥发送给了B。 8f34fb8017e5a19812ce178bbe590d43
  • 接下来A使用密文和密钥生成一个值,此处生成的是7f05。这个由密钥和密文生成的值就是消息认证码,以下简称MAC。 67332a1dc85e05f1dec6cf085a8878f6
  • A将MAC(7f05)和密文发送给B。 25b78adbaca7cac18856057b5571aa93
  • 和A一样,B也需要使用密文和密钥来生成MAC。经过对比,B可以确认自己计算出来的7f05和A发来的7f05一致。 e6f03c375f4ed09b2b048a83d0bb8029
  • 接下来,B只需使用密钥对密文进行解密即可,最终B成功取得了A发送过来的商品编号abc。 9a4192f5054d60862d64edcfdfdf2ced

验证消息认证码

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

  • 假设A向B发送密文和MAC时,X对密文进行了篡改。 3c6dbd9d3712dd037856559889e3f367
  • B使用该密文计算MAC,得到的值时b85c,发现和收到的MAC不一致。 205c68fac736d1ec25688e284bbe35b7
  • 由此,B意识到密文或者MAC,甚至两者都可能遭到了篡改。于是B废弃了收到的密文和MAC,由A提出再次发送的请求。

加密仅仅是一个数值计算和处理的过程,所以即使密文被篡改了,也能够进行解密相关的计算。

使用场景

如果原本消息是很长的句子,那么它被篡改后意思会变得很奇怪,所以接收者有可能会发现它是被篡改过的。

但是,如果原本的消息就是商品编号等无法被人们直接理解的内容,那么解密后接收者便很难判断它是否被篡改。由于密码本身无法告诉人们消息是否被篡改,所以就需要使用消息认证码来检测。

缺陷

在使用消息认证码的过程中,AB双方都可以对消息进行加密并且算出MAC。也就是说,我们无法证明原本的消息是A生成的还是B生成的。

因此,加入A是坏人,他就可以在自己发出消息后声称”这条消息是B捏造的“,而否认自己的行为。如果B是坏人,他也可以自己准备一条消息,然后声称”这是A发给我的消息“。

使用MAC时,生成的一方和检测的一方持有同样的密钥,所以不能确定MAC由哪方生成,这个问题可以由下方的”数字签名“来解决。

数字签名

数字签名不仅可以实现消息认证码的认证和检测篡改功能,还可以预防是否否认问题的发生。由于在消息认证码中使用的是共享密钥加密,所以持有密钥的收信人也有可能是消息的发送者,这样是无法预防事后否认行为的。而数字签名只有发信人才能生成的,因此使用它就可以确定谁是消息的发送者了。

特征图解

  • 假设A要向B发送消息 70065eb2d4548ae7b0456d9584a47800
  • 在发送前A给消息加上数字签名。数字签名只能由A生成。 20a908035f337755e89ededfaf3b5e69
  • 只要发送的消息上有A的数字签名,就能确定消息的发送者就是A。 52fe1aa69feb1ea616fb13aeb5cbcf35
  • B可以验证数字签名的正确性,但无法生成数字签名。 51a4ed395aadc8b3590044d7ed3f706a

数字签名生成图解

数字签名的生成使用的是公开密钥加密ffac700cab9258af1e923654bd982617

  • 首先,A准备好需要发送的信息、私有密钥和公开密钥。由消息的发送着来准备这两个密钥,这一点与公开密钥加密有所不同。 43d9de8e401c074228784eed98c8f423
  • A将公开密钥发送给B 17ec025a68b0003927b491199435b148
  • A使用私有密钥加密消息,加密后的消息就是数字签名。 7555d1b5797a066508d7f2d813040c93
  • A将消息和签名都发送给了B 1366732da097771222c2d0de06809b7a
  • B使用公开密钥对密文(签名)进行解密。 f1d011bfba60a85bca30f8fc387cd2a4
  • B对解密后的消息进行确认,看他是否和收到的消息一致。流程到此结束。 377efd65bc96b9b2bd37835575e2b06a

缺陷

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

解决方案

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

写在最后

  • 文中使用的图片源自《我的第一本算法书》,如若侵权,请评论区留言,作者立即删除相关图片。
  • 文中如有错误,欢迎在评论区指正,如果这篇文章帮到了你,欢迎点赞和关注😊
  • 本文首发于掘金,未经许可禁止转载💌
3

评论区