2
votes

Are there any security concerns with using the InternalsVisibleTo attribute with strong-named assemblies? I understand that the assembly receiving information this way must have the private key to decrypt the messages, and that within the InternalsVisibleTo attribute you specify the public key in clear text. Would it be possible for someone to alter the assembly dll and public key in the InternalsVisibleTo attribute to share internal functions to assemblies that weren't originally intended to be shared to?

1
What "messages" are you talking about? Bear in mind that if someone can modify an assembly, they can run the whole thing in full trust mode anyway, at which point they can do whatever they like anyway...Jon Skeet
"decrypt the messages"? What messages? This has nothing to do with messaging...Marc Gravell
Public keys are designed to be publicly visible, hence the name.Paul Ruane

1 Answers

4
votes

It has nothing to do with encryption. And a strong name for an InternalsVisibleTo assembly is a hard requirement. All that it proves is that whomever created the assembly had access to the same secret as you did. The private key. With a very strong guarantee that whomever modifies the assembly or tries to create one that impersonates the assembly cannot provide the same proof. They can't get it signed the same way without having access to that private key.

This is sufficient to guarantee trust. Provided you guard the private key.