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

4.5 会话跟踪
HTTP是一个无连接的协议。每一个HTTP请求是独立于其他的请求，并且协议规范中，没有提供任何机制可以确定了一系列要求是属于任何一个用户或另一个。随着时间的推移，处理会话跟踪的几大战略已经形成;最实际的就是使用Cookies和URL重写。在Java Servlet API中提供了httpsession对象，它代表了每一个与网络服务器交互的用户。在Servlet API规范要求的Web 容器贯彻落实使用cookie机制进行会话跟踪。在这个方法中Web容器自动设置会话跟踪Cookie名称为jsessionid 。当servlet容器判断出客户端没有返回Cookies时，它便使用URL重写进行会话跟踪。我们使用cookie跟踪用户会话。Cookies交换机制类似于一个网络浏览器和网络服务器，但存在一个区别，即客户端MIDlet程序在每个请求时必须明确发出会话cookie返回到服务器上。
5 实现细节
应用始于客户发出一个HTTP请求，以初始化J2EE服务器上的Servlet。初始化Servlet的几项基本任务，即
1 产生一个128位的随机数（challenge）。
2 为客户端请求创建一个新的HTTP会话。
3 将challenge存储在会话变量中。
4 生成128位加密/解密会话密钥。
5 将会话密钥存放在客户实体数据库特定条目中。
6从数据库获取客户的pin码和共享密钥。
7 通过客户pin码加密共享密钥并加入共享密钥。
8 在一个HTTP响应中向提出请求的客户端返还产生的challenge和加密的会话密钥。
在第一步生成128位随机数challenge，目的就是要给客户端的验证数据提供一个随机的共混物，让窃取者在研究通过无线网络得到的客户每次发送给服务器认证数据时，将得到不同的值，传送到。这也将阻止入侵者利用会话认证数据获取进入系统的权限。在第8步这个随机challenge连同传送会话所产生的密钥一起被传给客户，客户会附上pin码，使用加密会话密钥加密新的组合，然后发送加密结果连同用户名到服务器上。作为一个随机值，这个challenge将是确保由用户发出的加密模块不同于每个认证的请求。有人会说，采用随机密钥的话，每一次会话将不再需要这种一个随机的challenge，因为每次会话的认证数据都以不同的会话密钥进行了加密，因此在任何两次会话中这些数据将永远持有同样的价值。这是事实，但是我们发现，有必要不断的生成challenge，以保持设计的灵活性，而有些用户可能更喜欢长时间使用不变的密钥，而不是每次会话都改变它。在这种情况下，存在的challenge有必要将在密钥的生存期内随机化认证数据以防止重放攻击。
在第2步，一个新的HTTP会话建立了;这个会话将被服务器用于标识客户，并保存服务器不同组件共享的数据。这是显示在第3步的上述程序，如随机challenge所产生的初始化服务器组件是储存在客户会话中事后被认证的组件使用，将在后面介绍。在第4步，加密/解密的会话密钥在服务器上随机生成。每一次会话使用不同的密钥，降低了风险。一个攻击者将不可能通过收集网络上加密的数据来获取有用信息，无法进行成功的分析。如前所述，该设计可以灵活地修改以增加加密密钥的寿命。在第5步，产生的密钥被储存在客户数据库记录，直到他们由认证及期权处理服务器组件使用。一个值得一提的重要的问题是，这里的选择数据库储存这些密钥，而不是一个会话变量。这一决定也是为了维持设计的灵活性，让这些会话密钥有一个更长的生存期，。如果这些密钥被储存在一个会话变量里，然后，他们在会话结束时将被摧毁，而储存在数据库中，会向他们提供一个持久存储其生命周期取决于该项目的需求。
步骤6和7是必须的步骤。当在加密或解密实际数据会话密钥被传送给客户使用，它们确保使用无线连接安全传输会话密钥。因为以纯文本格式向客户转交这些密钥是完全没有安全保障的，所以他们都是由客户端的pin码加密的，再加上在第4.4讨论的64位共享密钥。本次会话密钥，现在可以通过网络与在第8步中讨论的challenge一起安全地移交给客户了。加密的会话密钥客户储存在局部变量中。客户继续进入登录表单，在那里他/她输入了一个用户ID和64位（其实是8个字符） pin码 。当按下连接按钮，一个简单的客户端的验证机制将对输入的有效性进行校验，避免pin码无效时发送不必要的客户端请求。经过校验机制，实际用于加密/解密敏感网络数据的密钥要予以追缴，这样是为了初始化AES分组密码。正如先前所说，加密会话密钥和解密会话密钥被加密（由pin码加上共享密钥）存放在手机内存中。此外，共享密钥加密储存（由pin码加密，加上pin码本身）在MIDlet的JAR文件的密钥类中。因此，共享密钥是使用pin码解密 ，会话密钥使用pin码和共享密钥解密。这是密钥类的责任。使用pin码解密共享密钥再到用它同pin码解密用于加密/解密的会话密钥。取出密钥后，他们可以用来初始化的AES密码。两个AES分组密码被初始化：第一个密码是负责加密从客户端向服务器发送的数据，第二个密码是负责解密从服务器发送到客户端的数据。经过初始化密码，加密密码加密关联的
challenge与pin码 （图3） 。该加密结果块附加到用户ID号码后，通过发送
图3 在客户端及服务器端的AES操作
一个HTTP请求将新的组合发送到J2EE服务器上的认证Servlet。在服务器端，认证Servlet接收到用户ID号码和加密challenge- pin码的组合数据块。它开始通过提取用户ID号码，并利用它作为向数据库查询的参数查询放在数据表中的用户信息。如果查询返回一个null结果，那就是用户ID没有存入数据库表， Servlet使会话失效，并发出了'拒绝访问'的信息给客户。如果查询返回一个有效的结果，那么ResultSet中的JDBC对象，是用来提取在HTTP请求收到相对应的用户ID的加密密钥，解密钥匙和pin码。这些密钥是用来初始化的AES分组密码，之后在处理数据块中使用。经过初始化密码，该块包含了加密密码challenge相关信息的数据被解密密码解密：如果由客户端发送的pin码与来自数据库pin码相匹配，并且如果收到的challenge与来自会话变量的challenge相匹配的话，那么客户端被认证。在此阶段，客户要么被认证，要么拒绝访问。
客户端认证后，认证Servlet，在另一个会话变量中存储AES密钥和客户的用户名，以便使他们可以在随后的请求使用。服务器还发送给客户的欢迎讯息确认认证。客户现在可以继续前进，并查看选项列表或服务器应用程序所提供的服务（在我们的例子中下是银行服务）。然后客户端可以从表选择一个选项（图4 ） ，发送相应的请求，被选择的识别码发送到在J2EE服务器上的选项处理Servlet。选择处理的Servlet开始试图得到请求相关的Session对象。经检索Session对象， Servlet检查，Session对象是否是新成立的，以确保客户端已通过了认证阶段。然后Servle从本次会话对象中检索出的AES密码和用户名。如果这些会话变量的内容是无效的，这意味着该客户端没有经过认证阶段，因此Servlet停止所有处理。否则，如果内容的会话变量不是无效的，处理servelt取出选择的操作码，并根据客户所选择的操作， Servlet运行所需的数据库查询有关数据库，以获得特定操作所必要的数据。然后Servlet将返回的数据以16字节块重新组织并用SHA-1散列算法哈希他们（National Instituteof Standards and Technology, 1995） ，以产生一个独特的消息摘要。为了在无线网络确保数据的完整性，本哈希操作是必要的。该数据块同产生的消息摘要利用加密AES密钥加密，并将结果以16进制格式转交给客户。当客户端收到加密的数据块和消息摘要后，解密，并也利用SHA-1算法对解密数据块产生一个信息摘要。由此产生的信息摘要与服务器发出的解密消息摘要进行比较，如果这两项消息摘要是一致的，客户便可以确认，它的数据网络传输中没有被修改，并能将它呈现给用户。这一过程的说明如图5 。我们在这里指出，并非所有在J2ME客户端和J2EE服务器之间进行网络传输的数据都要加密的;此举有助提高客户端性能，因为它只需要加密/解密敏感数据。这种加密
的数据做根据由客户端和服务器协商后的策略进行加密的。客户机/服务器交互安全示意图如图 4 。
图 4 安全的客户/服务器交互

 

 

 

