首 頁 關於德錡 試用申請    
   
CPU、操作系統與編程語言

在上一節說明了解釋執行與編譯執行的語言後,我們知道現有開發語言所實現的加密性能實際上是比較差的,但現今世界上的開發語言大多是以執行的效率、易學性和可移植性為標準的,沒有那種語言是以加密性為標準的語言,如果我們希望編制加密性特別強的軟體的話,不得不從現有的環境出發,採用一些特別的方法來提高軟體的安全性能,本文就這個問題來提出一些能夠提高軟體加密性能的方法來同大家討論一下。

 

任何軟體編制都離不開特定的CPU、操作系統以及編程語言。雖然現在有Java等號稱可以不依賴任何CPU和操作系統的編程語言,但實際上只是Java虛擬機替你完成了這些工作。而且由於這些語言都不是真正的編譯性語言,所以加密性都很差。一個軟體的加密性是否良好同具體的CPU、操作系統與編程語言是有很大關係的。如果要破解一個在SGI工作站上的程序一定比PC上的程序要難得多。實際上並不是SGI工作站上的程序編得特別好,而是人們對SGI工作站的了解要比對PC的了解少得多,而且也很難找到相關的系統資料。這裡有個加密方面的摩爾定律,某種技術的普及化程度越高,那麼它的加密性就越差。例如我用VB寫一個程序,其中調用了大量的ActiveX,COM等控件,而且針對MMX、3DNow、SSE..做了具體的優化。這樣的程序要比用完全用VC寫的程序的安全性要好得多,因為這完全是一種純技術上的比拼,如果某個黑客對VB,ActiveX,COM的技術及內部工作原理十分清楚的話,可能破解這種程序要比VC編寫的程序容易許多。但一個人的精力是有限的,不可能去了解所有的技術。一個人學習如何使用ActiveX來編程序可能只需要2-3天的時間,但如果要完全搞懂ActiveX的工作原理的話,恐怕沒有十天半個月是不行的。而且上面這些方法都不需要加密方面的專家就能實現,一個好的工程師只要多花些心思就能夠完成。對PC而言,經歷了DOS、Win31、Win95/98、WinNT、Win2000等一系列操作系統的變遷。在DOS下面的程序基本都是16位段模式、單任務、線性指令流式編程。而在Win31下面已經轉變為保護模式以消息傳遞為基礎的編程,到了Win95/98/NT/2000又轉向了32位保護模式、多任務、以消息傳遞為基礎的編程。在不同平台下的編程方式的區別也很大,但相對於傳統的單任務、線性指令流的編程方式,Win32下面的消息傳遞和多任務方式的編程大大增加了軟體的復雜性,如果能夠好好利用這一點,軟件的加密性能夠提升到一個相當的高度。通常我們認為軟件的加密性與軟件的效率是成反比的,一個軟件如果在加密上面考慮得過多的話,那么執行效率必然要下降。這個問題是因為大多數的軟件開發者都是在軟件完成后才開始考慮加密性的問題,這樣的加密不但斧鑿的痕跡特別明顯而且帶來軟件效率的下降。實際上如果能在軟件編制的初期就能考慮到加密性的問題,這個問題很容易解決。就我們常說的面向對象編程(OOP)來說,大多數人只是在被動的使用OOP來編程,而在具體的函數功能實現上往往還是傳統的模塊化思想。如果能夠把每個函數每個功能都細化成OOP,軟體的加密強度自然會大大的提高,而且軟體的可維護性也會很好。針對核心的計算函數進行特定CPU的優化(FPU、MMX、3DNow、SSE...),不但軟體的加密性提高,而且運算速度也會大大的加快。如果說軟體的加密性同軟體的執行效率是不沖突的話,那麼軟體的加密性同軟件的可移植性就很難共存了,因為你不可能希望一個能鎖住所有門的鎖有很好的安全性。不同的平台、不同的CPU都會產生不同的加密方式,但軟體必然是在特定的CPU和操作系統平台上執行,針對特定平台的優化,不但是安全性的要求,更多的是執行效率上的考慮。

Copyright © 2000-2003 德錡實業有限公司