AES 加密和密鑰存儲？

Question

幾年前，當第一次接觸到 ASP.net 和 .NET 框架時，我構建了一個非常簡單的在線文件存儲系統。 該系統使用 Rijndael 加密來存儲服務器硬盤上加密的文件，並使用 HttpHandler 來解密這些文件並將其發送到客戶端。

作為我使用 ASP.net 和數據庫的第一個項目之一，我不太了解整個事情的工作原理（以及落入Jeff Atwood 在這個主題上描述的同一個陷阱），我決定將新生成的密鑰和 IV 與每個一起存儲數據庫中的文件條目。

為了讓事情更清楚一點，加密只是為了保護文件不被直接訪問服務器，密鑰不是由用戶輸入的密碼生成的。

我的問題是，假設我不想為所有文件保留一個密鑰，我應該如何存儲加密密鑰以獲得最佳安全性？ 什么被認為是最佳實踐？ （即：在不同的服務器上，在純文本文件上，加密）。

另外，這種類型的加密算法中使用的初始化向量是什么？ 它應該在系統中保持不變嗎？

Answer 1

密鑰應該受到保護並保密，簡單。 實施不是。 密鑰管理系統由可靠的供應商以大量資金出售，因為解決問題很困難 。

您當然不希望為每個用戶使用相同的密鑰，使用的密鑰越多，它就越容易破壞它，或者至少有一些信息泄漏。 AES是塊密碼，它將數據拆分為塊，並將最后一個塊加密的結果提供給下一個塊。 初始化向量是算法的初始提要，因為在起點處沒有任何內容可以開始。 使用具有相同密鑰的隨機IV會降低信息泄露的風險 - 對於每個加密的數據，它應該是不同的。

如何存儲密鑰取決於系統的架構方式。 我剛剛完成了一個KMS，其中密鑰遠離主系統，加密和解密的功能通過WCF公開。 您發送純文本並獲取對密鑰和加密文本的引用 - 這樣KMS負責系統中的所有加密。 在您的情況下，這可能是矯枉過正的。 如果用戶在系統中輸入密碼，則可以使用該密碼生成密鑰對。 然后，此密鑰對可用於加密該用戶的密鑰存儲區 - XML，SQL，等等，並用於解密用於保護數據的每個密鑰。

如果不了解您的系統配置方式或其目的，除了“必須保護密鑰，密鑰和IV不得重復使用”之外，很難推薦其他任何內容。

Answer 2

在http://web.archive.org/web/20121017062956/http://www.di-mgt.com.au/cryptoCreditcard.html上有一篇關於這篇文章的非常好的文章，它涵蓋了IV和腌制問題以及歐洲央行提出的問題如上所述。

誠然，它仍然沒有完全覆蓋“我在哪里存儲鑰匙”，但在閱讀並消化之后，希望解決方案不會是一個巨大的飛躍......

Answer 3

作為一個非常好的解決方案，您可以將Key / IV對存儲在表中：

ID                    Key           IV
skjsh-38798-1298-hjj  FHDJK398720== HFkjdf87923==

保存加密值時，請保存ID和隨機Salt值。

然后，當您需要解密該值時，使用id和與數據一起存儲的salt查找key / iv對。

您需要確保在密鑰存儲周圍有一個良好的安全模型。 如果使用SQL Server，請不要向從應用程序訪問數據庫的用戶授予SELECT權限。 你不想讓某人訪問整個表。

Answer 4

如果您只是為每個用戶生成一個密鑰，然后用“主密鑰”加密它呢？ 然后，確保有隨機的 ivs，只要你對主密鑰保密，任何人都不能大量使用任何數量的密鑰。 當然，加密和解密功能必須在服務器端，而且主密鑰根本不暴露，甚至不暴露給服務器的rest。 這將是一個不錯的方式 go 關於它，但顯然，存在一些問題，即，如果您不安全地存儲了您的主密鑰，那么您的安全性就會下降。 當然，您可以對主密鑰進行加密，但是您只是把罐頭踢了下來。 也許，你可以有一個 AES 密鑰，用 RSA 密鑰加密，然后 RSA 密鑰由秘密密碼保護。 這會緩解這個問題，就好像你有一個大小合適的 RSA 密鑰，你應該很好，然后你可以向客戶端公開加密功能（盡管可能仍然不應該）並且因為密鑰加密使用公鑰，你可以把那個拍下來。 為了增加安全性，如果需要，您可以每隔幾個月甚至幾周循環一次 RSA 密鑰。 這些只是一些想法，我知道它不是防彈的，但比僅僅將其塞入 sql 數據庫更安全。