對稱密鑰存儲

Question

我的公司將爲我們的客戶存儲敏感數據，並將使用其中一個受管.NET加密算法類對數據進行加密。大部分工作已經完成，但我們還沒有弄清楚如何/在哪裏存儲密鑰。我已經做了一些輕鬆的搜索和閱讀，看起來像一個硬件解決方案可能是最安全的。有沒有人有關於關鍵存儲解決方案或方法的建議？

---

感謝您的回覆，每個人。

spoulson，這個問題實際上都是你提到的「範圍」。我想我應該更清楚。

數據本身以及加密和解密數據的邏輯被抽象到ASP.NET配置文件提供程序中。此配置文件提供程序允許加密的配置文件屬性以及純文本屬性。加密屬性值的存儲方式與純文本格式完全相同 - 明顯的例外是它們已被加密。

這就是說，關鍵需要能夠被傳喚的三個原因之一：

1. 授權的Web應用程序，授權的服務器上運行，需要對數據進行加密。
2. 與＃1相同，但用於解密數據。
3. 我們業務團隊的授權成員需要查看加密數據。

我想象的方式是，沒有人會真正知道關鍵 - 將有一塊軟件控制數據的實際加密和解密。也就是說，關鍵還是需要來自的某處。如果你之前沒有做過這樣的事情，那麼如果我完全不瞭解我應該如何工作的理由，那麼請讓我知道。

Answer 1

這個問題（技術方面）只有兩個真正的解決方案。 假設它只是需要訪問關鍵應用程序本身的...

1. 硬件安全模塊（HSM） - 通常是相當昂貴的，而不是簡單地實現。可以是專用設備（例如nCipher）或特定令牌（例如Alladin eToken）。然後，您仍然必須定義如何處理該硬件...

2. DPAPI（Windows數據保護API）。在System.Security.Cryptography（ProtectedMemory，ProtectedStorage等）中有這樣的類。這將操作系統的密鑰管理交給了操作系統 - 它處理得很好。在「USER_MODE」中使用，DPAPI會將密鑰的解密鎖定給加密它的單個用戶。 （沒有得到太多的細節，用戶的密碼是加密/解密方案的一部分 - 沒有，更改密碼不犯規不起來。）

新增：最好使用DPAPI保護您的萬能鑰匙，而不是直接加密應用程序的數據。並且不要忘記在您的加密密鑰上設置強大的ACL ...

Answer 2

Microsoft Rights Management Server (RMS)也有類似的問題。它只是通過使用主密碼加密其配置來解決它。 ...密碼上的密碼，如果你願意的話。

Answer 3

最好的辦法是在物理上保護鑰匙所在的硬件。另外，千萬不要將它寫入磁盤 - 找一些方法來防止將這部分內存分頁到磁盤。當加密/解密密鑰需要加載到內存中時，以及不安全的硬件始終存在這種攻擊場所。

像你說的那樣，有硬件加密設備，但它們不能縮放 - 所有加密/解密都通過芯片。

Answer 4

您可以使用另一個使用PBKDF2之類的密碼從另一個對稱密鑰中加密對稱密鑰。

讓用戶出示密碼，生成用於加密數據的新密​​鑰，使用密碼生成另一個密鑰，然後加密並存儲數據加密密鑰。

它不如使用硬件令牌安全，但它可能仍然足夠好，並且使用起來非常簡單。

Answer 5

我想我誤解了你的問題。你所要求的不在應用程序如何處理其關鍵存儲的範圍內，而在於你的公司將如何存儲它。

在這種情況下，你有兩個明顯的選擇：

• 物理：寫入USB驅動器，刻錄到CD等存儲在物理上安全的位置。但是，您遇到遞歸問題：您將密鑰存儲在Vault的哪個位置？通常，您委派2個或更多人（或團隊）持有密鑰。

• 軟件：Cyber-Ark私人方舟是我公司用來存儲其祕密數字信息。我們存儲所有管理員密碼，許可證密鑰，私鑰等。它通過運行未加入域的Windows「保險庫」服務器，防火牆除自身以外的所有端口，並存儲其在磁盤上加密的所有數據。用戶通過首先對用戶進行身份驗證的Web界面進行訪問，然後通過類似瀏覽器的界面與Vault服務器進行安全通信。記錄所有更改和版本。但是，這也具有相同的遞歸問題......主管理員訪問CD。這存儲在具有有限訪問權限的實體保管庫中。

Answer 6

在寫出之前，使用硬編碼的密鑰來加密生成的密鑰。然後你可以在任何地方寫。

是的，您可以找到硬編碼的密鑰，但只要您認爲可以將對稱密鑰存儲在任何地方，它的安全性並不低。

Answer 7

根據您的應用程序，您可以使用Diffie-Hellman方法讓雙方安全地達成對稱密鑰。

經過初始安全交換後，密鑰得到認可，會話的其餘部分（或新會話）可以使用此新對稱密鑰。

Answer 8

從OP應對這一answer＃3

一個經授權的會員才能查看加密數據的方式，但沒有他們實際知道的關鍵是使用密鑰託管(rsa labs)(wikipedia)

總之，關鍵是分解成單獨的部分，並給予'受託人'。由於私鑰的性質，每個片段都是無用的。然而，如果需要解密數據，那麼'受託人'可以將他們的部分組合成整個密鑰。

Answer 9

我們有同樣的問題，並且經歷了相同的過程。
我們需要在一臺計算機（客戶端）上啓動進程，然後登錄到另一臺計算機（數據庫服務器）。

目前，我們認爲最好的做法是：

• 操作員手動啓動客戶端PC上的過程。
• 客戶端PC提示操作員他的個人登錄憑證。
• 運營商輸入他的憑證。
• 客戶端PC使用這些登錄到數據庫服務器。
• 客戶端PC從數據庫服務器請求自己的登錄憑證。
• 數據庫服務器檢查操作員的登錄憑證是否有權獲取客戶機進程的憑證並將其返回給客戶機。
• 客戶端PC註銷數據庫服務器。
• 客戶端PC使用自己的憑證登錄到數據庫服務器。

實際上，操作員的登錄密碼是關鍵，但它不存儲在任何地方。