|
Michael Juntao Yuan ( juntao@mail.utexas.edu)
德州大學奧斯丁分校 電子商業研究中心 副研究員
請注意本文,它討論了基於 J2ME 的行動商業應用程式的一些安全性挑戰和解決方案的當前成果。特別地,J2ME 開發人員 Michael Yuan 和 Ju Long 討論了最常用但也最缺乏安全性的 J2ME
Profile
? MIDP 的應用程式開發的挑戰。其中包括 J2ME 相對於Thin Client(如 WAP)和本機應用程式的優點的概述,以及關於 J2ME 當前和未來安全性框架的優缺點對比的討論。另外,新興的 Web 服務正逐漸成為網際網路領域中重要的元件,所以請瞭解更多關於它的資訊,以及這一新技術可能對您的 J2ME 開發策略有怎樣的影響。
隨著行動商業應用程式從時髦的口號逐漸變成現實,對於行動用戶和無線應用程式開發人員這類人而言,安全性正在成為一個重要方面。網路整體安全性的強度取決於其最薄弱環節,而在行動商業網絡中,最薄弱環節是客戶端設備。無線信號的可截取本質以及大多數手持設備有限的記憶體和計算能力,使無線系統極易受到資料竊賊的攻擊。
但客戶端並非行動商業網絡上的唯一薄弱環節。隨著 Web 服務技術成為網際網路領域中日益重要的元件,無線網路將面臨一些全新的弱點。Web 服務使用開放通信協定並在組織的防火牆之外運行,當在企業中部署這些系統時,這將會造成非常實際的安全性威脅。
解決方案正在形成,儘管尚需時日。尤其是,Web 服務本身可以用來提供安全性解決方案。新的 Web 服務規範計畫標準化和集成使用 XML 消息傳遞的先進的安全性解決方案(如 Kerberos 認證和授權、數位證書、數位簽名和公∕私鑰加密)。可互操作的 Web 服務可以將那些安全性解決方案用作產品和服務供應商的一類實用程式。但即使正在出現這些有希望的解決方案,對於您如何有效地保護自己的無線應用程式及運行應用程式的網路而言,開發平臺的選擇將始終起到舉足輕重的作用。
在本文中,我們將重點討論在 Java 2 Platform,Micro Edition(J2ME)上進行開發的優缺點。我們首先對 J2ME 的基本概念和優點作簡單概述。接下來,我們將深入研究基於 J2ME 的應用程式相對於其他無線備選應用程式(如 WAP 和本機應用程式)的潛在安全性優點。我們將說明當前在 J2ME 平臺上可用的應用程式安全性模型,以及該平臺對於一些可預料未來趨勢的適用性。作為討論的一部分,我們將提出一些增強 J2ME 應用程式的網路和資料安全性的可能方法。在結束部分,我們將總結使用 J2ME 技術開發用於最小型無線設備的高級安全應用程式的可行性。在整篇文章中,我們將主要集中討論當前的和即將出臺的(2.0)MIDP 規範,假定 MIDP 是最廣泛使用的 J2ME Profile。
因為 Web 服務承諾了在行動商業和無線安全性的發展中扮演重要角色,所以在整篇文章中,我們都將討論包含 Web 服務的技術。我們將花一些時間研究 Web 服務對您的 J2ME 開發策略的影響。但是,我們不會很深入地討論這個話題。
將 Java 平臺用於無線設備開發的最大優點是能夠生產可在多種平臺上運行的可移植程式碼。但即使有這個優點,各種無線設備在記憶體、處理能力、電池壽命、顯示幕大小和網路帶寬等方面的能力差異還是相當大的。不可能將運行在成熟的機頂盒上的應用程式的全部功能都移植到行動電話上。即使對於類似的設備(如 PDA 和高級智慧型電話),在兩者間建立可攜性也常常使一種設備超負荷而另一種設備利用不充分。只能在多組類似設備之間實現真正的可攜性。因為認識到一種規格並不能適合所有設備,所以小心地設計 J2ME 以在可攜性和可用性之間取得平衡。
J2ME 分成幾種不同的配置和Profile。配置包含用於一系列設備的 Java 語言核心庫。當前有兩種配置:連接的設備配置(Connected Device Configuration (CDC))被設計用於相對較大和功能強大的設備(如高端 PDA、機頂盒與網路設備);有限連接設備配置(Connected Limited Device Configuration (CLDC))被設計用於小型的資源有限的設備(如行動電話和低端 PDA)。CDC 的安全性、計算能力和 I/O 功能比 CLDC 高級得多。
每個配置上面都有幾個Profile。Profile定義了更高級的、特定於設備的 API 庫,包括 GUI、網路和 API。每個Profile有自己的運行時環境並適合於一系列類似的設備。為一個特定Profile編寫的 Java 應用程式可以在由該Profile支援的所有硬體∕OS 平臺之間進行移植。行動資訊設備Profile(Mobile Information Device Profile (MIDP))和 PDA Profile文件(PDA Profile)是 CLDC 的兩個比較重要的Profile文件。基礎Profile文件(Foundation Profile)和個人Profile文件(Personal Profile)是 CDC 的兩個重要的Profile文件。
個人Profile構建在基礎Profile之上,以便在高端 PDA 上運行。個人Profile配置了完全相容 Java 2 的VM實現。個人Profile應用程式可以利用所有基於 Java 2 標準版(J2SE)域的安全性管理器,以及大量可用於 J2SE 應用程式的密碼術和安全性庫。總之,個人Profile文件提供了成熟的安全性解決方案,它們類似於用於 J2SE 應用程式的那些解決方案。
實現安全 MIDP 應用程式要困難得多,因為 CLDC 配置的數學計算能力有限並且許多底層設備的處理能力不足。但是,MIDP 設備是使用最廣泛的無線設備,因此在那些設備上啟用安全應用程式很重要。在本文中,我們主要集中討論 MIDP 應用程式的安全性挑戰以及當前可用的或處於開發中的解決方案。
我們的經驗是,無論是在特性還是安全性方面,本機應用程式和 J2ME 應用程式都比那些以無線應用程式協定(Wireless Application Protocol (WAP))構建的應用程式提供多得多的功能。但 WAP 是一種Thin Client開發協議,J2ME 是一種專用于智慧應用程式的開發平臺。無論應用程式是用 J2ME 還是本機技術構建的,智慧應用程式都比 WAP 應用程式多提供了下列安全性優點:
- 由於中間沒有 WAP 閘道,智慧應用程式能夠提供從後端到無線設備的可伸縮的端到端安全性。當後端發展成消息驅動的 Web 服務框架時,這一點就尤其重要。
- 智慧應用程式能夠在本地存儲和處理資料,因此減少了網路流量。這不僅節省了寶貴的無線帶寬和減少了延遲時間,而且降低了關鍵資訊被截取或阻斷(例如,透過拒絕服務攻擊)的可能性。
- 智慧應用程式有效地利用了設備處理能力。胖客戶端可以根據內容建立全面分級的安全性策略,而不是無論是否需要都以相同的密鑰強度加密所有內容。
因為智慧應用程式比 WAP 頁面能幹得多,所以,運行智慧應用程式確實增加了軟體Crash和∕或病毒攻擊的風險。接下來,我們將討論,與那些設備本機應用程式相比,J2ME 應用程式有哪些處理和安全性優點。
正如我們已經提到的,與平臺相比,Java 平臺的主要優點是它允許我們編寫可移植的應用程式。Java 平臺的可攜性來自其執行模型。具體地說,它是由於在運行時使用 JVM 來將 Java 位元組碼處理成機器碼,因而在硬體之上提供了一個相容性層。Java 平臺的執行模型還引入了一些在設備本機應用程式中缺乏的重要安全性優點。這些優點如下:
- JVM 驗證類裝入器中所有的類並確保應用程式不會執行任何危險操作。因為對於 MIDP VM 而言,運行時類驗證在計算上代價很高,所以 MIDP 有特殊的兩步位元組碼驗證模式。我們將在後面一節中討論這種方案。
- JVM 有用來防止運行時應用程式錯誤的監控機制。垃圾收集器是一個好示例。JVM 能夠在運行時自動清理應用程式記憶體堆。這有助於避免發生記憶體洩漏,記憶體洩漏是導致本機應用程式崩潰的主要原因。
- JVM 可以提供用於應用程式的安全性管理器或SandBox。從 Web 上偶然下載的病毒和其他敵意程式碼可能造成嚴重的安全性風險。在 Java 平臺上,可以對整個應用程式(例如 JAR 檔)進行數位簽名。
位元組碼驗證
正如我們已經討論的,JVM 提供了防止惡意程式碼進入企業系統的服務。位元組碼驗證過程保證了應用程式不能訪問記憶體空間或使用其域外的資源。位元組碼驗證還防止應用程式重載 Java 語言核心庫,這是一種可以用來繞過其他應用程式級安全性措施的方法。
但是,由於這種操作高昂的計算開銷,MIDP VM 不在運行時執行完整的位元組碼驗證。相反,應用程式開發人員必須在把應用程式部署到行動設備中之前,在開發平臺或登臺區域上預先驗證類。預驗證過程優化執行流,創建應用程式中包含指令目錄的堆疊映射(stackmap),然後將堆疊映射添加到經預驗證的類文件。在運行時,MIDP VM 迅速地對位元組碼進行線性掃描,將每個有效的指令與合適的堆疊映射項相匹配。
因為 MIDP 缺少完整的安全性模型,所以在 MIDP 中禁用了一些 J2SE 特性以使潛在的安全性風險降到最低。例如,為了防止對核心類的非法重載,MIDP VM 不允許用戶定義的類別。MIDP 也不支援 Java 本機介面(Java Native Interface (JNI))或反射(reflection)。即使適當地採取了這些安全性措施,也並非所有透過位元組碼驗證的程式碼都被允許運行。程式碼簽名是 J2ME 應用程式安全性策略中下一個重要元素。
程式碼簽名
要獲得行動應用程式安全性的範例,我們只需研究 Java applet,它使用數位簽名和安全性SandBox以確保 Web 上的程式碼安全。這?是關於 applet 安全性工作原理的簡要概述:
- 在傳輸之前,applet 伺服器用其數位證書對 applet JAR 檔進行簽名。
- 在接收時,流覽器端 Java 安全性管理器驗證簽名並判斷應用程式的發送方和完整性是否可信。
- 如果不能驗證數位簽名,則運行時退出並給出錯誤資訊。如果能夠驗證簽名,則安全性管理器使用數位證書,透過查詢客戶端或透過使用表來查詢可信實體的許可權來確定實體的許可權域。
- 在成功完成驗證過程之後,應用程式碼被傳遞到客戶端。
可以用和 Java applet 一樣的方式對基於 J2ME/CDC 的行動程式碼進行簽名和傳遞。理論上,也可以用相同的方法保護 MIDP 應用程式。但是,由於處理能力和記憶體有限,MIDP 1.0 規範中還不可以使用基於域的安全性管理器。當前的 MIDP VM 只能提供最小的安全性SandBox。例如,MIDlet 套件只能訪問它自己創建的持久記錄存儲。
可以透過建立點對點安全連接來保證網路與資料安全性。SSL/TLS(安全套接字層∕傳輸層安全性 ? 以後簡稱為 SSL)這樣的安全性協定允許我們在網際網路主機之間打開安全套接字。SSL 利用公鑰演算法和數位證書在素不相識的各方之間建立信任並交換當前會話的私鑰。於是,SSL 通信各方使用快速的私鑰演算法來加密和解密通信資料。SSL 協定支援認證、資料完整性和機密性。在電子商業應用程式中,基於 SSL 的安全 HTTP(HTTPS)已經成為傳輸敏感資料的標準協定。
J2SE 以其通用連接框架(Generic Connection Framework)提供對 HTTPS 的優秀的和透明的支援。所有 J2ME/CDC 應用程式都有權訪問 HTTPS 功能,但在 MIDP 1.0 規範中並不正式需要 HTTPS 支援。考慮到 HTTPS 在行動商業中顯而易見的重要性,許多 MIDP 設備供應商已經將對 HTTPS 的支持添加到它們自己的 MIDP 運行時實現中。Sun Microsystems 也在其 J2ME Wireless Toolkit 版本 1.0.2 及後續版本中添加了 HTTPS 支援。在即將出臺的 MIDP 2.0 規範中,HTTPS 支援將成為正式需求。
保護內容而非連接
儘管 HTTPS/SSL 協議非常流行而且功能又很強大,但它們原本是為有線網際網路領域設計的。當我們開始將 SSL 應用於新一代動態無線應用程式時,會出現許多嚴重問題,如下所示:
- 對等點組和基於訂閱的多播應用程式將成將來智慧無線應用程式的主要模型。作為一種一對一協定,SSL 不能很好地支援多播應用程式。
- SSL 是一種保護主機間直接連接的點對點協定。然而,新興的網際網路領域是基於 Web 服務的。因此,它需要多個仲介來協助處理和傳遞基於 XML 的服務請求。於是就出現了對端到端安全性解決方案的需求。
- SSL 是一種保護主機間直接連接的點對點協定。然而,新興的網際網路領域是基於 Web 服務的。因此,它需要多個仲介來協助處理和傳遞基於 XML 的服務請求。於是就出現了對端到端安全性解決方案的需求。
當行動商業網絡擴展時,目前出現的與 SSL 有關的問題只會變得更嚴重。為了解決這些問題,我們需要一種具有靈活加密方案的端到端安全性模型以滿足一系列不同的需求。我們需要關注保護內容而非連接。我們將透過研究幾種很有前途的(用於實現端到端無線安全性的)內容格式、安全性協定和工具來結束這個討論。
XML 優點
J2ME 應用程式可以在 HTTP 協定上使用 XML 資料格式與後端伺服器和其他 J2ME 應用程式通信。遺憾的是,所有那些額外標記使 XML 對於有限的無線帶寬而言成為一種相當龐大的格式。儘管如此,XML 還是提供了一些很重要的優點。XML 是一種非常健壯的、易於理解的消息格式。這也是為新一代開放、可互操作的 Web 服務所選的通信資料格式。因此,使用 J2ME 的無線設備必須有處理 XML 的能力,以便訪問 Web 服務的世界。此時,使用 XML 的優點遠勝於其BandWidth開銷。
在基於 MIDP 的應用程式上支援 XML 很困難,因為 CLDC 基本類別中的字串功能很有限。幸運的是,MIDP 應用程式已有幾個XML 解析器可以使用。kXML(由 Enhydra 開發)提供了用於 XML 的簡單 API(Simple API for XML (SAX))和有限的文件物件模型(Document Object Model (DOM))能力。kXML 包還包含一種稱為 kSOAP 的特殊實用程式,用於為 Web 服務解析 SOAP 消息。原本計畫將內置羽量級 XML 解析支援用於 MIDP 2.0 規範,但最近更改了這一計畫。JSR 118 專家組已經決定在即將出臺的 JSR 172 J2ME Web 服務規範(請參閱參考資料)中包含 XML 解析支援,該規範還將包含用於 CDC 和 CLDC 應用程式的基於 XML 的遠端程序呼叫(RPC)。
XML 是我們為 J2ME 無線應用程式和後端服務之間的資料通信所選的格式。為了提供點對點安全性,我們需要確保 XML 文件的安全。因此,我們需要特殊的 XML 標準以將安全性元資訊與單個文件相關聯。
已提出了幾個 XML 安全性協定以在 XML 應用程式中支援通信資料安全性。其中有下列協議:
- 安全性斷言標記語言(Security Assertion Markup Language (SAML))是以 XML 消息傳輸認證和授權資訊的協定。它可以用來提供單點登錄 Web 服務。
- XML 數位簽名定義了如何對 XML 文件的部分或全部進行數位簽名以保證資料完整性。可以用 XML 密鑰管理規範(XML Key Management Specification (XKMS))格式封裝與 XML 數位簽名一起分發的公鑰。
- XML 加密允許應用程式使用對預先約定的對稱密鑰的引用來加密部分或全部 XML 文件。
- Web 服務安全 XML 協議族(WS-Security)是一個由 IBM 和 Microsoft 認可的向 Web 服務提供安全性的完整的解決方案。它以 XML 數位簽名、XML 加密以及類似於 SAML 的認證和授權方案為基礎。
所有上述安全性協議都可以綁定到 Web 服務消息傳遞協定。例如,我們可以將 SAML 段嵌入到 SOAP 消息頭中來認證和授權對所請求服務的訪問。我們也可以將 XML 數位簽名段嵌入到 SOAP 頭以認證消息中的信用卡號。
因為缺乏 XML 和密碼 API,當前的 MIDP 1.0 規範不支援安全 XML 標準。實際上,甚至 MIDP 2.0 也將不包含通用密碼 API。這使得開發人員只能依靠第三方庫(如 Bouncy Castle 羽量級密碼術包)以在 MIDP 應用程式中支援安全 XML。對於 CDC 和 CLDC 設備,JSR 177 提出了使用 SIM 卡的用於安全性和信任服務的 API。加上 SAML 或 WS-Security,新 API 就能夠支援自動標識和單點登錄 Web 服務了。
儘管情況複雜,我們還是可以得出結論,與 WAP 和本機應用程式開發方式相比,J2ME 確實提供了許多優點,包括安全性優點。在高端,CDC 的個人Profile將 J2SE 的全部功能賦予無線應用程式,在大多數情況下包括在嚴格的安全性需求下實現成熟的應用程式的能力。
在安全性 API 方面,當前的 MIDP 1.0 規範沒有提供足夠的支援。但在第三方庫和供應商支援的幫助下,我們發現可以用 MIDP 1.0 來實現安全應用程式。而且,正如我們所見,即將出臺的 MIDP 2.0 規範承諾提供一套核心安全性 API,這些 API 應該允許我們創建具有更高級和靈活安全性特性的行動商業應用程式。
當開發行動商業應用程式時,要考慮的最重要的因素之一是它們將如何適應 Web 服務域。Web 服務技術正在迅速發展,整個網際網路領域也隨之發展。我們已經花了一些時間討論應用於基於 J2ME 的應用程式開發的 Web 服務技術。我們鼓勵您從參考資料一節中的一些參考資料開始,深入研究這個主題。
- 對 J2ME 剛入門,請下載 J2ME 無線工具箱(J2ME Wireless Toolkit)。
- 有關更多 J2ME 資訊,從正式的 J2ME 網站開始學習。
- 無線 Java 開發者是 J2ME 參考資料總目錄。
- 瞭解更多關於即將出版的 J2ME Web 服務規範的內容,請參閱 Java Community Process JSR 頁面。
注:本文来之IBM DW 台湾省