从"嘿,今晚..."谈消息安全传输中的技术点

和女/男票聊了一些私密的话，成天担心消息会不会被泄漏，始终不放心，看完此文，消息传输安全性的来龙去脉，终于略知一二了。

一、初级阶段：信息裸传

特点：在网络上传递明文

黑客定理一：网络上传递的数据是不安全的，属网络于黑客公共场所，能被截取

结果：传递明文无异于不穿衣服裸奔

改进方案：先加密，再在网络上传输

二、进阶阶段：传输密文

特点：

• 服务端和客户端先约定好加密算法，加密密钥

• 客户端，传输前用约定好的密钥加密

• 传输密文

• 服务端，收到消息后用约定好的密钥解密

这么传输消息安全么？

黑客定理二：客户端的代码是不安全的，属于黑客本地范畴，能被逆向工程，任何客户端与服务端提前约定好的算法与密钥都是不安全的

结果：任何客户端的代码混淆，二进制化都只能提高黑客的破解门槛，本质是不安全的

改进方案：不能固定密钥

三、中级阶段：服务端为每个用户生成密钥

特点：

• 客户端和服务端提前约定好加密算法，在传递消息前，先协商密钥

• 客户端，请求密钥

• 服务端，返回密钥

• 然后用协商密钥加密消息，传输密文

这么传输安全么？

结果：

• 如黑客定理一，网上传输的内容是不安全的，于是乎，黑客能得到加密key=X

• 如黑客定理二，客户端和服务端提前约定的加密算法是不安全的，于是乎，黑客能得到加密算法

• 于是乎，黑客截取后续传递的密文，可以用对应的算法和密钥解密

改进方案：协商的密钥不能在网络上传递

四、再进阶阶段：客户端确定密钥，密钥不再传输

特点：

• 协商的密钥无需在网络传输

• 使用“具备用户特性的东西”作为加密密钥，例如：用户密码的散列值

• 一人一密，每个人的密钥不同

• 然后密钥加密消息，传输密文

• 服务端从db里获取这个“具备用户特性的东西”，解密

这么传输安全么？

黑客定理三：用户客户端内存是安全的，属于黑客远端范畴，不能被破解

当然，用户中了木马，用户的机器被控制的情况不在此列，如果机器真被控制，监控用户屏幕就好了，就不用搞得这么麻烦了

结果：使用“具备用户特性的东西”作为加密密钥，一人一密，是安全的。只是，当“具备用户特性的东西”泄漏，就有潜在风险

五、高级阶段：一次一密，密钥协商

特点：每次通信前，进行密钥协商，一次一密

密钥协商过程，如下图所述，需要随机生成三次密钥，两次非对称加密密钥（公钥，私钥），一次对称加密密钥，简称安全信道建立的“三次握手”，在客户端发起安全信道建立请求后：

• 服务端随机生成公私钥对(公钥pk1，私钥pk2)，并将公钥pk1传给客户端

  (注意：此时黑客能截获pk1)

• 客户端随机生成公私钥对(公钥pk11，私钥pk22)，并将公钥pk22，通过pk1加密，传给服务端

  (注意：此时黑客能截获密文，也知道是通过pk1加密的，但由于黑客不知道私钥pk2，是无法解密的)

  服务端收到密文，用私钥pk2解密，得到pk11

• 服务端随机生成对称加密密钥key=X，用pk11加密，传给客户端

  (注意：同理，黑客由密文无法解密出key)

  客户端收到密文，用私钥pk22解密，可到key=X

至此，安全信道建立完毕，后续通讯用key=X加密，以保证信息的安全性

六、总结

黑客定理一：网络上传递的数据是不安全的，属于黑客公共场所，能被截取

黑客定理二：客户端的代码是不安全的，属于黑客本地范畴，能被逆向工程，任何客户端与服务端提前约定好的算法与密钥都是不安全的

黑客定理三：用户客户端内存是安全的，属于黑客远端范畴，不能被破解

对于不同加密方法明：

• 明文消息传递如同裸奔，不安全

• 客户端和服务端提前约定加密算法和密钥，不安全（好多公司都是这么实现的=_=）

• 服务端随机生成密钥，发送给客户端，不安全

• 一人一密，客户端使用“具备用户特性的东西”作为加密密钥，弱安全

• 一次一密，三次握手建立安全信道，安全

好了，这下明白了，可以放心的和女/男票发送“啪啪啪”“咻咻咻”“嘿嘿嘿”了

只要即时通讯公司有良知，不从服务端偷看，一切都是安全的。额，这个“只要”的假设，貌似不成立

有收获吗？帮转哟，嘿嘿嘿