基于J2ME的移动商务应用层端到端安全解决方案（二）

2.2 应用层方案
关于应用层安全解决方案，这是一类本属于该层的工作。几乎没有哪种方案解决了移动商务端到端安全的各种不同问题以及在一个完整的，系统的设计过程应对各种挑战和关切。(Itani and Kayssi, 2002; Juul and Joergensen, 2001; Yap, 2001)一些解决方案处理在WAP网关上面所讨论的有关的安全漏洞。这样的解决方案面临的困难与WML脚本的弱特性，客户端脚本语言WAP开发环境以及WAP应用可浏览的特性，使得不适宜在应用层执行加密操作相关联。其他解决办法提出用可扩展标记语言（ XML ）作为J2ME的无线客户端和后端服务器之间的数据通讯格式，并提供端到端的安全性，确保在J2ME的设备和服务器之间安全传送XML文件。这类建议依赖于几个已提议支持通信数据安全的XML应用的XML安全协议。这些安全协议中，有一个可以提及的XML加密协议，其中提供了可以加密一个XML文件的一部分甚至是整个文件。采用对称加密技术，其关键是在参考文件。XML数字签名协议（ reagle ， 1999年），其中规定了如何用数字化方式签署XML文件和安全断言标记语言（ SAML声明） （结构化信息标准推进组织， 2002年） ，这是一项说明在一个XML文件如何嵌入认证和授权信息的协议。不过，。由于缺乏XML技术支持和自身的安全规程和标准，在目前SUN的移动信息设备简介（在MIDP ） 1.0版的规格，甚至在未来的MIDP 2.0规范J2ME的设备，这些建议仍然没有得到执行。缺乏支持，是因为在Java基础类库中有限的字符串函数降低了XML的解析的效率。此外，结构化标记的XML对于有限的无线带宽是一个颇为笨重的语言，而没有必要在一个无线环境施加额外的网络流量。在在本文中建议的安全解决方案有一个清晰简洁的分隔，隔离了用来在通信实体之间的传送数据的数据格式和安全操作的实现。这使得解决方案适用于一定范围内的数据格式，而不是特定范围内，并允许努力集中财力保证了安全的解决方案，并保证其优化性能，而无需作出关心在运输网络数据使用的格式。
3 J2ME：移动设备中的java
3.1 J2ME概述
J2ME使服务器有可以接受一套群新的客户：手机，双程寻呼机，以及palmtops 。这些器件可以通过使用MIDP编程。MIDP是一套Java的API，其中，连同连接有限设备配置（ CLDC采用）一起提供完整的Java运行环境。(Lawton, 2002). J2ME的主要目的是继承功能强大的的Java编程语言，设计了一个轻量级虚拟机（KVM） (Lawton, 2002)，能够对资源受限的移动设备提供一个安全和清洁的执行环境。使用J2ME和Java 2平台企业版（ J2EE ） ，就可以创建百分之百基于Java的无线企业应用程序。
3.2 J2ME网络模型
J2ME提供了一个优雅的网络模式非常适合企业无线应用开发。这是因为在CLDC采用的水平存在一个通用的连接框架。此外，MIDP基于CLDC，提供httpconnection接口，制订了封装一个HTTP连接必要所需的方法。
尽管在CLDC一级存在一个通用的连接框架，SUN 的参考实现没有要求实现TCP或UDP协议。MIDP唯一的支持和执行协议是HTTP的，事实上只有这一个协议是MIDP的实现一定要支持的。因此无线技术开发商想使用TCP流或UDP数据包提供通信服务就必须提供自己的TCP或UDP实现。因此，不建议使用其他的HTTP以外的J2ME网络传输协议，以确保各项业务的正常运作网络应用可以跨多个J2ME的设备。
提供http的支持背后的原因之一，那就是HTTP既能被互联网协议如TCP / IP实现，也能被非互联网协议，如WAP实现。举例来说，一个支持MIDP功能的设备可能是在没有内置支持TCP / IP，但还有的HTTP能够如期运行在WAP协议栈上，并使用WAP的传输层
通过协议转换网关进入因特网上。这就保证了应用将运行于任何MIDP的设备，无论是GSM手机的WAP协议栈， 还是Palm OS的掌上电脑或手持设备与蓝牙功能。
4 使移动银行安全可靠：特性设计与实现
移动银行应用程序的设计和实施提供了一个原型解决方案，在无线网络中以确保敏感的数据，无论传输这一数据底层传输协议是什么。唯一的要求是有一个在MIDP兼容的设备。其中一个可能的优势是，当使用WAP的协议栈为传送HTTP的消息时，为在WAP网关中安全漏洞提供一个解决方案。本节讨论的设计从客户环境开始， 到服务器环境、加密算法，会议加密/解密、密钥管理过程，以及会话跟踪机制。
4.1 客户端环境
客户端应用遵守MIDP1.0规范。开发的第一阶段，使用由SUN 提供的J2ME Wireless Toolkit的1.0.4 （ Sun Microsystems公司， 2002年）。Wireless Toolkit，是一套提供J2ME developers的工具，有模拟器环境，文档，并举例说明，以开发基于MIDP兼容应用。应用使用索尼爱立信P800 Java手机在GSM网络采用了GPRS功能的sim卡进行测试。
最重要的客户端应用类 是bankingmidlet类，它是应用的主类。 aesengine类及其实用类提供加密/解密业务和服务， sha1digest类执行散列化操作，Keys类，它负责解密加密/解密服务器所产生的会话密钥。 MIDP的应用被包装在一个Java档案（JAR）文件内，其中有应用类和资源文件。这种JAR文件，实际上是与Java应用程序描述文件一起下载到物理设备（手提电话）
4.2 服务器端环境
受益于一个纯粹的Java解决方案，服务器端的应用按照J2EE规范实现（ Sun Microsystems公司， 2002年）。服务器端应用包括三个除了加密类和使用类以外的Java的servlet。这些类都被打包在一个网络档案（WAR）文件中，并部署在J2EE应用服务器上。使用SUN J2EE服务器版本1.3.1的参考实现。使用Cloudscape的数据库服务器，一个IBM的纯Java实现的小型数据库服务器。主服务器端的应用组件认证的Servlet authservlet ，该类负责认证客户，初始化Servlet的initservlet ，后者负责生成随机的挑战和随机会话键，选择处理的Servlet optionservlet ，他们的工作是处理客户的请求。在Java servlet是使用Java数据库连接（JDBC ） API和新javax.sql包与数据库进行通信（图1）部分服务由javax.sql包的连


