How can I prevent unauthorized code from accessing my assembly in .NET 2.0?

Question

In .NET 1.x, you could use the StrongNameIdentityPermissionAttribute on your assembly to ensure that only code signed by you could access your assembly. According to the MSDN documentation,

In the .NET Framework version 2.0 and later, demands for identity permissions are ineffective if the calling assembly has full trust.

This means that any application with full trust can just bypass my security demands.

How can I prevent unauthorized code from accessing my assembly in .NET 2.0?

Answer 1

As per Eric's suggestion, I solved it by checking the key myself. In the code I want to protect, I add the following call,

EnsureAssemblyIsSignedByMyCompany( Assembly.GetCallingAssembly() );

Then the implementation of that method is

  /// <summary>
  /// Ensures that the given assembly is signed by My Company or Microsoft.
  /// </summary>
  /// <param name="assembly"></param>
  private static void EnsureAssemblyIsSignedByMyCompany( Assembly assembly )
  {
     if ( assembly == null )
        throw new ArgumentNullException( "assembly" );

     byte[] pubkey = assembly.GetName().GetPublicKeyToken();
     if ( pubkey.Length == 0 )
        throw new ArgumentException( "No public key token in assembly." );

     StringBuilder builder = new StringBuilder();
     foreach ( byte b in pubkey )
     {
        builder.AppendFormat( "{0:x2}", b );
     }
     string pkString = builder.ToString();
     if ( pkString != "b77a5c561934e089" /* Microsoft */ &&
          pkString != "abababababababab" /* Ivara */ )
     {
        throw new ArgumentException( "Assembly is not signed by My Company or Microsoft. You do not have permission to call this code." );
     }
  }

** Names and keys changed to protect the innocent. Any likeness to real names or companies is merely a coincidence.*

Answer 2

See this article:
http://blogs.msdn.com/ericlippert/archive/2008/10/06/preventing-third-party-derivation-part-two.aspx

Particularly this part:

In recent versions of .NET, "full trust means full trust". That is, fully-trusted code satisfies all demands, including demands for things like "was signed with this key", whether it actually was signed or not.

Isn't that a deadly flaw in the security system? No. Fully trusted code always had the ability to do that, because fully trusted code has the ability to control the evidence associated with a given assembly. If you can control the evidence,then you can forge an assembly that looks like it came from Microsoft, no problem. (And if you already have malicious full-trust code in your process then you have already lost -- it doesn't need to impersonate Microsoft-signed assemblies; it already has the power to do whatever the user can do.)

Apparently, the .Net designers felt that this attribute wasn't very effective for full trust code in .Net 1.x either.