.Net Dynamic Plugin Loading with Authority

Question

What recommendations can you give for a system which must do the following:

Load Plugins (and eventually execute them) but have 2 methods of loading these plugins:

• Load only authorized plugins (developed by the owner of the software)
• Load all plugins

And we need to be reasonably secure that the authorized plugins are the real deal (unmodified). However all plugins must be in seperate assemblies. I've been looking at using strong named assemblies for the plugins, with the public key stored in the loader application, but to me this seems too easy to modify the public key within the loader application (if the user was so inclined) regardless of any obfuscation of the loader application. Any more secure ideas?

Answer 1

Basically, if you're putting your code on someone else's machine, there's no absolute guarantee of security.

You can look at all kinds of security tricks, but in the end, the code is on their machine so it's out of your control.

How much do you stand to lose if the end user loads an unauthorised plugin?

Answer 2

How much do you stand to lose if the end user loads an unauthorised plugin?

Admittedly this won't happen often, but when/if it does happen we lose a lot and I although I understand we will produce nothing 100% secure, I want to make it enough of a hindrance to put people off doing it.

The annoying thing about going with a simple dynamic loading with full strong name, is that all it takes is a simple string literal change within the loader app to load any other assembly even though the plugins are signed.

Answer 3

you can broaden your question : "how can I protect my .net assemblies from reverse engineering ?"

the answer is - you can not. for those who havent seen it yet, just look up "reflector", and run it on some naive exe.

(by the way, this is always the answer for code that is out of your hands, as long as you do not have en/decryption hardware sent with it),

obfuscating tries to make the reverse engineering to be harder (cost more money) than development, and for some types of algorithems it succeeds.

Answer 4

Sign the assemblies.

Strong-name signing, or strong-naming, gives a software component a globally unique identity that cannot be spoofed by someone else. Strong names are used to guarantee that component dependencies and configuration statements map to exactly the right component and component version.

http://msdn.microsoft.com/en-us/library/h4fa028b(VS.80).aspx