We have to ship a hard- and software prototype to a customer for a first field test. The software is just not ready (protected - too much Python code) for distribution without the possibility, that someone extracts to easy our code and algorithm (I know, there is not really a 100% security anyway).

My idea is to give the customer a proprietary laptop with our software. The disk of the laptop is fully encrypted and can only be decrypted with a one time password. So the customer has to power on the laptop all the time. The software would be executable only (chmod +x) and inside the root folder. The whole disk for the customer would be no-read/write or read-only.

Any ideas on that, if this could be possible? Maybe with LVM (luks)? I know, there exist some OTPs but mostly for unsecure network connections or only parts of the disk, when the OS is already started. Do you know another workaround to accomplish this?

  • To start with, Linux file permissions do not work the way you think. ... Just stop trying the impossible and rely on the legal system. – deviantfan Jun 30 '16 at 6:12
  • 1
    Type the password yourself and provide customer with the unlocked laptop. That solves the one-time part, doesn't it? It doesn't solve the problem though. – techraf Jun 30 '16 at 6:25
  • 2
    Still could hook up the drive to another pc and copy everything bitwise, so the OTP can be used as often as wanted – Kimmax Jul 5 '16 at 12:08
  • You realize laptops have to power off at times, right? Things like an update requiring a reboot, running out of battery while in the field / on a flight / anywhere that an outlet or the power supply isn't available, running into a problem for which the usual solution is "restart the computer", a hardware or software issue triggering a reboot... this approach is a sure road to failure. – CBHacking Dec 24 '17 at 3:31
  • To expand on what @deviantfan said, file permissions (on approximately any file system or OS, be it Linux, Windows, or things more esoteric) do not support execute-but-do-not-read as an option. You have to read the file to execute it (and this is especially true of Python, which isn't even executable code to begin with; it is read by a python interpreter). The few attempts I know of to create an execute-but-not-read file system were easy to bypass (hook up a debugger to the executing process, or map its binary as a library in another process, and then read its executable code that way.) – CBHacking Dec 24 '17 at 3:37

Send one of your engineers with the laptop. Rationale:

  • If it's important enough to send a laptop, it's important enough to send a person
  • There will be no problems caused by ad-hoc encryption and lock-in
  • If there are (other) problems he'll be able to solve them
  • No problems with the client copying the software or hardware
  • Your guy will learn a lot from the client about what the client expects and needs
  • If your hardware and software are not GA quality I expect your documentation isn't either
  • Above all you avoid the situation where your prospective client finds himself with a laptop he cannot use for some reason, and decides your product is not good

But do write up an NDA agreement too, of course.

| improve this answer | |
  • +1 because, although not strictly InfoSec-related, this is definitely the correct and logical answer. A "first field test" should absolutely have somebody on hand, especially if the product isn't production-ready. – CBHacking Dec 24 '17 at 3:28

You can't give a laptop to someone else and expect them to run it without being technically able to read its files. Once they have access to the hardware, they could read anything that it is run.

That said, you could make it "hard enough" for a company scenario. They probably wouldn't be interested in hacking into the laptop. But for a skilled and determined enough attacker, any solution involving giving them full physical access to the laptop could be bypassed.

The solution given by Law29 of sending an engineer to operate it solves it nicely.

| improve this answer | |
  • 1
    Exactly. An OTP does not provide any benefit to data at rest security. It only works for a live authentication system. – forest Dec 24 '17 at 6:02
  • Yes -- in my (year-and-a-half-old) answer I did not address the feasibility of providing an OTP for decrypting a hard disk. Off the cuff I cannot think of any way to do that would not be a bad hack; hard to execute, solving the problem only imperfectly and causing much more problems than it would solve. – Law29 Dec 24 '17 at 14:20

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.