d7s*_*rai 4 security authentication dll components mef
我正在构建一个Windows(服务)应用程序,简而言之,它包含一个"引导程序"和一个"引擎"(由引导程序加载的对象,它将控制转移给它,然后执行应用程序的实际任务).引导程序是一个非常基本的启动例程,几乎没有可能更改的功能.但是安装后引擎本身可能会升级,我正在实现一种机制,以便它可以自行升级 - 通过联系"主服务器"并检查其版本号与"最新"版本.如果有更新版本的引擎可用,它会将其下载到指定的文件夹中并调用引导程序中的方法以"重新启动".
因此,每当引导程序启动时,它都会使用MEF"扫描"适当的目录以实现IEngine,比较它们的引导程序兼容性数字并选择最新的兼容引擎版本.然后它将控制转移到引擎(然后,然后执行更新检查等).如果没有合格的IEngine - 或者MEF在组合期间失败 - 它会回到IEngine的默认内置实现中.
此应用程序将在远程服务器(或多个)上运行,其背后的全部原理是将手动应用程序维护保持在最低限度(如不必卸载/下载新版本/重新安装等).
所以,问题是:由于引导程序有效地将程序执行转移到IEngine对象上的方法,因此以某种方式找到应用程序扫描文件夹的恶意IEngine实现(或模仿器)基本上会在服务器加载时造成严重破坏并被发现是最符合条件的引擎版本.
我正在寻找一种机制来验证IEngine实现是否"真实" - 正如由适当的权威机构发布的那样.我一直在玩一些家庭brewn"解决方案"(IEngine暴露了一个传递"挑战"的Validate函数,并且必须以各种方式返回正确的"响应" - 比如让引导程序产生随机字符串加密并传递给引擎候选者,后者必须解密并修改字符串,然后对其进行哈希处理,加密哈希并将其返回给引导程序,后者将对其随机字符串执行类似的字符串修改,然后对其进行哈希并比较哈希到候选等的解密响应(哈希),但我确定.Net中有功能来执行这种验证？我只看了强命名,
输入将不胜感激.
可以使用私钥对程序集进行数字签名.结果称为强名称程序集.
加载强命名程序集时,.NET会自动检查其签名是否与嵌入的公钥匹配.因此,当加载了一个强大的命名程序集时,您可以保证作者拥有与该公钥对应的私钥.
您可以通过调用Assembly .GetName().GetPublicKey()获取公钥,然后将其与预期的公钥(即您的公钥)进行比较.
您可以扫描插件程序集,AssemblyCatalog使用正确的公钥创建一个(拒绝其他公钥),最后将它们聚合为一个AggregateCatalog并CompositionContainer使用它构建一个.
这基本上是Glenn Block在这个帖子中解释的内容.(最好忽略Bnaya关联的博客文章,他的解释StrongNameIdentityPermission是不正确的.)
编辑回复评论墙:
为了获得该公钥,我使控制台应用程序将公钥字节数组输出到某处.我将字节数组嵌入到我的宿主应用程序中,然后使用它来与插件候选者的公钥进行比较.那会是这样做的吗？
是的,但有一种更简单的方法来提取公钥.看看sn.exe的-Tp选项.
这种机制是否会自动阻止恶意插件程序集公开正确但"伪造"的公钥？因为,有没有一些机制来取消任何已签名的程序集,但是它的公开公钥和它的内部私钥之间是否不匹配,从而完全加载/运行？
据我所知,支票会自动发生.如果签名错误,则无法加载(甚至动态)强名称程序集.否则强名就没用了.要对此进行测试,可以在十六进制编辑器中打开强名称程序集,更改某些内容(如程序集中const string嵌入的字符)并验证是否无法再加载程序集.
我想我所指的是类似于这里描述的黑客/破解的类型:http: //www.dotnetmonster.com/Uwe/Forum.aspx/dotnet-security/407/Signed-assemblies-easily-cracked and这里:http://blogs.msdn.com/b/shawnfa/archive/2008/05/14/strong-name-bypass.aspx
[...更多评论......]
然而,这显然可以通过简单的篡改来绕过(如第一个链接所示,>并在此处解释):grimes.demon.co.uk/workshops/fusionWSCrackOne.htm
您所指的"攻击"分为三类:
结论:强名称适合用于身份验证(至少从.NET 2.0开始)
| 归档时间： |
|
| 查看次数： |
1493 次 |
| 最近记录： |