Strong Names Explained

Link：Strong Names Explained

Introduction

Strong Name (further referred to as "SN") is atechnology introduced with the .NET platform and it brings many possibilities into.NET applications. But many .NET developers still seeStrong Names as securityenablers (which is very wrong!) and not as atechnology uniquely identifyingassemblies. There is a lot of misunderstanding about SNs (as we could seein the article "BuildingSecurity Awareness in .NET Assemblies : Part 3 - Learn to break Strong Name .NET Assemblies") andthis article attempts to clear those up. Now let's see what SNs are, what wecan use them for and how they work.

Strong Name is a technology based on cryptographicprinciples, primary digital signatures; basic idea is presented in the figurebelow:

At the heart of digitalsignatures is asymmetric cryptography (RSA, EL Gamal), together with hashingfunctions (MD5, SHA). So what happens when we want to sign any data? I'll try toexplain what happens in the figure above.

Details

First we must get a public/privatekey pair (from our administrator, certification authority, bank, applicationetc.) that we will use for encryption/decryption. Then DATA (term DATArepresents general data we want to sign) is taken and run through some hashing algorithm(like MD5 or SHA - however, MD5 is not recommended) and hash of DATA isproduced. The hash is encrypted by private key of user A and attached toplaintext data. The DATA and attached signature are sent to user B who takespublic key of user A and decrypts attached signature where hash of DATA is storedand encrypted. Finally user B runs DATA through the same hashing algorithm asuser A and if both hashes are the same then user B can be pretty sure that the DATAhas not been tampered with and also identity of user A is proven. But this is anaive scenario because it's hard to securely deliver public keys over insecurecommunication channels like Internet. That is why certificates were introducedbut I will not cover it here because certificates aren't used in SNs anddelivery of public key is a matter of publisher's policy (maybe I can coverdistribution of public keys, certificates and certification authorities in another article). Now let's assume that public key was delivered to user Bsecurely.

This process is used in thecreation of SN for .NET applications. You can translate termDATA asassemblies and apply the same steps to them when SNs are used. But what is thepurpose and usage of this SN technology? Simple - there is the only one reason �to uniquely identify each assembly. See section24.3.3.4of CLI ECMA specification where SNs are defined:

This header entry points tothe strong name hash for an image that can be used to deterministicallyidentify a module from a referencing point (Section 6.2.1.3).

SNs are not any securityenhancement; they enable unique identification and side-by-side code execution.

Now we know that SNs are notsecurity enablers. Where to use them then? We can see two scenarios where SNscan be used:

• Versioning
• Authentication

Versioning solves known problem calledas "DLL hell". Signed assemblies are unique and SN solves problem withnamespace collisions (developers can distribute their assemblies even with thesame file names as shown of figure below). Assemblies signed with SNs areuniquely identified and are protected and stored in different spaces.

In addition to collisionprotection, SN should help developers to uniquely identify versions of their.NET assemblies.

That is why when developers wantto use GAC (Global Assembly Cache) assemblies must be signed to separateeach publisher's namespace and to separate each version.

The second important feature ofStrong Names is authentication; a process where we want to ensure ourselvesabout the code's origin. This can be used in many situations, such as assigninghigher permissions for chosen publishers (as will be shown later) or ensuringthat code is provided by a specific supplier.

It has been shown that signaturesand public keys can be easily removed from assemblies. Yes, that is right butit is correct behavior even when we use digital signatures in emails oranywhere else! Let's see how it works!

We can use some analogy from ourreal life. Let's assume you are a boss of your company and you are sending anemail to your employees where new prices of your products are proposed. Thisemail is a plaintext and you use some non-trusted outsourcing mailing services.Your communication can be easily monitored and your email can be easily accessedby unauthorized persons who can change its content, for instance your pricesproposed in email.

How to solve that? The answer is cryptography,again digital signatures that you can use to authenticate to your employees andto verify content of your email. Simply you have to add a digital signature toyour email and thenrequire your employees will trust just verifiedemails that have your valid digital signature. Let's assume that all PKIinfrastructure is set up and working correctly. Now, when an intruder removesthe digital signature from your email, his employees will not trust thembecause they can't be verified and application will alert users about this insecurestate.

The same situation is when SNsare used. You can remove SNs from assemblies , but this makes no sense because justas in the case of emails, assemblies without SNs can't be trusted whenenvironment is set up to require those digital signatures or SNs.

This is also related to another veryimportant point in .NET � Code Groups & Policy Levels. As inthe case of emails, when PKI is setup in a company and security policy is defined thatemployees can't trust and verify emails which are not signed or where the encryptedhash value is different from hashed plaintext content. The same can be donewith .NET Framework using the.NET Configuration tool on each machine orby group policy for large networks.

This tool provides configurationoptions for .NET Framework including Runtime Security wherepolicylevels and code groups can be set. Policy levels work onintersection principle as shown in the figure below

