Practically, if the code and keys are on an SD card machine, they will be able to de-compile it, they will be able to discover the keys and they will be able to extract the sensitive data.
It's like encrypting movies, a DVD has to include all of the information required to decrypt the movie so that it can be displayed to the viewer, so all movie copy protection mechanisms are ultimately doomed.
The best you can do is change the economics of reverse engineering your product.
Is encryption and/or obfuscation worth it?
Now we have established that there is no way to completely protect yourself, the questions become
- How likely is this to happen?
- What is the value to someone else of your algorithm and data?
- What is the cost to them of buying a license to use your software?
- What is the cost to them of replicating your algorithm and data?
- What is the cost to them of reverse engineering your algorithm and data?
- What is the cost to you of protecting your algorithm and data?
If these produce a significant economic imperative to protect your algorithm/data then you should look into doing it. For instance if the value of the service and cost to customers are both high, but the cost of reverse engineering your code is much lower than the cost of developing it themselves, then people may attempt it.
So, this leads on to your question
- How do you secure your algorithm and data?
The option you suggest, obfuscating the code, messes with the economics above - it tries to significantly increase the cost to them (5 above) without increasing the cost to you (6) very much. The problem is that as with DVD encryption it is doomed to failure and if there is enough of a differential between 3, 4 and 5 then eventually someone will do it.
Another option might be a form of Steganography, which allows you to identify who decrypted your code and started distributing it. For instance, if you have 100 different float values as part of your data, and a 1bit error in the LSB of each of those values wouldn't cause a problem with your application, encode a unique (to each customer) identifier into those bits. The problem is, if someone has access to multiple copies of your application data, it would be obvious that it differs, making it easier to identify the hidden message.
The only really secure option is to provide a critical part of your software as a service, rather than include it in your application.
Conceptually, your application would collect up all of the data required to run your algorithm, package it up as a request to a server (controlled by you) in the cloud, your service would then calculate your results and pass it back to the client, which would display it.
This keeps all of your proprietary, confidential data and algorithms within a domain that you control completely, and removes any possibility of a client extracting either.
The obvious downside is that clients are tied into your service provision, are at the mercy of your servers and their internet connection. On the plus side, they are always up to date with bug fixes. Unfortunately many people object to SaaS for exactly these reasons.
This would be a huge step to take though, and could have a huge cost 6 above, but is the only way I can see to keep your algorithm and data completely secure.