SHA256を使ってXMLを署名しないでください。

Question

質問するのは奇妙な質問ですが、試してみます。

ターゲットフレームワークを4.5.2として使用してプロジェクトを開始しました。要件はSHA1アルゴリズムを使用してXMLファイルに署名することでした。私は、このMSDNのページで例を使用し、それがうまく働いた：

• https://msdn.microsoft.com/en-us/library/ms148731(v=vs.110).aspx

はその後、要件はSHA256アルゴリズムに変更しました。私は、元のコードを適応させるためにそれらのページ内のコードを使用し、それがうまく働いた、私はその時によって、ターゲットフレームワークとして4.6を使用していました：

• https://blogs.msdn.microsoft.com/winsdk/2015/11/14/using-sha256-with-the-signedxml-class/

• の.NET Framework 4.6.2が追加されますRSA-SHA256 を使用してXML文書に署名するためのサポート

[Iは、2つの以上のリンクを投稿することができません]それから私は、フレームワークのバージョン4.6.2がSHA256を完全にサポートを追加したことを発見し、暗号いますConfig.AddAlgorithm（）呼び出しはもはや必要ではありませんでした。プロジェクトをバージョン4.6.2に変更し、必要な変更を加え、CryptoConfig.AddAlgorithm（）呼び出しについてコメントしました。うまくいきました。

しかし、私たちのソフトウェアはWindows XPで動作するように変更しました（はい、まだ使用しています）。XP（SP3）で動作する最後のフレームワークバージョンはv4.0です。したがって、SHA256を使用してXMLファイルに署名することがフレームワーク4.0で機能するかどうかをテストする必要がありました。

ターゲットフレームワークをv4.0に変更して変更を開始しました。私がCryptoConfig.AddAlgorithm（）呼び出しで使用したRSAPKCS1SHA256SignatureDescriptionクラスは、フレームワーク4.5以降でしか使用できないため、一部のWebページで見たように、独自のバージョンを作成する必要があります。

しかし、今は変です。私はCryptoConfig.AddAlgorithm（）コールが何が起こるかを見るためにコメントしたので、私はカスタムクラスを書くことができましたが、ちょうどうまくいきました！

私は、CryptoConfig.AddAlgorithm（）がプロジェクトまたは自分のマシンのどこかにアルゴリズムを登録していると考えました。私はそれについて研究しましたが、何も見つかりませんでした。だから私は別のマシンで試してみましたが、それも機能しましたが、そのマシンは前のコードを実行していた可能性があります。私は別のマシンを試しました。そのマシンは確かではありませんでしたが、そこでも働いていました。

私はプロジェクトを見たことがないマシンに行きました。その時、私はそれをコンパイルし、実行可能ファイルを配備しました（他のマシンでVSプロジェクトを実行していました）。そのマシンで4.0以降の.NET Frameworkをすべて削除し、アプリケーションを実行しようとしました。そして...それはまだ動作します！ SHA256を使ってXMLに署名し、正常に動作します。これらのマシンはすべてWindows 10を実行しています。

何が起こっているのですか？

Answer 1

対象のバージョンと実行しているバージョンが同じではありません。 4.0〜4.7のターゲットは4.7ランタイムで実行されます。サポートを追加することは非破壊であったので、ターゲットバージョンのバックアウトではサポートされませんでした。

WinXPには4.6.2がないので、自分でハンドラを追加する必要があります。どのようなフレームワークXPをターゲットにしていても、利用可能なAPIに制限されますが、ランタイムが異なる動作をする可能性があるため、ターゲットOSで実際にテストする必要があります。

Answer 2

私はいくつかの研究を行ってと.NET Frameworkに関するいくつかのことを学んだMarteen Bodewesコメントとbartonjs答え後。過去に私は.NETのサイドバイサイド機能に関するMicrosoftのマーケティングを本当に買ったが、というのバージョンのフレームワークはすべて同じマシン上に共存すると思っていた。今日私はそれがまさにそうではないことを学んだ。

まず、CLRとフレームワークは、必ずしも一緒に歩くわけではない別のものです。 Common Language Runtime（CLR）は、並行して共存するかどうかを判断するためのフレームワークの重要な部分です。 1.0、1.1、2.0および4：今日によってCLRの唯一の4バージョンがある

• https://docs.microsoft.com/en-us/dotnet/standard/clr#versions-of-the-common-language-runtime

同じCLRバージョンを共有するすべてのフレームワークのバージョンは、インプレースの交換となります以前のバージョンのしたがって、マシンにFramework 2.0だけがあれば、CLR 2.0とFramework 2.0を使用できます。そのマシンにFramework 3.5をインストールしても、CLR 2.0がありますが、Framework 2.0は3.5バージョンに置き換えられます。その後、Framework 4.0をインストールすると、CLR 2.0とCLR 4、Framework 3.5とFramework 4.0があります。 Framework 4.5を同じマシンにインストールすると、CLR 4が残りますが、今度はフレームワーク4.0がバージョン4.5に置き換えられました。

私のマシンでは、「C：\ Windows \ assembly」パスの下にv2.0とv4.0のフォルダしかありません。私は、ランタイム中に.NET DLLがそのパスからロードされていることに気付きました。それでも、私は 'C：\ Windows \ Microsoft.NET \ Framework'の目的が何であるかは分かりません。

しかし、私はバートンに尋ねた質問に答えなかった：新しいバージョンのフレームワークが、同じマシンから同じCLRを共有する以前のバージョンをなくした場合、どのクラス、メソッド、プロパティなどがVisual Studioにあるかプロジェクトのために選ばれたその特定の目標フレームワークに対して有効ですか？

だから私はスコットHanselman氏によって、この優れた記事が見つかりました：

• https://www.hanselman.com/blog/NETVersioningAndMultiTargetingNET45IsAnInplaceUpgradeToNET40.aspx

をそして答えは：ディレクトリの下に「C：\プログラムファイル（x86の）\リファレンスアセンブリ\マイクロソフト\ Framework \ .NETFramework 'は、マシンを通過したすべてのバージョンのアーカイブで、Visual Studioではそれらを使用しています！ （なぜ、これらのものはすべて1つの場所にあり、本当に並んでいるわけではないのですか？）

これらすべての回答の後、私は何が起こっているのかよく理解しました。私はすべてをアンインストールしたので、最後のマシンにフレームワーク4.7がインストールされていましたが、Visual Studio Community 2017をインストールしてテストをキャンセルしましたが、Visual Studio Installerは既にインストールされていました。マシンに最後のフレームワークを置く）、Windows XP SP3でアプリケーションを実行したときに本当に失敗したのは驚きではありませんでした。しかし、今私は何をすべきか正確に分かっています。