security - MEF:组件认证

Question

我正在构建一个 Windows(服务)应用程序，简而言之，它由一个“ Bootstrap ”和一个“引擎”(由 Bootstrap 加载的一个对象，它将控制权转移给它，然后执行应用程序的实际任务)组成。 Bootstrap 是一个非常基本的启动例程，几乎没有可能更改的功能。但是引擎本身可能会在安装后进行升级，我正在实现一种机制，以便它可以自行升级 - 通过联系“主服务器”并根据“最新”版本检查其版本号。如果有更新版本的引擎可用，它会将其下载到指定的文件夹并调用 Bootstrap 中的方法来“重新启动”。

因此，每当 Bootstrap 启动时，它都会使用 MEF 来“扫描”适当的目录以查找 IEngine 的实现，比较它们的 Bootstrap 兼容性编号并选择最新的兼容引擎版本。然后它将控制权转移给引擎(然后依次执行更新检查等)。如果没有符合条件的 IEngine - 或 MEF 在合成过程中失败 - 它会使用默认的 IEngine 内置实现。

此应用程序将在远程服务器(或多个)上运行，其背后的全部理由是将手动应用程序维护降至最低(因为不必卸载/下载新版本/重新安装等)。

所以，问题是:由于 Bootstrap 有效地将程序执行转移到 IEngine 对象上的方法，以某种方式找到进入应用程序扫描文件夹的恶意 IEngine 实现(或模仿者)如果加载，基本上会对服务器造成严重破坏并被发现是最符合条件的引擎版本。

我正在寻找一种机制来验证 IEngine 实现是“真实的”——就像由适当的权威机构发布的那样。我一直在玩一些自制的“解决方案”(让 IEngine 公开一个 Validate 函数，该函数传递了一个“挑战”并且必须返回一个正确的“响应” - 以各种方式，比如让 Bootstrap 产生一个随机字符串被加密并传递给候选引擎，然后它必须解密和修改字符串，然后对其进行哈希处理，加密哈希并将其返回给 Bootstrap ， Bootstrap 将对其随机字符串执行类似的字符串修改，然后对其进行哈希处理并进行比较哈希到来自候选人等的解密响应(哈希)，但我确定.Net中有执行这种验证的功能？我只是看了Strong Naming，但它似乎不是动态加载但未想到的dll的系统的最佳方式..

输入将不胜感激。

Answer 1

可以使用私钥对程序集进行数字签名。结果称为 strong named assembly .
加载强命名程序集时，.NET 会自动检查其签名是否与嵌入的公钥匹配。因此，当加载了强命名程序集时，您可以保证作者拥有与该公钥对应的私钥。
您可以通过调用Assembly获取公钥.GetName() .GetPublicKey()然后将其与预期的进行比较，即您的。
您可以扫描插件程序集，创建 AssemblyCatalog对于每个拥有正确公钥的人(拒绝其他人)，最后将它们聚合成 AggregateCatalog并建立一个 CompositionContainer用它。
这基本上是 Glenn Block 在 this thread 中解释的内容。 . (最好忽略 Bnaya 链接的博客文章，他对 StrongNameIdentityPermission 的解释是不正确的。)
编辑 回复评论墙:

To get that public key, I make theconsole application output the publickey byte array to somewhere. I embedthe byte array in my host application,and subsequently use that to compareagainst the public keys of plugincandidates. Would that be the way todo it?

是的，但是有一种更简单的方法可以提取公钥。看 -Tp sn.exe 的选项.

Does this mechanism automatically prevent a malicous plugin assembly from exposing acorrect, but "faked" public key? As in, is there some mechanism to disqualify any assemblythat is signed, but has a mismatch between its exposed public key and it's internalprivate key, from being loaded/run at all?

据我所知，检查是自动进行的。如果签名错误，则无法加载(甚至动态地)强命名程序集。否则强名称将毫无用处。要对此进行测试，您可以在十六进制编辑器中打开强命名程序集，更改某些内容(如嵌入程序集中的 const string 中的字符)并验证无法再加载程序集。

I guess what I was referring to was something akin to the type of hack/crack described here:http://www.dotnetmonster.com/Uwe/Forum.aspx/dotnet-security/407/Signed-assemblies-easily-crackedand here: Link

[...snip more comments...]

However, this can - apparently - be bypassed by simple tampering (as shown in first link, > and explained more here): grimes.demon.co.uk/workshops/fusionWSCrackOne.htm

您所指的“攻击”分为三类:

完全删除强名称。这不会破坏身份验证，程序集将不再有公钥，因此您将拒绝它。

禁用强名称检查，这需要对机器的完全访问权限。如果这是由攻击者完成的，则意味着攻击者已经拥有您的机器。在这种情况下，任何安全机制都将毫无意义。我们实际上要防御的是机器和程序集源之间的攻击者。

.NET 1.1 中的一个错误使得真正的利用成为可能，该错误已被修复

结论:强名称适合用于身份验证(至少从 .NET 2.0 开始)