Any value to signing assemblies if not using the GAC?

[Tom Dacon]

If you're not putting assemblies in the GAC, but are referencing shared code
with copylocal=true into the projects that use them, is there any value to
signing the assemblies?

In the environment I've just begun to work in, there are customer-facing web
sites, internally-accessed maintenance and admin web sites, middle-tier
business logic assemblies, services, and Windows Forms apps that run on the
middle-tier. The policy is to sign the assemblies, but never to place them
in the GAC, even on the production servers.

My question: is there any actual value to signing the assemblies at all?
Presumably there's some assurance at runtime that the assemblies haven't
been compromised, but I'm having a hard time constructing a scenario in
which it pays off.

Any thoughts? Links? Best practices?

Tom Dacon
Dacon Software Consulting

 

[Steven Cheng[MSFT]]

Hi Tom,

Thanks for your posting. As for the question on strong-named assembly you
mentioned, here are some of my understanding:

The dotnet assembly's Full name consists of 4 parts:
assembly file name, culture, publickeytoken ,version such as :

com.microsoft.crypto, Culture=en, PublicKeyToken=a5d015c7d5a0b012,
Version=1.0.0.0

And the publickeytoken is null until we strong-named it (sign with a
keypair). Then, anyother application or assembly reference it will contains
the key token info in the metadata manifest. You can use the ILDasm tool to
view assembly's metadata manifest . This can guarantee that we didn't load
a incorrect assembly.
Here is some msdn reference on this:

#Side-by-Side Execution Overview
http://msdn.microsoft.com/library/en-us/cpguide/html/cpconside-by-sideexecut
ionoverview.asp?frame=true

#Simplifying Deployment and Solving DLL Hell with the .NET Framework
http://msdn.microsoft.com/library/en-us/dndotnet/html/dplywithnet.asp?frame=
true

BTW, the GAC mainly provide a global store where we can manage our
strong-named assemblies centrally, and convenient to update.

Hope helps. Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Richard Blewett [DevelopMentor]]

Version numbers are ignored without strong names so if you want to take advantage of version aware loading then that is an issue.

You can't use codebase hint based deployment without a strong name

You can't use the StrongNameIdentityPermission attribute to control who can call your code

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

nntp://news.microsoft.com/microsoft.public.dotnet.framework/<[email protected]>

If you're not putting assemblies in the GAC, but are referencing shared code
with copylocal=true into the projects that use them, is there any value to
signing the assemblies?

In the environment I've just begun to work in, there are customer-facing web
sites, internally-accessed maintenance and admin web sites, middle-tier
business logic assemblies, services, and Windows Forms apps that run on the
middle-tier. The policy is to sign the assemblies, but never to place them
in the GAC, even on the production servers.

My question: is there any actual value to signing the assemblies at all?
Presumably there's some assurance at runtime that the assemblies haven't
been compromised, but I'm having a hard time constructing a scenario in
which it pays off.

Any thoughts? Links? Best practices?

Tom Dacon
Dacon Software Consulting



---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.809 / Virus Database: 551 - Release Date: 09/12/2004



[microsoft.public.dotnet.framework]

 

[Nick Malik]

If you have zero-touch deployment, then it is imperative that you sign your
assemblies. Even if you don't use zero-touch, but you do download your
windows app to the client, you need to do this.

Security scenario:
Your server has a copy of your client windows app and associated assemblies.
Your users download the client from the server on install.
Hacker cracks your server system and downloads your client and assemblies.
He modifies the code in an assembly to include a trojan and re-uploads the
modified assembly.

All new users of your app will download the client and the trojan-infected
assembly. Locally running DLLs run in the security space of the user, who
is often an administrator on their own machine.

Also, if your client checks the server for the updated dll and downloads it,
then all of your users will be infected, not just the current ones.

Signed code avoids this because the signature is an encrypted version of a
hash that is made of the assembly. Signed assemblies are checked, when they
are loaded, to make sure that the hash still matches. If someone had played
with it, the hash wouldn't match and the assembly wouldn't load.

This also allows you to insure that malware cannot call your application use
some of the features of .NET.

Therefore, to provide the foundation for security, your organization is
right to dictate, across the board, that all assemblies should be signed.

--- Nick

 

[Guest]

Nick,
I've read some articles that indicated that protecting against the
"Trojan Horse" attack is altogether foolproof. In your example, if the
hacker could get copies of the server assemblies, then couldn't he rebuild
them with a virus embedded and then sign them with his own key pair. At this
point, whatever was downloaded by subsequent clients would successfully pass
the verification step.

This protection seems to work fine if the attacker only compromises some
of the application assemblies, which is of course a valuable layer of
security in of itself.

Is there a verification step in this scenario that I am not aware of? I
am relatively new to .NET and am trying to verify my own understanding of
these details.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/strongNames.asp

 

[Guest]

I have a question concerning this topic however that you didn't explicitly
address and was wondering if you have any suggestions or input.
Currently, I am developing our build process for an ASP.NET application.
This application will consist of about 8 assemblies in total. Even though
these assemblies will be deployed in a private application directory, we are
would like to apply strong names to them. As I understand things, this
might help
defend against "Trojan Horse" style attacks where someone gets a copy of one
of
your assemblies and replaces it in your application base directory.
(although I think
that if they get them all, you are officially hose, but that is another
subject)

Anyway, if possible, we would like to avoid the need to rebuild any given
Assembly if code changes have not occurred. However, a problem I see with
this approach has to do with the fact that Strong Names are partly comprised
of the version number itself. This can easily be seen in the assembly
manifest using the ILDASM.exe to look at referenced strongly named assemblies.

For example, lets say I build Assembly A & B and they are both strongly
named. If A references B then an extern reference will be placed in the
Assembly A's manifest (during compilation) pointing to Assembly B via its
strong name.

So, if I change something internal to Assembly B, but not A, this appears
to require a rebuild of both since Assembly A's manifest would need to be
updated
to use the new strong name for Assembly B, even though Assembly A did not
change.
(This assumes you follow the good practice of updating your Assembly
versions when
changes are made.)

Am I missing something here, or is this simply the way things must work
when using .NET strong named assemblies. Thanks for any input you can
provide.