上层认证的安全协议 __〈无线局域网安全务实：WPA与802.11i〉读书笔记

 上层认证
 
         在2.2节里，我们谈到定义了3个主要的安全层：无线局域网层，接入控制层和认证层。IEEE 802.11工作在无线局域网层，IEEE802.1X, EAP, RADIUS工作在接入控制层，认证层使用的是上层认证协议，它是不依赖于LAN技术的。在RSN中，上层认证协议有很多种，比如TLS, SSL和Kerberos V5。在WPA中指定使用TLS作为认证方法。
 
3.1 上层认证中的密钥
  • 对称密钥，加密和解密都使用一个相同的密钥。在认证过程中，每个成员都向认证方证明他们知道这个密钥。当成员验明身份后，他和认证方就能够创建用于安全上下文的两者相互匹配的会话密钥，这种密钥是由主密钥导出的，它也可能附带其他信息，比如时间和创建会话密钥（称为临时密钥）时产生的任意数据。附带这些额外信息的目的是为了保证临时密钥只能在当前会话中使用，此后不能再次使用。
  • 非对称密钥，加密和解密不是使用一个相同的密钥， 有公钥和私钥之分。公钥和私钥的副本在数字上是相关联的。用公钥进行加密的文件，要用私钥进行解密，且用公钥是不能解密的；用私钥加密的文件，要用公钥进行解密，且私钥是不能解密的。公钥是公开的，所有人都可以得到它，而私钥是私有的，具有唯一性。
 
      认证权威机构（Certification Authority, CA)是一个可信任的第三方机构，它为使用PKI(public key infrastructure)的客户颁发一系列的公钥和私钥。就像公安局为了认证一个人的身份而发放身份证一样，CA向它的客户们发放数字证书，该数字证书包括客户的基本信息和客户的公钥，并且CA会用自己的私钥在数字证书上签名。
      一个网站可以通过CA购买一个证书（其实就是一串数字），将它和公司网址绑定在一起，当有用户访问该网站时，网站就会将自己的证书发送给用户；用户的浏览器将查看这个证书并确认发送者的身份。如果这个证书是一家有名的CA发布的，浏览器很可能将发送者识别为一个值得依赖的证书，如果不是，它就行告知用户这不是一个值得依赖的证书，并提示是否继续。由于证书中有该网站的公钥，所以浏览者可以用该公钥加密信息，发送给网站的服务器，网站服务器可以用自己的私钥对信息进行解密。
        如何保证该证书是由CA发布而不是伪造的呢？因为该证书是用CA的私钥签名的，所以通过该CA的公钥解密签名就可以证明确实是由该CA签发的。浏览器可能会发送信息到CA进行核对。
 
3.2 传输层加密（TLS, Transport Layer Security)
 
       在Internet早期发展中，Netscape公司是浏览器的主要设计者。随着网络的商业潜能逐渐呈现，网上交易安全成了主要问题，Netscape公司为了解决这个问题，开发一种安全方法SSL(Socket Security Layer)。
        SSL基于数字认证的基础上，它嵌入Netscape浏览器中，它最终成为了安全网络事务处理的一个标准方法，在鉴别一方或双方后，建立一条具有加密和完整性检验功能的专用通道。但是SSL毕竟是属于一家公司的专有方案，人们更期待一种建立在国际标准上的技术，因此IEFT决定对SSL进行标准化。在1999年发布的RFC2246标准中，提出了TSL协议，它是基于Netscape公司发布的SSL3.0协议规范之上的。但是RFC中指出，两者是有区别的，不能直接互通。TSL只是和传输协议层密切相关，它是建立在TCP/IP协议这上的，所具体浏览器或电脑系统或插口无关。
