02-19-2011 06:02 PM
I have done desktop development but I have never developed for any phone before. I have a someone who wants me to develop a proprietary BB app for him. His goal is to make some money doing this and he is concerned about someone getting his application and putting it up on the web where people can download it for free. How can I secure the application from this kind of theft? Are there detailed instructions somewhere?
02-19-2011 08:10 PM
Assuming that it gets out and not downloaded from app world.
You can use the payment sdk at the time it runs for the first time. If it did not come from app world, it probably would not work and you can let the user know that they probably have an authorized version and have them go to app world to install the app properly.
You might want to do a simple test case to verify this.
02-19-2011 10:15 PM
The client had an iPhone app someone wrote for him and he put it on the Apple App store. He thinks people have been downloading it for free from somewhere, though I can't confirm this. Presumably, the stolen version came from the app store and was then posted on the internet. He does not want the same thing to happen again to his BB app.
If the customer pays for the app when they download it from the app store (or in this case, the BB counterpart to the app store), why would they expect to pay again when they register the app to use it for the first time?
With desktop software, executable files can be copied from machine to machine and it's often not very secure. How can I make the app secure? What is there to stop someone from copying the app from phone to phone or from some rouge download or file sharing site to their phone? Do I use the PIN of the phone? How do I tailor the executable so it runs only on a phone with that PIN? Is there documentation describing how the apps are kept safe from theft and how to write the app to protect it from such theft?
02-20-2011 10:34 AM
02-22-2011 01:10 PM
This touches on one of my favorite aspects of the BlackBerry platform in that it is very easy to distribute OTA from anywhere on the web with jad/cod deployment. This model should be embraced, not feared.
Now to help you with your problem...it sounds like you may need to study up on the various license models in use today, as somewhat of a standard since early days of shareware distribution for the desktop (none, static, single, dynamic). All the answers are on the Web for you, just that it can take some time to piece them together. So I'll break down the process for you and let you decide how to implement.
The most secure option is "dynamic", which uses a dynamic key for each installation. The key component is a unique algorithm (that you must define) that uses a combination of an app key and the Device ID to create a unique string commonly referred to as a license code or registration key. At runtime, compare the stored value to a runtime-generated value (based on app key and Device ID) and if they match let the app run, if not disable it.
A license component or class within your application should (at a minimum) support the following basic functionality:
Optionally, you may want to support a trial period and to do this is simple, just store a date or timestamp in the PersistentStore upon first use and compare that to the current date/time when app is used.
I'm not sure how much documentation RIM provides on this topic, but distribution providers typically provide at least some guidance, but they won't usually offer any code snippits. You're on your own for that (for a number of reasons). But you can find some good information if you Google the right keywords. I would recommend searching keywords like "generate dynamic license" and "java", that will probably get you started on a pretty good trail.
Good luck, it's not that all difficult, just can be tricky (and somewhat time consuming) the first time around. The best part is that once you build a licensing component you can easily reuse it in all of your apps. If you ever consider outsourcing this aspect of your project let me know.
02-23-2011 01:20 AM
Thank you for the reply.
Am I to understand that every time my app is downloaded, that copy will be given a unique "app key"? Or will all copies of my app have the same "app key"? Unless every copy of the app downloaded has a unique key (which we might call a copy-key since it is unique to the copy of the app, not just the app), I have doubts that the method you described is secure.
If every copy has a unique key, I can make sure each copy of the app is paid for by checking the key of the copy in a DB on my web site when the user registers. Users could be prevented from paying for one copy and then registering it mutliple times with different PINs. That is what I am trying to achieve.
Now the next question is whether App World will support this distribution model/approach. I.e. will App World stamp each copy of the app with a unique key just before the copy is downloaded? If not, it seems to me that I have to build my own web site to handle the downloads and dynamically stamp each copy when I get a download request. This would mean that I cannot use App World to handle the downloads. And I think it would mean I can't use App World to handle the payments either.
Maybe I need to read up on .jad files. Perhaps the .jad/.cod sytem solves the same problem another way, but at this point I don't see how.
02-23-2011 06:39 AM - edited 02-23-2011 06:41 AM
Sorry, perhaps I should have clarified that the license key you generate at runtime is a one way hash, this is what provides the security. Your app key should be an RPN string that is defined once at development time for your application. When distributed, each device has a unique Device ID that you use in combination with your RPN string and hash algorithm to generate a unique installation key. To validate at runtime, your app should generate a license key using the one way hash algorithm and then compare it to the stored value at the time of purchase or download. If no match or no stored value, then your app should be in free trial mode or disabled.
If RPN doesn't make sense it means Revers Polish Notation. Google it and you will be busy for quite a while. But this should get you down the right path...
02-24-2011 01:50 PM
I think there is a problem with your approach and I don't think you see it. I don't think you understand my question. Unless each copy of the app has a unique key (ID), I don't see how you can make it secure that way. Each device having a unique device ID is not good enough.
02-24-2011 02:35 PM - edited 02-24-2011 02:37 PM
Perhaps you don't understand something about my explanation, but this methodology is correct.
Please study up on hashing algorithms (particularly those that use RPN), it's crucial to this methodology. Once you understand that, you'll understand what I'm talking about and it will all make more sense, I promise.
But to your point, each BB has a unique key called a Device ID. You use this, plus a standard key (made up on string of your choosing) for your application and create an encrypted hash based on these values. The app key is always the same, the Device ID is always unique, the combination in an encrypted hash is extremely secure. The only way to break it is to determine the app key you come up with, plus generate an algorithm that exactly matches the one you also come up with. And the only way to unlock it (i.e. register the app) is to provide the resulting hash value (typically a numeric value who's length is up to you), then your app generates the hash based on known app key and Device ID and compares the result. How could it be more secure than that?
You could always go with a less secure model of Static, Single or None, but I will continue using the Dynamic method because it is extremely flexible and, dare I say, bulletproof, and has served me quite well over the years.