Hello,
I have the following situation:
Assembly A.dll have some routine inside that application B.exe uses. I waht
to prevent other people from loading A.dll and call the method with the
routine.

For that, I make A.dll and B.dll strong named, and the method
"String SensitiveRoutine()" have the StrongNameIdentityPermission attribute
with the pulic key of B.exe, I set the security action to Demand.

and I receive this secutiry error:
Request for the permission of type
System.Security.Permissions.StrongNameIdentityPermission, mscorlib,
Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 failed.

If I set the security action to LinkDemand I don't receive the error, but
other application C.exe with different public key can call the method! and I
don't want this.

If I put the attribute at assembly level
[assembly:StrongNameIdentityPermissionAttribute........] with RequestMinimum
as security action, it does't work.

what should I do to ensure that the code that call the sensitive routine is
one from the strong named assemblies that I signed before?

[quoted text, click to view]

This is to be expected in most cases since their is often some .NET
Framework code (which is not signed with your strong naming key) on the call
stack. Link demands are usually used for identity permission demands to
prevent exactly this issue.


[quoted text, click to view]

This is not expected behaviour under version 1.1 of the .NET Framework. Are
you calling SensitiveRoutine directly from C.exe, or is the call being made
by invoking a method in A.dll or B.dll that then invokes SensitiveRoutine?


[quoted text, click to view]

Assembly-level permission attributes affect only the assembly in which they
appear. They have no impact whatsoever on demands placed on callers from
other assemblies, so the behaviour you describe is to be expected.


[quoted text, click to view]

That depends by what you mean by "ensure". Highly privileged code can
bypass any identity permission even under v. 1.1. In v. 2.0, fully trusted
code will automatically pass all identity permission demands, so your SNIP
attribute will provide even less protection there. If you want to more
effectively screen callers, a licensing scheme may be more effective.
However, this wouldn't offer substantial protection against a determined and
highly privileged attacker, so it may or may not be worth the trouble of
implementing in your particular case.

[quoted text, click to view]

This is not expected behaviour under version 1.1 of the .NET Framework. Are
you calling SensitiveRoutine directly from C.exe, or is the call being made
by invoking a method in A.dll or B.dll that then invokes SensitiveRoutine?

[ED]
Yes, I called the sensitive routine directly from the .exe(s)


[quoted text, click to view]

Assembly-level permission attributes affect only the assembly in which they
appear. They have no impact whatsoever on demands placed on callers from
other assemblies, so the behaviour you describe is to be expected.

[ED]
Thanks for this comment!


[quoted text, click to view]

That depends by what you mean by "ensure". Highly privileged code can
bypass any identity permission even under v. 1.1. In v. 2.0, fully trusted
code will automatically pass all identity permission demands, so your SNIP
attribute will provide even less protection there. If you want to more
effectively screen callers, a licensing scheme may be more effective.
However, this wouldn't offer substantial protection against a determined and
highly privileged attacker, so it may or may not be worth the trouble of
implementing in your particular case.

[ED]
I need that my routine ONLY be called from a strong named assembly signed
with my key, no one other can do it.

[quoted text, click to view]

Are you absolutely certain that C.exe is signed with a different key? If
so, could you please post the exact code used for your SNIP attribute?


[quoted text, click to view]

It simply isn't possible to completely prevent calls into your method by
undesired callers. Highly privileged code run by a highly privileged
attacker will always be able to bypass whatever protection you add. Might
you be able to share a bit more detail about how your application is
deployed and who you are attempting to protect against?

[quoted text, click to view]

[ED]
Well, my application is a windows service acting as a server for many
clients, and I have other .exe for activate an aplication. This .exe will ask
the user for the serial and activation number, and the validation and
activation process will take place in a common assembly. When I said common I
mean that the activator, the service, and other applications I have will use
it. All those assemblies (the activator and the service) are signed with my
key. As you can see, if some one creates another app that uses my assembly,
can call the methods that activate the application, because they're public to
enable the .exe and the service to activate it and check the activation
respectively.

I thought will be possible to protect the calls to the activation methods