2
$\begingroup$

Imagine that I need to install my server in a remote location, so my algorithm can do something fancy (collocation of server at a financial exchange is how I thought of this question, but it applies more generally).

Imagine also I don't trust the people I am working with. They will have access to my server and I cannot be there to stop them from opening up the box and copying the disks.

Is there any way for me to hide the business logic of my algorithm from them, while maintaining that algorithm's functionality? In other words, can I encrypt my software and yet have it operate at the same time?

My feeling is no, since the software needs to speak in machine language, using the instruction set architecture, which is pretty standard. But CS is full of surprises so I thought I'd ask.

If the answer is yes, how do I do it? If the answer is no, are there any safeguards I can implement?

$\endgroup$
  • $\begingroup$ Not sure how this is a computer science question. $\endgroup$ – Raphael Jan 27 '17 at 17:51
7
$\begingroup$

If you want a practical answer: with Intel SGX, the answer seems to be a qualified yes, but software development is likely to be more painful. (Similar with a TPM, though that will be even more annoying.) See, e.g., https://security.stackexchange.com/q/2459/971.

If you want a theoretical answer: in theory, you could use various cryptographic schemes for outsourcing computation (e.g., fully homomorphic cryptography, secure multiparty computation, SNARKs, outsourcing computation, and so on). As a general theorem, any computation you can do in polynomial time, could also be done on the remote server in polynomial time, with ability to verify that the result it gives you back is correct in polynomial time. However, in practice right now these schemes include an enormous performance overhead (a factor of a million slowdown or more), except for certain special tasks, so they're not at a stage where you could actually use them in practice today.

$\endgroup$
  • $\begingroup$ Would it be possible without outsourcing computation and without third-party? If yes, should I post another question here or at crypto? $\endgroup$ – Evil Aug 11 '17 at 23:18
  • $\begingroup$ @Evil, you mean, you are looking for some approach other than the two approaches I gave? I don't know. If you can articulate a clear set of requirements and threat model and describe what approaches you've already considered and why you rejected them, then it's worth asking a question somewhere. I'm not sure whether to ask here or on Crypto.SE, as that will depend on the question. If you're looking for cryptographic solutions, ask on Crypto.SE. If you're open to non-cryptographic solutions, ask here or on Security.SE (I'd recommend the latter, but it's probably on-topic on both places). $\endgroup$ – D.W. Aug 11 '17 at 23:23
  • $\begingroup$ Well, I am looking for full encryption scheme of function (still performing computation) where input and output are public, everything computed at the device with physical access from attackers, and no connection to third-party or external server is possible. I have asked at chat and got impression it is not entirely possible, so I am open to any solution. (Sorry for providing link). I thought that I could use FHE or MPC, but there are flaws in this idea, I cannot securely store keys at the device, so it defies the idea. $\endgroup$ – Evil Aug 11 '17 at 23:45
  • 1
    $\begingroup$ @Evil, I suggest posting at Security.SE. Consider tamper-resistant hardware (smartcards, etc.). $\endgroup$ – D.W. Aug 12 '17 at 1:56
1
$\begingroup$

Software Obfuscation is one way of hiding the details of an algorithm so that it cannot easily be recovered. The idea is to introduce additional spurious control and data flow that cannot be easily removed. Disassembly tools then have a hard time converting the assembly language code back into readable source code.

$\endgroup$
  • 2
    $\begingroup$ But if the workers have unsupervised physical access, they still can copy the software, and use it / take it, without reversing it. $\endgroup$ – Evil Jan 27 '17 at 9:24
  • 2
    $\begingroup$ @Evil You can work around this: e.g. generate a hardware identifier during installation using a secret key and embed it in the program. If the workers have access only to the running software, their copy now won't run (or will run long enough to report). $\endgroup$ – Alexey Romanov Jan 27 '17 at 10:18
  • 1
    $\begingroup$ Oh yes, there are some workarounds, I just wanted to point that using only obfuscation is not enough in the setting given by OP. $\endgroup$ – Evil Jan 27 '17 at 10:22
1
$\begingroup$

An activation key that is only activated with entering a code. That code could be long like from a USB drive. But this is does not necessarily hide business logic.

If your algorithm uses critical constants you could encrypt them and again you must supply a decryption key at run time.

Encrypt the compiled (or interpreted) code just makes things a lot harder.

Obfuscate is a strong deterrent but with enough time and resources they will crack it.

Security SE may be a better fit for this question.

$\endgroup$

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.