无线传输层安全协议WTLS安全机制详解

  　　WTLS的作用是保证传输层的安全，作为WAP 协议栈的一个层次向上层提供安全传输服务接口。WTLS是以安全协议TLS1.0标准为基础发展而来的，提供通信双方数据的机密性、完整性和通信双方的鉴权机制。WTLS在TLS的基础上，根据无线环境、长距离、低带宽、自身的适用范围等增加了一些新的特性，如对数据报的支持、握手协议的优化和动态密钥刷新等。

        WTLS能够提供下列三种类别的安全服务：

                         i.              第一类服务：能使用交换的公共密钥建立安全传输，使用对称算法加密解密数据，检查数据完整性，可以建立安全通信的通道，但没有对通信双方的身份进行鉴权。

                       ii.              第二类服务：除完成第一类服务的功能外还可以交换服务器证书，完成对服务器的鉴别。

                      iii.              第三类服务：除完成第二类服务的功能外还可以交换客户证书，在服务器鉴别的基础上又增加了客户鉴别，对恶意的用户冒充也能进行抗击。

        从第一类服务到第三类服务安全级别逐级增高，可以根据应用对安全级别的要求选择性的实现某一级别的安全服务。通常应该对这三种类别的服务都能支持，在握手协商的过程中由客户端与服务端共同协商选定一个类别。

一 WTLS安全问题解决方法

1.    加密

        WTLS的保密性依靠加密通信通道来实现，所使用的加密方法和计算共享密钥所需的值在握手时进行交换。首先，客户端和服务器交换Hello消息，此后，客户端和服务器交换预主密钥（Pre master Secret），这个值用来计算主密钥（Master Secret），计算所使用的加密算法在服务器的Hello消息中进行选择。在这条消息中，服务器通知客户端已经选择了一个密码组，客户端向服务器提供一个密码组列表。如果服务器未发现合适的密码组，则握手失败，连接关闭。当前常用的大批量加密算法有：支持40、56和128位密钥的RC5，支持40和56位密钥的DES，支持40、56和128位密钥的3DES和IDEA。所有的算法都是分组加密算法，加密密钥在密钥分组的基础上进行操作，密钥分组根据协商的密钥刷新频率在一段时间后重新运算。

2.    密钥交换

        为了保证安全的联系通道，加密密钥或计算密钥的初始值必须以安全方式进行交换。WTLS的密钥交换机制提供了一种匿名交换密钥的方法。在密钥交换过程中，服务器发送包含服务器公钥的服务器密钥交换消息。密钥交换算法可能是RSA、Diffie-Hellman或Elliptic Curve Diffie-Hellman。在RSA和匿名RSA中，客户端用服务器的公钥加密预主密钥，并在客户密钥交换消息中将其返回给服务器。在基于Diffie-Hellman的算法中，客户端和服务器在一个私钥和相应的公钥基础上计算预主密钥。

        如果客户端列出了它所支持的用密码写的密钥交换方法，服务器可以选择是使用基于客户请求的方法，还是定义另一种方法。如果客户端并未提出任何方法，则服务器必须指明。

3.    鉴别

        WTLS的身份鉴别依靠证书实现。身份鉴别可以在客户端和服务器之间进行，也可以在服务器允许的情况下，只由客户端鉴别服务器，服务器还可以要求客户端向服务器证明自己。在WTLS规范中，身份鉴别是可选的。

        当前所支持的证书类型包括：X.509v3、X9.68 和 WTLS证书。在客户端和服务器之间交换Hello消息之后，鉴别过程随即开始。当使用鉴别时，服务器发送服务证书消息给客户端。根据WTLS规范，为了优化流量和客户处理，服务器一次只发送一个证书。服务器证书由CA公司独立分发的公钥进行鉴别。服务器也可以发送证书请求消息给客户端以鉴别之。此时，客户端发送客户证书消息返回给服务器，客户端证书遵循与服务证书相同的结构。

