How to prevent my client from hacking into the demo computer I provide him?

Question

I need to provide a customer of the company I work at, a laptop computer with a demo software that will run on it.

The software is for display only and doesn't require any user interaction via keyboard or mouse.

I need the computer to disable all device inputs and the hard drive to be encrypted, so only this computer can run. I want to prevent the customer from accessing the computer while it works and prevent the option of removing the hard drive and using it on a different computer.

Does anyone know of any hardware computer\hard-drive combo that can do this?

Thanks.

Answer 1

This is simply not possible. Physical access to hardware literally removes all promise of security.

Sure, you can make it more difficult for someone to gain unauthorized access. But beyond the most trivial and inexpensive measures, doing so is a complete waste of time and money. If someone really wants to get in, they will find a way to do so and you won't be able to stop them.

Not to mention they could reverse engineer your software without ever compromising the demo computer that you provide. I'm not sure if this falls under your definition of "hacking", but it probably should.

This is not a technology problem, it's a legal problem. You need to protect your software and your intellectual property with licenses and other contractual agreements. Get the customer to sign a non-disclosure agreement, if necessary. The best thing to do is to consult a lawyer, not a technologist.

If you're afraid of lawyers, hire a security company. Lock the computer down with hardware solutions, like a locked cabinet and an armed guard. If that sounds ridiculous, see the above paragraph.

Answer 2

Check your laptop's BIOS at boot, look around for options like hard drive encryption or "ATA Hard Disk Lock" (not encryption, but I don't think most drives have any mechanism that would allow you to bypass the password).

You can shoot epoxy into the firewire port to prevent them from attaching a PCI memory reader debugging tool.

Update

The fact that it's Linux gives you some more flexibility. :) You can remove the usbhid.ko, hid.ko, and similar kernel modules from the system. Look through lsmod(8) output and remove anything that looks like it'd be useful for the trackpad or keyboard or nipple-mouse. Delete the firewire modules. Maybe even the serial and parallel modules. (If you're not using them, it won't hurt to be rid of them.)

You'll need to lock down grub as well, so that your client can't just edit the kernel boot line and add init=bash or init=getty /dev/ttyS01 or something else similarly annoying.

You might also want to use a tool such as AppArmor, SElinux, TOMOYO, or SMACK. Any of these mandatory access control tools can prevent an application from escaping a well-defined set of privileges. As I've worked on the AppArmor system for a decade now, it's the one I know best and the one I'd recommend :) but any of these tools can help lock down every mechanism that your client can interact with the computer.

(To tell a small diversionary tale, we took an AppArmor-confined system to the DEFCON Capture The Flag contest for several years; one year required allowing users to telnet in as root with a specific password. AppArmor made it easy to confine the telnetd daemon, the shell it started, and then the programs that the 'scorebot' needed to run. We never won the CTF contests, but we never got rooted, either. We never needed to worry about physical attacks because everyone who was defending was known to us.)

Best of luck.

Answer 3

As hinted at in the comment on the question, the correct device for accomplishing this is called a "contract". Write one up (or, better, hire a lawyer to write one up - you can probably get it done for a couple hundred dollars, which is a lot less than tamper-proof hardware would cost) detailing what they are and are not allowed to do with the demo unit and have them sign it as a condition of receiving said demo unit.

Answer 4

After getting some good advices and understanding from you, the weak points I should look out for I would like to sum up and tell you what we decided to finally do:

First, a couple of things you need to know.

1. Legal protection is not available when dealing with our customer. If he decides to hack the system he would succeed, eventually.

2. As long as we can protect the product in such a way that the customer will have to invest more money in the reverse engineering, than what the entire company is worth, that's a good enough protection for us.

3. Our system is Linux + Java + Postgres

Now for the solution we selected

1. We will protect the bios with a password. on the bios level, we'll limit boot to the HD and prevent connection of USB devices. This can be hacked by buying a back door code on the web for 30$ or tampering with a chip on the board. However, this will leave indications of tampering, which are quite visible.

2. We'll lock down Grub to prevent booting to the command line.

3. The keyboard, mousepad and usb mouse in XWin are locked using parameters in xorg.conf:

   Section "ServerFlags"
   Option "AllowEmptyInput" "false"
   Option "AutoAddDevices" "false"
   Option "AutoEnableDevices" "false"
   EndSection
   

4. We'll delete usb and keyboard drivers from the kernel. (to make life harder on hackers).

5. We'll put physical indication (probably color silicon) on the HD, to see if the HD is removed from the computer. If they remove the HD or hack the bios, they will leave fingerprints that they won't be able to wipe.

