加解密模塊使得開發(fā)者可以很容易的在應(yīng)用中使用加解密的相關(guān)功能，例如，加密信息，創(chuàng)建一個(gè)數(shù)據(jù)的hash值，比較hash值，看看數(shù)據(jù)是否被修改。

　　模塊具有下列功能：

• 　　減少實(shí)現(xiàn)標(biāo)準(zhǔn)功能的開發(fā)代碼，加解密模塊實(shí)現(xiàn)了常用的加解密功能。
• 　　在應(yīng)用和跨企業(yè)之間提供一致的加解密策略。
• 　　降低了開發(fā)者為應(yīng)用建立一致的加解密架構(gòu)所需的學(xué)習(xí)曲線
• 　　是可擴(kuò)展的，意味著它支持自定義加解密的provider

　　一、加解密模塊簡介

　　包括下列主題：

• 　　通用解決方案
• 　　示例代碼
• 　　什么時(shí)候使用加解密模塊
• 　　Key的管理和分布
• 　　選擇算法

　　1.1通用解決方案

　　開發(fā)者在開發(fā)的時(shí)候，經(jīng)常需要加密數(shù)據(jù)和hash功能來滿足企業(yè)組織的安全需要。應(yīng)用創(chuàng)建數(shù)據(jù)和管理數(shù)據(jù)，也包括配置信息，通常需要加密。另外，訪問系統(tǒng)需要的密碼和其他信息也需要hash。

　　加解密模塊通過提供抽象出來的加解密provider來簡化開發(fā)者的工作，可以通過配置，再不修改代碼的情況下改變provider。

　　模塊只支持對稱加密算法，對稱加密算法使用相同的key加密和解密。模塊不支持非對稱（也就是公鑰）加密解密，使用一個(gè)key加密信息，使用另外一個(gè)key解密信息。

　　加解密模塊的設(shè)計(jì)滿足了開發(fā)者在開發(fā)應(yīng)用的時(shí)候這方面的常用需求，下面列出了一些常用的解決方案，以供參考：

• 　　配置信息加密
• 　　加密數(shù)據(jù)
• 　　解密數(shù)據(jù)
• 　　獲取數(shù)據(jù)的hash值
• 　　檢查hash值是否和數(shù)據(jù)匹配

　　1.2示例代碼

代碼

<!--<br/ /><br/ />Code highlighting produced by Actipro CodeHighlighter (freeware)<br/ />http://www.CodeHighlighter.com/<br/ /><br/ />-->
???????????? // Encrypt?the?Sensitive?Data?String
???????????? string ?encryptedContentBase64 = Cryptographer?.EncryptSymmetric?( " symmProvider " ,
??????????????????????????????????????????????????????????????????????????? " SensitiveData " );
????????????
???????????? // Decrypt?the?base64?encoded?string
???????????? string ?readableString = string .Empty?;
????????????readableString? = Cryptographer?.DecryptSymmetric?( " symmProvider " ,encryptedContentBase64?);
????????}

?

?

　　1.3什么時(shí)候使用加解密模塊

　　在你需要hash數(shù)據(jù)，或者是對稱加解密的時(shí)候，可以選擇企業(yè)庫的加解密模塊。你也可以自定義加解密的provider。如果數(shù)據(jù)只需要加密，不需要解密，例如：密碼。可以使用hash。如果數(shù)據(jù)需要加密和解密，那就選擇對稱加密算法。

　　使用對稱加密的一個(gè)先決條件是發(fā)送數(shù)據(jù)的應(yīng)用和接受數(shù)據(jù)的應(yīng)用之間是可信任的。例如，發(fā)送方和接受方是同一個(gè)應(yīng)用。這種限制通常會(huì)不適合一些需要網(wǎng)絡(luò)傳輸數(shù)據(jù)的應(yīng)用。在使用加解密模塊的時(shí)候，有兩點(diǎn)也需要考慮：

　　1）對稱密鑰的管理

　　2）選擇hash值，還是選擇對稱加密算法

　　1.4管理和分布key

　　對稱加密算法在加密和解密的時(shí)候使用同一個(gè)key，發(fā)送數(shù)據(jù)和接受數(shù)據(jù)的雙方都必須要具有key。任何拿到這個(gè)key的應(yīng)用也都可以加密和解密數(shù)據(jù)。這就意味著，如果攻擊者獲得key，就可以拿到加密的數(shù)據(jù)內(nèi)容。攻擊者也可以通過刪除或者是破壞key，使得正常應(yīng)用無法讀取數(shù)據(jù)。一個(gè)key文件是一個(gè)加密文件，里面包括了加解密所需要的key。需要很小心的管理key，可以考慮下面的方式：

• 　　使用Access Control List （ACL訪問控制列表）保護(hù)key，只有授權(quán)才可以訪問key文件。
• 　　在高危環(huán)境關(guān)閉電腦的遠(yuǎn)程調(diào)試。例如，服務(wù)器的匿名訪問。

　　加解密模塊將每一個(gè)key文件存在在本地計(jì)算機(jī)，配置節(jié)<securityCryptographyConfiguraion>中包含了每個(gè)文件的絕對地址。為了保護(hù)key，在寫入文件的時(shí)候使用了DPAPI加密了key信息。如果使用加解密，一定要保證路徑地址也是加密值。例如，你可以將ACLs值包含在路徑加密值中。如果應(yīng)用需要其他硬件輔助的加密，需要修改模塊的源代碼來滿足需求。

　　模塊不完全解決key的分發(fā)問題。如果key只是在自己的安全的計(jì)算機(jī)上使用的話，很容易解決分發(fā)問題。但是，如果是在多個(gè)地方共享key，需要仔細(xì)的計(jì)劃。一個(gè)辦法是用企業(yè)庫的配置工具，在你分發(fā)之前導(dǎo)出key文件。導(dǎo)出key的時(shí)候設(shè)置一個(gè)password。在另外的地方使用企業(yè)庫配置工具導(dǎo)入key的時(shí)候需要輸入密碼。

　　1.5算法的選擇

如果一個(gè)加解密算法被破解，或者算法是很容易被暴力破解的，加解密provider就不是安全的。自定義的算法在沒有測試的時(shí)候是很容易被破解的。相反，使用公用的，著名的加密算法是經(jīng)得起考驗(yàn)的。

　　如果計(jì)算能力增加的話，推薦增加key的長度。目前情況，加密key的長度在128-256位之間是較為安全的，目前大多算法至少都是128位。

　　hash算法中，推薦用 SHA256 算法，算法使用的hash大小是256位。SHA1 hash算法是16位的，這種算法是可以接受的，但是不夠的。MD4和MD5不在推薦使用。

　　對稱加密算法中，推薦使用 AES ，也叫做Rijndael。這個(gè)算法的key長度支持128、192、256位。DES算法不在推薦使用。

　　未完待續(xù)。。。。。。。。。。。。。。。。。。。。

微軟企業(yè)庫4.1學(xué)習(xí)筆記（二十一）加解密模塊1 簡介