4.    完整性

        数据完整性通过使用消息鉴别编码(MAC)而得到保证， MAC算法同时也被认为是加密算法。客户端发送一列所支持的MAC算法，服务器在返回的Hello 消息中标出所选的算法。WTLS支持通用的MAC算法，MAC在压缩的WTLS 数据上产生。

5.    安全状态

        在安全协商后，会话通信双方将拥有同样的安全状态。当前状态通过安全参数产生，并持续更新。

二 WTLS协议结构

        WTLS工作在无线数据报协议(WDP)层和无线事务协议 (WTP)层之间，它所提供的服务对这两层协议来说是可选的。WTLS由功能协议层和记录协议层构成。其中功能协议层包含了握手协议、改变密码标准协议、 告警协议；记录协议层提供对握手协议层以及上层应用数据的封装结构，在客户端和服务端的WTLS对等层之间完成实际的数据传送任务。WTLS协议结构如图3-1所示

1.    记录协议(Record Protocol)

        本协议是一个从相邻层接收原始数据的协议，它仅在连接状态下运行。当开始一个安全会话时，连接状态初始化为NULL。逻辑上存在两种状态：当前状态和未决状态，记录在当前状态下处理。它将所接收到的数据进行压缩、加/解密、鉴别和数据完整性处理，然后向上层转交或向下层发送。本协议进行的有关处理完全按照在握手协议中通信双方所协商一致的处理流程和算法进行。

2.    握手协议(Handshake Protocol)

        所有与安全相关的参数都是在握手阶段协商一致的。这些参数包括：协议版本号、使用的加密算法、鉴别的信息和由公开密钥技术生成的密钥素材。握手阶段从客户方与服务方进行Hello消息应答开始，在两个 Hello消息中，通信双方商定一致的会话方式。当客户方发送Client Hello消息以后，它等待接收Server Hello Done消息。服务方如果需要鉴别，可以发一个代表自己的服务器证书给客户方，也可以要求客户方鉴别自己。Server Key Exchange 用于向客户方提供公开密钥。

        当客户方收到Server Hello Done消息后，返回Client Certificate 消息以让服务方鉴别自己。随后客户方发送一个Client Key Exchange消息，包含由服务方用公开密钥加密过的共享主密钥和其他一些信息，以使双方完成密钥交换。最后，客户方发送一个包含验证前面所有数据的Finished Message，服务方也同样发送一个Finished Message证实交换和计算的信息来回应客户方。此外，任何一方都可以发送一个Change Cipher Spec消息来决定双方使用的密码参数。

3.    告警协议(Alert Protocol)

        告警类型是WTLS记录层支持的内容类型之一，告警消息传送的内容为信息错误的严重程度及告警描述。记录协议的告警消息主要有警告、危急、致命三种。告警消息使用当前的安全状态发送，如果告警消息的类型是“致命”，则双方将结束安全链接。同时，其他使用安全会话的链接可以继续，但会话标识必须设成无效，从而使失败的链接不能被用于建立新的安全链接。当告警消息的类型为“危急”时，当前的安全链接结束，而其他使用安全会话的链接可以继续，会话标记可以用于建立新的安全链接。

        WTLS中的出错处理是基于告警消息的，当发现错误时，发现的一方发送包含出现错误的告警消息，进一步的处理依赖于出现错误的级别和类型。

        告警中采用4字节校验和，该值可以通过接收其他对话方的上次记录计算得出，方法如下：

       （1）以0填充记录，使其长度为4的模。

       （2）将结果分割为4字节的长度块。

       （3）对这些块进行XOR运算。

告警接收方应该检查校验和是否与以前所发送的信息相匹配。

4.    改变密码标准协议(Change Cipher Spec Protocol)

        此协议用来在WAP会话的双方间进行加密策略改变的通知，仅使用一种改变密码标准消息。消息中包含一个字节，值为1。此消息在双方的安全参数协商一致后，在握手阶段由客户方或服务方发送给对方实体，用于通知对方：以后的数据记录将采用新协商的密码规范和密钥。当消息到达时， 发送消息的一方设定当前的写状态为待决状态(Pending State)，接收消息的一方设定当前的读状态为待决状态。