3.2.1 TLS的功能
 
      TLS提供的全部服务包括认证、加密和基本的数据压缩功能( 但是目前为止TLS的数据压缩功能一直未用）。TLS介于应用层和TCP层之间，应用层数据行传递给TLS层，TLS层对数据进行加密并增加自己的头。SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。
但是，这里有两个问题。
 
（1）如何保证公钥不被篡改？
 
解决方法：将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。
 
（2）公钥加密计算量太大，如何减少耗用的时间？
 
解决方法：每一次对话（session），客户端和服务器端都生成一个"对话密钥"（session key），用它来加密信息。由于"对话密钥"是对称加密，所以运算速度非常快，而服务器公钥只用于加密"对话密钥"本身，这样就减少了加密运算的消耗时间。
 
因此，SSL/TLS协议的基本过程是这样的：
 
（1） 客户端向服务器端索要并验证公钥。
 
（2） 双方协商生成"对话密钥"。
 
（3） 双方采用"对话密钥"进行加密通信。
 
上面过程的前两步，又称为"握手阶段"（handshake）。
          TLS分为两层：握手协议和记录协议
3.2.2 握手协议
           握手协议： 是client和server用TLS通信时使用的第一个子协议，也是最复杂的子协议。该协议允许服务器和客户机相互验证（但一般是只验证服务器不验证客户），协商加密和完整性算法以及会话密钥，它是在应用程序的数据传输之前使用的。整个握手阶段都不加密，都是明文的.
 
             
 
  1. Client hello消息
       包括客户端可以支持的TLS最高版本号（version),
         一个用于生成主密钥的32字节的随机数（random)，
         一个确定会话的会话ID，一个客户端可以支持的密码套件列表（cipher suite)，密码套件格式：每个套件都以TLS开关，紧跟着的是主密钥生成算法，然后是“WITH”，后面是数据加密算法和散列算法，例如TLS_DHE_RSA_WITH_DES_CBC_SHA，表示把DHE_RSA定义为主密钥生成算法，把DES_CBC定义为数据加密算法，把SHA定义为散列算法；
        一个客户端可以支持的压缩算法列表
  1.    Server hello 消息
       server用server hello消息进行应答，包括以下内容：
         一个TLS版本号。取客户端支持的最高版本号和服务端支持的最高版本号中的较低者
       一个用于生成主秘密的32字节的随机数。（客户端一个、服务端一个）
       session ID 与client hello中session ID相同
       从客户端的密码套件列表中选择的一个密码套件
       从客户端的压缩方法的列表中选择的压缩方法
  1.   服务器是本阶段所有消息的唯一发送方，客户是所有消息的唯一接收方。该阶段分为4步:
     Certificate:服务器将数字证书发送给客户端，使客户端能用服务器证书中的服务器公钥认证服务器，由于certificate比较大，所以数据可能会分包发出；
      服务器密钥交换（可选）：这里根据主密钥生成算法而定
      证书请求（可选）：服务器可能会要求客户自身进行验证
      服务器握手完成（Server Hello Done):没有具体内容
           
  1.      客户端回应，客户端是本阶段所有消息的唯一发送方，服务器是所有消息的唯一接收方，该阶段分为3步：
          证书（可选）：为了对服务器证明自身，客户要发送一个证书信息，这是可选的。
             客户端预主密钥交换（PreMaster Secret):客户端将预主密钥发送给服务端，注意这里会使用服务端的公钥进行加密。
           证书验证（可选），对预备秘密和随机数进行签名，证明拥有（a）证书的公钥。
 
             客户端收到服务器回应以后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息。
 
（1） 一个随机数。该随机数用服务器公钥加密，防止被窃听（PreMaster Secret)
 
（2） 编码改变通知(Change Cipher Spec)，表示随后的信息都将用双方商定的加密方法和密钥发送。
 
（3） 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。
 
             上面第一项的随机数，是整个握手阶段出现的第三个随机数，又称"pre-master key"。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把"会话密钥”。。为什么需要三个随机数：
"不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。
 
对于RSA密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。
 
pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么仅适用pre master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。"
 
此外，如果前一步，服务器要求客户端证书，客户端会在这一步发送证书及相关信息。
 
  1. 服务器的最后回应
           服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的"会话密钥"。然后，向客户端最后发送下面信息。
（1）编码改变通知(change Cipher Spec)，表示随后的信息都将用双方商定的加密方法和密钥发送。
 
（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。
 
             至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用"会话密钥”加密内容。
如果正在恢复TLS会话，客户端和服务器会从开始消息直接跳到结束消息，从新的随机数（包含在hello消息中的）和旧的主密钥计算出新的主密钥。这个过程避免了“昂贵的”认证操作，但仍能阻止伪造的客户和服务器，因为旧的主密钥只在原来的客户端和服务器拥有。
        
   可以用CloudFlare与vistor之间的过程说明这个握手协议的整个过程;
           
 
3.2.2 session的恢复
          握手阶段用来建立SSL连接。如果出于某种原因，对话中断，就需要重新握手。这时有两种方法可以恢复原来的session：一种叫做session ID，另一种叫做session ticket。
 
  • session ID的思想很简单，就是每一次对话都有一个编号（session ID）。如果对话中断，下次重连的时候，只要客户端给出这个编号，且服务器有这个编号的记录，双方就可以重新使用已有的"对话密钥"，而不必重新生成一把。
         
          上图中，客户端给出session ID，服务器确认该编号存在，双方就不再进行握手阶段剩余的步骤，而直接用已有的对话密钥进行加密通信。
  • Session Ticket
             session ID是目前所有浏览器都支持的方法，但是它的缺点在于session ID往往只保留在一台服务器上。所以，如果客户端的请求发到另一台服务器，就无法恢复对话。session ticket就是为了解决这个问题而诞生的，目前只有Firefox和Chrome浏览器支持。
         
              上图中，客户端不再发送session ID，而是发送一个服务器在上一次对话中发送过来的session ticket。这个session ticket是加密的，只有服务器才能解密，其中包括本次对话的主要信息，比如对话密钥和加密方法。当服务器收到session ticket以后，解密后就不必重新生成对话密钥了。
 
3.2.3 记录协议
        记录协议在客户机和服务器握手成功后使用，即客户机和服务器鉴别对方和确定安全信息交换使用的算法后，进入SSL记录协议，记录协议向SSL连接提供两个服务：
 
　　（1）保密性：使用握手协议定义的秘密密钥实现
 
　　（2）完整性：握手协议定义了MAC，用于保证消息完整性
 
　　记录协议的过程：
          其实TLS握手协议也使用记录协议来发送信息。初始阶段时，记录协议只是向前明文传递数据，不进行数据加密和压缩。在经过握手协议得出加密数据的密钥之后，记录协议就用来发送加密了的数据。 
posted @ 2017-06-05 18:50  sun sun  阅读(362)  评论(0)  编辑  收藏  举报