JSON.NETなどのさまざまなサードパーティライブラリを使用して構築されたアプリケーションがあります。
アプリケーションを構成するすべてのDLLが、サードパーティのものを含めてデジタル署名されていることを確認したいと思います。これらは作成者によって署名されていないことを考えると、サードパーティのものに自分で署名することはできますか/すべきですか?
JSON.NETなどのさまざまなサードパーティライブラリを使用して構築されたアプリケーションがあります。
アプリケーションを構成するすべてのDLLが、サードパーティのものを含めてデジタル署名されていることを確認したいと思います。これらは作成者によって署名されていないことを考えると、サードパーティのものに自分で署名することはできますか/すべきですか?
インターネットで同じ質問に対する答えを(失敗して)見つけようとしました。
その結果、GoogleとAdobeがどのように製品を提供しているかを確認し、サードパーティのものを含め、フォルダー内のすべてのバイナリが署名されていることを確認しました。
いくつかの例:1。Google Chromeにはpepflashplayer.dllが含まれています。これは、Adobeが著作権を所有していますが、「GoogleInc。」がデジタル署名しています。2. Adobe Readerには、IBMが著作権を所有しているが、「AdobeSystems」がデジタル署名したicudt40.dllが含まれています。
したがって、ベストプラクティスは、サードパーティのものを含め、アプリケーションを構成するすべてのバイナリに署名することだと思います。改ざんが顧客のマシンで発生した場合、改ざんを回避するか、少なくとも簡単に検出するのに役立つため、これは理にかなっています。
強い名前付けについて話しているのですか、それともauthenticode署名について話しているのですか?後者の問題は、authenticode署名付きアセンブリがロードされるとき、.NETが証明書を検証するときであり、一部の構成(たとえば、OCSPをチェックする必要があり、到達できない場合)では、これに数十秒かかる場合があります。このため、authenticodeおよびX.509証明書を使用したアセンブリへの署名を停止する必要がありました。
もう1つの欠点は、署名されたアセンブリが何らかの方法でマルウェアによって使用されている場合、ウイルス対策会社の専門家になりたくない人が、(a)アセンブリをマルウェアとしてマークし、さらに悪いことに、認証局に不平を言う可能性があることです。コード署名証明書を発行すると、証明書は取り消されます。
.NETの厳密な名前付け(証明書のないキーペアを使用)は、多かれ少なかれあなたのプライベートビジネスです。
更新:Authenticodeは通常、PE形式のファイル(EXEおよびDLL)、SYSおよびCABに適用されます。強い命名は純粋な.NET技術です。
警告メッセージは、Authenticode署名について説明しています。インストーラーに署名する必要があり(確かに)、署名されたアプリケーションの実行のみを許可するようにシステムポリシーが設定されていない限り、メッセージを取り除くのに十分です(この場合、アプリケーションのEXEにも署名する必要があります)。