三 WTLS中的握手协议

3.1      握手协议的流程

        与安全相关的参数均在握手过程中产生，当WTLS的客户端与服务端第一次通信时，它们将在握手过程中协商协议版本、选择加密算法、相互验证并用公钥加密算法产生一个共享的会话密钥。

                         i.              当通信开始时，握手协议主要实现如下功能：

                       ii.              协商密钥交换模式，选择密码算法。

                      iii.              根据应用需要，对通信一方或双方进行身份认证。

                     iv.              通信双方按照协商的密钥交换模式建立一个预先主密钥。

                       v.              利用预先主密钥和随机数生成一个主密钥。

                     vi.              将所有密码安全参数传给协议记录层。

                    vii.              用户和服务器确认对方已经计算出相同的密码参数，且握手协议没有受到攻击者阻扰。

        完整的握手过程如图3-2所示。首先客户端对服务器端发出ClientHello消息，告知服务器客户端要与它连接。而服务器端发出ServerHello消息，如果服务器端没有发出该消息则会出现致命的错误而中断整个安全连接。在两个Hello消息中通信双方将协商下列属性：协议版本、密钥交换组合、压缩方式、密钥刷新和顺序编码模式等。除此之外，还会有两个随机变量产生出来并进行交换：ClientHello.random和ServerHello.random。

        在客户端发出Hello消息后，它将开始接收消息直到收到ServerHelloDone消息。如果服务器端需要验证的话，服务器端将发送服务器认证消息，而且服务器端也可能会要求客户端提供其认证。而服务器密钥交换信息则向客户端提供服务器公钥用于产生或管理预主密钥。

        客户端在收到ServerHelloDone信息后将继续握手过程，如果服务器要求，客户端将发送能够证明自己身份的认证。紧接着客户端将发送密钥交换信息，该信息包含了用服务器公钥加密的预主密钥或能够完成双方密钥交换的基本信息。最后客户端将发送一个完成消息，其中包含对于先前数据和计算数值的确认。

同样服务器端将发送一个完成消息，而且也包含对于先前数据和计算数值的确认。

        此刻，客户端会送出一个改变密码规则消息，并且客户端会将新的密码规则拷贝到现有的书写密码规则中。然后客户端立即按新的算法、密钥送出完成信息。当服务器端收到改变密码规则消息后，同样会将新的密码规则拷贝到现有读取密码规则中，并用新的密码规则传送本身完成信息以作为响应。此刻整个握手过程已经完成，客户端和服务器端开始交换应用层的数据。

 

        当客户端和服务器端决定继续使用前一次的安全会话参数时，握手过程将被简化，其信息流如图3-3所示。首先客户端发送一个包含会话标示符的ClientHello消息，服务器端将检测安全会话缓存以寻找一个与客户端传来的会话标示符相匹配的会话。如果找不到，则服务器端将产生一个新的会话标示符，并开始完整握手过程。

   

3.2      密钥交换

        WAP规范规定了握手协议中的四种密钥交换方式：

 A          共享密钥方法：这是最简单的方法，客户与服务器在通信之前就已经共享了一个密钥，在通信时将其共享密钥作为预主密钥，利用它和双方新近生成的随机数生成保密通信所需要的主密钥。

B         RSA加密传输方法：当RSA算法用于认证服务器并交换密钥时，客户生成一个20字节的秘密数，用服务器的公开密钥加密后传给服务器；服务器利用其秘密密钥可以解密出上述秘密数。这种方法生成的主密钥为上述秘密数与服务器公开密钥的级连。

C            DH密钥交换方法：即传统的Diffle-Hellman密钥交换方法，客户和服务器先分别生成随机数Rk和Rs，并基于一个公共基计算出随机幂指数；然后，它们交换计算出来的随机幂指数；最后，双方分别利用对方提供的随机幂指数为基，以它们自己选择的随机数为指数，计算出它们共享的密钥。这种方法容易遭到中间人攻击。

