MIDP 2.0安全機制 與 MIDlet 數字簽名
本文檔是 WoTrust 根據 Forum Nokia 提供的技術文檔《MIDP 2.0: Tutorial On Signed MIDlets》翻譯整理的,請同時參考此英文原文文檔: http://www.wotrust.com/support/resou...ts_v1_1_en.pdf 。請使用者在編寫 MIDlet 和簽名 MIdlet 之前閱讀此文檔,以便對 MIDP2.0 的安全機制有一個深刻的了解,有助于使用者能用好 MIDlet 代碼簽名證書。
充分了解 MIDP2.0 的安全機制後就可以向 WoTrust 申請 Thawte 或 VeriSign 的 Java 代碼簽名證書來簽名 MIDlet ,請同時參考:Nokia MIDlet(MIDP 2.0) 代碼簽名證書申請和使用指南: http://www.wotrust.com/support/Nokia...ning_guide.htm
一、概述
MIDP2.0 采用了全新的安全機制,這對于需要調用一個敏感的(重要的)函數和 API 的 MIDlet 開發者來講是必須了解的,如:網絡連接配接 API 、消息 API 和推 (Push) 函數等,還有一些可選的 MIDP 包也有許多受限制的 API 。
雖然購買代碼簽名證書需要費用,但簽名 MIDlet 對開發者來講是收益非淺的,因為許多受保護的 API 都是需要簽名的,以保護開發者和使用者的利益。當然,有些應用是不需要簽名的,如有些不需要聯網的僅用到一些圖形 API 的小遊戲軟體。但一些重要的應用,如:連接配接網絡、發送短消息 ( 短信和彩信 ) 或通路移動終端 ( 智能手機、 PDA 等,以下簡稱為手機 ) 上的 PIM( 個人資訊管理 ) 資料等等都需要簽名。
數字簽名 MIDlet 的好處包括:
(1) 基于 MIDlet 的安全政策,某些功能是必須簽名才能使用的,而有些功能雖然不簽名也可以使用,但必須要求使用者在使用時确認和修改其安全政策,如:寫使用者資料預設是不允許沒有簽名的 MIDlet 操作的;
(2) 基于手機的系統安全和移動網絡的安全考慮,某些手機制造商、移動營運商等可能拒絕沒有簽名的 MIDlet 在手機上安裝和運作;
(3) 大大改善使用者體驗,讓使用者使用友善,使得使用者不會遭遇調用受保護 API 時的安全警告的煩惱;
(4) 出于安全考慮,安裝沒有簽名的 MIDlet 是會有安全警告的,而相反,安裝已經簽名的 MIDlet 則不會出現煩人的警告,手機會自動驗證簽名而順利地安裝成功;
(5) 已經簽名的 MIDlet 将使得使用者能改善其低安全政策設定,提高手機的安全性;
(6) 確定已經簽名的 MIDlet 不會被非法篡改和非法盜用。
二、 MIDP 2.0 安全機制
MIDP 是一個開放的平台,使得任何人都可以為支援 MIDP 的裝置開發各種應用軟體,一般都是移動終端裝置。 MIDlet 套件可以以匿名方式通過網絡下載下傳,非常友善,但這也會帶來許多安全問題和隐私資訊保護問題,使用者會問: MIDlet 能把使用者的個人資訊發給不知道的伺服器嗎?會自動産生沒有授權的呼叫或短消息而給使用者帶來費用嗎?惡意軟體會破壞手機?等等。
除了 Java 語言的安全特性外, MIDP 還增加了許多安全考慮。 MIDP 2.0 比 MIDP 1.0 增強了安全政策,把 API 分為普通 API 和敏感 API ,如:通過 HTTP 協定通路移動網絡,由于會給使用者産生費用, 是以被列為 敏感 API 。 MIDlet 2.0 推出了可信任 MIDlet(trusted) 和不可信任 MIDlet(untrusted) 的概念,一個不可信任 MIDlet 隻能通路有限的 API ,同時還需要使用者手動确認并修改其安全政策;而可信任 MIDlet 則自動繼承系統中的安全政策而獲得通路許可。
許可 (Permissions) 用于需要身份認證的 敏感 API 。 MIDP 2.0 要求調用 敏感 API 之前必須獲得必要的許可,這些許可包的命名同 J2SE 許可,如: HTTP 連接配接許可同樣稱為: javax.microedition.io.Connector.http 。 有關許可的文檔同意歸類在受保護 API 中。
2.1 Protection Domains( 保護域 )
保護域是 MIDP 2.0 中一個非常重要的安全概念,一個保護域就是一個許可集和一種互動模式,這些許可既可以是自己繼承的,也可能是使用者設定的,前者稱為允許 (allowed) ,而後者稱為使用者允許 (user permission) 。當一個 MIDlet 被安裝後,它被配置設定到一個指定的保護域而獲得它的許可和互動模式。
而使用者允許則需要使用者自己決定是否同意,使用者既拒絕一個許可,也可以同意。使用者允許有 3 種互動模式: blanket( 普遍适用 ) 、 session( 短期适用 ) 和 oneshot( 本次适用 ) , 普遍适用 模式就是 MIDlet 安裝時獲得的許可一直有效,除非使用者取消這些許可;而 短期适用 模式則是指第一次調用 API 時需要使用者允許,有效期到此 MIDlet 套件運作結束;而 本次适用 模式則在每次調用 API 時都要求使用者允許。保護域為使用者許可定義了預設的互動模式。
一個 MIDlet 套件使用 MIDlet-Permissions 和 MIDlet-Permissions-Opt 屬性來明确地定義其許可,可以是在 JAD 檔案中定義,也可以在 manifest 檔案中定義。其中: MIDlet-Permissions 定義了 MIDlet 套件中必須具有的許可,而 MIDlet-Permissions-Opt 則定義希望具有的許可。如:一個應用軟體的基本要求是要有 http 連接配接才能正常工作,同時,也可以使用 https 連接配接 ( 伺服器部署了 SSL 證書 ) 來增強安全性,但不是必須的,這樣,這個應用軟體的應用描述可以是這樣:
MIDlet-Permissions: javax.microedition.io.Connector.http
MIDlet-Permissions-Opt: javax.microedition.io.Connector.https
請注意:一個 MIDlet 所要求的許可必須是安裝時配置設定的保護域所具有的許可的子集。如: Nokia S60 MIDP Emulator Prototype 2.0 (SDK) 有一個叫做“ minimum ”的域,此域沒有任何許可。是以,如果一個含有許多許可的已經簽名的 MIDlet 如果被安裝到此域,則會安裝失敗,因為此域不支援這些許可。同樣,如果一個許可的名稱有拼寫錯誤,則一樣會導緻安裝失敗,因為域中沒有此拼寫錯誤的許可。
MIDP 2.0 為 GSM/UTMS 裝置定義了 4 種保護域: manufacturer( 裝置制造商 ) , operator( 移動營運商 ) , trusted third party( 可信任的第三方 ) , and untrusted( 不受信任域 ) ,除了 untrusted 域外,每個保護域都對應一組根證書,用于簽名 MIDlet 的簽名證書的根證書必須包含在這些根證書中,使用不同的簽名證書簽名的 MIDlet 将被自動歸類予根證書所屬的保護域,根證書與保護域的關系是:一個保護域可以有許多個根證書,而一個根證書隻能對應于一個保護域。
具體來講, manufacturer 域屬于裝置制造商,其根證書是裝置制造商自己的根證書;而 operator 域營運商,一般使用其 SIM 卡中的根證書;而 trusted third party 域則預置了全球知名的數字證書頒發機構 (CA) 的根證書,用于驗證由 CA 頒發的 MIDlet 簽名證書;而 untrusted 域沒有根證書,将用于沒有簽名的 MIDlet 和 MIDP 1.0 。
Thawte 和 VeriSign 的根證書已經預置在 trusted third party 域中,其 Java 代碼簽名證書可以用于簽名 MIDlet 。當然,使用者也可以選擇使用裝置制造商和移動營運商頒發的證書,隻要其根證書已經包含在手機的 4 個保護域中。據 WoTrust 了解,大多數摩托羅拉 (Motorola) 手機隻支援裝置制造商域,是以,隻能向 Motorola 申請簽名服務了。
請注意:由于 MIDP 2.0 也在不斷地修改和增補,是以,可能不用的移動網絡營運商有不同的保護域和許可,使用者可能需要向移動營運商了解詳細資訊。而最簡單的方法是檢查目标使用者所使用的手機的根證書是否有計劃購買的 MIDlet 簽名證書的根證書。
2.2 Untrusted MIDlet ( 不受信任的 MIDlet)
MIDP 2.0 定義了那些 API 是 untrusted 的,這些 Jar 檔案的來源和完整性是不能被手機驗證的。但這并不意味着這些 MIDlet 不能被安裝和運作,而是運作這些 MIDlet 需要使用者人工确認允許。而所有 MIDP 1.0 的 MIDlets 都被定義為 untrusted 。
untrusted 的 MIDlets 隻能調用一個不需要許可保護的 API ,如:
java.util
java.lang
java.io
javax.microedition.rms
javax.microedition.midlet
javax.microedition.lcdui
javax.microedition.lcdui.game
javax.microedition.media
javax.microedition.media.control
如果 untrusted MIDlet 套件試圖調用一個被保護的 API 而且沒有被人工允許,則會産生一個 SecurityException 而被 MIDlet 按照安全政策處理。請注意: Nokia 的 UI API 是不被保護的,包括類: com.nokia.mid.sound 和 com.nokia.mid.ui 。
2.3 Trusted MIDlets ( 可信任的 MIDlets)
如果手機能驗證 MIDlet 的身份和完整性 ( 也就是已經數字簽名 ) ,則會自動配置設定一個合适的保護 域這種 MIDlet 套件就稱為可信任的 MIDlet 。一個可信任的 MIDlet 套件所要求的許可将被準許,隻要所屬的保護域擁有這種許可,假如許可: javax.microedition.io.Connector.http 已經在所屬保護域中是允許的,則 MIDlet 在打開一個 http 連接配接時是不需要使用者确認的。
請不要混淆了可信任的 MIDlet 套件和可信任的保護域的不同,每個可信任的 MIDlet 套件依據安全政策被配置設定到一個特定的保護域。
您需要使用一個手機中已經預置的根證書的證書頒發機構頒發的代碼簽名證書來簽名 MIDlet ,否則将不能通過身份驗證。成功簽名後的 JAD 檔案中一定會包含有整個簽名證書的證書鍊,屬性名稱為: MIDlet-Certificate-1-1 就是您的簽名證書,而 MIDlet-Certificate-1-2 就是 CA 的中級根證書,而 MIDlet-Certificate-1-3 就是 CA 的頂級根證書。同時還會有一個 MIDlet-Jar-RSA-SHA1 屬性就是 JAR 檔案的摘要。
當一個 MIDlet 被下載下傳或被安裝時, MIDlet 應用管理器首先會檢查 JAD 檔案中是否包含了 MIDlet-Jar-RSA-SHA1 屬性,如果有,則啟動如下驗證過程:首先會讀出 MIDlet-Certificate-1-1 、 MIDlet-Certificate-1-2 和 MIDlet-Certificate-1-3 屬性中的證書,并與已經預置的根證書相比較,如果證書鍊能被根證書驗證,則表明開發者身份已經被驗證。接着就會使用使用者證書來解密 MIDlet-Jar-RSA-SHA1 屬性的摘要,再計算出已經下載下傳的 Jar 檔案的摘要,比較兩個摘要是否相等,如果相等,則表明 MIDlet 代碼自簽名後沒有被修改。這樣,既驗證了身份又檢查了完整性的 MIDlet 會被配置設定到所屬根證書所對應的保護域中。但是,如果 MIDlet 中的許可屬性 ( MIDlet-Permissions ) 中有一個或多個不屬于所屬的保護域,則仍然不允許安裝。而如果 MIDlet 中的可選許可屬性 ( MIDlet-Permissions-Opt ) 中有一個或多個不屬于所屬的保護域,會允許安裝。可見,正确設定許可屬性和可選許可屬性非常重要。
2.4 Function Groups ( 功能分組 )
為了簡化使用者管理操作, MIDlet 把一些類似功能分組,這樣,使用者隻需對功能組設定許可即可。如:許可 “Net Access”( 網絡通路 ) 組來代替許可 javax.microedition.io.Connector.http ,這對于簡化手機的互動操作非常有用。
MIDP 2.0 和 JTWI 定義了如下 7 個功能組:
(1) Net Access: 包括所有網絡連接配接許可;
(2) Messaging: 包括所有與發送和接收短消息 ( 短信和彩信 等 ) 相關的許可;
(3) Auto Invocation : 包括與自動啟動 MIDlet 相關的許可,如: Push Registration
(4) Local Connectivity : 包括與本地連接配接相關的許可,如: IrDA 或 藍牙;
(5) Multimedia Recording : 包括與允許錄音、照相、攝像等相關的許可;
(6) Read User Data : 包括讀取使用者資料相關的許可,如:通訊錄、日程表等;
(7) Write User Data : 包括寫使用者資料相關的許可。
不同的手機支援不同的功能組,如: Multimedia Recording 就不會包含在沒有攝錄裝置的手機中。當然,也有可能将來會增加更多的功能組。
功能組也同時定義了不同的域的不同互動方式,如:在不信任域, “Net Access” ( 網絡通路 ) 被設定為 session( 短期适用 ) 或 denied( 拒絕 ) ,而在可信任域則可以設定為 oneshot 、 blanket 和 denied 的。
三、仿真器和手機的預設安全設定
讓我們來看看具體的使用 Thawte 或 VeriSign 代碼簽名證書簽名後的 MIDlet 在 trusted third party 域中的所有預設許可,如下圖 1 所示,點選 NDS 3.0 的“ Config Emulators ”就可以看到仿真器在 trusted third party 域的預設安全設定是“ Ask first time ”,即第 1 次使用是需要确認:
圖1:http://www.wotrust.com/support/image...Security_1.gif
如下圖 2 所示,您可以下拉所有功能組的許可設定,如“ Network Access ”就有 4 個選項可以修改: Ask first time 、 Ask every time 、 Always allowed 和 Not allowed :
圖2:http://www.wotrust.com/support/image...Security_2.gif
而如下圖 3 所示,在“ Real Life ”模式,也就是實際手機的運作模式,可以看出:定義的 7 個功能組都是“ Always allowed ” ( 總是允許 ) ,這就顯示出 MIDlet 簽名對于開發商來講是多麼的重要,将大大友善了使用者的使用,再也不需要使用者操作煩人的系列确認了。
圖1:http://www.wotrust.com/support/image...Security_3.gif