Code groups (inside of those policylevels) provide permission sets for applications that belong to them accordingto their evidence (origin, publisher,strong name etc.). The assembly will getthose permissions based on the intersection of code groups from each policylevel applicable to it. This is a very important improvement in securityarchitecture and improves the traditional Windows security model that is processcentric (see figure below).

.NET introduces Code AccessSecurity (CAS) which is used to identify the origin of code and assign to it specificrestrictions and then make security policy more granular and protecting againstattacks such as luring attacks.

However my intention isn't todescribe CAS or Windows security internals (I can write about it in otherarticles) but show SN principles. Let's move back to it!

Now we can move to the second usefor SN - administrators and developers can use SNs together with code groups toprovide assemblies with higher permissions (not the default ones that assemblywill acquire according to default .NET Framework settings). Let's see anexample! I must point out that this is just a simplified example how SN canidentify publisher, this is NOT a way to obey CLR security or how to use itin enterprise environment.That is why please try to understand the exampleas a general principle available with SNs but NOT as a design pattern!Usage of SNs as authentication is a more complex problem and there are manynon-trivial issues when SNs are involved. But it's out of scope of this article,so now back to the sample!

Take my sample Windows Formsproject and rebuild it and put .exe file on any share on your LAN. Then try tostart this application from this share and click on button � what happens? A securityexception is raised because application doesn't have enough privileges.

Now go to .NET Configuration tooland add a new code group

add new code group called Test

and in the second dialog choose Strong name, click onImport button and locate the .exe file in Debug folder of project folder andfinally assign full trust for this application

Now you have created a new code group containing justyour sample application. Now go to your network share and try to start sampleapplication again. And it works! Why? Because it belongs to our new code groupTestwith full trust permissions.

Now remove SN from sample application (as described in his article or justsimply remove attribute [assembly: AssemblyKeyFile("KeyFile.snk")]fromAssemblyInfo.cs file), recompile and publish it on share. Try torun it and what happens? It's not working! Why? Because assembly can't show thisstrong name evidence and it belongs to the default code group (with limitedprivileges) now.

It's not surprising, nothing special, no magic � justcorrect usage of Strong Name technology. SNs are easy and powerful butwe have to understand how andwhere to use them. That is why I want tooutline some "issues" that are connected with SNs that will present allcapabilities that we can expect from SNs.

So what are the weaknesses of SNs? First we have to realizethat SNs are a lightweight version of Authenticode and they provide fast and easilyused technology to get enterprise features like versioning and authentication.But this ease of use must be paid by something and here goes a list ofdisadvantages:

• It can be very hard to securely associate publisher with hispublic key when certification authorities are not involved. Publisher must shiphis public key by himself and he must ensure that public key is not tampered.Without certification authorities it's impossible to do it securely when ourproducts are distributed over insecure channels and there are no other ways toverify the publisher's public key.
• There is no way how to revoke public key when the private key hasbeen compromised. As this is easily done in case of certificates (just publishrevoked certificates on CRL, Certificate Revocation List) in case of SNs, revocation is a nightmare. Just imagine that you as a junior security engineer haslost USB key with your private key used to sign your assemblies. Then you'llhave to call and email your clients with newly signed assemblies, give themyour new public key and setup all environments again). There is no automaticway like CRL, everything must be done "by hand".

Authenticode can be considered as more powerful from an enterpriseand architectural perspective. So why not use Authenticode instead of SNs?Here are the reasons:

• SNs don't require any third party (such as Verisign) to create signatures and manage public keys. Any developer can easily create and manage his keys (see chapter "Generate key pair with sn.exe tool" in my free book ".NET in Samples") without payment to any third party.
• SNs can avoid network connections and PKI involvement so applications can run and be verified even when network connections are not available.
• Authenticode certificates are not a part of assembly names and that is why they can't separate publisher's namespaces like SNs do. Do you remember the statement from ECMA in the beginning? That SNs should "deterministically identify" modules and this is the most important reason. So not a security enabler but unique identification is the primary reason for SNs! And Authenticode is not designed for this purpose!

Conclusion

I hope this helps you understand the strong name technology inthe .NET Framework, and helped you see that it is very powerful, but with definedlimits. It is a technology that should be used appropriately.

With SNs we can uniquely identify an assembly and runside-by-side our assemblies. Security scenarios are not recommended to be usedwithStrong Names (even when it's supported by .NET Framework), just in caseyou are advanced in security and working with certificates and key management.There are many design patterns on how to useStrong Names and all this depends onapplication architecture, client requirements and infrastructure settings(Active Directory, PKI etc.).

There could be much more written about it (like usage of SNsin large companies, problems with key distribution, etc.), but this was notintended for this article, it was just a reaction to some misinterpretation ofthis technology and the article is intended to put it right.