MIDP 2.0安全機制 與 MIDlet 數位簽章

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