blocks|key|3258760|text|我见过使用挑战/响应系统解锁程序集的公司(最著名的是飞马成像公司)编写的DLL。DLL的购买者被提供与购买者的名字绑定的“许可证代码”，然后DLL的消费者使用它来解锁DLL的特征的特定子集。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3258761|因此，当应用程序第一次使用程序集时，将在程序集中调用Unlock()方法。用户名和解锁码被传入，并通过一种验证身份的算法运行，大概使用某种类型的公钥加密算法。|offset|length|style|CODE|3258762|在解锁代码中编码了一些位，用于指定功能；然后，这些位在程序集中设置一些功能标志。所有调用函数都必须检查这些标志，以确定是否启用了适当的功能。Unlock()方法只调用一次，并且适用于加载的程序集的生存期。|3258763|当然，由于您必须在程序集中提供“私钥”，此过程不是防黑客攻击的(什么是？)，但它是合理安全的，并将使诚实的人保持诚实。|3258764|entityMap^0|0|Q|8|0|1Y|8|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@$D|P|E|Q|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@$D|S|E|T|F|G]]|9|@]|A|$]]|$1|J|3|K|5|6|7|U|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|M|$]]

I have seen DLL's written by companies (most notably Pegasus Imaging) that use a challenge/response system to unlock the assembly. The purchaser of the DLL is provided with a "License Code," tied to the name of the purchaser, which the consumer of the DLL then uses to unlock a specific subset of the DLL's features.

So when the assembly is used the first time by the application, the <code>Unlock()</code> method is called in the assembly. The user name and unlock code are passed in and run through an algorithm that verifies identity, presumably using a Public Key Encryption algorithm of some sort. 

There are some bits encoded in the unlock code that specify features; these bits then set some feature flags in the assembly. All calling functions must check these flags to determine if the appropriate feature is enabled. The <code>Unlock()</code> method is called only once, and is good for the lifetime of the loaded assembly.

Of course, since you have to provide the "private key" in the assembly, this procedure is not hack-proof (what is?), but it is reasonably secure, and will keep the honest people honest.

blocks|key|3044909|text|我认为如果你不能控制代码运行的执行环境，就没有办法做到这一点。在用户计算机上以完全信任运行的代码将能够绕过您添加的任何限制。例如，完全信任代码可以使用反射API调用私有或内部方法，因此即使使用InternalsVisibleToAttribute也无法工作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3044910|如果您控制执行环境，则可以创建一个AppDomain，其中您的代码是完全受信任的，而第三方代码是部分受信任的，除非您将AllowPartiallyTrustedCallersAttribute+(APTCA)放在程序集上，否则无法调用您的代码。可以使用SecurityCritical和SecuritySafeCritical属性限制可以在APTCA程序集中调用的方法。|offset|length|3044911|How+to:+Run+Partially+Trusted+Code+in+a+Sandbox|3044912|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/system.security.allowpartiallytrustedcallersattribute.aspx|1|http://msdn.microsoft.com/en-us/library/system.security.securitycriticalattribute.aspx|2|http://msdn.microsoft.com/en-us/library/system.security.securitysafecriticalattribute.aspx|3|http://msdn.microsoft.com/en-us/library/bb763046.aspx^0|0|1N|11|0|3I|G|1|3Z|K|2|0|0|1B|3|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@$D|X|E|Y|1|Z]|$D|10|E|11|1|12]|$D|13|E|14|1|15]]|A|$]]|$1|F|3|G|5|6|7|16|8|@]|9|@$D|17|E|18|1|19]]|A|$]]|$1|H|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]|P|$5|K|L|M|A|$N|Q]]|R|$5|K|L|M|A|$N|S]]|T|$5|K|L|M|A|$N|U]]]]

I don't think there's a way to do this if you don't control the execution environment under which the code is run. Code running with full trust on a user's machine would be able to get around any restrictions you added. For example, full trust code could invoke private or internal methods with the reflection APIs, so even using the InternalsVisibleToAttribute wouldn't work.

