网络安全(1)-身份认证

网络数据安全

    现在在网络上两个节点A和B之间进行通信的时候，数据包经过的路径上很有可能会有很多的路由节点。在这些中间路由节点上，A和B之间的IP包是完全可以被截获、修改、甚至丢弃的，因此在网络上的数据传输并不安全，或者说基本的网络7层协议并不确保数据传输的安全性。 
    数据的安全传输对用户来说意义重大，显然，没有用户愿意忍受自己所发送的每一段消息、传输的每一份文件都有可能被另外一个不相干的人偷窥。因此，在不安全的网络上构建安全的通信非常重要。 
    要在网络上进行数据的安全传输，主要需要实现两个方面： 
（1）身份认证，用于确定你数据的来源是你预想的。 
（2）数据加解密，用于对传输的数据进行加解密。 
（3）数据完整性校验，用于防止数据被篡改。

身份认证

    身份认证是对数据的来源进行确认，比如用户A和用户B通过网络传输数据，他们都希望自己收到的数据是来自B和A，而不是由其他人伪造的；某机构发布了一个文件，用户A从网上下载了该文件，他希望该文件确实是由该机构发布的，这些都可以通过身份认证来得到保证。 
    现在常用的身份认证方法是使用证书。 
1、证书使用 
    证书就是一个公私钥对中的公钥（公私钥在后续RSA中会具体讲），公私钥是非对称加解密的实现方式，公钥加密的数据，只有对应的私钥才能解密，反之亦然。 
如果某机构申请了一张属于自己的证书，然后向互联网用户公开该证书，用户如果接受，则将证书存在电脑中。之后该机构在发布数据的时候，带上签名，签名可以是一个明文字符串X+经过该机构私钥对X加密后的结果Y。当用户收到数据之后，通过该机构公开的证书（公钥）对签名中的Y进行解密得到Z，如果此时Z和X相等，则可以判定该数据确实是由该机构发布的。<私钥加密，公钥解密>

2、证书申请/颁发 
    颁发证书crt，颁发证书当然不是谁想干就能干的，这得有专门的证书颁发机构来执行这项权利。CA(Certificate Authority,证书授权中心)是负责管理和签发证书的机构的第三方机构，一般是权威可信的、经过国家认证的部门。 
    如果某机构或网站想要一个证书用于向用户证明自己的身份，它首先要想CA申请，CA如果同意申请，会签发一张证书给该机构。此时该机构或网站有了证书，它向网络用户公开的时候，怎么让人们相信这张证书确实是CA颁发的而不是自己伪造的呢？首先，CA是权威机构，它自己也有证书，且证书一般都会被用户接受存放在电脑中；然后，CA在证书的末尾会添加一段签名（和上面的X加密得到Y一个道理），用户在收到新颁发的证书之后会通过自己电脑中存放的CA机构的证书去解密从而可以校验该证书是否是CA颁发。

3、证书层级与信任链 
    证书是分层级的，每份证书（除了根证书）都会指定其上级CA（颁发该证书的CA）的名字，系统根据名字定位到系统中的CA证书；其上级CA的证书也会指定其对应的再上一级CA的名字.....直到根证书，根证书是不需要证明的。 
-windows系统自带了一些CA证书，大部分是美国的CA颁发，中国用户应该先安装一个工信部的根证书，该证书应该是美国的CA签发，国内的其他机构再向工信部申请证书。 
    根证书一定是可信的，这是证书安全体系的根本。根证书信任的那些证书也应该是安全的，根证书信任的那些证书信任的证书也应该是安全的，这样一级一级往下传.... 如果中间有证书不遵守规则，信任了不安全的证书，那么后续的证书链均有可能不安全......比如前段时间支付宝偷偷在用户的电脑里添加根证书，这种行为私自修改的信任链规则，添加的根证书可能会信任一些不安全的证书，从而给系统带来隐患。

使用证书进行身份认证

