WAP端到端加密解决方案

一、WAP端到端的安全性问题

　　WAP采用与TLS/SSL类似的WTLS实现传输层的安全性，从而保证信息在WAP网关和WAP设备之间的安全性。如同TLS/SSL对于互联网的作用一样，在多数情况下WTLS已经足以保障WAP的安全性，但是由于WAP网关担负着在WTLS和TLS之间转换信息的任务，导致信息在转换过程中存在安全漏洞。 

如上图所示，WAP网关在WAP设备和Web服务器之间起着翻译的作用：数据从WAP设备发送到WEB服务器时，WAP网关需要将WTLS加密的数据解密，然后用TLS/SSL加密后发送给WEB服务器；数据从WEB服务器发送到WAP设备时，WAP网关需要将TLS/SSL加密的数据进行解密，然后用WTLS加密后发送给WAP设备。由此带来的安全性问题：

　　1. 数据在WAP网关上在一定时间内以明文形式存在

　　2. WAP网关服务供应商可能在日志中保存数据明文，潜在的第三方可能获得所有的传输数据



二、业界解决方案

　　WAP论坛和工业界很早就意识到WAP网关存在的安全性问题，并提出了一系列的措施和解决方案来提高WAP的安全性。

　　1. WAP网关服务供应商尽力确保WAP网关的安全，如保证不保存数据明文、在内存中进行最优化的加密和解密以减少数据明文存在的时间窗口、在释放前覆盖加密解密进程使用的内存以确保数据的安全性。

　　2. 对于安全要求较高的公司可以拥有自己的WAP网关，从而保障数据端到端的安全性。

　　3. 通过PKI公用密匙架构实现数据安全性

　　4. 通过WIM（WAP身份模块）实现数据安全性

　　虽然我们可以相信大部分WAP网关服务供应商会尽力保障WAP网关的安全性，但是对于WAP内容提供商而言，这仍然属于不可控制的因素，特别是当WAP用户处于漫游状态时，内容提供商完全无法保障数据端到端的安全性。

　　第二种解决方案仅仅适用于对于安全性有特别高需求的公司，而需要付出的代价不仅仅是额外硬件的投资，而且还有日常维护带来的费用。

　　从纯技术角度而言，第三和第四种解决方案应当可以解决端到端的安全性问题。但是由于目前大部分手机和WAP网关还不完全对PKI和WIM的支持，在实际应用上具有很大的局限性。



三、应用层解决方案

　　考虑到目前大部分WAP设备能够支持WML和WMLScript，我们尝试通过WMLScript在应用层寻找端到端安全性解决方案。由于安全漏洞主要存在于WAP网关对数据加、解密的过程，我们可以通过在应用层对数据加密实现数据端到端的安全性。在应用层对数据加密后，WAP网关在加、解密过程中获得的数据明文是加密后的数据，从而最大程度的保障数据端到端的安全性。这样的解决方案应当满足以下要求：

　　1. 能够在大部分手机、WAP网关上得到支持

　　2. 采用的加密算法必须是得到业界认可的

　　3. 加密算法能够在WAP设备上有限的内存和处理能力下快速运行

　　4. 加密算法能够通过WMLScript实现

　　5. 在服务器端不需要额外硬件投资

　　6. 在客户端不需要额外投资

　　针对上述设计目标，我们选择CipherSaber 算法作为该解决方案的加密算法。CipherSaber算法采用Ron Rivest的RC4算法作为基础，RC4在工业界得到广泛的支持和应用，包括互联网通用的SSL加密算法。大部分专家认为，当密匙足够长的时候，RC4算法是非常安全的。RC4算法相当简单明了，算法专家Bruce Schneier是这样评价RC4的："RC4算法非常简洁，程序员可以完全靠记忆完成编程"。参见http://ciphersaber.gurus.com/

　　CipherSaber加密算法可以通过16行Qbasic（38个语句）实现，这启发我们通过WMLScript 实现该加密算法并在手机上运行。实际测试表明，在未进行优化情况下，我们可以通过109个WMLScript语句实现CipherSaber加密算法。

　　CipherSaber是一种对称加密算法，这意味着加密和解密使用同样的密匙。在需要发送加密信息的时候，只需要把经过CipherSaber加密的数据发送出去。发送端和接收端必须拥有同样的密匙。

