计算机安全

在移动时代，恶意软件的形态已经再一次发生变化。它既不是病毒也不是木马，而是 "具备实用功能，但背地却通过获取用户的敏感信息来获利" 的应用软件。

一个软件到底是正常的还是恶意的？ 边界已经越来越模糊了。

 

我们上网过程需要经过一系列的中间节点，有交换机，有路由器。我们的上网产生的所有数据包，都经由这些中间节点，这意味着我们由以下三个级别的安全风险。

  * 被窃听的风险。可能会有人在这些节点上监听你访问和提交的内容

  * 被篡改的风险。可能会有人在这些节点上接获并修改你访问的内容

  * 被钓鱼的风险。可能会有人冒充你要访问的服务提供方和你通信

虽然大部分的中间节点由网络运营商提供，我们刨除这些节点被黑客所黑的情形，基本上认为可信。但这并不绝对，至少在中国，运营商修改中转的数据包这样的事情是干得出来的，常见的手法有:

  * 在正常的HTML页面插入广告

  * 修改用户下载的apk文件，替换成自己想分发的apk文件

  * 修改404类型的HTML页面，替换成自己的搜索引擎的搜索页

其次是WIFI路由器。WIFI路由器因为其提供方鱼龙混杂，天生是安全问题的大户。运营商能够干的事情它全部可以干，甚至可以更加肆无忌惮，以李鬼换李逵，钓鱼的风险并不低。

比如你以为登陆的是交通银行官网，它可能给你一个一模一样外观的网站，但是一旦你输入用户名和密码就会被它偷偷记录下来。

 

怎么解决中间人问题?

首先是怎么防篡改。应用场景是电子合同/公章，网络请求授权等。这类场景的特征是在在乎内容是否有人看到，在乎的是内容是不是真的是某个人写的。

解决方法是数字签名技术。一般来说，一个受数字签名保护的文档可示意如下:

其中，"要防篡改的内容" 是信息原文。 "密钥提示" 是在数字签名的 ”密钥“有多个的情况下，通过 "密钥提示" 找到对应的 "密钥"。如果用于保护信息的 "密钥" 只有一个， 那么可以没有 "密钥提示"。"指纹"则是对信息使用特定 "密钥" 和 信息摘要算法生成的信息摘要。

大部分情况下，数字签名的信息摘要算法会选择HMAC MD5 或者 HMAC SHA1。

验证信息是否被篡改的过程正好相反。

 

如果我们希望更彻底的隐私保护，避免被窃听，被篡改，被钓鱼，那么数字签名就不顶用了，而需要对内容进行加密。

加密算法上，一般分为对称加密和非对称加密。

对称加密是指用什么样的密钥(key)加密，就用什么样的密钥解密，这比较符合大家惯常的思维。

非对称加密非常有趣。它有一对密钥，分私钥(private key) 和 公钥 (public key) 。私钥自己拿着，永远不要给别人知道。公钥顾名思义是可以公开的，任何人都允许拿。

那么公私钥怎么配合？首先，通过公钥加密的文本，只有私钥才能解得开。这就解决了定向发送的问题。网络中间人看到加密后的信息是没有用的，因为没有私钥解不开。

另外，私钥拥有人可以用私钥对信息进行数字签名(防止篡改)， 所有有公钥的人都可以验证签名，以确认信息的确来自私钥，这就解决了请求来源验证的问题。

那么A，B两个人怎么才能进行安全通讯呢？首先A，B两人都要有自己的公钥，并把公钥发给对方。这样A就有A-private-key，B-public-key， B就有B-private-key, A-public-key。通讯过程如下所示。

  * A向B发信息R。具体来说，A首先用A-private-key对R进行签名，得到(R, R-digest); 然后用 B-public-key 对 (R, R-digest)加

    密，得到 encoded (R, R-digest); 然后把最终的加密信息发出去。

  * B收到encoded(R, R-digest)，用B-private-key解密得到(R, R-digest), 然后再用 A-public-key验证信息的确来自A。

  * B理解了R后，回复信息给A。这时两人的角色互换，其它同上。

 

非对称加密机制非常有效地解决了在不可信地网络环境下地安全通讯问题。但是它也有一个缺点，那就是慢。相比之下，它的速度比对称加密慢很多。

 

所以，一个改善思路是结合两者。非对称加密仅用于传输关键信息，比如对称加密所需要的密码。完整的通讯过程如下所示。

  * A生成一个临时用的随机密码 random-key。

  * A向B发送 random-key， 机制用的就是上面的非对称加密，基于B-public-key。

  * B收到A发送的random-key, 把它记录下来，并回复A成功。回复的信息可以基于random-key做对称加密。

  * 此后，A向B发，B向A发信息，都用 random-key 作对称加密，直到本次会话结束。

你可能发现，整个过程中A自己已经不再需要非对称的公私钥对了。只要A事先有B的公钥(B-public-key)就可以。

 

当然，上面我的讨论，没有涉及B如何把自己的 B-public-key交给对方的。在假设网络不可信的前提下，这似乎是个难题。

有两个可能性。一个是A和B很熟悉，平常经常一起玩。那么他们交换public-key完全可以不依赖任何现代通讯设备，包括电话和互联网，而是写在一张纸上，某天聚会的时候交换给对方。