安全系列之——数据传输的完整性、私密性、源认证、不可否认性

网络通讯过程中，为了保证信息安全，需要考虑多方面的因素。比较重要的几个关键点：



• 完整性（Integrity）：确保信息在传输过程中，没有被篡改。

• 私密性（Confidentiality）：也就是通过加密，确保只有可信的实体可以看到这些信息。

• 源认证（Authenticity）：确保是可信的源发送了这些信息，而不是伪装源发送的消息。

• 不可否认性（Nonrepudiation）：不能事后否认发送过这条信息。



这一期就从数据传输的完整性、私密性、源认证、不可否认性四个方面说明信息安全。具体的代码在前几期的【安全系列】中已经讲过来，这里主从实际的场景谈谈如何使用



一、优雅的发送文件



在之前的文章中关于散列函数，有过专门的介绍，可以参考。散列函数的主要任务就是验证数据的完整性。通过散列函数计算得到的结果叫做散列值，这个散列值也常常称为数据的指纹（Fingerprint）。



指纹在实际生活中用处很多，比如在刑侦案件的处理时，将犯罪现场的指纹到指纹库中比对，指纹库中的指纹可能是我们办理身份证时公安局采集的，如果指纹一样，则说明指纹库中的这个人就是犯罪现场的这个人。





在网上下载文件时，也可以使用这种技术。比如之前文章介绍的在mysql官网下载mysql的软件包。mysql官方将软件包上传到官网时，同时会使用相应的hash散列函数（比如MD5）生成相应散列值，并将散列值也放在官网上。当一个用户到官网下载mysql软件包后，也会使用相同的hash算法对下载的文件生成散列值，通过比较官网的散列值和生成的散列值，就可以确认是不是相同的文件了。





同时，在网上发文件给其他人时，也可以使用这种技术。用户A要给用户B发一个文件，可以将文件和文件的散列值一起发给对方，对方收到后，使用相同的散列函数生成新的散列值，并和收到的散列值进行比较，确定文件是否发生变化。





在上面的介绍中，虽然可以保证文件或信息在网络传输中的完整性，但是信息被人劫持后，会泄露敏感信息，也就是没有加密解密。关于加密解密，之前的文章中已经说过如何做对称加密和非对称加密，可以自行查看。



比如在网上发送机密文件时，可以使用对称加密将文件加密后，发送给对方；对方收到文件后可以使用相同的秘钥解密文件。





对称加密解密常用的是AES算法和DES算法，AES更安全。对称加密的优点是，加解密速度快，发送大文件时体验更好。但是由于加密解密使用的是同一把秘钥，如何将秘钥安全的发送给对方是一个问题。



这时可以考虑使用非对称加密，用户A可以通过网络获取用户B的公钥，公钥的网络传输不会有问题，这样就可以解决对称加密的秘钥共享问题。至于为什么使用公钥加密参考之前的文章。





非对称加密虽然解决了秘钥共享问题，但是非对称加密解密的速度要低于对称加密解密的速度，那么如何解决大文件发送的体验问题呢？



一个优雅的解决方案就是，加密文件时使用对称加密，秘钥使用生成的随机数；然后使用B的公钥对随机数做非对称加密。然后将对称加密的文件和非对称加密的随机数秘钥发给用户B。用户B收到后，先使用自己的私钥非对称解密获得随机数，然后在使用随机数和对称解密算法，解密文件。这样既可以保证秘钥的传输，也可以保证解密的速度。





二、优雅的发送报文



在网络通讯中，更多时候，通讯双方会通过文字进行交流。和发送文件一样，也需要保证通讯的安全。为了更好的理解这里的内容，墙裂建议先看一下之前的文章《安全系列之——RSA的公钥私钥有多少人能分的清楚？RSA的签名验签与加密解密如何使用公私钥？》。



比如用户A需要通过网络，将自己的用户名、银行账号、密码发送给用户B，用户A为了自己安全，保证账号密码不泄露，发送的数据只能B看到，即使信息被劫持别人也看不到，用户A就需要使用用户B的公钥对发送的部分数据或整个报文加密，用户B收到信息后，使用自己的私钥解密，这样就安全了。





上面是站在用户A的角度考虑安全性。如果用户B为了自己的安全，防止有人恶意的调用自己的接口，只能让合法的用户调用，那么用户B就要求调用方使用自己的私钥做签名，然后用户B使用对方的公钥验签，验签通过，就相当于源认证成功，而且用户A还不能否认自己没有发送过信息。





这里可以看到，签名使用的是A的私钥，加密使用的是B的公钥。



如果同时保证AB双方的安全，A要求B解密，B要求A签名，可以将上面的两种方式结合起来。下面这个图也是一个优雅的解决方案。用户A给用户B发信息，A使用B的公钥加密可以保证数据只能被B解密；加密后的数据使用消息摘要技术计算散列值，然后使用A的私钥签名，这样B既可以做验签，也可以保证数据的完整性。





这种方式在实际的网络通讯中应用非常广泛。比如对接支付宝、微信等各大开发平台时，都会有相关的签名验签、加密解密。



虽然这是一个完美的解决方案，就没有缺点了吗？



当然有，随着通讯的人数增多，秘钥也会急剧增加，秘钥如何管理也是一个问题。同时，使用非对称加密算法，虽然被调用方验签通过，说这个请求是一个合法的用户发送的请求，但是这个用户是谁依然不知道，只能知道这个用户是私钥的持有者。关于这问题的进一步说明还需要引入数字证书，CA等相关机制，以后有时间再详细说明这个问题。



关注公众号，输入“java-summary”即可获得源码。



完成，收工！





【传播知识，共享价值】，感谢小伙伴们的关注和支持，我是【诸葛小猿】，一个彷徨中奋斗的互联网民工。