If you control the execution environment, you can create an AppDomain where your code is fully trusted, and third party code is partially trusted and can't call your code unless you put an <a href="http://msdn.microsoft.com/en-us/library/system.security.allowpartiallytrustedcallersattribute.aspx" rel="nofollow noreferrer">AllowPartiallyTrustedCallersAttribute</a> (APTCA) on the assembly. You can restrict which methods can be called in an APTCA assembly with the <a href="http://msdn.microsoft.com/en-us/library/system.security.securitycriticalattribute.aspx" rel="nofollow noreferrer">SecurityCritical</a> and <a href="http://msdn.microsoft.com/en-us/library/system.security.securitysafecriticalattribute.aspx" rel="nofollow noreferrer">SecuritySafeCritical</a> attributes.

<a href="http://msdn.microsoft.com/en-us/library/bb763046.aspx" rel="nofollow noreferrer">How to: Run Partially Trusted Code in a Sandbox</a>

blocks|key|311070|text|首先，正如您所认识到的，仅使用InternalsVisibleTo是不够的-您还需要对每个程序集进行签名和强命名，以确保不会有人只是伪造名称。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|311071|既然这样已经不成问题了，那么您就必须自己开发一个挑战-响应实现--除非您愿意使用显式描述为您不想使用的InternalsVisibleTo方法，否则您不能这样做。|311072|在C-R模型中，您需要在每次方法调用时传递某种令牌(或者可能只是为了实例化一个对象)。令牌将是一个只有你的代码才能创建实例的类-我会让它成为你想要使用的程序集的内部类，并让它可以通过InternalsVisibleTo访问-这样只需要管理一个类：|311073|//+SharedAssembly.dll
//+marks+ConsumingAssembly.dll+as+having+access+to+internals...

internal+sealed+class+AccessToken+{+}

public+class+SecuredClass
{
+++public+static+bool+WorkMethod(+AccessToken+token,+string+otherParameter+)
+++{
+++++++if(+token+==+null+)
+++++++++++throw+new+ArgumentException();+//+you+may+want+a+custom+exception.

+++++++//+do+your+business+logic...
+++++++return+true;++++++++
+++}
}



//+ConsumingAssembly.dll++(has+access+via+InternalsVisibleTo)

public+class+MainClass
{
++public+static+void+Main()
++{
++++++var+token+=+new+AccessToken();+//+can+create+this+because+of+IVT+access
++++++SecuredClass.WorkMethod(+token,+""+);++//+tada...
++}
}|code-block|syntax|javascript|311074|您可能希望将AccessToken类放在服务提供者和使用者都知道的第三个程序集中，这样您就不必经常为不同程序集的访问令牌类维护不同的组。|311075|为每种方法构建一个C-R机制既繁琐又乏味。它也不是100%25万无一失的--有足够的时间和耐心的人可能会找到一个方法来绕过它。|311076|最好的选择(在您的情况下可能是可能的，也可能是不可能的)是将您的私有代码保存在您自己的服务器上，并只将其公开为not服务(或类似的东西)。这使您可以主动管理IP的可访问性，并允许您以集中式(而不是分布式)方式更新谁有权访问。已经存在使用证书、消息签名和加密来限制对web服务的访问的技术。这将是控制IP访问的最可靠(也是最可靠的)方法。|311077|entityMap^0|F|I|0|1F|I|0|2J|I|0|0|6|B|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@$9|X|A|Y|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Z|8|@$9|10|A|11|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|12|8|@$9|13|A|14|B|C]]|D|@]|E|$]]|$1|J|3|K|5|L|7|15|8|@]|D|@]|E|$M|N]]|$1|O|3|P|5|6|7|16|8|@$9|17|A|18|B|C]]|D|@]|E|$]]|$1|Q|3|R|5|6|7|19|8|@]|D|@]|E|$]]|$1|S|3|T|5|6|7|1A|8|@]|D|@]|E|$]]|$1|U|3|-4|5|6|7|1B|8|@]|D|@]|E|$]]]|V|$]]

