【正文】 (3) 確定跟隨在當(dāng)前指令后面的虛擬機(jī)器指令 。 ● 如果指令要把值壓入堆棧 ， 往堆棧頂端加入指示的類型 ， 需確保堆棧有足夠的空間存放新元素 。 (2) 仿真指令對堆棧和寄存器的影響： ● 如果指令要使用來自堆棧的值 ， 需確保堆棧中有足夠的元素 ， 并且堆棧頂端元素具有適當(dāng)?shù)念愋?， 否則 ，驗(yàn)證失敗 。 數(shù)據(jù)流分析器執(zhí)行如下循環(huán)： (1) 找到一個設(shè)置了 “ changed”位的虛擬機(jī)器指令 ，如果沒有找到 ， 則表示該方法已被驗(yàn)證 。 對每一條指令都有一個“ changed”位來表示這個指令是否需要查看 。 對于第一條指令 ，編號較小的寄存器包含方法類型簽名所指示的類型；堆棧為空；所有其它的寄存器包含非法值；對于其它指令 ， 指示該指令沒有被訪問 ， 還沒有其堆棧或寄存器的信息 。 在確定堆棧中值的類型時 ， 字節(jié)碼驗(yàn)證器不需要區(qū)分不同的整數(shù)類型(如 byte、 short和 char)。 第 13章 移動代碼安全 對每一條指令 ， 在執(zhí)行之前 ， 驗(yàn)證器要跟蹤堆棧和寄存器的內(nèi)容 。 ● 對每一個異常處理程序 ， 其起始點(diǎn)和結(jié)束點(diǎn)都必須指向一個指令的開始 。 如操作碼 ldc1只能用于整數(shù) 、 浮點(diǎn)數(shù)或 string類型 ， 而操作碼 getfield必須引用一個域 。除方法指明的所能用的寄存器外 ， 代碼不能訪問和修改任何其它的寄存器 。 類似的 ， 不允許出現(xiàn)到達(dá)代碼開始前或代碼結(jié)束后的分支 。 這一步中把每個指令轉(zhuǎn)換成一個結(jié)構(gòu) 。 首先 ， 把組成虛指令的字節(jié)分成一系列的指令 ， 每一個指令開始位置的偏移量保存在一個位表中 。這個替換的指令表示已經(jīng)執(zhí)行了對這個指令的驗(yàn)證 ，不需要再次驗(yàn)證了 。 在執(zhí)行完驗(yàn)證后 ， 字節(jié)碼流中的指令就會被另一種形式的指令所代替 。 指令第一次調(diào)用方法或訪問 、 修改域時 ， 驗(yàn)證器需： ● 確保方法或域存在于給定的類中； ● 檢查方法或域是否具有要求的簽名； ● 檢查當(dāng)前正在執(zhí)行的方法是否有權(quán)訪問給定的方法或域。 如一個方法調(diào)用另一個返回 foobarType類型對象的方法時 ， 如果立即把同一類型的域分配給返回的對象 ，驗(yàn)證器就不會驗(yàn)證 foobarType類型是否存在；如果把a(bǔ)notherType類型的域分配給返回的對象 ， 則必須裝載foobarType和 anotherType的定義以確保 foobarType是anotherType的一個子類 。 在 “ 字節(jié)碼驗(yàn)證 ” 中我們將進(jìn)一步描述這一步的細(xì)節(jié) 。 第 13章 移動代碼安全 (3) 這一步是類驗(yàn)證中最復(fù)雜的一步 ， 在這一步中需要驗(yàn)證每一個方法的字節(jié)碼 。 第 13章 移動代碼安全 (2) 第二步更進(jìn)一步驗(yàn)證類文件的格式： ● 確保 final類沒有被繼承 ， final方法沒有被覆蓋； ● 每個類必須有一個超類； ● 確保常數(shù)存儲庫滿足一定的限制 ， 如其中的類引用必須包含一個指向存儲庫中的一個 unicode字符串引用的域 。 下面詳細(xì)介紹驗(yàn)證器的驗(yàn)證過程 ， 其中提到的類文件格式的具體細(xì)節(jié)可參考參考資料 [5]： (1) 驗(yàn)證的第一步發(fā)生在將類讀入解釋器時 。 如解釋器能肯定代碼遵守以下限制： ● 代碼中不存在緩沖區(qū)溢出； ● 所有的寄存器訪問和存儲都是合法的； ● 所有字節(jié)碼的參數(shù)都是正確的； ● 不存在非法的數(shù)據(jù)轉(zhuǎn)換 。 第 13章 移動代碼安全 字節(jié)碼驗(yàn)證器同樣可以增強(qiáng)解釋器的性能 。而且，方法或變量也可能從公有變成私有。如用戶編譯好了一個類，假設(shè) PurchaseStockOptions是 TradingClass的一個子類。 如 HotJava瀏覽器是下載已經(jīng)編譯好的類文件 ， 它無法確定下載的字節(jié)碼是由可信的 Java編譯器編譯的還是由某個有惡意企圖的編譯器編譯的 。 編譯器還要確保程序沒有訪問未初始化的本地變量 。 Java語言是強(qiáng)類型的： ● 在運(yùn)行期 ， 如果不進(jìn)行明確的檢查不能把對象分配給某個子類； ● 要檢查所有對方法和變量的引用以確保對象具有合適的類型 。 Java通過自動垃圾收集 (周期性地釋放沒有被引用的內(nèi)存 )來避免這些問題 。 第 13章 移動代碼安全 4) 通過垃圾收集獲得安全 在 C/C++中 ， 編程人員經(jīng)常面對的問題是內(nèi)存分配和釋放 。 第 13章 移動代碼安全 3) 通過摒棄指針獲得安全 Java摒棄了 C語言中的指針?biāo)惴?， 因此編程人員無法偽造指針來訪問內(nèi)存 。 第 13章 移動代碼安全 2) 通過明確定義獲得安全 Java語言的定義非常嚴(yán)格： ● 保證所有的基本類型使用指定的長度； ● 所有的操作必須按指定的順序執(zhí)行 。 第 13章 移動代碼安全 Java底層安全性實(shí)現(xiàn) 1. 底層安全 Java解釋器通過以下幾種方式實(shí)現(xiàn)底層安全： 1) 通過發(fā)布源代碼獲得安全 如果需要 ， Java解釋器和編譯器均可獲得完整的源代碼 。 第 13章 移動代碼安全 ● 多線程： Java提供了一個內(nèi)建的機(jī)制來提供對多個并發(fā)子任務(wù)的支持 。 ● 高性能：由于解釋字節(jié)碼的性能一般都是比較高的 ， 從而 Java可以在運(yùn)行時直接將字節(jié)碼翻譯成機(jī)器指令 。 總之 ， 在 Java語言規(guī)范中沒有任何與具體實(shí)現(xiàn)相關(guān)的內(nèi)容 。 為此 ， Java定義了獨(dú)立于平臺的基本數(shù)據(jù)類型及其運(yùn)算 ， 從而使得 Java數(shù)據(jù)在任何硬件平臺上都是一致的 。 但僅僅如此還不夠 ， 不同操作系統(tǒng)基本數(shù)據(jù)類型的設(shè)計實(shí)現(xiàn)是不同的 ， 如在 Windows (int)為 16位 ， 在 Windows 95中為 32位 ， 而在 DEC Alpha中卻為 64位 。 Java的做法是讓編譯器生成與特定計算機(jī)體系結(jié)構(gòu)無關(guān)的字節(jié)碼指令 ， 這些字節(jié)碼指令在任何機(jī)器上都很容易解釋 ， 并能很容易地翻譯成本機(jī)機(jī)器代碼 。 本節(jié)的后續(xù)內(nèi)容將詳細(xì)介紹 Java的安全實(shí)現(xiàn)以及其潛在的安全威脅 。類型檢查可以檢查出許多開發(fā)早期出現(xiàn)的錯誤； Java沒有采用 C++中的指針?biāo)惴ǘ鴮?shí)現(xiàn)了真數(shù)組 ， 從而避免了覆蓋內(nèi)存和破壞數(shù)據(jù)的可能 。 Java應(yīng)用程序通過 URL打開和訪問網(wǎng)絡(luò)上的對象與編程人員訪問本地文件系統(tǒng)一樣簡單 。 第 13章 移動代碼安全 ● 面向?qū)ο螅汉?C++一樣 ， Java是一種面向?qū)ο蟮木幊陶Z言 。 在 C和 C++中 ， 一個復(fù)雜的操作是內(nèi)存管理：內(nèi)存分配和內(nèi)存釋放 。 在 Sun Microsystems公司提供的技術(shù)報告 [5]中稱： “ Java是一種簡單的 、 面向?qū)ο蟮?、 適合網(wǎng)絡(luò)編程的 、 解釋的 、健壯的 、 安全的 、 與結(jié)構(gòu)無關(guān)的 、 可移植的 、 高性能的 、 多線程的動態(tài)語言 。 這些問題的存在或許可以解釋移動代理為什么得不到廣泛應(yīng)用 。 第 13章 移動代碼安全 3． 總結(jié) 相比惡意代碼而言 ， 惡意主機(jī)問題更難以處理 ，目前還沒有實(shí)際的 、 在計算上可行的方法用來檢測篡改 ， 而一些可以用來證明發(fā)生了篡改的技術(shù)也會大大增加服務(wù)器的負(fù)荷 。 其中 ， E為某個加密函數(shù) 。 方案的本質(zhì)是這樣的：代理程序計算某個函數(shù) f，主機(jī)為代理計算 f(x)但不需要知道 f的任何實(shí)質(zhì)性的內(nèi)容 。 如有時候采用法律行動的代價比篡改帶來的經(jīng)濟(jì)損失更大；有些時候 ， 代理發(fā)送數(shù)字簽名 ， 但由于某些原因其私鑰已被泄漏 。是不能實(shí)現(xiàn)的。構(gòu)造全息樣片 y39。這樣，服務(wù)器就可以采用哈希樹的方案將樣片散列成一個小的根值，然后把根值返回給代理所有者，由所有者判斷 y是否正確。具有如下特性：代理所有者只需要檢查 y39。從而，主機(jī)把 y編碼成全息樣片 y39。主機(jī)執(zhí)行完代理后把 y發(fā)送給代理所有者，由所有者驗(yàn)證 y。 第 13章 移動代碼安全 Yee提出了一種投機(jī)的方法來檢測語義上的篡改。 當(dāng)服務(wù)器僅僅通過與正在運(yùn)行的代理進(jìn)行欺詐性的交互實(shí)現(xiàn)篡改時 ， 上述方案就無法自動檢測到 。 第 13章 移動代碼安全 PRACs允許代理所有者 (同時擁有 k k …、 kn)自動地對返回代理中包含的每一部分結(jié)果進(jìn)行密碼驗(yàn)證 。 在第 i個服務(wù)器 ， 代理使用密鑰 ki對其執(zhí)行結(jié)果進(jìn)行簽名并由此產(chǎn)生 PARC；在轉(zhuǎn)移到下一個服務(wù)器之前 ，代理把 ki從狀態(tài)中刪除 。 Yee[4]提出了兩種檢測惡意主機(jī)篡改代理的方法 。 第 13章 移動代碼安全 這種方法在實(shí)際的操作中存在兩個問題： (a) 這種方法在主機(jī)違規(guī)操作時不會向代理所有者發(fā)出警報 ， 而只有在所有者懷疑時提供一種可驗(yàn)證的識別方法； (b) 在需要生成執(zhí)行跡時 ， 服務(wù)器需要保存所有的執(zhí)行跡 ， 這就給服務(wù)器帶來了非常高的負(fù)擔(dān) 。 第 13章 移動代碼安全 一旦執(zhí)行完畢 ， 服務(wù)器就計算整個執(zhí)行跡的密碼散列值并將它返回給代理的所有者 。 首先 ， 將代理代碼的指令分成兩類：只依賴于代理內(nèi)部狀態(tài)的指令以及其結(jié)果依賴于和計算環(huán)境交互的指令 。 第 13章 移動代碼安全 (1) 執(zhí)行跟蹤 。 下面將介紹檢測惡意主機(jī)的技術(shù) ， 這些技術(shù)都是基于公開密鑰基礎(chǔ)設(shè)施的 ， 它們允許用戶 、 主機(jī)和代理之間相互認(rèn)證 。 第 13章 移動代碼安全 1． 檢測篡改 我們無法采用技術(shù)途徑來使代理不受破壞 ， 但是如果能明確地識別出惡意主機(jī) ， 那么法律的 、 社會的威脅就可能阻止惡意主機(jī)