　　运用CipherSaber实现端到端应用层安全性的具体步骤：

　　为实现WAP应用层端到端的安全性，在实际运用中必须遵循一定的步骤。下面我们用一个航空公司售票交易为例，详细解释各个步骤的实现：

　　1. 用户登陆到WEB站点。通过用户名、密码进行校验，申请WAP用户名和密码，设定手机号码和下单密码。WEB服务器采用TRIPLE DES或其他不可逆加密算法对下单密码加密后存储在数据库中。（下单密码的修改必须通过类似步骤2－9的过程进行，用户将不能通过网页修改下单密码）

　　2. 用户登陆到WAP站点，通过用户名、密码进行校验。

　　3. 用户浏览WAP站点内容，有意购买机票。

　　4. 用户填写机票订单。

　　5. 用户提交订单给WEB服务器，服务器为订单产生流水号，并根据流水号和提交时间产生随机密匙。

　　6. WEB服务器通过SMS将随机密匙发送给用户手机。

　　7. Web服务器将校验WML表单发送给用户手机。

　　8. 用户在校验WML表单中填写收到的随机密匙和在步骤1中设定的下单密码。用户手机调用WMLScript，使用随机密码和下单密码对下单密码进行CipherSaber加密。

　　9. WEB服务器在规定的时间内收到加密数据后，使用随机密码和下单密码对数据进行CipherSaber解密，用TRIPLE DES对下单密码加密后与存储在数据库中的下单密码进行比较。如果密码符合，批准交易；否则拒绝交易。（如果WEB服务器在规定的时间内没有收到加密数据，密匙将作废，用户需要重复步骤5－9完成交易）

　　10. WEB服务器将处理结果通知用户。



四、可能的攻击方式及分析

　　如果有人通过某种方式获得用户WEB站点的用户名和密码，他尝试冒充该用户修改手机号码和下单密码，他将无法修改手机号码或下单密码。

　　· WAP的用户名和密码与WEB站点的用户名和密码是不一样的，系统可以通过要求用户输入WAP用户名和密码才允许修改手机号码

　　· 无法通过WEB站点修改下单密码，因为下单密码的修改必须通过手机进行，而且必须拥有现行下单密码

　　如果有人通过某种方式获得用户WAP站点的用户名和密码，他尝试冒充该用户进行交易处理，他将无法完成交易。

　　· WAP的用户名和密码与WEB的用户名和密码是不一样的，他将无法修改手机号码或下单密码

　　· 他冒充用户提交交易后，将无法收到WEB服务器产生的随机密匙，从而无法将下单密码正确加密后送交WEB服务器

　　如果有人在WAP网关处对信息进行截取，

　　· 由于下单密码已经在手机端采用随机密匙和下单密码进行CipherSaber加密，WAP网关看到的数据明文是加密后的明文

　　· 即使攻击者在截取加密的数据明文后，采用解密算法进行解密，他必须采用非常高性能的计算机进行，否则随机密匙一旦过期，攻击者将无法完成攻击。由于数据是采用随机密匙和下单密码混合进行加密，攻击者即使解密一个交易的数据明文，也无法将解密结果用于新的交易。

　　· 可以通过增加密匙长度的方法增加解密的难度



　　据以上的讨论，我们可以发现：一般攻击者要想成功冒充某个用户进行交易，他必须满足以下条件：

　　1. 拥有WAP用户名和密码

　　2. 拥有预先注册的手机

　　3. 知道下单密码

　　在满足这三个条件的情况下，我们可以认定该用户就是原先注册的用户。



五、结论

　　综上所述，我们可以看到，本文提出的应用层端到端加密方案的优越性在于：

　　1. 能够在大部分手机、WAP网关上得到支持

　　2. 采用的加密算法是得到业界认可并广泛采用的

　　3. 加密算法能够在WAP设备上有限的内存和处理能力下快速运行

　　4. 加密算法能够通过WMLScript实现

　　5. 在服务器端不需要额外硬件投资

　　6. 在客户端不需要额外投资

　　7. 一旦WAP系统提出新的安全解决方案，可以很快的升级

　　8. 开发成本低廉