我正在尋找在達到以下目標的方式轉換XML文檔的方法:替代PKI數字簽名
- 它可以被分配到在互聯網上已知的應用和管理,他們不任何特殊的存儲要求
- 該應用程序能夠確定該文檔的源
- 中的應用可確定它是否已經被篡改或改變的,因爲它是生成
- 文檔被加密,但是對混淆的目的,而不是因爲它包含敏感信息
- 的應用程序可以讀取XML
這聽起來像一個典型的數字簽名方案的內容。但是,我不希望源和收件人應用程序必須處理與管理公鑰和私鑰相關的後勤問題。
所以,我的問題是:有沒有辦法可靠地滿足這些要求,而不使用數字證書?
我正在尋找在達到以下目標的方式轉換XML文檔的方法:替代PKI數字簽名
這聽起來像一個典型的數字簽名方案的內容。但是,我不希望源和收件人應用程序必須處理與管理公鑰和私鑰相關的後勤問題。
所以,我的問題是:有沒有辦法可靠地滿足這些要求,而不使用數字證書?
如果您沒有真正尋找安全性 - 特別是在僞造/變更方面,嵌入在應用程序中的祕密對稱密鑰足以滿足更改檢測和加密方面的要求。只需使用標準分組密碼和MAC(Message Authentication Code (wikipedia))即可。當然,提取密鑰並更改這些文檔相對簡單。
不幸的是,識別來源有點棘手。當您使用PKI時,身份會隱式出現,因爲每個私鑰隱含地標識了一個實體。由於您沒有這樣一個自然的標識符,您現在需要定義您自己的標識方案:可能是您在運行它的計算機上看到的第一個網絡適配器的MAC地址,或者可能是您明確指定身份的更精細的方案個人應用程序或使用該應用程序的個人。一旦你有了某種形式的身份定義,在將加密/簽名操作作爲一個單獨的XML字段加入之前,將這個標識字符串添加到文檔的開始處會很簡單。
感謝一些有用的指針,@ vhallac,正是我所需要的。經過反思,在我的情況下,識別消息來源並不重要。最重要的因素是能夠檢測原始文檔是否已被更改。 – 2013-05-01 08:49:15
據我瞭解,源應用程序和收件人應用程序都會共享一個密鑰來加密/解密文檔。爲了讓惡意用戶篡改文檔而不會使其變得毫無意義,他們需要獲得密鑰,解密文檔,修改文檔並使用相同的密鑰對其進行重新加密。那將是這種方法的主要弱點? – 2013-05-01 08:51:59
@PaulTaylor另一個問題是,如果對稱密鑰從某個應用程序泄漏,則必須替換/更新所有已對其中的密鑰進行了硬編碼的應用程序。對於PKI,這是不同的 - 在簽名的情況下,您需要驗證證書的有效性,這是非常自動化的過程,並且如果證書在簽名方面被替換,則不需要替換所有驗證器。 – 2013-05-01 13:27:38
對於身份驗證,您需要有一些確保此身份驗證的密鑰方案。如果您不特別喜歡證書,則可選擇使用OpenPGP密鑰進行XML(XMLDSig支持OpenPGP密鑰)。
[披露:我爲餘弦工作由ARX]
不過,我不希望在源和收件人的應用程序必須處理與管理公鑰和私鑰相關的後勤問題。
另一種方式來指揮人員是使用PKI,但通過集中最小化平常PKI後勤問題。
它可以自動生成已經在收件人的機器的信任鏈中的證書。 CoSign和其他人這樣做。
由此產生的數字簽名XML文件可以輕鬆驗證身份/真實性和收件人的完整性,同時最大限度地減少簽署XML文件的管理負擔。
這也有幫助,謝謝@Larry K,我會研究它。但是,即使這在我正在考慮的場景中可能不可行,因爲它需要足夠的權限才能訪問服務器證書存儲。 – 2013-05-02 12:39:33
Re:訪問服務器證書存儲的足夠權限 - 在簽名機器上還是在收件人/驗證機器上? – 2013-05-03 08:14:07
兩者,但收件人特別。 – 2013-05-03 08:26:45
如果不面對密鑰管理,就無法獲得真正的安全性。您必須交換一些關鍵材料,無論是某種對稱算法的預共享密鑰,還是PKI系統中認證機構的公鑰。 – erickson 2013-04-30 21:00:46