图 1 客户端服务器端组件
接池处理，如分布式事务和用逻辑名字绑定数据源。为了不每次加载的具体JDBC驱动程序，需要一个客户端和服务器端组件连接数据库，使用Java命名和目录接口（ JNDI）以通过其逻辑名从一个J2EE服务器上的JNDI目录服务检索数据源。
4.3 加密算法
加密算法使用的是AES公司Rijndael算法(Daemen and Rijmen, 2001) 。 AES公司的Rijndael是一个迭代分组密码，即在产生输出以前初始输入块和密钥进行多重周期转化。该算法可以在可变长度块上采用可变长度的密钥，一个128 ， 192 ，或256位的密钥可以用来加密数据块是128 ， 192 ，或256位长的，在所有密钥和块长度的九个组合中，都是可行的。该算法是书面的，致使块长度或密钥长度可以很容易以32位的倍数延伸，并且系统是专门设计用于一系列的处理器高效率地执行， AES公司的Rijndael是一个替代非线性变换网络， 10， 12或14轮，具体取决于密钥大小。一个用AES进行加密的数据块要分成字节数组，每个加密操作是基于字节的。 AES的全面功能由4层组成。在第一层的时候，一个8 ￡ 8 S-box是适用于每个字节。第二次和第三次层是线性混合层，在该曾层的数组是行进行转移，列被混合。在第四层时，子密钥字节异或到数组的每个字节。在最后一轮，柱混合别忽略了。有关AES公司rijandael实现来自the Legion of the Bouncy Castle加密包（the Legion of the Bouncy Castle， 2003年） ，其中提供了该算法的一个Java实现。在本文建议的安全解决方案选择AES公司的Rijndael作为对称加密算法，主要有三个原因：安全，效率和多功能性。对于任何分组密码，安全是最重要的特征。这就是说，密码是对利用其内部结构进行cryptanalytic攻击的免疫针。一个密码的安全性通常是取决于它的安全保证金。如果一个N轮密码与存在着一个针对en 2 kT轮减少版的cryptanalytic攻击，那么该密码便有一个K轮的绝对安全保证金。 Rijndael，其块大小128位，密钥尺寸128位，这是本文中使用的结合，它有一个四保守轮的安全保证金。 Rijndael的设计者并没有发现针对6轮以上的减少版的捷径攻击。捷径袭击定义为密钥恢复比详尽密钥搜索速度快的攻击。效率是和安全一样重要的，是指把大量的需要执行加密或解密的资源。 Rijndael在嵌入式设备中已被证明是一个很好的算法，也很适合运行在受限制的空间环境中。这是由于它的低内存和处理能力需求。第三个重要特点，就是功能多样。多功能是指在范围广泛的各种设备和处理器的类型中以高效率地执行一个密码操作。 Rijndael是旨在跨越多种硬件和软件计算环境中有效的执行，包括从8位智能卡处理器到32位架构。多功能的Rijndael确保在客户和服务器双方的机器有效运作加密和解密。综合考虑， Rijndael的密码组合，安全，性能，高效率和灵活性，使之成为在无线环境中实现的优秀的算法，在该银行应用实现中，采用128位钥匙处理16字节的数据块。这种选择是出于以下限制。尽管事实上Rijndael支持可变块长度和可变密钥长度， 但是AES公司规范中固定块长度为128位，支持密钥长度为128 ，192或256位而已。Rijndael中其他的块长度与密钥长度组合在AES公司甄选过程没有评价，并因此在目前联邦信息处理标准（FIPS）也没有被采纳。因此，块尺寸选择好了，并选择128位密钥，以确保在移动装置上有效运作加密业务，因为当密钥长度增加，加密算法处理要求也会陆续增加。最后，128位加密密钥是为移动商务银行应用软件开发可以接受的安全水平。
4.4 密钥管理

