How would you stop a hacker from changing the call in the application itself from ScoreKeeper.GetHighScore() to return 9999999 ?
–
Ohad SchneiderNov 12 '12 at 15:23

@ohadsc - no security is perfect, but you can at least make it unappealing.
–
StingyJackNov 12 '12 at 15:42

@StingyJack I'm just saying that if the hacker has access to this DLL then he might have access to the application itself, in which case worrying about the DLL is misdirected
–
Ohad SchneiderNov 12 '12 at 15:57

1

Both are about preventing the user from substituting modified code (in one case without license check, in one case with a fake score computation -- these details are irrelevant to the security task).
–
Ben VoigtNov 12 '12 at 16:43

2 Answers
2

This DLL contains a class, say ScoreKeeper that implements a method called GetHighScore(). The application calls this periodically.

And then:

Is there a way to prevent the .NET application from using a "non-authorized" DLL here in place of the one I am supplying?

Assuming that you want to prevent someone from swapping out the assembly you have provided with an assembly of their own which has the same name and type (which is in the same namespace), you couldapply a strong name to the assembly that contains the ScoreKeeper class and have your consumers reference that.

However, we'll see that there are issues that make this not 100% reliable. Strong Names help you protect unaware users from replacement of your DLL with a malicious spoofed copy. But if the user is complicit in the spoofing (which would be the case if he is trying to cheat), then code signing will be no more than a speed bump and provides no real protection. Certainly, Strong Names don't provide protection comparable to e.g. PunkBuster.

Using a Strong Name to verify an assembly publisher's identity

When you add a strong name to an assembly, you are using a private key (part of an asymmetric public/private key pair, more on this later) to generate a cryptographic hash and the public key is included in the assembly name (along with the hash).

Using the public hash and the public key, the CLR is able to verify that the signature of the assembly did in fact come from the private key.

Of course, this means, you should protect the key (internally and externally); if someone else has your key, then they can effectively impersonate you and publish assemblies that people would trust to be from you.

Then, when you add a reference to your signed assembly, if someone tries to put a different assembly in with the same assembly name (not the fully qualified one, just the name without version, hash and public key) and same type name, the CLR fill fail when trying to load the type, indicating that it couldn't find it; the type is resolved using the fully-qualified assembly name, along with the namespace and type name.

Why Strong Names are not 100% secure (is anything?)

1) Hash Collisions

It is still a hash that is being verified. While the hash is quite large (160 bits for the default hash algorithm, SHA-1), any hash that has a finite number of values is subject to a collision. While extremely unlikely, it is possible (impossible vs. improbable). Furthermore, only the last 8 bytes is used by default. Combined with research indicating that SHA-1 is relatively weak, this is a good reason to use SHA-256 Enhanced Strong Naming as described in MSDN.

The computer administrator can simply bypass the strong name check, using sn -Vr. According to MSDN:

Registers assembly for verification skipping... A malicious assembly could use the fully specified assembly name (assembly name, version, culture, and public key token) of the assembly added to the skip verification list to fake its identity. This would allow the malicious assembly to also skip verification.

Starting with the .NET Framework version 3.5 Service Pack 1 (SP1), strong-name signatures are not validated when an assembly is loaded into a full-trust AppDomain object, such as the default AppDomain for the MyComputer zone.

In order to have .NET check the strong name of each assembly loaded into your application, you'll want to insert the following snippet (provided by MSDN) into your application configuration file:

Beware, however, that this only protected against removal of the strong name.

When you override the bypass feature, the strong name is validated only for correctness; it is not checked for a StrongNameIdentityPermission. If you want to confirm a specific strong name, you have to perform that check separately.

If in light of the concerns above, you'd still like to pursue Strong Naming your assembly, here's how.

Generating a Strong Name and signing your assembly

You have two options for which key to use when generating a strong name. In Visual Studio, go to the Signing tab on the project properties and click "Sign the assembly":

From there, you have two options to generate the public/private key, to have VS.NET generate the keys for you, or point to an existing one:

When selecting "New", Visual Studio will prompt you for the name of the file to generate, as well as whether or not you want to optionally use a password to access it:

At which point, the key will be added to your project:

Now, you can move this to a solution item (if you have multiple projects in your solution).

Visual Studio in this case is really just calling the Strong Name command line tool to generate a public and private key pair. If you'd rather do that yourself, you'd want to call sn.exe with the -k command line option to generate the key, like so:

sn -k keyPair.snk

And then add it via the "Browse" dialog above.

Note that when you do this, it will pull the key into your project. If you don't want to do this (as it copies the key into every project), then delete the key from the project and then add an existing file to the project, but link it. This will clear the "Choose a strong name key file" option, but if you drop it down, you'll see the full path to your linked key file.

Seems like the most straightforward answer would be to calculate a secure hash of the DLL you are loading, and then compare it against a golden value that you have precalculated. Of course,this will still be vulnerable to being broken by a sufficiently determined attacker, but it will significantly raise the bar for people who want to cheat.

I was thinking this as a hand-rolled solution so +1 for the idea anyway
–
jglouieNov 12 '12 at 15:19

1

Why would you do it when strong named assemblies do it for you? It's reinventing the wheel, and chances are, less secure.
–
casperOne♦Nov 12 '12 at 15:31

@casperOne - no argument, and I realized this about 2 seconds after I posted the answer. See my first comment on this answer (at the time, yours wasn't posted). FYI, one of your upvotes is mine.
–
Drew ShaferNov 12 '12 at 15:56

2

@casperOne: Maybe because disabling a hand-coded hash check is more work than bypassing a strong name?
–
Ben VoigtNov 12 '12 at 16:17