MIDPV2。0規范!
一 簡介:
MIDP v2.0是由JCP(Java Community Process)制訂的,該規范的制訂是由大約50個公司共同參與設計參見附錄一。MIDP v2.0規范設計的目的是定義一體系架構,相應的APIs,從而為第三方的移動信息設備(MIDs〕應用的開發提供一開放的標準環境。
MIDP v2.0規范是在MIDP v1.0規范的基礎上設計的,它保證了同MIDP v1.0的兼容性。即在MIDP v1.0上編寫的MIDlets能在MIDP v2.0上執行。
根據J2ME定義的體系架構,MIDP被設計在CLDC的基礎上運行。關于CLDC的資料可以參見: http://jcp.org/jsr/detail/30.jsp.雖然MIDP v2.0規范是在CLDC1.0所提供的功能的基礎上制訂的,但它仍能運行在CLDC1.1的基礎上,以及以后的更新版本。但我們希望MIDP v2.0的實現最好在CLDC1.1的基礎上。
二 J2ME 架構:
Java自1995年發明以來以發生了很大的變化,從最早的為基于溜覽器中運行的Applet的編程,到 Servlet/EJB的Server編程,再到現在的MIDlet為無線信息設備的編程。它已發展成為為開發者提供一端到端編程開發的平臺,即我們常說 的 J2SE/J2EE/J2ME,Java的三個平臺(fig1)。由于無線編程有其完全不同于傳統編程的特殊性,比如:運行設備的多樣性,設備處理能力不 如服務器和微機,用戶界面的差異性等。另外在加上無線技術的飛速發展,使得J2ME的體系架構有者完全不同于J2SE/J2EE的特點。
圖1: Java 的三個平臺
J2ME的架構是把我們傳統的Java架構:硬件/OS/JVM/APIs/應用加一變化,變成了:硬件/OS/Configuration/Progile/應用。之所以采用這樣的架構是由我們上面所談到的J2ME的特殊性有關。
圖2: J2ME的架構
J2ME/CLDC/MIDP作為J2ME的一個版本,它是專為無線移動通訊設備說設計的,在下面我們簡單介紹它的體系架構。從下圖中我們可以看到:
圖3: CLDC/MIDP架構
1.在CLDC之上有兩類API:
-MIDP APIs: 這些APIs正是MIDP v.0規范所要定義的APIs.
- OEM-specific APIs: MIDP規范所涉及的無線通訊設備多種多樣,因此它不可能 涉及所有設備 的需求。因此這一類的APIs是由OEM廠商提供以便訪問特定設備的特定功能。但基于這些APIs的應用可能不能在其它的MIDs設備上運行。
2.MID應用的種類:
-MIDP: 一個MIDP應用或稱為MIDet,它必需只使用MIDP和CLDC規范中所定義的APIs。該類應用能在應是在MID設備上最常見的應用。
-OEM-specific: 一個OEM-specific的應用會使用一些不在MIDP中定義的PIs(OEM-specific classes) 。這些應用不能在不同的MIDs設備上運行。
-Native: 一個本地應用使指用非Java語言編寫的直接運行于設備操作系統之上的應用。在MIDP規范中不涉及OEM-specific和Native的應用。
三 MID v2.0規范所涉及的范圍:
我們都知道無線信息設備(MIDs〕的功能多種多樣。但MIDP規范并不是要對這些設備的所有功能都要加以 定義,并提供APIs編程。相反MIDP v1.0和MIDP v2.0的專家組同意只針對有通用并且成功實施的功能的需求制訂相應的APIs。在MIDP v1.0中這些功能包括:
- 應用的下載
- 應用的生命周期
- 端到端的傳輸(http)
- 網絡聯結
- 數據庫存儲
- 計時器
- 用戶界面
通過用戶對MIDP v1.0的使用經驗和反饋,MIDP v2.0的專家組在MIDP v1.0 APIs的基礎上又新加了下面的 APIs:
- 應用的下載和計費
- 端到端的安全傳輸(https)
- 應用的數字簽名和域的安全模式
- MIDlet的push注冊(server push model)
- 聲音
基于上面所講的同樣的原因,一些功能是不會在MIDP的定義范圍內,這些功能包括:
- 系統層的APIs: MIDP APIs的重點是針對應用的開發者,而不是系統開發。因此一些底層的涉及系統接口的APIs,比如無線信息設備的電源管理,語音的編碼模塊就屬于系統層的APIs而不在MIDP所討論的范圍內。
- 底層的安全:MIDP規范不涉及底層的安全的功能,它只使用CLDC所提供的底層的安全機制。
關于MIDP v2.0的新APIs在本文中我們不加以介紹。
四 MIDP v2.0的安全機制:
我們知道Java語言作為以種網絡編程語言,它具有很多特點來滿足網絡編程的需求,其中最為人們所津津樂道 的是它的遍寫一次到處運行,以及它的安全性。特別是它的安全性,從它的發明道現在的7年的時間已經為無數的事實所證明。Java語言的安全性,安全機制也 有它發展的過程,下面我們簡單介紹以下Java的安全機制。
1.Java1.0的沙箱機制:
fig3: Java1.0安全的沙箱機制
上圖所描述的是Java1.0的沙箱機制,它最早是為在溜覽器中運行的Applet所設計。因
Applet的運行代碼是通過網絡傳輸到用戶的機器中,為了防止惡意代碼,該機制把用戶應用簡單分為本地應用和網絡應用(applet)。對網絡應用它只
能放問一些安全的 APIs從而保證安全性。但該機制過于簡單,無法很好滿足開發者的需求。
2.Java1.1的可信任代碼的安全機制:
fig4: 可信任代碼的安全機制
該安全機制只是在Java1.0沙箱安全機制的基礎上,引入一種新的網絡應用,及可信任的網絡應用,但并未對所訪問的資源進行很好的劃分。大家從圖中可看出,應用要嗎受沙箱的約束,只能訪問有限資源,要么就能訪問所有資源。
3.Java1.2/2的域安全機制:
Java1.2/2的域安全機制
該安全機制通過配置文件對Java的應用以及訪問的資源進行配置,從而實現了一種非常細化的安全機制。
4.MIDP安全機制及其發展:
MIDP1.0規范在制訂時由于當時的無線網絡尚處于發展階段,因此在考慮MIDP
v1.0的安全機制時沒有太多考慮應用在網絡傳輸過程中安全性的設置,而是把重點放在無線應用在設備上的運行過程中的安全性上。因此MIDP1.0規范通
過沙箱的安全機制來提供MIDlet
suite運行時的安全性,該機制保證MIDlet所能調用的APIs不能訪問設備的敏感信息和功能。在MIDP2.0安全機制的制訂過程中,專家組采納
了用戶對MIDP v1.0安全機制所提出的意見:即1.0版本的安全性太“強”使得很多的無線設備的功能
不能通過MIDP的編程來加以使用。比
如說手機中地址本的訪問等。如果要把這些敏感功能的APIs開放讓用戶的應用訪問,就必須引入一種新的安全機制。該機制就是我們前面所描述的
Java1.2/2的域的安全機制。在MIDP v2.0中對不被信任的MIDlet則只能運行于該沙箱安全機制中。任何一種MIDP
v2.0的實現,必需支持非信任的MIDlet的在MIDs設備上的運行。
MIDP2.0引入了信任的MIDlet的新概念,對于信任的MIDlet它能使用一些敏感的和被限制使用
的APIs.當無線信息設備檢測到一MIDlet
sute是可信任時,則它對APIs的訪問由相應的安全域的策略定義。我們將在下面的章節中詳悉介紹。當驗證一MIDlet
suite是否能信任時發生錯誤,則該MIDlet suite必需被拒絕
執行。
5.MIDP2.0的域的安全機制:
非信任的MIDlet Suites
一非信任的MIDlet suite是指MIDlet suite的下載源和JAR文件的完整性不能被下載的設備所信任。對于非信任的MIDlet suite必需只能運行于非信任的安全域中,在該域中對受保護的APIs或功能不能訪問或由設備使用者確定可以訪問或不可以訪問。任何一MIDP1.0兼 容的MIDlet suite能在MIDP v2.0的實現上用非信任的模式運行。對于非信任的MIDlet suites它能訪問它的JAR manifest和application desctiptor文件以及下面的APIs:
- javax.microedition.rms
- javax.microedition.midlet
- javax.microedition.lcdui
- javax.microedition.lcdui.game
- javax.microedition.media
- javax.microedition.media.control
非信任安全域對以下APIs或功能的訪問必須由用戶確定可以或不可以:
- javax.microedition.io.HttpConnection
- javax.microedition.io.HttpsConnection
可信任的 MIDlet Suite 的安全:
可信任的 MIDlet Suite 的安全是建立在保護域的機制上。每一保護域定義了該域中的 MIDlet suite 的訪問權限。該保護域的定義者可以定義設備怎樣確認和驗證它能信任的 MIDlet suite 并把該域所允許和授權使用的受保護的APIs和功能綁定給該MIDlet suite。設備所使用的驗證和信任MIDlet suite的機制的定義是分開的,這樣有利于人們根據設備,網絡,和商業模式的不同來進行選擇。可信任的 MIDlet Suites使用X.509 PKI的簽名和驗證機制來確定一MIDlet suites的可信任性。
在MIDP2.0的域的安全機制中,大家主要回涉及以下概念:
保護域: 是MIDlet suite所允許的權限訪問的集合
權限訪問: 是指必須通過授權才能使用的 APIs 或功能
信任MIDlet Suite: 指該MIDlet suite能通過驗證并其JAR文件的完整性能被保證,并能被該設備上的某一保護域所信任。
配置文件: 一配置文件中包含許多域或別名的定義。每一域由包含所賦于的權限和用戶操作所構成。
配置文件的例子:
domain: O= MIDlet Underwriters, Inc. , C=US
allow: javax.microedition.io.HttpConnection
oneshot(oneshot): javax.microedition.io.CommConnection
alias: client_connections javax.microedition.io.SocketConnection, javax.microedition.io.SecureConnection,
javax.microedition.io.HttpConnection,
javax.microedition.io.HttpsConnection
domain: O=Acme Wireless, OU=Software Assurance
allow: client_connections
allow: javax.microedition.io.ServerSocketConnection, javax.microedition.io.UDPDatagramConnection
oneshot(oneshot): javax.microedition.io.CommConnection
domain: allnet
blanket(session): client_connections
oneshot: javax.microedition.io.CommConnection
五. 總結:
MIDP v2.0是為廣大的開發者在無線移動通訊設備上提供的一個開放的Java平臺,它具有開放性,通用性,以及比MIDP v1.0更強的安全功能。它是由全球約五十多家廠商所共同制定的,因此基于MIDP v2.0的應用在將來回有很廣泛的應用前景。
附錄一:MIDP v2.0 的專家組:
公司:
4thpass Inc, AGEA Corporation, Alcatel, Aplix
Corporation, AromaSoft Corp, Baltimore Technologies CELLon France,
Distributed Systems Technology Centre, Elata PLC, Esmertec, Espial
Group Inc, France Telecom / Orange, Fujitsu Limited, German Aerospace
Center (DLR), Institute of Communications and Navigation, Hitachi
Ltd./Digital Media Group, In Fusio, J-PhoneEast Co. Ltd, Logica Mobile
Networks, Mitsubishi Electric Corp, Mobile Scope AG, Mobilitec,
Motorola, NEC Corporation, Nextel Communications Inc, Nokia, NTT
DoCoMo, Inc, Omnitel Pronto Italia S.p.A, One 2 One, Openwave Systems
,
Inc, Orange (UK), Palm, Philips Consumer Communications, Philips
Semiconductors, Research In Motion (RIM), Samsung Electronics Co., Ltd,
Sharp Labs, Siemens AG, Siemens ICM, Smart Fusion, Sony Ericsson Mobile
Communications, Sun Microsystems, Inc, Symbian Ltd, Telef'nica M'viles
Espa'a, Vaultus, Inc, Veloxsoft, Inc, Vodafone Global Platform &
Internet Services, Vodafone Group Services Limited, Vodafone
Multimedia, Zucotto Wireless,
個人:
Fabio Ciucci, Glen Cordrey, Jon Eaves, David Hook, Myank Jain, Neil Katin, Steve Ma, Ravi Reddy Wai Kit Tony Fung