在SQL Server 2008中加密SSN的最佳方式是什麼？

Question

我正在開發一個使用.NET 3.5和SQL Server 2008的新Web應用程序，需要存儲一些社會安全號碼。我一直在做一些關於數據庫加密的初步閱讀，這有點令人困惑。

我很高興使用非對稱密鑰對SSN進行加密，因爲這樣面向公衆的應用程序一旦加密就無法獲取任何數據。我認爲只有管理界面才能夠解密和顯示數據。但它聽起來像SQL Server只使用對稱密鑰來保護數據？

那麼，在SQL Server 2008中加密SSN的最佳方法是什麼？獎勵積分，如果你鏈接到一個很好的教程或兩個。

Answer 1

你真的不想使用非對稱加密，因爲它非常慢。相反，您需要使用非對稱密鑰來保護對稱密鑰，然後保持對稱密鑰的方便。說實話，我會堅持SQL Server中的內容，而不是自己設計一些東西。一個非常好的開始是http://dotnetslackers.com/articles/sql/IntroductionToSQLServerEncryptionAndSymmetricKeyEncryptionTutorial.aspx

Answer 2

如果你加密數據，那麼你必須問問自己誰會解密它。如果您使用非對稱加密系統（例如RSA），則加密使用公鑰，解密使用相應的私鑰; 「不對稱」來自私鑰不能從公鑰重新計算的事實（儘管這兩個密鑰在數學上連接在一起）。

非對稱加密往往會產生開銷。第一種說法是，這種加密必須包含一些隨機部分，因爲每個人都可以加密（公鑰是，公開）：如果加密過程是確定性的，那麼任何人都可以加密所有可能的SSN（少於一個數十億，這對現代計算機來說是非常小的數字）並且與加密值相匹配。因此，在加密期間必須有一些隨機添加，並且加密的SSN大於明文SSN。

已知的非對稱加密系統使用具有自己成本的數學結構。基本上，對於RSA加密系統，使用「足夠強」的密鑰，加密消息的長度至少爲128字節。一些加密系統做得更好;同時堅持走完學術研究的路徑，我可以在41個字節左右（與El-Gamal相比NIST K-163橢圓曲線）做到這一點。小一點似乎更難。

所以難怪一個給定的數據庫系統在默認情況下不會包含這樣的功能。

對於您的問題，您應該首先定義（寫），儘可能清楚，您可以：

• 是什麼，你要保護的數據
• 誰輸入數據
• 是誰應該讀回數據

然後你應該問自己，是否加密是一個適當的工具。當設想的攻擊者可以獲得原始的存儲數據時，加密是很好的。這意味着攻擊者繞過了操作系統的保護。那時，無論操作系統知道什麼，攻擊者也知道。如果數據庫託管在一臺機器上，並且存在可以獲得解密的SSN的接口，那麼該機器「知道」如何獲取數據，攻擊者也是如此......另一方面，如果主機機器操作系統被認爲具有足夠的彈性，那麼加密似乎根本不需要。

對數據庫的對稱加密可能會解決一個較弱的問題，攻擊者在此之後獲取硬盤的副本，然後。主機系統知道對稱加密密鑰，但只知道它在RAM中。竊取硬盤的攻擊者不會擁有該密鑰。

Answer 3

如果您必須存儲SSN並且希望對它們進行加密，我推薦使用3DES或AES等對稱密鑰加密機制。讓加密密鑰成爲一些通行短語的派生物，只有那些被授權訪問數據的人才知道，並且他們每次訪問數據時都必須輸入密碼。

例：(10+ Character Pass Phrase) -> SHA-1 => KEY.

不要打擾依靠數據庫本身上做加密（儘管當然期待到像TDE或功能的任何主機操作系統運行的全磁盤或文件加密支持作爲二次過所有安全機制），而是使用內置的.NET加密庫以及您正在使用的任何編程語言來讀取和寫入數據庫。

這給你的好處是你不必存儲公鑰和私鑰或者生成這些密鑰（這在計算上很昂貴），而且它們相對較大，所以存儲成本更高（相對）當未經授權的用戶訪問運行您的代碼的機器（不包括用戶輸入密碼短語時發生的中間人攻擊）時，您不必擔心密鑰遭到破壞。其次，它確保了在被訪問時唯一可以解密的方式是由被授權的用戶（知道密碼）。根據您的預算（時間，精力和資源），您可以添加多因素身份驗證，其中加密密鑰源自密碼短語，也包含授權用戶喜歡智能卡的某些令牌。第三，使用對稱密鑰加密算法加密和解密數據將快得多。