2009-12-24 317 views
0

是否有一種將AES密鑰與應用程序一起運輸的好方法,但是仍然足夠安全嗎?存儲AES密鑰

我不太喜歡硬編碼鍵的想法(因爲應用程序可以反編譯),但是另一種方法是將它們保存在遠程服務器上,這對服務器來說看起來相當危險或者網絡中斷。

我知道Java提供的機制叫做key-store,但是AFAIK,如果代碼是反編譯的,那麼這個key-store也可以打開?

有什麼想法?

在此先感謝!

回答

1

你不能相信你的應用程序來保證你的密鑰安全。你不能相信該應用程序真的是你的。

您可以安全地傳輸密鑰,因爲在應用程序末端沒有硬件保護您的密鑰,這意味着您丟失了密鑰,任何擁有十六進制編輯器或調試器的人都可以將密鑰從您的應用程序中取出。

如果一個應用程序「需要」一個密鑰,我會試圖讓每個用戶(或許可證)只是一個私鑰和證書。

然後,您可以使用簽名檢查和Diffie-Hellman密鑰交換,在運行時從網絡服務器爲應用程序的每個許可實例提供一個密鑰。這也可以讓你確保只有一個許可證實例正在運行。

+0

嗨。 是否有任何實施此方法的開源(首選)/商業軟件包? 謝謝。 – SyBer 2009-12-31 13:49:22

+0

您可以使用OpenSSL的庫或標準JCE完成所有這些工作。 – IanNorton 2011-04-13 19:42:01

0

這取決於你打算使用什麼鑰匙,什麼算作「足夠安全」,但總的來說,我不認爲你可以在客戶端的機器上使用鑰匙執行代碼,並仍然阻止客戶從獲得鑰匙。

+0

只是想加密一些信息,這些信息將存儲在一個純文件中。 – SyBer 2009-12-24 17:00:40

+1

如果你想防止臨時用戶(而不是一個確定的逆向工程專家),AES是一種矯枉過正。在這樣的情況下,我使用了一個簡單的異或密鑰加密和一個硬編碼的密鑰。一般來說,所有數據保護任務都有兩種形式 - 防止錯誤的用戶和防止故意破解的良好意義。第二個更復雜;就你而言,這在理論上是不可解的。所以假設你正在解決第一類問題並採取相應的行動。 – 2010-01-02 01:49:25

4

你必須更好地描述應用程序。

如果您試圖將密鑰從安裝軟件的計算機的所有者處絕對安全,你不能。你不應該嘗試。這是他們的機器,他們有權知道它的一切。

在某些軟件的每個副本中嵌入相同的對稱密鑰似乎是一種糟糕的設計。對稱密鑰應該是新鮮生成的,然後使用一些非對稱算法進行交換。這樣,只有公鑰的完整性需要得到保護;如果有人發現密鑰並不重要。

+0

我想使用密鑰加密剩餘寬限期的數量 - 即應用程序運行所剩的時間,但無法連接到在線授權機構進行許可證檢查。 你能提供一些關於非對稱密鑰的更多信息嗎? 有沒有在這方面的Java的任何好的文章? 謝謝。 – SyBer 2009-12-24 17:26:56

0

不,這些鍵應該由應用程序本身生成並由用戶存儲。如果您傳輸的私鑰已經損失了很多,幾乎與丟失私有密鑰副本一樣多,然後再發貨。

用戶的安全不應該成爲目標。

+0

爲什麼我迷路了,如果密鑰移動通過SSL? – SyBer 2009-12-24 17:07:55

+0

因爲你擁有你的私鑰。當至少有兩個人擁有該密鑰時,這使得兩倍的安全難以保證。如果你只是在客戶端機器上加密信息,那麼所有的_you_需要的是他們的公鑰,它是安全的傳輸。私鑰應該鎖定在只有加密人員才能訪問的小盒子中。 否則跳過AES,只是去做3DES。如果您沒有利用公鑰/私鑰架構,請不要使用它。 – 2009-12-24 18:05:03

+0

我需要在同一臺機器上同時加密和解密信息。 密鑰在傳輸後保持非常短的時間,然後丟棄。 那麼還有什麼風險嗎? – SyBer 2009-12-25 20:49:51

3

如果應用程序使用密鑰,密鑰將在某個時間位於內存中。一個足夠複雜的用戶/攻擊者可以看到它。調試器和適時的斷點是他們需要的。

+0

你在這裏,仍然需要更大的經驗水平,這可能只有攻擊者的1%。 – SyBer 2009-12-24 17:08:42

+0

取決於用戶羣。和數據的價值。實際上攻擊的攻擊者很複雜:) – 2009-12-24 17:25:46

1

不,傳送私人加密密鑰是一個壞主意。

一個典型的方法是將加密密鑰存儲在配置文件中,該配置文件在安裝/更新時由系統管理員或部署人員編輯。密鑰本身可以通過安全(加密)電子郵件進行通信,或通過電話簡單地讀出,或者只是在安裝時隨機產生(針對每個用戶)。

+0

爲什麼它很糟糕,如果鏈接是安全的,例如HTTPS? – SyBer 2009-12-24 17:27:41