最近需要实现一个艺术品买卖交易平台。由于安全性的需求,学习了各种加密方法。这里总结一下。
Alice
要和Bob
互传消息,消息在公开的网络上传播,不希望消息被别人看见,所以需要加密后,在网络上传送加密后的消息。只有有解密钥匙的人才能破解密文,看到消息内容。
最简单的方法是Alice
和Bob
制作一把钥匙的两个副本,各自保存一个。
Alice
或Bob
在发消息前先用钥匙加密消息,接收的人用钥匙解密后查看消息就行。加密解密用同一把钥匙就是对称加密。常见的对压缩文件加密的方式就是对称加密。常用的对称加密算法有AES
(最常用)、DES
、RC4
。
由于对称加密算法加密的信息长度通常是固定的(如AES
需要128/192/256位),但日常生活中我们给账号设定的密码通常不限长度,所以一般会先使用PBE
(Password Based Encryption
)算法,用随机数凑至足够长度,再进行加密。
但是如果不能面对面接触,如何通过公开的网络将钥匙分享给另一个人,同时防止攻击者截获并且备份一把钥匙留作他用?
目前被认为最安全的方法是加密和解密用两把不同的钥匙。
Alice
生成一把私钥和一把公钥,通过公开的网络将公钥传给Bob
。日后发消息时,Bob
先把消息用Alice
的公钥加密,然后通过公开的网络传给Alice
。因为加密的消息只能用Alice
的私钥解锁,所以只有Alice
能破解密文内容。当Alice
想要给Bob
传消息时,也是同样的道理。
尽管在多人互传消息时,非对称加密所需的密钥数量远低于对称加密。但是非对称加密算法的加密速度非常慢,而且只能加密长度有限的消息。相比之下,对称加密算法速度比较快,而且加密的消息长度不限。所以一种解决办法是使用非对称加密的方式来传送对称加密的密钥,而在传消息时使用对称加密的方式。比如AES
+RSA
(著名的WannaCry
病毒用的也是这个方法)。
当Alice
想要给一份文件签名然后传送给Bob
时,会先对文件使用叫做“哈希”的东西,得到一段长度固定的文件的摘要(digest
)。摘要并非用于加密,而是用来确保文件内容完整无误,没有被攻击者修改过。常见的摘要算法有MD5
、SHA1
、SHA256
、SHA512
。
Alice
随后将摘要信息使用Bob
的公钥进行加密,这份加密的文件摘要就是Alice
对这份文件的数字签名,确保了文件的完整无误(因为包含摘要),并且进一步保证了文件的真实性(因为摘要被Bob
的私钥加密了)。
然后,Alice
将自己的数字签名,和文件一起,发送给Bob
。Bob
拿到文件和加密的摘要,先使用自己的私钥对文件摘要进行解密,同时,自己也对文件内容使用“哈希”来生成一份摘要,然后通过比对两份摘要是否相同,从而确定文件是否真的是被Alice
签名过的。
之所以要用两步:生成摘要+加密摘要,而非直接加密原文,是因为非对称加密耗时长,加密+解密的步骤比网络传输的速度还要慢,得不偿失。
常用的数字签名算法有:RSA
、DSA
(Digital Signature Algorithm
,比如被比特币和Sony等公司使用的椭圆数字签名算法——ECDSA
)
但是即使是上面描述的最妥善的加密措施,也没法防范中间人攻击。
如果在上述过程中,有一个攻击人,偷偷使用了Alice
的电脑,将Bob的公钥换成了自己的公钥。日后
Alice`发信息时,就会使用攻击人的公钥加密信息,从而信息会被攻击人收取。
(另一种中间人攻击是,攻击人截获Alice
的发给Bob
的消息,然后假扮Alice
给Bob
发消息,然后在Bob
给Alice
发消息时做相同的事,从而破获密钥。)
那么,Alice
如何确认自己使用的公钥是Bob
的公钥呢?
Bob
可以去找证书中心(certificate authority
,简称CA
),为自己的公钥做认证。证书中心用自己的私钥,将Bob
的公钥以及Bob
的一些个人信息一起,加密生成一段文本,发给Bob
。这个文本就是证书中心颁发给Bob
的数字证书。
具体流程如下图。
这里有个问题:证书中心使用自己的私钥来加密数字证书,而Alice
使用Bob
的公钥来加密发给Bob
信息,为什么截然相反?
因为使用对方的公钥加密信息,能确保信息只被对方破解。而使用自己的私钥加密信息,能够确保收到信息的所有人,都知道信息是由自己加密的。证书中心需要的是让所有人都知道,证书是由自己颁发的。
以后,Bob
只需要在传送文件和数字签名(也就是加密的文件摘要)的同时,也附上自己的数字签名。Alice
收到后,首先使用电脑出厂时就已经安装的证书中心的公钥,来解密数字签名,然后获取Bob
的公钥,随后Alice
再使用Bob
的公钥,来解密文件附带的Bob
的数字签名,就能确保文件的准确无误,而且能确定文件是被Bob
签名过的。
HTTPS协议就用到了数字证书。