SSL/TLS协议簇加解密流程

一、概述

      SSL协议是最早Netscape公司开发的安全通信协议,用于浏览器安全通信。到SSL Version3,提交作为IFTF草案,已经广泛的应用Intetnet通信。之后IETF对SSLv3稍作改动并更名为TLS1.0,对应RFC2246,之后的TLS1.1、TLS1.2先后被接受为RFC4346,RFC5246,另外由于TLS是基于TCP协议设计,导致其不能处理独立纪录,不允许SSL时有数据丢失,在RFC4347中提出了一种“Datagram TLS”---DTLS,可以理解为TLS1.1的分支。

      SSL/TLS协议的设计目标是保证数据的机密性和完整性。因此在SSL/TLS协议中包含了3类算法:对称加密算法(保证机密性),数据签名算法(保证完整性)和公钥算法(用于交换密钥)。下面以TLS1.0为基准介绍SSL/TLS协议簇加解密流程。

二、加解密流程

      SSL/TLS协议的基本数据交互流程如下图:

      加解密流程详细介绍如下:

SSL-TLS

      Client Hello :表示客户端向服务器发起SSL握手请求。

      客户端:生成一个32byte的random用于计算主密钥、加密密钥和消息的数字签名。在cipher suites中指明自己支持的对称加密、非对称加密和数字签名算法。

     

      Server Hello:表示服务器相应客户端的SSL握手请求。

      服务器端:生成一个32byte的random用于计算主密钥、加密密钥和消息的数字签名。生成一个23byte的SessionID。在client cipher suites中挑选一个加密强度最高的算法组合,作为双方的通讯的算法。

      如TLS_RSA_WITH_AES_128_CBC_SHA表示通讯协议时TLS、非对称加密算法为RSA、对称加密算法为AES_128_CBC、数字签名算法为SHA。

     

      Certificate:服务端证书。

      服务器端:如果服务端证书是Base64编码,首先把证书进行Base64解码,得到的是使用ASN.1格式编码的X.509证书。

      证书中的信息包括:无标题

     客户端:根据收到的证书,判断其合法性,并计算得到服务器的公钥(对于RSA算法,是解析得到n和e,对于DH算法解析得到a和q)。

     证书合法性的判断方法:

     ~颁布者的合法性(hash值)

     ~有效期

     ~签名值是否合法:首先对证书中除签名值部分的内容按照证书中的签名

     算法进行签名,把得到的签名按照asn.1编码方式进行编码:OBJECT格式的签名算法+ ASN_OCTET_STRING格式的签名值A;把证书中的签名值按照证书中的主体公钥算法进行解密得到B;当A和B完全相同时认为证书有效(证书制作过程中的签名值计算方法:计算得到A,和客户端计算方法相同,用服务器私钥对A进行加密,得到证书中的签名值)

      一般情况下客户端收到的是一个证书链,第一个是服务器的证书,之后是服务器证书签发者。。。最后是自签名的根证书。如下图。在实际解析中先要验证根CA的证书,然后是直接证书签发者证书,最后是服务器终端证书。clip_image002

     Certificate Request:当服务器需要验证客户端证书时使用。

    

     Server Key Exchange:用于交换对车密钥,只有在使用RSA扩展选项或者DH算法时才会使用。

 

     Server Hello Done:表示握手消息结束。

 

     Client Key Exchange:交换预主密钥。

     客户端:

           RSA算法:

                 随机生成48byte的预主密钥,把48byte的第一个字节设置成主版本号,第二个字节设置成次版本号。用步骤2中协商得到的非对称加密算法进行加密。传递给服务器端。

           DH算法:

                得到随机数Xc,计算得到Yc,把Yc通过Client Key Exchange消息明文传递为服务器端;根据a,q,Xc,Ys计算得到预主密钥。

     客户端和服务器端都需要根据预主密钥计算得到主密钥、加密密钥和签名密钥,方法如下:

          RSA算法:     

                接到客户端加密的预主密钥,按照非对称密钥进行解密,得到预主密钥。然后按照PRF算法计算得到主密钥。(生成主密钥的算法SSL和TLS略有不同。)

          DH算法:

                根据a,q,Xs,Yc计算得到预主密钥。

          根据预主密钥计算得到主密钥的算法(PRF算法):就是带密钥的MD5签名算法和带密钥SHA签名算法得到的结果异或得到的。

         MD5:

              密钥:预主密钥的前24byte,签名文本:字符串“master secret”+服务器端32byte的random + 客户端32byte的random,生成48byte的MD5Hash值

         SHA:

             密钥:预主密钥的后24byte,签名文本:字符串“master secret”+服务器端32byte的random + 客户端32byte的random,生成48byte的SHAHash值

         得到主密钥:MD5Hash XOR SHAHash

         最后根据主密钥计算的到6个实际使用的密钥:client_write_MAC_secret;server_write_MAC_secret;client_write_key;server_write_key;client_write_IV;server_write_IV;

         计算方法和计算主密钥的方法类似,都使用PRF算法。不同的是提供给MD5和SHA的密钥是主密钥,最后生成的Hash长度为148。然后把148byte的Hash依次赋值给上述6个实际密钥。

     Change Cipher Spec:表示之后的消息传输都将采用对称加密方式进行。

 

     Encryted HandShake Message:加密的Finish报文,用于验证双方协商的对称加密算法、客户端密钥。

 
    ~客户端给服务器发送的Finished报文:

          客户端:对字符串“client finished”应用PRF算法:MD5和SHA的密钥是主密钥,加密的密文是SSL握手以来所有消息的串联,生成的Hash值为12Byte;对生成的12byte应用HMAC算法,算法的密钥是client_write_MAC_secret,把计算得到的MAC值添加到Hash后面;如果是对称加密算法是块加密算法,那么还需要填充pad。最后用第2步中协商的对称加密算法对上述数据进行整体加密,加密密钥是前面中计算得到的client_write_key。

         服务器端:首先用密钥为的client_write_key对称加密算法对数据进行解密,计算字符串“client finished”的MAC值和客户端发送过来的12byte进行比较,相同则认为client_write_key的对称加密正确,再用client_write_MAC_secret计算MAC值,和客户端的数据进行比较,如果相同则认为client_write_MAC_secret正确。

    ~服务器给客户端发送的Finished报文:

    和客户端给服务器发送的Finished报文类似,是对字符串“server finished”进行计算,用于验证server_write_key和server_write_MAC_secret。

  

    APP Data:加密数据。

    服务器端:首先根据client_write_key解密整个消息体,并对其中的实际数据部分进行HMAC(密钥为client_write_MAC_secret)并和客户端发送过来的MAC进行比较,如果相同则认为数据完整。

    客户端:首先根据server_write_key解密整个消息体,并对其中的实际数据部分进行HMAC(密钥为server_write_MAC_secret)并和客户端发送过来的MAC进行比较,如果相同则认为数据完整。

 

