If you write a PHP application, where you have to deliver the compiled code to the customer, how could you include a functionality to send encrypted data from that application to others, and include those needed keys inside the code, so the customer cannot reverse engineer it so easily?
Just including the keys in the code and compile it with ionCube doesen't seem the best solution for this:
How secure is ionCube compiled code? ... not secure enough
With the standard engine, you can't. There are a number of code obfuscator available as well as several PHP code protection tool but none will offer you good protection against an attacker who knows what he's doing.
There is one additional issue that I read in your description of your problem: you seem to want to protect passwords or other secret data using code obfuscation. If that is indeed the case, then stop right there: there is NO way to protect such data from someone with a debugger if you follow that path. All you can do is slow down a potential attacker so your only hope is that the data you want to protect is not worth the time spent retrieving it.
If you really must provide robust data security in your application, you'll need to find another model (which will depend on what you're doing, exactly).
Well, you know that every software in the end-user (be it a client, a regular costumer that is viewing a video, etc) can be reverse-engineered.
And that applies to any solution like "download the keys from a server", because once your program is descompiled, the user has access to it.
I don't think anyone here will be able to give you a better solution than those comercial tools already give you, so if you just want to make it harder for your client, go with those obfuscation - encryption solutions, and hope for the best.
You could also try using some custom hardwre (like a token) that will have part of the code, or some essencial function, inside it. And you can also have some webservice, so that your client will acess your webserver and just receive the data after you do some processing. And, of course, both these alternatives have drawbacks.
Since your comment clarified that you need to deliver a whole machine (or VM) and if you have that in mind then you're into a different ballgame. Forget trying to do anything to or with the PHP, it's not secure when the attackers have access to it and trying to make it that way is arguably a fools errand.
Delivering the whole machine however has much more scope for securing access. You can probably get some help if you have scope to dump Linux derivatives in favour of a BSD which has a more robust security model as I understand it.
Security is always relative. If they have control of the box and are determined, resourced and skilled enough they'll get through whatever you implement. Other options might be more profitable along the lines of allowing them to think they've broken your security and logging when the usage agreements have been broken for you to charge them accordingly.
For additional protection than encoding already gives, deviating from a standard PHP build would offer some advantages, and you could use a custom C based module where the key is compiled into the module and not existing within the PHP code. However consider what protection there is to the data before it is encrypted; PHP itself is opensource and can be modified, so there are inherent risks from that and hardware solutions mentioned in replies may therefore not help, and are not immune to reverse engineering.
Steinberg used hardware dongles for Cubase, and they were successfully reverse engineered years back and software emulations released. Despite sophisticated on-chip anti-tamper protection such as light detectors and signal voltage monitoring, the hardware set-top box viewing cards used for a UK TV service called on-digital were successfully reverse engineered, allegedly by a competitor, leading to cloned cards being produced and the resultant demise of the company. The aim with protection is to make reverse engineering as tricky, expensive, and time consuming as possible, but it can never be prevented.
When you deliver a working system into the hands of your attacker, you cannot prevent them from reverse-engineering it. There are no exceptions.
But with clever distribution of keys and certificates, you can alleviate some of the trouble. If each user gets his own key and certificate (signed by you), then you can uniquely identify that user by anything he signs. Sharing his key would reveal the identity of the person who shared it.
Likewise, by distributing public keys for encrypting outbound data, you can limit decryption to only those machines that possess the associated private key.
IN RESPONSE TO COMMENT
only need the strictly confidential data somehow stored on the harddrive encrypted and the decryption should be only possible through my software.
You lost at "decryption should only be possible through my software". This is 100% absolutely positively impossible. What you've described is, exactly, DRM. Read Cory Doctrow's explanation of this from almost a decade ago. Some of the smartest and most financially-motivated individuals have worked on this, and continue to work on this to this day, and at no point has it ever actually worked. Because it can't.
What you can instead do is have decryption done only on your server, or a similar solution. The way (the ONLY way) to prevent the client from decrypting your data is to not give him the key. Which means he can't be the one decrypting it.
