關于J2ME MIDP1.0.3中的安全問題簡述

2019-11-18 12:45:00

字體：大中小

來源：轉載

供稿：網友

　　自從當初建議設立該板塊起討論的大多都是關于J2EE或是有著大量移動代碼的安全問題而很少涉及J2ME，很久沒來這里，近日發現J2ME的安全問題也很值得討論，尤其是lhjiang兄又碰到類似問題，而我在所回的帖子中事后想想發覺有諸多不當，所以不敢怠慢，馬上上網查閱了類似資料兼之以往的些許經驗似乎總結出來了一些關于J2ME中（這里只討論MIDP1.0.3）安全問題的心得。不敢獨享，拿出來分享一二，純屬愚見，請各位不吝指正。
　　
　　方案一：使用第三方的高級加密API。
　　的確如lhjiang兄所述，目前基于MIDP的最有效的也是為數不多的第三方加密API是BouncyCastle，可到下列站點下載:www.bouncycastle.org 但問題也如lhjiang所言，并不是每個OEM都支持該API，在所回的上一篇帖子當中我提到一個辦法，即假如你要使用一些第三方的API，唯一的解決辦法就是把提供該API的jar文件和你的MIDP一并打包成一個MIDP Suite以使得該產品從而支持該API，這霎一看很有道理，但后來想想覺得不妥，因為API的使用與否還要看設備本身的支持程度，誰也不會認為隨便一個java手機只要下載了MMApi就可以支持MM了吧（據知情人士透漏，諾基亞的下一款新手機將會支持MMApi,大概要到明年才能面市）？當然不是！其實許多API本身并沒有提供任何具體的實現，比如說GCF，在javax.microedition.io這個包中除了Connector這一個類之外其余全是接口，這些只是為了標準化的要求，至于具體的實現還要看OEM的支持程度。所以不能對第三方的API抱有過高的期望。
　　解決辦法：確定你所開發機型的OEM支持該API，否則請看方案二。
　　
　　方案二：根據要開發機型的支持程度自己實現具體的安全措施，這里主要是加密。但這種方法幾乎是行不通的，原因有三：
　?。?）支持CLDC1.0規范的設備本身的處理和計算能力不足以勝任如此繁重的計算工作。
　?。?）CLDC1.0規范目前不支持浮點數，如此復雜的加密算法沒浮點數支持就干脆別想了；
　　（3）MIDP1.0規范所支持的J2SE的子集中Math類只有三個方法：abs(),max(),min()還想什么呢？
　　解決辦法：等待MIDP規范2.0的推出
　　
　　方案三：使用HTTPS.
　　方案三的提出我是要感謝一位作者（是外國人，名字又忘了，唉?。┪沂菂⒖剂怂奈臋n才知道MIDP1.0.3的參考實現（Reference Implementation）竟然支持了HTTPS,我很驚異（說實話，文檔本身并不令我驚異，因為MIDP的安全模型和J2EE中的經典安全模型完全一致，比起諸如Jini,RMI等大量移動代碼的安全性而言要簡單得多，1.0.3支持HTTPS才是最令我吃驚的），后來仔細又看了看MIDP1.0.3參考實現的文檔，果然支持，嗯！當初看文檔太粗心了。那這就比睡大覺還簡單了，因為其中的安全模型和以往的經典模型完全一致，比如在Applet中的數字簽名（關于Applet的數字簽名的文章我以前曾寫過一篇，可以參考一下，貽笑大方了）或關于在移動代碼中的代碼簽名等（關于這方面的東西，我曾發過一篇帖子專門論及RMI和Jini的移動代碼簽名問題，可供參閱）所以假如你對這些內容非常熟悉的話，相信MIDP的HTTPS協議的實現方法就會很快把握了。在API方面沒有作任何的更動，只需在Connector的open(String url)方法的url中指定https協議即可。最重要的是必須得到要認證的服務器端所配置的證書并將其導入到J2MEWTK所維護的密鑰庫中即可。而所有的命令都是由J2MEWTK的bin目錄下的MEKeytool命令所完成的，是不是很眼熟，若你用過J2SE的keytool命令的話很快就可以搞定的。當然為練習起見你可以使用keytool先生成一些自簽署的證書用以測試之用。

上一篇：J2ME Timer - 更簡單的實現多任務調度執行

下一篇：J2ME(CLDC/MIDP)簡介