D            EC-DH密钥交换方法：椭圆曲线版本的Diffie-Hellman密钥交换方法，客户和服务器先分别随机数Rk和Rs，并基于某个椭圆曲线的生成点分别计算出随机点Pk和Ps；最后，双方分别利用对方提供的随机点和自己选择的随机数Rk和Rs，计算出共享密钥，即RkRsG的坐标x。这种方法也容易遭到中间人攻击。

3.3      身份认证以及相应的握手协议的分类

        WAP规范采用基于用户公开密钥证书方法进行身份认证。公开密钥证书的记录中包含有用户的身份信息，CA在对用户的身份信息进行确认后，对用户的公开密钥和身份等信息的哈希值进行数字签名，从而保证证书不能被更改和伪造。

        WAP规范推荐了两种数字签名算法，即RSA和ECDSA。由此，公开密钥证书也分为两种：对用户RSA公开密钥进行RSA数字签名而产生的证书，和对用户的ECDH公开密钥进行ECDSA签名的证书。证书的格式有多种：X-509、WTLS、X-968等。

        WAP规范规定数据加密和完整性保护是必须提供的安全性服务，为此握手协议必须实现密钥交换功能，而身份认证可以根据应用要求有选择性的实现。为此，WTLS握手协议可分为三个安全类：

l         无认证的握手协议。

l         服务器认证的握手协议。

l         服务器和客户相互认证的握手协议。

        为了提高协议效率并保证密钥交换和身份认证功能的安全实现，握手协议中证书的签名算法必须与密钥交换算法一致。下面分别论述这三种安全类中的握手协议。

1.    无认证的握手协议

        无认证的握手协议采用共享密钥方式实现密钥交换，它的实现方式如图3-4所示。客户端首先发送ClientHello消息给服务器端，其中包含协议版本、密钥交换模式、加密算法和完整性算法，，以及随机数等信息。客户端和服务器端利用共享密钥作为预主密钥，并结合来自用户和服务器的随机数，生成真正的主密钥。

        基于共享密钥的协议存在一个主要问题就是密钥的分配问题。由于预主密钥不能在无线信道中以明文方式传送，在实际应用中预主密钥必须以某种方式分配到用户手中。例如，GSM网络中移动用户与归属局共享的密钥是以SIM卡方式传给移动用户的：在移动用户个人初始化时，归属局生成密钥，并将它存入SIM卡，再将SIM卡交给移动用户。基于共享密钥的握手协议实现简单，适合在低功耗、低计算能力的移动终端上实现，因而在实际中得到广泛应用。

2.    服务器认证的握手协议

        服务器认证的握手协议采用基于公钥证书的方法实现身份认证。其预主密钥的分配过程如下：服务器端将公开密钥传给客户端，用户生成一个预主密钥，并用服务器的公开密钥加密后传给服务器端，服务器利用其秘密密钥解密恢复预主密钥，这就很好的解决了预主密钥的分配问题。这种密钥交换方式不要求通信双方事先共享任何密钥，适用于分布式网络。服务器认证的握手协议的实现方式如图3-5所示。

3.    用户和服务器双向认证握手协议

        用户和服务器双向认证握手协议，是在服务器认证握手协议的基础上加上用户认证功能。在WAP规范中，用户身份认证也是基于用户的公开密钥证书的。在握手协议中，服务器向用户传证书请求消息，用户或者将其公开密钥证书直接传给服务器，或者将一个URL地址传给服务器，服务器根据URL连接调用用户公开密钥证书，后者不仅可以节省证书传送时间，而且也可以降低无线终端的复杂度。用户和服务器双向认证握手协议的实现过程如图3-6所示。

3.4      主密钥的生成

        上述握手协议中预主密钥的生成方法各不相同，根据密钥交换方法来变化。而将预主密钥转换成主密钥的方法则是相同的，即：

        master_secret = PRF(pre_master_secret,“master secret”,ClientHello.random +

                                          ServerHello.random)[0..19]

