Protecting a system deployed in a "hostile" environment

Question

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....

Answer 1

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:

• You must encrypt the filesystem and use hardware decryption
• You must isolate your applications from each other, so that security issues in one don't compromise others
• You must plan for security issues to occur, which means putting mitigation strategies like a secure hypervisor in place

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.

Answer 2

... 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:

1. What happens if their internet connection dies or they move offices and disconnect the machine for a bit?
2. What if you code it wrong and it misfires? Deleting data even if the customer is using it correctly?
3. I can only assume your request implies that your application offers no backup capabilities. Am I correct? Sounds exactly like a product I wouldn't buy.
4. How valuable is the data your 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?

Answer 3

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.