使用公开的证书

    https协议中，浏览器就是通过证书来验证服务器是否合法的。 
    服务器首先会向CA申请证书（如果没有向CA申请，则在访问的时候浏览器会提示用户是否信任该服务器提供的证书）；浏览器在访问https服务器的时候，https服务器最开始就将自己的证书发送给浏览器，如果服务器的证书是向CA申请过的，浏览器可以通过本地机器上CA的证书对服务器的证书进行确认（通过CA的公钥进行解密，判断签名是否一致）；如果服务器的证书没有向CA申请过，则浏览器会发出警告，此时可以将该证书添加到“受信任的根证书颁发机构”存储区，就不会再收到安全提示了（当然要确定该网站确实没有问题）。 
    确认了证书没有问题之后，我们怎么确定证书确实是由服务器发送过来的，而不是另外一个网站提前获得了证书，然后再发给浏览器的呢？（如果是那样，则说明浏览器建立连接的对象搞错了。之后即使浏览器进行对称加密的密钥不会被假冒的服务器获得，因为浏览器会用正确网站的证书公钥加密，而只有拥有私钥的正确的网站才能够解密，但是至少浏览器无法正常的通信...) 
    可以这样，浏览器先随机生成一个字符串，然后传送给服务器，服务器用私钥加密，并将加密之后的结果返回给浏览器，浏览器用公钥解密，查看是否是之前随机生成的字符串。假冒的服务器没有私钥，因此无法对字符串进行正确的加密，从而浏览器会得出错误的结果。这样，就可以通过证书验证对方就是真正的服务器。 
    当然，上面的过程也可能被一个假冒的服务器破坏：浏览器发送字符串给假冒的服务器，假冒的服务器没有私钥因此无法加密，但是它可以直接将字符串发送给真正的服务器，真正的服务器返回结果之后再将结果转发给浏览器，这样仍然可以欺骗浏览器让它以为自己是和真正的服务器在通信。但是，这样做对假冒服务器来说除了破坏了浏览器的通信之外，并无法获取、篡改机密信息，因为浏览器在建立和服务器（无论是真正的服务器还是假冒的服务器），都会再生成一个对称加密的密钥，之后在通信的时候都使用这个密钥进行加密，而只有真正的服务器才能够通过私钥解开这个密钥，假冒的服务器除了获得加密之后的数据之外，其他什么也做不了（当然，它可以修改数据，但是这可以通过数据的完整性校验被发现）。因此，只要身份认证没有问题，中间人攻击就无法进行。

使用预设置的证书

    在搭建vpn服务器的时候，也可以通过手动在本地存储对方服务器的证书，从而在之后进行双方服务器的身份认证。服务器都先在本地生成公私钥对，然后将公钥拷贝到对方的机器上，这样之后在进行通信的时候，就可以使用公私钥对来进行身份确认。

使用临时分配的证书

    有可能通信双方需要临时在网络上交换公钥，他们网络比较安全，交换的公钥并不会被窃取，但实际并不是这样，此时就会出现一种更为可怕的中间人攻击：

假如A和B认为，任何网站都是不可靠的，他们从未并且今后也不会在网上公布自己的公钥。为了加密通信，A需要亲自告诉B他的公钥，B也需要亲自告诉A自己的公钥。收到公钥后，双方便用对方的公钥加密进行数据传输。因为用这个公钥加密后，只有对方才能解开密码，因此双方都认为这条通信线路是安全的。其实，他俩的麻烦大了。这条线路并不是安全的，第三者可以用一种很搞笑的方式来窃听消息。假设有一个人C知道A和B之间将有一次加密通话。C劫持了A和B之间的通讯线路。现在，A把他的公钥发给B，这个公钥传到一半时被C拦截下来，于是C获得了A的公钥；C再把他自己的公钥发给B，让B把C的公钥错当成A的公钥。同样地，B把他自己的公钥发给A，被C拦截下来。C把自己的公钥发给A，让A以为那是B的公钥。以后，每当A给B发加密消息时，A其实是用C的公钥在加密；C把A的消息解密后，再用B的公钥加密后传给B。类似地，一旦B给A发送消息，C都可以将消息解密，并用A的公钥进行加密后传过去。此时，A和B都以为自己在用对方的公钥加密，并都能用自己的私有钥匙解开对方传来的密文；殊不知，这中间有人仅仅用了一点雕虫小技，无声无息地窃走了所有的信息。C正是利用了公钥加密术“谁都可以加密”的性质，结结实实地玩弄了A和B。

    那么，如何防范这种中间人攻击呢？

中间人之所以能够得逞，关键就是，无论是网络通话还是国际象棋，双方总是一先一后地发送信息。不过，在网络通讯中，我们有一种很特别的办法，他可以迫使中间人无法再扮演“即时翻译”的角色。首先，A把想说的话（最好是能够证明自己身份的话）进行加密，同时B也完成相同的工作。然后，A把他的加密消息的前面一半传给B，B收到后也把他的密文的一半传给A；A再把剩下的部份传给B，之后B也把他的密文的另一半回传给A。此时，A和B分别用自己的私钥进行解密，查看对方发来的消息。这带给中间人C一个不可逾越的障碍：两段密文要合在一起才能解开，中间人拿着其中一半密文，那是一点办法都没有。此时，中间人陷入了一个非常窘迫的境地，他只有两条路可选：要么硬着头皮把这半截密文发给B，当B得到全部密文后会发现用他自己的私钥根本解不开，从而意识到中间有人捣乱；要么就忽略这半截密文，自己编几句A想跟B说的话，用B的公钥加密并发一半给B。如此一来，中间人需要编造所有A和B之间的对话，这需要相当厚的脸皮，风险异常之大，要不了多久便会露出马脚。

参考

身份验证、中间人攻击和数字签名：浅谈密码学（中）