移动商务中首要关注的是确保客户端和服务器端的通信。为此，我们实施了一个会话密钥管理机制，如为每一个客户端会话随机产生加密/解密密钥。这种机制解释如下：客户端和服务器使用两个128位的钥匙，每个方向的数据传输各一个。就是说一个密钥是用来加密客户端数据和解密服务器端数据，另一个密钥是用来加密服务器端数据，解密客户端数据。在开始每一个客户端会话时，服务器随机生成这对钥匙，并将他们存储在客户实体数据库的具体条目中。服务器，然后进行使用客户端的64位pin码对会话密钥加密，得到一个客户端和服务器共享的64位共享密钥。这对加密会话密钥交给客户端，而它被存放在局部变量。另一个重要的必须加以处理的问题是确保安全的在客户端和服务器存储共享密钥。在服务器端这一共享密钥是储存在数据库上，我们假设由数据库管理系统及其他计算机安全政策进行担保。确保在客户端机器的共享密钥好像更具有挑战性。它是经过加密处理，保存在JAR文档的Java密钥类中，如图 2所示，共享密钥是用客户端的pin码 （ 64位）加密，在加上该pin码，因为AES公司的要求是密钥的长度是128位。在该银行应用中，分布式应用中手机银行服务在客户订购服务时以客户的pin码加密共享密钥并将他存储在客户手机上，这是这项服务的职责。这样，即使手机被盗和应用程序代码被反编译，入侵者都将无法取出共享密钥的实际值，加密值并没有多大用处。它是只有当客户登录到该系统的运行时表示，这种共享密钥是用用户pincode解密，并同pincode一起使用， 然后解密在实际的数据交互中进行加密/解密操作的会话密钥。(图 3).
图 2 共享密钥加密及安全存储