摘要本文描述了如何用Code Access Security技術來保護代碼使代碼不致被惡意調用
作為一名NET開發人員你沒日沒夜地寫代碼你的組件運行在越來越多的機器上忽然有一天你發現你寫的組件被引用在別人寫的項目裡而且最可氣的是那人竟用你的名義在做破壞它人系統的惡事！你忍不住了大叫一聲Oh shit！然後打開MSDN看看有什麼辦法能幫助你阻止這場陰謀
OK辦法找到了那就是NET平台提供的Code Access Security有大量繼承於CodeAccessPermission的類可以幫你實現不同方面不同范圍的代碼安全控制你所需要做的只是從中挑出最適合的類別加以應用從而達到保護你的組件的目的
在經過一番挑選之後你最終確定了使用StrongNameIdentityPermissionAttribute類這個類允許你將組件（或類方法）與某一強名稱（通常就是你發布程序時所用的強名稱）綁定這樣只有在客戶端程序具有該強名稱簽名的情況下才能使用你的組件也就是說除了你自己編寫的客戶端代碼因為擁有同樣的簽名而被允許使用組件以外任何第三方代碼都無法通過StrongNameIdentityPermissionAttribute的防護因此也就無法惡意調用你的組件了）聽起來真的不錯馬上就動手做吧！
為了簡便起見先創建一個很簡單的Class Library項目代碼如下
// SecureCompdll
using System
namespace musicland
{
public class SecureComp
{
public string Confidential（）
{
return This is confidential！
}
}
}
現在的這個組件非常可憐因為任何人都可以寫代碼來調用它下面你就要耍點手段了）
首先引入SystemSecurityPermissions命名空間
using SystemSecurityPermissions
然後在組件級加上StrongNameIdentityPermissionAttribute屬性
[assembly StrongNameIdentityPermissionAttribute（SecurityActionRequestMinimum
PublicKey=ccd+
fddbbadfcedddccedacbceaeecdf+
debcabfafcbfafbbcefbeeffcebfdf+
aacfccadbdeeacccacbafcacfebeab）]
namespace musicland
…
注意這裡使用了SecurityActionRequestMinimum這申明除非獲得StrongNameIdentityPermissionAttribute所表明的資源訪問權限（即對SecureCompdll組件的訪問權限可以把SecureCompdll看作一樣資源）否則CLR不會准許調用方（即客戶端代碼）訪問所請求的資源此外在PublicKey屬性中加入了你所允許的公匙（Public Key）的十六進制表示（轉化成字符串類型）CRL在運行期間將依照這一段公匙來判斷調用方是否合法除非調用方擁有相應的私匙（Private Key）否則將無法訪問看來平時一定要倍加保護你的密鑰文件因為密鑰文件（特別是private key）的洩露將會成為你無盡惡夢的根源而延遲簽名（delay signing）在這裡也就顯得格外重要了）
說到這裡你一定會有個大大的問號這長長的一串PublicKey是怎麼得出來的？難道要我憑空湊出來不成？當然不是還記得那個Snexe工具嗎？通過它就可以把PublicKey給提取出來OK打開你的命令行定位到密鑰文件所在目錄並輸入以下內容
sn –p Keysnk PublicKeysnk
這樣提取出來的公匙信息就被存儲在PublicKeysnk文件中你現在只需把公匙信息讀取出來並轉化成適當的格式就可以了這裡你可以使用NET Framework自帶的Secutilexe工具但據我所了解Secutil工具的輸出都是數組格式（我在自己的機器上測試了Secutil所提供的全部輸出選項但所得結果都是一樣這讓我很感意外不知大家是否有更好的辦法）因此就動手自己寫了一個小工具來完成這一讀取和轉換大家如果感興趣可以發郵件給我（因為我沒有自己的網絡空間可以存放當然你也可以自己來寫因為它實在是太簡單了就是讀取二進制文件）
好了現在你的代碼就被全副武裝起來了試著寫一個Console客戶端來調用SecureComp結果怎麼樣？是不是無法獲得相應權限？試著用Keysnk給客戶端程序簽名後再訪問這回可以訪問了吧！）
結論適當地應用Code Access Security可以使你的代碼被保護起來不致被第三方不正確調用但是過多的安全保護也將造成代碼運行效率下降從而帶來負面影響
From:http://tw.wingwit.com/Article/program/net/201311/12839.html
