1 单向散列(hash)
明文加密成密文后, 就不能通过某种算法再还原成明文,
一般用来存储用户的密码等信息.验证密码时, 通过把用户输入同样采用相同的hash算法得到密文, 和数据库对比
最知名的单向散列算法: MD5, SHA-256
但我们很多时候只是需要传输时加密, 收到后想要还原得到明文怎么办呢? 这就是我们接下来要说的对称加密
2 对称加密
明文 通过对称加密算法经过密钥加密 得到 密文,
密文 通过对称加密算法经过密钥解密 得到 明文
由于 加密 和 解密 都使用同一把 密钥, 所以称之为对称加密
最知名的对称加密算法: AES
比如说A是服务端, B是客户端, 这两个程序都是你自己写的, 你怎么保证通信过程安全呢?
我们就先用对称加密试试看吧
那这个密钥存放哪里呢?
如果你说, “用一个变量记录这个密钥, 服务端A和客户端B都放一份不就好了?”
因为你对明文肯定会在发送前加密, 别人对你的客户端用OD调试器附加, 对send函数下一个断点, 断下后逆向跟踪, 就可以很快找到你的密钥
如果你说, “那我就把变量只放在服务端, 客户端与服务端第一次通信时, 服务端把密钥传过去”
别人对你的客户端抓包, 第一个包就是你服务端发的这个密钥
如果你说, “那我把这个密钥也加密后再传过去”
那你这个用于加密密钥的密钥总得明文发过去吧, 这是个先有鸡还是先有蛋的问题, 无穷无尽
那这个密钥直接放客户端也不行, 从服务端进行密钥传输也不行, 怎么办呢?
下面有请非对称加密闪亮登录
3 非对称加密
非对称加密算法是一个非常神奇的算法, 它用的不是一个密钥, 而是一对密钥(两个), 我们可以称之为公钥和私钥,
如果对一串明文, 你用公钥加密 就只能用私钥解密, 你用私钥加密 就只能用公钥解密
最知名的非对称加密算法: RSA
(1) 准备工作
A和B都要先利用openssl (一个开源的密码程序库)
通过以下命令生成 自己的公钥 和 私钥
$ openssl
$ OpenSSL> genrsa -out app_private_key.pem 2048 # 制作私钥
$ OpenSSL> rsa -in app_private_key.pem -pubout -out app_public_key.pem # 制作公钥
$ OpenSSL> exit
现在A有了自己的私钥和公钥, B也有了自己的私钥和公钥,
注意: 公钥是公开的, A和B要进行非对称加密通信的话, A要把A的公钥发给B, B也要把B的公钥发给A
(2) 正式开始
现在A和B准备工作完成, 就能正式通过RSA传递数据了,
比如现在A要给B发送数据
A先把明文用 B的公钥 进行非对称加密, 这样在传输过程中, 除了B的私钥, 没有任何东西能解密
B收到后, 用 自己的私钥 解密, 得到明文
比如B要给A发送数据
B先把明文用 A的公钥加密, 发送,
A收到后, 用 自己的私钥 解密, 得到明文
发现规律没有, 你要发给谁, 就用谁的公钥加密, 这样他收到后, 只有他自己的私钥能解密
如果你说, “A给B发送数据, 用A的私钥加密, B收到后, 用A的公钥解密不也可以吗?”
可以确实是可以, 但是你想啊, A的公钥解密, A的公钥可能不只发给B, 还发给了C,D, 那C,D不是也能对这个数据包解密了?
如果你说, “非对称加密 这么6p, 那我们传输数据用它就好了, 忘了对称加密吧?”
非对称加密过程很复杂, 所以它很慢, 比对称加密慢了几百倍, 用于网络传输不现实
那这个对称加密保证不了安全, 非对称又保证不了效率, 咋办呢?
这就是我们接下来要说的 混合加密
4 混合加密
混合加密, 包括后面要介绍的几种技术, 都不是加密算法
混合加密 使用了 非对称加密 和 对称加密
思路: 用非对称加密 来解决 对称加密算法的密钥传输 问题, 此后AB双方通过对称加密通信
对称加密算法的密钥 由 服务端A生成
A把 对称加密算法的密钥 用 B的公钥 加密,
B收到后 用自己的私钥 解密, 得到对称加密算法的密钥
AB都有对称加密的密钥了, 双方就可以愉快地进行对称加密通信了
混合加密好像解决了所有的问题哎, 真的能保证绝对安全了吗?
首先明确一下, 我们上面的混合加密 解决了什么问题? 窃听!!!
因为黑客拿到对称加密的通信密钥, 就能窃听A和B之间的通信内容,
我们用混合加密, 让他拿不到这个通信密钥
但对于逆向大佬来说, 还是可以拿到的, 因为你程序B总得解密得到通信密钥后放到一个变量里吧
这个过程可能会被逆向跟踪, 我们最好再搭配反调试+异步回调+多线程+时钟扰乱, 增大逆向难度
还剩什么问题没解决, 篡改 和 冒充!!!
要怎么解决呢? “数字签名”技术来啦~
5 数字签名
数字签名使用了hash算法和非对称加密,
利用私钥加密, 公钥如果能成功解密得到摘要, 可以证明发送方的身份, 防止冒充
对消息内容进行hash, 得到摘要, 经过摘要对比, 可以检测是否被篡改
服务端A向客户端B发送数据:
先对明文使用hash函数, 生成摘要(digest), 对这个摘要用A的私钥加密, 生成数字签名(signature)
再对 明文+数字签名 发给B
客户端B收到数据后:
对 数字签名 用A的公钥解密, 得到 摘要
再对明文用hash函数, 得到摘要2
对比 摘要 和 摘要2, 若两者一致, 说明数据确实是A发过来的
为什么说数字签名能解决冒充问题呢?
如果A希望只有B才能接收数据, 就要用B的公钥加密后发送, 这样只有B的私钥能解, 那但这种情况下, 其它人可能冒充A向B发送消息
如果A希望其它人不能冒充自己, 就要用A自己的私钥加密, 这样具有唯一性, 其它人伪造不了
如何用数字签名技术验证通信双方的身份呢?
A用自己的私钥 签名一个消息”我是A”, B收到后用A的公钥验签, 确认身份没问题后
B也用自己的私钥, 签名一个消息”我是B”, A收到后用B的公钥验签, 也没问题的话
A和B就知道对方不是假冒的, 后面就可以用混合加密进行安全通信了
6 数字证书
问题全都解决了吗? 还没呢!
之前我们说过, 非对称加密时, 公钥是公开的, A和B要进行非对称加密通信的话, A要把A的公钥发给B, B也要把B的公钥发给A
这个进行公钥分发的阶段其实是有漏洞的, 为什么呢?
这种现象叫 “中间人劫持”, 看下图
要怎么安全地分发公钥呢? 或者说要怎么证明”A的公钥”确实是A的? 而不是别人伪造的呢?
现在中有公证处, 网络世界也有这样一种具备公信力的组织, 叫做CA, 他们给服务端颁发一个数字证书, 上面写上A的信息, 包括A的公钥, 这样如果拿到了证书, 也就拿到了可信任的A的公钥
问题是, 证书要怎么安全传输呢? 如果证书被篡改了怎么办?
现在的情况是, 需要一种既要能判断公钥是否冒充, 还要能判断数据是否被篡改的手段, 这不就是刚刚讲的数字签名嘛
具体怎么操作呢? 其实就是把 数字签名中的 “明文”部分 换为 “数字证书”
注:
客户端B向服务端A发送请求时, 服务端A会返回自己数字证书给客户端B
CA公钥是内置在客户电脑中的, 更确切地说, 是在浏览器中