By now you've probably already created your first "Hello World" application using one of the languages in the .NET Framework such as C# or VB.NET - or perhaps you've even managed VC++. The .NET Framework allows all kinds of different languages to utilize code written in various other languages and by other vendors. But there's a downside: how do you make sure your code isn't used by unauthorized clients?

There's been an enormous amount of marketing and publicity surrounding the .NET Framework and all of the wonderful things it can do for you. If you browse the Web at all, then you simply can't escape the onslaught of advertising and marketing related to how Web services will be changing the future of programming and the future of the Web.

One of the features that Microsoft uses as a selling point for their adventurous new framework is the concept of Code Access Security (CAS). Every piece of code executed by the Common Language Runtime (CLR) runs within a security context. Such code is granted permissions based on various identifying factors that are also the elements that contribute to the strong name of an assembly. They are:

• Filename: The filename of the assembly itself (such as MyAssembly.DLL or MyProgram.EXE)
• Culture: The target culture of the assembly (such as en, fr, or fr-CA)
• Version: The version number of the assembly
• Public Key: A key that's assigned to your assembly when you build it against an RSA signature file

It is the last of these, the public key, that we'll focus on in this article.

Keeping Out Unauthorized Users

Administrators can execute a security policy that grants or revokes permissions at various levels throughout the enterprise to assemblies based on any of the above identifying characteristics. This allows an administrator to prevent a given assembly from contacting hosts on the Internet or from deleting files from the local hard drive.

It's fine that administrators can control what code is allowed to do - and what it's not allowed to do - on their own machines. But problems arise when the developers and the administrators have a conflict of interest.

Take the following scenario: you're the publisher of some software that reads and writes its data in an encrypted, proprietary format. This is advantageous to you because only your software can read and write this data. Now, along comes .NET and you convert your software to .NET and distribute it. Let's say you have a class library that manages all of the I/O with regard to your proprietary file type. Well, with command-line utilities like ILDASM.EXE and programmatic tools using Reflection, anyone can simply examine the metadata for that assembly and get a detailed description of all methods and their arguments. It would take a programmer only a few minutes to determine how to use your assembly to manipulate your proprietary files.

Obviously, you don't want this to happen. There are countless other scenarios in which companies need to protect their own interests by preventing their APIs and classes from being executed by unauthorized users.

Strong-Naming an Assembly

It might look bad, but you do have an option. Earlier, we mentioned that you can strong-name an assembly by signing it with an RSA signature file. This creates a public/private key pair and stores that pair in a file. All assemblies built using this signature file will expose the same public key, which allows them to be identified as coming from the same publisher. No one can produce an assembly with the same public key unless they manage to get access to your RSA signature file.

To create this RSA signature file, open up a command prompt (preferably the one Visual Studio .NET provides, which automatically configures your path settings) and type the following:

SN -k SecureProducts.snk

This is an excerpt from the complete article that will be featured in the printed Preview Issue of .NET Developer's Journal. To read the article in full, subscribe now. With your subscription confirmation, you'll get the online password to read this and other .NETDJ articles. You can also look for the special preview of the print edition of .NET Developer's Journal on newsstands and in bookstores. Both the print Preview Issue and the online archives are available now.