Let's say I want to move my 1U Dell server to co-location site with a hostile company who will try to steal my code (this is almost 90% probability if I dont take steps)...

The limitation for their hostility I see (or hope) - they can't remove the box completely and tell me, "oops, it got lost in mail", they can't hire experts from too high level (like FBI or NSA), so it has to be done on the level of a savvy sysadmin reading hacking forums. Also, they would have to explain any downtime (which is easy but in conjunction with tampering evidence will be powerful deterrent).


From my understanding the best way to secure your software is to encrypt it on the disk.

Then to disable external access to boot your server for cold boot attack (I think - disconnect optical drive, USB, com port etc.)

Then I still have the following problems - opening the case and connecting to the MB or removing RAM where the decripted software was running before a cold boot attack.

Question #1 - are there other threats for the code to be stolen in the given situation?

What I am thinking is to make sure if they tamper with the case I will get hard proof which can be brought to court and I get the compensation. If the tamper evident device is convincing and reliable then they won't risk their reputation with the legal case and leave this alone.

Please tell me what you think. Is it feasible plan? Is it possible to narrow the chances of stealing to opening the box (I mean is disconnection USB etc will work?) Are there any other things I need to consider?

EDIT. I will try to compile the answers.

The main consideration - using Dell TPM. Box is Dell R210

  1. RAM removal (cold boot attack)
  2. Console access using unsecure account [doest it help to recover TPM keys?]
  3. Boot from another hard disk [doest it help to recover TPM keys?]

EDIT EDIT. Guys, most of you wrongly assumed that having box on colocation means an ISP or Internet company who sells colo to the webservers, gamers etc. Nothing even close in my case. There are few guys in my area of expertise who sells colo at affordable price. (By colo I mean letting other people they know to put boxes in their racks) And we all are doing the same thing so they dont need to ask they know what I do and I know what they do. Putting unsecured box to them is like leaving open bottle of Glenfiddich 18 next to an alcoholic and walk away. Whatever the morality is they will be really really tempted to open it. I know cos I would too in their shoes. Cold boot is not so much sophisticated thing to do either. So most of your projections simply doesnt count in my case.

I am going to leave it open for couple of day is someone would like to add to the actual physical threats list.

Thank you for your patience :)

  • 1
    Curious... Is this actually a "hosting company", a "customer", or another department within a mega-corporation? How does this hoster know so much about your app? Feb 21, 2012 at 18:40
  • Are you more worried about private key theft, or intellectual property? What kind of app is this? Why does the business require your code in this hostile location? Feb 21, 2012 at 18:46
  • > Is this actually a "hosting company", a "customer", or another department - that is the good question. thank you. It is neither of these but the idea is correct - it is not a hosting company what many assumed. its just it - trust on my word. the threat is real but I want to manage it and use the serivce. this is why I am here asking questions... Feb 21, 2012 at 21:37
  • Thanks; I asked the second set of questions (Are you more concerned about Intellectual Property/Code or Private Keys) since you may be able to protect your interests using software. I know people that are using the Azure Service Bus to allow "local" access to a remote server doing stock analysis. The algorithms are kept "private" in a trusted datacenter, and the namespaces keep the client and server anonymous. This all happens with transport encryption. Feb 21, 2012 at 22:02
  • yes the algorithm is the clue. but it is very low latency so there is no point to have it split. If I could split I certainly wont be even thinking about colo. but yes in many cases this approach is a good one. Feb 21, 2012 at 22:32

4 Answers 4


Your attacker has physical access to the machine and can boot it under an operating system under his control or mount the drive in another machine. Therefore you need security that is provided at least in part outside the machine's storage, in a way that is somewhat resistant to physical tampering.

This is a typical use case for a Trusted Platform Module (TPM). The TPM is an additional chip on your motherboard somewhat tamper-resistant (not to a well-equipped lab, not even to a knowledgeable individual with a bit of electronic equipment, but to a casual person equipped with nothing more than a screwdriver and a USB stick) and tamper-evident (it can be defeated by ripping it off the motherboard and inserting an active chip between the TPM and the rest of the motherboard, but it would be difficult to solder it back without leaving a trace). The TPM can store secret keys that never escape it and can perform cryptographic operations with these keys. In particular:

A TPM is not a magic bullet. It needs to be configured properly, and more generally the whole platform needs to be configured properly. A TPM is no good if the attacker can plug in a keyboard and obtain console access because of an improperly secured account or because the BIOS allows booting from a disk other than your own.

Another attack that a TPM won't prevent is on the RAM. For example, the attacker might try a hot swap attack on the RAM and read its contents. So you would need a tamper-resistant, or at least tamper-evident case.

If you use a TPM in this way, don't forget to back up all the TPM's master keys before shipping the box, as your data would be lost without them.

Given the way you present your situation, I suspect that

  • either you exagerate the worth of your code to the hosting company (why would they care? who would they sell it to?);
  • or, if this is worth so much to you, you need to pay for more expensive hosting.

