保护部署在“敌对”环境中的系统环境
在我的公司，我们正在开发一个由多台服务器组成的大型系统。 该系统由大约 5 个逻辑组件组成。数据存储在 XML、MS SQL 和 SQLite 中。它是一个.Net系统（大部分），组件使用WCF和一些自定义UDP进行通信。 客户端主要通过自定义UDP或WEB(ASP.NET & Silverlight)访问系统。
保护通信很容易，只需一些 SSL 和 WCF 上的一些安全措施，我们就完成了。
我们面临的主要问题是系统需要部署在客户的站点上，而我们不一定信任该客户。我们需要保护服务器上的数据以及软件本身免受逆向工程的影响。两者对我们都至关重要。
我们还需要一个终止开关，我想要一些可以根据命令或者在一段时间内无法打电话回家时销毁数据和软件的东西。
我正在考虑的方向是使用 TPM 或类似的东西 - 某种硬件加密解决方案，与我们可以在内部保留的另一项服务相结合，以加密服务器上的所有软件和数据，以便密钥来自我们的服务器安全地存储在我们的站点中，并且可能会从 TPM 中屏蔽内存。
您建议如何解决这样的问题？
更新 04/02 我正在寻找实用的建议，或者对可以帮助我的产品提出建议，所以我正在开始赏金...
大家看，我们基本上将我们的机器放在客户的网站上（出于商业和实用原因），我们拥有客户可以在几小时内收到他支付的所有费用，并且可以对数据进行任何他想要的操作。但在那台机器上运行的算法以及存储在那里的一些数据是我们想要保护的商业秘密。 理想情况下，如果我不同意，我希望机器根本不工作，甚至不启动，并且如果没有我的同意，机器上的所有内容都保持加密状态。内存屏蔽看起来也是一种在执行时保护机器的好方法。
另外，理想情况下，我希望一旦有人用螺丝刀靠近所有机器上的硬盘和存储设备就会爆炸……:-)但我认为这太过分了……
更新< /strong> 10/02 好吧，在做了一些研究之后，我认为我们将尝试与 PS3 加密系统相同的方向，除了我们将引入用于解密软件和来自我们服务器的数据的密钥。这样我们就可以在我们的机器上决定是否信任请求密钥的服务器，我们只需重新安装机器即可获得终止开关。这可能是基于 TPM 或类似的东西，也许是英特尔的 TXT... 我也对内存屏蔽作为一项重要的安全功能非常感兴趣...
顺便说一句，我们无法通过将系统的有价值的部分移动到我们的站点来解决这个问题，这既是因为业务需求，也是因为它在技术上不可行 - 我们需要巨大的带宽....
At my company we are developing a large system, comprised of several servers.
The system is comprised from about 5 logical components. Data is stored in XMLs, MS SQL, and SQLite. It's a .Net system(mostly) ,the components communicate using WCF, and some custom UDP.
Clients access the system mostly through the custom UDP or WEB(ASP.NET & Silverlight).
Protecting the communication is easy, some SSL, and some security on the WCF and we're done.
The main problem we are facing is that the system needs to be deployed on a client's site, a client that we dont necessarily trust. We need to defend the data on the servers, and the software itself from reverse engineering. Both are crucially important to us.
Also we need a kill switch, i would like something that destroys the data and the software, upon command, or if unable to call home for a certain period of time.
The direction that i was thinking of is using TPM, or something alike - some hardware encryption solution, in combination with another service that we could keep internally to encrypt all the software and data on the servers, so that the key's will come from our server safely in our site, and maybe memory curtaining from the TPM.
How do you suggest solving such a problem?
UPDATE 04/02
I'm looking for practical suggestions, or advise on products that could help me, so I'm starting a bounty...
Look guys we're basically putting our machine in the client's site (for business and practicality reasons), we own that machine, and the client receives everything he's paying for within hours, and he can do with the data whatever he wants. But i the algorithms running on that machine, and some of the data stored there is our trade secrets, that we want to protect.
Ideally i would want the machine not to work at all not even boot if i dont say it's OK, and without my OK for everything on the machine to remain encrypted. Memory curtaining also looks like a nice way to protect the machine while executing.
Also ideally I would want the HD's and the storage on all the machines to explode as soon as someone gets near them with a screwdriver... :-) but i think that would be taking it too far ...
UPDATE 10/02
O.K. after doing some research, I think we are going to try something in the same direction as the PS3 encryption system, except we're going to bring in the keys for decrypting the software and the data from our servers. doing so we can decide on our machines whether we trust the server requesting the keys, we can get a kill switch just by reseating the machine. this is probably be based on TPM or something similar, maybe intel's TXT...
I'm also really interested in memory curtaining as an important security feature...
BTW, we cant solve this by moving the valuable parts of our system to our site, both because of business requirements and because its not technologically feasible - we would need a huge bandwidth....
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
实际上，你所要求的是圣杯。这大致相当于游戏机的做法，在游戏机中，您有一个在不受信任的环境中运行的受信任平台。
考虑一下您是否可以从第一天开始就将机器视为受到损害。如果您可以在这种假设下工作，那么事情对您来说就会变得容易得多，但这在这里听起来不太可行。
就实际保护而言，存在一些问题：
我知道这些都是相当模糊的，但这确实是过去几年游戏机保护的历史——如果您对如何解决这个问题感到好奇（和破碎）一遍又一遍，看看控制台制造商。
虽然这从未完全成功，但您可以显着提高进入门槛。
What you're asking for, in effect, is the holy grail. This is roughly equivalent to what's done for game consoles, where you have a trusted platform running in an untrusted environment.
Consider whether or not you can treat the machine as compromised from day 1. If you can work under that assumption, then things become considerably easier for you, but that doesn't sound terribly viable here.
In terms of actually securing it, there are a few concerns:
I know these are fairly vague, but this is really the history of game console protections over the last couple of years -- if you're curious as to how this has been solved (and broken) over and over, look to the console manufacturers.
It's never been done completely successfully, but you can raise the barrier to entry significantly.
...说实话，这听起来像是您在问如何将病毒写入您的应用程序，这让我认为您的客户可能有更多的理由不信任您，而不是相反。
话虽这么说，由于多种原因，这是一个糟糕的主意：
连接中断或他们搬迁办公室
并断开机器的连接
少量？
失火？即使删除数据
客户使用是否正确？
意味着您的应用程序提供
没有备份功能。我是吗
正确的？听起来完全像
我不会购买的产品。
应用程序管理？如果是的话
删除了什么样的财务
这会给客户带来损失吗？有
您的法律部门签字同意
已确认您无法被扣押
容易？
... To be honest it sounds like you're asking how to write a virus into your application which makes me think your client probably has more reason to not trust you than the other way around.
That being said this is a terrible idea for a number of reasons:
connection dies or they move offices
and disconnect the machine for a
bit?
misfires? Deleting data even if the
customer is using it correctly?
implies that your application offers
no backup capabilities. Am I
correct? Sounds exactly like a
product I wouldn't buy.
application manages? If it is
deleted what kind of financial
losses would this result in for the client? Has
your legal department signed off on
this and verified you can't be held
liable?
这个问题每周被问 2-3 次，答案总是一样的——你给用户的任何东西都不再是你的了。
你可以让用户更难获取数据，但你无法阻止他完全获取数据。你可以加密数据，你可以将解密密钥保存在 USB cryptotoken 上（这不会暴露密钥），但理论上如果代码可以调用 cryptotoken 并要求它解密数据块，那么黑客就可以复制您的代码（理论上）并使该代码调用 cryptotoken 来解密所有数据。
实际上，任务可能变得足够复杂，以至于无法获取数据。此时您应该检查解密的数据对于用户来说到底有多重要。
关于终止开关：这不起作用。绝不。如果需要，用户可以制作副本并从备份中恢复。他可以改变电脑时钟。他甚至可能减慢计算机的时钟（如果数据非常有价值，以至于投资定制仿真硬件是可行的）。
关于关键数据：有时事实证明，您的宝贵资产对其他人来说实际上没有什么价值[而您的解决方案的其他方面却是]。示例：我们提供驱动程序产品的源代码。它对我们来说是最有价值的资产，但用户不是为代码行付费，而是为支持、更新和其他好处付费。如果不投入相当于我们许可证成本的金额，用户将无法有效使用[被盗]源代码。
关于混淆：代码片段的虚拟化（例如VMProtect产品）似乎非常有效，但是，通过一定的努力也可以绕过它。
一般来说，我可以想到一些带有定制操作系统的定制硬件，像提款机一样密封（以便客户在不破坏密封的情况下无法进入），定期检查等。这可能有效。因此，这项任务不仅是技术性的，而且主要是组织性的 - 您需要安排定期检查机器等。
总结：如果数据那么有价值，请保留它您的服务器并仅提供互联网连接。否则只能将风险降到最低，而不能完全避免。
This question is asked on SO 2-3 times a week, and the answer is always the same - whatever you have given to the user is not yours anymore.
You can make it harder for the user to get to the data, but you can't prevent him from getting there completely. You can encrypt the data, you can keep the decryption key on USB cryptotoken (which doesn't expose the secret key), but in theory if the code can call cryptotoken and ask it to decrypt the chunk of data, then the hacker can duplicate your code (in theory) and make this code call cryptotoken to decrypt all data.
Practically the task can be made complicated enough to make it unfeasible to get the data. At this point you should check, how much important the decrypted data really is for the user.
About kill switch: this doesn't work. Never. The user can make a copy and restore it from backup if needed. HE can change computer clock. He can probably even slow down the clock of the computer (if the data is so valuable that investing into custom emulation hardware is feasible).
About critical data: sometimes it turns out that your valuable asset is really of little value to anybody else [and some other aspect of your solution is]. Example: we ship source code of our driver products. It's the most valuable asset for us, but the users pay not for lines of code, but for support, updates and other benefits. The user will not be able to effectively use the [stolen] source code without investing the sum, comparable to the cost of our license.
About obfuscation: virtualization of pieces of code (eg. VMProtect product) seems to be quite effective, however, it can also be bypassed with certain effort.
In general I can think of some custom hardware with custom-built operating system, sealed like a cash machine (so that the client can't get in without breaking the seal), with regular inspections etc. This might works. So the task is not just technical but mostly organizational - you will need to arrange regular inspections of the machine etc.
To summarize: if the data is that valuable, keep it on your servers and offer Internet connection only. Otherwise you can only minimize the risks, not avoid them completely.
正如其他人所说，没有灵丹妙药。用户可以关闭机器，将硬盘作为其他机器的从属设备，备份所有内容，对代码进行反向引擎，然后成功破解它。一旦用户对可执行文件进行物理访问，它就可能受到损害，并且在 100% 的情况下无法阻止它。
你能做的最好的事情就是让潜在破解者的工作变得非常困难，但无论你做什么，它都不是牢不可破的。
如果出现问题，使用自我毁灭可以通过备份所有内容的破解者来解决。
在 USB 驱动程序中使用密钥有助于让破解者变得更加困难，但最终可能会被有能力、坚定的破解者击败：解密内容的代码不能处于加密状态（包括获取密钥的部分），因此这是最大的弱点。破解这部分代码以将密钥保存在其他地方会导致密钥失效。
如果软件在远程服务器中进行身份验证，则可以通过攻击客户端并绕过身份验证来实现这一目的。如果它从服务器获取密钥，则可以使用嗅探网络来拦截包含密钥的服务器数据。如果服务器数据被加密，破解者可以通过分析解密它的软件并钓鱼未加密的数据来解密它。
特别是，如果破解者使用模拟器来运行能够保存内存快照（包括算法的未加密版本）的软件，那么一切都会变得容易得多。如果他可以在运行您的软件时直接操作和固定内存，那就更容易了。
如果你不期望你的不受信任的客户非常坚定，你可以让事情变得复杂，并希望他们永远不会获得足够的精力和技能来值得打破它。
在我看来，更好的解决方案是将所有软件放在您信任的服务器中，让他们的服务器只要求您的服务器完成这项工作，并将您的算法保留在您的服务器中。这比其他一切都更安全、更简单，因为它消除了根本问题：用户不再能够物理访问算法。您真的应该考虑一种方法来实现这一点，消除将代码保留在客户端的需要。然而，即使这也不是牢不可破的，黑客可以通过分析输入函数的输出来推断算法的作用。在大多数情况下（看起来这不是你的情况），算法并不是系统中最重要的，而是数据。
因此，如果您确实无法避免在不受信任的一方运行该算法，那么您不能做比您已经说过的更多的事情：加密所有内容（最好是在硬件中），验证和检查所有内容，在某人之前销毁重要数据如果您怀疑有问题，请考虑对其进行备份，并使其他人很难破解它。
但是，如果您真的想要一些想法，并且真的想要这样做，那么我们开始：
我可以建议您使您的程序变得突变。 IE：当您解密代码时，使用不同的密钥对其进行加密并丢弃旧密钥。从服务器获取一个新密钥，并断言该密钥本身的编码方式很难用提供受损新密钥的东西来模拟服务器。确保密钥是唯一的并且永远不会重复使用。再说一遍，这并不是牢不可破的（破解者要做的第一件事就是攻击这个功能）。
另一件事：放置大量不明显的红鲱鱼，这些东西会进行无意义的奇怪一致性检查，其中有很多算法的非功能性虚假版本，并添加了许多复杂的过度膨胀，实际上什么也不做并断言它运行正如真实代码所预期的那样。让真正的代码做一些看起来奇怪且无意义的事情。这使得调试和逆向工程变得更加困难，因为破解者需要付出大量努力来尝试将有用的内容与垃圾分开。
编辑：显然，让垃圾代码的一部分看起来比正确的代码更好，这样破解者就会首先查看那里，实际上会浪费时间和耐心。不用说，混淆一切，所以即使破解者获得了纯未加密的运行代码，它仍然看起来令人困惑并且非常奇怪。
As everyone else said, there is no magic bullet. The user could turn off the machine, get the HD as a slave to other machine, backup everything, reverse engine your code and then crack it sucessfully. Once the user has physic access to the executable, it is potentially compromised and there is nothing to do to stop it in 100% of the cases.
The best you can do is to make the work of a potential cracker hard as hell, but no matter what you does, it would not be unbreakable.
Using a self destruction in case of something wrong can be worked around by a cracker which backup'd everything.
Using a key in a USB driver helps to make the cracker life harder, but can be ultimately defeated by a competent determined cracker: The code that unencrypt things can't be in a encrypted state (including the part that gets the key), so it is the big weak point. Hacking that part of the code to save the key somewhere else defeats the key.
If the software does authentication in a remote server, this can be worked by attacking the client and circunventing the authentication. If it gets a key from the server, sniffing the network could be used to intercept the server data which contains the key. If the server data is encrypted, the cracker can unencrypt it by analysing the software that unencrypts it and fishing the unencrypted data.
In special, everything there would be much easier to a cracker if he uses an emulator to run your software that is capable to save snapshots of the memory (including a uncrypted version of the algorithm). Still easier if he can manipulate and pin the memory direct while running your software.
If you don't expect that your untrusted client are very determined, you can just complicate things and hope that they will never get the enough energy and skill to be worthing to break it.
The better solution, in my opinion, is to get all the software in your trusted server, and make their server just ask your server to do the job, and keep your algorithms in your server. This is much safer and simpler than everything else, because it removes the fundamental problem: The user no more has physical access to the algorithm. You should really, really think about a way to do this by eliminating your needs to keep the code in the client. However even this is not unbreakable, a hacker can deduce what the algorithm does by analyzing what is the output in function of the input. In most scenarios (does not looks like that this is your case), the algorithm is not the most important in the system, but instead the data is.
So, if you really can't avoiding running the algorithm in the untrusted party, you can't do much more than what you already said to do: encrypt everything (preferencially in hardware), authenticate and check everything, destroy important data before someone thinks about backuping it if you suspect that something is wrong, and make it hard as hell to someone crack it.
BUT, IF YOU REALLY WANT SOME IDEAS, AND REALLY WANT TO DO THIS, HERE WE GO:
I could suggest for you to make your program mutant. I.E: When you decrypt your code, encrypt it with a different key and throw away the old key. Get a new key from the server and assert that the key is itself coded in a way that it would be very hard to mock the server with something that gives compromised new keys. Make some guarantee that the key is unique and is never reused. Again, this is not unbreakable (and the first thing a cracker would do is to attack this very feature).
One more thing: Put a lot of non-obvious red herrings that does non-sense strange consistency checks, which a lot of non-functional bogus version of your algorithm and add a lot of complex overbloat that effectively does nothing and asserts that it runs as expected from real code. Make the real code do some things that looks strange and non-sense too. This makes debugging and reverse-enginering even harder, bacause the cracker will need a lot of effort trying to separate what is useful from what is junk.
EDIT: And obviously, make a part of the junk code looking better than the correct one, so a cracker would look there firstly, effectively losing time and patience. Needless to say, obfuscate everything, so even if the cracker get the plain unencrypted running code, it still looks confusing and very strange.
我知道其他人可能会在这个解决方案中找出漏洞 - 并且随意这样做，因为我以此类事情为生，并且欢迎挑战！ - 但为什么不这样做：
既然您显然使用的是 Windows，请使用最大安全设置在硬盘驱动器上启用 BitLocker 驱动器保护。这将有助于减轻人们克隆驱动器的情况，正如我的理解 - 如果我错了，请说出来！ - 其内容将根据系统硬件设置进行加密。
在硬件上启用 TPM 并为您的软件正确配置它。这将有助于停止硬件嗅探。
禁用您不使用的任何帐户，并锁定系统帐户和组以仅使用您需要的帐户。设置 Active Directory 和安全 VPN 的奖励积分，这样您就可以通过后门远程访问他们的网络以检查系统，而无需进行正式的现场访问。
要提高进入此领域所需的技术门槛，请使用 C++ 或其他非 .Net 语言编写软件，因为 MSIL 字节码很容易通过公开的免费工具反编译为源代码，并且需要更多的技术在汇编中反编译某些东西的技能，即使使用正确的工具仍然非常可行。确保为您将使用的硬件启用所有 cpu 指令，这会使事情变得更加复杂。
让您的软件经常验证已部署系统的硬件配置文件（唯一硬件 ID）。如果失败（如硬件已更改），则使其自毁。
硬件经过验证后，将您的软件从加密的二进制映像加载到加密的 RAM 磁盘中，然后该磁盘本身会在（非固定！）内存中解密。不要固定它，或者使用恒定的内存地址，因为这是一个坏主意。
请记住，可以通过安全密钥相对于其他内存块的随机性在内存中检测到安全密钥。为了帮助缓解这种情况，请确保使用多个“虚拟”密钥，如果使用这些密钥，则会触发入侵检测和爆炸场景。由于您不应该固定按键使用的内存，这将允许人们多次触发相同的虚拟按键。如果您可以随机生成所有虚拟密钥，并且由于下面的#12而使真实密钥每次都不同，那么他们就不能简单地寻找不会改变的密钥..因为它们都会改变，那就加分了。
利用多态汇编代码。请记住，汇编实际上只是可以根据指令和堆栈状态/之前调用的内容进行自我修改的数字。例如，在简单的 i386 系统中，0x0F97（如果在上面则设置字节）可以很容易地成为完全相反的指令（如果在下面则设置字节），只需减去 5。如果您确实需要，请使用您的密钥来初始化堆栈并利用 CPU 的 L1/L2 缓存想要成为核心。
确保您的系统了解当前日期/时间并验证当前日期/时间是否在可接受的范围内。从部署前一天开始并给予 4 年的限制将与保修/支持下硬盘驱动器的硬件故障钟形曲线兼容，因此您可以利用此类保护并在硬件更新之间留出良好的时间。如果此验证失败，请使其自行终止。
您可以通过确保您的 pid 文件经常更新为当前时间来帮助减轻人们对时钟的困扰；将其上次修改时间（作为加密数据及其在文件系统上的文件属性）与当前时间进行比较，将成为人们是否搞砸了时钟的早期预警系统。一旦检测到问题，就会爆发。
所有数据文件都应使用根据您的命令自行更新的密钥进行加密。将您的系统设置为每周至少更新一次以及每次重新启动时更新。将此添加到您应该拥有的软件“从您的服务器更新”功能中。
所有加密技术都应遵循 FIPS 准则。因此，请使用强加密、使用 HMACS 等。考虑到您当前的情况，您应该尝试达到 FIPS-140-2-level-4 规范，但可以理解的是，从经济角度来看，某些要求可能不可行，实际上，FIPS-140 -2-level-2 可能是您的限制。
在所有自毁情况下，请让它先给您打电话，以便您立即知道发生了什么。
最后是一些非软件解决方案：
如果它无法打电话回家......作为最后的努力，将自定义硬件设备连接到内部串行/USB 端口，该端口设置为激活继电器，然后启动一块铝热剂如果它检测到案例、硬件或软件篡改。将其放在硬盘驱动器顶部并将它们放在主板上效果最好。但是，如果这不是美国军方批准的情况（我假设您在美国），您需要向您的法律部门查询所需的许可证等。
为了确保硬件不被篡改，请参阅 FIPS 物理安全要求，了解有关确保系统物理安全的更多详细信息。如果您能了解如何将您正在使用的现代机架用螺栓/焊接到旧的 AS400 机箱中作为伪装，以帮助减轻硬件的移动/篡改，那就加分了。年轻的家伙会不知道该怎么做，并担心打破“吸旧东西”，年长的家伙会想知道“wtf？”，大多数人都会留下血迹，如果他们经常篡改的话，可以在以后用作篡改的证据。锋利的外壳，至少根据我自己的经验。
如果收到入侵通知，请将其从轨道上发射出去……这是确定的唯一方法。 ;) 只需确保您填写了所有法律表格和访问要求，以便法律部门对风险或责任的减轻感到满意...或者，您可以设置通知系统，一旦您收到通知，就会自动向人们发送电子邮件/短信/电话通知告诉你它爆炸了。
I know others will probably poke holes in this solution - and feel free to do so as I do this sort of thing for a living and would welcome the challenge! - but why not do this:
Since you are clearly using windows, enable bit-locker drive protection on the hard drive with the max security settings. This will help mitigate people cloning the drive as my understanding - If I am wrong, say so! - is its contents will be encrypted based on that systems hardware settings.
Enable TPM on the hardware and configure it correctly for your software. This will help stop hardware sniffing.
Disable any accounts not used by you and lock down the system accounts and groups to use only what you need. Bonus points for setting up Active Directory and a secured VPN so you can access their network remotely via a back door to check the system without making an official on-site visit.
To rise the technical bar required to get into this, Write the software in C++ or some other non-.Net language since MSIL byte-code is easily de-compilable into source code by publicly available free tools and it takes more technical skill to decompile something in assembly even if it is still very doable with the right tools. Make sure you enable all cpu instructions for the hardware you will be using, to further complicate matters.
Have your software validate the hardware profile (Unique Hardware ID's) of the deployed system every so often. If this fails (as in the hardware has changed) have it self destruct.
Once the hardware has been validated load your software from an encrypted binary image loaded into a encrypted RAM disk that is then itself de-crypted in (non-pinned!) memory. Don't pin it, or use a constant memory address as that is a bad idea.
Be very careful that once the decryption is done, the keys are removed from RAM as some compilers will stupidly optimize out a non-secured bzero/memset0 calls and leave your key in memory.
Remember that security keys can be detected in memory by their randomness in relation to other blocks of memory. To help mitigate this make sure you use multiple "dummy" keys that if used, trigger an intrusion detection and explode scenario. Since you should not be pinning memory used by the keys, this will allow people to trigger the same dummy keys multiple times. Bonus points if you can have all dummy keys randomly generated, and the real key different each time due to the #12 below, so that they cannot simply look for the key that doesn't change.. because they all do.
Make use of polymorphic assembly code. Remember that assembly is really just numbers that can be made self modifying based on the instructions and state of the stack/what was called before. For example in a simple i386 system 0x0F97 (Set byte if above) can easily be the exact opposite (Set byte if below) instruction by simply subtracting 5. Use your keys to initialize the stack and leverage the CPU's L1/L2 cache if you really want to go hard core.
Make sure your system understands the current date/time and validates the current date/time is within acceptable ranges. Starting the day before the deployment and giving it a limit of 4 years would be compatible with the bell curve of hardware failure for hard drives under warranty/support so you can take advantage of such protection AND allow you good time between hardware updates. On failure of this validation, make it kill itself.
You can help mitigate people screwing with the clock by making sure your pid file is updated with the current time every so often; Comparing its last modified time (as both encrypted data and its file attributes on the file system) to the current time will be a early warning system for if people have screwed with the clock. On problem detected, explode.
All data files should be encrypted with a key that updates itself on your command. Set your system to update it at least once a week, and on every reboot. Add this to the software's update-from-your-servers feature that you should have.
All cryptography should follow FIPS guidelines. So use strong crypto, use HMACS, etc. You should try to hit FIPS-140-2-level-4 specs given your current situation, but understandably some of the requirements may not be feasible from an economic standpoint and realistically, FIPS-140-2-level-2 may be your limit.
In all self destruct cases, have it phone home to you first so you know immediately what happened.
And finally some non-software solutions:
If it cant phone home.. as a last ditch effort a custom hardware device connected to an internal serial/usb port that is set to activate a relay that then sets off a block of Thermite if it detects either case, hardware, or software tampering. Putting it on top of the hard drives and placing these over the motherboard will do the job best. You will however need to check with your legal department for the permits, etc required if this is not a US military approved situation as I am assuming you are in the USA.
To make sure the hardware is not tampered with, See FIPS physical security requirements for more details on making sure the system is physically secure. Bonus points if if you can see about bolting/welding the modern racks you are using into an old AS400 case as camouflage to help mitigate movement/tampering of the hardware. Younger guys will not know what to do and be worried about breaking "suck old stuff", older guys will wonder "wtf?", and most everybody will leave blood behind that can be used later as evidence of tampering if they tamper with the often sharp edged case, at least based on my own experience.
In the case of an intrusion notification, nuke it from orbit.. its the only way to be sure. ;) Just make sure you have all legal forms and requirements for access filled out so legal is happy with the mitigation of risk or liability... Or you can set up your notification system to email/text/phone people automatically once you get a notification telling you it exploded.
“拥有一个完全安全的系统的唯一方法就是用锤子砸碎它。”
也就是说，有可能与潜在的黑客搞砸，使其变得比其价值更多的麻烦。如果机器是一个“黑匣子”，他们无法真正直接访问它，而是有处理它的程序，那么对它的最大威胁就是物理访问。您可以锁定箱子，甚至可以在箱子中安装一个小的易碎物品，如果箱子被打开，该物品就会折断...确保您的服务人员始终更换该物品...它会通知您是否有人打开过未经授权（是的，这是青少年的老把戏，但它确实有效）。至于盒子本身，请物理禁用您绝对不需要的任何硬件（例如 USB 端口）。
如果您处理的机器不是黑匣子，请对所有内容进行加密...如果没有密钥，256 位加密实际上不可能破解...那么技巧就变成了获取密钥。
理论上，您可能会更改密钥（通过重新加密数据），并且只能通过直接与（安全）服务器通信的进程来检索。
此外，跟踪盒子上发生的所有情况，尤其是软件中发生的超出正常使用范围的任何情况。其中大部分无法保护您免受真正、真正有决心的人的侵害……但它可以提醒您您的系统已受到损害。 （据此你可以起诉任何闯入者）
至于终止开关……嗯，潜伏病毒就在那里，但正如已经说过的，它们可能会被愚弄或意外触发。我建议，如果您怀疑存在违规行为，不要将其自身清除干净，而是让系统使用随机生成的密钥加密所有内容，将密钥发送到您的服务器（这样您就可以消除损坏），然后“粉碎”用于包含密钥的文件。 （许多文件粉碎机可以很好地破坏数据，以至于（几乎）不可能恢复。）
"The only way to have a totally secure system is to smash it with a hammer"
That said, it is possible to screw with the would-be hackers enough to make it more trouble than it is worth. If the machine is a 'black box' where they can't truly access it directly, but instead have programs that deal with it, then your greatest threat to it is physical access. You can lock cases down, and even install a small, breakable item into the case that will be snapped if the case is opened...make sure your service people always replace this item...it will let you know if someone has opened it without authorization (yes, it's an old teenager trick, but it works). As for the box itself, physically disable any bits of hardware (like USB ports) that you don't absolutely need.
If you are dealing with a machine that isn't a black-box, encrypt the hell out of everything...256bit encryption is effectively impossible to crack without the key...then the trick becomes getting the key.
In theory, you could potentially have the key change (by re-encrypting the data) and only be retrievable by a process that directly communicates with your (safe) servers.
Additionally, track everything that happens to the box, especially anything that occurs in the software that is outside of normal use. Much of this can't protect you from someone who is really, really determined...but it can alert you that your system has been compromised. (upon which you can sue the heck out of whoever broke in)
As for the kill switch...well, sleeper viruses are out there, but as has been said, they can be fooled or set off by accident. I would suggest that rather than wiping itself clean, if you suspect a breach, have the system encrypt everything it can with a randomly generated key, send the key to your servers (so you can undo the damage), and then 'shred' the file that used to contain the key. (many file shredders out there can destroy data well enough that it is (almost) impossible to recover.)
总结一下答案，是的。这个问题没有“完全安全”的解决方案，因为它需要同态加密（存在现在仅以有限原型的形式存在，这需要大量的计算）。
实践中，您需要的是适当的需求工程和安全工程的结合（评估利益相关者、利益、已部署系统内的宝贵资产、每个成功攻击场景可能造成的攻击和损害以及防御成本。）
在 要么会发现保护并不是真正需要的，要么您可以部署一些合理的措施并用合法的东西覆盖其他“漏洞”，或者从商业模式开始完全重新设计系统（不太可能，但也有可能） 。
一般来说，安全是系统工程问题，你不应该只局限于技术方法。
Summarizing the answers, yes. There are no 'perfectly safe' solutions to this problem, as it would need homomorphic encryption (which exist now only in the form of limited prototypes which require ridiculous amounts of computation).
In practice, what you need is the combination of proper requirements engineering and security engineering (evaluate stakeholders, interests, valuable assets within the deployed system, possible attacks and damages from each successful attack scenario VS costs to defend from it.)
After that, you'll either see that the protection is not really needed, OR you can deploy some reasonable measures and cover other 'holes' with legal stuff, OR re-engineer the system altogether, starting with the business model (Unlikely, but possible, too).
Generally, security is the systems engineering problem, and you should not limit yourself to technical approaches only.