这是 2020 年一个平平无奇的周末,小北在家里刷着 B 站,看着喜欢的 up 主视频。
在一旁玩手机的女朋友突然问”你知道数字证书是来干啥的不,为啥浏览器提示证书不可信?”
你要问这个,那我可来劲了,于是乎从加密、数字签名一直讲到了数字证书。。。终于把女朋友讲睡着了,独自写下这篇文章。
正文
如果你能
非常清晰
的回答出以下问题,可以直接拉到最下面帮我点个赞~,把时间用去陪陪女朋友:
-
非对称加密中公私钥都可以加密,那么什么时候用公钥加密,什么时候用私钥“加密” ?
-
-
为什么要对数据的摘要进行签名,而不是直接计算原始数据的数字签名?
-
这篇文章,主要围绕
数字签名
和
数字证书
的原理以及它们的作用展开。
争取做到让不具备任何密码学基础知识的同学都能听懂,所以在这里需要先对齐一些加密相关的概念 。
1. 什么是加密
加密就是
对明文数据按某种特殊算法进行处理,使其成为不可读的一段代码,通常称为“密文“,
密文通过”密钥“解密后还原出原来的明文,通过这样的途径可以达到保护数据不被非法人窃取、阅读的目的。
定义简单吧?那来看个题,考虑以下哪些属于加密方法:
这几种都是日常开发中常用的数据编码技术,但是只有 AES、RSA、SM4 才能算是加密方法。
为什么呢?
一个区分的简单方法就是看编码后的数据是否还能还原,能还原的是加密。
MD5 实际上是对数据进行有损压缩,无论数据有多长,1KB、1Mb 还是 1G,都会生成固定 128 位的散列值,并且 MD5 理论上是不可能对编码后的数据进行还原的,即不可逆。
MD5 因为其具有不可逆性、单向恒定性(相同的数据多次计算值不变)被广泛应用于文件完整性验证、口令加密以及接下来会讲到的数字签名中。
至于 BASE64 是否算做加密方法,仁者见仁。在这里不下结论,因为 BASE64 编码不需要密钥,且编码后的字符串任何人都可以解码出原串,所以一般不认为是加密方法。BASE64 常用来做转码,把二进制字节序列转化为 ASCII 字符序列。
2. 加密算法的分类
加密算法按照加解密使用的密钥是否相同,可分为:
-
对称加密(Symmetric Cryptography)
-
非对称加密(Asymmetric Cryptography)
1. 对称加密
对称加密是指加密和解密时使用同一个密钥。
2. 非对称加密
非对称加密是指加密和解密使用不同的密钥,这两个密钥分别叫做「公钥」、「私钥」。
公钥是可以公开给所有人的,而私钥需要自己保密的。
公钥加密的数据只能用私钥解密:
同理,私钥“加密”的数据只能用公钥“解密”:
大家注意到没,我对
私钥“加密”
这里打了引号,为什么呢?
因为私钥不是用来加密的,准确的说法应该是
「私钥签名,公钥验签」
。
这个问题很多同学都存在误解,认为公私钥都可以用于加密。
实际上不是的,至于为什么,后面讲完签名我会解释的。
3. 故事开始
为了讲这个故事,小北请来了密码学中常用的学术情侣,Alice 和 Bob,以及窃听者代表 Eve。
我们从 Alice、Bob 约会的故事展开,来讲讲其中暗藏着哪些危机,又是如何一步步化解的。
3.1 第一回合
九月,一个夜黑风高的晚上,Bob 想约 Alice 出来玩,于是给 Alice 发了一封邮件:
但我们都知道网络是不可信的,并且由于消息在网络中是明文传输的,所以黑客可以轻易的截获、篡改甚至冒充 Bob。
来,我们看看黑客 Eve 是怎么干的:
黑客窃听伪造
瞧,Eve 轻易的拿到了邮件内容
(窃听)
,并且修改了邮件内容
(篡改)
,甚至说他可以随时冒充 Bob 给 Alice 发送邮件
(伪装)
。
如果上图中 Eve 伪造的内容被 Alice 接收到了,那么后果可想而知。
现实世界中,我们每天都在通过网络进行聊天、转账、浏览不存在网站。
如果都是这样明文传输数据,显然毫无安全感。
3.2 第二回合
既然我们不能明文传输,那么 Bob 和 Alice 提前商量好密钥,使用对称加密对邮件内容加密不就好了~
对称加密
现在 Bob 发送的邮件都使用和 Alice 提前商量好的密钥加密后再传输。
由于没有密钥,Eve 就算截获到数据也无法获取邮件的内容,也没法篡改和冒充 Bob。
因为篡改后的数据必须使用密钥再次加密 Alice 才能正确解密。
那么只要 Bob 和 Alice 能够保证 密钥不泄露,整个通信就是安全的。
如果密钥泄露,被中间人截获,那么就等同于明文通信。
所以我们不能把安全性寄托在人上面。
并且这里也存在一个问题,如果两个人不能线下见面, 如何在网上安全的交换密钥呢?
这似乎是无解的,因为
交换密钥的时候我们必须明文通信,不然对方根本看不懂。但是明文交换即意味着可能泄露。
但是别忘了我们的密码学工具箱里还有一个好东西—
「非对称加密」
。
Bob 和 Alice 各自生成一对公私钥,因为公钥本来就是公开的,即可以被任何人获取,所以可以通过网络明文交换公钥。
然后使用公钥加密邮件内容后发送给对方,接收者使用自己的私钥即可解密。完美~
3.3 第三回合
来看看,在非对称加密体系下,Bob 如何给 Alice 发消息的。
首先 Alice 需要先生成一对公私钥,私钥只能 Alice 自己知道,公钥是可以让任何人都知道的,因此可将公钥直接发送给 Bob,就算被截获也无所谓。
非对称加密
Bob 使用 Alice 的公钥加密邮件内容,加密后的内容只能由 Alice 的私钥解密,所以就算 Eve 截获也是徒劳。
反之,如果 Alice 想给 Bob 回信,就需要用 Bob 的公钥加密后发送。
这就解决了密钥交换问题,也保证了邮件内容不会泄露。也就是说现在可以
防窃听
。
3.4 如何证明 Bob 是 Bob
不知道你注意到没有,这里也存在另外一个问题:
Eve 也可以使用 Alice 的公钥冒充 Bob 给 Alice 发邮件啊,因为 Alice 的公钥本来就是公开的,任何人都可以获得。
由于 Eve 也可以获得 Alice 公钥,所以没法防止 Eve
伪造
和
篡改
,并且对于 Alice 而言,她无法分辨出邮件到底是 Eve 发的还是 Bob。
所以这个问题的本质就是
「Alice 如何确认邮件来自于 Bob」
。
那么在生活中,我们如何做这件事呢?
那就是让 Bob 在纸上
签名
并且
按手印
,因为指纹和字迹是 Bob 独有的,其它人很难伪造。
所以我们需要在计算机中引入类似的机制:
即只有 Bob 自己能够产生的独一无二的标志,并且其它人能够验证这个标志确实是属于 Bob的。
这就是我们今天要讲的主题—
「数字签名」。
还记得什么是 Bob 独有的吗?
对,就是 Bob 自己的私钥,Bob 用自己的私钥对邮件内容计算一个「签名」,将「签名」和邮件内容一起发送出去,接受者 Alice 可以使用 Bob 的公钥验证这个签名是否正确,这就叫「验签」。
如果不是 Bob 的私钥计算的签名,那么 Alice 用 Bob 公钥验签将会出错。
可以看到, Eve 试图使用自己的私钥计算签名然后发送给 Alice, 但是 Alice 使用 Bob的公钥进行验签时将会出错!
那么 Eve 可能篡改内容并冒充 Bob 的签名吗?不可能!因为内容发生改变时,对应的签名也需要重新计算,而签名的生成依赖于私钥,只要 Bob 的私钥不泄露,签名就不会被冒充。
啊啥?你说万一私钥泄露了怎么办?那就当我没说......
所以使用数字签名,我们能够鉴别消息的发送者,也就是说黑客无法伪装发送者进行发送数据,也无法篡改。
注意:
可以看出我们这里数据是明文传输的,存在窃听风险。但是我们为了阐述数字签名机制是如何运转的,故意将保证信息机密性的机制省略了。
如果想要保证数据的机密性,我们常见的做法是,通信双方通过非对称加密安全交换对称加密的密钥,后续通信过程的数据都使用对称加密保证数据机密性。
并且「签名」的作用本身也不是用来保证数据的机密性,而是用于验证数据来源的防止数据被篡改的,也就是确认发送者的身份。
一般而言,我们不会直接对数据本身直接计算数字签名,为什么呢?
因为数字签名属于非对称加密,非对称加密依赖于复杂的数学运算,包括大数乘法、大数模等等,耗时比较久。
如果数据量大的时候计算数字签名将会比较耗时,所以一般做法是先将原数据进行 Hash 运算,得到的 Hash 值就叫做「摘要」。
「摘要」就像人的指纹一样,可以代表一个人,只要内容发生了改变,计算出来的摘要也应该变化。
「摘要」最好是不可逆转的,一般使用开头提到的 MD5 作为 Hash 函数,MD5 输出的结果固定位 128 位。
为什么「摘要」最好是不可逆转的?
因为既然 Alice 可以用 Bob 公钥解开签名,那么理论上其它人,比如 Eve 也可以使用 Bob 公钥解开签名拿到数据。
所以我们最好对数据的「摘要」进行签名,这样,Eve 就算解开签名,拿到的也是「摘要」,如果摘要是不可逆转的,也就是无法从摘要反推出原文,也就达到了保密的作用。
发送者使用私钥对「摘要」计算数字签名。那么接收者如何验证呢?
接受者 Alice 收到后,取下数字签名,同时用 Bob 的公钥解密,得到「摘要1」,
证明确实是 Bob 发的
。
( 画外音:如果使用 Bob 的公钥验证签名出错,那么签名一定不是 Bob 的私钥生成的)