First of all, as you realize, it's not enough to use <code>InternalsVisibleTo</code> - you would also need to sign and strongly-name each assembly to ensure someone can't just spoof the name.

Now that that's out of the way, you would have to develop a challenge-response implementation on your own - this isn't something you can do unless you're willing to use the <code>InternalsVisibleTo</code> approach that you explicitly describe you don't want to use.

In a C-R model, you would need to pass some kind of token with every method call (or perhaps just to instantiate an object). The token would be a class that only your code can create an instance of - I would make this an internal class of the assembly you want to consume and make it accessible with <code>InternalsVisibleTo</code> - this way only a single class needs to be managed:

<pre><code>// SharedAssembly.dll
// marks ConsumingAssembly.dll as having access to internals...

internal sealed class AccessToken { }

public class SecuredClass
{
 public static bool WorkMethod( AccessToken token, string otherParameter )
 {
 if( token == null )
 throw new ArgumentException(); // you may want a custom exception.

 // do your business logic...
 return true; 
 }
}



// ConsumingAssembly.dll (has access via InternalsVisibleTo)

public class MainClass
{
 public static void Main()
 {
 var token = new AccessToken(); // can create this because of IVT access
 SecuredClass.WorkMethod( token, "" ); // tada...
 }
}
</code></pre>

You may want to put the <code>AccessToken</code> class in a third assembly that both the service provider and consumer know about so that you don't have to constantly maintain a different group for access token classes for different assemblies.

Building a C-R mechanism for every method is cumbersome and tedious. It also isn't 100% foolproof - someone with enough time and patience could probably find a way around it.

The best option (which may or may not be possible in your case) would be to keep your private code on your own servers and only expose it as a webservice (or something similar). This allows you to actively manage accessiblity to your IP and allows you to update who has access in a centralized (rather than distributed) manner. Technologies already exist to restrict access to web services using certificates, message-signature, and encryption. This would be the most reliable (and proven) way to control access to you IP.

blocks|key|305944|text|如果您希望将调用者限制为只使用由特定证书签名的authenticode签名的代码，您仍然可以使用CAS+(只是不使用StrongNameIdentityPermission)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|305945|就像使用任何PublisherIdentityPermission权限一样使用CAS。或者，如果您想以声明方式完成此操作，则可以使用use+an+attribute。|offset|length|305946|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/system.security.permissions.publisheridentitypermission.aspx|1|http://msdn.microsoft.com/en-us/library/system.security.permissions.publisheridentitypermissionattribute.aspx^0|0|6|R|0|1U|G|1|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@$D|R|E|S|1|T]|$D|U|E|V|1|W]]|A|$]]|$1|F|3|-4|5|6|7|X|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]|N|$5|I|J|K|A|$L|O]]]]

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 <a href="http://msdn.microsoft.com/en-us/library/system.security.permissions.publisheridentitypermission.aspx" rel="noreferrer">PublisherIdentityPermission</a> just like you would have used any CAS permissions. Or if you want to do it declaratively, <a href="http://msdn.microsoft.com/en-us/library/system.security.permissions.publisheridentitypermissionattribute.aspx" rel="noreferrer">use an attribute</a>.

blocks|key|3258861|text|我觉得这太大惊小怪了！如果你真的想要安全性，把你的代码放在服务器后面，并使用客户端-服务器架构。或web服务。或者介于两者之间的东西，比如WCF或remoting。然后使用身份验证对客户端进行身份验证。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3258862|见鬼，你可以让所有的东西都是私有的，公开一个公共API，并在本地根调用。|3258863|在纯桌面环境中保护来自未经授权调用者的dll只会使问题变得更加复杂和难以处理。更不用说它的内部看起来会很丑陋。|3258864|我看到了一些惯例的出现。这可能对你有用。但它并不能为您提供所需的“完全安全性”。如果你有一个应该对客户隐藏的程序集，不要把它放在GAC中。使用名称空间，后缀类似于"INTERNAL“。|3258865|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

