【正文】 第 13章 移動代碼安全 第 13章 移動代碼安全 引言 移動代碼安全技術 Java安全 第 13章 移動代碼安全 引 言 移動代碼又稱移動代理 、 可下載代碼 、 可執(zhí)行內容 、 遠程代碼等等 ， 它是指在本地執(zhí)行的遠程代碼 。傳統(tǒng)系統(tǒng)中 ， 執(zhí)行的代碼都是駐留在執(zhí)行代碼的主機上 ， 而對于移動代碼 ， 執(zhí)行的代碼則是來自遠程主機 。 Carzaniga等人 [1]將移動代碼進行了分類并與傳統(tǒng)的基于客戶機 —服務器技術的分布式系統(tǒng)作了比較： 第 13章 移動代碼安全 (1) 客戶機 —服務器模型：客戶機和服務器位于不同的主機上 ， 由客戶機向服務器發(fā)送請求；處理請求所需的資源和代碼都位于服務器端 。 (2) 即時響應代碼 (CodeonDemand)：客戶機擁有完成某項操作的資源 ， 但沒有如何完成這項操作的代碼 ， 客戶機通過向遠程服務器發(fā)送請求 ， 由服務器將代碼發(fā)送給客戶機 。 這種類型的移動代碼包括： Java應用程序 、 ActiveX控件 、 MIMI Tcl擴展和 Postscript等 。 第 13章 移動代碼安全 (3) 遠程計算：客戶機擁有描述某項服務的代碼 ，而執(zhí)行代碼所需的資源位于遠程服務器上 。 客戶機把代碼發(fā)送到服務器上 ， 由服務器執(zhí)行代碼并把結果回送到客戶機 。 (4) 移動代理：客戶機進程在執(zhí)行期間為了完成某項服務需要訪問一些資源 ， 而這些資源位于遠程服務器上 ， 于是客戶機把客戶機進程移植到服務器端并由服務器完成服務 。 客戶機進程會一直停留在服務器上直到下一個客戶機進程移植過來 。 第 13章 移動代碼安全 Java應用程序 (Applet)和代理 (Agent)是移動代碼中的兩種主要形式 。 Java應用程序是用戶把代碼從遠程主機下載到本地執(zhí)行 。 這種技術在 Web瀏覽器中嵌入了 Java虛擬機 。 這樣 ， Web發(fā)布者就可以向用戶提供動畫 、 游戲等動態(tài)內容 ， 而不僅僅提供靜態(tài)的 HTML頁面或依賴于帶寬的 CGI交互式內容 。 而代理則相反 ， 用戶是把代碼發(fā)送到網(wǎng)絡上以完成用戶所需的某項任務 。最早的移動代理系統(tǒng)之一是 Telescript。 第 13章 移動代碼安全 從上面的討論可以看出 ， 移動代碼是由一方生成 ，但在另一方控制的環(huán)境中運行的代碼 。 這就會帶來安全問題 。 如對于 Java應用程序 ， 用戶在執(zhí)行它來實現(xiàn)某些操作的同時要承擔惡意代碼破壞系統(tǒng)的風險 ， 而代理則要保護其代碼免受惡意主機的利用 。 第 13章 移動代碼安全 移動代碼安全技術 移動代碼會導致安全問題的本質在于在運行代碼時需要訪問系統(tǒng)資源 ， 而代碼卻是來自于另一臺 ， 甚至是不可信的主機 。 即代碼提供者和代碼運行者之間可能是互不信任的 。 移動代碼易受到以下幾種類型的攻擊 [2]： (1) 泄漏用戶或主機的機密信息； (2) 拒絕服務：使合法用戶無法獲得資源； 第 13章 移動代碼安全 (3) 破壞或修改數(shù)據(jù)； (4) 惡作劇攻擊：如在用戶屏幕上顯示圖片或在用戶主機上播放音樂等 。 第 13章 移動代碼安全 移動代碼安全需要考慮以下幾個方面： (1) 訪問控制：規(guī)定誰可以使用代碼； (2) 用戶認證：識別合法用戶； (3) 數(shù)據(jù)完整性：保證代碼在傳輸過程中未被修改過； (4) 不可抵賴：發(fā)送者和接收方不能否認使用過代碼； (5) 數(shù)據(jù)機密性：保護敏感數(shù)據(jù)； (6) 審計：跟蹤移動代碼的使用 。 第 13章 移動代碼安全 在前面提到 ， 移動代碼安全可以從兩個方面考慮：一是惡意代碼對本地系統(tǒng)的破壞；二是遠程惡意主機對代理的非法使用 。 接下來 ， 我們將從惡意代碼和惡意主機兩個方面來討論移動代碼的安全技術 [3]。 第 13章 移動代碼安全 惡意代碼 對于 Java應用程序類的移動代碼 ， 一般的操作是用戶下載可執(zhí)行格式的二進制 Applet然后運行 。 這就很容易帶來安全問題：用戶必須允許不可信的代碼在本機運行 ， 而這些代碼可能會隨機寫內存 ， 從而導致系統(tǒng)崩潰；代碼甚至可以讀 、 修改以至刪除用戶個人文件 。 在運行 Applet之前進行認證可以解決這個問題 。 通過認證 ， 用戶就可以確定它所運行的代碼來自于特定的可信源 。 但是這種方法帶來了兩個問題： 第 13章 移動代碼安全 (1) 嚴重限制了用戶可以運行的 Applet(必須來自可信源 )， 而不可信服務器也可提供有用的 、 好的代碼； (2) 更重要的是來自可信源的代碼可能存在 bug， 從而對用戶系統(tǒng)帶來惡劣的影響 。 對這個問題的理想解決方法就是阻止不安全的行為 。 接下來討論三種解決惡意代碼問題的技術：安全解釋器 、 故障隔離和代碼驗證 。 第 13章 移動代碼安全 1． 安全解釋器 直接運行二進制代碼是很危險的 ， 解決這個問題的常用方法是不使用編譯好的可執(zhí)行代碼 ， 而采用解釋移動代碼的方法 。 在這種情況下 ， 解釋器能很好地控制 Applet并能檢查每一條指令和每一個狀態(tài)以決定是否執(zhí)行 Applet。 這樣 ， 系統(tǒng)的安全性就在于實現(xiàn)解釋器的安全策略的正確性上 。 安全解釋器包括 SafeTcl、SafeTcl擴展 、 Java等等 。 第 13章 移動代碼安全 2． 故障隔離 采用安全的解釋器系統(tǒng)能很好地解決惡意代碼的問題 。 但是 ， 相對編譯的機器碼而言 ， 解釋器存在嚴重的性能缺陷：執(zhí)行 Java Applet比執(zhí)行一般的二進制代碼要慢得多 。 為此可以轉而采用一種稱為 “ 沙盒 ” (sandbox)的方法來獲得安全 。 第 13章 移動代碼安全 在沙盒模式中 ， 下載的不可信代碼的操作將嚴格局限于沙盒中 。 沙盒是由運行代碼的主機特別為移動代碼分配的地址空間 ， 如 Web瀏覽器特別為 Java Applet分配的區(qū)域 。 這時 ， 移動代碼可以在沙盒中運行 ， 但不會超出沙盒的界限 。 例如 ， Applet不能讀取或修改存儲在用戶系統(tǒng)上的文件 。 在某種情況下 ， 即使用戶偶然引入了一個敵意的 Applet， 這個 Applet也不能破壞用戶的系統(tǒng) 。 因此這種沙盒模式為移動代碼提供了一個受限的運行環(huán)境 ， 在此環(huán)境中可以運行從開放網(wǎng)絡中獲得的不被完全信任的代碼 (如 Applet等 )。 第 13章 移動代碼安全 實現(xiàn)沙盒有兩種方法： (1) 插入對地址進行條件檢查的操作 ， 如果地址非法則產(chǎn)生異常； (2) 簡單覆蓋對應沙盒地址的高比特位 。 第一種方法更適合調試 ， 而第二種方法系統(tǒng)開銷小一些 。 采用沙盒模式的主要缺點是可下載的代碼不再是與平臺無關的 ， 而與操作平臺無關原本是 Java系統(tǒng)的主要設計目標之一 。 第 13章 移動代碼安全 3． 代碼驗證 第三種技術是一種稱為證明攜帶碼 PCC(ProofCarrying Code)的技術 [4]。 采用這種技術時 ， 移動代碼主機為 Applet確定安全策略 ， 然后以 Edinburgh邏輯結構 (Logical Framework：用來發(fā)布安全策略和對證明進行編碼 )對安全策略編碼并發(fā)布這個策略 。 Java Applet作者的任務不僅是把 Applet編譯成機器代碼 ， 還要產(chǎn)生一個安全證明 (Safety Proof)， 用來證明這個代碼符合安全策略中指定的安全規(guī)則 (Safety Rules)。 第 13章 移動代碼安全 當用戶下載代碼后 ， 它只要驗證代碼中的證明 ，看是否合法并滿足安全規(guī)則就行 。 如果是則加載代碼并運行它 。 這種方法是否有效的關鍵在于哪些程序特性可以用 LF表示和證實 。 PCC已成功應用于最小和最大 CPU周期限制 、 內存的安全使用 、 網(wǎng)絡帶寬消耗以及類型安全中 。 此外 ， 為 C語言的安全子集開發(fā)了 PCC編譯器 ，它可以自動生成安全證明 。 第 13章 移動代碼安全 PCC是一種很有前景的方法 ， 但是 ， 它也存在一些缺點： PCC與平臺有關； LF編碼的安全策略和安全證明必須和操作系統(tǒng)以及機器硬件密切聯(lián)系 。 更多信息可以參考網(wǎng)站： 第 13章 移動代碼安全 惡意主機 在討論了惡意代碼問題之后 ， 我們開始討論惡意主機問題 。 在移動代理編程中 ， 用戶所關心的是其代理能否被正確執(zhí)行 。 如一個購物代理可能會攜帶電子現(xiàn)金 ， 一個主機就可能會欺騙代理使它為某些商品支付高價錢 ， 甚至竊取代理內的金錢 。 這都是用戶所要面對的安全問題 。 主機為了執(zhí)行代理 ， 需要訪問代理代碼和狀態(tài) ，那么如何保證敏感數(shù)據(jù)的機密性 ， 或者說如何保證代理算法被忠實地執(zhí)行呢 ？ Chess[13]等人認為保護移動代理的限制有： 第 13章 移動代碼安全 (1) 要對代理代碼或狀態(tài)的任意部分保密 ， 就必須采取加密； (2) 我們無法阻止拒絕服務攻擊 ， 因為攻擊者不需要專門可信硬件的幫助就可以任意修改代理代碼或終止代理 。 由此可見 ， 要解決惡意主機問題就要從以下兩個方面著手： (1) 能夠檢驗篡改； (2) 能阻止機密信息泄漏 。 第 13章 移動代碼安全 1． 檢測篡改 我們無法采用技術途徑來使代理不受破壞 ， 但是如果能明確地識別出惡意主機 ， 那么法律的 、 社會的威脅就可能阻止惡意主機的操作員破壞代理 。 識別惡意主機還可能使代理的所有者因代理的損失而獲得某種程度的補償 。 下面將介紹檢測惡意主機的技術 ， 這些技術都是基于公開密鑰基礎設施的 ， 它們允許用戶