基于J2ME的移动商务应用层端到端安全解决方案(一)

    技术2022-05-11  18

    基于J2ME的移动商务应用层端到端安全解决方案 作者:Wassim Itani,Ayman Kayssi  摘要 本文提出了一种基于J2ME的无线企业级应用的应用层端到端安全解决方案。该方案通过使用纯java技术来保证J2ME客户端与J2EE服务器端的安全通信,并提供了端到端的客户端认证、数据加密等机制。此方案可以在任何可用的受限的MIDP设备中实现,不需要对底层协议或无线网络架构做任何修改。本文将通过一个移动银行应用来详细说明此方案的实现方法。 1 引言 移动商务(m-commerce)在过去的几年里已经取得了重大的成果。在电子商务和因特网的基础上,加上手持设备和无线网络的优势,移动商务正在蓬勃发展。它不仅为移动设备提供了新的应用领域,而且为移动用户和移动服务提供商创造了新的机遇。一般意义的移动商务是指利用移动设备通过无线网络来处理商业交易的过程。诸如银行、移动支付等新应用越来越切实可行了。许多现有的电子商务应用都可以适当调整以满足无线网络的环境。 移动商务为商家联系新老客户提供了新的方式,比如无线移动方式。它还使商家在无线网络中提供新的以及加强的应用和服务,并且保证该服务和应用的唯一性。可能移动商务与电子商务相比,最大的优势在于它无处不在,触手可及。用户随时随地都可以使用移动设备与移动商务应用进行交互,不会被限制在台式机或者其他有线设备上。同样,移动商务供应商和应用服务供应商能够使用定位或位置系统访问他们的用户,如GPS。但这将导致一套有价值的基于位置的应用和服务无法应用于使用固话网络的PC用户。另外,事实上移动设备通常不会有共同的用户群,因此开发由应用提供商为他们的个人用户提供的个性化的应用服务蕴藏着巨大商机。 移动银行被认为是移动商务应用中最流行的应用之一。经历了电话银行、网上银行,传统的银行服务今天已经出现在移动设备上了。尽管这些设备的采用某种程度上加速了发展,但是一些关键应用像银行事务,好象还在犹豫,担心泄露他们的敏感数据。移动银行必须开发一套安全系统使用户能够像面对面交易一样信任你的系统。移动银行还需要遵守银行部门的安全规则和惯例。在很多国家,所有的银行数据在传输线路上必须达到128位加密的安全水平。因此法律上规定银行必须加密所有通过移动银行交易的敏感数据。 本文提出一种一般的J2ME应用层加密方法论,使用AES Rijndael的对称分组密码算法提供认证、保证数据的保密性以及移动用户和银行服务者端到端的相互信任。我们的主要目标是提供一种高度安全的环境,使用和部署方便,不需要改动任何基础结构或者无线网络底层协议。选择对应用层进行加密是因为它不依赖于底层的协议,由应用自身处理所有的安全相关的功能。 在应用层使用公钥进行加密已经被证明是不适于嵌入式环境的(Harbitter and Menasce,2001)。这是因为这些操作需要大量的CPU和资源。这些资源需求会导致企业级无线应用反应很慢。另一方面,AES对称加密已经被证明在大小和速度上都是高效的,而且适于在移动设备的软硬件平台实现。 本文剩下的部分组织如下:在第二部分,我们简要描述一下在J2ME平台下处理无线网络安全的相关工作任务,并说明这个应用层安全解决方案的合理性。在第三部分,简短介绍下J2ME的网络模型。在第四部分,我们讨论实现安全银行应用的设计特性,包括客户端环境概况,服务器端概况,加密算法,密钥管理机制以及会话跟踪。第五部分,通过描述一个安全客户端-服务器端的交互机制解释总体的信息流。在第6部分是一份系统实现的性能分析报告,第7部分是结束语。 2 相关内容及当前安全解决方案 在这部分,我们给出几种关于移动商务应用安全的解决方案。一般来讲,要提供端到端的安全,方案实施必须嵌入到网络协议层,或者是应用层,或者是传输层。两种实现各有千秋,我们将通过实例来指出当前安全解决方案的优缺点。适时提供一个与我们的方案的比较。 2.1 传输层方案 在传输层,安全协议被分为两大体系结构取决于它们是符合目前的互联网协议的。第一种体系结构使用非标准的因特网协议来在无线网络中加密数据,然后在有线网络中转用标准的因特网协议(WAP 论坛,2000)。这种在无线设备中使用非标准的因特网协议是因为因特网协议现在的形式太庞大以至于对于低内存,处理能力有限的无线设备中实现是不可能的。这种无线网络协议和有线网络协议的兼容性缺陷致使需要一个代理或者网关负责协议的选择操作。 第二种体系结构坚信遵守目前的互联网协议才能实现通过实施这些协议在某种程度上尊重有限资源的无线设备,并考虑到特征的无线网工作。这种结构不需要客户端/服务器端的网关。 无线应用协议(WAP)1.2规定(WAP论坛,2000)第一种模型。WAP使用无线传输层安全协议(WTLS)作为它在传输层的协议。WTLS是基于传输层安全协议,并被优化,以便有效的地用于受限的无线通信中。WTLS是负责移动电话和WAP网关之间的数据安全的,而著名的安全套接字层协议保证了在有线网络中WAP网关和因特网网络服务器之间的安全通信。这个结构的优点是能够很好的适应在受限的无线环境中的操作,因为它的无线协议是特别为这种环境设计的。但是,与标准的因特网协议以及需要使用网关执行协议转换滋生了一些安全隐患,而且阻碍了为WAP 1.x提供端到端的安全保证。这是由于这一事实,即协议转换机制在网关在协议切换过程中数据处于未加密状态,导致在网关中的数据保密性很差。任何可以访问这个网关的入侵者都能够在数据解密之后,再次使用SSL加密之前将数据拦截下来。此外,把网关作为数量巨大的无限无线互联网客户端的唯一切入点将会使网关成为单点失败点,并且成为系统的主要性能瓶颈。该安全解决方案,介绍了可用于为WAP 1.x提供端到端安全的基于代理的架构。在通用连接框架的支持下,J2ME移动信息设备应用能够使WAP协议栈完成与HTTP网络的交互,不需要TCP/IP协议。因此,使用J2ME制定一个通用应用层安全解决方案的副作用在于,它对WAP网关的安全漏洞提供了一个可行的,协议无关的解决办法,确保了敏感数据在客户端与服务器端应用传输过程中的保密性。应该指出的是,加强WAP应该从网关安全问题着手:WAP2.0规范规定通过对标准的互联网通信协议如IP,TCP,HTTP等的支持,从而不需要再使用WAP网关,使的WAP功能的移动电话进入互联网设备。但是,升级到WAP的2.0 ,需要大幅改动移动电话和无线网络。此外,WAP应用的用户群近来由于WAP网关的众多漏洞而有所缩小。WAP是一种基于浏览器的技术,这使它不适于开发那些界面反应灵敏以及业务逻辑复杂的应用。尽管在有线网络中,基于浏览器的应用取得了重大的成功,但是在无线网络环境中,事实并非如此。原因在于大多数移动设备的屏幕尺寸都很小,而且无线网络的延迟相对较长。此外,基于浏览器的WAP应用需要持续提供可用的连接,因为应用本身是驻留在服务器上的,与那种完全运行在客户端设备的java应用相比,它需要大量的网络数据传输,而后者只是在需要的时候才到服务器上获取自身应用必须的字节数据。WAP2.0将使用XHTML做为它的标记语言。取代了WAP 1.X使用的WML。这将进一步增加网络流量,因为XHTML比WML中拥有更强化的功能和更丰富的标签。 在降低网络流量并提高用户体验方面,这种将表现方式与应用数据相分离的标记语言给基于J2ME的应用带来的优势超过了基于WAP应用。第二个传输层安全方式依赖于以互联网为基础的端到端安全策略协议,从而不再需要使用协议转换网关。作为默认的Internet安全协议, SSL是自然地被选择用作作为提供端到端安全的方法。 SSL的已被证明在确保安全电子商务应用方面是非常成功。 它的运行机制是通过在TCP的基础上建立一条安全通道,通过通道它提供服务器认证使用证书,保密和电文的完整性,作为附加功能,还支持客户端加密认证。 虽然SSL在保证因特网应用的安全性上成功了,但是它的某些部分是计算密集型的,而且需要大量的内存空间,这些对于无线设备来讲是无法承担的。因此,Sun Microsystems公司已开发了重量轻的SSL实现成为kssl(Gupta and Gupta, 2001)。它是SSL 3.0版的客户端实现,支持RSA-RC4-128-MD5和RSA-RC4-40-MD5的加密算法。SSL被分成4层,分别是握手层、记录层、警惕层以及改变加密规格层。其中握手协议是SSL中最复杂的一部分。其宗旨有三:第一,它允许客户端和服务器谈判一项加密和消息认证码(陆委会)算法,以用于在保护的实际数据传输。其次,它允许客户端和服务器端建立一个一套加密钥匙,将用于由记录层,以传统方法加密的SSL记录数据用商定算法。第三,握手认证服务器,并可能有选择认证客户端。握手协议使用公钥加密,生成一个客户端和服务器端共享的精密密文,之后就是通过这个精密密文来产生对称密钥和MAC码。这些公钥操作以及为解析证书链路用于鉴别服务器强加的一个主要性能瓶颈是在无线环境中尤其明显。基于这个原因, SSL的规格还支持简化的SSL握手,它在相同的客户端和服务器利用了上次会话信息,如重用上次会话的精密密文以避免解析服务器证书和执行公钥加密操作。这样就大大提高了握手机制的运行效率。记录层则负责确保实际数据传输通过使用由握手协议协商成立算法和密钥确保它的保密性和完整性。警惕协议,是用来让一方提醒其他特殊条件,而改变加密规格协议需要说明握手操作的完成和对称加密和Mac操作的开始。 在J2ME设备上实现的SSL(KSSL)具有很大优势,它使这些设备直接安全地与数量庞大的支持SSL的互联网的网络服务器沟通。Kssl背后的主要理论是重用上次会话信息,如重用上次会话的精密密文以避免解析服务器证书和执行公钥加密操作,从而避免重复握手。这有助于避免复杂的,资源密集型公开密钥操作在客户端设备执行。此外, kssl不执行客户端认证的,因为它要求CPU密集型私钥RSA的操作。 kssl 和其相关类,使J2ME的虚拟机增加了约百分之二十五,这是推荐的协议,在未来的MIDP 2.0规范以支持HTTPS的( HTTP上的SSL )协议。

    尽管kssl在确保移动商务应用安全显示出了优势, 但是有些评论在这里值得一提。首先,当客户需要连接不同的服务器或当浏览敏感内容,kssl的表现被认为是不可接受的。这是由于在这种情况下,每一次客户端连接到一个新的网络服务器就需要进行完整的握手SSL。使用20 MHz 的Palm PDA通过cdpd无线网络进行一次完整的握手需要10-13 秒。(Gupta and Gupta, 2001)在客户端与同一个服务器进行通信的时候可以避免这个性能瓶颈。这时客户端只进行简化的握手,因为它使用了上次会话的认证解析结果以及精密密文,因此绕过资源密集的公共密钥操作。然而,保存精密密文和多次重用它来生成对称加密钥匙引起一些对安全的关注。这无线设备上的万能钥匙可以很容易被窥探或被盗。这是一个很重要的要考虑的问题,因为几乎所有安全的SSL取决于私人的精密密文。攻击者知道精密密文可以计算出所有用来保护连接的加密钥匙。在本文中所提出的解决办法,特定应用共享的密文利用被客户端和服务器所知的客户端pincode加密,在第4.4节再作讨论。这一共同秘密,将有助于认证服务器和保证对称加密密钥的安全,从而有效和安全地进行同样功能的SSL的握手。唯一的要求是,客户可由服务提供商安全地提供与他的认证pincode。在今天的电子商务中,这操作通常是在服务的订阅时申请。第二个评论关于SSL的运作,当执行加密操作的时候,是其非分化的。或者换句话说, SSL不分青红皂加密所有网络数据,而不需考虑其类型或敏感性。对于SSL,网络数据只是一个类型,并没有在这一网络为基础的数据对敏感性进行分类。因此,当使用SSL时 ,所有的网络数据采用相同的密钥强度加密,可能对于有些无线应用是不必要的,甚至是不可取的。SSL的这个缺陷将变得更加明显和迫切,因为移动商务网扩大,因此一个可配置的安全模型与灵活的加密方案的需求将不断增加,以满足各种不同的需求。在本文提出的应用层安全模型对此给予了高度重视。一刀切'的解决办法,如kssl是行不通的,在多元化无线世界里没有假设可以作出关于无线设备能力和性能或对无线网络应用程序的操作的统一标准。这仅仅是用户和服务供应商才能确定他们的应用的实际的需要和要求。基于这个原因,安全业务,是基于对不同的安全策略,网络数据根据敏感性和内容进行分组,并考虑到无线设备的处理能力和存储能力。加密算法,加密密钥的大小和会话的生存期都是可能包括在该应用程序的安全策略的参数。这种灵活性可以确保有效的运作,同时对设备和无线网络的应用范围广泛。

    最新回复(0)