I think it's too much fuss for nothing! If you really want security, put your code behind a server and use a client-server architecture. Or web services. Or something in between like WCF, or remoting. Then use authentication to authenticate a client.

Heck you can make everything private, expose a public API and root the calls locally.

Securing a dll from unauthorized callers in a desktop only environment only makes matters more complicated and harder to work with. Not to mention that it would look pretty ugly on the inside.

I see some conventions emerging. And that may work for you. But it doesn't give you the "total security" you require. If you have an assembly that is supposed to be hidden from customers, don't put it in the GAC. Use namespaces postfixed with something like "INTERNAL".

blocks|key|311102|text|显然，您必须对来自被调用方法的每个调用执行检查-任何试图强制实施限制的外部系统都可以使用反射轻松绕过。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|311103|在该方法中，您可以使用|311104|new+StackTrace().GetFrame(1).GetMethod().Module.Assembly|code-block|syntax|javascript|311105|来获取调用程序集。现在您可以使用|311106|callingAssembly.GetName().GetPublicKey()|311107|获取调用程序集的公钥，并将其与被调用程序集的公钥进行比较。如果它们匹配-假设您的所有程序集都使用相同的密钥对签名-调用者将被接受为合法调用者。|311108|但有一个漏洞-第三方程序集可以使用您的公司公钥延迟签名，并排除在数字签名验证之外。因此，加载器将使用强名称和您公司的公钥加载第三方程序集，即使它尚未签名。要关闭此循环漏洞，您必须检查签名。没有托管API，您必须P/Invoke|311109|Boolean+StrongNameSignatureVerificationEx(
+++String+wszFilePath,
+++Boolean+fForceVerification,
+++ref+Boolean++pfWasVerified)|311110|将fForceVerification设置为true，并检查结果是否为true。|offset|length|style|CODE|311111|总而言之，这可能是每个调用相当多的开销。可能的诱惑是缓存结果，但假设调用者具有反射权限，操作这样的缓存可能并不是很难。另一方面，你永远不会有100%25的把握。控制系统的人可以自由地(几乎)做他想做的任何事情--附加调试器、修改内存内容、操纵库或整个运行时。最后，您还必须有效地保护您的程序集不被反编译和修改。|311112|entityMap^0|0|0|0|0|0|0|0|0|1|I|M|4|Z|4|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|13|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|14|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|15|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|16|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|17|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|18|8|@]|9|@]|A|$]]|$1|Q|3|R|5|F|7|19|8|@]|9|@]|A|$G|H]]|$1|S|3|T|5|6|7|1A|8|@$U|1B|V|1C|W|X]|$U|1D|V|1E|W|X]|$U|1F|V|1G|W|X]]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1H|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1I|8|@]|9|@]|A|$]]]|11|$]]

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

<pre><code>new StackTrace().GetFrame(1).GetMethod().Module.Assembly
</code></pre>

to get the calling assembly. Now you can use

<pre><code>callingAssembly.GetName().GetPublicKey()
</code></pre>

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

<pre><code>Boolean StrongNameSignatureVerificationEx(
 String wszFilePath,
 Boolean fForceVerification,
 ref Boolean pfWasVerified)
</code></pre>

with <code>fForceVerification</code> set to <code>true</code> and check if the result is <code>true</code>.

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.

Is there any way to secure your assembly down to the class/property &amp; 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

Secure C# Assemblies from unauthorized Callers

有没有办法保护您的程序集到类/属性&类/方法级别，以防止未经我们公司签名的其他程序集使用/调用它们？我想在没有任何强命名要求的情况下这样做(比如使用StrongNameIdentityPermission)，并坚持程序集的签名方式。我真的不想求助于使用InternalsVisibleTo属性，因为这在不断变化的软件生态...

问保护来自未经授权调用者的C#程序集
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问保护来自未经授权调用者的C#程序集EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问保护来自未经授权调用者的C#程序集
EN