Don't forget that if they have your code, it's no good if they can't make money out of it. If they suddenly offer a service just like yours, you may have a good reason to sue and demand discovery of just how they developed their service (consult your lawyer). Not all security measures are technical, a contract can be a deterrent.

  • You are almost there :) thank you. I already past the TPM phase. So I asked this question specifically because I want to use TPM but I want tamper-evident device on the box to deter them from opening it (see my other questions 2 days ago). Feb 21, 2012 at 1:00
  • P.S. this is not your normal internet colo. this is specialised company which simply sells space in their own racks and I need it but if they see my box getting some business they will want to get into it without doubt. So I dont exagerate. Hence the deterrent need to be adequate. Feb 21, 2012 at 1:09
  • 1
    A TPM does not defend against attackers who have physical access to the machine. So, it wouldn't actually be sufficient to protect against a malicious hosting provider (assuming we actually took that threat model seriously).
    – D.W.
    Feb 21, 2012 at 1:36
  • 2
    Obviously you may not be able to give many more details, but can you hint at the reason you can't go with a provider you trust? Feb 21, 2012 at 14:30
  • 2
    @Bobb - What kind of hosting company tells other customers anything about your business ( i.e. which rack contains your information ). If you cannot trust your hosting company not to give this information out DO NOT USE THEM.
    – Ramhound
    Feb 21, 2012 at 17:07

I think you're not thinking about this clearly.

If you are convinced that the hosting provider is going to try to steal your code, there's a very simple solution: don't deploy your code on a machine with that hosting provider!

If you are convinced that every hosting provider is going to try to steal your code, don't deploy it on any hosting provider: deploy it on machines on your own premises.

That said, I strongly suspect your threat analysis to be mistaken. I find it hard to believe that there is a 90% probability that every hosting provider will steal your code, if they can get away with it. There's just no way that is accurate. If they were caught, the hit to their reputation would be devastating: it would put them out of business. Reputable providers are unlikely to take that risk. And, what's more, most hosting providers don't have an interest in your code; they are focused on their hosting service business, and probably don't care about your code.

So I suspect that you have mis-estimated the risk. But, if you're convinced you've got the risk right, well, the solution is simple. Just don't use a hosting provider.

You know the old joke:
Patient: Doctor, doctor, please help me. It hurts when I slap my knee.
Doctor: Well, don't do that then!

  • If I'd sit home every time I think a terrorist would fly a jet into my office I'd die from heart attack. I'd rather solve the problem. I know you wouldnt believe but I did few thing in my life which deemed not possible by the majority. Sometime if you cant but you really want then you can. Feb 21, 2012 at 21:53
  • Could you please stick to the point - enumerate the physical threats feasible to implement for a savvy IT person / non-pro hacker / retired security forces crook. Feb 21, 2012 at 21:53

Classically, there are four things you can do with any risk:

  • Treat it by implementing security controls.
  • Tolerate it as acceptable.
  • Transfer it to a third party.
  • Terminate it.

In the situation you describe, where you have a very high likelihood of an incident, and assuming that the cost of an incident is high as well, then the best approach is going to be to terminate the risk - i.e. don't do it in the first place.

Not much help to you, of course, but there's a reason why security people go on and on about physical access to the box; there are no truly effective security controls when the attacker has unfettered access to the box.

If you cannot Terminate it, then of course you can try the other methods. Transfer to a third party will be difficult, as this would be complicated and expensive to insure, and you already don't trust the contract you have with the hosting provider.

That leaves a combination of Treat and Tolerate. Treating the risk would involve things like intrusion/tamper detection, monitoring of activity on the box, warning the provider that you will sue at the drop of a hat, and so on. However, because the attacker has physical access to the box, network, and power, and is prepared to break their contract and the law, then these treatments will not be able to reduce the risk by much.

That just leaves tolerating the risk despite it's severity: accepting that if you have to put the box into that situation there is a good chance your asset will be compromised.

Lastly, there is one other treatment that I'd recommend you consider in this case. If you would be able to tell that they had stole your code because they start using it, and if they claim that they won't, you could try to get your lawyer to add penalty clauses to the agreement with them - a sort of non-complete. Not ideal, since it only kicks in after the damage is done, but in this bad a situation every treatment you can pile on helps a little.

  • there is another option - increase risk so the other guys wont attempt it. eg use of high security tamper evident device (which is in my other question). (it is similar to your #1 but not exactly, deterrent is the word) Feb 21, 2012 at 1:02
  • Ah, they're not my categories! Tamper detection devices and threat of legal action are both security controls and count under "treatment" in the four Ts. Let me update my answer a little... Feb 21, 2012 at 14:20
  • P.S. By the way - there is no service either. So the only way for me to deter through legal proceeding is to have a solid tamper-evident device on the box. This is why I asked this question (to know where to put these devices) and also see my other question about tamper-evident device itself. Feb 21, 2012 at 21:50

Actually the best way to secure your source code is to not put it on a server you do not control. Can you compile your code and only deploy the binaries?

There would seem to be another big risk which you do not mention, are you planning on doing backups? Who will be doing them?

If the colo is doing the backups, how do you know they didn't make a copy.

If you are doing the backups via the network to a remote site, how do you know that they are not sniffing the traffic?

  • no backups. by code I meant binaries of course but the application is not massive and can be reversed. also the critical part is very small and those guys know what to look for so it shouldnt be too hard. Feb 19, 2012 at 3:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.