zoukankan      html  css  js  c++  java
  • 计算机网络——如何保证网络传输的安全性

    一、前言

      前几天在面试时,被问到了如何保证网络数据传输的安全性的问题,当时对这一块没怎么研究过,所以当时并没有回答出来。所以,今天花了点时间,研究了一下这方面的内容。这篇博客就来简单说一说保证网络传输安全性的一些方式。


    二、正文

    2.1 安全传输需要解决的问题

      先有问题,才有解决方案,所以我们先来讨论一下,网络传输中,需要解决哪些问题,才能保证安全。需要解决的问题大致有如下三个:

    1. 发送方鉴别:确保接收到的数据,确实是由我们认为的那个人(或主机)发送来的,而不是其他人以虚假身份发送的;
    2. 报文完整性:确保我们接收到的报文就是发送方发送的初始报文,而没有被第三方进行篡改;
    3. 数据机密性:确保报文即使被其他人截获,也无法读出其中的信息,也就是要对数据加密;

      如果上面三个问题都得到了解决,那我们基本上就可以保证数据传输是安全的。下面我们就针对上面三个问题,来谈一谈解决方案。


    2.2 非对称加密与对称加密

      在网络安全中,有两个非常重要的概念,就是对称加密非对称加密,后面要谈的所有方案,都离不开这两种机制。所以,在了解具体解决问题的方案前,我们先来了解这两个概念。

    (一)对称加密

      对称加密的原理很简单,就是数据的发送方和接收方共享一个加密数据的密钥,使用这个密钥加密的数据,可以使用这个密钥进行解密。而这个密钥是隐私的,只有数据的发送方和接收方知道,这也就意味着,其他人如果截获了数据,由于这个数据使用了密钥加密,而它没有这个密钥,所有无法解析出原始数据。

    (二)非对称加密

      非对称加密系统中,参与加密解密的共有两个——公钥私钥,使用私钥加密的数据,只能用公钥解密,而使用公钥加密的数据,只能用私钥解出。在非对称加密系统中,每一台主机都有自己的私钥和公钥,私钥只有自己知道,而公钥是公开的,可以让所有主机知道。发送方在发送数据时,使用接收方的公钥进行加密,而接收方使用自己的私钥进行解密,即可完成隐私的数据传输。如果数据被其它人截获,但是因为它没有接收方的私钥,所以无法解析出数据。

      非对称加密能够工作的一个前提是,必须确保发送方拿到的公钥,就是接收方的公钥,而不是其他人发送来的假公钥,如果公钥是假的,那么这个机制也就失去了意义。在实际应用中,解决这个问题的方式就是,每一台主机的公钥和私钥,都是由官方机构所分配的,这些机构被称为认证中心CA)。CA在分配公钥私钥时,会严格地验证身份,然后对身份进行绑定,而我们在获取公钥时,通过CA获取,即可保证获取到的公钥就是接收方的。

      需要注意的一点是,非对称加密的效率一般比较低,而对称加密的效率相对较高。下面,开始正式讨论解决上面三个问题的方案。


    2.3 解决数据机密性

    (一)非对称加密

    1. 发送方获取接受方的公钥,使用公钥对需要发送的数据进行加密,然后发送;

    2. 接受方接收到后,使用自己的私钥进行解密,解析出数据;

    总结:因为只有接受方知道自己的私钥,所以只有接受方能读出数据。但是,非对称加密的执行效率比较低,所以每一次数据传输都使用非对称加密,响应速度将会比较慢


    (二)非对称加密 + 对称加密(多次传输)

      为了解决非对称加密效率较低的问题,我们可以使用对称加密,但是同步对称加密的密钥,却需要依赖于非对称加密:

    1. 发送方随机生成一个密钥,然后获取接受方的公钥,使用公钥加密这个密钥,发送给接受方;

    2. 接收方接收到加密的密钥后,使用自己的私钥解析出密钥,此时双方就完成了密钥同步;

    3. 之后双方发送的所有数据,都可以使用这个密钥进行加密解密;

    总结:由于私钥只有接收方自己知道,所以这个密钥不会被其他人截获;同时使用对称加密的速度,要高于非对称加密,所以解决了上一个方案效率不高的问题;需要注意,一般密钥都比较短,所以使用非对称加密对密钥进行加密,一般比直接加密数据更快,而且只需要进行一次,所以速度能够显著提高

      HTTPS依赖于SSL保证数据传输的安全性,而SSL就是使用类似机制。


    (三)非对称加密 + 对称加密(单次传输)

      如果发送方只是需要向接收方发送一次数据,那先进行一次密钥同步可能有些浪费时间,可以使用如下方案解决:

    1. 发送方随机生成一个密钥,然后使用这个密钥对数据进行加密;

    2. 发送方使用接收方的公钥对数据密钥进行加密,然后将加密的数据和加密的密钥发送;

    3. 接收方首先使用自己的私钥解析出密钥,然后使用解析出的密钥将数据解析出来;

    总结:此方案适合于进行单次数据发送,因为不需要进行密钥的同步,而是将密钥与数据一同发送;同时,这个密钥使用了接收方的公钥加密,所以这个密钥只有接收方自己能解析出来,而其他人解析不出密钥,自然无法解析数据;


    2.4 同时解决发送方鉴别和报文完整性

      下面我们来说说解决发送方鉴别和报文完整性的方案。有一个经典的方案能够同时解决这两个问题,其过程如下:

    1. 发送方使用一个hash算法(如MD5SHA-1),计算需要发送的数据的hash值;

    2. 使用自己的私钥,对计算出的hash值进行加密;

    3. 将原始数据和加密后的hash值发送到接收方;

    4. 接收方使用发送方的公钥解析出加密后的hash值;

    5. 使用与发送方相同的hash算法,计算接收到的数据的hash值,与解析出的hash值进行比较;

    6. 若这两个hash值一致,表示这个数据并没有被篡改;

    总结:

    1、首先,hash值是用发送方的私钥加密,私钥只有发送方自己知道,如果接收方能够使用发送方的公钥解密,那就说明这个数据就是预期中的发送方发的,不可能是其他人发的,于是完成了发送方鉴别;

    2、接收方使用同样的hash算法,计算原始数据的hash值,如果这个hash值与解密后的hash值一致,则就能保证这个数据没有被篡改;

    上面两步中,但凡有一步出现了错误,就认为这是一个脏数据;

      这个方案被称为数字签名。为什么是计算出hash值,对hash值加密,而不是直接使用私钥对数据加密?这是因为hash值比较小,加密解密比较快。


    2.5 同时解决三个问题的方案

      上面提到的三个问题中,但凡有一个没有解决,数据传输都是不可靠的,这里我们就通过上面提到的几个办法,来同时解决三个问题。办法很简单,直接将上面解决方案进行整合即可:

    1. 首先,我们使用2.4中所提出的办法,对数据进行处理,也就是计算hash,然后使用自己的私钥加密hash

    2. 然后,将第一步计算出的hash与原始数据组合,使用2.3中提出的非对称加密 + 对称加密的方式,进行加密,加密之后再进行发送,保证数据的隐秘性;

    3. 接收方接收到数据后,使用2.3中的过程对数据解密,得到原始数据和加密后的hash

    4. 使用2.4中的方式完成发送方鉴别以及数据完整性校验;

    总结:上面的方式非常简单,就是将我们之前提过的加密,以及2.4中的方案组合,以此来同时解决三个问题。这是一个非常常用的方案,比如安全的邮件传输协议的实现就使用了类似方案。


    2.6 解决发送方鉴别的其他方案

      假设接收方和发送方有一个共享的密钥,则可以使用以下方式进行身份鉴别:

    1. 发送方向接收方发送自己的身份,比如发送一个“我是xxx”;

    2. 接收方为了验证不是其他人发送的虚假数据,向发送方发送一个随机数,这个随机数短时间内不会重复;

    3. 发送方使用它们共享的密钥,对这个随机数加密后发回接收方;

    4. 接收方接收后,使用密钥解密,如果确实是自己之前发送出去的随机数,即可确认对方身份;

      这里存在的问题是如何让接收方和发送方有一个共享密钥,其实就可以通过2.3节中第二个方案提到的,使用非对称加密的方式同步密钥。

    总结:

    1、由于密钥只有发送方和接收方知晓,所以如果发送方能够将加密后的随机数发回,即可确认它的身份;

    2、为什么不直接使用加密后的身份信息发送,而是使用随机数?因为如果这个加密后的身份数据被截获,其他人不需要进行解密,只需要向接收方发送这个加密后的身份,即可伪造自己的身份;


    2.7 解决数据完整性的其他方案

      假设发送方和接收方有一个共享的密钥,则可以使用如下步骤保证数据完整性:

    1. 发送方将原始数据与密钥拼接,然后计算拼接后的hash值,将这个hash值与原始数据一同发送;

    2. 接收方接收到后,同样将原始数据和密钥拼接,并计算hash值,然后与发来的hash值比较;

    3. hash值一致,可以保证这个数据没有修改,否则就是被篡改的数据;

    总结:由于拼接进原始数据的密钥只有传输双方知道,这个hash值只有它们双方能计算出来,所以如果hash值不一致,即可认为数据是有问题的。

      这个方案叫报文鉴别码,和前面提过的数字签名有些类似,但是不同的是,这个方案中,并不需要对发送的数据进行加密,只是计算hash作为鉴别码,只要保证密钥不被窃取,即可保证数据的完整性。


    2.8 如何防止发送方自己发送虚假数据

      需要注意的一点是,我们上面所提出的方案,都是针对第三方侵入的解决方法,也就是防止除发送方和接收方外,有其他人对数据传输做手脚。但是,如果发送方自己篡改数据,或伪造数据,然后发送,这应该怎么解决呢?接收方如何能够识别出接收到的数据就是原始数据,而不是发送方自己篡改或发送的虚假数据呢?这是我最近一直在想的问题。

      在这种情况下,我们需要考虑的是,发送数据的用户可以做到什么程度?由于发送数据的设备就在发送者手上,是不是意味着数据发送过程中的密钥等信息,用户是可以通过一些手段看到的?如果是可以,那上面所说的机制应该就没法保证安全性了。但是,本人水平有限,并不清楚有户对于发送到自己设备上的数据,可以窃取到什么程度。希望了解这个问题的人能够为我解答。

      当然,上面的机制可能没办法保证完全可靠,但是也有很大的效果。比如说报文鉴别码就能解决用户自己篡改自己的数据这个问题。如果用户没有获取到密钥,则它自然无法发送虚假数据,因为没有密钥就没有办法计算出虚假数据的hash。虽然用户可能可以通过一些手段,获取到这个密钥,但是过程是应该是非常复杂的,这就对窃取的技术要求非常高,所以在大部分情况下可以保证数据不被篡改。

      说实话,对于用户自己发送虚假数据这个问题,由于我知识水平不足,一直无法想清楚,网上也没有找到相关的资料,所以上面的描述都是基于我目前的理解。如果有了解这个问题相关知识,以及解决方案的,麻烦告知。


    三、总结

      以上就对数据的安全传输方案做了一个大致的介绍,归根到底,就是基于数据隐秘性,报文完整性以及发送方鉴别这三个问题,这三者缺一不可,只有全部解决,才能保证传输的可靠。

      希望上面的内容对需要了解这一方面的人有所帮助,若存在错误或不足,也欢迎指正。


    四、参考

    • 《计算机网络——自顶向下方法(原书第七版)》
  • 相关阅读:
    Oracle 推出 ODAC for Entity Framework 和 LINQ to Entities Beta版
    Entity Framework Feature CTP 5系列文章
    MonoDroid相关资源
    MSDN杂志上的Windows Phone相关文章
    微软学Android Market推出 Web Windows Phone Marketplace
    使用 Visual Studio Agent 2010 进行负载压力测试的安装指南
    MonoMac 1.0正式发布
    Shawn Wildermuth的《Architecting WP7 》系列文章
    使用.NET Mobile API即51Degrees.mobi检测UserAgent
    MongoDB 客户端 MongoVue
  • 原文地址:https://www.cnblogs.com/tuyang1129/p/12891346.html
Copyright © 2011-2022 走看看