如果有人在程序外部修改此文件,程序应该无法再次加载它。
编辑:该程序处理信用卡信息,因此任何方式更改配置都可能存在潜在的安全风险。此软件将分发给大量客户。理想情况下,客户应该拥有直接绑定到可执行文件的配置。这将有望防止黑客能够放置虚假配置。
但是,配置仍然需要可编辑性,因此为每个客户编译单独的副本不是一个选项。
重要的是,这必须是动态的。因此,随着配置的更改,我可以将哈希与配置文件绑定。
write(MD5(SecretKey + ConfigFileText));
然后你只需删除该MD5并重新哈希文件(包括您的秘密密钥)。如果MD5相同,则没有人修改它。这可以防止某人修改它并重新应用MD5,因为他们不知道您的秘密密钥。
请记住,这是一个相当弱的解决方案(就像您建议的那样),因为他们可以轻松跟踪到您的程序以查找密钥或存储MD5的位置。
更好的解决方案是使用公钥系统并签署配置文件。同样,这也很脆弱,因为需要将私钥存储在他们的本地计算机上。几乎任何存在于他们本地PC上的东西都可以通过足够的努力绕过。
如果您真的想将信息存储在可执行文件中(我会不建议这样做),那么您可以尝试将其附加在EXE的末尾。通常情况下是安全的。修改可执行程序是类似病毒的行为,大多数操作系统安全性也会试图阻止您。如果您的程序位于Program Files目录中,而您的配置文件位于Application Data目录中,并且用户以非管理员身份登录(在XP或Vista中),则无法更新EXE。
更新:无论您使用非对称加密、RSA或量子密码,如果您将密钥存储在用户的计算机上(除非您将其全部通过Web服务路由),否则用户可以找到您的密钥,即使这意味着运行时检查CPU上的寄存器! 您只能为自己购买适度的安全级别,因此请坚持使用简单的方法。要防止修改,建议使用我提出的解决方案。要防止阅读,请加密它,如果您正在本地存储密钥,请使用AES Rijndael。
更新: FixedGUID / SecretKey 可以在安装时生成并存储在“秘密”注册表中。或者,您可以每次从硬件配置中使用它时生成它。然后,您会变得更加复杂。为了允许适度的硬件更改,您需要获取 6 个不同的签名,并将您的配置文件哈希 6 次 - 每次都是一次。将每个哈希值与第二个秘密值(如上述 GUID,全局或在安装时生成)结合起来。然后,在检查时,您单独验证每个哈希值。只要它们有 3 个以上的 6 个(或您的容差是什么),那么您就接受它。下次写入时,您将其与新的硬件配置进行哈希处理。这使他们可以随着时间的推移逐步更换硬件并获得全新的系统。也许这是一个弱点。这一切都取决于您的容忍度。基于更严格的容差有所变化。
更新: 对于信用卡系统,您可能需要考虑一些真正的安全性。您应该聘请一位安全和密码顾问。需要交换更多信息。他们需要分析您的具体需求和风险。
此外,如果您想要使用 .NET 进行安全编程,您需要首先使用一个非常好的 .NET 混淆器(搜索一下)。.NET 程序集太容易被反编译,以获取源代码和读取所有机密信息。不要听起来像破碎的唱片,但任何依赖于用户系统安全性的东西从一开始就 fundamentally flawed.出于纯好奇,您不希望在文件被更改时加载它的原因是什么?
为什么不将所有配置信息编译到可执行文件中?根本就不需要外部文件吗?
编辑
我刚刚读到您对此程序是信用卡信息程序的编辑说明。这提出了一个非常有趣的挑战。
我认为,为了达到这种安全级别,某种相当大规模的加密是必要的,但我不知道如何处理这种情况,以使加密秘密不能从可执行文件中提取。
是否有可能对某种在线源进行身份验证?
我建议您使用非对称密钥加密来加密您的配置文件,无论它们是存储在可执行文件内部还是外部。
如果我没记错的话,RSA是其中一种变体。
有关详细解释,请参阅维基百科上的公钥密码。
将“读取”密钥存储在您的可执行文件中,并将“写入”密钥保留给自己。因此,除了您之外,没有人可以修改配置。
这样做的优点包括:
但请确保进行适当的实施并做出一些研究。
只需创建一个包含MD5哈希的常量字符串,并将其编译到您的应用程序中... 您的应用程序可以在验证配置文件时直接引用此常量字符串。