三、协议簇

    上节是以TLS1.0为基准进行说明,但是SSL/TLS协议簇内的协议之间有一定的差别。

3.1 SSL3.0

 

     生成主密钥

     TLS1.0使用了PRF算法,其核心是分别用MD5和SHA分别计算的到Hash,并把MD5Hash和SHAHash相异或得到主密钥;

     SSL的计算方法:把SHA计算得到的Hash作为MD5的输入,计算得到16byte的Hash值,重复计算3次,把3次计算得到的3个16byte的Hash拼接成主密钥。

     生成计算密钥

     区别同上

     数字签名算法

     对于加密数据的数字签名算法。

     TLS1.0使用了RFC2104定义的HMAC算法:HMAC:MAC = H(Key^oPad,H(Key^iPad , context))

     SSLv3使用的MAC算法和HMAC算法类似:MAC = H(Key+oPad, H(Key+iPad , context))

3.2 TLS1.1

     加密数据格式

     TLS1.0中块加密数据的格式为

     block-ciphered struct {

         opaque content[TLSCompressed.length];

         opaque MAC[CipherSpec.hash_size];

         uint8 padding[GenericBlockCipher.padding_length];

         uint8 padding_length;

     } GenericBlockCipher;

     TLS1.1块加密数据的格式为

     block-ciphered struct {

          opaque IV[CipherSpec.block_length];

          opaque content[TLSCompressed.length];

          opaque MAC[CipherSpec.hash_size];

          uint8 padding[GenericBlockCipher.padding_length];

          uint8 padding_length;

      } GenericBlockCipher;

      导致在块加密数据解码时有所不同。

3.3 TLS1.2

     生成主密钥

          默认使用SHA256代替PRF

     生成计算密钥

          默认使用SHA256代替PRF

阅读更多
个人分类: 网络协议
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