安全连接在MIDP2.0里面必须有一个或者更多的一些规格来实现：
在HTTP中使用TLS(RFC2818)和TLS v1.0（RFC2246）
SSL v3.0
无效传输层安全（WTLS），或者WAP TLS功能子集和信道规格。
没有实际测试，开发人员可以不知道那个规格是实现在那个特定的设备。在WTLS的情况下，终端到终端的加密尚未提供。安全连接存在于手机和WAP网关，网关到终端中。因此，比较充分信任的网关才可以访问没加密的数据。这是一个不可接受的高安全性应用程序，通常由移动网络提供商操作网关。
此外，安全连接在MIDP2.0中要求服务器有一个验证的有效证书。然而，这里没有支持基于证书认证的客户端，因此，客户端必须通过其他手段进行应用程序水平的身份验证。
安全存储
MIDP2.0不支持加密存储，使其容易无耻悲鄙下流的网'学,网总是抄辣,文,论'文"网受到硬件攻击。在一些设备中，它可以安装一个文件系统资源管理器，存储J2ME使用的那些文件和通过蓝牙技术发送这些文件到另一台设备。因此，J2ME的存储系统对于敏感数据并不能被信任，除非应用程序自己保护数据。为Java添加加密库可能是一个部分解决方案——例如，Bouncy Castle的轻量级加密API支持多种对此加密算法。然而，加密API的可用性不会自动解决明文存储问题。
加密是一个计算密集型认为，当用Java实现，它将会很费时间，因为像CPU架构那样的低级别的优化是不可能的。本地库或加密硬件有可能更有效地执行加密。
另外一个重要的问题是J2ME实现中的随机性来源不足。一个供使用的强大的密码，加密密钥必须是不可能猜测到的。MIDP2.0不可能提供一个强大的加密伪随机数发生器类似于J2SE的安全随机。因此，J2ME中的PRNG是不适合生成加密密钥的。然而，开发人员使用它用于其它目的，而且这样对一个系统安全产生重大的影响，尤其是当前时间用PRNG产生种子时。一个例子是基于SSL对Sun的MIDP参考实现的攻击。
由于MIDP2.0不提供加密存储和MIDP1不提供HTTPS连接，一些J2ME开发公司制定他们自己的轻量级的加密方案。在大多数情况下，这些创造新的加密算法的用心良好的努力会导致一种情况，使数据对普通用户保持隐藏，但却很少保密性强。这些措施通常依赖于这种加密算法的保密性，这被认为是非常不好的做法。许多国家有法律规范在两个通信相方无法控制的媒介传输过程中的私人数据保护。这些法律往往要求加密数据的算法强度等于或者优于三重数据加密标准；它的继承者，高级加密标准，也符合这一要求。不过，国内的加密方案几乎可以肯定，缺乏行之有效的强度加密算法，例如3DES或AES。
使用客户端攻击服务器
除了病毒和蠕虫的网络服务器攻击和分布式拒绝服务攻击这些众所周知的问题，开发人员必须考虑从客户端应用程序可能攻击服务器应用程序的很多方式。两个例子是客户端在没有指令情况下发送命令或者发送到应用程序的数据意外的输入了大量数据块。
客户端软件可能到达各种各样的人手中，包括哪些不能抗拒试图突破它。黑客可以逆向工程软件和研究源代码，或断一点，只需要篡改二进制代码。游戏行业正在面临这样的问题，游戏被破解，，避免日常基础的许可证密钥检查。另外一个聘请黑客战略就是使用网络嗅探器来识别应用协议然后写他们恶意的客户端，行为类似于原有的那种。
开发人员可以采取几种措施提高一个客户服务器应用程序的安全级别，但在我们经验中，大多数人对于他们的客户端软件相当信任。他们的论据是：“嘿，我们写的。为什么我们不能信任它？”在我们看来，这是一个危险的态度。
未来J2ME的安全：SATSA
J2ME新的安全和信任服务API（原文请找腾讯752018766辣,文-论'文.网
http://www.751com.cn）揭露了MIDP2.0安全体系结构的几个缺点。SATSA依赖于软件或者硬件实现了的安全要素。这意味着SE可以采取不同的形式，如一个软件组件，专用硬件设备，或可移动智能卡。一些SE可以在一种设备上使用。SE的准确形式是对应用程序开发人员透明的，因为SATSA实现解决了与SE的互动。
支持密码智能卡尤其对开发智能手机J2ME应用程序的开发人员有用。一张智能卡可存储密钥和证书和签署数据，没有私钥离开过卡。高端智能卡防篡改，并提供认证机制，如授权访问前要求PIN或者密码。私钥不需要存储在不同的不安全的客户中，让厂商能够专注于从物理入侵和同样重要的API开发中保护智能卡。
很多银行已经发现智能卡，包括一磁条可以与旧的ATM机相兼容。通过为客户提供具有加密工具的智能卡，银行可以为移动电话，掌上电脑和桌面计算机提供客户软件，从而把几乎相同的安全水平扩展到所有的平台。当然，不同的操作系统有不同的安全级别，因此银行必须仔细分析每个平台的智能卡访问控制。
SATSA APIs
SATSA规范定义了四个API：APDU,JCRMI,PKI和CRYPTO。前两个为智能卡交互添加功能。SATSA的APDU用智能卡通信，通过使用应用程序控制数据单元协议，这是由ISO7816-4规范所定义的。而SATSA的JCRMI使用智能卡进行高层次通信，通过Java远程方法调用协议卡。
SATA的PKI让应用程序强求一个SE的数字签名，从而提供认证并可能不可否认的使用存储在智能卡上密钥。证书管理给应用程序一个从SE中增加或删除客户端证书的机会。它还可能包括请求生成一个新的证书签名要求。让客户端产生自己的密钥是在系统中支持不可否认性的重要因素。因为SE可能不支持密钥生成，开发人员必须慎重选择，考虑有关应用程序的需求。
上一页 [1] [2] [3] [4] [5] [6] 下一页
J2ME网络安全挑战英文文献及翻译 第3页下载如图片无法显示或论文不完整，请联系qq752018766