这里PRF代表伪随机数。

        主密钥的长度固定为20字节，而预主密钥的长度则依密钥交换的方法不同而有所不同。当主密钥计算出之后，预主密钥立即被删除。

        在一个恢复的会话中，主密钥与前一次会话中的主密钥相同。然而，由于握手协议中双方重新交换了随机数，这样新的会话将使用不同的密钥组。所谓密钥组是指加密算法和MAC算法所需要的加密密钥、初始矢量和MAC密钥。

        密钥组以下述方法计算：当握手协议正常结束时，握手协议中生成的主密钥、选择的密码算法等信息均被传给WTLS层的记录协议。记录协议生成加密算法所需要的加密密钥和初始矢量，以及MAC算法所需要的MAC密钥。而这些密码参数则是由主密钥、客户随机数和服务器随机数等参数经过伪随机函数PRF产生：

        key_block = PRF(SecurityParameters.master_secret,expansion_label,

                                    seq_num + SecurityParameters.server_random +

                                   SecurityParameters.client_random);

        上述计算过程重复多次，直到生成全部的密码参数。其中，expansion_label值在客户端写和服务器端写中使用不同的值，seq_num则取决于握手协议中所选用的密钥刷新频率。

        一个新的密钥组的生成发生在序列号的间隔处，与密钥刷新频率一致。计算中使用的序列号是要求密钥刷新的第一个号。

        不同的扩展标志值用于客户端写密钥和服务器端写密钥，所以，密钥组生成“client expansion”作为扩展标志值，分割为以下各项：

        client_write_MAC_secret[SecurityParameters.hash_size]

        client_write encryption_key[SecurityParameters.key_material]

        client_write IV[SecurityParameters.IV_size]

        密钥组生成“server expansion”作为扩展标志值，分割为以下各项：

       server_write_MAC_secret[SecurityParameters.hash_size]

        server_write encryption_key[SecurityParameters.key_material]

        server_write IV[SecurityParameters.IV_size]

        在WTLS协议中，许多连接状态参数可以在安全连接期间被重新计算，这一特点被称为密钥刷新，它是为了减小新的密钥过程而被执行。在密钥刷新中，MAC密文值、加密密钥和IV矢量将根据序列号而变化。刷新频率根据密钥刷新参数。上述计算中所用的序列号参数是触发密钥刷新的记录序号。如果序列号根本不用，则在所有的计算中序列号为0。

3.5      HMAC和伪随机函数

        WAP规范利用哈希函数（如MD5或SHA）保护数据的完整性。WTLS规范采用哈希函数H（SHA-1或MD-5）构造MAC，其具体构造可以表示如下：

        HMAC(K,data) = H(K XOR opad + H(K XOR ipad + data)

        哈希函数以H表示，K是由上述密钥组生成方法产生的MAC密钥，opad和ipad是两个固定字符串，它们如下构造：

        ipad = the byte 0x36 repeated B times

        opad = the byte 0x5c repeated B times

        B=64表示数据分组的字节长度，L表示哈希输出的字节长度（L=16 MD5,L=20 SHA-1）。密钥K取决于B，使用密钥长度超过B的应用首先用H计算密钥的哈希值，然后取L个字节作为HMAC的实际密钥。在任何情况下，推荐给K的最小长度是L个字节（哈希输出长度）。

        哈希函数除了用于构造HMAC外，还用来构造伪随机函数PRF。在TLS规范中PRF由两个不同的哈希函数构成，而WTLS为节省资源仅采用了一个哈希函数形成PRF。

        首先我们定义一个数据扩展函数P_hash(secret,data),它可以利用HMAC通过多次迭代将密钥和种子扩展为任意长度的输出。

        P_hash(secret,data) = HMAC_hash(secret,A(1) + seed) +

                                           HMAC_hash(secret,A(2) + seed) +

                                           HMAC_hash(secret,A(3) + seed) + ……

        其中，A(0)=seed,A(i)=HMAC_hash(secret,A(i-1))。这样，伪随机函数PRF可以构造如下：

        PRF(secret,label,seed) = P_hash(secret,label + seed)。

        上述所有公式中的“＋”都表示字符串的级连。 

 

转自：http://blog.csdn.net/purpleforest/article/details/1353412