WAP端到端加密解决方案

来源:百度文库 编辑:神马文学网 时间:2024/04/29 23:36:46
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. 开发成本低廉