PHP Source Code Encryption Concept

Question

Scenario:

I'm looking to protect my software that is written in PHP. The nature of PHP is that it is delivered as plain text and therefore cannot be protected by itself. I don't want to install libs to the server like ZendGuard, IonCube or SourceGuardian. I want that individuals should use the software but should not interfere with the protected part of the application (licensing, sensitive parts). The software is distributed to clients as trial software.

Solution Concept:

Encrypt the payload with a blockcipher (AES) and store the key on a remote system. To software would require the key to decrypt the payload. An obfuscated part of the software should contact the key server via cURL over SSL and request the decryption key. The decryption key should only be sent back to the Server IP that holds a trial license. A checksum of the files could also be posted with the key request and if it even fails once, the key server could reject to provide the decryption key forever, which should hopefully prevent tampering.

Notes:

• The client requesting the trial will be known in advance so unauthorized copies of the software should never receive a (correct) decryption key in first place.
• The decryption keys are unique to every client and the payload parts are too.
• The code will never be stored decrypted but only decrypted at runtime and eval()'ed.

Questions:

• Is this a feasable or doomed to failure?
• Wouldn't this protect even against the tiniest tampering by anyone?

Thank you!

Answer 1

Let's see. Once your key server sends the decryption key, the hacker can monitor network activity to retrieve the key and use it to decrypt the source code. From this moment, he can do whatever he wants with it, especially:

• Modify it in a way that it will either send the checksums you are expecting, and not the actual checksums of files,

• Replace the part which contacts the key server, or simply remove it to avoid the check,

• Post on P2P networks the decrypted source code with key checking part removed.

On the other hand, some part of the legitimate users of your product will probably prefer using the product of your competitors, because:

1. They'll find that your app is slow to start. Contacting the remote key server takes time, which may or may not be accepted by the end users.

2. Decrypting takes time too, which can waste too much resources on servers. Your competitors' products may achieve much better CPU footprint if they don't add this sort of complexity.

3. Banning by IP will  cause additional problems. Most users have dynamic IPs, which means that a ban will affect the concerned person only for a very limited amount of time (such as one day), and then prevent other persons to access your product. In the same way, banning the whole company or a wifi spot is rather unfortunate in terms of marketing.

4. They won't accept to rely on a fragile product (unless you work in a very large company which guarantees that the product will be maintained for the next 5, 10 or 15 years). Not having the source code means that:

   • If your company stops maintaining it, your customers will be using an obsolete product which may contain known but unpatched bugs.

   • If a customer wants to modify it, he has no other choice than to pay you (often a lot, because of the monopoly) to do the change.

5. They won't accept to rely on a product which can contain malware. If you're a known company with excellent reputation, this is not an issue. If you're a startup or don't have a well-established reputation, some customers would not install your app because of the risk of malicious code. This is especially important on servers which are often more protected than desktop PCs in companies.

If you actually invented something that should be protected (and very probably, you haven't), the only way you can protect it is to move the sensitive code to the servers you own, and then provide an API to access the functionality from the outside. As soon as you give the code, no matter how well is it protected, it can be decrypted; otherwise, it wouldn't be possible to run it.

If the only goal is to have a trial version, simply host it on your own servers. Potential customers will be able to try it, and if they are interested, purchase the product. Of course, in order to convince sysadmins as well, you should also provide very detailed information about the way your app should be deployed and hosted.

Later, when your product becomes successful, you may consider evolving your offer, by providing:

• The limited in time demo hosted on your server,

• The pay-per-month subscription where the product is still hosted on your server. Multiple variants of subscriptions may target separately individuals, small companies and medium-sized companies. For small entities, the product may be out of charge for a year or some other long period of time (or forever).

• The more expensive solution where the customer deploys your app on his own servers. This solution may target large companies.

With this model (used by many startups), encryption of source code becomes mostly irrelevant. Large companies won't try to download your product from a P2P network, because of all the compliance policies which prevent them from using unlicensed products.

Answer 2

You wrote in a comment to MainMa's answer that:

I thought about this for a simple trial period of maybe a couple of days and after the purchase has been made, deliver the decrypted version. The main goal is to deliver the product without delivering the source (at first) so that the user can see if he likes the product (or if it's useful) .

which coincidentally turns your question into an XY problem. In other words, you are seeking to solve a problem, and instead of asking about the problem you want to solve, you ask about your proposed solution. (Which can work, if the proposed solution is actually good and you just need some minor detail straightened out.)

If the above is your reason for doing this, then forget about obfuscating the source code. It will add a huge amount of complexity and risk, with many downsides as explained by MainMa and no real, tangible advantages for anyone.

Instead, host a copy of your own that prospective customers can log in to and experiment with. Restore a blank database every midnight or something like that, make it clear to any users that any and all data they enter is publicly accessible and will be deleted, and prominently publish a link to it as well as the username and password to log in to the demo.

If the data needs to be preserved for some non-trivial amount of time for the user to be able to determine whether the application suits their needs (which it doesn't sound like based on your talking about a few days), offer prospective customers the ability to set up a trial installation on your server which is automatically deleted after some reasonable, short period of time.

In addition, this solution will give the users the ability to easily evaluate whether an upgrade provides additional value to them before they upgrade. If the upgrade is in any way whatsoever disruptive, or if a downgrade is non-trivial, that alone can be an advantage.

And all that for the cost of you having some additional web hosting, a cron job and storing a database snapshot and/or a few additional copies of the default database contents.