Secure C# Assemblies from unauthorized Callers

Question

Is there any way to secure your assembly down to the class/property & class/method level to prevent the using/calling of them from another assembly that isn't signed by our company?

I would like to do this without any requirements on strong naming (like using StrongNameIdentityPermission) and stick with how an assembly is signed. I really do not want to resort to using the InternalsVisibleTo attribute as that is not maintainable in a ever changing software ecosystem.

For example:

Scenario One

Foo.dll is signed by my company and Bar.dll is not signed at all.

Foo has Class A Bar has Class B

Class A has public method GetSomething() Class B tries to call Foo.A.GetSomething() and is rejected

Rejected can be an exception or being ignored in someway

Scenario Two

Foo.dll is signed by my company and Moo.dll is also signed by my company.

Foo has Class A Moo has Class C

Class A has public method GetSomething() Class C tries to call Foo.A.GetSomething() and is not rejected

Answer 1

If you are wanting to limit the callers to only code that has been authenticode signed by a specific certificate, you can still use CAS (just not StrongNameIdentityPermission).

Use PublisherIdentityPermission just like you would have used any CAS permissions. Or if you want to do it declaratively, use an attribute.

Answer 2

Obviously you have to perform a check on every call from within the called method - any external system trying to enforce the restrictions is easily bypassed using reflection.

From within the method you can use

new StackTrace().GetFrame(1).GetMethod().Module.Assembly

to get the calling assembly. Now you can use

callingAssembly.GetName().GetPublicKey()

to obtain the public key of the calling assembly and compare it with the public key of the called assembly. If they match - assuming all your assemblies are signed with the same key pair - the caller is accepted as a legitimated caller.

But there is one loop hole - a 3rd party assembly can be delay signed with your companies public key and excluded from the digital signature verification. In consequence the loader will load the 3rd party assembly with a strong name and your companies public key even if it is not yet signed. To close this loop hole you have to check the signature. There is no managed API and you have to P/Invoke

Boolean StrongNameSignatureVerificationEx(
   String wszFilePath,
   Boolean fForceVerification,
   ref Boolean  pfWasVerified)

with fForceVerification set to true and check if the result is true.

All together this may be quite a lot overhead per call. The temptation is probably to cache the result but assuming a caller with reflection permission it is probably not very hard to manipulate such a cache. On the other hand you will never be 100% sure. Who ever controls the system is free to do (almost) everything he wants - attach an debugger, modify memory content, manipulate libraries or the whole runtime. Finally you have to efficiently protect your assembly from decompilation and modification, too.