Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Assemblies can be digitally signed with a private key. The result is called a <a href="http://msdn.microsoft.com/en-us/library/wd40t7ad.aspx" rel="noreferrer">strong named assembly</a>.</p> <p>When a strong named assembly is loaded, .NET automatically checks whether its signature matches the embedded public key. So when a strong named assembly has been loaded, you have the guarantee that the author posseses the private key that corresponds to that public key.</p> <p>You can get the public key by calling <a href="http://msdn.microsoft.com/en-us/library/xbe1wdx9.aspx" rel="noreferrer">Assembly</a><a href="http://msdn.microsoft.com/en-us/library/y3bk16ya.aspx" rel="noreferrer">.GetName()</a><a href="http://msdn.microsoft.com/en-us/library/system.reflection.assemblyname.getpublickey.aspx" rel="noreferrer">.GetPublicKey()</a> and then compare it to the expected one, i.e. yours.</p> <p>You can scan over the plugin assemblies, create an <code>AssemblyCatalog</code> for each one with the right public key (rejecting the others), finally aggregating them into an <code>AggregateCatalog</code> and building a <code>CompositionContainer</code> with it.</p> <p>This is basically what Glenn Block also explained in <a href="http://mef.codeplex.com/Thread/View.aspx?ThreadId=79489" rel="noreferrer">this thread</a>. (Best ignore the blog post linked there by Bnaya, his interpretation of <code>StrongNameIdentityPermission</code> is not correct.)</p> <p><strong>edit</strong> with responses to the wall of comments:</p> <blockquote> <p>To get that public key, I make the console application output the public key byte array to somewhere. I embed the byte array in my host application, and subsequently use that to compare against the public keys of plugin candidates. Would that be the way to do it?</p> </blockquote> <p>Yes, but there is a simpler way to extract the public key. Look at the <code>-Tp</code> option of <a href="http://msdn.microsoft.com/en-us/library/k5b5tt23(VS.71).aspx" rel="noreferrer">sn.exe</a>.</p> <blockquote> <p>Does this mechanism automatically prevent a malicous plugin assembly from exposing a correct, but "faked" public key? As in, is there some mechanism to disqualify any assembly that is signed, but has a mismatch between its exposed public key and it's internal private key, from being loaded/run at all?</p> </blockquote> <p>As far as I know, the check happens automatically. A strong named assembly cannot be loaded (even dynamically) if its signature is wrong. Otherwise the strong name would be useless. To test this, you can open your strong named assembly in a hex editor, change something (like a character in a <code>const string</code> embedded in the assembly) and verify that the assembly can no longer be loaded.</p> <blockquote> <p>I guess what I was referring to was something akin to the type of hack/crack described here: <a href="http://www.dotnetmonster.com/Uwe/Forum.aspx/dotnet-security/407/Signed-assemblies-easily-cracked" rel="noreferrer">http://www.dotnetmonster.com/Uwe/Forum.aspx/dotnet-security/407/Signed-assemblies-easily-cracked</a> and here: <a href="http://blogs.msdn.com/b/shawnfa/archive/2008/05/14/strong-name-bypass.aspx" rel="noreferrer">http://blogs.msdn.com/b/shawnfa/archive/2008/05/14/strong-name-bypass.aspx</a> </p> <p>[...snip more comments...]</p> <p>However, this can - apparently - be bypassed by simple tampering (as shown in first link, > and explained more here): grimes.demon.co.uk/workshops/fusionWSCrackOne.htm</p> </blockquote> <p>The "attacks" you refer to fall in three categories:</p> <ul> <li>removing the strong name altogether. This does not break the authentication, the assembly will no longer have a public key and so you will reject it.</li> <li>disabling the strong name check, which requires full access to the machine. If this was done by an attacker, then it would mean that the attacker already owns your machine. Any security mechanism would be meaningless in such a context. What we are actually defending against is an attacker <em>between</em> the machine and the source of the assemblies.</li> <li>a real exploit made possible by a bug in .NET 1.1 that has since been fixed</li> </ul> <p>Conclusion: strong names are suitable to use for authentication (at least since .NET 2.0)</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload