Rsa
數字證書是如何工作的，為什麼不能從簽名文件中逆向工程？
如今，數字證書非常普遍地用於簽署文件。它們被各種作業系統用來確保可靠性和安全性。例如，Android 要求在 Android Market 上送出的每個應用程序都使用證書進行簽名，並且任何更新都使用相同的證書進行簽名。這可以防止任何入侵帳戶的人用他們自己的可能是惡意的應用程序替換該應用程序。
我的問題有兩個部分：
- 這些證書實際上是如何工作的？它類似於數字簽名的工作方式嗎？
- 為什麼無法逆向工程並從已簽名的文件中創建證書？如果您同時擁有同一個文件的簽名副本和未簽名副本，答案會改變嗎？這是否因算法而異？
為簡化起見，假設我們的證書是由 Java JDK 中的密鑰工俱生成的，使用 RSA 算法，密鑰大小為 2048 位（這有關係嗎？），有效期為 10000 天。
這樣的證書基本上只是數字簽名的一種實現。一個證書用於使用私鑰對數據進行簽名，並與簽名和數據一起將相應的驗證證書提供給使用者。使用者使用驗證證書來驗證文件是否與其簽名匹配。
由於公鑰/私鑰的加密屬性，您無法從驗證證書對簽名證書進行逆向工程。無論他們使用什麼簽名算法，私鑰都應該無法從公鑰中導出。究竟為什麼這很困難（或至少被認為是困難的）取決於所使用的確切算法，但作為一般規則，它們都具有此屬性。
一個範例情況，對於一個虛構的應用商店/市場系統：
- 開發人員通過市場所有者在市場中創建一個帳戶，並向市場所有者提供其公共證書的副本。
- 開發人員使用他們的私有證書籤署應用程序，並將應用程序、簽名和公共證書提供給市場所有者。
- 市場所有者驗證證書是否與他們記錄中的開發者證書相匹配。
- 市場所有者使用公共證書驗證應用程序的簽名是否有效。
- 市場從應用程序中剝離簽名和證書。
- Market 使用自己的私有證書對應用進行簽名，並將簽名和公共證書放入應用中。
- 下載該應用程序的任何人都會驗證公共證書是否與其設備的本地副本相匹配（它可能具有所述證書的內置副本），並且他們會根據市場所有者的公共證書驗證應用程序的簽名。
出現了很多變化和復雜性。當證書被洩露時會發生什麼，如何撤銷它？如果使用者失去了他的證書怎麼辦？如果市場所有者想要使用多個證書怎麼辦？證書有效期怎麼算？等等。但這是這種系統如何使用證書工作的一般模型。