6. We'll use Obfuscation tools on the Java code. Our product is quite complex, so Obfuscating it, will prevent any reverse engineering at reasonable cost or time frames. Please read: http://www.javaworld.com/javaworld/javaqa/2003-05/01-qa-0509-jcrypt.html and we'll use one the following tools Open Source tools: http://java-source.net/open-source/obfuscators or DashO from http://www.preemptive.com/

7. SSH access is available to me only with a key file. All passwords will be removed where possible.

With all the steps above, we can force hackers to work for their money and get an indication if the system was hacked.

Answer 5

Once someone has physical access to a system, there's not much you can do about it. For starters its OS dependant - you could possibly use read only media to prevent the user from messing with the the system, and in the process of setting it up, set it to have the inputs unavailable - possibly using bartpe (for windows) or some manner of livecd - many methods allow you to make a bootable backup from a running system.

I'd also suggest tamper evident stickers over the hard drive, or cd rom drive - at the very least it'd let you know if the hard drive was removed.

In this case tho, a mini ITX or full system which has a lockable case might be a better bet tho

Answer 6

Full-disk encryption software normally relies on a password being entered to decrypt it, how were you proposing to protect the harddrive - in other words where are you going to put the 'secret'?

Answer 7

Why give them physical access to the software at all?

If so little local input is involved, the laptop you provide them needs to do nothing more than act as a remote viewer of another machine that remains in your possession.

This way they can run with very limited privileges, be constantly monitored and the family jewels need never leave your vault. Even without knowing your platform, I am sure there are quite a number of remote access options that would suit; Teamviewer, LogMeIn or Remmina to name a few.

There are obviously still security issues to consider, but back this up with a pretty strict legal contract and you should be able to sleep nights without a worry.

Answer 8

Once you give someone physical access to a machine, they can pull out the hard drive, make a copy of it, stuff it back in, and hack it at their leisure. Cody is correct that this problem is not really solvable.

One work-around is to have the real program running on a remote demo computer. Have your client's demo computer connect to it. This will make your application look less responsive, so it may hurt sales :/

Answer 9

This is a very tricky problem. I have an off-the-wall idea that I am just going to throw out there, since it might be a better solution than physically damaging the computer. You could have this software product of yours setup as a linux screen-saver. Then set the time-out to really small that way if a user tries to interact with the computer a login screen will appear and they will be SOL, but application should resume after time-out for screensaver. To get past your hard-drive encryption problem, The only solution I can really think of here is that if you have hardware encryption on the motherboard of the laptop it could be so that only THAT specific laptop can access the hard-drive. You will have to check your system BIOS to see if you have that feature. other than that I use truecrypt.org for all of my (and my works) encryption needs, but that all usually requires a password entry. Figured I would suggest it all the same though. If I think of something more I will let you know, good luck ;)

Answer 10

Have you considered enabling the CPU ID in BIOS and then since you control the code, insert appropriate check into your code at periodic areas. During program start - check CPU ID, if bad, abort and overwrite the program. During program run - check CPU ID, if bad, abort and overwrite program...

Answer 11

A solution would be to look at the Trusted Platform functionality a few companies offer, although it may be over priced for what you want to do.

Microsoft have a TPM module which you can use with TPM hardware

This Infineon page gives links to a number of manufacturers such as Dell, HP, Toshiba etc

TPM allows you to tie software to hardware in a much more secure way.

Answer 12

If it's Linux disable inputs from the mouse and keyboard and don't allow USB drives or CD to boot.

You'll need a way of getting in yourself but with some authentication it's shouldn't be too tricky to research. Maybe add a BIOS password and allow CDs to boot after yuo've accessed the BIOS.

Answer 13

You could open the laptop and disable the keyboard and trackpad by unplugging the physical connectors.
You would have to do this once everything else was configured. USB devices disabled, boot from CD/DVD disabled etc. This way once you get the computer back yuo can simply open it up, re-connect the trackpad and keyboard and set everything back to normal and the computer will be fully usable again.
If you were really concerned you could use security screws / security tape to prevent him opening the laptop himself.

Answer 14

I saw mention of remote access in some of the answers here, and responses hinting or eluding to a VNC. No one metioned a Thin Client.

Since your software/machine needs to access dynamic content, and be connected to a network, a thin client would seem to be a good fit.

Applications run as if installed on your potential customer's machine; however very little hardware, and certainly NOT your software needs to be installed on the machine that's going to leave your hands.

In a transaction like the one you're describing, there absolutely has to be some give/take from both parties involved - an effort to keep everyone honest.

If you don't trust this person, do not hand them your idea and cross your fingers. Even if you end up suing for copyright infringement, or theft, the damage is already done - but it seems you already feel that way.

Best of luck.