使用數字簽名簽署強名稱程序集是不好的做法嗎？

Question

我很好奇，通過谷歌研究，我一直在學習數字簽名和強烈命名的程序集。 如果您真的努力，似乎可以使用數字簽名來簽署強名稱的程序集。

我推測，通過這種做法，可以通過這種方式使用它來規避數字簽名的目的。

微軟說：

“強名稱本身並不意味着一種信任程度，例如通過數字簽名和支持證書提供的信任。”
- http://msdn.microsoft.com/en-us/library/wd40t7ad%28v=vs.110%29.aspx

我是否正確地猜測以這種方式使用數字簽名實際上是一種不好的做法，這可能會造成安全漏洞並且絕對沒有用處？ 或者甚至可能嗎？ 使用數字簽名作為強名稱可能或更好然后什么都不做？ 除了正確使用數字簽名之外，它是否提供了額外的安全性。

Answer 1

使用數字簽名簽署強名稱程序集是不好的做法嗎？

不，這是一個非常好的做法。

如果您真的努力，似乎可以使用數字簽名來簽署強名稱的程序集。

這有點棘手，因為強大的命名和數字簽名都會修改程序集。 程序集必須首先強名，然后簽名。

我推測通過這種做法可以通過這種方式使用它來規避數字簽名的目的，因為強烈命名的程序集可以被黑客攻擊

好的，所以你猜測有攻擊。 我猜測沒有。 說明漏洞和建議的攻擊。

（至少有些帖子說過）。

你打算讓我們猜猜哪個帖子這么說了嗎？

“強名稱本身並不意味着一種信任程度，例如通過數字簽名和支持證書提供的信任。”

那是對的。 強名稱和數字證書類似，但它們解決了不同的問題。 強名稱解決了裝配問題的識別問題。 簽名解決了信任鏈問題。

我已經看到過互聯網海報的例子，他們試圖正確地認為他們正在保護自己的軟件。

無論是強命名還是證書簽名都不能保護軟件 ！ 安全系統的目的不是保護軟件 ，而是保護用戶 。 我們沒有駕駛執照來保證機動車輛部門免受忍者襲擊。 我們有駕駛執照，證明駕照的持有人確實是他們所說的並且被允許駕駛的人。 任何認為強有力的命名保護軟件的人都非常非常困惑。

我是否正確地猜測以這種方式使用數字簽名實際上是一種不好的做法，這可能會造成安全漏洞並且絕對沒有用處？

不，你錯了。

跨越溪流是好事還是壞事（請原諒幽默。）？

為什么這會是一件壞事？ 我們所擁有的只是你聲稱存在攻擊，並且沒有任何證據確實存在攻擊。

或者甚至可能嗎？

當然有可能。

我所看到的帖子中提到使用兩個一致的方式（使用數字簽名來簽署一個特別強烈命名的組件（不是數字簽名））可能或更好然后什么都不做？

您要求我們評論我們尚未閱讀的帖子的准確性，而您尚未提供鏈接。 我們應該怎么知道它們是否准確？

Answer 2

用於強烈簽署程序集的密鑰不存在信任鏈。 您不能使用相同類型的密鑰進行強名稱簽名和“代碼簽名”：因此“混合和匹配”沒有問題。 這兩種類型的簽名服務器有兩種不同的用途，您需要在特定情況下選擇您需要的那些（很可能只是強名稱簽名而.Net沒有內置驗證的另一個）。

通過簽名強名稱，您不能說特定密鑰是否屬於特定實體，不像其他類型的簽名，您知道簽名證書的來源（即，身份驗證簽名或HTTPS的SSL證書），並且可以合理地確定原點。

強烈簽名告訴您由相同“實體”創建的相同密鑰簽署的程序集，但沒有指示此“實體”是什么/誰。 你不能說“這個新版本的裝配是由FooBar公司制造的”，你只能說“它與前一個公司/集團共同構建”。

注意：確實有一些“眾所周知的”公鑰（即由Microsoft簽名的框架程序集），但是你不能通過查看公鑰來獲得任何程序集並說“由X簽名”。

請注意，Eric Lippert在回答 - .NET程序集的簽名中詳細介紹了這一點。

Answer 3

把它分成清楚的部分，因為我不太清楚你在問什么。

是否可以使用數字簽名的私鑰（例如Authenticode）來強烈命名程序集？

是的，至少在理論上 - 因為所有的密鑰都是一個字節序列。

這樣做有什么意義嗎？

由於您不需要為強名稱支付私鑰，因此使用付費數字簽名來做這件事就沒有多大意義了。 您支付的是與數字簽名相關的信任。 正如Eric Lippert，Alexei和其他人所解釋的那樣，強有力的命名並沒有得到信任。

如果你這樣做，那會是一個安全漏洞嗎？

不管你是數字簽名還是強命名，無論你使用什么私鑰，你所提供的所有組件都是公鑰。 公鑰意在為公眾所知-這就是非對稱加密的整點。 只要您的私鑰保持私密，就沒有漏洞。

ETA：我希望看到問題中提到的帖子，關於使用Authenticode簽名進行強命名（而不是將兩者結合使用）。