图5 安全增强操作
6 性能测试
客户端应用在索尼爱立信Java的手机P800中测试。以及服务器端的应用使用J2EE服务器1.3.1版本下运行Windows 2000进行测试。我们使用通用分组无线业务（ GPRS ）执行连接http网络进行J2ME的客户端和J2EE服务器之间交互。该应用在以下测量数据中展现出优良的性能，介绍如下。
应该予以重视的是提高应用的性能，特别是对存在内存和处理局限性的客户端。事实上，某些战略必须被纳入J2ME的客户端代码，以改善其性能。
我们重点关注的主要性能策略是：
1 尽可能多地减少的MIDP应用程序的大小：这是通过减少构成应用软件的java类数量，这样除了减少应用程序的大小，还有助于通过限制KVM装载类的个数来节省内存
2 尽可能少用对象：这是非常重要的，尤其是当我们知道在大多数面向对象的语言中创建对象是一个性能瓶颈。
3 在对象不再使用（以使他们标记为垃圾收集）的时候，将对象的引用赋null，并明确但明智的调用垃圾回收器。这项技术从闲置的对象腾出更多的内存，这是很有用的。
4 采用可变的对象，如在执行字符串加法操作时使用stringbuffer对象而不是字符串对象，。这是由于因为字符串对象是一成不变的，一旦他们创建了，他们就不能随意修改。操作中，看似修改字符串对象（如字符串），实际上，是创键了新的字符串对象。这增加了程序的内存需求。除了上述技术之外，还有其他有效率的Java编码技术帮助高效率地利用嵌入式设备资源。此外，设计和实现该J2ME的应用考虑到了移动性的需求，这进一步制约其施加。移动无线设备和无线通信介质的性质中增加网络输入/输出错误的概率和网络连接一致性的危险。在模拟器测试应用的时候这些错误不常出现，因此在应用软件开发阶段预计这类错误，并处理这些问题，可以为应用在一个真正的网络正确执行提供很多帮助。这是事实，大部分这类错误是不能控制的，而且涉及到操作环境，但是在应用中利用简单的编码技术设法处理他们，对减少他们的影响扮演着一个重要角色。其中一些技术被用于应用代码的技术有：
1  在I / O错误可能发生的时候，如开放一个HTTP连接，或当读或写网络数据，显式的捕获异常并处理这些问题。
2  无线连接的最小的数据量传输。这有助于减少网络流量和传输出错的概率。
3 将HTTP请求放在后台线程执行。这有助于隐藏网络信息获取过程的影响，使用户图形界面保持反应灵敏，在网络连接的不同阶段能响应其他业务。性能测量采取了索尼爱立信手机，包括AES加密操作， AES解密操作，以及SHA-1散列操作。另外对那些利用无线网络，以执行HTTP与服务器进行网络交互的应用的业务采用定时测量。这包括challenge和会话密钥检索操作和认证操作以及具体的银行选择数据的检索操作。测量这些操作所需的时间，将会给显示出对网络往返延迟。
†在Java的手机上，AES加密操作运行超过165kbps。
†在Java的手机上，AES解密操作然超过105kbps。
†在Java的手机上，SHA-1散列操作运行大约650kbps。
†challenge和会话密钥检索操作从HTTP请求开始，直到challenge及会话密钥装载到JAVA手机，所需时间大约为2123 ms。
†认证操作从HTTP请求开始到认证结果返回客户手机，所需的时间大约2325 ms
†第一选择的检索（获取用户的银行帐户资料）从HTTP请求开始到结果返回客户手机需要大约2593ms
†第二个选择的检索（检索有关用户最后交易的资料）从HTTP请求开始到认证结果返回客户手机需要大约2029ms
†客户端的应用最高RAM需求曲线，在不同的应用阶段确定为大约20 KB。注意，此内存曲线测量，是用Wireless Toolkit模拟器的廓线。
7 总结
在这篇文章中我们介绍了在无线网络中基于J2ME的客户和基于J2EE的服务器之间采用纯Java组件提供端到端的客户端验证和数据保密性和完整性的应用层安全解决方案。此方案可以在任何可用的受限的MIDP设备中实现，不需要对底层协议或无线网络架构做任何修改。通过银行应用来说明安全解决方案的使用。
鸣谢
本项工作是由libancell赠款支持。
参考资料：
Daemen J, Rijmen V. Rijndael, the advanced encryption standard. Dr Dobb’s J 2001;March.
Dawkins, S. Montenegro G, Kojo M, Magret V. End-to-end Performance Implications of Slow Links, RFC3150.
URL http://www.faqs.org/rfcs/rfc3150.html; July 2001.
W. Itani, A. Kayssi / Journal of Network and Computer Applications 27 (2004) 13–32 31
Gupta V, Gupta S. Securing the wireless Internet. IEEE Commun 2001;December.
Harbitter A, Menasce D. The performance of public key-enabled kerberos authentication in mobile computing
applications. Proceedings of the 8th ACM conference on Computer and Communications Security; 2001.
Itani S, Kayssi A. Securing mobile banking transactions using wap application-layer security. Proceedings of the
International Conference on Communication Systems and Networks; September 2002.
Juul NC, Joergensen N. WAP may stumble over the gateway. Proceedings of the International Conference on
Advances in Infrastructure for Electronic Business, Science, and Education on the Internet (SSGRR 2001);
August 2001.
Keating G. Performance analysis of AES candidates on the 6805 CPU core, URL http://members.ozemail.com.
au/~geoffk/aes-6805/paper.pdf; April 1999.
Lawton G. Moving Java into mobile phones. IEEE Comput 2002;June.
Legion of the Bouncy Castle, Bouncy Castle Crypto APIs. URL http://www.bouncycastle.org; February 2003.
National Institute of Standards and Technology. Secure Hash Standard. Federal Information Processing Standards
Publication 180-1; April 1995.
Organization for the Advancement of Structured Information Standards. SAML 1.0 Specification, OASIS. URL
http://www.oasis-open.org/committees/download.php/1383/oasis-sstc-saml-1.0-pdf.zip; November 2002.
Reagle J, editor. XML signature requirements. ; October 1999. URL http://www.w3.org/TR/xmldsig-requirements.
Reagle J, editor. XML encryption requirements, W3C; March 2002. URL http://www.w3.org/TR/xml-encryption-
req.
Soriano M, Ponce D. A security and usability proposal for mobile electronic commerce. IEEE Commun 2002;
August.
Sun Microsystems. J2EE Platform Specification v1.4; August 2002.
Sun Microsystems. J2ME Wireless Toolkit 1.0.4 User’s Guide; June 2002.
WAP Forum, Wireless Application Protocol Architecture Specification. URL http://www.wapforum.org/what/
technical_1_2_1.htm; June 2000.
WAP Forum, WAP 2.0 Technical White Paper, URL http://www.wapforum.org/what/WAPWhite_Paper1.pdf;
January 2002.
Yap E. Minding the security gap in your e-business application. TrustNews 2001;August.
32 W. Itani, A. Kayssi / Journal of Network and Computer Applications 27 (2004) 13–32