問題タブ [snk]

.snk ファイルとは何ですか? 私はそれがStrongly Named Keyの略であることを知っていますが、それが何であり、どのように機能するかについてのすべての説明は頭を悩ませています。

厳密に名前が付けられたキーがどのように使用され、どのように機能するかについて簡単な説明はありますか?

.snk ファイルを使用してクラス ライブラリに厳密な名前を付けた場合、同じライブラリの新しいバージョンを作成する場合、この .snk ファイルを新しいものに置き換える必要がありますか?

.NET アセンブリの署名に使用される .snk RSA キーペア ファイルを、PHP やその他のソフトウェアで使用できる XML ベースのファイルに変換する方法を教えてください。

XML ファイルのサンプル:

相互運用機能を介して、多くのマネージアセンブリとActiveXおよびCOMコンポーネント（C ++で記述）を参照するマネージアプリケーションに強い名前を付けたいと思います。また、強い名前のアセンブリは弱い名前のアセンブリを参照できないため、特にActiveXとCOMの相互運用機能を処理するときに、どのような問題に備える必要があるのか​​、何に遭遇したのかを教えてください。

このアプリケーションのソリューションは大きいです。これは、マネージドC＃、Vb.net、ネイティブC ++、およびマネージドC ++/CLIの50以上のプロジェクトで構成されています。したがって、あなたが提供する情報や実生活の話が多ければ多いほど、私はより良い準備をして頭痛から身を守ることができます。

ありがとう。

検証をスキップした後、GACからインストールおよびロードできる遅延署名付きアセンブリのセットを使用しています（sn -Vr * .. ..

プロセスとしての遅延署名には公開鍵ファイルのみが必要なので

1. sn -k keys.snk（公開鍵と秘密鍵の両方）
2. sn -p keys.snk pkey.snk（公開鍵のみ）
3. プロジェクトのプロパティにpkey.snkを追加し、[遅延記号のみ]をオンにします
4. sn -v（アセンブリが遅延署名されていることを表示します）
5. sn -e（pkeyを抽出）
6. fc（差分が見つかりません）

SNKファイルの最初の160バイトはPKey ...であり、残りの436バイトは秘密鍵を表していることがわかりました。

開発目的では、sn-Vrまたはsn -R keys.snk（遅延署名されたものを置き換える新しい公開/秘密鍵のペア）で十分ですが、アセンブリから公開鍵を抽出してペアリングするかどうかを知りたいです。あなた自身の秘密鍵でうまくいくでしょう...

これは潜在的なセキュリティの抜け穴である可能性があります（アセンブリは公開鍵トークンで検索されるため）...これを可能にする組み込みツールが.Net Framework/SDKにないのも不思議ではありません。

SNKファイル構造（ファイル形式）全体が文書化されているところはありますか？このアプローチは、一般的に機能しますか？どう思いますか？

Visual Studio 2008 を使用しており、複数のプロジェクトを含むソリューションがあります。アセンブリに署名するための 1 つの snk があり、これはソリューション フォルダーにあります。

各プロジェクトに snk をリンクしましたが、リンクされた snk でプロジェクトに署名しようとすると、ファイル ダイアログで snk ファイルが見つかりません。

ここで一歩を踏み外しましたか？

署名アセンブリの背後にある基本的な考え方は理解していますが、Telerik またはサード パーティの DLL を使用するときに問題があります。2 つの独自の .DLL を使用する .exe があります。これらの DLL は、エンタープライズ ライブラリ DLL と Telerik DLL を使用します。

私はすべてのプロジェクトに厳密な名前 .snk を付けましたが、コンパイラをコンパイルすると、エンタープライズ ライブラリ DLL などは署名されていないと説明されます。これは理にかなっています。

te sn.exe -Vr コマンドで検証を無効にしたり、プロジェクトの署名を遅らせたりしたくありません。しかし、これはどのように機能するのでしょうか？洞察力に感謝します。

.snkファイルを使用してマネージC++プロジェクトに署名しようとすると、このエラーが発生するのはなぜですか。「......SlimDX\ build \ vs2010 \ x86 \ Debug \VOS.snk'に署名に必要な秘密鍵がありません」

プロジェクト設定で設定してみました::

1. キーファイル=$（ProjectDir）x86 \ $（Configuration）\ VOS.snk
2. 遅延記号=いいえ（/ DELAYSIGN：NO）

そして、iv'eはAssemblyInfo.cppで設定しようとしました::

1. [アセンブリ：AssemblyKeyFile（ "VOS.snk"）]
2. [アセンブリ：AssemblyDelaySignAttribute（false）]

.snkファイルと.pfxファイルの両方があります。ここで何が欠けていますか？.snkファイルはC＃.NET3.5プロジェクトで必要なすべてです...マネージC++プロジェクトでも機能しないのはなぜですか？何らかの方法でpfxファイルを使用する必要がありますか？

時々、強い名前でコンパイル結果に署名するために使用される.snkファイルを含むサンプルプロジェクトがネットワーク上に表示されます。

ちなみに、これは明らかに間違っています。.snkファイルが公開されると、元のコードサプライヤから出荷されたが、現在は悪意のあるコードが含まれているアセンブリを置き換えるために使用できるアセンブリを誰でも作成できます。.snkファイルを出荷する人は、そのリスクを真剣に扱っておらず、ファイルを出荷するだけだと思います。そうしないと、プロジェクトが既成でコンパイルされないためです。

「便利」以外に.snkファイルを発送する理由はありますか？

厳密な名前 (.snk ファイルに格納されたキーペア) による署名は、(他の用途の中でも)アセンブリの偽造から保護することを目的としています。

例: 厳密な名前で署名されたアセンブリを出荷した後、他の開発者が私のアセンブリを使用したため、そのアセンブリには私のキーペアの公開キーに言及している私のアセンブリへの参照が含まれています。一部のユーザーは、その開発者アセンブリと私のアセンブリをインストールし、その開発者のコ​​ードを喜んで使用します。他の誰かが私のバージョンのように見えるアセンブリを作成しようとし、それが「インストールする価値のある更新」であることをユーザーに納得させた場合、私は自分のキーペアを制御しており、偽造されたアセンブリは同じキーペアで署名されていないため、偽造されたアセンブリは読み込まれません。 . わかりました。

しかし、悪意のある当事者が私のアセンブリと他の開発者の依存アセンブリの両方を偽造し、それらの両方を「出荷」することを防ぐのは何ですか? 彼らは私のアセンブリとその開発者のアセンブリを取得し、両方を改ざんし、私のアセンブリの偽造バージョンに任意のキーで署名し、それへの参照を依存アセンブリの偽造バージョンに追加し、署名してから両方を出荷します。つまり、悪意を持って 2 つのアセンブリを「出荷」することは、1 つのアセンブリを「出荷」するよりもはるかに難しくないはずです。

厳密な名前で署名すると、複数のアセンブリの偽造からどのように保護されますか?