安全算法(三)消息验证码、数字签名和数字证书

发布时间:2023年12月20日

安全算法(三)消息验证码、数字签名和数字证书

主要介绍了消息验证码、数字签名和数字证书三种加密方式。

消息认证码

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

假设 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://blog.csdn.net/weixin_47723114/article/details/135108370
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。